On Wed, Jun 12, 2019 at 02:26:24AM +0000, james qian wang (Arm Technology 
China) wrote:
> On Tue, Jun 11, 2019 at 02:30:38PM +0200, Daniel Vetter wrote:
> > On Tue, Jun 11, 2019 at 11:13:45AM +0000, Lowry Li (Arm Technology China) 
> > wrote:
> > > From: "Lowry Li (Arm Technology China)" <lowry...@arm.com>
> > >
> > > The komeda internal resources (pipelines) are shared between crtcs,
> > > and resources release by disable_crtc. This commit is working for once
> > > user forgot disabling crtc like app quit abnomally, and then the
> > > resources can not be used by another crtc. Adds drop_master to
> > > shutdown the device and make sure all the komeda resources have been
> > > released and can be used for the next usage.
> > >
> > > Signed-off-by: Lowry Li (Arm Technology China) <lowry...@arm.com>
> > > ---
> > >  drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 13 +++++++++++++
> > >  1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c 
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > > index 8543860..647bce5 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > > @@ -54,11 +54,24 @@ static irqreturn_t komeda_kms_irq_handler(int irq, 
> > > void *data)
> > >  return status;
> > >  }
> > >
> > > +/* Komeda internal resources (pipelines) are shared between crtcs, and 
> > > resources
> > > + * are released by disable_crtc. But if user forget disabling crtc like 
> > > app quit
> > > + * abnormally, the resources can not be used by another crtc.
> > > + * Use drop_master to shutdown the device and make sure all the komeda 
> > > resources
> > > + * have been released, and can be used for the next usage.
> > > + */
> >
> > No. If we want this, we need to implement this across drivers, not with
> > per-vendor hacks.
> >
> > The kerneldoc should have been a solid hint: "Only used by vmwgfx."
> > -Daniel
> 
> Hi Daniel:
> This drop_master is really what we want, can we update the doc and
> add komeda as a user of this hacks like "used by vmwfgx and komeda",
> or maybe directly promote this per-vendor hacks as an optional chip
> function ?

Still no, because it would mean different behaviour for arm/komeda
compared to everyone else. And we really don't want this, because this
would completely break flicker-less vt-switching.

Currently the only fallback for this case is the lastclose handler, which
atm just restores fbcon/fbdev. If you want to change/extend that to work
without fbdev, then that's the place to do the change. And across _all_
drm kms drivers, so that we have consistent behaviour.

kms is a cross-vendor api, vendor hacks are very, very much not cool.
-Daniel

> 
> James
> 
> > > +static void komeda_kms_drop_master(struct drm_device *dev,
> > > +   struct drm_file *file_priv)
> > > +{
> > > +drm_atomic_helper_shutdown(dev);
> > > +}
> > > +
> > >  static struct drm_driver komeda_kms_driver = {
> > >  .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
> > >     DRIVER_PRIME | DRIVER_HAVE_IRQ,
> > >  .lastclose= drm_fb_helper_lastclose,
> > >  .irq_handler= komeda_kms_irq_handler,
> > > +.master_drop= komeda_kms_drop_master,
> > >  .gem_free_object_unlocked= drm_gem_cma_free_object,
> > >  .gem_vm_ops= &drm_gem_cma_vm_ops,
> > >  .dumb_create= komeda_gem_cma_dumb_create,
> > > --
> > > 1.9.1
> > >
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> _______________________________________________
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Reply via email to