Re: [PATCH 1/5] [RFC]intel_hdmi_audio:include header

[Takashi Iwai <tiwai@suse.de>]

At Thu, 25 Nov 2010 11:37:58 +0530,
Bandarupalli, Sailaja wrote:
> 
> 
> > > > > +/**
> > > > > + * union aud_cfg - Audio configuration offset - 69000
> > > > > + *
> > > > > + * @cfg_regx: individual register bits
> > > > > + * @cfg_regval: full register value
> > > > > + *
> > > > > + * */
> > > > > +union aud_cfg {
> > > > > +	struct {
> > > > > +		u32 aud_en:1;
> > > > > +		u32 layout:1;
> > > > > +		u32 fmt:2;
> > > > > +		u32 num_ch:2;
> > > > > +		u32 rsvd0:1;
> > > > > +		u32 set:1;
> > > > > +		u32 flat:1;
> > > > > +		u32 val_bit:1;
> > > > > +		u32 user_bit:1;
> > > > > +		u32 underrun:1;
> > > > > +		u32 rsvd1:20;
> > > > > +	} cfg_regx;
> > > > > +	u32 cfg_regval;
> > > > > +};
> > > >
> > > > In general, better to avoid bit fields if it's used for the data
> > > > transfer.  The bit-fields are never portable.
> > > >
> > > These bit fields are used for programming the HDMI controller
> > subsystem.
> > 
> > So, these bit-fields data aren't exposed to the hardware as is, but
> > used only between the hdmi audio and the controller drivers?
> > (But then, why these have to be defined in here?)
> > 
> > 
> These bits  fields are used between HDMI audio driver and hardware.
> They are exposed by the hardware as is, and we need to write to 
> specific bits to enable HDMI audio.

Then the bit-fields aren't suitable regarding the portability.


Takashi