On Wed, Oct 21, 2015 at 12:47:34PM +0000, Oder Chiou wrote:
> > > +struct rt5645_eq_param_s {
> > > + unsigned short reg;
> > > + unsigned short val;
> > > +};
> > As I said in reply to your earlier version just now this seems like a
> > really strange way of configuring things - we'd need to understand why
> > this is a good format for doing the configuration.
> There are 56 registers(0x1a4 to 0x1cd and 0x1e5 to 0x1f8) for setting the
> EQ parameters, and there is a register(0xb1) to control how many bands are
> enabled. The EQ parameters are affected by which bands are enabled, and we
> can set the EQ parameters which are required. The goal is to implement the
56 registers isn't so many in total but...
> function as simple as possible. In case of the Google Celes, we can only set
> 5 registers. We have added the check function in the "rt5645_hweq_put", if
> the settings are invalid, they are not copied to private data. In the enable
> function, we also validate the registers, and only the 57 registers can be
> set. Could you give us some hint?
It's a lot simpler from a kernel code point of view to just export the
full register coefficient block - but it's nice to see your tuning
software is smart enough to be able to output the smaller set of
register writes! I think this is fine if you can put the above
explanation into the changelog and also change things to remove the need
to specify platform data and just always provide these controls, with
validation of the registers being written I think that is a good idea,
especially given the separate register for specifying how many bands are
enabled.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
