> -----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.
