All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-05-26 15:47 ` Judy Hsiao
  0 siblings, 0 replies; 21+ messages in thread
From: Judy Hsiao @ 2021-05-26 15:47 UTC (permalink / raw)
  To: broonie
  Cc: Taniya Das, Rohit kumar, Banajit Goswami, Patrick Lai,
	Andy Gross, Bjorn Andersson, Liam Girdwood, Rob Herring,
	Jaroslav Kysela, Takashi Iwai, Srini Kandagatla, Stephan Gerhold,
	dianders, dgreid, cychiang, tzungbi, swboyd, linux-arm-kernel,
	linux-arm-msm, devicetree, alsa-devel, Judy Hsiao

Sets channels_max to 4 to support QUAD channel.

Signed-off-by: Judy Hsiao <judyhsiao@chromium.org>
---
 sound/soc/codecs/max98357a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c
index 918812763884..c3cf1743caad 100644
--- a/sound/soc/codecs/max98357a.c
+++ b/sound/soc/codecs/max98357a.c
@@ -117,7 +117,7 @@ static struct snd_soc_dai_driver max98357a_dai_driver = {
 		.rate_min	= 8000,
 		.rate_max	= 96000,
 		.channels_min	= 1,
-		.channels_max	= 2,
+		.channels_max	= 4,
 	},
 	.ops    = &max98357a_dai_ops,
 };
-- 
2.31.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-05-26 15:47 ` Judy Hsiao
  0 siblings, 0 replies; 21+ messages in thread
From: Judy Hsiao @ 2021-05-26 15:47 UTC (permalink / raw)
  To: broonie
  Cc: Taniya Das, alsa-devel, Banajit Goswami, Liam Girdwood,
	Rohit kumar, Patrick Lai, Andy Gross, dgreid, devicetree,
	tzungbi, Stephan Gerhold, linux-arm-msm, swboyd, Rob Herring,
	Bjorn Andersson, linux-arm-kernel, dianders, cychiang,
	Takashi Iwai, Judy Hsiao

Sets channels_max to 4 to support QUAD channel.

Signed-off-by: Judy Hsiao <judyhsiao@chromium.org>
---
 sound/soc/codecs/max98357a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c
index 918812763884..c3cf1743caad 100644
--- a/sound/soc/codecs/max98357a.c
+++ b/sound/soc/codecs/max98357a.c
@@ -117,7 +117,7 @@ static struct snd_soc_dai_driver max98357a_dai_driver = {
 		.rate_min	= 8000,
 		.rate_max	= 96000,
 		.channels_min	= 1,
-		.channels_max	= 2,
+		.channels_max	= 4,
 	},
 	.ops    = &max98357a_dai_ops,
 };
-- 
2.31.0


^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-05-26 15:47 ` Judy Hsiao
  0 siblings, 0 replies; 21+ messages in thread
From: Judy Hsiao @ 2021-05-26 15:47 UTC (permalink / raw)
  To: broonie
  Cc: Taniya Das, Rohit kumar, Banajit Goswami, Patrick Lai,
	Andy Gross, Bjorn Andersson, Liam Girdwood, Rob Herring,
	Jaroslav Kysela, Takashi Iwai, Srini Kandagatla, Stephan Gerhold,
	dianders, dgreid, cychiang, tzungbi, swboyd, linux-arm-kernel,
	linux-arm-msm, devicetree, alsa-devel, Judy Hsiao

Sets channels_max to 4 to support QUAD channel.

Signed-off-by: Judy Hsiao <judyhsiao@chromium.org>
---
 sound/soc/codecs/max98357a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c
index 918812763884..c3cf1743caad 100644
--- a/sound/soc/codecs/max98357a.c
+++ b/sound/soc/codecs/max98357a.c
@@ -117,7 +117,7 @@ static struct snd_soc_dai_driver max98357a_dai_driver = {
 		.rate_min	= 8000,
 		.rate_max	= 96000,
 		.channels_min	= 1,
-		.channels_max	= 2,
+		.channels_max	= 4,
 	},
 	.ops    = &max98357a_dai_ops,
 };
-- 
2.31.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
  2021-05-26 15:47 ` Judy Hsiao
  (?)
