[PATCH] ASoC: max98357a: set channels_max to 4
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, };
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
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.
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.
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.
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.
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.
participants (5)
-
Cheng-yi Chiang -
Judy Hsiao -
Mark Brown -
Pierre-Louis Bossart -
Tzung-Bi Shih