[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3c131132-35ce-e5da-2608-36d53abc6c83@linaro.org>
Date: Thu, 11 May 2023 19:57:40 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Aidan MacDonald <aidanmacdonald.0x0@...il.com>
Cc: lgirdwood@...il.com, broonie@...nel.org, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
perex@...ex.cz, tiwai@...e.com, alsa-devel@...a-project.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 3/3] dt-bindings: ASoC: Add ESS ES9218P codec bindings
On 11/05/2023 13:26, Aidan MacDonald wrote:
>
> Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> writes:
>
>> On 11/05/2023 12:15, Aidan MacDonald wrote:
>>>
>>> Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> writes:
>>>
>>>> On 10/05/2023 13:23, Aidan MacDonald wrote:
>>>>> ...
>>>>> + ess,max-clock-div:
>>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>>> + description:
>>>>> + Sets the maximum MCLK divider for generating the internal CLK.
>>>>> + CLK must be at least 20x the I2C bus speed or I2C transactions
>>>>> + will fail. The maximum divider should be chosen to ensure that
>>>>> + CLK will not fall below the limit.
>>>>> + enum:
>>>>> + - 1
>>>>> + - 2
>>>>> + - 4
>>>>> + - 8
>>>>> + default: 1
>>>>
>>>> Why do you need to customize it per board?
>>>>
>>>
>>> There's no generic API to read or change the bus speed (SCL frequency)
>>> for I2C adapters, so it's impossible to calculate a limit on the MCLK
>>> divider automatically.
>>>
>>> Defaulting to 1 is always safe, but means wasting power at lower sample
>>> rates. If you know what the bus speed is you can use a higher divider
>>> limit to save power, and it has to be done at the board/firmware level
>>> because that's the only place where the bus speed is known.
>>
>> If I understand correctly, you only miss a way to get bus_freq_hz from
>> i2c_timings to calculate the divider by yourself? This looks like Linux
>> limitation, so we shouldn't push it into DT, but rather fix Linux. The
>> I2C bus rate is known, the MCLK rate as well, so divider is possible to
>> deduce.
>>
>> I am actually surprised that I2C core does not store the timings
>> anywhere and each bus host has to deal with it on its own.
>>
>> Best regards,
>> Krzysztof
>
> I agree it'd be better if Linux provided access the bus frequency, but
> even if that API was added it will take time for every I2C adapter to
> support it. So in that case we would still need a DT property to provide
> a safe limit or use a safe default, and miss potential power savings.
>
> I'd prefer to add the DT property to allow power savings to be had now,
> and drop it if/when the kernel gets an API for bus frequency. That will
> be safe from a compatibility point of view -- the property won't be
> providing any useful information so it won't matter if old DTs have it.
OK, sounds good.
Best regards,
Krzysztof
Powered by blists - more mailing lists