10:58 <afaerber> javier__, do you recall what happened to https://patchwork.kernel.org/patch/4884221/ ? I don't see it applied and no resend

11:05 <javier__> afaerber: yes, Lee didn't want the dev->of_node check since now the devices will be populated by DT

11:05 <javier__> but that is not true with the latest series that add support for the cros_ec user-space interface since that is not represented in DT

11:06 <afaerber> javier__, if I add an i2c-tunnel node for Spring, should linux-next be okay or do I need that patch?

11:07 <javier__> afaerber: so I decided to drop the patch and will post it once "[PATCH v5 0/7] platform/chrome: Add user-space dev inferface support

11:07 <javier__> is merged

11:07 <afaerber> the issue I'm seeing is that if I add both the tunnel with google,limited-passthrough support and the sbs-battery it doesn't boot

11:08 <afaerber> if I drop the sbs-battery it boots but I'm unsure whether it's picking it up the tunnel correctly

11:10 <afaerber> javier__, btw I got the mwifiex firmware to load if I make it a module - but not built-in ;)

11:10 <afaerber> it shows up as mlan0 in ip a, but I didn't manage to really test it

11:15 <javier__> afaerber: so you shouldn't need that patch for spring (at least for the device registration)

11:16 <afaerber> javier__, specifically because of the cros ec register code for cros-ec-i2c-tunnel? i.e., will I need it for the tpc65090?

11:16 <afaerber> *tps

11:27 <javier__> afaerber: no, because the "cros-ec-i2c-tunnel" is registered as an i2c bus so *I think* the i2c subsystem takes care of traverse the tree and register each child device

11:29 <javier__> afaerber: so you only need to add as mfd cells, the devices that are connected to the cros ec "bus" (i.e: the i2c tunnel and keyboard)

11:30 <afaerber> hm, I thought that the tpc65090 was not on the i2c bus, therefore the separate driver needed, only the sbs-battery is located there DT-wise

11:30 <afaerber> *tps65090

11:40 <javier__> afaerber: yes it is, in the i2c bus in the EC like in the peach pit/pi boards

11:41 <afaerber> javier__, https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/regulator/cros_ec-tps65090.c

11:41 <afaerber> that's not an i2c driver, so it cannot live on an i2c bus :)

11:42 <javier__> afaerber: yes but that is a problem in spring since the EC in Spring does not support the EC_CMD_I2C_PASSTHRU command

11:43 <javier__> that's why they forked the tps65090 driver and communicate directly with the EC to manage the regualtors

11:43 <javier__> look at those EC_CMD_LDO_SET commands

11:43 <afaerber> and my question was whether I need your patch for upstreaming that forked driver ;)

11:43 <javier__> afaerber: Doug explained very well here what is the problem and the possible solutions: http://code.google.com/p/chromium/issues/detail?id=391797

11:44 <afaerber> I know and I have the i2c-tunnel already patched

11:44 <afaerber> https://github.com/afaerber/linux/commits/spring-test

11:46 <javier__> afaerber: cool, then you should be able to use the standard tps65090 driver right?

11:46 <afaerber> javier__, why? that's not what Doug writes. it only handles sbs-battery 0xb

11:53 <javier__> afaerber: what doug wrote (afaiu) is that the i2c-tunnel driver has to be extended to translate between i2c writes and reads to smbus (if that is possible) or use custom EC commands like vincent does for the sb battery (EC_CMD_SB_*) but also for the tps65090 regulators (EC_CMD_LDO_*)

11:54 <javier__> afaerber: so you can use the standard sb battery and tps65090 drivers and make the i2c-tunnel to translate to what the EC supports

11:56 <javier__> so vincent's patch is just a reference but more work is needed

11:56 <javier__> afaerber: I may had missunderstood though

11:57 <afaerber> I'm taking one step at a time, trying to fix my dark display - right now I can say that at least with your patch my i2c-tunnel gets initialized and correctly picks up the google,limited-passthrough setting

12:01 <afaerber> the tps65090's lcd_vdd vfet6 is my hope there

12:02 <afaerber> the only thing of note in dmesg otherwise is vdd_g3d getting turned off, which I guess is okay since I don't have Mali/Lima drivers

12:04 <javier__> afaerber: yeah, you do have backlight though right? do you know what is the power supply for that?

12:04 <javier__> on peach pit/pi is fet2 the power supply for backlight and fet6 for the display

12:08 <afaerber> javier__, no, my problem is that the display more often than not stays dark when I power-on the device. I see on USB when to press Ctrl+d and then previously the display went on either in U-Boot or when the kernel was at a certain point. now it stays dark, no backlight and said "unable to config video" on next-20150218

12:09 <afaerber> I already read the non-external-pwm code path in ps8622 with no insights

12:10 <afaerber> if it's a regression in the bridge patches, it must've happened between v7 and the merged v9

12:10 <afaerber> change log was not telling

12:13 <javier__> afaerber: I see :-/

12:14 <javier__> afaerber: btw, you can change the Google Binary Block (GBB) flags to avoid the need to press Ctrl + d

