14:40 <fungi> saw the hdmi support patches for the 3288 and 3399 hit the ml today... anybody know if there's work underway somewhere in the community to support hdmi on the 3188?

14:45 <fungi> trying to decide if i'm better off collaborating on that or just ditching the dev boards i have now and moving on to a newer generation sbc/soc

15:10 <xandey> sjg1_: I had another look, and found a few things to revert and change to get things partially working on rk3288 rock2. What is a good way to start a dialog about this?

15:10 <xandey> Should I send you an email and cc the u-boot list? Do I attach the 2 reverts and 2 commits?

15:10 <xandey> I don't really think they're what the eventual fix would be.

15:38 <sjg1_> Yes please send to u-boot list and cc me. The patches should be sent separately to the list (e.g. with patman)

19:13 <xandey> sjg1_: took me a bit to figure out patman, and it looks like I didn't mange to cc the maintainer list, sorry.

20:30 <sjg1_> xandey: No problem. It should cc maintainers automatically if you don't give it the -m flag. If you get alias errors, use -t

20:56 <mmind00> fungi ... rk3288 has hdmi support for over a year now :-) ... only the rk3399 is new ... as for the rk3188 ... it doesn't bring hdmi encoders (or any other graphics encoder) in the soc itself ... i.e. the lcd-controllers only output rgb to separate encoder chips on the boards

20:58 <mmind00> fungi: I think I saw a patch applied to make the core drm driver for rockchip support non-iommu-based graphics (like the rk3188 and before), but while all the Rockchip Android sources most of the time do contain sources for those separate encoder chips ... (nearly) all of them carry some proprietary license header, so you can't legally use them as base for a sane driver

21:00 <xandey> sjg1_: yeah, i'm not sure what I did. my history just show the -i option since the revert didn't pass the style guidelines. I might have done the git-send-email command separately though.

21:00 <xandey> Thanks for taking a look. We are OK with the older version though, so not critical.

21:16 <fungi> mmind00: thanks for the details. and yeah i misread the patch series... now i see the commit message simply referred to reusing some of the 3288 support for 3399

21:17 <fungi> i'll have to go back over the circuit diagrams for the rock pro and figure out which chip is intended to be doing hdmi encoding on it in that case

21:24 <mmind00> fungi: you might be in luck there ... the original rock had a "it66121fn" (that's the one I know with the proprietary sources) while on the rock pro they seem to have switched to a rk616 which is Rockchip's own chip

21:25 <mmind00> fungi: https://github.com/radxa/linux-rockchip/tree/mirror/rk3188-rbox-jb/drivers/video/rockchip/hdmi/rk616 does not have any license headers, so I would assume the COPYING on the kernel root dir should take effect (aka GPL2) ;-)

21:28 <mmind00> fungi: so essentially you would need to add the rk3188 lcdc variant to the vop-part of the drm driver (the TRM on radxa's site does contain necessary informations) and then somehow convert the rk616 driver into a sane one

21:36 <fungi> mmind00: ooh, awesome. i'll see what i come up with

21:37 <fungi> i've played around with their forked android kernel sources some. unfortunately they do silly things like hard-code only one resolution into them

21:38 <fungi> which, for the lvds makes sense. hdmi less so

21:41 <mmind00> fungi: yeah, the old Android cruft is pretty crazy, but juding by the age of the rk3188 and earlier, I don't think they'll get much vendor-mainline-love

21:41 <mmind00> but of course I may be (and definitly hope to be) wrong