06:41 <rperier> amstan: hehe, still need to backport edp driver (until it is merged in mainline) to check that this part works fine, the rest seems ok :)

06:41 <rperier> (modulo some bugs in next... but that's next...)

06:42 <rperier> (linux-next I meant)

06:42 <rperier> hi all btw

06:52 <sjoerd> ooi does anyone happen to know of hand how similar the lcd controllers are on RK31xx and RK32xx ?

06:57 <mmind00> sjoerd: the lcd controllers themselfs are quite similar ... the big difference is memory management

06:57 <mmind00> sjoerd: i.e. rk32xx uses an iommu, where the older ones do not

06:58 <mmind00> sjoerd: and the driver currently can only handle the iommu-path ... would probably need something cma-based for the others

07:02 <sjoerd> I see

07:02 <sjoerd> mmind00: thanks!

07:03 <mmind00> sjoerd: ah forgot to mention ... the output encoders connected to the lcd controllers are different too

07:04 <mmind00> sjoerd: aka stuff like hdmi etc is created by external chips on the rk3188

07:04 <sjoerd> Nod

07:04 <sjoerd> it's a RK616 or somesuch on the rock pro i have here

07:05 <mmind00> yep, or an IT-something on the earlier ones

07:05 <sjoerd> yup

07:06 <sjoerd> not having to do a driver for the lcd part form scratch is at least very helpful :)

07:07 <mmind00> sjoerd: hehe ... having iommu and non-iommu allocation both supported in a driver is also already done in some other drm drivers, so you can get inspiration ;-)

07:08 <sjoerd> mmind00: Yeah exynos does that indeed

07:08 <sjoerd> as one example

07:08 <mmind00> sjoerd: the hard part will probably be trying to manage two possible failing components (encoder

07:08 <mmind00> + lcdc)

07:08 <sjoerd> Yes

07:09 <sjoerd> That's always the fun if iti doesn't work with these things isn't it

07:09 <sjoerd> "something somewhere is wrong"...

07:10 <mmind00> yep :-)

07:11 <mmind00> sjoerd: anyway, https://github.com/mmind/linux-rockchip/commits/devel/lcdc-workbench contains some old things, where I at least compared the register sets a bit ... and I think rperier also did some first steps in this area

07:11 <rperier> indeed , I did

07:11 <rperier> few months ago

07:11 <rperier> https://github.com/rperier/linux-rockchip/tree/topic/drm-noiommu <--- you can look at this branch

07:12 <mmind00> rperier: when is the speedy v2 patch coming? :-D

07:13 <naobsd> it might be nice if someone support lcdc and hdmi bridge on u-boot too ;)

07:14 <sjoerd> It might be nice if rk3188 worked with upstream u-boot first :p

07:14 <naobsd> where can I buy my spare time? :)

07:14 <sjoerd> If you find out, do tell

07:14 <naobsd> by 1click

07:18 <rperier> mmind00: I will try to do it this noon (or this evening in the worst case), I don't do rockchip stuffs at work (unfortunately) :)

07:19 <mmind00> rperier: great

07:19 <rperier> :)

10:55 <rperier> don't compute Doug remarks about node names and "_" instead of "-"... I mean... everything in the dts for jerry is named with "_"...

12:17 <mmind00> rperier: "edp_hpd: edp_hpd" -> "edp_hpd: edp-hpd"

12:17 <mmind00> rperier: the one with the ":" is the node reference with a "_", node-names normally have a "-"

12:18 <mmind00> rperier: but the epd should stay out for the time being anyway

12:19 <mmind00> rperier: I'm with Doug on this, to add epd stuff to all boards once the epd driver lands ... from what I've heard, shouldn't be long now for the merged driver to appear (aka exynos is using a similar edp IP)

12:25 <rperier> oh I totally agree about edp, I was just wondering what he meant for the naming issue

17:02 <rperier> mmind00: if I remember correctly, you have a not completly stable wifi for veyron in your devel/somewhat-stable branch ? no?

17:07 <mmind00> rperier: correct

17:07 <mmind00> rperier: the mwifiex can connect but when it is supposed to start transmitting real data it somehow dies

17:08 <rperier> mhhhh....I will try on my veyron and try to investigate

17:09 <rperier> I mean, if you don't plan to do it yourself of course

17:09 <rperier> that's a good way to learn how wifi really works in the kernel

17:11 <rperier> sorry if my sentences are not very clear... my brain itself is not really clear... I had an hard student night yesterday... I am not completly... "fresh" ... (tiny hangover) :/

17:12 <rperier> :D

17:14 <cristian_c> hello

17:14 <cristian_c> I'd like to access to mount user readable/writable nand partition (i.e. /sdcard)

17:15 <cristian_c> I think loop* block files are related to mtd partitions and I think I could mount /system or /sdcard , mtdblock8 and mtdblock9, respectively (they are ext4 the first one and vfat the second one). So, I'd like to know if maybe I've to enable some CONFIG options in the kernel configuration file or to something else. Any ideas?

18:13 <amstan> mmind00: i remember steev and leming dealing with that a while ago on 3.14, but they fixed it eventually

18:13 <steev> amstan: nah, mwifiex is just a shitty driver.

18:14 <steev> amstan: my "workaround" is s2r and resume

18:14 <amstan> but it works fine for me on jerry right now

18:14 <amstan> oh yeah.. broadcom doesn't resume properly

18:14 <steev> i don't have a jerry

18:14 <amstan> rperier: you'll be the one having fun with that, speedy is broadcom afaik

18:14 <steev> yeah, i've noticed that with minnie

18:14 <leming> the main issue came from using the 3.14 drivers instead of 3.8

18:15 <steev> the 3.8 stack is heavily patched to work

18:56 <rperier> amstan: what do you mean ? all veyron don't have the same chipset for wifi ?

18:56 <mmind00> rperier: sorry, I'm back now ... I currently don't plan on spending larger amounts of time on wifi at the moment

18:57 <mmind00> rperier: yep, some are Marvell based and some use a Broadcom module

18:57 <rperier> arf... I see ^^

18:57 <rperier> I want to use my wifi on speedy so I will try my best

18:59 <mmind00> rperier: see the mail from Michael Trimarchi ... who seems to have wrangled the broadcom chips a bit already

19:38 <amstan> rperier: arch's kernel/drivers should work

19:38 <amstan> rperier: for broadcom, as long as you don't expect it to work after a resume