Messages in this thread | | | Subject | Re: [PATCH v5 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288 | From | Guillaume Tucker <> | Date | Wed, 10 May 2017 11:10:55 +0100 |
| |
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
| |