On Mon, Jul 06, 2020 at 04:02:57PM -0700, Dan Williams wrote:
> On Thu, Jul 2, 2020 at 6:44 AM Ranjani Sridharan
> wrote:
> [..]
> > > > Hi Jason,
> > > >
> > > > We're addressing the naming in the next version as well. We've had
> > > > several people reject the name virtual bus and we've narrowe
On Thu, Jul 2, 2020 at 6:44 AM Ranjani Sridharan
wrote:
[..]
> > > Hi Jason,
> > >
> > > We're addressing the naming in the next version as well. We've had
> > > several people reject the name virtual bus and we've narrowed in on
> > > "ancillary bus" for the new name suggesting that we have the c
On Wed, 2020-07-01 at 08:59 +0200, Greg KH wrote:
> On Tue, Jun 30, 2020 at 10:24:04AM -0700, Ranjani Sridharan wrote:
> > On Tue, 2020-06-30 at 08:32 -0300, Jason Gunthorpe wrote:
> > > On Tue, Jun 30, 2020 at 11:31:41AM +0100, Mark Brown wrote:
> > > > On Mon, Jun 29, 2020 at 07:59:59PM -0300, Ja
On Thu, Jul 02, 2020 at 09:11:47AM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 02, 2020 at 12:15:22PM +0100, Mark Brown wrote:
> > These are very much physical devices often with distinct IPs in distinct
> > address ranges and so on, it's just that those addresses happen not to
> > be on buses it
On Thu, Jul 02, 2020 at 12:15:22PM +0100, Mark Brown wrote:
> On Wed, Jul 01, 2020 at 08:32:50PM -0300, Jason Gunthorpe wrote:
> > On Wed, Jul 01, 2020 at 10:50:49AM +0100, Mark Brown wrote:
>
> > > Another part of this is that there's not a clean cut over between MMIO
> > > and not using any hard
On Wed, Jul 01, 2020 at 08:32:50PM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 01, 2020 at 10:50:49AM +0100, Mark Brown wrote:
> > Another part of this is that there's not a clean cut over between MMIO
> > and not using any hardware resources at all - for example a device might
> > be connected ov
On Wed, Jul 01, 2020 at 10:50:49AM +0100, Mark Brown wrote:
> On Tue, Jun 30, 2020 at 02:27:10PM -0300, Jason Gunthorpe wrote:
>
> > I wonder if SW_MFD might me more apt though? Based on Mark's remarks
> > current MFD is 'hw' MFD where the created platform_devices expect a
> > MMIO pass through, w
On Tue, Jun 30, 2020 at 02:27:10PM -0300, Jason Gunthorpe wrote:
> I wonder if SW_MFD might me more apt though? Based on Mark's remarks
> current MFD is 'hw' MFD where the created platform_devices expect a
> MMIO pass through, while this is a MFD a device-specific SW
> interfacing layer.
Another
On Tue, Jun 30, 2020 at 10:24:04AM -0700, Ranjani Sridharan wrote:
> On Tue, 2020-06-30 at 08:32 -0300, Jason Gunthorpe wrote:
> > On Tue, Jun 30, 2020 at 11:31:41AM +0100, Mark Brown wrote:
> > > On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote:
> > > > On Mon, Jun 29, 2020 at 09:33
On Tue, Jun 30, 2020 at 10:24:04AM -0700, Ranjani Sridharan wrote:
> On Tue, 2020-06-30 at 08:32 -0300, Jason Gunthorpe wrote:
> > On Tue, Jun 30, 2020 at 11:31:41AM +0100, Mark Brown wrote:
> > > On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote:
> > > > On Mon, Jun 29, 2020 at 09:33
On Tue, 2020-06-30 at 08:32 -0300, Jason Gunthorpe wrote:
> On Tue, Jun 30, 2020 at 11:31:41AM +0100, Mark Brown wrote:
> > On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote:
> > > On Mon, Jun 29, 2020 at 09:33:17PM +0100, Mark Brown wrote:
> > > > On Wed, May 27, 2020 at 09:17:33AM +
On Tue, Jun 30, 2020 at 08:32:45AM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 30, 2020 at 11:31:41AM +0100, Mark Brown wrote:
> > On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote:
> > > > What are we supposed to do with things like PCI attached FPGAs and ASICs
> > > > in that case?
On Tue, Jun 30, 2020 at 11:31:41AM +0100, Mark Brown wrote:
> On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote:
> > On Mon, Jun 29, 2020 at 09:33:17PM +0100, Mark Brown wrote:
> > > On Wed, May 27, 2020 at 09:17:33AM +0200, Greg KH wrote:
>
> > > > Ok, that's good to hear. But plat
On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote:
> On Mon, Jun 29, 2020 at 09:33:17PM +0100, Mark Brown wrote:
> > On Wed, May 27, 2020 at 09:17:33AM +0200, Greg KH wrote:
> > > Ok, that's good to hear. But platform devices should never be showing
> > > up as a child of a PCI devi
-r...@vger.kernel.org; nhor...@redhat.com; sassm...@redhat.com;
> Fred Oh
> Subject: Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF
> client
>
> On Mon, Jun 29, 2020 at 09:33:17PM +0100, Mark Brown wrote:
> > On Wed, May 27, 2020 at 09:17:33AM +0200, Greg KH wrote:
On Mon, Jun 29, 2020 at 09:33:17PM +0100, Mark Brown wrote:
> On Wed, May 27, 2020 at 09:17:33AM +0200, Greg KH wrote:
>
> > Ok, that's good to hear. But platform devices should never be showing
> > up as a child of a PCI device. In the "near future" when we get the
> > virtual bus code merged,
On Wed, May 20, 2020 at 12:02:25AM -0700, Jeff Kirsher wrote:
> From: Ranjani Sridharan
>
> A client in the SOF (Sound Open Firmware) context is a
> device that needs to communicate with the DSP via IPC
As please send patches to the maintainers for the code you would like to
change. :(
> +conf
On Fri, May 22, 2020 at 10:33:20AM -0500, Pierre-Louis Bossart wrote:
> On 5/22/20 9:55 AM, Jason Gunthorpe wrote:
> > Maybe not great, but at least it is consistent with all the lifetime
> > models and the operation of the driver core.
> I agree your comments are valid ones, I just don't have a
On Wed, May 27, 2020 at 09:17:33AM +0200, Greg KH wrote:
> Ok, that's good to hear. But platform devices should never be showing
> up as a child of a PCI device. In the "near future" when we get the
> virtual bus code merged, we can convert any existing users like this to
> the new code.
What a
On Sat, May 23, 2020 at 08:23:51AM +0200, Greg KH wrote:
> Then fix that problem there. The audio card should not be being created
> as a platform device, as that is not what it is. And even if it was,
> the probe should not complete, it should clean up after itself and error
> out.
To be clear
If yes, that's yet another problem... During the PCI probe, we start a
workqueue and return success to avoid blocking everything.
That's crazy.
And only 'later' do we actually create the card. So that's two levels
of probe that cannot report a failure. I didn't come up with this
design, II
On Tue, May 26, 2020 at 03:37:36PM +0200, Takashi Iwai wrote:
> On Tue, 26 May 2020 15:15:26 +0200,
> Pierre-Louis Bossart wrote:
> >
> >
> >
> > On 5/24/20 1:35 AM, Greg KH wrote:
> > > On Sat, May 23, 2020 at 02:41:51PM -0500, Pierre-Louis Bossart wrote:
> > >>
> > >>
> > >> On 5/23/20 1:23 AM
On Tue, 26 May 2020 15:15:26 +0200,
Pierre-Louis Bossart wrote:
>
>
>
> On 5/24/20 1:35 AM, Greg KH wrote:
> > On Sat, May 23, 2020 at 02:41:51PM -0500, Pierre-Louis Bossart wrote:
> >>
> >>
> >> On 5/23/20 1:23 AM, Greg KH wrote:
> >>> On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Boss
On 5/24/20 1:35 AM, Greg KH wrote:
On Sat, May 23, 2020 at 02:41:51PM -0500, Pierre-Louis Bossart wrote:
On 5/23/20 1:23 AM, Greg KH wrote:
On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote:
This is not an hypothetical case, we've had this recurring problem when a
PCI d
On Sat, May 23, 2020 at 02:41:51PM -0500, Pierre-Louis Bossart wrote:
> If yes, that's yet another problem... During the PCI probe, we start a
> workqueue and return success to avoid blocking everything. And only 'later'
> do we actually create the card. So that's two levels of probe that cannot
>
On Sat, May 23, 2020 at 02:41:51PM -0500, Pierre-Louis Bossart wrote:
>
>
> On 5/23/20 1:23 AM, Greg KH wrote:
> > On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote:
> > > This is not an hypothetical case, we've had this recurring problem when a
> > > PCI device creates an audi
On 5/23/20 1:23 AM, Greg KH wrote:
On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote:
This is not an hypothetical case, we've had this recurring problem when a
PCI device creates an audio card represented as a platform device. When the
card registration fails, typically due
On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote:
> This is not an hypothetical case, we've had this recurring problem when a
> PCI device creates an audio card represented as a platform device. When the
> card registration fails, typically due to configuration issues, the PCI
>
Maybe if you can present some diagram or something, because I really
can't understand why asoc is trying to do with virtual bus here.
instead of having a 1:1 mapping between PCI device and a monolithic
card, we want to split the sound card in multiple orthogonal parts such as:
PCI device
On Fri, May 22, 2020 at 01:48:00PM -0500, Pierre-Louis Bossart wrote:
>
>
> On 5/22/20 1:40 PM, Jason Gunthorpe wrote:
> > On Fri, May 22, 2020 at 01:35:54PM -0500, Pierre-Louis Bossart wrote:
> > >
> > >
> > > On 5/22/20 12:10 PM, Jason Gunthorpe wrote:
> > > > On Fri, May 22, 2020 at 10:33:20
On 5/22/20 1:40 PM, Jason Gunthorpe wrote:
On Fri, May 22, 2020 at 01:35:54PM -0500, Pierre-Louis Bossart wrote:
On 5/22/20 12:10 PM, Jason Gunthorpe wrote:
On Fri, May 22, 2020 at 10:33:20AM -0500, Pierre-Louis Bossart wrote:
Maybe not great, but at least it is consistent with all the l
On Fri, May 22, 2020 at 01:35:54PM -0500, Pierre-Louis Bossart wrote:
>
>
> On 5/22/20 12:10 PM, Jason Gunthorpe wrote:
> > On Fri, May 22, 2020 at 10:33:20AM -0500, Pierre-Louis Bossart wrote:
> >
> > > > Maybe not great, but at least it is consistent with all the lifetime
> > > > models and th
On 5/22/20 12:10 PM, Jason Gunthorpe wrote:
On Fri, May 22, 2020 at 10:33:20AM -0500, Pierre-Louis Bossart wrote:
Maybe not great, but at least it is consistent with all the lifetime
models and the operation of the driver core.
I agree your comments are valid ones, I just don't have a solu
On Fri, May 22, 2020 at 10:33:20AM -0500, Pierre-Louis Bossart wrote:
> > Maybe not great, but at least it is consistent with all the lifetime
> > models and the operation of the driver core.
>
> I agree your comments are valid ones, I just don't have a solution to be
> fully compliant with these
On 5/22/20 9:55 AM, Jason Gunthorpe wrote:
On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote:
+ ret = virtbus_register_device(vdev);
+ if (ret < 0)
+ return ret;
+
+ /* make sure the probe is complete before updating client list
*/
+
On Fri, May 22, 2020 at 09:29:57AM -0500, Pierre-Louis Bossart wrote:
>
> > > > > + ret = virtbus_register_device(vdev);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > > > +
> > > > > + /* make sure the probe is complete before updating client list
> > > > > */
> >
+ ret = virtbus_register_device(vdev);
+ if (ret < 0)
+ return ret;
+
+ /* make sure the probe is complete before updating client list
*/
+ timeout = msecs_to_jiffies(SOF_CLIENT_PROBE_TIMEOUT_MS);
+ time = wait_for_completion_timeout(&cdev->probe_comp
On Thu, May 21, 2020 at 02:11:37PM -0700, Ranjani Sridharan wrote:
> On Wed, 2020-05-20 at 09:54 -0300, Jason Gunthorpe wrote:
> > On Wed, May 20, 2020 at 12:02:25AM -0700, Jeff Kirsher wrote:
> > > From: Ranjani Sridharan
> > >
> > > A client in the SOF (Sound Open Firmware) context is a
> > > d
On Wed, 2020-05-20 at 09:54 -0300, Jason Gunthorpe wrote:
> On Wed, May 20, 2020 at 12:02:25AM -0700, Jeff Kirsher wrote:
> > From: Ranjani Sridharan
> >
> > A client in the SOF (Sound Open Firmware) context is a
> > device that needs to communicate with the DSP via IPC
> > messages. The SOF core
On Wed, May 20, 2020 at 09:54:37AM -0300, Jason Gunthorpe wrote:
> > + if (!time) {
> > + dev_err(sdev->dev, "error: probe of virtbus dev %s timed out\n",
> > + name);
> > + virtbus_unregister_device(vdev);
>
> Unregister does kfree? In general I've found th
On Wed, May 20, 2020 at 12:02:25AM -0700, Jeff Kirsher wrote:
> From: Ranjani Sridharan
>
> A client in the SOF (Sound Open Firmware) context is a
> device that needs to communicate with the DSP via IPC
> messages. The SOF core is responsible for serializing the
> IPC messages to the DSP from the
On Wed, May 20, 2020 at 12:02:25AM -0700, Jeff Kirsher wrote:
> From: Ranjani Sridharan
>
> A client in the SOF (Sound Open Firmware) context is a
> device that needs to communicate with the DSP via IPC
> messages. The SOF core is responsible for serializing the
> IPC messages to the DSP from the
From: Ranjani Sridharan
A client in the SOF (Sound Open Firmware) context is a
device that needs to communicate with the DSP via IPC
messages. The SOF core is responsible for serializing the
IPC messages to the DSP from the different clients. One
example of an SOF client would be an IPC test clie
43 matches
Mail list logo
