Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1260585 > unrolled thread

[RFC 0/8] Add support for NVIDIA Tegra XUSB

Back to article view | Back to linux.kernel

Contents

  [RFC 0/8] Add support for NVIDIA Tegra XUSB Martyn Welch <martyn.welch@collabora.co.uk> - 2015-11-02 13:00 +0100
    Re: [RFC 0/8] Add support for NVIDIA Tegra XUSB Stephen Warren <swarren@wwwdotorg.org> - 2015-11-02 18:30 +0100
    Re: [RFC 0/8] Add support for NVIDIA Tegra XUSB Andrew Bresticker <abrestic@chromium.org> - 2015-11-02 18:30 +0100
      Re: [RFC 0/8] Add support for NVIDIA Tegra XUSB Martyn Welch <martyn.welch@collabora.co.uk> - 2015-11-02 18:40 +0100

#1260585 — [RFC 0/8] Add support for NVIDIA Tegra XUSB

This series is based on commits that can be found in the git tree here:

https://github.com/thierryreding/linux/commits/staging/xhci

I have included the patches I've used from that tree as patches 1-5.

The above patches were submitted for review back in May:

https://lkml.org/lkml/2015/5/4/574

The approach taken in these patches was deemed not appropriate (treating
the XUSB as a MFD).

In patch 6 I add the bindings based in those submitted for review here
(with a few modifications currently required by the driver):

https://www.spinics.net/lists/linux-usb/msg130940.html

I have included my changes to the original patch series in patch 7. With
these modifications the patch series builds and works, but is rather hacky.
Devices for the mailbox driver and xHCI driver are now created in the xusb
driver (still under the mfd directory for now - it will be moved before
this series is submitted properly). As the child devices use
infrastructure which expects the device to be associated with a of_node,
it has been necessary to point the child device at the parents of_node
where this is needed. This approach did not seem viable for the mailbox
API, so to get that working the child device node was pointed to the
parents of_node (in tegra_xusb_add_device). The unfortunate side effect of
this is that upon device creation the parents probe routine gets called...

Not good.

Patch 8 attempts to resolve this. When passing the parents device node to
the mailbox API, the mailbox's receive callback was raising errors as
that function is looking for the drvdata stored in the child's device node,
but getting the parents. This patch jumps though a few hoops to get to the
child's device node.

Unfortunately, whilst the receive callback seems to be getting the right
drvdata, USB3 devices are being enumerated as USB2 devices rather than
USB3 devices, so something is clearly not right.

I'm posting these patches in the hope that someone can point me in the
right direction.

Is there a better approach I'm missing?

Any ideas why devices aren't being enumerated as USB3?

Martyn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1260812

On 11/02/2015 04:55 AM, Martyn Welch wrote:
> This series is based on commits that can be found in the git tree here:
>
> https://github.com/thierryreding/linux/commits/staging/xhci
>
> I have included the patches I've used from that tree as patches 1-5.
>
> The above patches were submitted for review back in May:
>
> https://lkml.org/lkml/2015/5/4/574

Let's hold off on any XUSB driver submissions. We need to sort out what 
we want the DT binding to look like first. Hopefully Thierry will be 
posting revised XUSB PADCTL and XUSB bindings in the near future. Once 
that's finalized, then we can look at drivers that implement them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1260824

Hi Martyn,

On Mon, Nov 2, 2015 at 3:55 AM, Martyn Welch
<martyn.welch@collabora.co.uk> wrote:
> This series is based on commits that can be found in the git tree here:
>
> https://github.com/thierryreding/linux/commits/staging/xhci
>
> I have included the patches I've used from that tree as patches 1-5.
>
> The above patches were submitted for review back in May:
>
> https://lkml.org/lkml/2015/5/4/574
>
> The approach taken in these patches was deemed not appropriate (treating
> the XUSB as a MFD).
>
> In patch 6 I add the bindings based in those submitted for review here
> (with a few modifications currently required by the driver):
>
> https://www.spinics.net/lists/linux-usb/msg130940.html
>
> I have included my changes to the original patch series in patch 7. With
> these modifications the patch series builds and works, but is rather hacky.
> Devices for the mailbox driver and xHCI driver are now created in the xusb
> driver (still under the mfd directory for now - it will be moved before
> this series is submitted properly). As the child devices use
> infrastructure which expects the device to be associated with a of_node,
> it has been necessary to point the child device at the parents of_node
> where this is needed. This approach did not seem viable for the mailbox
> API, so to get that working the child device node was pointed to the
> parents of_node (in tegra_xusb_add_device). The unfortunate side effect of
> this is that upon device creation the parents probe routine gets called...
>
> Not good.
>
> Patch 8 attempts to resolve this. When passing the parents device node to
> the mailbox API, the mailbox's receive callback was raising errors as
> that function is looking for the drvdata stored in the child's device node,
> but getting the parents. This patch jumps though a few hoops to get to the
> child's device node.

After my last submission, we had a discussion about the mailbox and
decided not to use the mailbox framework and instead use a private API
between the xHCI driver and the XUSB_PADCTL driver.

> Unfortunately, whilst the receive callback seems to be getting the right
> drvdata, USB3 devices are being enumerated as USB2 devices rather than
> USB3 devices, so something is clearly not right.

Tegra124?  Tegra210?  Which board?

Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1260831

On 02/11/15 17:27, Andrew Bresticker wrote:
> Hi Martyn,
>
> On Mon, Nov 2, 2015 at 3:55 AM, Martyn Welch
> <martyn.welch@collabora.co.uk> wrote:
>> This series is based on commits that can be found in the git tree here:
>>
>> https://github.com/thierryreding/linux/commits/staging/xhci
>>
>> I have included the patches I've used from that tree as patches 1-5.
>>
>> The above patches were submitted for review back in May:
>>
>> https://lkml.org/lkml/2015/5/4/574
>>
>> The approach taken in these patches was deemed not appropriate (treating
>> the XUSB as a MFD).
>>
>> In patch 6 I add the bindings based in those submitted for review here
>> (with a few modifications currently required by the driver):
>>
>> https://www.spinics.net/lists/linux-usb/msg130940.html
>>
>> I have included my changes to the original patch series in patch 7. With
>> these modifications the patch series builds and works, but is rather hacky.
>> Devices for the mailbox driver and xHCI driver are now created in the xusb
>> driver (still under the mfd directory for now - it will be moved before
>> this series is submitted properly). As the child devices use
>> infrastructure which expects the device to be associated with a of_node,
>> it has been necessary to point the child device at the parents of_node
>> where this is needed. This approach did not seem viable for the mailbox
>> API, so to get that working the child device node was pointed to the
>> parents of_node (in tegra_xusb_add_device). The unfortunate side effect of
>> this is that upon device creation the parents probe routine gets called...
>>
>> Not good.
>>
>> Patch 8 attempts to resolve this. When passing the parents device node to
>> the mailbox API, the mailbox's receive callback was raising errors as
>> that function is looking for the drvdata stored in the child's device node,
>> but getting the parents. This patch jumps though a few hoops to get to the
>> child's device node.
> After my last submission, we had a discussion about the mailbox and
> decided not to use the mailbox framework and instead use a private API
> between the xHCI driver and the XUSB_PADCTL driver.
>

Ok.

>> Unfortunately, whilst the receive callback seems to be getting the right
>> drvdata, USB3 devices are being enumerated as USB2 devices rather than
>> USB3 devices, so something is clearly not right.
> Tegra124?  Tegra210?  Which board?

Tegra124, nyan-blaze.

Martyn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web