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? >From what I've read on #linux-rockchip: <wzyy2> rk3288w have some differences: USB HOST : add ohci, fix ehci bug GPU : update rev <wzyy2> VOP, video codec, rga : some bug fix <wzyy2> hdmi : HDCP2.2 So from, yes a new gpu-revision, but that shouldn't affect this series. >From the above I guess the hooks into the rest of the soc haven't changed so rk3288-mali should still be enough and the driver normally can detect and handle revision differences. And if there are really severe changes appearing later on _and_ we actually get special support for the rk3288w in the kernel (googling for rk3288w mentions it in conjunction with windows 10) there is nothing speaking against having a rk3288w-mali compatible at that time. Heiko > > >> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
