ASoC: rt5645: Add the HWEQ for the customized speaker output
Subsystems (3)
Oder Chiou
maintainerPATCH 1/1 ASoC: rt5645: Add the HWEQ for the customized speaker output
The patch adds the HWEQ function for the customized speaker output that is in order to the customer's requirement. The customer can enable the HWEQ in the platform data, and set the parameters of the HWEQ in the ALSA binary control byte-by-byte.
--- include/sound/rt5645.h | 2 + sound/soc/codecs/rt5645.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 111 insertions(+)
include/sound/rt5645.h +2 -0
@@ -23,6 +23,8 @@ struct rt5645_platform_data {unsigned int jd_mode;/* Invert JD when jack insert */ bool jd_invert; +/* Speaker HWEQ */ + bool hweq; };#endif
sound/soc/codecs/rt5645.c +109 -0
166 lines not on this page · raw message
Signature · 1 line
1.8.1.1.439.g50a6b54
Mark Brown
maintainersound/soc/codecs/rt5645.c static const struct reg_default rt5645_reg[] = { · line 232
Quoted 9 lines · Oder Chiou
The patch adds the HWEQ function for the customized speaker output that is in order to the customer's requirement. The customer can enable the HWEQ in the platform data, and set the parameters of the HWEQ in the ALSA binary control byte-by-byte.
sound/soc/codecs/rt5645.c +4
-0+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.
Oder Chiou
maintainerQuoted 9 lines
sound/soc/codecs/rt5645.c static const struct reg_default rt5645_reg[] = { · line 232
Quoted 4 lines
sound/soc/codecs/rt5645.c +4
-0+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 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?
Mark Brown
maintainerQuoted 9 lines · Oder Chiou
Quoted 8 lines
sound/soc/codecs/rt5645.c static const struct reg_default rt5645_reg[] = { · line 232
Quoted 4 lines
sound/soc/codecs/rt5645.c +4
-0+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.
Quoted 4 lines
There are 56 registers(0x1a4 to
0x1cdand0x1e5to0x1f8) 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...
Quoted 5 lines
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.