public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sameer Pujar <spujar@nvidia.com>
To: Mark Brown <broonie@kernel.org>
Cc: robh+dt@kernel.org, krzk+dt@kernel.org, thierry.reding@gmail.com,
	lgirdwood@gmail.com, perex@perex.cz, tiwai@suse.com,
	jonathanh@nvidia.com, mkumard@nvidia.com, sheetal@nvidia.com,
	alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 2/8] ASoC: tegra: Fix AMX byte map
Date: Fri, 23 Jun 2023 11:09:32 +0530	[thread overview]
Message-ID: <7893c366-e6aa-d606-c3d6-e85f73a345e0@nvidia.com> (raw)
In-Reply-To: <ad4b4dc9-7466-45a9-a008-c2301a7485dd@sirena.org.uk>



On 22-06-2023 17:37, Mark Brown wrote:
> On Thu, Jun 22, 2023 at 05:04:10PM +0530, Sameer Pujar wrote:
>> From: Sheetal <sheetal@nvidia.com>
>>
>> Byte mask for channel-1 of stream-1 is not getting enabled and this
>> causes failures during AMX use cases. The enable bit is not set during
>> put() callback of byte map mixer control.
>>
>> This happens because the byte map value 0 matches the initial state
>> of byte map array and put() callback returns without doing anything.
>>
>> Fix the put() callback by actually looking at the byte mask array
>> to identify if any change is needed and update the fields accordingly.
> I'm not quite sure I follow the logic here - I'd have expected this to
> mean that there's a bootstrapping issue and that we should be doing some
> more initialisation during startup such that the existing code which
> checks if there is a change will be doing the right thing?
The issue can happen in subsequent cycles as well if once the user 
disables the byte map by putting 256. It happens because of following 
reason where 256 value is reset to 0 since the byte map array is tightly 
packed and it can't store 256 value.

static int tegra210_amx_put_byte_map() {
         ...
         if (value >= 0 && value <= 255)
             mask_val |= (1 << (reg % 32));
         else
             mask_val &= ~(1 << (reg % 32));

         if (mask_val == amx->byte_mask[reg / 32])
             return 0;

         /* Update byte map and slot */
==>     bytes_map[reg] = value % 256;
         amx->byte_mask[reg / 32] = mask_val;

         return 1;
}

>> Also update get() callback to return 256 if the byte map is disabled.
> This will be a user visible change.  It's not clear to me why it's
> needed - it seems like it's a hack to push users to do an update in the
> case where they want to use channel 1 stream 1?

Though it looks like 256 value is forced, but actually the user sees 
whatever value is set before. The 256 value storage is linked to byte 
mask value.

I must admit that this is not easily readable. If you suggest to 
simplify this, I can check if storage space increase for byte map value 
can make it more readable. Thanks for your feedback.








  reply	other threads:[~2023-06-23  5:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22 11:34 [PATCH 0/8] Few audio fixes on Tegra platforms Sameer Pujar
2023-06-22 11:34 ` [PATCH 1/8] ASoC: tegra: Fix SFC conversion for few rates Sameer Pujar
2023-06-22 11:34 ` [PATCH 2/8] ASoC: tegra: Fix AMX byte map Sameer Pujar
2023-06-22 12:07   ` Mark Brown
2023-06-23  5:39     ` Sameer Pujar [this message]
2023-06-23 10:15       ` Mark Brown
2023-06-26  9:41         ` Sameer Pujar
2023-06-22 11:34 ` [PATCH 3/8] ASoC: tegra: Fix ADX " Sameer Pujar
2023-06-22 11:34 ` [PATCH 4/8] ASoC: rt5640: Fix sleep in atomic context Sameer Pujar
2023-06-22 12:12   ` Mark Brown
2023-06-23  4:54     ` Sameer Pujar
2023-06-22 11:34 ` [PATCH 5/8] ASoC: tegra: Use normal system sleep for ASRC Sameer Pujar
2023-06-22 11:34 ` [PATCH 6/8] ASoC: tegra: Remove stale comments in AHUB Sameer Pujar
2023-06-22 11:34 ` [PATCH 7/8] arm64: tegra: Update AHUB clock parent and rate on Tegra234 Sameer Pujar
2023-06-22 12:13   ` Mark Brown
2023-06-23  4:51     ` Sameer Pujar
2023-06-22 11:34 ` [PATCH 8/8] arm64: tegra: Update AHUB clock parent and rate Sameer Pujar
2023-06-22 22:33 ` (subset) [PATCH 0/8] Few audio fixes on Tegra platforms Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7893c366-e6aa-d606-c3d6-e85f73a345e0@nvidia.com \
    --to=spujar@nvidia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=krzk+dt@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mkumard@nvidia.com \
    --cc=perex@perex.cz \
    --cc=robh+dt@kernel.org \
    --cc=sheetal@nvidia.com \
    --cc=stable@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox