[Intel-gfx] [PATCH 53/59] drm/arc: Move to drm/tiny

Daniel Vetter daniel.vetter at ffwll.ch
Wed Apr 15 12:20:35 UTC 2020


On Wed, Apr 15, 2020 at 2:03 PM Alexey Brodkin
<Alexey.Brodkin at synopsys.com> wrote:
>
> Hi Daniel,
>
> > -----Original Message-----
> > From: Sam Ravnborg <sam at ravnborg.org>
> > Sent: Wednesday, April 15, 2020 12:45 PM
> > To: Daniel Vetter <daniel.vetter at ffwll.ch>
> > Cc: Intel Graphics Development <intel-gfx at lists.freedesktop.org>; Alexey Brodkin
> > <abrodkin at synopsys.com>; DRI Development <dri-devel at lists.freedesktop.org>; Daniel Vetter
> > <daniel.vetter at intel.com>
> > Subject: Re: [PATCH 53/59] drm/arc: Move to drm/tiny
> >
> > Hi Daniel.
> > On Wed, Apr 15, 2020 at 09:40:28AM +0200, Daniel Vetter wrote:
> > > Because it is.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > > Cc: Alexey Brodkin <abrodkin at synopsys.com>
> > > ---
> > >  MAINTAINERS                                         |  2 +-
> > >  drivers/gpu/drm/Kconfig                             |  2 --
> > >  drivers/gpu/drm/Makefile                            |  1 -
> > >  drivers/gpu/drm/arc/Kconfig                         | 10 ----------
> > >  drivers/gpu/drm/arc/Makefile                        |  3 ---
> > >  drivers/gpu/drm/tiny/Kconfig                        | 10 ++++++++++
> > >  drivers/gpu/drm/tiny/Makefile                       |  1 +
> > >  drivers/gpu/drm/{arc/arcpgu_drv.c => tiny/arcpgu.c} |  0
> > >  8 files changed, 12 insertions(+), 17 deletions(-)
> > >  delete mode 100644 drivers/gpu/drm/arc/Kconfig
> > >  delete mode 100644 drivers/gpu/drm/arc/Makefile
> > >  rename drivers/gpu/drm/{arc/arcpgu_drv.c => tiny/arcpgu.c} (100%)
> >
> > We have "DRM: ARC: add HDMI 2.0 TX encoder support" which
> > adds another platform driver to drm/arc/
> > This speaks against the move to tiny IMO
>
> Indeed that's an interesting question, see v3 series here:
> https://lists.freedesktop.org/archives/dri-devel/2020-April/262352.html

Looking at this patch series, feels a bit like hand-rolling of bridge
code, badly. We should get away from that.

Once you have that I think the end result is tiny enough that it can
stay, bridges intergrate quite well into simple display pipe drivers.

> BTW should I pull that series in my tree and send you a pull-request
> or that kind of change needs to go through another tree?
>
> Also I'd like to test the change we discuss here to make sure stuff
> still works. Once we do that I'll send an update. Any hint on
> when that change needs to be acked/nacked?

Simplest is if this can all land through drm-misc, is arc not
maintained in there? And there's plenty of time for testing, I'm just
slowly crawling through the tree to get everything polished and
cleaned up in this area.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the Intel-gfx mailing list