All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Pan Xiuli <xiuli.pan@linux.intel.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Evan Green <evgreen@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [alsa-devel] [PATCH] ASoC: SOF: Intel: work around snd_hdac_aligned_read link failure
Date: Tue, 10 Sep 2019 09:52:13 +0200	[thread overview]
Message-ID: <CAK8P3a2-gMbuN-17MC6ZsDwvPGCHmbJojKYGnrUshxhazATPRg@mail.gmail.com> (raw)
In-Reply-To: <s5hef0oaav5.wl-tiwai@suse.de>

On Tue, Sep 10, 2019 at 9:06 AM Takashi Iwai <tiwai@suse.de> wrote:
> On Mon, 09 Sep 2019 22:51:23 +0200, Arnd Bergmann wrote:
> >
> > On Mon, Sep 9, 2019 at 10:39 PM Pierre-Louis Bossart
> > <pierre-louis.bossart@linux.intel.com> wrote:
> > >
> > > On 9/9/19 2:51 PM, Arnd Bergmann wrote:
> > > > When CONFIG_SND_HDA_ALIGNED_MMIO is selected by another driver
> > > > (i.e. Tegra) that selects CONFIG_SND_HDA_CORE as a loadable
> > > > module, but SND_SOC_SOF_HDA_COMMON is built-in, we get a
> > > > link failure from some functions that access the hda register:
> > > >
> > > > sound/soc/sof/intel/hda.o: In function `hda_ipc_irq_dump':
> > > > hda.c:(.text+0x784): undefined reference to `snd_hdac_aligned_read'
> > > > sound/soc/sof/intel/hda-stream.o: In function `hda_dsp_stream_threaded_handler':
> > > > hda-stream.c:(.text+0x12e4): undefined reference to `snd_hdac_aligned_read'
> > > > hda-stream.c:(.text+0x12f8): undefined reference to `snd_hdac_aligned_write'
> > > >
> > > > Add an explicit 'select' statement as a workaround. This is
> > > > not a great solution, but it's the easiest way I could come
> > > > up with.
> > >
> > > Thanks for spotting this, I don't think anyone on the SOF team looked at
> > > this. Maybe we can filter with depends on !TEGRA or
> > > !SND_HDA_ALIGNED_MMIO at the SOF Intel top-level instead?
> >
> > That doesn't sound much better than my approach, but could also work.
> > One idea that I had but did not manage to implement was to move out
> > the snd_hdac_aligned_read/write functions from the core hda code
> > into a separate file. I think that would be the cleanest solution,
> > as it decouples the problem from any drivers.
>
> Yeah, that's a tricky problem because of the reverse-selection, as
> usual...
>
> Another solution would be to just avoid byte/word access but use only
> long access, i.e. replace snd_hdac_chip_readb() with
> snd_hdac_chip_readl() with the aligned register and bit shift.
> The aligned access helper is needed only for the register that isn't
> aligned with 4 bytes offset.

Ok, so basically open-coding the aligned access to RIRBSTS?
That sounds like a much nicer workaround. So in place of

                        sd_status = snd_hdac_stream_readb(s, SD_STS);
                        dev_vdbg(bus->dev, "stream %d status 0x%x\n",
                                 s->index, sd_status);
                        snd_hdac_stream_writeb(s, SD_STS, sd_status);

I suppose one could just readl/writel SOF_HDA_ADSP_REG_CL_SD_CTL
and print the shifted value, right?

While I know nothing about the underlying requirements, I wonder
about two things that stick out to me:

1. the existing code just writes back the same byte it has read. If
    this write has no side-effects, why write it at all? OTOH, if it has
    side-effects, isn't the aligned implementation of writing the whole
    word in snd_hdac_aligned_write()  fundamentally flawed?

2. Doesn't the read-modify-write cycle in snd_hdac_aligned_write()
   need locking to work correctly?

          Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Pan Xiuli <xiuli.pan@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Evan Green <evgreen@chromium.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [alsa-devel] [PATCH] ASoC: SOF: Intel: work around snd_hdac_aligned_read link failure
Date: Tue, 10 Sep 2019 09:52:13 +0200	[thread overview]
Message-ID: <CAK8P3a2-gMbuN-17MC6ZsDwvPGCHmbJojKYGnrUshxhazATPRg@mail.gmail.com> (raw)
In-Reply-To: <s5hef0oaav5.wl-tiwai@suse.de>

On Tue, Sep 10, 2019 at 9:06 AM Takashi Iwai <tiwai@suse.de> wrote:
> On Mon, 09 Sep 2019 22:51:23 +0200, Arnd Bergmann wrote:
> >
> > On Mon, Sep 9, 2019 at 10:39 PM Pierre-Louis Bossart
> > <pierre-louis.bossart@linux.intel.com> wrote:
> > >
> > > On 9/9/19 2:51 PM, Arnd Bergmann wrote:
> > > > When CONFIG_SND_HDA_ALIGNED_MMIO is selected by another driver
> > > > (i.e. Tegra) that selects CONFIG_SND_HDA_CORE as a loadable
> > > > module, but SND_SOC_SOF_HDA_COMMON is built-in, we get a
> > > > link failure from some functions that access the hda register:
> > > >
> > > > sound/soc/sof/intel/hda.o: In function `hda_ipc_irq_dump':
> > > > hda.c:(.text+0x784): undefined reference to `snd_hdac_aligned_read'
> > > > sound/soc/sof/intel/hda-stream.o: In function `hda_dsp_stream_threaded_handler':
> > > > hda-stream.c:(.text+0x12e4): undefined reference to `snd_hdac_aligned_read'
> > > > hda-stream.c:(.text+0x12f8): undefined reference to `snd_hdac_aligned_write'
> > > >
> > > > Add an explicit 'select' statement as a workaround. This is
> > > > not a great solution, but it's the easiest way I could come
> > > > up with.
> > >
> > > Thanks for spotting this, I don't think anyone on the SOF team looked at
> > > this. Maybe we can filter with depends on !TEGRA or
> > > !SND_HDA_ALIGNED_MMIO at the SOF Intel top-level instead?
> >
> > That doesn't sound much better than my approach, but could also work.
> > One idea that I had but did not manage to implement was to move out
> > the snd_hdac_aligned_read/write functions from the core hda code
> > into a separate file. I think that would be the cleanest solution,
> > as it decouples the problem from any drivers.
>
> Yeah, that's a tricky problem because of the reverse-selection, as
> usual...
>
> Another solution would be to just avoid byte/word access but use only
> long access, i.e. replace snd_hdac_chip_readb() with
> snd_hdac_chip_readl() with the aligned register and bit shift.
> The aligned access helper is needed only for the register that isn't
> aligned with 4 bytes offset.

