* Re: [PATCH/RFT v2 17/17] ARM: dts: da850: add usb device node
From: David Lechner @ 2016-10-25 0:48 UTC (permalink / raw)
To: ahaslam-rdvid1DuHRBWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
johan-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
nsekhar-l0cyMroinI0, stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
khilman-rdvid1DuHRBWk0Htik3J/w, sshtylyov-hkdhdckH98+B+jHODAdFcQ,
manjunath.goudar-QSEj5FYQhm4dnm+yROfE0A,
broonie-DgEjT+Ai2ygdnm+yROfE0A, abailon-rdvid1DuHRBWk0Htik3J/w
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161024164634.4330-18-ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 10/24/2016 11:46 AM, ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org wrote:
> From: Axel Haslam <ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>
> This adds the usb (ohci) device node for the da850 soc.
> Also it enables it for the lcdk board
>
> Signed-off-by: Axel Haslam <ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 8 ++++++++
> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
> 2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index 7b8ab21..fa91339 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -86,6 +86,14 @@
> };
> };
>
> +&usb_phy {
> + status = "okay";
> +};
> +
> +&usb {
> + status = "okay";
Don't you need to specify a regulator here using the vbus-supply property?
> +};
> +
> &serial2 {
> pinctrl-names = "default";
> pinctrl-0 = <&serial2_rxtx_pins>;
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 33fcdce..ec2cec3 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -381,6 +381,14 @@
> #phy-cells = <1>;
> status = "disabled";
> };
> + usb: usb@0225000 {
Don't need the leading 0 on usb@225000
The alias (usb:) might need to be more specific since there is a second
usb device that will be added later for musb. (The comments in the
previous review only referred to the "usb" in "usb@", not the alias.)
> + compatible = "ti,da830-ohci";
> + reg = <0x225000 0x1000>;
> + interrupts = <59>;
> + phys = <&usb_phy 1>;
> + phy-names = "usb-phy";
> + status = "disabled";
> + };
> gpio: gpio@226000 {
> compatible = "ti,dm6441-gpio";
> gpio-controller;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: Add vendor prefix for Aries Embedded GmbH
From: Marek Vasut @ 2016-10-25 0:47 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqL4NUoonJ+Lw0tbhyKk0xM4ke65BNQ1VNndfUrqLZsgLw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10/25/2016 02:14 AM, Rob Herring wrote:
> On Mon, Oct 24, 2016 at 6:38 AM, Marek Vasut <marex-ynQEQJNshbs@public.gmane.org> wrote:
>> On 09/19/2016 11:38 PM, Marek Vasut wrote:
>>> Add vendor prefix for Aries Embedded GmbH
>>> http://www.aries-embedded.de/
>>>
>>> Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
>>> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>
>> Hi, bump ?
>
> Looks fine, but please resend to the DT list so that patchwork picks
> this up and it will be in my queue.
OK, done.
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] of: Add vendor prefix for Aries Embedded GmbH
From: Marek Vasut @ 2016-10-25 0:46 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA; +Cc: Marek Vasut, Rob Herring
Add vendor prefix for Aries Embedded GmbH
http://www.aries-embedded.de/
Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index e2fa9b3..3f1e7c8 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -27,6 +27,7 @@ analogix Analogix Semiconductor, Inc.
apm Applied Micro Circuits Corporation (APM)
aptina Aptina Imaging
arasan Arasan Chip Systems
+aries Aries Embedded GmbH
arm ARM Ltd.
armadeus ARMadeus Systems SARL
arrow Arrow Electronics
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH/RFT v2 11/17] USB: OHCI: make ohci-da8xx a separate driver
From: David Lechner @ 2016-10-25 0:38 UTC (permalink / raw)
To: ahaslam-rdvid1DuHRBWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
johan-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
nsekhar-l0cyMroinI0, stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
khilman-rdvid1DuHRBWk0Htik3J/w, sshtylyov-hkdhdckH98+B+jHODAdFcQ,
manjunath.goudar-QSEj5FYQhm4dnm+yROfE0A,
broonie-DgEjT+Ai2ygdnm+yROfE0A, abailon-rdvid1DuHRBWk0Htik3J/w
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161024164634.4330-12-ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 10/24/2016 11:46 AM, ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org wrote:
> From: Manjunath Goudar <manjunath.goudar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Separate the Davinci OHCI host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.
No need for comment about kernel 3.11.
>
> Signed-off-by: Manjunath Goudar <manjunath.goudar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/usb/host/Kconfig | 2 +-
> drivers/usb/host/Makefile | 1 +
> drivers/usb/host/ohci-da8xx.c | 185 +++++++++++++++++-------------------------
> drivers/usb/host/ohci-hcd.c | 18 ----
> 4 files changed, 76 insertions(+), 130 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 83b6cec..642c6fe8 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -479,7 +479,7 @@ config USB_OHCI_HCD_OMAP3
> OMAP3 and later chips.
>
> config USB_OHCI_HCD_DAVINCI
> - bool "OHCI support for TI DaVinci DA8xx"
> + tristate "OHCI support for TI DaVinci DA8xx"
> depends on ARCH_DAVINCI_DA8XX
> depends on USB_OHCI_HCD=y
Need to drop the "=y" here, otherwise you still can't compile this as a
module.
> select PHY_DA8XX_USB
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 6ef785b..2644537 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_USB_OHCI_HCD_AT91) += ohci-at91.o
> obj-$(CONFIG_USB_OHCI_HCD_S3C2410) += ohci-s3c2410.o
> obj-$(CONFIG_USB_OHCI_HCD_LPC32XX) += ohci-nxp.o
> obj-$(CONFIG_USB_OHCI_HCD_PXA27X) += ohci-pxa27x.o
> +obj-$(CONFIG_USB_OHCI_HCD_DAVINCI) += ohci-da8xx.o
>
> obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
> obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
> index e98066d..5585d9e 100644
> --- a/drivers/usb/host/ohci-da8xx.c
> +++ b/drivers/usb/host/ohci-da8xx.c
> @@ -11,16 +11,31 @@
> * kind, whether express or implied.
> */
>
> +#include <linux/clk.h>
> +#include <linux/io.h>
> #include <linux/interrupt.h>
> #include <linux/jiffies.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> #include <linux/platform_device.h>
> -#include <linux/clk.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_data/usb-davinci.h>
> +#include <linux/platform_device.h>
linux/platform_device.h is listed twice
> +#include <linux/usb.h>
> +#include <linux/usb/hcd.h>
> +#include <asm/unaligned.h>
>
> -#ifndef CONFIG_ARCH_DAVINCI_DA8XX
> -#error "This file is DA8xx bus glue. Define CONFIG_ARCH_DAVINCI_DA8XX."
> -#endif
> +#include "ohci.h"
> +
> +#define DRIVER_DESC "OHCI DA8XX driver"
> +
> +static const char hcd_name[] = "ohci-da8xx";
why static const char instead of #define? This is only used one time in
a pr_info, so it seems kind of pointless anyway.
> +
> +static struct hc_driver __read_mostly ohci_da8xx_hc_driver;
> +
> +static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq,
> + u16 wValue, u16 wIndex, char *buf, u16 wLength);
> +static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
>
> static struct clk *usb11_clk;
> static struct phy *usb11_phy;
> @@ -73,7 +88,7 @@ static void ohci_da8xx_ocic_handler(struct da8xx_ohci_root_hub *hub)
> hub->set_power(0);
> }
>
> -static int ohci_da8xx_init(struct usb_hcd *hcd)
> +static int ohci_da8xx_reset(struct usb_hcd *hcd)
> {
> struct device *dev = hcd->self.controller;
> struct da8xx_ohci_root_hub *hub = dev_get_platdata(dev);
> @@ -93,7 +108,7 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
> */
> ohci->num_ports = 1;
>
> - result = ohci_init(ohci);
> + result = ohci_setup(hcd);
> if (result < 0) {
> ohci_da8xx_disable();
> return result;
> @@ -121,30 +136,12 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
> return result;
> }
>
> -static void ohci_da8xx_stop(struct usb_hcd *hcd)
> -{
> - ohci_stop(hcd);
> - ohci_da8xx_disable();
> -}
> -
> -static int ohci_da8xx_start(struct usb_hcd *hcd)
> -{
> - struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> - int result;
> -
> - result = ohci_run(ohci);
> - if (result < 0)
> - ohci_da8xx_stop(hcd);
> -
> - return result;
> -}
> -
> /*
> * Update the status data from the hub with the over-current indicator change.
> */
> static int ohci_da8xx_hub_status_data(struct usb_hcd *hcd, char *buf)
> {
> - int length = ohci_hub_status_data(hcd, buf);
> + int length = orig_ohci_hub_status_data(hcd, buf);
>
> /* See if we have OCIC flag set */
> if (ocic_flag) {
> @@ -226,66 +223,13 @@ static int ohci_da8xx_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
> }
> }
>
> - return ohci_hub_control(hcd, typeReq, wValue, wIndex, buf, wLength);
> + return orig_ohci_hub_control(hcd, typeReq, wValue,
> + wIndex, buf, wLength);
> }
>
> -static const struct hc_driver ohci_da8xx_hc_driver = {
> - .description = hcd_name,
> - .product_desc = "DA8xx OHCI",
> - .hcd_priv_size = sizeof(struct ohci_hcd),
> -
> - /*
> - * generic hardware linkage
> - */
> - .irq = ohci_irq,
> - .flags = HCD_USB11 | HCD_MEMORY,
> -
> - /*
> - * basic lifecycle operations
> - */
> - .reset = ohci_da8xx_init,
> - .start = ohci_da8xx_start,
> - .stop = ohci_da8xx_stop,
> - .shutdown = ohci_shutdown,
> -
> - /*
> - * managing i/o requests and associated device resources
> - */
> - .urb_enqueue = ohci_urb_enqueue,
> - .urb_dequeue = ohci_urb_dequeue,
> - .endpoint_disable = ohci_endpoint_disable,
> -
> - /*
> - * scheduling support
> - */
> - .get_frame_number = ohci_get_frame,
> -
> - /*
> - * root hub support
> - */
> - .hub_status_data = ohci_da8xx_hub_status_data,
> - .hub_control = ohci_da8xx_hub_control,
> -
> -#ifdef CONFIG_PM
> - .bus_suspend = ohci_bus_suspend,
> - .bus_resume = ohci_bus_resume,
> -#endif
> - .start_port_reset = ohci_start_port_reset,
> -};
> -
> /*-------------------------------------------------------------------------*/
>
> -
> -/**
> - * usb_hcd_da8xx_probe - initialize DA8xx-based HCDs
> - * Context: !in_interrupt()
> - *
> - * Allocates basic resources for this USB host controller, and
> - * then invokes the start() method for the HCD associated with it
> - * through the hotplug entry's driver_data.
> - */
> -static int usb_hcd_da8xx_probe(const struct hc_driver *driver,
> - struct platform_device *pdev)
> +static int ohci_da8xx_probe(struct platform_device *pdev)
> {
> struct da8xx_ohci_root_hub *hub = dev_get_platdata(&pdev->dev);
> struct usb_hcd *hcd;
> @@ -295,6 +239,11 @@ static int usb_hcd_da8xx_probe(const struct hc_driver *driver,
> if (hub == NULL)
> return -ENODEV;
>
> + hcd = usb_create_hcd(&ohci_da8xx_hc_driver, &pdev->dev,
> + dev_name(&pdev->dev));
> + if (!hcd)
> + return -ENOMEM;
> +
Won't this leak hdc if there is an error later?
> usb11_clk = devm_clk_get(&pdev->dev, "usb11");
> if (IS_ERR(usb11_clk)) {
> if (PTR_ERR(usb11_clk) != -EPROBE_DEFER)
> @@ -309,9 +258,6 @@ static int usb_hcd_da8xx_probe(const struct hc_driver *driver,
> return PTR_ERR(usb11_phy);
> }
>
> - hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
> - if (!hcd)
> - return -ENOMEM;
Why does this need to be moved?
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> hcd->regs = devm_ioremap_resource(&pdev->dev, mem);
> @@ -323,13 +269,12 @@ static int usb_hcd_da8xx_probe(const struct hc_driver *driver,
> hcd->rsrc_start = mem->start;
> hcd->rsrc_len = resource_size(mem);
>
> - ohci_hcd_init(hcd_to_ohci(hcd));
> -
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> error = -ENODEV;
> goto err;
> }
> +
> error = usb_add_hcd(hcd, irq, 0);
> if (error)
> goto err;
> @@ -348,35 +293,14 @@ static int usb_hcd_da8xx_probe(const struct hc_driver *driver,
> return error;
> }
>
> -/**
> - * usb_hcd_da8xx_remove - shutdown processing for DA8xx-based HCDs
> - * @dev: USB Host Controller being removed
> - * Context: !in_interrupt()
> - *
> - * Reverses the effect of usb_hcd_da8xx_probe(), first invoking
> - * the HCD's stop() method. It is always called from a thread
> - * context, normally "rmmod", "apmd", or something similar.
> - */
> -static inline void
> -usb_hcd_da8xx_remove(struct usb_hcd *hcd, struct platform_device *pdev)
> +static int ohci_da8xx_remove(struct platform_device *pdev)
> {
> + struct usb_hcd *hcd = platform_get_drvdata(pdev);
> struct da8xx_ohci_root_hub *hub = dev_get_platdata(&pdev->dev);
>
> hub->ocic_notify(NULL);
> usb_remove_hcd(hcd);
> usb_put_hcd(hcd);
> -}
> -
> -static int ohci_hcd_da8xx_drv_probe(struct platform_device *dev)
> -{
> - return usb_hcd_da8xx_probe(&ohci_da8xx_hc_driver, dev);
> -}
> -
> -static int ohci_hcd_da8xx_drv_remove(struct platform_device *dev)
> -{
> - struct usb_hcd *hcd = platform_get_drvdata(dev);
> -
> - usb_hcd_da8xx_remove(hcd, dev);
>
> return 0;
> }
> @@ -426,12 +350,16 @@ static int ohci_da8xx_resume(struct platform_device *dev)
> }
> #endif
>
> +static const struct ohci_driver_overrides da8xx_overrides __initconst = {
> + .reset = ohci_da8xx_reset
> +};
> +
> /*
> * Driver definition to register with platform structure.
> */
> static struct platform_driver ohci_hcd_da8xx_driver = {
> - .probe = ohci_hcd_da8xx_drv_probe,
> - .remove = ohci_hcd_da8xx_drv_remove,
> + .probe = ohci_da8xx_probe,
> + .remove = ohci_da8xx_remove,
> .shutdown = usb_hcd_platform_shutdown,
> #ifdef CONFIG_PM
> .suspend = ohci_da8xx_suspend,
It would probably be a good idea to change the driver name here.
Currently it is "ohci". Although this would be better in a separate
patch if the name has to be changed to match in other files as well.
> @@ -442,4 +370,39 @@ static int ohci_da8xx_resume(struct platform_device *dev)
> },
> };
>
> +static int __init ohci_da8xx_init(void)
> +{
> +
> + if (usb_disabled())
> + return -ENODEV;
> +
> + pr_info("%s: " DRIVER_DESC "\n", hcd_name);
> + ohci_init_driver(&ohci_da8xx_hc_driver, &da8xx_overrides);
> +
> + /*
> + * The Davinci da8xx HW has some unusual quirks, which require
> + * da8xx-specific workarounds. We override certain hc_driver
> + * functions here to achieve that. We explicitly do not enhance
> + * ohci_driver_overrides to allow this more easily, since this
> + * is an unusual case, and we don't want to encourage others to
> + * override these functions by making it too easy.
> + */
> +
> + orig_ohci_hub_control = ohci_da8xx_hc_driver.hub_control;
> + orig_ohci_hub_status_data = ohci_da8xx_hc_driver.hub_status_data;
> +
> + ohci_da8xx_hc_driver.hub_status_data = ohci_da8xx_hub_status_data;
> + ohci_da8xx_hc_driver.hub_control = ohci_da8xx_hub_control;
> +
> + return platform_driver_register(&ohci_hcd_da8xx_driver);
> +}
> +module_init(ohci_da8xx_init);
> +
> +static void __exit ohci_da8xx_cleanup(void)
ohci_da8xx_exit would be a better name
> +{
> + platform_driver_unregister(&ohci_hcd_da8xx_driver);
> +}
> +module_exit(ohci_da8xx_cleanup);
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_LICENSE("GPL");
> MODULE_ALIAS("platform:ohci");
this will need to be changed too if you change the driver name
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index 1700908..8de174a 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -1219,11 +1219,6 @@ void ohci_init_driver(struct hc_driver *drv,
> #define SA1111_DRIVER ohci_hcd_sa1111_driver
> #endif
>
> -#ifdef CONFIG_USB_OHCI_HCD_DAVINCI
> -#include "ohci-da8xx.c"
> -#define DAVINCI_PLATFORM_DRIVER ohci_hcd_da8xx_driver
> -#endif
> -
> #ifdef CONFIG_USB_OHCI_HCD_PPC_OF
> #include "ohci-ppc-of.c"
> #define OF_PLATFORM_DRIVER ohci_hcd_ppc_of_driver
> @@ -1303,19 +1298,9 @@ static int __init ohci_hcd_mod_init(void)
> goto error_tmio;
> #endif
>
> -#ifdef DAVINCI_PLATFORM_DRIVER
> - retval = platform_driver_register(&DAVINCI_PLATFORM_DRIVER);
> - if (retval < 0)
> - goto error_davinci;
> -#endif
> -
> return retval;
>
> /* Error path */
> -#ifdef DAVINCI_PLATFORM_DRIVER
> - platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
> - error_davinci:
> -#endif
> #ifdef TMIO_OHCI_DRIVER
> platform_driver_unregister(&TMIO_OHCI_DRIVER);
> error_tmio:
> @@ -1351,9 +1336,6 @@ static int __init ohci_hcd_mod_init(void)
>
> static void __exit ohci_hcd_mod_exit(void)
> {
> -#ifdef DAVINCI_PLATFORM_DRIVER
> - platform_driver_unregister(&DAVINCI_PLATFORM_DRIVER);
> -#endif
> #ifdef TMIO_OHCI_DRIVER
> platform_driver_unregister(&TMIO_OHCI_DRIVER);
> #endif
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 2/3] of/pci: Add helper function to parse max-link-speed from dt
From: Rob Herring @ 2016-10-25 0:17 UTC (permalink / raw)
To: Shawn Lin
Cc: Bjorn Helgaas, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Wenrui Li, Brian Norris,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1476755110-22647-2-git-send-email-shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Mon, Oct 17, 2016 at 8:45 PM, Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> This new helper function could be used by host drivers to
> get the limitaion of max link speed provided by dt. If the
> property isn't assigned or is invalid, it will return -EINVAL
> to the caller.
>
> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: Add vendor prefix for Aries Embedded GmbH
From: Rob Herring @ 2016-10-25 0:14 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <ae228088-b8bc-7445-f621-52d20850d49e-ynQEQJNshbs@public.gmane.org>
On Mon, Oct 24, 2016 at 6:38 AM, Marek Vasut <marex-ynQEQJNshbs@public.gmane.org> wrote:
> On 09/19/2016 11:38 PM, Marek Vasut wrote:
>> Add vendor prefix for Aries Embedded GmbH
>> http://www.aries-embedded.de/
>>
>> Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
>> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Hi, bump ?
Looks fine, but please resend to the DT list so that patchwork picks
this up and it will be in my queue.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 1/8] PM / OPP: Reword binding supporting multiple regulators per device
From: Stephen Boyd @ 2016-10-24 22:48 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, nm-l0cyMroinI0, Viresh Kumar,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Vincent Guittot,
robh-DgEjT+Ai2ygdnm+yROfE0A, d-gerlach-l0cyMroinI0,
broonie-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <891ef8705e13dff331a3135647f4c18f88402a12.1476952750.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 10/20, Viresh Kumar wrote:
> On certain platforms (like TI), DVFS for a single device (CPU) requires
> configuring multiple power supplies.
>
> The OPP bindings already contains binding and example to explain this
> case, but it isn't sufficient. For example, there is no way for the code
> parsing these bindings to know which voltage values belong to which
> power supply. Also its not possible to know the order in which the
> supplies need to be configured while switching OPPs.
>
> This patch tries to clarify on those details and does some minor changes
> as well.
>
> Note that the bindings do not specify the order in which the regulators
> need to be programmed and the order in which the entries are added for
> the supplies.
>
> The user of the bindings (like the kernel) shall know these details
> already and the DT is responsible to supply only the readings for the
> regulators.
>
> Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
Reviewed-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 0/3] Add support for Broadcom OTP controller
From: Markus Mayer @ 2016-10-24 22:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Florian Fainelli, Jonathan Richardson, Srinivas Kandagatla,
Maxime Ripard, linux-arm-kernel@lists.infradead.org, lkml,
devicetree@vger.kernel.org, Mark Rutland, Rob Herring,
Scott Branden, Ray Jui, BCM Kernel Feedback
In-Reply-To: <CA+55aFxeu9YKb=zAba8MVRgxmJoQJ8W6u3NNJv7rP6mwxj+nVA@mail.gmail.com>
FWIW, this thread ends up in the spam folder for me also on my private
e-mail account. And it's not the only Broadcom thread. Quite a few
Broadcom e-mails end up there. The thread was sent to me via
infradead.org. My private e-mail is also hosted by Gmail.
I get this:
SPF: PASS with IP 2001:1868:205:0:0:0:0:9 Learn more
DKIM: NEUTRAL with domain null Learn more
DMARC: FAIL Learn more
So, it's not DKIM for me, but DMARC that's failing.
The actual headers:
Received: from bombadil.infradead.org (bombadil.infradead.org.
[2001:1868:205::9])
by mx.google.com with ESMTPS id
r127si16944054pgr.251.2016.10.24.12.13.37
for <mmayer at mmayer.net>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 24 Oct 2016 12:13:37 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of
linux-arm-kernel-bounces+mmayer=mmayer.net@lists.infradead.org
designates 2001:1868:205::9 as permitted sender)
client-ip=2001:1868:205::9;
Authentication-Results: mx.google.com;
dkim=neutral (body hash did not verify) header.i=@broadcom.com;
spf=pass (google.com: best guess record for domain of
linux-arm-kernel-bounces+mmayer=mmayer.net@lists.infradead.org
designates 2001:1868:205::9 as permitted sender)
smtp.mailfrom=linux-arm-kernel-bounces+mmayer=mmayer.net@lists.infradead.org;
dmarc=fail (p=QUARANTINE dis=NONE) header.from=broadcom.com
Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by
bombadil.infradead.org
Regards,
-Markus
^ permalink raw reply
* Re: [v2 2/2] fpga: Add support for Lattice iCE40 FPGAs
From: Moritz Fischer @ 2016-10-24 22:28 UTC (permalink / raw)
To: atull
Cc: Joel Holdsworth, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, mark.rutland-5wv7dgnIgG8,
pawel.moll-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.02.1610241615280.14525@linuxheads99>
Hi Joel,
Ha, finally someone beat me to submitting my driver,
I had an ugly hack to bitbang the SPI since I couldn't figure
out a good way to assert the creset after the CS.
Thanks!
On Mon, Oct 24, 2016 at 04:55:43PM -0500, atull wrote:
> On Mon, 24 Oct 2016, Joel Holdsworth wrote:
>
> > The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
> > and very regular structure, designed for low-cost, high-volume consumer
> > and system applications.
> >
> > This patch adds support to the FPGA manager for configuring the SRAM of
> > iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
> > UltraPlus devices, through slave SPI.
> >
> > The iCE40 family is notable because it is the first FPGA family to have
> > complete reverse engineered bit-stream documentation for the iCE40LP and
> > iCE40HX devices. Furthermore, there is now a Free Software Verilog
> > synthesis tool-chain: the "IceStorm" tool-chain.
> >
> > This project is the work of Clifford Wolf, who is the maintainer of
> > Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
> > contributions from "Cotton Seed", the main author of "arachne-pnr"; a
> > place-and-route tool for iCE40 FPGAs.
> >
> > Having a Free Software synthesis tool-chain offers interesting
> > opportunities for embedded devices that are able reconfigure themselves
> > with open firmware that is generated on the device itself. For example
> > a mobile device might have an application processer with an iCE40 FPGA
processer ? :)
> > attached, which implements slave devices, or through which the processor
> > communicates with other devices through the FPGA fabric.
> >
> > A kernel driver for the iCE40 is useful, because in some cases, the FPGA
> > may need to be configured before other devices can be accessed.
> >
> > An example of such a device is the icoBOARD; a RaspberryPI HAT which
> > features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
> > Digilent-compatible PMOD modules. A PMOD module may contain a device
> > with which the kernel communicates, via the FPGA.
> > ---
> > .../bindings/fpga/lattice-ice40-fpga-mgr.txt | 23 +++
> > drivers/fpga/Kconfig | 6 +
> > drivers/fpga/Makefile | 1 +
> > drivers/fpga/ice40spi.c | 212 +++++++++++++++++++++
> > 4 files changed, 242 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> > create mode 100644 drivers/fpga/ice40spi.c
> >
>
> Hi Joel,
>
> Thanks for submitting your driver!
>
> I didn't see any huge problems, just minor things below...
>
> Alan
>
> > diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> > new file mode 100644
> > index 0000000..b253ac8
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> > @@ -0,0 +1,23 @@
> > +Lattice iCE40 FPGA Manager
> > +
> > +Required properties:
> > +- compatible: should contain "lattice,ice40-fpga-mgr"
> > +- reg: SPI chip select
> > +- spi-max-frequency: Maximum SPI frequency (>=1000000, <=25000000)
> > +- cdone-gpios: GPIO connected to CDONE pin
> > +- creset_b-gpios: GPIO connected to CRESET_B pin. Note that CRESET_B is
> > + treated as an active-low output because the signal is
> > + treated as an enable signal, rather than a reset. This
> > + is necessary because the FPGA will enter Master SPI
> > + mode and drive SCK with a clock signal, potentially
> > + jamming other devices on the bus, unless CRESET_B is
> > + held high until the firmware is loaded.
>
> Both could be singular ...-gpio since only one gpio should be specified.
>
> > +
> > +Example:
> > + ice40: ice40@0 {
> > + compatible = "lattice,ice40-fpga-mgr";
> > + reg = <0>;
> > + spi-max-frequency = <1000000>;
> > + cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
> > + creset_b-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
> > + };
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index d614102..85ff429 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -13,6 +13,12 @@ config FPGA
> >
> > if FPGA
> >
> > +config FPGA_MGR_ICE40_SPI
> > + tristate "Lattice iCE40 SPI"
> > + depends on SPI
> > + help
> > + FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
> > +
> > config FPGA_MGR_SOCFPGA
> > tristate "Altera SOCFPGA FPGA Manager"
> > depends on ARCH_SOCFPGA
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index 8d83fc6..6c809cc 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -6,5 +6,6 @@
> > obj-$(CONFIG_FPGA) += fpga-mgr.o
> >
> > # FPGA Manager Drivers
> > +obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40spi.o
>
> Could this be ice40-spi.c?
>
> > obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> > obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> > diff --git a/drivers/fpga/ice40spi.c b/drivers/fpga/ice40spi.c
> > new file mode 100644
> > index 0000000..ab5ee86
> > --- /dev/null
> > +++ b/drivers/fpga/ice40spi.c
> > @@ -0,0 +1,212 @@
> > +/*
> > + * FPGA Manager Driver for Lattice iCE40.
> > + *
> > + * Copyright (c) 2016 Joel Holdsworth
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; version 2 of the License.
> > + *
> > + * This driver adds support to the FPGA manager for configuring the SRAM of
> > + * Lattice iCE40 FPGAs through slave SPI.
> > + */
> > +
> > +#include <linux/delay.h>
> > +#include <linux/fpga/fpga-mgr.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/of_gpio.h>
> > +#include <linux/spi/spi.h>
> > +
> > +struct ice40_fpga_priv {
> > + struct spi_device *dev;
> > + struct gpio_desc *creset_b;
> > + struct gpio_desc *cdone;
> > + enum fpga_mgr_states state;
>
> state is never used. You could just remove it.
>
> > +};
> > +
> > +static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
> > +{
> > + return mgr->state;
>
> fpga_mgr_register will call your ice40_fpga_ops_state() function to
> get its initial state. That's the only time this gets called. So
> you could return one of the enum fpga_mgr_states here. I'm guessing
> FPGA_MGR_STATE_UNKNOWN. I'm realizing that there will be devices
> that don't really know what initial state they are in; I could have
> removed the absolute requirement for the state in the fpga_manager_ops
> and assumed FPGA_MGR_STATE_UNKNOWN unless a low level driver provided
> a state function. But for now, just return FPGA_MGR_STATE_UNKNOWN
> here unless you have a way of knowing what state you are in when
> the driver is probed.
You could potentially also just look at the CDONE GPIO.
>
> > +}
> > +
> > +static void set_cs(struct spi_device *spi, bool enable)
> > +{
> > + if (gpio_is_valid(spi->cs_gpio))
> > + gpio_set_value(spi->cs_gpio, !enable);
> > + else if (spi->master->set_cs)
> > + spi->master->set_cs(spi, !enable);
> > +}
> > +
> > +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> > + const char *buf, size_t count)
>
> Checkpatch complains about alignment here.
>
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > + struct spi_device *dev = priv->dev;
> > + int ret;
> > +
> > + if ((flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> > + dev_err(&dev->dev,
> > + "Partial reconfiguration is not supported\n");
> > + return -EINVAL;
Maybe -ENOTSUPP ?
> > + }
> > +
> > + /* Lock the bus, assert SS_B and CRESET_B */
> > + ret = spi_bus_lock(dev->master);
> > + if (ret) {
> > + dev_err(&dev->dev, "Failed to lock SPI bus, ret: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + set_cs(dev, 1);
> > + gpiod_set_value(priv->creset_b, 1);
> > +
> > + /* Delay for >200ns */
> > + udelay(1);
Named constant?
> > +
> > + /* Come out of reset */
> > + gpiod_set_value(priv->creset_b, 0);
> > +
> > + /* Check CDONE is de-asserted i.e. the FPGA is reset */
> > + if (gpiod_get_value(priv->cdone)) {
> > + dev_err(&dev->dev, "Device reset failed, CDONE is asserted\n");
> > + ret = -EIO;
> > + }
> > +
> > + /* Wait for the housekeeping to complete */
> > + if (!ret)
> > + udelay(1200);
Named constant?
>
> Would usleep_range work for you since it's more than 10uSec
> (Documentation/timers/timers-howto.txt)?
>
> > +
> > + /* Release the SS_B */
> > + set_cs(dev, 0);
> > + spi_bus_unlock(dev->master);
> > +
> > + return ret;
> > +}
> > +
> > +static int ice40_fpga_ops_write(struct fpga_manager *mgr,
> > + const char *buf, size_t count)
>
> Checkpatch complains about alignment here also.
>
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > + struct spi_device *dev = priv->dev;
> > + int ret;
> > +
> > + ret = spi_write(dev, buf, count);
> > + if (ret)
> > + dev_err(&dev->dev, "Error sending SPI data, ret: %d\n", ret);
> > +
> > + return ret;
> > +}
> > +
> > +static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr, u32 flags)
> > +{
> > + struct ice40_fpga_priv *priv = mgr->priv;
> > + struct spi_device *dev = priv->dev;
> > + int ret = 0;
> > +
> > + /* Check CDONE is asserted */
> > + if (!gpiod_get_value(priv->cdone)) {
> > + dev_err(&dev->dev,
> > + "CDONE was not asserted after firmware transfer\n");
> > + return -EIO;
> > + }
> > +
> > + /* Send >49-bits of zero-padding to activate the firmware */
> > + ret = spi_write(dev, NULL, 7);
Could make that a named constant ...
> > + if (ret) {
> > + dev_err(&dev->dev, "Error sending zero padding, ret: %d\n",
> > + ret);
> > + return ret;
> > + }
> > +
> > + /* Success */
> > + return 0;
> > +}
> > +
> > +static const struct fpga_manager_ops ice40_fpga_ops = {
> > + .state = ice40_fpga_ops_state,
> > + .write_init = ice40_fpga_ops_write_init,
> > + .write = ice40_fpga_ops_write,
> > + .write_complete = ice40_fpga_ops_write_complete,
> > +};
> > +
> > +static int ice40_fpga_probe(struct spi_device *spi)
> > +{
> > + struct device *dev = &spi->dev;
> > + struct device_node *np = spi->dev.of_node;
> > + struct ice40_fpga_priv *priv;
> > + int ret;
> > +
> > + if (!np) {
> > + dev_err(dev, "No Device Tree entry\n");
> > + return -EINVAL;
> > + }
> > +
> > + priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->dev = spi;
> > +
> > + /* Check board setup data. */
> > + if (spi->max_speed_hz > 25000000) {
> > + dev_err(dev, "speed is too high\n");
> > + return -EINVAL;
> > + } else if (spi->mode & SPI_CPHA) {
> > + dev_err(dev, "bad mode\n");
> > + return -EINVAL;
> > + }
> > +
> > + /* Set up the GPIOs */
> > + priv->cdone = devm_gpiod_get(dev, "cdone", GPIOD_IN);
> > + if (IS_ERR(priv->cdone)) {
> > + dev_err(dev, "Failed to get CDONE GPIO: %ld\n",
> > + PTR_ERR(priv->cdone));
> > + return ret;
> > + }
> > +
> > + priv->creset_b = devm_gpiod_get(dev, "creset_b", GPIOD_OUT_HIGH);
> > + if (IS_ERR(priv->creset_b)) {
> > + dev_err(dev, "Failed to get CRESET_B GPIO: %ld\n",
> > + PTR_ERR(priv->creset_b));
> > + return ret;
> > + }
> > +
> > + /* Register with the FPGA manager */
> > + ret = fpga_mgr_register(dev, "Lattice iCE40 FPGA Manager",
> > + &ice40_fpga_ops, priv);
> > + if (ret) {
> > + dev_err(dev, "unable to register FPGA manager");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int ice40_fpga_remove(struct spi_device *spi)
> > +{
> > + fpga_mgr_unregister(&spi->dev);
> > + return 0;
> > +}
> > +
>
> #ifdef CONFIG_OF
> > +static const struct of_device_id ice40_fpga_of_match[] = {
> > + { .compatible = "lattice,ice40-fpga-mgr", },
> > + {},
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, ice40_fpga_of_match);
> #endif
>
> > +
> > +static struct spi_driver ice40_fpga_driver = {
> > + .probe = ice40_fpga_probe,
> > + .remove = ice40_fpga_remove,
> > + .driver = {
> > + .name = "ice40spi",
> > + .owner = THIS_MODULE,
>
> It's not necessary to specify .owner anymore.
>
> > + .of_match_table = of_match_ptr(ice40_fpga_of_match),
> > + },
> > +};
> > +
> > +module_spi_driver(ice40_fpga_driver);
> > +
> > +MODULE_AUTHOR("Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>");
> > +MODULE_DESCRIPTION("Lattice iCE40 FPGA Manager");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 2.7.4
> >
> >
Cheers,
Moritz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 5/9] dt-bindings: Update binding for PM domain idle states
From: Lina Iyer @ 2016-10-24 22:21 UTC (permalink / raw)
To: ulf.hansson, khilman, rjw, linux-pm, linux-arm-kernel
Cc: andy.gross, sboyd, linux-arm-msm, brendan.jackman,
lorenzo.pieralisi, sudeep.holla, Juri.Lelli, Lina Iyer,
devicetree, Marc Titinger
In-Reply-To: <1477347668-41901-1-git-send-email-lina.iyer@linaro.org>
Update DT bindings to describe idle states of PM domains.
This patch is based on the original patch by Marc Titinger.
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
.../devicetree/bindings/power/power_domain.txt | 44 ++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index 025b5e7..3c926b5 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -29,6 +29,16 @@ Optional properties:
specified by this binding. More details about power domain specifier are
available in the next section.
+- domain-idle-states : A phandle of an idle-state that shall be soaked into a
+ generic domain power state. The idle state definitions must be
+ compatible with "domain-idle-state" as well as
+ "arm,idle-state" as defined in [1].
+ The domain-idle-state property reflects the idle state of this PM domain and
+ not the idle states of the devices or sub-domains in the PM domain. Devices
+ and sub-domains have their own idle-states independent of the parent
+ domain's idle states. In the absence of this property, the domain would be
+ considered as capable of being powered-on or powered-off.
+
Example:
power: power-controller@12340000 {
@@ -59,6 +69,38 @@ The nodes above define two power controllers: 'parent' and 'child'.
Domains created by the 'child' power controller are subdomains of '0' power
domain provided by the 'parent' power controller.
+Example 3:
+ parent: power-controller@12340000 {
+ compatible = "foo,power-controller";
+ reg = <0x12340000 0x1000>;
+ #power-domain-cells = <0>;
+ domain-idle-states = <&DOMAIN_RET>, <&DOMAIN_PWR_DN>;
+ };
+
+ child: power-controller@12341000 {
+ compatible = "foo,power-controller";
+ reg = <0x12341000 0x1000>;
+ power-domains = <&parent 0>;
+ #power-domain-cells = <0>;
+ domain-idle-states = <&DOMAIN_PWR_DN>;
+ };
+
+ DOMAIN_RET: state@0 {
+ compatible = "domain-idle-state", "arm,idle-state";
+ reg = <0x0>;
+ entry-latency-us = <1000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <10000>;
+ };
+
+ DOMAIN_PWR_DN: state@1 {
+ compatible = "domain-idle-state", "arm,idle-state";
+ reg = <0x1>;
+ entry-latency-us = <5000>;
+ exit-latency-us = <8000>;
+ min-residency-us = <7000>;
+ };
+
==PM domain consumers==
Required properties:
@@ -76,3 +118,5 @@ Example:
The node above defines a typical PM domain consumer device, which is located
inside a PM domain with index 0 of a power controller represented by a node
with the label "power".
+
+[1]. Documentation/devicetree/bindings/arm/idle-states.txt
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/9] dt-bindings: add domain-idle-state compatible to arm,idle-state
From: Lina Iyer @ 2016-10-24 22:21 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
khilman-DgEjT+Ai2ygdnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: andy.gross-QSEj5FYQhm4dnm+yROfE0A, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, brendan.jackman-5wv7dgnIgG8,
lorenzo.pieralisi-5wv7dgnIgG8, sudeep.holla-5wv7dgnIgG8,
Juri.Lelli-5wv7dgnIgG8, Lina Iyer,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring
In-Reply-To: <1477347668-41901-1-git-send-email-lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
CPU's idle states are defined by the arm,idle-state compatible flag. See
[1]. PM domains that can contains devices and other domains also has
similar definition for its idle state. Reuse the definition of
arm,idle-state for PM domains by allowing an addition compatible string
("domain-idle-state") to denote idle states that are specific to PM
Domains.
[1]. Documentation/devicetree/bindings/arm/idle-states.txt
Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Suggested-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Signed-off-by: Lina Iyer <lina.iyer-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/arm/idle-states.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
index b8e41c1..4b0ff59 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -271,6 +271,9 @@ follows:
Usage: Required
Value type: <stringlist>
Definition: Must be "arm,idle-state".
+ Additionally, nodes that are used to describe a
+ idle-state of PM domain must also define
+ "domain-idle-state" as compatible string.
- local-timer-stop
Usage: See definition
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [v2 2/2] fpga: Add support for Lattice iCE40 FPGAs
From: atull @ 2016-10-24 21:55 UTC (permalink / raw)
To: Joel Holdsworth
Cc: ijc+devicetree, galak, mark.rutland, moritz.fischer, pawel.moll,
robh+dt, devicetree, linux-kernel
In-Reply-To: <1477283989-21947-2-git-send-email-joel@airwebreathe.org.uk>
On Mon, 24 Oct 2016, Joel Holdsworth wrote:
> The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
> and very regular structure, designed for low-cost, high-volume consumer
> and system applications.
>
> This patch adds support to the FPGA manager for configuring the SRAM of
> iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
> UltraPlus devices, through slave SPI.
>
> The iCE40 family is notable because it is the first FPGA family to have
> complete reverse engineered bit-stream documentation for the iCE40LP and
> iCE40HX devices. Furthermore, there is now a Free Software Verilog
> synthesis tool-chain: the "IceStorm" tool-chain.
>
> This project is the work of Clifford Wolf, who is the maintainer of
> Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
> contributions from "Cotton Seed", the main author of "arachne-pnr"; a
> place-and-route tool for iCE40 FPGAs.
>
> Having a Free Software synthesis tool-chain offers interesting
> opportunities for embedded devices that are able reconfigure themselves
> with open firmware that is generated on the device itself. For example
> a mobile device might have an application processer with an iCE40 FPGA
> attached, which implements slave devices, or through which the processor
> communicates with other devices through the FPGA fabric.
>
> A kernel driver for the iCE40 is useful, because in some cases, the FPGA
> may need to be configured before other devices can be accessed.
>
> An example of such a device is the icoBOARD; a RaspberryPI HAT which
> features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
> Digilent-compatible PMOD modules. A PMOD module may contain a device
> with which the kernel communicates, via the FPGA.
> ---
> .../bindings/fpga/lattice-ice40-fpga-mgr.txt | 23 +++
> drivers/fpga/Kconfig | 6 +
> drivers/fpga/Makefile | 1 +
> drivers/fpga/ice40spi.c | 212 +++++++++++++++++++++
> 4 files changed, 242 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> create mode 100644 drivers/fpga/ice40spi.c
>
Hi Joel,
Thanks for submitting your driver!
I didn't see any huge problems, just minor things below...
Alan
> diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> new file mode 100644
> index 0000000..b253ac8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> @@ -0,0 +1,23 @@
> +Lattice iCE40 FPGA Manager
> +
> +Required properties:
> +- compatible: should contain "lattice,ice40-fpga-mgr"
> +- reg: SPI chip select
> +- spi-max-frequency: Maximum SPI frequency (>=1000000, <=25000000)
> +- cdone-gpios: GPIO connected to CDONE pin
> +- creset_b-gpios: GPIO connected to CRESET_B pin. Note that CRESET_B is
> + treated as an active-low output because the signal is
> + treated as an enable signal, rather than a reset. This
> + is necessary because the FPGA will enter Master SPI
> + mode and drive SCK with a clock signal, potentially
> + jamming other devices on the bus, unless CRESET_B is
> + held high until the firmware is loaded.
Both could be singular ...-gpio since only one gpio should be specified.
> +
> +Example:
> + ice40: ice40@0 {
> + compatible = "lattice,ice40-fpga-mgr";
> + reg = <0>;
> + spi-max-frequency = <1000000>;
> + cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
> + creset_b-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
> + };
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index d614102..85ff429 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -13,6 +13,12 @@ config FPGA
>
> if FPGA
>
> +config FPGA_MGR_ICE40_SPI
> + tristate "Lattice iCE40 SPI"
> + depends on SPI
> + help
> + FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
> +
> config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8d83fc6..6c809cc 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -6,5 +6,6 @@
> obj-$(CONFIG_FPGA) += fpga-mgr.o
>
> # FPGA Manager Drivers
> +obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40spi.o
Could this be ice40-spi.c?
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> diff --git a/drivers/fpga/ice40spi.c b/drivers/fpga/ice40spi.c
> new file mode 100644
> index 0000000..ab5ee86
> --- /dev/null
> +++ b/drivers/fpga/ice40spi.c
> @@ -0,0 +1,212 @@
> +/*
> + * FPGA Manager Driver for Lattice iCE40.
> + *
> + * Copyright (c) 2016 Joel Holdsworth
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This driver adds support to the FPGA manager for configuring the SRAM of
> + * Lattice iCE40 FPGAs through slave SPI.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/fpga/fpga-mgr.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/of_gpio.h>
> +#include <linux/spi/spi.h>
> +
> +struct ice40_fpga_priv {
> + struct spi_device *dev;
> + struct gpio_desc *creset_b;
> + struct gpio_desc *cdone;
> + enum fpga_mgr_states state;
state is never used. You could just remove it.
> +};
> +
> +static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
> +{
> + return mgr->state;
fpga_mgr_register will call your ice40_fpga_ops_state() function to
get its initial state. That's the only time this gets called. So
you could return one of the enum fpga_mgr_states here. I'm guessing
FPGA_MGR_STATE_UNKNOWN. I'm realizing that there will be devices
that don't really know what initial state they are in; I could have
removed the absolute requirement for the state in the fpga_manager_ops
and assumed FPGA_MGR_STATE_UNKNOWN unless a low level driver provided
a state function. But for now, just return FPGA_MGR_STATE_UNKNOWN
here unless you have a way of knowing what state you are in when
the driver is probed.
> +}
> +
> +static void set_cs(struct spi_device *spi, bool enable)
> +{
> + if (gpio_is_valid(spi->cs_gpio))
> + gpio_set_value(spi->cs_gpio, !enable);
> + else if (spi->master->set_cs)
> + spi->master->set_cs(spi, !enable);
> +}
> +
> +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
Checkpatch complains about alignment here.
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + int ret;
> +
> + if ((flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + dev_err(&dev->dev,
> + "Partial reconfiguration is not supported\n");
> + return -EINVAL;
> + }
> +
> + /* Lock the bus, assert SS_B and CRESET_B */
> + ret = spi_bus_lock(dev->master);
> + if (ret) {
> + dev_err(&dev->dev, "Failed to lock SPI bus, ret: %d\n", ret);
> + return ret;
> + }
> +
> + set_cs(dev, 1);
> + gpiod_set_value(priv->creset_b, 1);
> +
> + /* Delay for >200ns */
> + udelay(1);
> +
> + /* Come out of reset */
> + gpiod_set_value(priv->creset_b, 0);
> +
> + /* Check CDONE is de-asserted i.e. the FPGA is reset */
> + if (gpiod_get_value(priv->cdone)) {
> + dev_err(&dev->dev, "Device reset failed, CDONE is asserted\n");
> + ret = -EIO;
> + }
> +
> + /* Wait for the housekeeping to complete */
> + if (!ret)
> + udelay(1200);
Would usleep_range work for you since it's more than 10uSec
(Documentation/timers/timers-howto.txt)?
> +
> + /* Release the SS_B */
> + set_cs(dev, 0);
> + spi_bus_unlock(dev->master);
> +
> + return ret;
> +}
> +
> +static int ice40_fpga_ops_write(struct fpga_manager *mgr,
> + const char *buf, size_t count)
Checkpatch complains about alignment here also.
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + int ret;
> +
> + ret = spi_write(dev, buf, count);
> + if (ret)
> + dev_err(&dev->dev, "Error sending SPI data, ret: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + int ret = 0;
> +
> + /* Check CDONE is asserted */
> + if (!gpiod_get_value(priv->cdone)) {
> + dev_err(&dev->dev,
> + "CDONE was not asserted after firmware transfer\n");
> + return -EIO;
> + }
> +
> + /* Send >49-bits of zero-padding to activate the firmware */
> + ret = spi_write(dev, NULL, 7);
> + if (ret) {
> + dev_err(&dev->dev, "Error sending zero padding, ret: %d\n",
> + ret);
> + return ret;
> + }
> +
> + /* Success */
> + return 0;
> +}
> +
> +static const struct fpga_manager_ops ice40_fpga_ops = {
> + .state = ice40_fpga_ops_state,
> + .write_init = ice40_fpga_ops_write_init,
> + .write = ice40_fpga_ops_write,
> + .write_complete = ice40_fpga_ops_write_complete,
> +};
> +
> +static int ice40_fpga_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct device_node *np = spi->dev.of_node;
> + struct ice40_fpga_priv *priv;
> + int ret;
> +
> + if (!np) {
> + dev_err(dev, "No Device Tree entry\n");
> + return -EINVAL;
> + }
> +
> + priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = spi;
> +
> + /* Check board setup data. */
> + if (spi->max_speed_hz > 25000000) {
> + dev_err(dev, "speed is too high\n");
> + return -EINVAL;
> + } else if (spi->mode & SPI_CPHA) {
> + dev_err(dev, "bad mode\n");
> + return -EINVAL;
> + }
> +
> + /* Set up the GPIOs */
> + priv->cdone = devm_gpiod_get(dev, "cdone", GPIOD_IN);
> + if (IS_ERR(priv->cdone)) {
> + dev_err(dev, "Failed to get CDONE GPIO: %ld\n",
> + PTR_ERR(priv->cdone));
> + return ret;
> + }
> +
> + priv->creset_b = devm_gpiod_get(dev, "creset_b", GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->creset_b)) {
> + dev_err(dev, "Failed to get CRESET_B GPIO: %ld\n",
> + PTR_ERR(priv->creset_b));
> + return ret;
> + }
> +
> + /* Register with the FPGA manager */
> + ret = fpga_mgr_register(dev, "Lattice iCE40 FPGA Manager",
> + &ice40_fpga_ops, priv);
> + if (ret) {
> + dev_err(dev, "unable to register FPGA manager");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int ice40_fpga_remove(struct spi_device *spi)
> +{
> + fpga_mgr_unregister(&spi->dev);
> + return 0;
> +}
> +
#ifdef CONFIG_OF
> +static const struct of_device_id ice40_fpga_of_match[] = {
> + { .compatible = "lattice,ice40-fpga-mgr", },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, ice40_fpga_of_match);
#endif
> +
> +static struct spi_driver ice40_fpga_driver = {
> + .probe = ice40_fpga_probe,
> + .remove = ice40_fpga_remove,
> + .driver = {
> + .name = "ice40spi",
> + .owner = THIS_MODULE,
It's not necessary to specify .owner anymore.
> + .of_match_table = of_match_ptr(ice40_fpga_of_match),
> + },
> +};
> +
> +module_spi_driver(ice40_fpga_driver);
> +
> +MODULE_AUTHOR("Joel Holdsworth <joel@airwebreathe.org.uk>");
> +MODULE_DESCRIPTION("Lattice iCE40 FPGA Manager");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
>
^ permalink raw reply
* Re: [PATCH v1 0/3] Add support for Broadcom OTP controller
From: Linus Torvalds @ 2016-10-24 21:52 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jonathan Richardson, Srinivas Kandagatla, Maxime Ripard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
lkml, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mark Rutland, Rob Herring, Scott Branden, Ray Jui,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <82ad10b1-32ab-3962-d5ab-e787e2c70130-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Oct 24, 2016 at 2:27 PM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Should we compare the headers added by lists.infradead.org
So for me, it didn't go through infraded.org, but I got it through the
kernel mailing list.
I'll send you the raw email data in private, you can compare it
against your good one.
Linus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 0/3] Add support for Broadcom OTP controller
From: Florian Fainelli @ 2016-10-24 21:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jonathan Richardson, Srinivas Kandagatla, Maxime Ripard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
lkml, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mark Rutland, Rob Herring, Scott Branden, Ray Jui,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <CA+55aFwAZPJ+o0qkYjJziHofYvvsocHuWr1YUmVnzj6VTv_sgA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10/24/2016 01:14 PM, Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 12:54 PM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> The older setup was using smtphost.broadcom.com which we have now
>> documented as being invalid, here Jonathan used gmail directly (since
>> that's our mail provider now):
>>
>> Received: from lbrmn-lnxub108.corp.ad.broadcom.com ([216.31.219.19])
>> by smtp.gmail.com with ESMTPSA id
>> s89sm8325746qkl.44.2016.10.24.12.12.00
>> (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
>> Mon, 24 Oct 2016 12:12:03 -0700 (PDT)
>
> Hmm. I get that too, so if that's the right thing for a broadcom.com
> address, it's not the smtp server issue.
>
> We had a few cases of the kernel mailing list itself messing up emails
> sufficiently to fail dkim, but that shouldn't be an issue for the
> relaxed/relaxed model that broadcom uses (the vger mailing list
> software screws up whitespace, which "relaxed" ignores).
>
>> Is there something else we need to check? Here is what I read for the
>> cover-letter:
>>
>> Authentication-Results: mx.google.com;
>> dkim=pass header.i=@broadcom.com;
>> spf=pass (google.com: domain of ...
>
> Hmm. I get:
>
> Authentication-Results: mx.google.com;
> dkim=fail header.i=@broadcom.com;
>
> with the actual dkim signature looking like this:
>
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=broadcom.com; s=google;
> h=from:to:cc:subject:date:message-id;
> bh=9zStGnsZQDQqP6cm1CHPk7EYVtLvDsm2wN5qy5Mgx7M=;
> b=Z/1QD+FwJogJY9D8Qd197Q+VJt7Tr9+WoHFeKYRL00yhvxrMg0P8jKj1FbucJTluvM
> agC2eq9qCpZcNAfridjExDRDCuUPAIJIXTr9Npkpqlk6gEMq2FysrGer2D9Z4HQ/atTX
> 67VirFsQK0gK7impYMn9kW5Q9BIIw5bOg7OdI=
>
> and those fields that it protects look like this:
>
> From: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> To: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Maxime
> Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland
> <mark.rutland-5wv7dgnIgG8@public.gmane.org>, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Scott
> Branden <sbranden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>, Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
> bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org, Jonathan Richardson
> <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Subject: [PATCH v1 0/3] Add support for Broadcom OTP controller
> Date: Mon, 24 Oct 2016 12:12:01 -0700
> Message-Id: <1477336324-10543-1-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>
> and I don't see anything obviously wrong anywhere - except for that
> "dkim=fail" thing, and the email being in my spam folder.
Should we compare the headers added by lists.infradead.org and see what
could possibly go wrong here? I can see that by being delivered to
lists.infradead.org and then back to my personal gmail.com (not my other
broadcom.com account), there are a bunch of extra headers:
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3
X-CRM114-CacheID: sfid-20161024_121226_013940_81319C20
X-CRM114-Status: GOOD ( 13.05 )
X-Spam-Score: -2.7 (--)
X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary:
Content analysis details: (-2.7 points)
pts rule name description
---- ----------------------
--------------------------------------------------
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at
http://www.dnswl.org/, low
trust [2607:f8b0:400d:c09:0:0:0:22f listed in] [list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
X-BeenThere: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
X-Mailman-Version: 2.1.20
Precedence: list
Would those be used by your mail client to put this mail in spam, or was
that done by the linux-foundation.org (also gmail?) mail upon reception?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: David Lechner @ 2016-10-24 21:20 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman
Cc: Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b6cd3c47-0df8-266a-2b8d-13c82062b647-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
On 10/24/2016 02:50 PM, David Lechner wrote:
> On 10/24/2016 10:50 AM, David Lechner wrote:
>> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>>
>>>> +&ehrpwm1 {
>>>> + status = "disabled";
>>>
>>> Hmm, disabled? Can you add this node when you actually use it?
>>
>> Not sure why I have this disabled. Like the gpios, the pwms can be used
>> via sysfs, so I would like to leave them.
>>
>
> Now I remember why these are disabled. The clock matching is broken.
> Only the first ehrpwm and the first ecap get clocks. The others fail.
>
> I can change these to "okay". It will just result in a kernel error
> message until the clocks are fixed.
>
correction: it is not the clocks that are broken. it is the device names.
In arch/arm/mach-davinci/da8xx-dt.c, we have...
OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f00000, "ehrpwm", NULL),
OF_DEV_AUXDATA("ti,da850-ehrpwm", 0x01f02000, "ehrpwm", NULL),
OF_DEV_AUXDATA("ti,da850-ecap", 0x01f06000, "ecap", NULL),
OF_DEV_AUXDATA("ti,da850-ecap", 0x01f07000, "ecap", NULL),
OF_DEV_AUXDATA("ti,da850-ecap", 0x01f08000, "ecap", NULL),
Which causes each device to have the same device node name. This causes
sysfs errors because it is trying to register a second device at the
same sysfs path.
If you change the names here, then the device do not work because the
clock lookup fails.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 0/3] Add support for Broadcom OTP controller
From: Linus Torvalds @ 2016-10-24 20:14 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jonathan Richardson, Srinivas Kandagatla, Maxime Ripard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
lkml, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mark Rutland, Rob Herring, Scott Branden, Ray Jui,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <e34f01b6-a059-9988-0f93-e5adb82a5436-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Oct 24, 2016 at 12:54 PM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> The older setup was using smtphost.broadcom.com which we have now
> documented as being invalid, here Jonathan used gmail directly (since
> that's our mail provider now):
>
> Received: from lbrmn-lnxub108.corp.ad.broadcom.com ([216.31.219.19])
> by smtp.gmail.com with ESMTPSA id
> s89sm8325746qkl.44.2016.10.24.12.12.00
> (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
> Mon, 24 Oct 2016 12:12:03 -0700 (PDT)
Hmm. I get that too, so if that's the right thing for a broadcom.com
address, it's not the smtp server issue.
We had a few cases of the kernel mailing list itself messing up emails
sufficiently to fail dkim, but that shouldn't be an issue for the
relaxed/relaxed model that broadcom uses (the vger mailing list
software screws up whitespace, which "relaxed" ignores).
> Is there something else we need to check? Here is what I read for the
> cover-letter:
>
> Authentication-Results: mx.google.com;
> dkim=pass header.i=@broadcom.com;
> spf=pass (google.com: domain of ...
Hmm. I get:
Authentication-Results: mx.google.com;
dkim=fail header.i=@broadcom.com;
with the actual dkim signature looking like this:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=broadcom.com; s=google;
h=from:to:cc:subject:date:message-id;
bh=9zStGnsZQDQqP6cm1CHPk7EYVtLvDsm2wN5qy5Mgx7M=;
b=Z/1QD+FwJogJY9D8Qd197Q+VJt7Tr9+WoHFeKYRL00yhvxrMg0P8jKj1FbucJTluvM
agC2eq9qCpZcNAfridjExDRDCuUPAIJIXTr9Npkpqlk6gEMq2FysrGer2D9Z4HQ/atTX
67VirFsQK0gK7impYMn9kW5Q9BIIw5bOg7OdI=
and those fields that it protects look like this:
From: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
To: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Maxime
Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Rutland
<mark.rutland-5wv7dgnIgG8@public.gmane.org>, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Scott
Branden <sbranden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>, Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org, Jonathan Richardson
<jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Subject: [PATCH v1 0/3] Add support for Broadcom OTP controller
Date: Mon, 24 Oct 2016 12:12:01 -0700
Message-Id: <1477336324-10543-1-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
and I don't see anything obviously wrong anywhere - except for that
"dkim=fail" thing, and the email being in my spam folder.
Linus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 0/3] Add support for Broadcom OTP controller
From: Florian Fainelli @ 2016-10-24 19:54 UTC (permalink / raw)
To: Linus Torvalds, Jonathan Richardson
Cc: Mark Rutland, devicetree, Scott Branden, Ray Jui, lkml,
Rob Herring, Srinivas Kandagatla, bcm-kernel-feedback-list,
Maxime Ripard, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAADWXX-43-k2K2T1V5MQMd0z0V502wf1syNHERPfvNstOJw-3A@mail.gmail.com>
On 10/24/2016 12:39 PM, Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 12:12 PM, Jonathan Richardson
> <jonathan.richardson@broadcom.com> wrote:
>> This patch set adds support for Broadcom's OTP controller found on chips such
>> as Cygnus and Stingray. A node has been added to the Cygnus dts.
>
> These patches fail DKIM and will thus be marked as spam for a lot of people.
>
> The usual reason tends to be that you use the wrong smtp server that
> doesn't add the right signature. That's happened before with
> broadcom.com addresses.
The older setup was using smtphost.broadcom.com which we have now
documented as being invalid, here Jonathan used gmail directly (since
that's our mail provider now):
Received: from lbrmn-lnxub108.corp.ad.broadcom.com ([216.31.219.19])
by smtp.gmail.com with ESMTPSA id
s89sm8325746qkl.44.2016.10.24.12.12.00
(version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Mon, 24 Oct 2016 12:12:03 -0700 (PDT)
Is there something else we need to check? Here is what I read for the
cover-letter:
Authentication-Results: mx.google.com;
dkim=pass header.i=@broadcom.com;
spf=pass (google.com: domain of
bcm-kernel-feedback-list.pdl+bncbdh5xfvr4ydrbbn2xhaakgqed7hz4rq@broadcom.com
designates 2607:f8b0:400c:c08::247 as permitted sender)
smtp.mailfrom=bcm-kernel-feedback-list.pdl+bncBDH5XFVR4YDRBBN2XHAAKGQED7HZ4RQ@broadcom.com;
dmarc=pass (p=QUARANTINE dis=NONE) header.from=broadcom.com
--
Florian
^ permalink raw reply
* Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: David Lechner @ 2016-10-24 19:50 UTC (permalink / raw)
To: Sekhar Nori, Kevin Hilman
Cc: Rob Herring, Mark Rutland, Russell King, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1593441f-d147-4c91-8aab-8622dd8ced19@lechnology.com>
On 10/24/2016 10:50 AM, David Lechner wrote:
> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>
>>> +&ehrpwm1 {
>>> + status = "disabled";
>>
>> Hmm, disabled? Can you add this node when you actually use it?
>
> Not sure why I have this disabled. Like the gpios, the pwms can be used
> via sysfs, so I would like to leave them.
>
Now I remember why these are disabled. The clock matching is broken.
Only the first ehrpwm and the first ecap get clocks. The others fail.
I can change these to "okay". It will just result in a kernel error
message until the clocks are fixed.
^ permalink raw reply
* Re: [PATCH v3 3/6] dt-bindings: pinctrl: Deprecate sunxi pinctrl bindings
From: Maxime Ripard @ 2016-10-24 19:49 UTC (permalink / raw)
To: Linus Walleij
Cc: Chen-Yu Tsai, linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring
In-Reply-To: <CACRpkdb7zs7Nhs3i1o=WUt787vJCuePre3Tj3wLu++qwpO0atQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 991 bytes --]
Hi Linus,
On Mon, Oct 24, 2016 at 02:03:59AM +0200, Linus Walleij wrote:
> On Thu, Oct 20, 2016 at 3:49 PM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > The generic pin configuration and multiplexing should be preferred now,
> > even though we still support the old one.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Patch applied.
Thanks a lot.
However, it looks like the first patch from this serie is missing from
your tree, is there a reason for that?
Also, in order to preserve bisectability, could you create an
immutable branch for those sunxi patches so that I can merge the DT
bits?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Stephen Boyd @ 2016-10-24 19:48 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Felipe Balbi, Arnd Bergmann, Neil Armstrong, linux-arm-msm,
linux-usb, linux-kernel, Bjorn Andersson, devicetree, Peter Chen,
Andy Gross, linux-arm-kernel
In-Reply-To: <CAGb2v66t8t3o0PxzaaBKnRvNP=CWG5nYud7Wjp27Q1x2baM4hg@mail.gmail.com>
Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
> Hi,
>
> On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > The ULPI bus can be built as a module, and it will soon be
> > calling these functions when it supports probing devices from DT.
> > Export them so they can be used by the ULPI module.
> >
> > Acked-by: Rob Herring <robh@kernel.org>
> > Cc: <devicetree@vger.kernel.org>
> > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > ---
> > drivers/of/device.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > index 8a22a253a830..6719ab35b62e 100644
> > --- a/drivers/of/device.c
> > +++ b/drivers/of/device.c
> > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
> >
> > return tsize;
> > }
> > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
> >
> > int of_device_request_module(struct device *dev)
> > {
> > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > }
> > mutex_unlock(&of_mutex);
> > }
> > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
>
> This is trailing the wrong function.
>
Good catch. Must have been some bad rebase.
Peter, can you fix it while applying or should I resend this patch?
^ permalink raw reply
* Re: [PATCH v1 0/3] Add support for Broadcom OTP controller
From: Linus Torvalds @ 2016-10-24 19:39 UTC (permalink / raw)
To: Jonathan Richardson
Cc: Srinivas Kandagatla, Maxime Ripard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
lkml, devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Rob Herring, Scott Branden, Ray Jui,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w
In-Reply-To: <1477336324-10543-1-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Mon, Oct 24, 2016 at 12:12 PM, Jonathan Richardson
<jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> This patch set adds support for Broadcom's OTP controller found on chips such
> as Cygnus and Stingray. A node has been added to the Cygnus dts.
These patches fail DKIM and will thus be marked as spam for a lot of people.
The usual reason tends to be that you use the wrong smtp server that
doesn't add the right signature. That's happened before with
broadcom.com addresses.
Linus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 4/8] drivers:input:tsc2007: add iio interface to read external ADC input and temperature
From: H. Nikolaus Schaller @ 2016-10-24 19:14 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Mark Rutland, devicetree, linux-omap, Arnd Bergmann, kernel,
Tony Lindgren, linux-kernel, Mark Brown, Dmitry Torokhov,
Russell King, linux-iio, Sebastian Reichel,
Javier Martinez Canillas, Rob Herring, Mika Penttilä,
Benoît Cousson, linux-input, Michael Welling, letux-kernel,
Andrew F. Davis, Igor Grinberg
In-Reply-To: <4b6773d9-bc33-7471-ee29-01f51c5cfce2@kernel.org>
Hi Jonathan,
> Am 23.10.2016 um 21:00 schrieb Jonathan Cameron <jic23@kernel.org>:
>
> On 23/10/16 19:34, H. Nikolaus Schaller wrote:
>> Hi Jonathan,
>>
>>> Am 23.10.2016 um 11:57 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>>
>>> Hi,
>>>
>>>>> +static int tsc2007_alloc(struct i2c_client *client, struct tsc2007 **ts,
>>>>> + struct input_dev **input_dev)
>>>>> +{
>>>>> + int err;
>>>>> + struct iio_dev *indio_dev;
>>>>> +
>>>>> + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*ts));
>>>> Instead of doing this to reduce the delta between versions make
>>>> iio_priv a struct tsc2007 **
>>>>
>>>> That is have a single pointer in there and do your allocation of struct
>>>> tsc2007 separately.
>>>
>>> Sorry, but I think I do not completely understand what you mean here.
>>>
>>> The problem is that we need to allocate some struct tsc2007 in both cases.
>>> But in one case managed directly by &client->dev and in the other managed
>>> indirectly. This is why I use the private area of struct iio_dev to store
>>> the full struct tsc2007 and not just a pointer.
>>
>> Ok, I think I finally did understand how you mean this and have started to
>> implement something.
>>
> oops. Didn't look on in my emails to get to this one!
>> The idea is to have one alloc function to return a struct tsc2007. This
>> can be part of the probe function, like it is in the unpatched driver.
>>
>> In case of iio this struct tsc2007 is also allocated explicitly so that
>> a pointer can be stored in iio_priv.
>>
>> This just means an additional iio_priv->ts = devm_kzalloc() in case of iio.
>>
>> I have added that approach to my inlined patch and it seems to work (attached).
>>
>> Sorry if I do not use the wording you would use and sometimes overlook
>> something you have said. I feel here like moving on thin ice and doing
>> guesswork about unspoken assumptions...
> That's fine. Stuff that can appear obvious to one person is not
> necessarily obvious to another!
>>
>>>
>>>>
>>>> Having doing that, you can have this CONFIG_IIO block as just
>>>> doing the iio stuff with the input elements pulled back into the main
>>>> probe function.
>>>>
>>>> Then define something like
>>>>
>>>> iio_configure (stubbed to nothing if no IIO)
>>>> and
>>>> iio_unconfigure (also stubbed to nothing if no IIO).
>>
>> This seems to work (draft attached).
>>
>>>>
>>>> A couple of additions in the header
>>
>> I think you mean tsc2007.h?
> Nope. A local header alongside the driver is what you want for this stuff.
> driver/input/tsc2007.h
>>
>> This currently contains only platform data and could IMHO be eliminated
>> if everything becomes DT.
>>
>>>> to make it all work
>>>> (the struct tsc2007 and tsc2007_xfer() + a few of the
>>>> register defines..
>>
>> Here it appears to me that I have to make a lot of so far private static
>> and even static inline functions public so that I can make them stubs and
>> call them from tsc2007_iio.c.
> There will be a few.
>>
>> And for having proper parameter types I have to make most private structs
>> also public.
> Yes a few of those as well.
>>
>> I really like the idea to have the optional iio feature in a separate source
>> file, but when really starting to write code, I get the impression that
>> it introduces more problems than it solves.
>>
>> And I wonder a little why it is not done for #ifdef CONFIG_OF in tsc2007.c
>> as well. There are also two static function in some #ifdef #else # endif
>> and not going through stubs.
> Usually it is only done once a certain volume of code exists.
>>
>> So is this intended to give up some static definitions?
> Yes, that happens the moment you have multiple source files.
>
> Some losses but generally end up with clean code separation. Always a trade
> off unfortunately. Pity we can't just insist IIO is available! Rather large
> to pull in for what is probable a niche use case.
>
> Below is definitely heading in the right direction. I remember vaguely being
> convinced of the worth of doing this when optional code is involved!
> (was a good while ago now)
>
> Jonathan
>>
>> BR and thanks,
>> Nikolaus
>>
>> diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
>> index 5e3c4bf..92da8f6 100644
>> --- a/drivers/input/touchscreen/tsc2007.c
>> +++ b/drivers/input/touchscreen/tsc2007.c
>> @@ -30,6 +30,7 @@
>> #include <linux/of.h>
>> #include <linux/of_gpio.h>
>> #include <linux/input/touchscreen.h>
>> +#include <linux/iio/iio.h>
> Should not need this after introducing the new file. Will only be
> needed in the iio specific .c file.
>>
>> #define TSC2007_MEASURE_TEMP0 (0x0 << 4)
>> #define TSC2007_MEASURE_AUX (0x2 << 4)
>> @@ -98,6 +99,9 @@ struct tsc2007 {
> This will definitely need to go in the header though.
Now I have split the code into:
tsc2007.h (constants, structs and stubs)
tsc2007_iio.c (the iio stuff)
tsc2007.c (most parts of the original driver)
but I have a problem of correctly modifying the Makefile.
It currently looks like:
obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o
obj-$(CONFIG_IIO) += tsc2007_iio.o
We have configured CONFIG_TOUCHSCREEN_TSC2007=m and CONFIG_IIO=y.
This obviously compiles tsc2007_iio.o into the kernel.
This means that tsc2007_iio.o references tsc2007_xfer which is part of
the module.
I would like to get both linked into the module, but the iio part
obviously only if CONFIG_IIO is defined (either -y or -m).
How can I define this?
Or can I define
obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o tsc2007_iio.o
and embrace all code in tsc2007_iio with a big #ifdef CONFIG_IIO
so that it is compiled into an empty object file in the non-iio case?
BR and thanks,
Nikolaus
^ permalink raw reply
* [PATCH v1 3/3] ARM: dts: Add node for Broadcom OTP controller driver
From: Jonathan Richardson @ 2016-10-24 19:12 UTC (permalink / raw)
To: Srinivas Kandagatla, Maxime Ripard
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, Rob Herring,
Scott Branden, Ray Jui,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
Jonathan Richardson, Jonathan Richardson, Scott Branden,
Oza Pawandeep
In-Reply-To: <1477336324-10543-1-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
From: Jonathan Richardson <jonathar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Tested-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Oza Pawandeep <oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index fabc9f3..a74a430 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -91,6 +91,13 @@
#address-cells = <1>;
#size-cells = <1>;
+ otp: otp@0301c800 {
+ compatible = "brcm,ocotp";
+ reg = <0x0301c800 0x2c>;
+ brcm,ocotp-size = <2048>;
+ status = "disabled";
+ };
+
pcie_phy: phy@0301d0a0 {
compatible = "brcm,cygnus-pcie-phy";
reg = <0x0301d0a0 0x14>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v1 2/3] nvmem: Add the Broadcom OTP controller driver
From: Jonathan Richardson @ 2016-10-24 19:12 UTC (permalink / raw)
To: Srinivas Kandagatla, Maxime Ripard
Cc: linux-arm-kernel, linux-kernel, devicetree, Mark Rutland,
Rob Herring, Scott Branden, Ray Jui, bcm-kernel-feedback-list,
Jonathan Richardson, Jonathan Richardson, Scott Branden,
Oza Pawandeep
In-Reply-To: <1477336324-10543-1-git-send-email-jonathan.richardson@broadcom.com>
From: Jonathan Richardson <jonathar@broadcom.com>
Add support for 32 and 64-bit versions of Broadcom's On-Chip OTP
controller. These controllers are used on SoC's such as Cygnus and
Stingray.
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Oza Pawandeep <oza@broadcom.com>
Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
---
drivers/nvmem/Kconfig | 12 ++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/bcm-ocotp.c | 335 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 349 insertions(+)
create mode 100644 drivers/nvmem/bcm-ocotp.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index ba140ea..06935a7 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -80,6 +80,18 @@ config ROCKCHIP_EFUSE
This driver can also be built as a module. If so, the module
will be called nvmem_rockchip_efuse.
+config NVMEM_BCM_OCOTP
+ tristate "Broadcom On-Chip OTP Controller support"
+ depends on ARCH_BCM_IPROC || COMPILE_TEST
+ depends on HAS_IOMEM
+ default ARCH_BCM_IPROC
+ help
+ Say y here to enable read/write access to the Broadcom OTP
+ controller.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-bcm-ocotp.
+
config NVMEM_SUNXI_SID
tristate "Allwinner SoCs SID support"
depends on ARCH_SUNXI
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 8f942a0..71781ca 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -6,6 +6,8 @@ obj-$(CONFIG_NVMEM) += nvmem_core.o
nvmem_core-y := core.o
# Devices
+obj-$(CONFIG_NVMEM_BCM_OCOTP) += nvmem-bcm-ocotp.o
+nvmem-bcm-ocotp-y := bcm-ocotp.o
obj-$(CONFIG_NVMEM_IMX_OCOTP) += nvmem-imx-ocotp.o
nvmem-imx-ocotp-y := imx-ocotp.o
obj-$(CONFIG_NVMEM_LPC18XX_EEPROM) += nvmem_lpc18xx_eeprom.o
diff --git a/drivers/nvmem/bcm-ocotp.c b/drivers/nvmem/bcm-ocotp.c
new file mode 100644
index 0000000..646cadb
--- /dev/null
+++ b/drivers/nvmem/bcm-ocotp.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (C) 2016 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+/*
+ * # of tries for OTP Status. The time to execute a command varies. The slowest
+ * commands are writes which also vary based on the # of bits turned on. Writing
+ * 0xffffffff takes ~3800 us.
+ */
+#define OTPC_RETRIES 5000
+
+/* Sequence to enable OTP program */
+#define OTPC_PROG_EN_SEQ { 0xf, 0x4, 0x8, 0xd }
+
+/* OTPC Commands */
+#define OTPC_CMD_READ 0x0
+#define OTPC_CMD_OTP_PROG_ENABLE 0x2
+#define OTPC_CMD_OTP_PROG_DISABLE 0x3
+#define OTPC_CMD_PROGRAM 0xA
+
+/* OTPC Status Bits */
+#define OTPC_STAT_CMD_DONE BIT(1)
+#define OTPC_STAT_PROG_OK BIT(2)
+
+/* OTPC register definition */
+#define OTPC_MODE_REG_OFFSET 0x0
+#define OTPC_MODE_REG_OTPC_MODE 0
+#define OTPC_COMMAND_OFFSET 0x4
+#define OTPC_COMMAND_COMMAND_WIDTH 6
+#define OTPC_CMD_START_OFFSET 0x8
+#define OTPC_CMD_START_START 0
+#define OTPC_CPU_STATUS_OFFSET 0xc
+#define OTPC_CPUADDR_REG_OFFSET 0x28
+#define OTPC_CPUADDR_REG_OTPC_CPU_ADDRESS_WIDTH 16
+#define OTPC_CPU_WRITE_REG_OFFSET 0x2c
+
+#define OTPC_CMD_MASK (BIT(OTPC_COMMAND_COMMAND_WIDTH) - 1)
+#define OTPC_ADDR_MASK (BIT(OTPC_CPUADDR_REG_OTPC_CPU_ADDRESS_WIDTH) - 1)
+
+
+struct otpc_map {
+ /* in words. */
+ u32 otpc_row_size;
+ /* 128 bit row / 4 words support. */
+ u16 data_r_offset[4];
+ /* 128 bit row / 4 words support. */
+ u16 data_w_offset[4];
+};
+
+static struct otpc_map otp_map = {
+ .otpc_row_size = 1,
+ .data_r_offset = {0x10},
+ .data_w_offset = {0x2c},
+};
+
+static struct otpc_map otp_map_v2 = {
+ .otpc_row_size = 2,
+ .data_r_offset = {0x10, 0x5c},
+ .data_w_offset = {0x2c, 0x64},
+};
+
+struct otpc_priv {
+ struct device *dev;
+ void __iomem *base;
+ struct otpc_map *map;
+ struct nvmem_config *config;
+};
+
+static inline void set_command(void __iomem *base, u32 command)
+{
+ writel(command & OTPC_CMD_MASK, base + OTPC_COMMAND_OFFSET);
+}
+
+static inline void set_cpu_address(void __iomem *base, u32 addr)
+{
+ writel(addr & OTPC_ADDR_MASK, base + OTPC_CPUADDR_REG_OFFSET);
+}
+
+static inline void set_start_bit(void __iomem *base)
+{
+ writel(1 << OTPC_CMD_START_START, base + OTPC_CMD_START_OFFSET);
+}
+
+static inline void reset_start_bit(void __iomem *base)
+{
+ writel(0, base + OTPC_CMD_START_OFFSET);
+}
+
+static inline void write_cpu_data(void __iomem *base, u32 value)
+{
+ writel(value, base + OTPC_CPU_WRITE_REG_OFFSET);
+}
+
+static int poll_cpu_status(void __iomem *base, u32 value)
+{
+ u32 status;
+ u32 retries;
+
+ for (retries = 0; retries < OTPC_RETRIES; retries++) {
+ status = readl(base + OTPC_CPU_STATUS_OFFSET);
+ if (status & value)
+ break;
+ udelay(1);
+ }
+ if (retries == OTPC_RETRIES)
+ return -EAGAIN;
+
+ return 0;
+}
+
+static int enable_ocotp_program(void __iomem *base)
+{
+ static const u32 vals[] = OTPC_PROG_EN_SEQ;
+ int i;
+ int ret;
+
+ /* Write the magic sequence to enable programming */
+ set_command(base, OTPC_CMD_OTP_PROG_ENABLE);
+ for (i = 0; i < ARRAY_SIZE(vals); i++) {
+ write_cpu_data(base, vals[i]);
+ set_start_bit(base);
+ ret = poll_cpu_status(base, OTPC_STAT_CMD_DONE);
+ reset_start_bit(base);
+ if (ret)
+ return ret;
+ }
+
+ return poll_cpu_status(base, OTPC_STAT_PROG_OK);
+}
+
+static int disable_ocotp_program(void __iomem *base)
+{
+ int ret;
+
+ set_command(base, OTPC_CMD_OTP_PROG_DISABLE);
+ set_start_bit(base);
+ ret = poll_cpu_status(base, OTPC_STAT_PROG_OK);
+ reset_start_bit(base);
+
+ return ret;
+}
+
+static int bcm_otpc_read(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct otpc_priv *priv = context;
+ u32 *buf = val;
+ u32 bytes_read;
+ u32 address = offset / priv->config->word_size;
+ int i, ret;
+
+ for (bytes_read = 0; bytes_read < bytes;) {
+ set_command(priv->base, OTPC_CMD_READ);
+ set_cpu_address(priv->base, address++);
+ set_start_bit(priv->base);
+ ret = poll_cpu_status(priv->base, OTPC_STAT_CMD_DONE);
+ if (ret) {
+ dev_err(priv->dev, "otp read error: 0x%x", ret);
+ return -EIO;
+ }
+
+ for (i = 0; i < priv->map->otpc_row_size; i++) {
+ *buf++ = readl(priv->base +
+ priv->map->data_r_offset[i]);
+ bytes_read += sizeof(*buf);
+ }
+
+ reset_start_bit(priv->base);
+ }
+
+ return 0;
+}
+
+static int bcm_otpc_write(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct otpc_priv *priv = context;
+ u32 *buf = val;
+ u32 bytes_written;
+ u32 address = offset / priv->config->word_size;
+ int i, ret;
+
+ if (offset % priv->config->word_size)
+ return -EINVAL;
+
+ ret = enable_ocotp_program(priv->base);
+ if (ret)
+ return -EIO;
+
+ for (bytes_written = 0; bytes_written < bytes;) {
+ set_command(priv->base, OTPC_CMD_PROGRAM);
+ set_cpu_address(priv->base, address++);
+ for (i = 0; i < priv->map->otpc_row_size; i++) {
+ writel(*buf, priv->base + priv->map->data_r_offset[i]);
+ buf++;
+ bytes_written += sizeof(*buf);
+ }
+ set_start_bit(priv->base);
+ ret = poll_cpu_status(priv->base, OTPC_STAT_CMD_DONE);
+ reset_start_bit(priv->base);
+ if (ret) {
+ dev_err(priv->dev, "otp write error: 0x%x", ret);
+ return -EIO;
+ }
+ }
+
+ disable_ocotp_program(priv->base);
+
+ return 0;
+}
+
+static struct nvmem_config bcm_otpc_nvmem_config = {
+ .name = "bcm-ocotp",
+ .read_only = false,
+ .word_size = 4,
+ .stride = 4,
+ .owner = THIS_MODULE,
+ .reg_read = bcm_otpc_read,
+ .reg_write = bcm_otpc_write,
+};
+
+static const struct of_device_id bcm_otpc_dt_ids[] = {
+ { .compatible = "brcm,ocotp" },
+ { .compatible = "brcm,ocotp-v2" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, bcm_otpc_dt_ids);
+
+static int bcm_otpc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *dn = dev->of_node;
+ struct resource *res;
+ struct otpc_priv *priv;
+ struct nvmem_device *nvmem;
+ int err;
+ u32 num_words;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ if (of_device_is_compatible(dev->of_node, "brcm,ocotp"))
+ priv->map = &otp_map;
+ else if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2"))
+ priv->map = &otp_map_v2;
+ else {
+ dev_err(&pdev->dev,
+ "%s otpc config map not defined\n", __func__);
+ return -EINVAL;
+ }
+
+ /* Get OTP base address register. */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->base)) {
+ dev_err(dev, "unable to map I/O memory\n");
+ return PTR_ERR(priv->base);
+ }
+
+ /* Enable CPU access to OTPC. */
+ writel(readl(priv->base + OTPC_MODE_REG_OFFSET) |
+ BIT(OTPC_MODE_REG_OTPC_MODE),
+ priv->base + OTPC_MODE_REG_OFFSET);
+ reset_start_bit(priv->base);
+
+ /* Read size of memory in words. */
+ err = of_property_read_u32(dn, "brcm,ocotp-size", &num_words);
+ if (err) {
+ dev_err(dev, "size parameter not specified\n");
+ return -EINVAL;
+ } else if (num_words == 0) {
+ dev_err(dev, "size must be > 0\n");
+ return -EINVAL;
+ }
+
+ bcm_otpc_nvmem_config.size = 4 * num_words;
+ bcm_otpc_nvmem_config.dev = dev;
+ bcm_otpc_nvmem_config.priv = priv;
+
+ if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2")) {
+ bcm_otpc_nvmem_config.word_size = 8;
+ bcm_otpc_nvmem_config.stride = 8;
+ }
+
+ priv->config = &bcm_otpc_nvmem_config;
+
+ nvmem = nvmem_register(&bcm_otpc_nvmem_config);
+ if (IS_ERR(nvmem)) {
+ dev_err(dev, "error registering nvmem config\n");
+ return PTR_ERR(nvmem);
+ }
+
+ platform_set_drvdata(pdev, nvmem);
+
+ return 0;
+}
+
+static int bcm_otpc_remove(struct platform_device *pdev)
+{
+ struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+ return nvmem_unregister(nvmem);
+}
+
+static struct platform_driver bcm_otpc_driver = {
+ .probe = bcm_otpc_probe,
+ .remove = bcm_otpc_remove,
+ .driver = {
+ .name = "brcm-otpc",
+ .of_match_table = bcm_otpc_dt_ids,
+ },
+};
+module_platform_driver(bcm_otpc_driver);
+
+MODULE_DESCRIPTION("Broadcom OTPC driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v1 1/3] dt-bindings: Document Broadcom OTP controller driver
From: Jonathan Richardson @ 2016-10-24 19:12 UTC (permalink / raw)
To: Srinivas Kandagatla, Maxime Ripard
Cc: linux-arm-kernel, linux-kernel, devicetree, Mark Rutland,
Rob Herring, Scott Branden, Ray Jui, bcm-kernel-feedback-list,
Jonathan Richardson, Jonathan Richardson, Scott Branden,
Oza Pawandeep
In-Reply-To: <1477336324-10543-1-git-send-email-jonathan.richardson@broadcom.com>
From: Jonathan Richardson <jonathar@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Oza Pawandeep <oza@broadcom.com>
Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
---
Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
diff --git a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
new file mode 100644
index 0000000..6462e12
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
@@ -0,0 +1,17 @@
+Broadcom OTP memory controller
+
+Required Properties:
+- compatible: "brcm,ocotp" for the first generation Broadcom OTPC which is used
+ in Cygnus and supports 32 bit read/write. Use "brcm,ocotp-v2" for the second
+ generation Broadcom OTPC which is used in SoC's such as Stingray and supports
+ 64-bit read/write.
+- reg: Base address of the OTP controller.
+- brcm,ocotp-size: Amount of memory available, in 32 bit words
+
+Example:
+
+otp: otp@0301c800 {
+ compatible = "brcm,ocotp";
+ reg = <0x0301c800 0x2c>;
+ brcm,ocotp-size = <2048>;
+};
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox