Re: [PATCH] pinctrl: pistachio: Use common error handling code in pistachio_gpio_register()

[Andrew Bresticker]

Markus,

On Mon, Oct 30, 2017 at 10:51 AM, SF Markus Elfring
<elfr...@users.sourceforge.net> wrote:
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Mon, 30 Oct 2017 18:40:10 +0100
>
> Adjust jump targets so that a bit of exception handling can be better
> reused at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>

Acked-by: Andrew Bresticker <abres...@chromium.org>

> ---
>  drivers/pinctrl/pinctrl-pistachio.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-pistachio.c 
> b/drivers/pinctrl/pinctrl-pistachio.c
> index 55375b1b3cc8..b314eb61bf35 100644
> --- a/drivers/pinctrl/pinctrl-pistachio.c
> +++ b/drivers/pinctrl/pinctrl-pistachio.c
> @@ -1362,21 +1362,21 @@ static int pistachio_gpio_register(struct 
> pistachio_pinctrl *pctl)
> if (!child) {
> dev_err(pctl->dev, "No node for bank %u\n", i);
> ret = -ENODEV;
> -   goto err;
> +   goto remove_chips;
> }
>
> if (!of_find_property(child, "gpio-controller", NULL)) {
> dev_err(pctl->dev,
> "No gpio-controller property for bank %u\n", 
> i);
> ret = -ENODEV;
> -   goto err;
> +   goto remove_chips;
> }
>
> irq = irq_of_parse_and_map(child, 0);
> if (irq < 0) {
> dev_err(pctl->dev, "No IRQ for bank %u: %d\n", i, 
> irq);
> ret = irq;
> -   goto err;
> +   goto remove_chips;
> }
>
> bank = >gpio_banks[i];
> @@ -1389,7 +1389,7 @@ static int pistachio_gpio_register(struct 
> pistachio_pinctrl *pctl)
> if (ret < 0) {
> dev_err(pctl->dev, "Failed to add GPIO chip %u: %d\n",
> i, ret);
> -   goto err;
> +   goto remove_chips;
> }
>
> ret = gpiochip_irqchip_add(>gpio_chip, >irq_chip,
> @@ -1397,8 +1397,7 @@ static int pistachio_gpio_register(struct 
> pistachio_pinctrl *pctl)
> if (ret < 0) {
> dev_err(pctl->dev, "Failed to add IRQ chip %u: %d\n",
> i, ret);
> -   gpiochip_remove(>gpio_chip);
> -   goto err;
> +   goto remove_chip;
> }
> gpiochip_set_chained_irqchip(>gpio_chip, 
> >irq_chip,
>  irq, pistachio_gpio_irq_handler);
> @@ -1409,13 +1408,15 @@ static int pistachio_gpio_register(struct 
> pistachio_pinctrl *pctl)
> if (ret < 0) {
> dev_err(pctl->dev, "Failed to add GPIO range %u: 
> %d\n",
> i, ret);
> -   gpiochip_remove(>gpio_chip);
> -   goto err;
> +   goto remove_chip;
> }
> }
>
> return 0;
> -err:
> +
> +remove_chip:
> +   gpiochip_remove(>gpio_chip);
> +remove_chips:
> for (; i > 0; i--) {
> bank = >gpio_banks[i - 1];
> gpiochip_remove(>gpio_chip);
> --
> 2.14.3
>

Re: [PATCH] pinctrl: pistachio: Use common error handling code in pistachio_gpio_register()

[Andrew Bresticker]

Markus,

On Mon, Oct 30, 2017 at 10:51 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Mon, 30 Oct 2017 18:40:10 +0100
>
> Adjust jump targets so that a bit of exception handling can be better
> reused at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 

Acked-by: Andrew Bresticker 

> ---
>  drivers/pinctrl/pinctrl-pistachio.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-pistachio.c 
> b/drivers/pinctrl/pinctrl-pistachio.c
> index 55375b1b3cc8..b314eb61bf35 100644
> --- a/drivers/pinctrl/pinctrl-pistachio.c
> +++ b/drivers/pinctrl/pinctrl-pistachio.c
> @@ -1362,21 +1362,21 @@ static int pistachio_gpio_register(struct 
> pistachio_pinctrl *pctl)
> if (!child) {
> dev_err(pctl->dev, "No node for bank %u\n", i);
> ret = -ENODEV;
> -   goto err;
> +   goto remove_chips;
> }
>
> if (!of_find_property(child, "gpio-controller", NULL)) {
> dev_err(pctl->dev,
> "No gpio-controller property for bank %u\n", 
> i);
> ret = -ENODEV;
> -   goto err;
> +   goto remove_chips;
> }
>
> irq = irq_of_parse_and_map(child, 0);
> if (irq < 0) {
> dev_err(pctl->dev, "No IRQ for bank %u: %d\n", i, 
> irq);
> ret = irq;
> -   goto err;
> +   goto remove_chips;
> }
>
> bank = >gpio_banks[i];
> @@ -1389,7 +1389,7 @@ static int pistachio_gpio_register(struct 
> pistachio_pinctrl *pctl)
> if (ret < 0) {
> dev_err(pctl->dev, "Failed to add GPIO chip %u: %d\n",
> i, ret);
> -   goto err;
> +   goto remove_chips;
> }
>
> ret = gpiochip_irqchip_add(>gpio_chip, >irq_chip,
> @@ -1397,8 +1397,7 @@ static int pistachio_gpio_register(struct 
> pistachio_pinctrl *pctl)
> if (ret < 0) {
> dev_err(pctl->dev, "Failed to add IRQ chip %u: %d\n",
> i, ret);
> -   gpiochip_remove(>gpio_chip);
> -   goto err;
> +   goto remove_chip;
> }
> gpiochip_set_chained_irqchip(>gpio_chip, 
> >irq_chip,
>  irq, pistachio_gpio_irq_handler);
> @@ -1409,13 +1408,15 @@ static int pistachio_gpio_register(struct 
> pistachio_pinctrl *pctl)
> if (ret < 0) {
> dev_err(pctl->dev, "Failed to add GPIO range %u: 
> %d\n",
> i, ret);
> -   gpiochip_remove(>gpio_chip);
> -   goto err;
> +   goto remove_chip;
> }
> }
>
> return 0;
> -err:
> +
> +remove_chip:
> +   gpiochip_remove(>gpio_chip);
> +remove_chips:
> for (; i > 0; i--) {
> bank = >gpio_banks[i - 1];
> gpiochip_remove(>gpio_chip);
> --
> 2.14.3
>

Re: [PATCH] arm64: tegra: Add missing Smaug revision

[Andrew Bresticker]

On Wed, Jun 29, 2016 at 1:52 AM, Alexandre Courbot <acour...@nvidia.com> wrote:
> The "google,smaug-rev2" string is missing from the compatible list of
> Smaug's DT. The differences of rev2 are not relevant at our current
> level of support and it boots just fine, so add it.
>
> Signed-off-by: Alexandre Courbot <acour...@nvidia.com>

Acked-by: Andrew Bresticker <abres...@chromium.org>

> ---
>  arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts 
> b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> index 431266a48e9c..82a96bd27bc8 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> @@ -11,7 +11,8 @@
> compatible = "google,smaug-rev8", "google,smaug-rev7",
>  "google,smaug-rev6", "google,smaug-rev5",
>  "google,smaug-rev4", "google,smaug-rev3",
> -"google,smaug-rev1", "google,smaug", "nvidia,tegra210";
> +"google,smaug-rev2", "google,smaug-rev1",
> +"google,smaug", "nvidia,tegra210";
>
> aliases {
> serial0 = 
> --
> 2.9.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: tegra: Add missing Smaug revision

[Andrew Bresticker]

On Wed, Jun 29, 2016 at 1:52 AM, Alexandre Courbot  wrote:
> The "google,smaug-rev2" string is missing from the compatible list of
> Smaug's DT. The differences of rev2 are not relevant at our current
> level of support and it boots just fine, so add it.
>
> Signed-off-by: Alexandre Courbot 

Acked-by: Andrew Bresticker 

> ---
>  arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts 
> b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> index 431266a48e9c..82a96bd27bc8 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
> @@ -11,7 +11,8 @@
> compatible = "google,smaug-rev8", "google,smaug-rev7",
>  "google,smaug-rev6", "google,smaug-rev5",
>  "google,smaug-rev4", "google,smaug-rev3",
> -"google,smaug-rev1", "google,smaug", "nvidia,tegra210";
> +"google,smaug-rev2", "google,smaug-rev1",
> +"google,smaug", "nvidia,tegra210";
>
> aliases {
> serial0 = 
> --
> 2.9.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Andrew Bresticker]

> +Required properties:
> +
> +- compatible: Must be:
> +  - Tegra124: "nvidia,tegra124-xusb-padctl"
> +  - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl"
> +- reg: Physical base address and length of the controller's registers.
> +- resets: Must contain an entry for each entry in reset-names.
> +- reset-names: Must include the following entries:
> +  - "padctl"

Also... there's a padctl interrupt that'll be necessary for LP0
suspend/resume and runtime power-gating of the xHC.  We should
probably include that here too.

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Andrew Bresticker]

> +Required properties:
> +
> +- compatible: Must be:
> +  - Tegra124: "nvidia,tegra124-xusb-padctl"
> +  - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl"
> +- reg: Physical base address and length of the controller's registers.
> +- resets: Must contain an entry for each entry in reset-names.
> +- reset-names: Must include the following entries:
> +  - "padctl"

Also... there's a padctl interrupt that'll be necessary for LP0
suspend/resume and runtime power-gating of the xHC.  We should
probably include that here too.

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

[Andrew Bresticker]

On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding  wrote:
> From: Thierry Reding 
>
> Extend the binding to cover the set of feature found in Tegra210.
>
> Signed-off-by: Thierry Reding 

> +PCIe pad:
> +-
> +
> +Required properties:
> +- clocks: Must contain an entry for each entry in clock-names.
> +- clock-names: Must contain the following entries:
> +  - "pll": phandle and specifier referring to the PLLE
> +- resets: Must contain an entry for each entry in reset-names.
> +- reset-names: Must contain the following entries:
> +  - "phy": reset for the PCIe UPHY block
> +
> +SATA pad:
> +-
> +
> +Required properties:
> +- resets: Must contain an entry for each entry in reset-names.
> +- reset-names: Must contain the following entries:
> +  - "phy": reset for the SATA UPHY block

Doesn't the SATA pad require PLLE as well?  You've included it in the
example DT fragment, but it's absent here.

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

[Andrew Bresticker]

On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding  wrote:
> From: Thierry Reding 
>
> Extend the binding to cover the set of feature found in Tegra210.
>
> Signed-off-by: Thierry Reding 

> +PCIe pad:
> +-
> +
> +Required properties:
> +- clocks: Must contain an entry for each entry in clock-names.
> +- clock-names: Must contain the following entries:
> +  - "pll": phandle and specifier referring to the PLLE
> +- resets: Must contain an entry for each entry in reset-names.
> +- reset-names: Must contain the following entries:
> +  - "phy": reset for the PCIe UPHY block
> +
> +SATA pad:
> +-
> +
> +Required properties:
> +- resets: Must contain an entry for each entry in reset-names.
> +- reset-names: Must contain the following entries:
> +  - "phy": reset for the SATA UPHY block

Doesn't the SATA pad require PLLE as well?  You've included it in the
example DT fragment, but it's absent here.

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Andrew Bresticker]

Hi Thierry,

On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding  wrote:
> From: Thierry Reding 
>
> The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
> set of lanes that are used for PCIe, SATA and USB.
>
> Signed-off-by: Thierry Reding 

Thanks, this binding looks much better, IMO.  A couple small comments below...

> +Port nodes:
> +===
> +
> +A required child node named "ports" contains a list of all the ports exposed
> +by the XUSB pad controller. Per-port configuration is only required for USB.
> +
> +USB2 ports:
> +---
> +
> +Required properties:
> +- status: Defines the operation status of the port. Valid values are:
> +  - "disabled": the port is disabled
> +  - "okay": the port is enabled
> +- mode: A string that determines the mode in which to run the port. Valid
> +  values are:
> +  - "host": for USB host mode
> +  - "device": for USB device mode
> +  - "otg": for USB OTG mode
> +
> +Optional properties:
> +- nvidia,internal: A boolean property whose presence determines that a port
> +  is internal. In the absence of this property the port is considered to be
> +  external.
> +- vbus-supply: phandle to a regulator supplying the VBUS voltage.

Both Blaze and Smaug require an offset to be applied to the fused
HS_CURR_LEVEL value, so I think we need another property here for
that.

> +ULPI ports:
> +---
> +
> +Optional properties:
> +- status: Defines the operation status of the port. Valid values are:
> +  - "disabled": the port is disabled
> +  - "okay": the port is enabled
> +- nvidia,internal: A boolean property whose presence determines that a port
> +  is internal. In the absence of this property the port is considered to be
> +  external.
> +- vbus-supply: phandle to a regulator supplying the VBUS voltage.
> +
> +HSIC ports:
> +---
> +
> +Required properties:
> +- status: Defines the operation status of the port. Valid values are:
> +  - "disabled": the port is disabled
> +  - "okay": the port is enabled
> +
> +Optional properties:
> +- vbus-supply: phandle to a regulator supplying the VBUS voltage.

I believe this pin is named VDDIO_HSIC?

Also there are several other HSIC pad parameters (STROBE_TRIM,
DATA_TRIM, etc.) which probably should be supplied via DT.

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Andrew Bresticker]

Hi Thierry,

On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding  wrote:
> From: Thierry Reding 
>
> The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
> set of lanes that are used for PCIe, SATA and USB.
>
> Signed-off-by: Thierry Reding 

Thanks, this binding looks much better, IMO.  A couple small comments below...

> +Port nodes:
> +===
> +
> +A required child node named "ports" contains a list of all the ports exposed
> +by the XUSB pad controller. Per-port configuration is only required for USB.
> +
> +USB2 ports:
> +---
> +
> +Required properties:
> +- status: Defines the operation status of the port. Valid values are:
> +  - "disabled": the port is disabled
> +  - "okay": the port is enabled
> +- mode: A string that determines the mode in which to run the port. Valid
> +  values are:
> +  - "host": for USB host mode
> +  - "device": for USB device mode
> +  - "otg": for USB OTG mode
> +
> +Optional properties:
> +- nvidia,internal: A boolean property whose presence determines that a port
> +  is internal. In the absence of this property the port is considered to be
> +  external.
> +- vbus-supply: phandle to a regulator supplying the VBUS voltage.

Both Blaze and Smaug require an offset to be applied to the fused
HS_CURR_LEVEL value, so I think we need another property here for
that.

> +ULPI ports:
> +---
> +
> +Optional properties:
> +- status: Defines the operation status of the port. Valid values are:
> +  - "disabled": the port is disabled
> +  - "okay": the port is enabled
> +- nvidia,internal: A boolean property whose presence determines that a port
> +  is internal. In the absence of this property the port is considered to be
> +  external.
> +- vbus-supply: phandle to a regulator supplying the VBUS voltage.
> +
> +HSIC ports:
> +---
> +
> +Required properties:
> +- status: Defines the operation status of the port. Valid values are:
> +  - "disabled": the port is disabled
> +  - "okay": the port is enabled
> +
> +Optional properties:
> +- vbus-supply: phandle to a regulator supplying the VBUS voltage.

I believe this pin is named VDDIO_HSIC?

Also there are several other HSIC pad parameters (STROBE_TRIM,
DATA_TRIM, etc.) which probably should be supplied via DT.

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

[Andrew Bresticker]

Hi Martyn,

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

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

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

Tegra124?  Tegra210?  Which board?

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

Re: [PATCH 1/2] Input: Add binding document for a generic ADC keypad

[Andrew Bresticker]

Hi Fabio,

On Sun, Nov 1, 2015 at 5:55 AM, Fabio Estevam  wrote:
> Hi Andrew,
>
> On Mon, Mar 30, 2015 at 1:56 AM, Andrew Bresticker
>  wrote:
>
>>> I'd rather we have it defined explicitly in the binding, i.e. make it a
>>> required property?
>>
>> Sure, will do.
>
> Do you plan to send a v2 of the generic ADC keypad series?

We ended up not needing this driver, so I didn't send up a v2.

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

Re: [PATCH 1/2] Input: Add binding document for a generic ADC keypad

[Andrew Bresticker]

Hi Fabio,

On Sun, Nov 1, 2015 at 5:55 AM, Fabio Estevam <feste...@gmail.com> wrote:
> Hi Andrew,
>
> On Mon, Mar 30, 2015 at 1:56 AM, Andrew Bresticker
> <abres...@chromium.org> wrote:
>
>>> I'd rather we have it defined explicitly in the binding, i.e. make it a
>>> required property?
>>
>> Sure, will do.
>
> Do you plan to send a v2 of the generic ADC keypad series?

We ended up not needing this driver, so I didn't send up a v2.

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

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

[Andrew Bresticker]

Hi Martyn,

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

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

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

Tegra124?  Tegra210?  Which board?

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

Re: [PATCH 2/2] clk: Convert __clk_get_name(hw->clk) to clk_hw_get_name(hw)

[Andrew Bresticker]

On Wed, Aug 12, 2015 at 4:12 PM, Stephen Boyd  wrote:
> Use the provider based method to get a clock's name so that we
> can get rid of the clk member in struct clk_hw one day. Mostly
> converted with the following coccinelle script.
>
> @@
> struct clk_hw *E;
> @@
>
> -__clk_get_name(E->clk)
> +clk_hw_get_name(E)
>
> Cc: Heiko Stuebner 
> Cc: Sylwester Nawrocki 
> Cc: Tomasz Figa 
> Cc: Peter De Schrijver 
> Cc: Prashant Gaikwad 
> Cc: Stephen Warren 
> Cc: Thierry Reding 
> Cc: Alexandre Courbot 
> Cc: Tero Kristo 
> Cc: Ulf Hansson 
> Cc: Sebastian Hesselbarth 
> Cc: Andrew Bresticker 
> Cc: Ezequiel Garcia 
> Cc: Ralf Baechle 
> Cc: Kevin Cernekee 
> Cc: Geert Uytterhoeven 
> Cc: Ulrich Hecht 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Signed-off-by: Stephen Boyd 

>  drivers/clk/pistachio/clk-pll.c  |  4 ++--

For Pistachio,

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

Re: [PATCH 2/2] clk: Convert __clk_get_name(hw-clk) to clk_hw_get_name(hw)

[Andrew Bresticker]

On Wed, Aug 12, 2015 at 4:12 PM, Stephen Boyd sb...@codeaurora.org wrote:
 Use the provider based method to get a clock's name so that we
 can get rid of the clk member in struct clk_hw one day. Mostly
 converted with the following coccinelle script.

 @@
 struct clk_hw *E;
 @@

 -__clk_get_name(E-clk)
 +clk_hw_get_name(E)

 Cc: Heiko Stuebner he...@sntech.de
 Cc: Sylwester Nawrocki s.nawro...@samsung.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Peter De Schrijver pdeschrij...@nvidia.com
 Cc: Prashant Gaikwad pgaik...@nvidia.com
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Thierry Reding thierry.red...@gmail.com
 Cc: Alexandre Courbot gnu...@gmail.com
 Cc: Tero Kristo t-kri...@ti.com
 Cc: Ulf Hansson ulf.hans...@linaro.org
 Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
 Cc: Andrew Bresticker abres...@chromium.org
 Cc: Ezequiel Garcia ezequiel.gar...@imgtec.com
 Cc: Ralf Baechle r...@linux-mips.org
 Cc: Kevin Cernekee cerne...@chromium.org
 Cc: Geert Uytterhoeven geert+rene...@glider.be
 Cc: Ulrich Hecht ulrich.hecht+rene...@gmail.com
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-rockc...@lists.infradead.org
 Cc: linux-samsung-...@vger.kernel.org
 Cc: linux-te...@vger.kernel.org
 Cc: linux-o...@vger.kernel.org
 Signed-off-by: Stephen Boyd sb...@codeaurora.org

  drivers/clk/pistachio/clk-pll.c  |  4 ++--

For Pistachio,

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

Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality

[Andrew Bresticker]

Hi Roger,

On Wed, Jul 15, 2015 at 6:26 AM, Roger Quadros  wrote:
> Hi Andrew,
>
> On 13/07/15 22:14, Andrew Bresticker wrote:
>> Hi Roger,
>>
>> On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros  wrote:
>>> Usage model:
>>> ---
>>>
>>> - The OTG controller device is assumed to be the parent of
>>> the host and gadget controller. It must call usb_otg_register()
>>> before populating the host and gadget devices so that the OTG
>>> core is aware that it is an OTG device before the host & gadget
>>> register. The OTG controller must provide struct otg_fsm_ops *
>>> which will be called by the OTG core depending on OTG bus state.
>>
>> I'm wondering if the requirement that the OTG controller be the parent
>> of the USB host/device-controllers makes sense.  For some context, I'm
>> working on adding dual-role support for Tegra210, specifically on a
>> system with USB Type-C.  On Tegra, the USB host-controller and USB
>> device-controller are two separate IP blocks (XUSB host and XUSB
>> device) with another, separate, IP block (XUSB padctl) for the USB PHY
>> and OTG support.  In the non-Type-C case, your OTG framework could
>> work well, though it's debatable as to whether or not the XUSB padctl
>> device should be a parent to the XUSB host/device-controller devices
>> (currently it isn't - it's just a PHY provider).  But in the Type-C
>> case, it's an off-chip embedded controller that determines the
>> dual-role status of the Type-C port, so the above requirement doesn't
>> make sense at all.
>>
>> My idea was to have the OTG/DRD controller explicitly specify its host
>> and device controllers, so in DT, something like:
>>
>> otg-controller {
>> ...
>> device-controller = <_device>;
>> host-controller = <_host>;
>> ...
>> };
>>
>> usb_device: usb-device@ {
>> ...
>> };
>>
>> usb_host: usb-host@... {
>> ...
>> };
>>
>> What do you think?
>
> I agree that we need to support your use case but how to do it
> is not yet clear to me.
>
> In your above example the otg controller knows what are the host
> and gadget controllers but the host/gadget devices don't
> know who is their otg controller.
>
> So the problem is that when usb_otg_register_hcd/gadget() is called
> we need to get a handle to the otg controller.
>
> One solution I see is to iterate over the registered otg_controller_list
> and check if we match the host/gadget controller in there.
>
> Then there is also a possibility that host/gadget controllers get
> registered before the OTG controller. Then we can't know for sure if
> the host/gadget controller was meant for dual-role operation or not
> and it will resort to single role operation.
>
> Any idea to prevent the above situation?
>
> Maybe we need to add some logic in host/gadget cores to check if the port
> is meant for dual-role use and defer probe if OTG controller is not yet
> registered?

In the DT case, I think we could add an "otg-controller" property to
the host and gadget nodes, and in usb_otg_register_{hcd,gadget}()
check for that property and defer probe if the referenced OTG
controller has not yet been registered.  Not sure how to indicate that
a host/gadget is meant for dual-role operation on non-DT platforms
though.

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

Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality

[Andrew Bresticker]

Hi Roger,

On Wed, Jul 15, 2015 at 6:26 AM, Roger Quadros rog...@ti.com wrote:
 Hi Andrew,

 On 13/07/15 22:14, Andrew Bresticker wrote:
 Hi Roger,

 On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros rog...@ti.com wrote:
 Usage model:
 ---

 - The OTG controller device is assumed to be the parent of
 the host and gadget controller. It must call usb_otg_register()
 before populating the host and gadget devices so that the OTG
 core is aware that it is an OTG device before the host  gadget
 register. The OTG controller must provide struct otg_fsm_ops *
 which will be called by the OTG core depending on OTG bus state.

 I'm wondering if the requirement that the OTG controller be the parent
 of the USB host/device-controllers makes sense.  For some context, I'm
 working on adding dual-role support for Tegra210, specifically on a
 system with USB Type-C.  On Tegra, the USB host-controller and USB
 device-controller are two separate IP blocks (XUSB host and XUSB
 device) with another, separate, IP block (XUSB padctl) for the USB PHY
 and OTG support.  In the non-Type-C case, your OTG framework could
 work well, though it's debatable as to whether or not the XUSB padctl
 device should be a parent to the XUSB host/device-controller devices
 (currently it isn't - it's just a PHY provider).  But in the Type-C
 case, it's an off-chip embedded controller that determines the
 dual-role status of the Type-C port, so the above requirement doesn't
 make sense at all.

 My idea was to have the OTG/DRD controller explicitly specify its host
 and device controllers, so in DT, something like:

 otg-controller {
 ...
 device-controller = usb_device;
 host-controller = usb_host;
 ...
 };

 usb_device: usb-device@ {
 ...
 };

 usb_host: usb-host@... {
 ...
 };

 What do you think?

 I agree that we need to support your use case but how to do it
 is not yet clear to me.

 In your above example the otg controller knows what are the host
 and gadget controllers but the host/gadget devices don't
 know who is their otg controller.

 So the problem is that when usb_otg_register_hcd/gadget() is called
 we need to get a handle to the otg controller.

 One solution I see is to iterate over the registered otg_controller_list
 and check if we match the host/gadget controller in there.

 Then there is also a possibility that host/gadget controllers get
 registered before the OTG controller. Then we can't know for sure if
 the host/gadget controller was meant for dual-role operation or not
 and it will resort to single role operation.

 Any idea to prevent the above situation?

 Maybe we need to add some logic in host/gadget cores to check if the port
 is meant for dual-role use and defer probe if OTG controller is not yet
 registered?

In the DT case, I think we could add an otg-controller property to
the host and gadget nodes, and in usb_otg_register_{hcd,gadget}()
check for that property and defer probe if the referenced OTG
controller has not yet been registered.  Not sure how to indicate that
a host/gadget is meant for dual-role operation on non-DT platforms
though.

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

Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality

[Andrew Bresticker]

Hi Peter,

On Mon, Jul 13, 2015 at 5:59 PM, Peter Chen  wrote:
> On Mon, Jul 13, 2015 at 12:14:43PM -0700, Andrew Bresticker wrote:
>> Hi Roger,
>>
>> On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros  wrote:
>> > Usage model:
>> > ---
>> >
>> > - The OTG controller device is assumed to be the parent of
>> > the host and gadget controller. It must call usb_otg_register()
>> > before populating the host and gadget devices so that the OTG
>> > core is aware that it is an OTG device before the host & gadget
>> > register. The OTG controller must provide struct otg_fsm_ops *
>> > which will be called by the OTG core depending on OTG bus state.
>>
>> I'm wondering if the requirement that the OTG controller be the parent
>> of the USB host/device-controllers makes sense.  For some context, I'm
>> working on adding dual-role support for Tegra210, specifically on a
>> system with USB Type-C.  On Tegra, the USB host-controller and USB
>> device-controller are two separate IP blocks (XUSB host and XUSB
>> device) with another, separate, IP block (XUSB padctl) for the USB PHY
>> and OTG support.  In the non-Type-C case, your OTG framework could
>> work well, though it's debatable as to whether or not the XUSB padctl
>> device should be a parent to the XUSB host/device-controller devices
>> (currently it isn't - it's just a PHY provider).  But in the Type-C
>> case, it's an off-chip embedded controller that determines the
>> dual-role status of the Type-C port, so the above requirement doesn't
>> make sense at all.
>
> Hi Andrew,
>
> I think your problem is how to add your core driver to manage device and
> host functionality together, and once you find how (through padctl/type-c
> controller) to do it based on current code, it will be clear how to use roger
> proposal framework at that time.
>
> Most of current core drivers, we use extcon driver (through gpio) or USB
> vbus/id pin (through internal registers) to manager roles.

Right, currently I'm modeling the Type-C controller as an extcon
device and handle the role-changes in the core drivers, but that
doesn't really make sense for the non-Type-C case where we use the
XUSB padctl controller and need a full OTG state-machine.  Roger's new
OTG/DRD framework would fit my situation perfectly since it makes the
host/device-controller drivers independent from all the
OTG/role-changing logic.  The only issue is the requirement that the
OTG/DRD controller be the parent device of the host/device
controllers.

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

Re: [PATCH v2 4/8] MIPS: Remove "weak" from get_c0_perfcount_int() declaration

[Andrew Bresticker]

Hi Bjorn,

On Tue, Jul 14, 2015 at 9:46 AM, Bjorn Helgaas  wrote:
> Weak header file declarations are error-prone because they make every
> definition weak, and the linker chooses one based on link order (see
> 10629d711ed7 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node
> decl")).
>
> get_c0_perfcount_int() is defined in several files.  Every definition is
> weak, so I assume Kconfig prevents two or more from being included.  The
> callers contain identical default code used when get_c0_perfcount_int()
> isn't defined at all.
>
> Add a weak get_c0_perfcount_int() definition with the default code and
> remove the weak annotation from the declaration.
>
> Then the platform implementations will be strong and will override the weak
> default.  If multiple platforms are ever configured in, we'll get a link
> error instead of calling a random platform's implementation.
>
> Signed-off-by: Bjorn Helgaas 
> CC: Andrew Bresticker 

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

Re: [PATCH v2 4/8] MIPS: Remove weak from get_c0_perfcount_int() declaration

[Andrew Bresticker]

Hi Bjorn,

On Tue, Jul 14, 2015 at 9:46 AM, Bjorn Helgaas bhelg...@google.com wrote:
 Weak header file declarations are error-prone because they make every
 definition weak, and the linker chooses one based on link order (see
 10629d711ed7 (PCI: Remove __weak annotation from pcibios_get_phb_of_node
 decl)).

 get_c0_perfcount_int() is defined in several files.  Every definition is
 weak, so I assume Kconfig prevents two or more from being included.  The
 callers contain identical default code used when get_c0_perfcount_int()
 isn't defined at all.

 Add a weak get_c0_perfcount_int() definition with the default code and
 remove the weak annotation from the declaration.

 Then the platform implementations will be strong and will override the weak
 default.  If multiple platforms are ever configured in, we'll get a link
 error instead of calling a random platform's implementation.

 Signed-off-by: Bjorn Helgaas bhelg...@google.com
 CC: Andrew Bresticker abres...@chromium.org

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

Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality

[Andrew Bresticker]

Hi Peter,

On Mon, Jul 13, 2015 at 5:59 PM, Peter Chen peter.c...@freescale.com wrote:
 On Mon, Jul 13, 2015 at 12:14:43PM -0700, Andrew Bresticker wrote:
 Hi Roger,

 On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros rog...@ti.com wrote:
  Usage model:
  ---
 
  - The OTG controller device is assumed to be the parent of
  the host and gadget controller. It must call usb_otg_register()
  before populating the host and gadget devices so that the OTG
  core is aware that it is an OTG device before the host  gadget
  register. The OTG controller must provide struct otg_fsm_ops *
  which will be called by the OTG core depending on OTG bus state.

 I'm wondering if the requirement that the OTG controller be the parent
 of the USB host/device-controllers makes sense.  For some context, I'm
 working on adding dual-role support for Tegra210, specifically on a
 system with USB Type-C.  On Tegra, the USB host-controller and USB
 device-controller are two separate IP blocks (XUSB host and XUSB
 device) with another, separate, IP block (XUSB padctl) for the USB PHY
 and OTG support.  In the non-Type-C case, your OTG framework could
 work well, though it's debatable as to whether or not the XUSB padctl
 device should be a parent to the XUSB host/device-controller devices
 (currently it isn't - it's just a PHY provider).  But in the Type-C
 case, it's an off-chip embedded controller that determines the
 dual-role status of the Type-C port, so the above requirement doesn't
 make sense at all.

 Hi Andrew,

 I think your problem is how to add your core driver to manage device and
 host functionality together, and once you find how (through padctl/type-c
 controller) to do it based on current code, it will be clear how to use roger
 proposal framework at that time.

 Most of current core drivers, we use extcon driver (through gpio) or USB
 vbus/id pin (through internal registers) to manager roles.

Right, currently I'm modeling the Type-C controller as an extcon
device and handle the role-changes in the core drivers, but that
doesn't really make sense for the non-Type-C case where we use the
XUSB padctl controller and need a full OTG state-machine.  Roger's new
OTG/DRD framework would fit my situation perfectly since it makes the
host/device-controller drivers independent from all the
OTG/role-changing logic.  The only issue is the requirement that the
OTG/DRD controller be the parent device of the host/device
controllers.

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

Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality

[Andrew Bresticker]

Hi Roger,

On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros  wrote:
> Usage model:
> ---
>
> - The OTG controller device is assumed to be the parent of
> the host and gadget controller. It must call usb_otg_register()
> before populating the host and gadget devices so that the OTG
> core is aware that it is an OTG device before the host & gadget
> register. The OTG controller must provide struct otg_fsm_ops *
> which will be called by the OTG core depending on OTG bus state.

I'm wondering if the requirement that the OTG controller be the parent
of the USB host/device-controllers makes sense.  For some context, I'm
working on adding dual-role support for Tegra210, specifically on a
system with USB Type-C.  On Tegra, the USB host-controller and USB
device-controller are two separate IP blocks (XUSB host and XUSB
device) with another, separate, IP block (XUSB padctl) for the USB PHY
and OTG support.  In the non-Type-C case, your OTG framework could
work well, though it's debatable as to whether or not the XUSB padctl
device should be a parent to the XUSB host/device-controller devices
(currently it isn't - it's just a PHY provider).  But in the Type-C
case, it's an off-chip embedded controller that determines the
dual-role status of the Type-C port, so the above requirement doesn't
make sense at all.

My idea was to have the OTG/DRD controller explicitly specify its host
and device controllers, so in DT, something like:

otg-controller {
...
device-controller = <_device>;
host-controller = <_host>;
...
};

usb_device: usb-device@ {
...
};

usb_host: usb-host@... {
...
};

What do you think?

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

Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality

[Andrew Bresticker]

Hi Roger,

On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros rog...@ti.com wrote:
 Usage model:
 ---

 - The OTG controller device is assumed to be the parent of
 the host and gadget controller. It must call usb_otg_register()
 before populating the host and gadget devices so that the OTG
 core is aware that it is an OTG device before the host  gadget
 register. The OTG controller must provide struct otg_fsm_ops *
 which will be called by the OTG core depending on OTG bus state.

I'm wondering if the requirement that the OTG controller be the parent
of the USB host/device-controllers makes sense.  For some context, I'm
working on adding dual-role support for Tegra210, specifically on a
system with USB Type-C.  On Tegra, the USB host-controller and USB
device-controller are two separate IP blocks (XUSB host and XUSB
device) with another, separate, IP block (XUSB padctl) for the USB PHY
and OTG support.  In the non-Type-C case, your OTG framework could
work well, though it's debatable as to whether or not the XUSB padctl
device should be a parent to the XUSB host/device-controller devices
(currently it isn't - it's just a PHY provider).  But in the Type-C
case, it's an off-chip embedded controller that determines the
dual-role status of the Type-C port, so the above requirement doesn't
make sense at all.

My idea was to have the OTG/DRD controller explicitly specify its host
and device controllers, so in DT, something like:

otg-controller {
...
device-controller = usb_device;
host-controller = usb_host;
...
};

usb_device: usb-device@ {
...
};

usb_host: usb-host@... {
...
};

What do you think?

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

Re: [PATCH V2 0/3] Pistachio USB2.0 PHY

[Andrew Bresticker]

On Wed, Jun 3, 2015 at 8:44 AM, Andrew Bresticker  wrote:
> On Tue, Jun 2, 2015 at 11:07 PM, Kishon Vijay Abraham I  wrote:
>>
>>
>> On Monday 11 May 2015 08:15 PM, Kishon Vijay Abraham I wrote:
>>>
>>>
>>>
>>> On Tuesday 05 May 2015 11:43 PM, Ezequiel Garcia wrote:
>>>>
>>>> Hi Kishon,
>>>>
>>>>>
>>>>> This series adds support for the USB2.0 PHY present on the IMG Pistachio
>>>>> SoC.
>>>>>
>>>>> Based on mips-for-linux-next and tested on the IMG Pistachio BuB.  If
>>>>> possible,
>>>>> I'd like this to go through the MIPS tree with Kishon's ACK.
>>>>>
>>>>
>>>> Tested-by: Ezequiel Garcia 
>>>>
>>>> Can we have your Ack for this series so Ralf can pick it?
>>>
>>>
>>> sure..
>>>
>>> Acked-by: Kishon Vijay Abraham I 
>>
>>
>> I'm not sure if this has been merged yet. But this will cause conflicts with
>> other PHY patches in Makefile and Kconfig when linus merges to his tree. I'd
>> prefer the phy patches go in PHY tree itself.
>
> It doesn't look like Ralf has picked these up, so if you want to take
> them through your tree, that would be great.

Actually I take that back, looks like Ralf just picked them up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 0/3] Pistachio USB2.0 PHY

[Andrew Bresticker]

On Tue, Jun 2, 2015 at 11:07 PM, Kishon Vijay Abraham I  wrote:
>
>
> On Monday 11 May 2015 08:15 PM, Kishon Vijay Abraham I wrote:
>>
>>
>>
>> On Tuesday 05 May 2015 11:43 PM, Ezequiel Garcia wrote:
>>>
>>> Hi Kishon,
>>>

 This series adds support for the USB2.0 PHY present on the IMG Pistachio
 SoC.

 Based on mips-for-linux-next and tested on the IMG Pistachio BuB.  If
 possible,
 I'd like this to go through the MIPS tree with Kishon's ACK.

>>>
>>> Tested-by: Ezequiel Garcia 
>>>
>>> Can we have your Ack for this series so Ralf can pick it?
>>
>>
>> sure..
>>
>> Acked-by: Kishon Vijay Abraham I 
>
>
> I'm not sure if this has been merged yet. But this will cause conflicts with
> other PHY patches in Makefile and Kconfig when linus merges to his tree. I'd
> prefer the phy patches go in PHY tree itself.

It doesn't look like Ralf has picked these up, so if you want to take
them through your tree, that would be great.

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

Re: [PATCH V2 0/3] Pistachio USB2.0 PHY

[Andrew Bresticker]

On Wed, Jun 3, 2015 at 8:44 AM, Andrew Bresticker abres...@chromium.org wrote:
 On Tue, Jun 2, 2015 at 11:07 PM, Kishon Vijay Abraham I kis...@ti.com wrote:


 On Monday 11 May 2015 08:15 PM, Kishon Vijay Abraham I wrote:



 On Tuesday 05 May 2015 11:43 PM, Ezequiel Garcia wrote:

 Hi Kishon,


 This series adds support for the USB2.0 PHY present on the IMG Pistachio
 SoC.

 Based on mips-for-linux-next and tested on the IMG Pistachio BuB.  If
 possible,
 I'd like this to go through the MIPS tree with Kishon's ACK.


 Tested-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

 Can we have your Ack for this series so Ralf can pick it?


 sure..

 Acked-by: Kishon Vijay Abraham I kis...@ti.com


 I'm not sure if this has been merged yet. But this will cause conflicts with
 other PHY patches in Makefile and Kconfig when linus merges to his tree. I'd
 prefer the phy patches go in PHY tree itself.

 It doesn't look like Ralf has picked these up, so if you want to take
 them through your tree, that would be great.

Actually I take that back, looks like Ralf just picked them up.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 0/3] Pistachio USB2.0 PHY

[Andrew Bresticker]

