[Intel-gfx] [PATCH 2/7] drm/i915: Add get_eld audio component

Daniel Vetter daniel at ffwll.ch
Mon Nov 30 08:31:52 PST 2015


On Mon, Nov 30, 2015 at 04:55:50PM +0100, Takashi Iwai wrote:
> On Mon, 30 Nov 2015 15:17:05 +0100,
> Daniel Vetter wrote:
> > 
> > On Mon, Nov 30, 2015 at 03:11:16PM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 30, 2015 at 02:37:46PM +0100, Takashi Iwai wrote:
> > > > diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
> > > > index 30d89e0da2c6..058d39e8d57f 100644
> > > > --- a/include/drm/i915_component.h
> > > > +++ b/include/drm/i915_component.h
> > > > @@ -38,6 +38,7 @@
> > > >   * @codec_wake_override: Enable/Disable generating the codec wake signal
> > > >   * @get_cdclk_freq: get the Core Display Clock in KHz
> > > >   * @sync_audio_rate: set n/cts based on the sample rate
> > > > + * @get_eld: fill the audio state and ELD bytes for the given port
> > > 
> > > In 4.4 kerneldoc supports extended in-line comments for struct members
> > > like this:
> > > 
> > > >   */
> > > >  struct i915_audio_component_ops {
> > > >  	struct module *owner;
> > > > @@ -46,6 +47,8 @@ struct i915_audio_component_ops {
> > > >  	void (*codec_wake_override)(struct device *, bool enable);
> > > >  	int (*get_cdclk_freq)(struct device *);
> > > >  	int (*sync_audio_rate)(struct device *, int port, int rate);
> > > 
> > > 	/**
> > > 	 * @get_eld:
> > > 	 *
> > > 	 * lots of blabla, possibly in multiple paragraphs.
> > > 	 */
> > > 
> > > Please use that layout and put a copy of the more detailed description you
> > > put into the commit message of how ->get_eld exactly works.
> > > 
> > > I did ask for this to get done as part of some of the previous, and it was
> > > partially done but not exactly how kerneldoc wants it :( But I think we
> > > need to start somewhere ...
> > 
> > Strike that, I looked at the wrong tree ;-) linux-next should have all the
> > patches using the new extended style.
> 
> OK, so this is a post-4.4 change.  I can rebase on it.  Could you
> point a steady branch suitable for it?

Dave's drm-next would be it, if Dave opens it up and pulls in the 2 pull
requests I've sent out earlier. Dave?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list