RE: [PATCH 2/6] ASoC: samsung: i2s: configure PSR from sound card

[Padmanabhan Rajanbabu]

> -----Original Message-----
> From: Mark Brown [mailto:broonie@xxxxxxxxxx]
> Sent: 14 October 2022 05:32 PM
> To: Padmanabhan Rajanbabu <p.rajanbabu@xxxxxxxxxxx>
> Cc: lgirdwood@xxxxxxxxx; robh+dt@xxxxxxxxxx;
> krzysztof.kozlowski+dt@xxxxxxxxxx; s.nawrocki@xxxxxxxxxxx;
> perex@xxxxxxxx; tiwai@xxxxxxxx; pankaj.dubey@xxxxxxxxxxx;
> alim.akhtar@xxxxxxxxxxx; rcsekar@xxxxxxxxxxx;
> aswani.reddy@xxxxxxxxxxx; alsa-devel@xxxxxxxxxxxxxxxx;
> devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-samsung-
> soc@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 2/6] ASoC: samsung: i2s: configure PSR from sound card
> 
> On Fri, Oct 14, 2022 at 03:51:47PM +0530, Padmanabhan Rajanbabu wrote:
> > Currently the prescaler value in samsung I2S dai is calculated by
> > dividing the peripheral input clock frequency with frame clock
> > frequency and root clock frequency divider. This prescaler value is
> > used to divide the input clock to generate root clock (RCLK) from
> > which frame clock is generated for I2S communication.
> >
> > However for the platforms which does not have a dedicated audio PLL as
> > an input clock source, the prescaler divider will not generate
> > accurate root clock frequency, which inturn affects sampling frequency
> also.
> >
> > To overcome this scenario, support has been added to let the sound
> > card identify right prescaler divider value and configure the
> > prescaler (PSR) divider directly the from the sound card to achieve
> > near accurate sample frequencies
> 
> It's not clear to me why the solution here is to move the configuration to
the
> sound card rather than to improve the I2S driver to be able to cope with
> whatever the restrictions are on the PSR in these systems - it seems more
> cumbersome for system integrators, especially since you've not documented
> the issues or how to configure it.  Could you expand on what the
constraints
> are here and why it's not possible for the driver to figure things out
(given
> some quirk information)?

Thank you for reviewing the patch.

In Samsung I2S CPU controller, to derive the frame clock, we are supposed to
configure the PSR and RFS internal dividers. i.e.

OPCLK -> PSR -> RCLK -> RFS -> Frame clock

Where:
OPCLK - Operational clock
PSR - Operational clock prescaler
RCLK - Root Clock (derived from OPCLK based on PSR)
RFS - Root frequency selection (divider)
Frame clock - Sample frequency (derived from RCLK based on RFS)

Ultimately,

PSR = OPCLK / Frame clock / RFS

Unlike other platforms utilizing Samsung CPU DAI, FSD SoC has a limitation
on
operational clock, where the clock frequency is fixed (66 MHz) and cannot be
modified. 

Assuming that an userspace application wants perform playback @44100 Hz
and assuming that RFS divider value is configured as 256, the PSR value will
yield to

66 MHz / 44.1 KHz / 256 = 5

However if HW uses PSR = 5 to derive the frame clock from operational clock,
then

RCLK = OPCLK / PSR = 66 MHz / 5 = 13.2 MHz
Frame clock = RCLK / RFS = 13.2 MHz / 256 = 51562 Hz

The actual frame clock derived based on PSR is now different from what user
application has intended. The situation did not improve even if the RFS is
swept throughout the entire valid range.

We can overcome this scenario to an extent if we can get a flexibility to
Configure both PSR as well as RFS.

i.e. to achieve frame clock of 44100 Hz, if PSR  = 23 and RFS = 64
then frame clock = 66 MHz / 23 / 64 = 44836 Hz 

Although the sample frequency is not precise, it is very much closer to the
Intended frequency, when compared to that of the existing solution. Since
this
scenario is specific to FSD SoC and has no changes in the Samsung I2S CPU
DAI,
the configuration is being done from the sound card of FSD SoC during
hw_params.

Please let me know if you think this scenario can be approached in any other
way possible, rather than configuring from sound card.