On Tue, Jun 2, 2015 at 11:07 PM, Kishon Vijay Abraham I kis...@ti.com wrote:


 On Monday 11 May 2015 08:15 PM, Kishon Vijay Abraham I wrote:



 On Tuesday 05 May 2015 11:43 PM, Ezequiel Garcia wrote:

 Hi Kishon,


 This series adds support for the USB2.0 PHY present on the IMG Pistachio
 SoC.

 Based on mips-for-linux-next and tested on the IMG Pistachio BuB.  If
 possible,
 I'd like this to go through the MIPS tree with Kishon's ACK.


 Tested-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

 Can we have your Ack for this series so Ralf can pick it?


 sure..

 Acked-by: Kishon Vijay Abraham I kis...@ti.com


 I'm not sure if this has been merged yet. But this will cause conflicts with
 other PHY patches in Makefile and Kconfig when linus merges to his tree. I'd
 prefer the phy patches go in PHY tree itself.

It doesn't look like Ralf has picked these up, so if you want to take
them through your tree, that would be great.

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

Re: [PATCH 1/5] usb: xhci: cleanup xhci_hcd allocation

[Andrew Bresticker]

Hi Mathias,

On Mon, May 25, 2015 at 8:05 AM, Mathias Nyman
 wrote:
>
> I've been testing add/remove HCD extensively and didn't observe any 
> issues after applying
> these 5 patches. Well there is one issue that comes up but it has nothing 
> to do with xhci
> not being allocated. It has more to do with command being queued after 
> the HCD has gone away
> and so getting stuck forever without timing out.

 I went through the codepaths and you're right, should work fine. My 
 concern wasn't valid.
 This patchset doesn't even touch the order how primary and shared HCDs are 
 created and added
 in the PCI case, only for the platform device case.

 I'll try it out and send forward once rc1 is out.
>>>
>>> did you get a chance to try this series?
>>>
>>
>> Sorry, not yet, got delayed by other internal tasks.
>> I'll try it out as soon as possible.
>>
>>
>
> Ok, back to this, I'd like to get both this series and Andrew's xhci-tegra
> support to 4.2
>
> I did similar changes to xhci-tegra.c as Roger did to xhci-pci.c and 
> xhci-plat.c,
> but I can't test them and would need both your eyes on this to make sure it 
> looks ok.
>
> Both series are in a tegra_otg_merge topic branch in:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git tegra_otg_merge
>
> It contains Andrews full xhci tegra support series, but If I understood 
> correctly only
> patch 9/9 (maybe 8/9 as well?) will actually go through the xhci tree.
> Patch 1/9 is not needed with Roger's changes anymre
>
> The changes are in the last patch, here:
> https://git.kernel.org/cgit/linux/kernel/git/mnyman/xhci.git/commit/?h=tegra_otg_merge
>
> and would be squashed together with patch 9/9.

No need to apply patch 8/9 or 9/9... Lee Jones has NAK'ed the MFD
driver on which the xhci-tegra driver depends, so I'll need to re-spin
the series.  It would be great if you could ACK those two patches
though so that the entire series could go through the Tegra tree for
4.3.

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

Re: [PATCH v8 0/9] Tegra xHCI support

[Andrew Bresticker]

Hi Jassi,

On Mon, May 11, 2015 at 8:56 PM, Jassi Brar  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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] usb: xhci: cleanup xhci_hcd allocation

[Andrew Bresticker]

Hi Mathias,

On Mon, May 25, 2015 at 8:05 AM, Mathias Nyman
mathias.ny...@linux.intel.com wrote:

 I've been testing add/remove HCD extensively and didn't observe any 
 issues after applying
 these 5 patches. Well there is one issue that comes up but it has nothing 
 to do with xhci
 not being allocated. It has more to do with command being queued after 
 the HCD has gone away
 and so getting stuck forever without timing out.

 I went through the codepaths and you're right, should work fine. My 
 concern wasn't valid.
 This patchset doesn't even touch the order how primary and shared HCDs are 
 created and added
 in the PCI case, only for the platform device case.

 I'll try it out and send forward once rc1 is out.

 did you get a chance to try this series?


 Sorry, not yet, got delayed by other internal tasks.
 I'll try it out as soon as possible.



 Ok, back to this, I'd like to get both this series and Andrew's xhci-tegra
 support to 4.2

 I did similar changes to xhci-tegra.c as Roger did to xhci-pci.c and 
 xhci-plat.c,
 but I can't test them and would need both your eyes on this to make sure it 
 looks ok.

 Both series are in a tegra_otg_merge topic branch in:

 git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git tegra_otg_merge

 It contains Andrews full xhci tegra support series, but If I understood 
 correctly only
 patch 9/9 (maybe 8/9 as well?) will actually go through the xhci tree.
 Patch 1/9 is not needed with Roger's changes anymre

 The changes are in the last patch, here:
 https://git.kernel.org/cgit/linux/kernel/git/mnyman/xhci.git/commit/?h=tegra_otg_merge

 and would be squashed together with patch 9/9.

No need to apply patch 8/9 or 9/9... Lee Jones has NAK'ed the MFD
driver on which the xhci-tegra driver depends, so I'll need to re-spin
the series.  It would be great if you could ACK those two patches
though so that the entire series could go through the Tegra tree for
4.3.

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

Re: [PATCH v8 0/9] Tegra xHCI support

[Andrew Bresticker]

Hi Jassi,

On Mon, May 11, 2015 at 8:56 PM, Jassi Brar jassisinghb...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/9] clk: pistachio: Propagate rate changes in the MIPS PLL clock sub-tree

[Andrew Bresticker]

On Fri, May 22, 2015 at 10:52 AM, Ezequiel Garcia
 wrote:
>
>
> On 05/22/2015 02:42 PM, Andrew Bresticker wrote:
>> On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
>>  wrote:
>>> This commit passes CLK_SET_RATE_PARENT to the "mips_div",
>>> "mips_internal_div", and "mips_pll_mux" clocks. This flag is needed for the
>>> "mips" clock to propagate rate changes up to the "mips_pll" root clock.
>>>
>>> Signed-off-by: Govindraj Raja 
>>> Signed-off-by: Ezequiel Garcia 
>>
>> IIRC the clk core will prefer changing a downstream divider over
>> propagating the rate change up another level.  So, for example, if
>> MIPS_PLL is initially 400Mhz and we request a MIPS rate of 200Mhz,
>> we'll change the first intermediate divider to /2 rather than
>> propagate the rate change up to MIPS_PLL.  Wouldn't it be more
>> power-efficient to set the MIPS_PLL directly to the requested rate
>> rather than using external dividers to divide it down?
>>
>
> Indeed.
>
> Do you think we still want to be able to change the MIPS clk rate and
> propagate the change up to the PLL? Otherwise, I'll drop this patch and
> I'll drop the DIV_F and MUX_F macro patches.

Well I do think we want to propagate changes from MIPS up to MIPS_PLL,
but we need to work around the behavior of CLK_SET_RATE_PARENT when
applied to divider clocks.  Since there's no reason to ever set the
dividers between MIPS and MIPS_PLL to something besides /1
(James/Govindraj/Damien, correct me if I'm wrong here), then I think
we could just set CLK_DIVIDER_READ_ONLY on those dividers.  It's a bit
of a hack, but it's certainly simpler than writing a separate CPU
clock driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9] clk: pistachio: Correct critical clock list

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
 wrote:
> From: Damien Horsley 
>
> Correct the critical clock list. The current one is wrong, and may
> fail under some circumstances.
>
> Signed-off-by: Damien Horsley 
> Signed-off-by: Ezequiel Garcia 

The commit message could be more descriptive, e.g. explaining which
additional clocks must be enabled at all times and why, especially
since forcing on clocks form the clock driver is very much frowned
upon unless absolutely necessary.  Otherwise,

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

Re: [PATCH 8/9] clk: pistachio: Add sanity checks on PLL configuration

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
 wrote:
> From: Kevin Cernekee 
>
> When setting the PLL rates, check that:
>
>  - VCO is within range
>  - PFD is within range
>  - PLL is disabled when postdiv is changed
>  - postdiv2 <= postdiv1
>
> Signed-off-by: Kevin Cernekee 
> Signed-off-by: Ezequiel Garcia 

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

Re: [PATCH 7/9] clk: pistachio: Add a rate table for the MIPS PLL

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
 wrote:
> This commit adds a rate parameter table, which makes it possible for
> the MIPS PLL to support rate change.
>
> Signed-off-by: Govindraj Raja 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/clk/pistachio/clk-pistachio.c | 12 +++-
>  drivers/clk/pistachio/clk.h   | 12 
>  2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/pistachio/clk-pistachio.c 
> b/drivers/clk/pistachio/clk-pistachio.c
> index 22a7ebd..0ac7429 100644
> --- a/drivers/clk/pistachio/clk-pistachio.c
> +++ b/drivers/clk/pistachio/clk-pistachio.c
> @@ -145,8 +145,18 @@ static struct pistachio_mux pistachio_muxes[] __initdata 
> = {
> MUX(CLK_BT_PLL_MUX, "bt_pll_mux", mux_xtal_bt, 0x200, 17),
>  };
>
> +static struct pistachio_pll_rate_table mips_pll_rates[] = {
> +   MIPS_PLL_RATES(5200, 41600, 1, 16, 2, 1),
> +   MIPS_PLL_RATES(5200, 44200, 1, 17, 2, 1),
> +   MIPS_PLL_RATES(5200, 46800, 1, 18, 2, 1),
> +   MIPS_PLL_RATES(5200, 49400, 1, 19, 2, 1),
> +   MIPS_PLL_RATES(5200, 52000, 1, 20, 2, 1),
> +   MIPS_PLL_RATES(5200, 54600, 1, 21, 2, 1),
> +};
> +
>  static struct pistachio_pll pistachio_plls[] __initdata = {
> -   PLL_FIXED(CLK_MIPS_PLL, "mips_pll", "xtal", PLL_GF40LP_LAINT, 0x0),
> +   PLL(CLK_MIPS_PLL, "mips_pll", "xtal", PLL_GF40LP_LAINT, 0x0,
> +   mips_pll_rates),
> PLL_FIXED(CLK_AUDIO_PLL, "audio_pll", "audio_refclk_mux",
>   PLL_GF40LP_FRAC, 0xc),
> PLL_FIXED(CLK_RPU_V_PLL, "rpu_v_pll", "xtal", PLL_GF40LP_LAINT, 0x20),
> diff --git a/drivers/clk/pistachio/clk.h b/drivers/clk/pistachio/clk.h
> index 3bb6bbe..b5d22d6 100644
> --- a/drivers/clk/pistachio/clk.h
> +++ b/drivers/clk/pistachio/clk.h
> @@ -121,6 +121,18 @@ struct pistachio_pll_rate_table {
> unsigned int frac;
>  };
>
> +#define MIPS_PLL_RATES(_fref, _fout, _refdiv, _fbdiv,  \
> +  _postdiv1, _postdiv2)\
> +{   \
> +   .fref   = _fref,\
> +   .fout   = _fout,\
> +   .refdiv = _refdiv,  \
> +   .fbdiv  = _fbdiv,   \
> +   .postdiv1   = _postdiv1,\
> +   .postdiv2   = _postdiv2,\
> +   .frac   = 0,\
> +}

Wouldn't this be applicable to any integer PLL, not just MIPS_PLL?
Also, maybe we should just populate fout_{min,max} here, setting them
to _fout?  See my comment in patch 3/9.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/9] clk: pistachio: Propagate rate changes in the MIPS PLL clock sub-tree

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
 wrote:
> This commit passes CLK_SET_RATE_PARENT to the "mips_div",
> "mips_internal_div", and "mips_pll_mux" clocks. This flag is needed for the
> "mips" clock to propagate rate changes up to the "mips_pll" root clock.
>
> Signed-off-by: Govindraj Raja 
> Signed-off-by: Ezequiel Garcia 

IIRC the clk core will prefer changing a downstream divider over
propagating the rate change up another level.  So, for example, if
MIPS_PLL is initially 400Mhz and we request a MIPS rate of 200Mhz,
we'll change the first intermediate divider to /2 rather than
propagate the rate change up to MIPS_PLL.  Wouldn't it be more
power-efficient to set the MIPS_PLL directly to the requested rate
rather than using external dividers to divide it down?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/9] clk: pistachio: Add a MUX_F macro to pass clk_flags

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
 wrote:
> As preparation work to support MIPS PLL rate change propagation, this
> commit adds a MUX_F macro to pass clk_flags.
>
> Signed-off-by: Govindraj Raja 
> Signed-off-by: Ezequiel Garcia 

> --- a/drivers/clk/pistachio/clk.h
> +++ b/drivers/clk/pistachio/clk.h

> @@ -44,11 +45,22 @@ struct pistachio_mux {
> .id = _id,  \
> .reg= _reg, \
> .shift  = _shift,   \
> +   .clk_flags  = CLK_SET_RATE_NO_REPARENT, \
> .name   = _name,\
> .parents= _pnames,  \
> .num_parents= ARRAY_SIZE(_pnames)   \
> }
>
> +#define MUX_F(_id, _name, _pnames, _reg, _shift, _clkf)\
> +{   \
> +   .id = _id,  \
> +   .reg= _reg, \
> +   .shift  = _shift,   \
> +   .name   = _name,\
> +   .parents= _pnames,  \
> +   .num_parents= ARRAY_SIZE(_pnames),  \
> +   .clk_flags  = _clkf,\
> +}

nit: the indentation here is inconsistent with the other macros in this file.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/9] clk: pistachio: Extend DIV_F to pass clk_flags as well

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
 wrote:
> As preparation work to support MIPS PLL rate change propagation, this
> commit extends the DIV_F macro to pass clk_flags in addition to div_flags.
>
> Signed-off-by: Govindraj Raja 
> Signed-off-by: Ezequiel Garcia 

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

Re: [PATCH 3/9] clk: pistachio: Implement PLL rate adjustment

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
 wrote:
> This commit implements small rate changes to the fractional PLL.
> This is done using the PLL frac parameter. The .set_rate function
> first finds the parameters associated to the closest nominal rate.
>
> Then the new rate is set, using parameters from the table entry,
> except for the frac parameter, which is calculated from the rate
> using the fractional PLL rate formula.
>
> Using .round_rate, the driver guarantees that only rates near
> a table nominal rate is applied. To this extent, add two parameters
> fout_min and fout_max, which allows to define the allowed rate
> adjustment.
>
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/clk/pistachio/clk-pll.c | 48 
> +++--
>  drivers/clk/pistachio/clk.h |  2 ++
>  2 files changed, 39 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/pistachio/clk-pll.c b/drivers/clk/pistachio/clk-pll.c
> index f12d520..cf000bb 100644
> --- a/drivers/clk/pistachio/clk-pll.c
> +++ b/drivers/clk/pistachio/clk-pll.c
> @@ -90,29 +90,50 @@ static struct pistachio_pll_rate_table *
>  pll_get_params(struct pistachio_clk_pll *pll, unsigned long fref,
>unsigned long fout)
>  {
> -   unsigned int i;
> +   unsigned int i, best;
> +   unsigned long err, best_err = ~0;
>
> for (i = 0; i < pll->nr_rates; i++) {
> -   if (pll->rates[i].fref == fref && pll->rates[i].fout == fout)
> -   return >rates[i];
> +   err = abs(pll->rates[i].fout - fout);
> +   if (pll->rates[i].fref == fref && err < best_err) {
> +   best = i;
> +   best_err = err;
> +   }
> }
>
> -   return NULL;
> +   return >rates[best];
>  }
>
>  static long pll_round_rate(struct clk_hw *hw, unsigned long rate,
>unsigned long *parent_rate)
>  {
> struct pistachio_clk_pll *pll = to_pistachio_pll(hw);
> -   unsigned int i;
> +   unsigned int i, best;
> +   unsigned long err, best_err = ~0;
>
> for (i = 0; i < pll->nr_rates; i++) {
> -   if (i > 0 && pll->rates[i].fref == *parent_rate &&
> -   pll->rates[i].fout <= rate)
> -   return pll->rates[i - 1].fout;
> +   err = abs(pll->rates[i].fout - rate);
> +   if (pll->rates[i].fref == *parent_rate && err < best_err) {
> +   best = i;
> +   best_err = err;
> +   }
> }
>
> -   return pll->rates[0].fout;
> +   /* Make sure fout_{min,max} parameters have sane values */
> +   if (!pll->rates[best].fout_min)
> +   pll->rates[best].fout_min = pll->rates[best].fout;
> +   if (!pll->rates[best].fout_max)
> +   pll->rates[best].fout_max = pll->rates[best].fout;

Perhaps the rate tables should just always populate fout_min and fout_max?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/7] clocksource: mips-gic: Split clocksource and clockevent initialization

[Andrew Bresticker]

On Thu, May 21, 2015 at 3:25 PM, Ezequiel Garcia
 wrote:
>
>
> On 05/21/2015 07:24 PM, Andrew Bresticker wrote:
>> On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
>>  wrote:
>>> This is preparation work for the introduction of clockevent frequency
>>> update with a clock notifier. This is only possible when the device
>>> is passed a clk struct, so let's split the legacy and devicetree
>>> initialization.
>>>
>>> Signed-off-by: Ezequiel Garcia 
>>> ---
>>>  drivers/clocksource/mips-gic-timer.c | 13 -
>>>  1 file changed, 8 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/clocksource/mips-gic-timer.c 
>>> b/drivers/clocksource/mips-gic-timer.c
>>> index c4352f0..22a4daf 100644
>>> --- a/drivers/clocksource/mips-gic-timer.c
>>> +++ b/drivers/clocksource/mips-gic-timer.c
>>> @@ -142,11 +142,6 @@ static void __init __gic_clocksource_init(void)
>>> ret = clocksource_register_hz(_clocksource, gic_frequency);
>>> if (ret < 0)
>>> pr_warn("GIC: Unable to register clocksource\n");
>>> -
>>> -   gic_clockevent_init();
>>> -
>>> -   /* And finally start the counter */
>>> -   gic_start_count();
>>>  }
>>
>> Instead of duplicating this bit in both the OF and non-OF paths, maybe
>> it would be better to do the notifier registration in
>> gic_clockevent_init(), either by passing around the struct clk or
>> making it a global?
>>
>
> Yeah, I had something like that first, but somehow it looked ugly to have:
>
>   gic_clockevent_init(IS_ERR(clk) ? NULL : clk);
>
> Don't have a strong opinion though.

Ah that is a bit ugly.  I'm fine either way though, so:

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

Re: [PATCH 7/7] mips: pistachio: Allow to enable the external timer based clocksource

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:43 PM, Ezequiel Garcia
 wrote:
> This commit introduces a new config, so the user can choose to enable
> the General Purpose Timer based clocksource. This option is required
> to have CPUFreq support.
>
> Signed-off-by: Ezequiel Garcia 
> ---
>  arch/mips/Kconfig   |  1 +
>  arch/mips/pistachio/Kconfig | 13 +
>  2 files changed, 14 insertions(+)
>  create mode 100644 arch/mips/pistachio/Kconfig
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index f501665..91f6ca0 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -934,6 +934,7 @@ source "arch/mips/jazz/Kconfig"
>  source "arch/mips/jz4740/Kconfig"
>  source "arch/mips/lantiq/Kconfig"
>  source "arch/mips/lasat/Kconfig"
> +source "arch/mips/pistachio/Kconfig"
>  source "arch/mips/pmcs-msp71xx/Kconfig"
>  source "arch/mips/ralink/Kconfig"
>  source "arch/mips/sgi-ip27/Kconfig"
> diff --git a/arch/mips/pistachio/Kconfig b/arch/mips/pistachio/Kconfig
> new file mode 100644
> index 000..97731ea
> --- /dev/null
> +++ b/arch/mips/pistachio/Kconfig
> @@ -0,0 +1,13 @@
> +config PISTACHIO_GPTIMER_CLKSRC
> +   bool "Enable General Purpose Timer based clocksource"
> +   depends on MACH_PISTACHIO
> +   select CLKSRC_PISTACHIO
> +   select MIPS_EXTERNAL_TIMER

Why not just select these in the MACH_PISTACHIO Kconfig entry?  Is
there any harm in always having the Pistachio GPT enabled?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/7] clocksource: Add Pistachio clocksource-only driver

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:41 PM, Ezequiel Garcia
 wrote:
