qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* sysbus usb xhci
@ 2020-01-02  7:13 Sai Pavan Boddu
  2020-01-02  9:45 ` kraxel
  0 siblings, 1 reply; 7+ messages in thread
From: Sai Pavan Boddu @ 2020-01-02  7:13 UTC (permalink / raw)
  To: kraxel, peter.maydell; +Cc: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

Hi Gred,

We are seeing of options to reuse the hcd-xhci model and use it over system bus interface rather than pci. (for Xilinx ZynqMP SOC, usb emulation)
Are there any plans of implementing a sysbus device ? if none it would be good if provided few pointers to start.

Im looking at hcd-ehci/ochi as a reference, let me know if there are any know limitations for this usecase.

Thanks & Regards,
Sai Pavan


[-- Attachment #2: Type: text/html, Size: 2421 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sysbus usb xhci
  2020-01-02  7:13 sysbus usb xhci Sai Pavan Boddu
@ 2020-01-02  9:45 ` kraxel
  2020-01-02 11:26   ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 7+ messages in thread
From: kraxel @ 2020-01-02  9:45 UTC (permalink / raw)
  To: Sai Pavan Boddu; +Cc: peter.maydell, qemu-devel

On Thu, Jan 02, 2020 at 07:13:25AM +0000, Sai Pavan Boddu wrote:
> Hi Gred,
> 
> We are seeing of options to reuse the hcd-xhci model and use it over system bus interface rather than pci. (for Xilinx ZynqMP SOC, usb emulation)
> Are there any plans of implementing a sysbus device ? if none it would be good if provided few pointers to start.

There have been some discussions about this for a (IIRC) sbsa machine,
but I'm not sure whenever that where just ideas or some code exists.

> Im looking at hcd-ehci/ochi as a reference, let me know if there are any know limitations for this usecase.

Yep, the path for xhci would be quite simliar:  Create a new
XHCIPciState struct, move over all pci-specific bits from XHCIState,
leaving the generic stuff in XHCIState for sharing with sysbus.
Possibly move all pci-specific code bits into a new source file (for
cleanup, will also allow to build qemu with CONFIG_PCI=n and still have
XHCI enabled).

Once this separation is done you should be able to create a sysbus
device, reusing the generic xhci code and adding sysbus plumbing
(mmio, irq, ...)

cheers,
  Gerd



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sysbus usb xhci
  2020-01-02  9:45 ` kraxel
@ 2020-01-02 11:26   ` Philippe Mathieu-Daudé
  2020-01-03  5:14     ` Sai Pavan Boddu
  0 siblings, 1 reply; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-01-02 11:26 UTC (permalink / raw)
  To: kraxel, Sai Pavan Boddu; +Cc: peter.maydell, qemu-devel

On 1/2/20 10:45 AM, kraxel@redhat.com wrote:
> On Thu, Jan 02, 2020 at 07:13:25AM +0000, Sai Pavan Boddu wrote:
>> Hi Gred,
>>
>> We are seeing of options to reuse the hcd-xhci model and use it over system bus interface rather than pci. (for Xilinx ZynqMP SOC, usb emulation)
>> Are there any plans of implementing a sysbus device ? if none it would be good if provided few pointers to start.
> 
> There have been some discussions about this for a (IIRC) sbsa machine,
> but I'm not sure whenever that where just ideas or some code exists.
> 
>> Im looking at hcd-ehci/ochi as a reference, let me know if there are any know limitations for this usecase.
> 
> Yep, the path for xhci would be quite simliar:  Create a new
> XHCIPciState struct, move over all pci-specific bits from XHCIState,
> leaving the generic stuff in XHCIState for sharing with sysbus.
> Possibly move all pci-specific code bits into a new source file (for
> cleanup, will also allow to build qemu with CONFIG_PCI=n and still have
> XHCI enabled).
> 
> Once this separation is done you should be able to create a sysbus
> device, reusing the generic xhci code and adding sysbus plumbing
> (mmio, irq, ...)

The SDHCI commits b635d98cf32..8b7455c75e seem similar to what you want 
to achieve (see also commit ce8646034).



^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: sysbus usb xhci
  2020-01-02 11:26   ` Philippe Mathieu-Daudé
@ 2020-01-03  5:14     ` Sai Pavan Boddu
  2020-01-08 15:32       ` Sai Pavan Boddu
  0 siblings, 1 reply; 7+ messages in thread
From: Sai Pavan Boddu @ 2020-01-03  5:14 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, kraxel; +Cc: peter.maydell, qemu-devel

Thanks Philippe & Gred. I would start with the below pointers.

