* [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-04 17:36 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bresticker,
Jon Hunter, Mathias Nyman, Greg Kroah-Hartman
xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
for the shared HCD, requiring xHCI host-controller drivers to set it
between usb_create_shared_hcd() and usb_add_hcd(). There's no reason
xhci_gen_setup() can't set the shared HCD's hcd_priv as well, so move
that bit out of the host-controller drivers and into xhci_gen_setup().
Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Reviewed-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
Cc: Mathias Nyman <mathias.nyman-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
---
No changes from v5/v6/v7.
New for v5.
Peviously posted here: https://lkml.org/lkml/2014/10/30/726
---
drivers/usb/host/xhci-pci.c | 5 -----
drivers/usb/host/xhci-plat.c | 5 -----
drivers/usb/host/xhci.c | 6 +++---
3 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 2af32e2..f9ce741 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -247,11 +247,6 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
goto dealloc_usb2_hcd;
}
- /* Set the xHCI pointer before xhci_pci_setup() (aka hcd_driver.reset)
- * is called by usb_add_hcd().
- */
- *((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
-
retval = usb_add_hcd(xhci->shared_hcd, dev->irq,
IRQF_SHARED);
if (retval)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 783e819..852b1e9 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,11 +147,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
(pdata && pdata->usb3_lpm_capable))
xhci->quirks |= XHCI_LPM_SUPPORT;
- /*
- * Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
- * is called by usb_add_hcd().
- */
- *((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ec8ac16..2901a67 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4849,9 +4849,9 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
*/
hcd->has_tt = 1;
} else {
- /* xHCI private pointer was set in xhci_pci_probe for the second
- * registered roothub.
- */
+ xhci = hcd_to_xhci(hcd->primary_hcd);
+ *((struct xhci_hcd **) hcd->hcd_priv) = xhci;
+
return 0;
}
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: linux-arm-kernel
xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
for the shared HCD, requiring xHCI host-controller drivers to set it
between usb_create_shared_hcd() and usb_add_hcd(). There's no reason
xhci_gen_setup() can't set the shared HCD's hcd_priv as well, so move
that bit out of the host-controller drivers and into xhci_gen_setup().
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
No changes from v5/v6/v7.
New for v5.
Peviously posted here: https://lkml.org/lkml/2014/10/30/726
---
drivers/usb/host/xhci-pci.c | 5 -----
drivers/usb/host/xhci-plat.c | 5 -----
drivers/usb/host/xhci.c | 6 +++---
3 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 2af32e2..f9ce741 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -247,11 +247,6 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
goto dealloc_usb2_hcd;
}
- /* Set the xHCI pointer before xhci_pci_setup() (aka hcd_driver.reset)
- * is called by usb_add_hcd().
- */
- *((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
-
retval = usb_add_hcd(xhci->shared_hcd, dev->irq,
IRQF_SHARED);
if (retval)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 783e819..852b1e9 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,11 +147,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
(pdata && pdata->usb3_lpm_capable))
xhci->quirks |= XHCI_LPM_SUPPORT;
- /*
- * Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
- * is called by usb_add_hcd().
- */
- *((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ec8ac16..2901a67 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4849,9 +4849,9 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
*/
hcd->has_tt = 1;
} else {
- /* xHCI private pointer was set in xhci_pci_probe for the second
- * registered roothub.
- */
+ xhci = hcd_to_xhci(hcd->primary_hcd);
+ *((struct xhci_hcd **) hcd->hcd_priv) = xhci;
+
return 0;
}
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Andrew Bresticker, Jon Hunter, Mathias Nyman,
Greg Kroah-Hartman
xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
for the shared HCD, requiring xHCI host-controller drivers to set it
between usb_create_shared_hcd() and usb_add_hcd(). There's no reason
xhci_gen_setup() can't set the shared HCD's hcd_priv as well, so move
that bit out of the host-controller drivers and into xhci_gen_setup().
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
No changes from v5/v6/v7.
New for v5.
Peviously posted here: https://lkml.org/lkml/2014/10/30/726
---
drivers/usb/host/xhci-pci.c | 5 -----
drivers/usb/host/xhci-plat.c | 5 -----
drivers/usb/host/xhci.c | 6 +++---
3 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 2af32e2..f9ce741 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -247,11 +247,6 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
goto dealloc_usb2_hcd;
}
- /* Set the xHCI pointer before xhci_pci_setup() (aka hcd_driver.reset)
- * is called by usb_add_hcd().
- */
- *((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
-
retval = usb_add_hcd(xhci->shared_hcd, dev->irq,
IRQF_SHARED);
if (retval)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 783e819..852b1e9 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,11 +147,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
(pdata && pdata->usb3_lpm_capable))
xhci->quirks |= XHCI_LPM_SUPPORT;
- /*
- * Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
- * is called by usb_add_hcd().
- */
- *((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ec8ac16..2901a67 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4849,9 +4849,9 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
*/
hcd->has_tt = 1;
} else {
- /* xHCI private pointer was set in xhci_pci_probe for the second
- * registered roothub.
- */
+ xhci = hcd_to_xhci(hcd->primary_hcd);
+ *((struct xhci_hcd **) hcd->hcd_priv) = xhci;
+
return 0;
}
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread[parent not found: <1430761002-9327-2-git-send-email-abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]
* Re: [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-19 18:39 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-19 18:39 UTC (permalink / raw)
To: Mathias Nyman
Cc: Stephen Warren, Alexandre Courbot, Thierry Reding,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bresticker,
Jon Hunter, Greg Kroah-Hartman
Hi Mathias,
On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
<abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
> for the shared HCD, requiring xHCI host-controller drivers to set it
> between usb_create_shared_hcd() and usb_add_hcd(). There's no reason
> xhci_gen_setup() can't set the shared HCD's hcd_priv as well, so move
> that bit out of the host-controller drivers and into xhci_gen_setup().
>
> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Reviewed-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
> Cc: Mathias Nyman <mathias.nyman-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Any chance you could pick this up for 4.2? It's a dependency for the
xhci-tegra driver which looks like it's going to slip to 4.3 now.
Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup
@ 2015-05-19 18:39 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-19 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mathias,
On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
<abrestic@chromium.org> wrote:
> xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
> for the shared HCD, requiring xHCI host-controller drivers to set it
> between usb_create_shared_hcd() and usb_add_hcd(). There's no reason
> xhci_gen_setup() can't set the shared HCD's hcd_priv as well, so move
> that bit out of the host-controller drivers and into xhci_gen_setup().
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Reviewed-by: Felipe Balbi <balbi@ti.com>
> Cc: Mathias Nyman <mathias.nyman@intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Any chance you could pick this up for 4.2? It's a dependency for the
xhci-tegra driver which looks like it's going to slip to 4.3 now.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup
@ 2015-05-19 18:39 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-19 18:39 UTC (permalink / raw)
To: Mathias Nyman
Cc: Stephen Warren, Alexandre Courbot, Thierry Reding, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Andrew Bresticker, Jon Hunter, Greg Kroah-Hartman
Hi Mathias,
On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
<abrestic@chromium.org> wrote:
> xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
> for the shared HCD, requiring xHCI host-controller drivers to set it
> between usb_create_shared_hcd() and usb_add_hcd(). There's no reason
> xhci_gen_setup() can't set the shared HCD's hcd_priv as well, so move
> that bit out of the host-controller drivers and into xhci_gen_setup().
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Reviewed-by: Felipe Balbi <balbi@ti.com>
> Cc: Mathias Nyman <mathias.nyman@intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Any chance you could pick this up for 4.2? It's a dependency for the
xhci-tegra driver which looks like it's going to slip to 4.3 now.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread
[parent not found: <CAL1qeaGo2-T=suBiCTtHmyR1sNeS_ZG-2j2FuuLdGc9vmct2ug-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup
2015-05-19 18:39 ` Andrew Bresticker
(?)
@ 2015-05-22 12:19 ` Mathias Nyman
-1 siblings, 0 replies; 136+ messages in thread
From: Mathias Nyman @ 2015-05-22 12:19 UTC (permalink / raw)
To: Andrew Bresticker, Mathias Nyman
Cc: Stephen Warren, Alexandre Courbot, Thierry Reding,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jon Hunter,
Greg Kroah-Hartman, Roger Quadros
Hi
On 19.05.2015 21:39, Andrew Bresticker wrote:
> Hi Mathias,
>
> On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
> <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
>> for the shared HCD, requiring xHCI host-controller drivers to set it
>> between usb_create_shared_hcd() and usb_add_hcd(). There's no reason
>> xhci_gen_setup() can't set the shared HCD's hcd_priv as well, so move
>> that bit out of the host-controller drivers and into xhci_gen_setup().
>>
>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> Reviewed-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
>> Cc: Mathias Nyman <mathias.nyman-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Cc: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
>
> Any chance you could pick this up for 4.2? It's a dependency for the
> xhci-tegra driver which looks like it's going to slip to 4.3 now.
>
I got some internal tasks I need(ed) to attend, and I'm a bit late with
the 4.2 patches. I'll try to sort it out next week.
A got some patches from Roger Quadros where he changed
how struct xhci_hcd is allocated to get xhci working with OTG code.
That code will conflict with patch 1/9, so patch 1/9 will probably be dropped,
but that shouldn't affect the rest of your patches.
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup
@ 2015-05-22 12:19 ` Mathias Nyman
0 siblings, 0 replies; 136+ messages in thread
From: Mathias Nyman @ 2015-05-22 12:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi
On 19.05.2015 21:39, Andrew Bresticker wrote:
> Hi Mathias,
>
> On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
> <abrestic@chromium.org> wrote:
>> xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
>> for the shared HCD, requiring xHCI host-controller drivers to set it
>> between usb_create_shared_hcd() and usb_add_hcd(). There's no reason
>> xhci_gen_setup() can't set the shared HCD's hcd_priv as well, so move
>> that bit out of the host-controller drivers and into xhci_gen_setup().
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Reviewed-by: Felipe Balbi <balbi@ti.com>
>> Cc: Mathias Nyman <mathias.nyman@intel.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Any chance you could pick this up for 4.2? It's a dependency for the
> xhci-tegra driver which looks like it's going to slip to 4.3 now.
>
I got some internal tasks I need(ed) to attend, and I'm a bit late with
the 4.2 patches. I'll try to sort it out next week.
A got some patches from Roger Quadros where he changed
how struct xhci_hcd is allocated to get xhci working with OTG code.
That code will conflict with patch 1/9, so patch 1/9 will probably be dropped,
but that shouldn't affect the rest of your patches.
-Mathias
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup
@ 2015-05-22 12:19 ` Mathias Nyman
0 siblings, 0 replies; 136+ messages in thread
From: Mathias Nyman @ 2015-05-22 12:19 UTC (permalink / raw)
To: Andrew Bresticker, Mathias Nyman
Cc: Stephen Warren, Alexandre Courbot, Thierry Reding, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Jon Hunter, Greg Kroah-Hartman, Roger Quadros
Hi
On 19.05.2015 21:39, Andrew Bresticker wrote:
> Hi Mathias,
>
> On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
> <abrestic@chromium.org> wrote:
>> xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
>> for the shared HCD, requiring xHCI host-controller drivers to set it
>> between usb_create_shared_hcd() and usb_add_hcd(). There's no reason
>> xhci_gen_setup() can't set the shared HCD's hcd_priv as well, so move
>> that bit out of the host-controller drivers and into xhci_gen_setup().
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Reviewed-by: Felipe Balbi <balbi@ti.com>
>> Cc: Mathias Nyman <mathias.nyman@intel.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Any chance you could pick this up for 4.2? It's a dependency for the
> xhci-tegra driver which looks like it's going to slip to 4.3 now.
>
I got some internal tasks I need(ed) to attend, and I'm a bit late with
the 4.2 patches. I'll try to sort it out next week.
A got some patches from Roger Quadros where he changed
how struct xhci_hcd is allocated to get xhci working with OTG code.
That code will conflict with patch 1/9, so patch 1/9 will probably be dropped,
but that shouldn't affect the rest of your patches.
-Mathias
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v8 2/9] mailbox: Make mbox_chan_ops const
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-04 17:36 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bresticker,
Jon Hunter, Jassi Brar, Suman Anna, Ashwin Chaugule,
Ley Foon Tan
The mailbox controller's channel ops ought to be read-only. Update
all the mailbox drivers to make their mbox_chan_ops const as well.
Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Jassi Brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
Cc: Ashwin Chaugule <ashwin.chaugule-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Ley Foon Tan <lftan-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
---
Changes from v7:
- Constify all drivers' mbox_chan_ops.
No changes from v5/v6.
New for v5.
---
drivers/mailbox/arm_mhu.c | 2 +-
drivers/mailbox/mailbox-altera.c | 2 +-
drivers/mailbox/omap-mailbox.c | 2 +-
drivers/mailbox/pcc.c | 2 +-
include/linux/mailbox_controller.h | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/arm_mhu.c b/drivers/mailbox/arm_mhu.c
index ac693c6..d9e99f9 100644
--- a/drivers/mailbox/arm_mhu.c
+++ b/drivers/mailbox/arm_mhu.c
@@ -110,7 +110,7 @@ static void mhu_shutdown(struct mbox_chan *chan)
free_irq(mlink->irq, chan);
}
-static struct mbox_chan_ops mhu_ops = {
+static const struct mbox_chan_ops mhu_ops = {
.send_data = mhu_send_data,
.startup = mhu_startup,
.shutdown = mhu_shutdown,
diff --git a/drivers/mailbox/mailbox-altera.c b/drivers/mailbox/mailbox-altera.c
index a266265..bb682c9 100644
--- a/drivers/mailbox/mailbox-altera.c
+++ b/drivers/mailbox/mailbox-altera.c
@@ -285,7 +285,7 @@ static void altera_mbox_shutdown(struct mbox_chan *chan)
}
}
-static struct mbox_chan_ops altera_mbox_ops = {
+static const struct mbox_chan_ops altera_mbox_ops = {
.send_data = altera_mbox_send_data,
.startup = altera_mbox_startup,
.shutdown = altera_mbox_shutdown,
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 0f332c1..03f8545 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -604,7 +604,7 @@ static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
return ret;
}
-static struct mbox_chan_ops omap_mbox_chan_ops = {
+static const struct mbox_chan_ops omap_mbox_chan_ops = {
.startup = omap_mbox_chan_startup,
.send_data = omap_mbox_chan_send_data,
.shutdown = omap_mbox_chan_shutdown,
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 7e91d68..26d121d 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -198,7 +198,7 @@ static int pcc_send_data(struct mbox_chan *chan, void *data)
return 0;
}
-static struct mbox_chan_ops pcc_chan_ops = {
+static const struct mbox_chan_ops pcc_chan_ops = {
.send_data = pcc_send_data,
};
diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
index d4cf96f..68c4245 100644
--- a/include/linux/mailbox_controller.h
+++ b/include/linux/mailbox_controller.h
@@ -72,7 +72,7 @@ struct mbox_chan_ops {
*/
struct mbox_controller {
struct device *dev;
- struct mbox_chan_ops *ops;
+ const struct mbox_chan_ops *ops;
struct mbox_chan *chans;
int num_chans;
bool txdone_irq;
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 2/9] mailbox: Make mbox_chan_ops const
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: linux-arm-kernel
The mailbox controller's channel ops ought to be read-only. Update
all the mailbox drivers to make their mbox_chan_ops const as well.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Cc: Ley Foon Tan <lftan@altera.com>
---
Changes from v7:
- Constify all drivers' mbox_chan_ops.
No changes from v5/v6.
New for v5.
---
drivers/mailbox/arm_mhu.c | 2 +-
drivers/mailbox/mailbox-altera.c | 2 +-
drivers/mailbox/omap-mailbox.c | 2 +-
drivers/mailbox/pcc.c | 2 +-
include/linux/mailbox_controller.h | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/arm_mhu.c b/drivers/mailbox/arm_mhu.c
index ac693c6..d9e99f9 100644
--- a/drivers/mailbox/arm_mhu.c
+++ b/drivers/mailbox/arm_mhu.c
@@ -110,7 +110,7 @@ static void mhu_shutdown(struct mbox_chan *chan)
free_irq(mlink->irq, chan);
}
-static struct mbox_chan_ops mhu_ops = {
+static const struct mbox_chan_ops mhu_ops = {
.send_data = mhu_send_data,
.startup = mhu_startup,
.shutdown = mhu_shutdown,
diff --git a/drivers/mailbox/mailbox-altera.c b/drivers/mailbox/mailbox-altera.c
index a266265..bb682c9 100644
--- a/drivers/mailbox/mailbox-altera.c
+++ b/drivers/mailbox/mailbox-altera.c
@@ -285,7 +285,7 @@ static void altera_mbox_shutdown(struct mbox_chan *chan)
}
}
-static struct mbox_chan_ops altera_mbox_ops = {
+static const struct mbox_chan_ops altera_mbox_ops = {
.send_data = altera_mbox_send_data,
.startup = altera_mbox_startup,
.shutdown = altera_mbox_shutdown,
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 0f332c1..03f8545 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -604,7 +604,7 @@ static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
return ret;
}
-static struct mbox_chan_ops omap_mbox_chan_ops = {
+static const struct mbox_chan_ops omap_mbox_chan_ops = {
.startup = omap_mbox_chan_startup,
.send_data = omap_mbox_chan_send_data,
.shutdown = omap_mbox_chan_shutdown,
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 7e91d68..26d121d 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -198,7 +198,7 @@ static int pcc_send_data(struct mbox_chan *chan, void *data)
return 0;
}
-static struct mbox_chan_ops pcc_chan_ops = {
+static const struct mbox_chan_ops pcc_chan_ops = {
.send_data = pcc_send_data,
};
diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
index d4cf96f..68c4245 100644
--- a/include/linux/mailbox_controller.h
+++ b/include/linux/mailbox_controller.h
@@ -72,7 +72,7 @@ struct mbox_chan_ops {
*/
struct mbox_controller {
struct device *dev;
- struct mbox_chan_ops *ops;
+ const struct mbox_chan_ops *ops;
struct mbox_chan *chans;
int num_chans;
bool txdone_irq;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 2/9] mailbox: Make mbox_chan_ops const
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Andrew Bresticker, Jon Hunter, Jassi Brar,
Suman Anna, Ashwin Chaugule, Ley Foon Tan
The mailbox controller's channel ops ought to be read-only. Update
all the mailbox drivers to make their mbox_chan_ops const as well.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Suman Anna <s-anna@ti.com>
Cc: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Cc: Ley Foon Tan <lftan@altera.com>
---
Changes from v7:
- Constify all drivers' mbox_chan_ops.
No changes from v5/v6.
New for v5.
---
drivers/mailbox/arm_mhu.c | 2 +-
drivers/mailbox/mailbox-altera.c | 2 +-
drivers/mailbox/omap-mailbox.c | 2 +-
drivers/mailbox/pcc.c | 2 +-
include/linux/mailbox_controller.h | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/arm_mhu.c b/drivers/mailbox/arm_mhu.c
index ac693c6..d9e99f9 100644
--- a/drivers/mailbox/arm_mhu.c
+++ b/drivers/mailbox/arm_mhu.c
@@ -110,7 +110,7 @@ static void mhu_shutdown(struct mbox_chan *chan)
free_irq(mlink->irq, chan);
}
-static struct mbox_chan_ops mhu_ops = {
+static const struct mbox_chan_ops mhu_ops = {
.send_data = mhu_send_data,
.startup = mhu_startup,
.shutdown = mhu_shutdown,
diff --git a/drivers/mailbox/mailbox-altera.c b/drivers/mailbox/mailbox-altera.c
index a266265..bb682c9 100644
--- a/drivers/mailbox/mailbox-altera.c
+++ b/drivers/mailbox/mailbox-altera.c
@@ -285,7 +285,7 @@ static void altera_mbox_shutdown(struct mbox_chan *chan)
}
}
-static struct mbox_chan_ops altera_mbox_ops = {
+static const struct mbox_chan_ops altera_mbox_ops = {
.send_data = altera_mbox_send_data,
.startup = altera_mbox_startup,
.shutdown = altera_mbox_shutdown,
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 0f332c1..03f8545 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -604,7 +604,7 @@ static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
return ret;
}
-static struct mbox_chan_ops omap_mbox_chan_ops = {
+static const struct mbox_chan_ops omap_mbox_chan_ops = {
.startup = omap_mbox_chan_startup,
.send_data = omap_mbox_chan_send_data,
.shutdown = omap_mbox_chan_shutdown,
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 7e91d68..26d121d 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -198,7 +198,7 @@ static int pcc_send_data(struct mbox_chan *chan, void *data)
return 0;
}
-static struct mbox_chan_ops pcc_chan_ops = {
+static const struct mbox_chan_ops pcc_chan_ops = {
.send_data = pcc_send_data,
};
diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
index d4cf96f..68c4245 100644
--- a/include/linux/mailbox_controller.h
+++ b/include/linux/mailbox_controller.h
@@ -72,7 +72,7 @@ struct mbox_chan_ops {
*/
struct mbox_controller {
struct device *dev;
- struct mbox_chan_ops *ops;
+ const struct mbox_chan_ops *ops;
struct mbox_chan *chans;
int num_chans;
bool txdone_irq;
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread[parent not found: <1430761002-9327-3-git-send-email-abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]
* Re: [PATCH v8 2/9] mailbox: Make mbox_chan_ops const
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-04 19:22 ` Suman Anna
-1 siblings, 0 replies; 136+ messages in thread
From: Suman Anna @ 2015-05-04 19:22 UTC (permalink / raw)
To: Andrew Bresticker, Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jon Hunter, Jassi Brar,
Ashwin Chaugule, Ley Foon Tan
On 05/04/2015 12:36 PM, Andrew Bresticker wrote:
> The mailbox controller's channel ops ought to be read-only. Update
> all the mailbox drivers to make their mbox_chan_ops const as well.
>
> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Cc: Jassi Brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> Cc: Ashwin Chaugule <ashwin.chaugule-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Ley Foon Tan <lftan-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
Thanks, the new patch looks good.
Acked-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> ---
> Changes from v7:
> - Constify all drivers' mbox_chan_ops.
> No changes from v5/v6.
> New for v5.
> ---
> drivers/mailbox/arm_mhu.c | 2 +-
> drivers/mailbox/mailbox-altera.c | 2 +-
> drivers/mailbox/omap-mailbox.c | 2 +-
> drivers/mailbox/pcc.c | 2 +-
> include/linux/mailbox_controller.h | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mailbox/arm_mhu.c b/drivers/mailbox/arm_mhu.c
> index ac693c6..d9e99f9 100644
> --- a/drivers/mailbox/arm_mhu.c
> +++ b/drivers/mailbox/arm_mhu.c
> @@ -110,7 +110,7 @@ static void mhu_shutdown(struct mbox_chan *chan)
> free_irq(mlink->irq, chan);
> }
>
> -static struct mbox_chan_ops mhu_ops = {
> +static const struct mbox_chan_ops mhu_ops = {
> .send_data = mhu_send_data,
> .startup = mhu_startup,
> .shutdown = mhu_shutdown,
> diff --git a/drivers/mailbox/mailbox-altera.c b/drivers/mailbox/mailbox-altera.c
> index a266265..bb682c9 100644
> --- a/drivers/mailbox/mailbox-altera.c
> +++ b/drivers/mailbox/mailbox-altera.c
> @@ -285,7 +285,7 @@ static void altera_mbox_shutdown(struct mbox_chan *chan)
> }
> }
>
> -static struct mbox_chan_ops altera_mbox_ops = {
> +static const struct mbox_chan_ops altera_mbox_ops = {
> .send_data = altera_mbox_send_data,
> .startup = altera_mbox_startup,
> .shutdown = altera_mbox_shutdown,
> diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
> index 0f332c1..03f8545 100644
> --- a/drivers/mailbox/omap-mailbox.c
> +++ b/drivers/mailbox/omap-mailbox.c
> @@ -604,7 +604,7 @@ static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
> return ret;
> }
>
> -static struct mbox_chan_ops omap_mbox_chan_ops = {
> +static const struct mbox_chan_ops omap_mbox_chan_ops = {
> .startup = omap_mbox_chan_startup,
> .send_data = omap_mbox_chan_send_data,
> .shutdown = omap_mbox_chan_shutdown,
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 7e91d68..26d121d 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -198,7 +198,7 @@ static int pcc_send_data(struct mbox_chan *chan, void *data)
> return 0;
> }
>
> -static struct mbox_chan_ops pcc_chan_ops = {
> +static const struct mbox_chan_ops pcc_chan_ops = {
> .send_data = pcc_send_data,
> };
>
> diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
> index d4cf96f..68c4245 100644
> --- a/include/linux/mailbox_controller.h
> +++ b/include/linux/mailbox_controller.h
> @@ -72,7 +72,7 @@ struct mbox_chan_ops {
> */
> struct mbox_controller {
> struct device *dev;
> - struct mbox_chan_ops *ops;
> + const struct mbox_chan_ops *ops;
> struct mbox_chan *chans;
> int num_chans;
> bool txdone_irq;
>
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 2/9] mailbox: Make mbox_chan_ops const
@ 2015-05-04 19:22 ` Suman Anna
0 siblings, 0 replies; 136+ messages in thread
From: Suman Anna @ 2015-05-04 19:22 UTC (permalink / raw)
To: linux-arm-kernel
On 05/04/2015 12:36 PM, Andrew Bresticker wrote:
> The mailbox controller's channel ops ought to be read-only. Update
> all the mailbox drivers to make their mbox_chan_ops const as well.
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Suman Anna <s-anna@ti.com>
> Cc: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> Cc: Ley Foon Tan <lftan@altera.com>
Thanks, the new patch looks good.
Acked-by: Suman Anna <s-anna@ti.com>
> ---
> Changes from v7:
> - Constify all drivers' mbox_chan_ops.
> No changes from v5/v6.
> New for v5.
> ---
> drivers/mailbox/arm_mhu.c | 2 +-
> drivers/mailbox/mailbox-altera.c | 2 +-
> drivers/mailbox/omap-mailbox.c | 2 +-
> drivers/mailbox/pcc.c | 2 +-
> include/linux/mailbox_controller.h | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mailbox/arm_mhu.c b/drivers/mailbox/arm_mhu.c
> index ac693c6..d9e99f9 100644
> --- a/drivers/mailbox/arm_mhu.c
> +++ b/drivers/mailbox/arm_mhu.c
> @@ -110,7 +110,7 @@ static void mhu_shutdown(struct mbox_chan *chan)
> free_irq(mlink->irq, chan);
> }
>
> -static struct mbox_chan_ops mhu_ops = {
> +static const struct mbox_chan_ops mhu_ops = {
> .send_data = mhu_send_data,
> .startup = mhu_startup,
> .shutdown = mhu_shutdown,
> diff --git a/drivers/mailbox/mailbox-altera.c b/drivers/mailbox/mailbox-altera.c
> index a266265..bb682c9 100644
> --- a/drivers/mailbox/mailbox-altera.c
> +++ b/drivers/mailbox/mailbox-altera.c
> @@ -285,7 +285,7 @@ static void altera_mbox_shutdown(struct mbox_chan *chan)
> }
> }
>
> -static struct mbox_chan_ops altera_mbox_ops = {
> +static const struct mbox_chan_ops altera_mbox_ops = {
> .send_data = altera_mbox_send_data,
> .startup = altera_mbox_startup,
> .shutdown = altera_mbox_shutdown,
> diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
> index 0f332c1..03f8545 100644
> --- a/drivers/mailbox/omap-mailbox.c
> +++ b/drivers/mailbox/omap-mailbox.c
> @@ -604,7 +604,7 @@ static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
> return ret;
> }
>
> -static struct mbox_chan_ops omap_mbox_chan_ops = {
> +static const struct mbox_chan_ops omap_mbox_chan_ops = {
> .startup = omap_mbox_chan_startup,
> .send_data = omap_mbox_chan_send_data,
> .shutdown = omap_mbox_chan_shutdown,
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 7e91d68..26d121d 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -198,7 +198,7 @@ static int pcc_send_data(struct mbox_chan *chan, void *data)
> return 0;
> }
>
> -static struct mbox_chan_ops pcc_chan_ops = {
> +static const struct mbox_chan_ops pcc_chan_ops = {
> .send_data = pcc_send_data,
> };
>
> diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
> index d4cf96f..68c4245 100644
> --- a/include/linux/mailbox_controller.h
> +++ b/include/linux/mailbox_controller.h
> @@ -72,7 +72,7 @@ struct mbox_chan_ops {
> */
> struct mbox_controller {
> struct device *dev;
> - struct mbox_chan_ops *ops;
> + const struct mbox_chan_ops *ops;
> struct mbox_chan *chans;
> int num_chans;
> bool txdone_irq;
>
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 2/9] mailbox: Make mbox_chan_ops const
@ 2015-05-04 19:22 ` Suman Anna
0 siblings, 0 replies; 136+ messages in thread
From: Suman Anna @ 2015-05-04 19:22 UTC (permalink / raw)
To: Andrew Bresticker, Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Jon Hunter, Jassi Brar, Ashwin Chaugule,
Ley Foon Tan
On 05/04/2015 12:36 PM, Andrew Bresticker wrote:
> The mailbox controller's channel ops ought to be read-only. Update
> all the mailbox drivers to make their mbox_chan_ops const as well.
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Suman Anna <s-anna@ti.com>
> Cc: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> Cc: Ley Foon Tan <lftan@altera.com>
Thanks, the new patch looks good.
Acked-by: Suman Anna <s-anna@ti.com>
> ---
> Changes from v7:
> - Constify all drivers' mbox_chan_ops.
> No changes from v5/v6.
> New for v5.
> ---
> drivers/mailbox/arm_mhu.c | 2 +-
> drivers/mailbox/mailbox-altera.c | 2 +-
> drivers/mailbox/omap-mailbox.c | 2 +-
> drivers/mailbox/pcc.c | 2 +-
> include/linux/mailbox_controller.h | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mailbox/arm_mhu.c b/drivers/mailbox/arm_mhu.c
> index ac693c6..d9e99f9 100644
> --- a/drivers/mailbox/arm_mhu.c
> +++ b/drivers/mailbox/arm_mhu.c
> @@ -110,7 +110,7 @@ static void mhu_shutdown(struct mbox_chan *chan)
> free_irq(mlink->irq, chan);
> }
>
> -static struct mbox_chan_ops mhu_ops = {
> +static const struct mbox_chan_ops mhu_ops = {
> .send_data = mhu_send_data,
> .startup = mhu_startup,
> .shutdown = mhu_shutdown,
> diff --git a/drivers/mailbox/mailbox-altera.c b/drivers/mailbox/mailbox-altera.c
> index a266265..bb682c9 100644
> --- a/drivers/mailbox/mailbox-altera.c
> +++ b/drivers/mailbox/mailbox-altera.c
> @@ -285,7 +285,7 @@ static void altera_mbox_shutdown(struct mbox_chan *chan)
> }
> }
>
> -static struct mbox_chan_ops altera_mbox_ops = {
> +static const struct mbox_chan_ops altera_mbox_ops = {
> .send_data = altera_mbox_send_data,
> .startup = altera_mbox_startup,
> .shutdown = altera_mbox_shutdown,
> diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
> index 0f332c1..03f8545 100644
> --- a/drivers/mailbox/omap-mailbox.c
> +++ b/drivers/mailbox/omap-mailbox.c
> @@ -604,7 +604,7 @@ static int omap_mbox_chan_send_data(struct mbox_chan *chan, void *data)
> return ret;
> }
>
> -static struct mbox_chan_ops omap_mbox_chan_ops = {
> +static const struct mbox_chan_ops omap_mbox_chan_ops = {
> .startup = omap_mbox_chan_startup,
> .send_data = omap_mbox_chan_send_data,
> .shutdown = omap_mbox_chan_shutdown,
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 7e91d68..26d121d 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -198,7 +198,7 @@ static int pcc_send_data(struct mbox_chan *chan, void *data)
> return 0;
> }
>
> -static struct mbox_chan_ops pcc_chan_ops = {
> +static const struct mbox_chan_ops pcc_chan_ops = {
> .send_data = pcc_send_data,
> };
>
> diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
> index d4cf96f..68c4245 100644
> --- a/include/linux/mailbox_controller.h
> +++ b/include/linux/mailbox_controller.h
> @@ -72,7 +72,7 @@ struct mbox_chan_ops {
> */
> struct mbox_controller {
> struct device *dev;
> - struct mbox_chan_ops *ops;
> + const struct mbox_chan_ops *ops;
> struct mbox_chan *chans;
> int num_chans;
> bool txdone_irq;
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v8 3/9] mailbox: Fix up error handling in mbox_request_channel()
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-04 17:36 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bresticker,
Jon Hunter, Benson Leung, Jassi Brar
From: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
mbox_request_channel() currently returns EBUSY in the event the controller
is not present or if of_xlate() fails, but in neither case is EBUSY really
appropriate. Return EPROBE_DEFER if the controller is not yet present
and change of_xlate() to return an ERR_PTR instead of NULL so that the
error can be propagated back to the caller of mbox_request_channel().
Signed-off-by: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Acked-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
Cc: Jassi Brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
No changes from v7.
Changes from v6:
- Update omap-mailbox's xlate() to return error codes.
No changes from v5.
New for v5.
---
drivers/mailbox/mailbox.c | 11 ++++++++---
drivers/mailbox/omap-mailbox.c | 6 +++---
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 19b491d..c3c42d4 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -318,7 +318,7 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
return ERR_PTR(-ENODEV);
}
- chan = NULL;
+ chan = ERR_PTR(-EPROBE_DEFER);
list_for_each_entry(mbox, &mbox_cons, node)
if (mbox->dev->of_node == spec.np) {
chan = mbox->of_xlate(mbox, &spec);
@@ -327,7 +327,12 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
of_node_put(spec.np);
- if (!chan || chan->cl || !try_module_get(mbox->dev->driver->owner)) {
+ if (IS_ERR(chan)) {
+ mutex_unlock(&con_mutex);
+ return chan;
+ }
+
+ if (chan->cl || !try_module_get(mbox->dev->driver->owner)) {
dev_dbg(dev, "%s: mailbox not free\n", __func__);
mutex_unlock(&con_mutex);
return ERR_PTR(-EBUSY);
@@ -390,7 +395,7 @@ of_mbox_index_xlate(struct mbox_controller *mbox,
int ind = sp->args[0];
if (ind >= mbox->num_chans)
- return NULL;
+ return ERR_PTR(-EINVAL);
return &mbox->chans[ind];
}
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 03f8545..a3dbfd9 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -639,18 +639,18 @@ static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
mdev = container_of(controller, struct omap_mbox_device, controller);
if (WARN_ON(!mdev))
- return NULL;
+ return ERR_PTR(-EINVAL);
node = of_find_node_by_phandle(phandle);
if (!node) {
pr_err("%s: could not find node phandle 0x%x\n",
__func__, phandle);
- return NULL;
+ return ERR_PTR(-ENODEV);
}
mbox = omap_mbox_device_find(mdev, node->name);
of_node_put(node);
- return mbox ? mbox->chan : NULL;
+ return mbox ? mbox->chan : ERR_PTR(-ENOENT);
}
static int omap_mbox_probe(struct platform_device *pdev)
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 3/9] mailbox: Fix up error handling in mbox_request_channel()
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: linux-arm-kernel
From: Benson Leung <bleung@chromium.org>
mbox_request_channel() currently returns EBUSY in the event the controller
is not present or if of_xlate() fails, but in neither case is EBUSY really
appropriate. Return EPROBE_DEFER if the controller is not yet present
and change of_xlate() to return an ERR_PTR instead of NULL so that the
error can be propagated back to the caller of mbox_request_channel().
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Acked-by: Suman Anna <s-anna@ti.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
---
No changes from v7.
Changes from v6:
- Update omap-mailbox's xlate() to return error codes.
No changes from v5.
New for v5.
---
drivers/mailbox/mailbox.c | 11 ++++++++---
drivers/mailbox/omap-mailbox.c | 6 +++---
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 19b491d..c3c42d4 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -318,7 +318,7 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
return ERR_PTR(-ENODEV);
}
- chan = NULL;
+ chan = ERR_PTR(-EPROBE_DEFER);
list_for_each_entry(mbox, &mbox_cons, node)
if (mbox->dev->of_node == spec.np) {
chan = mbox->of_xlate(mbox, &spec);
@@ -327,7 +327,12 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
of_node_put(spec.np);
- if (!chan || chan->cl || !try_module_get(mbox->dev->driver->owner)) {
+ if (IS_ERR(chan)) {
+ mutex_unlock(&con_mutex);
+ return chan;
+ }
+
+ if (chan->cl || !try_module_get(mbox->dev->driver->owner)) {
dev_dbg(dev, "%s: mailbox not free\n", __func__);
mutex_unlock(&con_mutex);
return ERR_PTR(-EBUSY);
@@ -390,7 +395,7 @@ of_mbox_index_xlate(struct mbox_controller *mbox,
int ind = sp->args[0];
if (ind >= mbox->num_chans)
- return NULL;
+ return ERR_PTR(-EINVAL);
return &mbox->chans[ind];
}
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 03f8545..a3dbfd9 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -639,18 +639,18 @@ static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
mdev = container_of(controller, struct omap_mbox_device, controller);
if (WARN_ON(!mdev))
- return NULL;
+ return ERR_PTR(-EINVAL);
node = of_find_node_by_phandle(phandle);
if (!node) {
pr_err("%s: could not find node phandle 0x%x\n",
__func__, phandle);
- return NULL;
+ return ERR_PTR(-ENODEV);
}
mbox = omap_mbox_device_find(mdev, node->name);
of_node_put(node);
- return mbox ? mbox->chan : NULL;
+ return mbox ? mbox->chan : ERR_PTR(-ENOENT);
}
static int omap_mbox_probe(struct platform_device *pdev)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 3/9] mailbox: Fix up error handling in mbox_request_channel()
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Andrew Bresticker, Jon Hunter, Benson Leung,
Jassi Brar
From: Benson Leung <bleung@chromium.org>
mbox_request_channel() currently returns EBUSY in the event the controller
is not present or if of_xlate() fails, but in neither case is EBUSY really
appropriate. Return EPROBE_DEFER if the controller is not yet present
and change of_xlate() to return an ERR_PTR instead of NULL so that the
error can be propagated back to the caller of mbox_request_channel().
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Acked-by: Suman Anna <s-anna@ti.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
---
No changes from v7.
Changes from v6:
- Update omap-mailbox's xlate() to return error codes.
No changes from v5.
New for v5.
---
drivers/mailbox/mailbox.c | 11 ++++++++---
drivers/mailbox/omap-mailbox.c | 6 +++---
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 19b491d..c3c42d4 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -318,7 +318,7 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
return ERR_PTR(-ENODEV);
}
- chan = NULL;
+ chan = ERR_PTR(-EPROBE_DEFER);
list_for_each_entry(mbox, &mbox_cons, node)
if (mbox->dev->of_node == spec.np) {
chan = mbox->of_xlate(mbox, &spec);
@@ -327,7 +327,12 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
of_node_put(spec.np);
- if (!chan || chan->cl || !try_module_get(mbox->dev->driver->owner)) {
+ if (IS_ERR(chan)) {
+ mutex_unlock(&con_mutex);
+ return chan;
+ }
+
+ if (chan->cl || !try_module_get(mbox->dev->driver->owner)) {
dev_dbg(dev, "%s: mailbox not free\n", __func__);
mutex_unlock(&con_mutex);
return ERR_PTR(-EBUSY);
@@ -390,7 +395,7 @@ of_mbox_index_xlate(struct mbox_controller *mbox,
int ind = sp->args[0];
if (ind >= mbox->num_chans)
- return NULL;
+ return ERR_PTR(-EINVAL);
return &mbox->chans[ind];
}
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 03f8545..a3dbfd9 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -639,18 +639,18 @@ static struct mbox_chan *omap_mbox_of_xlate(struct mbox_controller *controller,
mdev = container_of(controller, struct omap_mbox_device, controller);
if (WARN_ON(!mdev))
- return NULL;
+ return ERR_PTR(-EINVAL);
node = of_find_node_by_phandle(phandle);
if (!node) {
pr_err("%s: could not find node phandle 0x%x\n",
__func__, phandle);
- return NULL;
+ return ERR_PTR(-ENODEV);
}
mbox = omap_mbox_device_find(mdev, node->name);
of_node_put(node);
- return mbox ? mbox->chan : NULL;
+ return mbox ? mbox->chan : ERR_PTR(-ENOENT);
}
static int omap_mbox_probe(struct platform_device *pdev)
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-04 17:36 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bresticker,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Samuel Ortiz, Lee Jones
Add a binding document for the XUSB host complex on NVIDIA Tegra124
and later SoCs. The XUSB host complex includes a mailbox for
communication with the XUSB micro-controller and an xHCI host-controller.
Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Changes from v7:
- Move non-shared resources into child nodes.
New for v7.
---
.../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
new file mode 100644
index 0000000..bc50110
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
@@ -0,0 +1,37 @@
+NVIDIA Tegra XUSB host copmlex
+==============================
+
+The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
+controller and a mailbox for communication with the XUSB micro-controller.
+
+Required properties:
+--------------------
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
+ Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
+ where <chip> is tegra132.
+ - reg: Must contain the base and length of the XUSB FPCI registers.
+ - ranges: Bus address mapping for the XUSB block. Can be empty since the
+ mapping is 1:1.
+ - #address-cells: Must be 2.
+ - #size-cells: Must be 2.
+
+Example:
+--------
+ usb@0,70098000 {
+ compatible = "nvidia,tegra124-xusb";
+ reg = <0x0 0x70098000 0x0 0x1000>;
+ ranges;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ usb-host@0,70090000 {
+ compatible = "nvidia,tegra124-xhci";
+ ...
+ };
+
+ mailbox {
+ compatible = "nvidia,tegra124-xusb-mbox";
+ ...
+ };
+ };
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: linux-arm-kernel
Add a binding document for the XUSB host complex on NVIDIA Tegra124
and later SoCs. The XUSB host complex includes a mailbox for
communication with the XUSB micro-controller and an xHCI host-controller.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Lee Jones <lee.jones@linaro.org>
---
Changes from v7:
- Move non-shared resources into child nodes.
New for v7.
---
.../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
new file mode 100644
index 0000000..bc50110
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
@@ -0,0 +1,37 @@
+NVIDIA Tegra XUSB host copmlex
+==============================
+
+The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
+controller and a mailbox for communication with the XUSB micro-controller.
+
+Required properties:
+--------------------
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
+ Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
+ where <chip> is tegra132.
+ - reg: Must contain the base and length of the XUSB FPCI registers.
+ - ranges: Bus address mapping for the XUSB block. Can be empty since the
+ mapping is 1:1.
+ - #address-cells: Must be 2.
+ - #size-cells: Must be 2.
+
+Example:
+--------
+ usb at 0,70098000 {
+ compatible = "nvidia,tegra124-xusb";
+ reg = <0x0 0x70098000 0x0 0x1000>;
+ ranges;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ usb-host at 0,70090000 {
+ compatible = "nvidia,tegra124-xhci";
+ ...
+ };
+
+ mailbox {
+ compatible = "nvidia,tegra124-xusb-mbox";
+ ...
+ };
+ };
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Andrew Bresticker, Jon Hunter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz,
Lee Jones
Add a binding document for the XUSB host complex on NVIDIA Tegra124
and later SoCs. The XUSB host complex includes a mailbox for
communication with the XUSB micro-controller and an xHCI host-controller.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Lee Jones <lee.jones@linaro.org>
---
Changes from v7:
- Move non-shared resources into child nodes.
New for v7.
---
.../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
new file mode 100644
index 0000000..bc50110
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
@@ -0,0 +1,37 @@
+NVIDIA Tegra XUSB host copmlex
+==============================
+
+The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
+controller and a mailbox for communication with the XUSB micro-controller.
+
+Required properties:
+--------------------
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
+ Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
+ where <chip> is tegra132.
+ - reg: Must contain the base and length of the XUSB FPCI registers.
+ - ranges: Bus address mapping for the XUSB block. Can be empty since the
+ mapping is 1:1.
+ - #address-cells: Must be 2.
+ - #size-cells: Must be 2.
+
+Example:
+--------
+ usb@0,70098000 {
+ compatible = "nvidia,tegra124-xusb";
+ reg = <0x0 0x70098000 0x0 0x1000>;
+ ranges;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ usb-host@0,70090000 {
+ compatible = "nvidia,tegra124-xhci";
+ ...
+ };
+
+ mailbox {
+ compatible = "nvidia,tegra124-xusb-mbox";
+ ...
+ };
+ };
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread[parent not found: <1430761002-9327-5-git-send-email-abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-13 14:39 ` Lee Jones
-1 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-13 14:39 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jon Hunter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Mon, 04 May 2015, Andrew Bresticker wrote:
> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> and later SoCs. The XUSB host complex includes a mailbox for
> communication with the XUSB micro-controller and an xHCI host-controller.
>
> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Changes from v7:
> - Move non-shared resources into child nodes.
> New for v7.
> ---
> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> new file mode 100644
> index 0000000..bc50110
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> @@ -0,0 +1,37 @@
> +NVIDIA Tegra XUSB host copmlex
> +==============================
> +
> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> +controller and a mailbox for communication with the XUSB micro-controller.
> +
> +Required properties:
> +--------------------
> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> + where <chip> is tegra132.
> + - reg: Must contain the base and length of the XUSB FPCI registers.
> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> + mapping is 1:1.
> + - #address-cells: Must be 2.
> + - #size-cells: Must be 2.
> +
> +Example:
> +--------
> + usb@0,70098000 {
> + compatible = "nvidia,tegra124-xusb";
> + reg = <0x0 0x70098000 0x0 0x1000>;
> + ranges;
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + usb-host@0,70090000 {
> + compatible = "nvidia,tegra124-xhci";
> + ...
> + };
> +
> + mailbox {
> + compatible = "nvidia,tegra124-xusb-mbox";
> + ...
> + };
This doesn't appear to be a proper MFD. I would have the USB and
Mailbox devices probe seperately and use a phandle to point the USB
device to its Mailbox.
usb@xyz {
mboxes = <&xusb-mailbox, [chan]>;
};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-13 14:39 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-13 14:39 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 04 May 2015, Andrew Bresticker wrote:
> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> and later SoCs. The XUSB host complex includes a mailbox for
> communication with the XUSB micro-controller and an xHCI host-controller.
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> ---
> Changes from v7:
> - Move non-shared resources into child nodes.
> New for v7.
> ---
> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> new file mode 100644
> index 0000000..bc50110
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> @@ -0,0 +1,37 @@
> +NVIDIA Tegra XUSB host copmlex
> +==============================
> +
> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> +controller and a mailbox for communication with the XUSB micro-controller.
> +
> +Required properties:
> +--------------------
> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> + where <chip> is tegra132.
> + - reg: Must contain the base and length of the XUSB FPCI registers.
> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> + mapping is 1:1.
> + - #address-cells: Must be 2.
> + - #size-cells: Must be 2.
> +
> +Example:
> +--------
> + usb at 0,70098000 {
> + compatible = "nvidia,tegra124-xusb";
> + reg = <0x0 0x70098000 0x0 0x1000>;
> + ranges;
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + usb-host at 0,70090000 {
> + compatible = "nvidia,tegra124-xhci";
> + ...
> + };
> +
> + mailbox {
> + compatible = "nvidia,tegra124-xusb-mbox";
> + ...
> + };
This doesn't appear to be a proper MFD. I would have the USB and
Mailbox devices probe seperately and use a phandle to point the USB
device to its Mailbox.
usb at xyz {
mboxes = <&xusb-mailbox, [chan]>;
};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-13 14:39 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-13 14:39 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Samuel Ortiz
On Mon, 04 May 2015, Andrew Bresticker wrote:
> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> and later SoCs. The XUSB host complex includes a mailbox for
> communication with the XUSB micro-controller and an xHCI host-controller.
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> ---
> Changes from v7:
> - Move non-shared resources into child nodes.
> New for v7.
> ---
> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> new file mode 100644
> index 0000000..bc50110
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> @@ -0,0 +1,37 @@
> +NVIDIA Tegra XUSB host copmlex
> +==============================
> +
> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> +controller and a mailbox for communication with the XUSB micro-controller.
> +
> +Required properties:
> +--------------------
> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> + where <chip> is tegra132.
> + - reg: Must contain the base and length of the XUSB FPCI registers.
> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> + mapping is 1:1.
> + - #address-cells: Must be 2.
> + - #size-cells: Must be 2.
> +
> +Example:
> +--------
> + usb@0,70098000 {
> + compatible = "nvidia,tegra124-xusb";
> + reg = <0x0 0x70098000 0x0 0x1000>;
> + ranges;
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + usb-host@0,70090000 {
> + compatible = "nvidia,tegra124-xhci";
> + ...
> + };
> +
> + mailbox {
> + compatible = "nvidia,tegra124-xusb-mbox";
> + ...
> + };
This doesn't appear to be a proper MFD. I would have the USB and
Mailbox devices probe seperately and use a phandle to point the USB
device to its Mailbox.
usb@xyz {
mboxes = <&xusb-mailbox, [chan]>;
};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-13 14:39 ` Lee Jones
(?)
@ 2015-05-13 16:26 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-13 16:26 UTC (permalink / raw)
To: Lee Jones
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jon Hunter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
Lee,
On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Mon, 04 May 2015, Andrew Bresticker wrote:
>
>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> and later SoCs. The XUSB host complex includes a mailbox for
>> communication with the XUSB micro-controller and an xHCI host-controller.
>>
>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> Changes from v7:
>> - Move non-shared resources into child nodes.
>> New for v7.
>> ---
>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> new file mode 100644
>> index 0000000..bc50110
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> @@ -0,0 +1,37 @@
>> +NVIDIA Tegra XUSB host copmlex
>> +==============================
>> +
>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> +controller and a mailbox for communication with the XUSB micro-controller.
>> +
>> +Required properties:
>> +--------------------
>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> + where <chip> is tegra132.
>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> + mapping is 1:1.
>> + - #address-cells: Must be 2.
>> + - #size-cells: Must be 2.
>> +
>> +Example:
>> +--------
>> + usb@0,70098000 {
>> + compatible = "nvidia,tegra124-xusb";
>> + reg = <0x0 0x70098000 0x0 0x1000>;
>> + ranges;
>> +
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + usb-host@0,70090000 {
>> + compatible = "nvidia,tegra124-xhci";
>> + ...
>> + };
>> +
>> + mailbox {
>> + compatible = "nvidia,tegra124-xusb-mbox";
>> + ...
>> + };
>
> This doesn't appear to be a proper MFD. I would have the USB and
> Mailbox devices probe seperately and use a phandle to point the USB
> device to its Mailbox.
>
> usb@xyz {
> mboxes = <&xusb-mailbox, [chan]>;
> };
Then what will set up the shared regmap? The point of using an MFD
here was to share a register set with both the mailbox and xHCI
drivers and avoid having to map the same register set twice in two
separate drivers.
Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-13 16:26 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-13 16:26 UTC (permalink / raw)
To: linux-arm-kernel
Lee,
On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Mon, 04 May 2015, Andrew Bresticker wrote:
>
>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> and later SoCs. The XUSB host complex includes a mailbox for
>> communication with the XUSB micro-controller and an xHCI host-controller.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> ---
>> Changes from v7:
>> - Move non-shared resources into child nodes.
>> New for v7.
>> ---
>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> new file mode 100644
>> index 0000000..bc50110
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> @@ -0,0 +1,37 @@
>> +NVIDIA Tegra XUSB host copmlex
>> +==============================
>> +
>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> +controller and a mailbox for communication with the XUSB micro-controller.
>> +
>> +Required properties:
>> +--------------------
>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> + where <chip> is tegra132.
>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> + mapping is 1:1.
>> + - #address-cells: Must be 2.
>> + - #size-cells: Must be 2.
>> +
>> +Example:
>> +--------
>> + usb at 0,70098000 {
>> + compatible = "nvidia,tegra124-xusb";
>> + reg = <0x0 0x70098000 0x0 0x1000>;
>> + ranges;
>> +
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + usb-host at 0,70090000 {
>> + compatible = "nvidia,tegra124-xhci";
>> + ...
>> + };
>> +
>> + mailbox {
>> + compatible = "nvidia,tegra124-xusb-mbox";
>> + ...
>> + };
>
> This doesn't appear to be a proper MFD. I would have the USB and
> Mailbox devices probe seperately and use a phandle to point the USB
> device to its Mailbox.
>
> usb at xyz {
> mboxes = <&xusb-mailbox, [chan]>;
> };
Then what will set up the shared regmap? The point of using an MFD
here was to share a register set with both the mailbox and xHCI
drivers and avoid having to map the same register set twice in two
separate drivers.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-13 16:26 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-13 16:26 UTC (permalink / raw)
To: Lee Jones
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Samuel Ortiz
Lee,
On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Mon, 04 May 2015, Andrew Bresticker wrote:
>
>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> and later SoCs. The XUSB host complex includes a mailbox for
>> communication with the XUSB micro-controller and an xHCI host-controller.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> ---
>> Changes from v7:
>> - Move non-shared resources into child nodes.
>> New for v7.
>> ---
>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> new file mode 100644
>> index 0000000..bc50110
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> @@ -0,0 +1,37 @@
>> +NVIDIA Tegra XUSB host copmlex
>> +==============================
>> +
>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> +controller and a mailbox for communication with the XUSB micro-controller.
>> +
>> +Required properties:
>> +--------------------
>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> + where <chip> is tegra132.
>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> + mapping is 1:1.
>> + - #address-cells: Must be 2.
>> + - #size-cells: Must be 2.
>> +
>> +Example:
>> +--------
>> + usb@0,70098000 {
>> + compatible = "nvidia,tegra124-xusb";
>> + reg = <0x0 0x70098000 0x0 0x1000>;
>> + ranges;
>> +
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + usb-host@0,70090000 {
>> + compatible = "nvidia,tegra124-xhci";
>> + ...
>> + };
>> +
>> + mailbox {
>> + compatible = "nvidia,tegra124-xusb-mbox";
>> + ...
>> + };
>
> This doesn't appear to be a proper MFD. I would have the USB and
> Mailbox devices probe seperately and use a phandle to point the USB
> device to its Mailbox.
>
> usb@xyz {
> mboxes = <&xusb-mailbox, [chan]>;
> };
Then what will set up the shared regmap? The point of using an MFD
here was to share a register set with both the mailbox and xHCI
drivers and avoid having to map the same register set twice in two
separate drivers.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread[parent not found: <CAL1qeaF-7aAx0gqPe-_D4ZaZET0Kejr801KrbvuQ_2w6c8mcnA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-13 16:26 ` Andrew Bresticker
(?)
@ 2015-05-13 16:50 ` Lee Jones
-1 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-13 16:50 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jon Hunter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Wed, 13 May 2015, Andrew Bresticker wrote:
> Lee,
>
> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >
> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >> and later SoCs. The XUSB host complex includes a mailbox for
> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> ---
> >> Changes from v7:
> >> - Move non-shared resources into child nodes.
> >> New for v7.
> >> ---
> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >> 1 file changed, 37 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> new file mode 100644
> >> index 0000000..bc50110
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> @@ -0,0 +1,37 @@
> >> +NVIDIA Tegra XUSB host copmlex
> >> +==============================
> >> +
> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >> +
> >> +Required properties:
> >> +--------------------
> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >> + where <chip> is tegra132.
> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >> + mapping is 1:1.
> >> + - #address-cells: Must be 2.
> >> + - #size-cells: Must be 2.
> >> +
> >> +Example:
> >> +--------
> >> + usb@0,70098000 {
> >> + compatible = "nvidia,tegra124-xusb";
> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >> + ranges;
> >> +
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >> +
> >> + usb-host@0,70090000 {
> >> + compatible = "nvidia,tegra124-xhci";
> >> + ...
> >> + };
> >> +
> >> + mailbox {
> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >> + ...
> >> + };
> >
> > This doesn't appear to be a proper MFD. I would have the USB and
> > Mailbox devices probe seperately and use a phandle to point the USB
> > device to its Mailbox.
> >
> > usb@xyz {
> > mboxes = <&xusb-mailbox, [chan]>;
> > };
>
> Then what will set up the shared regmap? The point of using an MFD
> here was to share a register set with both the mailbox and xHCI
> drivers and avoid having to map the same register set twice in two
> separate drivers.
Can you share the mapping please?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-13 16:50 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-13 16:50 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 13 May 2015, Andrew Bresticker wrote:
> Lee,
>
> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >
> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >> and later SoCs. The XUSB host complex includes a mailbox for
> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> Cc: Pawel Moll <pawel.moll@arm.com>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >> Cc: Kumar Gala <galak@codeaurora.org>
> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >> Cc: Lee Jones <lee.jones@linaro.org>
> >> ---
> >> Changes from v7:
> >> - Move non-shared resources into child nodes.
> >> New for v7.
> >> ---
> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >> 1 file changed, 37 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> new file mode 100644
> >> index 0000000..bc50110
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> @@ -0,0 +1,37 @@
> >> +NVIDIA Tegra XUSB host copmlex
> >> +==============================
> >> +
> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >> +
> >> +Required properties:
> >> +--------------------
> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >> + where <chip> is tegra132.
> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >> + mapping is 1:1.
> >> + - #address-cells: Must be 2.
> >> + - #size-cells: Must be 2.
> >> +
> >> +Example:
> >> +--------
> >> + usb at 0,70098000 {
> >> + compatible = "nvidia,tegra124-xusb";
> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >> + ranges;
> >> +
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >> +
> >> + usb-host at 0,70090000 {
> >> + compatible = "nvidia,tegra124-xhci";
> >> + ...
> >> + };
> >> +
> >> + mailbox {
> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >> + ...
> >> + };
> >
> > This doesn't appear to be a proper MFD. I would have the USB and
> > Mailbox devices probe seperately and use a phandle to point the USB
> > device to its Mailbox.
> >
> > usb at xyz {
> > mboxes = <&xusb-mailbox, [chan]>;
> > };
>
> Then what will set up the shared regmap? The point of using an MFD
> here was to share a register set with both the mailbox and xHCI
> drivers and avoid having to map the same register set twice in two
> separate drivers.
Can you share the mapping please?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-13 16:50 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-13 16:50 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Samuel Ortiz
On Wed, 13 May 2015, Andrew Bresticker wrote:
> Lee,
>
> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >
> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >> and later SoCs. The XUSB host complex includes a mailbox for
> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> Cc: Pawel Moll <pawel.moll@arm.com>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >> Cc: Kumar Gala <galak@codeaurora.org>
> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >> Cc: Lee Jones <lee.jones@linaro.org>
> >> ---
> >> Changes from v7:
> >> - Move non-shared resources into child nodes.
> >> New for v7.
> >> ---
> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >> 1 file changed, 37 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> new file mode 100644
> >> index 0000000..bc50110
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> @@ -0,0 +1,37 @@
> >> +NVIDIA Tegra XUSB host copmlex
> >> +==============================
> >> +
> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >> +
> >> +Required properties:
> >> +--------------------
> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >> + where <chip> is tegra132.
> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >> + mapping is 1:1.
> >> + - #address-cells: Must be 2.
> >> + - #size-cells: Must be 2.
> >> +
> >> +Example:
> >> +--------
> >> + usb@0,70098000 {
> >> + compatible = "nvidia,tegra124-xusb";
> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >> + ranges;
> >> +
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >> +
> >> + usb-host@0,70090000 {
> >> + compatible = "nvidia,tegra124-xhci";
> >> + ...
> >> + };
> >> +
> >> + mailbox {
> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >> + ...
> >> + };
> >
> > This doesn't appear to be a proper MFD. I would have the USB and
> > Mailbox devices probe seperately and use a phandle to point the USB
> > device to its Mailbox.
> >
> > usb@xyz {
> > mboxes = <&xusb-mailbox, [chan]>;
> > };
>
> Then what will set up the shared regmap? The point of using an MFD
> here was to share a register set with both the mailbox and xHCI
> drivers and avoid having to map the same register set twice in two
> separate drivers.
Can you share the mapping please?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-13 16:50 ` Lee Jones
(?)
@ 2015-05-13 17:03 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-13 17:03 UTC (permalink / raw)
To: Lee Jones
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jon Hunter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Wed, 13 May 2015, Andrew Bresticker wrote:
>
>> Lee,
>>
>> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
>> >
>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> >> and later SoCs. The XUSB host complex includes a mailbox for
>> >> communication with the XUSB micro-controller and an xHCI host-controller.
>> >>
>> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> >> ---
>> >> Changes from v7:
>> >> - Move non-shared resources into child nodes.
>> >> New for v7.
>> >> ---
>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> >> 1 file changed, 37 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> new file mode 100644
>> >> index 0000000..bc50110
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> @@ -0,0 +1,37 @@
>> >> +NVIDIA Tegra XUSB host copmlex
>> >> +==============================
>> >> +
>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> >> +controller and a mailbox for communication with the XUSB micro-controller.
>> >> +
>> >> +Required properties:
>> >> +--------------------
>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> >> + where <chip> is tegra132.
>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> >> + mapping is 1:1.
>> >> + - #address-cells: Must be 2.
>> >> + - #size-cells: Must be 2.
>> >> +
>> >> +Example:
>> >> +--------
>> >> + usb@0,70098000 {
>> >> + compatible = "nvidia,tegra124-xusb";
>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
>> >> + ranges;
>> >> +
>> >> + #address-cells = <2>;
>> >> + #size-cells = <2>;
>> >> +
>> >> + usb-host@0,70090000 {
>> >> + compatible = "nvidia,tegra124-xhci";
>> >> + ...
>> >> + };
>> >> +
>> >> + mailbox {
>> >> + compatible = "nvidia,tegra124-xusb-mbox";
>> >> + ...
>> >> + };
>> >
>> > This doesn't appear to be a proper MFD. I would have the USB and
>> > Mailbox devices probe seperately and use a phandle to point the USB
>> > device to its Mailbox.
>> >
>> > usb@xyz {
>> > mboxes = <&xusb-mailbox, [chan]>;
>> > };
>>
>> Then what will set up the shared regmap? The point of using an MFD
>> here was to share a register set with both the mailbox and xHCI
>> drivers and avoid having to map the same register set twice in two
>> separate drivers.
>
> Can you share the mapping please?
What do you mean? That's what the MFD is doing now by setting up an
MMIO regmap to be shared between the two devices.
Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-13 17:03 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-13 17:03 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 13 May 2015, Andrew Bresticker wrote:
>
>> Lee,
>>
>> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
>> >
>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> >> and later SoCs. The XUSB host complex includes a mailbox for
>> >> communication with the XUSB micro-controller and an xHCI host-controller.
>> >>
>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> >> Cc: Rob Herring <robh+dt@kernel.org>
>> >> Cc: Pawel Moll <pawel.moll@arm.com>
>> >> Cc: Mark Rutland <mark.rutland@arm.com>
>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> >> Cc: Kumar Gala <galak@codeaurora.org>
>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
>> >> Cc: Lee Jones <lee.jones@linaro.org>
>> >> ---
>> >> Changes from v7:
>> >> - Move non-shared resources into child nodes.
>> >> New for v7.
>> >> ---
>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> >> 1 file changed, 37 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> new file mode 100644
>> >> index 0000000..bc50110
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> @@ -0,0 +1,37 @@
>> >> +NVIDIA Tegra XUSB host copmlex
>> >> +==============================
>> >> +
>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> >> +controller and a mailbox for communication with the XUSB micro-controller.
>> >> +
>> >> +Required properties:
>> >> +--------------------
>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> >> + where <chip> is tegra132.
>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> >> + mapping is 1:1.
>> >> + - #address-cells: Must be 2.
>> >> + - #size-cells: Must be 2.
>> >> +
>> >> +Example:
>> >> +--------
>> >> + usb at 0,70098000 {
>> >> + compatible = "nvidia,tegra124-xusb";
>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
>> >> + ranges;
>> >> +
>> >> + #address-cells = <2>;
>> >> + #size-cells = <2>;
>> >> +
>> >> + usb-host at 0,70090000 {
>> >> + compatible = "nvidia,tegra124-xhci";
>> >> + ...
>> >> + };
>> >> +
>> >> + mailbox {
>> >> + compatible = "nvidia,tegra124-xusb-mbox";
>> >> + ...
>> >> + };
>> >
>> > This doesn't appear to be a proper MFD. I would have the USB and
>> > Mailbox devices probe seperately and use a phandle to point the USB
>> > device to its Mailbox.
>> >
>> > usb at xyz {
>> > mboxes = <&xusb-mailbox, [chan]>;
>> > };
>>
>> Then what will set up the shared regmap? The point of using an MFD
>> here was to share a register set with both the mailbox and xHCI
>> drivers and avoid having to map the same register set twice in two
>> separate drivers.
>
> Can you share the mapping please?
What do you mean? That's what the MFD is doing now by setting up an
MMIO regmap to be shared between the two devices.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-13 17:03 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-13 17:03 UTC (permalink / raw)
To: Lee Jones
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Samuel Ortiz
On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 13 May 2015, Andrew Bresticker wrote:
>
>> Lee,
>>
>> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
>> >
>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> >> and later SoCs. The XUSB host complex includes a mailbox for
>> >> communication with the XUSB micro-controller and an xHCI host-controller.
>> >>
>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> >> Cc: Rob Herring <robh+dt@kernel.org>
>> >> Cc: Pawel Moll <pawel.moll@arm.com>
>> >> Cc: Mark Rutland <mark.rutland@arm.com>
>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> >> Cc: Kumar Gala <galak@codeaurora.org>
>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
>> >> Cc: Lee Jones <lee.jones@linaro.org>
>> >> ---
>> >> Changes from v7:
>> >> - Move non-shared resources into child nodes.
>> >> New for v7.
>> >> ---
>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> >> 1 file changed, 37 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> new file mode 100644
>> >> index 0000000..bc50110
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> @@ -0,0 +1,37 @@
>> >> +NVIDIA Tegra XUSB host copmlex
>> >> +==============================
>> >> +
>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> >> +controller and a mailbox for communication with the XUSB micro-controller.
>> >> +
>> >> +Required properties:
>> >> +--------------------
>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> >> + where <chip> is tegra132.
>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> >> + mapping is 1:1.
>> >> + - #address-cells: Must be 2.
>> >> + - #size-cells: Must be 2.
>> >> +
>> >> +Example:
>> >> +--------
>> >> + usb@0,70098000 {
>> >> + compatible = "nvidia,tegra124-xusb";
>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
>> >> + ranges;
>> >> +
>> >> + #address-cells = <2>;
>> >> + #size-cells = <2>;
>> >> +
>> >> + usb-host@0,70090000 {
>> >> + compatible = "nvidia,tegra124-xhci";
>> >> + ...
>> >> + };
>> >> +
>> >> + mailbox {
>> >> + compatible = "nvidia,tegra124-xusb-mbox";
>> >> + ...
>> >> + };
>> >
>> > This doesn't appear to be a proper MFD. I would have the USB and
>> > Mailbox devices probe seperately and use a phandle to point the USB
>> > device to its Mailbox.
>> >
>> > usb@xyz {
>> > mboxes = <&xusb-mailbox, [chan]>;
>> > };
>>
>> Then what will set up the shared regmap? The point of using an MFD
>> here was to share a register set with both the mailbox and xHCI
>> drivers and avoid having to map the same register set twice in two
>> separate drivers.
>
> Can you share the mapping please?
What do you mean? That's what the MFD is doing now by setting up an
MMIO regmap to be shared between the two devices.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread[parent not found: <CAL1qeaE7XHmreQ_b52iop6fOY1osAhjij81c4vVr7_8wO_cYxQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-13 17:03 ` Andrew Bresticker
(?)
@ 2015-05-14 7:29 ` Lee Jones
-1 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 7:29 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jon Hunter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Wed, 13 May 2015, Andrew Bresticker wrote:
> On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Wed, 13 May 2015, Andrew Bresticker wrote:
> >
> >> Lee,
> >>
> >> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >> >
> >> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >> >> and later SoCs. The XUSB host complex includes a mailbox for
> >> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >> >>
> >> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> >> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> >> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> >> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> >> ---
> >> >> Changes from v7:
> >> >> - Move non-shared resources into child nodes.
> >> >> New for v7.
> >> >> ---
> >> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >> >> 1 file changed, 37 insertions(+)
> >> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> >> new file mode 100644
> >> >> index 0000000..bc50110
> >> >> --- /dev/null
> >> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> >> @@ -0,0 +1,37 @@
> >> >> +NVIDIA Tegra XUSB host copmlex
> >> >> +==============================
> >> >> +
> >> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >> >> +
> >> >> +Required properties:
> >> >> +--------------------
> >> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >> >> + where <chip> is tegra132.
> >> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >> >> + mapping is 1:1.
> >> >> + - #address-cells: Must be 2.
> >> >> + - #size-cells: Must be 2.
> >> >> +
> >> >> +Example:
> >> >> +--------
> >> >> + usb@0,70098000 {
> >> >> + compatible = "nvidia,tegra124-xusb";
> >> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >> >> + ranges;
> >> >> +
> >> >> + #address-cells = <2>;
> >> >> + #size-cells = <2>;
> >> >> +
> >> >> + usb-host@0,70090000 {
> >> >> + compatible = "nvidia,tegra124-xhci";
> >> >> + ...
> >> >> + };
> >> >> +
> >> >> + mailbox {
> >> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >> >> + ...
> >> >> + };
> >> >
> >> > This doesn't appear to be a proper MFD. I would have the USB and
> >> > Mailbox devices probe seperately and use a phandle to point the USB
> >> > device to its Mailbox.
> >> >
> >> > usb@xyz {
> >> > mboxes = <&xusb-mailbox, [chan]>;
> >> > };
> >>
> >> Then what will set up the shared regmap? The point of using an MFD
> >> here was to share a register set with both the mailbox and xHCI
> >> drivers and avoid having to map the same register set twice in two
> >> separate drivers.
> >
> > Can you share the mapping please?
>
> What do you mean? That's what the MFD is doing now by setting up an
> MMIO regmap to be shared between the two devices.
I mean, can you share the documentation with me. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 7:29 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 7:29 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 13 May 2015, Andrew Bresticker wrote:
> On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Wed, 13 May 2015, Andrew Bresticker wrote:
> >
> >> Lee,
> >>
> >> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >> >
> >> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >> >> and later SoCs. The XUSB host complex includes a mailbox for
> >> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >> >>
> >> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> >> Cc: Pawel Moll <pawel.moll@arm.com>
> >> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >> >> Cc: Kumar Gala <galak@codeaurora.org>
> >> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >> >> Cc: Lee Jones <lee.jones@linaro.org>
> >> >> ---
> >> >> Changes from v7:
> >> >> - Move non-shared resources into child nodes.
> >> >> New for v7.
> >> >> ---
> >> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >> >> 1 file changed, 37 insertions(+)
> >> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> >> new file mode 100644
> >> >> index 0000000..bc50110
> >> >> --- /dev/null
> >> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> >> @@ -0,0 +1,37 @@
> >> >> +NVIDIA Tegra XUSB host copmlex
> >> >> +==============================
> >> >> +
> >> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >> >> +
> >> >> +Required properties:
> >> >> +--------------------
> >> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >> >> + where <chip> is tegra132.
> >> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >> >> + mapping is 1:1.
> >> >> + - #address-cells: Must be 2.
> >> >> + - #size-cells: Must be 2.
> >> >> +
> >> >> +Example:
> >> >> +--------
> >> >> + usb at 0,70098000 {
> >> >> + compatible = "nvidia,tegra124-xusb";
> >> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >> >> + ranges;
> >> >> +
> >> >> + #address-cells = <2>;
> >> >> + #size-cells = <2>;
> >> >> +
> >> >> + usb-host at 0,70090000 {
> >> >> + compatible = "nvidia,tegra124-xhci";
> >> >> + ...
> >> >> + };
> >> >> +
> >> >> + mailbox {
> >> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >> >> + ...
> >> >> + };
> >> >
> >> > This doesn't appear to be a proper MFD. I would have the USB and
> >> > Mailbox devices probe seperately and use a phandle to point the USB
> >> > device to its Mailbox.
> >> >
> >> > usb at xyz {
> >> > mboxes = <&xusb-mailbox, [chan]>;
> >> > };
> >>
> >> Then what will set up the shared regmap? The point of using an MFD
> >> here was to share a register set with both the mailbox and xHCI
> >> drivers and avoid having to map the same register set twice in two
> >> separate drivers.
> >
> > Can you share the mapping please?
>
> What do you mean? That's what the MFD is doing now by setting up an
> MMIO regmap to be shared between the two devices.
I mean, can you share the documentation with me. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 7:29 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 7:29 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Samuel Ortiz
On Wed, 13 May 2015, Andrew Bresticker wrote:
> On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Wed, 13 May 2015, Andrew Bresticker wrote:
> >
> >> Lee,
> >>
> >> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >> >
> >> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >> >> and later SoCs. The XUSB host complex includes a mailbox for
> >> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >> >>
> >> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> >> Cc: Pawel Moll <pawel.moll@arm.com>
> >> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >> >> Cc: Kumar Gala <galak@codeaurora.org>
> >> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >> >> Cc: Lee Jones <lee.jones@linaro.org>
> >> >> ---
> >> >> Changes from v7:
> >> >> - Move non-shared resources into child nodes.
> >> >> New for v7.
> >> >> ---
> >> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >> >> 1 file changed, 37 insertions(+)
> >> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> >> new file mode 100644
> >> >> index 0000000..bc50110
> >> >> --- /dev/null
> >> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> >> @@ -0,0 +1,37 @@
> >> >> +NVIDIA Tegra XUSB host copmlex
> >> >> +==============================
> >> >> +
> >> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >> >> +
> >> >> +Required properties:
> >> >> +--------------------
> >> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >> >> + where <chip> is tegra132.
> >> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >> >> + mapping is 1:1.
> >> >> + - #address-cells: Must be 2.
> >> >> + - #size-cells: Must be 2.
> >> >> +
> >> >> +Example:
> >> >> +--------
> >> >> + usb@0,70098000 {
> >> >> + compatible = "nvidia,tegra124-xusb";
> >> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >> >> + ranges;
> >> >> +
> >> >> + #address-cells = <2>;
> >> >> + #size-cells = <2>;
> >> >> +
> >> >> + usb-host@0,70090000 {
> >> >> + compatible = "nvidia,tegra124-xhci";
> >> >> + ...
> >> >> + };
> >> >> +
> >> >> + mailbox {
> >> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >> >> + ...
> >> >> + };
> >> >
> >> > This doesn't appear to be a proper MFD. I would have the USB and
> >> > Mailbox devices probe seperately and use a phandle to point the USB
> >> > device to its Mailbox.
> >> >
> >> > usb@xyz {
> >> > mboxes = <&xusb-mailbox, [chan]>;
> >> > };
> >>
> >> Then what will set up the shared regmap? The point of using an MFD
> >> here was to share a register set with both the mailbox and xHCI
> >> drivers and avoid having to map the same register set twice in two
> >> separate drivers.
> >
> > Can you share the mapping please?
>
> What do you mean? That's what the MFD is doing now by setting up an
> MMIO regmap to be shared between the two devices.
I mean, can you share the documentation with me. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-14 7:29 ` Lee Jones
(?)
@ 2015-05-14 7:32 ` Jon Hunter
-1 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 7:32 UTC (permalink / raw)
To: Lee Jones, Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On 14/05/15 08:29, Lee Jones wrote:
> On Wed, 13 May 2015, Andrew Bresticker wrote:
>
>> On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> On Wed, 13 May 2015, Andrew Bresticker wrote:
>>>
>>>> Lee,
>>>>
>>>> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>>>
>>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>>>
>>>>>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>>>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>>>>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>>>>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>>>>>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>>>> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>>>> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>>> ---
>>>>>> Changes from v7:
>>>>>> - Move non-shared resources into child nodes.
>>>>>> New for v7.
>>>>>> ---
>>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>>>> 1 file changed, 37 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..bc50110
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> @@ -0,0 +1,37 @@
>>>>>> +NVIDIA Tegra XUSB host copmlex
>>>>>> +==============================
>>>>>> +
>>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +--------------------
>>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>>>> + where <chip> is tegra132.
>>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>>>> + mapping is 1:1.
>>>>>> + - #address-cells: Must be 2.
>>>>>> + - #size-cells: Must be 2.
>>>>>> +
>>>>>> +Example:
>>>>>> +--------
>>>>>> + usb@0,70098000 {
>>>>>> + compatible = "nvidia,tegra124-xusb";
>>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>>>> + ranges;
>>>>>> +
>>>>>> + #address-cells = <2>;
>>>>>> + #size-cells = <2>;
>>>>>> +
>>>>>> + usb-host@0,70090000 {
>>>>>> + compatible = "nvidia,tegra124-xhci";
>>>>>> + ...
>>>>>> + };
>>>>>> +
>>>>>> + mailbox {
>>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>>>> + ...
>>>>>> + };
>>>>>
>>>>> This doesn't appear to be a proper MFD. I would have the USB and
>>>>> Mailbox devices probe seperately and use a phandle to point the USB
>>>>> device to its Mailbox.
>>>>>
>>>>> usb@xyz {
>>>>> mboxes = <&xusb-mailbox, [chan]>;
>>>>> };
>>>>
>>>> Then what will set up the shared regmap? The point of using an MFD
>>>> here was to share a register set with both the mailbox and xHCI
>>>> drivers and avoid having to map the same register set twice in two
>>>> separate drivers.
>>>
>>> Can you share the mapping please?
>>
>> What do you mean? That's what the MFD is doing now by setting up an
>> MMIO regmap to be shared between the two devices.
>
> I mean, can you share the documentation with me. :)
You can download the documentation from here [1]. See chapter 19 USB
complex. However, I will warn you that unfortunately, you need to sign
up for an account :-(
Cheers
Jon
[1] https://developer.nvidia.com/tegra-k1-technical-reference-manual
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 7:32 ` Jon Hunter
0 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 7:32 UTC (permalink / raw)
To: linux-arm-kernel
On 14/05/15 08:29, Lee Jones wrote:
> On Wed, 13 May 2015, Andrew Bresticker wrote:
>
>> On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
>>> On Wed, 13 May 2015, Andrew Bresticker wrote:
>>>
>>>> Lee,
>>>>
>>>> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
>>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>>>
>>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>>>
>>>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>>>>>> Cc: Lee Jones <lee.jones@linaro.org>
>>>>>> ---
>>>>>> Changes from v7:
>>>>>> - Move non-shared resources into child nodes.
>>>>>> New for v7.
>>>>>> ---
>>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>>>> 1 file changed, 37 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..bc50110
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> @@ -0,0 +1,37 @@
>>>>>> +NVIDIA Tegra XUSB host copmlex
>>>>>> +==============================
>>>>>> +
>>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +--------------------
>>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>>>> + where <chip> is tegra132.
>>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>>>> + mapping is 1:1.
>>>>>> + - #address-cells: Must be 2.
>>>>>> + - #size-cells: Must be 2.
>>>>>> +
>>>>>> +Example:
>>>>>> +--------
>>>>>> + usb at 0,70098000 {
>>>>>> + compatible = "nvidia,tegra124-xusb";
>>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>>>> + ranges;
>>>>>> +
>>>>>> + #address-cells = <2>;
>>>>>> + #size-cells = <2>;
>>>>>> +
>>>>>> + usb-host at 0,70090000 {
>>>>>> + compatible = "nvidia,tegra124-xhci";
>>>>>> + ...
>>>>>> + };
>>>>>> +
>>>>>> + mailbox {
>>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>>>> + ...
>>>>>> + };
>>>>>
>>>>> This doesn't appear to be a proper MFD. I would have the USB and
>>>>> Mailbox devices probe seperately and use a phandle to point the USB
>>>>> device to its Mailbox.
>>>>>
>>>>> usb at xyz {
>>>>> mboxes = <&xusb-mailbox, [chan]>;
>>>>> };
>>>>
>>>> Then what will set up the shared regmap? The point of using an MFD
>>>> here was to share a register set with both the mailbox and xHCI
>>>> drivers and avoid having to map the same register set twice in two
>>>> separate drivers.
>>>
>>> Can you share the mapping please?
>>
>> What do you mean? That's what the MFD is doing now by setting up an
>> MMIO regmap to be shared between the two devices.
>
> I mean, can you share the documentation with me. :)
You can download the documentation from here [1]. See chapter 19 USB
complex. However, I will warn you that unfortunately, you need to sign
up for an account :-(
Cheers
Jon
[1] https://developer.nvidia.com/tegra-k1-technical-reference-manual
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 7:32 ` Jon Hunter
0 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 7:32 UTC (permalink / raw)
To: Lee Jones, Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Samuel Ortiz
On 14/05/15 08:29, Lee Jones wrote:
> On Wed, 13 May 2015, Andrew Bresticker wrote:
>
>> On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
>>> On Wed, 13 May 2015, Andrew Bresticker wrote:
>>>
>>>> Lee,
>>>>
>>>> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
>>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>>>
>>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>>>
>>>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>>>>>> Cc: Lee Jones <lee.jones@linaro.org>
>>>>>> ---
>>>>>> Changes from v7:
>>>>>> - Move non-shared resources into child nodes.
>>>>>> New for v7.
>>>>>> ---
>>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>>>> 1 file changed, 37 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..bc50110
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> @@ -0,0 +1,37 @@
>>>>>> +NVIDIA Tegra XUSB host copmlex
>>>>>> +==============================
>>>>>> +
>>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +--------------------
>>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>>>> + where <chip> is tegra132.
>>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>>>> + mapping is 1:1.
>>>>>> + - #address-cells: Must be 2.
>>>>>> + - #size-cells: Must be 2.
>>>>>> +
>>>>>> +Example:
>>>>>> +--------
>>>>>> + usb@0,70098000 {
>>>>>> + compatible = "nvidia,tegra124-xusb";
>>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>>>> + ranges;
>>>>>> +
>>>>>> + #address-cells = <2>;
>>>>>> + #size-cells = <2>;
>>>>>> +
>>>>>> + usb-host@0,70090000 {
>>>>>> + compatible = "nvidia,tegra124-xhci";
>>>>>> + ...
>>>>>> + };
>>>>>> +
>>>>>> + mailbox {
>>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>>>> + ...
>>>>>> + };
>>>>>
>>>>> This doesn't appear to be a proper MFD. I would have the USB and
>>>>> Mailbox devices probe seperately and use a phandle to point the USB
>>>>> device to its Mailbox.
>>>>>
>>>>> usb@xyz {
>>>>> mboxes = <&xusb-mailbox, [chan]>;
>>>>> };
>>>>
>>>> Then what will set up the shared regmap? The point of using an MFD
>>>> here was to share a register set with both the mailbox and xHCI
>>>> drivers and avoid having to map the same register set twice in two
>>>> separate drivers.
>>>
>>> Can you share the mapping please?
>>
>> What do you mean? That's what the MFD is doing now by setting up an
>> MMIO regmap to be shared between the two devices.
>
> I mean, can you share the documentation with me. :)
You can download the documentation from here [1]. See chapter 19 USB
complex. However, I will warn you that unfortunately, you need to sign
up for an account :-(
Cheers
Jon
[1] https://developer.nvidia.com/tegra-k1-technical-reference-manual
^ permalink raw reply [flat|nested] 136+ messages in thread[parent not found: <55544F91.4060402-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-14 7:32 ` Jon Hunter
(?)
@ 2015-05-14 7:45 ` Lee Jones
-1 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 7:45 UTC (permalink / raw)
To: Jon Hunter
Cc: Andrew Bresticker, Stephen Warren, Thierry Reding,
Alexandre Courbot, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, 14 May 2015, Jon Hunter wrote:
>
> On 14/05/15 08:29, Lee Jones wrote:
> > On Wed, 13 May 2015, Andrew Bresticker wrote:
> >
> >> On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >>> On Wed, 13 May 2015, Andrew Bresticker wrote:
> >>>
> >>>> Lee,
> >>>>
> >>>> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>>>>
> >>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>>>>> and later SoCs. The XUSB host complex includes a mailbox for
> >>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
> >>>>>>
> >>>>>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >>>>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>>>>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> >>>>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> >>>>>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> >>>>>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >>>>>> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >>>>>> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>>>>> ---
> >>>>>> Changes from v7:
> >>>>>> - Move non-shared resources into child nodes.
> >>>>>> New for v7.
> >>>>>> ---
> >>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>>>>> 1 file changed, 37 insertions(+)
> >>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> new file mode 100644
> >>>>>> index 0000000..bc50110
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> @@ -0,0 +1,37 @@
> >>>>>> +NVIDIA Tegra XUSB host copmlex
> >>>>>> +==============================
> >>>>>> +
> >>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +--------------------
> >>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>>>>> + where <chip> is tegra132.
> >>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>>>>> + mapping is 1:1.
> >>>>>> + - #address-cells: Must be 2.
> >>>>>> + - #size-cells: Must be 2.
> >>>>>> +
> >>>>>> +Example:
> >>>>>> +--------
> >>>>>> + usb@0,70098000 {
> >>>>>> + compatible = "nvidia,tegra124-xusb";
> >>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>>>>> + ranges;
> >>>>>> +
> >>>>>> + #address-cells = <2>;
> >>>>>> + #size-cells = <2>;
> >>>>>> +
> >>>>>> + usb-host@0,70090000 {
> >>>>>> + compatible = "nvidia,tegra124-xhci";
> >>>>>> + ...
> >>>>>> + };
> >>>>>> +
> >>>>>> + mailbox {
> >>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
> >>>>>> + ...
> >>>>>> + };
> >>>>>
> >>>>> This doesn't appear to be a proper MFD. I would have the USB and
> >>>>> Mailbox devices probe seperately and use a phandle to point the USB
> >>>>> device to its Mailbox.
> >>>>>
> >>>>> usb@xyz {
> >>>>> mboxes = <&xusb-mailbox, [chan]>;
> >>>>> };
> >>>>
> >>>> Then what will set up the shared regmap? The point of using an MFD
> >>>> here was to share a register set with both the mailbox and xHCI
> >>>> drivers and avoid having to map the same register set twice in two
> >>>> separate drivers.
> >>>
> >>> Can you share the mapping please?
> >>
> >> What do you mean? That's what the MFD is doing now by setting up an
> >> MMIO regmap to be shared between the two devices.
> >
> > I mean, can you share the documentation with me. :)
>
> You can download the documentation from here [1]. See chapter 19 USB
> complex. However, I will warn you that unfortunately, you need to sign
> up for an account :-(
I'll give that a miss for the time being. See my other mail for now.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 7:45 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 7:45 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 14 May 2015, Jon Hunter wrote:
>
> On 14/05/15 08:29, Lee Jones wrote:
> > On Wed, 13 May 2015, Andrew Bresticker wrote:
> >
> >> On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >>> On Wed, 13 May 2015, Andrew Bresticker wrote:
> >>>
> >>>> Lee,
> >>>>
> >>>> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>>>>
> >>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>>>>> and later SoCs. The XUSB host complex includes a mailbox for
> >>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
> >>>>>>
> >>>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>>> Cc: Pawel Moll <pawel.moll@arm.com>
> >>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
> >>>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >>>>>> Cc: Kumar Gala <galak@codeaurora.org>
> >>>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >>>>>> Cc: Lee Jones <lee.jones@linaro.org>
> >>>>>> ---
> >>>>>> Changes from v7:
> >>>>>> - Move non-shared resources into child nodes.
> >>>>>> New for v7.
> >>>>>> ---
> >>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>>>>> 1 file changed, 37 insertions(+)
> >>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> new file mode 100644
> >>>>>> index 0000000..bc50110
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> @@ -0,0 +1,37 @@
> >>>>>> +NVIDIA Tegra XUSB host copmlex
> >>>>>> +==============================
> >>>>>> +
> >>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +--------------------
> >>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>>>>> + where <chip> is tegra132.
> >>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>>>>> + mapping is 1:1.
> >>>>>> + - #address-cells: Must be 2.
> >>>>>> + - #size-cells: Must be 2.
> >>>>>> +
> >>>>>> +Example:
> >>>>>> +--------
> >>>>>> + usb at 0,70098000 {
> >>>>>> + compatible = "nvidia,tegra124-xusb";
> >>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>>>>> + ranges;
> >>>>>> +
> >>>>>> + #address-cells = <2>;
> >>>>>> + #size-cells = <2>;
> >>>>>> +
> >>>>>> + usb-host at 0,70090000 {
> >>>>>> + compatible = "nvidia,tegra124-xhci";
> >>>>>> + ...
> >>>>>> + };
> >>>>>> +
> >>>>>> + mailbox {
> >>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
> >>>>>> + ...
> >>>>>> + };
> >>>>>
> >>>>> This doesn't appear to be a proper MFD. I would have the USB and
> >>>>> Mailbox devices probe seperately and use a phandle to point the USB
> >>>>> device to its Mailbox.
> >>>>>
> >>>>> usb at xyz {
> >>>>> mboxes = <&xusb-mailbox, [chan]>;
> >>>>> };
> >>>>
> >>>> Then what will set up the shared regmap? The point of using an MFD
> >>>> here was to share a register set with both the mailbox and xHCI
> >>>> drivers and avoid having to map the same register set twice in two
> >>>> separate drivers.
> >>>
> >>> Can you share the mapping please?
> >>
> >> What do you mean? That's what the MFD is doing now by setting up an
> >> MMIO regmap to be shared between the two devices.
> >
> > I mean, can you share the documentation with me. :)
>
> You can download the documentation from here [1]. See chapter 19 USB
> complex. However, I will warn you that unfortunately, you need to sign
> up for an account :-(
I'll give that a miss for the time being. See my other mail for now.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 7:45 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 7:45 UTC (permalink / raw)
To: Jon Hunter
Cc: Andrew Bresticker, Stephen Warren, Thierry Reding,
Alexandre Courbot, devicetree, linux-tegra, linux-usb,
linux-arm-kernel, linux-kernel, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, 14 May 2015, Jon Hunter wrote:
>
> On 14/05/15 08:29, Lee Jones wrote:
> > On Wed, 13 May 2015, Andrew Bresticker wrote:
> >
> >> On Wed, May 13, 2015 at 9:50 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >>> On Wed, 13 May 2015, Andrew Bresticker wrote:
> >>>
> >>>> Lee,
> >>>>
> >>>> On Wed, May 13, 2015 at 7:39 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>>>>
> >>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>>>>> and later SoCs. The XUSB host complex includes a mailbox for
> >>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
> >>>>>>
> >>>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>>> Cc: Pawel Moll <pawel.moll@arm.com>
> >>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
> >>>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >>>>>> Cc: Kumar Gala <galak@codeaurora.org>
> >>>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >>>>>> Cc: Lee Jones <lee.jones@linaro.org>
> >>>>>> ---
> >>>>>> Changes from v7:
> >>>>>> - Move non-shared resources into child nodes.
> >>>>>> New for v7.
> >>>>>> ---
> >>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>>>>> 1 file changed, 37 insertions(+)
> >>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> new file mode 100644
> >>>>>> index 0000000..bc50110
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> @@ -0,0 +1,37 @@
> >>>>>> +NVIDIA Tegra XUSB host copmlex
> >>>>>> +==============================
> >>>>>> +
> >>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +--------------------
> >>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>>>>> + where <chip> is tegra132.
> >>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>>>>> + mapping is 1:1.
> >>>>>> + - #address-cells: Must be 2.
> >>>>>> + - #size-cells: Must be 2.
> >>>>>> +
> >>>>>> +Example:
> >>>>>> +--------
> >>>>>> + usb@0,70098000 {
> >>>>>> + compatible = "nvidia,tegra124-xusb";
> >>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>>>>> + ranges;
> >>>>>> +
> >>>>>> + #address-cells = <2>;
> >>>>>> + #size-cells = <2>;
> >>>>>> +
> >>>>>> + usb-host@0,70090000 {
> >>>>>> + compatible = "nvidia,tegra124-xhci";
> >>>>>> + ...
> >>>>>> + };
> >>>>>> +
> >>>>>> + mailbox {
> >>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
> >>>>>> + ...
> >>>>>> + };
> >>>>>
> >>>>> This doesn't appear to be a proper MFD. I would have the USB and
> >>>>> Mailbox devices probe seperately and use a phandle to point the USB
> >>>>> device to its Mailbox.
> >>>>>
> >>>>> usb@xyz {
> >>>>> mboxes = <&xusb-mailbox, [chan]>;
> >>>>> };
> >>>>
> >>>> Then what will set up the shared regmap? The point of using an MFD
> >>>> here was to share a register set with both the mailbox and xHCI
> >>>> drivers and avoid having to map the same register set twice in two
> >>>> separate drivers.
> >>>
> >>> Can you share the mapping please?
> >>
> >> What do you mean? That's what the MFD is doing now by setting up an
> >> MMIO regmap to be shared between the two devices.
> >
> > I mean, can you share the documentation with me. :)
>
> You can download the documentation from here [1]. See chapter 19 USB
> complex. However, I will warn you that unfortunately, you need to sign
> up for an account :-(
I'll give that a miss for the time being. See my other mail for now.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-13 14:39 ` Lee Jones
(?)
@ 2015-05-14 7:20 ` Jon Hunter
-1 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 7:20 UTC (permalink / raw)
To: Lee Jones, Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
Hi Lee,
On 13/05/15 15:39, Lee Jones wrote:
> On Mon, 04 May 2015, Andrew Bresticker wrote:
>
>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> and later SoCs. The XUSB host complex includes a mailbox for
>> communication with the XUSB micro-controller and an xHCI host-controller.
>>
>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> Changes from v7:
>> - Move non-shared resources into child nodes.
>> New for v7.
>> ---
>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> new file mode 100644
>> index 0000000..bc50110
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> @@ -0,0 +1,37 @@
>> +NVIDIA Tegra XUSB host copmlex
>> +==============================
>> +
>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> +controller and a mailbox for communication with the XUSB micro-controller.
>> +
>> +Required properties:
>> +--------------------
>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> + where <chip> is tegra132.
>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> + mapping is 1:1.
>> + - #address-cells: Must be 2.
>> + - #size-cells: Must be 2.
>> +
>> +Example:
>> +--------
>> + usb@0,70098000 {
>> + compatible = "nvidia,tegra124-xusb";
>> + reg = <0x0 0x70098000 0x0 0x1000>;
>> + ranges;
>> +
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + usb-host@0,70090000 {
>> + compatible = "nvidia,tegra124-xhci";
>> + ...
>> + };
>> +
>> + mailbox {
>> + compatible = "nvidia,tegra124-xusb-mbox";
>> + ...
>> + };
>
> This doesn't appear to be a proper MFD. I would have the USB and
> Mailbox devices probe seperately and use a phandle to point the USB
> device to its Mailbox.
>
> usb@xyz {
> mboxes = <&xusb-mailbox, [chan]>;
> };
>
I am assuming that Andrew had laid it out like this to reflect the hw
structure. The mailbox and xhci controller are part of the xusb
sub-system and hence appear as child nodes. My understanding is that for
device-tree we want the device-tree structure to reflect the actual hw.
Is this not the case?
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 7:20 ` Jon Hunter
0 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 7:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lee,
On 13/05/15 15:39, Lee Jones wrote:
> On Mon, 04 May 2015, Andrew Bresticker wrote:
>
>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> and later SoCs. The XUSB host complex includes a mailbox for
>> communication with the XUSB micro-controller and an xHCI host-controller.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> ---
>> Changes from v7:
>> - Move non-shared resources into child nodes.
>> New for v7.
>> ---
>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> new file mode 100644
>> index 0000000..bc50110
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> @@ -0,0 +1,37 @@
>> +NVIDIA Tegra XUSB host copmlex
>> +==============================
>> +
>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> +controller and a mailbox for communication with the XUSB micro-controller.
>> +
>> +Required properties:
>> +--------------------
>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> + where <chip> is tegra132.
>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> + mapping is 1:1.
>> + - #address-cells: Must be 2.
>> + - #size-cells: Must be 2.
>> +
>> +Example:
>> +--------
>> + usb at 0,70098000 {
>> + compatible = "nvidia,tegra124-xusb";
>> + reg = <0x0 0x70098000 0x0 0x1000>;
>> + ranges;
>> +
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + usb-host at 0,70090000 {
>> + compatible = "nvidia,tegra124-xhci";
>> + ...
>> + };
>> +
>> + mailbox {
>> + compatible = "nvidia,tegra124-xusb-mbox";
>> + ...
>> + };
>
> This doesn't appear to be a proper MFD. I would have the USB and
> Mailbox devices probe seperately and use a phandle to point the USB
> device to its Mailbox.
>
> usb at xyz {
> mboxes = <&xusb-mailbox, [chan]>;
> };
>
I am assuming that Andrew had laid it out like this to reflect the hw
structure. The mailbox and xhci controller are part of the xusb
sub-system and hence appear as child nodes. My understanding is that for
device-tree we want the device-tree structure to reflect the actual hw.
Is this not the case?
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 7:20 ` Jon Hunter
0 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 7:20 UTC (permalink / raw)
To: Lee Jones, Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Samuel Ortiz
Hi Lee,
On 13/05/15 15:39, Lee Jones wrote:
> On Mon, 04 May 2015, Andrew Bresticker wrote:
>
>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> and later SoCs. The XUSB host complex includes a mailbox for
>> communication with the XUSB micro-controller and an xHCI host-controller.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> ---
>> Changes from v7:
>> - Move non-shared resources into child nodes.
>> New for v7.
>> ---
>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> new file mode 100644
>> index 0000000..bc50110
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> @@ -0,0 +1,37 @@
>> +NVIDIA Tegra XUSB host copmlex
>> +==============================
>> +
>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> +controller and a mailbox for communication with the XUSB micro-controller.
>> +
>> +Required properties:
>> +--------------------
>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> + where <chip> is tegra132.
>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> + mapping is 1:1.
>> + - #address-cells: Must be 2.
>> + - #size-cells: Must be 2.
>> +
>> +Example:
>> +--------
>> + usb@0,70098000 {
>> + compatible = "nvidia,tegra124-xusb";
>> + reg = <0x0 0x70098000 0x0 0x1000>;
>> + ranges;
>> +
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + usb-host@0,70090000 {
>> + compatible = "nvidia,tegra124-xhci";
>> + ...
>> + };
>> +
>> + mailbox {
>> + compatible = "nvidia,tegra124-xusb-mbox";
>> + ...
>> + };
>
> This doesn't appear to be a proper MFD. I would have the USB and
> Mailbox devices probe seperately and use a phandle to point the USB
> device to its Mailbox.
>
> usb@xyz {
> mboxes = <&xusb-mailbox, [chan]>;
> };
>
I am assuming that Andrew had laid it out like this to reflect the hw
structure. The mailbox and xhci controller are part of the xusb
sub-system and hence appear as child nodes. My understanding is that for
device-tree we want the device-tree structure to reflect the actual hw.
Is this not the case?
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread[parent not found: <55544CC5.9050001-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-14 7:20 ` Jon Hunter
(?)
@ 2015-05-14 7:40 ` Lee Jones
-1 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 7:40 UTC (permalink / raw)
To: Jon Hunter
Cc: Andrew Bresticker, Stephen Warren, Thierry Reding,
Alexandre Courbot, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, 14 May 2015, Jon Hunter wrote:
> Hi Lee,
>
> On 13/05/15 15:39, Lee Jones wrote:
> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >
> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >> and later SoCs. The XUSB host complex includes a mailbox for
> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> ---
> >> Changes from v7:
> >> - Move non-shared resources into child nodes.
> >> New for v7.
> >> ---
> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >> 1 file changed, 37 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> new file mode 100644
> >> index 0000000..bc50110
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> @@ -0,0 +1,37 @@
> >> +NVIDIA Tegra XUSB host copmlex
> >> +==============================
> >> +
> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >> +
> >> +Required properties:
> >> +--------------------
> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >> + where <chip> is tegra132.
> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >> + mapping is 1:1.
> >> + - #address-cells: Must be 2.
> >> + - #size-cells: Must be 2.
> >> +
> >> +Example:
> >> +--------
> >> + usb@0,70098000 {
> >> + compatible = "nvidia,tegra124-xusb";
> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >> + ranges;
> >> +
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >> +
> >> + usb-host@0,70090000 {
> >> + compatible = "nvidia,tegra124-xhci";
> >> + ...
> >> + };
> >> +
> >> + mailbox {
> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >> + ...
> >> + };
> >
> > This doesn't appear to be a proper MFD. I would have the USB and
> > Mailbox devices probe seperately and use a phandle to point the USB
> > device to its Mailbox.
> >
> > usb@xyz {
> > mboxes = <&xusb-mailbox, [chan]>;
> > };
> >
>
> I am assuming that Andrew had laid it out like this to reflect the hw
> structure. The mailbox and xhci controller are part of the xusb
> sub-system and hence appear as child nodes. My understanding is that for
> device-tree we want the device-tree structure to reflect the actual hw.
> Is this not the case?
Yes, the DT files should reflect h/w. I have requested to see what
the memory map looks like, so I might provide a more appropriate
solution to accepting a pretty pointless MFD.
Two solutions spring to mind. You can either call
of_platform_populate() from the USB driver, as some already do:
drivers/usb/dwc3/dwc3-exynos.c:
ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-keystone.c:
error = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-omap.c:
ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-qcom.c:
ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
drivers/usb/dwc3/dwc3-st.c:
ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/musb/musb_am335x.c:
ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
Or use the "simple-mfd", which is currently in -next:
git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 7:40 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 7:40 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 14 May 2015, Jon Hunter wrote:
> Hi Lee,
>
> On 13/05/15 15:39, Lee Jones wrote:
> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >
> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >> and later SoCs. The XUSB host complex includes a mailbox for
> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> Cc: Pawel Moll <pawel.moll@arm.com>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >> Cc: Kumar Gala <galak@codeaurora.org>
> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >> Cc: Lee Jones <lee.jones@linaro.org>
> >> ---
> >> Changes from v7:
> >> - Move non-shared resources into child nodes.
> >> New for v7.
> >> ---
> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >> 1 file changed, 37 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> new file mode 100644
> >> index 0000000..bc50110
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> @@ -0,0 +1,37 @@
> >> +NVIDIA Tegra XUSB host copmlex
> >> +==============================
> >> +
> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >> +
> >> +Required properties:
> >> +--------------------
> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >> + where <chip> is tegra132.
> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >> + mapping is 1:1.
> >> + - #address-cells: Must be 2.
> >> + - #size-cells: Must be 2.
> >> +
> >> +Example:
> >> +--------
> >> + usb at 0,70098000 {
> >> + compatible = "nvidia,tegra124-xusb";
> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >> + ranges;
> >> +
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >> +
> >> + usb-host at 0,70090000 {
> >> + compatible = "nvidia,tegra124-xhci";
> >> + ...
> >> + };
> >> +
> >> + mailbox {
> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >> + ...
> >> + };
> >
> > This doesn't appear to be a proper MFD. I would have the USB and
> > Mailbox devices probe seperately and use a phandle to point the USB
> > device to its Mailbox.
> >
> > usb at xyz {
> > mboxes = <&xusb-mailbox, [chan]>;
> > };
> >
>
> I am assuming that Andrew had laid it out like this to reflect the hw
> structure. The mailbox and xhci controller are part of the xusb
> sub-system and hence appear as child nodes. My understanding is that for
> device-tree we want the device-tree structure to reflect the actual hw.
> Is this not the case?
Yes, the DT files should reflect h/w. I have requested to see what
the memory map looks like, so I might provide a more appropriate
solution to accepting a pretty pointless MFD.
Two solutions spring to mind. You can either call
of_platform_populate() from the USB driver, as some already do:
drivers/usb/dwc3/dwc3-exynos.c:
ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-keystone.c:
error = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-omap.c:
ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-qcom.c:
ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
drivers/usb/dwc3/dwc3-st.c:
ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/musb/musb_am335x.c:
ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
Or use the "simple-mfd", which is currently in -next:
git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 7:40 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 7:40 UTC (permalink / raw)
To: Jon Hunter
Cc: Andrew Bresticker, Stephen Warren, Thierry Reding,
Alexandre Courbot, devicetree, linux-tegra, linux-usb,
linux-arm-kernel, linux-kernel, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, 14 May 2015, Jon Hunter wrote:
> Hi Lee,
>
> On 13/05/15 15:39, Lee Jones wrote:
> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >
> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >> and later SoCs. The XUSB host complex includes a mailbox for
> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> Cc: Pawel Moll <pawel.moll@arm.com>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >> Cc: Kumar Gala <galak@codeaurora.org>
> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >> Cc: Lee Jones <lee.jones@linaro.org>
> >> ---
> >> Changes from v7:
> >> - Move non-shared resources into child nodes.
> >> New for v7.
> >> ---
> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >> 1 file changed, 37 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> new file mode 100644
> >> index 0000000..bc50110
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >> @@ -0,0 +1,37 @@
> >> +NVIDIA Tegra XUSB host copmlex
> >> +==============================
> >> +
> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >> +
> >> +Required properties:
> >> +--------------------
> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >> + where <chip> is tegra132.
> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >> + mapping is 1:1.
> >> + - #address-cells: Must be 2.
> >> + - #size-cells: Must be 2.
> >> +
> >> +Example:
> >> +--------
> >> + usb@0,70098000 {
> >> + compatible = "nvidia,tegra124-xusb";
> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >> + ranges;
> >> +
> >> + #address-cells = <2>;
> >> + #size-cells = <2>;
> >> +
> >> + usb-host@0,70090000 {
> >> + compatible = "nvidia,tegra124-xhci";
> >> + ...
> >> + };
> >> +
> >> + mailbox {
> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >> + ...
> >> + };
> >
> > This doesn't appear to be a proper MFD. I would have the USB and
> > Mailbox devices probe seperately and use a phandle to point the USB
> > device to its Mailbox.
> >
> > usb@xyz {
> > mboxes = <&xusb-mailbox, [chan]>;
> > };
> >
>
> I am assuming that Andrew had laid it out like this to reflect the hw
> structure. The mailbox and xhci controller are part of the xusb
> sub-system and hence appear as child nodes. My understanding is that for
> device-tree we want the device-tree structure to reflect the actual hw.
> Is this not the case?
Yes, the DT files should reflect h/w. I have requested to see what
the memory map looks like, so I might provide a more appropriate
solution to accepting a pretty pointless MFD.
Two solutions spring to mind. You can either call
of_platform_populate() from the USB driver, as some already do:
drivers/usb/dwc3/dwc3-exynos.c:
ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-keystone.c:
error = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-omap.c:
ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/dwc3/dwc3-qcom.c:
ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
drivers/usb/dwc3/dwc3-st.c:
ret = of_platform_populate(node, NULL, NULL, dev);
drivers/usb/musb/musb_am335x.c:
ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
Or use the "simple-mfd", which is currently in -next:
git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-14 7:40 ` Lee Jones
(?)
@ 2015-05-14 9:14 ` Jon Hunter
-1 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 9:14 UTC (permalink / raw)
To: Lee Jones
Cc: Andrew Bresticker, Stephen Warren, Thierry Reding,
Alexandre Courbot, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On 14/05/15 08:40, Lee Jones wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>
>> Hi Lee,
>>
>> On 13/05/15 15:39, Lee Jones wrote:
>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>
>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>
>>>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>>>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>> ---
>>>> Changes from v7:
>>>> - Move non-shared resources into child nodes.
>>>> New for v7.
>>>> ---
>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>> 1 file changed, 37 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>> new file mode 100644
>>>> index 0000000..bc50110
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>> @@ -0,0 +1,37 @@
>>>> +NVIDIA Tegra XUSB host copmlex
>>>> +==============================
>>>> +
>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>> +
>>>> +Required properties:
>>>> +--------------------
>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>> + where <chip> is tegra132.
>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>> + mapping is 1:1.
>>>> + - #address-cells: Must be 2.
>>>> + - #size-cells: Must be 2.
>>>> +
>>>> +Example:
>>>> +--------
>>>> + usb@0,70098000 {
>>>> + compatible = "nvidia,tegra124-xusb";
>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>> + ranges;
>>>> +
>>>> + #address-cells = <2>;
>>>> + #size-cells = <2>;
>>>> +
>>>> + usb-host@0,70090000 {
>>>> + compatible = "nvidia,tegra124-xhci";
>>>> + ...
>>>> + };
>>>> +
>>>> + mailbox {
>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>> + ...
>>>> + };
>>>
>>> This doesn't appear to be a proper MFD. I would have the USB and
>>> Mailbox devices probe seperately and use a phandle to point the USB
>>> device to its Mailbox.
>>>
>>> usb@xyz {
>>> mboxes = <&xusb-mailbox, [chan]>;
>>> };
>>>
>>
>> I am assuming that Andrew had laid it out like this to reflect the hw
>> structure. The mailbox and xhci controller are part of the xusb
>> sub-system and hence appear as child nodes. My understanding is that for
>> device-tree we want the device-tree structure to reflect the actual hw.
>> Is this not the case?
>
> Yes, the DT files should reflect h/w. I have requested to see what
> the memory map looks like, so I might provide a more appropriate
> solution to accepting a pretty pointless MFD.
For the xusb-host has memory from 0x7009000 - 0x7009ffff.
Within this range, we have this fpci range which is defined as 0x7009800
- 0x70098fff. This range is being shared between the mailbox and xhci
drivers. Looking at the drivers, we have ...
mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
So it is a bit messy as they overlap. However, we could have ...
xusb_mbox: mailbox {
compatible = "nvidia,tegra124-xusb-mbox";
reg = <0x0 0x700980e0 0x0 0x14>,
<0x0 0x70098428 0x0 0x4>;
...
};
usb-host@0,70090000 {
compatible = "nvidia,tegra124-xhci";
reg = <0x0 0x70090000 0x0 0x8000>,
<0x0 0x70098000 0x0 0x00d0>;
<0x0 0x70098800 0x0 0x0004>;
<0x0 0x70099000 0x0 0x1000>;
...
};
I believe that Thierry and Stephen said that they wished to avoid
multiple devices sharing the same memory ranges, and so we would need to
divvy up the memory map as above. However, I am not sure if this is an
ok thing to do.
> Two solutions spring to mind. You can either call
> of_platform_populate() from the USB driver, as some already do:
>
> drivers/usb/dwc3/dwc3-exynos.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-keystone.c:
> error = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-omap.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-qcom.c:
> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> drivers/usb/dwc3/dwc3-st.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/musb/musb_am335x.c:
> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>
> Or use the "simple-mfd", which is currently in -next:
>
> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
That is nice. Sounds like the "simple-bus" style of device but for an
mfd. Based upon the above, let me know if you think we could use the
"simple-mfd"?
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 9:14 ` Jon Hunter
0 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 9:14 UTC (permalink / raw)
To: linux-arm-kernel
On 14/05/15 08:40, Lee Jones wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>
>> Hi Lee,
>>
>> On 13/05/15 15:39, Lee Jones wrote:
>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>
>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>
>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>>>> Cc: Lee Jones <lee.jones@linaro.org>
>>>> ---
>>>> Changes from v7:
>>>> - Move non-shared resources into child nodes.
>>>> New for v7.
>>>> ---
>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>> 1 file changed, 37 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>> new file mode 100644
>>>> index 0000000..bc50110
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>> @@ -0,0 +1,37 @@
>>>> +NVIDIA Tegra XUSB host copmlex
>>>> +==============================
>>>> +
>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>> +
>>>> +Required properties:
>>>> +--------------------
>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>> + where <chip> is tegra132.
>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>> + mapping is 1:1.
>>>> + - #address-cells: Must be 2.
>>>> + - #size-cells: Must be 2.
>>>> +
>>>> +Example:
>>>> +--------
>>>> + usb at 0,70098000 {
>>>> + compatible = "nvidia,tegra124-xusb";
>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>> + ranges;
>>>> +
>>>> + #address-cells = <2>;
>>>> + #size-cells = <2>;
>>>> +
>>>> + usb-host at 0,70090000 {
>>>> + compatible = "nvidia,tegra124-xhci";
>>>> + ...
>>>> + };
>>>> +
>>>> + mailbox {
>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>> + ...
>>>> + };
>>>
>>> This doesn't appear to be a proper MFD. I would have the USB and
>>> Mailbox devices probe seperately and use a phandle to point the USB
>>> device to its Mailbox.
>>>
>>> usb at xyz {
>>> mboxes = <&xusb-mailbox, [chan]>;
>>> };
>>>
>>
>> I am assuming that Andrew had laid it out like this to reflect the hw
>> structure. The mailbox and xhci controller are part of the xusb
>> sub-system and hence appear as child nodes. My understanding is that for
>> device-tree we want the device-tree structure to reflect the actual hw.
>> Is this not the case?
>
> Yes, the DT files should reflect h/w. I have requested to see what
> the memory map looks like, so I might provide a more appropriate
> solution to accepting a pretty pointless MFD.
For the xusb-host has memory from 0x7009000 - 0x7009ffff.
Within this range, we have this fpci range which is defined as 0x7009800
- 0x70098fff. This range is being shared between the mailbox and xhci
drivers. Looking at the drivers, we have ...
mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
So it is a bit messy as they overlap. However, we could have ...
xusb_mbox: mailbox {
compatible = "nvidia,tegra124-xusb-mbox";
reg = <0x0 0x700980e0 0x0 0x14>,
<0x0 0x70098428 0x0 0x4>;
...
};
usb-host at 0,70090000 {
compatible = "nvidia,tegra124-xhci";
reg = <0x0 0x70090000 0x0 0x8000>,
<0x0 0x70098000 0x0 0x00d0>;
<0x0 0x70098800 0x0 0x0004>;
<0x0 0x70099000 0x0 0x1000>;
...
};
I believe that Thierry and Stephen said that they wished to avoid
multiple devices sharing the same memory ranges, and so we would need to
divvy up the memory map as above. However, I am not sure if this is an
ok thing to do.
> Two solutions spring to mind. You can either call
> of_platform_populate() from the USB driver, as some already do:
>
> drivers/usb/dwc3/dwc3-exynos.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-keystone.c:
> error = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-omap.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-qcom.c:
> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> drivers/usb/dwc3/dwc3-st.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/musb/musb_am335x.c:
> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>
> Or use the "simple-mfd", which is currently in -next:
>
> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
That is nice. Sounds like the "simple-bus" style of device but for an
mfd. Based upon the above, let me know if you think we could use the
"simple-mfd"?
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 9:14 ` Jon Hunter
0 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 9:14 UTC (permalink / raw)
To: Lee Jones
Cc: Andrew Bresticker, Stephen Warren, Thierry Reding,
Alexandre Courbot, devicetree, linux-tegra, linux-usb,
linux-arm-kernel, linux-kernel, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On 14/05/15 08:40, Lee Jones wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>
>> Hi Lee,
>>
>> On 13/05/15 15:39, Lee Jones wrote:
>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>
>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>
>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>>>> Cc: Lee Jones <lee.jones@linaro.org>
>>>> ---
>>>> Changes from v7:
>>>> - Move non-shared resources into child nodes.
>>>> New for v7.
>>>> ---
>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>> 1 file changed, 37 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>> new file mode 100644
>>>> index 0000000..bc50110
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>> @@ -0,0 +1,37 @@
>>>> +NVIDIA Tegra XUSB host copmlex
>>>> +==============================
>>>> +
>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>> +
>>>> +Required properties:
>>>> +--------------------
>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>> + where <chip> is tegra132.
>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>> + mapping is 1:1.
>>>> + - #address-cells: Must be 2.
>>>> + - #size-cells: Must be 2.
>>>> +
>>>> +Example:
>>>> +--------
>>>> + usb@0,70098000 {
>>>> + compatible = "nvidia,tegra124-xusb";
>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>> + ranges;
>>>> +
>>>> + #address-cells = <2>;
>>>> + #size-cells = <2>;
>>>> +
>>>> + usb-host@0,70090000 {
>>>> + compatible = "nvidia,tegra124-xhci";
>>>> + ...
>>>> + };
>>>> +
>>>> + mailbox {
>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>> + ...
>>>> + };
>>>
>>> This doesn't appear to be a proper MFD. I would have the USB and
>>> Mailbox devices probe seperately and use a phandle to point the USB
>>> device to its Mailbox.
>>>
>>> usb@xyz {
>>> mboxes = <&xusb-mailbox, [chan]>;
>>> };
>>>
>>
>> I am assuming that Andrew had laid it out like this to reflect the hw
>> structure. The mailbox and xhci controller are part of the xusb
>> sub-system and hence appear as child nodes. My understanding is that for
>> device-tree we want the device-tree structure to reflect the actual hw.
>> Is this not the case?
>
> Yes, the DT files should reflect h/w. I have requested to see what
> the memory map looks like, so I might provide a more appropriate
> solution to accepting a pretty pointless MFD.
For the xusb-host has memory from 0x7009000 - 0x7009ffff.
Within this range, we have this fpci range which is defined as 0x7009800
- 0x70098fff. This range is being shared between the mailbox and xhci
drivers. Looking at the drivers, we have ...
mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
So it is a bit messy as they overlap. However, we could have ...
xusb_mbox: mailbox {
compatible = "nvidia,tegra124-xusb-mbox";
reg = <0x0 0x700980e0 0x0 0x14>,
<0x0 0x70098428 0x0 0x4>;
...
};
usb-host@0,70090000 {
compatible = "nvidia,tegra124-xhci";
reg = <0x0 0x70090000 0x0 0x8000>,
<0x0 0x70098000 0x0 0x00d0>;
<0x0 0x70098800 0x0 0x0004>;
<0x0 0x70099000 0x0 0x1000>;
...
};
I believe that Thierry and Stephen said that they wished to avoid
multiple devices sharing the same memory ranges, and so we would need to
divvy up the memory map as above. However, I am not sure if this is an
ok thing to do.
> Two solutions spring to mind. You can either call
> of_platform_populate() from the USB driver, as some already do:
>
> drivers/usb/dwc3/dwc3-exynos.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-keystone.c:
> error = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-omap.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-qcom.c:
> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> drivers/usb/dwc3/dwc3-st.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/musb/musb_am335x.c:
> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>
> Or use the "simple-mfd", which is currently in -next:
>
> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
That is nice. Sounds like the "simple-bus" style of device but for an
mfd. Based upon the above, let me know if you think we could use the
"simple-mfd"?
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-14 9:14 ` Jon Hunter
@ 2015-05-14 9:30 ` Lee Jones
-1 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 9:30 UTC (permalink / raw)
To: Jon Hunter
Cc: Andrew Bresticker, Stephen Warren, Thierry Reding,
Alexandre Courbot, devicetree, linux-tegra, linux-usb,
linux-arm-kernel, linux-kernel, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, 14 May 2015, Jon Hunter wrote:
> On 14/05/15 08:40, Lee Jones wrote:
> > On Thu, 14 May 2015, Jon Hunter wrote:
> >> On 13/05/15 15:39, Lee Jones wrote:
> >>> On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>>
> >>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>>> and later SoCs. The XUSB host complex includes a mailbox for
> >>>> communication with the XUSB micro-controller and an xHCI host-controller.
> >>>>
> >>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>> Cc: Pawel Moll <pawel.moll@arm.com>
> >>>> Cc: Mark Rutland <mark.rutland@arm.com>
> >>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >>>> Cc: Kumar Gala <galak@codeaurora.org>
> >>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >>>> Cc: Lee Jones <lee.jones@linaro.org>
> >>>> ---
> >>>> Changes from v7:
> >>>> - Move non-shared resources into child nodes.
> >>>> New for v7.
> >>>> ---
> >>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>>> 1 file changed, 37 insertions(+)
> >>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>> new file mode 100644
> >>>> index 0000000..bc50110
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>> @@ -0,0 +1,37 @@
> >>>> +NVIDIA Tegra XUSB host copmlex
> >>>> +==============================
> >>>> +
> >>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>>> +controller and a mailbox for communication with the XUSB micro-controller.
> >>>> +
> >>>> +Required properties:
> >>>> +--------------------
> >>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>>> + where <chip> is tegra132.
> >>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>>> + mapping is 1:1.
> >>>> + - #address-cells: Must be 2.
> >>>> + - #size-cells: Must be 2.
> >>>> +
> >>>> +Example:
> >>>> +--------
> >>>> + usb@0,70098000 {
> >>>> + compatible = "nvidia,tegra124-xusb";
> >>>> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>>> + ranges;
> >>>> +
> >>>> + #address-cells = <2>;
> >>>> + #size-cells = <2>;
> >>>> +
> >>>> + usb-host@0,70090000 {
> >>>> + compatible = "nvidia,tegra124-xhci";
> >>>> + ...
> >>>> + };
> >>>> +
> >>>> + mailbox {
> >>>> + compatible = "nvidia,tegra124-xusb-mbox";
> >>>> + ...
> >>>> + };
> >>>
> >>> This doesn't appear to be a proper MFD. I would have the USB and
> >>> Mailbox devices probe seperately and use a phandle to point the USB
> >>> device to its Mailbox.
> >>>
> >>> usb@xyz {
> >>> mboxes = <&xusb-mailbox, [chan]>;
> >>> };
> >>>
> >>
> >> I am assuming that Andrew had laid it out like this to reflect the hw
> >> structure. The mailbox and xhci controller are part of the xusb
> >> sub-system and hence appear as child nodes. My understanding is that for
> >> device-tree we want the device-tree structure to reflect the actual hw.
> >> Is this not the case?
> >
> > Yes, the DT files should reflect h/w. I have requested to see what
> > the memory map looks like, so I might provide a more appropriate
> > solution to accepting a pretty pointless MFD.
>
> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
>
> Within this range, we have this fpci range which is defined as 0x7009800
> - 0x70098fff. This range is being shared between the mailbox and xhci
> drivers. Looking at the drivers, we have ...
>
> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
>
> So it is a bit messy as they overlap. However, we could have ...
>
> xusb_mbox: mailbox {
> compatible = "nvidia,tegra124-xusb-mbox";
> reg = <0x0 0x700980e0 0x0 0x14>,
> <0x0 0x70098428 0x0 0x4>;
> ...
> };
> usb-host@0,70090000 {
> compatible = "nvidia,tegra124-xhci";
> reg = <0x0 0x70090000 0x0 0x8000>,
> <0x0 0x70098000 0x0 0x00d0>;
> <0x0 0x70098800 0x0 0x0004>;
> <0x0 0x70099000 0x0 0x1000>;
> ...
> };
>
> I believe that Thierry and Stephen said that they wished to avoid
> multiple devices sharing the same memory ranges, and so we would need to
> divvy up the memory map as above. However, I am not sure if this is an
> ok thing to do.
>
> > Two solutions spring to mind. You can either call
> > of_platform_populate() from the USB driver, as some already do:
> >
> > drivers/usb/dwc3/dwc3-exynos.c:
> > ret = of_platform_populate(node, NULL, NULL, dev);
> > drivers/usb/dwc3/dwc3-keystone.c:
> > error = of_platform_populate(node, NULL, NULL, dev);
> > drivers/usb/dwc3/dwc3-omap.c:
> > ret = of_platform_populate(node, NULL, NULL, dev);
> > drivers/usb/dwc3/dwc3-qcom.c:
> > ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > drivers/usb/dwc3/dwc3-st.c:
> > ret = of_platform_populate(node, NULL, NULL, dev);
> > drivers/usb/musb/musb_am335x.c:
> > ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> >
> > Or use the "simple-mfd", which is currently in -next:
> >
> > git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>
> That is nice. Sounds like the "simple-bus" style of device but for an
That's precisely what it does. FYI: You 'can' use "simple-bus" and it
will do the right thing, but as an MFD isn't really a bus, it was
decided to create something a little more fitting.
> mfd. Based upon the above, let me know if you think we could use the
> "simple-mfd"?
I do. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 9:30 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 9:30 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 14 May 2015, Jon Hunter wrote:
> On 14/05/15 08:40, Lee Jones wrote:
> > On Thu, 14 May 2015, Jon Hunter wrote:
> >> On 13/05/15 15:39, Lee Jones wrote:
> >>> On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>>
> >>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>>> and later SoCs. The XUSB host complex includes a mailbox for
> >>>> communication with the XUSB micro-controller and an xHCI host-controller.
> >>>>
> >>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>> Cc: Pawel Moll <pawel.moll@arm.com>
> >>>> Cc: Mark Rutland <mark.rutland@arm.com>
> >>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >>>> Cc: Kumar Gala <galak@codeaurora.org>
> >>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >>>> Cc: Lee Jones <lee.jones@linaro.org>
> >>>> ---
> >>>> Changes from v7:
> >>>> - Move non-shared resources into child nodes.
> >>>> New for v7.
> >>>> ---
> >>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>>> 1 file changed, 37 insertions(+)
> >>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>> new file mode 100644
> >>>> index 0000000..bc50110
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>> @@ -0,0 +1,37 @@
> >>>> +NVIDIA Tegra XUSB host copmlex
> >>>> +==============================
> >>>> +
> >>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>>> +controller and a mailbox for communication with the XUSB micro-controller.
> >>>> +
> >>>> +Required properties:
> >>>> +--------------------
> >>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>>> + where <chip> is tegra132.
> >>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>>> + mapping is 1:1.
> >>>> + - #address-cells: Must be 2.
> >>>> + - #size-cells: Must be 2.
> >>>> +
> >>>> +Example:
> >>>> +--------
> >>>> + usb at 0,70098000 {
> >>>> + compatible = "nvidia,tegra124-xusb";
> >>>> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>>> + ranges;
> >>>> +
> >>>> + #address-cells = <2>;
> >>>> + #size-cells = <2>;
> >>>> +
> >>>> + usb-host at 0,70090000 {
> >>>> + compatible = "nvidia,tegra124-xhci";
> >>>> + ...
> >>>> + };
> >>>> +
> >>>> + mailbox {
> >>>> + compatible = "nvidia,tegra124-xusb-mbox";
> >>>> + ...
> >>>> + };
> >>>
> >>> This doesn't appear to be a proper MFD. I would have the USB and
> >>> Mailbox devices probe seperately and use a phandle to point the USB
> >>> device to its Mailbox.
> >>>
> >>> usb at xyz {
> >>> mboxes = <&xusb-mailbox, [chan]>;
> >>> };
> >>>
> >>
> >> I am assuming that Andrew had laid it out like this to reflect the hw
> >> structure. The mailbox and xhci controller are part of the xusb
> >> sub-system and hence appear as child nodes. My understanding is that for
> >> device-tree we want the device-tree structure to reflect the actual hw.
> >> Is this not the case?
> >
> > Yes, the DT files should reflect h/w. I have requested to see what
> > the memory map looks like, so I might provide a more appropriate
> > solution to accepting a pretty pointless MFD.
>
> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
>
> Within this range, we have this fpci range which is defined as 0x7009800
> - 0x70098fff. This range is being shared between the mailbox and xhci
> drivers. Looking at the drivers, we have ...
>
> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
>
> So it is a bit messy as they overlap. However, we could have ...
>
> xusb_mbox: mailbox {
> compatible = "nvidia,tegra124-xusb-mbox";
> reg = <0x0 0x700980e0 0x0 0x14>,
> <0x0 0x70098428 0x0 0x4>;
> ...
> };
> usb-host at 0,70090000 {
> compatible = "nvidia,tegra124-xhci";
> reg = <0x0 0x70090000 0x0 0x8000>,
> <0x0 0x70098000 0x0 0x00d0>;
> <0x0 0x70098800 0x0 0x0004>;
> <0x0 0x70099000 0x0 0x1000>;
> ...
> };
>
> I believe that Thierry and Stephen said that they wished to avoid
> multiple devices sharing the same memory ranges, and so we would need to
> divvy up the memory map as above. However, I am not sure if this is an
> ok thing to do.
>
> > Two solutions spring to mind. You can either call
> > of_platform_populate() from the USB driver, as some already do:
> >
> > drivers/usb/dwc3/dwc3-exynos.c:
> > ret = of_platform_populate(node, NULL, NULL, dev);
> > drivers/usb/dwc3/dwc3-keystone.c:
> > error = of_platform_populate(node, NULL, NULL, dev);
> > drivers/usb/dwc3/dwc3-omap.c:
> > ret = of_platform_populate(node, NULL, NULL, dev);
> > drivers/usb/dwc3/dwc3-qcom.c:
> > ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > drivers/usb/dwc3/dwc3-st.c:
> > ret = of_platform_populate(node, NULL, NULL, dev);
> > drivers/usb/musb/musb_am335x.c:
> > ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> >
> > Or use the "simple-mfd", which is currently in -next:
> >
> > git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>
> That is nice. Sounds like the "simple-bus" style of device but for an
That's precisely what it does. FYI: You 'can' use "simple-bus" and it
will do the right thing, but as an MFD isn't really a bus, it was
decided to create something a little more fitting.
> mfd. Based upon the above, let me know if you think we could use the
> "simple-mfd"?
I do. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-14 9:30 ` Lee Jones
(?)
@ 2015-05-14 10:09 ` Jon Hunter
-1 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 10:09 UTC (permalink / raw)
To: Lee Jones, Thierry Reding
Cc: Andrew Bresticker, Stephen Warren, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On 14/05/15 10:30, Lee Jones wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>> On 14/05/15 08:40, Lee Jones wrote:
>>> On Thu, 14 May 2015, Jon Hunter wrote:
>>>> On 13/05/15 15:39, Lee Jones wrote:
>>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>>>
>>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>>>
>>>>>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>>>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>>>>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>>>>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>>>>>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>>>> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>>>> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>>> ---
>>>>>> Changes from v7:
>>>>>> - Move non-shared resources into child nodes.
>>>>>> New for v7.
>>>>>> ---
>>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>>>> 1 file changed, 37 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..bc50110
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> @@ -0,0 +1,37 @@
>>>>>> +NVIDIA Tegra XUSB host copmlex
>>>>>> +==============================
>>>>>> +
>>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +--------------------
>>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>>>> + where <chip> is tegra132.
>>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>>>> + mapping is 1:1.
>>>>>> + - #address-cells: Must be 2.
>>>>>> + - #size-cells: Must be 2.
>>>>>> +
>>>>>> +Example:
>>>>>> +--------
>>>>>> + usb@0,70098000 {
>>>>>> + compatible = "nvidia,tegra124-xusb";
>>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>>>> + ranges;
>>>>>> +
>>>>>> + #address-cells = <2>;
>>>>>> + #size-cells = <2>;
>>>>>> +
>>>>>> + usb-host@0,70090000 {
>>>>>> + compatible = "nvidia,tegra124-xhci";
>>>>>> + ...
>>>>>> + };
>>>>>> +
>>>>>> + mailbox {
>>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>>>> + ...
>>>>>> + };
>>>>>
>>>>> This doesn't appear to be a proper MFD. I would have the USB and
>>>>> Mailbox devices probe seperately and use a phandle to point the USB
>>>>> device to its Mailbox.
>>>>>
>>>>> usb@xyz {
>>>>> mboxes = <&xusb-mailbox, [chan]>;
>>>>> };
>>>>>
>>>>
>>>> I am assuming that Andrew had laid it out like this to reflect the hw
>>>> structure. The mailbox and xhci controller are part of the xusb
>>>> sub-system and hence appear as child nodes. My understanding is that for
>>>> device-tree we want the device-tree structure to reflect the actual hw.
>>>> Is this not the case?
>>>
>>> Yes, the DT files should reflect h/w. I have requested to see what
>>> the memory map looks like, so I might provide a more appropriate
>>> solution to accepting a pretty pointless MFD.
>>
>> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
>>
>> Within this range, we have this fpci range which is defined as 0x7009800
>> - 0x70098fff. This range is being shared between the mailbox and xhci
>> drivers. Looking at the drivers, we have ...
>>
>> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
>> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
>>
>> So it is a bit messy as they overlap. However, we could have ...
>>
>> xusb_mbox: mailbox {
>> compatible = "nvidia,tegra124-xusb-mbox";
>> reg = <0x0 0x700980e0 0x0 0x14>,
>> <0x0 0x70098428 0x0 0x4>;
>> ...
>> };
>> usb-host@0,70090000 {
>> compatible = "nvidia,tegra124-xhci";
>> reg = <0x0 0x70090000 0x0 0x8000>,
>> <0x0 0x70098000 0x0 0x00d0>;
>> <0x0 0x70098800 0x0 0x0004>;
>> <0x0 0x70099000 0x0 0x1000>;
>> ...
>> };
>>
>> I believe that Thierry and Stephen said that they wished to avoid
>> multiple devices sharing the same memory ranges, and so we would need to
>> divvy up the memory map as above. However, I am not sure if this is an
>> ok thing to do.
>>
>>> Two solutions spring to mind. You can either call
>>> of_platform_populate() from the USB driver, as some already do:
>>>
>>> drivers/usb/dwc3/dwc3-exynos.c:
>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/dwc3/dwc3-keystone.c:
>>> error = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/dwc3/dwc3-omap.c:
>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/dwc3/dwc3-qcom.c:
>>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
>>> drivers/usb/dwc3/dwc3-st.c:
>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/musb/musb_am335x.c:
>>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>>>
>>> Or use the "simple-mfd", which is currently in -next:
>>>
>>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>>
>> That is nice. Sounds like the "simple-bus" style of device but for an
>
> That's precisely what it does. FYI: You 'can' use "simple-bus" and it
> will do the right thing, but as an MFD isn't really a bus, it was
> decided to create something a little more fitting.
>
>> mfd. Based upon the above, let me know if you think we could use the
>> "simple-mfd"?
>
> I do. :)
Thanks Lee.
Thierry, any objections on the above mem-mapping?
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 10:09 ` Jon Hunter
0 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 10:09 UTC (permalink / raw)
To: linux-arm-kernel
On 14/05/15 10:30, Lee Jones wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>> On 14/05/15 08:40, Lee Jones wrote:
>>> On Thu, 14 May 2015, Jon Hunter wrote:
>>>> On 13/05/15 15:39, Lee Jones wrote:
>>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>>>
>>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>>>
>>>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>>>>>> Cc: Lee Jones <lee.jones@linaro.org>
>>>>>> ---
>>>>>> Changes from v7:
>>>>>> - Move non-shared resources into child nodes.
>>>>>> New for v7.
>>>>>> ---
>>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>>>> 1 file changed, 37 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..bc50110
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> @@ -0,0 +1,37 @@
>>>>>> +NVIDIA Tegra XUSB host copmlex
>>>>>> +==============================
>>>>>> +
>>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +--------------------
>>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>>>> + where <chip> is tegra132.
>>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>>>> + mapping is 1:1.
>>>>>> + - #address-cells: Must be 2.
>>>>>> + - #size-cells: Must be 2.
>>>>>> +
>>>>>> +Example:
>>>>>> +--------
>>>>>> + usb at 0,70098000 {
>>>>>> + compatible = "nvidia,tegra124-xusb";
>>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>>>> + ranges;
>>>>>> +
>>>>>> + #address-cells = <2>;
>>>>>> + #size-cells = <2>;
>>>>>> +
>>>>>> + usb-host at 0,70090000 {
>>>>>> + compatible = "nvidia,tegra124-xhci";
>>>>>> + ...
>>>>>> + };
>>>>>> +
>>>>>> + mailbox {
>>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>>>> + ...
>>>>>> + };
>>>>>
>>>>> This doesn't appear to be a proper MFD. I would have the USB and
>>>>> Mailbox devices probe seperately and use a phandle to point the USB
>>>>> device to its Mailbox.
>>>>>
>>>>> usb at xyz {
>>>>> mboxes = <&xusb-mailbox, [chan]>;
>>>>> };
>>>>>
>>>>
>>>> I am assuming that Andrew had laid it out like this to reflect the hw
>>>> structure. The mailbox and xhci controller are part of the xusb
>>>> sub-system and hence appear as child nodes. My understanding is that for
>>>> device-tree we want the device-tree structure to reflect the actual hw.
>>>> Is this not the case?
>>>
>>> Yes, the DT files should reflect h/w. I have requested to see what
>>> the memory map looks like, so I might provide a more appropriate
>>> solution to accepting a pretty pointless MFD.
>>
>> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
>>
>> Within this range, we have this fpci range which is defined as 0x7009800
>> - 0x70098fff. This range is being shared between the mailbox and xhci
>> drivers. Looking at the drivers, we have ...
>>
>> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
>> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
>>
>> So it is a bit messy as they overlap. However, we could have ...
>>
>> xusb_mbox: mailbox {
>> compatible = "nvidia,tegra124-xusb-mbox";
>> reg = <0x0 0x700980e0 0x0 0x14>,
>> <0x0 0x70098428 0x0 0x4>;
>> ...
>> };
>> usb-host at 0,70090000 {
>> compatible = "nvidia,tegra124-xhci";
>> reg = <0x0 0x70090000 0x0 0x8000>,
>> <0x0 0x70098000 0x0 0x00d0>;
>> <0x0 0x70098800 0x0 0x0004>;
>> <0x0 0x70099000 0x0 0x1000>;
>> ...
>> };
>>
>> I believe that Thierry and Stephen said that they wished to avoid
>> multiple devices sharing the same memory ranges, and so we would need to
>> divvy up the memory map as above. However, I am not sure if this is an
>> ok thing to do.
>>
>>> Two solutions spring to mind. You can either call
>>> of_platform_populate() from the USB driver, as some already do:
>>>
>>> drivers/usb/dwc3/dwc3-exynos.c:
>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/dwc3/dwc3-keystone.c:
>>> error = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/dwc3/dwc3-omap.c:
>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/dwc3/dwc3-qcom.c:
>>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
>>> drivers/usb/dwc3/dwc3-st.c:
>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/musb/musb_am335x.c:
>>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>>>
>>> Or use the "simple-mfd", which is currently in -next:
>>>
>>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>>
>> That is nice. Sounds like the "simple-bus" style of device but for an
>
> That's precisely what it does. FYI: You 'can' use "simple-bus" and it
> will do the right thing, but as an MFD isn't really a bus, it was
> decided to create something a little more fitting.
>
>> mfd. Based upon the above, let me know if you think we could use the
>> "simple-mfd"?
>
> I do. :)
Thanks Lee.
Thierry, any objections on the above mem-mapping?
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 10:09 ` Jon Hunter
0 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 10:09 UTC (permalink / raw)
To: Lee Jones, Thierry Reding
Cc: Andrew Bresticker, Stephen Warren, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Samuel Ortiz
On 14/05/15 10:30, Lee Jones wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>> On 14/05/15 08:40, Lee Jones wrote:
>>> On Thu, 14 May 2015, Jon Hunter wrote:
>>>> On 13/05/15 15:39, Lee Jones wrote:
>>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>>>
>>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>>>
>>>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>>>>>> Cc: Lee Jones <lee.jones@linaro.org>
>>>>>> ---
>>>>>> Changes from v7:
>>>>>> - Move non-shared resources into child nodes.
>>>>>> New for v7.
>>>>>> ---
>>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>>>> 1 file changed, 37 insertions(+)
>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..bc50110
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>> @@ -0,0 +1,37 @@
>>>>>> +NVIDIA Tegra XUSB host copmlex
>>>>>> +==============================
>>>>>> +
>>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +--------------------
>>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>>>> + where <chip> is tegra132.
>>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>>>> + mapping is 1:1.
>>>>>> + - #address-cells: Must be 2.
>>>>>> + - #size-cells: Must be 2.
>>>>>> +
>>>>>> +Example:
>>>>>> +--------
>>>>>> + usb@0,70098000 {
>>>>>> + compatible = "nvidia,tegra124-xusb";
>>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>>>> + ranges;
>>>>>> +
>>>>>> + #address-cells = <2>;
>>>>>> + #size-cells = <2>;
>>>>>> +
>>>>>> + usb-host@0,70090000 {
>>>>>> + compatible = "nvidia,tegra124-xhci";
>>>>>> + ...
>>>>>> + };
>>>>>> +
>>>>>> + mailbox {
>>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>>>> + ...
>>>>>> + };
>>>>>
>>>>> This doesn't appear to be a proper MFD. I would have the USB and
>>>>> Mailbox devices probe seperately and use a phandle to point the USB
>>>>> device to its Mailbox.
>>>>>
>>>>> usb@xyz {
>>>>> mboxes = <&xusb-mailbox, [chan]>;
>>>>> };
>>>>>
>>>>
>>>> I am assuming that Andrew had laid it out like this to reflect the hw
>>>> structure. The mailbox and xhci controller are part of the xusb
>>>> sub-system and hence appear as child nodes. My understanding is that for
>>>> device-tree we want the device-tree structure to reflect the actual hw.
>>>> Is this not the case?
>>>
>>> Yes, the DT files should reflect h/w. I have requested to see what
>>> the memory map looks like, so I might provide a more appropriate
>>> solution to accepting a pretty pointless MFD.
>>
>> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
>>
>> Within this range, we have this fpci range which is defined as 0x7009800
>> - 0x70098fff. This range is being shared between the mailbox and xhci
>> drivers. Looking at the drivers, we have ...
>>
>> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
>> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
>>
>> So it is a bit messy as they overlap. However, we could have ...
>>
>> xusb_mbox: mailbox {
>> compatible = "nvidia,tegra124-xusb-mbox";
>> reg = <0x0 0x700980e0 0x0 0x14>,
>> <0x0 0x70098428 0x0 0x4>;
>> ...
>> };
>> usb-host@0,70090000 {
>> compatible = "nvidia,tegra124-xhci";
>> reg = <0x0 0x70090000 0x0 0x8000>,
>> <0x0 0x70098000 0x0 0x00d0>;
>> <0x0 0x70098800 0x0 0x0004>;
>> <0x0 0x70099000 0x0 0x1000>;
>> ...
>> };
>>
>> I believe that Thierry and Stephen said that they wished to avoid
>> multiple devices sharing the same memory ranges, and so we would need to
>> divvy up the memory map as above. However, I am not sure if this is an
>> ok thing to do.
>>
>>> Two solutions spring to mind. You can either call
>>> of_platform_populate() from the USB driver, as some already do:
>>>
>>> drivers/usb/dwc3/dwc3-exynos.c:
>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/dwc3/dwc3-keystone.c:
>>> error = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/dwc3/dwc3-omap.c:
>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/dwc3/dwc3-qcom.c:
>>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
>>> drivers/usb/dwc3/dwc3-st.c:
>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>> drivers/usb/musb/musb_am335x.c:
>>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>>>
>>> Or use the "simple-mfd", which is currently in -next:
>>>
>>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>>
>> That is nice. Sounds like the "simple-bus" style of device but for an
>
> That's precisely what it does. FYI: You 'can' use "simple-bus" and it
> will do the right thing, but as an MFD isn't really a bus, it was
> decided to create something a little more fitting.
>
>> mfd. Based upon the above, let me know if you think we could use the
>> "simple-mfd"?
>
> I do. :)
Thanks Lee.
Thierry, any objections on the above mem-mapping?
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread[parent not found: <5554746A.4000608-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-14 10:09 ` Jon Hunter
(?)
@ 2015-05-14 10:23 ` Lee Jones
-1 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 10:23 UTC (permalink / raw)
To: Jon Hunter
Cc: Thierry Reding, Andrew Bresticker, Stephen Warren,
Alexandre Courbot, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, 14 May 2015, Jon Hunter wrote:
> On 14/05/15 10:30, Lee Jones wrote:
> > On Thu, 14 May 2015, Jon Hunter wrote:
> >> On 14/05/15 08:40, Lee Jones wrote:
> >>> On Thu, 14 May 2015, Jon Hunter wrote:
> >>>> On 13/05/15 15:39, Lee Jones wrote:
> >>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>>>>
> >>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>>>>> and later SoCs. The XUSB host complex includes a mailbox for
> >>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
> >>>>>>
> >>>>>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >>>>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>>>>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> >>>>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> >>>>>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> >>>>>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >>>>>> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >>>>>> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>>>>> ---
> >>>>>> Changes from v7:
> >>>>>> - Move non-shared resources into child nodes.
> >>>>>> New for v7.
> >>>>>> ---
> >>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>>>>> 1 file changed, 37 insertions(+)
> >>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> new file mode 100644
> >>>>>> index 0000000..bc50110
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> @@ -0,0 +1,37 @@
> >>>>>> +NVIDIA Tegra XUSB host copmlex
> >>>>>> +==============================
> >>>>>> +
> >>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +--------------------
> >>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>>>>> + where <chip> is tegra132.
> >>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>>>>> + mapping is 1:1.
> >>>>>> + - #address-cells: Must be 2.
> >>>>>> + - #size-cells: Must be 2.
> >>>>>> +
> >>>>>> +Example:
> >>>>>> +--------
> >>>>>> + usb@0,70098000 {
> >>>>>> + compatible = "nvidia,tegra124-xusb";
> >>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>>>>> + ranges;
> >>>>>> +
> >>>>>> + #address-cells = <2>;
> >>>>>> + #size-cells = <2>;
> >>>>>> +
> >>>>>> + usb-host@0,70090000 {
> >>>>>> + compatible = "nvidia,tegra124-xhci";
> >>>>>> + ...
> >>>>>> + };
> >>>>>> +
> >>>>>> + mailbox {
> >>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
> >>>>>> + ...
> >>>>>> + };
> >>>>>
> >>>>> This doesn't appear to be a proper MFD. I would have the USB and
> >>>>> Mailbox devices probe seperately and use a phandle to point the USB
> >>>>> device to its Mailbox.
> >>>>>
> >>>>> usb@xyz {
> >>>>> mboxes = <&xusb-mailbox, [chan]>;
> >>>>> };
> >>>>>
> >>>>
> >>>> I am assuming that Andrew had laid it out like this to reflect the hw
> >>>> structure. The mailbox and xhci controller are part of the xusb
> >>>> sub-system and hence appear as child nodes. My understanding is that for
> >>>> device-tree we want the device-tree structure to reflect the actual hw.
> >>>> Is this not the case?
> >>>
> >>> Yes, the DT files should reflect h/w. I have requested to see what
> >>> the memory map looks like, so I might provide a more appropriate
> >>> solution to accepting a pretty pointless MFD.
> >>
> >> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
> >>
> >> Within this range, we have this fpci range which is defined as 0x7009800
> >> - 0x70098fff. This range is being shared between the mailbox and xhci
> >> drivers. Looking at the drivers, we have ...
> >>
> >> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
> >> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
> >>
> >> So it is a bit messy as they overlap. However, we could have ...
> >>
> >> xusb_mbox: mailbox {
> >> compatible = "nvidia,tegra124-xusb-mbox";
> >> reg = <0x0 0x700980e0 0x0 0x14>,
> >> <0x0 0x70098428 0x0 0x4>;
> >> ...
> >> };
> >> usb-host@0,70090000 {
> >> compatible = "nvidia,tegra124-xhci";
> >> reg = <0x0 0x70090000 0x0 0x8000>,
> >> <0x0 0x70098000 0x0 0x00d0>;
> >> <0x0 0x70098800 0x0 0x0004>;
> >> <0x0 0x70099000 0x0 0x1000>;
> >> ...
> >> };
> >>
> >> I believe that Thierry and Stephen said that they wished to avoid
> >> multiple devices sharing the same memory ranges, and so we would need to
> >> divvy up the memory map as above. However, I am not sure if this is an
> >> ok thing to do.
> >>
> >>> Two solutions spring to mind. You can either call
> >>> of_platform_populate() from the USB driver, as some already do:
> >>>
> >>> drivers/usb/dwc3/dwc3-exynos.c:
> >>> ret = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/dwc3/dwc3-keystone.c:
> >>> error = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/dwc3/dwc3-omap.c:
> >>> ret = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/dwc3/dwc3-qcom.c:
> >>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> >>> drivers/usb/dwc3/dwc3-st.c:
> >>> ret = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/musb/musb_am335x.c:
> >>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> >>>
> >>> Or use the "simple-mfd", which is currently in -next:
> >>>
> >>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> >>
> >> That is nice. Sounds like the "simple-bus" style of device but for an
> >
> > That's precisely what it does. FYI: You 'can' use "simple-bus" and it
> > will do the right thing, but as an MFD isn't really a bus, it was
> > decided to create something a little more fitting.
> >
> >> mfd. Based upon the above, let me know if you think we could use the
> >> "simple-mfd"?
> >
> > I do. :)
>
> Thanks Lee.
>
> Thierry, any objections on the above mem-mapping?
If you have the mailbox as the child device and use "simple-mfd", you
don't need to slice up the memory do you?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 10:23 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 10:23 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 14 May 2015, Jon Hunter wrote:
> On 14/05/15 10:30, Lee Jones wrote:
> > On Thu, 14 May 2015, Jon Hunter wrote:
> >> On 14/05/15 08:40, Lee Jones wrote:
> >>> On Thu, 14 May 2015, Jon Hunter wrote:
> >>>> On 13/05/15 15:39, Lee Jones wrote:
> >>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>>>>
> >>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>>>>> and later SoCs. The XUSB host complex includes a mailbox for
> >>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
> >>>>>>
> >>>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>>> Cc: Pawel Moll <pawel.moll@arm.com>
> >>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
> >>>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >>>>>> Cc: Kumar Gala <galak@codeaurora.org>
> >>>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >>>>>> Cc: Lee Jones <lee.jones@linaro.org>
> >>>>>> ---
> >>>>>> Changes from v7:
> >>>>>> - Move non-shared resources into child nodes.
> >>>>>> New for v7.
> >>>>>> ---
> >>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>>>>> 1 file changed, 37 insertions(+)
> >>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> new file mode 100644
> >>>>>> index 0000000..bc50110
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> @@ -0,0 +1,37 @@
> >>>>>> +NVIDIA Tegra XUSB host copmlex
> >>>>>> +==============================
> >>>>>> +
> >>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +--------------------
> >>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>>>>> + where <chip> is tegra132.
> >>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>>>>> + mapping is 1:1.
> >>>>>> + - #address-cells: Must be 2.
> >>>>>> + - #size-cells: Must be 2.
> >>>>>> +
> >>>>>> +Example:
> >>>>>> +--------
> >>>>>> + usb at 0,70098000 {
> >>>>>> + compatible = "nvidia,tegra124-xusb";
> >>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>>>>> + ranges;
> >>>>>> +
> >>>>>> + #address-cells = <2>;
> >>>>>> + #size-cells = <2>;
> >>>>>> +
> >>>>>> + usb-host at 0,70090000 {
> >>>>>> + compatible = "nvidia,tegra124-xhci";
> >>>>>> + ...
> >>>>>> + };
> >>>>>> +
> >>>>>> + mailbox {
> >>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
> >>>>>> + ...
> >>>>>> + };
> >>>>>
> >>>>> This doesn't appear to be a proper MFD. I would have the USB and
> >>>>> Mailbox devices probe seperately and use a phandle to point the USB
> >>>>> device to its Mailbox.
> >>>>>
> >>>>> usb at xyz {
> >>>>> mboxes = <&xusb-mailbox, [chan]>;
> >>>>> };
> >>>>>
> >>>>
> >>>> I am assuming that Andrew had laid it out like this to reflect the hw
> >>>> structure. The mailbox and xhci controller are part of the xusb
> >>>> sub-system and hence appear as child nodes. My understanding is that for
> >>>> device-tree we want the device-tree structure to reflect the actual hw.
> >>>> Is this not the case?
> >>>
> >>> Yes, the DT files should reflect h/w. I have requested to see what
> >>> the memory map looks like, so I might provide a more appropriate
> >>> solution to accepting a pretty pointless MFD.
> >>
> >> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
> >>
> >> Within this range, we have this fpci range which is defined as 0x7009800
> >> - 0x70098fff. This range is being shared between the mailbox and xhci
> >> drivers. Looking at the drivers, we have ...
> >>
> >> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
> >> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
> >>
> >> So it is a bit messy as they overlap. However, we could have ...
> >>
> >> xusb_mbox: mailbox {
> >> compatible = "nvidia,tegra124-xusb-mbox";
> >> reg = <0x0 0x700980e0 0x0 0x14>,
> >> <0x0 0x70098428 0x0 0x4>;
> >> ...
> >> };
> >> usb-host at 0,70090000 {
> >> compatible = "nvidia,tegra124-xhci";
> >> reg = <0x0 0x70090000 0x0 0x8000>,
> >> <0x0 0x70098000 0x0 0x00d0>;
> >> <0x0 0x70098800 0x0 0x0004>;
> >> <0x0 0x70099000 0x0 0x1000>;
> >> ...
> >> };
> >>
> >> I believe that Thierry and Stephen said that they wished to avoid
> >> multiple devices sharing the same memory ranges, and so we would need to
> >> divvy up the memory map as above. However, I am not sure if this is an
> >> ok thing to do.
> >>
> >>> Two solutions spring to mind. You can either call
> >>> of_platform_populate() from the USB driver, as some already do:
> >>>
> >>> drivers/usb/dwc3/dwc3-exynos.c:
> >>> ret = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/dwc3/dwc3-keystone.c:
> >>> error = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/dwc3/dwc3-omap.c:
> >>> ret = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/dwc3/dwc3-qcom.c:
> >>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> >>> drivers/usb/dwc3/dwc3-st.c:
> >>> ret = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/musb/musb_am335x.c:
> >>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> >>>
> >>> Or use the "simple-mfd", which is currently in -next:
> >>>
> >>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> >>
> >> That is nice. Sounds like the "simple-bus" style of device but for an
> >
> > That's precisely what it does. FYI: You 'can' use "simple-bus" and it
> > will do the right thing, but as an MFD isn't really a bus, it was
> > decided to create something a little more fitting.
> >
> >> mfd. Based upon the above, let me know if you think we could use the
> >> "simple-mfd"?
> >
> > I do. :)
>
> Thanks Lee.
>
> Thierry, any objections on the above mem-mapping?
If you have the mailbox as the child device and use "simple-mfd", you
don't need to slice up the memory do you?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 10:23 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-14 10:23 UTC (permalink / raw)
To: Jon Hunter
Cc: Thierry Reding, Andrew Bresticker, Stephen Warren,
Alexandre Courbot, devicetree, linux-tegra, linux-usb,
linux-arm-kernel, linux-kernel, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, 14 May 2015, Jon Hunter wrote:
> On 14/05/15 10:30, Lee Jones wrote:
> > On Thu, 14 May 2015, Jon Hunter wrote:
> >> On 14/05/15 08:40, Lee Jones wrote:
> >>> On Thu, 14 May 2015, Jon Hunter wrote:
> >>>> On 13/05/15 15:39, Lee Jones wrote:
> >>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>>>>
> >>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>>>>> and later SoCs. The XUSB host complex includes a mailbox for
> >>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
> >>>>>>
> >>>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>>> Cc: Pawel Moll <pawel.moll@arm.com>
> >>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
> >>>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >>>>>> Cc: Kumar Gala <galak@codeaurora.org>
> >>>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >>>>>> Cc: Lee Jones <lee.jones@linaro.org>
> >>>>>> ---
> >>>>>> Changes from v7:
> >>>>>> - Move non-shared resources into child nodes.
> >>>>>> New for v7.
> >>>>>> ---
> >>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>>>>> 1 file changed, 37 insertions(+)
> >>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> new file mode 100644
> >>>>>> index 0000000..bc50110
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>>>>> @@ -0,0 +1,37 @@
> >>>>>> +NVIDIA Tegra XUSB host copmlex
> >>>>>> +==============================
> >>>>>> +
> >>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
> >>>>>> +
> >>>>>> +Required properties:
> >>>>>> +--------------------
> >>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>>>>> + where <chip> is tegra132.
> >>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>>>>> + mapping is 1:1.
> >>>>>> + - #address-cells: Must be 2.
> >>>>>> + - #size-cells: Must be 2.
> >>>>>> +
> >>>>>> +Example:
> >>>>>> +--------
> >>>>>> + usb@0,70098000 {
> >>>>>> + compatible = "nvidia,tegra124-xusb";
> >>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>>>>> + ranges;
> >>>>>> +
> >>>>>> + #address-cells = <2>;
> >>>>>> + #size-cells = <2>;
> >>>>>> +
> >>>>>> + usb-host@0,70090000 {
> >>>>>> + compatible = "nvidia,tegra124-xhci";
> >>>>>> + ...
> >>>>>> + };
> >>>>>> +
> >>>>>> + mailbox {
> >>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
> >>>>>> + ...
> >>>>>> + };
> >>>>>
> >>>>> This doesn't appear to be a proper MFD. I would have the USB and
> >>>>> Mailbox devices probe seperately and use a phandle to point the USB
> >>>>> device to its Mailbox.
> >>>>>
> >>>>> usb@xyz {
> >>>>> mboxes = <&xusb-mailbox, [chan]>;
> >>>>> };
> >>>>>
> >>>>
> >>>> I am assuming that Andrew had laid it out like this to reflect the hw
> >>>> structure. The mailbox and xhci controller are part of the xusb
> >>>> sub-system and hence appear as child nodes. My understanding is that for
> >>>> device-tree we want the device-tree structure to reflect the actual hw.
> >>>> Is this not the case?
> >>>
> >>> Yes, the DT files should reflect h/w. I have requested to see what
> >>> the memory map looks like, so I might provide a more appropriate
> >>> solution to accepting a pretty pointless MFD.
> >>
> >> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
> >>
> >> Within this range, we have this fpci range which is defined as 0x7009800
> >> - 0x70098fff. This range is being shared between the mailbox and xhci
> >> drivers. Looking at the drivers, we have ...
> >>
> >> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
> >> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
> >>
> >> So it is a bit messy as they overlap. However, we could have ...
> >>
> >> xusb_mbox: mailbox {
> >> compatible = "nvidia,tegra124-xusb-mbox";
> >> reg = <0x0 0x700980e0 0x0 0x14>,
> >> <0x0 0x70098428 0x0 0x4>;
> >> ...
> >> };
> >> usb-host@0,70090000 {
> >> compatible = "nvidia,tegra124-xhci";
> >> reg = <0x0 0x70090000 0x0 0x8000>,
> >> <0x0 0x70098000 0x0 0x00d0>;
> >> <0x0 0x70098800 0x0 0x0004>;
> >> <0x0 0x70099000 0x0 0x1000>;
> >> ...
> >> };
> >>
> >> I believe that Thierry and Stephen said that they wished to avoid
> >> multiple devices sharing the same memory ranges, and so we would need to
> >> divvy up the memory map as above. However, I am not sure if this is an
> >> ok thing to do.
> >>
> >>> Two solutions spring to mind. You can either call
> >>> of_platform_populate() from the USB driver, as some already do:
> >>>
> >>> drivers/usb/dwc3/dwc3-exynos.c:
> >>> ret = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/dwc3/dwc3-keystone.c:
> >>> error = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/dwc3/dwc3-omap.c:
> >>> ret = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/dwc3/dwc3-qcom.c:
> >>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> >>> drivers/usb/dwc3/dwc3-st.c:
> >>> ret = of_platform_populate(node, NULL, NULL, dev);
> >>> drivers/usb/musb/musb_am335x.c:
> >>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> >>>
> >>> Or use the "simple-mfd", which is currently in -next:
> >>>
> >>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> >>
> >> That is nice. Sounds like the "simple-bus" style of device but for an
> >
> > That's precisely what it does. FYI: You 'can' use "simple-bus" and it
> > will do the right thing, but as an MFD isn't really a bus, it was
> > decided to create something a little more fitting.
> >
> >> mfd. Based upon the above, let me know if you think we could use the
> >> "simple-mfd"?
> >
> > I do. :)
>
> Thanks Lee.
>
> Thierry, any objections on the above mem-mapping?
If you have the mailbox as the child device and use "simple-mfd", you
don't need to slice up the memory do you?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-14 10:23 ` Lee Jones
(?)
@ 2015-05-14 11:21 ` Jon Hunter
-1 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 11:21 UTC (permalink / raw)
To: Lee Jones
Cc: Thierry Reding, Andrew Bresticker, Stephen Warren,
Alexandre Courbot, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On 14/05/15 11:23, Lee Jones wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>> On 14/05/15 10:30, Lee Jones wrote:
>>> On Thu, 14 May 2015, Jon Hunter wrote:
>>>> On 14/05/15 08:40, Lee Jones wrote:
>>>>> On Thu, 14 May 2015, Jon Hunter wrote:
>>>>>> On 13/05/15 15:39, Lee Jones wrote:
>>>>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>>>>>
>>>>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>>>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>>>>>
>>>>>>>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>>>>>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>>>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>>>>>>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>>>>>>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>>>>>>>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>>>>>> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>>>>>> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>>>>>>> ---
>>>>>>>> Changes from v7:
>>>>>>>> - Move non-shared resources into child nodes.
>>>>>>>> New for v7.
>>>>>>>> ---
>>>>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>>>>>> 1 file changed, 37 insertions(+)
>>>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..bc50110
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>>> @@ -0,0 +1,37 @@
>>>>>>>> +NVIDIA Tegra XUSB host copmlex
>>>>>>>> +==============================
>>>>>>>> +
>>>>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +--------------------
>>>>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>>>>>> + where <chip> is tegra132.
>>>>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>>>>>> + mapping is 1:1.
>>>>>>>> + - #address-cells: Must be 2.
>>>>>>>> + - #size-cells: Must be 2.
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> +--------
>>>>>>>> + usb@0,70098000 {
>>>>>>>> + compatible = "nvidia,tegra124-xusb";
>>>>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>>>>>> + ranges;
>>>>>>>> +
>>>>>>>> + #address-cells = <2>;
>>>>>>>> + #size-cells = <2>;
>>>>>>>> +
>>>>>>>> + usb-host@0,70090000 {
>>>>>>>> + compatible = "nvidia,tegra124-xhci";
>>>>>>>> + ...
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + mailbox {
>>>>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>>>>>> + ...
>>>>>>>> + };
>>>>>>>
>>>>>>> This doesn't appear to be a proper MFD. I would have the USB and
>>>>>>> Mailbox devices probe seperately and use a phandle to point the USB
>>>>>>> device to its Mailbox.
>>>>>>>
>>>>>>> usb@xyz {
>>>>>>> mboxes = <&xusb-mailbox, [chan]>;
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> I am assuming that Andrew had laid it out like this to reflect the hw
>>>>>> structure. The mailbox and xhci controller are part of the xusb
>>>>>> sub-system and hence appear as child nodes. My understanding is that for
>>>>>> device-tree we want the device-tree structure to reflect the actual hw.
>>>>>> Is this not the case?
>>>>>
>>>>> Yes, the DT files should reflect h/w. I have requested to see what
>>>>> the memory map looks like, so I might provide a more appropriate
>>>>> solution to accepting a pretty pointless MFD.
>>>>
>>>> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
>>>>
>>>> Within this range, we have this fpci range which is defined as 0x7009800
>>>> - 0x70098fff. This range is being shared between the mailbox and xhci
>>>> drivers. Looking at the drivers, we have ...
>>>>
>>>> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
>>>> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
>>>>
>>>> So it is a bit messy as they overlap. However, we could have ...
>>>>
>>>> xusb_mbox: mailbox {
>>>> compatible = "nvidia,tegra124-xusb-mbox";
>>>> reg = <0x0 0x700980e0 0x0 0x14>,
>>>> <0x0 0x70098428 0x0 0x4>;
>>>> ...
>>>> };
>>>> usb-host@0,70090000 {
>>>> compatible = "nvidia,tegra124-xhci";
>>>> reg = <0x0 0x70090000 0x0 0x8000>,
>>>> <0x0 0x70098000 0x0 0x00d0>;
>>>> <0x0 0x70098800 0x0 0x0004>;
>>>> <0x0 0x70099000 0x0 0x1000>;
>>>> ...
>>>> };
>>>>
>>>> I believe that Thierry and Stephen said that they wished to avoid
>>>> multiple devices sharing the same memory ranges, and so we would need to
>>>> divvy up the memory map as above. However, I am not sure if this is an
>>>> ok thing to do.
>>>>
>>>>> Two solutions spring to mind. You can either call
>>>>> of_platform_populate() from the USB driver, as some already do:
>>>>>
>>>>> drivers/usb/dwc3/dwc3-exynos.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/dwc3/dwc3-keystone.c:
>>>>> error = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/dwc3/dwc3-omap.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/dwc3/dwc3-qcom.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
>>>>> drivers/usb/dwc3/dwc3-st.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/musb/musb_am335x.c:
>>>>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>>>>>
>>>>> Or use the "simple-mfd", which is currently in -next:
>>>>>
>>>>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>>>>
>>>> That is nice. Sounds like the "simple-bus" style of device but for an
>>>
>>> That's precisely what it does. FYI: You 'can' use "simple-bus" and it
>>> will do the right thing, but as an MFD isn't really a bus, it was
>>> decided to create something a little more fitting.
>>>
>>>> mfd. Based upon the above, let me know if you think we could use the
>>>> "simple-mfd"?
>>>
>>> I do. :)
>>
>> Thanks Lee.
>>
>> Thierry, any objections on the above mem-mapping?
>
> If you have the mailbox as the child device and use "simple-mfd", you
> don't need to slice up the memory do you?
Ok, I see what you are saying and I know that was what Andrew was doing
in this patch (just not with the "simple-mfd").
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 11:21 ` Jon Hunter
0 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 11:21 UTC (permalink / raw)
To: linux-arm-kernel
On 14/05/15 11:23, Lee Jones wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>> On 14/05/15 10:30, Lee Jones wrote:
>>> On Thu, 14 May 2015, Jon Hunter wrote:
>>>> On 14/05/15 08:40, Lee Jones wrote:
>>>>> On Thu, 14 May 2015, Jon Hunter wrote:
>>>>>> On 13/05/15 15:39, Lee Jones wrote:
>>>>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>>>>>
>>>>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>>>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>>>>>
>>>>>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>>>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>>>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>>>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>>>>>>>> Cc: Lee Jones <lee.jones@linaro.org>
>>>>>>>> ---
>>>>>>>> Changes from v7:
>>>>>>>> - Move non-shared resources into child nodes.
>>>>>>>> New for v7.
>>>>>>>> ---
>>>>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>>>>>> 1 file changed, 37 insertions(+)
>>>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..bc50110
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>>> @@ -0,0 +1,37 @@
>>>>>>>> +NVIDIA Tegra XUSB host copmlex
>>>>>>>> +==============================
>>>>>>>> +
>>>>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +--------------------
>>>>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>>>>>> + where <chip> is tegra132.
>>>>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>>>>>> + mapping is 1:1.
>>>>>>>> + - #address-cells: Must be 2.
>>>>>>>> + - #size-cells: Must be 2.
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> +--------
>>>>>>>> + usb at 0,70098000 {
>>>>>>>> + compatible = "nvidia,tegra124-xusb";
>>>>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>>>>>> + ranges;
>>>>>>>> +
>>>>>>>> + #address-cells = <2>;
>>>>>>>> + #size-cells = <2>;
>>>>>>>> +
>>>>>>>> + usb-host at 0,70090000 {
>>>>>>>> + compatible = "nvidia,tegra124-xhci";
>>>>>>>> + ...
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + mailbox {
>>>>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>>>>>> + ...
>>>>>>>> + };
>>>>>>>
>>>>>>> This doesn't appear to be a proper MFD. I would have the USB and
>>>>>>> Mailbox devices probe seperately and use a phandle to point the USB
>>>>>>> device to its Mailbox.
>>>>>>>
>>>>>>> usb at xyz {
>>>>>>> mboxes = <&xusb-mailbox, [chan]>;
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> I am assuming that Andrew had laid it out like this to reflect the hw
>>>>>> structure. The mailbox and xhci controller are part of the xusb
>>>>>> sub-system and hence appear as child nodes. My understanding is that for
>>>>>> device-tree we want the device-tree structure to reflect the actual hw.
>>>>>> Is this not the case?
>>>>>
>>>>> Yes, the DT files should reflect h/w. I have requested to see what
>>>>> the memory map looks like, so I might provide a more appropriate
>>>>> solution to accepting a pretty pointless MFD.
>>>>
>>>> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
>>>>
>>>> Within this range, we have this fpci range which is defined as 0x7009800
>>>> - 0x70098fff. This range is being shared between the mailbox and xhci
>>>> drivers. Looking at the drivers, we have ...
>>>>
>>>> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
>>>> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
>>>>
>>>> So it is a bit messy as they overlap. However, we could have ...
>>>>
>>>> xusb_mbox: mailbox {
>>>> compatible = "nvidia,tegra124-xusb-mbox";
>>>> reg = <0x0 0x700980e0 0x0 0x14>,
>>>> <0x0 0x70098428 0x0 0x4>;
>>>> ...
>>>> };
>>>> usb-host at 0,70090000 {
>>>> compatible = "nvidia,tegra124-xhci";
>>>> reg = <0x0 0x70090000 0x0 0x8000>,
>>>> <0x0 0x70098000 0x0 0x00d0>;
>>>> <0x0 0x70098800 0x0 0x0004>;
>>>> <0x0 0x70099000 0x0 0x1000>;
>>>> ...
>>>> };
>>>>
>>>> I believe that Thierry and Stephen said that they wished to avoid
>>>> multiple devices sharing the same memory ranges, and so we would need to
>>>> divvy up the memory map as above. However, I am not sure if this is an
>>>> ok thing to do.
>>>>
>>>>> Two solutions spring to mind. You can either call
>>>>> of_platform_populate() from the USB driver, as some already do:
>>>>>
>>>>> drivers/usb/dwc3/dwc3-exynos.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/dwc3/dwc3-keystone.c:
>>>>> error = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/dwc3/dwc3-omap.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/dwc3/dwc3-qcom.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
>>>>> drivers/usb/dwc3/dwc3-st.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/musb/musb_am335x.c:
>>>>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>>>>>
>>>>> Or use the "simple-mfd", which is currently in -next:
>>>>>
>>>>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>>>>
>>>> That is nice. Sounds like the "simple-bus" style of device but for an
>>>
>>> That's precisely what it does. FYI: You 'can' use "simple-bus" and it
>>> will do the right thing, but as an MFD isn't really a bus, it was
>>> decided to create something a little more fitting.
>>>
>>>> mfd. Based upon the above, let me know if you think we could use the
>>>> "simple-mfd"?
>>>
>>> I do. :)
>>
>> Thanks Lee.
>>
>> Thierry, any objections on the above mem-mapping?
>
> If you have the mailbox as the child device and use "simple-mfd", you
> don't need to slice up the memory do you?
Ok, I see what you are saying and I know that was what Andrew was doing
in this patch (just not with the "simple-mfd").
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 11:21 ` Jon Hunter
0 siblings, 0 replies; 136+ messages in thread
From: Jon Hunter @ 2015-05-14 11:21 UTC (permalink / raw)
To: Lee Jones
Cc: Thierry Reding, Andrew Bresticker, Stephen Warren,
Alexandre Courbot, devicetree, linux-tegra, linux-usb,
linux-arm-kernel, linux-kernel, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On 14/05/15 11:23, Lee Jones wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>> On 14/05/15 10:30, Lee Jones wrote:
>>> On Thu, 14 May 2015, Jon Hunter wrote:
>>>> On 14/05/15 08:40, Lee Jones wrote:
>>>>> On Thu, 14 May 2015, Jon Hunter wrote:
>>>>>> On 13/05/15 15:39, Lee Jones wrote:
>>>>>>> On Mon, 04 May 2015, Andrew Bresticker wrote:
>>>>>>>
>>>>>>>> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>>>>>>> and later SoCs. The XUSB host complex includes a mailbox for
>>>>>>>> communication with the XUSB micro-controller and an xHCI host-controller.
>>>>>>>>
>>>>>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>>>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>>>>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>>>>>>> Cc: Kumar Gala <galak@codeaurora.org>
>>>>>>>> Cc: Samuel Ortiz <sameo@linux.intel.com>
>>>>>>>> Cc: Lee Jones <lee.jones@linaro.org>
>>>>>>>> ---
>>>>>>>> Changes from v7:
>>>>>>>> - Move non-shared resources into child nodes.
>>>>>>>> New for v7.
>>>>>>>> ---
>>>>>>>> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>>>>>>> 1 file changed, 37 insertions(+)
>>>>>>>> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..bc50110
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>>>>>>> @@ -0,0 +1,37 @@
>>>>>>>> +NVIDIA Tegra XUSB host copmlex
>>>>>>>> +==============================
>>>>>>>> +
>>>>>>>> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>>>>>>> +controller and a mailbox for communication with the XUSB micro-controller.
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +--------------------
>>>>>>>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>>>>>>> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>>>>>>> + where <chip> is tegra132.
>>>>>>>> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>>>>>>> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>>>>>>> + mapping is 1:1.
>>>>>>>> + - #address-cells: Must be 2.
>>>>>>>> + - #size-cells: Must be 2.
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> +--------
>>>>>>>> + usb@0,70098000 {
>>>>>>>> + compatible = "nvidia,tegra124-xusb";
>>>>>>>> + reg = <0x0 0x70098000 0x0 0x1000>;
>>>>>>>> + ranges;
>>>>>>>> +
>>>>>>>> + #address-cells = <2>;
>>>>>>>> + #size-cells = <2>;
>>>>>>>> +
>>>>>>>> + usb-host@0,70090000 {
>>>>>>>> + compatible = "nvidia,tegra124-xhci";
>>>>>>>> + ...
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + mailbox {
>>>>>>>> + compatible = "nvidia,tegra124-xusb-mbox";
>>>>>>>> + ...
>>>>>>>> + };
>>>>>>>
>>>>>>> This doesn't appear to be a proper MFD. I would have the USB and
>>>>>>> Mailbox devices probe seperately and use a phandle to point the USB
>>>>>>> device to its Mailbox.
>>>>>>>
>>>>>>> usb@xyz {
>>>>>>> mboxes = <&xusb-mailbox, [chan]>;
>>>>>>> };
>>>>>>>
>>>>>>
>>>>>> I am assuming that Andrew had laid it out like this to reflect the hw
>>>>>> structure. The mailbox and xhci controller are part of the xusb
>>>>>> sub-system and hence appear as child nodes. My understanding is that for
>>>>>> device-tree we want the device-tree structure to reflect the actual hw.
>>>>>> Is this not the case?
>>>>>
>>>>> Yes, the DT files should reflect h/w. I have requested to see what
>>>>> the memory map looks like, so I might provide a more appropriate
>>>>> solution to accepting a pretty pointless MFD.
>>>>
>>>> For the xusb-host has memory from 0x7009000 - 0x7009ffff.
>>>>
>>>> Within this range, we have this fpci range which is defined as 0x7009800
>>>> - 0x70098fff. This range is being shared between the mailbox and xhci
>>>> drivers. Looking at the drivers, we have ...
>>>>
>>>> mailbox uses: 0x700980e0 - 0x700980f3 and 0x70098428 - 0x7009842b.
>>>> xhci uses: 0x70098000 - 0x700980cf and 0x70098800 - 0x70098803.
>>>>
>>>> So it is a bit messy as they overlap. However, we could have ...
>>>>
>>>> xusb_mbox: mailbox {
>>>> compatible = "nvidia,tegra124-xusb-mbox";
>>>> reg = <0x0 0x700980e0 0x0 0x14>,
>>>> <0x0 0x70098428 0x0 0x4>;
>>>> ...
>>>> };
>>>> usb-host@0,70090000 {
>>>> compatible = "nvidia,tegra124-xhci";
>>>> reg = <0x0 0x70090000 0x0 0x8000>,
>>>> <0x0 0x70098000 0x0 0x00d0>;
>>>> <0x0 0x70098800 0x0 0x0004>;
>>>> <0x0 0x70099000 0x0 0x1000>;
>>>> ...
>>>> };
>>>>
>>>> I believe that Thierry and Stephen said that they wished to avoid
>>>> multiple devices sharing the same memory ranges, and so we would need to
>>>> divvy up the memory map as above. However, I am not sure if this is an
>>>> ok thing to do.
>>>>
>>>>> Two solutions spring to mind. You can either call
>>>>> of_platform_populate() from the USB driver, as some already do:
>>>>>
>>>>> drivers/usb/dwc3/dwc3-exynos.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/dwc3/dwc3-keystone.c:
>>>>> error = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/dwc3/dwc3-omap.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/dwc3/dwc3-qcom.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
>>>>> drivers/usb/dwc3/dwc3-st.c:
>>>>> ret = of_platform_populate(node, NULL, NULL, dev);
>>>>> drivers/usb/musb/musb_am335x.c:
>>>>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>>>>>
>>>>> Or use the "simple-mfd", which is currently in -next:
>>>>>
>>>>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>>>>
>>>> That is nice. Sounds like the "simple-bus" style of device but for an
>>>
>>> That's precisely what it does. FYI: You 'can' use "simple-bus" and it
>>> will do the right thing, but as an MFD isn't really a bus, it was
>>> decided to create something a little more fitting.
>>>
>>>> mfd. Based upon the above, let me know if you think we could use the
>>>> "simple-mfd"?
>>>
>>> I do. :)
>>
>> Thanks Lee.
>>
>> Thierry, any objections on the above mem-mapping?
>
> If you have the mailbox as the child device and use "simple-mfd", you
> don't need to slice up the memory do you?
Ok, I see what you are saying and I know that was what Andrew was doing
in this patch (just not with the "simple-mfd").
Cheers
Jon
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-14 7:40 ` Lee Jones
(?)
@ 2015-05-14 17:38 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-14 17:38 UTC (permalink / raw)
To: Lee Jones
Cc: Jon Hunter, Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>
>> Hi Lee,
>>
>> On 13/05/15 15:39, Lee Jones wrote:
>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
>> >
>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> >> and later SoCs. The XUSB host complex includes a mailbox for
>> >> communication with the XUSB micro-controller and an xHCI host-controller.
>> >>
>> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> >> ---
>> >> Changes from v7:
>> >> - Move non-shared resources into child nodes.
>> >> New for v7.
>> >> ---
>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> >> 1 file changed, 37 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> new file mode 100644
>> >> index 0000000..bc50110
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> @@ -0,0 +1,37 @@
>> >> +NVIDIA Tegra XUSB host copmlex
>> >> +==============================
>> >> +
>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> >> +controller and a mailbox for communication with the XUSB micro-controller.
>> >> +
>> >> +Required properties:
>> >> +--------------------
>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> >> + where <chip> is tegra132.
>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> >> + mapping is 1:1.
>> >> + - #address-cells: Must be 2.
>> >> + - #size-cells: Must be 2.
>> >> +
>> >> +Example:
>> >> +--------
>> >> + usb@0,70098000 {
>> >> + compatible = "nvidia,tegra124-xusb";
>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
>> >> + ranges;
>> >> +
>> >> + #address-cells = <2>;
>> >> + #size-cells = <2>;
>> >> +
>> >> + usb-host@0,70090000 {
>> >> + compatible = "nvidia,tegra124-xhci";
>> >> + ...
>> >> + };
>> >> +
>> >> + mailbox {
>> >> + compatible = "nvidia,tegra124-xusb-mbox";
>> >> + ...
>> >> + };
>> >
>> > This doesn't appear to be a proper MFD. I would have the USB and
>> > Mailbox devices probe seperately and use a phandle to point the USB
>> > device to its Mailbox.
>> >
>> > usb@xyz {
>> > mboxes = <&xusb-mailbox, [chan]>;
>> > };
>> >
>>
>> I am assuming that Andrew had laid it out like this to reflect the hw
>> structure. The mailbox and xhci controller are part of the xusb
>> sub-system and hence appear as child nodes. My understanding is that for
>> device-tree we want the device-tree structure to reflect the actual hw.
>> Is this not the case?
>
> Yes, the DT files should reflect h/w. I have requested to see what
> the memory map looks like, so I might provide a more appropriate
> solution to accepting a pretty pointless MFD.
FWIW, the address map for XUSB looks like this:
XUSB_HOST: 0x70090000 - 0x7009a000
xHCI registers: 0x70090000 - 0x70098000
FPCI configuration registers: 0x70098000 - 0x70099000
IPFS configuration registers: 0x70099000 - 0x7009a000
> Two solutions spring to mind. You can either call
> of_platform_populate() from the USB driver, as some already do:
>
> drivers/usb/dwc3/dwc3-exynos.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-keystone.c:
> error = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-omap.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-qcom.c:
> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> drivers/usb/dwc3/dwc3-st.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/musb/musb_am335x.c:
> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
This still requires a small, separate driver to setup the regmap and
do of_platform_populate(). The only difference is it lives in
drivers/usb/ instead of drivers/mfd/.
> Or use the "simple-mfd", which is currently in -next:
>
> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
I'm not too opposed to this, but Thierry was when I brought this up
before. The issue here is that if we ever have to do something
besides setting up a regmap in the MFD, we'd have to change the
binding and break DT backwards-compatibility.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 17:38 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-14 17:38 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>
>> Hi Lee,
>>
>> On 13/05/15 15:39, Lee Jones wrote:
>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
>> >
>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> >> and later SoCs. The XUSB host complex includes a mailbox for
>> >> communication with the XUSB micro-controller and an xHCI host-controller.
>> >>
>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> >> Cc: Rob Herring <robh+dt@kernel.org>
>> >> Cc: Pawel Moll <pawel.moll@arm.com>
>> >> Cc: Mark Rutland <mark.rutland@arm.com>
>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> >> Cc: Kumar Gala <galak@codeaurora.org>
>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
>> >> Cc: Lee Jones <lee.jones@linaro.org>
>> >> ---
>> >> Changes from v7:
>> >> - Move non-shared resources into child nodes.
>> >> New for v7.
>> >> ---
>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> >> 1 file changed, 37 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> new file mode 100644
>> >> index 0000000..bc50110
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> @@ -0,0 +1,37 @@
>> >> +NVIDIA Tegra XUSB host copmlex
>> >> +==============================
>> >> +
>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> >> +controller and a mailbox for communication with the XUSB micro-controller.
>> >> +
>> >> +Required properties:
>> >> +--------------------
>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> >> + where <chip> is tegra132.
>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> >> + mapping is 1:1.
>> >> + - #address-cells: Must be 2.
>> >> + - #size-cells: Must be 2.
>> >> +
>> >> +Example:
>> >> +--------
>> >> + usb at 0,70098000 {
>> >> + compatible = "nvidia,tegra124-xusb";
>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
>> >> + ranges;
>> >> +
>> >> + #address-cells = <2>;
>> >> + #size-cells = <2>;
>> >> +
>> >> + usb-host at 0,70090000 {
>> >> + compatible = "nvidia,tegra124-xhci";
>> >> + ...
>> >> + };
>> >> +
>> >> + mailbox {
>> >> + compatible = "nvidia,tegra124-xusb-mbox";
>> >> + ...
>> >> + };
>> >
>> > This doesn't appear to be a proper MFD. I would have the USB and
>> > Mailbox devices probe seperately and use a phandle to point the USB
>> > device to its Mailbox.
>> >
>> > usb at xyz {
>> > mboxes = <&xusb-mailbox, [chan]>;
>> > };
>> >
>>
>> I am assuming that Andrew had laid it out like this to reflect the hw
>> structure. The mailbox and xhci controller are part of the xusb
>> sub-system and hence appear as child nodes. My understanding is that for
>> device-tree we want the device-tree structure to reflect the actual hw.
>> Is this not the case?
>
> Yes, the DT files should reflect h/w. I have requested to see what
> the memory map looks like, so I might provide a more appropriate
> solution to accepting a pretty pointless MFD.
FWIW, the address map for XUSB looks like this:
XUSB_HOST: 0x70090000 - 0x7009a000
xHCI registers: 0x70090000 - 0x70098000
FPCI configuration registers: 0x70098000 - 0x70099000
IPFS configuration registers: 0x70099000 - 0x7009a000
> Two solutions spring to mind. You can either call
> of_platform_populate() from the USB driver, as some already do:
>
> drivers/usb/dwc3/dwc3-exynos.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-keystone.c:
> error = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-omap.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-qcom.c:
> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> drivers/usb/dwc3/dwc3-st.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/musb/musb_am335x.c:
> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
This still requires a small, separate driver to setup the regmap and
do of_platform_populate(). The only difference is it lives in
drivers/usb/ instead of drivers/mfd/.
> Or use the "simple-mfd", which is currently in -next:
>
> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
I'm not too opposed to this, but Thierry was when I brought this up
before. The issue here is that if we ever have to do something
besides setting up a regmap in the MFD, we'd have to change the
binding and break DT backwards-compatibility.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-14 17:38 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-14 17:38 UTC (permalink / raw)
To: Lee Jones
Cc: Jon Hunter, Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 14 May 2015, Jon Hunter wrote:
>
>> Hi Lee,
>>
>> On 13/05/15 15:39, Lee Jones wrote:
>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
>> >
>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>> >> and later SoCs. The XUSB host complex includes a mailbox for
>> >> communication with the XUSB micro-controller and an xHCI host-controller.
>> >>
>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> >> Cc: Rob Herring <robh+dt@kernel.org>
>> >> Cc: Pawel Moll <pawel.moll@arm.com>
>> >> Cc: Mark Rutland <mark.rutland@arm.com>
>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> >> Cc: Kumar Gala <galak@codeaurora.org>
>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
>> >> Cc: Lee Jones <lee.jones@linaro.org>
>> >> ---
>> >> Changes from v7:
>> >> - Move non-shared resources into child nodes.
>> >> New for v7.
>> >> ---
>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>> >> 1 file changed, 37 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> new file mode 100644
>> >> index 0000000..bc50110
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>> >> @@ -0,0 +1,37 @@
>> >> +NVIDIA Tegra XUSB host copmlex
>> >> +==============================
>> >> +
>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>> >> +controller and a mailbox for communication with the XUSB micro-controller.
>> >> +
>> >> +Required properties:
>> >> +--------------------
>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>> >> + where <chip> is tegra132.
>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>> >> + mapping is 1:1.
>> >> + - #address-cells: Must be 2.
>> >> + - #size-cells: Must be 2.
>> >> +
>> >> +Example:
>> >> +--------
>> >> + usb@0,70098000 {
>> >> + compatible = "nvidia,tegra124-xusb";
>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
>> >> + ranges;
>> >> +
>> >> + #address-cells = <2>;
>> >> + #size-cells = <2>;
>> >> +
>> >> + usb-host@0,70090000 {
>> >> + compatible = "nvidia,tegra124-xhci";
>> >> + ...
>> >> + };
>> >> +
>> >> + mailbox {
>> >> + compatible = "nvidia,tegra124-xusb-mbox";
>> >> + ...
>> >> + };
>> >
>> > This doesn't appear to be a proper MFD. I would have the USB and
>> > Mailbox devices probe seperately and use a phandle to point the USB
>> > device to its Mailbox.
>> >
>> > usb@xyz {
>> > mboxes = <&xusb-mailbox, [chan]>;
>> > };
>> >
>>
>> I am assuming that Andrew had laid it out like this to reflect the hw
>> structure. The mailbox and xhci controller are part of the xusb
>> sub-system and hence appear as child nodes. My understanding is that for
>> device-tree we want the device-tree structure to reflect the actual hw.
>> Is this not the case?
>
> Yes, the DT files should reflect h/w. I have requested to see what
> the memory map looks like, so I might provide a more appropriate
> solution to accepting a pretty pointless MFD.
FWIW, the address map for XUSB looks like this:
XUSB_HOST: 0x70090000 - 0x7009a000
xHCI registers: 0x70090000 - 0x70098000
FPCI configuration registers: 0x70098000 - 0x70099000
IPFS configuration registers: 0x70099000 - 0x7009a000
> Two solutions spring to mind. You can either call
> of_platform_populate() from the USB driver, as some already do:
>
> drivers/usb/dwc3/dwc3-exynos.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-keystone.c:
> error = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-omap.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/dwc3/dwc3-qcom.c:
> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> drivers/usb/dwc3/dwc3-st.c:
> ret = of_platform_populate(node, NULL, NULL, dev);
> drivers/usb/musb/musb_am335x.c:
> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
This still requires a small, separate driver to setup the regmap and
do of_platform_populate(). The only difference is it lives in
drivers/usb/ instead of drivers/mfd/.
> Or use the "simple-mfd", which is currently in -next:
>
> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
I'm not too opposed to this, but Thierry was when I brought this up
before. The issue here is that if we ever have to do something
besides setting up a regmap in the MFD, we'd have to change the
binding and break DT backwards-compatibility.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread[parent not found: <CAL1qeaEqNejuGkN-ke11mtWnaaRo+XieCBkQ6+NQ-Afym6uxVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-14 17:38 ` Andrew Bresticker
(?)
@ 2015-05-19 18:36 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-19 18:36 UTC (permalink / raw)
To: Lee Jones
Cc: Jon Hunter, Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
Lee,
On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
<abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Thu, 14 May 2015, Jon Hunter wrote:
>>
>>> Hi Lee,
>>>
>>> On 13/05/15 15:39, Lee Jones wrote:
>>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
>>> >
>>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>> >> and later SoCs. The XUSB host complex includes a mailbox for
>>> >> communication with the XUSB micro-controller and an xHCI host-controller.
>>> >>
>>> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>>> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>>> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> >> ---
>>> >> Changes from v7:
>>> >> - Move non-shared resources into child nodes.
>>> >> New for v7.
>>> >> ---
>>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>> >> 1 file changed, 37 insertions(+)
>>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>> >>
>>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>> >> new file mode 100644
>>> >> index 0000000..bc50110
>>> >> --- /dev/null
>>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>> >> @@ -0,0 +1,37 @@
>>> >> +NVIDIA Tegra XUSB host copmlex
>>> >> +==============================
>>> >> +
>>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>> >> +controller and a mailbox for communication with the XUSB micro-controller.
>>> >> +
>>> >> +Required properties:
>>> >> +--------------------
>>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>> >> + where <chip> is tegra132.
>>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>> >> + mapping is 1:1.
>>> >> + - #address-cells: Must be 2.
>>> >> + - #size-cells: Must be 2.
>>> >> +
>>> >> +Example:
>>> >> +--------
>>> >> + usb@0,70098000 {
>>> >> + compatible = "nvidia,tegra124-xusb";
>>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
>>> >> + ranges;
>>> >> +
>>> >> + #address-cells = <2>;
>>> >> + #size-cells = <2>;
>>> >> +
>>> >> + usb-host@0,70090000 {
>>> >> + compatible = "nvidia,tegra124-xhci";
>>> >> + ...
>>> >> + };
>>> >> +
>>> >> + mailbox {
>>> >> + compatible = "nvidia,tegra124-xusb-mbox";
>>> >> + ...
>>> >> + };
>>> >
>>> > This doesn't appear to be a proper MFD. I would have the USB and
>>> > Mailbox devices probe seperately and use a phandle to point the USB
>>> > device to its Mailbox.
>>> >
>>> > usb@xyz {
>>> > mboxes = <&xusb-mailbox, [chan]>;
>>> > };
>>> >
>>>
>>> I am assuming that Andrew had laid it out like this to reflect the hw
>>> structure. The mailbox and xhci controller are part of the xusb
>>> sub-system and hence appear as child nodes. My understanding is that for
>>> device-tree we want the device-tree structure to reflect the actual hw.
>>> Is this not the case?
>>
>> Yes, the DT files should reflect h/w. I have requested to see what
>> the memory map looks like, so I might provide a more appropriate
>> solution to accepting a pretty pointless MFD.
>
> FWIW, the address map for XUSB looks like this:
>
> XUSB_HOST: 0x70090000 - 0x7009a000
> xHCI registers: 0x70090000 - 0x70098000
> FPCI configuration registers: 0x70098000 - 0x70099000
> IPFS configuration registers: 0x70099000 - 0x7009a000
>
>> Two solutions spring to mind. You can either call
>> of_platform_populate() from the USB driver, as some already do:
>>
>> drivers/usb/dwc3/dwc3-exynos.c:
>> ret = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/dwc3/dwc3-keystone.c:
>> error = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/dwc3/dwc3-omap.c:
>> ret = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/dwc3/dwc3-qcom.c:
>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
>> drivers/usb/dwc3/dwc3-st.c:
>> ret = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/musb/musb_am335x.c:
>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>
> This still requires a small, separate driver to setup the regmap and
> do of_platform_populate(). The only difference is it lives in
> drivers/usb/ instead of drivers/mfd/.
>
>> Or use the "simple-mfd", which is currently in -next:
>>
>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>
> I'm not too opposed to this, but Thierry was when I brought this up
> before. The issue here is that if we ever have to do something
> besides setting up a regmap in the MFD, we'd have to change the
> binding and break DT backwards-compatibility.
Any thoughts on this? A minimal MFD seems to be the best way to
future-proof this binding/driver should it need to be extended in the
future. If this is a firm NAK from you however, I'll need to let
Jassi now so that he can un-queue the mailbox patches for 4.2....
Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-19 18:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-19 18:36 UTC (permalink / raw)
To: linux-arm-kernel
Lee,
On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
<abrestic@chromium.org> wrote:
> On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> On Thu, 14 May 2015, Jon Hunter wrote:
>>
>>> Hi Lee,
>>>
>>> On 13/05/15 15:39, Lee Jones wrote:
>>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
>>> >
>>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>> >> and later SoCs. The XUSB host complex includes a mailbox for
>>> >> communication with the XUSB micro-controller and an xHCI host-controller.
>>> >>
>>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>> >> Cc: Rob Herring <robh+dt@kernel.org>
>>> >> Cc: Pawel Moll <pawel.moll@arm.com>
>>> >> Cc: Mark Rutland <mark.rutland@arm.com>
>>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>> >> Cc: Kumar Gala <galak@codeaurora.org>
>>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
>>> >> Cc: Lee Jones <lee.jones@linaro.org>
>>> >> ---
>>> >> Changes from v7:
>>> >> - Move non-shared resources into child nodes.
>>> >> New for v7.
>>> >> ---
>>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>> >> 1 file changed, 37 insertions(+)
>>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>> >>
>>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>> >> new file mode 100644
>>> >> index 0000000..bc50110
>>> >> --- /dev/null
>>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>> >> @@ -0,0 +1,37 @@
>>> >> +NVIDIA Tegra XUSB host copmlex
>>> >> +==============================
>>> >> +
>>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>> >> +controller and a mailbox for communication with the XUSB micro-controller.
>>> >> +
>>> >> +Required properties:
>>> >> +--------------------
>>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>> >> + where <chip> is tegra132.
>>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>> >> + mapping is 1:1.
>>> >> + - #address-cells: Must be 2.
>>> >> + - #size-cells: Must be 2.
>>> >> +
>>> >> +Example:
>>> >> +--------
>>> >> + usb at 0,70098000 {
>>> >> + compatible = "nvidia,tegra124-xusb";
>>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
>>> >> + ranges;
>>> >> +
>>> >> + #address-cells = <2>;
>>> >> + #size-cells = <2>;
>>> >> +
>>> >> + usb-host at 0,70090000 {
>>> >> + compatible = "nvidia,tegra124-xhci";
>>> >> + ...
>>> >> + };
>>> >> +
>>> >> + mailbox {
>>> >> + compatible = "nvidia,tegra124-xusb-mbox";
>>> >> + ...
>>> >> + };
>>> >
>>> > This doesn't appear to be a proper MFD. I would have the USB and
>>> > Mailbox devices probe seperately and use a phandle to point the USB
>>> > device to its Mailbox.
>>> >
>>> > usb at xyz {
>>> > mboxes = <&xusb-mailbox, [chan]>;
>>> > };
>>> >
>>>
>>> I am assuming that Andrew had laid it out like this to reflect the hw
>>> structure. The mailbox and xhci controller are part of the xusb
>>> sub-system and hence appear as child nodes. My understanding is that for
>>> device-tree we want the device-tree structure to reflect the actual hw.
>>> Is this not the case?
>>
>> Yes, the DT files should reflect h/w. I have requested to see what
>> the memory map looks like, so I might provide a more appropriate
>> solution to accepting a pretty pointless MFD.
>
> FWIW, the address map for XUSB looks like this:
>
> XUSB_HOST: 0x70090000 - 0x7009a000
> xHCI registers: 0x70090000 - 0x70098000
> FPCI configuration registers: 0x70098000 - 0x70099000
> IPFS configuration registers: 0x70099000 - 0x7009a000
>
>> Two solutions spring to mind. You can either call
>> of_platform_populate() from the USB driver, as some already do:
>>
>> drivers/usb/dwc3/dwc3-exynos.c:
>> ret = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/dwc3/dwc3-keystone.c:
>> error = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/dwc3/dwc3-omap.c:
>> ret = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/dwc3/dwc3-qcom.c:
>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
>> drivers/usb/dwc3/dwc3-st.c:
>> ret = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/musb/musb_am335x.c:
>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>
> This still requires a small, separate driver to setup the regmap and
> do of_platform_populate(). The only difference is it lives in
> drivers/usb/ instead of drivers/mfd/.
>
>> Or use the "simple-mfd", which is currently in -next:
>>
>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>
> I'm not too opposed to this, but Thierry was when I brought this up
> before. The issue here is that if we ever have to do something
> besides setting up a regmap in the MFD, we'd have to change the
> binding and break DT backwards-compatibility.
Any thoughts on this? A minimal MFD seems to be the best way to
future-proof this binding/driver should it need to be extended in the
future. If this is a firm NAK from you however, I'll need to let
Jassi now so that he can un-queue the mailbox patches for 4.2....
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-19 18:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-19 18:36 UTC (permalink / raw)
To: Lee Jones
Cc: Jon Hunter, Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz
Lee,
On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
<abrestic@chromium.org> wrote:
> On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> On Thu, 14 May 2015, Jon Hunter wrote:
>>
>>> Hi Lee,
>>>
>>> On 13/05/15 15:39, Lee Jones wrote:
>>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
>>> >
>>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
>>> >> and later SoCs. The XUSB host complex includes a mailbox for
>>> >> communication with the XUSB micro-controller and an xHCI host-controller.
>>> >>
>>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>> >> Cc: Rob Herring <robh+dt@kernel.org>
>>> >> Cc: Pawel Moll <pawel.moll@arm.com>
>>> >> Cc: Mark Rutland <mark.rutland@arm.com>
>>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>> >> Cc: Kumar Gala <galak@codeaurora.org>
>>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
>>> >> Cc: Lee Jones <lee.jones@linaro.org>
>>> >> ---
>>> >> Changes from v7:
>>> >> - Move non-shared resources into child nodes.
>>> >> New for v7.
>>> >> ---
>>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
>>> >> 1 file changed, 37 insertions(+)
>>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>> >>
>>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>> >> new file mode 100644
>>> >> index 0000000..bc50110
>>> >> --- /dev/null
>>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
>>> >> @@ -0,0 +1,37 @@
>>> >> +NVIDIA Tegra XUSB host copmlex
>>> >> +==============================
>>> >> +
>>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
>>> >> +controller and a mailbox for communication with the XUSB micro-controller.
>>> >> +
>>> >> +Required properties:
>>> >> +--------------------
>>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
>>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
>>> >> + where <chip> is tegra132.
>>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
>>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
>>> >> + mapping is 1:1.
>>> >> + - #address-cells: Must be 2.
>>> >> + - #size-cells: Must be 2.
>>> >> +
>>> >> +Example:
>>> >> +--------
>>> >> + usb@0,70098000 {
>>> >> + compatible = "nvidia,tegra124-xusb";
>>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
>>> >> + ranges;
>>> >> +
>>> >> + #address-cells = <2>;
>>> >> + #size-cells = <2>;
>>> >> +
>>> >> + usb-host@0,70090000 {
>>> >> + compatible = "nvidia,tegra124-xhci";
>>> >> + ...
>>> >> + };
>>> >> +
>>> >> + mailbox {
>>> >> + compatible = "nvidia,tegra124-xusb-mbox";
>>> >> + ...
>>> >> + };
>>> >
>>> > This doesn't appear to be a proper MFD. I would have the USB and
>>> > Mailbox devices probe seperately and use a phandle to point the USB
>>> > device to its Mailbox.
>>> >
>>> > usb@xyz {
>>> > mboxes = <&xusb-mailbox, [chan]>;
>>> > };
>>> >
>>>
>>> I am assuming that Andrew had laid it out like this to reflect the hw
>>> structure. The mailbox and xhci controller are part of the xusb
>>> sub-system and hence appear as child nodes. My understanding is that for
>>> device-tree we want the device-tree structure to reflect the actual hw.
>>> Is this not the case?
>>
>> Yes, the DT files should reflect h/w. I have requested to see what
>> the memory map looks like, so I might provide a more appropriate
>> solution to accepting a pretty pointless MFD.
>
> FWIW, the address map for XUSB looks like this:
>
> XUSB_HOST: 0x70090000 - 0x7009a000
> xHCI registers: 0x70090000 - 0x70098000
> FPCI configuration registers: 0x70098000 - 0x70099000
> IPFS configuration registers: 0x70099000 - 0x7009a000
>
>> Two solutions spring to mind. You can either call
>> of_platform_populate() from the USB driver, as some already do:
>>
>> drivers/usb/dwc3/dwc3-exynos.c:
>> ret = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/dwc3/dwc3-keystone.c:
>> error = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/dwc3/dwc3-omap.c:
>> ret = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/dwc3/dwc3-qcom.c:
>> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
>> drivers/usb/dwc3/dwc3-st.c:
>> ret = of_platform_populate(node, NULL, NULL, dev);
>> drivers/usb/musb/musb_am335x.c:
>> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>
> This still requires a small, separate driver to setup the regmap and
> do of_platform_populate(). The only difference is it lives in
> drivers/usb/ instead of drivers/mfd/.
>
>> Or use the "simple-mfd", which is currently in -next:
>>
>> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
>
> I'm not too opposed to this, but Thierry was when I brought this up
> before. The issue here is that if we ever have to do something
> besides setting up a regmap in the MFD, we'd have to change the
> binding and break DT backwards-compatibility.
Any thoughts on this? A minimal MFD seems to be the best way to
future-proof this binding/driver should it need to be extended in the
future. If this is a firm NAK from you however, I'll need to let
Jassi now so that he can un-queue the mailbox patches for 4.2....
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread[parent not found: <CAL1qeaHy0h7bXhuLHh4AG2Zfu48JYeawgVo4dp_k4oX8YFw6tA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-19 18:36 ` Andrew Bresticker
(?)
@ 2015-05-20 6:35 ` Lee Jones
-1 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-20 6:35 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Jon Hunter, Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Tue, 19 May 2015, Andrew Bresticker wrote:
> Lee,
>
> On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >> On Thu, 14 May 2015, Jon Hunter wrote:
> >>
> >>> Hi Lee,
> >>>
> >>> On 13/05/15 15:39, Lee Jones wrote:
> >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>> >
> >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >>> >>
> >>> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >>> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> >>> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> >>> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> >>> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >>> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> >>> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >>> >> ---
> >>> >> Changes from v7:
> >>> >> - Move non-shared resources into child nodes.
> >>> >> New for v7.
> >>> >> ---
> >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>> >> 1 file changed, 37 insertions(+)
> >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>> >>
> >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>> >> new file mode 100644
> >>> >> index 0000000..bc50110
> >>> >> --- /dev/null
> >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>> >> @@ -0,0 +1,37 @@
> >>> >> +NVIDIA Tegra XUSB host copmlex
> >>> >> +==============================
> >>> >> +
> >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >>> >> +
> >>> >> +Required properties:
> >>> >> +--------------------
> >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>> >> + where <chip> is tegra132.
> >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>> >> + mapping is 1:1.
> >>> >> + - #address-cells: Must be 2.
> >>> >> + - #size-cells: Must be 2.
> >>> >> +
> >>> >> +Example:
> >>> >> +--------
> >>> >> + usb@0,70098000 {
> >>> >> + compatible = "nvidia,tegra124-xusb";
> >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>> >> + ranges;
> >>> >> +
> >>> >> + #address-cells = <2>;
> >>> >> + #size-cells = <2>;
> >>> >> +
> >>> >> + usb-host@0,70090000 {
> >>> >> + compatible = "nvidia,tegra124-xhci";
> >>> >> + ...
> >>> >> + };
> >>> >> +
> >>> >> + mailbox {
> >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >>> >> + ...
> >>> >> + };
> >>> >
> >>> > This doesn't appear to be a proper MFD. I would have the USB and
> >>> > Mailbox devices probe seperately and use a phandle to point the USB
> >>> > device to its Mailbox.
> >>> >
> >>> > usb@xyz {
> >>> > mboxes = <&xusb-mailbox, [chan]>;
> >>> > };
> >>> >
> >>>
> >>> I am assuming that Andrew had laid it out like this to reflect the hw
> >>> structure. The mailbox and xhci controller are part of the xusb
> >>> sub-system and hence appear as child nodes. My understanding is that for
> >>> device-tree we want the device-tree structure to reflect the actual hw.
> >>> Is this not the case?
> >>
> >> Yes, the DT files should reflect h/w. I have requested to see what
> >> the memory map looks like, so I might provide a more appropriate
> >> solution to accepting a pretty pointless MFD.
> >
> > FWIW, the address map for XUSB looks like this:
> >
> > XUSB_HOST: 0x70090000 - 0x7009a000
> > xHCI registers: 0x70090000 - 0x70098000
> > FPCI configuration registers: 0x70098000 - 0x70099000
> > IPFS configuration registers: 0x70099000 - 0x7009a000
> >
> >> Two solutions spring to mind. You can either call
> >> of_platform_populate() from the USB driver, as some already do:
> >>
> >> drivers/usb/dwc3/dwc3-exynos.c:
> >> ret = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/dwc3/dwc3-keystone.c:
> >> error = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/dwc3/dwc3-omap.c:
> >> ret = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/dwc3/dwc3-qcom.c:
> >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> >> drivers/usb/dwc3/dwc3-st.c:
> >> ret = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/musb/musb_am335x.c:
> >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> >
> > This still requires a small, separate driver to setup the regmap and
> > do of_platform_populate(). The only difference is it lives in
> > drivers/usb/ instead of drivers/mfd/.
> >
> >> Or use the "simple-mfd", which is currently in -next:
> >>
> >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> >
> > I'm not too opposed to this, but Thierry was when I brought this up
> > before. The issue here is that if we ever have to do something
> > besides setting up a regmap in the MFD, we'd have to change the
> > binding and break DT backwards-compatibility.
>
> Any thoughts on this? A minimal MFD seems to be the best way to
> future-proof this binding/driver should it need to be extended in the
> future. If this is a firm NAK from you however, I'll need to let
> Jassi now so that he can un-queue the mailbox patches for 4.2....
I was waiting to hear Thierry's thoughts. However, I am unconvinced
that you need an MFD driver for this and refuse to take a shell (read
"pointless") one on an "if we ever ..." clause.
Will you break backwards capability though? I'm not sure you will.
Old DTBs will still use 'simple-mfd' and probe the devices in the
normal way. *If* you introduce an MFD driver at a later date then the
old DTB will miss out the *new* functionality, which is expected and
accepted.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-20 6:35 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-20 6:35 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 19 May 2015, Andrew Bresticker wrote:
> Lee,
>
> On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> <abrestic@chromium.org> wrote:
> > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> On Thu, 14 May 2015, Jon Hunter wrote:
> >>
> >>> Hi Lee,
> >>>
> >>> On 13/05/15 15:39, Lee Jones wrote:
> >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>> >
> >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >>> >>
> >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> >>> >> ---
> >>> >> Changes from v7:
> >>> >> - Move non-shared resources into child nodes.
> >>> >> New for v7.
> >>> >> ---
> >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>> >> 1 file changed, 37 insertions(+)
> >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>> >>
> >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>> >> new file mode 100644
> >>> >> index 0000000..bc50110
> >>> >> --- /dev/null
> >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>> >> @@ -0,0 +1,37 @@
> >>> >> +NVIDIA Tegra XUSB host copmlex
> >>> >> +==============================
> >>> >> +
> >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >>> >> +
> >>> >> +Required properties:
> >>> >> +--------------------
> >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>> >> + where <chip> is tegra132.
> >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>> >> + mapping is 1:1.
> >>> >> + - #address-cells: Must be 2.
> >>> >> + - #size-cells: Must be 2.
> >>> >> +
> >>> >> +Example:
> >>> >> +--------
> >>> >> + usb at 0,70098000 {
> >>> >> + compatible = "nvidia,tegra124-xusb";
> >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>> >> + ranges;
> >>> >> +
> >>> >> + #address-cells = <2>;
> >>> >> + #size-cells = <2>;
> >>> >> +
> >>> >> + usb-host at 0,70090000 {
> >>> >> + compatible = "nvidia,tegra124-xhci";
> >>> >> + ...
> >>> >> + };
> >>> >> +
> >>> >> + mailbox {
> >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >>> >> + ...
> >>> >> + };
> >>> >
> >>> > This doesn't appear to be a proper MFD. I would have the USB and
> >>> > Mailbox devices probe seperately and use a phandle to point the USB
> >>> > device to its Mailbox.
> >>> >
> >>> > usb at xyz {
> >>> > mboxes = <&xusb-mailbox, [chan]>;
> >>> > };
> >>> >
> >>>
> >>> I am assuming that Andrew had laid it out like this to reflect the hw
> >>> structure. The mailbox and xhci controller are part of the xusb
> >>> sub-system and hence appear as child nodes. My understanding is that for
> >>> device-tree we want the device-tree structure to reflect the actual hw.
> >>> Is this not the case?
> >>
> >> Yes, the DT files should reflect h/w. I have requested to see what
> >> the memory map looks like, so I might provide a more appropriate
> >> solution to accepting a pretty pointless MFD.
> >
> > FWIW, the address map for XUSB looks like this:
> >
> > XUSB_HOST: 0x70090000 - 0x7009a000
> > xHCI registers: 0x70090000 - 0x70098000
> > FPCI configuration registers: 0x70098000 - 0x70099000
> > IPFS configuration registers: 0x70099000 - 0x7009a000
> >
> >> Two solutions spring to mind. You can either call
> >> of_platform_populate() from the USB driver, as some already do:
> >>
> >> drivers/usb/dwc3/dwc3-exynos.c:
> >> ret = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/dwc3/dwc3-keystone.c:
> >> error = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/dwc3/dwc3-omap.c:
> >> ret = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/dwc3/dwc3-qcom.c:
> >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> >> drivers/usb/dwc3/dwc3-st.c:
> >> ret = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/musb/musb_am335x.c:
> >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> >
> > This still requires a small, separate driver to setup the regmap and
> > do of_platform_populate(). The only difference is it lives in
> > drivers/usb/ instead of drivers/mfd/.
> >
> >> Or use the "simple-mfd", which is currently in -next:
> >>
> >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> >
> > I'm not too opposed to this, but Thierry was when I brought this up
> > before. The issue here is that if we ever have to do something
> > besides setting up a regmap in the MFD, we'd have to change the
> > binding and break DT backwards-compatibility.
>
> Any thoughts on this? A minimal MFD seems to be the best way to
> future-proof this binding/driver should it need to be extended in the
> future. If this is a firm NAK from you however, I'll need to let
> Jassi now so that he can un-queue the mailbox patches for 4.2....
I was waiting to hear Thierry's thoughts. However, I am unconvinced
that you need an MFD driver for this and refuse to take a shell (read
"pointless") one on an "if we ever ..." clause.
Will you break backwards capability though? I'm not sure you will.
Old DTBs will still use 'simple-mfd' and probe the devices in the
normal way. *If* you introduce an MFD driver at a later date then the
old DTB will miss out the *new* functionality, which is expected and
accepted.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-20 6:35 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-20 6:35 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Jon Hunter, Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz
On Tue, 19 May 2015, Andrew Bresticker wrote:
> Lee,
>
> On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> <abrestic@chromium.org> wrote:
> > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> On Thu, 14 May 2015, Jon Hunter wrote:
> >>
> >>> Hi Lee,
> >>>
> >>> On 13/05/15 15:39, Lee Jones wrote:
> >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> >>> >
> >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> >>> >>
> >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> >>> >> ---
> >>> >> Changes from v7:
> >>> >> - Move non-shared resources into child nodes.
> >>> >> New for v7.
> >>> >> ---
> >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> >>> >> 1 file changed, 37 insertions(+)
> >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>> >>
> >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>> >> new file mode 100644
> >>> >> index 0000000..bc50110
> >>> >> --- /dev/null
> >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> >>> >> @@ -0,0 +1,37 @@
> >>> >> +NVIDIA Tegra XUSB host copmlex
> >>> >> +==============================
> >>> >> +
> >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> >>> >> +
> >>> >> +Required properties:
> >>> >> +--------------------
> >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> >>> >> + where <chip> is tegra132.
> >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> >>> >> + mapping is 1:1.
> >>> >> + - #address-cells: Must be 2.
> >>> >> + - #size-cells: Must be 2.
> >>> >> +
> >>> >> +Example:
> >>> >> +--------
> >>> >> + usb@0,70098000 {
> >>> >> + compatible = "nvidia,tegra124-xusb";
> >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> >>> >> + ranges;
> >>> >> +
> >>> >> + #address-cells = <2>;
> >>> >> + #size-cells = <2>;
> >>> >> +
> >>> >> + usb-host@0,70090000 {
> >>> >> + compatible = "nvidia,tegra124-xhci";
> >>> >> + ...
> >>> >> + };
> >>> >> +
> >>> >> + mailbox {
> >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> >>> >> + ...
> >>> >> + };
> >>> >
> >>> > This doesn't appear to be a proper MFD. I would have the USB and
> >>> > Mailbox devices probe seperately and use a phandle to point the USB
> >>> > device to its Mailbox.
> >>> >
> >>> > usb@xyz {
> >>> > mboxes = <&xusb-mailbox, [chan]>;
> >>> > };
> >>> >
> >>>
> >>> I am assuming that Andrew had laid it out like this to reflect the hw
> >>> structure. The mailbox and xhci controller are part of the xusb
> >>> sub-system and hence appear as child nodes. My understanding is that for
> >>> device-tree we want the device-tree structure to reflect the actual hw.
> >>> Is this not the case?
> >>
> >> Yes, the DT files should reflect h/w. I have requested to see what
> >> the memory map looks like, so I might provide a more appropriate
> >> solution to accepting a pretty pointless MFD.
> >
> > FWIW, the address map for XUSB looks like this:
> >
> > XUSB_HOST: 0x70090000 - 0x7009a000
> > xHCI registers: 0x70090000 - 0x70098000
> > FPCI configuration registers: 0x70098000 - 0x70099000
> > IPFS configuration registers: 0x70099000 - 0x7009a000
> >
> >> Two solutions spring to mind. You can either call
> >> of_platform_populate() from the USB driver, as some already do:
> >>
> >> drivers/usb/dwc3/dwc3-exynos.c:
> >> ret = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/dwc3/dwc3-keystone.c:
> >> error = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/dwc3/dwc3-omap.c:
> >> ret = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/dwc3/dwc3-qcom.c:
> >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> >> drivers/usb/dwc3/dwc3-st.c:
> >> ret = of_platform_populate(node, NULL, NULL, dev);
> >> drivers/usb/musb/musb_am335x.c:
> >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> >
> > This still requires a small, separate driver to setup the regmap and
> > do of_platform_populate(). The only difference is it lives in
> > drivers/usb/ instead of drivers/mfd/.
> >
> >> Or use the "simple-mfd", which is currently in -next:
> >>
> >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> >
> > I'm not too opposed to this, but Thierry was when I brought this up
> > before. The issue here is that if we ever have to do something
> > besides setting up a regmap in the MFD, we'd have to change the
> > binding and break DT backwards-compatibility.
>
> Any thoughts on this? A minimal MFD seems to be the best way to
> future-proof this binding/driver should it need to be extended in the
> future. If this is a firm NAK from you however, I'll need to let
> Jassi now so that he can un-queue the mailbox patches for 4.2....
I was waiting to hear Thierry's thoughts. However, I am unconvinced
that you need an MFD driver for this and refuse to take a shell (read
"pointless") one on an "if we ever ..." clause.
Will you break backwards capability though? I'm not sure you will.
Old DTBs will still use 'simple-mfd' and probe the devices in the
normal way. *If* you introduce an MFD driver at a later date then the
old DTB will miss out the *new* functionality, which is expected and
accepted.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-20 6:35 ` Lee Jones
(?)
@ 2015-05-20 14:52 ` Thierry Reding
-1 siblings, 0 replies; 136+ messages in thread
From: Thierry Reding @ 2015-05-20 14:52 UTC (permalink / raw)
To: Lee Jones
Cc: Andrew Bresticker, Jon Hunter, Stephen Warren, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
[-- Attachment #1: Type: text/plain, Size: 9617 bytes --]
On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> On Tue, 19 May 2015, Andrew Bresticker wrote:
>
> > Lee,
> >
> > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > >>
> > >>> Hi Lee,
> > >>>
> > >>> On 13/05/15 15:39, Lee Jones wrote:
> > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > >>> >
> > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > >>> >>
> > >>> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > >>> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > >>> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> > >>> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > >>> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> > >>> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > >>> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > >>> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > >>> >> ---
> > >>> >> Changes from v7:
> > >>> >> - Move non-shared resources into child nodes.
> > >>> >> New for v7.
> > >>> >> ---
> > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > >>> >> 1 file changed, 37 insertions(+)
> > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > >>> >>
> > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > >>> >> new file mode 100644
> > >>> >> index 0000000..bc50110
> > >>> >> --- /dev/null
> > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > >>> >> @@ -0,0 +1,37 @@
> > >>> >> +NVIDIA Tegra XUSB host copmlex
> > >>> >> +==============================
> > >>> >> +
> > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > >>> >> +
> > >>> >> +Required properties:
> > >>> >> +--------------------
> > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > >>> >> + where <chip> is tegra132.
> > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > >>> >> + mapping is 1:1.
> > >>> >> + - #address-cells: Must be 2.
> > >>> >> + - #size-cells: Must be 2.
> > >>> >> +
> > >>> >> +Example:
> > >>> >> +--------
> > >>> >> + usb@0,70098000 {
> > >>> >> + compatible = "nvidia,tegra124-xusb";
> > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > >>> >> + ranges;
> > >>> >> +
> > >>> >> + #address-cells = <2>;
> > >>> >> + #size-cells = <2>;
> > >>> >> +
> > >>> >> + usb-host@0,70090000 {
> > >>> >> + compatible = "nvidia,tegra124-xhci";
> > >>> >> + ...
> > >>> >> + };
> > >>> >> +
> > >>> >> + mailbox {
> > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > >>> >> + ...
> > >>> >> + };
> > >>> >
> > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > >>> > device to its Mailbox.
> > >>> >
> > >>> > usb@xyz {
> > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > >>> > };
> > >>> >
> > >>>
> > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > >>> structure. The mailbox and xhci controller are part of the xusb
> > >>> sub-system and hence appear as child nodes. My understanding is that for
> > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > >>> Is this not the case?
> > >>
> > >> Yes, the DT files should reflect h/w. I have requested to see what
> > >> the memory map looks like, so I might provide a more appropriate
> > >> solution to accepting a pretty pointless MFD.
> > >
> > > FWIW, the address map for XUSB looks like this:
> > >
> > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > xHCI registers: 0x70090000 - 0x70098000
> > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > >
> > >> Two solutions spring to mind. You can either call
> > >> of_platform_populate() from the USB driver, as some already do:
> > >>
> > >> drivers/usb/dwc3/dwc3-exynos.c:
> > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/dwc3/dwc3-keystone.c:
> > >> error = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/dwc3/dwc3-omap.c:
> > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/dwc3/dwc3-qcom.c:
> > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > >> drivers/usb/dwc3/dwc3-st.c:
> > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/musb/musb_am335x.c:
> > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > >
> > > This still requires a small, separate driver to setup the regmap and
> > > do of_platform_populate(). The only difference is it lives in
> > > drivers/usb/ instead of drivers/mfd/.
> > >
> > >> Or use the "simple-mfd", which is currently in -next:
> > >>
> > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > >
> > > I'm not too opposed to this, but Thierry was when I brought this up
> > > before. The issue here is that if we ever have to do something
> > > besides setting up a regmap in the MFD, we'd have to change the
> > > binding and break DT backwards-compatibility.
> >
> > Any thoughts on this? A minimal MFD seems to be the best way to
> > future-proof this binding/driver should it need to be extended in the
> > future. If this is a firm NAK from you however, I'll need to let
> > Jassi now so that he can un-queue the mailbox patches for 4.2....
>
> I was waiting to hear Thierry's thoughts. However, I am unconvinced
> that you need an MFD driver for this and refuse to take a shell (read
> "pointless") one on an "if we ever ..." clause.
>
> Will you break backwards capability though? I'm not sure you will.
> Old DTBs will still use 'simple-mfd' and probe the devices in the
> normal way. *If* you introduce an MFD driver at a later date then the
> old DTB will miss out the *new* functionality, which is expected and
> accepted.
I'm a little confused by the simple-mfd approach. The only code I see in
linux-next for this is a single line that adds the "simple-mfd" string
to the OF device ID table in drivers/of/platform.c. As far as I can tell
this will merely cause child devices to be created. There won't be a
shared regmap and resources won't be set up properly either. Having a
proper MFD driver seems to be the only way to achieve what we need.
The reason why every other simple-mfd users seems to get away with this
is because they also match on syscon and that sets up a regmap of its
own and the child device drivers use the syscon API to get at it. So I
don't see how we can make use of simple-mfd to achieve what we need,
unless we essentially copy what syscon does (but do proper resource
management while at it).
There is also the matter of clocks, resets, power supplies, etc. which
simple-mfd can't take into account in its current form. From a hardware
point of view, (some of) the clocks and resets are shared by the XHCI
and the mailbox blocks, so the device tree node would have to take that
into account. And a driver would also have to know which clocks, resets
and power supplies to probe and the order in which they need to be
enabled. simple-mfd doesn't provide any of that currently, so we'd
likely need to hack around that in all sorts of weird ways in the child
drivers. It makes much more sense for a top-level MFD driver to set up
the shared hardware resources and then instantiate the child devices and
let the drivers for those only care about the child-specific resources.
A catch-all driver will inevitably lead to implementing a midlayer with
potentially all sorts of quirks to make it work with the various devices
out there.
A much better implementation, in my opinion, would be to make simple-mfd
a subclassable object and then have drivers use a helper library to call
code that is common for simple-mfd kinds of devices. Something like this
for example:
struct tegra_xusb {
...
struct mfd_simple mfd;
...
};
static int tegra_xusb_probe(struct platform_device *pdev)
{
struct tegra_xusb *xusb;
...
err = mfd_simple_register(&xusb->mfd);
...
}
Now all these drivers reuse all the code provided by the mfd_simple
helper, which will instantiate the children, but it is also very easy to
tie in the platform-specific glue (clocks, resets, regulators, ...) via
the device-specific drivers.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-20 14:52 ` Thierry Reding
0 siblings, 0 replies; 136+ messages in thread
From: Thierry Reding @ 2015-05-20 14:52 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> On Tue, 19 May 2015, Andrew Bresticker wrote:
>
> > Lee,
> >
> > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > <abrestic@chromium.org> wrote:
> > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > >>
> > >>> Hi Lee,
> > >>>
> > >>> On 13/05/15 15:39, Lee Jones wrote:
> > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > >>> >
> > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > >>> >>
> > >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> > >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> > >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> > >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> > >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> > >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> > >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> > >>> >> ---
> > >>> >> Changes from v7:
> > >>> >> - Move non-shared resources into child nodes.
> > >>> >> New for v7.
> > >>> >> ---
> > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > >>> >> 1 file changed, 37 insertions(+)
> > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > >>> >>
> > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > >>> >> new file mode 100644
> > >>> >> index 0000000..bc50110
> > >>> >> --- /dev/null
> > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > >>> >> @@ -0,0 +1,37 @@
> > >>> >> +NVIDIA Tegra XUSB host copmlex
> > >>> >> +==============================
> > >>> >> +
> > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > >>> >> +
> > >>> >> +Required properties:
> > >>> >> +--------------------
> > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > >>> >> + where <chip> is tegra132.
> > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > >>> >> + mapping is 1:1.
> > >>> >> + - #address-cells: Must be 2.
> > >>> >> + - #size-cells: Must be 2.
> > >>> >> +
> > >>> >> +Example:
> > >>> >> +--------
> > >>> >> + usb at 0,70098000 {
> > >>> >> + compatible = "nvidia,tegra124-xusb";
> > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > >>> >> + ranges;
> > >>> >> +
> > >>> >> + #address-cells = <2>;
> > >>> >> + #size-cells = <2>;
> > >>> >> +
> > >>> >> + usb-host at 0,70090000 {
> > >>> >> + compatible = "nvidia,tegra124-xhci";
> > >>> >> + ...
> > >>> >> + };
> > >>> >> +
> > >>> >> + mailbox {
> > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > >>> >> + ...
> > >>> >> + };
> > >>> >
> > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > >>> > device to its Mailbox.
> > >>> >
> > >>> > usb at xyz {
> > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > >>> > };
> > >>> >
> > >>>
> > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > >>> structure. The mailbox and xhci controller are part of the xusb
> > >>> sub-system and hence appear as child nodes. My understanding is that for
> > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > >>> Is this not the case?
> > >>
> > >> Yes, the DT files should reflect h/w. I have requested to see what
> > >> the memory map looks like, so I might provide a more appropriate
> > >> solution to accepting a pretty pointless MFD.
> > >
> > > FWIW, the address map for XUSB looks like this:
> > >
> > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > xHCI registers: 0x70090000 - 0x70098000
> > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > >
> > >> Two solutions spring to mind. You can either call
> > >> of_platform_populate() from the USB driver, as some already do:
> > >>
> > >> drivers/usb/dwc3/dwc3-exynos.c:
> > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/dwc3/dwc3-keystone.c:
> > >> error = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/dwc3/dwc3-omap.c:
> > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/dwc3/dwc3-qcom.c:
> > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > >> drivers/usb/dwc3/dwc3-st.c:
> > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/musb/musb_am335x.c:
> > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > >
> > > This still requires a small, separate driver to setup the regmap and
> > > do of_platform_populate(). The only difference is it lives in
> > > drivers/usb/ instead of drivers/mfd/.
> > >
> > >> Or use the "simple-mfd", which is currently in -next:
> > >>
> > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > >
> > > I'm not too opposed to this, but Thierry was when I brought this up
> > > before. The issue here is that if we ever have to do something
> > > besides setting up a regmap in the MFD, we'd have to change the
> > > binding and break DT backwards-compatibility.
> >
> > Any thoughts on this? A minimal MFD seems to be the best way to
> > future-proof this binding/driver should it need to be extended in the
> > future. If this is a firm NAK from you however, I'll need to let
> > Jassi now so that he can un-queue the mailbox patches for 4.2....
>
> I was waiting to hear Thierry's thoughts. However, I am unconvinced
> that you need an MFD driver for this and refuse to take a shell (read
> "pointless") one on an "if we ever ..." clause.
>
> Will you break backwards capability though? I'm not sure you will.
> Old DTBs will still use 'simple-mfd' and probe the devices in the
> normal way. *If* you introduce an MFD driver at a later date then the
> old DTB will miss out the *new* functionality, which is expected and
> accepted.
I'm a little confused by the simple-mfd approach. The only code I see in
linux-next for this is a single line that adds the "simple-mfd" string
to the OF device ID table in drivers/of/platform.c. As far as I can tell
this will merely cause child devices to be created. There won't be a
shared regmap and resources won't be set up properly either. Having a
proper MFD driver seems to be the only way to achieve what we need.
The reason why every other simple-mfd users seems to get away with this
is because they also match on syscon and that sets up a regmap of its
own and the child device drivers use the syscon API to get at it. So I
don't see how we can make use of simple-mfd to achieve what we need,
unless we essentially copy what syscon does (but do proper resource
management while at it).
There is also the matter of clocks, resets, power supplies, etc. which
simple-mfd can't take into account in its current form. From a hardware
point of view, (some of) the clocks and resets are shared by the XHCI
and the mailbox blocks, so the device tree node would have to take that
into account. And a driver would also have to know which clocks, resets
and power supplies to probe and the order in which they need to be
enabled. simple-mfd doesn't provide any of that currently, so we'd
likely need to hack around that in all sorts of weird ways in the child
drivers. It makes much more sense for a top-level MFD driver to set up
the shared hardware resources and then instantiate the child devices and
let the drivers for those only care about the child-specific resources.
A catch-all driver will inevitably lead to implementing a midlayer with
potentially all sorts of quirks to make it work with the various devices
out there.
A much better implementation, in my opinion, would be to make simple-mfd
a subclassable object and then have drivers use a helper library to call
code that is common for simple-mfd kinds of devices. Something like this
for example:
struct tegra_xusb {
...
struct mfd_simple mfd;
...
};
static int tegra_xusb_probe(struct platform_device *pdev)
{
struct tegra_xusb *xusb;
...
err = mfd_simple_register(&xusb->mfd);
...
}
Now all these drivers reuse all the code provided by the mfd_simple
helper, which will instantiate the children, but it is also very easy to
tie in the platform-specific glue (clocks, resets, regulators, ...) via
the device-specific drivers.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150520/3807ec83/attachment.sig>
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-20 14:52 ` Thierry Reding
0 siblings, 0 replies; 136+ messages in thread
From: Thierry Reding @ 2015-05-20 14:52 UTC (permalink / raw)
To: Lee Jones
Cc: Andrew Bresticker, Jon Hunter, Stephen Warren, Alexandre Courbot,
devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz
[-- Attachment #1: Type: text/plain, Size: 9360 bytes --]
On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> On Tue, 19 May 2015, Andrew Bresticker wrote:
>
> > Lee,
> >
> > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > <abrestic@chromium.org> wrote:
> > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > >>
> > >>> Hi Lee,
> > >>>
> > >>> On 13/05/15 15:39, Lee Jones wrote:
> > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > >>> >
> > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > >>> >>
> > >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> > >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> > >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> > >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> > >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> > >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> > >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> > >>> >> ---
> > >>> >> Changes from v7:
> > >>> >> - Move non-shared resources into child nodes.
> > >>> >> New for v7.
> > >>> >> ---
> > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > >>> >> 1 file changed, 37 insertions(+)
> > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > >>> >>
> > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > >>> >> new file mode 100644
> > >>> >> index 0000000..bc50110
> > >>> >> --- /dev/null
> > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > >>> >> @@ -0,0 +1,37 @@
> > >>> >> +NVIDIA Tegra XUSB host copmlex
> > >>> >> +==============================
> > >>> >> +
> > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > >>> >> +
> > >>> >> +Required properties:
> > >>> >> +--------------------
> > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > >>> >> + where <chip> is tegra132.
> > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > >>> >> + mapping is 1:1.
> > >>> >> + - #address-cells: Must be 2.
> > >>> >> + - #size-cells: Must be 2.
> > >>> >> +
> > >>> >> +Example:
> > >>> >> +--------
> > >>> >> + usb@0,70098000 {
> > >>> >> + compatible = "nvidia,tegra124-xusb";
> > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > >>> >> + ranges;
> > >>> >> +
> > >>> >> + #address-cells = <2>;
> > >>> >> + #size-cells = <2>;
> > >>> >> +
> > >>> >> + usb-host@0,70090000 {
> > >>> >> + compatible = "nvidia,tegra124-xhci";
> > >>> >> + ...
> > >>> >> + };
> > >>> >> +
> > >>> >> + mailbox {
> > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > >>> >> + ...
> > >>> >> + };
> > >>> >
> > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > >>> > device to its Mailbox.
> > >>> >
> > >>> > usb@xyz {
> > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > >>> > };
> > >>> >
> > >>>
> > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > >>> structure. The mailbox and xhci controller are part of the xusb
> > >>> sub-system and hence appear as child nodes. My understanding is that for
> > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > >>> Is this not the case?
> > >>
> > >> Yes, the DT files should reflect h/w. I have requested to see what
> > >> the memory map looks like, so I might provide a more appropriate
> > >> solution to accepting a pretty pointless MFD.
> > >
> > > FWIW, the address map for XUSB looks like this:
> > >
> > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > xHCI registers: 0x70090000 - 0x70098000
> > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > >
> > >> Two solutions spring to mind. You can either call
> > >> of_platform_populate() from the USB driver, as some already do:
> > >>
> > >> drivers/usb/dwc3/dwc3-exynos.c:
> > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/dwc3/dwc3-keystone.c:
> > >> error = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/dwc3/dwc3-omap.c:
> > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/dwc3/dwc3-qcom.c:
> > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > >> drivers/usb/dwc3/dwc3-st.c:
> > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > >> drivers/usb/musb/musb_am335x.c:
> > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > >
> > > This still requires a small, separate driver to setup the regmap and
> > > do of_platform_populate(). The only difference is it lives in
> > > drivers/usb/ instead of drivers/mfd/.
> > >
> > >> Or use the "simple-mfd", which is currently in -next:
> > >>
> > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > >
> > > I'm not too opposed to this, but Thierry was when I brought this up
> > > before. The issue here is that if we ever have to do something
> > > besides setting up a regmap in the MFD, we'd have to change the
> > > binding and break DT backwards-compatibility.
> >
> > Any thoughts on this? A minimal MFD seems to be the best way to
> > future-proof this binding/driver should it need to be extended in the
> > future. If this is a firm NAK from you however, I'll need to let
> > Jassi now so that he can un-queue the mailbox patches for 4.2....
>
> I was waiting to hear Thierry's thoughts. However, I am unconvinced
> that you need an MFD driver for this and refuse to take a shell (read
> "pointless") one on an "if we ever ..." clause.
>
> Will you break backwards capability though? I'm not sure you will.
> Old DTBs will still use 'simple-mfd' and probe the devices in the
> normal way. *If* you introduce an MFD driver at a later date then the
> old DTB will miss out the *new* functionality, which is expected and
> accepted.
I'm a little confused by the simple-mfd approach. The only code I see in
linux-next for this is a single line that adds the "simple-mfd" string
to the OF device ID table in drivers/of/platform.c. As far as I can tell
this will merely cause child devices to be created. There won't be a
shared regmap and resources won't be set up properly either. Having a
proper MFD driver seems to be the only way to achieve what we need.
The reason why every other simple-mfd users seems to get away with this
is because they also match on syscon and that sets up a regmap of its
own and the child device drivers use the syscon API to get at it. So I
don't see how we can make use of simple-mfd to achieve what we need,
unless we essentially copy what syscon does (but do proper resource
management while at it).
There is also the matter of clocks, resets, power supplies, etc. which
simple-mfd can't take into account in its current form. From a hardware
point of view, (some of) the clocks and resets are shared by the XHCI
and the mailbox blocks, so the device tree node would have to take that
into account. And a driver would also have to know which clocks, resets
and power supplies to probe and the order in which they need to be
enabled. simple-mfd doesn't provide any of that currently, so we'd
likely need to hack around that in all sorts of weird ways in the child
drivers. It makes much more sense for a top-level MFD driver to set up
the shared hardware resources and then instantiate the child devices and
let the drivers for those only care about the child-specific resources.
A catch-all driver will inevitably lead to implementing a midlayer with
potentially all sorts of quirks to make it work with the various devices
out there.
A much better implementation, in my opinion, would be to make simple-mfd
a subclassable object and then have drivers use a helper library to call
code that is common for simple-mfd kinds of devices. Something like this
for example:
struct tegra_xusb {
...
struct mfd_simple mfd;
...
};
static int tegra_xusb_probe(struct platform_device *pdev)
{
struct tegra_xusb *xusb;
...
err = mfd_simple_register(&xusb->mfd);
...
}
Now all these drivers reuse all the code provided by the mfd_simple
helper, which will instantiate the children, but it is also very easy to
tie in the platform-specific glue (clocks, resets, regulators, ...) via
the device-specific drivers.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread[parent not found: <20150520145227.GA3787-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>]
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-20 14:52 ` Thierry Reding
(?)
@ 2015-05-21 7:19 ` Linus Walleij
-1 siblings, 0 replies; 136+ messages in thread
From: Linus Walleij @ 2015-05-21 7:19 UTC (permalink / raw)
To: Thierry Reding
Cc: Lee Jones, Andrew Bresticker, Jon Hunter, Stephen Warren,
Alexandre Courbot, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Wed, May 20, 2015 at 4:52 PM, Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I'm a little confused by the simple-mfd approach. The only code I see in
> linux-next for this is a single line that adds the "simple-mfd" string
> to the OF device ID table in drivers/of/platform.c. As far as I can tell
> this will merely cause child devices to be created. There won't be a
> shared regmap and resources won't be set up properly either.
That is correct. The simple-mfd is a two-component approach.
Ideally, in the simplest case, you combine simple-mfd with syscon.
foo@0 {
compatible = "foo", "syscon", "simple-mfd";
reg = <0x10000000 0x1000>;
bar@1 {
compatible = "bar";
};
baz@2 {
compatible = "baz";
};
};
This will instantiate bar and baz.
These subdrivers then probe and:
probe() {
struct regmap *map;
map = syscon_node_to_regmap(parent->of_node);
(...)
}
Simple, syscon is the MFD hub.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-21 7:19 ` Linus Walleij
0 siblings, 0 replies; 136+ messages in thread
From: Linus Walleij @ 2015-05-21 7:19 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, May 20, 2015 at 4:52 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> I'm a little confused by the simple-mfd approach. The only code I see in
> linux-next for this is a single line that adds the "simple-mfd" string
> to the OF device ID table in drivers/of/platform.c. As far as I can tell
> this will merely cause child devices to be created. There won't be a
> shared regmap and resources won't be set up properly either.
That is correct. The simple-mfd is a two-component approach.
Ideally, in the simplest case, you combine simple-mfd with syscon.
foo at 0 {
compatible = "foo", "syscon", "simple-mfd";
reg = <0x10000000 0x1000>;
bar at 1 {
compatible = "bar";
};
baz at 2 {
compatible = "baz";
};
};
This will instantiate bar and baz.
These subdrivers then probe and:
probe() {
struct regmap *map;
map = syscon_node_to_regmap(parent->of_node);
(...)
}
Simple, syscon is the MFD hub.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-21 7:19 ` Linus Walleij
0 siblings, 0 replies; 136+ messages in thread
From: Linus Walleij @ 2015-05-21 7:19 UTC (permalink / raw)
To: Thierry Reding
Cc: Lee Jones, Andrew Bresticker, Jon Hunter, Stephen Warren,
Alexandre Courbot, devicetree, linux-tegra, linux-usb,
linux-arm-kernel, linux-kernel, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Wed, May 20, 2015 at 4:52 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> I'm a little confused by the simple-mfd approach. The only code I see in
> linux-next for this is a single line that adds the "simple-mfd" string
> to the OF device ID table in drivers/of/platform.c. As far as I can tell
> this will merely cause child devices to be created. There won't be a
> shared regmap and resources won't be set up properly either.
That is correct. The simple-mfd is a two-component approach.
Ideally, in the simplest case, you combine simple-mfd with syscon.
foo@0 {
compatible = "foo", "syscon", "simple-mfd";
reg = <0x10000000 0x1000>;
bar@1 {
compatible = "bar";
};
baz@2 {
compatible = "baz";
};
};
This will instantiate bar and baz.
These subdrivers then probe and:
probe() {
struct regmap *map;
map = syscon_node_to_regmap(parent->of_node);
(...)
}
Simple, syscon is the MFD hub.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-20 14:52 ` Thierry Reding
(?)
@ 2015-05-21 8:40 ` Lee Jones
-1 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-21 8:40 UTC (permalink / raw)
To: Thierry Reding
Cc: Andrew Bresticker, Jon Hunter, Stephen Warren, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Wed, 20 May 2015, Thierry Reding wrote:
> On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > >>> >
> > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > >>> >>
> > > >>> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > > >>> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > >>> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> > > >>> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > > >>> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> > > >>> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > > >>> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > >>> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > >>> >> ---
> > > >>> >> Changes from v7:
> > > >>> >> - Move non-shared resources into child nodes.
> > > >>> >> New for v7.
> > > >>> >> ---
> > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > >>> >> 1 file changed, 37 insertions(+)
> > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >>
> > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >> new file mode 100644
> > > >>> >> index 0000000..bc50110
> > > >>> >> --- /dev/null
> > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >> @@ -0,0 +1,37 @@
> > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > >>> >> +==============================
> > > >>> >> +
> > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > >>> >> +
> > > >>> >> +Required properties:
> > > >>> >> +--------------------
> > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > >>> >> + where <chip> is tegra132.
> > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > >>> >> + mapping is 1:1.
> > > >>> >> + - #address-cells: Must be 2.
> > > >>> >> + - #size-cells: Must be 2.
> > > >>> >> +
> > > >>> >> +Example:
> > > >>> >> +--------
> > > >>> >> + usb@0,70098000 {
> > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > >>> >> + ranges;
> > > >>> >> +
> > > >>> >> + #address-cells = <2>;
> > > >>> >> + #size-cells = <2>;
> > > >>> >> +
> > > >>> >> + usb-host@0,70090000 {
> > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > >>> >> + ...
> > > >>> >> + };
> > > >>> >> +
> > > >>> >> + mailbox {
> > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > >>> >> + ...
> > > >>> >> + };
> > > >>> >
> > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > >>> > device to its Mailbox.
> > > >>> >
> > > >>> > usb@xyz {
> > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > >>> > };
> > > >>> >
> > > >>>
> > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > >>> Is this not the case?
> > > >>
> > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > >> the memory map looks like, so I might provide a more appropriate
> > > >> solution to accepting a pretty pointless MFD.
> > > >
> > > > FWIW, the address map for XUSB looks like this:
> > > >
> > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > xHCI registers: 0x70090000 - 0x70098000
> > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > >
> > > >> Two solutions spring to mind. You can either call
> > > >> of_platform_populate() from the USB driver, as some already do:
> > > >>
> > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > >> drivers/usb/dwc3/dwc3-st.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/musb/musb_am335x.c:
> > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > >
> > > > This still requires a small, separate driver to setup the regmap and
> > > > do of_platform_populate(). The only difference is it lives in
> > > > drivers/usb/ instead of drivers/mfd/.
> > > >
> > > >> Or use the "simple-mfd", which is currently in -next:
> > > >>
> > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > >
> > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > before. The issue here is that if we ever have to do something
> > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > binding and break DT backwards-compatibility.
> > >
> > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > future-proof this binding/driver should it need to be extended in the
> > > future. If this is a firm NAK from you however, I'll need to let
> > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> >
> > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > that you need an MFD driver for this and refuse to take a shell (read
> > "pointless") one on an "if we ever ..." clause.
> >
> > Will you break backwards capability though? I'm not sure you will.
> > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > normal way. *If* you introduce an MFD driver at a later date then the
> > old DTB will miss out the *new* functionality, which is expected and
> > accepted.
>
> I'm a little confused by the simple-mfd approach. The only code I see in
> linux-next for this is a single line that adds the "simple-mfd" string
> to the OF device ID table in drivers/of/platform.c. As far as I can tell
> this will merely cause child devices to be created. There won't be a
> shared regmap and resources won't be set up properly either. Having a
> proper MFD driver seems to be the only way to achieve what we need.
>
> The reason why every other simple-mfd users seems to get away with this
> is because they also match on syscon and that sets up a regmap of its
> own and the child device drivers use the syscon API to get at it. So I
> don't see how we can make use of simple-mfd to achieve what we need,
> unless we essentially copy what syscon does (but do proper resource
> management while at it).
If you have shared resources and your device isn't classed as a syscon
device then yes, simple-mfd probably isn't suitable for this use-case.
You might need to go into more detail with regards to "proper resource
management", as I'm not entirely sure I agree.
Still, this doesn't change the fact that, from what I've seen, I still
don't think you need a dedicated MFD driver.
What do you think of:
usb-host@0,70090000 {
compatible = "nvidia,tegra124-xhci";
reg = <0x0 0x70090000 0x0 0x80CF>,
<0x0 0x70098800 0x0 0x0800>,
<0x0 0x70099000 0x0 0x1000>;
/* Something from the datasheet */
reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
ranges;
xusb_mbox: mailbox {
compatible = "nvidia,tegra124-xusb-mbox";
reg = <0x0 0x700980e0 0x0 0x13>,
<0x0 0x70098428 0x0 0x03>;
/* Something from the datasheet */
reg-names = "mbox-one", "mbox-two";
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
};
};
Then hvae the XHCI driver call of_platform_populate() as I proposed
above?
> There is also the matter of clocks, resets, power supplies, etc. which
> simple-mfd can't take into account in its current form. From a hardware
> point of view, (some of) the clocks and resets are shared by the XHCI
> and the mailbox blocks, so the device tree node would have to take that
> into account. And a driver would also have to know which clocks, resets
> and power supplies to probe and the order in which they need to be
> enabled. simple-mfd doesn't provide any of that currently, so we'd
> likely need to hack around that in all sorts of weird ways in the child
> drivers. It makes much more sense for a top-level MFD driver to set up
> the shared hardware resources and then instantiate the child devices and
> let the drivers for those only care about the child-specific resources.
>
> A catch-all driver will inevitably lead to implementing a midlayer with
> potentially all sorts of quirks to make it work with the various devices
> out there.
>
> A much better implementation, in my opinion, would be to make simple-mfd
> a subclassable object and then have drivers use a helper library to call
> code that is common for simple-mfd kinds of devices. Something like this
> for example:
>
> struct tegra_xusb {
> ...
> struct mfd_simple mfd;
> ...
> };
>
> static int tegra_xusb_probe(struct platform_device *pdev)
> {
> struct tegra_xusb *xusb;
> ...
> err = mfd_simple_register(&xusb->mfd);
> ...
> }
>
> Now all these drivers reuse all the code provided by the mfd_simple
> helper, which will instantiate the children, but it is also very easy to
> tie in the platform-specific glue (clocks, resets, regulators, ...) via
> the device-specific drivers.
I'm not keen on creating a not-so-simple-mfd driver. Let's work with
what we've got for the time being.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-21 8:40 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-21 8:40 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 20 May 2015, Thierry Reding wrote:
> On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > <abrestic@chromium.org> wrote:
> > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > >>> >
> > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > >>> >>
> > > >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> > > >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> > > >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> > > >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> > > >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > > >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> > > >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> > > >>> >> ---
> > > >>> >> Changes from v7:
> > > >>> >> - Move non-shared resources into child nodes.
> > > >>> >> New for v7.
> > > >>> >> ---
> > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > >>> >> 1 file changed, 37 insertions(+)
> > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >>
> > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >> new file mode 100644
> > > >>> >> index 0000000..bc50110
> > > >>> >> --- /dev/null
> > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >> @@ -0,0 +1,37 @@
> > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > >>> >> +==============================
> > > >>> >> +
> > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > >>> >> +
> > > >>> >> +Required properties:
> > > >>> >> +--------------------
> > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > >>> >> + where <chip> is tegra132.
> > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > >>> >> + mapping is 1:1.
> > > >>> >> + - #address-cells: Must be 2.
> > > >>> >> + - #size-cells: Must be 2.
> > > >>> >> +
> > > >>> >> +Example:
> > > >>> >> +--------
> > > >>> >> + usb at 0,70098000 {
> > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > >>> >> + ranges;
> > > >>> >> +
> > > >>> >> + #address-cells = <2>;
> > > >>> >> + #size-cells = <2>;
> > > >>> >> +
> > > >>> >> + usb-host at 0,70090000 {
> > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > >>> >> + ...
> > > >>> >> + };
> > > >>> >> +
> > > >>> >> + mailbox {
> > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > >>> >> + ...
> > > >>> >> + };
> > > >>> >
> > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > >>> > device to its Mailbox.
> > > >>> >
> > > >>> > usb at xyz {
> > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > >>> > };
> > > >>> >
> > > >>>
> > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > >>> Is this not the case?
> > > >>
> > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > >> the memory map looks like, so I might provide a more appropriate
> > > >> solution to accepting a pretty pointless MFD.
> > > >
> > > > FWIW, the address map for XUSB looks like this:
> > > >
> > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > xHCI registers: 0x70090000 - 0x70098000
> > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > >
> > > >> Two solutions spring to mind. You can either call
> > > >> of_platform_populate() from the USB driver, as some already do:
> > > >>
> > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > >> drivers/usb/dwc3/dwc3-st.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/musb/musb_am335x.c:
> > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > >
> > > > This still requires a small, separate driver to setup the regmap and
> > > > do of_platform_populate(). The only difference is it lives in
> > > > drivers/usb/ instead of drivers/mfd/.
> > > >
> > > >> Or use the "simple-mfd", which is currently in -next:
> > > >>
> > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > >
> > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > before. The issue here is that if we ever have to do something
> > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > binding and break DT backwards-compatibility.
> > >
> > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > future-proof this binding/driver should it need to be extended in the
> > > future. If this is a firm NAK from you however, I'll need to let
> > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> >
> > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > that you need an MFD driver for this and refuse to take a shell (read
> > "pointless") one on an "if we ever ..." clause.
> >
> > Will you break backwards capability though? I'm not sure you will.
> > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > normal way. *If* you introduce an MFD driver at a later date then the
> > old DTB will miss out the *new* functionality, which is expected and
> > accepted.
>
> I'm a little confused by the simple-mfd approach. The only code I see in
> linux-next for this is a single line that adds the "simple-mfd" string
> to the OF device ID table in drivers/of/platform.c. As far as I can tell
> this will merely cause child devices to be created. There won't be a
> shared regmap and resources won't be set up properly either. Having a
> proper MFD driver seems to be the only way to achieve what we need.
>
> The reason why every other simple-mfd users seems to get away with this
> is because they also match on syscon and that sets up a regmap of its
> own and the child device drivers use the syscon API to get at it. So I
> don't see how we can make use of simple-mfd to achieve what we need,
> unless we essentially copy what syscon does (but do proper resource
> management while at it).
If you have shared resources and your device isn't classed as a syscon
device then yes, simple-mfd probably isn't suitable for this use-case.
You might need to go into more detail with regards to "proper resource
management", as I'm not entirely sure I agree.
Still, this doesn't change the fact that, from what I've seen, I still
don't think you need a dedicated MFD driver.
What do you think of:
usb-host at 0,70090000 {
compatible = "nvidia,tegra124-xhci";
reg = <0x0 0x70090000 0x0 0x80CF>,
<0x0 0x70098800 0x0 0x0800>,
<0x0 0x70099000 0x0 0x1000>;
/* Something from the datasheet */
reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
ranges;
xusb_mbox: mailbox {
compatible = "nvidia,tegra124-xusb-mbox";
reg = <0x0 0x700980e0 0x0 0x13>,
<0x0 0x70098428 0x0 0x03>;
/* Something from the datasheet */
reg-names = "mbox-one", "mbox-two";
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
};
};
Then hvae the XHCI driver call of_platform_populate() as I proposed
above?
> There is also the matter of clocks, resets, power supplies, etc. which
> simple-mfd can't take into account in its current form. From a hardware
> point of view, (some of) the clocks and resets are shared by the XHCI
> and the mailbox blocks, so the device tree node would have to take that
> into account. And a driver would also have to know which clocks, resets
> and power supplies to probe and the order in which they need to be
> enabled. simple-mfd doesn't provide any of that currently, so we'd
> likely need to hack around that in all sorts of weird ways in the child
> drivers. It makes much more sense for a top-level MFD driver to set up
> the shared hardware resources and then instantiate the child devices and
> let the drivers for those only care about the child-specific resources.
>
> A catch-all driver will inevitably lead to implementing a midlayer with
> potentially all sorts of quirks to make it work with the various devices
> out there.
>
> A much better implementation, in my opinion, would be to make simple-mfd
> a subclassable object and then have drivers use a helper library to call
> code that is common for simple-mfd kinds of devices. Something like this
> for example:
>
> struct tegra_xusb {
> ...
> struct mfd_simple mfd;
> ...
> };
>
> static int tegra_xusb_probe(struct platform_device *pdev)
> {
> struct tegra_xusb *xusb;
> ...
> err = mfd_simple_register(&xusb->mfd);
> ...
> }
>
> Now all these drivers reuse all the code provided by the mfd_simple
> helper, which will instantiate the children, but it is also very easy to
> tie in the platform-specific glue (clocks, resets, regulators, ...) via
> the device-specific drivers.
I'm not keen on creating a not-so-simple-mfd driver. Let's work with
what we've got for the time being.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-21 8:40 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-21 8:40 UTC (permalink / raw)
To: Thierry Reding
Cc: Andrew Bresticker, Jon Hunter, Stephen Warren, Alexandre Courbot,
devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz
On Wed, 20 May 2015, Thierry Reding wrote:
> On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > <abrestic@chromium.org> wrote:
> > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > >>> >
> > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > >>> >>
> > > >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> > > >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> > > >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> > > >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> > > >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > > >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> > > >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> > > >>> >> ---
> > > >>> >> Changes from v7:
> > > >>> >> - Move non-shared resources into child nodes.
> > > >>> >> New for v7.
> > > >>> >> ---
> > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > >>> >> 1 file changed, 37 insertions(+)
> > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >>
> > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >> new file mode 100644
> > > >>> >> index 0000000..bc50110
> > > >>> >> --- /dev/null
> > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > >>> >> @@ -0,0 +1,37 @@
> > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > >>> >> +==============================
> > > >>> >> +
> > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > >>> >> +
> > > >>> >> +Required properties:
> > > >>> >> +--------------------
> > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > >>> >> + where <chip> is tegra132.
> > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > >>> >> + mapping is 1:1.
> > > >>> >> + - #address-cells: Must be 2.
> > > >>> >> + - #size-cells: Must be 2.
> > > >>> >> +
> > > >>> >> +Example:
> > > >>> >> +--------
> > > >>> >> + usb@0,70098000 {
> > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > >>> >> + ranges;
> > > >>> >> +
> > > >>> >> + #address-cells = <2>;
> > > >>> >> + #size-cells = <2>;
> > > >>> >> +
> > > >>> >> + usb-host@0,70090000 {
> > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > >>> >> + ...
> > > >>> >> + };
> > > >>> >> +
> > > >>> >> + mailbox {
> > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > >>> >> + ...
> > > >>> >> + };
> > > >>> >
> > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > >>> > device to its Mailbox.
> > > >>> >
> > > >>> > usb@xyz {
> > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > >>> > };
> > > >>> >
> > > >>>
> > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > >>> Is this not the case?
> > > >>
> > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > >> the memory map looks like, so I might provide a more appropriate
> > > >> solution to accepting a pretty pointless MFD.
> > > >
> > > > FWIW, the address map for XUSB looks like this:
> > > >
> > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > xHCI registers: 0x70090000 - 0x70098000
> > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > >
> > > >> Two solutions spring to mind. You can either call
> > > >> of_platform_populate() from the USB driver, as some already do:
> > > >>
> > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > >> drivers/usb/dwc3/dwc3-st.c:
> > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > >> drivers/usb/musb/musb_am335x.c:
> > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > >
> > > > This still requires a small, separate driver to setup the regmap and
> > > > do of_platform_populate(). The only difference is it lives in
> > > > drivers/usb/ instead of drivers/mfd/.
> > > >
> > > >> Or use the "simple-mfd", which is currently in -next:
> > > >>
> > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > >
> > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > before. The issue here is that if we ever have to do something
> > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > binding and break DT backwards-compatibility.
> > >
> > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > future-proof this binding/driver should it need to be extended in the
> > > future. If this is a firm NAK from you however, I'll need to let
> > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> >
> > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > that you need an MFD driver for this and refuse to take a shell (read
> > "pointless") one on an "if we ever ..." clause.
> >
> > Will you break backwards capability though? I'm not sure you will.
> > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > normal way. *If* you introduce an MFD driver at a later date then the
> > old DTB will miss out the *new* functionality, which is expected and
> > accepted.
>
> I'm a little confused by the simple-mfd approach. The only code I see in
> linux-next for this is a single line that adds the "simple-mfd" string
> to the OF device ID table in drivers/of/platform.c. As far as I can tell
> this will merely cause child devices to be created. There won't be a
> shared regmap and resources won't be set up properly either. Having a
> proper MFD driver seems to be the only way to achieve what we need.
>
> The reason why every other simple-mfd users seems to get away with this
> is because they also match on syscon and that sets up a regmap of its
> own and the child device drivers use the syscon API to get at it. So I
> don't see how we can make use of simple-mfd to achieve what we need,
> unless we essentially copy what syscon does (but do proper resource
> management while at it).
If you have shared resources and your device isn't classed as a syscon
device then yes, simple-mfd probably isn't suitable for this use-case.
You might need to go into more detail with regards to "proper resource
management", as I'm not entirely sure I agree.
Still, this doesn't change the fact that, from what I've seen, I still
don't think you need a dedicated MFD driver.
What do you think of:
usb-host@0,70090000 {
compatible = "nvidia,tegra124-xhci";
reg = <0x0 0x70090000 0x0 0x80CF>,
<0x0 0x70098800 0x0 0x0800>,
<0x0 0x70099000 0x0 0x1000>;
/* Something from the datasheet */
reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
ranges;
xusb_mbox: mailbox {
compatible = "nvidia,tegra124-xusb-mbox";
reg = <0x0 0x700980e0 0x0 0x13>,
<0x0 0x70098428 0x0 0x03>;
/* Something from the datasheet */
reg-names = "mbox-one", "mbox-two";
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
};
};
Then hvae the XHCI driver call of_platform_populate() as I proposed
above?
> There is also the matter of clocks, resets, power supplies, etc. which
> simple-mfd can't take into account in its current form. From a hardware
> point of view, (some of) the clocks and resets are shared by the XHCI
> and the mailbox blocks, so the device tree node would have to take that
> into account. And a driver would also have to know which clocks, resets
> and power supplies to probe and the order in which they need to be
> enabled. simple-mfd doesn't provide any of that currently, so we'd
> likely need to hack around that in all sorts of weird ways in the child
> drivers. It makes much more sense for a top-level MFD driver to set up
> the shared hardware resources and then instantiate the child devices and
> let the drivers for those only care about the child-specific resources.
>
> A catch-all driver will inevitably lead to implementing a midlayer with
> potentially all sorts of quirks to make it work with the various devices
> out there.
>
> A much better implementation, in my opinion, would be to make simple-mfd
> a subclassable object and then have drivers use a helper library to call
> code that is common for simple-mfd kinds of devices. Something like this
> for example:
>
> struct tegra_xusb {
> ...
> struct mfd_simple mfd;
> ...
> };
>
> static int tegra_xusb_probe(struct platform_device *pdev)
> {
> struct tegra_xusb *xusb;
> ...
> err = mfd_simple_register(&xusb->mfd);
> ...
> }
>
> Now all these drivers reuse all the code provided by the mfd_simple
> helper, which will instantiate the children, but it is also very easy to
> tie in the platform-specific glue (clocks, resets, regulators, ...) via
> the device-specific drivers.
I'm not keen on creating a not-so-simple-mfd driver. Let's work with
what we've got for the time being.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-21 8:40 ` Lee Jones
(?)
@ 2015-05-21 10:12 ` Thierry Reding
-1 siblings, 0 replies; 136+ messages in thread
From: Thierry Reding @ 2015-05-21 10:12 UTC (permalink / raw)
To: Lee Jones
Cc: Andrew Bresticker, Jon Hunter, Stephen Warren, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
[-- Attachment #1: Type: text/plain, Size: 13446 bytes --]
On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> On Wed, 20 May 2015, Thierry Reding wrote:
> > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > >>> >
> > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > > >>> >>
> > > > >>> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > > > >>> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > > >>> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> > > > >>> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > > > >>> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> > > > >>> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > > > >>> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > > >>> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > > >>> >> ---
> > > > >>> >> Changes from v7:
> > > > >>> >> - Move non-shared resources into child nodes.
> > > > >>> >> New for v7.
> > > > >>> >> ---
> > > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > > >>> >> 1 file changed, 37 insertions(+)
> > > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >>
> > > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >> new file mode 100644
> > > > >>> >> index 0000000..bc50110
> > > > >>> >> --- /dev/null
> > > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >> @@ -0,0 +1,37 @@
> > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > >>> >> +==============================
> > > > >>> >> +
> > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > > >>> >> +
> > > > >>> >> +Required properties:
> > > > >>> >> +--------------------
> > > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > > >>> >> + where <chip> is tegra132.
> > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > > >>> >> + mapping is 1:1.
> > > > >>> >> + - #address-cells: Must be 2.
> > > > >>> >> + - #size-cells: Must be 2.
> > > > >>> >> +
> > > > >>> >> +Example:
> > > > >>> >> +--------
> > > > >>> >> + usb@0,70098000 {
> > > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > > >>> >> + ranges;
> > > > >>> >> +
> > > > >>> >> + #address-cells = <2>;
> > > > >>> >> + #size-cells = <2>;
> > > > >>> >> +
> > > > >>> >> + usb-host@0,70090000 {
> > > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > > >>> >> + ...
> > > > >>> >> + };
> > > > >>> >> +
> > > > >>> >> + mailbox {
> > > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > > >>> >> + ...
> > > > >>> >> + };
> > > > >>> >
> > > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > > >>> > device to its Mailbox.
> > > > >>> >
> > > > >>> > usb@xyz {
> > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > >>> > };
> > > > >>> >
> > > > >>>
> > > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > > >>> Is this not the case?
> > > > >>
> > > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > > >> the memory map looks like, so I might provide a more appropriate
> > > > >> solution to accepting a pretty pointless MFD.
> > > > >
> > > > > FWIW, the address map for XUSB looks like this:
> > > > >
> > > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > > xHCI registers: 0x70090000 - 0x70098000
> > > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > > >
> > > > >> Two solutions spring to mind. You can either call
> > > > >> of_platform_populate() from the USB driver, as some already do:
> > > > >>
> > > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > > >> drivers/usb/dwc3/dwc3-st.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/musb/musb_am335x.c:
> > > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > > >
> > > > > This still requires a small, separate driver to setup the regmap and
> > > > > do of_platform_populate(). The only difference is it lives in
> > > > > drivers/usb/ instead of drivers/mfd/.
> > > > >
> > > > >> Or use the "simple-mfd", which is currently in -next:
> > > > >>
> > > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > > >
> > > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > > before. The issue here is that if we ever have to do something
> > > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > > binding and break DT backwards-compatibility.
> > > >
> > > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > > future-proof this binding/driver should it need to be extended in the
> > > > future. If this is a firm NAK from you however, I'll need to let
> > > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> > >
> > > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > > that you need an MFD driver for this and refuse to take a shell (read
> > > "pointless") one on an "if we ever ..." clause.
> > >
> > > Will you break backwards capability though? I'm not sure you will.
> > > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > > normal way. *If* you introduce an MFD driver at a later date then the
> > > old DTB will miss out the *new* functionality, which is expected and
> > > accepted.
> >
> > I'm a little confused by the simple-mfd approach. The only code I see in
> > linux-next for this is a single line that adds the "simple-mfd" string
> > to the OF device ID table in drivers/of/platform.c. As far as I can tell
> > this will merely cause child devices to be created. There won't be a
> > shared regmap and resources won't be set up properly either. Having a
> > proper MFD driver seems to be the only way to achieve what we need.
> >
> > The reason why every other simple-mfd users seems to get away with this
> > is because they also match on syscon and that sets up a regmap of its
> > own and the child device drivers use the syscon API to get at it. So I
> > don't see how we can make use of simple-mfd to achieve what we need,
> > unless we essentially copy what syscon does (but do proper resource
> > management while at it).
>
> If you have shared resources and your device isn't classed as a syscon
> device then yes, simple-mfd probably isn't suitable for this use-case.
> You might need to go into more detail with regards to "proper resource
> management", as I'm not entirely sure I agree.
>
> Still, this doesn't change the fact that, from what I've seen, I still
> don't think you need a dedicated MFD driver.
>
> What do you think of:
>
> usb-host@0,70090000 {
> compatible = "nvidia,tegra124-xhci";
> reg = <0x0 0x70090000 0x0 0x80CF>,
> <0x0 0x70098800 0x0 0x0800>,
> <0x0 0x70099000 0x0 0x1000>;
>
> /* Something from the datasheet */
> reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
>
> interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> ranges;
>
> xusb_mbox: mailbox {
> compatible = "nvidia,tegra124-xusb-mbox";
> reg = <0x0 0x700980e0 0x0 0x13>,
> <0x0 0x70098428 0x0 0x03>;
>
> /* Something from the datasheet */
> reg-names = "mbox-one", "mbox-two";
> interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
>
> Then hvae the XHCI driver call of_platform_populate() as I proposed
> above?
That's a little bonghits. It requires the drivers to jump through hoops
to properly manage register accesses (needs to differentiate on the base
depending on the register offset). So if you're going to NAK the MFD
approach I'd rather go a completely different route and keep only a top-
level node in DT here.
One of the problems that the MFD design tries to solve is that the XHCI
controller needs a reference to the mailbox and the pad controller for a
PHY. The pad controller at the same time requires a reference to the
mailbox, so we have a circular dependency that we can only resolve by
introducing two separate devices, instantiated by some top-level entity.
For that reason I don't think your proposal is going to work either. The
circular dependency can't be broken because the XHCI driver will not be
able to of_platform_populate() before getting a PHY, and the PHY will
never show up until of_platform_populate() is called.
So if this isn't going to be an MFD, then I think we should simply go
and instantiate platform devices from the XUSB driver directly. The
problem arising from that is that we have no place to put the top-level
driver. We could take it into drivers/soc/tegra, or perhaps even have it
in the XHCI driver.
If we instantiate platform devices we can either set up the resources
such that we don't have to jump through hoops (I think the resource tree
will allow that) or set up a shared regmap. The latter might be the
easier way out, though it'd also be copying much of what MFD does, but
so be it if that's the only way we can get the matter settled.
> > There is also the matter of clocks, resets, power supplies, etc. which
> > simple-mfd can't take into account in its current form. From a hardware
> > point of view, (some of) the clocks and resets are shared by the XHCI
> > and the mailbox blocks, so the device tree node would have to take that
> > into account. And a driver would also have to know which clocks, resets
> > and power supplies to probe and the order in which they need to be
> > enabled. simple-mfd doesn't provide any of that currently, so we'd
> > likely need to hack around that in all sorts of weird ways in the child
> > drivers. It makes much more sense for a top-level MFD driver to set up
> > the shared hardware resources and then instantiate the child devices and
> > let the drivers for those only care about the child-specific resources.
> >
> > A catch-all driver will inevitably lead to implementing a midlayer with
> > potentially all sorts of quirks to make it work with the various devices
> > out there.
> >
> > A much better implementation, in my opinion, would be to make simple-mfd
> > a subclassable object and then have drivers use a helper library to call
> > code that is common for simple-mfd kinds of devices. Something like this
> > for example:
> >
> > struct tegra_xusb {
> > ...
> > struct mfd_simple mfd;
> > ...
> > };
> >
> > static int tegra_xusb_probe(struct platform_device *pdev)
> > {
> > struct tegra_xusb *xusb;
> > ...
> > err = mfd_simple_register(&xusb->mfd);
> > ...
> > }
> >
> > Now all these drivers reuse all the code provided by the mfd_simple
> > helper, which will instantiate the children, but it is also very easy to
> > tie in the platform-specific glue (clocks, resets, regulators, ...) via
> > the device-specific drivers.
>
> I'm not keen on creating a not-so-simple-mfd driver. Let's work with
> what we've got for the time being.
What we currently have is not a driver at all, it's merely an alias for
simple-bus.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-21 10:12 ` Thierry Reding
0 siblings, 0 replies; 136+ messages in thread
From: Thierry Reding @ 2015-05-21 10:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> On Wed, 20 May 2015, Thierry Reding wrote:
> > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > <abrestic@chromium.org> wrote:
> > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > >>> >
> > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > > >>> >>
> > > > >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> > > > >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> > > > >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> > > > >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> > > > >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > > > >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> > > > >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > > >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> > > > >>> >> ---
> > > > >>> >> Changes from v7:
> > > > >>> >> - Move non-shared resources into child nodes.
> > > > >>> >> New for v7.
> > > > >>> >> ---
> > > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > > >>> >> 1 file changed, 37 insertions(+)
> > > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >>
> > > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >> new file mode 100644
> > > > >>> >> index 0000000..bc50110
> > > > >>> >> --- /dev/null
> > > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >> @@ -0,0 +1,37 @@
> > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > >>> >> +==============================
> > > > >>> >> +
> > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > > >>> >> +
> > > > >>> >> +Required properties:
> > > > >>> >> +--------------------
> > > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > > >>> >> + where <chip> is tegra132.
> > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > > >>> >> + mapping is 1:1.
> > > > >>> >> + - #address-cells: Must be 2.
> > > > >>> >> + - #size-cells: Must be 2.
> > > > >>> >> +
> > > > >>> >> +Example:
> > > > >>> >> +--------
> > > > >>> >> + usb at 0,70098000 {
> > > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > > >>> >> + ranges;
> > > > >>> >> +
> > > > >>> >> + #address-cells = <2>;
> > > > >>> >> + #size-cells = <2>;
> > > > >>> >> +
> > > > >>> >> + usb-host at 0,70090000 {
> > > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > > >>> >> + ...
> > > > >>> >> + };
> > > > >>> >> +
> > > > >>> >> + mailbox {
> > > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > > >>> >> + ...
> > > > >>> >> + };
> > > > >>> >
> > > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > > >>> > device to its Mailbox.
> > > > >>> >
> > > > >>> > usb at xyz {
> > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > >>> > };
> > > > >>> >
> > > > >>>
> > > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > > >>> Is this not the case?
> > > > >>
> > > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > > >> the memory map looks like, so I might provide a more appropriate
> > > > >> solution to accepting a pretty pointless MFD.
> > > > >
> > > > > FWIW, the address map for XUSB looks like this:
> > > > >
> > > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > > xHCI registers: 0x70090000 - 0x70098000
> > > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > > >
> > > > >> Two solutions spring to mind. You can either call
> > > > >> of_platform_populate() from the USB driver, as some already do:
> > > > >>
> > > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > > >> drivers/usb/dwc3/dwc3-st.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/musb/musb_am335x.c:
> > > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > > >
> > > > > This still requires a small, separate driver to setup the regmap and
> > > > > do of_platform_populate(). The only difference is it lives in
> > > > > drivers/usb/ instead of drivers/mfd/.
> > > > >
> > > > >> Or use the "simple-mfd", which is currently in -next:
> > > > >>
> > > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > > >
> > > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > > before. The issue here is that if we ever have to do something
> > > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > > binding and break DT backwards-compatibility.
> > > >
> > > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > > future-proof this binding/driver should it need to be extended in the
> > > > future. If this is a firm NAK from you however, I'll need to let
> > > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> > >
> > > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > > that you need an MFD driver for this and refuse to take a shell (read
> > > "pointless") one on an "if we ever ..." clause.
> > >
> > > Will you break backwards capability though? I'm not sure you will.
> > > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > > normal way. *If* you introduce an MFD driver at a later date then the
> > > old DTB will miss out the *new* functionality, which is expected and
> > > accepted.
> >
> > I'm a little confused by the simple-mfd approach. The only code I see in
> > linux-next for this is a single line that adds the "simple-mfd" string
> > to the OF device ID table in drivers/of/platform.c. As far as I can tell
> > this will merely cause child devices to be created. There won't be a
> > shared regmap and resources won't be set up properly either. Having a
> > proper MFD driver seems to be the only way to achieve what we need.
> >
> > The reason why every other simple-mfd users seems to get away with this
> > is because they also match on syscon and that sets up a regmap of its
> > own and the child device drivers use the syscon API to get at it. So I
> > don't see how we can make use of simple-mfd to achieve what we need,
> > unless we essentially copy what syscon does (but do proper resource
> > management while at it).
>
> If you have shared resources and your device isn't classed as a syscon
> device then yes, simple-mfd probably isn't suitable for this use-case.
> You might need to go into more detail with regards to "proper resource
> management", as I'm not entirely sure I agree.
>
> Still, this doesn't change the fact that, from what I've seen, I still
> don't think you need a dedicated MFD driver.
>
> What do you think of:
>
> usb-host at 0,70090000 {
> compatible = "nvidia,tegra124-xhci";
> reg = <0x0 0x70090000 0x0 0x80CF>,
> <0x0 0x70098800 0x0 0x0800>,
> <0x0 0x70099000 0x0 0x1000>;
>
> /* Something from the datasheet */
> reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
>
> interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> ranges;
>
> xusb_mbox: mailbox {
> compatible = "nvidia,tegra124-xusb-mbox";
> reg = <0x0 0x700980e0 0x0 0x13>,
> <0x0 0x70098428 0x0 0x03>;
>
> /* Something from the datasheet */
> reg-names = "mbox-one", "mbox-two";
> interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
>
> Then hvae the XHCI driver call of_platform_populate() as I proposed
> above?
That's a little bonghits. It requires the drivers to jump through hoops
to properly manage register accesses (needs to differentiate on the base
depending on the register offset). So if you're going to NAK the MFD
approach I'd rather go a completely different route and keep only a top-
level node in DT here.
One of the problems that the MFD design tries to solve is that the XHCI
controller needs a reference to the mailbox and the pad controller for a
PHY. The pad controller at the same time requires a reference to the
mailbox, so we have a circular dependency that we can only resolve by
introducing two separate devices, instantiated by some top-level entity.
For that reason I don't think your proposal is going to work either. The
circular dependency can't be broken because the XHCI driver will not be
able to of_platform_populate() before getting a PHY, and the PHY will
never show up until of_platform_populate() is called.
So if this isn't going to be an MFD, then I think we should simply go
and instantiate platform devices from the XUSB driver directly. The
problem arising from that is that we have no place to put the top-level
driver. We could take it into drivers/soc/tegra, or perhaps even have it
in the XHCI driver.
If we instantiate platform devices we can either set up the resources
such that we don't have to jump through hoops (I think the resource tree
will allow that) or set up a shared regmap. The latter might be the
easier way out, though it'd also be copying much of what MFD does, but
so be it if that's the only way we can get the matter settled.
> > There is also the matter of clocks, resets, power supplies, etc. which
> > simple-mfd can't take into account in its current form. From a hardware
> > point of view, (some of) the clocks and resets are shared by the XHCI
> > and the mailbox blocks, so the device tree node would have to take that
> > into account. And a driver would also have to know which clocks, resets
> > and power supplies to probe and the order in which they need to be
> > enabled. simple-mfd doesn't provide any of that currently, so we'd
> > likely need to hack around that in all sorts of weird ways in the child
> > drivers. It makes much more sense for a top-level MFD driver to set up
> > the shared hardware resources and then instantiate the child devices and
> > let the drivers for those only care about the child-specific resources.
> >
> > A catch-all driver will inevitably lead to implementing a midlayer with
> > potentially all sorts of quirks to make it work with the various devices
> > out there.
> >
> > A much better implementation, in my opinion, would be to make simple-mfd
> > a subclassable object and then have drivers use a helper library to call
> > code that is common for simple-mfd kinds of devices. Something like this
> > for example:
> >
> > struct tegra_xusb {
> > ...
> > struct mfd_simple mfd;
> > ...
> > };
> >
> > static int tegra_xusb_probe(struct platform_device *pdev)
> > {
> > struct tegra_xusb *xusb;
> > ...
> > err = mfd_simple_register(&xusb->mfd);
> > ...
> > }
> >
> > Now all these drivers reuse all the code provided by the mfd_simple
> > helper, which will instantiate the children, but it is also very easy to
> > tie in the platform-specific glue (clocks, resets, regulators, ...) via
> > the device-specific drivers.
>
> I'm not keen on creating a not-so-simple-mfd driver. Let's work with
> what we've got for the time being.
What we currently have is not a driver at all, it's merely an alias for
simple-bus.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150521/6010df0a/attachment.sig>
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-21 10:12 ` Thierry Reding
0 siblings, 0 replies; 136+ messages in thread
From: Thierry Reding @ 2015-05-21 10:12 UTC (permalink / raw)
To: Lee Jones
Cc: Andrew Bresticker, Jon Hunter, Stephen Warren, Alexandre Courbot,
devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz
[-- Attachment #1: Type: text/plain, Size: 13189 bytes --]
On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> On Wed, 20 May 2015, Thierry Reding wrote:
> > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > <abrestic@chromium.org> wrote:
> > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > >>> >
> > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > > >>> >>
> > > > >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> > > > >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> > > > >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> > > > >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> > > > >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > > > >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> > > > >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > > >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> > > > >>> >> ---
> > > > >>> >> Changes from v7:
> > > > >>> >> - Move non-shared resources into child nodes.
> > > > >>> >> New for v7.
> > > > >>> >> ---
> > > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > > >>> >> 1 file changed, 37 insertions(+)
> > > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >>
> > > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >> new file mode 100644
> > > > >>> >> index 0000000..bc50110
> > > > >>> >> --- /dev/null
> > > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > >>> >> @@ -0,0 +1,37 @@
> > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > >>> >> +==============================
> > > > >>> >> +
> > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > > >>> >> +
> > > > >>> >> +Required properties:
> > > > >>> >> +--------------------
> > > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > > >>> >> + where <chip> is tegra132.
> > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > > >>> >> + mapping is 1:1.
> > > > >>> >> + - #address-cells: Must be 2.
> > > > >>> >> + - #size-cells: Must be 2.
> > > > >>> >> +
> > > > >>> >> +Example:
> > > > >>> >> +--------
> > > > >>> >> + usb@0,70098000 {
> > > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > > >>> >> + ranges;
> > > > >>> >> +
> > > > >>> >> + #address-cells = <2>;
> > > > >>> >> + #size-cells = <2>;
> > > > >>> >> +
> > > > >>> >> + usb-host@0,70090000 {
> > > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > > >>> >> + ...
> > > > >>> >> + };
> > > > >>> >> +
> > > > >>> >> + mailbox {
> > > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > > >>> >> + ...
> > > > >>> >> + };
> > > > >>> >
> > > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > > >>> > device to its Mailbox.
> > > > >>> >
> > > > >>> > usb@xyz {
> > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > >>> > };
> > > > >>> >
> > > > >>>
> > > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > > >>> Is this not the case?
> > > > >>
> > > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > > >> the memory map looks like, so I might provide a more appropriate
> > > > >> solution to accepting a pretty pointless MFD.
> > > > >
> > > > > FWIW, the address map for XUSB looks like this:
> > > > >
> > > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > > xHCI registers: 0x70090000 - 0x70098000
> > > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > > >
> > > > >> Two solutions spring to mind. You can either call
> > > > >> of_platform_populate() from the USB driver, as some already do:
> > > > >>
> > > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > > >> drivers/usb/dwc3/dwc3-st.c:
> > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > >> drivers/usb/musb/musb_am335x.c:
> > > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > > >
> > > > > This still requires a small, separate driver to setup the regmap and
> > > > > do of_platform_populate(). The only difference is it lives in
> > > > > drivers/usb/ instead of drivers/mfd/.
> > > > >
> > > > >> Or use the "simple-mfd", which is currently in -next:
> > > > >>
> > > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > > >
> > > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > > before. The issue here is that if we ever have to do something
> > > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > > binding and break DT backwards-compatibility.
> > > >
> > > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > > future-proof this binding/driver should it need to be extended in the
> > > > future. If this is a firm NAK from you however, I'll need to let
> > > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> > >
> > > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > > that you need an MFD driver for this and refuse to take a shell (read
> > > "pointless") one on an "if we ever ..." clause.
> > >
> > > Will you break backwards capability though? I'm not sure you will.
> > > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > > normal way. *If* you introduce an MFD driver at a later date then the
> > > old DTB will miss out the *new* functionality, which is expected and
> > > accepted.
> >
> > I'm a little confused by the simple-mfd approach. The only code I see in
> > linux-next for this is a single line that adds the "simple-mfd" string
> > to the OF device ID table in drivers/of/platform.c. As far as I can tell
> > this will merely cause child devices to be created. There won't be a
> > shared regmap and resources won't be set up properly either. Having a
> > proper MFD driver seems to be the only way to achieve what we need.
> >
> > The reason why every other simple-mfd users seems to get away with this
> > is because they also match on syscon and that sets up a regmap of its
> > own and the child device drivers use the syscon API to get at it. So I
> > don't see how we can make use of simple-mfd to achieve what we need,
> > unless we essentially copy what syscon does (but do proper resource
> > management while at it).
>
> If you have shared resources and your device isn't classed as a syscon
> device then yes, simple-mfd probably isn't suitable for this use-case.
> You might need to go into more detail with regards to "proper resource
> management", as I'm not entirely sure I agree.
>
> Still, this doesn't change the fact that, from what I've seen, I still
> don't think you need a dedicated MFD driver.
>
> What do you think of:
>
> usb-host@0,70090000 {
> compatible = "nvidia,tegra124-xhci";
> reg = <0x0 0x70090000 0x0 0x80CF>,
> <0x0 0x70098800 0x0 0x0800>,
> <0x0 0x70099000 0x0 0x1000>;
>
> /* Something from the datasheet */
> reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
>
> interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> ranges;
>
> xusb_mbox: mailbox {
> compatible = "nvidia,tegra124-xusb-mbox";
> reg = <0x0 0x700980e0 0x0 0x13>,
> <0x0 0x70098428 0x0 0x03>;
>
> /* Something from the datasheet */
> reg-names = "mbox-one", "mbox-two";
> interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
>
> Then hvae the XHCI driver call of_platform_populate() as I proposed
> above?
That's a little bonghits. It requires the drivers to jump through hoops
to properly manage register accesses (needs to differentiate on the base
depending on the register offset). So if you're going to NAK the MFD
approach I'd rather go a completely different route and keep only a top-
level node in DT here.
One of the problems that the MFD design tries to solve is that the XHCI
controller needs a reference to the mailbox and the pad controller for a
PHY. The pad controller at the same time requires a reference to the
mailbox, so we have a circular dependency that we can only resolve by
introducing two separate devices, instantiated by some top-level entity.
For that reason I don't think your proposal is going to work either. The
circular dependency can't be broken because the XHCI driver will not be
able to of_platform_populate() before getting a PHY, and the PHY will
never show up until of_platform_populate() is called.
So if this isn't going to be an MFD, then I think we should simply go
and instantiate platform devices from the XUSB driver directly. The
problem arising from that is that we have no place to put the top-level
driver. We could take it into drivers/soc/tegra, or perhaps even have it
in the XHCI driver.
If we instantiate platform devices we can either set up the resources
such that we don't have to jump through hoops (I think the resource tree
will allow that) or set up a shared regmap. The latter might be the
easier way out, though it'd also be copying much of what MFD does, but
so be it if that's the only way we can get the matter settled.
> > There is also the matter of clocks, resets, power supplies, etc. which
> > simple-mfd can't take into account in its current form. From a hardware
> > point of view, (some of) the clocks and resets are shared by the XHCI
> > and the mailbox blocks, so the device tree node would have to take that
> > into account. And a driver would also have to know which clocks, resets
> > and power supplies to probe and the order in which they need to be
> > enabled. simple-mfd doesn't provide any of that currently, so we'd
> > likely need to hack around that in all sorts of weird ways in the child
> > drivers. It makes much more sense for a top-level MFD driver to set up
> > the shared hardware resources and then instantiate the child devices and
> > let the drivers for those only care about the child-specific resources.
> >
> > A catch-all driver will inevitably lead to implementing a midlayer with
> > potentially all sorts of quirks to make it work with the various devices
> > out there.
> >
> > A much better implementation, in my opinion, would be to make simple-mfd
> > a subclassable object and then have drivers use a helper library to call
> > code that is common for simple-mfd kinds of devices. Something like this
> > for example:
> >
> > struct tegra_xusb {
> > ...
> > struct mfd_simple mfd;
> > ...
> > };
> >
> > static int tegra_xusb_probe(struct platform_device *pdev)
> > {
> > struct tegra_xusb *xusb;
> > ...
> > err = mfd_simple_register(&xusb->mfd);
> > ...
> > }
> >
> > Now all these drivers reuse all the code provided by the mfd_simple
> > helper, which will instantiate the children, but it is also very easy to
> > tie in the platform-specific glue (clocks, resets, regulators, ...) via
> > the device-specific drivers.
>
> I'm not keen on creating a not-so-simple-mfd driver. Let's work with
> what we've got for the time being.
What we currently have is not a driver at all, it's merely an alias for
simple-bus.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 136+ messages in thread[parent not found: <20150521101247.GA8073-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>]
* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-21 10:12 ` Thierry Reding
(?)
@ 2015-05-26 15:18 ` Lee Jones
-1 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-26 15:18 UTC (permalink / raw)
To: Thierry Reding
Cc: Andrew Bresticker, Jon Hunter, Stephen Warren, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, 21 May 2015, Thierry Reding wrote:
> On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> > On Wed, 20 May 2015, Thierry Reding wrote:
> > > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > > <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> > > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > > >>> >
> > > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > > > >>> >>
> > > > > >>> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja8pug/h7KTFAQ@public.gmane.orgg>
> > > > > >>> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > > > >>> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> > > > > >>> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > > > > >>> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> > > > > >>> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > > > > >>> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > > > >>> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > > > >>> >> ---
> > > > > >>> >> Changes from v7:
> > > > > >>> >> - Move non-shared resources into child nodes.
> > > > > >>> >> New for v7.
> > > > > >>> >> ---
> > > > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > > > >>> >> 1 file changed, 37 insertions(+)
> > > > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > >>> >>
> > > > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > >>> >> new file mode 100644
> > > > > >>> >> index 0000000..bc50110
> > > > > >>> >> --- /dev/null
> > > > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > >>> >> @@ -0,0 +1,37 @@
> > > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > > >>> >> +==============================
> > > > > >>> >> +
> > > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > > > >>> >> +
> > > > > >>> >> +Required properties:
> > > > > >>> >> +--------------------
> > > > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > > > >>> >> + where <chip> is tegra132.
> > > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > > > >>> >> + mapping is 1:1.
> > > > > >>> >> + - #address-cells: Must be 2.
> > > > > >>> >> + - #size-cells: Must be 2.
> > > > > >>> >> +
> > > > > >>> >> +Example:
> > > > > >>> >> +--------
> > > > > >>> >> + usb@0,70098000 {
> > > > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > > > >>> >> + ranges;
> > > > > >>> >> +
> > > > > >>> >> + #address-cells = <2>;
> > > > > >>> >> + #size-cells = <2>;
> > > > > >>> >> +
> > > > > >>> >> + usb-host@0,70090000 {
> > > > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > > > >>> >> + ...
> > > > > >>> >> + };
> > > > > >>> >> +
> > > > > >>> >> + mailbox {
> > > > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > > > >>> >> + ...
> > > > > >>> >> + };
> > > > > >>> >
> > > > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > > > >>> > device to its Mailbox.
> > > > > >>> >
> > > > > >>> > usb@xyz {
> > > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > > >>> > };
> > > > > >>> >
> > > > > >>>
> > > > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > > > >>> Is this not the case?
> > > > > >>
> > > > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > > > >> the memory map looks like, so I might provide a more appropriate
> > > > > >> solution to accepting a pretty pointless MFD.
> > > > > >
> > > > > > FWIW, the address map for XUSB looks like this:
> > > > > >
> > > > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > > > xHCI registers: 0x70090000 - 0x70098000
> > > > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > > > >
> > > > > >> Two solutions spring to mind. You can either call
> > > > > >> of_platform_populate() from the USB driver, as some already do:
> > > > > >>
> > > > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > > > >> drivers/usb/dwc3/dwc3-st.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/musb/musb_am335x.c:
> > > > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > > > >
> > > > > > This still requires a small, separate driver to setup the regmap and
> > > > > > do of_platform_populate(). The only difference is it lives in
> > > > > > drivers/usb/ instead of drivers/mfd/.
> > > > > >
> > > > > >> Or use the "simple-mfd", which is currently in -next:
> > > > > >>
> > > > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > > > >
> > > > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > > > before. The issue here is that if we ever have to do something
> > > > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > > > binding and break DT backwards-compatibility.
> > > > >
> > > > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > > > future-proof this binding/driver should it need to be extended in the
> > > > > future. If this is a firm NAK from you however, I'll need to let
> > > > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> > > >
> > > > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > > > that you need an MFD driver for this and refuse to take a shell (read
> > > > "pointless") one on an "if we ever ..." clause.
> > > >
> > > > Will you break backwards capability though? I'm not sure you will.
> > > > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > > > normal way. *If* you introduce an MFD driver at a later date then the
> > > > old DTB will miss out the *new* functionality, which is expected and
> > > > accepted.
> > >
> > > I'm a little confused by the simple-mfd approach. The only code I see in
> > > linux-next for this is a single line that adds the "simple-mfd" string
> > > to the OF device ID table in drivers/of/platform.c. As far as I can tell
> > > this will merely cause child devices to be created. There won't be a
> > > shared regmap and resources won't be set up properly either. Having a
> > > proper MFD driver seems to be the only way to achieve what we need.
> > >
> > > The reason why every other simple-mfd users seems to get away with this
> > > is because they also match on syscon and that sets up a regmap of its
> > > own and the child device drivers use the syscon API to get at it. So I
> > > don't see how we can make use of simple-mfd to achieve what we need,
> > > unless we essentially copy what syscon does (but do proper resource
> > > management while at it).
> >
> > If you have shared resources and your device isn't classed as a syscon
> > device then yes, simple-mfd probably isn't suitable for this use-case.
> > You might need to go into more detail with regards to "proper resource
> > management", as I'm not entirely sure I agree.
> >
> > Still, this doesn't change the fact that, from what I've seen, I still
> > don't think you need a dedicated MFD driver.
> >
> > What do you think of:
> >
> > usb-host@0,70090000 {
> > compatible = "nvidia,tegra124-xhci";
> > reg = <0x0 0x70090000 0x0 0x80CF>,
> > <0x0 0x70098800 0x0 0x0800>,
> > <0x0 0x70099000 0x0 0x1000>;
> >
> > /* Something from the datasheet */
> > reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
> >
> > interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> > ranges;
> >
> > xusb_mbox: mailbox {
> > compatible = "nvidia,tegra124-xusb-mbox";
> > reg = <0x0 0x700980e0 0x0 0x13>,
> > <0x0 0x70098428 0x0 0x03>;
> >
> > /* Something from the datasheet */
> > reg-names = "mbox-one", "mbox-two";
> > interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> > };
> > };
> >
> > Then hvae the XHCI driver call of_platform_populate() as I proposed
> > above?
>
> That's a little bonghits. It requires the drivers to jump through hoops
> to properly manage register accesses (needs to differentiate on the base
> depending on the register offset). So if you're going to NAK the MFD
> approach I'd rather go a completely different route and keep only a top-
> level node in DT here.
>
> One of the problems that the MFD design tries to solve is that the XHCI
> controller needs a reference to the mailbox and the pad controller for a
> PHY. The pad controller at the same time requires a reference to the
> mailbox, so we have a circular dependency that we can only resolve by
> introducing two separate devices, instantiated by some top-level entity.
> For that reason I don't think your proposal is going to work either. The
> circular dependency can't be broken because the XHCI driver will not be
> able to of_platform_populate() before getting a PHY, and the PHY will
> never show up until of_platform_populate() is called.
>
> So if this isn't going to be an MFD, then I think we should simply go
> and instantiate platform devices from the XUSB driver directly. The
> problem arising from that is that we have no place to put the top-level
> driver. We could take it into drivers/soc/tegra, or perhaps even have it
> in the XHCI driver.
>
> If we instantiate platform devices we can either set up the resources
> such that we don't have to jump through hoops (I think the resource tree
> will allow that) or set up a shared regmap. The latter might be the
> easier way out, though it'd also be copying much of what MFD does, but
> so be it if that's the only way we can get the matter settled.
I understand the difficulties identified and empathise with your
situation. I just can't bring myself to justify that a USB device
which has it's own Mailbox is an MFD. If you take a look above, you
can see some examples of other USB drivers registering sub-devices. I
think you can make this work well for your setup.
> > > There is also the matter of clocks, resets, power supplies, etc. which
> > > simple-mfd can't take into account in its current form. From a hardware
> > > point of view, (some of) the clocks and resets are shared by the XHCI
> > > and the mailbox blocks, so the device tree node would have to take that
> > > into account. And a driver would also have to know which clocks, resets
> > > and power supplies to probe and the order in which they need to be
> > > enabled. simple-mfd doesn't provide any of that currently, so we'd
> > > likely need to hack around that in all sorts of weird ways in the child
> > > drivers. It makes much more sense for a top-level MFD driver to set up
> > > the shared hardware resources and then instantiate the child devices and
> > > let the drivers for those only care about the child-specific resources.
> > >
> > > A catch-all driver will inevitably lead to implementing a midlayer with
> > > potentially all sorts of quirks to make it work with the various devices
> > > out there.
> > >
> > > A much better implementation, in my opinion, would be to make simple-mfd
> > > a subclassable object and then have drivers use a helper library to call
> > > code that is common for simple-mfd kinds of devices. Something like this
> > > for example:
> > >
> > > struct tegra_xusb {
> > > ...
> > > struct mfd_simple mfd;
> > > ...
> > > };
> > >
> > > static int tegra_xusb_probe(struct platform_device *pdev)
> > > {
> > > struct tegra_xusb *xusb;
> > > ...
> > > err = mfd_simple_register(&xusb->mfd);
> > > ...
> > > }
> > >
> > > Now all these drivers reuse all the code provided by the mfd_simple
> > > helper, which will instantiate the children, but it is also very easy to
> > > tie in the platform-specific glue (clocks, resets, regulators, ...) via
> > > the device-specific drivers.
> >
> > I'm not keen on creating a not-so-simple-mfd driver. Let's work with
> > what we've got for the time being.
>
> What we currently have is not a driver at all, it's merely an alias for
> simple-bus.
Right, which is exactly what it was designed to be. Initially we were
using simple-bus, but some people (rightly) thought this an abuse 'cos
MFD isn't really a bus.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-26 15:18 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-26 15:18 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 21 May 2015, Thierry Reding wrote:
> On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> > On Wed, 20 May 2015, Thierry Reding wrote:
> > > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > > <abrestic@chromium.org> wrote:
> > > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > > >>> >
> > > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > > > >>> >>
> > > > > >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> > > > > >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> > > > > >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> > > > > >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> > > > > >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > > > > >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> > > > > >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > > > >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> > > > > >>> >> ---
> > > > > >>> >> Changes from v7:
> > > > > >>> >> - Move non-shared resources into child nodes.
> > > > > >>> >> New for v7.
> > > > > >>> >> ---
> > > > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > > > >>> >> 1 file changed, 37 insertions(+)
> > > > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > >>> >>
> > > > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > >>> >> new file mode 100644
> > > > > >>> >> index 0000000..bc50110
> > > > > >>> >> --- /dev/null
> > > > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > >>> >> @@ -0,0 +1,37 @@
> > > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > > >>> >> +==============================
> > > > > >>> >> +
> > > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > > > >>> >> +
> > > > > >>> >> +Required properties:
> > > > > >>> >> +--------------------
> > > > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > > > >>> >> + where <chip> is tegra132.
> > > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > > > >>> >> + mapping is 1:1.
> > > > > >>> >> + - #address-cells: Must be 2.
> > > > > >>> >> + - #size-cells: Must be 2.
> > > > > >>> >> +
> > > > > >>> >> +Example:
> > > > > >>> >> +--------
> > > > > >>> >> + usb at 0,70098000 {
> > > > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > > > >>> >> + ranges;
> > > > > >>> >> +
> > > > > >>> >> + #address-cells = <2>;
> > > > > >>> >> + #size-cells = <2>;
> > > > > >>> >> +
> > > > > >>> >> + usb-host at 0,70090000 {
> > > > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > > > >>> >> + ...
> > > > > >>> >> + };
> > > > > >>> >> +
> > > > > >>> >> + mailbox {
> > > > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > > > >>> >> + ...
> > > > > >>> >> + };
> > > > > >>> >
> > > > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > > > >>> > device to its Mailbox.
> > > > > >>> >
> > > > > >>> > usb at xyz {
> > > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > > >>> > };
> > > > > >>> >
> > > > > >>>
> > > > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > > > >>> Is this not the case?
> > > > > >>
> > > > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > > > >> the memory map looks like, so I might provide a more appropriate
> > > > > >> solution to accepting a pretty pointless MFD.
> > > > > >
> > > > > > FWIW, the address map for XUSB looks like this:
> > > > > >
> > > > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > > > xHCI registers: 0x70090000 - 0x70098000
> > > > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > > > >
> > > > > >> Two solutions spring to mind. You can either call
> > > > > >> of_platform_populate() from the USB driver, as some already do:
> > > > > >>
> > > > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > > > >> drivers/usb/dwc3/dwc3-st.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/musb/musb_am335x.c:
> > > > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > > > >
> > > > > > This still requires a small, separate driver to setup the regmap and
> > > > > > do of_platform_populate(). The only difference is it lives in
> > > > > > drivers/usb/ instead of drivers/mfd/.
> > > > > >
> > > > > >> Or use the "simple-mfd", which is currently in -next:
> > > > > >>
> > > > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > > > >
> > > > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > > > before. The issue here is that if we ever have to do something
> > > > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > > > binding and break DT backwards-compatibility.
> > > > >
> > > > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > > > future-proof this binding/driver should it need to be extended in the
> > > > > future. If this is a firm NAK from you however, I'll need to let
> > > > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> > > >
> > > > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > > > that you need an MFD driver for this and refuse to take a shell (read
> > > > "pointless") one on an "if we ever ..." clause.
> > > >
> > > > Will you break backwards capability though? I'm not sure you will.
> > > > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > > > normal way. *If* you introduce an MFD driver at a later date then the
> > > > old DTB will miss out the *new* functionality, which is expected and
> > > > accepted.
> > >
> > > I'm a little confused by the simple-mfd approach. The only code I see in
> > > linux-next for this is a single line that adds the "simple-mfd" string
> > > to the OF device ID table in drivers/of/platform.c. As far as I can tell
> > > this will merely cause child devices to be created. There won't be a
> > > shared regmap and resources won't be set up properly either. Having a
> > > proper MFD driver seems to be the only way to achieve what we need.
> > >
> > > The reason why every other simple-mfd users seems to get away with this
> > > is because they also match on syscon and that sets up a regmap of its
> > > own and the child device drivers use the syscon API to get at it. So I
> > > don't see how we can make use of simple-mfd to achieve what we need,
> > > unless we essentially copy what syscon does (but do proper resource
> > > management while at it).
> >
> > If you have shared resources and your device isn't classed as a syscon
> > device then yes, simple-mfd probably isn't suitable for this use-case.
> > You might need to go into more detail with regards to "proper resource
> > management", as I'm not entirely sure I agree.
> >
> > Still, this doesn't change the fact that, from what I've seen, I still
> > don't think you need a dedicated MFD driver.
> >
> > What do you think of:
> >
> > usb-host at 0,70090000 {
> > compatible = "nvidia,tegra124-xhci";
> > reg = <0x0 0x70090000 0x0 0x80CF>,
> > <0x0 0x70098800 0x0 0x0800>,
> > <0x0 0x70099000 0x0 0x1000>;
> >
> > /* Something from the datasheet */
> > reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
> >
> > interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> > ranges;
> >
> > xusb_mbox: mailbox {
> > compatible = "nvidia,tegra124-xusb-mbox";
> > reg = <0x0 0x700980e0 0x0 0x13>,
> > <0x0 0x70098428 0x0 0x03>;
> >
> > /* Something from the datasheet */
> > reg-names = "mbox-one", "mbox-two";
> > interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> > };
> > };
> >
> > Then hvae the XHCI driver call of_platform_populate() as I proposed
> > above?
>
> That's a little bonghits. It requires the drivers to jump through hoops
> to properly manage register accesses (needs to differentiate on the base
> depending on the register offset). So if you're going to NAK the MFD
> approach I'd rather go a completely different route and keep only a top-
> level node in DT here.
>
> One of the problems that the MFD design tries to solve is that the XHCI
> controller needs a reference to the mailbox and the pad controller for a
> PHY. The pad controller at the same time requires a reference to the
> mailbox, so we have a circular dependency that we can only resolve by
> introducing two separate devices, instantiated by some top-level entity.
> For that reason I don't think your proposal is going to work either. The
> circular dependency can't be broken because the XHCI driver will not be
> able to of_platform_populate() before getting a PHY, and the PHY will
> never show up until of_platform_populate() is called.
>
> So if this isn't going to be an MFD, then I think we should simply go
> and instantiate platform devices from the XUSB driver directly. The
> problem arising from that is that we have no place to put the top-level
> driver. We could take it into drivers/soc/tegra, or perhaps even have it
> in the XHCI driver.
>
> If we instantiate platform devices we can either set up the resources
> such that we don't have to jump through hoops (I think the resource tree
> will allow that) or set up a shared regmap. The latter might be the
> easier way out, though it'd also be copying much of what MFD does, but
> so be it if that's the only way we can get the matter settled.
I understand the difficulties identified and empathise with your
situation. I just can't bring myself to justify that a USB device
which has it's own Mailbox is an MFD. If you take a look above, you
can see some examples of other USB drivers registering sub-devices. I
think you can make this work well for your setup.
> > > There is also the matter of clocks, resets, power supplies, etc. which
> > > simple-mfd can't take into account in its current form. From a hardware
> > > point of view, (some of) the clocks and resets are shared by the XHCI
> > > and the mailbox blocks, so the device tree node would have to take that
> > > into account. And a driver would also have to know which clocks, resets
> > > and power supplies to probe and the order in which they need to be
> > > enabled. simple-mfd doesn't provide any of that currently, so we'd
> > > likely need to hack around that in all sorts of weird ways in the child
> > > drivers. It makes much more sense for a top-level MFD driver to set up
> > > the shared hardware resources and then instantiate the child devices and
> > > let the drivers for those only care about the child-specific resources.
> > >
> > > A catch-all driver will inevitably lead to implementing a midlayer with
> > > potentially all sorts of quirks to make it work with the various devices
> > > out there.
> > >
> > > A much better implementation, in my opinion, would be to make simple-mfd
> > > a subclassable object and then have drivers use a helper library to call
> > > code that is common for simple-mfd kinds of devices. Something like this
> > > for example:
> > >
> > > struct tegra_xusb {
> > > ...
> > > struct mfd_simple mfd;
> > > ...
> > > };
> > >
> > > static int tegra_xusb_probe(struct platform_device *pdev)
> > > {
> > > struct tegra_xusb *xusb;
> > > ...
> > > err = mfd_simple_register(&xusb->mfd);
> > > ...
> > > }
> > >
> > > Now all these drivers reuse all the code provided by the mfd_simple
> > > helper, which will instantiate the children, but it is also very easy to
> > > tie in the platform-specific glue (clocks, resets, regulators, ...) via
> > > the device-specific drivers.
> >
> > I'm not keen on creating a not-so-simple-mfd driver. Let's work with
> > what we've got for the time being.
>
> What we currently have is not a driver at all, it's merely an alias for
> simple-bus.
Right, which is exactly what it was designed to be. Initially we were
using simple-bus, but some people (rightly) thought this an abuse 'cos
MFD isn't really a bus.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-05-26 15:18 ` Lee Jones
0 siblings, 0 replies; 136+ messages in thread
From: Lee Jones @ 2015-05-26 15:18 UTC (permalink / raw)
To: Thierry Reding
Cc: Andrew Bresticker, Jon Hunter, Stephen Warren, Alexandre Courbot,
devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz
On Thu, 21 May 2015, Thierry Reding wrote:
> On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> > On Wed, 20 May 2015, Thierry Reding wrote:
> > > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > > <abrestic@chromium.org> wrote:
> > > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > > >>> >
> > > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > > > >>> >>
> > > > > >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> > > > > >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> > > > > >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> > > > > >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> > > > > >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > > > > >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> > > > > >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > > > >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> > > > > >>> >> ---
> > > > > >>> >> Changes from v7:
> > > > > >>> >> - Move non-shared resources into child nodes.
> > > > > >>> >> New for v7.
> > > > > >>> >> ---
> > > > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > > > >>> >> 1 file changed, 37 insertions(+)
> > > > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > >>> >>
> > > > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > >>> >> new file mode 100644
> > > > > >>> >> index 0000000..bc50110
> > > > > >>> >> --- /dev/null
> > > > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > >>> >> @@ -0,0 +1,37 @@
> > > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > > >>> >> +==============================
> > > > > >>> >> +
> > > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > > > >>> >> +
> > > > > >>> >> +Required properties:
> > > > > >>> >> +--------------------
> > > > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > > > >>> >> + where <chip> is tegra132.
> > > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > > > >>> >> + mapping is 1:1.
> > > > > >>> >> + - #address-cells: Must be 2.
> > > > > >>> >> + - #size-cells: Must be 2.
> > > > > >>> >> +
> > > > > >>> >> +Example:
> > > > > >>> >> +--------
> > > > > >>> >> + usb@0,70098000 {
> > > > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > > > >>> >> + ranges;
> > > > > >>> >> +
> > > > > >>> >> + #address-cells = <2>;
> > > > > >>> >> + #size-cells = <2>;
> > > > > >>> >> +
> > > > > >>> >> + usb-host@0,70090000 {
> > > > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > > > >>> >> + ...
> > > > > >>> >> + };
> > > > > >>> >> +
> > > > > >>> >> + mailbox {
> > > > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > > > >>> >> + ...
> > > > > >>> >> + };
> > > > > >>> >
> > > > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > > > >>> > device to its Mailbox.
> > > > > >>> >
> > > > > >>> > usb@xyz {
> > > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > > >>> > };
> > > > > >>> >
> > > > > >>>
> > > > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > > > >>> Is this not the case?
> > > > > >>
> > > > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > > > >> the memory map looks like, so I might provide a more appropriate
> > > > > >> solution to accepting a pretty pointless MFD.
> > > > > >
> > > > > > FWIW, the address map for XUSB looks like this:
> > > > > >
> > > > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > > > xHCI registers: 0x70090000 - 0x70098000
> > > > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > > > >
> > > > > >> Two solutions spring to mind. You can either call
> > > > > >> of_platform_populate() from the USB driver, as some already do:
> > > > > >>
> > > > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > > > >> drivers/usb/dwc3/dwc3-st.c:
> > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > >> drivers/usb/musb/musb_am335x.c:
> > > > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > > > >
> > > > > > This still requires a small, separate driver to setup the regmap and
> > > > > > do of_platform_populate(). The only difference is it lives in
> > > > > > drivers/usb/ instead of drivers/mfd/.
> > > > > >
> > > > > >> Or use the "simple-mfd", which is currently in -next:
> > > > > >>
> > > > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > > > >
> > > > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > > > before. The issue here is that if we ever have to do something
> > > > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > > > binding and break DT backwards-compatibility.
> > > > >
> > > > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > > > future-proof this binding/driver should it need to be extended in the
> > > > > future. If this is a firm NAK from you however, I'll need to let
> > > > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> > > >
> > > > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > > > that you need an MFD driver for this and refuse to take a shell (read
> > > > "pointless") one on an "if we ever ..." clause.
> > > >
> > > > Will you break backwards capability though? I'm not sure you will.
> > > > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > > > normal way. *If* you introduce an MFD driver at a later date then the
> > > > old DTB will miss out the *new* functionality, which is expected and
> > > > accepted.
> > >
> > > I'm a little confused by the simple-mfd approach. The only code I see in
> > > linux-next for this is a single line that adds the "simple-mfd" string
> > > to the OF device ID table in drivers/of/platform.c. As far as I can tell
> > > this will merely cause child devices to be created. There won't be a
> > > shared regmap and resources won't be set up properly either. Having a
> > > proper MFD driver seems to be the only way to achieve what we need.
> > >
> > > The reason why every other simple-mfd users seems to get away with this
> > > is because they also match on syscon and that sets up a regmap of its
> > > own and the child device drivers use the syscon API to get at it. So I
> > > don't see how we can make use of simple-mfd to achieve what we need,
> > > unless we essentially copy what syscon does (but do proper resource
> > > management while at it).
> >
> > If you have shared resources and your device isn't classed as a syscon
> > device then yes, simple-mfd probably isn't suitable for this use-case.
> > You might need to go into more detail with regards to "proper resource
> > management", as I'm not entirely sure I agree.
> >
> > Still, this doesn't change the fact that, from what I've seen, I still
> > don't think you need a dedicated MFD driver.
> >
> > What do you think of:
> >
> > usb-host@0,70090000 {
> > compatible = "nvidia,tegra124-xhci";
> > reg = <0x0 0x70090000 0x0 0x80CF>,
> > <0x0 0x70098800 0x0 0x0800>,
> > <0x0 0x70099000 0x0 0x1000>;
> >
> > /* Something from the datasheet */
> > reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
> >
> > interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> > ranges;
> >
> > xusb_mbox: mailbox {
> > compatible = "nvidia,tegra124-xusb-mbox";
> > reg = <0x0 0x700980e0 0x0 0x13>,
> > <0x0 0x70098428 0x0 0x03>;
> >
> > /* Something from the datasheet */
> > reg-names = "mbox-one", "mbox-two";
> > interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> > };
> > };
> >
> > Then hvae the XHCI driver call of_platform_populate() as I proposed
> > above?
>
> That's a little bonghits. It requires the drivers to jump through hoops
> to properly manage register accesses (needs to differentiate on the base
> depending on the register offset). So if you're going to NAK the MFD
> approach I'd rather go a completely different route and keep only a top-
> level node in DT here.
>
> One of the problems that the MFD design tries to solve is that the XHCI
> controller needs a reference to the mailbox and the pad controller for a
> PHY. The pad controller at the same time requires a reference to the
> mailbox, so we have a circular dependency that we can only resolve by
> introducing two separate devices, instantiated by some top-level entity.
> For that reason I don't think your proposal is going to work either. The
> circular dependency can't be broken because the XHCI driver will not be
> able to of_platform_populate() before getting a PHY, and the PHY will
> never show up until of_platform_populate() is called.
>
> So if this isn't going to be an MFD, then I think we should simply go
> and instantiate platform devices from the XUSB driver directly. The
> problem arising from that is that we have no place to put the top-level
> driver. We could take it into drivers/soc/tegra, or perhaps even have it
> in the XHCI driver.
>
> If we instantiate platform devices we can either set up the resources
> such that we don't have to jump through hoops (I think the resource tree
> will allow that) or set up a shared regmap. The latter might be the
> easier way out, though it'd also be copying much of what MFD does, but
> so be it if that's the only way we can get the matter settled.
I understand the difficulties identified and empathise with your
situation. I just can't bring myself to justify that a USB device
which has it's own Mailbox is an MFD. If you take a look above, you
can see some examples of other USB drivers registering sub-devices. I
think you can make this work well for your setup.
> > > There is also the matter of clocks, resets, power supplies, etc. which
> > > simple-mfd can't take into account in its current form. From a hardware
> > > point of view, (some of) the clocks and resets are shared by the XHCI
> > > and the mailbox blocks, so the device tree node would have to take that
> > > into account. And a driver would also have to know which clocks, resets
> > > and power supplies to probe and the order in which they need to be
> > > enabled. simple-mfd doesn't provide any of that currently, so we'd
> > > likely need to hack around that in all sorts of weird ways in the child
> > > drivers. It makes much more sense for a top-level MFD driver to set up
> > > the shared hardware resources and then instantiate the child devices and
> > > let the drivers for those only care about the child-specific resources.
> > >
> > > A catch-all driver will inevitably lead to implementing a midlayer with
> > > potentially all sorts of quirks to make it work with the various devices
> > > out there.
> > >
> > > A much better implementation, in my opinion, would be to make simple-mfd
> > > a subclassable object and then have drivers use a helper library to call
> > > code that is common for simple-mfd kinds of devices. Something like this
> > > for example:
> > >
> > > struct tegra_xusb {
> > > ...
> > > struct mfd_simple mfd;
> > > ...
> > > };
> > >
> > > static int tegra_xusb_probe(struct platform_device *pdev)
> > > {
> > > struct tegra_xusb *xusb;
> > > ...
> > > err = mfd_simple_register(&xusb->mfd);
> > > ...
> > > }
> > >
> > > Now all these drivers reuse all the code provided by the mfd_simple
> > > helper, which will instantiate the children, but it is also very easy to
> > > tie in the platform-specific glue (clocks, resets, regulators, ...) via
> > > the device-specific drivers.
> >
> > I'm not keen on creating a not-so-simple-mfd driver. Let's work with
> > what we've got for the time being.
>
> What we currently have is not a driver at all, it's merely an alias for
> simple-bus.
Right, which is exactly what it was designed to be. Initially we were
using simple-bus, but some people (rightly) thought this an abuse 'cos
MFD isn't really a bus.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
2015-05-26 15:18 ` Lee Jones
(?)
@ 2015-06-30 18:22 ` Grant Likely
-1 siblings, 0 replies; 136+ messages in thread
From: Grant Likely @ 2015-06-30 18:22 UTC (permalink / raw)
To: Lee Jones, Thierry Reding
Cc: Mark Rutland, Alexandre Courbot, Ian Campbell,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz, Pawel Moll,
devicetree-u79uwXL29TY76Z2rM5mHXA, Andrew Bresticker,
Stephen Warren, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jon Hunter,
Rob Herring, Kumar Gala, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Tue, 26 May 2015 16:18:54 +0100
, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
wrote:
> On Thu, 21 May 2015, Thierry Reding wrote:
>
> > On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> > > On Wed, 20 May 2015, Thierry Reding wrote:
> > > > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > > > <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> > > > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > > > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > > > >>> >
> > > > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > > > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > > > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > > > > >>> >>
> > > > > > >>> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > > > > > >>> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > > > > >>> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> > > > > > >>> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > > > > > >>> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> > > > > > >>> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > > > > > >>> >> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > > > > > >>> >> Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > > > > >>> >> ---
> > > > > > >>> >> Changes from v7:
> > > > > > >>> >> - Move non-shared resources into child nodes.
> > > > > > >>> >> New for v7.
> > > > > > >>> >> ---
> > > > > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > > > > >>> >> 1 file changed, 37 insertions(+)
> > > > > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >>
> > > > > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >> new file mode 100644
> > > > > > >>> >> index 0000000..bc50110
> > > > > > >>> >> --- /dev/null
> > > > > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >> @@ -0,0 +1,37 @@
> > > > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > > > >>> >> +==============================
> > > > > > >>> >> +
> > > > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > > > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > > > > >>> >> +
> > > > > > >>> >> +Required properties:
> > > > > > >>> >> +--------------------
> > > > > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > > > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > > > > >>> >> + where <chip> is tegra132.
> > > > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > > > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > > > > >>> >> + mapping is 1:1.
> > > > > > >>> >> + - #address-cells: Must be 2.
> > > > > > >>> >> + - #size-cells: Must be 2.
> > > > > > >>> >> +
> > > > > > >>> >> +Example:
> > > > > > >>> >> +--------
> > > > > > >>> >> + usb@0,70098000 {
> > > > > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > > > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > > > > >>> >> + ranges;
> > > > > > >>> >> +
> > > > > > >>> >> + #address-cells = <2>;
> > > > > > >>> >> + #size-cells = <2>;
> > > > > > >>> >> +
> > > > > > >>> >> + usb-host@0,70090000 {
> > > > > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > > > > >>> >> + ...
> > > > > > >>> >> + };
> > > > > > >>> >> +
> > > > > > >>> >> + mailbox {
> > > > > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > > > > >>> >> + ...
> > > > > > >>> >> + };
> > > > > > >>> >
> > > > > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > > > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > > > > >>> > device to its Mailbox.
> > > > > > >>> >
> > > > > > >>> > usb@xyz {
> > > > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > > > >>> > };
> > > > > > >>> >
> > > > > > >>>
> > > > > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > > > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > > > > >>> Is this not the case?
> > > > > > >>
> > > > > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > > > > >> the memory map looks like, so I might provide a more appropriate
> > > > > > >> solution to accepting a pretty pointless MFD.
> > > > > > >
> > > > > > > FWIW, the address map for XUSB looks like this:
> > > > > > >
> > > > > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > > > > xHCI registers: 0x70090000 - 0x70098000
> > > > > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > > > > >
> > > > > > >> Two solutions spring to mind. You can either call
> > > > > > >> of_platform_populate() from the USB driver, as some already do:
> > > > > > >>
> > > > > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > > > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > > > > >> drivers/usb/dwc3/dwc3-st.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/musb/musb_am335x.c:
> > > > > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > > > > >
> > > > > > > This still requires a small, separate driver to setup the regmap and
> > > > > > > do of_platform_populate(). The only difference is it lives in
> > > > > > > drivers/usb/ instead of drivers/mfd/.
> > > > > > >
> > > > > > >> Or use the "simple-mfd", which is currently in -next:
> > > > > > >>
> > > > > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > > > > >
> > > > > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > > > > before. The issue here is that if we ever have to do something
> > > > > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > > > > binding and break DT backwards-compatibility.
> > > > > >
> > > > > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > > > > future-proof this binding/driver should it need to be extended in the
> > > > > > future. If this is a firm NAK from you however, I'll need to let
> > > > > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> > > > >
> > > > > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > > > > that you need an MFD driver for this and refuse to take a shell (read
> > > > > "pointless") one on an "if we ever ..." clause.
> > > > >
> > > > > Will you break backwards capability though? I'm not sure you will.
> > > > > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > > > > normal way. *If* you introduce an MFD driver at a later date then the
> > > > > old DTB will miss out the *new* functionality, which is expected and
> > > > > accepted.
> > > >
> > > > I'm a little confused by the simple-mfd approach. The only code I see in
> > > > linux-next for this is a single line that adds the "simple-mfd" string
> > > > to the OF device ID table in drivers/of/platform.c. As far as I can tell
> > > > this will merely cause child devices to be created. There won't be a
> > > > shared regmap and resources won't be set up properly either. Having a
> > > > proper MFD driver seems to be the only way to achieve what we need.
> > > >
> > > > The reason why every other simple-mfd users seems to get away with this
> > > > is because they also match on syscon and that sets up a regmap of its
> > > > own and the child device drivers use the syscon API to get at it. So I
> > > > don't see how we can make use of simple-mfd to achieve what we need,
> > > > unless we essentially copy what syscon does (but do proper resource
> > > > management while at it).
> > >
> > > If you have shared resources and your device isn't classed as a syscon
> > > device then yes, simple-mfd probably isn't suitable for this use-case.
> > > You might need to go into more detail with regards to "proper resource
> > > management", as I'm not entirely sure I agree.
> > >
> > > Still, this doesn't change the fact that, from what I've seen, I still
> > > don't think you need a dedicated MFD driver.
> > >
> > > What do you think of:
> > >
> > > usb-host@0,70090000 {
> > > compatible = "nvidia,tegra124-xhci";
> > > reg = <0x0 0x70090000 0x0 0x80CF>,
> > > <0x0 0x70098800 0x0 0x0800>,
> > > <0x0 0x70099000 0x0 0x1000>;
> > >
> > > /* Something from the datasheet */
> > > reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
> > >
> > > interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> > > ranges;
> > >
> > > xusb_mbox: mailbox {
> > > compatible = "nvidia,tegra124-xusb-mbox";
> > > reg = <0x0 0x700980e0 0x0 0x13>,
> > > <0x0 0x70098428 0x0 0x03>;
> > >
> > > /* Something from the datasheet */
> > > reg-names = "mbox-one", "mbox-two";
> > > interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> > > };
> > > };
> > >
> > > Then hvae the XHCI driver call of_platform_populate() as I proposed
> > > above?
> >
> > That's a little bonghits. It requires the drivers to jump through hoops
> > to properly manage register accesses (needs to differentiate on the base
> > depending on the register offset). So if you're going to NAK the MFD
> > approach I'd rather go a completely different route and keep only a top-
> > level node in DT here.
> >
> > One of the problems that the MFD design tries to solve is that the XHCI
> > controller needs a reference to the mailbox and the pad controller for a
> > PHY. The pad controller at the same time requires a reference to the
> > mailbox, so we have a circular dependency that we can only resolve by
> > introducing two separate devices, instantiated by some top-level entity.
> > For that reason I don't think your proposal is going to work either. The
> > circular dependency can't be broken because the XHCI driver will not be
> > able to of_platform_populate() before getting a PHY, and the PHY will
> > never show up until of_platform_populate() is called.
> >
> > So if this isn't going to be an MFD, then I think we should simply go
> > and instantiate platform devices from the XUSB driver directly. The
> > problem arising from that is that we have no place to put the top-level
> > driver. We could take it into drivers/soc/tegra, or perhaps even have it
> > in the XHCI driver.
> >
> > If we instantiate platform devices we can either set up the resources
> > such that we don't have to jump through hoops (I think the resource tree
> > will allow that) or set up a shared regmap. The latter might be the
> > easier way out, though it'd also be copying much of what MFD does, but
> > so be it if that's the only way we can get the matter settled.
>
> I understand the difficulties identified and empathise with your
> situation. I just can't bring myself to justify that a USB device
> which has it's own Mailbox is an MFD. If you take a look above, you
> can see some examples of other USB drivers registering sub-devices. I
> think you can make this work well for your setup.
Not using MFD I would say is completely justified. I think too many
devices try to get shoehorned into MFD when there really isn't a need
for it.
g.
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-06-30 18:22 ` Grant Likely
0 siblings, 0 replies; 136+ messages in thread
From: Grant Likely @ 2015-06-30 18:22 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 26 May 2015 16:18:54 +0100
, Lee Jones <lee.jones@linaro.org>
wrote:
> On Thu, 21 May 2015, Thierry Reding wrote:
>
> > On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> > > On Wed, 20 May 2015, Thierry Reding wrote:
> > > > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > > > <abrestic@chromium.org> wrote:
> > > > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > > > >>> >
> > > > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > > > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > > > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > > > > >>> >>
> > > > > > >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> > > > > > >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> > > > > > >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> > > > > > >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> > > > > > >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > > > > > >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> > > > > > >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > > > > >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> > > > > > >>> >> ---
> > > > > > >>> >> Changes from v7:
> > > > > > >>> >> - Move non-shared resources into child nodes.
> > > > > > >>> >> New for v7.
> > > > > > >>> >> ---
> > > > > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > > > > >>> >> 1 file changed, 37 insertions(+)
> > > > > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >>
> > > > > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >> new file mode 100644
> > > > > > >>> >> index 0000000..bc50110
> > > > > > >>> >> --- /dev/null
> > > > > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >> @@ -0,0 +1,37 @@
> > > > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > > > >>> >> +==============================
> > > > > > >>> >> +
> > > > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > > > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > > > > >>> >> +
> > > > > > >>> >> +Required properties:
> > > > > > >>> >> +--------------------
> > > > > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > > > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > > > > >>> >> + where <chip> is tegra132.
> > > > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > > > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > > > > >>> >> + mapping is 1:1.
> > > > > > >>> >> + - #address-cells: Must be 2.
> > > > > > >>> >> + - #size-cells: Must be 2.
> > > > > > >>> >> +
> > > > > > >>> >> +Example:
> > > > > > >>> >> +--------
> > > > > > >>> >> + usb at 0,70098000 {
> > > > > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > > > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > > > > >>> >> + ranges;
> > > > > > >>> >> +
> > > > > > >>> >> + #address-cells = <2>;
> > > > > > >>> >> + #size-cells = <2>;
> > > > > > >>> >> +
> > > > > > >>> >> + usb-host at 0,70090000 {
> > > > > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > > > > >>> >> + ...
> > > > > > >>> >> + };
> > > > > > >>> >> +
> > > > > > >>> >> + mailbox {
> > > > > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > > > > >>> >> + ...
> > > > > > >>> >> + };
> > > > > > >>> >
> > > > > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > > > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > > > > >>> > device to its Mailbox.
> > > > > > >>> >
> > > > > > >>> > usb at xyz {
> > > > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > > > >>> > };
> > > > > > >>> >
> > > > > > >>>
> > > > > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > > > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > > > > >>> Is this not the case?
> > > > > > >>
> > > > > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > > > > >> the memory map looks like, so I might provide a more appropriate
> > > > > > >> solution to accepting a pretty pointless MFD.
> > > > > > >
> > > > > > > FWIW, the address map for XUSB looks like this:
> > > > > > >
> > > > > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > > > > xHCI registers: 0x70090000 - 0x70098000
> > > > > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > > > > >
> > > > > > >> Two solutions spring to mind. You can either call
> > > > > > >> of_platform_populate() from the USB driver, as some already do:
> > > > > > >>
> > > > > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > > > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > > > > >> drivers/usb/dwc3/dwc3-st.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/musb/musb_am335x.c:
> > > > > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > > > > >
> > > > > > > This still requires a small, separate driver to setup the regmap and
> > > > > > > do of_platform_populate(). The only difference is it lives in
> > > > > > > drivers/usb/ instead of drivers/mfd/.
> > > > > > >
> > > > > > >> Or use the "simple-mfd", which is currently in -next:
> > > > > > >>
> > > > > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > > > > >
> > > > > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > > > > before. The issue here is that if we ever have to do something
> > > > > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > > > > binding and break DT backwards-compatibility.
> > > > > >
> > > > > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > > > > future-proof this binding/driver should it need to be extended in the
> > > > > > future. If this is a firm NAK from you however, I'll need to let
> > > > > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> > > > >
> > > > > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > > > > that you need an MFD driver for this and refuse to take a shell (read
> > > > > "pointless") one on an "if we ever ..." clause.
> > > > >
> > > > > Will you break backwards capability though? I'm not sure you will.
> > > > > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > > > > normal way. *If* you introduce an MFD driver at a later date then the
> > > > > old DTB will miss out the *new* functionality, which is expected and
> > > > > accepted.
> > > >
> > > > I'm a little confused by the simple-mfd approach. The only code I see in
> > > > linux-next for this is a single line that adds the "simple-mfd" string
> > > > to the OF device ID table in drivers/of/platform.c. As far as I can tell
> > > > this will merely cause child devices to be created. There won't be a
> > > > shared regmap and resources won't be set up properly either. Having a
> > > > proper MFD driver seems to be the only way to achieve what we need.
> > > >
> > > > The reason why every other simple-mfd users seems to get away with this
> > > > is because they also match on syscon and that sets up a regmap of its
> > > > own and the child device drivers use the syscon API to get at it. So I
> > > > don't see how we can make use of simple-mfd to achieve what we need,
> > > > unless we essentially copy what syscon does (but do proper resource
> > > > management while at it).
> > >
> > > If you have shared resources and your device isn't classed as a syscon
> > > device then yes, simple-mfd probably isn't suitable for this use-case.
> > > You might need to go into more detail with regards to "proper resource
> > > management", as I'm not entirely sure I agree.
> > >
> > > Still, this doesn't change the fact that, from what I've seen, I still
> > > don't think you need a dedicated MFD driver.
> > >
> > > What do you think of:
> > >
> > > usb-host at 0,70090000 {
> > > compatible = "nvidia,tegra124-xhci";
> > > reg = <0x0 0x70090000 0x0 0x80CF>,
> > > <0x0 0x70098800 0x0 0x0800>,
> > > <0x0 0x70099000 0x0 0x1000>;
> > >
> > > /* Something from the datasheet */
> > > reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
> > >
> > > interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> > > ranges;
> > >
> > > xusb_mbox: mailbox {
> > > compatible = "nvidia,tegra124-xusb-mbox";
> > > reg = <0x0 0x700980e0 0x0 0x13>,
> > > <0x0 0x70098428 0x0 0x03>;
> > >
> > > /* Something from the datasheet */
> > > reg-names = "mbox-one", "mbox-two";
> > > interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> > > };
> > > };
> > >
> > > Then hvae the XHCI driver call of_platform_populate() as I proposed
> > > above?
> >
> > That's a little bonghits. It requires the drivers to jump through hoops
> > to properly manage register accesses (needs to differentiate on the base
> > depending on the register offset). So if you're going to NAK the MFD
> > approach I'd rather go a completely different route and keep only a top-
> > level node in DT here.
> >
> > One of the problems that the MFD design tries to solve is that the XHCI
> > controller needs a reference to the mailbox and the pad controller for a
> > PHY. The pad controller at the same time requires a reference to the
> > mailbox, so we have a circular dependency that we can only resolve by
> > introducing two separate devices, instantiated by some top-level entity.
> > For that reason I don't think your proposal is going to work either. The
> > circular dependency can't be broken because the XHCI driver will not be
> > able to of_platform_populate() before getting a PHY, and the PHY will
> > never show up until of_platform_populate() is called.
> >
> > So if this isn't going to be an MFD, then I think we should simply go
> > and instantiate platform devices from the XUSB driver directly. The
> > problem arising from that is that we have no place to put the top-level
> > driver. We could take it into drivers/soc/tegra, or perhaps even have it
> > in the XHCI driver.
> >
> > If we instantiate platform devices we can either set up the resources
> > such that we don't have to jump through hoops (I think the resource tree
> > will allow that) or set up a shared regmap. The latter might be the
> > easier way out, though it'd also be copying much of what MFD does, but
> > so be it if that's the only way we can get the matter settled.
>
> I understand the difficulties identified and empathise with your
> situation. I just can't bring myself to justify that a USB device
> which has it's own Mailbox is an MFD. If you take a look above, you
> can see some examples of other USB drivers registering sub-devices. I
> think you can make this work well for your setup.
Not using MFD I would say is completely justified. I think too many
devices try to get shoehorned into MFD when there really isn't a need
for it.
g.
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB
@ 2015-06-30 18:22 ` Grant Likely
0 siblings, 0 replies; 136+ messages in thread
From: Grant Likely @ 2015-06-30 18:22 UTC (permalink / raw)
To: Lee Jones, Thierry Reding
Cc: Mark Rutland, Alexandre Courbot, Ian Campbell, linux-usb,
Samuel Ortiz, Pawel Moll, devicetree, Andrew Bresticker,
Stephen Warren, linux-kernel, Jon Hunter, Rob Herring,
Kumar Gala, linux-tegra, linux-arm-kernel
On Tue, 26 May 2015 16:18:54 +0100
, Lee Jones <lee.jones@linaro.org>
wrote:
> On Thu, 21 May 2015, Thierry Reding wrote:
>
> > On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> > > On Wed, 20 May 2015, Thierry Reding wrote:
> > > > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > > > <abrestic@chromium.org> wrote:
> > > > > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > > > > > >> On Thu, 14 May 2015, Jon Hunter wrote:
> > > > > > >>> On 13/05/15 15:39, Lee Jones wrote:
> > > > > > >>> > On Mon, 04 May 2015, Andrew Bresticker wrote:
> > > > > > >>> >
> > > > > > >>> >> Add a binding document for the XUSB host complex on NVIDIA Tegra124
> > > > > > >>> >> and later SoCs. The XUSB host complex includes a mailbox for
> > > > > > >>> >> communication with the XUSB micro-controller and an xHCI host-controller.
> > > > > > >>> >>
> > > > > > >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> > > > > > >>> >> Cc: Rob Herring <robh+dt@kernel.org>
> > > > > > >>> >> Cc: Pawel Moll <pawel.moll@arm.com>
> > > > > > >>> >> Cc: Mark Rutland <mark.rutland@arm.com>
> > > > > > >>> >> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> > > > > > >>> >> Cc: Kumar Gala <galak@codeaurora.org>
> > > > > > >>> >> Cc: Samuel Ortiz <sameo@linux.intel.com>
> > > > > > >>> >> Cc: Lee Jones <lee.jones@linaro.org>
> > > > > > >>> >> ---
> > > > > > >>> >> Changes from v7:
> > > > > > >>> >> - Move non-shared resources into child nodes.
> > > > > > >>> >> New for v7.
> > > > > > >>> >> ---
> > > > > > >>> >> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 ++++++++++++++++++++++
> > > > > > >>> >> 1 file changed, 37 insertions(+)
> > > > > > >>> >> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >>
> > > > > > >>> >> diff --git a/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >> new file mode 100644
> > > > > > >>> >> index 0000000..bc50110
> > > > > > >>> >> --- /dev/null
> > > > > > >>> >> +++ b/Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> > > > > > >>> >> @@ -0,0 +1,37 @@
> > > > > > >>> >> +NVIDIA Tegra XUSB host copmlex
> > > > > > >>> >> +==============================
> > > > > > >>> >> +
> > > > > > >>> >> +The XUSB host complex on Tegra124 and later SoCs contains an xHCI host
> > > > > > >>> >> +controller and a mailbox for communication with the XUSB micro-controller.
> > > > > > >>> >> +
> > > > > > >>> >> +Required properties:
> > > > > > >>> >> +--------------------
> > > > > > >>> >> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb".
> > > > > > >>> >> + Otherwise, must contain '"nvidia,<chip>-xusb", "nvidia,tegra124-xusb"'
> > > > > > >>> >> + where <chip> is tegra132.
> > > > > > >>> >> + - reg: Must contain the base and length of the XUSB FPCI registers.
> > > > > > >>> >> + - ranges: Bus address mapping for the XUSB block. Can be empty since the
> > > > > > >>> >> + mapping is 1:1.
> > > > > > >>> >> + - #address-cells: Must be 2.
> > > > > > >>> >> + - #size-cells: Must be 2.
> > > > > > >>> >> +
> > > > > > >>> >> +Example:
> > > > > > >>> >> +--------
> > > > > > >>> >> + usb@0,70098000 {
> > > > > > >>> >> + compatible = "nvidia,tegra124-xusb";
> > > > > > >>> >> + reg = <0x0 0x70098000 0x0 0x1000>;
> > > > > > >>> >> + ranges;
> > > > > > >>> >> +
> > > > > > >>> >> + #address-cells = <2>;
> > > > > > >>> >> + #size-cells = <2>;
> > > > > > >>> >> +
> > > > > > >>> >> + usb-host@0,70090000 {
> > > > > > >>> >> + compatible = "nvidia,tegra124-xhci";
> > > > > > >>> >> + ...
> > > > > > >>> >> + };
> > > > > > >>> >> +
> > > > > > >>> >> + mailbox {
> > > > > > >>> >> + compatible = "nvidia,tegra124-xusb-mbox";
> > > > > > >>> >> + ...
> > > > > > >>> >> + };
> > > > > > >>> >
> > > > > > >>> > This doesn't appear to be a proper MFD. I would have the USB and
> > > > > > >>> > Mailbox devices probe seperately and use a phandle to point the USB
> > > > > > >>> > device to its Mailbox.
> > > > > > >>> >
> > > > > > >>> > usb@xyz {
> > > > > > >>> > mboxes = <&xusb-mailbox, [chan]>;
> > > > > > >>> > };
> > > > > > >>> >
> > > > > > >>>
> > > > > > >>> I am assuming that Andrew had laid it out like this to reflect the hw
> > > > > > >>> structure. The mailbox and xhci controller are part of the xusb
> > > > > > >>> sub-system and hence appear as child nodes. My understanding is that for
> > > > > > >>> device-tree we want the device-tree structure to reflect the actual hw.
> > > > > > >>> Is this not the case?
> > > > > > >>
> > > > > > >> Yes, the DT files should reflect h/w. I have requested to see what
> > > > > > >> the memory map looks like, so I might provide a more appropriate
> > > > > > >> solution to accepting a pretty pointless MFD.
> > > > > > >
> > > > > > > FWIW, the address map for XUSB looks like this:
> > > > > > >
> > > > > > > XUSB_HOST: 0x70090000 - 0x7009a000
> > > > > > > xHCI registers: 0x70090000 - 0x70098000
> > > > > > > FPCI configuration registers: 0x70098000 - 0x70099000
> > > > > > > IPFS configuration registers: 0x70099000 - 0x7009a000
> > > > > > >
> > > > > > >> Two solutions spring to mind. You can either call
> > > > > > >> of_platform_populate() from the USB driver, as some already do:
> > > > > > >>
> > > > > > >> drivers/usb/dwc3/dwc3-exynos.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/dwc3/dwc3-keystone.c:
> > > > > > >> error = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/dwc3/dwc3-omap.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/dwc3/dwc3-qcom.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, qdwc->dev);
> > > > > > >> drivers/usb/dwc3/dwc3-st.c:
> > > > > > >> ret = of_platform_populate(node, NULL, NULL, dev);
> > > > > > >> drivers/usb/musb/musb_am335x.c:
> > > > > > >> ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> > > > > > >
> > > > > > > This still requires a small, separate driver to setup the regmap and
> > > > > > > do of_platform_populate(). The only difference is it lives in
> > > > > > > drivers/usb/ instead of drivers/mfd/.
> > > > > > >
> > > > > > >> Or use the "simple-mfd", which is currently in -next:
> > > > > > >>
> > > > > > >> git show next/master:Documentation/devicetree/bindings/mfd/mfd.txt
> > > > > > >
> > > > > > > I'm not too opposed to this, but Thierry was when I brought this up
> > > > > > > before. The issue here is that if we ever have to do something
> > > > > > > besides setting up a regmap in the MFD, we'd have to change the
> > > > > > > binding and break DT backwards-compatibility.
> > > > > >
> > > > > > Any thoughts on this? A minimal MFD seems to be the best way to
> > > > > > future-proof this binding/driver should it need to be extended in the
> > > > > > future. If this is a firm NAK from you however, I'll need to let
> > > > > > Jassi now so that he can un-queue the mailbox patches for 4.2....
> > > > >
> > > > > I was waiting to hear Thierry's thoughts. However, I am unconvinced
> > > > > that you need an MFD driver for this and refuse to take a shell (read
> > > > > "pointless") one on an "if we ever ..." clause.
> > > > >
> > > > > Will you break backwards capability though? I'm not sure you will.
> > > > > Old DTBs will still use 'simple-mfd' and probe the devices in the
> > > > > normal way. *If* you introduce an MFD driver at a later date then the
> > > > > old DTB will miss out the *new* functionality, which is expected and
> > > > > accepted.
> > > >
> > > > I'm a little confused by the simple-mfd approach. The only code I see in
> > > > linux-next for this is a single line that adds the "simple-mfd" string
> > > > to the OF device ID table in drivers/of/platform.c. As far as I can tell
> > > > this will merely cause child devices to be created. There won't be a
> > > > shared regmap and resources won't be set up properly either. Having a
> > > > proper MFD driver seems to be the only way to achieve what we need.
> > > >
> > > > The reason why every other simple-mfd users seems to get away with this
> > > > is because they also match on syscon and that sets up a regmap of its
> > > > own and the child device drivers use the syscon API to get at it. So I
> > > > don't see how we can make use of simple-mfd to achieve what we need,
> > > > unless we essentially copy what syscon does (but do proper resource
> > > > management while at it).
> > >
> > > If you have shared resources and your device isn't classed as a syscon
> > > device then yes, simple-mfd probably isn't suitable for this use-case.
> > > You might need to go into more detail with regards to "proper resource
> > > management", as I'm not entirely sure I agree.
> > >
> > > Still, this doesn't change the fact that, from what I've seen, I still
> > > don't think you need a dedicated MFD driver.
> > >
> > > What do you think of:
> > >
> > > usb-host@0,70090000 {
> > > compatible = "nvidia,tegra124-xhci";
> > > reg = <0x0 0x70090000 0x0 0x80CF>,
> > > <0x0 0x70098800 0x0 0x0800>,
> > > <0x0 0x70099000 0x0 0x1000>;
> > >
> > > /* Something from the datasheet */
> > > reg-names = "xhci-before-mbox", "xhci-after-mbox", "ipfs";
> > >
> > > interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
> > > ranges;
> > >
> > > xusb_mbox: mailbox {
> > > compatible = "nvidia,tegra124-xusb-mbox";
> > > reg = <0x0 0x700980e0 0x0 0x13>,
> > > <0x0 0x70098428 0x0 0x03>;
> > >
> > > /* Something from the datasheet */
> > > reg-names = "mbox-one", "mbox-two";
> > > interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
> > > };
> > > };
> > >
> > > Then hvae the XHCI driver call of_platform_populate() as I proposed
> > > above?
> >
> > That's a little bonghits. It requires the drivers to jump through hoops
> > to properly manage register accesses (needs to differentiate on the base
> > depending on the register offset). So if you're going to NAK the MFD
> > approach I'd rather go a completely different route and keep only a top-
> > level node in DT here.
> >
> > One of the problems that the MFD design tries to solve is that the XHCI
> > controller needs a reference to the mailbox and the pad controller for a
> > PHY. The pad controller at the same time requires a reference to the
> > mailbox, so we have a circular dependency that we can only resolve by
> > introducing two separate devices, instantiated by some top-level entity.
> > For that reason I don't think your proposal is going to work either. The
> > circular dependency can't be broken because the XHCI driver will not be
> > able to of_platform_populate() before getting a PHY, and the PHY will
> > never show up until of_platform_populate() is called.
> >
> > So if this isn't going to be an MFD, then I think we should simply go
> > and instantiate platform devices from the XUSB driver directly. The
> > problem arising from that is that we have no place to put the top-level
> > driver. We could take it into drivers/soc/tegra, or perhaps even have it
> > in the XHCI driver.
> >
> > If we instantiate platform devices we can either set up the resources
> > such that we don't have to jump through hoops (I think the resource tree
> > will allow that) or set up a shared regmap. The latter might be the
> > easier way out, though it'd also be copying much of what MFD does, but
> > so be it if that's the only way we can get the matter settled.
>
> I understand the difficulties identified and empathise with your
> situation. I just can't bring myself to justify that a USB device
> which has it's own Mailbox is an MFD. If you take a look above, you
> can see some examples of other USB drivers registering sub-devices. I
> think you can make this work well for your setup.
Not using MFD I would say is completely justified. I think too many
devices try to get shoehorned into MFD when there really isn't a need
for it.
g.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-04 17:36 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bresticker,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Jassi Brar
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.
Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Jassi Brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Changes from v7:
- Added back interrupts property.
Changes from v6:
- Removed reg/interrupts properties.
No changes from v3/v4/v5.
Changes from v2:
- Dropped channel specifier.
- Added pointer to mailbox documentation.
Changes from v1:
- Updated to use common mailbox bindings.
---
.../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt b/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
new file mode 100644
index 0000000..7eb72ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
@@ -0,0 +1,32 @@
+NVIDIA Tegra XUSB mailbox
+=========================
+
+The Tegra XUSB mailbox is used by the Tegra xHCI controller's firmware to
+communicate requests to the host and PHY drivers.
+
+Refer to ./mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+--------------------
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
+ Otherwise, must contain '"nvidia,<chip>-xusb-mbox",
+ "nvidia,tegra124-xusb-mbox"' where <chip> is tegra132.
+ - interrupts: Must contain the XUSB mailbox interrupt.
+ - #mbox-cells: Should be 0. There is only one physical channel.
+
+Example:
+--------
+ xusb_mbox: mailbox {
+ compatible = "nvidia,tegra124-xusb-mbox";
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+
+ #mbox-cells = <0>;
+ };
+
+ usb-host@0,70090000 {
+ ...
+ mboxes = <&xusb_mbox>;
+ mbox-names = "xusb";
+ ...
+ };
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: linux-arm-kernel
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
---
Changes from v7:
- Added back interrupts property.
Changes from v6:
- Removed reg/interrupts properties.
No changes from v3/v4/v5.
Changes from v2:
- Dropped channel specifier.
- Added pointer to mailbox documentation.
Changes from v1:
- Updated to use common mailbox bindings.
---
.../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt b/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
new file mode 100644
index 0000000..7eb72ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
@@ -0,0 +1,32 @@
+NVIDIA Tegra XUSB mailbox
+=========================
+
+The Tegra XUSB mailbox is used by the Tegra xHCI controller's firmware to
+communicate requests to the host and PHY drivers.
+
+Refer to ./mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+--------------------
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
+ Otherwise, must contain '"nvidia,<chip>-xusb-mbox",
+ "nvidia,tegra124-xusb-mbox"' where <chip> is tegra132.
+ - interrupts: Must contain the XUSB mailbox interrupt.
+ - #mbox-cells: Should be 0. There is only one physical channel.
+
+Example:
+--------
+ xusb_mbox: mailbox {
+ compatible = "nvidia,tegra124-xusb-mbox";
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+
+ #mbox-cells = <0>;
+ };
+
+ usb-host at 0,70090000 {
+ ...
+ mboxes = <&xusb_mbox>;
+ mbox-names = "xusb";
+ ...
+ };
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Andrew Bresticker, Jon Hunter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Jassi Brar
Add device-tree bindings for the Tegra XUSB mailbox which will be used
for communication between the Tegra xHCI controller's firmware and the
host processor.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
---
Changes from v7:
- Added back interrupts property.
Changes from v6:
- Removed reg/interrupts properties.
No changes from v3/v4/v5.
Changes from v2:
- Dropped channel specifier.
- Added pointer to mailbox documentation.
Changes from v1:
- Updated to use common mailbox bindings.
---
.../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt b/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
new file mode 100644
index 0000000..7eb72ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
@@ -0,0 +1,32 @@
+NVIDIA Tegra XUSB mailbox
+=========================
+
+The Tegra XUSB mailbox is used by the Tegra xHCI controller's firmware to
+communicate requests to the host and PHY drivers.
+
+Refer to ./mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Required properties:
+--------------------
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
+ Otherwise, must contain '"nvidia,<chip>-xusb-mbox",
+ "nvidia,tegra124-xusb-mbox"' where <chip> is tegra132.
+ - interrupts: Must contain the XUSB mailbox interrupt.
+ - #mbox-cells: Should be 0. There is only one physical channel.
+
+Example:
+--------
+ xusb_mbox: mailbox {
+ compatible = "nvidia,tegra124-xusb-mbox";
+ interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+
+ #mbox-cells = <0>;
+ };
+
+ usb-host@0,70090000 {
+ ...
+ mboxes = <&xusb_mbox>;
+ mbox-names = "xusb";
+ ...
+ };
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread[parent not found: <1430761002-9327-7-git-send-email-abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]
* Re: [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-08 20:42 ` Benson Leung
-1 siblings, 0 replies; 136+ messages in thread
From: Benson Leung @ 2015-05-08 20:42 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jon Hunter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Jassi Brar
On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
<abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
> + Otherwise, must contain '"nvidia,<chip>-xusb-mbox",
> + "nvidia,tegra124-xusb-mbox"' where <chip> is tegra132.
The driver doesn't seem to have any particular entry for tegra132, so
that would be a bad example.
--
Benson Leung
Software Engineer, Chrom* OS
bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
@ 2015-05-08 20:42 ` Benson Leung
0 siblings, 0 replies; 136+ messages in thread
From: Benson Leung @ 2015-05-08 20:42 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
<abrestic@chromium.org> wrote:
> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
> + Otherwise, must contain '"nvidia,<chip>-xusb-mbox",
> + "nvidia,tegra124-xusb-mbox"' where <chip> is tegra132.
The driver doesn't seem to have any particular entry for tegra132, so
that would be a bad example.
--
Benson Leung
Software Engineer, Chrom* OS
bleung at chromium.org
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
@ 2015-05-08 20:42 ` Benson Leung
0 siblings, 0 replies; 136+ messages in thread
From: Benson Leung @ 2015-05-08 20:42 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Jassi Brar
On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
<abrestic@chromium.org> wrote:
> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
> + Otherwise, must contain '"nvidia,<chip>-xusb-mbox",
> + "nvidia,tegra124-xusb-mbox"' where <chip> is tegra132.
The driver doesn't seem to have any particular entry for tegra132, so
that would be a bad example.
--
Benson Leung
Software Engineer, Chrom* OS
bleung@chromium.org
^ permalink raw reply [flat|nested] 136+ messages in thread
[parent not found: <CANLzEksWtzSmz=OCuwVdY5RSG6gDrOoMyGsW3i9jMcjD3WtPKQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
2015-05-08 20:42 ` Benson Leung
(?)
@ 2015-05-08 20:53 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-08 20:53 UTC (permalink / raw)
To: Benson Leung
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jon Hunter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Jassi Brar
On Fri, May 8, 2015 at 1:42 PM, Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
> <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
>> + Otherwise, must contain '"nvidia,<chip>-xusb-mbox",
>> + "nvidia,tegra124-xusb-mbox"' where <chip> is tegra132.
>
> The driver doesn't seem to have any particular entry for tegra132, so
> that would be a bad example.
The convention on Tegra is to use "nvidia,<chip>-<ip>" for each IP
block. Additionally, since the XUSB-related blocks on Tegra132 are
identical to Tegra124, these devices on Tegra132 are 'compatible' with
their Tegra124 variants.
For some context, see Paul's comments in commit 193c9d23
("Documentation: DT bindings: add more Tegra chip compatible
strings").
Thanks,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
@ 2015-05-08 20:53 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-08 20:53 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 8, 2015 at 1:42 PM, Benson Leung <bleung@chromium.org> wrote:
> On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
> <abrestic@chromium.org> wrote:
>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
>> + Otherwise, must contain '"nvidia,<chip>-xusb-mbox",
>> + "nvidia,tegra124-xusb-mbox"' where <chip> is tegra132.
>
> The driver doesn't seem to have any particular entry for tegra132, so
> that would be a bad example.
The convention on Tegra is to use "nvidia,<chip>-<ip>" for each IP
block. Additionally, since the XUSB-related blocks on Tegra132 are
identical to Tegra124, these devices on Tegra132 are 'compatible' with
their Tegra124 variants.
For some context, see Paul's comments in commit 193c9d23
("Documentation: DT bindings: add more Tegra chip compatible
strings").
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
@ 2015-05-08 20:53 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-08 20:53 UTC (permalink / raw)
To: Benson Leung
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Jassi Brar
On Fri, May 8, 2015 at 1:42 PM, Benson Leung <bleung@chromium.org> wrote:
> On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
> <abrestic@chromium.org> wrote:
>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
>> + Otherwise, must contain '"nvidia,<chip>-xusb-mbox",
>> + "nvidia,tegra124-xusb-mbox"' where <chip> is tegra132.
>
> The driver doesn't seem to have any particular entry for tegra132, so
> that would be a bad example.
The convention on Tegra is to use "nvidia,<chip>-<ip>" for each IP
block. Additionally, since the XUSB-related blocks on Tegra132 are
identical to Tegra124, these devices on Tegra132 are 'compatible' with
their Tegra124 variants.
For some context, see Paul's comments in commit 193c9d23
("Documentation: DT bindings: add more Tegra chip compatible
strings").
Thanks,
Andrew
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
2015-05-08 20:53 ` Andrew Bresticker
(?)
@ 2015-05-08 21:03 ` Benson Leung
-1 siblings, 0 replies; 136+ messages in thread
From: Benson Leung @ 2015-05-08 21:03 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Jassi Brar
On Fri, May 8, 2015 at 1:53 PM, Andrew Bresticker <abrestic@chromium.org> wrote:
>
> The convention on Tegra is to use "nvidia,<chip>-<ip>" for each IP
> block. Additionally, since the XUSB-related blocks on Tegra132 are
> identical to Tegra124, these devices on Tegra132 are 'compatible' with
> their Tegra124 variants.
>
> For some context, see Paul's comments in commit 193c9d23
> ("Documentation: DT bindings: add more Tegra chip compatible
> strings").
Ah, understood. Thanks for the clarification!
Reviewed-by: Benson Leung <bleung@chromium.org>
--
Benson Leung
Software Engineer, Chrom* OS
bleung@chromium.org
^ permalink raw reply [flat|nested] 136+ messages in thread* [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
@ 2015-05-08 21:03 ` Benson Leung
0 siblings, 0 replies; 136+ messages in thread
From: Benson Leung @ 2015-05-08 21:03 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 8, 2015 at 1:53 PM, Andrew Bresticker <abrestic@chromium.org> wrote:
>
> The convention on Tegra is to use "nvidia,<chip>-<ip>" for each IP
> block. Additionally, since the XUSB-related blocks on Tegra132 are
> identical to Tegra124, these devices on Tegra132 are 'compatible' with
> their Tegra124 variants.
>
> For some context, see Paul's comments in commit 193c9d23
> ("Documentation: DT bindings: add more Tegra chip compatible
> strings").
Ah, understood. Thanks for the clarification!
Reviewed-by: Benson Leung <bleung@chromium.org>
--
Benson Leung
Software Engineer, Chrom* OS
bleung at chromium.org
^ permalink raw reply [flat|nested] 136+ messages in thread* Re: [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding
@ 2015-05-08 21:03 ` Benson Leung
0 siblings, 0 replies; 136+ messages in thread
From: Benson Leung @ 2015-05-08 21:03 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot, devicetree,
linux-tegra, linux-usb, linux-arm-kernel, linux-kernel,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Jassi Brar
On Fri, May 8, 2015 at 1:53 PM, Andrew Bresticker <abrestic@chromium.org> wrote:
>
> The convention on Tegra is to use "nvidia,<chip>-<ip>" for each IP
> block. Additionally, since the XUSB-related blocks on Tegra132 are
> identical to Tegra124, these devices on Tegra132 are 'compatible' with
> their Tegra124 variants.
>
> For some context, see Paul's comments in commit 193c9d23
> ("Documentation: DT bindings: add more Tegra chip compatible
> strings").
Ah, understood. Thanks for the clarification!
Reviewed-by: Benson Leung <bleung@chromium.org>
--
Benson Leung
Software Engineer, Chrom* OS
bleung@chromium.org
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v8 7/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-04 17:36 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bresticker,
Jon Hunter, Jassi Brar
The Tegra xHCI controller's firmware communicates requests to the host
processor through a mailbox interface. While there is only a single
physical channel, messages sent by the controller can be divided
into two groups: those intended for the PHY driver and those intended
for the host-controller driver. The requesting driver is assigned
one of two virtual channels when the single physical channel is
requested. All incoming messages are sent to both virtual channels.
Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Jassi Brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Changes from v7:
- Don't reset ownership of mailbox for messages which require ACK/NAK.
- Synchronize and free IRQ before unregistering controller.
Changes from v6:
- Access FPCI registers using parent MFD's regmap.
Changes from v5:
- Poll for TX completion using MBOX_OWNER field.
Changes from v4:
- Use chan->cl to indicate channel allocation status
- Addressed review comments from Thierry
No changes from v3.
Changes from v2:
- Fixed mailbox IRQ vs. channel alloc/free race.
- Renamed defines to match TRM.
- Dropped channel specifier and instead allocated virtual channels as they
were requested.
- Removed MODULE_ALIAS.
Changes from v1:
- Converted to common mailbox framework.
- Removed useless polling sequences in TX path.
- Moved xusb include from linux/ to soc/tegra/
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/tegra-xusb-mailbox.c | 290 +++++++++++++++++++++++++++++++++++
include/soc/tegra/xusb.h | 43 ++++++
4 files changed, 343 insertions(+)
create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
create mode 100644 include/soc/tegra/xusb.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 84b0a2d..37da641 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -60,4 +60,12 @@ config ALTERA_MBOX
An implementation of the Altera Mailbox soft core. It is used
to send message between processors. Say Y here if you want to use the
Altera mailbox support.
+
+config TEGRA_XUSB_MBOX
+ tristate "NVIDIA Tegra XUSB Mailbox"
+ depends on MFD_TEGRA_XUSB
+ help
+ Mailbox driver for the XUSB complex found on NVIDIA Tegra124 and
+ later SoCs. The XUSB mailbox is used to communicate between the
+ XUSB microcontroller and the host processor.
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index b18201e..d77012a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_OMAP2PLUS_MBOX) += omap-mailbox.o
obj-$(CONFIG_PCC) += pcc.o
obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o
+
+obj-$(CONFIG_TEGRA_XUSB_MBOX) += tegra-xusb-mailbox.o
diff --git a/drivers/mailbox/tegra-xusb-mailbox.c b/drivers/mailbox/tegra-xusb-mailbox.c
new file mode 100644
index 0000000..4e2477d
--- /dev/null
+++ b/drivers/mailbox/tegra-xusb-mailbox.c
@@ -0,0 +1,290 @@
+/*
+ * NVIDIA Tegra XUSB mailbox driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#include <soc/tegra/xusb.h>
+
+#define XUSB_MBOX_NUM_CHANS 2 /* Host + PHY */
+
+#define XUSB_CFG_ARU_MBOX_CMD 0xe4
+#define MBOX_DEST_FALC BIT(27)
+#define MBOX_DEST_PME BIT(28)
+#define MBOX_DEST_SMI BIT(29)
+#define MBOX_DEST_XHCI BIT(30)
+#define MBOX_INT_EN BIT(31)
+#define XUSB_CFG_ARU_MBOX_DATA_IN 0xe8
+#define CMD_DATA_SHIFT 0
+#define CMD_DATA_MASK 0xffffff
+#define CMD_TYPE_SHIFT 24
+#define CMD_TYPE_MASK 0xff
+#define XUSB_CFG_ARU_MBOX_DATA_OUT 0xec
+#define XUSB_CFG_ARU_MBOX_OWNER 0xf0
+#define MBOX_OWNER_NONE 0
+#define MBOX_OWNER_FW 1
+#define MBOX_OWNER_SW 2
+#define XUSB_CFG_ARU_SMI_INTR 0x428
+#define MBOX_SMI_INTR_FW_HANG BIT(1)
+#define MBOX_SMI_INTR_EN BIT(3)
+
+struct tegra_xusb_mbox {
+ struct mbox_controller mbox;
+ struct regmap *fpci_regs;
+ spinlock_t lock;
+ int irq;
+};
+
+static inline u32 mbox_readl(struct tegra_xusb_mbox *mbox, unsigned long offset)
+{
+ u32 val;
+
+ regmap_read(mbox->fpci_regs, offset, &val);
+
+ return val;
+}
+
+static inline void mbox_writel(struct tegra_xusb_mbox *mbox, u32 val,
+ unsigned long offset)
+{
+ regmap_write(mbox->fpci_regs, offset, val);
+}
+
+static inline struct tegra_xusb_mbox *to_tegra_mbox(struct mbox_controller *c)
+{
+ return container_of(c, struct tegra_xusb_mbox, mbox);
+}
+
+static inline u32 mbox_pack_msg(struct tegra_xusb_mbox_msg *msg)
+{
+ u32 val;
+
+ val = (msg->cmd & CMD_TYPE_MASK) << CMD_TYPE_SHIFT;
+ val |= (msg->data & CMD_DATA_MASK) << CMD_DATA_SHIFT;
+
+ return val;
+}
+
+static inline void mbox_unpack_msg(u32 val, struct tegra_xusb_mbox_msg *msg)
+{
+ msg->cmd = (val >> CMD_TYPE_SHIFT) & CMD_TYPE_MASK;
+ msg->data = (val >> CMD_DATA_SHIFT) & CMD_DATA_MASK;
+}
+
+static bool mbox_cmd_requires_ack(enum tegra_xusb_mbox_cmd cmd)
+{
+ switch (cmd) {
+ case MBOX_CMD_SET_BW:
+ case MBOX_CMD_ACK:
+ case MBOX_CMD_NAK:
+ return false;
+ default:
+ return true;
+ }
+}
+
+static int tegra_xusb_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct tegra_xusb_mbox *mbox = to_tegra_mbox(chan->mbox);
+ struct tegra_xusb_mbox_msg *msg = data;
+ unsigned long flags;
+ u32 reg;
+
+ dev_dbg(mbox->mbox.dev, "TX message %#x:%#x\n", msg->cmd, msg->data);
+
+ spin_lock_irqsave(&mbox->lock, flags);
+ /*
+ * Acquire the mailbox. The firmware still owns the mailbox for
+ * ACK/NAK messages.
+ */
+ if (!(msg->cmd == MBOX_CMD_ACK || msg->cmd == MBOX_CMD_NAK)) {
+ if (mbox_readl(mbox, XUSB_CFG_ARU_MBOX_OWNER) !=
+ MBOX_OWNER_NONE) {
+ dev_err(mbox->mbox.dev, "Mailbox not idle\n");
+ goto busy;
+ }
+
+ mbox_writel(mbox, MBOX_OWNER_SW, XUSB_CFG_ARU_MBOX_OWNER);
+ if (mbox_readl(mbox, XUSB_CFG_ARU_MBOX_OWNER) !=
+ MBOX_OWNER_SW) {
+ dev_err(mbox->mbox.dev, "Failed to acquire mailbox");
+ goto busy;
+ }
+ }
+
+ mbox_writel(mbox, mbox_pack_msg(msg), XUSB_CFG_ARU_MBOX_DATA_IN);
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_CMD);
+ reg |= MBOX_INT_EN | MBOX_DEST_FALC;
+ mbox_writel(mbox, reg, XUSB_CFG_ARU_MBOX_CMD);
+
+ spin_unlock_irqrestore(&mbox->lock, flags);
+
+ return 0;
+busy:
+ spin_unlock_irqrestore(&mbox->lock, flags);
+ return -EBUSY;
+}
+
+static int tegra_xusb_mbox_startup(struct mbox_chan *chan)
+{
+ return 0;
+}
+
+static void tegra_xusb_mbox_shutdown(struct mbox_chan *chan)
+{
+}
+
+static bool tegra_xusb_mbox_last_tx_done(struct mbox_chan *chan)
+{
+ struct tegra_xusb_mbox *mbox = to_tegra_mbox(chan->mbox);
+
+ return mbox_readl(mbox, XUSB_CFG_ARU_MBOX_OWNER) == MBOX_OWNER_NONE;
+}
+
+static const struct mbox_chan_ops tegra_xusb_mbox_chan_ops = {
+ .send_data = tegra_xusb_mbox_send_data,
+ .startup = tegra_xusb_mbox_startup,
+ .shutdown = tegra_xusb_mbox_shutdown,
+ .last_tx_done = tegra_xusb_mbox_last_tx_done,
+};
+
+static irqreturn_t tegra_xusb_mbox_irq(int irq, void *p)
+{
+ struct tegra_xusb_mbox *mbox = p;
+ struct tegra_xusb_mbox_msg msg;
+ unsigned int i;
+ u32 reg;
+
+ spin_lock(&mbox->lock);
+
+ /* Clear mbox interrupts */
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_SMI_INTR);
+ if (reg & MBOX_SMI_INTR_FW_HANG)
+ dev_err(mbox->mbox.dev, "Controller firmware hang\n");
+ mbox_writel(mbox, reg, XUSB_CFG_ARU_SMI_INTR);
+
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_DATA_OUT);
+ mbox_unpack_msg(reg, &msg);
+
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_CMD);
+ reg &= ~MBOX_DEST_SMI;
+ mbox_writel(mbox, reg, XUSB_CFG_ARU_MBOX_CMD);
+
+ /* Clear mailbox owner if no ACK/NAK is required. */
+ if (!mbox_cmd_requires_ack(msg.cmd))
+ mbox_writel(mbox, MBOX_OWNER_NONE, XUSB_CFG_ARU_MBOX_OWNER);
+
+ dev_dbg(mbox->mbox.dev, "RX message %#x:%#x\n", msg.cmd, msg.data);
+ for (i = 0; i < XUSB_MBOX_NUM_CHANS; i++) {
+ if (mbox->mbox.chans[i].cl)
+ mbox_chan_received_data(&mbox->mbox.chans[i], &msg);
+ }
+
+ spin_unlock(&mbox->lock);
+
+ return IRQ_HANDLED;
+}
+
+static struct mbox_chan *tegra_xusb_mbox_of_xlate(struct mbox_controller *ctlr,
+ const struct of_phandle_args *sp)
+{
+ struct tegra_xusb_mbox *mbox = to_tegra_mbox(ctlr);
+ struct mbox_chan *chan = ERR_PTR(-EINVAL);
+ unsigned long flags;
+ unsigned int i;
+
+ /* Pick the first available (virtual) channel. */
+ spin_lock_irqsave(&mbox->lock, flags);
+ for (i = 0; XUSB_MBOX_NUM_CHANS; i++) {
+ if (!ctlr->chans[i].cl) {
+ chan = &ctlr->chans[i];
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&mbox->lock, flags);
+
+ return chan;
+}
+
+static const struct of_device_id tegra_xusb_mbox_of_match[] = {
+ { .compatible = "nvidia,tegra124-xusb-mbox" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tegra_xusb_mbox_of_match);
+
+static int tegra_xusb_mbox_probe(struct platform_device *pdev)
+{
+ struct tegra_xusb_mbox *mbox;
+ int ret;
+
+ mbox = devm_kzalloc(&pdev->dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, mbox);
+ spin_lock_init(&mbox->lock);
+ mbox->fpci_regs = dev_get_drvdata(pdev->dev.parent);
+
+ mbox->mbox.dev = &pdev->dev;
+ mbox->mbox.chans = devm_kcalloc(&pdev->dev, XUSB_MBOX_NUM_CHANS,
+ sizeof(*mbox->mbox.chans), GFP_KERNEL);
+ if (!mbox->mbox.chans)
+ return -ENOMEM;
+ mbox->mbox.num_chans = XUSB_MBOX_NUM_CHANS;
+ mbox->mbox.ops = &tegra_xusb_mbox_chan_ops;
+ mbox->mbox.txdone_poll = true;
+ mbox->mbox.txpoll_period = 1;
+ mbox->mbox.of_xlate = tegra_xusb_mbox_of_xlate;
+
+ mbox->irq = platform_get_irq(pdev, 0);
+ if (mbox->irq < 0)
+ return mbox->irq;
+ ret = devm_request_irq(&pdev->dev, mbox->irq, tegra_xusb_mbox_irq, 0,
+ dev_name(&pdev->dev), mbox);
+ if (ret < 0)
+ return ret;
+
+ ret = mbox_controller_register(&mbox->mbox);
+ if (ret < 0)
+ dev_err(&pdev->dev, "failed to register mailbox: %d\n", ret);
+
+ return ret;
+}
+
+static int tegra_xusb_mbox_remove(struct platform_device *pdev)
+{
+ struct tegra_xusb_mbox *mbox = platform_get_drvdata(pdev);
+
+ synchronize_irq(mbox->irq);
+ devm_free_irq(&pdev->dev, mbox->irq, mbox);
+ mbox_controller_unregister(&mbox->mbox);
+
+ return 0;
+}
+
+static struct platform_driver tegra_xusb_mbox_driver = {
+ .probe = tegra_xusb_mbox_probe,
+ .remove = tegra_xusb_mbox_remove,
+ .driver = {
+ .name = "tegra-xusb-mbox",
+ .of_match_table = tegra_xusb_mbox_of_match,
+ },
+};
+module_platform_driver(tegra_xusb_mbox_driver);
+
+MODULE_AUTHOR("Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>");
+MODULE_DESCRIPTION("NVIDIA Tegra XUSB mailbox driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/soc/tegra/xusb.h b/include/soc/tegra/xusb.h
new file mode 100644
index 0000000..5ce5e12
--- /dev/null
+++ b/include/soc/tegra/xusb.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef __SOC_TEGRA_XUSB_H__
+#define __SOC_TEGRA_XUSB_H__
+
+/* Command requests from the firmware */
+enum tegra_xusb_mbox_cmd {
+ MBOX_CMD_MSG_ENABLED = 1,
+ MBOX_CMD_INC_FALC_CLOCK,
+ MBOX_CMD_DEC_FALC_CLOCK,
+ MBOX_CMD_INC_SSPI_CLOCK,
+ MBOX_CMD_DEC_SSPI_CLOCK,
+ MBOX_CMD_SET_BW, /* no ACK/NAK required */
+ MBOX_CMD_SET_SS_PWR_GATING,
+ MBOX_CMD_SET_SS_PWR_UNGATING,
+ MBOX_CMD_SAVE_DFE_CTLE_CTX,
+ MBOX_CMD_AIRPLANE_MODE_ENABLED, /* unused */
+ MBOX_CMD_AIRPLANE_MODE_DISABLED, /* unused */
+ MBOX_CMD_START_HSIC_IDLE,
+ MBOX_CMD_STOP_HSIC_IDLE,
+ MBOX_CMD_DBC_WAKE_STACK, /* unused */
+ MBOX_CMD_HSIC_PRETEND_CONNECT,
+
+ MBOX_CMD_MAX,
+
+ /* Response message to above commands */
+ MBOX_CMD_ACK = 128,
+ MBOX_CMD_NAK
+};
+
+struct tegra_xusb_mbox_msg {
+ u32 cmd;
+ u32 data;
+};
+
+#endif /* __SOC_TEGRA_XUSB_H__ */
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 7/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: linux-arm-kernel
The Tegra xHCI controller's firmware communicates requests to the host
processor through a mailbox interface. While there is only a single
physical channel, messages sent by the controller can be divided
into two groups: those intended for the PHY driver and those intended
for the host-controller driver. The requesting driver is assigned
one of two virtual channels when the single physical channel is
requested. All incoming messages are sent to both virtual channels.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
---
Changes from v7:
- Don't reset ownership of mailbox for messages which require ACK/NAK.
- Synchronize and free IRQ before unregistering controller.
Changes from v6:
- Access FPCI registers using parent MFD's regmap.
Changes from v5:
- Poll for TX completion using MBOX_OWNER field.
Changes from v4:
- Use chan->cl to indicate channel allocation status
- Addressed review comments from Thierry
No changes from v3.
Changes from v2:
- Fixed mailbox IRQ vs. channel alloc/free race.
- Renamed defines to match TRM.
- Dropped channel specifier and instead allocated virtual channels as they
were requested.
- Removed MODULE_ALIAS.
Changes from v1:
- Converted to common mailbox framework.
- Removed useless polling sequences in TX path.
- Moved xusb include from linux/ to soc/tegra/
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/tegra-xusb-mailbox.c | 290 +++++++++++++++++++++++++++++++++++
include/soc/tegra/xusb.h | 43 ++++++
4 files changed, 343 insertions(+)
create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
create mode 100644 include/soc/tegra/xusb.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 84b0a2d..37da641 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -60,4 +60,12 @@ config ALTERA_MBOX
An implementation of the Altera Mailbox soft core. It is used
to send message between processors. Say Y here if you want to use the
Altera mailbox support.
+
+config TEGRA_XUSB_MBOX
+ tristate "NVIDIA Tegra XUSB Mailbox"
+ depends on MFD_TEGRA_XUSB
+ help
+ Mailbox driver for the XUSB complex found on NVIDIA Tegra124 and
+ later SoCs. The XUSB mailbox is used to communicate between the
+ XUSB microcontroller and the host processor.
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index b18201e..d77012a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_OMAP2PLUS_MBOX) += omap-mailbox.o
obj-$(CONFIG_PCC) += pcc.o
obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o
+
+obj-$(CONFIG_TEGRA_XUSB_MBOX) += tegra-xusb-mailbox.o
diff --git a/drivers/mailbox/tegra-xusb-mailbox.c b/drivers/mailbox/tegra-xusb-mailbox.c
new file mode 100644
index 0000000..4e2477d
--- /dev/null
+++ b/drivers/mailbox/tegra-xusb-mailbox.c
@@ -0,0 +1,290 @@
+/*
+ * NVIDIA Tegra XUSB mailbox driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#include <soc/tegra/xusb.h>
+
+#define XUSB_MBOX_NUM_CHANS 2 /* Host + PHY */
+
+#define XUSB_CFG_ARU_MBOX_CMD 0xe4
+#define MBOX_DEST_FALC BIT(27)
+#define MBOX_DEST_PME BIT(28)
+#define MBOX_DEST_SMI BIT(29)
+#define MBOX_DEST_XHCI BIT(30)
+#define MBOX_INT_EN BIT(31)
+#define XUSB_CFG_ARU_MBOX_DATA_IN 0xe8
+#define CMD_DATA_SHIFT 0
+#define CMD_DATA_MASK 0xffffff
+#define CMD_TYPE_SHIFT 24
+#define CMD_TYPE_MASK 0xff
+#define XUSB_CFG_ARU_MBOX_DATA_OUT 0xec
+#define XUSB_CFG_ARU_MBOX_OWNER 0xf0
+#define MBOX_OWNER_NONE 0
+#define MBOX_OWNER_FW 1
+#define MBOX_OWNER_SW 2
+#define XUSB_CFG_ARU_SMI_INTR 0x428
+#define MBOX_SMI_INTR_FW_HANG BIT(1)
+#define MBOX_SMI_INTR_EN BIT(3)
+
+struct tegra_xusb_mbox {
+ struct mbox_controller mbox;
+ struct regmap *fpci_regs;
+ spinlock_t lock;
+ int irq;
+};
+
+static inline u32 mbox_readl(struct tegra_xusb_mbox *mbox, unsigned long offset)
+{
+ u32 val;
+
+ regmap_read(mbox->fpci_regs, offset, &val);
+
+ return val;
+}
+
+static inline void mbox_writel(struct tegra_xusb_mbox *mbox, u32 val,
+ unsigned long offset)
+{
+ regmap_write(mbox->fpci_regs, offset, val);
+}
+
+static inline struct tegra_xusb_mbox *to_tegra_mbox(struct mbox_controller *c)
+{
+ return container_of(c, struct tegra_xusb_mbox, mbox);
+}
+
+static inline u32 mbox_pack_msg(struct tegra_xusb_mbox_msg *msg)
+{
+ u32 val;
+
+ val = (msg->cmd & CMD_TYPE_MASK) << CMD_TYPE_SHIFT;
+ val |= (msg->data & CMD_DATA_MASK) << CMD_DATA_SHIFT;
+
+ return val;
+}
+
+static inline void mbox_unpack_msg(u32 val, struct tegra_xusb_mbox_msg *msg)
+{
+ msg->cmd = (val >> CMD_TYPE_SHIFT) & CMD_TYPE_MASK;
+ msg->data = (val >> CMD_DATA_SHIFT) & CMD_DATA_MASK;
+}
+
+static bool mbox_cmd_requires_ack(enum tegra_xusb_mbox_cmd cmd)
+{
+ switch (cmd) {
+ case MBOX_CMD_SET_BW:
+ case MBOX_CMD_ACK:
+ case MBOX_CMD_NAK:
+ return false;
+ default:
+ return true;
+ }
+}
+
+static int tegra_xusb_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct tegra_xusb_mbox *mbox = to_tegra_mbox(chan->mbox);
+ struct tegra_xusb_mbox_msg *msg = data;
+ unsigned long flags;
+ u32 reg;
+
+ dev_dbg(mbox->mbox.dev, "TX message %#x:%#x\n", msg->cmd, msg->data);
+
+ spin_lock_irqsave(&mbox->lock, flags);
+ /*
+ * Acquire the mailbox. The firmware still owns the mailbox for
+ * ACK/NAK messages.
+ */
+ if (!(msg->cmd == MBOX_CMD_ACK || msg->cmd == MBOX_CMD_NAK)) {
+ if (mbox_readl(mbox, XUSB_CFG_ARU_MBOX_OWNER) !=
+ MBOX_OWNER_NONE) {
+ dev_err(mbox->mbox.dev, "Mailbox not idle\n");
+ goto busy;
+ }
+
+ mbox_writel(mbox, MBOX_OWNER_SW, XUSB_CFG_ARU_MBOX_OWNER);
+ if (mbox_readl(mbox, XUSB_CFG_ARU_MBOX_OWNER) !=
+ MBOX_OWNER_SW) {
+ dev_err(mbox->mbox.dev, "Failed to acquire mailbox");
+ goto busy;
+ }
+ }
+
+ mbox_writel(mbox, mbox_pack_msg(msg), XUSB_CFG_ARU_MBOX_DATA_IN);
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_CMD);
+ reg |= MBOX_INT_EN | MBOX_DEST_FALC;
+ mbox_writel(mbox, reg, XUSB_CFG_ARU_MBOX_CMD);
+
+ spin_unlock_irqrestore(&mbox->lock, flags);
+
+ return 0;
+busy:
+ spin_unlock_irqrestore(&mbox->lock, flags);
+ return -EBUSY;
+}
+
+static int tegra_xusb_mbox_startup(struct mbox_chan *chan)
+{
+ return 0;
+}
+
+static void tegra_xusb_mbox_shutdown(struct mbox_chan *chan)
+{
+}
+
+static bool tegra_xusb_mbox_last_tx_done(struct mbox_chan *chan)
+{
+ struct tegra_xusb_mbox *mbox = to_tegra_mbox(chan->mbox);
+
+ return mbox_readl(mbox, XUSB_CFG_ARU_MBOX_OWNER) == MBOX_OWNER_NONE;
+}
+
+static const struct mbox_chan_ops tegra_xusb_mbox_chan_ops = {
+ .send_data = tegra_xusb_mbox_send_data,
+ .startup = tegra_xusb_mbox_startup,
+ .shutdown = tegra_xusb_mbox_shutdown,
+ .last_tx_done = tegra_xusb_mbox_last_tx_done,
+};
+
+static irqreturn_t tegra_xusb_mbox_irq(int irq, void *p)
+{
+ struct tegra_xusb_mbox *mbox = p;
+ struct tegra_xusb_mbox_msg msg;
+ unsigned int i;
+ u32 reg;
+
+ spin_lock(&mbox->lock);
+
+ /* Clear mbox interrupts */
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_SMI_INTR);
+ if (reg & MBOX_SMI_INTR_FW_HANG)
+ dev_err(mbox->mbox.dev, "Controller firmware hang\n");
+ mbox_writel(mbox, reg, XUSB_CFG_ARU_SMI_INTR);
+
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_DATA_OUT);
+ mbox_unpack_msg(reg, &msg);
+
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_CMD);
+ reg &= ~MBOX_DEST_SMI;
+ mbox_writel(mbox, reg, XUSB_CFG_ARU_MBOX_CMD);
+
+ /* Clear mailbox owner if no ACK/NAK is required. */
+ if (!mbox_cmd_requires_ack(msg.cmd))
+ mbox_writel(mbox, MBOX_OWNER_NONE, XUSB_CFG_ARU_MBOX_OWNER);
+
+ dev_dbg(mbox->mbox.dev, "RX message %#x:%#x\n", msg.cmd, msg.data);
+ for (i = 0; i < XUSB_MBOX_NUM_CHANS; i++) {
+ if (mbox->mbox.chans[i].cl)
+ mbox_chan_received_data(&mbox->mbox.chans[i], &msg);
+ }
+
+ spin_unlock(&mbox->lock);
+
+ return IRQ_HANDLED;
+}
+
+static struct mbox_chan *tegra_xusb_mbox_of_xlate(struct mbox_controller *ctlr,
+ const struct of_phandle_args *sp)
+{
+ struct tegra_xusb_mbox *mbox = to_tegra_mbox(ctlr);
+ struct mbox_chan *chan = ERR_PTR(-EINVAL);
+ unsigned long flags;
+ unsigned int i;
+
+ /* Pick the first available (virtual) channel. */
+ spin_lock_irqsave(&mbox->lock, flags);
+ for (i = 0; XUSB_MBOX_NUM_CHANS; i++) {
+ if (!ctlr->chans[i].cl) {
+ chan = &ctlr->chans[i];
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&mbox->lock, flags);
+
+ return chan;
+}
+
+static const struct of_device_id tegra_xusb_mbox_of_match[] = {
+ { .compatible = "nvidia,tegra124-xusb-mbox" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tegra_xusb_mbox_of_match);
+
+static int tegra_xusb_mbox_probe(struct platform_device *pdev)
+{
+ struct tegra_xusb_mbox *mbox;
+ int ret;
+
+ mbox = devm_kzalloc(&pdev->dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, mbox);
+ spin_lock_init(&mbox->lock);
+ mbox->fpci_regs = dev_get_drvdata(pdev->dev.parent);
+
+ mbox->mbox.dev = &pdev->dev;
+ mbox->mbox.chans = devm_kcalloc(&pdev->dev, XUSB_MBOX_NUM_CHANS,
+ sizeof(*mbox->mbox.chans), GFP_KERNEL);
+ if (!mbox->mbox.chans)
+ return -ENOMEM;
+ mbox->mbox.num_chans = XUSB_MBOX_NUM_CHANS;
+ mbox->mbox.ops = &tegra_xusb_mbox_chan_ops;
+ mbox->mbox.txdone_poll = true;
+ mbox->mbox.txpoll_period = 1;
+ mbox->mbox.of_xlate = tegra_xusb_mbox_of_xlate;
+
+ mbox->irq = platform_get_irq(pdev, 0);
+ if (mbox->irq < 0)
+ return mbox->irq;
+ ret = devm_request_irq(&pdev->dev, mbox->irq, tegra_xusb_mbox_irq, 0,
+ dev_name(&pdev->dev), mbox);
+ if (ret < 0)
+ return ret;
+
+ ret = mbox_controller_register(&mbox->mbox);
+ if (ret < 0)
+ dev_err(&pdev->dev, "failed to register mailbox: %d\n", ret);
+
+ return ret;
+}
+
+static int tegra_xusb_mbox_remove(struct platform_device *pdev)
+{
+ struct tegra_xusb_mbox *mbox = platform_get_drvdata(pdev);
+
+ synchronize_irq(mbox->irq);
+ devm_free_irq(&pdev->dev, mbox->irq, mbox);
+ mbox_controller_unregister(&mbox->mbox);
+
+ return 0;
+}
+
+static struct platform_driver tegra_xusb_mbox_driver = {
+ .probe = tegra_xusb_mbox_probe,
+ .remove = tegra_xusb_mbox_remove,
+ .driver = {
+ .name = "tegra-xusb-mbox",
+ .of_match_table = tegra_xusb_mbox_of_match,
+ },
+};
+module_platform_driver(tegra_xusb_mbox_driver);
+
+MODULE_AUTHOR("Andrew Bresticker <abrestic@chromium.org>");
+MODULE_DESCRIPTION("NVIDIA Tegra XUSB mailbox driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/soc/tegra/xusb.h b/include/soc/tegra/xusb.h
new file mode 100644
index 0000000..5ce5e12
--- /dev/null
+++ b/include/soc/tegra/xusb.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef __SOC_TEGRA_XUSB_H__
+#define __SOC_TEGRA_XUSB_H__
+
+/* Command requests from the firmware */
+enum tegra_xusb_mbox_cmd {
+ MBOX_CMD_MSG_ENABLED = 1,
+ MBOX_CMD_INC_FALC_CLOCK,
+ MBOX_CMD_DEC_FALC_CLOCK,
+ MBOX_CMD_INC_SSPI_CLOCK,
+ MBOX_CMD_DEC_SSPI_CLOCK,
+ MBOX_CMD_SET_BW, /* no ACK/NAK required */
+ MBOX_CMD_SET_SS_PWR_GATING,
+ MBOX_CMD_SET_SS_PWR_UNGATING,
+ MBOX_CMD_SAVE_DFE_CTLE_CTX,
+ MBOX_CMD_AIRPLANE_MODE_ENABLED, /* unused */
+ MBOX_CMD_AIRPLANE_MODE_DISABLED, /* unused */
+ MBOX_CMD_START_HSIC_IDLE,
+ MBOX_CMD_STOP_HSIC_IDLE,
+ MBOX_CMD_DBC_WAKE_STACK, /* unused */
+ MBOX_CMD_HSIC_PRETEND_CONNECT,
+
+ MBOX_CMD_MAX,
+
+ /* Response message to above commands */
+ MBOX_CMD_ACK = 128,
+ MBOX_CMD_NAK
+};
+
+struct tegra_xusb_mbox_msg {
+ u32 cmd;
+ u32 data;
+};
+
+#endif /* __SOC_TEGRA_XUSB_H__ */
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 7/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Andrew Bresticker, Jon Hunter, Jassi Brar
The Tegra xHCI controller's firmware communicates requests to the host
processor through a mailbox interface. While there is only a single
physical channel, messages sent by the controller can be divided
into two groups: those intended for the PHY driver and those intended
for the host-controller driver. The requesting driver is assigned
one of two virtual channels when the single physical channel is
requested. All incoming messages are sent to both virtual channels.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
---
Changes from v7:
- Don't reset ownership of mailbox for messages which require ACK/NAK.
- Synchronize and free IRQ before unregistering controller.
Changes from v6:
- Access FPCI registers using parent MFD's regmap.
Changes from v5:
- Poll for TX completion using MBOX_OWNER field.
Changes from v4:
- Use chan->cl to indicate channel allocation status
- Addressed review comments from Thierry
No changes from v3.
Changes from v2:
- Fixed mailbox IRQ vs. channel alloc/free race.
- Renamed defines to match TRM.
- Dropped channel specifier and instead allocated virtual channels as they
were requested.
- Removed MODULE_ALIAS.
Changes from v1:
- Converted to common mailbox framework.
- Removed useless polling sequences in TX path.
- Moved xusb include from linux/ to soc/tegra/
---
drivers/mailbox/Kconfig | 8 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/tegra-xusb-mailbox.c | 290 +++++++++++++++++++++++++++++++++++
include/soc/tegra/xusb.h | 43 ++++++
4 files changed, 343 insertions(+)
create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
create mode 100644 include/soc/tegra/xusb.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 84b0a2d..37da641 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -60,4 +60,12 @@ config ALTERA_MBOX
An implementation of the Altera Mailbox soft core. It is used
to send message between processors. Say Y here if you want to use the
Altera mailbox support.
+
+config TEGRA_XUSB_MBOX
+ tristate "NVIDIA Tegra XUSB Mailbox"
+ depends on MFD_TEGRA_XUSB
+ help
+ Mailbox driver for the XUSB complex found on NVIDIA Tegra124 and
+ later SoCs. The XUSB mailbox is used to communicate between the
+ XUSB microcontroller and the host processor.
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index b18201e..d77012a 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_OMAP2PLUS_MBOX) += omap-mailbox.o
obj-$(CONFIG_PCC) += pcc.o
obj-$(CONFIG_ALTERA_MBOX) += mailbox-altera.o
+
+obj-$(CONFIG_TEGRA_XUSB_MBOX) += tegra-xusb-mailbox.o
diff --git a/drivers/mailbox/tegra-xusb-mailbox.c b/drivers/mailbox/tegra-xusb-mailbox.c
new file mode 100644
index 0000000..4e2477d
--- /dev/null
+++ b/drivers/mailbox/tegra-xusb-mailbox.c
@@ -0,0 +1,290 @@
+/*
+ * NVIDIA Tegra XUSB mailbox driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#include <soc/tegra/xusb.h>
+
+#define XUSB_MBOX_NUM_CHANS 2 /* Host + PHY */
+
+#define XUSB_CFG_ARU_MBOX_CMD 0xe4
+#define MBOX_DEST_FALC BIT(27)
+#define MBOX_DEST_PME BIT(28)
+#define MBOX_DEST_SMI BIT(29)
+#define MBOX_DEST_XHCI BIT(30)
+#define MBOX_INT_EN BIT(31)
+#define XUSB_CFG_ARU_MBOX_DATA_IN 0xe8
+#define CMD_DATA_SHIFT 0
+#define CMD_DATA_MASK 0xffffff
+#define CMD_TYPE_SHIFT 24
+#define CMD_TYPE_MASK 0xff
+#define XUSB_CFG_ARU_MBOX_DATA_OUT 0xec
+#define XUSB_CFG_ARU_MBOX_OWNER 0xf0
+#define MBOX_OWNER_NONE 0
+#define MBOX_OWNER_FW 1
+#define MBOX_OWNER_SW 2
+#define XUSB_CFG_ARU_SMI_INTR 0x428
+#define MBOX_SMI_INTR_FW_HANG BIT(1)
+#define MBOX_SMI_INTR_EN BIT(3)
+
+struct tegra_xusb_mbox {
+ struct mbox_controller mbox;
+ struct regmap *fpci_regs;
+ spinlock_t lock;
+ int irq;
+};
+
+static inline u32 mbox_readl(struct tegra_xusb_mbox *mbox, unsigned long offset)
+{
+ u32 val;
+
+ regmap_read(mbox->fpci_regs, offset, &val);
+
+ return val;
+}
+
+static inline void mbox_writel(struct tegra_xusb_mbox *mbox, u32 val,
+ unsigned long offset)
+{
+ regmap_write(mbox->fpci_regs, offset, val);
+}
+
+static inline struct tegra_xusb_mbox *to_tegra_mbox(struct mbox_controller *c)
+{
+ return container_of(c, struct tegra_xusb_mbox, mbox);
+}
+
+static inline u32 mbox_pack_msg(struct tegra_xusb_mbox_msg *msg)
+{
+ u32 val;
+
+ val = (msg->cmd & CMD_TYPE_MASK) << CMD_TYPE_SHIFT;
+ val |= (msg->data & CMD_DATA_MASK) << CMD_DATA_SHIFT;
+
+ return val;
+}
+
+static inline void mbox_unpack_msg(u32 val, struct tegra_xusb_mbox_msg *msg)
+{
+ msg->cmd = (val >> CMD_TYPE_SHIFT) & CMD_TYPE_MASK;
+ msg->data = (val >> CMD_DATA_SHIFT) & CMD_DATA_MASK;
+}
+
+static bool mbox_cmd_requires_ack(enum tegra_xusb_mbox_cmd cmd)
+{
+ switch (cmd) {
+ case MBOX_CMD_SET_BW:
+ case MBOX_CMD_ACK:
+ case MBOX_CMD_NAK:
+ return false;
+ default:
+ return true;
+ }
+}
+
+static int tegra_xusb_mbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct tegra_xusb_mbox *mbox = to_tegra_mbox(chan->mbox);
+ struct tegra_xusb_mbox_msg *msg = data;
+ unsigned long flags;
+ u32 reg;
+
+ dev_dbg(mbox->mbox.dev, "TX message %#x:%#x\n", msg->cmd, msg->data);
+
+ spin_lock_irqsave(&mbox->lock, flags);
+ /*
+ * Acquire the mailbox. The firmware still owns the mailbox for
+ * ACK/NAK messages.
+ */
+ if (!(msg->cmd == MBOX_CMD_ACK || msg->cmd == MBOX_CMD_NAK)) {
+ if (mbox_readl(mbox, XUSB_CFG_ARU_MBOX_OWNER) !=
+ MBOX_OWNER_NONE) {
+ dev_err(mbox->mbox.dev, "Mailbox not idle\n");
+ goto busy;
+ }
+
+ mbox_writel(mbox, MBOX_OWNER_SW, XUSB_CFG_ARU_MBOX_OWNER);
+ if (mbox_readl(mbox, XUSB_CFG_ARU_MBOX_OWNER) !=
+ MBOX_OWNER_SW) {
+ dev_err(mbox->mbox.dev, "Failed to acquire mailbox");
+ goto busy;
+ }
+ }
+
+ mbox_writel(mbox, mbox_pack_msg(msg), XUSB_CFG_ARU_MBOX_DATA_IN);
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_CMD);
+ reg |= MBOX_INT_EN | MBOX_DEST_FALC;
+ mbox_writel(mbox, reg, XUSB_CFG_ARU_MBOX_CMD);
+
+ spin_unlock_irqrestore(&mbox->lock, flags);
+
+ return 0;
+busy:
+ spin_unlock_irqrestore(&mbox->lock, flags);
+ return -EBUSY;
+}
+
+static int tegra_xusb_mbox_startup(struct mbox_chan *chan)
+{
+ return 0;
+}
+
+static void tegra_xusb_mbox_shutdown(struct mbox_chan *chan)
+{
+}
+
+static bool tegra_xusb_mbox_last_tx_done(struct mbox_chan *chan)
+{
+ struct tegra_xusb_mbox *mbox = to_tegra_mbox(chan->mbox);
+
+ return mbox_readl(mbox, XUSB_CFG_ARU_MBOX_OWNER) == MBOX_OWNER_NONE;
+}
+
+static const struct mbox_chan_ops tegra_xusb_mbox_chan_ops = {
+ .send_data = tegra_xusb_mbox_send_data,
+ .startup = tegra_xusb_mbox_startup,
+ .shutdown = tegra_xusb_mbox_shutdown,
+ .last_tx_done = tegra_xusb_mbox_last_tx_done,
+};
+
+static irqreturn_t tegra_xusb_mbox_irq(int irq, void *p)
+{
+ struct tegra_xusb_mbox *mbox = p;
+ struct tegra_xusb_mbox_msg msg;
+ unsigned int i;
+ u32 reg;
+
+ spin_lock(&mbox->lock);
+
+ /* Clear mbox interrupts */
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_SMI_INTR);
+ if (reg & MBOX_SMI_INTR_FW_HANG)
+ dev_err(mbox->mbox.dev, "Controller firmware hang\n");
+ mbox_writel(mbox, reg, XUSB_CFG_ARU_SMI_INTR);
+
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_DATA_OUT);
+ mbox_unpack_msg(reg, &msg);
+
+ reg = mbox_readl(mbox, XUSB_CFG_ARU_MBOX_CMD);
+ reg &= ~MBOX_DEST_SMI;
+ mbox_writel(mbox, reg, XUSB_CFG_ARU_MBOX_CMD);
+
+ /* Clear mailbox owner if no ACK/NAK is required. */
+ if (!mbox_cmd_requires_ack(msg.cmd))
+ mbox_writel(mbox, MBOX_OWNER_NONE, XUSB_CFG_ARU_MBOX_OWNER);
+
+ dev_dbg(mbox->mbox.dev, "RX message %#x:%#x\n", msg.cmd, msg.data);
+ for (i = 0; i < XUSB_MBOX_NUM_CHANS; i++) {
+ if (mbox->mbox.chans[i].cl)
+ mbox_chan_received_data(&mbox->mbox.chans[i], &msg);
+ }
+
+ spin_unlock(&mbox->lock);
+
+ return IRQ_HANDLED;
+}
+
+static struct mbox_chan *tegra_xusb_mbox_of_xlate(struct mbox_controller *ctlr,
+ const struct of_phandle_args *sp)
+{
+ struct tegra_xusb_mbox *mbox = to_tegra_mbox(ctlr);
+ struct mbox_chan *chan = ERR_PTR(-EINVAL);
+ unsigned long flags;
+ unsigned int i;
+
+ /* Pick the first available (virtual) channel. */
+ spin_lock_irqsave(&mbox->lock, flags);
+ for (i = 0; XUSB_MBOX_NUM_CHANS; i++) {
+ if (!ctlr->chans[i].cl) {
+ chan = &ctlr->chans[i];
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&mbox->lock, flags);
+
+ return chan;
+}
+
+static const struct of_device_id tegra_xusb_mbox_of_match[] = {
+ { .compatible = "nvidia,tegra124-xusb-mbox" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tegra_xusb_mbox_of_match);
+
+static int tegra_xusb_mbox_probe(struct platform_device *pdev)
+{
+ struct tegra_xusb_mbox *mbox;
+ int ret;
+
+ mbox = devm_kzalloc(&pdev->dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, mbox);
+ spin_lock_init(&mbox->lock);
+ mbox->fpci_regs = dev_get_drvdata(pdev->dev.parent);
+
+ mbox->mbox.dev = &pdev->dev;
+ mbox->mbox.chans = devm_kcalloc(&pdev->dev, XUSB_MBOX_NUM_CHANS,
+ sizeof(*mbox->mbox.chans), GFP_KERNEL);
+ if (!mbox->mbox.chans)
+ return -ENOMEM;
+ mbox->mbox.num_chans = XUSB_MBOX_NUM_CHANS;
+ mbox->mbox.ops = &tegra_xusb_mbox_chan_ops;
+ mbox->mbox.txdone_poll = true;
+ mbox->mbox.txpoll_period = 1;
+ mbox->mbox.of_xlate = tegra_xusb_mbox_of_xlate;
+
+ mbox->irq = platform_get_irq(pdev, 0);
+ if (mbox->irq < 0)
+ return mbox->irq;
+ ret = devm_request_irq(&pdev->dev, mbox->irq, tegra_xusb_mbox_irq, 0,
+ dev_name(&pdev->dev), mbox);
+ if (ret < 0)
+ return ret;
+
+ ret = mbox_controller_register(&mbox->mbox);
+ if (ret < 0)
+ dev_err(&pdev->dev, "failed to register mailbox: %d\n", ret);
+
+ return ret;
+}
+
+static int tegra_xusb_mbox_remove(struct platform_device *pdev)
+{
+ struct tegra_xusb_mbox *mbox = platform_get_drvdata(pdev);
+
+ synchronize_irq(mbox->irq);
+ devm_free_irq(&pdev->dev, mbox->irq, mbox);
+ mbox_controller_unregister(&mbox->mbox);
+
+ return 0;
+}
+
+static struct platform_driver tegra_xusb_mbox_driver = {
+ .probe = tegra_xusb_mbox_probe,
+ .remove = tegra_xusb_mbox_remove,
+ .driver = {
+ .name = "tegra-xusb-mbox",
+ .of_match_table = tegra_xusb_mbox_of_match,
+ },
+};
+module_platform_driver(tegra_xusb_mbox_driver);
+
+MODULE_AUTHOR("Andrew Bresticker <abrestic@chromium.org>");
+MODULE_DESCRIPTION("NVIDIA Tegra XUSB mailbox driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/soc/tegra/xusb.h b/include/soc/tegra/xusb.h
new file mode 100644
index 0000000..5ce5e12
--- /dev/null
+++ b/include/soc/tegra/xusb.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef __SOC_TEGRA_XUSB_H__
+#define __SOC_TEGRA_XUSB_H__
+
+/* Command requests from the firmware */
+enum tegra_xusb_mbox_cmd {
+ MBOX_CMD_MSG_ENABLED = 1,
+ MBOX_CMD_INC_FALC_CLOCK,
+ MBOX_CMD_DEC_FALC_CLOCK,
+ MBOX_CMD_INC_SSPI_CLOCK,
+ MBOX_CMD_DEC_SSPI_CLOCK,
+ MBOX_CMD_SET_BW, /* no ACK/NAK required */
+ MBOX_CMD_SET_SS_PWR_GATING,
+ MBOX_CMD_SET_SS_PWR_UNGATING,
+ MBOX_CMD_SAVE_DFE_CTLE_CTX,
+ MBOX_CMD_AIRPLANE_MODE_ENABLED, /* unused */
+ MBOX_CMD_AIRPLANE_MODE_DISABLED, /* unused */
+ MBOX_CMD_START_HSIC_IDLE,
+ MBOX_CMD_STOP_HSIC_IDLE,
+ MBOX_CMD_DBC_WAKE_STACK, /* unused */
+ MBOX_CMD_HSIC_PRETEND_CONNECT,
+
+ MBOX_CMD_MAX,
+
+ /* Response message to above commands */
+ MBOX_CMD_ACK = 128,
+ MBOX_CMD_NAK
+};
+
+struct tegra_xusb_mbox_msg {
+ u32 cmd;
+ u32 data;
+};
+
+#endif /* __SOC_TEGRA_XUSB_H__ */
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v8 8/9] usb: Add NVIDIA Tegra xHCI controller binding
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-04 17:36 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bresticker,
Jon Hunter, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Mathias Nyman, Greg Kroah-Hartman
Add device-tree binding documentation for the xHCI controller present
on Tegra124 and later SoCs.
Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Mathias Nyman <mathias.nyman-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
---
Changes from v7:
- Added back non-shared reg/interrupts properties.
Changes from v6:
- Removed XUSB_DEV related clocks/resets. They will be consumed by
a separate driver and binding.
- Removed reg/interrupts properties.
No changes from v5.
Changes from v4:
- Updated regulator names, as suggested by Thierry.
No changes from v3.
Changes from v2:
- Added mbox-names property.
Changes from v1:
- Updated to use common mailbox bindings.
- Added remaining XUSB-related clocks and resets.
- Updated list of power supplies to be more accurate wrt to the hardware.
---
.../bindings/usb/nvidia,tegra124-xhci.txt | 96 ++++++++++++++++++++++
1 file changed, 96 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
new file mode 100644
index 0000000..54d21c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
@@ -0,0 +1,96 @@
+NVIDIA Tegra xHCI controller
+============================
+
+The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed
+by the Tegra XUSB pad controller.
+
+Required properties:
+--------------------
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xhci".
+ Otherwise, must contain '"nvidia,<chip>-xhci", "nvidia,tegra124-xhci"'
+ where <chip> is tegra132.
+ - reg: Must contain the base and length of the xHCI host registers and XUSB
+ IPFS registers.
+ - interrupts: Must contain the xHCI host interrupt.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clock/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ - xusb_host
+ - xusb_host_src
+ - xusb_falcon_src
+ - xusb_ss
+ - xusb_ss_src
+ - xusb_ss_div2
+ - xusb_hs_src
+ - xusb_fs_src
+ - pll_u_480m
+ - clk_m
+ - pll_e
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - xusb_host
+ - xusb_ss
+ - xusb_src
+ Note that xusb_src is the shared reset for xusb_{ss,hs,fs,falcon,host}_src.
+ - mboxes: Must contain an entry for the XUSB mailbox channel.
+ See ../mailbox/mailbox.txt for details.
+ - mbox-names: Must include the following entries:
+ - xusb
+ - avddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05V.
+ - dvddio-pex-supply: PCIe/USB3 digital logic power supply. Must supply 1.05V.
+ - avdd-usb-supply: USB controller power supply. Must supply 3.3V.
+ - avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8V.
+ - avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05V.
+ - avdd-usb-ss-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05V.
+ - hvdd-usb-ss-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3V.
+ - hvdd-usb-ss-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3V.
+
+Optional properties:
+--------------------
+ - phys: Must contain an entry for each entry in phy-names.
+ See ../phy/phy-bindings.txt for details.
+ - phy-names: Should include an entry for each PHY used by the controller.
+ Names must be of the form "<type>-<number>" where <type> is one of "utmi",
+ "hsic", or "usb3" and <number> is a 0-based index. On Tegra124, there may
+ be up to 3 UTMI, 2 HSIC, and 2 USB3 PHYs.
+
+Example:
+--------
+ usb-host@0,70090000 {
+ compatible = "nvidia,tegra124-xhci";
+ reg = <0x0 0x70090000 0x0 0x8000>,
+ <0x0 0x70099000 0x0 0x1000>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA124_CLK_XUSB_HOST>,
+ <&tegra_car TEGRA124_CLK_XUSB_HOST_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_FALCON_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS_DIV2>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_HS_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_FS_SRC>,
+ <&tegra_car TEGRA124_CLK_PLL_U_480M>,
+ <&tegra_car TEGRA124_CLK_CLK_M>,
+ <&tegra_car TEGRA124_CLK_PLL_E>;
+ clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_div2", "xusb_ss_src",
+ "xusb_hs_src", "xusb_fs_src", "pll_u_480m",
+ "clk_m", "pll_e";
+ resets = <&tegra_car 89>, <&tegra_car 156>, <&tegra_car 143>;
+ reset-names = "xusb_host", "xusb_ss", "xusb_src";
+ mboxes = <&xusb_mbox>;
+ mbox-names = "xusb";
+ phys = <&padctl TEGRA_XUSB_PADCTL_UTMI_P1>, /* mini-PCIe USB */
+ <&padctl TEGRA_XUSB_PADCTL_UTMI_P2>, /* USB A */
+ <&padctl TEGRA_XUSB_PADCTL_USB3_P0>; /* USB A */
+ phy-names = "utmi-1", "utmi-2", "usb3-0";
+ avddio-pex-supply = <&vdd_1v05_run>;
+ dvddio-pex-supply = <&vdd_1v05_run>;
+ avdd-usb-supply = <&vdd_3v3_lp0>;
+ avdd-pll-utmip-supply = <&vddio_1v8>;
+ avdd-pll-erefe-supply = <&avdd_1v05_run>;
+ avdd-usb-ss-pll-supply = <&vdd_1v05_run>;
+ hvdd-usb-ss-supply = <&vdd_3v3_lp0>;
+ hvdd-usb-ss-pll-e-supply = <&vdd_3v3_lp0>;
+ };
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 8/9] usb: Add NVIDIA Tegra xHCI controller binding
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: linux-arm-kernel
Add device-tree binding documentation for the xHCI controller present
on Tegra124 and later SoCs.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Changes from v7:
- Added back non-shared reg/interrupts properties.
Changes from v6:
- Removed XUSB_DEV related clocks/resets. They will be consumed by
a separate driver and binding.
- Removed reg/interrupts properties.
No changes from v5.
Changes from v4:
- Updated regulator names, as suggested by Thierry.
No changes from v3.
Changes from v2:
- Added mbox-names property.
Changes from v1:
- Updated to use common mailbox bindings.
- Added remaining XUSB-related clocks and resets.
- Updated list of power supplies to be more accurate wrt to the hardware.
---
.../bindings/usb/nvidia,tegra124-xhci.txt | 96 ++++++++++++++++++++++
1 file changed, 96 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
new file mode 100644
index 0000000..54d21c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
@@ -0,0 +1,96 @@
+NVIDIA Tegra xHCI controller
+============================
+
+The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed
+by the Tegra XUSB pad controller.
+
+Required properties:
+--------------------
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xhci".
+ Otherwise, must contain '"nvidia,<chip>-xhci", "nvidia,tegra124-xhci"'
+ where <chip> is tegra132.
+ - reg: Must contain the base and length of the xHCI host registers and XUSB
+ IPFS registers.
+ - interrupts: Must contain the xHCI host interrupt.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clock/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ - xusb_host
+ - xusb_host_src
+ - xusb_falcon_src
+ - xusb_ss
+ - xusb_ss_src
+ - xusb_ss_div2
+ - xusb_hs_src
+ - xusb_fs_src
+ - pll_u_480m
+ - clk_m
+ - pll_e
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - xusb_host
+ - xusb_ss
+ - xusb_src
+ Note that xusb_src is the shared reset for xusb_{ss,hs,fs,falcon,host}_src.
+ - mboxes: Must contain an entry for the XUSB mailbox channel.
+ See ../mailbox/mailbox.txt for details.
+ - mbox-names: Must include the following entries:
+ - xusb
+ - avddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05V.
+ - dvddio-pex-supply: PCIe/USB3 digital logic power supply. Must supply 1.05V.
+ - avdd-usb-supply: USB controller power supply. Must supply 3.3V.
+ - avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8V.
+ - avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05V.
+ - avdd-usb-ss-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05V.
+ - hvdd-usb-ss-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3V.
+ - hvdd-usb-ss-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3V.
+
+Optional properties:
+--------------------
+ - phys: Must contain an entry for each entry in phy-names.
+ See ../phy/phy-bindings.txt for details.
+ - phy-names: Should include an entry for each PHY used by the controller.
+ Names must be of the form "<type>-<number>" where <type> is one of "utmi",
+ "hsic", or "usb3" and <number> is a 0-based index. On Tegra124, there may
+ be up to 3 UTMI, 2 HSIC, and 2 USB3 PHYs.
+
+Example:
+--------
+ usb-host at 0,70090000 {
+ compatible = "nvidia,tegra124-xhci";
+ reg = <0x0 0x70090000 0x0 0x8000>,
+ <0x0 0x70099000 0x0 0x1000>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA124_CLK_XUSB_HOST>,
+ <&tegra_car TEGRA124_CLK_XUSB_HOST_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_FALCON_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS_DIV2>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_HS_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_FS_SRC>,
+ <&tegra_car TEGRA124_CLK_PLL_U_480M>,
+ <&tegra_car TEGRA124_CLK_CLK_M>,
+ <&tegra_car TEGRA124_CLK_PLL_E>;
+ clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_div2", "xusb_ss_src",
+ "xusb_hs_src", "xusb_fs_src", "pll_u_480m",
+ "clk_m", "pll_e";
+ resets = <&tegra_car 89>, <&tegra_car 156>, <&tegra_car 143>;
+ reset-names = "xusb_host", "xusb_ss", "xusb_src";
+ mboxes = <&xusb_mbox>;
+ mbox-names = "xusb";
+ phys = <&padctl TEGRA_XUSB_PADCTL_UTMI_P1>, /* mini-PCIe USB */
+ <&padctl TEGRA_XUSB_PADCTL_UTMI_P2>, /* USB A */
+ <&padctl TEGRA_XUSB_PADCTL_USB3_P0>; /* USB A */
+ phy-names = "utmi-1", "utmi-2", "usb3-0";
+ avddio-pex-supply = <&vdd_1v05_run>;
+ dvddio-pex-supply = <&vdd_1v05_run>;
+ avdd-usb-supply = <&vdd_3v3_lp0>;
+ avdd-pll-utmip-supply = <&vddio_1v8>;
+ avdd-pll-erefe-supply = <&avdd_1v05_run>;
+ avdd-usb-ss-pll-supply = <&vdd_1v05_run>;
+ hvdd-usb-ss-supply = <&vdd_3v3_lp0>;
+ hvdd-usb-ss-pll-e-supply = <&vdd_3v3_lp0>;
+ };
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 8/9] usb: Add NVIDIA Tegra xHCI controller binding
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Andrew Bresticker, Jon Hunter, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Mathias Nyman, Greg Kroah-Hartman
Add device-tree binding documentation for the xHCI controller present
on Tegra124 and later SoCs.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Changes from v7:
- Added back non-shared reg/interrupts properties.
Changes from v6:
- Removed XUSB_DEV related clocks/resets. They will be consumed by
a separate driver and binding.
- Removed reg/interrupts properties.
No changes from v5.
Changes from v4:
- Updated regulator names, as suggested by Thierry.
No changes from v3.
Changes from v2:
- Added mbox-names property.
Changes from v1:
- Updated to use common mailbox bindings.
- Added remaining XUSB-related clocks and resets.
- Updated list of power supplies to be more accurate wrt to the hardware.
---
.../bindings/usb/nvidia,tegra124-xhci.txt | 96 ++++++++++++++++++++++
1 file changed, 96 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
new file mode 100644
index 0000000..54d21c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
@@ -0,0 +1,96 @@
+NVIDIA Tegra xHCI controller
+============================
+
+The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed
+by the Tegra XUSB pad controller.
+
+Required properties:
+--------------------
+ - compatible: For Tegra124, must contain "nvidia,tegra124-xhci".
+ Otherwise, must contain '"nvidia,<chip>-xhci", "nvidia,tegra124-xhci"'
+ where <chip> is tegra132.
+ - reg: Must contain the base and length of the xHCI host registers and XUSB
+ IPFS registers.
+ - interrupts: Must contain the xHCI host interrupt.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clock/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ - xusb_host
+ - xusb_host_src
+ - xusb_falcon_src
+ - xusb_ss
+ - xusb_ss_src
+ - xusb_ss_div2
+ - xusb_hs_src
+ - xusb_fs_src
+ - pll_u_480m
+ - clk_m
+ - pll_e
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - xusb_host
+ - xusb_ss
+ - xusb_src
+ Note that xusb_src is the shared reset for xusb_{ss,hs,fs,falcon,host}_src.
+ - mboxes: Must contain an entry for the XUSB mailbox channel.
+ See ../mailbox/mailbox.txt for details.
+ - mbox-names: Must include the following entries:
+ - xusb
+ - avddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05V.
+ - dvddio-pex-supply: PCIe/USB3 digital logic power supply. Must supply 1.05V.
+ - avdd-usb-supply: USB controller power supply. Must supply 3.3V.
+ - avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8V.
+ - avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05V.
+ - avdd-usb-ss-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05V.
+ - hvdd-usb-ss-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3V.
+ - hvdd-usb-ss-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3V.
+
+Optional properties:
+--------------------
+ - phys: Must contain an entry for each entry in phy-names.
+ See ../phy/phy-bindings.txt for details.
+ - phy-names: Should include an entry for each PHY used by the controller.
+ Names must be of the form "<type>-<number>" where <type> is one of "utmi",
+ "hsic", or "usb3" and <number> is a 0-based index. On Tegra124, there may
+ be up to 3 UTMI, 2 HSIC, and 2 USB3 PHYs.
+
+Example:
+--------
+ usb-host@0,70090000 {
+ compatible = "nvidia,tegra124-xhci";
+ reg = <0x0 0x70090000 0x0 0x8000>,
+ <0x0 0x70099000 0x0 0x1000>;
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA124_CLK_XUSB_HOST>,
+ <&tegra_car TEGRA124_CLK_XUSB_HOST_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_FALCON_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS_DIV2>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_HS_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_FS_SRC>,
+ <&tegra_car TEGRA124_CLK_PLL_U_480M>,
+ <&tegra_car TEGRA124_CLK_CLK_M>,
+ <&tegra_car TEGRA124_CLK_PLL_E>;
+ clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_div2", "xusb_ss_src",
+ "xusb_hs_src", "xusb_fs_src", "pll_u_480m",
+ "clk_m", "pll_e";
+ resets = <&tegra_car 89>, <&tegra_car 156>, <&tegra_car 143>;
+ reset-names = "xusb_host", "xusb_ss", "xusb_src";
+ mboxes = <&xusb_mbox>;
+ mbox-names = "xusb";
+ phys = <&padctl TEGRA_XUSB_PADCTL_UTMI_P1>, /* mini-PCIe USB */
+ <&padctl TEGRA_XUSB_PADCTL_UTMI_P2>, /* USB A */
+ <&padctl TEGRA_XUSB_PADCTL_USB3_P0>; /* USB A */
+ phy-names = "utmi-1", "utmi-2", "usb3-0";
+ avddio-pex-supply = <&vdd_1v05_run>;
+ dvddio-pex-supply = <&vdd_1v05_run>;
+ avdd-usb-supply = <&vdd_3v3_lp0>;
+ avdd-pll-utmip-supply = <&vddio_1v8>;
+ avdd-pll-erefe-supply = <&avdd_1v05_run>;
+ avdd-usb-ss-pll-supply = <&vdd_1v05_run>;
+ hvdd-usb-ss-supply = <&vdd_3v3_lp0>;
+ hvdd-usb-ss-pll-e-supply = <&vdd_3v3_lp0>;
+ };
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCH v8 9/9] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-04 17:36 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Bresticker,
Jon Hunter, Mathias Nyman, Greg Kroah-Hartman
Add support for the on-chip xHCI host controller present on Tegra SoCs.
The controller requires external firmware which must be loaded before
using the controller. This driver loads the firmware, starts the
controller, and is able to service host-specific messages sent by
the controller's firmware.
The controller also supports USB device mode as well as powergating
of the SuperSpeed and host-controller logic when not in use, but
support for these is not yet implemented.
Based on work by:
Ajay Gupta <ajayg-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Bharath Yadav <byadav-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Mathias Nyman <mathias.nyman-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
---
No changes from v7.
Changes from v6:
- Access FPCI registers using parent MFD's regmap.
- Made regulator names and PHY types part of the SoC-specific data
since they will be different on Tegra210.
- Other cosmetic cleanups.
Changes from v5:
- Added dependency on COMPILE_TEST and MAILBOX.
- Added TODO about powergating support.
Changes from v4:
- Poll for controller to finish booting.
- Addressed review comments from Thierry.
Changes from v3:
- Used 32-bit DMA mask (platforms may have > 32-bit physical address space
and < 64-bit dma_addr_t).
- Moved comment about SET_BW command.
Changes from v2:
- Added filtering out of non-host mailbox messages.
- Removed MODULE_ALIAS.
Changes from v1:
- Updated to use common mailbox API.
- Fixed up so that the driver can be built and used as a module.
- Incorporated review feedback from Stephen.
- Misc. cleanups.
---
drivers/usb/host/Kconfig | 10 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/xhci-tegra.c | 947 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 958 insertions(+)
create mode 100644 drivers/usb/host/xhci-tegra.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 197a6a3..22601d0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -50,6 +50,16 @@ config USB_XHCI_RCAR
Say 'Y' to enable the support for the xHCI host controller
found in Renesas R-Car ARM SoCs.
+config USB_XHCI_TEGRA
+ tristate "xHCI support for NVIDIA Tegra SoCs"
+ depends on MFD_TEGRA_XUSB || COMPILE_TEST
+ depends on MAILBOX
+ depends on RESET_CONTROLLER
+ select FW_LOADER
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in NVIDIA Tegra124 and later SoCs.
+
endif # USB_XHCI_HCD
config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 65b0b6a..1b98107 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PCI) += pci-quirks.o
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_TEGRA) += xhci-tegra.o
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
new file mode 100644
index 0000000..d510dc5
--- /dev/null
+++ b/drivers/usb/host/xhci-tegra.c
@@ -0,0 +1,947 @@
+/*
+ * NVIDIA Tegra xHCI host controller driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/firmware.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_client.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+
+#include <soc/tegra/xusb.h>
+
+#include "xhci.h"
+
+#define TEGRA_XHCI_SS_CLK_HIGH_SPEED 120000000
+#define TEGRA_XHCI_SS_CLK_LOW_SPEED 12000000
+
+/* FPCI CFG registers */
+#define XUSB_CFG_1 0x004
+#define XUSB_IO_SPACE_EN BIT(0)
+#define XUSB_MEM_SPACE_EN BIT(1)
+#define XUSB_BUS_MASTER_EN BIT(2)
+#define XUSB_CFG_4 0x010
+#define XUSB_BASE_ADDR_SHIFT 15
+#define XUSB_BASE_ADDR_MASK 0x1ffff
+#define XUSB_CFG_ARU_C11_CSBRANGE 0x41c
+#define XUSB_CFG_CSB_BASE_ADDR 0x800
+
+/* IPFS registers */
+#define IPFS_XUSB_HOST_CONFIGURATION_0 0x180
+#define IPFS_EN_FPCI BIT(0)
+#define IPFS_XUSB_HOST_INTR_MASK_0 0x188
+#define IPFS_IP_INT_MASK BIT(16)
+#define IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_0 0x1bc
+
+#define CSB_PAGE_SELECT_MASK 0x7fffff
+#define CSB_PAGE_SELECT_SHIFT 9
+#define CSB_PAGE_OFFSET_MASK 0x1ff
+#define CSB_PAGE_SELECT(addr) ((addr) >> (CSB_PAGE_SELECT_SHIFT) & \
+ CSB_PAGE_SELECT_MASK)
+#define CSB_PAGE_OFFSET(addr) ((addr) & CSB_PAGE_OFFSET_MASK)
+
+/* Falcon CSB registers */
+#define XUSB_FALC_CPUCTL 0x100
+#define CPUCTL_STARTCPU BIT(1)
+#define CPUCTL_STATE_HALTED BIT(4)
+#define CPUCTL_STATE_STOPPED BIT(5)
+#define XUSB_FALC_BOOTVEC 0x104
+#define XUSB_FALC_DMACTL 0x10c
+#define XUSB_FALC_IMFILLRNG1 0x154
+#define IMFILLRNG1_TAG_MASK 0xffff
+#define IMFILLRNG1_TAG_LO_SHIFT 0
+#define IMFILLRNG1_TAG_HI_SHIFT 16
+#define XUSB_FALC_IMFILLCTL 0x158
+
+/* MP CSB registers */
+#define XUSB_CSB_MP_ILOAD_ATTR 0x101a00
+#define XUSB_CSB_MP_ILOAD_BASE_LO 0x101a04
+#define XUSB_CSB_MP_ILOAD_BASE_HI 0x101a08
+#define XUSB_CSB_MP_L2IMEMOP_SIZE 0x101a10
+#define L2IMEMOP_SIZE_SRC_OFFSET_SHIFT 8
+#define L2IMEMOP_SIZE_SRC_OFFSET_MASK 0x3ff
+#define L2IMEMOP_SIZE_SRC_COUNT_SHIFT 24
+#define L2IMEMOP_SIZE_SRC_COUNT_MASK 0xff
+#define XUSB_CSB_MP_L2IMEMOP_TRIG 0x101a14
+#define L2IMEMOP_ACTION_SHIFT 24
+#define L2IMEMOP_INVALIDATE_ALL (0x40 << L2IMEMOP_ACTION_SHIFT)
+#define L2IMEMOP_LOAD_LOCKED_RESULT (0x11 << L2IMEMOP_ACTION_SHIFT)
+#define XUSB_CSB_MP_APMAP 0x10181c
+#define APMAP_BOOTPATH BIT(31)
+
+#define IMEM_BLOCK_SIZE 256
+
+struct tegra_xhci_fw_cfgtbl {
+ u32 boot_loadaddr_in_imem;
+ u32 boot_codedfi_offset;
+ u32 boot_codetag;
+ u32 boot_codesize;
+ u32 phys_memaddr;
+ u16 reqphys_memsize;
+ u16 alloc_phys_memsize;
+ u32 rodata_img_offset;
+ u32 rodata_section_start;
+ u32 rodata_section_end;
+ u32 main_fnaddr;
+ u32 fwimg_cksum;
+ u32 fwimg_created_time;
+ u32 imem_resident_start;
+ u32 imem_resident_end;
+ u32 idirect_start;
+ u32 idirect_end;
+ u32 l2_imem_start;
+ u32 l2_imem_end;
+ u32 version_id;
+ u8 init_ddirect;
+ u8 reserved[3];
+ u32 phys_addr_log_buffer;
+ u32 total_log_entries;
+ u32 dequeue_ptr;
+ u32 dummy_var[2];
+ u32 fwimg_len;
+ u8 magic[8];
+ u32 ss_low_power_entry_timeout;
+ u8 num_hsic_port;
+ u8 padding[139]; /* Pad to 256 bytes */
+};
+
+struct tegra_xhci_phy_type {
+ const char *name;
+ unsigned int num;
+};
+
+struct tegra_xhci_soc_data {
+ const char *firmware_file;
+ const char * const *supply_names;
+ unsigned int num_supplies;
+ const struct tegra_xhci_phy_type *phy_types;
+ unsigned int num_types;
+};
+
+struct tegra_xhci_hcd {
+ struct device *dev;
+ struct usb_hcd *hcd;
+
+ int irq;
+
+ void __iomem *ipfs_base;
+ struct regmap *fpci_regs;
+
+ const struct tegra_xhci_soc_data *soc;
+
+ struct regulator_bulk_data *supplies;
+
+ struct clk *host_clk;
+ struct clk *falc_clk;
+ struct clk *ss_clk;
+ struct clk *ss_src_clk;
+ struct clk *hs_src_clk;
+ struct clk *fs_src_clk;
+ struct clk *pll_u_480m;
+ struct clk *clk_m;
+ struct clk *pll_e;
+
+ struct reset_control *host_rst;
+ struct reset_control *ss_rst;
+
+ struct phy **phys;
+ unsigned int num_phys;
+
+ struct work_struct mbox_req_work;
+ struct tegra_xusb_mbox_msg mbox_req;
+ struct mbox_client mbox_client;
+ struct mbox_chan *mbox_chan;
+
+ /* Firmware loading related */
+ void *fw_data;
+ size_t fw_size;
+ dma_addr_t fw_dma_addr;
+ bool fw_loaded;
+};
+
+static struct hc_driver __read_mostly tegra_xhci_hc_driver;
+
+static inline struct tegra_xhci_hcd *
+mbox_work_to_tegra(struct work_struct *work)
+{
+ return container_of(work, struct tegra_xhci_hcd, mbox_req_work);
+}
+
+static inline u32 fpci_readl(struct tegra_xhci_hcd *tegra, u32 addr)
+{
+ u32 val;
+
+ regmap_read(tegra->fpci_regs, addr, &val);
+
+ return val;
+}
+
+static inline void fpci_writel(struct tegra_xhci_hcd *tegra, u32 val, u32 addr)
+{
+ regmap_write(tegra->fpci_regs, addr, val);
+}
+
+static inline u32 ipfs_readl(struct tegra_xhci_hcd *tegra, u32 addr)
+{
+ return readl(tegra->ipfs_base + addr);
+}
+
+static inline void ipfs_writel(struct tegra_xhci_hcd *tegra, u32 val, u32 addr)
+{
+ writel(val, tegra->ipfs_base + addr);
+}
+
+static u32 csb_readl(struct tegra_xhci_hcd *tegra, u32 addr)
+{
+ u32 page, offset;
+
+ page = CSB_PAGE_SELECT(addr);
+ offset = CSB_PAGE_OFFSET(addr);
+ fpci_writel(tegra, page, XUSB_CFG_ARU_C11_CSBRANGE);
+ return fpci_readl(tegra, XUSB_CFG_CSB_BASE_ADDR + offset);
+}
+
+static void csb_writel(struct tegra_xhci_hcd *tegra, u32 val, u32 addr)
+{
+ u32 page, offset;
+
+ page = CSB_PAGE_SELECT(addr);
+ offset = CSB_PAGE_OFFSET(addr);
+ fpci_writel(tegra, page, XUSB_CFG_ARU_C11_CSBRANGE);
+ fpci_writel(tegra, val, XUSB_CFG_CSB_BASE_ADDR + offset);
+}
+
+static void tegra_xhci_ipfs_config(struct tegra_xhci_hcd *tegra)
+{
+ u32 reg;
+
+ reg = ipfs_readl(tegra, IPFS_XUSB_HOST_CONFIGURATION_0);
+ reg |= IPFS_EN_FPCI;
+ ipfs_writel(tegra, reg, IPFS_XUSB_HOST_CONFIGURATION_0);
+ udelay(10);
+
+ /* Program BAR0 space */
+ reg = fpci_readl(tegra, XUSB_CFG_4);
+ reg &= ~(XUSB_BASE_ADDR_MASK << XUSB_BASE_ADDR_SHIFT);
+ reg |= tegra->hcd->rsrc_start & (XUSB_BASE_ADDR_MASK <<
+ XUSB_BASE_ADDR_SHIFT);
+ fpci_writel(tegra, reg, XUSB_CFG_4);
+ usleep_range(100, 200);
+
+ /* Enable bus master */
+ reg = fpci_readl(tegra, XUSB_CFG_1);
+ reg |= XUSB_IO_SPACE_EN | XUSB_MEM_SPACE_EN | XUSB_BUS_MASTER_EN;
+ fpci_writel(tegra, reg, XUSB_CFG_1);
+
+ /* Enable interrupt assertion */
+ reg = ipfs_readl(tegra, IPFS_XUSB_HOST_INTR_MASK_0);
+ reg |= IPFS_IP_INT_MASK;
+ ipfs_writel(tegra, reg, IPFS_XUSB_HOST_INTR_MASK_0);
+
+ /* Set hysteresis */
+ ipfs_writel(tegra, 0x80, IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_0);
+}
+
+static int tegra_xhci_load_firmware(struct tegra_xhci_hcd *tegra)
+{
+ struct device *dev = tegra->dev;
+ struct tegra_xhci_fw_cfgtbl *cfg_tbl;
+ struct tm fw_tm;
+ u32 val, code_tag_blocks, code_size_blocks;
+ u64 fw_base;
+ time_t fw_time;
+ unsigned long timeout;
+
+ if (csb_readl(tegra, XUSB_CSB_MP_ILOAD_BASE_LO) != 0) {
+ dev_info(dev, "Firmware already loaded, Falcon state 0x%x\n",
+ csb_readl(tegra, XUSB_FALC_CPUCTL));
+ return 0;
+ }
+
+ cfg_tbl = (struct tegra_xhci_fw_cfgtbl *)tegra->fw_data;
+
+ /* Program the size of DFI into ILOAD_ATTR. */
+ csb_writel(tegra, tegra->fw_size, XUSB_CSB_MP_ILOAD_ATTR);
+
+ /*
+ * Boot code of the firmware reads the ILOAD_BASE registers
+ * to get to the start of the DFI in system memory.
+ */
+ fw_base = tegra->fw_dma_addr + sizeof(*cfg_tbl);
+ csb_writel(tegra, fw_base, XUSB_CSB_MP_ILOAD_BASE_LO);
+ csb_writel(tegra, fw_base >> 32, XUSB_CSB_MP_ILOAD_BASE_HI);
+
+ /* Set BOOTPATH to 1 in APMAP. */
+ csb_writel(tegra, APMAP_BOOTPATH, XUSB_CSB_MP_APMAP);
+
+ /* Invalidate L2IMEM. */
+ csb_writel(tegra, L2IMEMOP_INVALIDATE_ALL, XUSB_CSB_MP_L2IMEMOP_TRIG);
+
+ /*
+ * Initiate fetch of bootcode from system memory into L2IMEM.
+ * Program bootcode location and size in system memory.
+ */
+ code_tag_blocks = DIV_ROUND_UP(le32_to_cpu(cfg_tbl->boot_codetag),
+ IMEM_BLOCK_SIZE);
+ code_size_blocks = DIV_ROUND_UP(le32_to_cpu(cfg_tbl->boot_codesize),
+ IMEM_BLOCK_SIZE);
+ val = ((code_tag_blocks & L2IMEMOP_SIZE_SRC_OFFSET_MASK) <<
+ L2IMEMOP_SIZE_SRC_OFFSET_SHIFT) |
+ ((code_size_blocks & L2IMEMOP_SIZE_SRC_COUNT_MASK) <<
+ L2IMEMOP_SIZE_SRC_COUNT_SHIFT);
+ csb_writel(tegra, val, XUSB_CSB_MP_L2IMEMOP_SIZE);
+
+ /* Trigger L2IMEM load operation. */
+ csb_writel(tegra, L2IMEMOP_LOAD_LOCKED_RESULT,
+ XUSB_CSB_MP_L2IMEMOP_TRIG);
+
+ /* Setup Falcon auto-fill. */
+ csb_writel(tegra, code_size_blocks, XUSB_FALC_IMFILLCTL);
+
+ val = ((code_tag_blocks & IMFILLRNG1_TAG_MASK) <<
+ IMFILLRNG1_TAG_LO_SHIFT) |
+ (((code_size_blocks + code_tag_blocks) & IMFILLRNG1_TAG_MASK) <<
+ IMFILLRNG1_TAG_HI_SHIFT);
+ csb_writel(tegra, val, XUSB_FALC_IMFILLRNG1);
+
+ csb_writel(tegra, 0, XUSB_FALC_DMACTL);
+ msleep(50);
+
+ csb_writel(tegra, le32_to_cpu(cfg_tbl->boot_codetag),
+ XUSB_FALC_BOOTVEC);
+
+ /* Boot Falcon CPU and wait for it to enter the STOPPED (idle) state. */
+ timeout = jiffies + msecs_to_jiffies(5);
+ csb_writel(tegra, CPUCTL_STARTCPU, XUSB_FALC_CPUCTL);
+ while (time_before(jiffies, timeout)) {
+ if (csb_readl(tegra, XUSB_FALC_CPUCTL) == CPUCTL_STATE_STOPPED)
+ break;
+ usleep_range(100, 200);
+ }
+ if (csb_readl(tegra, XUSB_FALC_CPUCTL) != CPUCTL_STATE_STOPPED) {
+ dev_err(dev, "Falcon failed to start, state: %#x\n",
+ csb_readl(tegra, XUSB_FALC_CPUCTL));
+ return -EIO;
+ }
+
+ fw_time = le32_to_cpu(cfg_tbl->fwimg_created_time);
+ time_to_tm(fw_time, 0, &fw_tm);
+ dev_info(dev, "Firmware timestamp: %ld-%02d-%02d %02d:%02d:%02d UTC\n",
+ fw_tm.tm_year + 1900, fw_tm.tm_mon + 1, fw_tm.tm_mday,
+ fw_tm.tm_hour, fw_tm.tm_min, fw_tm.tm_sec);
+
+ return 0;
+}
+
+static int tegra_xhci_set_ss_clk(struct tegra_xhci_hcd *tegra,
+ unsigned long rate)
+{
+ struct clk *clk = tegra->ss_src_clk;
+ unsigned long new_parent_rate, old_parent_rate;
+ int ret, div;
+
+ if (clk_get_rate(clk) == rate)
+ return 0;
+
+ switch (rate) {
+ case TEGRA_XHCI_SS_CLK_HIGH_SPEED:
+ /*
+ * Reparent to PLLU_480M. Set divider first to avoid
+ * overclocking.
+ */
+ old_parent_rate = clk_get_rate(clk_get_parent(clk));
+ new_parent_rate = clk_get_rate(tegra->pll_u_480m);
+ div = new_parent_rate / rate;
+ ret = clk_set_rate(clk, old_parent_rate / div);
+ if (ret)
+ return ret;
+ ret = clk_set_parent(clk, tegra->pll_u_480m);
+ if (ret)
+ return ret;
+ /*
+ * The rate should already be correct, but set it again just
+ * to be sure.
+ */
+ ret = clk_set_rate(clk, rate);
+ if (ret)
+ return ret;
+ break;
+ case TEGRA_XHCI_SS_CLK_LOW_SPEED:
+ /* Reparent to CLK_M */
+ ret = clk_set_parent(clk, tegra->clk_m);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(clk, rate);
+ if (ret)
+ return ret;
+ break;
+ default:
+ dev_err(tegra->dev, "Invalid SS rate: %lu\n", rate);
+ return -EINVAL;
+ }
+
+ if (clk_get_rate(clk) != rate) {
+ dev_err(tegra->dev, "SS clock doesn't match requested rate\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int tegra_xhci_clk_enable(struct tegra_xhci_hcd *tegra)
+{
+ int ret;
+
+ ret = clk_prepare_enable(tegra->pll_e);
+ if (ret < 0)
+ return ret;
+ ret = clk_prepare_enable(tegra->host_clk);
+ if (ret < 0)
+ goto disable_plle;
+ ret = clk_prepare_enable(tegra->ss_clk);
+ if (ret < 0)
+ goto disable_host;
+ ret = clk_prepare_enable(tegra->falc_clk);
+ if (ret < 0)
+ goto disable_ss;
+ ret = clk_prepare_enable(tegra->fs_src_clk);
+ if (ret < 0)
+ goto disable_falc;
+ ret = clk_prepare_enable(tegra->hs_src_clk);
+ if (ret < 0)
+ goto disable_fs_src;
+ ret = tegra_xhci_set_ss_clk(tegra, TEGRA_XHCI_SS_CLK_HIGH_SPEED);
+ if (ret < 0)
+ goto disable_hs_src;
+
+ return 0;
+
+disable_hs_src:
+ clk_disable_unprepare(tegra->hs_src_clk);
+disable_fs_src:
+ clk_disable_unprepare(tegra->fs_src_clk);
+disable_falc:
+ clk_disable_unprepare(tegra->falc_clk);
+disable_ss:
+ clk_disable_unprepare(tegra->ss_clk);
+disable_host:
+ clk_disable_unprepare(tegra->host_clk);
+disable_plle:
+ clk_disable_unprepare(tegra->pll_e);
+ return ret;
+}
+
+static void tegra_xhci_clk_disable(struct tegra_xhci_hcd *tegra)
+{
+ clk_disable_unprepare(tegra->pll_e);
+ clk_disable_unprepare(tegra->host_clk);
+ clk_disable_unprepare(tegra->ss_clk);
+ clk_disable_unprepare(tegra->falc_clk);
+ clk_disable_unprepare(tegra->fs_src_clk);
+ clk_disable_unprepare(tegra->hs_src_clk);
+}
+
+static int tegra_xhci_phy_enable(struct tegra_xhci_hcd *tegra)
+{
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < tegra->num_phys; i++) {
+ ret = phy_init(tegra->phys[i]);
+ if (ret)
+ goto disable_phy;
+ ret = phy_power_on(tegra->phys[i]);
+ if (ret) {
+ phy_exit(tegra->phys[i]);
+ goto disable_phy;
+ }
+ }
+
+ return 0;
+disable_phy:
+ for (; i > 0; i--) {
+ phy_power_off(tegra->phys[i - 1]);
+ phy_exit(tegra->phys[i - 1]);
+ }
+ return ret;
+}
+
+static void tegra_xhci_phy_disable(struct tegra_xhci_hcd *tegra)
+{
+ unsigned int i;
+
+ for (i = 0; i < tegra->num_phys; i++) {
+ phy_power_off(tegra->phys[i]);
+ phy_exit(tegra->phys[i]);
+ }
+}
+
+static bool is_host_mbox_message(u32 cmd)
+{
+ switch (cmd) {
+ case MBOX_CMD_INC_SSPI_CLOCK:
+ case MBOX_CMD_DEC_SSPI_CLOCK:
+ case MBOX_CMD_INC_FALC_CLOCK:
+ case MBOX_CMD_DEC_FALC_CLOCK:
+ case MBOX_CMD_SET_BW:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static void tegra_xhci_mbox_work(struct work_struct *work)
+{
+ struct tegra_xhci_hcd *tegra = mbox_work_to_tegra(work);
+ struct tegra_xusb_mbox_msg *msg = &tegra->mbox_req;
+ struct tegra_xusb_mbox_msg resp;
+ int ret;
+
+ resp.cmd = 0;
+ switch (msg->cmd) {
+ case MBOX_CMD_INC_SSPI_CLOCK:
+ case MBOX_CMD_DEC_SSPI_CLOCK:
+ ret = tegra_xhci_set_ss_clk(tegra, msg->data * 1000);
+ resp.data = clk_get_rate(tegra->ss_src_clk) / 1000;
+ if (ret)
+ resp.cmd = MBOX_CMD_NAK;
+ else
+ resp.cmd = MBOX_CMD_ACK;
+ break;
+ case MBOX_CMD_INC_FALC_CLOCK:
+ case MBOX_CMD_DEC_FALC_CLOCK:
+ resp.data = clk_get_rate(tegra->falc_clk) / 1000;
+ if (resp.data != msg->data)
+ resp.cmd = MBOX_CMD_NAK;
+ else
+ resp.cmd = MBOX_CMD_ACK;
+ break;
+ case MBOX_CMD_SET_BW:
+ /*
+ * TODO: Request bandwidth once EMC scaling is supported.
+ * Ignore for now since ACK/NAK is not required for SET_BW
+ * messages.
+ */
+ break;
+ default:
+ break;
+ }
+
+ if (resp.cmd)
+ mbox_send_message(tegra->mbox_chan, &resp);
+}
+
+static void tegra_xhci_mbox_rx(struct mbox_client *cl, void *data)
+{
+ struct tegra_xhci_hcd *tegra = dev_get_drvdata(cl->dev);
+ struct tegra_xusb_mbox_msg *msg = data;
+
+ if (is_host_mbox_message(msg->cmd)) {
+ tegra->mbox_req = *msg;
+ schedule_work(&tegra->mbox_req_work);
+ }
+}
+
+static void tegra_xhci_quirks(struct device *dev, struct xhci_hcd *xhci)
+{
+ xhci->quirks |= XHCI_PLAT;
+}
+
+static int tegra_xhci_setup(struct usb_hcd *hcd)
+{
+ return xhci_gen_setup(hcd, tegra_xhci_quirks);
+}
+
+static const char * const tegra124_supply_names[] = {
+ "avddio-pex",
+ "dvddio-pex",
+ "avdd-usb",
+ "avdd-pll-utmip",
+ "avdd-pll-erefe",
+ "avdd-usb-ss-pll",
+ "hvdd-usb-ss",
+ "hvdd-usb-ss-pll-e",
+};
+
+static const struct tegra_xhci_phy_type tegra124_phy_types[] = {
+ { .name = "usb3", .num = 2, },
+ { .name = "utmi", .num = 3, },
+ { .name = "hsic", .num = 2, },
+};
+
+static const struct tegra_xhci_soc_data tegra124_soc_data = {
+ .firmware_file = "nvidia/tegra124/xusb.bin",
+ .supply_names = tegra124_supply_names,
+ .num_supplies = ARRAY_SIZE(tegra124_supply_names),
+ .phy_types = tegra124_phy_types,
+ .num_types = ARRAY_SIZE(tegra124_phy_types),
+};
+MODULE_FIRMWARE("nvidia/tegra124/xusb.bin");
+
+static const struct of_device_id tegra_xhci_of_match[] = {
+ { .compatible = "nvidia,tegra124-xhci", .data = &tegra124_soc_data },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tegra_xhci_of_match);
+
+static void tegra_xhci_probe_finish(const struct firmware *fw, void *context)
+{
+ struct tegra_xhci_hcd *tegra = context;
+ struct device *dev = tegra->dev;
+ struct xhci_hcd *xhci = NULL;
+ struct tegra_xhci_fw_cfgtbl *cfg_tbl;
+ struct tegra_xusb_mbox_msg msg;
+ int ret;
+
+ if (!fw)
+ goto put_usb2_hcd;
+
+ /* Load Falcon controller with its firmware. */
+ cfg_tbl = (struct tegra_xhci_fw_cfgtbl *)fw->data;
+ tegra->fw_size = le32_to_cpu(cfg_tbl->fwimg_len);
+ tegra->fw_data = dma_alloc_coherent(dev, tegra->fw_size,
+ &tegra->fw_dma_addr,
+ GFP_KERNEL);
+ if (!tegra->fw_data)
+ goto put_usb2_hcd;
+ memcpy(tegra->fw_data, fw->data, tegra->fw_size);
+
+ ret = tegra_xhci_load_firmware(tegra);
+ if (ret < 0)
+ goto put_usb2_hcd;
+
+ ret = usb_add_hcd(tegra->hcd, tegra->irq, IRQF_SHARED);
+ if (ret < 0)
+ goto put_usb2_hcd;
+ device_wakeup_enable(tegra->hcd->self.controller);
+
+ /*
+ * USB 2.0 roothub is stored in drvdata now. Swap it with the Tegra HCD.
+ */
+ tegra->hcd = dev_get_drvdata(dev);
+ dev_set_drvdata(dev, tegra);
+ xhci = hcd_to_xhci(tegra->hcd);
+ xhci->shared_hcd = usb_create_shared_hcd(&tegra_xhci_hc_driver,
+ dev, dev_name(dev),
+ tegra->hcd);
+ if (!xhci->shared_hcd)
+ goto dealloc_usb2_hcd;
+
+ ret = usb_add_hcd(xhci->shared_hcd, tegra->irq, IRQF_SHARED);
+ if (ret < 0)
+ goto put_usb3_hcd;
+
+ /* Enable firmware messages from controller. */
+ msg.cmd = MBOX_CMD_MSG_ENABLED;
+ msg.data = 0;
+ ret = mbox_send_message(tegra->mbox_chan, &msg);
+ if (ret < 0)
+ goto dealloc_usb3_hcd;
+
+ tegra->fw_loaded = true;
+ release_firmware(fw);
+ return;
+
+ /* Free up as much as we can and wait to be unbound. */
+dealloc_usb3_hcd:
+ usb_remove_hcd(xhci->shared_hcd);
+put_usb3_hcd:
+ usb_put_hcd(xhci->shared_hcd);
+dealloc_usb2_hcd:
+ usb_remove_hcd(tegra->hcd);
+ kfree(xhci);
+put_usb2_hcd:
+ usb_put_hcd(tegra->hcd);
+ tegra->hcd = NULL;
+ release_firmware(fw);
+}
+
+static int tegra_xhci_probe(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+ struct tegra_xhci_hcd *tegra;
+ struct resource *res;
+ struct usb_hcd *hcd;
+ struct phy *phy;
+ unsigned int i, j, k;
+ int ret;
+
+ BUILD_BUG_ON(sizeof(struct tegra_xhci_fw_cfgtbl) != 256);
+
+ tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
+ if (!tegra)
+ return -ENOMEM;
+ tegra->dev = &pdev->dev;
+ platform_set_drvdata(pdev, tegra);
+
+ match = of_match_device(tegra_xhci_of_match, &pdev->dev);
+ tegra->soc = match->data;
+
+ hcd = usb_create_hcd(&tegra_xhci_hc_driver, &pdev->dev,
+ dev_name(&pdev->dev));
+ if (!hcd)
+ return -ENOMEM;
+ tegra->hcd = hcd;
+
+ tegra->fpci_regs = dev_get_drvdata(pdev->dev.parent);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hcd->regs)) {
+ ret = PTR_ERR(hcd->regs);
+ goto put_hcd;
+ }
+ hcd->rsrc_start = res->start;
+ hcd->rsrc_len = resource_size(res);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ tegra->ipfs_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(tegra->ipfs_base)) {
+ ret = PTR_ERR(tegra->ipfs_base);
+ goto put_hcd;
+ }
+
+ tegra->irq = platform_get_irq(pdev, 0);
+ if (tegra->irq < 0) {
+ ret = tegra->irq;
+ goto put_hcd;
+ }
+
+ tegra->host_rst = devm_reset_control_get(&pdev->dev, "xusb_host");
+ if (IS_ERR(tegra->host_rst)) {
+ ret = PTR_ERR(tegra->host_rst);
+ goto put_hcd;
+ }
+ tegra->ss_rst = devm_reset_control_get(&pdev->dev, "xusb_ss");
+ if (IS_ERR(tegra->ss_rst)) {
+ ret = PTR_ERR(tegra->ss_rst);
+ goto put_hcd;
+ }
+
+ tegra->host_clk = devm_clk_get(&pdev->dev, "xusb_host");
+ if (IS_ERR(tegra->host_clk)) {
+ ret = PTR_ERR(tegra->host_clk);
+ goto put_hcd;
+ }
+ tegra->falc_clk = devm_clk_get(&pdev->dev, "xusb_falcon_src");
+ if (IS_ERR(tegra->falc_clk)) {
+ ret = PTR_ERR(tegra->falc_clk);
+ goto put_hcd;
+ }
+ tegra->ss_clk = devm_clk_get(&pdev->dev, "xusb_ss");
+ if (IS_ERR(tegra->ss_clk)) {
+ ret = PTR_ERR(tegra->ss_clk);
+ goto put_hcd;
+ }
+ tegra->ss_src_clk = devm_clk_get(&pdev->dev, "xusb_ss_src");
+ if (IS_ERR(tegra->ss_src_clk)) {
+ ret = PTR_ERR(tegra->ss_src_clk);
+ goto put_hcd;
+ }
+ tegra->hs_src_clk = devm_clk_get(&pdev->dev, "xusb_hs_src");
+ if (IS_ERR(tegra->hs_src_clk)) {
+ ret = PTR_ERR(tegra->hs_src_clk);
+ goto put_hcd;
+ }
+ tegra->fs_src_clk = devm_clk_get(&pdev->dev, "xusb_fs_src");
+ if (IS_ERR(tegra->fs_src_clk)) {
+ ret = PTR_ERR(tegra->fs_src_clk);
+ goto put_hcd;
+ }
+ tegra->pll_u_480m = devm_clk_get(&pdev->dev, "pll_u_480m");
+ if (IS_ERR(tegra->pll_u_480m)) {
+ ret = PTR_ERR(tegra->pll_u_480m);
+ goto put_hcd;
+ }
+ tegra->clk_m = devm_clk_get(&pdev->dev, "clk_m");
+ if (IS_ERR(tegra->clk_m)) {
+ ret = PTR_ERR(tegra->clk_m);
+ goto put_hcd;
+ }
+ tegra->pll_e = devm_clk_get(&pdev->dev, "pll_e");
+ if (IS_ERR(tegra->pll_e)) {
+ ret = PTR_ERR(tegra->pll_e);
+ goto put_hcd;
+ }
+ ret = tegra_xhci_clk_enable(tegra);
+ if (ret)
+ goto put_hcd;
+
+ tegra->supplies = devm_kcalloc(&pdev->dev, tegra->soc->num_supplies,
+ sizeof(*tegra->supplies), GFP_KERNEL);
+ if (!tegra->supplies) {
+ ret = -ENOMEM;
+ goto put_hcd;
+ }
+ for (i = 0; i < tegra->soc->num_supplies; i++)
+ tegra->supplies[i].supply = tegra->soc->supply_names[i];
+ ret = devm_regulator_bulk_get(&pdev->dev, tegra->soc->num_supplies,
+ tegra->supplies);
+ if (ret)
+ goto disable_clk;
+ ret = regulator_bulk_enable(tegra->soc->num_supplies, tegra->supplies);
+ if (ret)
+ goto disable_clk;
+
+ INIT_WORK(&tegra->mbox_req_work, tegra_xhci_mbox_work);
+ tegra->mbox_client.dev = &pdev->dev;
+ tegra->mbox_client.tx_block = true;
+ tegra->mbox_client.tx_tout = 0;
+ tegra->mbox_client.rx_callback = tegra_xhci_mbox_rx;
+ tegra->mbox_chan = mbox_request_channel(&tegra->mbox_client, 0);
+ if (IS_ERR(tegra->mbox_chan)) {
+ ret = PTR_ERR(tegra->mbox_chan);
+ goto disable_regulator;
+ }
+
+ for (i = 0; i < tegra->soc->num_types; i++)
+ tegra->num_phys += tegra->soc->phy_types[i].num;
+ tegra->phys = devm_kcalloc(&pdev->dev, tegra->num_phys,
+ sizeof(*tegra->phys), GFP_KERNEL);
+ if (!tegra->phys) {
+ ret = -ENOMEM;
+ goto put_mbox;
+ }
+ for (i = 0, k = 0; i < tegra->soc->num_types; i++) {
+ char prop[8];
+
+ for (j = 0; j < tegra->soc->phy_types[i].num; j++) {
+ snprintf(prop, sizeof(prop), "%s-%d",
+ tegra->soc->phy_types[i].name, j);
+ phy = devm_phy_optional_get(&pdev->dev, prop);
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ goto put_mbox;
+ }
+ tegra->phys[k++] = phy;
+ }
+ }
+
+ tegra_xhci_ipfs_config(tegra);
+
+ ret = tegra_xhci_phy_enable(tegra);
+ if (ret < 0)
+ goto put_mbox;
+
+ ret = request_firmware_nowait(THIS_MODULE, true,
+ tegra->soc->firmware_file,
+ tegra->dev, GFP_KERNEL, tegra,
+ tegra_xhci_probe_finish);
+ if (ret < 0)
+ goto disable_phy;
+
+ return 0;
+
+disable_phy:
+ tegra_xhci_phy_disable(tegra);
+put_mbox:
+ mbox_free_channel(tegra->mbox_chan);
+disable_regulator:
+ regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
+disable_clk:
+ tegra_xhci_clk_disable(tegra);
+put_hcd:
+ usb_put_hcd(hcd);
+ return ret;
+}
+
+static int tegra_xhci_remove(struct platform_device *pdev)
+{
+ struct tegra_xhci_hcd *tegra = platform_get_drvdata(pdev);
+ struct usb_hcd *hcd = tegra->hcd;
+ struct xhci_hcd *xhci;
+
+ if (tegra->fw_loaded) {
+ xhci = hcd_to_xhci(hcd);
+ usb_remove_hcd(xhci->shared_hcd);
+ usb_put_hcd(xhci->shared_hcd);
+ usb_remove_hcd(hcd);
+ usb_put_hcd(hcd);
+ kfree(xhci);
+ } else if (hcd) {
+ /* Unbound after probe(), but before firmware loading. */
+ usb_put_hcd(hcd);
+ }
+
+ if (tegra->fw_data)
+ dma_free_coherent(tegra->dev, tegra->fw_size, tegra->fw_data,
+ tegra->fw_dma_addr);
+
+ cancel_work_sync(&tegra->mbox_req_work);
+ mbox_free_channel(tegra->mbox_chan);
+ tegra_xhci_phy_disable(tegra);
+ regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
+ tegra_xhci_clk_disable(tegra);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int tegra_xhci_suspend(struct device *dev)
+{
+ struct tegra_xhci_hcd *tegra = dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(tegra->hcd);
+ bool wakeup = device_may_wakeup(dev);
+
+ /* TODO: Powergate controller across suspend/resume. */
+ return xhci_suspend(xhci, wakeup);
+}
+
+static int tegra_xhci_resume(struct device *dev)
+{
+ struct tegra_xhci_hcd *tegra = dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(tegra->hcd);
+
+ return xhci_resume(xhci, 0);
+}
+#endif
+
+static const struct dev_pm_ops tegra_xhci_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(tegra_xhci_suspend, tegra_xhci_resume)
+};
+
+static struct platform_driver tegra_xhci_driver = {
+ .probe = tegra_xhci_probe,
+ .remove = tegra_xhci_remove,
+ .driver = {
+ .name = "tegra-xhci",
+ .pm = &tegra_xhci_pm_ops,
+ .of_match_table = tegra_xhci_of_match,
+ },
+};
+
+static int __init tegra_xhci_init(void)
+{
+ xhci_init_driver(&tegra_xhci_hc_driver, tegra_xhci_setup);
+ return platform_driver_register(&tegra_xhci_driver);
+}
+module_init(tegra_xhci_init);
+
+static void __exit tegra_xhci_exit(void)
+{
+ platform_driver_unregister(&tegra_xhci_driver);
+}
+module_exit(tegra_xhci_exit);
+
+MODULE_AUTHOR("Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>");
+MODULE_DESCRIPTION("NVIDIA Tegra xHCI host-controller driver");
+MODULE_LICENSE("GPL v2");
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 9/9] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: linux-arm-kernel
Add support for the on-chip xHCI host controller present on Tegra SoCs.
The controller requires external firmware which must be loaded before
using the controller. This driver loads the firmware, starts the
controller, and is able to service host-specific messages sent by
the controller's firmware.
The controller also supports USB device mode as well as powergating
of the SuperSpeed and host-controller logic when not in use, but
support for these is not yet implemented.
Based on work by:
Ajay Gupta <ajayg@nvidia.com>
Bharath Yadav <byadav@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
No changes from v7.
Changes from v6:
- Access FPCI registers using parent MFD's regmap.
- Made regulator names and PHY types part of the SoC-specific data
since they will be different on Tegra210.
- Other cosmetic cleanups.
Changes from v5:
- Added dependency on COMPILE_TEST and MAILBOX.
- Added TODO about powergating support.
Changes from v4:
- Poll for controller to finish booting.
- Addressed review comments from Thierry.
Changes from v3:
- Used 32-bit DMA mask (platforms may have > 32-bit physical address space
and < 64-bit dma_addr_t).
- Moved comment about SET_BW command.
Changes from v2:
- Added filtering out of non-host mailbox messages.
- Removed MODULE_ALIAS.
Changes from v1:
- Updated to use common mailbox API.
- Fixed up so that the driver can be built and used as a module.
- Incorporated review feedback from Stephen.
- Misc. cleanups.
---
drivers/usb/host/Kconfig | 10 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/xhci-tegra.c | 947 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 958 insertions(+)
create mode 100644 drivers/usb/host/xhci-tegra.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 197a6a3..22601d0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -50,6 +50,16 @@ config USB_XHCI_RCAR
Say 'Y' to enable the support for the xHCI host controller
found in Renesas R-Car ARM SoCs.
+config USB_XHCI_TEGRA
+ tristate "xHCI support for NVIDIA Tegra SoCs"
+ depends on MFD_TEGRA_XUSB || COMPILE_TEST
+ depends on MAILBOX
+ depends on RESET_CONTROLLER
+ select FW_LOADER
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in NVIDIA Tegra124 and later SoCs.
+
endif # USB_XHCI_HCD
config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 65b0b6a..1b98107 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PCI) += pci-quirks.o
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_TEGRA) += xhci-tegra.o
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
new file mode 100644
index 0000000..d510dc5
--- /dev/null
+++ b/drivers/usb/host/xhci-tegra.c
@@ -0,0 +1,947 @@
+/*
+ * NVIDIA Tegra xHCI host controller driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/firmware.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_client.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+
+#include <soc/tegra/xusb.h>
+
+#include "xhci.h"
+
+#define TEGRA_XHCI_SS_CLK_HIGH_SPEED 120000000
+#define TEGRA_XHCI_SS_CLK_LOW_SPEED 12000000
+
+/* FPCI CFG registers */
+#define XUSB_CFG_1 0x004
+#define XUSB_IO_SPACE_EN BIT(0)
+#define XUSB_MEM_SPACE_EN BIT(1)
+#define XUSB_BUS_MASTER_EN BIT(2)
+#define XUSB_CFG_4 0x010
+#define XUSB_BASE_ADDR_SHIFT 15
+#define XUSB_BASE_ADDR_MASK 0x1ffff
+#define XUSB_CFG_ARU_C11_CSBRANGE 0x41c
+#define XUSB_CFG_CSB_BASE_ADDR 0x800
+
+/* IPFS registers */
+#define IPFS_XUSB_HOST_CONFIGURATION_0 0x180
+#define IPFS_EN_FPCI BIT(0)
+#define IPFS_XUSB_HOST_INTR_MASK_0 0x188
+#define IPFS_IP_INT_MASK BIT(16)
+#define IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_0 0x1bc
+
+#define CSB_PAGE_SELECT_MASK 0x7fffff
+#define CSB_PAGE_SELECT_SHIFT 9
+#define CSB_PAGE_OFFSET_MASK 0x1ff
+#define CSB_PAGE_SELECT(addr) ((addr) >> (CSB_PAGE_SELECT_SHIFT) & \
+ CSB_PAGE_SELECT_MASK)
+#define CSB_PAGE_OFFSET(addr) ((addr) & CSB_PAGE_OFFSET_MASK)
+
+/* Falcon CSB registers */
+#define XUSB_FALC_CPUCTL 0x100
+#define CPUCTL_STARTCPU BIT(1)
+#define CPUCTL_STATE_HALTED BIT(4)
+#define CPUCTL_STATE_STOPPED BIT(5)
+#define XUSB_FALC_BOOTVEC 0x104
+#define XUSB_FALC_DMACTL 0x10c
+#define XUSB_FALC_IMFILLRNG1 0x154
+#define IMFILLRNG1_TAG_MASK 0xffff
+#define IMFILLRNG1_TAG_LO_SHIFT 0
+#define IMFILLRNG1_TAG_HI_SHIFT 16
+#define XUSB_FALC_IMFILLCTL 0x158
+
+/* MP CSB registers */
+#define XUSB_CSB_MP_ILOAD_ATTR 0x101a00
+#define XUSB_CSB_MP_ILOAD_BASE_LO 0x101a04
+#define XUSB_CSB_MP_ILOAD_BASE_HI 0x101a08
+#define XUSB_CSB_MP_L2IMEMOP_SIZE 0x101a10
+#define L2IMEMOP_SIZE_SRC_OFFSET_SHIFT 8
+#define L2IMEMOP_SIZE_SRC_OFFSET_MASK 0x3ff
+#define L2IMEMOP_SIZE_SRC_COUNT_SHIFT 24
+#define L2IMEMOP_SIZE_SRC_COUNT_MASK 0xff
+#define XUSB_CSB_MP_L2IMEMOP_TRIG 0x101a14
+#define L2IMEMOP_ACTION_SHIFT 24
+#define L2IMEMOP_INVALIDATE_ALL (0x40 << L2IMEMOP_ACTION_SHIFT)
+#define L2IMEMOP_LOAD_LOCKED_RESULT (0x11 << L2IMEMOP_ACTION_SHIFT)
+#define XUSB_CSB_MP_APMAP 0x10181c
+#define APMAP_BOOTPATH BIT(31)
+
+#define IMEM_BLOCK_SIZE 256
+
+struct tegra_xhci_fw_cfgtbl {
+ u32 boot_loadaddr_in_imem;
+ u32 boot_codedfi_offset;
+ u32 boot_codetag;
+ u32 boot_codesize;
+ u32 phys_memaddr;
+ u16 reqphys_memsize;
+ u16 alloc_phys_memsize;
+ u32 rodata_img_offset;
+ u32 rodata_section_start;
+ u32 rodata_section_end;
+ u32 main_fnaddr;
+ u32 fwimg_cksum;
+ u32 fwimg_created_time;
+ u32 imem_resident_start;
+ u32 imem_resident_end;
+ u32 idirect_start;
+ u32 idirect_end;
+ u32 l2_imem_start;
+ u32 l2_imem_end;
+ u32 version_id;
+ u8 init_ddirect;
+ u8 reserved[3];
+ u32 phys_addr_log_buffer;
+ u32 total_log_entries;
+ u32 dequeue_ptr;
+ u32 dummy_var[2];
+ u32 fwimg_len;
+ u8 magic[8];
+ u32 ss_low_power_entry_timeout;
+ u8 num_hsic_port;
+ u8 padding[139]; /* Pad to 256 bytes */
+};
+
+struct tegra_xhci_phy_type {
+ const char *name;
+ unsigned int num;
+};
+
+struct tegra_xhci_soc_data {
+ const char *firmware_file;
+ const char * const *supply_names;
+ unsigned int num_supplies;
+ const struct tegra_xhci_phy_type *phy_types;
+ unsigned int num_types;
+};
+
+struct tegra_xhci_hcd {
+ struct device *dev;
+ struct usb_hcd *hcd;
+
+ int irq;
+
+ void __iomem *ipfs_base;
+ struct regmap *fpci_regs;
+
+ const struct tegra_xhci_soc_data *soc;
+
+ struct regulator_bulk_data *supplies;
+
+ struct clk *host_clk;
+ struct clk *falc_clk;
+ struct clk *ss_clk;
+ struct clk *ss_src_clk;
+ struct clk *hs_src_clk;
+ struct clk *fs_src_clk;
+ struct clk *pll_u_480m;
+ struct clk *clk_m;
+ struct clk *pll_e;
+
+ struct reset_control *host_rst;
+ struct reset_control *ss_rst;
+
+ struct phy **phys;
+ unsigned int num_phys;
+
+ struct work_struct mbox_req_work;
+ struct tegra_xusb_mbox_msg mbox_req;
+ struct mbox_client mbox_client;
+ struct mbox_chan *mbox_chan;
+
+ /* Firmware loading related */
+ void *fw_data;
+ size_t fw_size;
+ dma_addr_t fw_dma_addr;
+ bool fw_loaded;
+};
+
+static struct hc_driver __read_mostly tegra_xhci_hc_driver;
+
+static inline struct tegra_xhci_hcd *
+mbox_work_to_tegra(struct work_struct *work)
+{
+ return container_of(work, struct tegra_xhci_hcd, mbox_req_work);
+}
+
+static inline u32 fpci_readl(struct tegra_xhci_hcd *tegra, u32 addr)
+{
+ u32 val;
+
+ regmap_read(tegra->fpci_regs, addr, &val);
+
+ return val;
+}
+
+static inline void fpci_writel(struct tegra_xhci_hcd *tegra, u32 val, u32 addr)
+{
+ regmap_write(tegra->fpci_regs, addr, val);
+}
+
+static inline u32 ipfs_readl(struct tegra_xhci_hcd *tegra, u32 addr)
+{
+ return readl(tegra->ipfs_base + addr);
+}
+
+static inline void ipfs_writel(struct tegra_xhci_hcd *tegra, u32 val, u32 addr)
+{
+ writel(val, tegra->ipfs_base + addr);
+}
+
+static u32 csb_readl(struct tegra_xhci_hcd *tegra, u32 addr)
+{
+ u32 page, offset;
+
+ page = CSB_PAGE_SELECT(addr);
+ offset = CSB_PAGE_OFFSET(addr);
+ fpci_writel(tegra, page, XUSB_CFG_ARU_C11_CSBRANGE);
+ return fpci_readl(tegra, XUSB_CFG_CSB_BASE_ADDR + offset);
+}
+
+static void csb_writel(struct tegra_xhci_hcd *tegra, u32 val, u32 addr)
+{
+ u32 page, offset;
+
+ page = CSB_PAGE_SELECT(addr);
+ offset = CSB_PAGE_OFFSET(addr);
+ fpci_writel(tegra, page, XUSB_CFG_ARU_C11_CSBRANGE);
+ fpci_writel(tegra, val, XUSB_CFG_CSB_BASE_ADDR + offset);
+}
+
+static void tegra_xhci_ipfs_config(struct tegra_xhci_hcd *tegra)
+{
+ u32 reg;
+
+ reg = ipfs_readl(tegra, IPFS_XUSB_HOST_CONFIGURATION_0);
+ reg |= IPFS_EN_FPCI;
+ ipfs_writel(tegra, reg, IPFS_XUSB_HOST_CONFIGURATION_0);
+ udelay(10);
+
+ /* Program BAR0 space */
+ reg = fpci_readl(tegra, XUSB_CFG_4);
+ reg &= ~(XUSB_BASE_ADDR_MASK << XUSB_BASE_ADDR_SHIFT);
+ reg |= tegra->hcd->rsrc_start & (XUSB_BASE_ADDR_MASK <<
+ XUSB_BASE_ADDR_SHIFT);
+ fpci_writel(tegra, reg, XUSB_CFG_4);
+ usleep_range(100, 200);
+
+ /* Enable bus master */
+ reg = fpci_readl(tegra, XUSB_CFG_1);
+ reg |= XUSB_IO_SPACE_EN | XUSB_MEM_SPACE_EN | XUSB_BUS_MASTER_EN;
+ fpci_writel(tegra, reg, XUSB_CFG_1);
+
+ /* Enable interrupt assertion */
+ reg = ipfs_readl(tegra, IPFS_XUSB_HOST_INTR_MASK_0);
+ reg |= IPFS_IP_INT_MASK;
+ ipfs_writel(tegra, reg, IPFS_XUSB_HOST_INTR_MASK_0);
+
+ /* Set hysteresis */
+ ipfs_writel(tegra, 0x80, IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_0);
+}
+
+static int tegra_xhci_load_firmware(struct tegra_xhci_hcd *tegra)
+{
+ struct device *dev = tegra->dev;
+ struct tegra_xhci_fw_cfgtbl *cfg_tbl;
+ struct tm fw_tm;
+ u32 val, code_tag_blocks, code_size_blocks;
+ u64 fw_base;
+ time_t fw_time;
+ unsigned long timeout;
+
+ if (csb_readl(tegra, XUSB_CSB_MP_ILOAD_BASE_LO) != 0) {
+ dev_info(dev, "Firmware already loaded, Falcon state 0x%x\n",
+ csb_readl(tegra, XUSB_FALC_CPUCTL));
+ return 0;
+ }
+
+ cfg_tbl = (struct tegra_xhci_fw_cfgtbl *)tegra->fw_data;
+
+ /* Program the size of DFI into ILOAD_ATTR. */
+ csb_writel(tegra, tegra->fw_size, XUSB_CSB_MP_ILOAD_ATTR);
+
+ /*
+ * Boot code of the firmware reads the ILOAD_BASE registers
+ * to get to the start of the DFI in system memory.
+ */
+ fw_base = tegra->fw_dma_addr + sizeof(*cfg_tbl);
+ csb_writel(tegra, fw_base, XUSB_CSB_MP_ILOAD_BASE_LO);
+ csb_writel(tegra, fw_base >> 32, XUSB_CSB_MP_ILOAD_BASE_HI);
+
+ /* Set BOOTPATH to 1 in APMAP. */
+ csb_writel(tegra, APMAP_BOOTPATH, XUSB_CSB_MP_APMAP);
+
+ /* Invalidate L2IMEM. */
+ csb_writel(tegra, L2IMEMOP_INVALIDATE_ALL, XUSB_CSB_MP_L2IMEMOP_TRIG);
+
+ /*
+ * Initiate fetch of bootcode from system memory into L2IMEM.
+ * Program bootcode location and size in system memory.
+ */
+ code_tag_blocks = DIV_ROUND_UP(le32_to_cpu(cfg_tbl->boot_codetag),
+ IMEM_BLOCK_SIZE);
+ code_size_blocks = DIV_ROUND_UP(le32_to_cpu(cfg_tbl->boot_codesize),
+ IMEM_BLOCK_SIZE);
+ val = ((code_tag_blocks & L2IMEMOP_SIZE_SRC_OFFSET_MASK) <<
+ L2IMEMOP_SIZE_SRC_OFFSET_SHIFT) |
+ ((code_size_blocks & L2IMEMOP_SIZE_SRC_COUNT_MASK) <<
+ L2IMEMOP_SIZE_SRC_COUNT_SHIFT);
+ csb_writel(tegra, val, XUSB_CSB_MP_L2IMEMOP_SIZE);
+
+ /* Trigger L2IMEM load operation. */
+ csb_writel(tegra, L2IMEMOP_LOAD_LOCKED_RESULT,
+ XUSB_CSB_MP_L2IMEMOP_TRIG);
+
+ /* Setup Falcon auto-fill. */
+ csb_writel(tegra, code_size_blocks, XUSB_FALC_IMFILLCTL);
+
+ val = ((code_tag_blocks & IMFILLRNG1_TAG_MASK) <<
+ IMFILLRNG1_TAG_LO_SHIFT) |
+ (((code_size_blocks + code_tag_blocks) & IMFILLRNG1_TAG_MASK) <<
+ IMFILLRNG1_TAG_HI_SHIFT);
+ csb_writel(tegra, val, XUSB_FALC_IMFILLRNG1);
+
+ csb_writel(tegra, 0, XUSB_FALC_DMACTL);
+ msleep(50);
+
+ csb_writel(tegra, le32_to_cpu(cfg_tbl->boot_codetag),
+ XUSB_FALC_BOOTVEC);
+
+ /* Boot Falcon CPU and wait for it to enter the STOPPED (idle) state. */
+ timeout = jiffies + msecs_to_jiffies(5);
+ csb_writel(tegra, CPUCTL_STARTCPU, XUSB_FALC_CPUCTL);
+ while (time_before(jiffies, timeout)) {
+ if (csb_readl(tegra, XUSB_FALC_CPUCTL) == CPUCTL_STATE_STOPPED)
+ break;
+ usleep_range(100, 200);
+ }
+ if (csb_readl(tegra, XUSB_FALC_CPUCTL) != CPUCTL_STATE_STOPPED) {
+ dev_err(dev, "Falcon failed to start, state: %#x\n",
+ csb_readl(tegra, XUSB_FALC_CPUCTL));
+ return -EIO;
+ }
+
+ fw_time = le32_to_cpu(cfg_tbl->fwimg_created_time);
+ time_to_tm(fw_time, 0, &fw_tm);
+ dev_info(dev, "Firmware timestamp: %ld-%02d-%02d %02d:%02d:%02d UTC\n",
+ fw_tm.tm_year + 1900, fw_tm.tm_mon + 1, fw_tm.tm_mday,
+ fw_tm.tm_hour, fw_tm.tm_min, fw_tm.tm_sec);
+
+ return 0;
+}
+
+static int tegra_xhci_set_ss_clk(struct tegra_xhci_hcd *tegra,
+ unsigned long rate)
+{
+ struct clk *clk = tegra->ss_src_clk;
+ unsigned long new_parent_rate, old_parent_rate;
+ int ret, div;
+
+ if (clk_get_rate(clk) == rate)
+ return 0;
+
+ switch (rate) {
+ case TEGRA_XHCI_SS_CLK_HIGH_SPEED:
+ /*
+ * Reparent to PLLU_480M. Set divider first to avoid
+ * overclocking.
+ */
+ old_parent_rate = clk_get_rate(clk_get_parent(clk));
+ new_parent_rate = clk_get_rate(tegra->pll_u_480m);
+ div = new_parent_rate / rate;
+ ret = clk_set_rate(clk, old_parent_rate / div);
+ if (ret)
+ return ret;
+ ret = clk_set_parent(clk, tegra->pll_u_480m);
+ if (ret)
+ return ret;
+ /*
+ * The rate should already be correct, but set it again just
+ * to be sure.
+ */
+ ret = clk_set_rate(clk, rate);
+ if (ret)
+ return ret;
+ break;
+ case TEGRA_XHCI_SS_CLK_LOW_SPEED:
+ /* Reparent to CLK_M */
+ ret = clk_set_parent(clk, tegra->clk_m);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(clk, rate);
+ if (ret)
+ return ret;
+ break;
+ default:
+ dev_err(tegra->dev, "Invalid SS rate: %lu\n", rate);
+ return -EINVAL;
+ }
+
+ if (clk_get_rate(clk) != rate) {
+ dev_err(tegra->dev, "SS clock doesn't match requested rate\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int tegra_xhci_clk_enable(struct tegra_xhci_hcd *tegra)
+{
+ int ret;
+
+ ret = clk_prepare_enable(tegra->pll_e);
+ if (ret < 0)
+ return ret;
+ ret = clk_prepare_enable(tegra->host_clk);
+ if (ret < 0)
+ goto disable_plle;
+ ret = clk_prepare_enable(tegra->ss_clk);
+ if (ret < 0)
+ goto disable_host;
+ ret = clk_prepare_enable(tegra->falc_clk);
+ if (ret < 0)
+ goto disable_ss;
+ ret = clk_prepare_enable(tegra->fs_src_clk);
+ if (ret < 0)
+ goto disable_falc;
+ ret = clk_prepare_enable(tegra->hs_src_clk);
+ if (ret < 0)
+ goto disable_fs_src;
+ ret = tegra_xhci_set_ss_clk(tegra, TEGRA_XHCI_SS_CLK_HIGH_SPEED);
+ if (ret < 0)
+ goto disable_hs_src;
+
+ return 0;
+
+disable_hs_src:
+ clk_disable_unprepare(tegra->hs_src_clk);
+disable_fs_src:
+ clk_disable_unprepare(tegra->fs_src_clk);
+disable_falc:
+ clk_disable_unprepare(tegra->falc_clk);
+disable_ss:
+ clk_disable_unprepare(tegra->ss_clk);
+disable_host:
+ clk_disable_unprepare(tegra->host_clk);
+disable_plle:
+ clk_disable_unprepare(tegra->pll_e);
+ return ret;
+}
+
+static void tegra_xhci_clk_disable(struct tegra_xhci_hcd *tegra)
+{
+ clk_disable_unprepare(tegra->pll_e);
+ clk_disable_unprepare(tegra->host_clk);
+ clk_disable_unprepare(tegra->ss_clk);
+ clk_disable_unprepare(tegra->falc_clk);
+ clk_disable_unprepare(tegra->fs_src_clk);
+ clk_disable_unprepare(tegra->hs_src_clk);
+}
+
+static int tegra_xhci_phy_enable(struct tegra_xhci_hcd *tegra)
+{
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < tegra->num_phys; i++) {
+ ret = phy_init(tegra->phys[i]);
+ if (ret)
+ goto disable_phy;
+ ret = phy_power_on(tegra->phys[i]);
+ if (ret) {
+ phy_exit(tegra->phys[i]);
+ goto disable_phy;
+ }
+ }
+
+ return 0;
+disable_phy:
+ for (; i > 0; i--) {
+ phy_power_off(tegra->phys[i - 1]);
+ phy_exit(tegra->phys[i - 1]);
+ }
+ return ret;
+}
+
+static void tegra_xhci_phy_disable(struct tegra_xhci_hcd *tegra)
+{
+ unsigned int i;
+
+ for (i = 0; i < tegra->num_phys; i++) {
+ phy_power_off(tegra->phys[i]);
+ phy_exit(tegra->phys[i]);
+ }
+}
+
+static bool is_host_mbox_message(u32 cmd)
+{
+ switch (cmd) {
+ case MBOX_CMD_INC_SSPI_CLOCK:
+ case MBOX_CMD_DEC_SSPI_CLOCK:
+ case MBOX_CMD_INC_FALC_CLOCK:
+ case MBOX_CMD_DEC_FALC_CLOCK:
+ case MBOX_CMD_SET_BW:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static void tegra_xhci_mbox_work(struct work_struct *work)
+{
+ struct tegra_xhci_hcd *tegra = mbox_work_to_tegra(work);
+ struct tegra_xusb_mbox_msg *msg = &tegra->mbox_req;
+ struct tegra_xusb_mbox_msg resp;
+ int ret;
+
+ resp.cmd = 0;
+ switch (msg->cmd) {
+ case MBOX_CMD_INC_SSPI_CLOCK:
+ case MBOX_CMD_DEC_SSPI_CLOCK:
+ ret = tegra_xhci_set_ss_clk(tegra, msg->data * 1000);
+ resp.data = clk_get_rate(tegra->ss_src_clk) / 1000;
+ if (ret)
+ resp.cmd = MBOX_CMD_NAK;
+ else
+ resp.cmd = MBOX_CMD_ACK;
+ break;
+ case MBOX_CMD_INC_FALC_CLOCK:
+ case MBOX_CMD_DEC_FALC_CLOCK:
+ resp.data = clk_get_rate(tegra->falc_clk) / 1000;
+ if (resp.data != msg->data)
+ resp.cmd = MBOX_CMD_NAK;
+ else
+ resp.cmd = MBOX_CMD_ACK;
+ break;
+ case MBOX_CMD_SET_BW:
+ /*
+ * TODO: Request bandwidth once EMC scaling is supported.
+ * Ignore for now since ACK/NAK is not required for SET_BW
+ * messages.
+ */
+ break;
+ default:
+ break;
+ }
+
+ if (resp.cmd)
+ mbox_send_message(tegra->mbox_chan, &resp);
+}
+
+static void tegra_xhci_mbox_rx(struct mbox_client *cl, void *data)
+{
+ struct tegra_xhci_hcd *tegra = dev_get_drvdata(cl->dev);
+ struct tegra_xusb_mbox_msg *msg = data;
+
+ if (is_host_mbox_message(msg->cmd)) {
+ tegra->mbox_req = *msg;
+ schedule_work(&tegra->mbox_req_work);
+ }
+}
+
+static void tegra_xhci_quirks(struct device *dev, struct xhci_hcd *xhci)
+{
+ xhci->quirks |= XHCI_PLAT;
+}
+
+static int tegra_xhci_setup(struct usb_hcd *hcd)
+{
+ return xhci_gen_setup(hcd, tegra_xhci_quirks);
+}
+
+static const char * const tegra124_supply_names[] = {
+ "avddio-pex",
+ "dvddio-pex",
+ "avdd-usb",
+ "avdd-pll-utmip",
+ "avdd-pll-erefe",
+ "avdd-usb-ss-pll",
+ "hvdd-usb-ss",
+ "hvdd-usb-ss-pll-e",
+};
+
+static const struct tegra_xhci_phy_type tegra124_phy_types[] = {
+ { .name = "usb3", .num = 2, },
+ { .name = "utmi", .num = 3, },
+ { .name = "hsic", .num = 2, },
+};
+
+static const struct tegra_xhci_soc_data tegra124_soc_data = {
+ .firmware_file = "nvidia/tegra124/xusb.bin",
+ .supply_names = tegra124_supply_names,
+ .num_supplies = ARRAY_SIZE(tegra124_supply_names),
+ .phy_types = tegra124_phy_types,
+ .num_types = ARRAY_SIZE(tegra124_phy_types),
+};
+MODULE_FIRMWARE("nvidia/tegra124/xusb.bin");
+
+static const struct of_device_id tegra_xhci_of_match[] = {
+ { .compatible = "nvidia,tegra124-xhci", .data = &tegra124_soc_data },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tegra_xhci_of_match);
+
+static void tegra_xhci_probe_finish(const struct firmware *fw, void *context)
+{
+ struct tegra_xhci_hcd *tegra = context;
+ struct device *dev = tegra->dev;
+ struct xhci_hcd *xhci = NULL;
+ struct tegra_xhci_fw_cfgtbl *cfg_tbl;
+ struct tegra_xusb_mbox_msg msg;
+ int ret;
+
+ if (!fw)
+ goto put_usb2_hcd;
+
+ /* Load Falcon controller with its firmware. */
+ cfg_tbl = (struct tegra_xhci_fw_cfgtbl *)fw->data;
+ tegra->fw_size = le32_to_cpu(cfg_tbl->fwimg_len);
+ tegra->fw_data = dma_alloc_coherent(dev, tegra->fw_size,
+ &tegra->fw_dma_addr,
+ GFP_KERNEL);
+ if (!tegra->fw_data)
+ goto put_usb2_hcd;
+ memcpy(tegra->fw_data, fw->data, tegra->fw_size);
+
+ ret = tegra_xhci_load_firmware(tegra);
+ if (ret < 0)
+ goto put_usb2_hcd;
+
+ ret = usb_add_hcd(tegra->hcd, tegra->irq, IRQF_SHARED);
+ if (ret < 0)
+ goto put_usb2_hcd;
+ device_wakeup_enable(tegra->hcd->self.controller);
+
+ /*
+ * USB 2.0 roothub is stored in drvdata now. Swap it with the Tegra HCD.
+ */
+ tegra->hcd = dev_get_drvdata(dev);
+ dev_set_drvdata(dev, tegra);
+ xhci = hcd_to_xhci(tegra->hcd);
+ xhci->shared_hcd = usb_create_shared_hcd(&tegra_xhci_hc_driver,
+ dev, dev_name(dev),
+ tegra->hcd);
+ if (!xhci->shared_hcd)
+ goto dealloc_usb2_hcd;
+
+ ret = usb_add_hcd(xhci->shared_hcd, tegra->irq, IRQF_SHARED);
+ if (ret < 0)
+ goto put_usb3_hcd;
+
+ /* Enable firmware messages from controller. */
+ msg.cmd = MBOX_CMD_MSG_ENABLED;
+ msg.data = 0;
+ ret = mbox_send_message(tegra->mbox_chan, &msg);
+ if (ret < 0)
+ goto dealloc_usb3_hcd;
+
+ tegra->fw_loaded = true;
+ release_firmware(fw);
+ return;
+
+ /* Free up as much as we can and wait to be unbound. */
+dealloc_usb3_hcd:
+ usb_remove_hcd(xhci->shared_hcd);
+put_usb3_hcd:
+ usb_put_hcd(xhci->shared_hcd);
+dealloc_usb2_hcd:
+ usb_remove_hcd(tegra->hcd);
+ kfree(xhci);
+put_usb2_hcd:
+ usb_put_hcd(tegra->hcd);
+ tegra->hcd = NULL;
+ release_firmware(fw);
+}
+
+static int tegra_xhci_probe(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+ struct tegra_xhci_hcd *tegra;
+ struct resource *res;
+ struct usb_hcd *hcd;
+ struct phy *phy;
+ unsigned int i, j, k;
+ int ret;
+
+ BUILD_BUG_ON(sizeof(struct tegra_xhci_fw_cfgtbl) != 256);
+
+ tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
+ if (!tegra)
+ return -ENOMEM;
+ tegra->dev = &pdev->dev;
+ platform_set_drvdata(pdev, tegra);
+
+ match = of_match_device(tegra_xhci_of_match, &pdev->dev);
+ tegra->soc = match->data;
+
+ hcd = usb_create_hcd(&tegra_xhci_hc_driver, &pdev->dev,
+ dev_name(&pdev->dev));
+ if (!hcd)
+ return -ENOMEM;
+ tegra->hcd = hcd;
+
+ tegra->fpci_regs = dev_get_drvdata(pdev->dev.parent);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hcd->regs)) {
+ ret = PTR_ERR(hcd->regs);
+ goto put_hcd;
+ }
+ hcd->rsrc_start = res->start;
+ hcd->rsrc_len = resource_size(res);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ tegra->ipfs_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(tegra->ipfs_base)) {
+ ret = PTR_ERR(tegra->ipfs_base);
+ goto put_hcd;
+ }
+
+ tegra->irq = platform_get_irq(pdev, 0);
+ if (tegra->irq < 0) {
+ ret = tegra->irq;
+ goto put_hcd;
+ }
+
+ tegra->host_rst = devm_reset_control_get(&pdev->dev, "xusb_host");
+ if (IS_ERR(tegra->host_rst)) {
+ ret = PTR_ERR(tegra->host_rst);
+ goto put_hcd;
+ }
+ tegra->ss_rst = devm_reset_control_get(&pdev->dev, "xusb_ss");
+ if (IS_ERR(tegra->ss_rst)) {
+ ret = PTR_ERR(tegra->ss_rst);
+ goto put_hcd;
+ }
+
+ tegra->host_clk = devm_clk_get(&pdev->dev, "xusb_host");
+ if (IS_ERR(tegra->host_clk)) {
+ ret = PTR_ERR(tegra->host_clk);
+ goto put_hcd;
+ }
+ tegra->falc_clk = devm_clk_get(&pdev->dev, "xusb_falcon_src");
+ if (IS_ERR(tegra->falc_clk)) {
+ ret = PTR_ERR(tegra->falc_clk);
+ goto put_hcd;
+ }
+ tegra->ss_clk = devm_clk_get(&pdev->dev, "xusb_ss");
+ if (IS_ERR(tegra->ss_clk)) {
+ ret = PTR_ERR(tegra->ss_clk);
+ goto put_hcd;
+ }
+ tegra->ss_src_clk = devm_clk_get(&pdev->dev, "xusb_ss_src");
+ if (IS_ERR(tegra->ss_src_clk)) {
+ ret = PTR_ERR(tegra->ss_src_clk);
+ goto put_hcd;
+ }
+ tegra->hs_src_clk = devm_clk_get(&pdev->dev, "xusb_hs_src");
+ if (IS_ERR(tegra->hs_src_clk)) {
+ ret = PTR_ERR(tegra->hs_src_clk);
+ goto put_hcd;
+ }
+ tegra->fs_src_clk = devm_clk_get(&pdev->dev, "xusb_fs_src");
+ if (IS_ERR(tegra->fs_src_clk)) {
+ ret = PTR_ERR(tegra->fs_src_clk);
+ goto put_hcd;
+ }
+ tegra->pll_u_480m = devm_clk_get(&pdev->dev, "pll_u_480m");
+ if (IS_ERR(tegra->pll_u_480m)) {
+ ret = PTR_ERR(tegra->pll_u_480m);
+ goto put_hcd;
+ }
+ tegra->clk_m = devm_clk_get(&pdev->dev, "clk_m");
+ if (IS_ERR(tegra->clk_m)) {
+ ret = PTR_ERR(tegra->clk_m);
+ goto put_hcd;
+ }
+ tegra->pll_e = devm_clk_get(&pdev->dev, "pll_e");
+ if (IS_ERR(tegra->pll_e)) {
+ ret = PTR_ERR(tegra->pll_e);
+ goto put_hcd;
+ }
+ ret = tegra_xhci_clk_enable(tegra);
+ if (ret)
+ goto put_hcd;
+
+ tegra->supplies = devm_kcalloc(&pdev->dev, tegra->soc->num_supplies,
+ sizeof(*tegra->supplies), GFP_KERNEL);
+ if (!tegra->supplies) {
+ ret = -ENOMEM;
+ goto put_hcd;
+ }
+ for (i = 0; i < tegra->soc->num_supplies; i++)
+ tegra->supplies[i].supply = tegra->soc->supply_names[i];
+ ret = devm_regulator_bulk_get(&pdev->dev, tegra->soc->num_supplies,
+ tegra->supplies);
+ if (ret)
+ goto disable_clk;
+ ret = regulator_bulk_enable(tegra->soc->num_supplies, tegra->supplies);
+ if (ret)
+ goto disable_clk;
+
+ INIT_WORK(&tegra->mbox_req_work, tegra_xhci_mbox_work);
+ tegra->mbox_client.dev = &pdev->dev;
+ tegra->mbox_client.tx_block = true;
+ tegra->mbox_client.tx_tout = 0;
+ tegra->mbox_client.rx_callback = tegra_xhci_mbox_rx;
+ tegra->mbox_chan = mbox_request_channel(&tegra->mbox_client, 0);
+ if (IS_ERR(tegra->mbox_chan)) {
+ ret = PTR_ERR(tegra->mbox_chan);
+ goto disable_regulator;
+ }
+
+ for (i = 0; i < tegra->soc->num_types; i++)
+ tegra->num_phys += tegra->soc->phy_types[i].num;
+ tegra->phys = devm_kcalloc(&pdev->dev, tegra->num_phys,
+ sizeof(*tegra->phys), GFP_KERNEL);
+ if (!tegra->phys) {
+ ret = -ENOMEM;
+ goto put_mbox;
+ }
+ for (i = 0, k = 0; i < tegra->soc->num_types; i++) {
+ char prop[8];
+
+ for (j = 0; j < tegra->soc->phy_types[i].num; j++) {
+ snprintf(prop, sizeof(prop), "%s-%d",
+ tegra->soc->phy_types[i].name, j);
+ phy = devm_phy_optional_get(&pdev->dev, prop);
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ goto put_mbox;
+ }
+ tegra->phys[k++] = phy;
+ }
+ }
+
+ tegra_xhci_ipfs_config(tegra);
+
+ ret = tegra_xhci_phy_enable(tegra);
+ if (ret < 0)
+ goto put_mbox;
+
+ ret = request_firmware_nowait(THIS_MODULE, true,
+ tegra->soc->firmware_file,
+ tegra->dev, GFP_KERNEL, tegra,
+ tegra_xhci_probe_finish);
+ if (ret < 0)
+ goto disable_phy;
+
+ return 0;
+
+disable_phy:
+ tegra_xhci_phy_disable(tegra);
+put_mbox:
+ mbox_free_channel(tegra->mbox_chan);
+disable_regulator:
+ regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
+disable_clk:
+ tegra_xhci_clk_disable(tegra);
+put_hcd:
+ usb_put_hcd(hcd);
+ return ret;
+}
+
+static int tegra_xhci_remove(struct platform_device *pdev)
+{
+ struct tegra_xhci_hcd *tegra = platform_get_drvdata(pdev);
+ struct usb_hcd *hcd = tegra->hcd;
+ struct xhci_hcd *xhci;
+
+ if (tegra->fw_loaded) {
+ xhci = hcd_to_xhci(hcd);
+ usb_remove_hcd(xhci->shared_hcd);
+ usb_put_hcd(xhci->shared_hcd);
+ usb_remove_hcd(hcd);
+ usb_put_hcd(hcd);
+ kfree(xhci);
+ } else if (hcd) {
+ /* Unbound after probe(), but before firmware loading. */
+ usb_put_hcd(hcd);
+ }
+
+ if (tegra->fw_data)
+ dma_free_coherent(tegra->dev, tegra->fw_size, tegra->fw_data,
+ tegra->fw_dma_addr);
+
+ cancel_work_sync(&tegra->mbox_req_work);
+ mbox_free_channel(tegra->mbox_chan);
+ tegra_xhci_phy_disable(tegra);
+ regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
+ tegra_xhci_clk_disable(tegra);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int tegra_xhci_suspend(struct device *dev)
+{
+ struct tegra_xhci_hcd *tegra = dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(tegra->hcd);
+ bool wakeup = device_may_wakeup(dev);
+
+ /* TODO: Powergate controller across suspend/resume. */
+ return xhci_suspend(xhci, wakeup);
+}
+
+static int tegra_xhci_resume(struct device *dev)
+{
+ struct tegra_xhci_hcd *tegra = dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(tegra->hcd);
+
+ return xhci_resume(xhci, 0);
+}
+#endif
+
+static const struct dev_pm_ops tegra_xhci_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(tegra_xhci_suspend, tegra_xhci_resume)
+};
+
+static struct platform_driver tegra_xhci_driver = {
+ .probe = tegra_xhci_probe,
+ .remove = tegra_xhci_remove,
+ .driver = {
+ .name = "tegra-xhci",
+ .pm = &tegra_xhci_pm_ops,
+ .of_match_table = tegra_xhci_of_match,
+ },
+};
+
+static int __init tegra_xhci_init(void)
+{
+ xhci_init_driver(&tegra_xhci_hc_driver, tegra_xhci_setup);
+ return platform_driver_register(&tegra_xhci_driver);
+}
+module_init(tegra_xhci_init);
+
+static void __exit tegra_xhci_exit(void)
+{
+ platform_driver_unregister(&tegra_xhci_driver);
+}
+module_exit(tegra_xhci_exit);
+
+MODULE_AUTHOR("Andrew Bresticker <abrestic@chromium.org>");
+MODULE_DESCRIPTION("NVIDIA Tegra xHCI host-controller driver");
+MODULE_LICENSE("GPL v2");
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread* [PATCH v8 9/9] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
@ 2015-05-04 17:36 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-04 17:36 UTC (permalink / raw)
To: Stephen Warren, Thierry Reding, Alexandre Courbot
Cc: devicetree, linux-tegra, linux-usb, linux-arm-kernel,
linux-kernel, Andrew Bresticker, Jon Hunter, Mathias Nyman,
Greg Kroah-Hartman
Add support for the on-chip xHCI host controller present on Tegra SoCs.
The controller requires external firmware which must be loaded before
using the controller. This driver loads the firmware, starts the
controller, and is able to service host-specific messages sent by
the controller's firmware.
The controller also supports USB device mode as well as powergating
of the SuperSpeed and host-controller logic when not in use, but
support for these is not yet implemented.
Based on work by:
Ajay Gupta <ajayg@nvidia.com>
Bharath Yadav <byadav@nvidia.com>
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Cc: Mathias Nyman <mathias.nyman@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
No changes from v7.
Changes from v6:
- Access FPCI registers using parent MFD's regmap.
- Made regulator names and PHY types part of the SoC-specific data
since they will be different on Tegra210.
- Other cosmetic cleanups.
Changes from v5:
- Added dependency on COMPILE_TEST and MAILBOX.
- Added TODO about powergating support.
Changes from v4:
- Poll for controller to finish booting.
- Addressed review comments from Thierry.
Changes from v3:
- Used 32-bit DMA mask (platforms may have > 32-bit physical address space
and < 64-bit dma_addr_t).
- Moved comment about SET_BW command.
Changes from v2:
- Added filtering out of non-host mailbox messages.
- Removed MODULE_ALIAS.
Changes from v1:
- Updated to use common mailbox API.
- Fixed up so that the driver can be built and used as a module.
- Incorporated review feedback from Stephen.
- Misc. cleanups.
---
drivers/usb/host/Kconfig | 10 +
drivers/usb/host/Makefile | 1 +
drivers/usb/host/xhci-tegra.c | 947 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 958 insertions(+)
create mode 100644 drivers/usb/host/xhci-tegra.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 197a6a3..22601d0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -50,6 +50,16 @@ config USB_XHCI_RCAR
Say 'Y' to enable the support for the xHCI host controller
found in Renesas R-Car ARM SoCs.
+config USB_XHCI_TEGRA
+ tristate "xHCI support for NVIDIA Tegra SoCs"
+ depends on MFD_TEGRA_XUSB || COMPILE_TEST
+ depends on MAILBOX
+ depends on RESET_CONTROLLER
+ select FW_LOADER
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in NVIDIA Tegra124 and later SoCs.
+
endif # USB_XHCI_HCD
config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 65b0b6a..1b98107 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PCI) += pci-quirks.o
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_TEGRA) += xhci-tegra.o
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
new file mode 100644
index 0000000..d510dc5
--- /dev/null
+++ b/drivers/usb/host/xhci-tegra.c
@@ -0,0 +1,947 @@
+/*
+ * NVIDIA Tegra xHCI host controller driver
+ *
+ * Copyright (C) 2014 NVIDIA Corporation
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/dma-mapping.h>
+#include <linux/firmware.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_client.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+
+#include <soc/tegra/xusb.h>
+
+#include "xhci.h"
+
+#define TEGRA_XHCI_SS_CLK_HIGH_SPEED 120000000
+#define TEGRA_XHCI_SS_CLK_LOW_SPEED 12000000
+
+/* FPCI CFG registers */
+#define XUSB_CFG_1 0x004
+#define XUSB_IO_SPACE_EN BIT(0)
+#define XUSB_MEM_SPACE_EN BIT(1)
+#define XUSB_BUS_MASTER_EN BIT(2)
+#define XUSB_CFG_4 0x010
+#define XUSB_BASE_ADDR_SHIFT 15
+#define XUSB_BASE_ADDR_MASK 0x1ffff
+#define XUSB_CFG_ARU_C11_CSBRANGE 0x41c
+#define XUSB_CFG_CSB_BASE_ADDR 0x800
+
+/* IPFS registers */
+#define IPFS_XUSB_HOST_CONFIGURATION_0 0x180
+#define IPFS_EN_FPCI BIT(0)
+#define IPFS_XUSB_HOST_INTR_MASK_0 0x188
+#define IPFS_IP_INT_MASK BIT(16)
+#define IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_0 0x1bc
+
+#define CSB_PAGE_SELECT_MASK 0x7fffff
+#define CSB_PAGE_SELECT_SHIFT 9
+#define CSB_PAGE_OFFSET_MASK 0x1ff
+#define CSB_PAGE_SELECT(addr) ((addr) >> (CSB_PAGE_SELECT_SHIFT) & \
+ CSB_PAGE_SELECT_MASK)
+#define CSB_PAGE_OFFSET(addr) ((addr) & CSB_PAGE_OFFSET_MASK)
+
+/* Falcon CSB registers */
+#define XUSB_FALC_CPUCTL 0x100
+#define CPUCTL_STARTCPU BIT(1)
+#define CPUCTL_STATE_HALTED BIT(4)
+#define CPUCTL_STATE_STOPPED BIT(5)
+#define XUSB_FALC_BOOTVEC 0x104
+#define XUSB_FALC_DMACTL 0x10c
+#define XUSB_FALC_IMFILLRNG1 0x154
+#define IMFILLRNG1_TAG_MASK 0xffff
+#define IMFILLRNG1_TAG_LO_SHIFT 0
+#define IMFILLRNG1_TAG_HI_SHIFT 16
+#define XUSB_FALC_IMFILLCTL 0x158
+
+/* MP CSB registers */
+#define XUSB_CSB_MP_ILOAD_ATTR 0x101a00
+#define XUSB_CSB_MP_ILOAD_BASE_LO 0x101a04
+#define XUSB_CSB_MP_ILOAD_BASE_HI 0x101a08
+#define XUSB_CSB_MP_L2IMEMOP_SIZE 0x101a10
+#define L2IMEMOP_SIZE_SRC_OFFSET_SHIFT 8
+#define L2IMEMOP_SIZE_SRC_OFFSET_MASK 0x3ff
+#define L2IMEMOP_SIZE_SRC_COUNT_SHIFT 24
+#define L2IMEMOP_SIZE_SRC_COUNT_MASK 0xff
+#define XUSB_CSB_MP_L2IMEMOP_TRIG 0x101a14
+#define L2IMEMOP_ACTION_SHIFT 24
+#define L2IMEMOP_INVALIDATE_ALL (0x40 << L2IMEMOP_ACTION_SHIFT)
+#define L2IMEMOP_LOAD_LOCKED_RESULT (0x11 << L2IMEMOP_ACTION_SHIFT)
+#define XUSB_CSB_MP_APMAP 0x10181c
+#define APMAP_BOOTPATH BIT(31)
+
+#define IMEM_BLOCK_SIZE 256
+
+struct tegra_xhci_fw_cfgtbl {
+ u32 boot_loadaddr_in_imem;
+ u32 boot_codedfi_offset;
+ u32 boot_codetag;
+ u32 boot_codesize;
+ u32 phys_memaddr;
+ u16 reqphys_memsize;
+ u16 alloc_phys_memsize;
+ u32 rodata_img_offset;
+ u32 rodata_section_start;
+ u32 rodata_section_end;
+ u32 main_fnaddr;
+ u32 fwimg_cksum;
+ u32 fwimg_created_time;
+ u32 imem_resident_start;
+ u32 imem_resident_end;
+ u32 idirect_start;
+ u32 idirect_end;
+ u32 l2_imem_start;
+ u32 l2_imem_end;
+ u32 version_id;
+ u8 init_ddirect;
+ u8 reserved[3];
+ u32 phys_addr_log_buffer;
+ u32 total_log_entries;
+ u32 dequeue_ptr;
+ u32 dummy_var[2];
+ u32 fwimg_len;
+ u8 magic[8];
+ u32 ss_low_power_entry_timeout;
+ u8 num_hsic_port;
+ u8 padding[139]; /* Pad to 256 bytes */
+};
+
+struct tegra_xhci_phy_type {
+ const char *name;
+ unsigned int num;
+};
+
+struct tegra_xhci_soc_data {
+ const char *firmware_file;
+ const char * const *supply_names;
+ unsigned int num_supplies;
+ const struct tegra_xhci_phy_type *phy_types;
+ unsigned int num_types;
+};
+
+struct tegra_xhci_hcd {
+ struct device *dev;
+ struct usb_hcd *hcd;
+
+ int irq;
+
+ void __iomem *ipfs_base;
+ struct regmap *fpci_regs;
+
+ const struct tegra_xhci_soc_data *soc;
+
+ struct regulator_bulk_data *supplies;
+
+ struct clk *host_clk;
+ struct clk *falc_clk;
+ struct clk *ss_clk;
+ struct clk *ss_src_clk;
+ struct clk *hs_src_clk;
+ struct clk *fs_src_clk;
+ struct clk *pll_u_480m;
+ struct clk *clk_m;
+ struct clk *pll_e;
+
+ struct reset_control *host_rst;
+ struct reset_control *ss_rst;
+
+ struct phy **phys;
+ unsigned int num_phys;
+
+ struct work_struct mbox_req_work;
+ struct tegra_xusb_mbox_msg mbox_req;
+ struct mbox_client mbox_client;
+ struct mbox_chan *mbox_chan;
+
+ /* Firmware loading related */
+ void *fw_data;
+ size_t fw_size;
+ dma_addr_t fw_dma_addr;
+ bool fw_loaded;
+};
+
+static struct hc_driver __read_mostly tegra_xhci_hc_driver;
+
+static inline struct tegra_xhci_hcd *
+mbox_work_to_tegra(struct work_struct *work)
+{
+ return container_of(work, struct tegra_xhci_hcd, mbox_req_work);
+}
+
+static inline u32 fpci_readl(struct tegra_xhci_hcd *tegra, u32 addr)
+{
+ u32 val;
+
+ regmap_read(tegra->fpci_regs, addr, &val);
+
+ return val;
+}
+
+static inline void fpci_writel(struct tegra_xhci_hcd *tegra, u32 val, u32 addr)
+{
+ regmap_write(tegra->fpci_regs, addr, val);
+}
+
+static inline u32 ipfs_readl(struct tegra_xhci_hcd *tegra, u32 addr)
+{
+ return readl(tegra->ipfs_base + addr);
+}
+
+static inline void ipfs_writel(struct tegra_xhci_hcd *tegra, u32 val, u32 addr)
+{
+ writel(val, tegra->ipfs_base + addr);
+}
+
+static u32 csb_readl(struct tegra_xhci_hcd *tegra, u32 addr)
+{
+ u32 page, offset;
+
+ page = CSB_PAGE_SELECT(addr);
+ offset = CSB_PAGE_OFFSET(addr);
+ fpci_writel(tegra, page, XUSB_CFG_ARU_C11_CSBRANGE);
+ return fpci_readl(tegra, XUSB_CFG_CSB_BASE_ADDR + offset);
+}
+
+static void csb_writel(struct tegra_xhci_hcd *tegra, u32 val, u32 addr)
+{
+ u32 page, offset;
+
+ page = CSB_PAGE_SELECT(addr);
+ offset = CSB_PAGE_OFFSET(addr);
+ fpci_writel(tegra, page, XUSB_CFG_ARU_C11_CSBRANGE);
+ fpci_writel(tegra, val, XUSB_CFG_CSB_BASE_ADDR + offset);
+}
+
+static void tegra_xhci_ipfs_config(struct tegra_xhci_hcd *tegra)
+{
+ u32 reg;
+
+ reg = ipfs_readl(tegra, IPFS_XUSB_HOST_CONFIGURATION_0);
+ reg |= IPFS_EN_FPCI;
+ ipfs_writel(tegra, reg, IPFS_XUSB_HOST_CONFIGURATION_0);
+ udelay(10);
+
+ /* Program BAR0 space */
+ reg = fpci_readl(tegra, XUSB_CFG_4);
+ reg &= ~(XUSB_BASE_ADDR_MASK << XUSB_BASE_ADDR_SHIFT);
+ reg |= tegra->hcd->rsrc_start & (XUSB_BASE_ADDR_MASK <<
+ XUSB_BASE_ADDR_SHIFT);
+ fpci_writel(tegra, reg, XUSB_CFG_4);
+ usleep_range(100, 200);
+
+ /* Enable bus master */
+ reg = fpci_readl(tegra, XUSB_CFG_1);
+ reg |= XUSB_IO_SPACE_EN | XUSB_MEM_SPACE_EN | XUSB_BUS_MASTER_EN;
+ fpci_writel(tegra, reg, XUSB_CFG_1);
+
+ /* Enable interrupt assertion */
+ reg = ipfs_readl(tegra, IPFS_XUSB_HOST_INTR_MASK_0);
+ reg |= IPFS_IP_INT_MASK;
+ ipfs_writel(tegra, reg, IPFS_XUSB_HOST_INTR_MASK_0);
+
+ /* Set hysteresis */
+ ipfs_writel(tegra, 0x80, IPFS_XUSB_HOST_CLKGATE_HYSTERESIS_0);
+}
+
+static int tegra_xhci_load_firmware(struct tegra_xhci_hcd *tegra)
+{
+ struct device *dev = tegra->dev;
+ struct tegra_xhci_fw_cfgtbl *cfg_tbl;
+ struct tm fw_tm;
+ u32 val, code_tag_blocks, code_size_blocks;
+ u64 fw_base;
+ time_t fw_time;
+ unsigned long timeout;
+
+ if (csb_readl(tegra, XUSB_CSB_MP_ILOAD_BASE_LO) != 0) {
+ dev_info(dev, "Firmware already loaded, Falcon state 0x%x\n",
+ csb_readl(tegra, XUSB_FALC_CPUCTL));
+ return 0;
+ }
+
+ cfg_tbl = (struct tegra_xhci_fw_cfgtbl *)tegra->fw_data;
+
+ /* Program the size of DFI into ILOAD_ATTR. */
+ csb_writel(tegra, tegra->fw_size, XUSB_CSB_MP_ILOAD_ATTR);
+
+ /*
+ * Boot code of the firmware reads the ILOAD_BASE registers
+ * to get to the start of the DFI in system memory.
+ */
+ fw_base = tegra->fw_dma_addr + sizeof(*cfg_tbl);
+ csb_writel(tegra, fw_base, XUSB_CSB_MP_ILOAD_BASE_LO);
+ csb_writel(tegra, fw_base >> 32, XUSB_CSB_MP_ILOAD_BASE_HI);
+
+ /* Set BOOTPATH to 1 in APMAP. */
+ csb_writel(tegra, APMAP_BOOTPATH, XUSB_CSB_MP_APMAP);
+
+ /* Invalidate L2IMEM. */
+ csb_writel(tegra, L2IMEMOP_INVALIDATE_ALL, XUSB_CSB_MP_L2IMEMOP_TRIG);
+
+ /*
+ * Initiate fetch of bootcode from system memory into L2IMEM.
+ * Program bootcode location and size in system memory.
+ */
+ code_tag_blocks = DIV_ROUND_UP(le32_to_cpu(cfg_tbl->boot_codetag),
+ IMEM_BLOCK_SIZE);
+ code_size_blocks = DIV_ROUND_UP(le32_to_cpu(cfg_tbl->boot_codesize),
+ IMEM_BLOCK_SIZE);
+ val = ((code_tag_blocks & L2IMEMOP_SIZE_SRC_OFFSET_MASK) <<
+ L2IMEMOP_SIZE_SRC_OFFSET_SHIFT) |
+ ((code_size_blocks & L2IMEMOP_SIZE_SRC_COUNT_MASK) <<
+ L2IMEMOP_SIZE_SRC_COUNT_SHIFT);
+ csb_writel(tegra, val, XUSB_CSB_MP_L2IMEMOP_SIZE);
+
+ /* Trigger L2IMEM load operation. */
+ csb_writel(tegra, L2IMEMOP_LOAD_LOCKED_RESULT,
+ XUSB_CSB_MP_L2IMEMOP_TRIG);
+
+ /* Setup Falcon auto-fill. */
+ csb_writel(tegra, code_size_blocks, XUSB_FALC_IMFILLCTL);
+
+ val = ((code_tag_blocks & IMFILLRNG1_TAG_MASK) <<
+ IMFILLRNG1_TAG_LO_SHIFT) |
+ (((code_size_blocks + code_tag_blocks) & IMFILLRNG1_TAG_MASK) <<
+ IMFILLRNG1_TAG_HI_SHIFT);
+ csb_writel(tegra, val, XUSB_FALC_IMFILLRNG1);
+
+ csb_writel(tegra, 0, XUSB_FALC_DMACTL);
+ msleep(50);
+
+ csb_writel(tegra, le32_to_cpu(cfg_tbl->boot_codetag),
+ XUSB_FALC_BOOTVEC);
+
+ /* Boot Falcon CPU and wait for it to enter the STOPPED (idle) state. */
+ timeout = jiffies + msecs_to_jiffies(5);
+ csb_writel(tegra, CPUCTL_STARTCPU, XUSB_FALC_CPUCTL);
+ while (time_before(jiffies, timeout)) {
+ if (csb_readl(tegra, XUSB_FALC_CPUCTL) == CPUCTL_STATE_STOPPED)
+ break;
+ usleep_range(100, 200);
+ }
+ if (csb_readl(tegra, XUSB_FALC_CPUCTL) != CPUCTL_STATE_STOPPED) {
+ dev_err(dev, "Falcon failed to start, state: %#x\n",
+ csb_readl(tegra, XUSB_FALC_CPUCTL));
+ return -EIO;
+ }
+
+ fw_time = le32_to_cpu(cfg_tbl->fwimg_created_time);
+ time_to_tm(fw_time, 0, &fw_tm);
+ dev_info(dev, "Firmware timestamp: %ld-%02d-%02d %02d:%02d:%02d UTC\n",
+ fw_tm.tm_year + 1900, fw_tm.tm_mon + 1, fw_tm.tm_mday,
+ fw_tm.tm_hour, fw_tm.tm_min, fw_tm.tm_sec);
+
+ return 0;
+}
+
+static int tegra_xhci_set_ss_clk(struct tegra_xhci_hcd *tegra,
+ unsigned long rate)
+{
+ struct clk *clk = tegra->ss_src_clk;
+ unsigned long new_parent_rate, old_parent_rate;
+ int ret, div;
+
+ if (clk_get_rate(clk) == rate)
+ return 0;
+
+ switch (rate) {
+ case TEGRA_XHCI_SS_CLK_HIGH_SPEED:
+ /*
+ * Reparent to PLLU_480M. Set divider first to avoid
+ * overclocking.
+ */
+ old_parent_rate = clk_get_rate(clk_get_parent(clk));
+ new_parent_rate = clk_get_rate(tegra->pll_u_480m);
+ div = new_parent_rate / rate;
+ ret = clk_set_rate(clk, old_parent_rate / div);
+ if (ret)
+ return ret;
+ ret = clk_set_parent(clk, tegra->pll_u_480m);
+ if (ret)
+ return ret;
+ /*
+ * The rate should already be correct, but set it again just
+ * to be sure.
+ */
+ ret = clk_set_rate(clk, rate);
+ if (ret)
+ return ret;
+ break;
+ case TEGRA_XHCI_SS_CLK_LOW_SPEED:
+ /* Reparent to CLK_M */
+ ret = clk_set_parent(clk, tegra->clk_m);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(clk, rate);
+ if (ret)
+ return ret;
+ break;
+ default:
+ dev_err(tegra->dev, "Invalid SS rate: %lu\n", rate);
+ return -EINVAL;
+ }
+
+ if (clk_get_rate(clk) != rate) {
+ dev_err(tegra->dev, "SS clock doesn't match requested rate\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int tegra_xhci_clk_enable(struct tegra_xhci_hcd *tegra)
+{
+ int ret;
+
+ ret = clk_prepare_enable(tegra->pll_e);
+ if (ret < 0)
+ return ret;
+ ret = clk_prepare_enable(tegra->host_clk);
+ if (ret < 0)
+ goto disable_plle;
+ ret = clk_prepare_enable(tegra->ss_clk);
+ if (ret < 0)
+ goto disable_host;
+ ret = clk_prepare_enable(tegra->falc_clk);
+ if (ret < 0)
+ goto disable_ss;
+ ret = clk_prepare_enable(tegra->fs_src_clk);
+ if (ret < 0)
+ goto disable_falc;
+ ret = clk_prepare_enable(tegra->hs_src_clk);
+ if (ret < 0)
+ goto disable_fs_src;
+ ret = tegra_xhci_set_ss_clk(tegra, TEGRA_XHCI_SS_CLK_HIGH_SPEED);
+ if (ret < 0)
+ goto disable_hs_src;
+
+ return 0;
+
+disable_hs_src:
+ clk_disable_unprepare(tegra->hs_src_clk);
+disable_fs_src:
+ clk_disable_unprepare(tegra->fs_src_clk);
+disable_falc:
+ clk_disable_unprepare(tegra->falc_clk);
+disable_ss:
+ clk_disable_unprepare(tegra->ss_clk);
+disable_host:
+ clk_disable_unprepare(tegra->host_clk);
+disable_plle:
+ clk_disable_unprepare(tegra->pll_e);
+ return ret;
+}
+
+static void tegra_xhci_clk_disable(struct tegra_xhci_hcd *tegra)
+{
+ clk_disable_unprepare(tegra->pll_e);
+ clk_disable_unprepare(tegra->host_clk);
+ clk_disable_unprepare(tegra->ss_clk);
+ clk_disable_unprepare(tegra->falc_clk);
+ clk_disable_unprepare(tegra->fs_src_clk);
+ clk_disable_unprepare(tegra->hs_src_clk);
+}
+
+static int tegra_xhci_phy_enable(struct tegra_xhci_hcd *tegra)
+{
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < tegra->num_phys; i++) {
+ ret = phy_init(tegra->phys[i]);
+ if (ret)
+ goto disable_phy;
+ ret = phy_power_on(tegra->phys[i]);
+ if (ret) {
+ phy_exit(tegra->phys[i]);
+ goto disable_phy;
+ }
+ }
+
+ return 0;
+disable_phy:
+ for (; i > 0; i--) {
+ phy_power_off(tegra->phys[i - 1]);
+ phy_exit(tegra->phys[i - 1]);
+ }
+ return ret;
+}
+
+static void tegra_xhci_phy_disable(struct tegra_xhci_hcd *tegra)
+{
+ unsigned int i;
+
+ for (i = 0; i < tegra->num_phys; i++) {
+ phy_power_off(tegra->phys[i]);
+ phy_exit(tegra->phys[i]);
+ }
+}
+
+static bool is_host_mbox_message(u32 cmd)
+{
+ switch (cmd) {
+ case MBOX_CMD_INC_SSPI_CLOCK:
+ case MBOX_CMD_DEC_SSPI_CLOCK:
+ case MBOX_CMD_INC_FALC_CLOCK:
+ case MBOX_CMD_DEC_FALC_CLOCK:
+ case MBOX_CMD_SET_BW:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static void tegra_xhci_mbox_work(struct work_struct *work)
+{
+ struct tegra_xhci_hcd *tegra = mbox_work_to_tegra(work);
+ struct tegra_xusb_mbox_msg *msg = &tegra->mbox_req;
+ struct tegra_xusb_mbox_msg resp;
+ int ret;
+
+ resp.cmd = 0;
+ switch (msg->cmd) {
+ case MBOX_CMD_INC_SSPI_CLOCK:
+ case MBOX_CMD_DEC_SSPI_CLOCK:
+ ret = tegra_xhci_set_ss_clk(tegra, msg->data * 1000);
+ resp.data = clk_get_rate(tegra->ss_src_clk) / 1000;
+ if (ret)
+ resp.cmd = MBOX_CMD_NAK;
+ else
+ resp.cmd = MBOX_CMD_ACK;
+ break;
+ case MBOX_CMD_INC_FALC_CLOCK:
+ case MBOX_CMD_DEC_FALC_CLOCK:
+ resp.data = clk_get_rate(tegra->falc_clk) / 1000;
+ if (resp.data != msg->data)
+ resp.cmd = MBOX_CMD_NAK;
+ else
+ resp.cmd = MBOX_CMD_ACK;
+ break;
+ case MBOX_CMD_SET_BW:
+ /*
+ * TODO: Request bandwidth once EMC scaling is supported.
+ * Ignore for now since ACK/NAK is not required for SET_BW
+ * messages.
+ */
+ break;
+ default:
+ break;
+ }
+
+ if (resp.cmd)
+ mbox_send_message(tegra->mbox_chan, &resp);
+}
+
+static void tegra_xhci_mbox_rx(struct mbox_client *cl, void *data)
+{
+ struct tegra_xhci_hcd *tegra = dev_get_drvdata(cl->dev);
+ struct tegra_xusb_mbox_msg *msg = data;
+
+ if (is_host_mbox_message(msg->cmd)) {
+ tegra->mbox_req = *msg;
+ schedule_work(&tegra->mbox_req_work);
+ }
+}
+
+static void tegra_xhci_quirks(struct device *dev, struct xhci_hcd *xhci)
+{
+ xhci->quirks |= XHCI_PLAT;
+}
+
+static int tegra_xhci_setup(struct usb_hcd *hcd)
+{
+ return xhci_gen_setup(hcd, tegra_xhci_quirks);
+}
+
+static const char * const tegra124_supply_names[] = {
+ "avddio-pex",
+ "dvddio-pex",
+ "avdd-usb",
+ "avdd-pll-utmip",
+ "avdd-pll-erefe",
+ "avdd-usb-ss-pll",
+ "hvdd-usb-ss",
+ "hvdd-usb-ss-pll-e",
+};
+
+static const struct tegra_xhci_phy_type tegra124_phy_types[] = {
+ { .name = "usb3", .num = 2, },
+ { .name = "utmi", .num = 3, },
+ { .name = "hsic", .num = 2, },
+};
+
+static const struct tegra_xhci_soc_data tegra124_soc_data = {
+ .firmware_file = "nvidia/tegra124/xusb.bin",
+ .supply_names = tegra124_supply_names,
+ .num_supplies = ARRAY_SIZE(tegra124_supply_names),
+ .phy_types = tegra124_phy_types,
+ .num_types = ARRAY_SIZE(tegra124_phy_types),
+};
+MODULE_FIRMWARE("nvidia/tegra124/xusb.bin");
+
+static const struct of_device_id tegra_xhci_of_match[] = {
+ { .compatible = "nvidia,tegra124-xhci", .data = &tegra124_soc_data },
+ { },
+};
+MODULE_DEVICE_TABLE(of, tegra_xhci_of_match);
+
+static void tegra_xhci_probe_finish(const struct firmware *fw, void *context)
+{
+ struct tegra_xhci_hcd *tegra = context;
+ struct device *dev = tegra->dev;
+ struct xhci_hcd *xhci = NULL;
+ struct tegra_xhci_fw_cfgtbl *cfg_tbl;
+ struct tegra_xusb_mbox_msg msg;
+ int ret;
+
+ if (!fw)
+ goto put_usb2_hcd;
+
+ /* Load Falcon controller with its firmware. */
+ cfg_tbl = (struct tegra_xhci_fw_cfgtbl *)fw->data;
+ tegra->fw_size = le32_to_cpu(cfg_tbl->fwimg_len);
+ tegra->fw_data = dma_alloc_coherent(dev, tegra->fw_size,
+ &tegra->fw_dma_addr,
+ GFP_KERNEL);
+ if (!tegra->fw_data)
+ goto put_usb2_hcd;
+ memcpy(tegra->fw_data, fw->data, tegra->fw_size);
+
+ ret = tegra_xhci_load_firmware(tegra);
+ if (ret < 0)
+ goto put_usb2_hcd;
+
+ ret = usb_add_hcd(tegra->hcd, tegra->irq, IRQF_SHARED);
+ if (ret < 0)
+ goto put_usb2_hcd;
+ device_wakeup_enable(tegra->hcd->self.controller);
+
+ /*
+ * USB 2.0 roothub is stored in drvdata now. Swap it with the Tegra HCD.
+ */
+ tegra->hcd = dev_get_drvdata(dev);
+ dev_set_drvdata(dev, tegra);
+ xhci = hcd_to_xhci(tegra->hcd);
+ xhci->shared_hcd = usb_create_shared_hcd(&tegra_xhci_hc_driver,
+ dev, dev_name(dev),
+ tegra->hcd);
+ if (!xhci->shared_hcd)
+ goto dealloc_usb2_hcd;
+
+ ret = usb_add_hcd(xhci->shared_hcd, tegra->irq, IRQF_SHARED);
+ if (ret < 0)
+ goto put_usb3_hcd;
+
+ /* Enable firmware messages from controller. */
+ msg.cmd = MBOX_CMD_MSG_ENABLED;
+ msg.data = 0;
+ ret = mbox_send_message(tegra->mbox_chan, &msg);
+ if (ret < 0)
+ goto dealloc_usb3_hcd;
+
+ tegra->fw_loaded = true;
+ release_firmware(fw);
+ return;
+
+ /* Free up as much as we can and wait to be unbound. */
+dealloc_usb3_hcd:
+ usb_remove_hcd(xhci->shared_hcd);
+put_usb3_hcd:
+ usb_put_hcd(xhci->shared_hcd);
+dealloc_usb2_hcd:
+ usb_remove_hcd(tegra->hcd);
+ kfree(xhci);
+put_usb2_hcd:
+ usb_put_hcd(tegra->hcd);
+ tegra->hcd = NULL;
+ release_firmware(fw);
+}
+
+static int tegra_xhci_probe(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+ struct tegra_xhci_hcd *tegra;
+ struct resource *res;
+ struct usb_hcd *hcd;
+ struct phy *phy;
+ unsigned int i, j, k;
+ int ret;
+
+ BUILD_BUG_ON(sizeof(struct tegra_xhci_fw_cfgtbl) != 256);
+
+ tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
+ if (!tegra)
+ return -ENOMEM;
+ tegra->dev = &pdev->dev;
+ platform_set_drvdata(pdev, tegra);
+
+ match = of_match_device(tegra_xhci_of_match, &pdev->dev);
+ tegra->soc = match->data;
+
+ hcd = usb_create_hcd(&tegra_xhci_hc_driver, &pdev->dev,
+ dev_name(&pdev->dev));
+ if (!hcd)
+ return -ENOMEM;
+ tegra->hcd = hcd;
+
+ tegra->fpci_regs = dev_get_drvdata(pdev->dev.parent);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ hcd->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(hcd->regs)) {
+ ret = PTR_ERR(hcd->regs);
+ goto put_hcd;
+ }
+ hcd->rsrc_start = res->start;
+ hcd->rsrc_len = resource_size(res);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ tegra->ipfs_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(tegra->ipfs_base)) {
+ ret = PTR_ERR(tegra->ipfs_base);
+ goto put_hcd;
+ }
+
+ tegra->irq = platform_get_irq(pdev, 0);
+ if (tegra->irq < 0) {
+ ret = tegra->irq;
+ goto put_hcd;
+ }
+
+ tegra->host_rst = devm_reset_control_get(&pdev->dev, "xusb_host");
+ if (IS_ERR(tegra->host_rst)) {
+ ret = PTR_ERR(tegra->host_rst);
+ goto put_hcd;
+ }
+ tegra->ss_rst = devm_reset_control_get(&pdev->dev, "xusb_ss");
+ if (IS_ERR(tegra->ss_rst)) {
+ ret = PTR_ERR(tegra->ss_rst);
+ goto put_hcd;
+ }
+
+ tegra->host_clk = devm_clk_get(&pdev->dev, "xusb_host");
+ if (IS_ERR(tegra->host_clk)) {
+ ret = PTR_ERR(tegra->host_clk);
+ goto put_hcd;
+ }
+ tegra->falc_clk = devm_clk_get(&pdev->dev, "xusb_falcon_src");
+ if (IS_ERR(tegra->falc_clk)) {
+ ret = PTR_ERR(tegra->falc_clk);
+ goto put_hcd;
+ }
+ tegra->ss_clk = devm_clk_get(&pdev->dev, "xusb_ss");
+ if (IS_ERR(tegra->ss_clk)) {
+ ret = PTR_ERR(tegra->ss_clk);
+ goto put_hcd;
+ }
+ tegra->ss_src_clk = devm_clk_get(&pdev->dev, "xusb_ss_src");
+ if (IS_ERR(tegra->ss_src_clk)) {
+ ret = PTR_ERR(tegra->ss_src_clk);
+ goto put_hcd;
+ }
+ tegra->hs_src_clk = devm_clk_get(&pdev->dev, "xusb_hs_src");
+ if (IS_ERR(tegra->hs_src_clk)) {
+ ret = PTR_ERR(tegra->hs_src_clk);
+ goto put_hcd;
+ }
+ tegra->fs_src_clk = devm_clk_get(&pdev->dev, "xusb_fs_src");
+ if (IS_ERR(tegra->fs_src_clk)) {
+ ret = PTR_ERR(tegra->fs_src_clk);
+ goto put_hcd;
+ }
+ tegra->pll_u_480m = devm_clk_get(&pdev->dev, "pll_u_480m");
+ if (IS_ERR(tegra->pll_u_480m)) {
+ ret = PTR_ERR(tegra->pll_u_480m);
+ goto put_hcd;
+ }
+ tegra->clk_m = devm_clk_get(&pdev->dev, "clk_m");
+ if (IS_ERR(tegra->clk_m)) {
+ ret = PTR_ERR(tegra->clk_m);
+ goto put_hcd;
+ }
+ tegra->pll_e = devm_clk_get(&pdev->dev, "pll_e");
+ if (IS_ERR(tegra->pll_e)) {
+ ret = PTR_ERR(tegra->pll_e);
+ goto put_hcd;
+ }
+ ret = tegra_xhci_clk_enable(tegra);
+ if (ret)
+ goto put_hcd;
+
+ tegra->supplies = devm_kcalloc(&pdev->dev, tegra->soc->num_supplies,
+ sizeof(*tegra->supplies), GFP_KERNEL);
+ if (!tegra->supplies) {
+ ret = -ENOMEM;
+ goto put_hcd;
+ }
+ for (i = 0; i < tegra->soc->num_supplies; i++)
+ tegra->supplies[i].supply = tegra->soc->supply_names[i];
+ ret = devm_regulator_bulk_get(&pdev->dev, tegra->soc->num_supplies,
+ tegra->supplies);
+ if (ret)
+ goto disable_clk;
+ ret = regulator_bulk_enable(tegra->soc->num_supplies, tegra->supplies);
+ if (ret)
+ goto disable_clk;
+
+ INIT_WORK(&tegra->mbox_req_work, tegra_xhci_mbox_work);
+ tegra->mbox_client.dev = &pdev->dev;
+ tegra->mbox_client.tx_block = true;
+ tegra->mbox_client.tx_tout = 0;
+ tegra->mbox_client.rx_callback = tegra_xhci_mbox_rx;
+ tegra->mbox_chan = mbox_request_channel(&tegra->mbox_client, 0);
+ if (IS_ERR(tegra->mbox_chan)) {
+ ret = PTR_ERR(tegra->mbox_chan);
+ goto disable_regulator;
+ }
+
+ for (i = 0; i < tegra->soc->num_types; i++)
+ tegra->num_phys += tegra->soc->phy_types[i].num;
+ tegra->phys = devm_kcalloc(&pdev->dev, tegra->num_phys,
+ sizeof(*tegra->phys), GFP_KERNEL);
+ if (!tegra->phys) {
+ ret = -ENOMEM;
+ goto put_mbox;
+ }
+ for (i = 0, k = 0; i < tegra->soc->num_types; i++) {
+ char prop[8];
+
+ for (j = 0; j < tegra->soc->phy_types[i].num; j++) {
+ snprintf(prop, sizeof(prop), "%s-%d",
+ tegra->soc->phy_types[i].name, j);
+ phy = devm_phy_optional_get(&pdev->dev, prop);
+ if (IS_ERR(phy)) {
+ ret = PTR_ERR(phy);
+ goto put_mbox;
+ }
+ tegra->phys[k++] = phy;
+ }
+ }
+
+ tegra_xhci_ipfs_config(tegra);
+
+ ret = tegra_xhci_phy_enable(tegra);
+ if (ret < 0)
+ goto put_mbox;
+
+ ret = request_firmware_nowait(THIS_MODULE, true,
+ tegra->soc->firmware_file,
+ tegra->dev, GFP_KERNEL, tegra,
+ tegra_xhci_probe_finish);
+ if (ret < 0)
+ goto disable_phy;
+
+ return 0;
+
+disable_phy:
+ tegra_xhci_phy_disable(tegra);
+put_mbox:
+ mbox_free_channel(tegra->mbox_chan);
+disable_regulator:
+ regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
+disable_clk:
+ tegra_xhci_clk_disable(tegra);
+put_hcd:
+ usb_put_hcd(hcd);
+ return ret;
+}
+
+static int tegra_xhci_remove(struct platform_device *pdev)
+{
+ struct tegra_xhci_hcd *tegra = platform_get_drvdata(pdev);
+ struct usb_hcd *hcd = tegra->hcd;
+ struct xhci_hcd *xhci;
+
+ if (tegra->fw_loaded) {
+ xhci = hcd_to_xhci(hcd);
+ usb_remove_hcd(xhci->shared_hcd);
+ usb_put_hcd(xhci->shared_hcd);
+ usb_remove_hcd(hcd);
+ usb_put_hcd(hcd);
+ kfree(xhci);
+ } else if (hcd) {
+ /* Unbound after probe(), but before firmware loading. */
+ usb_put_hcd(hcd);
+ }
+
+ if (tegra->fw_data)
+ dma_free_coherent(tegra->dev, tegra->fw_size, tegra->fw_data,
+ tegra->fw_dma_addr);
+
+ cancel_work_sync(&tegra->mbox_req_work);
+ mbox_free_channel(tegra->mbox_chan);
+ tegra_xhci_phy_disable(tegra);
+ regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
+ tegra_xhci_clk_disable(tegra);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int tegra_xhci_suspend(struct device *dev)
+{
+ struct tegra_xhci_hcd *tegra = dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(tegra->hcd);
+ bool wakeup = device_may_wakeup(dev);
+
+ /* TODO: Powergate controller across suspend/resume. */
+ return xhci_suspend(xhci, wakeup);
+}
+
+static int tegra_xhci_resume(struct device *dev)
+{
+ struct tegra_xhci_hcd *tegra = dev_get_drvdata(dev);
+ struct xhci_hcd *xhci = hcd_to_xhci(tegra->hcd);
+
+ return xhci_resume(xhci, 0);
+}
+#endif
+
+static const struct dev_pm_ops tegra_xhci_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(tegra_xhci_suspend, tegra_xhci_resume)
+};
+
+static struct platform_driver tegra_xhci_driver = {
+ .probe = tegra_xhci_probe,
+ .remove = tegra_xhci_remove,
+ .driver = {
+ .name = "tegra-xhci",
+ .pm = &tegra_xhci_pm_ops,
+ .of_match_table = tegra_xhci_of_match,
+ },
+};
+
+static int __init tegra_xhci_init(void)
+{
+ xhci_init_driver(&tegra_xhci_hc_driver, tegra_xhci_setup);
+ return platform_driver_register(&tegra_xhci_driver);
+}
+module_init(tegra_xhci_init);
+
+static void __exit tegra_xhci_exit(void)
+{
+ platform_driver_unregister(&tegra_xhci_driver);
+}
+module_exit(tegra_xhci_exit);
+
+MODULE_AUTHOR("Andrew Bresticker <abrestic@chromium.org>");
+MODULE_DESCRIPTION("NVIDIA Tegra xHCI host-controller driver");
+MODULE_LICENSE("GPL v2");
--
2.2.0.rc0.207.ga3a616c
^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCH v8 0/9] Tegra xHCI support
2015-05-04 17:36 ` Andrew Bresticker
(?)
@ 2015-05-12 3:56 ` Jassi Brar
-1 siblings, 0 replies; 136+ messages in thread
From: Jassi Brar @ 2015-05-12 3:56 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
Devicetree List, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Linux Kernel Mailing List, Jon Hunter
On Mon, May 4, 2015 at 11:06 PM, Andrew Bresticker
<abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> This series adds support for xHCI on NVIDIA Tegra SoCs. This includes:
> - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI,
> - patches 4 and 5: adding an MFD driver for the XUSB cmoplex,
> - patches 6 and 7: adding a driver for the mailbox used to communicate
> with the xHCI controller's firmware, and
> - patches 8 and 9: adding a xHCI host-controller driver.
>
> The addition of USB PHY support to the XUSB padctl driver has been dropped.
> Thierry will be posting those patches later.
>
> Given the many compile and run-time dependencies in this series, it is probably
> best if the first 3 patches are picked up by the relevant maintainers in topic
> branches so that the remainder of the series can go through the Tegra tree.
>
> Tested on Jetson TK1 and Nyan-Big with a variety of USB2.0 and USB3.0 memory
> sticks and ethernet dongles. This has also been tested, with additional
> out-of-tree patches, on Tegra132 and Tegra210 based boards.
>
> Based on v4.1-rc2. A branch with the entire series is available at:
> https://github.com/abrestic/linux/tree/tegra-xhci-v8
>
> Cc: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Changes from v7:
> - Move non-shared resources into child nodes of MFD.
> - Fixed a couple of mailbox driver bugs.
>
> Changes from v6:
> - Dropped PHY changes from series. Will be posted later by Thierry.
> - Added an MFD device with the mailbox and xHCI host as sub-devices.
>
> Changes from v5:
> - Addressed review comments from Jassi and Felipe.
>
> Changes from v4:
> - Made USB support optional in padctl driver.
> - Made usb3-port a pinconfig property again.
> - Cleaned up mbox_request_channel() error handling and allowed it to defer
> probing (patch 3).
> - Minor xHCI (patch 1) and mailbox framework (patch 2) cleanups suggested
> by Thierry.
> - Addressed Thierry's review comments.
>
> Changes from v3:
> - Fixed USB2.0 flakiness on Jetson-TK1.
> - Switched to 32-bit DMA mask for host.
> - Addressed Stephen's review comments.
>
> Chagnes from v2:
> - Dropped mailbox channel specifier. The mailbox driver allocates virtual
> channels backed by the single physical channel.
> - Added support for HS_CURR_LEVEL adjustment pinconfig property, which
> will be required for the Blaze board.
> - Addressed Stephen's review comments.
>
> Changes from v1:
> - Converted mailbox driver to use the common mailbox framework.
> - Fixed up host driver so that it can now be built and used as a module.
> - Addressed Stephen's review comments.
> - Misc. cleanups.
>
> Andrew Bresticker (8):
> xhci: Set shared HCD's hcd_priv in xhci_gen_setup
> mailbox: Make mbox_chan_ops const
> mfd: Add binding document for NVIDIA Tegra XUSB
> mfd: Add driver for NVIDIA Tegra XUSB
> mailbox: Add NVIDIA Tegra XUSB mailbox binding
> mailbox: Add NVIDIA Tegra XUSB mailbox driver
> usb: Add NVIDIA Tegra xHCI controller binding
> usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
>
> Benson Leung (1):
> mailbox: Fix up error handling in mbox_request_channel()
>
> .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 +
> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 +
> .../bindings/usb/nvidia,tegra124-xhci.txt | 96 +++
> drivers/mailbox/Kconfig | 8 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/arm_mhu.c | 2 +-
> drivers/mailbox/mailbox-altera.c | 2 +-
> drivers/mailbox/mailbox.c | 11 +-
> drivers/mailbox/omap-mailbox.c | 8 +-
> drivers/mailbox/pcc.c | 2 +-
> drivers/mailbox/tegra-xusb-mailbox.c | 290 +++++++
> drivers/mfd/Kconfig | 7 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/tegra-xusb.c | 75 ++
> drivers/usb/host/Kconfig | 10 +
> drivers/usb/host/Makefile | 1 +
> drivers/usb/host/xhci-pci.c | 5 -
> drivers/usb/host/xhci-plat.c | 5 -
> drivers/usb/host/xhci-tegra.c | 947 +++++++++++++++++++++
> drivers/usb/host/xhci.c | 6 +-
> include/linux/mailbox_controller.h | 2 +-
> include/soc/tegra/xusb.h | 43 +
> 22 files changed, 1568 insertions(+), 24 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
> create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
> create mode 100644 drivers/mfd/tegra-xusb.c
> create mode 100644 drivers/usb/host/xhci-tegra.c
> create mode 100644 include/soc/tegra/xusb.h
>
Applied patches 2, 3, 6 & 7
Thanks.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v8 0/9] Tegra xHCI support
@ 2015-05-12 3:56 ` Jassi Brar
0 siblings, 0 replies; 136+ messages in thread
From: Jassi Brar @ 2015-05-12 3:56 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 4, 2015 at 11:06 PM, Andrew Bresticker
<abrestic@chromium.org> wrote:
> This series adds support for xHCI on NVIDIA Tegra SoCs. This includes:
> - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI,
> - patches 4 and 5: adding an MFD driver for the XUSB cmoplex,
> - patches 6 and 7: adding a driver for the mailbox used to communicate
> with the xHCI controller's firmware, and
> - patches 8 and 9: adding a xHCI host-controller driver.
>
> The addition of USB PHY support to the XUSB padctl driver has been dropped.
> Thierry will be posting those patches later.
>
> Given the many compile and run-time dependencies in this series, it is probably
> best if the first 3 patches are picked up by the relevant maintainers in topic
> branches so that the remainder of the series can go through the Tegra tree.
>
> Tested on Jetson TK1 and Nyan-Big with a variety of USB2.0 and USB3.0 memory
> sticks and ethernet dongles. This has also been tested, with additional
> out-of-tree patches, on Tegra132 and Tegra210 based boards.
>
> Based on v4.1-rc2. A branch with the entire series is available at:
> https://github.com/abrestic/linux/tree/tegra-xhci-v8
>
> Cc: Jon Hunter <jonathanh@nvidia.com>
>
> Changes from v7:
> - Move non-shared resources into child nodes of MFD.
> - Fixed a couple of mailbox driver bugs.
>
> Changes from v6:
> - Dropped PHY changes from series. Will be posted later by Thierry.
> - Added an MFD device with the mailbox and xHCI host as sub-devices.
>
> Changes from v5:
> - Addressed review comments from Jassi and Felipe.
>
> Changes from v4:
> - Made USB support optional in padctl driver.
> - Made usb3-port a pinconfig property again.
> - Cleaned up mbox_request_channel() error handling and allowed it to defer
> probing (patch 3).
> - Minor xHCI (patch 1) and mailbox framework (patch 2) cleanups suggested
> by Thierry.
> - Addressed Thierry's review comments.
>
> Changes from v3:
> - Fixed USB2.0 flakiness on Jetson-TK1.
> - Switched to 32-bit DMA mask for host.
> - Addressed Stephen's review comments.
>
> Chagnes from v2:
> - Dropped mailbox channel specifier. The mailbox driver allocates virtual
> channels backed by the single physical channel.
> - Added support for HS_CURR_LEVEL adjustment pinconfig property, which
> will be required for the Blaze board.
> - Addressed Stephen's review comments.
>
> Changes from v1:
> - Converted mailbox driver to use the common mailbox framework.
> - Fixed up host driver so that it can now be built and used as a module.
> - Addressed Stephen's review comments.
> - Misc. cleanups.
>
> Andrew Bresticker (8):
> xhci: Set shared HCD's hcd_priv in xhci_gen_setup
> mailbox: Make mbox_chan_ops const
> mfd: Add binding document for NVIDIA Tegra XUSB
> mfd: Add driver for NVIDIA Tegra XUSB
> mailbox: Add NVIDIA Tegra XUSB mailbox binding
> mailbox: Add NVIDIA Tegra XUSB mailbox driver
> usb: Add NVIDIA Tegra xHCI controller binding
> usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
>
> Benson Leung (1):
> mailbox: Fix up error handling in mbox_request_channel()
>
> .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 +
> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 +
> .../bindings/usb/nvidia,tegra124-xhci.txt | 96 +++
> drivers/mailbox/Kconfig | 8 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/arm_mhu.c | 2 +-
> drivers/mailbox/mailbox-altera.c | 2 +-
> drivers/mailbox/mailbox.c | 11 +-
> drivers/mailbox/omap-mailbox.c | 8 +-
> drivers/mailbox/pcc.c | 2 +-
> drivers/mailbox/tegra-xusb-mailbox.c | 290 +++++++
> drivers/mfd/Kconfig | 7 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/tegra-xusb.c | 75 ++
> drivers/usb/host/Kconfig | 10 +
> drivers/usb/host/Makefile | 1 +
> drivers/usb/host/xhci-pci.c | 5 -
> drivers/usb/host/xhci-plat.c | 5 -
> drivers/usb/host/xhci-tegra.c | 947 +++++++++++++++++++++
> drivers/usb/host/xhci.c | 6 +-
> include/linux/mailbox_controller.h | 2 +-
> include/soc/tegra/xusb.h | 43 +
> 22 files changed, 1568 insertions(+), 24 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
> create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
> create mode 100644 drivers/mfd/tegra-xusb.c
> create mode 100644 drivers/usb/host/xhci-tegra.c
> create mode 100644 include/soc/tegra/xusb.h
>
Applied patches 2, 3, 6 & 7
Thanks.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 0/9] Tegra xHCI support
@ 2015-05-12 3:56 ` Jassi Brar
0 siblings, 0 replies; 136+ messages in thread
From: Jassi Brar @ 2015-05-12 3:56 UTC (permalink / raw)
To: Andrew Bresticker
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
Devicetree List, linux-tegra, linux-usb, linux-arm-kernel,
Linux Kernel Mailing List, Jon Hunter
On Mon, May 4, 2015 at 11:06 PM, Andrew Bresticker
<abrestic@chromium.org> wrote:
> This series adds support for xHCI on NVIDIA Tegra SoCs. This includes:
> - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI,
> - patches 4 and 5: adding an MFD driver for the XUSB cmoplex,
> - patches 6 and 7: adding a driver for the mailbox used to communicate
> with the xHCI controller's firmware, and
> - patches 8 and 9: adding a xHCI host-controller driver.
>
> The addition of USB PHY support to the XUSB padctl driver has been dropped.
> Thierry will be posting those patches later.
>
> Given the many compile and run-time dependencies in this series, it is probably
> best if the first 3 patches are picked up by the relevant maintainers in topic
> branches so that the remainder of the series can go through the Tegra tree.
>
> Tested on Jetson TK1 and Nyan-Big with a variety of USB2.0 and USB3.0 memory
> sticks and ethernet dongles. This has also been tested, with additional
> out-of-tree patches, on Tegra132 and Tegra210 based boards.
>
> Based on v4.1-rc2. A branch with the entire series is available at:
> https://github.com/abrestic/linux/tree/tegra-xhci-v8
>
> Cc: Jon Hunter <jonathanh@nvidia.com>
>
> Changes from v7:
> - Move non-shared resources into child nodes of MFD.
> - Fixed a couple of mailbox driver bugs.
>
> Changes from v6:
> - Dropped PHY changes from series. Will be posted later by Thierry.
> - Added an MFD device with the mailbox and xHCI host as sub-devices.
>
> Changes from v5:
> - Addressed review comments from Jassi and Felipe.
>
> Changes from v4:
> - Made USB support optional in padctl driver.
> - Made usb3-port a pinconfig property again.
> - Cleaned up mbox_request_channel() error handling and allowed it to defer
> probing (patch 3).
> - Minor xHCI (patch 1) and mailbox framework (patch 2) cleanups suggested
> by Thierry.
> - Addressed Thierry's review comments.
>
> Changes from v3:
> - Fixed USB2.0 flakiness on Jetson-TK1.
> - Switched to 32-bit DMA mask for host.
> - Addressed Stephen's review comments.
>
> Chagnes from v2:
> - Dropped mailbox channel specifier. The mailbox driver allocates virtual
> channels backed by the single physical channel.
> - Added support for HS_CURR_LEVEL adjustment pinconfig property, which
> will be required for the Blaze board.
> - Addressed Stephen's review comments.
>
> Changes from v1:
> - Converted mailbox driver to use the common mailbox framework.
> - Fixed up host driver so that it can now be built and used as a module.
> - Addressed Stephen's review comments.
> - Misc. cleanups.
>
> Andrew Bresticker (8):
> xhci: Set shared HCD's hcd_priv in xhci_gen_setup
> mailbox: Make mbox_chan_ops const
> mfd: Add binding document for NVIDIA Tegra XUSB
> mfd: Add driver for NVIDIA Tegra XUSB
> mailbox: Add NVIDIA Tegra XUSB mailbox binding
> mailbox: Add NVIDIA Tegra XUSB mailbox driver
> usb: Add NVIDIA Tegra xHCI controller binding
> usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
>
> Benson Leung (1):
> mailbox: Fix up error handling in mbox_request_channel()
>
> .../bindings/mailbox/nvidia,tegra124-xusb-mbox.txt | 32 +
> .../bindings/mfd/nvidia,tegra124-xusb.txt | 37 +
> .../bindings/usb/nvidia,tegra124-xhci.txt | 96 +++
> drivers/mailbox/Kconfig | 8 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/arm_mhu.c | 2 +-
> drivers/mailbox/mailbox-altera.c | 2 +-
> drivers/mailbox/mailbox.c | 11 +-
> drivers/mailbox/omap-mailbox.c | 8 +-
> drivers/mailbox/pcc.c | 2 +-
> drivers/mailbox/tegra-xusb-mailbox.c | 290 +++++++
> drivers/mfd/Kconfig | 7 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/tegra-xusb.c | 75 ++
> drivers/usb/host/Kconfig | 10 +
> drivers/usb/host/Makefile | 1 +
> drivers/usb/host/xhci-pci.c | 5 -
> drivers/usb/host/xhci-plat.c | 5 -
> drivers/usb/host/xhci-tegra.c | 947 +++++++++++++++++++++
> drivers/usb/host/xhci.c | 6 +-
> include/linux/mailbox_controller.h | 2 +-
> include/soc/tegra/xusb.h | 43 +
> 22 files changed, 1568 insertions(+), 24 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mailbox/nvidia,tegra124-xusb-mbox.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/nvidia,tegra124-xusb.txt
> create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
> create mode 100644 drivers/mailbox/tegra-xusb-mailbox.c
> create mode 100644 drivers/mfd/tegra-xusb.c
> create mode 100644 drivers/usb/host/xhci-tegra.c
> create mode 100644 include/soc/tegra/xusb.h
>
Applied patches 2, 3, 6 & 7
Thanks.
^ permalink raw reply [flat|nested] 136+ messages in thread
[parent not found: <CABb+yY2WhH2gGbCr4n=m9HOa_843MuZDp=QWNDHbtB8AMYYwYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v8 0/9] Tegra xHCI support
2015-05-12 3:56 ` Jassi Brar
(?)
@ 2015-05-26 16:27 ` Andrew Bresticker
-1 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-26 16:27 UTC (permalink / raw)
To: Jassi Brar
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
Devicetree List, linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Linux Kernel Mailing List, Jon Hunter
Hi Jassi,
On Mon, May 11, 2015 at 8:56 PM, Jassi Brar <jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Applied patches 2, 3, 6 & 7
Please drop patches 6 and 7. Lee Jones has NAK'ed the MFD driver, so
I'll have to re-spin this series without using an MFD.
Thanks,
andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCH v8 0/9] Tegra xHCI support
@ 2015-05-26 16:27 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-26 16:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jassi,
On Mon, May 11, 2015 at 8:56 PM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> Applied patches 2, 3, 6 & 7
Please drop patches 6 and 7. Lee Jones has NAK'ed the MFD driver, so
I'll have to re-spin this series without using an MFD.
Thanks,
andrew
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCH v8 0/9] Tegra xHCI support
@ 2015-05-26 16:27 ` Andrew Bresticker
0 siblings, 0 replies; 136+ messages in thread
From: Andrew Bresticker @ 2015-05-26 16:27 UTC (permalink / raw)
To: Jassi Brar
Cc: Stephen Warren, Thierry Reding, Alexandre Courbot,
Devicetree List, linux-tegra, linux-usb, linux-arm-kernel,
Linux Kernel Mailing List, Jon Hunter
Hi Jassi,
On Mon, May 11, 2015 at 8:56 PM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> Applied patches 2, 3, 6 & 7
Please drop patches 6 and 7. Lee Jones has NAK'ed the MFD driver, so
I'll have to re-spin this series without using an MFD.
Thanks,
andrew
^ permalink raw reply [flat|nested] 136+ messages in thread