lkml.org 
[lkml]   [2017]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v5 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
Date
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


\
 
 \ /
  Last update: 2017-05-10 21:21    [W:0.066 / U:7.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site