Regards,
Sai Pavan

> -----Original Message-----
> From: Philippe Mathieu-Daudé <philmd@redhat.com>
> Sent: Thursday, January 2, 2020 4:56 PM
> To: kraxel@redhat.com; Sai Pavan Boddu <saipava@xilinx.com>
> Cc: peter.maydell@linaro.org; qemu-devel@nongnu.org
> Subject: Re: sysbus usb xhci
> 
> On 1/2/20 10:45 AM, kraxel@redhat.com wrote:
> > On Thu, Jan 02, 2020 at 07:13:25AM +0000, Sai Pavan Boddu wrote:
> >> Hi Gred,
> >>
> >> We are seeing of options to reuse the hcd-xhci model and use it over
> >> system bus interface rather than pci. (for Xilinx ZynqMP SOC, usb
> emulation) Are there any plans of implementing a sysbus device ? if none it
> would be good if provided few pointers to start.
> >
> > There have been some discussions about this for a (IIRC) sbsa machine,
> > but I'm not sure whenever that where just ideas or some code exists.
> >
> >> Im looking at hcd-ehci/ochi as a reference, let me know if there are any
> know limitations for this usecase.
> >
> > Yep, the path for xhci would be quite simliar:  Create a new
> > XHCIPciState struct, move over all pci-specific bits from XHCIState,
> > leaving the generic stuff in XHCIState for sharing with sysbus.
> > Possibly move all pci-specific code bits into a new source file (for
> > cleanup, will also allow to build qemu with CONFIG_PCI=n and still
> > have XHCI enabled).
> >
> > Once this separation is done you should be able to create a sysbus
> > device, reusing the generic xhci code and adding sysbus plumbing
> > (mmio, irq, ...)
> 
> The SDHCI commits b635d98cf32..8b7455c75e seem similar to what you
> want to achieve (see also commit ce8646034).


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: sysbus usb xhci
  2020-01-03  5:14     ` Sai Pavan Boddu
@ 2020-01-08 15:32       ` Sai Pavan Boddu
  2020-01-08 15:51         ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 7+ messages in thread
From: Sai Pavan Boddu @ 2020-01-08 15:32 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, kraxel; +Cc: peter.maydell, qemu-devel

Hi Gred/Philippe,

In the process of making hcd-xhci.c free of pci wrapper, I came across a dma command " ldq_le_pci_dma" for which I don’t see any low level alternative to replace.
Even I cannot find the source of it, do you have any thoughts on this ?

Regards,
Sai Pavan

