[Intel-gfx] [PATCH 0/5] sanitize hda/i915 interface using the component fw

[Imre Deak]

On Mon, 2014-12-08 at 21:14 +0100, Daniel Vetter wrote:
> On Mon, Dec 08, 2014 at 06:42:04PM +0200, Imre Deak wrote:
> > The current hda/i915 interface to enable/disable power wells and query
> > the CD clock rate is based on looking up the relevant i915 module
> > symbols from the hda driver. By using the component framework we can get
> > rid of some global state tracking in the i915 driver and pave the way to
> > fully decouple the two drivers: once support is added to enable/disable
> > the HDMI functionality dynamically in the hda driver, it can bind/unbind
> > itself from the i915 component master, without the need to keep a
> > reference on the i915 module.
> > 
> > This also gets rid of the problem that currently the i915 driver exposes
> > the interface only on HSW and BDW, while it's also needed at least on
> > VLV/CHV.
> 
> Awesome that you're tackling this, really happy to see these hacks go.
> Unfortunately I think it's upside down: hda should be the component master
> and i915 should only register a component.
> 
> Longer story: The main reason for the component helpers is to be able to
> magically delay registering the main/master driver until all the
> components are loaded. Otherwise -EDEFER doesn't work and also the
> suspend/resume ordering this should result in. Master here means whatever
> userspace eventually sees as a device node or similar, component is
> anything really that this userspace interfaces needs to function
> correctly.

EDEFER doesn't solve the suspend/resume ordering, at least not in the
general async s/r case. In any case I don't see a problem in making the
hda component the master and I think it's more logical that way as you
said, so I changed that.

> I think what we need here is then:
> - Put the current azx_probe into the master_bind callback. The new
>   azx_probe will do nothing else than register the master component and
>   the component match list. To do so it checks the chip flag and if it
>   needs to cooperate with i915 it registers one component match for that.
>   The master_bind (old probe) function calls component_bind_all with the
>   hda_intel pointer as void *data parameter.

I'm not sure this is the best way since by this the i915 module would
need to be pinned even when no HDMI functionality is used. I think a
better way would be to let the probe function run as now and
init/register all the non-HDMI functionality. Then only the HDMI
functionality would be inited/registered from the bind/unbind hooks.

But we could go either way even as a follow-up to this patchset.

> - i915 registers a component for the i915 gfx device. It uses the
>   component device to get at i915 sturctures and fills the dev+ops into
>   the hda_intel pointer it gets as void *data.
>
> Stuff we then should do on top:
> - Add deferred probing to azx_probe: Only when all components are there
>   should it actually register. This will take care of all the module load
>   order mess.

I agree that we should only register user interfaces when everything is
in place. But I'm not sure deferred probe is the best, we could do
without it by registering HDMI from the component bind hook.

>   It should also take care of system suspend/resume ordering and we
>   should be able to delete all the early_resume/late_suspend trickery.

Deferred probe doesn't solve the suspend/resume ordering, we would need
to have a separate HDMI device that is set as a child to the i915
device. Alternatively we could use device_pm_wait_for_dev().

> Imo we should have things ready up to this point to make sure this
> refactoring actually works.

I think we could go with this minimal patch with your change to have the
hda component be master. This only adds the support for components and
keeps everything else the same. We could consider the bigger changes as
a follow-up.

> Then there's some cool stuff we could do on top:
> - Register a i915-hda platform devices as a child of the gfx pci device.
>   Besides shuffling around a bit with the interfaces/argument casting and
>   the component match function this doesn't really have a functional
>   impact. But it makes the relationship more clear since hda doesn't
>   really need the entire pci device, but only the small part that does
>   audio.
> 
> - Replace the hand-rolled power-well interface with runtime pm on that
>   device node.
> 
> - If system suspend/resume doesn't work automatically with deferred
>   probing (tbh I'm not sure) add pm_ops to the component master. Then add
>   some functions as default implementations for pm_ops for components
>   which simply refcount all component pm_ops calls and call the master
>   pm_ops suspend on the first suspend call and resume on the last resume
>   call. That really should take care of suspend/resume ordering for good.

Yep, these sound good. I think having an HDMI child device is the
cleanest solution for the s/r ordering issue.

--Imre

> 
> Cheers, Daniel
> 
> > 
> > Imre Deak (5):
> >   drm/i915: add dev_to_i915_priv helper
> >   drm/i915: add component support
> >   ALSA: hda: pass chip to all i915 interface functions
> >   ALSA: hda: add component support
> >   drm/i915: remove unused power_well/get_cdclk_freq api
> > 
> >  drivers/gpu/drm/i915/i915_dma.c         |  80 ++++++++++++++++++++
> >  drivers/gpu/drm/i915/i915_drv.c         |  15 ++--
> >  drivers/gpu/drm/i915/intel_drv.h        |   8 ++
> >  drivers/gpu/drm/i915/intel_runtime_pm.c |  56 --------------
> >  include/drm/i915_component.h            |  38 ++++++++++
> >  include/drm/i915_powerwell.h            |  37 ----------
> >  sound/pci/hda/hda_i915.c                | 126 +++++++++++++++++++++-----------
> >  sound/pci/hda/hda_i915.h                |  12 +--
> >  sound/pci/hda/hda_intel.c               |  16 ++--
> >  sound/pci/hda/hda_priv.h                |   7 ++
> >  10 files changed, 238 insertions(+), 157 deletions(-)
> >  create mode 100644 include/drm/i915_component.h
> >  delete mode 100644 include/drm/i915_powerwell.h
> > 
> > -- 
> > 1.8.4
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>