Ok, so basically open-coding the aligned access to RIRBSTS?
That sounds like a much nicer workaround. So in place of

                        sd_status = snd_hdac_stream_readb(s, SD_STS);
                        dev_vdbg(bus->dev, "stream %d status 0x%x\n",
                                 s->index, sd_status);
                        snd_hdac_stream_writeb(s, SD_STS, sd_status);

I suppose one could just readl/writel SOF_HDA_ADSP_REG_CL_SD_CTL
and print the shifted value, right?

While I know nothing about the underlying requirements, I wonder
about two things that stick out to me:

1. the existing code just writes back the same byte it has read. If
    this write has no side-effects, why write it at all? OTOH, if it has
    side-effects, isn't the aligned implementation of writing the whole
    word in snd_hdac_aligned_write()  fundamentally flawed?

2. Doesn't the read-modify-write cycle in snd_hdac_aligned_write()
   need locking to work correctly?

          Arnd
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2019-09-10  7:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-09 19:51 [PATCH] ASoC: SOF: Intel: work around snd_hdac_aligned_read link failure Arnd Bergmann
2019-09-09 19:51 ` [alsa-devel] " Arnd Bergmann
2019-09-09 20:38 ` Pierre-Louis Bossart
2019-09-09 20:38   ` [alsa-devel] " Pierre-Louis Bossart
2019-09-09 20:51   ` Arnd Bergmann
2019-09-09 20:51     ` [alsa-devel] " Arnd Bergmann
2019-09-10  7:06     ` Takashi Iwai
2019-09-10  7:06       ` Takashi Iwai
2019-09-10  7:52       ` Arnd Bergmann [this message]
2019-09-10  7:52         ` Arnd Bergmann
2019-09-10  8:20         ` Takashi Iwai
2019-09-10  8:20           ` Takashi Iwai

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=CAK8P3a2-gMbuN-17MC6ZsDwvPGCHmbJojKYGnrUshxhazATPRg@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=evgreen@chromium.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.de \
    --cc=xiuli.pan@linux.intel.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 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.