> -----Original Message-----
> From: Sai Pavan Boddu
> Sent: Friday, January 3, 2020 10:44 AM
> To: Philippe Mathieu-Daudé <philmd@redhat.com>; kraxel@redhat.com
> Cc: peter.maydell@linaro.org; qemu-devel@nongnu.org
> Subject: RE: sysbus usb xhci
> 
> Thanks Philippe & Gred. I would start with the below pointers.
> 
> Regards,
> Sai Pavan
> 
> > -----Original Message-----
> > From: Philippe Mathieu-Daudé <philmd@redhat.com>
> > Sent: Thursday, January 2, 2020 4:56 PM
> > To: kraxel@redhat.com; Sai Pavan Boddu <saipava@xilinx.com>
> > Cc: peter.maydell@linaro.org; qemu-devel@nongnu.org
> > Subject: Re: sysbus usb xhci
> >
> > On 1/2/20 10:45 AM, kraxel@redhat.com wrote:
> > > On Thu, Jan 02, 2020 at 07:13:25AM +0000, Sai Pavan Boddu wrote:
> > >> Hi Gred,
> > >>
> > >> We are seeing of options to reuse the hcd-xhci model and use it
> > >> over system bus interface rather than pci. (for Xilinx ZynqMP SOC,
> > >> usb
> > emulation) Are there any plans of implementing a sysbus device ? if
> > none it would be good if provided few pointers to start.
> > >
> > > There have been some discussions about this for a (IIRC) sbsa
> > > machine, but I'm not sure whenever that where just ideas or some code
> exists.
> > >
> > >> Im looking at hcd-ehci/ochi as a reference, let me know if there
> > >> are any
> > know limitations for this usecase.
> > >
> > > Yep, the path for xhci would be quite simliar:  Create a new
> > > XHCIPciState struct, move over all pci-specific bits from XHCIState,
> > > leaving the generic stuff in XHCIState for sharing with sysbus.
> > > Possibly move all pci-specific code bits into a new source file (for
> > > cleanup, will also allow to build qemu with CONFIG_PCI=n and still
> > > have XHCI enabled).
> > >
> > > Once this separation is done you should be able to create a sysbus
> > > device, reusing the generic xhci code and adding sysbus plumbing
> > > (mmio, irq, ...)
> >
> > The SDHCI commits b635d98cf32..8b7455c75e seem similar to what you
> > want to achieve (see also commit ce8646034).


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sysbus usb xhci
  2020-01-08 15:32       ` Sai Pavan Boddu
@ 2020-01-08 15:51         ` Philippe Mathieu-Daudé
  2020-01-17 15:46           ` Sai Pavan Boddu
  0 siblings, 1 reply; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-01-08 15:51 UTC (permalink / raw)
  To: Sai Pavan Boddu, kraxel; +Cc: peter.maydell, qemu-devel

On 1/8/20 4:32 PM, Sai Pavan Boddu wrote:
> Hi Gred/Philippe,
> 
> In the process of making hcd-xhci.c free of pci wrapper, I came across a dma command " ldq_le_pci_dma" for which I don’t see any low level alternative to replace.
> Even I cannot find the source of it, do you have any thoughts on this ?

Isn't it ldq_le_phys()?

I think you want to extract the address space first in a common method. 
See in sdhci_pci_realize():

     s->dma_as = pci_get_address_space(dev);

And in sdhci_sysbus_realize():

     if (s->dma_mr) {
         s->dma_as = &s->sysbus_dma_as;
         address_space_init(s->dma_as, s->dma_mr, "sdhci-dma");
     } else {
         /* use system_memory() if property "dma" not set */
         s->dma_as = &address_space_memory;
     }

>> -----Original Message-----
>> From: Sai Pavan Boddu
>> Sent: Friday, January 3, 2020 10:44 AM
>> To: Philippe Mathieu-Daudé <philmd@redhat.com>; kraxel@redhat.com
>> Cc: peter.maydell@linaro.org; qemu-devel@nongnu.org
>> Subject: RE: sysbus usb xhci
>>
>> Thanks Philippe & Gred. I would start with the below pointers.
>>
>> Regards,
>> Sai Pavan
>>
>>> -----Original Message-----
>>> From: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> Sent: Thursday, January 2, 2020 4:56 PM
>>> To: kraxel@redhat.com; Sai Pavan Boddu <saipava@xilinx.com>
>>> Cc: peter.maydell@linaro.org; qemu-devel@nongnu.org
>>> Subject: Re: sysbus usb xhci
>>>
>>> On 1/2/20 10:45 AM, kraxel@redhat.com wrote:
>>>> On Thu, Jan 02, 2020 at 07:13:25AM +0000, Sai Pavan Boddu wrote:
>>>>> Hi Gred,
>>>>>
>>>>> We are seeing of options to reuse the hcd-xhci model and use it
>>>>> over system bus interface rather than pci. (for Xilinx ZynqMP SOC,
>>>>> usb
>>> emulation) Are there any plans of implementing a sysbus device ? if
>>> none it would be good if provided few pointers to start.
>>>>
>>>> There have been some discussions about this for a (IIRC) sbsa
>>>> machine, but I'm not sure whenever that where just ideas or some code
>> exists.
>>>>
>>>>> Im looking at hcd-ehci/ochi as a reference, let me know if there
>>>>> are any
>>> know limitations for this usecase.
>>>>
>>>> Yep, the path for xhci would be quite simliar:  Create a new
>>>> XHCIPciState struct, move over all pci-specific bits from XHCIState,
>>>> leaving the generic stuff in XHCIState for sharing with sysbus.
>>>> Possibly move all pci-specific code bits into a new source file (for
>>>> cleanup, will also allow to build qemu with CONFIG_PCI=n and still
>>>> have XHCI enabled).
>>>>
>>>> Once this separation is done you should be able to create a sysbus
>>>> device, reusing the generic xhci code and adding sysbus plumbing
>>>> (mmio, irq, ...)
>>>
>>> The SDHCI commits b635d98cf32..8b7455c75e seem similar to what you
>>> want to achieve (see also commit ce8646034).
> 



^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: sysbus usb xhci
  2020-01-08 15:51         ` Philippe Mathieu-Daudé