@ 2021-06-01  6:20   ` Tzung-Bi Shih
  -1 siblings, 0 replies; 21+ messages in thread
From: Tzung-Bi Shih @ 2021-06-01  6:20 UTC (permalink / raw)
  To: Judy Hsiao
  Cc: Mark Brown, Taniya Das, Rohit kumar, Banajit Goswami,
	Patrick Lai, Andy Gross, Bjorn Andersson, Liam Girdwood,
	Rob Herring, Jaroslav Kysela, Takashi Iwai, Srini Kandagatla,
	Stephan Gerhold, Douglas Anderson, Dylan Reid,
	Jimmy Cheng-Yi Chiang, Tzung-Bi Shih, Stephen Boyd,
	moderated list:ARM/Mediatek SoC support, linux-arm-msm,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development

On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
> Sets channels_max to 4 to support QUAD channel.

Could you point out probably the up-to-date MAX98357A datasheet for
4-channel support?

On a related note, from the public datasheet I could find[1], "Table
5" only shows 2 channel's configuration.

[1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-01  6:20   ` Tzung-Bi Shih
  0 siblings, 0 replies; 21+ messages in thread
From: Tzung-Bi Shih @ 2021-06-01  6:20 UTC (permalink / raw)
  To: Judy Hsiao
  Cc: Taniya Das, ALSA development, Banajit Goswami, Liam Girdwood,
	Rohit kumar, Patrick Lai, Andy Gross, Dylan Reid,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Tzung-Bi Shih, Stephan Gerhold, linux-arm-msm, Stephen Boyd,
	Rob Herring, Bjorn Andersson,
	moderated list:ARM/Mediatek SoC support, Douglas Anderson,
	Jimmy Cheng-Yi Chiang, Takashi Iwai, Mark Brown

On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
> Sets channels_max to 4 to support QUAD channel.

Could you point out probably the up-to-date MAX98357A datasheet for
4-channel support?

On a related note, from the public datasheet I could find[1], "Table
5" only shows 2 channel's configuration.

