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