[alsa-devel] SGTL500 and its external MCLK

[jonsmirl at gmail.com]

On Mon, Aug 11, 2014 at 1:50 AM, Nicolin Chen
<Guangyu.Chen at freescale.com> wrote:
> On Sat, Aug 09, 2014 at 12:42:43PM -0400, jonsmirl at gmail.com wrote:
>> On Fri, Aug 8, 2014 at 1:07 PM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
>> > On Fri, Aug 8, 2014 at 1:29 AM, Nicolin Chen <Guangyu.Chen at freescale.com> wrote:
>> >> On Thu, Aug 07, 2014 at 03:37:47PM -0400, jonsmirl at gmail.com wrote:
>> >>> Since the sgtl5000 driver has the handle to the clock, can't it just
>> >>> ask the clock for its rate? If it directly asked the clock for its
>> >>> rate it looks like this codec could be bound with simple-audio-card
>> >>> and not need a machine driver.
>> >>
>> >> I think Simple Card should already have the capability to support
>> >> this without changing sgtl5000's code. It has two properties that
>> >> can make it call set_sysclk() for you during the init(). They are
>> >> 'clocks' and 'system-clock-frequency'. Please refer to its binding
>> >> doc for details.
>>
>> Simple has a hard coded clock ID of zero. Which just happens to match
>> codecs/sgtl5000.h:#define SGTL5000_SYSCLK 0x00
>>
>> Lucky coincidence?
>
> It's also pretty fair to think that Simple Card only supports CODEC
> using the main sysclk -- id is 0x00. And I believe this also works
> out for other CODECs whose sysclk configurations aren't complicated
> since the name is Simple Card :)
>
>> >> And the topic why not let sgtl5000 fully control the clock has been
>> >> discussed in this thread:
>> >> http://comments.gmane.org/gmane.linux.alsa.devel/109093
>> >>
>> >> So I think the change can be done as well?
>> >
>> > I tried hacking on it some. One problem is with clocks that aren't
>> > 100% accurate. For example my clock is off a little - 22.571428. So
>> > when the code divides that by 44100 it gets 511.8 which truncates to
>> > 511 and the test for equal to 512 fails.
>
> This is a clock dividing accuracy issue. We can try DIV_ROUND_UP()
> instead of the truncating division.

Mark - how is clock accuracy supposed to be handled in ALSA? Should my
clocks tell their true rate 22.571428Mhz or lie and say they are
22.5792Mhz?

Are there problems with division truncation from the slightly low
clock rate lurking in the ALSA code that I need to avoid?



>
> Best regards,
> Nicolin



-- 
Jon Smirl
jonsmirl at gmail.com