Re: [PATCH 1/6] ASoC: max98088: Document DT bindings
Hello Sylwester, On 02/20/2015 01:12 PM, Sylwester Nawrocki wrote: On 20/02/15 01:36, Andreas Färber wrote: So it seems the mclk is not always set up properly by the kernel, relying on firmware. Who's in charge of setting that clock up? Right, it seems audio is only working due the firmware doing some previous setup. Probably it works on every boot if you have sound init as a part of the u-boot boot commands? Indeed it does, 24 MHz without the reparenting patch, and sound working. You can have parent of the CLKOUT clock set by the clk core if it is specified in device tree in the PMU (the clkout clock supplier) device node. Similarly as we did for the Odroix U3: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroid-common.dtsi#n39 Relying on the clk_set_rate() to set the parent clock is not optimal IMO. Presumably you need to set select stable parent clock for clkout like XXTI. But I'm not very familiar with exyno5250 and that might be something different. Thanks a lot for your suggestion. I'll drop Tushar's patch to allow clkout to be reparent during set_rate then and change his DTS patch to set a default parent for CLKOUT using assigned-clock-parents. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ASoC: max98088: Document DT bindings
On 20/02/15 01:36, Andreas Färber wrote: So it seems the mclk is not always set up properly by the kernel, relying on firmware. Who's in charge of setting that clock up? Right, it seems audio is only working due the firmware doing some previous setup. Probably it works on every boot if you have sound init as a part of the u-boot boot commands? Indeed it does, 24 MHz without the reparenting patch, and sound working. You can have parent of the CLKOUT clock set by the clk core if it is specified in device tree in the PMU (the clkout clock supplier) device node. Similarly as we did for the Odroix U3: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroid-common.dtsi#n39 Relying on the clk_set_rate() to set the parent clock is not optimal IMO. Presumably you need to set select stable parent clock for clkout like XXTI. But I'm not very familiar with exyno5250 and that might be something different. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ASoC: max98088: Document DT bindings
Hello Andreas,
We already talked over irc but for completeness I'll comment here
as well.
On 02/19/2015 07:54 PM, Andreas Färber wrote:
Am 19.02.2015 um 19:40 schrieb Andreas Färber:
Am 19.02.2015 um 18:48 schrieb Doug Anderson:
On Thu, Feb 19, 2015 at 6:13 AM, Andreas Färber afaer...@suse.de wrote:
I see that a master clock (mclk) is added in patch 6/6 but the
max98088 codec driver does handle this clock.
Sorry, I wanted to say the driver *does not* handle this clock but
fortunately you understood what I meant :)
If the SoC XCLKOUT provides the master clock to the max98089
codec in Spring like is the case for the max9809{0,5} codecs
in the Snow and Peach Pit/Pi Chromebooks then you need to do
something along the lines of the following commits:
e3048c3d2be5 ASoC: max98095: Add master clock handling
b10ab7b838bd ASoC: max98090: Add master clock handling
If that's the case you also have to mention in the DT binding
doc that clocks and clock-names are optional properties
like Documentation/devicetree/bindings/sound/max9809{0,5}.txt.
When I prepared this patch, I believe it was a straight copy from
max98090. Sounds like they changed since then.
My 6/6 adopted the mclk clock from your now-cancelled v2 patch for Snow,
assuming it would be the same on all Chromebooks. I tested that last
change by checking for errors in dmesg.
Doug, can you advise on how the clock wiring is for Spring?
I can confirm that XCLKOUT is connected to the codec MCLK on the
Spring schematics I have.
Thanks! I updated max98088 and had it working on first boot, but on
second boot it complained about the frequency:
[7.896834] max98088 7-0010: revision A
[7.912776] snow-audio sound: HiFi - 383.i2s mapping ok
[7.919367] max98088 7-0010: Invalid master clock frequency
[7.919429] snow-audio sound: ASoC: Spring-I2S-MAX98089 late_probe()
failed: -22
[7.920019] snow-audio sound: snd_soc_register_card failed (-22)
[7.920109] snow-audio: probe of sound failed with error -22
I had the same error on Snow but even on the first boot and after doing some
code archeology, I found the following commit [0] in a Samsung downstream
tree that solves the issue.
The problem is that clk_round_rate(max98095-mclk, freq) returns 0 as the
rounded rate if XCLOUT is not allowed to be re-parented on rate change.
With Tushar's patch I see that clk_round_rate() returns 2400 (24MHz)
so the codec driver setups the correct PLL clock.
You mentioned that it does make the error go away but still audio is not
working on Spring. Let's see if someone has an idea of what could be missing.
Reproducible on third boot.
On a suspicion, the fourth boot I waited for the double-beep of the
firmware (waiting for Ctrl+d/u), and then it did work.
So it seems the mclk is not always set up properly by the kernel,
relying on firmware. Who's in charge of setting that clock up?
Right, it seems audio is only working due the firmware doing some previous
setup. Probably it works on every boot if you have sound init as a part of
the u-boot boot commands?
Regards,
Andreas
Best regards,
Javier
[0]:
https://github.com/exynos-reference/kernel/commit/34ae055b32e621409a92dea6a29f65b723798f33
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ASoC: max98088: Document DT bindings
Hello Andreas,
On 02/18/2015 07:25 PM, Andreas Färber wrote:
Signed-off-by: Andreas Färber afaer...@suse.de
---
Documentation/devicetree/bindings/sound/max98088.txt | 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/max98088.txt
diff --git a/Documentation/devicetree/bindings/sound/max98088.txt
b/Documentation/devicetree/bindings/sound/max98088.txt
new file mode 100644
index ..6f8fe85040ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max98088.txt
@@ -0,0 +1,16 @@
+MAX98088 audio CODEC
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : maxim,max98088 or maxim,max98089.
+
+- reg : The I2C address of the device.
+
+Example:
+
+max98089: codec@10 {
+ compatible = maxim,max98089;
+ reg = 0x10;
+};
I see that a master clock (mclk) is added in patch 6/6 but the
max98088 codec driver does handle this clock.
If the SoC XCLKOUT provides the master clock to the max98089
codec in Spring like is the case for the max9809{0,5} codecs
in the Snow and Peach Pit/Pi Chromebooks then you need to do
something along the lines of the following commits:
e3048c3d2be5 ASoC: max98095: Add master clock handling
b10ab7b838bd ASoC: max98090: Add master clock handling
If that's the case you also have to mention in the DT binding
doc that clocks and clock-names are optional properties
like Documentation/devicetree/bindings/sound/max9809{0,5}.txt.
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ASoC: max98088: Document DT bindings
Am 19.02.2015 um 19:40 schrieb Andreas Färber:
Am 19.02.2015 um 18:48 schrieb Doug Anderson:
On Thu, Feb 19, 2015 at 6:13 AM, Andreas Färber afaer...@suse.de wrote:
I see that a master clock (mclk) is added in patch 6/6 but the
max98088 codec driver does handle this clock.
If the SoC XCLKOUT provides the master clock to the max98089
codec in Spring like is the case for the max9809{0,5} codecs
in the Snow and Peach Pit/Pi Chromebooks then you need to do
something along the lines of the following commits:
e3048c3d2be5 ASoC: max98095: Add master clock handling
b10ab7b838bd ASoC: max98090: Add master clock handling
If that's the case you also have to mention in the DT binding
doc that clocks and clock-names are optional properties
like Documentation/devicetree/bindings/sound/max9809{0,5}.txt.
When I prepared this patch, I believe it was a straight copy from
max98090. Sounds like they changed since then.
My 6/6 adopted the mclk clock from your now-cancelled v2 patch for Snow,
assuming it would be the same on all Chromebooks. I tested that last
change by checking for errors in dmesg.
Doug, can you advise on how the clock wiring is for Spring?
I can confirm that XCLKOUT is connected to the codec MCLK on the
Spring schematics I have.
Thanks! I updated max98088 and had it working on first boot, but on
second boot it complained about the frequency:
[7.896834] max98088 7-0010: revision A
[7.912776] snow-audio sound: HiFi - 383.i2s mapping ok
[7.919367] max98088 7-0010: Invalid master clock frequency
[7.919429] snow-audio sound: ASoC: Spring-I2S-MAX98089 late_probe()
failed: -22
[7.920019] snow-audio sound: snd_soc_register_card failed (-22)
[7.920109] snow-audio: probe of sound failed with error -22
Reproducible on third boot.
On a suspicion, the fourth boot I waited for the double-beep of the
firmware (waiting for Ctrl+d/u), and then it did work.
So it seems the mclk is not always set up properly by the kernel,
relying on firmware. Who's in charge of setting that clock up?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ASoC: max98088: Document DT bindings
Am 19.02.2015 um 18:48 schrieb Doug Anderson:
On Thu, Feb 19, 2015 at 6:13 AM, Andreas Färber afaer...@suse.de wrote:
I see that a master clock (mclk) is added in patch 6/6 but the
max98088 codec driver does handle this clock.
If the SoC XCLKOUT provides the master clock to the max98089
codec in Spring like is the case for the max9809{0,5} codecs
in the Snow and Peach Pit/Pi Chromebooks then you need to do
something along the lines of the following commits:
e3048c3d2be5 ASoC: max98095: Add master clock handling
b10ab7b838bd ASoC: max98090: Add master clock handling
If that's the case you also have to mention in the DT binding
doc that clocks and clock-names are optional properties
like Documentation/devicetree/bindings/sound/max9809{0,5}.txt.
When I prepared this patch, I believe it was a straight copy from
max98090. Sounds like they changed since then.
My 6/6 adopted the mclk clock from your now-cancelled v2 patch for Snow,
assuming it would be the same on all Chromebooks. I tested that last
change by checking for errors in dmesg.
Doug, can you advise on how the clock wiring is for Spring?
I can confirm that XCLKOUT is connected to the codec MCLK on the
Spring schematics I have.
Thanks! I updated max98088 and had it working on first boot, but on
second boot it complained about the frequency:
[7.896834] max98088 7-0010: revision A
[7.912776] snow-audio sound: HiFi - 383.i2s mapping ok
[7.919367] max98088 7-0010: Invalid master clock frequency
[7.919429] snow-audio sound: ASoC: Spring-I2S-MAX98089 late_probe()
failed: -22
[7.920019] snow-audio sound: snd_soc_register_card failed (-22)
[7.920109] snow-audio: probe of sound failed with error -22
Will investigate.
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ASoC: max98088: Document DT bindings
Hello Javier, Doug,
Am 19.02.2015 um 14:55 schrieb Javier Martinez Canillas:
On 02/18/2015 07:25 PM, Andreas Färber wrote:
Signed-off-by: Andreas Färber afaer...@suse.de
---
Documentation/devicetree/bindings/sound/max98088.txt | 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/max98088.txt
diff --git a/Documentation/devicetree/bindings/sound/max98088.txt
b/Documentation/devicetree/bindings/sound/max98088.txt
new file mode 100644
index ..6f8fe85040ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max98088.txt
@@ -0,0 +1,16 @@
+MAX98088 audio CODEC
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : maxim,max98088 or maxim,max98089.
+
+- reg : The I2C address of the device.
+
+Example:
+
+max98089: codec@10 {
+compatible = maxim,max98089;
+reg = 0x10;
+};
I see that a master clock (mclk) is added in patch 6/6 but the
max98088 codec driver does handle this clock.
If the SoC XCLKOUT provides the master clock to the max98089
codec in Spring like is the case for the max9809{0,5} codecs
in the Snow and Peach Pit/Pi Chromebooks then you need to do
something along the lines of the following commits:
e3048c3d2be5 ASoC: max98095: Add master clock handling
b10ab7b838bd ASoC: max98090: Add master clock handling
If that's the case you also have to mention in the DT binding
doc that clocks and clock-names are optional properties
like Documentation/devicetree/bindings/sound/max9809{0,5}.txt.
When I prepared this patch, I believe it was a straight copy from
max98090. Sounds like they changed since then.
My 6/6 adopted the mclk clock from your now-cancelled v2 patch for Snow,
assuming it would be the same on all Chromebooks. I tested that last
change by checking for errors in dmesg.
Doug, can you advise on how the clock wiring is for Spring?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ASoC: max98088: Document DT bindings
Andreas,
On Thu, Feb 19, 2015 at 6:13 AM, Andreas Färber afaer...@suse.de wrote:
I see that a master clock (mclk) is added in patch 6/6 but the
max98088 codec driver does handle this clock.
If the SoC XCLKOUT provides the master clock to the max98089
codec in Spring like is the case for the max9809{0,5} codecs
in the Snow and Peach Pit/Pi Chromebooks then you need to do
something along the lines of the following commits:
e3048c3d2be5 ASoC: max98095: Add master clock handling
b10ab7b838bd ASoC: max98090: Add master clock handling
If that's the case you also have to mention in the DT binding
doc that clocks and clock-names are optional properties
like Documentation/devicetree/bindings/sound/max9809{0,5}.txt.
When I prepared this patch, I believe it was a straight copy from
max98090. Sounds like they changed since then.
My 6/6 adopted the mclk clock from your now-cancelled v2 patch for Snow,
assuming it would be the same on all Chromebooks. I tested that last
change by checking for errors in dmesg.
Doug, can you advise on how the clock wiring is for Spring?
I can confirm that XCLKOUT is connected to the codec MCLK on the
Spring schematics I have.
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ASoC: max98088: Document DT bindings
Am 19.02.2015 um 21:48 schrieb Javier Martinez Canillas:
On 02/19/2015 07:54 PM, Andreas Färber wrote:
Am 19.02.2015 um 19:40 schrieb Andreas Färber:
I updated max98088 and had it working on first boot, but on
second boot it complained about the frequency:
[7.896834] max98088 7-0010: revision A
[7.912776] snow-audio sound: HiFi - 383.i2s mapping ok
[7.919367] max98088 7-0010: Invalid master clock frequency
[7.919429] snow-audio sound: ASoC: Spring-I2S-MAX98089 late_probe()
failed: -22
[7.920019] snow-audio sound: snd_soc_register_card failed (-22)
[7.920109] snow-audio: probe of sound failed with error -22
I had the same error on Snow but even on the first boot and after doing some
code archeology, I found the following commit [0] in a Samsung downstream
tree that solves the issue.
The problem is that clk_round_rate(max98095-mclk, freq) returns 0 as the
rounded rate if XCLOUT is not allowed to be re-parented on rate change.
Same on Spring:
diff --git a/sound/soc/codecs/max98088.c b/sound/soc/codecs/max98088.c
index 1aa81321afba..46dc64675c26 100644
--- a/sound/soc/codecs/max98088.c
+++ b/sound/soc/codecs/max98088.c
@@ -1365,6 +1365,7 @@ static int max98088_dai_set_sysclk(struct
snd_soc_dai *dai,
if (!IS_ERR(max98088-mclk)) {
freq = clk_round_rate(max98088-mclk, freq);
+ dev_warn(codec-dev, freq = %u\n, freq);
clk_set_rate(max98088-mclk, freq);
}
With Tushar's patch I see that clk_round_rate() returns 2400 (24MHz)
so the codec driver setups the correct PLL clock.
Ditto. With the clkout reparenting patch, clk_round_rate() returns 24MHz
just like when double-beep-initialized. However when not
double-beep-initialized, the driver initializes, but no audible output,
so there must be another missing puzzle piece.
On a suspicion, the fourth boot I waited for the double-beep of the
firmware (waiting for Ctrl+d/u), and then it did work.
So it seems the mclk is not always set up properly by the kernel,
relying on firmware. Who's in charge of setting that clock up?
Right, it seems audio is only working due the firmware doing some previous
setup. Probably it works on every boot if you have sound init as a part of
the u-boot boot commands?
Indeed it does, 24 MHz without the reparenting patch, and sound working.
'sound init' code:
https://github.com/afaerber/u-boot/blob/spring/drivers/sound/max98088.c
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