12:15 <javier__> but need to remove the write protect screw or whatever the wp mechanism is used on Spring

12:18 <javier__> afaerber: sylwester's answer about setting the CLKOUT parent in DT is very interesting btw

12:19 <afaerber> yeah, slightly complicated though ;) at least lots of clocks for exynos4 odroid

12:20 <javier__> yeah, but I think is because they are using "simple-audio-card" which is generic so you need to describe more

12:20 <javier__> I'll look if I can come up with something for snow and peach pit/pi that avoids needing tushar's patch to reparent XCLKOUT

12:29 <afaerber> just verified that the old next-20141124 still enables the backlight and screen, so no hardware defect :)

12:30 <afaerber> (other than a vertical dark pixel line across the screen)

12:31 <javier__> afaerber: it may be interesting to diff the drm bridges patches to see what broke on spring

13:01 <afaerber> javier__, hah, the C code is 100% identical :/

13:01 <afaerber> ftr https://github.com/afaerber/linux/commits/spring-test.20141124+bridge

13:04 <afaerber> (some sorted as 2000)

13:07 <javier__> afaerber: I see, so is something that change in the meantime in linux-next :-/

13:08 <afaerber> maybe it's the drm changes, or something with timing of the various components...

13:08 <afaerber> (ps8622 identical, I meant obviously)

15:16 <javier__> afaerber: can you try if this makes the audio to work on Spring http://paste.debian.net/plain/153151

15:19 <afaerber> Doug's i2c-tunnel autodetection did not work on Spring, I am now rebasing to next-20150220 where your clk fixes seem to be applied already

15:20 <afaerber> javier__, no assigned-clock-rates = <0>; necessary?

15:20 <javier__> afaerber: afaiu from the binding doc is only necessary if you want to have a rate != 0 for an assigned clock

15:21 <afaerber> okay

15:22 <javier__> afaerber: but since the xclout is registered with CLK_SET_RATE_PARENT then it will set the parent rate

15:54 <afaerber> javier__, confirmed that the i2c-tunnel now gets initialized without your sub-devices patch.

16:45 <afaerber> javier__, frequency is 24MHz with your patch, but no sound

16:46 <afaerber> javier__, also it looks kind of weird: either the driver code should map between its clocks property and exposed clocks, or the board should wire them up as appropriate, no?

18:14 <javier__> afaerber: yeah, I still not sure if that clock hierarchy is a property of the platform or the board...

18:20 <afaerber> javier__, hierarchy is soc where applicable, but choices are boards' afaiu

18:21 <afaerber> at least that's what I've seen on stm32 and other platforms, with choices depending on whether there is an external clock or not etc.

18:44 <tyler-baker> javier__, sjoerd great work on the peach pi/pit btw. I build upstream uboot/linux and ran the debian installer, worked great. only issue I have to resolve is why X is not starting. I see a 'atmel_mxt_ts 8-004b: Invalid object type T9.' Looks like there are patches posted for T100 touch object, should I give those a try?

18:47 <tyler-baker> javier__, sjoerd while I'm asking, if there are other patches I should use let me know. :)

18:59 <sjoerd> tyler-baker: Do you have a pi or a pit? The pi touch stuff still needs some patches i think

19:03 <tyler-baker> sjoerd, pi

19:03 <tyler-baker> sjoerd, ok I'm patching things now

19:05 <sjoerd> You'll have to ask Javier for the state

19:05 <tyler-baker> sjoerd, ack sounds good

19:05 <sjoerd> the atmel touchpad maintainer doesn't push very hard unfortunately

19:06 <tyler-baker> sjoerd, I notice those patches have been sitting there for quite some time :\

19:06 <sjoerd> Nod

19:30 <javier__> tyler-baker: yeah, I posted http://comments.gmane.org/gmane.linux.kernel.samsung-soc/40927 a couple of months ago but the atmel touchpad maintainer said that posted another version that superseded my series and that should be applied instead

19:30 <javier__> then got feedback on his patch and disappeared...

19:31 <javier__> tyler-baker: I'll address the issues pointed out on nick patch, rebase and repost next week, will cc you

19:35 <javier__> tyler-baker: I've also a DT patch from Samsung and an ucm profile for audio playback and capture on peach pit/pi

19:36 <javier__> the mainline ASoC driver seems to be a little buggy but that is orthogonal so I'll post that next week as well

19:37 <javier__> tyler-baker: and then the only peripheral missing is wifi which I already have DT support for it but there is a bug in the dw_mmc driver that we are looking to fix

19:39 <javier__> tyler-baker: tl; dr there aren't any in-flight patches that you have to apply now but expect some soon :)

19:42 <tyler-baker> javier__, sounds good, more than will to help test :) great information, thanks!

19:42 <tyler-baker> s/will/willing/g

19:53 <tyler-baker> I disabled the atmel mxt driver, and I'm booted into xcfe now, cool

19:56 <javier__> tyler-baker: awesome

20:10 <tyler-baker> enabled UVC and I'm taking selfie's now, so it must be a real computer now :)

20:35 <sjoerd> haha