All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Cc: "Alexander.Deucher@amd.com" <Alexander.Deucher@amd.com>,
	alsa-devel@alsa-project.org,
	Sergei Miroshnichenko <s.miroshnichenko@yadro.com>,
	"Christian.Koenig@amd.com" <Christian.Koenig@amd.com>
Subject: Re: Adding movable PCIe BARs support in snd_hda_intel
Date: Tue, 23 Mar 2021 12:39:07 +0100	[thread overview]
Message-ID: <s5hwntyaylg.wl-tiwai@suse.de> (raw)
In-Reply-To: <fe61113f-5b8e-53a0-23fc-65246eb08ac3@amd.com>

On Tue, 23 Mar 2021 12:23:16 +0100,
Andrey Grodzovsky wrote:
> 
> Just an update, i found the issue which was actually to wake up the HW
> before doing stop/restart (using pm_runtime_get_sync), also handled
> protecting from concurrent snd_pcm_ioctls accessing the registers
> while the BAR is unmapped. Can go through BAR move while aplay is
> running now.
> 
> Once again, would be happy for any comments on the code - 
> https://cgit.freedesktop.org/~agrodzov/linux/log/?h=yadro/pcie_hotplug/movable_bars_v9.1 

Hrm, this kind of change is a bit scary; we have some mechanism to
stop the HD-audio hardware operation (e.g. for loading the DSP for
CA0132 codec), but it's pretty hackish and error-prone.

Do we really need the BAR remap while operating the sound streaming?
That is, can't we simply refuse the remap if it's in operation?
If it can be refused, we may avoid a big locking or such.


thanks,

Takashi

> 
> 
> Andrey
> 
> On 2021-03-19 5:22 p.m., Andrey Grodzovsky wrote:
> > Hi, I am working on adding AMD related drivers support for PCIe BARs
> > move feature developed by Sergei
> > (https://linuxplumbersconf.org/event/7/contributions/847/attachments/584/1035/lpc2020_sergmir.pdf). 
> >
> > His feature is still not upstream, all his code and mine on top can
> > be seen here - 
> > https://cgit.freedesktop.org/~agrodzov/linux/log/?h=yadro/pcie_hotplug/movable_bars_v9.1 
> >
> > I did basic implementation fro amdgpu driver and now I am doing the
> > same for snd_hda_intel to support our on GPU Azalia audio
> > chips. This relevant commit is here - 
> > https://cgit.freedesktop.org/~agrodzov/linux/commit/?h=yadro/pcie_hotplug/movable_bars_v9.1&id=7ec0f60633e898cb941cebb3cd18aae1374fc365 
> >
> > Any driver that wants to support movable BARs needs to implement
> > rescan_prepare, rescan_done and bar_fixed callbacks where
> > rescan_prepare needs to stop HW/SW and unamp all MMIO mappings and
> > rescan_done needs to ioremap the BAR from it's new MMIO location and
> > restart HW/SW.
> >
> > I am able currently to trigger BARs move by sysfs using
> > "/sys/bus/pci/rescan" and the driver will go through the sequence I
> > described above without hangs. Problem is that after this when i try
> > to use mplayer I am getting following errors:
> >
> > andrey@andrey-test:~$ sudo mplayer -ao alsa:device=hw=0.3
> > Downloads/file_example_MP3_5MG.mp3
> > MPlayer 1.3.0 (Debian), built with gcc-9 (C) 2000-2016 MPlayer Team
> > do_connect: could not connect to socket
> > connect: No such file or directory
> > Failed to open LIRC support. You will not be able to use your remote
> > control.
> >
> > Playing Downloads/file_example_MP3_5MG.mp3.
> > libavformat version 58.29.100 (external)
> > Audio only file format detected.
> > Load subtitles in Downloads/
> > ==========================================================================
> > Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III
> > AUDIO: 44100 Hz, 2 ch, s16le, 320.0 kbit/22.68% (ratio: 40000->176400)
> > Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers
> > I, II, III)
> > ==========================================================================
> > AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
> > Video: no video
> > Starting playback...
> > A:   0.1 (00.0) of 132.0 (02:12.0) ??,?%
> > Audio device got stuck!
> >
> > and in dmesg I see
> > [  365.355518] snd_hda_codec_hdmi hdaudioC0D0: Unable to sync
> > register 0x2f0d00. -5
> >
> > Also I see 296.619014] snd_hda_intel 0000:0a:00.1: CORB reset
> > timeout#2, CORBRP = 65535 error during the rescan_done callback
> > execution
> >
> > I know it has to do with the move of BAR's MMIO address because when i
> > disallow BAR migration by returning true from bar_fixed callback I
> > have no such errors and mplayer works fine.
> >
> > I enabled MMIO trace and didn't see that post BAR move there is a
> > wrong MMIO access - all of them are from the new MMIO base offset -
> > 0xfcd80000 (trace attached including mmio trace and dmesg)
> >
> > I would be happy for any idea on this and any comment on the
> > correctness of my sequence in the code
> >
> > Andrey
> 

  reply	other threads:[~2021-03-23 11:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 21:22 Adding movable PCIe BARs support in snd_hda_intel Andrey Grodzovsky
2021-03-23 11:23 ` Andrey Grodzovsky
2021-03-23 11:39   ` Takashi Iwai [this message]
2021-03-23 14:22     ` Andrey Grodzovsky
2021-03-23 14:54       ` Takashi Iwai
2021-03-23 16:11         ` Andrey Grodzovsky
2021-03-23 16:50           ` Takashi Iwai
2021-03-23 17:08             ` Andrey Grodzovsky
2021-03-23 17:29               ` Takashi Iwai
2021-03-23 18:25                 ` Andrey Grodzovsky
2021-03-24 10:00                   ` Takashi Iwai
2021-03-24 14:53                     ` Andrey Grodzovsky
2021-03-24 15:06                       ` Takashi Iwai
2021-03-24 15:43                         ` Andrey Grodzovsky
2021-03-24 20:36                           ` Takashi Iwai
2021-03-24 21:43                             ` Andrey Grodzovsky
2021-03-25  6:58                               ` Takashi Iwai
2021-03-25 16:13                                 ` Andrey Grodzovsky
2021-03-25 16:38                                   ` Takashi Iwai
2021-03-26 21:27                                     ` Andrey Grodzovsky
2021-03-27  8:17                                       ` Takashi Iwai
2021-03-29 14:47                                         ` Andrey Grodzovsky
2021-03-29 14:52                                           ` Takashi Iwai
2021-03-29 14:57                                             ` Andrey Grodzovsky
2021-03-24 23:36                             ` [PATCH v2 1/8] ALSA: hda: Re-add dropped snd_poewr_change_state() kernel test robot
2021-03-24 23:36                               ` kernel test robot
2021-03-24 23:57                             ` kernel test robot
2021-03-24 23:57                               ` kernel test robot

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=s5hwntyaylg.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=Alexander.Deucher@amd.com \
    --cc=Christian.Koenig@amd.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andrey.grodzovsky@amd.com \
    --cc=s.miroshnichenko@yadro.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.