[PATCH 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[PATCH 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[Wu, Songjun]

On 9/8/2015 00:23, Mark Brown wrote:
> On Sun, Sep 06, 2015 at 05:44:21PM +0800, Wu, Songjun wrote:
>> On 9/3/2015 19:37, Mark Brown wrote:
>>> On Tue, Sep 01, 2015 at 01:41:40PM +0800, Songjun Wu wrote:
>
>>>> +static const char * const eqcfg_bass_text[] = {
>>>> +	"-12 dB", "-6 dB", "0 dB", "+6 dB", "+12 dB"
>>>> +};
>>>
>>>> +static const unsigned int eqcfg_bass_value[] = {
>>>> +	CLASSD_INTPMR_EQCFG_B_CUT_12,
>>>> +	CLASSD_INTPMR_EQCFG_B_CUT_6, CLASSD_INTPMR_EQCFG_FLAT,
>>>> +	CLASSD_INTPMR_EQCFG_B_BOOST_6, CLASSD_INTPMR_EQCFG_B_BOOST_12
>>>> +};
>
>>> This should be a Volume control with TLV information, as should the
>>> following few controls.
>
>> The Volume control with TLV information is not suitable for this case.
>> Bass, Medium, and treble are mutually exclusive.
>> So I think the SOC_ENUM control is suitable for this case.
>> The register layout is not very good,
>> The register is defined as below.
>> ?  EQCFG: Equalization Selection
>> Value Name       Description
>> 0     FLAT       Flat Response
>> 1     BBOOST12   Bass boost +12 dB
>> 2     BBOOST6    Bass boost +6 dB
>> 3     BCUT12     Bass cut -12 dB
>> 4     BCUT6      Bass cut -6 dB
>> 5     MBOOST3    Medium boost +3 dB
>> 6     MBOOST8    Medium boost +8 dB
>> 7     MCUT3      Medium cut -3 dB
>> 8     MCUT8      Medium cut -8 dB
>> 9     TBOOST12   Treble boost +12 dB
>> 10    TBOOST6    Treble boost +6 dB
>> 11    TCUT12     Treble cut -12 dB
>> 12    TCUT6      Treble cut -6 dB
>
> OK, so that's not actually what the code was doing - it had separate
> enums for bass, mid and treble.  If you make this a single enum with all
> the above options in it that seems like the best way of handling things.
>
A single enum seems not very friendly to user, there are tree EQs, bass, 
medium and treble.
So I create tree enum controls to control three EQs.
The 'get' function is replaced by 'classd_get_eq_enum', if user operates 
one of the tree EQ controls, the other two EQs will show 0 dB.

>>>> +static const struct snd_kcontrol_new atmel_classd_snd_controls[] = {
>>>> +SOC_SINGLE_TLV("Left Volume", CLASSD_INTPMR,
>>>> +		CLASSD_INTPMR_ATTL_SHIFT, 78, 1, classd_digital_tlv),
>>>> +
>>>> +SOC_SINGLE_TLV("Right Volume", CLASSD_INTPMR,
>>>> +		CLASSD_INTPMR_ATTR_SHIFT, 78, 1, classd_digital_tlv),
>>>
>>> This should be a single stereo control rather than separate left and
>>> right controls.
>
>> Since the classD IP defines two register fields to control left volume and
>> right volume respectively, I think it's better to provide two controls to
>> user.
>
> No, this is really common, we combine them in Linux to present a
> consistent interface to userspace.
>
I think carefully, your suggestion is reasonable.
The code will be modified, combine the left and right to a single stereo 
control.
Thank you.

>>>> +	dev_info(dev,
>>>> +		"Atmel Class D Amplifier (CLASSD) device at 0x%p (irq %d)\n",
>>>> +		io_base, dd->irq);
>
>>> This is a bit noisy and not really based on interaction with the
>>> hardware...  dev_dbg() seems better.
>
>> This information will occur only once when linux kernel starts.
>> It shows the classD is loaded to linux kernel.
>> I think it's better to provide more information to user.
>
> This stuff all adds up and since it'll go out on the console by default
> it both makes things more noisy and slows down boot - printing on the
> serial port isn't free.  If we want to have this sort of information we
> printed we should really do it in the driver core so it appears
> consistently for all devices rather than having individual code in each
> driver.
>
Accept, the code will be modified to dev_dbg().

[PATCH 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[Mark Brown]

On Tue, Sep 08, 2015 at 05:36:01PM +0800, Wu, Songjun wrote:
> On 9/8/2015 00:23, Mark Brown wrote:

> >OK, so that's not actually what the code was doing - it had separate
> >enums for bass, mid and treble.  If you make this a single enum with all
> >the above options in it that seems like the best way of handling things.

> A single enum seems not very friendly to user, there are tree EQs, bass,
> medium and treble.
> So I create tree enum controls to control three EQs.
> The 'get' function is replaced by 'classd_get_eq_enum', if user operates one
> of the tree EQ controls, the other two EQs will show 0 dB.

If you want to have three controls you need to write code so that the
user can only change one of them from 0dB at once, returning an error
otherwise.  That was why it looked like they were three separate
controls.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150908/3fafc3c9/attachment-0001.sig>

[PATCH 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[Wu, Songjun]

On 9/8/2015 20:23, Mark Brown wrote:
> On Tue, Sep 08, 2015 at 05:36:01PM +0800, Wu, Songjun wrote:
>> On 9/8/2015 00:23, Mark Brown wrote:
>
>>> OK, so that's not actually what the code was doing - it had separate
>>> enums for bass, mid and treble.  If you make this a single enum with all
>>> the above options in it that seems like the best way of handling things.
>
>> A single enum seems not very friendly to user, there are tree EQs, bass,
>> medium and treble.
>> So I create tree enum controls to control three EQs.
>> The 'get' function is replaced by 'classd_get_eq_enum', if user operates one
>> of the tree EQ controls, the other two EQs will show 0 dB.
>
> If you want to have three controls you need to write code so that the
> user can only change one of them from 0dB at once, returning an error
> otherwise.  That was why it looked like they were three separate
> controls.
>
If user operates two or tree controls at the same time, for my 
understanding, these operations are serial actually in kernel, not 
parallel, and the last operation will be effective. I only write the 
function 'classd_get_eq_enum' to get the enumeration value, if user 
changes one of controls, the other controls will get 0dB. Is my 
understanding correct?

[PATCH 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[Mark Brown]

On Wed, Sep 09, 2015 at 11:16:08AM +0800, Wu, Songjun wrote:
> On 9/8/2015 20:23, Mark Brown wrote:

> >If you want to have three controls you need to write code so that the
> >user can only change one of them from 0dB at once, returning an error
> >otherwise.  That was why it looked like they were three separate
> >controls.

> If user operates two or tree controls at the same time, for my
> understanding, these operations are serial actually in kernel, not parallel,
> and the last operation will be effective. I only write the function
> 'classd_get_eq_enum' to get the enumeration value, if user changes one of
> controls, the other controls will get 0dB. Is my understanding correct?

Yes, that's what's going to end up happening but it's not how controls
are expected to behave - applications will expect changing one control
to leave others unaffected so it's better to return an error rather than
change the other control.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150909/a105d0ce/attachment.sig>

[PATCH 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[Wu, Songjun]

On 9/9/2015 17:52, Mark Brown wrote:
> On Wed, Sep 09, 2015 at 11:16:08AM +0800, Wu, Songjun wrote:
>> On 9/8/2015 20:23, Mark Brown wrote:
>
>>> If you want to have three controls you need to write code so that the
>>> user can only change one of them from 0dB at once, returning an error
>>> otherwise.  That was why it looked like they were three separate
>>> controls.
>
>> If user operates two or tree controls at the same time, for my
>> understanding, these operations are serial actually in kernel, not parallel,
>> and the last operation will be effective. I only write the function
>> 'classd_get_eq_enum' to get the enumeration value, if user changes one of
>> controls, the other controls will get 0dB. Is my understanding correct?
>
> Yes, that's what's going to end up happening but it's not how controls
> are expected to behave - applications will expect changing one control
> to leave others unaffected so it's better to return an error rather than
> change the other control.
>
If application change non EQ controls, the others will be unaffected. 
But the classD IP can only supports one EQ control at once, these three 
EQ controls point to the same register field, if application set a 
different EQ control, the error occurs, there will be many errors, it's 
not very reasonable to application. The best way I think is if 
application set one EQ control, the other EQ controls will change to 
0dB, it's also consistent with fact.

[PATCH 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[Mark Brown]

On Thu, Sep 10, 2015 at 10:31:04AM +0800, Wu, Songjun wrote:
> On 9/9/2015 17:52, Mark Brown wrote:

> >Yes, that's what's going to end up happening but it's not how controls
> >are expected to behave - applications will expect changing one control
> >to leave others unaffected so it's better to return an error rather than
> >change the other control.

> If application change non EQ controls, the others will be unaffected. But
> the classD IP can only supports one EQ control at once, these three EQ
> controls point to the same register field, if application set a different EQ
> control, the error occurs, there will be many errors, it's not very
> reasonable to application. The best way I think is if application set one EQ
> control, the other EQ controls will change to 0dB, it's also consistent with
> fact.

There's no really good solutions here - this is why my initial
suggestion was to have a single enumerated control.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150911/372c9839/attachment.sig>

[PATCH 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[Wu, Songjun]

On 9/11/2015 18:34, Mark Brown wrote:
> On Thu, Sep 10, 2015 at 10:31:04AM +0800, Wu, Songjun wrote:
>> On 9/9/2015 17:52, Mark Brown wrote:
>
>>> Yes, that's what's going to end up happening but it's not how controls
>>> are expected to behave - applications will expect changing one control
>>> to leave others unaffected so it's better to return an error rather than
>>> change the other control.
>
>> If application change non EQ controls, the others will be unaffected. But
>> the classD IP can only supports one EQ control at once, these three EQ
>> controls point to the same register field, if application set a different EQ
>> control, the error occurs, there will be many errors, it's not very
>> reasonable to application. The best way I think is if application set one EQ
>> control, the other EQ controls will change to 0dB, it's also consistent with
>> fact.
>
> There's no really good solutions here - this is why my initial
> suggestion was to have a single enumerated control.
>
You are right, your suggestion is reasonable, to have a single 
enumerated control. The second version will be made and sent soon.

[PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver

[Wu, Songjun]

On 9/8/2015 00:25, Mark Brown wrote:
> On Sun, Sep 06, 2015 at 05:44:30PM +0800, Wu, Songjun wrote:
>> On 9/3/2015 19:43, Mark Brown wrote:
>
>>> Why is this a separate DT node?  It seems that this IP is entirely self
>>> contained so I'm not clear why we need a separate node for the card, the
>>> card is usually a separate node because it ties together multiple
>>> different devices in the system but that's not the case here.
>
>> The classD can finish the audio function without other devices.
>> But I want to reuse the code in ASoC, leave many things(like creating PCM,
>> DMA operations) to ASoC, then the driver can only focus on how to configure
>> classD.
>> The classD IP is divided to tree parts logically, platform, CPU dai,
>> and codec, and these parts are registered to ASoC.
>
>> This separate DT node is needed in ASoC, ties these tree parts in ClassD.
>
> Sure, there's no problem at all having that structure in software but it
> should be possible to do this without having to represent this structure
> in DT.  It should be possible to register the card at the same time as
> the rest of the components rather than needing the separate device in
> the DT.
>
Do you mean using a single entry in the DT for the whole classD system 
and instantiate ASoC components from it.
For now, there are two entry, they could be combined to one entry.

[PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver

[Mark Brown]

On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote:
> On 9/8/2015 00:25, Mark Brown wrote:

> >Sure, there's no problem at all having that structure in software but it
> >should be possible to do this without having to represent this structure
> >in DT.  It should be possible to register the card at the same time as
> >the rest of the components rather than needing the separate device in
> >the DT.

> Do you mean using a single entry in the DT for the whole classD system and
> instantiate ASoC components from it.
> For now, there are two entry, they could be combined to one entry.

Yes, exactly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150908/b2c34403/attachment-0001.sig>

[PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver

[Wu, Songjun]

On 9/8/2015 20:23, Mark Brown wrote:
> On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote:
>> On 9/8/2015 00:25, Mark Brown wrote:
>
>>> Sure, there's no problem at all having that structure in software but it
>>> should be possible to do this without having to represent this structure
>>> in DT.  It should be possible to register the card at the same time as
>>> the rest of the components rather than needing the separate device in
>>> the DT.
>
>> Do you mean using a single entry in the DT for the whole classD system and
>> instantiate ASoC components from it.
>> For now, there are two entry, they could be combined to one entry.
>
> Yes, exactly.
>
Accept. the two entries will be combined to one entry.

[PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver

[Wu, Songjun]

On 9/8/2015 20:23, Mark Brown wrote:
> On Tue, Sep 08, 2015 at 05:36:13PM +0800, Wu, Songjun wrote:
>> On 9/8/2015 00:25, Mark Brown wrote:
>
>>> Sure, there's no problem at all having that structure in software but it
>>> should be possible to do this without having to represent this structure
>>> in DT.  It should be possible to register the card at the same time as
>>> the rest of the components rather than needing the separate device in
>>> the DT.
>
>> Do you mean using a single entry in the DT for the whole classD system and
>> instantiate ASoC components from it.
>> For now, there are two entry, they could be combined to one entry.
>
> Yes, exactly.
>
I try to use one entry, but there is a problem.
It's about 'driver_data' in struct device.
In function snd_soc_register_card, the parameter 'card' will be set to 
'driver_data' by the code 'dev_set_drvdata(card->dev, card)'.
Then some resources(eg. regmap, clock) also need be recorded by 
'driver_data'. One entry could only has one 'driver_data'. I think the 
best way is to create two entries, like the current dts.
What's your opinion?

[PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver

[Mark Brown]

On Tue, Sep 15, 2015 at 11:11:53AM +0800, Wu, Songjun wrote:

> I try to use one entry, but there is a problem.
> It's about 'driver_data' in struct device.
> In function snd_soc_register_card, the parameter 'card' will be set to
> 'driver_data' by the code 'dev_set_drvdata(card->dev, card)'.
> Then some resources(eg. regmap, clock) also need be recorded by
> 'driver_data'. One entry could only has one 'driver_data'. I think the best
> way is to create two entries, like the current dts.
> What's your opinion?

Look at the recently applied sunxi driver for an example of how to do
this - it's a similar piece of hardware (entirely in the SoC and so on).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150916/3d474210/attachment.sig>

[PATCH 2/2] ASoC: atmel-classd: DT binding for Class D audio amplifier driver

[Wu, Songjun]

On 9/17/2015 03:42, Mark Brown wrote:
> On Tue, Sep 15, 2015 at 11:11:53AM +0800, Wu, Songjun wrote:
>
>> I try to use one entry, but there is a problem.
>> It's about 'driver_data' in struct device.
>> In function snd_soc_register_card, the parameter 'card' will be set to
>> 'driver_data' by the code 'dev_set_drvdata(card->dev, card)'.
>> Then some resources(eg. regmap, clock) also need be recorded by
>> 'driver_data'. One entry could only has one 'driver_data'. I think the best
>> way is to create two entries, like the current dts.
>> What's your opinion?
>
> Look at the recently applied sunxi driver for an example of how to do
> this - it's a similar piece of hardware (entirely in the SoC and so on).
>
Thank you, It really helps me. I will make a second version soon.