> The Pistachio SoC provides four general purpose timers, and allow
> to implement a clocksource driver.
>
> This driver can be used as a replacement for the MIPS GIC and MIPS R4K
> clocksources and sched clocks, which are clocked from the CPU clock.
>
> Given the general purpose timers are clocked from an independent clock,
> this new clocksource driver will be useful to introduce CPUFreq support
> for Pistachio machines.
>
> Signed-off-by: Govindraj Raja 
> Signed-off-by: Ezequiel Garcia 

> --- /dev/null
> +++ b/drivers/clocksource/time-pistachio.c

> @@ -0,0 +1,202 @@
> +/*
> + * Pistachio clocksource based on general-purpose timers
> + *
> + * Copyright (C) 2015 Imagination Technologies
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License. See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#define pr_fmt(fmt) "%s: " fmt, __func__
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Top level reg */
> +#defineCR_TIMER_CTRL_CFG   0x00
> +  #define TIMER_ME_GLOBAL  BIT(0)
> +#defineCR_TIMER_REV0x10
> +
> +/* Timer specific registers */
> +#define TIMER_CFG  0x20
> +  #define TIMER_ME_LOCAL   BIT(0)
> +#define TIMER_RELOAD_VALUE 0x24
> +#define TIMER_CURRENT_VALUE0x28
> +#define TIMER_CURRENT_OVERFLOW_VALUE   0x2C
> +#define TIMER_IRQ_STATUS   0x30
> +#define TIMER_IRQ_CLEAR0x34
> +#define TIMER_IRQ_MASK 0x38

nit: the spacing in these two sets of #defines is inconsistent and the
space at the beginning of the line looks a little weird to me, maybe
just do something like this:

#define REGISTER ...
#define  REGISTER_FIELD ...

> +
> +#define PERIP_TIMER_CONTROL0x90
> +
> +/* Timer specific configuration Values */
> +#define RELOAD_VALUE   0x
> +
> +static void __iomem *timer_base;
> +static DEFINE_RAW_SPINLOCK(lock);
> +
> +static inline u32 gpt_readl(u32 offset, u32 gpt_id)
> +{
> +   return __raw_readl(timer_base + 0x20 * gpt_id + offset);
> +}
> +
> +static inline void gpt_writel(u32 value, u32 offset, u32 gpt_id)
> +{
> +   __raw_writel(value, timer_base + 0x20 * gpt_id + offset);
> +}

Why raw iomem accessors?

> +static cycle_t clocksource_read_cycles(struct clocksource *cs)
> +{
> +   u32 counter, overflw;
> +   unsigned long flags;
> +
> +   raw_spin_lock_irqsave(, flags);
> +   overflw = gpt_readl(TIMER_CURRENT_OVERFLOW_VALUE, 0);
> +   counter = gpt_readl(TIMER_CURRENT_VALUE, 0);
> +   raw_spin_unlock_irqrestore(, flags);
> +
> +   return ~(cycle_t)counter;
> +}
> +
> +static u64 notrace pistachio_read_sched_clock(void)
> +{
> +   return clocksource_read_cycles(NULL);
> +}
> +
> +static void pistachio_clksrc_enable(int timeridx)
> +{
> +   u32 val;
> +
> +   /* Disable GPT local before loading reload value */
> +   val = gpt_readl(TIMER_CFG, timeridx);
> +   val &= ~TIMER_ME_LOCAL;
> +   gpt_writel(val, TIMER_CFG, timeridx);
> +
> +   gpt_writel(RELOAD_VALUE, TIMER_RELOAD_VALUE, timeridx);
> +
> +   val = gpt_readl(TIMER_CFG, timeridx);
> +   val |= TIMER_ME_LOCAL;
> +   gpt_writel(val, TIMER_CFG, timeridx);
> +}
> +
> +static void pistachio_clksrc_disable(int timeridx)
> +{
> +   u32 val;
> +
> +   /* Disable GPT local */
> +   val = gpt_readl(TIMER_CFG, timeridx);
> +   val &= ~TIMER_ME_LOCAL;
> +   gpt_writel(val, TIMER_CFG, timeridx);
> +}
> +
> +static int clocksource_enable(struct clocksource *cs)
> +{
> +   pistachio_clksrc_enable(0);
> +   return 0;
> +}
> +
> +static void clocksource_disable(struct clocksource *cs)
> +{
> +   pistachio_clksrc_disable(0);
> +}
> +
> +/* Desirable clock source for pistachio platform */
> +static struct clocksource clocksource_gpt = {
> +   .name   = "gptimer",
> +   .rating = 300,
> +   .enable = clocksource_enable,
> +   .disable= clocksource_disable,
> +   .read   = clocksource_read_cycles,

nit: these names are rather generic sounding, maybe add a "pistachio" prefix?

> +   .mask   = CLOCKSOURCE_MASK(32),
> +   .flags  = CLOCK_SOURCE_IS_CONTINUOUS |
> + CLOCK_SOURCE_SUSPEND_NONSTOP,
> +};
> +
> +static void __init pistachio_clksrc_of_init(struct device_node *node)
> +{
> +   struct clk *sys_clk, *fast_clk;
> +   struct regmap *periph_regs;
> +   unsigned long rate;
> +   int ret;
> +
> +   timer_base = of_iomap(node, 0);
> +   if (!timer_base) {
> +   pr_err("cannot iomap\n");
> +   return;
> +   }
> +
> +   /*

Re: [PATCH 6/7] clocksource: Add Pistachio clocksource-only driver

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:41 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 The Pistachio SoC provides four general purpose timers, and allow
 to implement a clocksource driver.

 This driver can be used as a replacement for the MIPS GIC and MIPS R4K
 clocksources and sched clocks, which are clocked from the CPU clock.

 Given the general purpose timers are clocked from an independent clock,
 this new clocksource driver will be useful to introduce CPUFreq support
 for Pistachio machines.

 Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

 --- /dev/null
 +++ b/drivers/clocksource/time-pistachio.c

 @@ -0,0 +1,202 @@
 +/*
 + * Pistachio clocksource based on general-purpose timers
 + *
 + * Copyright (C) 2015 Imagination Technologies
 + *
 + * This file is subject to the terms and conditions of the GNU General Public
 + * License. See the file COPYING in the main directory of this archive
 + * for more details.
 + */
 +
 +#define pr_fmt(fmt) %s:  fmt, __func__
 +
 +#include linux/clk.h
 +#include linux/clocksource.h
 +#include linux/clockchips.h
 +#include linux/delay.h
 +#include linux/err.h
 +#include linux/init.h
 +#include linux/spinlock.h
 +#include linux/mfd/syscon.h
 +#include linux/of.h
 +#include linux/of_address.h
 +#include linux/platform_device.h
 +#include linux/regmap.h
 +#include linux/sched_clock.h
 +#include linux/time.h
 +
 +/* Top level reg */
 +#defineCR_TIMER_CTRL_CFG   0x00
 +  #define TIMER_ME_GLOBAL  BIT(0)
 +#defineCR_TIMER_REV0x10
 +
 +/* Timer specific registers */
 +#define TIMER_CFG  0x20
 +  #define TIMER_ME_LOCAL   BIT(0)
 +#define TIMER_RELOAD_VALUE 0x24
 +#define TIMER_CURRENT_VALUE0x28
 +#define TIMER_CURRENT_OVERFLOW_VALUE   0x2C
 +#define TIMER_IRQ_STATUS   0x30
 +#define TIMER_IRQ_CLEAR0x34
 +#define TIMER_IRQ_MASK 0x38

nit: the spacing in these two sets of #defines is inconsistent and the
space at the beginning of the line looks a little weird to me, maybe
just do something like this:

#define REGISTER ...
#define  REGISTER_FIELD ...

 +
 +#define PERIP_TIMER_CONTROL0x90
 +
 +/* Timer specific configuration Values */
 +#define RELOAD_VALUE   0x
 +
 +static void __iomem *timer_base;
 +static DEFINE_RAW_SPINLOCK(lock);
 +
 +static inline u32 gpt_readl(u32 offset, u32 gpt_id)
 +{
 +   return __raw_readl(timer_base + 0x20 * gpt_id + offset);
 +}
 +
 +static inline void gpt_writel(u32 value, u32 offset, u32 gpt_id)
 +{
 +   __raw_writel(value, timer_base + 0x20 * gpt_id + offset);
 +}

Why raw iomem accessors?

 +static cycle_t clocksource_read_cycles(struct clocksource *cs)
 +{
 +   u32 counter, overflw;
 +   unsigned long flags;
 +
 +   raw_spin_lock_irqsave(lock, flags);
 +   overflw = gpt_readl(TIMER_CURRENT_OVERFLOW_VALUE, 0);
 +   counter = gpt_readl(TIMER_CURRENT_VALUE, 0);
 +   raw_spin_unlock_irqrestore(lock, flags);
 +
 +   return ~(cycle_t)counter;
 +}
 +
 +static u64 notrace pistachio_read_sched_clock(void)
 +{
 +   return clocksource_read_cycles(NULL);
 +}
 +
 +static void pistachio_clksrc_enable(int timeridx)
 +{
 +   u32 val;
 +
 +   /* Disable GPT local before loading reload value */
 +   val = gpt_readl(TIMER_CFG, timeridx);
 +   val = ~TIMER_ME_LOCAL;
 +   gpt_writel(val, TIMER_CFG, timeridx);
 +
 +   gpt_writel(RELOAD_VALUE, TIMER_RELOAD_VALUE, timeridx);
 +
 +   val = gpt_readl(TIMER_CFG, timeridx);
 +   val |= TIMER_ME_LOCAL;
 +   gpt_writel(val, TIMER_CFG, timeridx);
 +}
 +
 +static void pistachio_clksrc_disable(int timeridx)
 +{
 +   u32 val;
 +
 +   /* Disable GPT local */
 +   val = gpt_readl(TIMER_CFG, timeridx);
 +   val = ~TIMER_ME_LOCAL;
 +   gpt_writel(val, TIMER_CFG, timeridx);
 +}
 +
 +static int clocksource_enable(struct clocksource *cs)
 +{
 +   pistachio_clksrc_enable(0);
 +   return 0;
 +}
 +
 +static void clocksource_disable(struct clocksource *cs)
 +{
 +   pistachio_clksrc_disable(0);
 +}
 +
 +/* Desirable clock source for pistachio platform */
 +static struct clocksource clocksource_gpt = {
 +   .name   = gptimer,
 +   .rating = 300,
 +   .enable = clocksource_enable,
 +   .disable= clocksource_disable,
 +   .read   = clocksource_read_cycles,

nit: these names are rather generic sounding, maybe add a pistachio prefix?

 +   .mask   = CLOCKSOURCE_MASK(32),
 +   .flags  = CLOCK_SOURCE_IS_CONTINUOUS |
 + CLOCK_SOURCE_SUSPEND_NONSTOP,
 +};
 +
 +static void __init pistachio_clksrc_of_init(struct device_node *node)
 +{
 +   struct clk *sys_clk, *fast_clk;
 +   struct regmap *periph_regs;
 +   unsigned long rate;
 +   int ret;
 +
 +   timer_base = 

Re: [PATCH 7/7] mips: pistachio: Allow to enable the external timer based clocksource

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:43 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 This commit introduces a new config, so the user can choose to enable
 the General Purpose Timer based clocksource. This option is required
 to have CPUFreq support.

 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com
 ---
  arch/mips/Kconfig   |  1 +
  arch/mips/pistachio/Kconfig | 13 +
  2 files changed, 14 insertions(+)
  create mode 100644 arch/mips/pistachio/Kconfig

 diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
 index f501665..91f6ca0 100644
 --- a/arch/mips/Kconfig
 +++ b/arch/mips/Kconfig
 @@ -934,6 +934,7 @@ source arch/mips/jazz/Kconfig
  source arch/mips/jz4740/Kconfig
  source arch/mips/lantiq/Kconfig
  source arch/mips/lasat/Kconfig
 +source arch/mips/pistachio/Kconfig
  source arch/mips/pmcs-msp71xx/Kconfig
  source arch/mips/ralink/Kconfig
  source arch/mips/sgi-ip27/Kconfig
 diff --git a/arch/mips/pistachio/Kconfig b/arch/mips/pistachio/Kconfig
 new file mode 100644
 index 000..97731ea
 --- /dev/null
 +++ b/arch/mips/pistachio/Kconfig
 @@ -0,0 +1,13 @@
 +config PISTACHIO_GPTIMER_CLKSRC
 +   bool Enable General Purpose Timer based clocksource
 +   depends on MACH_PISTACHIO
 +   select CLKSRC_PISTACHIO
 +   select MIPS_EXTERNAL_TIMER

Why not just select these in the MACH_PISTACHIO Kconfig entry?  Is
there any harm in always having the Pistachio GPT enabled?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/7] clocksource: mips-gic: Split clocksource and clockevent initialization

[Andrew Bresticker]

On Thu, May 21, 2015 at 3:25 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:


 On 05/21/2015 07:24 PM, Andrew Bresticker wrote:
 On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
 ezequiel.gar...@imgtec.com wrote:
 This is preparation work for the introduction of clockevent frequency
 update with a clock notifier. This is only possible when the device
 is passed a clk struct, so let's split the legacy and devicetree
 initialization.

 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com
 ---
  drivers/clocksource/mips-gic-timer.c | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

 diff --git a/drivers/clocksource/mips-gic-timer.c 
 b/drivers/clocksource/mips-gic-timer.c
 index c4352f0..22a4daf 100644
 --- a/drivers/clocksource/mips-gic-timer.c
 +++ b/drivers/clocksource/mips-gic-timer.c
 @@ -142,11 +142,6 @@ static void __init __gic_clocksource_init(void)
 ret = clocksource_register_hz(gic_clocksource, gic_frequency);
 if (ret  0)
 pr_warn(GIC: Unable to register clocksource\n);
 -
 -   gic_clockevent_init();
 -
 -   /* And finally start the counter */
 -   gic_start_count();
  }

 Instead of duplicating this bit in both the OF and non-OF paths, maybe
 it would be better to do the notifier registration in
 gic_clockevent_init(), either by passing around the struct clk or
 making it a global?


 Yeah, I had something like that first, but somehow it looked ugly to have:

   gic_clockevent_init(IS_ERR(clk) ? NULL : clk);

 Don't have a strong opinion though.

Ah that is a bit ugly.  I'm fine either way though, so:

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

Re: [PATCH 3/9] clk: pistachio: Implement PLL rate adjustment

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 This commit implements small rate changes to the fractional PLL.
 This is done using the PLL frac parameter. The .set_rate function
 first finds the parameters associated to the closest nominal rate.

 Then the new rate is set, using parameters from the table entry,
 except for the frac parameter, which is calculated from the rate
 using the fractional PLL rate formula.

 Using .round_rate, the driver guarantees that only rates near
 a table nominal rate is applied. To this extent, add two parameters
 fout_min and fout_max, which allows to define the allowed rate
 adjustment.

 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com
 ---
  drivers/clk/pistachio/clk-pll.c | 48 
 +++--
  drivers/clk/pistachio/clk.h |  2 ++
  2 files changed, 39 insertions(+), 11 deletions(-)

 diff --git a/drivers/clk/pistachio/clk-pll.c b/drivers/clk/pistachio/clk-pll.c
 index f12d520..cf000bb 100644
 --- a/drivers/clk/pistachio/clk-pll.c
 +++ b/drivers/clk/pistachio/clk-pll.c
 @@ -90,29 +90,50 @@ static struct pistachio_pll_rate_table *
  pll_get_params(struct pistachio_clk_pll *pll, unsigned long fref,
unsigned long fout)
  {
 -   unsigned int i;
 +   unsigned int i, best;
 +   unsigned long err, best_err = ~0;

 for (i = 0; i  pll-nr_rates; i++) {
 -   if (pll-rates[i].fref == fref  pll-rates[i].fout == fout)
 -   return pll-rates[i];
 +   err = abs(pll-rates[i].fout - fout);
 +   if (pll-rates[i].fref == fref  err  best_err) {
 +   best = i;
 +   best_err = err;
 +   }
 }

 -   return NULL;
 +   return pll-rates[best];
  }

  static long pll_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate)
  {
 struct pistachio_clk_pll *pll = to_pistachio_pll(hw);
 -   unsigned int i;
 +   unsigned int i, best;
 +   unsigned long err, best_err = ~0;

 for (i = 0; i  pll-nr_rates; i++) {
 -   if (i  0  pll-rates[i].fref == *parent_rate 
 -   pll-rates[i].fout = rate)
 -   return pll-rates[i - 1].fout;
 +   err = abs(pll-rates[i].fout - rate);
 +   if (pll-rates[i].fref == *parent_rate  err  best_err) {
 +   best = i;
 +   best_err = err;
 +   }
 }

 -   return pll-rates[0].fout;
 +   /* Make sure fout_{min,max} parameters have sane values */
 +   if (!pll-rates[best].fout_min)
 +   pll-rates[best].fout_min = pll-rates[best].fout;
 +   if (!pll-rates[best].fout_max)
 +   pll-rates[best].fout_max = pll-rates[best].fout;

Perhaps the rate tables should just always populate fout_min and fout_max?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/9] clk: pistachio: Add a MUX_F macro to pass clk_flags

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 As preparation work to support MIPS PLL rate change propagation, this
 commit adds a MUX_F macro to pass clk_flags.

 Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

 --- a/drivers/clk/pistachio/clk.h
 +++ b/drivers/clk/pistachio/clk.h

 @@ -44,11 +45,22 @@ struct pistachio_mux {
 .id = _id,  \
 .reg= _reg, \
 .shift  = _shift,   \
 +   .clk_flags  = CLK_SET_RATE_NO_REPARENT, \
 .name   = _name,\
 .parents= _pnames,  \
 .num_parents= ARRAY_SIZE(_pnames)   \
 }

 +#define MUX_F(_id, _name, _pnames, _reg, _shift, _clkf)\
 +{   \
 +   .id = _id,  \
 +   .reg= _reg, \
 +   .shift  = _shift,   \
 +   .name   = _name,\
 +   .parents= _pnames,  \
 +   .num_parents= ARRAY_SIZE(_pnames),  \
 +   .clk_flags  = _clkf,\
 +}

nit: the indentation here is inconsistent with the other macros in this file.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/9] clk: pistachio: Propagate rate changes in the MIPS PLL clock sub-tree

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 This commit passes CLK_SET_RATE_PARENT to the mips_div,
 mips_internal_div, and mips_pll_mux clocks. This flag is needed for the
 mips clock to propagate rate changes up to the mips_pll root clock.

 Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

