Hi Randi, On 09/05/17 08:45, Randy Li wrote: > > > On 05/09/2017 03:40 PM, Guillaume Tucker wrote: >> On 09/05/17 02:16, Randy Li wrote: >>> >>> >>> On 05/09/2017 12:27 AM, Heiko St?bner wrote: >>>> Am Mittwoch, 3. Mai 2017, 10:56:24 CEST schrieb Guillaume Tucker: >>>>> The ARM Mali Midgard GPU kernel driver is only available >>>>> out-of-tree and is not going to be merged in its current form. >>>>> However, it would be useful to have its device tree bindings >>>>> merged. In particular, this would enable distributions to create >>>>> working driver packages (dkms...) without having to patch the >>>>> kernel. >>>>> >>>>> The bindings for the earlier Mali Utgard GPU family have already >>>>> been merged, so this is essentially the same scenario but for >>>>> newer GPUs (Mali-T604 ~ Mali-T880). >>>>> >>>>> This series of patches first imports the bindings from the latest >>>>> driver release with some clean-up then adds a gpu node for the >>>>> rk3288 SoC. This was successfully tested on Radxa Rock2 Square, >>>>> Firefly, Veyron Minnie and Jerry boards using Mali kernel driver >>>>> r16p0 and r12p0 user-space binary. >>> I won't suggest such combine. We meet some problems at mali 400 serial. >>> I would suggest the kernel version would match the user library. >> >> Well, I can test it again with r12p0 kernel driver (out-of-tree) >> if you want. The user-space driver checks the version of the >> kernel driver and gives up if it's not compatible. With Midgard, >> there's a range of versions that maintain kernel/userspace >> compatibility unlike Utgard and older Midgard releases where they >> had to exactly match. Again, if there was a mismatch then the >> user-space would fail to initialise and report an error. > Anyway, could you verify the mali userspace library r13p0? The latest user-space binary available from developer.arm.com for rk3288 is 12p0. Maybe Rockchip could make some new binaries available to the public? > Rockchip would use this version to offer the support of X11, wayland and gbm. Sounds great, although windowing systems are quite far away from GPU device tree bindings so I don't think this is too relevant for this current patch series. On a side note, it would be fantastic to get all this available in Debian packages :) >>> Also please notice there is rk3288w, the hardware version becomes r1p0. >> >> Sounds like a new SoC? Does rk3288w affect rk3288 in any way? > It is not a new SoC, just a new version of rk3288. It fixes a various of the chip bug of the rk3288. I see. I don't have access to any rk3288w platform but if you do then I guess it would be nice if you could test these patches on it :) Also I'm not sure if all rk3288 device trees changes must be tested on rk3288w, and this SoC is not mentioned anywhere in the kernel (as far as I can tell). Is there anything you think should block these current patches which only claim to support rk3288 from being merged? >> Unless it's a special case, it seems to me that any new SoC with >> a Midgard GPU would need an extra vendor compatible string in the >> binding documentation and maybe a separate gpu dt node. >> >>>> The actual devicetree parts are all Rockchip-specific, so I guess I'll just >>>> pick up the whole series, including the binding doc, after the merge >>>> window if nobody complains before that :-) >> >> Thanks! Guillaume P.S. kernel branch with a Mali driver I used for testing: https://git.collabora.com/cgit/user/gtucker/linux.git/log/?h=linux-4.11-mali-dt-rk3288
