On Thu, Sep 22, 2016 at 12:02 AM, Sriram Dash wrote:
>>From: Arnd Bergmann [mailto:a...@arndb.de]
>>On Wednesday, September 21, 2016 11:43:59 AM CEST Sriram Dash wrote:
>>> >From: Arnd Bergmann [mailto:a...@arndb.de] On Wednesday, September
>>> >21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>>>
>>>
>From: Arnd Bergmann [mailto:a...@arndb.de]
>On Wednesday, September 21, 2016 11:43:59 AM CEST Sriram Dash wrote:
>> >From: Arnd Bergmann [mailto:a...@arndb.de] On Wednesday, September
>> >21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>>
>> ===
>From: Arnd Bergmann [mailto:a...@arndb.de]
>On Wednesday, September 21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>>
>> Hello Arnd,
>>
>> We tried this patch on NXP platforms (ls2085 and ls1043) which use
>> dwc3 controller without any glue layer. On first go, this did not
>> work. But after minima
On Wednesday, September 21, 2016 11:43:59 AM CEST Sriram Dash wrote:
> >From: Arnd Bergmann [mailto:a...@arndb.de]
> >On Wednesday, September 21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>
> ==
> From 8b0dea1513e9e73a11dcfa802ddc71cca11d6
>From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org]
>On Wednesday, September 7, 2016 1:24:07 PM CEST Felipe Balbi wrote:
>>
>> Hi,
>>
>> Arnd Bergmann writes:
>>
>> [...]
>>
>> > Regarding the DMA configuration that you mention in
>> > ci_hdrc_add_device(), I think we s
On Wednesday, September 21, 2016 11:06:47 AM CEST Sriram Dash wrote:
>
> Hello Arnd,
>
> We tried this patch on NXP platforms (ls2085 and ls1043) which use dwc3
> controller without any glue layer. On first go, this did not work. But after
> minimal reworks mention snippet below, we are able to
On Wednesday, September 14, 2016 5:31:36 PM CEST Lorenzo Pieralisi wrote:
> On Wed, Sep 07, 2016 at 01:47:22PM +0300, Felipe Balbi wrote:
> >
> > Hi,
> >
> > Robin Murphy writes:
> > > On 07/09/16 10:55, Peter Chen wrote:
> > > [...]
> > >>> Regarding the DMA configuration that you mention in
>
On Wed, Sep 07, 2016 at 01:47:22PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Robin Murphy writes:
> > On 07/09/16 10:55, Peter Chen wrote:
> > [...]
> >>> Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
> >>> I think we should replace
> >>>
> >>> pdev->dev.dma_mas
On Thu, Sep 08, 2016 at 03:59:19PM +0300, Grygorii Strashko wrote:
> On 09/08/2016 03:28 PM, Peter Chen wrote:
> > On Thu, Sep 08, 2016 at 12:17:21PM +0200, Arnd Bergmann wrote:
> >> On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
> >>> Arnd Bergmann writes:
> On Thursday,
On Thu, Sep 08, 2016 at 02:52:29PM +0200, Arnd Bergmann wrote:
> On Thursday, September 8, 2016 8:28:10 PM CEST Peter Chen wrote:
> > On Thu, Sep 08, 2016 at 12:17:21PM +0200, Arnd Bergmann wrote:
> > > On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
> > > > Arnd Bergmann write
On 09/08/2016 03:28 PM, Peter Chen wrote:
> On Thu, Sep 08, 2016 at 12:17:21PM +0200, Arnd Bergmann wrote:
>> On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
>>> Arnd Bergmann writes:
On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi wrote:
>> If we do that,
On Thursday, September 8, 2016 8:28:10 PM CEST Peter Chen wrote:
> On Thu, Sep 08, 2016 at 12:17:21PM +0200, Arnd Bergmann wrote:
> > On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
> > > Arnd Bergmann writes:
> > > > On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi
On Thursday, September 8, 2016 2:52:46 PM CEST Felipe Balbi wrote:
> Arnd Bergmann writes:
> >> If we make dwc3.ko a library which glue calls directly then all these
> >> problems are solved but we break all current DTs and fall into the trap
> >> of having another MUSB.
> >
> > I don't see how we
On Thu, Sep 08, 2016 at 12:17:21PM +0200, Arnd Bergmann wrote:
> On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
> > Arnd Bergmann writes:
> > > On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi wrote:
> > >> > If we do that, we have to put child devices of the dwc3
On Thursday, September 8, 2016 3:02:56 PM CEST Grygorii Strashko wrote:
> dwc3: probe()
> if (!&pdev->dev->of_node)
> legacy case - hard-code DMA props
> dwc->sysdev = &pdev->dev;
The PCI case will fall into this too, as we almost never have an
->of_node po
On 09/08/2016 02:00 PM, Felipe Balbi wrote:
>
> Hi,
>
> Arnd Bergmann writes:
>> On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
>>> Arnd Bergmann writes:
On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi wrote:
>> If we do that, we have to put child devi
Hi,
Arnd Bergmann writes:
>> >> But this needs to be done before dwc3_probe() executes. For dwc3-pci
>> >> that's easy, but for DT devices, seems like it should be in of
>> >> core. Below is, clearly, not enough but should show the idea:
>> >>
>> >> diff --git a/drivers/of/device.c b/drivers/of
On Thursday, September 8, 2016 2:20:58 PM CEST Felipe Balbi wrote:
> >> It's quite a hack, though. I still think that inheriting DMA (or
> >> manually initializing a child with parent's DMA bits and pieces) is the
> >> best way to go. So we're back to of_dma_configure() and
> >> acpi_dma_configure(
Hi,
Arnd Bergmann writes:
> On Thursday, September 8, 2016 2:00:13 PM CEST Felipe Balbi wrote:
>> Arnd Bergmann writes:
>> > On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
>> >> Arnd Bergmann writes:
>> >> > That sounds a bit clumsy for the sake of consistency with PCI.
>>
On Thursday, September 8, 2016 2:00:13 PM CEST Felipe Balbi wrote:
> Arnd Bergmann writes:
> > On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
> >> Arnd Bergmann writes:
> >> > That sounds a bit clumsy for the sake of consistency with PCI.
> >> > The advantage is that xhci can
Hi,
Arnd Bergmann writes:
> On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
>> Arnd Bergmann writes:
>> > On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi wrote:
>> >> > If we do that, we have to put child devices of the dwc3 devices into
>> >> > the platform glu
On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote:
> Arnd Bergmann writes:
> > On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi wrote:
> >> > If we do that, we have to put child devices of the dwc3 devices into
> >> > the platform glue, and it also breaks those dwc3 de
Hi,
Arnd Bergmann writes:
> On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi wrote:
>> > If we do that, we have to put child devices of the dwc3 devices into
>> > the platform glue, and it also breaks those dwc3 devices that don't
>> > have a parent driver.
>>
>> Well, this is easy
On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi wrote:
> > If we do that, we have to put child devices of the dwc3 devices into
> > the platform glue, and it also breaks those dwc3 devices that don't
> > have a parent driver.
>
> Well, this is easy to fix:
>
> if (dwc->dev->p
Hi,
Arnd Bergmann writes:
>> > @@ -178,7 +179,7 @@ static void dwc3_frame_length_adjustment(struct dwc3
>> > *dwc)
>> > static void dwc3_free_one_event_buffer(struct dwc3 *dwc,
>> >struct dwc3_event_buffer *evt)
>> > {
>> > - dma_free_coherent(dwc->dev, evt->length, evt->buf, evt
On Thursday, September 8, 2016 11:03:10 AM CEST Felipe Balbi wrote:
> Arnd Bergmann writes:
> >> Arnd Bergmann writes:
> just look at the history of the file, you'll see that an Intel employee
> was a maintainer of chipidea driver. Also:
>
> $ git ls-files drivers/usb/chipidea/ | grep pci
> driv
Hi,
Arnd Bergmann writes:
>> Arnd Bergmann writes:
>>
>> [...]
>>
>> > Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
>> > I think we should replace
>> >
>> > pdev->dev.dma_mask = dev->dma_mask;
>> > pdev->dev.dma_parms = dev->dma_parms;
>> >
On Thursday, September 8, 2016 9:15:36 AM CEST Peter Chen wrote:
> >
> > Right, I was specifically talking about the code in chipidea here,
> > which I think is never used on the PCI bus, and how the current
> > code is broken. We can probably do better than of_dma_configure()
> > (see below), but
On Wed, Sep 07, 2016 at 05:24:08PM +0200, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 1:24:07 PM CEST Felipe Balbi wrote:
> >
> > Hi,
> >
> > Arnd Bergmann writes:
> >
> > [...]
> >
> > > Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
> > > I think we shou
On Wednesday, September 7, 2016 12:08:20 PM CEST Alan Stern wrote:
> On Wed, 7 Sep 2016, Arnd Bergmann wrote:
>
> > drivers/usb/host/ehci-fsl.c| 4 ++--
>
> How did this driver end up in the patch?
>
> > diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
> > index 9f5ffb6
On Wed, 7 Sep 2016, Arnd Bergmann wrote:
> However, to summarize the discussion so far, I agree that
> of_dma_configure() is not the solution to these problems, and I think
> we can do much better:
>
> Splitting the usb_bus->controller field into the Linux-internal device
> (used for the sysfs hi
On Wednesday, September 7, 2016 1:24:07 PM CEST Felipe Balbi wrote:
>
> Hi,
>
> Arnd Bergmann writes:
>
> [...]
>
> > Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
> > I think we should replace
> >
> > pdev->dev.dma_mask = dev->dma_mask;
> > pdev->d
On Wednesday, September 7, 2016 4:04:52 PM CEST Roger Quadros wrote:
> > The main use for it is to let you specify a MAC address for on-board
> > ethernet devices that lack an EPROM, but any other information can be
> > added that way too.
> >
> >> There is a bug in the USB core because of which
On 07/09/16 11:29, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 10:17:31 AM CEST Roger Quadros wrote:
>>>
>>> Speaking of that flag, I suppose we need the same logic to know where
>>> to look for USB devices attached to a dwc3 host when we need to describe
>>> them in DT. By default we lo
Hi,
Robin Murphy writes:
> On 07/09/16 10:55, Peter Chen wrote:
> [...]
>>> Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
>>> I think we should replace
>>>
>>> pdev->dev.dma_mask = dev->dma_mask;
>>> pdev->dev.dma_parms = dev->dma_parms;
>>> d
On 07/09/16 10:55, Peter Chen wrote:
[...]
>> Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
>> I think we should replace
>>
>> pdev->dev.dma_mask = dev->dma_mask;
>> pdev->dev.dma_parms = dev->dma_parms;
>> dma_set_coherent_mask(&pdev->dev, dev->
Hi,
Arnd Bergmann writes:
[...]
> Regarding the DMA configuration that you mention in ci_hdrc_add_device(),
> I think we should replace
>
> pdev->dev.dma_mask = dev->dma_mask;
> pdev->dev.dma_parms = dev->dma_parms;
> dma_set_coherent_mask(&pdev->dev, dev->coherent_dma
Hi,
Russell King - ARM Linux writes:
> On Wed, Sep 07, 2016 at 05:29:01PM +0800, Peter Chen wrote:
>> On Wed, Sep 07, 2016 at 10:52:46AM +0200, Arnd Bergmann wrote:
>> > On Wednesday, September 7, 2016 3:44:28 PM CEST Peter Chen wrote:
>> > >
>> > > The pre-condition of DT function at USB HCD c
On Wed, Sep 07, 2016 at 10:48:06AM +0200, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 2:33:13 PM CEST Peter Chen wrote:
> > >
> > > Right, that should make it work with iommu as well. However, it does
> > > not solve the other issue I mentioned above, with boards that have
> > > USB dev
On Wed, Sep 07, 2016 at 05:29:01PM +0800, Peter Chen wrote:
> On Wed, Sep 07, 2016 at 10:52:46AM +0200, Arnd Bergmann wrote:
> > On Wednesday, September 7, 2016 3:44:28 PM CEST Peter Chen wrote:
> > >
> > > The pre-condition of DT function at USB HCD core works is the host
> > > controller device
On Wed, Sep 07, 2016 at 10:52:46AM +0200, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 3:44:28 PM CEST Peter Chen wrote:
> >
> > The pre-condition of DT function at USB HCD core works is the host
> > controller device has of_node, since it is the root node for USB tree
> > described at D
On Wednesday, September 7, 2016 3:44:28 PM CEST Peter Chen wrote:
>
> The pre-condition of DT function at USB HCD core works is the host
> controller device has of_node, since it is the root node for USB tree
> described at DT. If the host controller device is not at DT, it needs
> to try to get i
On Wednesday, September 7, 2016 2:33:13 PM CEST Peter Chen wrote:
> >
> > Right, that should make it work with iommu as well. However, it does
> > not solve the other issue I mentioned above, with boards that have
> > USB devices hardwired to a chipidea host controller that need
> > configuration
On Wednesday, September 7, 2016 10:17:31 AM CEST Roger Quadros wrote:
> >
> > Speaking of that flag, I suppose we need the same logic to know where
> > to look for USB devices attached to a dwc3 host when we need to describe
> > them in DT. By default we look for child device nodes under the
> > n
On Tue, Sep 06, 2016 at 03:27:43PM +0200, Arnd Bergmann wrote:
> On Tuesday, September 6, 2016 1:50:48 PM CEST Felipe Balbi wrote:
> > Hi,
> >
> > Arnd Bergmann writes:
> > > On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote:
> > >>
> > >> this only solves the problem for DT devic
Hi Arnd,
On 02/09/16 18:51, Arnd Bergmann wrote:
> On Friday, September 2, 2016 10:21:23 AM CEST Alan Stern wrote:
>> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>>
>>> Hi,
>>>
>>> Russell King - ARM Linux writes:
On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> On Thursday,
Arnd Bergmann writes:
> On Tuesday, September 6, 2016 1:50:48 PM CEST Felipe Balbi wrote:
>> Hi,
>>
>> Arnd Bergmann writes:
>> > On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote:
>> >>
>> >> this only solves the problem for DT devices. Legacy devices and
>> >> PCI-based system
On Tue, Sep 06, 2016 at 12:38:29PM +0200, Arnd Bergmann wrote:
> On Tuesday, September 6, 2016 2:35:29 PM CEST Peter Chen wrote:
> > On Mon, Sep 05, 2016 at 05:39:27PM +0200, Arnd Bergmann wrote:
> > > On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
>
> > >
> > > Most of these are prob
On Tuesday, September 6, 2016 1:50:48 PM CEST Felipe Balbi wrote:
> Hi,
>
> Arnd Bergmann writes:
> > On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote:
> >>
> >> this only solves the problem for DT devices. Legacy devices and
> >> PCI-based systems will still suffer from the same
Hi,
Arnd Bergmann writes:
> On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote:
>>
>> this only solves the problem for DT devices. Legacy devices and
>> PCI-based systems will still suffer from the same problem. At least for
>> dwc3, I will only be taking patches that solve the pr
On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote:
>
> this only solves the problem for DT devices. Legacy devices and
> PCI-based systems will still suffer from the same problem. At least for
> dwc3, I will only be taking patches that solve the problem for all
> users, not a subset
On Tuesday, September 6, 2016 2:35:29 PM CEST Peter Chen wrote:
> On Mon, Sep 05, 2016 at 05:39:27PM +0200, Arnd Bergmann wrote:
> > On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
> >
> > Most of these are probably never used with any nonstandard
> > DMA settings (IOMMU, cache coheren
Hi,
Peter Chen writes:
> On Mon, Sep 05, 2016 at 05:39:27PM +0200, Arnd Bergmann wrote:
>> On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
>> >
>> > Can we use the firmware or bootloader information to provide the
>> > default dma-mapping attributes for devices that doesn't have an
>
On Mon, Sep 05, 2016 at 05:39:27PM +0200, Arnd Bergmann wrote:
> On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
> >
> > Can we use the firmware or bootloader information to provide the
> > default dma-mapping attributes for devices that doesn't have an
> > of_node pointer or ACPI data?
On Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
>
> Can we use the firmware or bootloader information to provide the
> default dma-mapping attributes for devices that doesn't have an
> of_node pointer or ACPI data? This will at least restore what we had
> previously provided . I'm con
On Fri, Sep 2, 2016 at 5:43 AM, Arnd Bergmann wrote:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>
>> Hi Felipe and Arnd,
>>
>> It has been a while since the last response to this discussion, but we
>> haven't reached an agreement yet! Can we get to a conclusion on if it
>> is
On 09/02/2016 02:08 PM, Felipe Balbi wrote:
>
> Hi,
>
> Russell King - ARM Linux writes:
>> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
Hi Felipe and Arnd,
It has been a while since the last r
On Friday, September 2, 2016 10:21:23 AM CEST Alan Stern wrote:
> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>
> > Hi,
> >
> > Russell King - ARM Linux writes:
> > > On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> > >> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>
On Fri, 2 Sep 2016, Felipe Balbi wrote:
> Hi,
>
> Russell King - ARM Linux writes:
> > On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> >> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> >> >
> >> > Hi Felipe and Arnd,
> >> >
> >> > It has been a while since the
Hi,
Felipe Balbi writes:
> Hi,
>
> Russell King - ARM Linux writes:
>> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>> >
>>> > Hi Felipe and Arnd,
>>> >
>>> > It has been a while since the last response to thi
On Friday, September 2, 2016 12:55:33 PM CEST Robin Murphy wrote:
>
> Huh? There's only no DMA description in DT if the device can be assumed
> to be happy with the defaults. Anything else should be using
> "dma-ranges", "dma-coherent", etc. to describe non-default integration
> aspects. For devic
Hi,
Robin Murphy writes:
It has been a while since the last response to this discussion, but we
haven't reached an agreement yet! Can we get to a conclusion on if it
is valid to create child platform device for abstraction purpose? If
yes, can this child device do DMA by it
On 02/09/16 11:53, Felipe Balbi wrote:
>
> Hi,
>
> Arnd Bergmann writes:
>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>>
>>> Hi Felipe and Arnd,
>>>
>>> It has been a while since the last response to this discussion, but we
>>> haven't reached an agreement yet! Can we get to
Hi,
Russell King - ARM Linux writes:
> On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
>> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>> >
>> > Hi Felipe and Arnd,
>> >
>> > It has been a while since the last response to this discussion, but we
>> > haven't reac
Hi,
Arnd Bergmann writes:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>>
>> Hi Felipe and Arnd,
>>
>> It has been a while since the last response to this discussion, but we
>> haven't reached an agreement yet! Can we get to a conclusion on if it
>> is valid to create child
On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> >
> > Hi Felipe and Arnd,
> >
> > It has been a while since the last response to this discussion, but we
> > haven't reached an agreement yet! Can we get to a conclusio
On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
>
> Hi Felipe and Arnd,
>
> It has been a while since the last response to this discussion, but we
> haven't reached an agreement yet! Can we get to a conclusion on if it
> is valid to create child platform device for abstraction purpo
On Thu, Apr 28, 2016 at 9:27 AM, Felipe Balbi wrote:
>
> Hi,
>
> Arnd Bergmann writes:
>> On Thursday 28 April 2016 15:16:12 Russell King - ARM Linux wrote:
>>> On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote:
>>> >
>>> > Hi,
>>> >
>>> > Arnd Bergmann writes:
>>> > >pointer and
Hi,
Arnd Bergmann writes:
> On Thursday 28 April 2016 15:16:12 Russell King - ARM Linux wrote:
>> On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote:
>> >
>> > Hi,
>> >
>> > Arnd Bergmann writes:
>> > >pointer and pass that in platform_data. This is really easy, it's
>> >
>> >
On Thursday 28 April 2016 15:16:12 Russell King - ARM Linux wrote:
> On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote:
> >
> > Hi,
> >
> > Arnd Bergmann writes:
> > >pointer and pass that in platform_data. This is really easy, it's
> >
> > Sorry but passing a struct device point
On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Arnd Bergmann writes:
> >pointer and pass that in platform_data. This is really easy, it's
>
> Sorry but passing a struct device pointer in platform_data is
> ridiculous. Not to mention that, as I said before, we can'
Hi,
Arnd Bergmann writes:
> On Wednesday 27 April 2016 23:05:42 Felipe Balbi wrote:
>> Arnd Bergmann writes:
>> > On Wednesday 27 April 2016 13:59:13 Alan Stern wrote:
>> >> On Wed, 27 Apr 2016, Arnd Bergmann wrote:
>> >>
>> >> > I've looked at the usb HCD code now and see this:
>> >> >
>> >>
On Wednesday 27 April 2016 23:05:42 Felipe Balbi wrote:
> Arnd Bergmann writes:
> > On Wednesday 27 April 2016 13:59:13 Alan Stern wrote:
> >> On Wed, 27 Apr 2016, Arnd Bergmann wrote:
> >>
> >> > I've looked at the usb HCD code now and see this:
> >> >
> >> > struct usb_hcd *usb_create_shared_h
Hi,
Arnd Bergmann writes:
> On Wednesday 27 April 2016 19:53:51 Felipe Balbi wrote:
>> Arnd Bergmann writes:
>> > On Wednesday 27 April 2016 16:50:19 Catalin Marinas wrote:
>> >> On Wed, Apr 27, 2016 at 04:11:17PM +0200, Arnd Bergmann wrote:
>> >> > On Wednesday 27 April 2016 14:59:00 Catalin M
Hi,
Arnd Bergmann writes:
> On Wednesday 27 April 2016 13:59:13 Alan Stern wrote:
>> On Wed, 27 Apr 2016, Arnd Bergmann wrote:
>>
>> > I've looked at the usb HCD code now and see this:
>> >
>> > struct usb_hcd *usb_create_shared_hcd(const struct hc_driver *driver,
>> > struct d
On Wednesday 27 April 2016 13:59:13 Alan Stern wrote:
> On Wed, 27 Apr 2016, Arnd Bergmann wrote:
>
> > I've looked at the usb HCD code now and see this:
> >
> > struct usb_hcd *usb_create_shared_hcd(const struct hc_driver *driver,
> > struct device *dev, const char *bus_name,
> >
On Wed, 27 Apr 2016, Arnd Bergmann wrote:
> I've looked at the usb HCD code now and see this:
>
> struct usb_hcd *usb_create_shared_hcd(const struct hc_driver *driver,
> struct device *dev, const char *bus_name,
> struct usb_hcd *primary_hcd)
> {
> ...
>
On Wednesday 27 April 2016 19:53:51 Felipe Balbi wrote:
> Arnd Bergmann writes:
> > On Wednesday 27 April 2016 16:50:19 Catalin Marinas wrote:
> >> On Wed, Apr 27, 2016 at 04:11:17PM +0200, Arnd Bergmann wrote:
> >> > On Wednesday 27 April 2016 14:59:00 Catalin Marinas wrote:
> >> > >
> >> > > I
Hi,
Arnd Bergmann writes:
> On Wednesday 27 April 2016 16:50:19 Catalin Marinas wrote:
>> On Wed, Apr 27, 2016 at 04:11:17PM +0200, Arnd Bergmann wrote:
>> > On Wednesday 27 April 2016 14:59:00 Catalin Marinas wrote:
>> > >
>> > > I would be in favour of a dma_inherit() function as well. We cou
On Wednesday 27 April 2016 16:50:19 Catalin Marinas wrote:
> On Wed, Apr 27, 2016 at 04:11:17PM +0200, Arnd Bergmann wrote:
> > On Wednesday 27 April 2016 14:59:00 Catalin Marinas wrote:
> > >
> > > I would be in favour of a dma_inherit() function as well. We could hack
> > > something up in the a
On Wed, Apr 27, 2016 at 04:11:17PM +0200, Arnd Bergmann wrote:
> On Wednesday 27 April 2016 14:59:00 Catalin Marinas wrote:
> >
> > I would be in favour of a dma_inherit() function as well. We could hack
> > something up in the arch code (like below) but I would rather prefer an
> > explicit dma_i
On Wed, Apr 27, 2016 at 08:41:06AM +0300, Felipe Balbi wrote:
> Grygorii Strashko writes:
> > On 04/26/2016 09:17 AM, Felipe Balbi wrote:
> >> Grygorii Strashko writes:
> >>> Now not all DMA paremters configured properly for "xhci-hcd" platform
> >>> device which is created manually. For example:
On 04/27/2016 04:59 PM, Catalin Marinas wrote:
On Wed, Apr 27, 2016 at 08:41:06AM +0300, Felipe Balbi wrote:
Grygorii Strashko writes:
On 04/26/2016 09:17 AM, Felipe Balbi wrote:
Grygorii Strashko writes:
Now not all DMA paremters configured properly for "xhci-hcd" platform
device which is
On Wednesday 27 April 2016 14:59:00 Catalin Marinas wrote:
>
> I would be in favour of a dma_inherit() function as well. We could hack
> something up in the arch code (like below) but I would rather prefer an
> explicit dma_inherit() call by drivers creating such devices.
>
> diff --git a/arch/ar
On 04/27/2016 08:41 AM, Felipe Balbi wrote:
>
> Hi,
>
> Grygorii Strashko writes:
>> On 04/26/2016 09:17 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Grygorii Strashko writes:
Now not all DMA paremters configured properly for "xhci-hcd" platform
device which is created manually. For ex
Hi,
Grygorii Strashko writes:
> On 04/26/2016 09:17 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Grygorii Strashko writes:
>>> Now not all DMA paremters configured properly for "xhci-hcd" platform
>>> device which is created manually. For example: dma_pfn_offset, dam_ops
>>> and iommu configuratio
On 04/26/2016 09:17 AM, Felipe Balbi wrote:
>
> Hi,
>
> Grygorii Strashko writes:
>> Now not all DMA paremters configured properly for "xhci-hcd" platform
>> device which is created manually. For example: dma_pfn_offset, dam_ops
>> and iommu configuration will not corresponds "dwc3" devices
>> c
Hi,
Grygorii Strashko writes:
> Now not all DMA paremters configured properly for "xhci-hcd" platform
> device which is created manually. For example: dma_pfn_offset, dam_ops
> and iommu configuration will not corresponds "dwc3" devices
> configuration. As result, this will cause problems like w
Now not all DMA paremters configured properly for "xhci-hcd" platform
device which is created manually. For example: dma_pfn_offset, dam_ops
and iommu configuration will not corresponds "dwc3" devices
configuration. As result, this will cause problems like wrong DMA
addresses translation on platfor
89 matches
Mail list logo