IIRC the clk core will prefer changing a downstream divider over
propagating the rate change up another level.  So, for example, if
MIPS_PLL is initially 400Mhz and we request a MIPS rate of 200Mhz,
we'll change the first intermediate divider to /2 rather than
propagate the rate change up to MIPS_PLL.  Wouldn't it be more
power-efficient to set the MIPS_PLL directly to the requested rate
rather than using external dividers to divide it down?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/9] clk: pistachio: Add a rate table for the MIPS PLL

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 This commit adds a rate parameter table, which makes it possible for
 the MIPS PLL to support rate change.

 Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com
 ---
  drivers/clk/pistachio/clk-pistachio.c | 12 +++-
  drivers/clk/pistachio/clk.h   | 12 
  2 files changed, 23 insertions(+), 1 deletion(-)

 diff --git a/drivers/clk/pistachio/clk-pistachio.c 
 b/drivers/clk/pistachio/clk-pistachio.c
 index 22a7ebd..0ac7429 100644
 --- a/drivers/clk/pistachio/clk-pistachio.c
 +++ b/drivers/clk/pistachio/clk-pistachio.c
 @@ -145,8 +145,18 @@ static struct pistachio_mux pistachio_muxes[] __initdata 
 = {
 MUX(CLK_BT_PLL_MUX, bt_pll_mux, mux_xtal_bt, 0x200, 17),
  };

 +static struct pistachio_pll_rate_table mips_pll_rates[] = {
 +   MIPS_PLL_RATES(5200, 41600, 1, 16, 2, 1),
 +   MIPS_PLL_RATES(5200, 44200, 1, 17, 2, 1),
 +   MIPS_PLL_RATES(5200, 46800, 1, 18, 2, 1),
 +   MIPS_PLL_RATES(5200, 49400, 1, 19, 2, 1),
 +   MIPS_PLL_RATES(5200, 52000, 1, 20, 2, 1),
 +   MIPS_PLL_RATES(5200, 54600, 1, 21, 2, 1),
 +};
 +
  static struct pistachio_pll pistachio_plls[] __initdata = {
 -   PLL_FIXED(CLK_MIPS_PLL, mips_pll, xtal, PLL_GF40LP_LAINT, 0x0),
 +   PLL(CLK_MIPS_PLL, mips_pll, xtal, PLL_GF40LP_LAINT, 0x0,
 +   mips_pll_rates),
 PLL_FIXED(CLK_AUDIO_PLL, audio_pll, audio_refclk_mux,
   PLL_GF40LP_FRAC, 0xc),
 PLL_FIXED(CLK_RPU_V_PLL, rpu_v_pll, xtal, PLL_GF40LP_LAINT, 0x20),
 diff --git a/drivers/clk/pistachio/clk.h b/drivers/clk/pistachio/clk.h
 index 3bb6bbe..b5d22d6 100644
 --- a/drivers/clk/pistachio/clk.h
 +++ b/drivers/clk/pistachio/clk.h
 @@ -121,6 +121,18 @@ struct pistachio_pll_rate_table {
 unsigned int frac;
  };

 +#define MIPS_PLL_RATES(_fref, _fout, _refdiv, _fbdiv,  \
 +  _postdiv1, _postdiv2)\
 +{   \
 +   .fref   = _fref,\
 +   .fout   = _fout,\
 +   .refdiv = _refdiv,  \
 +   .fbdiv  = _fbdiv,   \
 +   .postdiv1   = _postdiv1,\
 +   .postdiv2   = _postdiv2,\
 +   .frac   = 0,\
 +}

Wouldn't this be applicable to any integer PLL, not just MIPS_PLL?
Also, maybe we should just populate fout_{min,max} here, setting them
to _fout?  See my comment in patch 3/9.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/9] clk: pistachio: Propagate rate changes in the MIPS PLL clock sub-tree

[Andrew Bresticker]

On Fri, May 22, 2015 at 10:52 AM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:


 On 05/22/2015 02:42 PM, Andrew Bresticker wrote:
 On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
 ezequiel.gar...@imgtec.com wrote:
 This commit passes CLK_SET_RATE_PARENT to the mips_div,
 mips_internal_div, and mips_pll_mux clocks. This flag is needed for the
 mips clock to propagate rate changes up to the mips_pll root clock.

 Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

 IIRC the clk core will prefer changing a downstream divider over
 propagating the rate change up another level.  So, for example, if
 MIPS_PLL is initially 400Mhz and we request a MIPS rate of 200Mhz,
 we'll change the first intermediate divider to /2 rather than
 propagate the rate change up to MIPS_PLL.  Wouldn't it be more
 power-efficient to set the MIPS_PLL directly to the requested rate
 rather than using external dividers to divide it down?


 Indeed.

 Do you think we still want to be able to change the MIPS clk rate and
 propagate the change up to the PLL? Otherwise, I'll drop this patch and
 I'll drop the DIV_F and MUX_F macro patches.

Well I do think we want to propagate changes from MIPS up to MIPS_PLL,
but we need to work around the behavior of CLK_SET_RATE_PARENT when
applied to divider clocks.  Since there's no reason to ever set the
dividers between MIPS and MIPS_PLL to something besides /1
(James/Govindraj/Damien, correct me if I'm wrong here), then I think
we could just set CLK_DIVIDER_READ_ONLY on those dividers.  It's a bit
of a hack, but it's certainly simpler than writing a separate CPU
clock driver.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/9] clk: pistachio: Extend DIV_F to pass clk_flags as well

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 As preparation work to support MIPS PLL rate change propagation, this
 commit extends the DIV_F macro to pass clk_flags in addition to div_flags.

 Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

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

Re: [PATCH 8/9] clk: pistachio: Add sanity checks on PLL configuration

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 From: Kevin Cernekee cerne...@chromium.org

 When setting the PLL rates, check that:

  - VCO is within range
  - PFD is within range
  - PLL is disabled when postdiv is changed
  - postdiv2 = postdiv1

 Signed-off-by: Kevin Cernekee cerne...@chromium.org
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

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

Re: [PATCH 9/9] clk: pistachio: Correct critical clock list

[Andrew Bresticker]

On Thu, May 21, 2015 at 4:57 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 From: Damien Horsley damien.hors...@imgtec.com

 Correct the critical clock list. The current one is wrong, and may
 fail under some circumstances.

 Signed-off-by: Damien Horsley damien.hors...@imgtec.com
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

The commit message could be more descriptive, e.g. explaining which
additional clocks must be enabled at all times and why, especially
since forcing on clocks form the clock driver is very much frowned
upon unless absolutely necessary.  Otherwise,

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

Re: [PATCH 5/7] clocksource: Add Pistachio SoC general purpose timer binding document

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:41 PM, Ezequiel Garcia
 wrote:
> Add a device-tree binding document for the clocksource driver provided
> by Pistachio SoC general purpose timers.
>
> Signed-off-by: Ezequiel Garcia 

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

Re: [PATCH 4/7] clocksource: mips-gic: Update clockevent frequency on clock rate changes

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
 wrote:
> This commit introduces the clockevent frequency update, using
> a clock notifier. It will be used to support CPUFreq on platforms
> using MIPS GIC based clockevents.
>
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/clocksource/mips-gic-timer.c | 31 ++-
>  1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clocksource/mips-gic-timer.c 
> b/drivers/clocksource/mips-gic-timer.c
> index 22a4daf..71bbd42 100644
> --- a/drivers/clocksource/mips-gic-timer.c
> +++ b/drivers/clocksource/mips-gic-timer.c
> @@ -79,6 +79,13 @@ static void gic_clockevent_cpu_exit(struct 
> clock_event_device *cd)
> disable_percpu_irq(gic_timer_irq);
>  }
>
> +static void gic_update_frequency(void *data)
> +{
> +   unsigned long rate = (unsigned long)data;
> +
> +   clockevents_update_freq(this_cpu_ptr(_clockevent_device), rate);
> +}
> +
>  static int gic_cpu_notifier(struct notifier_block *nb, unsigned long action,
> void *data)
>  {
> @@ -94,10 +101,26 @@ static int gic_cpu_notifier(struct notifier_block *nb, 
> unsigned long action,
> return NOTIFY_OK;
>  }
>
> +static int gic_clk_notifier(struct notifier_block *nb, unsigned long action,
> +   void *data)
> +{
> +   struct clk_notifier_data *cnd = data;
> +
> +   if (action == POST_RATE_CHANGE)
> +   on_each_cpu(gic_update_frequency, (void *)cnd->new_rate, 1);
> +
> +   return NOTIFY_OK;
> +}
> +
> +
>  static struct notifier_block gic_cpu_nb = {
> .notifier_call = gic_cpu_notifier,
>  };
>
> +static struct notifier_block gic_clk_nb = {
> +   .notifier_call = gic_clk_notifier,
> +};
> +
>  static int gic_clockevent_init(void)
>  {
> int ret;
> @@ -160,6 +183,7 @@ void __init gic_clocksource_init(unsigned int frequency)
>  static void __init gic_clocksource_of_init(struct device_node *node)
>  {
> struct clk *clk;
> +   int ret;
>
> if (WARN_ON(!gic_present || !node->parent ||
> !of_device_is_compatible(node->parent, "mti,gic")))
> @@ -186,7 +210,12 @@ static void __init gic_clocksource_of_init(struct 
> device_node *node)
> }
>
> __gic_clocksource_init();
> -   gic_clockevent_init();
> +
> +   ret = gic_clockevent_init();
> +   if (ret < 0 && !IS_ERR(clk)) {

I think you mean ret == 0 here?

> +   if (clk_notifier_register(clk, _clk_nb) < 0)
> +   pr_warn("GIC: Unable to register clock notifier\n");
> +   }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/7] clocksource: mips-gic: Split clocksource and clockevent initialization

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
 wrote:
> This is preparation work for the introduction of clockevent frequency
> update with a clock notifier. This is only possible when the device
> is passed a clk struct, so let's split the legacy and devicetree
> initialization.
>
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/clocksource/mips-gic-timer.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clocksource/mips-gic-timer.c 
> b/drivers/clocksource/mips-gic-timer.c
> index c4352f0..22a4daf 100644
> --- a/drivers/clocksource/mips-gic-timer.c
> +++ b/drivers/clocksource/mips-gic-timer.c
> @@ -142,11 +142,6 @@ static void __init __gic_clocksource_init(void)
> ret = clocksource_register_hz(_clocksource, gic_frequency);
> if (ret < 0)
> pr_warn("GIC: Unable to register clocksource\n");
> -
> -   gic_clockevent_init();
> -
> -   /* And finally start the counter */
> -   gic_start_count();
>  }

Instead of duplicating this bit in both the OF and non-OF paths, maybe
it would be better to do the notifier registration in
gic_clockevent_init(), either by passing around the struct clk or
making it a global?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/7] clocksource: mips-gic: Add missing error returns checks

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
 wrote:
> This commit adds the required checks on the functions that return
> an error. Some of them are not critical, so only a warning is
> printed.
>
> Signed-off-by: Ezequiel Garcia 

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

Re: [PATCH 1/7] clocksource: mips-gic: Enable the clock before using it

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
 wrote:
> For the clock to be used (e.g. get its rate through clk_get_rate)
> it should be prepared and enabled first.
>
> Also, while the clock is enabled the driver must hold a reference to it,
> so let's remove the call to clk_put.
>
> Signed-off-by: Ezequiel Garcia 

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

Re: [PATCH 1/7] clocksource: mips-gic: Enable the clock before using it

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 For the clock to be used (e.g. get its rate through clk_get_rate)
 it should be prepared and enabled first.

 Also, while the clock is enabled the driver must hold a reference to it,
 so let's remove the call to clk_put.

 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

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

Re: [PATCH 2/7] clocksource: mips-gic: Add missing error returns checks

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 This commit adds the required checks on the functions that return
 an error. Some of them are not critical, so only a warning is
 printed.

 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

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

Re: [PATCH 3/7] clocksource: mips-gic: Split clocksource and clockevent initialization

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 This is preparation work for the introduction of clockevent frequency
 update with a clock notifier. This is only possible when the device
 is passed a clk struct, so let's split the legacy and devicetree
 initialization.

 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com
 ---
  drivers/clocksource/mips-gic-timer.c | 13 -
  1 file changed, 8 insertions(+), 5 deletions(-)

 diff --git a/drivers/clocksource/mips-gic-timer.c 
 b/drivers/clocksource/mips-gic-timer.c
 index c4352f0..22a4daf 100644
 --- a/drivers/clocksource/mips-gic-timer.c
 +++ b/drivers/clocksource/mips-gic-timer.c
 @@ -142,11 +142,6 @@ static void __init __gic_clocksource_init(void)
 ret = clocksource_register_hz(gic_clocksource, gic_frequency);
 if (ret  0)
 pr_warn(GIC: Unable to register clocksource\n);
 -
 -   gic_clockevent_init();
 -
 -   /* And finally start the counter */
 -   gic_start_count();
  }

Instead of duplicating this bit in both the OF and non-OF paths, maybe
it would be better to do the notifier registration in
gic_clockevent_init(), either by passing around the struct clk or
making it a global?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/7] clocksource: Add Pistachio SoC general purpose timer binding document

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:41 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 Add a device-tree binding document for the clocksource driver provided
 by Pistachio SoC general purpose timers.

 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

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

Re: [PATCH 4/7] clocksource: mips-gic: Update clockevent frequency on clock rate changes

[Andrew Bresticker]