[1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-01  6:20   ` Tzung-Bi Shih
  0 siblings, 0 replies; 21+ messages in thread
From: Tzung-Bi Shih @ 2021-06-01  6:20 UTC (permalink / raw)
  To: Judy Hsiao
  Cc: Mark Brown, Taniya Das, Rohit kumar, Banajit Goswami,
	Patrick Lai, Andy Gross, Bjorn Andersson, Liam Girdwood,
	Rob Herring, Jaroslav Kysela, Takashi Iwai, Srini Kandagatla,
	Stephan Gerhold, Douglas Anderson, Dylan Reid,
	Jimmy Cheng-Yi Chiang, Tzung-Bi Shih, Stephen Boyd,
	moderated list:ARM/Mediatek SoC support, linux-arm-msm,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development

On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
> Sets channels_max to 4 to support QUAD channel.

Could you point out probably the up-to-date MAX98357A datasheet for
4-channel support?

On a related note, from the public datasheet I could find[1], "Table
5" only shows 2 channel's configuration.

[1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
  2021-06-01  6:20   ` Tzung-Bi Shih
  (?)
@ 2021-06-15 15:47     ` Cheng-yi Chiang
  -1 siblings, 0 replies; 21+ messages in thread
From: Cheng-yi Chiang @ 2021-06-15 15:47 UTC (permalink / raw)
  To: Tzung-Bi Shih
  Cc: Judy Hsiao, Mark Brown, Taniya Das, Rohit kumar, Banajit Goswami,
	Patrick Lai, Andy Gross, Bjorn Andersson, Liam Girdwood,
	Rob Herring, Jaroslav Kysela, Takashi Iwai, Srini Kandagatla,
	Stephan Gerhold, Douglas Anderson, Dylan Reid, Tzung-Bi Shih,
	Stephen Boyd, moderated list:ARM/Mediatek SoC support,
	linux-arm-msm,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development

Hi Tzung-Bi,

On a platform, the four max98357a amps will be controlled by only one
codec device, as GPIO for SD_MODE is shared by all amps and is the
only thing to be controlled.
In this sense, I think we can treat max98357a DAI as if it supports
four channels.
I understand that this solution is not scalable, because one can
control as many amps as they want.
Theoretically, the number of supported channels by this codec device
is unlimited.
I found that rt1015.c has similar usage.
Do you have a better suggestion to support this kind of use case ?
Thanks!




On Tue, Jun 1, 2021 at 2:20 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
>
> On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
> > Sets channels_max to 4 to support QUAD channel.
>
> Could you point out probably the up-to-date MAX98357A datasheet for
> 4-channel support?
>
> On a related note, from the public datasheet I could find[1], "Table
> 5" only shows 2 channel's configuration.
>
> [1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-15 15:47     ` Cheng-yi Chiang
  0 siblings, 0 replies; 21+ messages in thread
From: Cheng-yi Chiang @ 2021-06-15 15:47 UTC (permalink / raw)
  To: Tzung-Bi Shih
  Cc: Taniya Das, ALSA development, Banajit Goswami, Takashi Iwai,
	Rohit kumar, Patrick Lai, Andy Gross, Dylan Reid,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Tzung-Bi Shih, Stephan Gerhold, linux-arm-msm, Stephen Boyd,
	Rob Herring, Bjorn Andersson,
	moderated list:ARM/Mediatek SoC support, Douglas Anderson,
	Liam Girdwood, Mark Brown, Judy Hsiao

Hi Tzung-Bi,

On a platform, the four max98357a amps will be controlled by only one
codec device, as GPIO for SD_MODE is shared by all amps and is the
only thing to be controlled.
In this sense, I think we can treat max98357a DAI as if it supports
four channels.
I understand that this solution is not scalable, because one can
control as many amps as they want.
Theoretically, the number of supported channels by this codec device
is unlimited.
I found that rt1015.c has similar usage.
Do you have a better suggestion to support this kind of use case ?
Thanks!




On Tue, Jun 1, 2021 at 2:20 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
>
> On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
> > Sets channels_max to 4 to support QUAD channel.
>
> Could you point out probably the up-to-date MAX98357A datasheet for
> 4-channel support?
>
> On a related note, from the public datasheet I could find[1], "Table
> 5" only shows 2 channel's configuration.
>
> [1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-15 15:47     ` Cheng-yi Chiang
  0 siblings, 0 replies; 21+ messages in thread
From: Cheng-yi Chiang @ 2021-06-15 15:47 UTC (permalink / raw)
  To: Tzung-Bi Shih
  Cc: Judy Hsiao, Mark Brown, Taniya Das, Rohit kumar, Banajit Goswami,
	Patrick Lai, Andy Gross, Bjorn Andersson, Liam Girdwood,
	Rob Herring, Jaroslav Kysela, Takashi Iwai, Srini Kandagatla,
	Stephan Gerhold, Douglas Anderson, Dylan Reid, Tzung-Bi Shih,
	Stephen Boyd, moderated list:ARM/Mediatek SoC support,
	linux-arm-msm,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development

Hi Tzung-Bi,

On a platform, the four max98357a amps will be controlled by only one
codec device, as GPIO for SD_MODE is shared by all amps and is the
only thing to be controlled.
In this sense, I think we can treat max98357a DAI as if it supports
four channels.
I understand that this solution is not scalable, because one can
control as many amps as they want.
Theoretically, the number of supported channels by this codec device
is unlimited.
I found that rt1015.c has similar usage.
Do you have a better suggestion to support this kind of use case ?
Thanks!




On Tue, Jun 1, 2021 at 2:20 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
>
> On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
> > Sets channels_max to 4 to support QUAD channel.
>
> Could you point out probably the up-to-date MAX98357A datasheet for
> 4-channel support?
>
> On a related note, from the public datasheet I could find[1], "Table
> 5" only shows 2 channel's configuration.
>
> [1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
  2021-06-15 15:47     ` Cheng-yi Chiang
  (?)
@ 2021-06-15 16:00       ` Pierre-Louis Bossart
  -1 siblings, 0 replies; 21+ messages in thread
From: Pierre-Louis Bossart @ 2021-06-15 16:00 UTC (permalink / raw)
  To: Cheng-yi Chiang, Tzung-Bi Shih
  Cc: Taniya Das, ALSA development, Banajit Goswami, Takashi Iwai,
	Rohit kumar, Patrick Lai, Andy Gross, Dylan Reid,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Tzung-Bi Shih, Stephan Gerhold, linux-arm-msm, Stephen Boyd,
	Rob Herring, Bjorn Andersson,
	moderated list:ARM/Mediatek SoC support, Douglas Anderson,
	Liam Girdwood, Mark Brown, Judy Hsiao



On 6/15/21 10:47 AM, Cheng-yi Chiang wrote:
> Hi Tzung-Bi,
> 
> On a platform, the four max98357a amps will be controlled by only one
> codec device, as GPIO for SD_MODE is shared by all amps and is the
> only thing to be controlled.
> In this sense, I think we can treat max98357a DAI as if it supports
> four channels.
> I understand that this solution is not scalable, because one can
> control as many amps as they want.
> Theoretically, the number of supported channels by this codec device
> is unlimited.
> I found that rt1015.c has similar usage.
> Do you have a better suggestion to support this kind of use case ?
> Thanks!

please don't top-post...

I don't think it's correct to declare 4-channel support at the 
individual codec DAI level when in practice each device will be provided 
with a TDM mask that selects two slots.

This is confusing device capabilities and TDM link configuration.

> On Tue, Jun 1, 2021 at 2:20 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
>>
>> On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
>>> Sets channels_max to 4 to support QUAD channel.
>>
>> Could you point out probably the up-to-date MAX98357A datasheet for
>> 4-channel support?
>>
>> On a related note, from the public datasheet I could find[1], "Table
>> 5" only shows 2 channel's configuration.
>>
>> [1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-15 16:00       ` Pierre-Louis Bossart
  0 siblings, 0 replies; 21+ messages in thread
From: Pierre-Louis Bossart @ 2021-06-15 16:00 UTC (permalink / raw)
  To: Cheng-yi Chiang, Tzung-Bi Shih
  Cc: Taniya Das,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development, Banajit Goswami, Stephan Gerhold,
	Liam Girdwood, linux-arm-msm, Patrick Lai, Takashi Iwai,
	Tzung-Bi Shih, Stephen Boyd, Rob Herring, Andy Gross,
	Rohit kumar, Mark Brown, Douglas Anderson, Dylan Reid,
	Bjorn Andersson, Judy Hsiao,
	moderated list:ARM/Mediatek SoC support



On 6/15/21 10:47 AM, Cheng-yi Chiang wrote:
> Hi Tzung-Bi,
> 
> On a platform, the four max98357a amps will be controlled by only one
> codec device, as GPIO for SD_MODE is shared by all amps and is the
> only thing to be controlled.
> In this sense, I think we can treat max98357a DAI as if it supports
> four channels.
> I understand that this solution is not scalable, because one can
> control as many amps as they want.
> Theoretically, the number of supported channels by this codec device
> is unlimited.
> I found that rt1015.c has similar usage.
> Do you have a better suggestion to support this kind of use case ?
> Thanks!

please don't top-post...

I don't think it's correct to declare 4-channel support at the 
individual codec DAI level when in practice each device will be provided 
with a TDM mask that selects two slots.

This is confusing device capabilities and TDM link configuration.

> On Tue, Jun 1, 2021 at 2:20 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
>>
>> On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
>>> Sets channels_max to 4 to support QUAD channel.
>>
>> Could you point out probably the up-to-date MAX98357A datasheet for
>> 4-channel support?
>>
>> On a related note, from the public datasheet I could find[1], "Table
>> 5" only shows 2 channel's configuration.
>>
>> [1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-15 16:00       ` Pierre-Louis Bossart
  0 siblings, 0 replies; 21+ messages in thread
From: Pierre-Louis Bossart @ 2021-06-15 16:00 UTC (permalink / raw)
  To: Cheng-yi Chiang, Tzung-Bi Shih
  Cc: Taniya Das, ALSA development, Banajit Goswami, Takashi Iwai,
	Rohit kumar, Patrick Lai, Andy Gross, Dylan Reid,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Tzung-Bi Shih, Stephan Gerhold, linux-arm-msm, Stephen Boyd,
	Rob Herring, Bjorn Andersson,
	moderated list:ARM/Mediatek SoC support, Douglas Anderson,
	Liam Girdwood, Mark Brown, Judy Hsiao



On 6/15/21 10:47 AM, Cheng-yi Chiang wrote:
> Hi Tzung-Bi,
> 
> On a platform, the four max98357a amps will be controlled by only one
> codec device, as GPIO for SD_MODE is shared by all amps and is the
> only thing to be controlled.
> In this sense, I think we can treat max98357a DAI as if it supports
> four channels.
> I understand that this solution is not scalable, because one can
> control as many amps as they want.
> Theoretically, the number of supported channels by this codec device
> is unlimited.
> I found that rt1015.c has similar usage.
> Do you have a better suggestion to support this kind of use case ?
> Thanks!

please don't top-post...

I don't think it's correct to declare 4-channel support at the 
individual codec DAI level when in practice each device will be provided 
with a TDM mask that selects two slots.

This is confusing device capabilities and TDM link configuration.

> On Tue, Jun 1, 2021 at 2:20 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
>>
>> On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
>>> Sets channels_max to 4 to support QUAD channel.
>>
>> Could you point out probably the up-to-date MAX98357A datasheet for
>> 4-channel support?
>>
>> On a related note, from the public datasheet I could find[1], "Table
>> 5" only shows 2 channel's configuration.
>>
>> [1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
  2021-06-15 16:00       ` Pierre-Louis Bossart
  (?)
@ 2021-06-16 10:14         ` Cheng-yi Chiang
  -1 siblings, 0 replies; 21+ messages in thread
From: Cheng-yi Chiang @ 2021-06-16 10:14 UTC (permalink / raw)
  To: Pierre-Louis Bossart
  Cc: Tzung-Bi Shih, Taniya Das, ALSA development, Banajit Goswami,
	Takashi Iwai, Rohit kumar, Patrick Lai, Andy Gross, Dylan Reid,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Tzung-Bi Shih, Stephan Gerhold, linux-arm-msm, Stephen Boyd,
	Rob Herring, Bjorn Andersson,
	moderated list:ARM/Mediatek SoC support, Douglas Anderson,
	Liam Girdwood, Mark Brown, Judy Hsiao

On Wed, Jun 16, 2021 at 12:00 AM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
>
> On 6/15/21 10:47 AM, Cheng-yi Chiang wrote:
> > Hi Tzung-Bi,
> >
> > On a platform, the four max98357a amps will be controlled by only one
> > codec device, as GPIO for SD_MODE is shared by all amps and is the
> > only thing to be controlled.
> > In this sense, I think we can treat max98357a DAI as if it supports
> > four channels.
> > I understand that this solution is not scalable, because one can
> > control as many amps as they want.
> > Theoretically, the number of supported channels by this codec device
> > is unlimited.
> > I found that rt1015.c has similar usage.
> > Do you have a better suggestion to support this kind of use case ?
> > Thanks!
>
> please don't top-post...
Hi Pierre-Louis,

I am sorry about that!
>
>
> I don't think it's correct to declare 4-channel support at the
> individual codec DAI level when in practice each device will be provided
> with a TDM mask that selects two slots.

On this platform there is no TDM support, so there were two I2S data lines.

>
> This is confusing device capabilities and TDM link configuration.

I see that in most of the use cases of multiple amps, we should use
codecs and num_codecs of the link.
But in this case we only want one codec to control the only GPIO
shared by 4 max98357a amps
I think we should be able to use 1 max98357 codec and 3 dummy codec to
fulfill this use case.
Not sure if the number of dummy codec would really matter.
With num_codec > 1 we should be able to bypass the channel checking
and just use the channel from CPU DAI.
Thanks for the suggestion.


>
> > On Tue, Jun 1, 2021 at 2:20 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
> >>
> >> On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
> >>> Sets channels_max to 4 to support QUAD channel.
> >>
> >> Could you point out probably the up-to-date MAX98357A datasheet for
> >> 4-channel support?
> >>
> >> On a related note, from the public datasheet I could find[1], "Table
> >> 5" only shows 2 channel's configuration.
> >>
> >> [1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-16 10:14         ` Cheng-yi Chiang
  0 siblings, 0 replies; 21+ messages in thread
From: Cheng-yi Chiang @ 2021-06-16 10:14 UTC (permalink / raw)
  To: Pierre-Louis Bossart
  Cc: Taniya Das,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development, Banajit Goswami, Rob Herring, Stephan Gerhold,
	Liam Girdwood, linux-arm-msm, Patrick Lai, Takashi Iwai,
	Tzung-Bi Shih, Stephen Boyd, Tzung-Bi Shih, Andy Gross,
	Rohit kumar, Mark Brown, Douglas Anderson, Dylan Reid,
	Bjorn Andersson, Judy Hsiao,
	moderated list:ARM/Mediatek SoC support

On Wed, Jun 16, 2021 at 12:00 AM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
>
> On 6/15/21 10:47 AM, Cheng-yi Chiang wrote:
> > Hi Tzung-Bi,
> >
> > On a platform, the four max98357a amps will be controlled by only one
> > codec device, as GPIO for SD_MODE is shared by all amps and is the
> > only thing to be controlled.
> > In this sense, I think we can treat max98357a DAI as if it supports
> > four channels.
> > I understand that this solution is not scalable, because one can
> > control as many amps as they want.
> > Theoretically, the number of supported channels by this codec device
> > is unlimited.
> > I found that rt1015.c has similar usage.
> > Do you have a better suggestion to support this kind of use case ?
> > Thanks!
>
> please don't top-post...
Hi Pierre-Louis,

I am sorry about that!
>
>
> I don't think it's correct to declare 4-channel support at the
> individual codec DAI level when in practice each device will be provided
> with a TDM mask that selects two slots.

On this platform there is no TDM support, so there were two I2S data lines.

>
> This is confusing device capabilities and TDM link configuration.

I see that in most of the use cases of multiple amps, we should use
codecs and num_codecs of the link.
But in this case we only want one codec to control the only GPIO
shared by 4 max98357a amps
I think we should be able to use 1 max98357 codec and 3 dummy codec to
fulfill this use case.
Not sure if the number of dummy codec would really matter.
With num_codec > 1 we should be able to bypass the channel checking
and just use the channel from CPU DAI.
Thanks for the suggestion.


>
> > On Tue, Jun 1, 2021 at 2:20 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
> >>
> >> On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
> >>> Sets channels_max to 4 to support QUAD channel.
> >>
> >> Could you point out probably the up-to-date MAX98357A datasheet for
> >> 4-channel support?
> >>
> >> On a related note, from the public datasheet I could find[1], "Table
> >> 5" only shows 2 channel's configuration.
> >>
> >> [1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-16 10:14         ` Cheng-yi Chiang
  0 siblings, 0 replies; 21+ messages in thread
From: Cheng-yi Chiang @ 2021-06-16 10:14 UTC (permalink / raw)
  To: Pierre-Louis Bossart
  Cc: Tzung-Bi Shih, Taniya Das, ALSA development, Banajit Goswami,
	Takashi Iwai, Rohit kumar, Patrick Lai, Andy Gross, Dylan Reid,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Tzung-Bi Shih, Stephan Gerhold, linux-arm-msm, Stephen Boyd,
	Rob Herring, Bjorn Andersson,
	moderated list:ARM/Mediatek SoC support, Douglas Anderson,
	Liam Girdwood, Mark Brown, Judy Hsiao

On Wed, Jun 16, 2021 at 12:00 AM Pierre-Louis Bossart
<pierre-louis.bossart@linux.intel.com> wrote:
>
>
>
> On 6/15/21 10:47 AM, Cheng-yi Chiang wrote:
> > Hi Tzung-Bi,
> >
> > On a platform, the four max98357a amps will be controlled by only one
> > codec device, as GPIO for SD_MODE is shared by all amps and is the
> > only thing to be controlled.
> > In this sense, I think we can treat max98357a DAI as if it supports
> > four channels.
> > I understand that this solution is not scalable, because one can
> > control as many amps as they want.
> > Theoretically, the number of supported channels by this codec device
> > is unlimited.
> > I found that rt1015.c has similar usage.
> > Do you have a better suggestion to support this kind of use case ?
> > Thanks!
>
> please don't top-post...
Hi Pierre-Louis,

I am sorry about that!
>
>
> I don't think it's correct to declare 4-channel support at the
> individual codec DAI level when in practice each device will be provided
> with a TDM mask that selects two slots.

On this platform there is no TDM support, so there were two I2S data lines.

>
> This is confusing device capabilities and TDM link configuration.

I see that in most of the use cases of multiple amps, we should use
codecs and num_codecs of the link.
But in this case we only want one codec to control the only GPIO
shared by 4 max98357a amps
I think we should be able to use 1 max98357 codec and 3 dummy codec to
fulfill this use case.
Not sure if the number of dummy codec would really matter.
With num_codec > 1 we should be able to bypass the channel checking
and just use the channel from CPU DAI.
Thanks for the suggestion.


>
> > On Tue, Jun 1, 2021 at 2:20 PM Tzung-Bi Shih <tzungbi@google.com> wrote:
> >>
> >> On Wed, May 26, 2021 at 11:47 PM Judy Hsiao <judyhsiao@chromium.org> wrote:
> >>> Sets channels_max to 4 to support QUAD channel.
> >>
> >> Could you point out probably the up-to-date MAX98357A datasheet for
> >> 4-channel support?
> >>
> >> On a related note, from the public datasheet I could find[1], "Table
> >> 5" only shows 2 channel's configuration.
> >>
> >> [1]: https://pdf1.alldatasheet.com/datasheet-pdf/view/623796/MAXIM/MAX98357A.html

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
  2021-06-16 10:14         ` Cheng-yi Chiang
  (?)
@ 2021-06-16 16:23           ` Pierre-Louis Bossart
  -1 siblings, 0 replies; 21+ messages in thread
From: Pierre-Louis Bossart @ 2021-06-16 16:23 UTC (permalink / raw)
  To: Cheng-yi Chiang
  Cc: Taniya Das,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development, Banajit Goswami, Rob Herring, Stephan Gerhold,
	Liam Girdwood, linux-arm-msm, Patrick Lai, Takashi Iwai,
	Tzung-Bi Shih, Stephen Boyd, Tzung-Bi Shih, Andy Gross,
	Rohit kumar, Mark Brown, Douglas Anderson, Dylan Reid,
	Bjorn Andersson, Judy Hsiao,
	moderated list:ARM/Mediatek SoC support


>> I don't think it's correct to declare 4-channel support at the
>> individual codec DAI level when in practice each device will be provided
>> with a TDM mask that selects two slots.
> 
> On this platform there is no TDM support, so there were two I2S data lines.
> 
>>
>> This is confusing device capabilities and TDM link configuration.
> 
> I see that in most of the use cases of multiple amps, we should use
> codecs and num_codecs of the link.
> But in this case we only want one codec to control the only GPIO
> shared by 4 max98357a amps
> I think we should be able to use 1 max98357 codec and 3 dummy codec to
> fulfill this use case.
> Not sure if the number of dummy codec would really matter.
> With num_codec > 1 we should be able to bypass the channel checking
> and just use the channel from CPU DAI.

Interesting, I haven't seen such 'multi-lane' solutions so far for I2S.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-16 16:23           ` Pierre-Louis Bossart
  0 siblings, 0 replies; 21+ messages in thread
From: Pierre-Louis Bossart @ 2021-06-16 16:23 UTC (permalink / raw)
  To: Cheng-yi Chiang
  Cc: Taniya Das,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development, Banajit Goswami, Stephan Gerhold,
	linux-arm-msm, Patrick Lai, Mark Brown, Bjorn Andersson,
	Liam Girdwood, Tzung-Bi Shih, Takashi Iwai, Tzung-Bi Shih,
	Rob Herring, Rohit kumar, Andy Gross, Douglas Anderson,
	Dylan Reid, Stephen Boyd, Judy Hsiao,
	moderated list:ARM/Mediatek SoC support


>> I don't think it's correct to declare 4-channel support at the
>> individual codec DAI level when in practice each device will be provided
>> with a TDM mask that selects two slots.
> 
> On this platform there is no TDM support, so there were two I2S data lines.
> 
>>
>> This is confusing device capabilities and TDM link configuration.
> 
> I see that in most of the use cases of multiple amps, we should use
> codecs and num_codecs of the link.
> But in this case we only want one codec to control the only GPIO
> shared by 4 max98357a amps
> I think we should be able to use 1 max98357 codec and 3 dummy codec to
> fulfill this use case.
> Not sure if the number of dummy codec would really matter.
> With num_codec > 1 we should be able to bypass the channel checking
> and just use the channel from CPU DAI.

Interesting, I haven't seen such 'multi-lane' solutions so far for I2S.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-16 16:23           ` Pierre-Louis Bossart
  0 siblings, 0 replies; 21+ messages in thread
From: Pierre-Louis Bossart @ 2021-06-16 16:23 UTC (permalink / raw)
  To: Cheng-yi Chiang
  Cc: Taniya Das,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development, Banajit Goswami, Rob Herring, Stephan Gerhold,
	Liam Girdwood, linux-arm-msm, Patrick Lai, Takashi Iwai,
	Tzung-Bi Shih, Stephen Boyd, Tzung-Bi Shih, Andy Gross,
	Rohit kumar, Mark Brown, Douglas Anderson, Dylan Reid,
	Bjorn Andersson, Judy Hsiao,
	moderated list:ARM/Mediatek SoC support


>> I don't think it's correct to declare 4-channel support at the
>> individual codec DAI level when in practice each device will be provided
>> with a TDM mask that selects two slots.
> 
> On this platform there is no TDM support, so there were two I2S data lines.
> 
>>
>> This is confusing device capabilities and TDM link configuration.
> 
> I see that in most of the use cases of multiple amps, we should use
> codecs and num_codecs of the link.
> But in this case we only want one codec to control the only GPIO
> shared by 4 max98357a amps
> I think we should be able to use 1 max98357 codec and 3 dummy codec to
> fulfill this use case.
> Not sure if the number of dummy codec would really matter.
> With num_codec > 1 we should be able to bypass the channel checking
> and just use the channel from CPU DAI.

Interesting, I haven't seen such 'multi-lane' solutions so far for I2S.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
  2021-06-16 16:23           ` Pierre-Louis Bossart
  (?)
@ 2021-06-16 20:40             ` Mark Brown
  -1 siblings, 0 replies; 21+ messages in thread
From: Mark Brown @ 2021-06-16 20:40 UTC (permalink / raw)
  To: Pierre-Louis Bossart
  Cc: Cheng-yi Chiang, Taniya Das,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development, Banajit Goswami, Rob Herring, Stephan Gerhold,
	Liam Girdwood, linux-arm-msm, Patrick Lai, Takashi Iwai,
	Tzung-Bi Shih, Stephen Boyd, Tzung-Bi Shih, Andy Gross,
	Rohit kumar, Douglas Anderson, Dylan Reid, Bjorn Andersson,
	Judy Hsiao, moderated list:ARM/Mediatek SoC support

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Wed, Jun 16, 2021 at 11:23:36AM -0500, Pierre-Louis Bossart wrote:

> > On this platform there is no TDM support, so there were two I2S data lines.

> Interesting, I haven't seen such 'multi-lane' solutions so far for I2S.

They're moderately common for high end systems (eg, you'll see surround
sound systems do this) - it makes it easier to find higher performance
DACs if you can use regular stereo DACs and it helps a bit with layout
if you can run slower digital signals.  There's controllers upstream
that do this without needing to tie together multiple stereo controllers
on the SoC side, one of the variants of the Samsung I2S controllers does
it for example.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-16 20:40             ` Mark Brown
  0 siblings, 0 replies; 21+ messages in thread
From: Mark Brown @ 2021-06-16 20:40 UTC (permalink / raw)
  To: Pierre-Louis Bossart
  Cc: Taniya Das,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development, Banajit Goswami, Stephan Gerhold,
	linux-arm-msm, Patrick Lai, Bjorn Andersson, Liam Girdwood,
	Tzung-Bi Shih, Takashi Iwai, Tzung-Bi Shih, Rob Herring,
	Rohit kumar, Andy Gross, Douglas Anderson, Dylan Reid,
	Stephen Boyd, Judy Hsiao,
	moderated list:ARM/Mediatek SoC support, Cheng-yi Chiang

[-- Attachment #1: Type: text/plain, Size: 672 bytes --]

On Wed, Jun 16, 2021 at 11:23:36AM -0500, Pierre-Louis Bossart wrote:

> > On this platform there is no TDM support, so there were two I2S data lines.

> Interesting, I haven't seen such 'multi-lane' solutions so far for I2S.

They're moderately common for high end systems (eg, you'll see surround
sound systems do this) - it makes it easier to find higher performance
DACs if you can use regular stereo DACs and it helps a bit with layout
if you can run slower digital signals.  There's controllers upstream
that do this without needing to tie together multiple stereo controllers
on the SoC side, one of the variants of the Samsung I2S controllers does
it for example.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] ASoC: max98357a: set channels_max to 4
@ 2021-06-16 20:40             ` Mark Brown
  0 siblings, 0 replies; 21+ messages in thread
From: Mark Brown @ 2021-06-16 20:40 UTC (permalink / raw)
  To: Pierre-Louis Bossart
  Cc: Cheng-yi Chiang, Taniya Das,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	ALSA development, Banajit Goswami, Rob Herring, Stephan Gerhold,
	Liam Girdwood, linux-arm-msm, Patrick Lai, Takashi Iwai,
	Tzung-Bi Shih, Stephen Boyd, Tzung-Bi Shih, Andy Gross,
	Rohit kumar, Douglas Anderson, Dylan Reid, Bjorn Andersson,
	Judy Hsiao, moderated list:ARM/Mediatek SoC support


[-- Attachment #1.1: Type: text/plain, Size: 672 bytes --]

On Wed, Jun 16, 2021 at 11:23:36AM -0500, Pierre-Louis Bossart wrote:

> > On this platform there is no TDM support, so there were two I2S data lines.

> Interesting, I haven't seen such 'multi-lane' solutions so far for I2S.

They're moderately common for high end systems (eg, you'll see surround
sound systems do this) - it makes it easier to find higher performance
DACs if you can use regular stereo DACs and it helps a bit with layout
if you can run slower digital signals.  There's controllers upstream
that do this without needing to tie together multiple stereo controllers
on the SoC side, one of the variants of the Samsung I2S controllers does
it for example.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2021-06-16 20:42 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-26 15:47 [PATCH] ASoC: max98357a: set channels_max to 4 Judy Hsiao
2021-05-26 15:47 ` Judy Hsiao
2021-05-26 15:47 ` Judy Hsiao
2021-06-01  6:20 ` Tzung-Bi Shih
2021-06-01  6:20   ` Tzung-Bi Shih
2021-06-01  6:20   ` Tzung-Bi Shih
2021-06-15 15:47   ` Cheng-yi Chiang
2021-06-15 15:47     ` Cheng-yi Chiang
2021-06-15 15:47     ` Cheng-yi Chiang
2021-06-15 16:00     ` Pierre-Louis Bossart
2021-06-15 16:00       ` Pierre-Louis Bossart
2021-06-15 16:00       ` Pierre-Louis Bossart
2021-06-16 10:14       ` Cheng-yi Chiang
2021-06-16 10:14         ` Cheng-yi Chiang
2021-06-16 10:14         ` Cheng-yi Chiang
2021-06-16 16:23         ` Pierre-Louis Bossart
2021-06-16 16:23           ` Pierre-Louis Bossart
2021-06-16 16:23           ` Pierre-Louis Bossart
2021-06-16 20:40           ` Mark Brown
2021-06-16 20:40             ` Mark Brown
2021-06-16 20:40             ` Mark Brown

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.