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.