Am Mittwoch, 10. Mai 2017, 11:10:55 CEST schrieb Guillaume Tucker: > 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?
