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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
