[Freedreno] Adreno 200 / AMD 430 on linux-3.19

Rob Clark robdclark at gmail.com
Wed Mar 4 07:08:20 PST 2015


On Wed, Mar 4, 2015 at 3:30 AM, Enrico Weigelt, metux IT consult
<weigelt at melag.de> wrote:
> Am 03.03.2015 um 19:27 schrieb Rob Clark:
>
>> well, a2xx doesn't really get too much love these days on the
>>
>> userspace side of things either, although that is probably strongly
>> related to my lack of motivation to deal w/ an old 2.6.x kernel ;-)
>
>
> Well, I already have the fsl-kgsl stuff on 3.10.12 - Robert and his
> boys did a nice here (and reading their patch comments sometimes is
> quite a fun ;-)). ...
>
> The dirty hacks to the blob driver working are quite scary
>
> I've rebased all the stuff to 3.19, but didn't get it working yet,
> eg. there had been deeper changes in the DRM internals which the
> fsl-kgsl still needs to be adapted for.
>
>> Upstream drm/msm support for a2xx would be really nice.
>
>
> For us over here, it's a quite important thing. As we're building
> medical devices, we need really good reproducability/tracability.
> Some horribly coded proprietary blob doesn't fit in here.
> (we haven't sorted out, whether we could use it all, yet).
>
> The alternative would be dropping GL entirely, which also means
> loosing QML (well, I'm not a fan of QML anyways, but the GUI folks
> usually like it).
>
>
> So, to get back to the original problem: how can I help to
> improve the situation ?
>

Well, getting a drm/kms setup going on imx5 would be, from userspace
perspective, I think the best solution.

It may be possible to get qcom kgsl stuff going, or add another
backend in libdrm_freedreno to handle the original amd kgsl kernel.  I
would have to assume the userspace interfaces between the two kgsl's
are in some ways similar.  But freedreno userspace on kgsl is a bit of
a delicate hack.  The way fencing works across processes is a complete
hack, and dealing with all the different possible kgsl's on different
branches tends to be problematic too.

I initially had a vague idea that drm/msm could work on imx5 as well,
as a "render-node' driver, sharing buffers w/ a separate kms-only
display driver (I think imx-drm should work on imx5).  I hadn't gotten
as far as figuring out the details.  Currently on snapdragon platforms
the drm/msm device binds to the display (and then hdmi, edp, gpu, etc)
are sub-devices.  I guess on imx5 maybe some sort of dummy device?

A bit depends, I suppose, on how the gpu integrates in to the rest of
the SoC.  I'm not sure if there are much differences in terms of
clocks/regulators/etc.  Or how the gpummu works.  For a3xx and later
snapdragon use an external iommu, but that is already separated out
since I knew that a2xx would have an internal mmu instead.  (fwiw,
drm/msm also supports a vram cma carveout, so for bring-up one could
start w/ putting the gpummu in bypass.)

Or if there are enough differences, possibly a bit of copy/paste of
the gpu and gem/submit parts might make sense.  If you stripped out
all the display related parts, drm/msm wouldn't be that big.

Perhaps worth talking to Robert and the pengutronix folks..  they
probably know the hw a bit better and maybe already have some thoughts
about how to approach it.

BR,
-R

>
> cu
> --
> Enrico Weigelt, metux IT consult
> +49-151-27565287
> [IDS]
>
> MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
> 21333 B
>
> Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen
> begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist
> ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist.
> Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht
> kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in
> irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten
> haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese
> Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und
> alle Anhänge, ohne eine Kopie zu behalten.
> Important Notice: This message may contain confidential or privileged
> information. It is intended only for the person it was addressed to. If you
> are not the intended recipient of this email you may not copy, forward,
> disclose or otherwise use it or any part of it in any form whatsoever. If
> you received this email in error please notify the sender by replying and
> delete this message and any attachments without retaining a copy.


More information about the Freedreno mailing list