@ 2020-01-17 15:46           ` Sai Pavan Boddu
  0 siblings, 0 replies; 7+ messages in thread
From: Sai Pavan Boddu @ 2020-01-17 15:46 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, kraxel; +Cc: peter.maydell, qemu-devel

Hi Gred/Philippe,

@Philippe Mathieu-Daudé,  thanks I found the alternative "ldq_le_dma".

Moving forward, for testing the new model. I ran through qtest:usb-hcd-xhci-test.c, are there any other test which I need to consider as first level validation ?

Regards,
Sai Pavan

> -----Original Message-----
> From: Philippe Mathieu-Daudé <philmd@redhat.com>
> Sent: Wednesday, January 8, 2020 9:21 PM
> To: Sai Pavan Boddu <saipava@xilinx.com>; kraxel@redhat.com
> Cc: peter.maydell@linaro.org; qemu-devel@nongnu.org
> Subject: Re: sysbus usb xhci
> 
> On 1/8/20 4:32 PM, Sai Pavan Boddu wrote:
> > Hi Gred/Philippe,
> >
> > In the process of making hcd-xhci.c free of pci wrapper, I came across a
> dma command " ldq_le_pci_dma" for which I don’t see any low level
> alternative to replace.
> > Even I cannot find the source of it, do you have any thoughts on this ?
> 
> Isn't it ldq_le_phys()?
> 
> I think you want to extract the address space first in a common method.
> See in sdhci_pci_realize():
> 
>      s->dma_as = pci_get_address_space(dev);
> 
> And in sdhci_sysbus_realize():
> 
>      if (s->dma_mr) {
>          s->dma_as = &s->sysbus_dma_as;
>          address_space_init(s->dma_as, s->dma_mr, "sdhci-dma");
>      } else {
>          /* use system_memory() if property "dma" not set */
>          s->dma_as = &address_space_memory;
>      }
> 
> >> -----Original Message-----
> >> From: Sai Pavan Boddu
> >> Sent: Friday, January 3, 2020 10:44 AM
> >> To: Philippe Mathieu-Daudé <philmd@redhat.com>; kraxel@redhat.com
> >> Cc: peter.maydell@linaro.org; qemu-devel@nongnu.org
> >> Subject: RE: sysbus usb xhci
> >>
> >> Thanks Philippe & Gred. I would start with the below pointers.
> >>
> >> Regards,
> >> Sai Pavan
> >>
> >>> -----Original Message-----
> >>> From: Philippe Mathieu-Daudé <philmd@redhat.com>
> >>> Sent: Thursday, January 2, 2020 4:56 PM
> >>> To: kraxel@redhat.com; Sai Pavan Boddu <saipava@xilinx.com>
> >>> Cc: peter.maydell@linaro.org; qemu-devel@nongnu.org
> >>> Subject: Re: sysbus usb xhci
> >>>
> >>> On 1/2/20 10:45 AM, kraxel@redhat.com wrote:
> >>>> On Thu, Jan 02, 2020 at 07:13:25AM +0000, Sai Pavan Boddu wrote:
> >>>>> Hi Gred,
> >>>>>
> >>>>> We are seeing of options to reuse the hcd-xhci model and use it
> >>>>> over system bus interface rather than pci. (for Xilinx ZynqMP SOC,
> >>>>> usb
> >>> emulation) Are there any plans of implementing a sysbus device ? if
> >>> none it would be good if provided few pointers to start.
> >>>>
> >>>> There have been some discussions about this for a (IIRC) sbsa
> >>>> machine, but I'm not sure whenever that where just ideas or some
> >>>> code
> >> exists.
> >>>>
> >>>>> Im looking at hcd-ehci/ochi as a reference, let me know if there
> >>>>> are any
> >>> know limitations for this usecase.
> >>>>
> >>>> Yep, the path for xhci would be quite simliar:  Create a new
> >>>> XHCIPciState struct, move over all pci-specific bits from
> >>>> XHCIState, leaving the generic stuff in XHCIState for sharing with
> sysbus.
> >>>> Possibly move all pci-specific code bits into a new source file
> >>>> (for cleanup, will also allow to build qemu with CONFIG_PCI=n and
> >>>> still have XHCI enabled).
> >>>>
> >>>> Once this separation is done you should be able to create a sysbus
> >>>> device, reusing the generic xhci code and adding sysbus plumbing
> >>>> (mmio, irq, ...)
> >>>
> >>> The SDHCI commits b635d98cf32..8b7455c75e seem similar to what you
> >>> want to achieve (see also commit ce8646034).
> >


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-01-17 15:48 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-02  7:13 sysbus usb xhci Sai Pavan Boddu
2020-01-02  9:45 ` kraxel
2020-01-02 11:26   ` Philippe Mathieu-Daudé
2020-01-03  5:14     ` Sai Pavan Boddu
2020-01-08 15:32       ` Sai Pavan Boddu
2020-01-08 15:51         ` Philippe Mathieu-Daudé
2020-01-17 15:46           ` Sai Pavan Boddu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).