On Thu, May 21, 2015 at 2:37 PM, Ezequiel Garcia
ezequiel.gar...@imgtec.com wrote:
 This commit introduces the clockevent frequency update, using
 a clock notifier. It will be used to support CPUFreq on platforms
 using MIPS GIC based clockevents.

 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com
 ---
  drivers/clocksource/mips-gic-timer.c | 31 ++-
  1 file changed, 30 insertions(+), 1 deletion(-)

 diff --git a/drivers/clocksource/mips-gic-timer.c 
 b/drivers/clocksource/mips-gic-timer.c
 index 22a4daf..71bbd42 100644
 --- a/drivers/clocksource/mips-gic-timer.c
 +++ b/drivers/clocksource/mips-gic-timer.c
 @@ -79,6 +79,13 @@ static void gic_clockevent_cpu_exit(struct 
 clock_event_device *cd)
 disable_percpu_irq(gic_timer_irq);
  }

 +static void gic_update_frequency(void *data)
 +{
 +   unsigned long rate = (unsigned long)data;
 +
 +   clockevents_update_freq(this_cpu_ptr(gic_clockevent_device), rate);
 +}
 +
  static int gic_cpu_notifier(struct notifier_block *nb, unsigned long action,
 void *data)
  {
 @@ -94,10 +101,26 @@ static int gic_cpu_notifier(struct notifier_block *nb, 
 unsigned long action,
 return NOTIFY_OK;
  }

 +static int gic_clk_notifier(struct notifier_block *nb, unsigned long action,
 +   void *data)
 +{
 +   struct clk_notifier_data *cnd = data;
 +
 +   if (action == POST_RATE_CHANGE)
 +   on_each_cpu(gic_update_frequency, (void *)cnd-new_rate, 1);
 +
 +   return NOTIFY_OK;
 +}
 +
 +
  static struct notifier_block gic_cpu_nb = {
 .notifier_call = gic_cpu_notifier,
  };

 +static struct notifier_block gic_clk_nb = {
 +   .notifier_call = gic_clk_notifier,
 +};
 +
  static int gic_clockevent_init(void)
  {
 int ret;
 @@ -160,6 +183,7 @@ void __init gic_clocksource_init(unsigned int frequency)
  static void __init gic_clocksource_of_init(struct device_node *node)
  {
 struct clk *clk;
 +   int ret;

 if (WARN_ON(!gic_present || !node-parent ||
 !of_device_is_compatible(node-parent, mti,gic)))
 @@ -186,7 +210,12 @@ static void __init gic_clocksource_of_init(struct 
 device_node *node)
 }

 __gic_clocksource_init();
 -   gic_clockevent_init();
 +
 +   ret = gic_clockevent_init();
 +   if (ret  0  !IS_ERR(clk)) {

I think you mean ret == 0 here?

 +   if (clk_notifier_register(clk, gic_clk_nb)  0)
 +   pr_warn(GIC: Unable to register clock notifier\n);
 +   }
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup

[Andrew Bresticker]

Hi Mathias,

On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
 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 
> Reviewed-by: Felipe Balbi 
> Cc: Mathias Nyman 
> Cc: Greg Kroah-Hartman 

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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Andrew Bresticker]

Lee,

On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
 wrote:
> On Thu, May 14, 2015 at 12:40 AM, 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 
>>> >> Cc: Rob Herring 
>>> >> Cc: Pawel Moll 
>>> >> Cc: Mark Rutland 
>>> >> Cc: Ian Campbell 
>>> >> Cc: Kumar Gala 
>>> >> Cc: Samuel Ortiz 
>>> >> Cc: Lee Jones 
>>> >> ---
>>> >> 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 000..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,-xusb", 
>>> >> "nvidia,tegra124-xusb"'
>>> >> +   where  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,7009 {
>>> >> +  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 = <, [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 

Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Andrew Bresticker]

Lee,

On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
abres...@chromium.org wrote:
 On Thu, May 14, 2015 at 12:40 AM, Lee Jones lee.jo...@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 abres...@chromium.org
  Cc: Rob Herring robh...@kernel.org
  Cc: Pawel Moll pawel.m...@arm.com
  Cc: Mark Rutland mark.rutl...@arm.com
  Cc: Ian Campbell ijc+devicet...@hellion.org.uk
  Cc: Kumar Gala ga...@codeaurora.org
  Cc: Samuel Ortiz sa...@linux.intel.com
  Cc: Lee Jones lee.jo...@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 000..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,7009 {
  +  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: 0x7009 - 0x7009a000
 xHCI registers: 0x7009 - 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

Re: [PATCH v8 1/9] xhci: Set shared HCD's hcd_priv in xhci_gen_setup

[Andrew Bresticker]

Hi Mathias,

On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
abres...@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 abres...@chromium.org
 Reviewed-by: Felipe Balbi ba...@ti.com
 Cc: Mathias Nyman mathias.ny...@intel.com
 Cc: Greg Kroah-Hartman gre...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: make module xhci_hcd removable

[Andrew Bresticker]

Hi Arthur,

On Mon, May 18, 2015 at 10:53 AM, Arthur Demchenkov  wrote:
> Fixed regression. After commit 29e409f the module xhci_hcd became
> non-removable. That behaviour is not expected and there're no notes
> about it in commit message. The module should be removable as it
> blocks PM suspend/resume functions (Debian Bug#666406).
>
> Signed-off-by: Arthur Demchenkov 

Oops, sorry about that!  Anyway,

Reviewed-by: Andrew Bresticker 

I suppose this should be a considered a stable fix for v3.18 and later.

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

Re: [PATCH V2 0/3] Pistachio USB2.0 PHY

[Andrew Bresticker]

On Mon, May 11, 2015 at 7:45 AM, Kishon Vijay Abraham I  wrote:
>
>
> On Tuesday 05 May 2015 11:43 PM, Ezequiel Garcia wrote:
>>
>> Hi Kishon,
>>
>>>
>>> This series adds support for the USB2.0 PHY present on the IMG Pistachio
>>> SoC.
>>>
>>> Based on mips-for-linux-next and tested on the IMG Pistachio BuB.  If
>>> possible,
>>> I'd like this to go through the MIPS tree with Kishon's ACK.
>>>
>>
>> Tested-by: Ezequiel Garcia 
>>
>> Can we have your Ack for this series so Ralf can pick it?
>
>
> sure..
>
> Acked-by: Kishon Vijay Abraham I 

Ralf, could you pick up this series for 4.2?

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

Re: [PATCH V2 0/3] Pistachio USB2.0 PHY

[Andrew Bresticker]

On Mon, May 11, 2015 at 7:45 AM, Kishon Vijay Abraham I kis...@ti.com wrote:


 On Tuesday 05 May 2015 11:43 PM, Ezequiel Garcia wrote:

 Hi Kishon,


 This series adds support for the USB2.0 PHY present on the IMG Pistachio
 SoC.

 Based on mips-for-linux-next and tested on the IMG Pistachio BuB.  If
 possible,
 I'd like this to go through the MIPS tree with Kishon's ACK.


 Tested-by: Ezequiel Garcia ezequiel.gar...@imgtec.com

 Can we have your Ack for this series so Ralf can pick it?


 sure..

 Acked-by: Kishon Vijay Abraham I kis...@ti.com

Ralf, could you pick up this series for 4.2?

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

Re: [PATCH] usb: make module xhci_hcd removable

[Andrew Bresticker]

Hi Arthur,

On Mon, May 18, 2015 at 10:53 AM, Arthur Demchenkov spinal...@gmail.com wrote:
 Fixed regression. After commit 29e409f the module xhci_hcd became
 non-removable. That behaviour is not expected and there're no notes
 about it in commit message. The module should be removable as it
 blocks PM suspend/resume functions (Debian Bug#666406).

 Signed-off-by: Arthur Demchenkov spinal...@gmail.com

Oops, sorry about that!  Anyway,

Reviewed-by: Andrew Bresticker abres...@chromium.org

I suppose this should be a considered a stable fix for v3.18 and later.

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

Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Andrew Bresticker]

On Thu, May 14, 2015 at 12:40 AM, 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 
>> >> Cc: Rob Herring 
>> >> Cc: Pawel Moll 
>> >> Cc: Mark Rutland 
>> >> Cc: Ian Campbell 
>> >> Cc: Kumar Gala 
>> >> Cc: Samuel Ortiz 
>> >> Cc: Lee Jones 
>> >> ---
>> >> 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 000..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,-xusb", "nvidia,tegra124-xusb"'
>> >> +   where  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,7009 {
>> >> +  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 = <, [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: 0x7009 - 0x7009a000
xHCI registers: 0x7009 - 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-

Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Andrew Bresticker]

On Thu, May 14, 2015 at 12:40 AM, Lee Jones lee.jo...@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 abres...@chromium.org
  Cc: Rob Herring robh...@kernel.org
  Cc: Pawel Moll pawel.m...@arm.com
  Cc: Mark Rutland mark.rutl...@arm.com
  Cc: Ian Campbell ijc+devicet...@hellion.org.uk
  Cc: Kumar Gala ga...@codeaurora.org
  Cc: Samuel Ortiz sa...@linux.intel.com
  Cc: Lee Jones lee.jo...@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 000..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,7009 {
  +  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: 0x7009 - 0x7009a000
xHCI registers: 0x7009 - 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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Andrew Bresticker]

On Wed, May 13, 2015 at 9:50 AM, Lee Jones  wrote:
> On Wed, 13 May 2015, Andrew Bresticker wrote:
>
>> Lee,
>>
>> On Wed, May 13, 2015 at 7:39 AM, 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 
>> >> Cc: Rob Herring 
>> >> Cc: Pawel Moll 
>> >> Cc: Mark Rutland 
>> >> Cc: Ian Campbell 
>> >> Cc: Kumar Gala 
>> >> Cc: Samuel Ortiz 
>> >> Cc: Lee Jones 
>> >> ---
>> >> 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 000..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,-xusb", "nvidia,tegra124-xusb"'
>> >> +   where  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,7009 {
>> >> + 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 = <, [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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 5/9] mfd: Add driver for NVIDIA Tegra XUSB

[Andrew Bresticker]

Lee,

On Wed, May 13, 2015 at 7:37 AM, Lee Jones  wrote:
> On Mon, 04 May 2015, Andrew Bresticker wrote:
>
>> Add an MFD driver for the XUSB host complex found on NVIDIA Tegra124
>> and later SoCs.
>
> What else does it do besides USB?

Nothing - it's just the xHCI host controller and mailbox.  As I
mentioned in the binding document, the purpose of this is simply to
map and share the register set which is shared between the two
devices.

>> Signed-off-by: Andrew Bresticker 
>> Cc: Samuel Ortiz 
>> Cc: Lee Jones 
>> ---
>> Changes from v7:
>>  - Have child nodes get non-shared memory and interrupts from DT.
>>  - Use of_platform_populate rather than mfd_add_devices.
>>  - Get rid of struct tegra_xusb.
>> New for v7.
>> ---
>>  drivers/mfd/Kconfig  |  7 +
>>  drivers/mfd/Makefile |  1 +
>>  drivers/mfd/tegra-xusb.c | 75 
>> 
>>  3 files changed, 83 insertions(+)
>>  create mode 100644 drivers/mfd/tegra-xusb.c
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index d5ad04d..61872b4 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -1430,6 +1430,13 @@ config MFD_STW481X
>> in various ST Microelectronics and ST-Ericsson embedded
>> Nomadik series.
>>
>> +config MFD_TEGRA_XUSB
>> + tristate "NVIDIA Tegra XUSB"
>> + depends on ARCH_TEGRA
>> + select MFD_CORE
>> + help
>> +   Support for the XUSB complex found on NVIDIA Tegra124 and later SoCs.
>> +
>>  menu "Multimedia Capabilities Port drivers"
>>   depends on ARCH_SA1100
>>
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index 0e5cfeb..7588caf 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -181,6 +181,7 @@ obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
>>  obj-$(CONFIG_MFD_DLN2)   += dln2.o
>>  obj-$(CONFIG_MFD_RT5033) += rt5033.o
>>  obj-$(CONFIG_MFD_SKY81452)   += sky81452.o
>> +obj-$(CONFIG_MFD_TEGRA_XUSB) += tegra-xusb.o
>>
>>  intel-soc-pmic-objs  := intel_soc_pmic_core.o intel_soc_pmic_crc.o
>>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
>> diff --git a/drivers/mfd/tegra-xusb.c b/drivers/mfd/tegra-xusb.c
>> new file mode 100644
>> index 000..e11fa23
>> --- /dev/null
>> +++ b/drivers/mfd/tegra-xusb.c
>> @@ -0,0 +1,75 @@
>> +/*
>> + * NVIDIA Tegra XUSB MFD driver
>> + *
>> + * Copyright (C) 2015 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 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static const struct of_device_id tegra_xusb_of_match[] = {
>> + { .compatible = "nvidia,tegra124-xusb", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, tegra_xusb_of_match);
>
> If you're not using this to patch on, I'd prefer you place it next to
> where it's first used i.e. down at the bottom of the file.

Ok.

>> +static struct regmap_config tegra_fpci_regmap_config = {
>> + .reg_bits = 32,
>> + .val_bits = 32,
>> + .reg_stride = 4,
>> +};
>> +
>> +static int tegra_xusb_probe(struct platform_device *pdev)
>> +{
>> + struct resource *res;
>> + struct regmap *fpci_regs;
>> + void __iomem *fpci_base;
>> + int ret;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + fpci_base = devm_ioremap_resource(>dev, res);
>> + if (IS_ERR(fpci_base))
>> + return PTR_ERR(fpci_base);
>> +
>> + tegra_fpci_regmap_config.max_register = res->end - res->start - 3;
>> + fpci_regs = devm_regmap_init_mmio(>dev, fpci_base,
>> +   _fpci_regmap_config);
>> + if (IS_ERR(fpci_regs)) {
>> + ret = PTR_ERR(fpci_regs);
>> + dev_err(>dev, "Failed to init regmap: %d\n", ret);
>> + return ret;
>> + }
>> + platform_set_drvdata(pdev, fpci_regs);
>> +
>> + ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, >dev);
>> + if (ret) {
>> + dev_err(>dev, "Failed to add sub-devices: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static struct platform_driver tegra_xusb_driver = {
>> + .probe = tegra_xusb_probe,
>
> No .remove()?

It would be empty.

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

Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Andrew Bresticker]

Lee,

On Wed, May 13, 2015 at 7:39 AM, 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 
>> Cc: Rob Herring 
>> Cc: Pawel Moll 
>> Cc: Mark Rutland 
>> Cc: Ian Campbell 
>> Cc: Kumar Gala 
>> Cc: Samuel Ortiz 
>> Cc: Lee Jones 
>> ---
>> 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 000..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,-xusb", "nvidia,tegra124-xusb"'
>> +   where  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,7009 {
>> + 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 = <, [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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 5/9] mfd: Add driver for NVIDIA Tegra XUSB

[Andrew Bresticker]

Lee,

On Wed, May 13, 2015 at 7:37 AM, Lee Jones lee.jo...@linaro.org wrote:
 On Mon, 04 May 2015, Andrew Bresticker wrote:

 Add an MFD driver for the XUSB host complex found on NVIDIA Tegra124
 and later SoCs.

 What else does it do besides USB?

Nothing - it's just the xHCI host controller and mailbox.  As I
mentioned in the binding document, the purpose of this is simply to
map and share the register set which is shared between the two
devices.

 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Cc: Samuel Ortiz sa...@linux.intel.com
 Cc: Lee Jones lee.jo...@linaro.org
 ---
 Changes from v7:
  - Have child nodes get non-shared memory and interrupts from DT.
  - Use of_platform_populate rather than mfd_add_devices.
  - Get rid of struct tegra_xusb.
 New for v7.
 ---
  drivers/mfd/Kconfig  |  7 +
  drivers/mfd/Makefile |  1 +
  drivers/mfd/tegra-xusb.c | 75 
 
  3 files changed, 83 insertions(+)
  create mode 100644 drivers/mfd/tegra-xusb.c

 diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
 index d5ad04d..61872b4 100644
 --- a/drivers/mfd/Kconfig
 +++ b/drivers/mfd/Kconfig
 @@ -1430,6 +1430,13 @@ config MFD_STW481X
 in various ST Microelectronics and ST-Ericsson embedded
 Nomadik series.

 +config MFD_TEGRA_XUSB
 + tristate NVIDIA Tegra XUSB
 + depends on ARCH_TEGRA
 + select MFD_CORE
 + help
 +   Support for the XUSB complex found on NVIDIA Tegra124 and later SoCs.
 +
  menu Multimedia Capabilities Port drivers
   depends on ARCH_SA1100

 diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
 index 0e5cfeb..7588caf 100644
 --- a/drivers/mfd/Makefile
 +++ b/drivers/mfd/Makefile
 @@ -181,6 +181,7 @@ obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
  obj-$(CONFIG_MFD_DLN2)   += dln2.o
  obj-$(CONFIG_MFD_RT5033) += rt5033.o
  obj-$(CONFIG_MFD_SKY81452)   += sky81452.o
 +obj-$(CONFIG_MFD_TEGRA_XUSB) += tegra-xusb.o

  intel-soc-pmic-objs  := intel_soc_pmic_core.o intel_soc_pmic_crc.o
  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
 diff --git a/drivers/mfd/tegra-xusb.c b/drivers/mfd/tegra-xusb.c
 new file mode 100644
 index 000..e11fa23
 --- /dev/null
 +++ b/drivers/mfd/tegra-xusb.c
 @@ -0,0 +1,75 @@
 +/*
 + * NVIDIA Tegra XUSB MFD driver
 + *
 + * Copyright (C) 2015 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/module.h
 +#include linux/mfd/core.h
 +#include linux/of.h
 +#include linux/of_platform.h
 +#include linux/platform_device.h
 +#include linux/regmap.h
 +#include linux/slab.h
 +
 +static const struct of_device_id tegra_xusb_of_match[] = {
 + { .compatible = nvidia,tegra124-xusb, },
 + {},
 +};
 +MODULE_DEVICE_TABLE(of, tegra_xusb_of_match);

 If you're not using this to patch on, I'd prefer you place it next to
 where it's first used i.e. down at the bottom of the file.

Ok.

 +static struct regmap_config tegra_fpci_regmap_config = {
 + .reg_bits = 32,
 + .val_bits = 32,
 + .reg_stride = 4,
 +};
 +
 +static int tegra_xusb_probe(struct platform_device *pdev)
 +{
 + struct resource *res;
 + struct regmap *fpci_regs;
 + void __iomem *fpci_base;
 + int ret;
 +
 + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 + fpci_base = devm_ioremap_resource(pdev-dev, res);
 + if (IS_ERR(fpci_base))
 + return PTR_ERR(fpci_base);
 +
 + tegra_fpci_regmap_config.max_register = res-end - res-start - 3;
 + fpci_regs = devm_regmap_init_mmio(pdev-dev, fpci_base,
 +   tegra_fpci_regmap_config);
 + if (IS_ERR(fpci_regs)) {
 + ret = PTR_ERR(fpci_regs);
 + dev_err(pdev-dev, Failed to init regmap: %d\n, ret);
 + return ret;
 + }
 + platform_set_drvdata(pdev, fpci_regs);
 +
 + ret = of_platform_populate(pdev-dev.of_node, NULL, NULL, pdev-dev);
 + if (ret) {
 + dev_err(pdev-dev, Failed to add sub-devices: %d\n, ret);
 + return ret;
 + }
 +
 + return 0;
 +}
 +
 +static struct platform_driver tegra_xusb_driver = {
 + .probe = tegra_xusb_probe,

 No .remove()?

It would be empty.

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

Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Andrew Bresticker]

Lee,

On Wed, May 13, 2015 at 7:39 AM, Lee Jones lee.jo...@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 abres...@chromium.org
 Cc: Rob Herring robh...@kernel.org
 Cc: Pawel Moll pawel.m...@arm.com
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Ian Campbell ijc+devicet...@hellion.org.uk
 Cc: Kumar Gala ga...@codeaurora.org
 Cc: Samuel Ortiz sa...@linux.intel.com
 Cc: Lee Jones lee.jo...@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 000..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,7009 {
 + 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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Andrew Bresticker]

On Wed, May 13, 2015 at 9:50 AM, Lee Jones lee.jo...@linaro.org wrote:
 On Wed, 13 May 2015, Andrew Bresticker wrote:

 Lee,

 On Wed, May 13, 2015 at 7:39 AM, Lee Jones lee.jo...@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 abres...@chromium.org
  Cc: Rob Herring robh...@kernel.org
  Cc: Pawel Moll pawel.m...@arm.com
  Cc: Mark Rutland mark.rutl...@arm.com
  Cc: Ian Campbell ijc+devicet...@hellion.org.uk
  Cc: Kumar Gala ga...@codeaurora.org
  Cc: Samuel Ortiz sa...@linux.intel.com
  Cc: Lee Jones lee.jo...@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 000..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,7009 {
  + 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 linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding

[Andrew Bresticker]

On Fri, May 8, 2015 at 1:42 PM, Benson Leung  wrote:
> On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
>  wrote:
>> + - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-mbox".
>> +   Otherwise, must contain '"nvidia,-xusb-mbox",
>> +   "nvidia,tegra124-xusb-mbox"' where  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,-" 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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding

[Andrew Bresticker]

On Fri, May 8, 2015 at 1:42 PM, Benson Leung ble...@chromium.org wrote:
 On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
 abres...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V5] pinctrl: Add Pistachio SoC pin control driver

[Andrew Bresticker]

Add a driver for the pin controller present on the IMG Pistachio SoC.
This driver provides pinmux and pinconfig operations as well as GPIO
and IRQ chips for the GPIO banks.

Signed-off-by: Damien Horsley 
Signed-off-by: Govindraj Raja 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Kevin Cernekee 
Signed-off-by: Andrew Bresticker 
Cc: James Hartley 
Cc: James Hogan 
---
Changes from v4:
 - Switched to using gpiochip_add_pin_range().
 - Fixed up Kconfig entry.
Changes from v3:
 - Addressed review comments from Ezequiel.
Changes from v2:
 - Removed module stuff which would be compiled out.
Changes from v1:
 - Addressed review comments from Linus.
 - Changed compatible string to "img,pistachio-system-pinctrl".
 - Look for GPIO sub-nodes by name.
 - A couple of bug fixes.
---
 drivers/pinctrl/Kconfig |8 +
 drivers/pinctrl/Makefile|1 +
 drivers/pinctrl/pinctrl-pistachio.c | 1504 +++
 3 files changed, 1513 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-pistachio.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index aeb5729..85691e4 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -125,6 +125,14 @@ config PINCTRL_SIRF
select PINMUX
select GPIOLIB_IRQCHIP
 
+config PINCTRL_PISTACHIO
+   def_bool y if MACH_PISTACHIO
+   depends on GPIOLIB
+   select PINMUX
+   select GENERIC_PINCONF
+   select GPIOLIB_IRQCHIP
+   select OF_GPIO
+
 config PINCTRL_ST
bool
depends on OF
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 6eadf04..510189e 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_PINCTRL_AMD) += pinctrl-amd.o
 obj-$(CONFIG_PINCTRL_FALCON)   += pinctrl-falcon.o
 obj-$(CONFIG_PINCTRL_MESON)+= meson/
 obj-$(CONFIG_PINCTRL_PALMAS)   += pinctrl-palmas.o
+obj-$(CONFIG_PINCTRL_PISTACHIO)+= pinctrl-pistachio.o
 obj-$(CONFIG_PINCTRL_ROCKCHIP) += pinctrl-rockchip.o
 obj-$(CONFIG_PINCTRL_SINGLE)   += pinctrl-single.o
 obj-$(CONFIG_PINCTRL_SIRF) += sirf/
diff --git a/drivers/pinctrl/pinctrl-pistachio.c 
b/drivers/pinctrl/pinctrl-pistachio.c
new file mode 100644
index 000..079ce8b
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-pistachio.c
@@ -0,0 +1,1504 @@
+/*
+ * Pistachio SoC pinctrl driver
+ *
+ * Copyright (C) 2014 Imagination Technologies Ltd.
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-utils.h"
+
+#define PADS_SCHMITT_EN0   0x000
+#define PADS_SCHMITT_EN_REG(pin)   (PADS_SCHMITT_EN0 + 0x4 * ((pin) / 32))
+#define PADS_SCHMITT_EN_BIT(pin)   BIT((pin) % 32)
+
+#define PADS_PU_PD00x040
+#define PADS_PU_PD_REG(pin)(PADS_PU_PD0 + 0x4 * ((pin) / 16))
+#define PADS_PU_PD_SHIFT(pin)  (2 * ((pin) % 16))
+#define PADS_PU_PD_MASK0x3
+#define PADS_PU_PD_HIGHZ   0x0
+#define PADS_PU_PD_UP  0x1
+#define PADS_PU_PD_DOWN0x2
+#define PADS_PU_PD_BUS 0x3
+
+#define PADS_FUNCTION_SELECT0  0x0c0
+#define PADS_FUNCTION_SELECT1  0x0c4
+#define PADS_FUNCTION_SELECT2  0x0c8
+#define PADS_SCENARIO_SELECT   0x0f8
+
+#define PADS_SLEW_RATE00x100
+#define PADS_SLEW_RATE_REG(pin)(PADS_SLEW_RATE0 + 0x4 * ((pin) 
/ 32))
+#define PADS_SLEW_RATE_BIT(pin)BIT((pin) % 32)
+
+#define PADS_DRIVE_STRENGTH0   0x120
+#define PADS_DRIVE_STRENGTH_REG(pin)   \
+   (PADS_DRIVE_STRENGTH0 + 0x4 * ((pin) / 16))
+#define PADS_DRIVE_STRENGTH_SHIFT(pin) (2 * ((pin) % 16))
+#define PADS_DRIVE_STRENGTH_MASK   0x3
+#define PADS_DRIVE_STRENGTH_2MA0x0
+#define PADS_DRIVE_STRENGTH_4MA0x1
+#define PADS_DRIVE_STRENGTH_8MA0x2
+#define PADS_DRIVE_STRENGTH_12MA   0x3
+
+#define GPIO_BANK_BASE(bank)   (0x200 + 0x24 * (bank))
+
+#define GPIO_BIT_EN0x00
+#define GPIO_OUTPUT_EN 0x04
+#define GPIO_OUTPUT0x08
+#define GPIO_INPUT 0x0c
+#define GPIO_INPUT_POLARITY0x10
+#define GPIO_INTERRUPT_TYPE0x14
+#define GPIO_INTERRUPT_TYPE_LEVEL  0x0
+#define GPIO_INTERRUPT_TYPE_EDGE   0x1
+#define GPIO_INTERRUPT_EDGE0x18
+#define GPIO_INTERRUPT_EDGE_SINGLE 0x0
+#define GPIO_INTERRUPT_EDGE_DUAL   0x1
+#define GPIO_INTERRUPT_EN  0x1c
+#define GPIO_INTERRUPT_

Re: [PATCH V4 2/2] pinctrl: Add Pistachio SoC pin control driver

[Andrew Bresticker]

Hi Linus,

On Wed, May 6, 2015 at 12:14 AM, Linus Walleij  wrote:
> Hi Andrew and sorry for a slow review process, I've been
> overloaded :(
>
> On Wed, Apr 29, 2015 at 3:13 AM, Andrew Bresticker
>  wrote:
>
>> Add a driver for the pin controller present on the IMG Pistachio SoC.
>> This driver provides pinmux and pinconfig operations as well as GPIO
>> and IRQ chips for the GPIO banks.
>>
>> Signed-off-by: Damien Horsley 
>> Signed-off-by: Govindraj Raja 
>> Signed-off-by: Ezequiel Garcia 
>> Signed-off-by: Kevin Cernekee 
>> Signed-off-by: Andrew Bresticker 
>> ---
>> Changes from v3:
>>  - Addressed review comments from Ezequiel.
>
> Overall this is a very very nice looking driver so expect it to
> be merged after addressing or answering my last few
> concerns.
>
>> +config PINCTRL_PISTACHIO
>> +   def_bool y if MACH_PISTACHIO
>> +   select PINMUX
>> +   select GENERIC_PINCONF
>> +   select GPIOLIB_IRQCHIP
>
> I think you also need
> depends on / select GPIOLIB
> select OF_GPIO
>
> x86_64 allmodconfig is usually the best way to test
> if your GPIOs and pin control fragments are correctly Kconfig:ed.

Right, will fix.

>> +#define GPIO_BANK(_bank, _pin_base, _npins)\
>> +   {   \
>> +   .gpio_chip = {  \
>> +   .label = "GPIO" #_bank, \
>> +   .request = pistachio_gpio_request,  \
>> +   .free = pistachio_gpio_free,\
>> +   .get_direction = pistachio_gpio_get_direction,  \
>> +   .direction_input = pistachio_gpio_direction_input, \
>> +   .direction_output = pistachio_gpio_direction_output, 
>> \
>> +   .get = pistachio_gpio_get,  \
>> +   .set = pistachio_gpio_set,  \
>> +   .base = _pin_base,  \
>> +   .ngpio = _npins,\
>> +   },  \
>> +   .irq_chip = {   \
>> +   .name = "GPIO" #_bank,  \
>> +   .irq_startup = pistachio_gpio_irq_startup,  \
>> +   .irq_ack = pistachio_gpio_irq_ack,  \
>> +   .irq_mask = pistachio_gpio_irq_mask,\
>> +   .irq_unmask = pistachio_gpio_irq_unmask,\
>> +   .irq_set_type = pistachio_gpio_irq_set_type,\
>> +   },  \
>> +   .gpio_range = { \
>> +   .name = "GPIO" #_bank,  \
>> +   .id = _bank,\
>> +   .base = _pin_base,  \
>> +   .pin_base = _pin_base,  \
>> +   .npins = _npins,\
>> +   },  \
>> +   }
>
> This -gpio_range is the only thing that bothers me a little, combined with
> this:
>
>> +   bank->gpio_range.gc = >gpio_chip;
>> +   pinctrl_add_gpio_range(pctl->pctldev, >gpio_range);
>
> Because it adds the ranges from the pinctrl side instead of
> doing it from the gpiochip side using
> gpiochip_add_pin_range() or gpiochip_add_pingroup_range().
>
> Have you tried using those (from  instead?
>
> They have the upside that .base is taken from the gpio_chip
> meaning it is unnecessary to define .base for the gpiochip
> too and you can just go for what gpiolib dynamically assigns
> for you.

Yup, switching to gpiochip_add_pin_range() works just fine here.

>> +static int __init pistachio_pinctrl_register(void)
>> +{
>> +   return platform_driver_register(_pinctrl_driver);
>> +}
>> +arch_initcall(pistachio_pinctrl_register);
>
> Is it necessary to have it registered so early?

No, nothing depends on it being initialized this early.  When I was
asked to remove the module stuff, I just picked arch_initcall since
that's what most other pinctrl drivers not using
module_platform_driver() use.  It also has the benefit of reducing the
number of probe deferrals.

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

Re: [PATCH V4 2/2] pinctrl: Add Pistachio SoC pin control driver

[Andrew Bresticker]

Hi Linus,

On Wed, May 6, 2015 at 12:14 AM, Linus Walleij linus.wall...@linaro.org wrote:
 Hi Andrew and sorry for a slow review process, I've been
 overloaded :(

 On Wed, Apr 29, 2015 at 3:13 AM, Andrew Bresticker
 abres...@chromium.org wrote:

 Add a driver for the pin controller present on the IMG Pistachio SoC.
 This driver provides pinmux and pinconfig operations as well as GPIO
 and IRQ chips for the GPIO banks.

 Signed-off-by: Damien Horsley damien.hors...@imgtec.com
 Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
 Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com
 Signed-off-by: Kevin Cernekee cerne...@chromium.org
 Signed-off-by: Andrew Bresticker abres...@chromium.org
 ---
 Changes from v3:
  - Addressed review comments from Ezequiel.

 Overall this is a very very nice looking driver so expect it to
 be merged after addressing or answering my last few
 concerns.

 +config PINCTRL_PISTACHIO
 +   def_bool y if MACH_PISTACHIO
 +   select PINMUX
 +   select GENERIC_PINCONF
 +   select GPIOLIB_IRQCHIP

 I think you also need
 depends on / select GPIOLIB
 select OF_GPIO

 x86_64 allmodconfig is usually the best way to test
 if your GPIOs and pin control fragments are correctly Kconfig:ed.

Right, will fix.

 +#define GPIO_BANK(_bank, _pin_base, _npins)\
 +   {   \
 +   .gpio_chip = {  \
 +   .label = GPIO #_bank, \
 +   .request = pistachio_gpio_request,  \
 +   .free = pistachio_gpio_free,\
 +   .get_direction = pistachio_gpio_get_direction,  \
 +   .direction_input = pistachio_gpio_direction_input, \
 +   .direction_output = pistachio_gpio_direction_output, 
 \
 +   .get = pistachio_gpio_get,  \
 +   .set = pistachio_gpio_set,  \
 +   .base = _pin_base,  \
 +   .ngpio = _npins,\
 +   },  \
 +   .irq_chip = {   \
 +   .name = GPIO #_bank,  \
 +   .irq_startup = pistachio_gpio_irq_startup,  \
 +   .irq_ack = pistachio_gpio_irq_ack,  \
 +   .irq_mask = pistachio_gpio_irq_mask,\
 +   .irq_unmask = pistachio_gpio_irq_unmask,\
 +   .irq_set_type = pistachio_gpio_irq_set_type,\
 +   },  \
 +   .gpio_range = { \
 +   .name = GPIO #_bank,  \
 +   .id = _bank,\
 +   .base = _pin_base,  \
 +   .pin_base = _pin_base,  \
 +   .npins = _npins,\
 +   },  \
 +   }

 This -gpio_range is the only thing that bothers me a little, combined with
 this:

 +   bank-gpio_range.gc = bank-gpio_chip;
 +   pinctrl_add_gpio_range(pctl-pctldev, bank-gpio_range);

 Because it adds the ranges from the pinctrl side instead of
 doing it from the gpiochip side using
 gpiochip_add_pin_range() or gpiochip_add_pingroup_range().

 Have you tried using those (from linux/gpio/driver.h instead?

 They have the upside that .base is taken from the gpio_chip
 meaning it is unnecessary to define .base for the gpiochip
 too and you can just go for what gpiolib dynamically assigns
 for you.

Yup, switching to gpiochip_add_pin_range() works just fine here.

 +static int __init pistachio_pinctrl_register(void)
 +{
 +   return platform_driver_register(pistachio_pinctrl_driver);
 +}
 +arch_initcall(pistachio_pinctrl_register);

 Is it necessary to have it registered so early?

No, nothing depends on it being initialized this early.  When I was
asked to remove the module stuff, I just picked arch_initcall since
that's what most other pinctrl drivers not using
module_platform_driver() use.  It also has the benefit of reducing the
number of probe deferrals.

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

[PATCH V5] pinctrl: Add Pistachio SoC pin control driver

[Andrew Bresticker]

Add a driver for the pin controller present on the IMG Pistachio SoC.
This driver provides pinmux and pinconfig operations as well as GPIO
and IRQ chips for the GPIO banks.

Signed-off-by: Damien Horsley damien.hors...@imgtec.com
Signed-off-by: Govindraj Raja govindraj.r...@imgtec.com
Signed-off-by: Ezequiel Garcia ezequiel.gar...@imgtec.com
Signed-off-by: Kevin Cernekee cerne...@chromium.org
Signed-off-by: Andrew Bresticker abres...@chromium.org
Cc: James Hartley james.hart...@imgtec.com
Cc: James Hogan james.ho...@imgtec.com
---
Changes from v4:
 - Switched to using gpiochip_add_pin_range().
 - Fixed up Kconfig entry.
Changes from v3:
 - Addressed review comments from Ezequiel.
Changes from v2:
 - Removed module stuff which would be compiled out.
Changes from v1:
 - Addressed review comments from Linus.
 - Changed compatible string to img,pistachio-system-pinctrl.
 - Look for GPIO sub-nodes by name.
 - A couple of bug fixes.
---
 drivers/pinctrl/Kconfig |8 +
 drivers/pinctrl/Makefile|1 +
 drivers/pinctrl/pinctrl-pistachio.c | 1504 +++
 3 files changed, 1513 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-pistachio.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index aeb5729..85691e4 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -125,6 +125,14 @@ config PINCTRL_SIRF
select PINMUX
select GPIOLIB_IRQCHIP
 
+config PINCTRL_PISTACHIO
+   def_bool y if MACH_PISTACHIO
+   depends on GPIOLIB
+   select PINMUX
+   select GENERIC_PINCONF
+   select GPIOLIB_IRQCHIP
+   select OF_GPIO
+
 config PINCTRL_ST
bool
depends on OF
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 6eadf04..510189e 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_PINCTRL_AMD) += pinctrl-amd.o
 obj-$(CONFIG_PINCTRL_FALCON)   += pinctrl-falcon.o
 obj-$(CONFIG_PINCTRL_MESON)+= meson/
 obj-$(CONFIG_PINCTRL_PALMAS)   += pinctrl-palmas.o
+obj-$(CONFIG_PINCTRL_PISTACHIO)+= pinctrl-pistachio.o
 obj-$(CONFIG_PINCTRL_ROCKCHIP) += pinctrl-rockchip.o
 obj-$(CONFIG_PINCTRL_SINGLE)   += pinctrl-single.o
 obj-$(CONFIG_PINCTRL_SIRF) += sirf/
diff --git a/drivers/pinctrl/pinctrl-pistachio.c 
b/drivers/pinctrl/pinctrl-pistachio.c
new file mode 100644
index 000..079ce8b
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-pistachio.c
@@ -0,0 +1,1504 @@
+/*
+ * Pistachio SoC pinctrl driver
+ *
+ * Copyright (C) 2014 Imagination Technologies Ltd.
+ * 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/gpio.h
+#include linux/gpio/driver.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/pinctrl/pinconf.h
+#include linux/pinctrl/pinconf-generic.h
+#include linux/pinctrl/pinctrl.h
+#include linux/pinctrl/pinmux.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/spinlock.h
+
+#include pinctrl-utils.h
+
+#define PADS_SCHMITT_EN0   0x000
+#define PADS_SCHMITT_EN_REG(pin)   (PADS_SCHMITT_EN0 + 0x4 * ((pin) / 32))
+#define PADS_SCHMITT_EN_BIT(pin)   BIT((pin) % 32)
+
+#define PADS_PU_PD00x040
+#define PADS_PU_PD_REG(pin)(PADS_PU_PD0 + 0x4 * ((pin) / 16))
+#define PADS_PU_PD_SHIFT(pin)  (2 * ((pin) % 16))
+#define PADS_PU_PD_MASK0x3
+#define PADS_PU_PD_HIGHZ   0x0
+#define PADS_PU_PD_UP  0x1
+#define PADS_PU_PD_DOWN0x2
+#define PADS_PU_PD_BUS 0x3
+
+#define PADS_FUNCTION_SELECT0  0x0c0
+#define PADS_FUNCTION_SELECT1  0x0c4
+#define PADS_FUNCTION_SELECT2  0x0c8
+#define PADS_SCENARIO_SELECT   0x0f8
+
+#define PADS_SLEW_RATE00x100
+#define PADS_SLEW_RATE_REG(pin)(PADS_SLEW_RATE0 + 0x4 * ((pin) 
/ 32))
+#define PADS_SLEW_RATE_BIT(pin)BIT((pin) % 32)
+
+#define PADS_DRIVE_STRENGTH0   0x120
+#define PADS_DRIVE_STRENGTH_REG(pin)   \
+   (PADS_DRIVE_STRENGTH0 + 0x4 * ((pin) / 16))
+#define PADS_DRIVE_STRENGTH_SHIFT(pin) (2 * ((pin) % 16))
+#define PADS_DRIVE_STRENGTH_MASK   0x3
+#define PADS_DRIVE_STRENGTH_2MA0x0
+#define PADS_DRIVE_STRENGTH_4MA0x1
+#define PADS_DRIVE_STRENGTH_8MA0x2
+#define PADS_DRIVE_STRENGTH_12MA   0x3
+
+#define GPIO_BANK_BASE(bank)   (0x200 + 0x24 * (bank))
+
+#define GPIO_BIT_EN0x00
+#define GPIO_OUTPUT_EN 0x04
+#define GPIO_OUTPUT0x08
+#define GPIO_INPUT 0x0c

Re: [PATCH V2 1/3] phy: Add binding document for Pistachio USB2.0 PHY

[Andrew Bresticker]

On Tue, May 5, 2015 at 4:35 PM, James Hogan  wrote:
> On Tue, May 05, 2015 at 04:09:31PM -0700, Andrew Bresticker wrote:
>> On Tue, May 5, 2015 at 3:43 PM, James Hogan  wrote:
>> > On Tue, May 05, 2015 at 03:16:23PM -0700, Andrew Bresticker wrote:
>> >> Hi James,
>> >>
>> >> On Tue, May 5, 2015 at 3:01 PM, James Hogan  
>> >> wrote:
>> >> > Hi Andrew,
>> >> >
>> >> > On Tue, Apr 07, 2015 at 03:04:16PM -0700, Andrew Bresticker wrote:
>> >> >> Add a binding document for the USB2.0 PHY found on the IMG Pistachio 
>> >> >> SoC.
>> >> >>
>> >> >> Signed-off-by: Andrew Bresticker 
>> >> >> Cc: Rob Herring 
>> >> >> Cc: Pawel Moll 
>> >> >> Cc: Mark Rutland 
>> >> >> Cc: Ian Campbell 
>> >> >> Cc: Kumar Gala 
>> >> >> ---
>> >> >> No changes from v1.
>> >> >> ---
>> >> >>  .../devicetree/bindings/phy/pistachio-usb-phy.txt  | 29 
>> >> >> ++
>> >> >>  include/dt-bindings/phy/phy-pistachio-usb.h| 16 
>> >> >>  2 files changed, 45 insertions(+)
>> >> >>  create mode 100644 
>> >> >> Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
>> >> >>  create mode 100644 include/dt-bindings/phy/phy-pistachio-usb.h
>> >> >>
>> >> >> diff --git 
>> >> >> a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt 
>> >> >> b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
>> >> >> new file mode 100644
>> >> >> index 000..afbc7e2
>> >> >> --- /dev/null
>> >> >> +++ b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
>> >> >> @@ -0,0 +1,29 @@
>> >> >> +IMG Pistachio USB PHY
>> >> >> +=
>> >> >> +
>> >> >> +Required properties:
>> >> >> +
>> >> >> + - compatible: Must be "img,pistachio-usb-phy".
>> >> >> + - #phy-cells: Must be 0.  See ./phy-bindings.txt for details.
>> >> >> + - clocks: Must contain an entry for each entry in clock-names.
>> >> >> +   See ../clock/clock-bindings.txt for details.
>> >> >> + - clock-names: Must include "usb_phy".
>> >> >> + - img,cr-top: Must constain a phandle to the CR_TOP syscon node.
>> >> >> + - img,refclk: Indicates the reference clock source for the USB PHY.
>> >> >> +   See  for a list of valid 
>> >> >> values.
>> >> >
>> >> > Possibly dumb question: why isn't the reference clock source specified
>> >> > in the normal ways like the "usb_phy" clock is?
>> >> >
>> >> > Does the value required here depend on what usb_phy clock gets muxed
>> >> > from or something?
>> >>
>> >> Right, the value indicates what clock "usb_phy" is: whether it comes
>> >> from the core clock controller, the XO crystal, or is some external
>> >> clock.  It's a mux internal to the PHY.
>> >
>> > Okay. If its a software controllable mux, is there a particular reason
>> > the DT doesn't describe it as such, i.e. have all 3 clock inputs, and
>> > the driver somehow work out which to use?
>>
>> Well, I'm not sure how the driver would determine which clock to use
>> without a device-tree property like the one I've got here :).  Also,
>
> Does it make sense to just look for the "best" usable source clock based
> on the supported rates listed in fsel_rate_map[] (for some definition of
> "best" such as "fastest" / "slowest" / "first usable"), or are things
> just not that simple?
>
> I'm just wondering how the DT writer would decide, since it seems to
> come down to a policy decision rather than a description of the
> hardware, which should probably be avoided in DT bindings if possible.

Ah, sorry if that was unclear - this *is* describing a hardware
property.  The DT author would pick a value by looking at which clock
is connected to the PHY in the schematic.

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

Re: [PATCH V2 1/3] phy: Add binding document for Pistachio USB2.0 PHY

[Andrew Bresticker]

On Tue, May 5, 2015 at 3:43 PM, James Hogan  wrote:
> On Tue, May 05, 2015 at 03:16:23PM -0700, Andrew Bresticker wrote:
>> Hi James,
>>
>> On Tue, May 5, 2015 at 3:01 PM, James Hogan  wrote:
>> > Hi Andrew,
>> >
>> > On Tue, Apr 07, 2015 at 03:04:16PM -0700, Andrew Bresticker wrote:
>> >> Add a binding document for the USB2.0 PHY found on the IMG Pistachio SoC.
>> >>
>> >> Signed-off-by: Andrew Bresticker 
>> >> Cc: Rob Herring 
>> >> Cc: Pawel Moll 
>> >> Cc: Mark Rutland 
>> >> Cc: Ian Campbell 
>> >> Cc: Kumar Gala 
>> >> ---
>> >> No changes from v1.
>> >> ---
>> >>  .../devicetree/bindings/phy/pistachio-usb-phy.txt  | 29 
>> >> ++
>> >>  include/dt-bindings/phy/phy-pistachio-usb.h| 16 
>> >>  2 files changed, 45 insertions(+)
>> >>  create mode 100644 
>> >> Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
>> >>  create mode 100644 include/dt-bindings/phy/phy-pistachio-usb.h
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt 
>> >> b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
>> >> new file mode 100644
>> >> index 000..afbc7e2
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
>> >> @@ -0,0 +1,29 @@
>> >> +IMG Pistachio USB PHY
>> >> +=
>> >> +
>> >> +Required properties:
>> >> +
>> >> + - compatible: Must be "img,pistachio-usb-phy".
>> >> + - #phy-cells: Must be 0.  See ./phy-bindings.txt for details.
>> >> + - clocks: Must contain an entry for each entry in clock-names.
>> >> +   See ../clock/clock-bindings.txt for details.
>> >> + - clock-names: Must include "usb_phy".
>> >> + - img,cr-top: Must constain a phandle to the CR_TOP syscon node.
>> >> + - img,refclk: Indicates the reference clock source for the USB PHY.
>> >> +   See  for a list of valid values.
>> >
>> > Possibly dumb question: why isn't the reference clock source specified
>> > in the normal ways like the "usb_phy" clock is?
>> >
>> > Does the value required here depend on what usb_phy clock gets muxed
>> > from or something?
>>
>> Right, the value indicates what clock "usb_phy" is: whether it comes
>> from the core clock controller, the XO crystal, or is some external
>> clock.  It's a mux internal to the PHY.
>
> Okay. If its a software controllable mux, is there a particular reason
> the DT doesn't describe it as such, i.e. have all 3 clock inputs, and
> the driver somehow work out which to use?

Well, I'm not sure how the driver would determine which clock to use
without a device-tree property like the one I've got here :).  Also,
all three clock need not be present.

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

Re: [PATCH V2 1/3] phy: Add binding document for Pistachio USB2.0 PHY

[Andrew Bresticker]

Hi James,

On Tue, May 5, 2015 at 3:01 PM, James Hogan  wrote:
> Hi Andrew,
>
> On Tue, Apr 07, 2015 at 03:04:16PM -0700, Andrew Bresticker wrote:
>> Add a binding document for the USB2.0 PHY found on the IMG Pistachio SoC.
>>
>> Signed-off-by: Andrew Bresticker 
>> Cc: Rob Herring 
>> Cc: Pawel Moll 
>> Cc: Mark Rutland 
>> Cc: Ian Campbell 
>> Cc: Kumar Gala 
>> ---
>> No changes from v1.
>> ---
>>  .../devicetree/bindings/phy/pistachio-usb-phy.txt  | 29 
>> ++
>>  include/dt-bindings/phy/phy-pistachio-usb.h| 16 
>>  2 files changed, 45 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
>>  create mode 100644 include/dt-bindings/phy/phy-pistachio-usb.h
>>
>> diff --git a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt 
>> b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
>> new file mode 100644
>> index 000..afbc7e2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
>> @@ -0,0 +1,29 @@
>> +IMG Pistachio USB PHY
>> +=
>> +
>> +Required properties:
>> +
>> + - compatible: Must be "img,pistachio-usb-phy".
>> + - #phy-cells: Must be 0.  See ./phy-bindings.txt for details.
>> + - clocks: Must contain an entry for each entry in clock-names.
>> +   See ../clock/clock-bindings.txt for details.
>> + - clock-names: Must include "usb_phy".
>> + - img,cr-top: Must constain a phandle to the CR_TOP syscon node.
>> + - img,refclk: Indicates the reference clock source for the USB PHY.
>> +   See  for a list of valid values.
>
> Possibly dumb question: why isn't the reference clock source specified
> in the normal ways like the "usb_phy" clock is?
>
> Does the value required here depend on what usb_phy clock gets muxed
> from or something?

Right, the value indicates what clock "usb_phy" is: whether it comes
from the core clock controller, the XO crystal, or is some external
clock.  It's a mux internal to the PHY.

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

Re: [PATCH V2 1/3] phy: Add binding document for Pistachio USB2.0 PHY

[Andrew Bresticker]

On Tue, May 5, 2015 at 3:43 PM, James Hogan james.ho...@imgtec.com wrote:
 On Tue, May 05, 2015 at 03:16:23PM -0700, Andrew Bresticker wrote:
 Hi James,

 On Tue, May 5, 2015 at 3:01 PM, James Hogan james.ho...@imgtec.com wrote:
  Hi Andrew,
 
  On Tue, Apr 07, 2015 at 03:04:16PM -0700, Andrew Bresticker wrote:
  Add a binding document for the USB2.0 PHY found on the IMG Pistachio SoC.
 
  Signed-off-by: Andrew Bresticker abres...@chromium.org
  Cc: Rob Herring robh...@kernel.org
  Cc: Pawel Moll pawel.m...@arm.com
  Cc: Mark Rutland mark.rutl...@arm.com
  Cc: Ian Campbell ijc+devicet...@hellion.org.uk
  Cc: Kumar Gala ga...@codeaurora.org
  ---
  No changes from v1.
  ---
   .../devicetree/bindings/phy/pistachio-usb-phy.txt  | 29 
  ++
   include/dt-bindings/phy/phy-pistachio-usb.h| 16 
   2 files changed, 45 insertions(+)
   create mode 100644 
  Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
   create mode 100644 include/dt-bindings/phy/phy-pistachio-usb.h
 
  diff --git a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt 
  b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
  new file mode 100644
  index 000..afbc7e2
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
  @@ -0,0 +1,29 @@
  +IMG Pistachio USB PHY
  +=
  +
  +Required properties:
  +
  + - compatible: Must be img,pistachio-usb-phy.
  + - #phy-cells: Must be 0.  See ./phy-bindings.txt for details.
  + - clocks: Must contain an entry for each entry in clock-names.
  +   See ../clock/clock-bindings.txt for details.
  + - clock-names: Must include usb_phy.
  + - img,cr-top: Must constain a phandle to the CR_TOP syscon node.
  + - img,refclk: Indicates the reference clock source for the USB PHY.
  +   See dt-bindings/phy/phy-pistachio-usb.h for a list of valid values.
 
  Possibly dumb question: why isn't the reference clock source specified
  in the normal ways like the usb_phy clock is?
 
  Does the value required here depend on what usb_phy clock gets muxed
  from or something?

 Right, the value indicates what clock usb_phy is: whether it comes
 from the core clock controller, the XO crystal, or is some external
 clock.  It's a mux internal to the PHY.

 Okay. If its a software controllable mux, is there a particular reason
 the DT doesn't describe it as such, i.e. have all 3 clock inputs, and
 the driver somehow work out which to use?

Well, I'm not sure how the driver would determine which clock to use
without a device-tree property like the one I've got here :).  Also,
all three clock need not be present.

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

Re: [PATCH V2 1/3] phy: Add binding document for Pistachio USB2.0 PHY

[Andrew Bresticker]

On Tue, May 5, 2015 at 4:35 PM, James Hogan james.ho...@imgtec.com wrote:
 On Tue, May 05, 2015 at 04:09:31PM -0700, Andrew Bresticker wrote:
 On Tue, May 5, 2015 at 3:43 PM, James Hogan james.ho...@imgtec.com wrote:
  On Tue, May 05, 2015 at 03:16:23PM -0700, Andrew Bresticker wrote:
  Hi James,
 
  On Tue, May 5, 2015 at 3:01 PM, James Hogan james.ho...@imgtec.com 
  wrote:
   Hi Andrew,
  
   On Tue, Apr 07, 2015 at 03:04:16PM -0700, Andrew Bresticker wrote:
   Add a binding document for the USB2.0 PHY found on the IMG Pistachio 
   SoC.
  
   Signed-off-by: Andrew Bresticker abres...@chromium.org
   Cc: Rob Herring robh...@kernel.org
   Cc: Pawel Moll pawel.m...@arm.com
   Cc: Mark Rutland mark.rutl...@arm.com
   Cc: Ian Campbell ijc+devicet...@hellion.org.uk
   Cc: Kumar Gala ga...@codeaurora.org
   ---
   No changes from v1.
   ---
.../devicetree/bindings/phy/pistachio-usb-phy.txt  | 29 
   ++
include/dt-bindings/phy/phy-pistachio-usb.h| 16 
2 files changed, 45 insertions(+)
create mode 100644 
   Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
create mode 100644 include/dt-bindings/phy/phy-pistachio-usb.h
  
   diff --git 
   a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt 
   b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
   new file mode 100644
   index 000..afbc7e2
   --- /dev/null
   +++ b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
   @@ -0,0 +1,29 @@
   +IMG Pistachio USB PHY
   +=
   +
   +Required properties:
   +
   + - compatible: Must be img,pistachio-usb-phy.
   + - #phy-cells: Must be 0.  See ./phy-bindings.txt for details.
   + - clocks: Must contain an entry for each entry in clock-names.
   +   See ../clock/clock-bindings.txt for details.
   + - clock-names: Must include usb_phy.
   + - img,cr-top: Must constain a phandle to the CR_TOP syscon node.
   + - img,refclk: Indicates the reference clock source for the USB PHY.
   +   See dt-bindings/phy/phy-pistachio-usb.h for a list of valid 
   values.
  
   Possibly dumb question: why isn't the reference clock source specified
   in the normal ways like the usb_phy clock is?
  
   Does the value required here depend on what usb_phy clock gets muxed
   from or something?
 
  Right, the value indicates what clock usb_phy is: whether it comes
  from the core clock controller, the XO crystal, or is some external
  clock.  It's a mux internal to the PHY.
 
  Okay. If its a software controllable mux, is there a particular reason
  the DT doesn't describe it as such, i.e. have all 3 clock inputs, and
  the driver somehow work out which to use?

 Well, I'm not sure how the driver would determine which clock to use
 without a device-tree property like the one I've got here :).  Also,

 Does it make sense to just look for the best usable source clock based
 on the supported rates listed in fsel_rate_map[] (for some definition of
 best such as fastest / slowest / first usable), or are things
 just not that simple?

 I'm just wondering how the DT writer would decide, since it seems to
 come down to a policy decision rather than a description of the
 hardware, which should probably be avoided in DT bindings if possible.

Ah, sorry if that was unclear - this *is* describing a hardware
property.  The DT author would pick a value by looking at which clock
is connected to the PHY in the schematic.

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

Re: [PATCH V2 1/3] phy: Add binding document for Pistachio USB2.0 PHY

[Andrew Bresticker]

Hi James,

On Tue, May 5, 2015 at 3:01 PM, James Hogan james.ho...@imgtec.com wrote:
 Hi Andrew,

 On Tue, Apr 07, 2015 at 03:04:16PM -0700, Andrew Bresticker wrote:
 Add a binding document for the USB2.0 PHY found on the IMG Pistachio SoC.

 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Cc: Rob Herring robh...@kernel.org
 Cc: Pawel Moll pawel.m...@arm.com
 Cc: Mark Rutland mark.rutl...@arm.com
 Cc: Ian Campbell ijc+devicet...@hellion.org.uk
 Cc: Kumar Gala ga...@codeaurora.org
 ---
 No changes from v1.
 ---
  .../devicetree/bindings/phy/pistachio-usb-phy.txt  | 29 
 ++
  include/dt-bindings/phy/phy-pistachio-usb.h| 16 
  2 files changed, 45 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
  create mode 100644 include/dt-bindings/phy/phy-pistachio-usb.h

 diff --git a/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt 
 b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
 new file mode 100644
 index 000..afbc7e2
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/phy/pistachio-usb-phy.txt
 @@ -0,0 +1,29 @@
 +IMG Pistachio USB PHY
 +=
 +
 +Required properties:
 +
 + - compatible: Must be img,pistachio-usb-phy.
 + - #phy-cells: Must be 0.  See ./phy-bindings.txt for details.
 + - clocks: Must contain an entry for each entry in clock-names.
 +   See ../clock/clock-bindings.txt for details.
 + - clock-names: Must include usb_phy.
 + - img,cr-top: Must constain a phandle to the CR_TOP syscon node.
 + - img,refclk: Indicates the reference clock source for the USB PHY.
 +   See dt-bindings/phy/phy-pistachio-usb.h for a list of valid values.

 Possibly dumb question: why isn't the reference clock source specified
 in the normal ways like the usb_phy clock is?

 Does the value required here depend on what usb_phy clock gets muxed
 from or something?

Right, the value indicates what clock usb_phy is: whether it comes
from the core clock controller, the XO crystal, or is some external
clock.  It's a mux internal to the PHY.

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

Re: [PATCH v4 02/20] clk: tegra: periph: add new periph clks and muxes for Tegra210

[Andrew Bresticker]

Hi Rhyland,

On Mon, May 4, 2015 at 9:37 AM, Rhyland Klein  wrote:
> Tegra210 has significant differences in muxes for peripheral clocks.
> One of the most important changes is that pll_m isn't to be used
> as a source for peripherals. Therefore, we need to define the new
> muxes and new clocks to use those muxes for Tegra210 support.
>
> Signed-off-by: Rhyland Klein 

A couple more clocks worth adding here are HSIC_TRK (clock 209),
USB2_TRK (clock 210), and their divider in CLK_SOURCE_USB2_HSIC_TRK.

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

[PATCH v8 3/9] mailbox: Fix up error handling in mbox_request_channel()

[Andrew Bresticker]

From: Benson Leung 

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 
Signed-off-by: Andrew Bresticker 
Acked-by: Suman Anna 
Cc: Jassi Brar 
---
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, _cons, node)
if (mbox->dev->of_node == spec.np) {
chan = mbox->of_xlate(mbox, );
@@ -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(_mutex);
+   return chan;
+   }
+
+   if (chan->cl || !try_module_get(mbox->dev->driver->owner)) {
dev_dbg(dev, "%s: mailbox not free\n", __func__);
mutex_unlock(_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 >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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v8 5/9] mfd: Add driver for NVIDIA Tegra XUSB

[Andrew Bresticker]

Add an MFD driver for the XUSB host complex found on NVIDIA Tegra124
and later SoCs.

Signed-off-by: Andrew Bresticker 
Cc: Samuel Ortiz 
Cc: Lee Jones 
---
Changes from v7:
 - Have child nodes get non-shared memory and interrupts from DT.
 - Use of_platform_populate rather than mfd_add_devices.
 - Get rid of struct tegra_xusb.
New for v7.
---
 drivers/mfd/Kconfig  |  7 +
 drivers/mfd/Makefile |  1 +
 drivers/mfd/tegra-xusb.c | 75 
 3 files changed, 83 insertions(+)
 create mode 100644 drivers/mfd/tegra-xusb.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d5ad04d..61872b4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1430,6 +1430,13 @@ config MFD_STW481X
  in various ST Microelectronics and ST-Ericsson embedded
  Nomadik series.
 
+config MFD_TEGRA_XUSB
+   tristate "NVIDIA Tegra XUSB"
+   depends on ARCH_TEGRA
+   select MFD_CORE
+   help
+ Support for the XUSB complex found on NVIDIA Tegra124 and later SoCs.
+
 menu "Multimedia Capabilities Port drivers"
depends on ARCH_SA1100
 
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 0e5cfeb..7588caf 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -181,6 +181,7 @@ obj-$(CONFIG_MFD_HI6421_PMIC)   += hi6421-pmic-core.o
 obj-$(CONFIG_MFD_DLN2) += dln2.o
 obj-$(CONFIG_MFD_RT5033)   += rt5033.o
 obj-$(CONFIG_MFD_SKY81452) += sky81452.o
+obj-$(CONFIG_MFD_TEGRA_XUSB)   += tegra-xusb.o
 
 intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
diff --git a/drivers/mfd/tegra-xusb.c b/drivers/mfd/tegra-xusb.c
new file mode 100644
index 000..e11fa23
--- /dev/null
+++ b/drivers/mfd/tegra-xusb.c
@@ -0,0 +1,75 @@
+/*
+ * NVIDIA Tegra XUSB MFD driver
+ *
+ * Copyright (C) 2015 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct of_device_id tegra_xusb_of_match[] = {
+   { .compatible = "nvidia,tegra124-xusb", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, tegra_xusb_of_match);
+
+static struct regmap_config tegra_fpci_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+};
+
+static int tegra_xusb_probe(struct platform_device *pdev)
+{
+   struct resource *res;
+   struct regmap *fpci_regs;
+   void __iomem *fpci_base;
+   int ret;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   fpci_base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(fpci_base))
+   return PTR_ERR(fpci_base);
+
+   tegra_fpci_regmap_config.max_register = res->end - res->start - 3;
+   fpci_regs = devm_regmap_init_mmio(>dev, fpci_base,
+ _fpci_regmap_config);
+   if (IS_ERR(fpci_regs)) {
+   ret = PTR_ERR(fpci_regs);
+   dev_err(>dev, "Failed to init regmap: %d\n", ret);
+   return ret;
+   }
+   platform_set_drvdata(pdev, fpci_regs);
+
+   ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, >dev);
+   if (ret) {
+   dev_err(>dev, "Failed to add sub-devices: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static struct platform_driver tegra_xusb_driver = {
+   .probe = tegra_xusb_probe,
+   .driver = {
+   .name = "tegra-xusb",
+   .of_match_table = tegra_xusb_of_match,
+   },
+};
+module_platform_driver(tegra_xusb_driver);
+
+MODULE_DESCRIPTION("NVIDIA Tegra XUSB MFD");
+MODULE_AUTHOR("Andrew Bresticker ");
+MODULE_LICENSE("GPL v2");
-- 
2.2.0.rc0.207.ga3a616c

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

[PATCH v8 6/9] mailbox: Add NVIDIA Tegra XUSB mailbox binding

[Andrew Bresticker]

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 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Jassi Brar 
---
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 000..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,-xusb-mbox",
+   "nvidia,tegra124-xusb-mbox"' where  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 = ;
+
+   #mbox-cells = <0>;
+   };
+
+   usb-host@0,7009 {
+   ...
+   mboxes = <_mbox>;
+   mbox-names = "xusb";
+   ...
+   };
-- 
2.2.0.rc0.207.ga3a616c

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

[PATCH v8 8/9] usb: Add NVIDIA Tegra xHCI controller binding

[Andrew Bresticker]

Add device-tree binding documentation for the xHCI controller present
on Tegra124 and later SoCs.

Signed-off-by: Andrew Bresticker 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Mathias Nyman 
Cc: Greg Kroah-Hartman 
---
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 000..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,-xhci", "nvidia,tegra124-xhci"'
+   where  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 "-" where  is one of "utmi",
+   "hsic", or "usb3" and  is a 0-based index.  On Tegra124, there may
+   be up to 3 UTMI, 2 HSIC, and 2 USB3 PHYs.
+
+Example:
+
+   usb-host@0,7009 {
+   compatible = "nvidia,tegra124-xhci";
+   reg = <0x0 0x7009 0x0 0x8000>,
+ <0x0 0x70099000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_car TEGRA124_CLK_XUSB_HOST>,
+<_car TEGRA124_CLK_XUSB_HOST_SRC>,
+<_car TEGRA124_CLK_XUSB_FALCON_SRC>,
+<_car TEGRA124_CLK_XUSB_SS>,
+<_car TEGRA124_CLK_XUSB_SS_DIV2>,
+<_car TEGRA124_CLK_XUSB_SS_SRC>,
+<_car TEGRA124_CLK_XUSB_HS_SRC>,
+<_car TEGRA124_CLK_XUSB_FS_SRC>,
+<_car TEGRA124_CLK_PLL_U_480M>,
+<_car TEGRA124_CLK_CLK_M>,
+<_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", "

[PATCH v8 9/9] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver

[Andrew Bresticker]

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 
  Bharath Yadav 

Signed-off-by: Andrew Bresticker 
Cc: Mathias Nyman 
Cc: Greg Kroah-Hartman 
---
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 000..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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "xhci.h"
+
+#define TEGRA_XHCI_SS_CLK_HIGH_SPEED 12000
+#define TEGRA_XHCI_SS_CLK_LOW_SPEED 1200
+
+/* 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_ENBIT(2)
+#define XUSB_CFG_4 0x010
+#define  XUSB_BASE_ADDR_SHIFT  15
+#define  XUSB_BASE_ADDR_MASK   0x1
+#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_00x1bc
+
+#define CSB_PAGE_SELECT_MASK   0x7f
+#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 CS

[PATCH v8 7/9] mailbox: Add NVIDIA Tegra XUSB mailbox driver

[Andrew Bresticker]

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 
Cc: Jassi Brar 
---
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 000..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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define XUSB_MBOX_NUM_CHANS2 /* Host + PHY */
+
+#define XUSB_CFG_ARU_MBOX_CMD  0xe4
+#define  MBOX_DEST_FALCBIT(27)
+#define  MBOX_DEST_PME BIT(28)
+#define  MBOX_DEST_SMI BIT(29)
+#define  MBOX_DEST_XHCIBIT(30)
+#define  MBOX_INT_EN   BIT(31)
+#define XUSB_CFG_ARU_MBOX_DATA_IN  0xe8
+#define  CMD_DATA_SHIFT0
+#define  CMD_DATA_MASK 0xff
+#define  CMD_TYPE_SHIFT24
+#define  CMD_TYPE_MASK 0xff
+#define XUSB_CFG_ARU_MBOX_DATA_OUT 0xec
+#define XUSB_CFG_ARU_MBOX_OWNER0xf0
+#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, );
+
+   return val;
+}
+
+static inline void mbox_writel(struct tegra_xusb_mbox *mbox, u32 val,
+   

[PATCH v8 4/9] mfd: Add binding document for NVIDIA Tegra XUSB

[Andrew Bresticker]

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 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Samuel Ortiz 
Cc: Lee Jones 
---
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 000..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,-xusb", "nvidia,tegra124-xusb"'
+   where  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,7009 {
+   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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/