linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH] ARM: config: Refresh mutli v7
       [not found]   ` <3877ae18-dbda-242a-60b2-f73734f8ba03@xs4all.nl>
@ 2021-06-09  9:28     ` Arnd Bergmann
  2021-06-10  2:19       ` Joel Stanley
  0 siblings, 1 reply; 2+ messages in thread
From: Arnd Bergmann @ 2021-06-09  9:28 UTC (permalink / raw)
  To: Hans Verkuil
  Cc: Joel Stanley, Linux ARM, Linux Fbdev development list, dri-devel

On Tue, Jun 8, 2021 at 6:49 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On 08/06/2021 18:14, Arnd Bergmann wrote:
>
> Right now it is inherent to the driver. It is probably possible to drop support
> for video overlay devices if CONFIG_FB=n, but it is not something I have time
> for. It's just a test driver (albeit a very useful test driver), so it is no
> big deal if it is disabled when CONFIG_FB=n.

Ok, thanks for the reply, makes sense.

I checked what other consequences there are if we disable CONFIG_FB
and CONFIG_DRM_KMS_FB_HELPER=y in all the defconfigs now,
as the patch from Kees did.

It appears that the only other arm32 framebuffers that remain are
FB_EFI=y, FB_WM8505=y, FB_MX3=m and FB_SIMPLE=y.

On arm64, losing CONFIG_FB=y would disable FB_EFI=y,
XEN_FBDEV_FRONTEND=y, and FB_MX3=m

On x86, it's only CONFIG_FB_EFI

It appears that FB_MX3 is orphaned since commit e1324ece2af4
("ARM: imx: Remove i.MX35 board files") because all Armv6 or
newer i.MX now use drivers/gpu/drm/mxsfb/mxsfb_drv.c, and
FB_WM8505 is probably unused as well (we discussed removing the
platform last winter, but decided to give it another year to see if
new users come up, which has not happened).

As long as simplefb, efifb and xenfb are needed though, we probably
want CONFIG_FB=y anyway and leaving VIVID=m with the dependency
does not cause problems until those are all turned into drm drivers.

      Arnd

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] ARM: config: Refresh mutli v7
  2021-06-09  9:28     ` [PATCH] ARM: config: Refresh mutli v7 Arnd Bergmann
@ 2021-06-10  2:19       ` Joel Stanley
  0 siblings, 0 replies; 2+ messages in thread
From: Joel Stanley @ 2021-06-10  2:19 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Hans Verkuil, Linux ARM, Linux Fbdev development list, dri-devel

On Wed, 9 Jun 2021 at 09:30, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jun 8, 2021 at 6:49 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > On 08/06/2021 18:14, Arnd Bergmann wrote:
> >
> > Right now it is inherent to the driver. It is probably possible to drop support
> > for video overlay devices if CONFIG_FB=n, but it is not something I have time
> > for. It's just a test driver (albeit a very useful test driver), so it is no
> > big deal if it is disabled when CONFIG_FB=n.
>
> Ok, thanks for the reply, makes sense.
>
> I checked what other consequences there are if we disable CONFIG_FB
> and CONFIG_DRM_KMS_FB_HELPER=y in all the defconfigs now,
> as the patch from Kees did.
>
> It appears that the only other arm32 framebuffers that remain are
> FB_EFI=y, FB_WM8505=y, FB_MX3=m and FB_SIMPLE=y.

FB_SH_MOBILE_LCDC on arm32 too.

> As long as simplefb, efifb and xenfb are needed though, we probably
> want CONFIG_FB=y anyway and leaving VIVID=m with the dependency
> does not cause problems until those are all turned into drm drivers.

I will go ahead with this for the v7 defconfig.

Cheers,

Joel

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-06-10  2:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20210608103833.598348-1-joel@jms.id.au>
     [not found] ` <CAK8P3a00xuEAKTHrCDw52M-YPJUphSU8bYayW9P_xyNDsTsNzg@mail.gmail.com>
     [not found]   ` <3877ae18-dbda-242a-60b2-f73734f8ba03@xs4all.nl>
2021-06-09  9:28     ` [PATCH] ARM: config: Refresh mutli v7 Arnd Bergmann
2021-06-10  2:19       ` Joel Stanley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).