13:27 <tkaiser> Anyone here around with a RK3328 device using DDR4 DRAM? Libre Computer Renegade / ROC-RK3328-CC for example?

17:55 <ccaione> mmind00: was looking at the UCM files for the VEYRON-I2S but to have it gracefully working with PA I need to add in the UCM the playback / capture PCM. Was wondering why it wasn't already done before

18:00 <mmind00> ccaione: I'm pretty clueless in sound-things ... the veyron-i2s ucm profile seems to stem from the ChromeOS sources and all I did was fixing the naming, so it doesn't occupy the generic rochchip-i2s naming

18:02 <ccaione> mmind00: no worries. I just find odd that this trivial fix is needed at all since the UCM file is upstreamed without it, so I wonder if I'm missing anything. I'll try to send a patch to the alsa guys, let's see what they say.

18:03 <mmind00> ccaione: hehe ... I'd just guess it really is just the unmodified chromeos profile and maybe nobody needed it then

18:04 <ccaione> we will see soon ;)

19:06 <Kwiboo> tkaiser: I have the ROC-RK3328-CC with DDR4 but was not around when you asked, I even got a pull request from T-Firefly with special DDR4 timings, going to test that later or tomorrow

19:15 <Kwiboo> mmind00: I have been using your rk3328 hdmi patchset on my rock64 device a few days and noticed some issues with vblank timeouts, I found the issue but could need some guidance on how to submit the patch (first time submitting to linux mainline)

19:15 <Kwiboo> would very much appreciate any feedback on https://github.com/Kwiboo/linux-rockchip/compare/7a99a049d4a6836fbd538d3b0534f87b2dd3e29d...9d54485bdf309302d0e3c1c1daeb7c4efbd06b67 before I try to figure out how and where to send :)

19:24 <mmind00> Kwiboo: first of all, please try maz vop irq patches (https://lkml.org/lkml/2018/2/20/249) before touching the vop irq code again

19:25 <mmind00> Kwiboo: and I think the whole Kevin chain of drm patches might also contain some vop-related fixes if I remember correctly

19:27 <mmind00> Kwiboo: if you need a base ... try my test-branch from yesterday https://github.com/mmind/linux-rockchip/commits/tmp/testing_20180312

19:28 <mmind00> Kwiboo: in general there a currently way to many drm-related patches in flight that either depend or conflict with each other ... and I'm trying to work my way through them slowly ;-)

19:29 <mmind00> Kwiboo: as for "where to send", please use scripts/get_maintainer.pl on a very recent kernel (4.16-rc ideally), as the rockchip drm-maintainership changed

19:29 <Kwiboo> I think I did test maz irq patches but will try again, the issue I had was caused by vop_bind completing but phy init defer probe due to efuse not being initialized, resulting in disable_irq calling twize when adding the iommu patchset

19:30 <tkaiser> Kwiboo: Nice, in case you could run a tinymembench <https://github.com/ssvb/tinymembench> it would be great. Since DDR4 should be somewhat faster than the DDR3/LPDDR3 setups out there.

19:33 <Kwiboo> mmind00: thanks for advise, I will check your test branch, I have only cherry picked some commits from drm-misc-next into my v4.16-rc test tree

19:34 <mmind00> Kwiboo: also, shouldn't the devm_request'ed irq be automatically freed in unbind?

19:34 <mmind00> (or after unbind to be precise)

19:35 <Kwiboo> tkaiser: will test shortly, using default RK 4.4 timings/opp + 1066mhz was rather unstable, hoping for stable 1066mhz this time

19:38 <Kwiboo> mmind00: I am not sure, the unbind was called and irq was left disabled causing none of iommu or drm irq func being called

19:39 <mmind00> Kwiboo: I didn't mean the enable_irq part ... more the devm_free_irq you have in there :-)

19:45 <Kwiboo> not sure the devm_free_irq call was needed, only tested it all togheter at this point, will test more, thanks for feedback and suggestions

19:55 <alyssa> btw, just wanted to let everyone know, on the RK3288 and a mainline kernel, HDMI support appears to be flawless. kudos to whoever worked on that \ o /

20:03 <mmind00> alyssa: glad it's working so nicely for you

20:04 <alyssa> :)

20:04 <alyssa> admittedly I needed like 3 different adaptors/extenders to connect to my DVI monitor, but hey, not the laptop's fault that my monitor is weird ;)

20:05 <mmind00> alyssa: and I guess most kudos need to go to Rockchip for that, as their developers were responsible for creating the whole graphics stack initially

20:22 <Kwiboo> mmind00: do you have datasheet for inno hdmi phy on rk3328, I created a patch to support vesa dmt pixel clocks on RK 4.4 kernel but would like to port it to mainline, see https://github.com/Kwiboo/linux-rockchip/commit/f166ba88945f1ea7ff327bb9f22f53aed728dde3, it will not work as-is and requires some changes to dw_hdmi_rockchip_mode_valid to get it working

20:23 <Kwiboo> I generated the clock configs based on assumptions that low vco was best, I do not know if this is correct or what the optimal config would be

20:28 <mmind00> Kwiboo: sadly nope ... there is no datasheet available ... Innosilicon seems to be very restrictive

20:32 <Kwiboo> ahh, too bad, the clocks I generated seems to work for the rates I have been able to test, but may not be the most optimal

20:43 <mmind00> Kwiboo: I'd guess we could first place the phy as is and then add your rates and involve Rockchip people to cross-check

20:44 <mmind00> i.e. they do have a datasheet but are not allowed to release to _anybody_

20:46 <alyssa> sounds mildly dystopic

20:52 <mmind00> hehe, yeah the joys of having separate intellectual property holders

20:54 <alyssa> ......sounds mildly dystopic

20:59 <Kwiboo> hehe, hopefully someone at Rockchip can cross-check later, I based the dmt clock configs on the existing cea clocks and info found in commit messages + comments in RK 4.4 code, generated all possible combinations with the info I had and sorted the matching variants based on similar principal as the general plls in rk3328/rk3399

22:26 <micken> beeble: http://www.update.uu.se/~micken/rolcog.jpg :)

23:51 <beeble> micken: congratulation