2023-03-02 17:19:59

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 5/5] ASoC: cs34l45: Hibernation support

On Thu, Mar 02, 2023 at 11:11:54AM -0600, Vlad Karpovich wrote:
> From: "Vlad.Karpovich" <[email protected]>
>
> Adds support for the amplifier hibernation controlled by
> DSP firmware.

What is amplifier hibernation?


Attachments:
(No filename) (232.00 B)
signature.asc (488.00 B)
Download all attachments

2023-03-02 17:59:28

by Vlad Karpovich

[permalink] [raw]
Subject: Re: [PATCH 5/5] ASoC: cs34l45: Hibernation support

The CS35L45 features a low-power Hibernation State. In this state, all
register contents are lost, but the contents of
RAM are retained. In the Hibernation State, only always-on digital
functions to support wake-up are enabled.
Entry to this state is achieved via the register interface (either by an
external driver using the control port, or the
programmable DSP). Exit from this state is triggered by activity on
device GPIO pins, intended SPI transaction, or I2C
transaction with intended slave address

On 3/2/23 11:19, Mark Brown wrote:
> On Thu, Mar 02, 2023 at 11:11:54AM -0600, Vlad Karpovich wrote:
>> From: "Vlad.Karpovich" <[email protected]>
>>
>> Adds support for the amplifier hibernation controlled by
>> DSP firmware.
> What is amplifier hibernation?

2023-03-02 18:08:50

by Mark Brown

[permalink] [raw]
Subject: Re: [PATCH 5/5] ASoC: cs34l45: Hibernation support

On Thu, Mar 02, 2023 at 11:59:05AM -0600, Vlad Karpovich wrote:
> The CS35L45 features a low-power Hibernation State. In this state, all
> register contents are lost, but the contents of
> RAM are retained. In the Hibernation State, only always-on digital functions
> to support wake-up are enabled.
> Entry to this state is achieved via the register interface (either by an
> external driver using the control port, or the
> programmable DSP). Exit from this state is triggered by activity on device
> GPIO pins, intended SPI transaction, or I2C
> transaction with intended slave address

OK, so it's essentially just a faster mechanism for bringing the device
out of runtime suspend? I would suggest doing something in the code to
clarify that this is not the same thing as system level hibernation,
having references to hibernate in the driver is likely to lead to
confusion down the line. I'd also include a bit more description in the
commit message too.

Please don't top post, reply in line with needed context. This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.


Attachments:
(No filename) (1.17 kB)
signature.asc (488.00 B)
Download all attachments

2023-03-02 20:03:53

by Vlad Karpovich

[permalink] [raw]
Subject: Re: [PATCH 5/5] ASoC: cs34l45: Hibernation support


On 3/2/23 12:08, Mark Brown wrote:
> On Thu, Mar 02, 2023 at 11:59:05AM -0600, Vlad Karpovich wrote:
>> The CS35L45 features a low-power Hibernation State. In this state, all
>> register contents are lost, but the contents of
>> RAM are retained. In the Hibernation State, only always-on digital functions
>> to support wake-up are enabled.
>> Entry to this state is achieved via the register interface (either by an
>> external driver using the control port, or the
>> programmable DSP). Exit from this state is triggered by activity on device
>> GPIO pins, intended SPI transaction, or I2C
>> transaction with intended slave address
> OK, so it's essentially just a faster mechanism for bringing the device
> out of runtime suspend?

I don't think it is a faster way since it requires interaction with DSP
and restoring all wiped registers.

But it saves a some power comparing a low power state in the current driver

> I would suggest doing something in the code to
> clarify that this is not the same thing as system level hibernation,
> having references to hibernate in the driver is likely to lead to
> confusion down the line.

The feature is named hibernation in the data sheet.  Renaming it in the
driver will add confusing for the driver user.

> I'd also include a bit more description in the
> commit message too.
I will do in next version.
> Please don't top post, reply in line with needed context. This allows
> readers to readily follow the flow of conversation and understand what
> you are talking about and also helps ensure that everything in the
> discussion is being addressed.
Thanks. I will do.