12:47 <forkbomb> mszyprow: hi, i plan on submitting a bunch of new dts for devices related to trats2 (Note 2, Galaxy S3), including a common dts that they share. Do you think I should make trats2 inherit from this DTS as well? Basically the only difference between it and the consumer S3 is the cmdline

12:50 <mszyprow> forkbomb: if possible, go with the pattern already used with odroids

12:51 <mszyprow> forkbomb: exynosXXXX-ZZZZZZ-common.dtsi + exynosXXXX-board1.dts + exynosXXXX-board2.dts

12:51 <mszyprow> Galaxy S3 is basically Trats2

12:52 <mszyprow> the only difference is bootloader/boot chain

12:52 <mszyprow> Note2 is uknown to me, it will probably have different lcd panel

12:52 <forkbomb> yeah. Note 2 has different sensors/lcd/touchscreen

12:53 <forkbomb> there's also the S3 LTE, which has the same panel but different gpios

12:53 <forkbomb> including, apparently, switched SCL and SDA lines for the camera i2c

12:54 <forkbomb> but yes, thanks. that's what i'll do

12:58 <mszyprow> forkbomb: did you manage to fix the the issues with trats2 panel driver?

13:02 <forkbomb> mszyprow: not yet

13:02 <forkbomb> i got wifi working though!

13:03 <mszyprow> forkbomb: nice! send patches then :)

13:03 <forkbomb> https://patchwork.kernel.org/patch/10048467/

13:07 <javier___> forkbomb: I think you should use non-removable instead of broken-cd in sdhci_3 node

13:07 <javier___> since is a WiFi SDIO module IIUC

13:08 <forkbomb> ok, do the two mean the same thing?

13:09 <javier___> forkbomb: I haven't looked the MMC core for a while so I don't remember if there were a semantics difference

13:09 <javier___> but if you check in Documentation/devicetree/bindings/mmc/mmc.txt non-removable seems to be the correct choice for you

13:10 <forkbomb> ok, i'll try it. it looks like broken-cd configures it to poll

13:10 <forkbomb> the tizen 3.10 kernel uses broken-cd, which i guess is where i got it from

13:10 <javier___> I mean, why there would be a card detection pin for a non-removable SDIO chip?

13:11 <forkbomb> that's true

13:11 <mszyprow> javier___: afair non-removable means probe once on boot, broken-cd poll for changes

13:11 <mszyprow> not sure how it integrates with mmc power seq

13:12 <forkbomb> i guess we'll find out...

13:12 <javier___> mszyprow: I see, that makes sense

13:12 <mszyprow> tizen 3.10 kernel used broken-cd to workaround lack of mmc power seq afair

13:13 <javier___> mszyprow: yeah, and also used (faked) regulators to toggle the GPIO pins for the reset sequence IIRC

13:13 <javier___> another DT hack :P

13:14 <forkbomb> yeah, non-removable works properly

13:14 <krzk> forkbomb: mszyprow: about the split of DTSes for common parts - it depends on common parts. We had in Exynos two patterns... or actually three patterns:

13:15 <krzk> forkbomb: 1. Have common dtsi (like Odroid).

13:15 <krzk> 2. Split common blocks and include them (e.g. audio, some periphereals), like Snow and partially in Odroid.

13:16 <krzk> 3. (kind of modification of 1) include DTS in other DTS and customize it (example some time ago: TM2 and TM2E for ARM64, but recently it was converted to Odroid model (1)).

13:16 <krzk> forkbomb: so it all depends - what are the differences and how the code will look like at the end

13:17 <forkbomb> i think what i have at the moment is 1/3 - https://gist.github.com/fourkbomb/165cdfa489af06d46f066929949ef53a

13:17 <forkbomb> i'll probably drop c1 and unify t0-lte/t0-3g for now

13:17 <mszyprow> krzk: split for common blocks is done because there are >1 boards which use them, but not all needs them (odroid xu3/xu3-lite audio vs. xu4 and hc1)

13:18 <forkbomb> since c1 is identical to m0 barring the modem

13:18 <forkbomb> and t0 are the same

13:18 <forkbomb> and i doubt i'll figure out the modem in the near future

13:28 <javier___> forkbomb: while being there I would also change the 0 for IRQ_TYPE_NONE in your interrupts property second cell

13:28 <javier___> besides those trivial comments the patch looks good to me

13:30 <krzk> mszyprow: yeah, true, the common blocks for specific parts make sense if they will be re-used by many, not just by two.

13:31 <mszyprow> krzk: two? what's the point duplicating the whole audio block in xu3.dts and xu3-lite.dts? it is better to make -audio.dtsi and include it both

13:33 <forkbomb> javier___: ok, i'll do v3 tomorrow then

13:35 <javier___> forkbomb: cool

13:49 <krzk> mszyprow: before having XU4 the audio block would be just part of "common" because there is no point of splitting something out of common DTSI just for two DTSes. However now you are referriing to a tree of three devices, sharing common part (DTSI) but only two of them have audio - then yes, let's share it