All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH v3 3/3] drm: Allow simpledrm to setup its emulated FB as firmware provided
Date: Thu, 5 May 2022 14:11:30 +0200	[thread overview]
Message-ID: <YnO+8hZ0ozPaZUEj@phenom.ffwll.local> (raw)
In-Reply-To: <bfb03d40-a023-12a9-9554-1b6e6c474134@redhat.com>

On Wed, May 04, 2022 at 01:32:37PM +0200, Javier Martinez Canillas wrote:
> On 5/4/22 12:58, Daniel Vetter wrote:
> > On Tue, May 03, 2022 at 09:15:40AM +0200, Javier Martinez Canillas wrote:
> >> Indicate to fbdev subsystem that the registered framebuffer is provided by
> >> the system firmware, so that it can handle accordingly. For example, would
> >> unregister the FB devices if asked to remove the conflicting framebuffers.
> >>
> >> Add a new DRM_FB_FW field to drm_fbdev_generic_setup() options parameter.
> >> Drivers can use this to indicate the FB helper initialization that the FB
> >> registered is provided by the firmware, so it can be configured as such.
> >>
> >> Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
> >> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> >> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> >> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> ---
> >>
> >> Changes in v3:
> >> - Drop the firmware local variable (Laurent Pinchart).
> >> - Use DRM_FB_OPTION() since DRM_FB_SET_OPTION() got renamed (kernel test robot).
> > 
> > Just for the record what I brought up on irc already:
> > 
> > FBINFO_MISC_FIRMWARE is purely an internal flag with no uapi impact, and
> > it's only to control whether we nuke this from
> > remove_conflicting_framebuffer or not. Since simpledrm only ever binds
> > against sysfb I think it'd be cleaner to only rely on that, and relegate
> 
> That's not actually true. The OF subsystem also registers "simple-framebuffer"
> devices when there are Device Tree nodes that contain a "simple-framebuffer"
> compatible string. In that case these pdev will also bind against simpledrm.

TIL.

> > that entire FBINFO_MISC_FIRMWARE misc hack to the fbdev dungeons and let
> > it quietly wither away there.
> >
> > Also I'm not a huge fan of these midlayer flags in general :-)
> 
> And while I agree with you that these midlayer flags are horrible, that is
> what any other fbdev that makes use of a firmware-provided framebuffer set,
> so simpledrm emulated fbdev shouldn't be the exception IMO.

So we discussed this a pile more on irc, and at least my take is that
people who run simpledrm but want to combine that with fbdev drivers and
expect it to all work nicely we can probably ignore. At least until all
this sysfb stuff is nicely unified, and at that point we shouldn't need
special flags anymore.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 3/3] drm: Allow simpledrm to setup its emulated FB as firmware provided
Date: Thu, 5 May 2022 14:11:30 +0200	[thread overview]
Message-ID: <YnO+8hZ0ozPaZUEj@phenom.ffwll.local> (raw)
In-Reply-To: <bfb03d40-a023-12a9-9554-1b6e6c474134@redhat.com>

On Wed, May 04, 2022 at 01:32:37PM +0200, Javier Martinez Canillas wrote:
> On 5/4/22 12:58, Daniel Vetter wrote:
> > On Tue, May 03, 2022 at 09:15:40AM +0200, Javier Martinez Canillas wrote:
> >> Indicate to fbdev subsystem that the registered framebuffer is provided by
> >> the system firmware, so that it can handle accordingly. For example, would
> >> unregister the FB devices if asked to remove the conflicting framebuffers.
> >>
> >> Add a new DRM_FB_FW field to drm_fbdev_generic_setup() options parameter.
> >> Drivers can use this to indicate the FB helper initialization that the FB
> >> registered is provided by the firmware, so it can be configured as such.
> >>
> >> Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
> >> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> >> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> >> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> ---
> >>
> >> Changes in v3:
> >> - Drop the firmware local variable (Laurent Pinchart).
> >> - Use DRM_FB_OPTION() since DRM_FB_SET_OPTION() got renamed (kernel test robot).
> > 
> > Just for the record what I brought up on irc already:
> > 
> > FBINFO_MISC_FIRMWARE is purely an internal flag with no uapi impact, and
> > it's only to control whether we nuke this from
> > remove_conflicting_framebuffer or not. Since simpledrm only ever binds
> > against sysfb I think it'd be cleaner to only rely on that, and relegate
> 
> That's not actually true. The OF subsystem also registers "simple-framebuffer"
> devices when there are Device Tree nodes that contain a "simple-framebuffer"
> compatible string. In that case these pdev will also bind against simpledrm.

TIL.

> > that entire FBINFO_MISC_FIRMWARE misc hack to the fbdev dungeons and let
> > it quietly wither away there.
> >
> > Also I'm not a huge fan of these midlayer flags in general :-)
> 
> And while I agree with you that these midlayer flags are horrible, that is
> what any other fbdev that makes use of a firmware-provided framebuffer set,
> so simpledrm emulated fbdev shouldn't be the exception IMO.

So we discussed this a pile more on irc, and at least my take is that
people who run simpledrm but want to combine that with fbdev drivers and
expect it to all work nicely we can probably ignore. At least until all
this sysfb stuff is nicely unified, and at that point we shouldn't need
special flags anymore.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2022-05-05 12:11 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-03  7:15 [PATCH v3 0/3] drm: Allow simpledrm to setup its emulated FB as firmware provided Javier Martinez Canillas
2022-05-03  7:15 ` Javier Martinez Canillas
2022-05-03  7:15 ` Javier Martinez Canillas
2022-05-03  7:15 ` Javier Martinez Canillas
2022-05-03  7:15 ` Javier Martinez Canillas
2022-05-03  7:15 ` Javier Martinez Canillas
2022-05-03  7:15 ` [PATCH v3 1/3] drm: Remove superfluous arg when calling to drm_fbdev_generic_setup() Javier Martinez Canillas
2022-05-03  7:15   ` Javier Martinez Canillas
2022-05-03  7:15 ` [PATCH v3 2/3] drm/fb-helper: Rename preferred_bpp drm_fbdev_generic_setup() parameter Javier Martinez Canillas
2022-05-03  7:15   ` Javier Martinez Canillas
2022-05-03  7:15   ` Javier Martinez Canillas
2022-05-03  7:15   ` Javier Martinez Canillas
2022-05-03  7:15   ` Javier Martinez Canillas
2022-05-03  7:15   ` Javier Martinez Canillas
2022-05-03 17:02   ` Jernej Škrabec
2022-05-03 17:02     ` Jernej Škrabec
2022-05-03 17:02     ` Jernej Škrabec
2022-05-03 17:02     ` Jernej Škrabec
2022-05-03 17:02     ` Jernej Škrabec
2022-05-03  7:15 ` [PATCH v3 3/3] drm: Allow simpledrm to setup its emulated FB as firmware provided Javier Martinez Canillas
2022-05-03  7:15   ` Javier Martinez Canillas
2022-05-04 10:58   ` Daniel Vetter
2022-05-04 10:58     ` Daniel Vetter
2022-05-04 11:32     ` Javier Martinez Canillas
2022-05-05 12:11       ` Daniel Vetter [this message]
2022-05-05 12:11         ` Daniel Vetter
2022-05-05 12:45         ` Javier Martinez Canillas
2022-05-05 12:58           ` Daniel Vetter
2022-05-05 12:58             ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YnO+8hZ0ozPaZUEj@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.