* Re: [PATCH v2] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2017-01-05 16:19 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Benoît Cousson
In-Reply-To: <1480713097-5931-1-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
* Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> [161202 13:11]:
> The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
> connected to port 2 of the OMAP EHCI controller. The board however has
> no EEPROM to store the ethernet MAC address, which is programmed by the
> boot loader.
>
> To allow Linux to use the same MAC address as the boot loader (or for
> that matter any fixed MAC address), we need a node in the device tree
> for the ethernet controller that the boot loader can update at runtime
> with a local-mac-address property. Add it, along with an alias for the
> ethernet controller to let the boot loader locate it easily.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> ---
> Changes since v1:
>
> - Renamed usb2 DT node to hub
Applying this finally into omap-for-v4.11/dt. Will post my related
patches using the hub naming shortly.
Regards,
Tony
--
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 2/3] ARM64: dts: exynos5433: add HDMI node
From: Javier Martinez Canillas @ 2017-01-05 16:21 UTC (permalink / raw)
To: Andrzej Hajda, linux-samsung-soc, Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski, Inki Dae,
Rob Herring, Mark Rutland, devicetree
In-Reply-To: <1483629943-31183-2-git-send-email-a.hajda@samsung.com>
Hello Andrzej,
On 01/05/2017 12:25 PM, Andrzej Hajda wrote:
> HDMI converts RGB/I80 signal from DECON_TV to HDMI/TMDS video stream.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v7 05/12] mux: support simplified bindings for single-user gpio mux
From: Peter Rosin @ 2017-01-05 16:21 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, Arnd Bergmann, Greg Kroah-Hartman,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483532187-28494-6-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 2017-01-04 13:16, Peter Rosin wrote:
> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
> ---
> drivers/mux/mux-core.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++--
> drivers/mux/mux-gpio.c | 56 ++--------------------------------
> include/linux/mux.h | 7 +++++
> 3 files changed, 89 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
> index 21da15a264ad..d887ae1c0e55 100644
> --- a/drivers/mux/mux-core.c
> +++ b/drivers/mux/mux-core.c
> @@ -15,6 +15,7 @@
> #include <linux/device.h>
> #include <linux/err.h>
> #include <linux/idr.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/module.h>
> #include <linux/mux.h>
> #include <linux/of.h>
> @@ -288,6 +289,63 @@ static struct mux_chip *of_find_mux_chip_by_node(struct device_node *np)
> return dev ? to_mux_chip(dev) : NULL;
> }
>
> +#ifdef CONFIG_MUX_GPIO
> +
> +static int mux_gpio_set(struct mux_control *mux, int state)
> +{
> + struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
> + int i;
> +
> + for (i = 0; i < mux_gpio->gpios->ndescs; i++)
> + mux_gpio->val[i] = (state >> i) & 1;
> +
> + gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
> + mux_gpio->gpios->desc,
> + mux_gpio->val);
> +
> + return 0;
> +}
> +
> +static const struct mux_control_ops mux_gpio_ops = {
> + .set = mux_gpio_set,
> +};
> +
> +struct mux_chip *mux_gpio_alloc(struct device *dev)
> +{
> + struct mux_chip *mux_chip;
> + struct mux_gpio *mux_gpio;
> + int pins;
> + int ret;
> +
> + pins = gpiod_count(dev, "mux");
> + if (pins < 0)
> + return ERR_PTR(pins);
> +
> + mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
> + pins * sizeof(*mux_gpio->val));
> + if (!mux_chip)
> + return ERR_PTR(-ENOMEM);
> +
> + mux_gpio = mux_chip_priv(mux_chip);
> + mux_gpio->val = (int *)(mux_gpio + 1);
> + mux_chip->ops = &mux_gpio_ops;
> +
> + mux_gpio->gpios = devm_gpiod_get_array(dev, "mux", GPIOD_OUT_LOW);
> + if (IS_ERR(mux_gpio->gpios)) {
> + ret = PTR_ERR(mux_gpio->gpios);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "failed to get gpios\n");
> + return ERR_PTR(ret);
> + }
> + WARN_ON(pins != mux_gpio->gpios->ndescs);
> + mux_chip->mux->states = 1 << pins;
> +
> + return mux_chip;
> +}
> +EXPORT_SYMBOL_GPL(mux_gpio_alloc);
> +
> +#endif /* CONFIG_MUX_GPIO */
> +
> struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
> {
> struct device_node *np = dev->of_node;
> @@ -307,9 +365,28 @@ struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
> ret = of_parse_phandle_with_args(np,
> "mux-controls", "#mux-control-cells",
> index, &args);
> +
> +#ifdef CONFIG_MUX_GPIO
> + if (ret == -ENOENT && !mux_name && gpiod_count(dev, "mux") > 0) {
> + mux_chip = mux_gpio_alloc(dev);
> + if (!IS_ERR(mux_chip)) {
> + ret = devm_mux_chip_register(dev, mux_chip);
> + if (ret < 0) {
> + dev_err(dev, "failed to register mux-chip\n");
> + return ERR_PTR(ret);
> + }
> + get_device(&mux_chip->dev);
> + return mux_chip->mux;
> + }
> +
> + ret = PTR_ERR(mux_chip);
> + }
> +#endif
> +
> if (ret) {
> - dev_err(dev, "%s: failed to get mux-control %s(%i)\n",
> - np->full_name, mux_name ?: "", index);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "%s: failed to get mux-control %s(%i)\n",
> + np->full_name, mux_name ?: "", index);
> return ERR_PTR(ret);
> }
>
> diff --git a/drivers/mux/mux-gpio.c b/drivers/mux/mux-gpio.c
> index 76b52bc63470..8a7bfbc0c4bb 100644
> --- a/drivers/mux/mux-gpio.c
> +++ b/drivers/mux/mux-gpio.c
> @@ -11,37 +11,12 @@
> */
>
> #include <linux/err.h>
> -#include <linux/gpio/consumer.h>
> #include <linux/module.h>
> #include <linux/mux.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/property.h>
Instead of moving the mux-gpio guts from mux-gpio.c to mux-core.c, I
will instead make CONFIG_MUX_GPIO a bool option (no module possible)
and call it from the mux-core. That will be cleaner and less of a
break of abstractions in my opinion.
Cheers,
Peter
> -struct mux_gpio {
> - struct gpio_descs *gpios;
> - int *val;
> -};
> -
> -static int mux_gpio_set(struct mux_control *mux, int state)
> -{
> - struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
> - int i;
> -
> - for (i = 0; i < mux_gpio->gpios->ndescs; i++)
> - mux_gpio->val[i] = (state >> i) & 1;
> -
> - gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
> - mux_gpio->gpios->desc,
> - mux_gpio->val);
> -
> - return 0;
> -}
> -
> -static const struct mux_control_ops mux_gpio_ops = {
> - .set = mux_gpio_set,
> -};
> -
> static const struct of_device_id mux_gpio_dt_ids[] = {
> { .compatible = "mux-gpio", },
> { /* sentinel */ }
> @@ -51,38 +26,13 @@ MODULE_DEVICE_TABLE(of, mux_gpio_dt_ids);
> static int mux_gpio_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *np = dev->of_node;
> struct mux_chip *mux_chip;
> - struct mux_gpio *mux_gpio;
> - int pins;
> u32 idle_state;
> int ret;
>
> - if (!np)
> - return -ENODEV;
> -
> - pins = gpiod_count(dev, "mux");
> - if (pins < 0)
> - return pins;
> -
> - mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
> - pins * sizeof(*mux_gpio->val));
> - if (!mux_chip)
> - return -ENOMEM;
> -
> - mux_gpio = mux_chip_priv(mux_chip);
> - mux_gpio->val = (int *)(mux_gpio + 1);
> - mux_chip->ops = &mux_gpio_ops;
> -
> - mux_gpio->gpios = devm_gpiod_get_array(dev, "mux", GPIOD_OUT_LOW);
> - if (IS_ERR(mux_gpio->gpios)) {
> - ret = PTR_ERR(mux_gpio->gpios);
> - if (ret != -EPROBE_DEFER)
> - dev_err(dev, "failed to get gpios\n");
> - return ret;
> - }
> - WARN_ON(pins != mux_gpio->gpios->ndescs);
> - mux_chip->mux->states = 1 << pins;
> + mux_chip = mux_gpio_alloc(dev);
> + if (IS_ERR(mux_chip))
> + return PTR_ERR(mux_chip);
>
> ret = device_property_read_u32(dev, "idle-state", &idle_state);
> if (ret >= 0) {
> diff --git a/include/linux/mux.h b/include/linux/mux.h
> index 3b9439927f11..3bfee23cfb8c 100644
> --- a/include/linux/mux.h
> +++ b/include/linux/mux.h
> @@ -241,4 +241,11 @@ struct mux_control *devm_mux_control_get(struct device *dev,
> */
> void devm_mux_control_put(struct device *dev, struct mux_control *mux);
>
> +struct mux_gpio {
> + struct gpio_descs *gpios;
> + int *val;
> +};
> +
> +struct mux_chip *mux_gpio_alloc(struct device *dev);
> +
> #endif /* _LINUX_MUX_H */
>
^ permalink raw reply
* Re: [PATCH v2] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Rob Herring @ 2017-01-05 16:27 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Tony Lindgren, Benoît Cousson
In-Reply-To: <1480713097-5931-1-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
On Fri, Dec 2, 2016 at 3:11 PM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
> connected to port 2 of the OMAP EHCI controller. The board however has
> no EEPROM to store the ethernet MAC address, which is programmed by the
> boot loader.
>
> To allow Linux to use the same MAC address as the boot loader (or for
> that matter any fixed MAC address), we need a node in the device tree
> for the ethernet controller that the boot loader can update at runtime
> with a local-mac-address property. Add it, along with an alias for the
> ethernet controller to let the boot loader locate it easily.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> ---
> Changes since v1:
>
> - Renamed usb2 DT node to hub
> ---
> arch/arm/boot/dts/omap3-beagle-xm.dts | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index 85e297ed0ea1..673cee2234b2 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -27,6 +27,7 @@
> aliases {
> display0 = &dvi0;
> display1 = &tv0;
> + ethernet = ðernet;
Sorry, just noticed this, but this should be dropped. It's not used
nor do we want an alias here.
Rob
P.S. The display ones are questionable, too. Only OMAP has them and
per platform alias names is not something we want.
--
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 10/12] ARM: dts: socfpga: add base fpga region and fpga bridges
From: Alan Tull @ 2017-01-05 16:28 UTC (permalink / raw)
To: Dinh Nguyen
Cc: Alan Tull, devicetree@vger.kernel.org, Dinh Nguyen,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1483575694-29599-11-git-send-email-dinguyen@kernel.org>
On Wed, Jan 4, 2017 at 6:21 PM, Dinh Nguyen <dinguyen@kernel.org> wrote:
> From: Alan Tull <atull@opensource.altera.com>
>
> Add h2f and lwh2f bridges.
> Add base FPGA Region to support DT overlays for FPGA programming.
> Add l3regs.
>
> Signed-off-by: Alan Tull <atull@opensource.altera.com>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
> ---
> arch/arm/boot/dts/socfpga.dtsi | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index de29172..dccc281 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -93,6 +93,16 @@
> };
> };
>
> + base_fpga_region {
> + compatible = "fpga-region";
> + fpga-mgr = <&fpgamgr0>;
> + fpga-bridges = <&fpga_bridge0>, <&fpga_bridge1>;
Hi Dinh,
We want to get rid of the 'fpga-bridges' line.
> +
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + ranges = <0 0xff200000 0x100000>;
Should get rid of the ranges line here too. The 'fpga-bridges' and
'ranges' line can be added in the overlay.
Alan
> + };
> +
> can0: can@ffc00000 {
> compatible = "bosch,d_can";
> reg = <0xffc00000 0x1000>;
> @@ -513,6 +523,22 @@
> };
> };
>
> + fpga_bridge0: fpga_bridge@ff400000 {
> + compatible = "altr,socfpga-lwhps2fpga-bridge";
> + reg = <0xff400000 0x100000>;
> + resets = <&rst LWHPS2FPGA_RESET>;
> + reset-names = "lwhps2fpga";
> + clocks = <&l4_main_clk>;
> + };
> +
> + fpga_bridge1: fpga_bridge@ff500000 {
> + compatible = "altr,socfpga-hps2fpga-bridge";
> + reg = <0xff500000 0x10000>;
> + resets = <&rst HPS2FPGA_RESET>;
> + reset-names = "hps2fpga";
> + clocks = <&l4_main_clk>;
> + };
> +
> fpgamgr0: fpgamgr@ff706000 {
> compatible = "altr,socfpga-fpga-mgr";
> reg = <0xff706000 0x1000
> @@ -694,6 +720,11 @@
> arm,prefetch-offset = <7>;
> };
>
> + l3regs@0xff800000 {
> + compatible = "altr,l3regs", "syscon";
> + reg = <0xff800000 0x1000>;
> + };
> +
> mmc: dwmmc0@ff704000 {
> compatible = "altr,socfpga-dw-mshc";
> reg = <0xff704000 0x1000>;
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree
From: Bjorn Andersson @ 2017-01-05 16:30 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Jingoo Han, devicetree,
linux-kernel, linux-iio, linux-leds, Bjorn Andersson
In-Reply-To: <20170105074952.GG24225@dell>
On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:
> On Wed, 04 Jan 2017, Bjorn Andersson wrote:
>
> > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> >
> > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > >
> > > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > >
> > > > Implement support for initialization of the lm3533 driver core and
> > > > probing child devices from Device Tree.
> > > >
> >
> > [..]
> >
> > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > > > lm3533_device_bl_init(lm3533);
> > > > lm3533_device_led_init(lm3533);
> > > >
> > > > + if (lm3533->dev->of_node) {
> > > > + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > + lm3533->dev);
> > > > + }
> > >
> > > I think it's save to call of_platform_populate(), even if !of_node.
> > > It will just fail and return an error code, which you are ignoring
> > > anyway.
> > >
> >
> > I thought so too, but that's apparently how you trigger probing children
> > of the root node. So we're stuck with a conditional.
>
> Ah, so this is to protect against the case where DT is present, but a
> node for this device is not (or is disabled), so is left unprobed.
> Then the bind is initiated via I2C? Or something else?
>
In the event that a new lm3533 is spawned from sysfs we would not have
platform_data when entering lm3533_device_init() and just bail early.
Therefor, this issue would be limited to the odd case of lm3533 being
initiated from code (e.g. a board file) on a DT enabled system. In which
case it will create and probe new devices from the root of the DT.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v4 2/2] dt-bindings: Add DT bindings info for FlexRM ring manager
From: Rob Herring @ 2017-01-05 16:32 UTC (permalink / raw)
To: Anup Patel
Cc: Jassi Brar, Mark Rutland, Ray Jui, Scott Branden, Pramod KUMAR,
Rob Rice, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
bcm-kernel-feedback-list@broadcom.com
In-Reply-To: <1483614475-3442-3-git-send-email-anup.patel@broadcom.com>
On Thu, Jan 5, 2017 at 5:07 AM, Anup Patel <anup.patel@broadcom.com> wrote:
> This patch adds device tree bindings document for the FlexRM
> ring manager found on Broadcom iProc SoCs.
>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> ---
> .../bindings/mailbox/brcm,iproc-flexrm-mbox.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-flexrm-mbox.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/3] ARM64: dts: exynos5433-tm2: enable HDMI/TV path
From: Javier Martinez Canillas @ 2017-01-05 16:33 UTC (permalink / raw)
To: Andrzej Hajda, linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz, Marek Szyprowski, Inki Dae,
Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483629943-31183-3-git-send-email-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hello Andrzej,
On 01/05/2017 12:25 PM, Andrzej Hajda wrote:
> TV path consist of following interconnected components:
> - DECON_TV - display controller,
> - HDMI - video signal converter RGB / HDMI,
> - MHL - video signal converter HDMI / MHL,
> - DDC - i2c slave device for EDID reading (on hsi2c_11 bus).
>
> The same path/configuration is used by TM2E board and is
> automatically applied thanks to dts file inclusion.
>
> Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 71 +++++++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
[snip]
>
> +&hdmi {
> + hpd-gpio = <&gpa3 0 0>;
Same comment than interrupts, please use the GPIO_ACTIVE_HIGH here.
The rest looks good to me.
Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 10/12] ARM: dts: socfpga: add base fpga region and fpga bridges
From: Alan Tull @ 2017-01-05 16:34 UTC (permalink / raw)
To: Dinh Nguyen
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dinh Nguyen,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Alan Tull
In-Reply-To: <CANk1AXSbqohp73xHpp7e9-37d61ZB-dRAPAFc2eQGRYUnvB+0w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Jan 5, 2017 at 10:28 AM, Alan Tull <atull-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Jan 4, 2017 at 6:21 PM, Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> From: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>>
>> Add h2f and lwh2f bridges.
>> Add base FPGA Region to support DT overlays for FPGA programming.
>> Add l3regs.
>>
>> Signed-off-by: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
>> Signed-off-by: Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> ---
>> arch/arm/boot/dts/socfpga.dtsi | 31 +++++++++++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
>> index de29172..dccc281 100644
>> --- a/arch/arm/boot/dts/socfpga.dtsi
>> +++ b/arch/arm/boot/dts/socfpga.dtsi
>> @@ -93,6 +93,16 @@
>> };
>> };
>>
>> + base_fpga_region {
>> + compatible = "fpga-region";
>> + fpga-mgr = <&fpgamgr0>;
>> + fpga-bridges = <&fpga_bridge0>, <&fpga_bridge1>;
>
> Hi Dinh,
>
> We want to get rid of the 'fpga-bridges' line.
>
>> +
>> + #address-cells = <0x1>;
>> + #size-cells = <0x1>;
>> + ranges = <0 0xff200000 0x100000>;
>
> Should get rid of the ranges line here too. The 'fpga-bridges' and
> 'ranges' line can be added in the overlay.
>
> Alan
>
>> + };
>> +
>> can0: can@ffc00000 {
>> compatible = "bosch,d_can";
>> reg = <0xffc00000 0x1000>;
>> @@ -513,6 +523,22 @@
>> };
>> };
>>
>> + fpga_bridge0: fpga_bridge@ff400000 {
>> + compatible = "altr,socfpga-lwhps2fpga-bridge";
>> + reg = <0xff400000 0x100000>;
>> + resets = <&rst LWHPS2FPGA_RESET>;
>> + reset-names = "lwhps2fpga";
The driver doesn't need 'reset-names' here or below for fpga_bridge1.
>> + clocks = <&l4_main_clk>;
>> + };
>> +
>> + fpga_bridge1: fpga_bridge@ff500000 {
>> + compatible = "altr,socfpga-hps2fpga-bridge";
>> + reg = <0xff500000 0x10000>;
>> + resets = <&rst HPS2FPGA_RESET>;
>> + reset-names = "hps2fpga";
>> + clocks = <&l4_main_clk>;
>> + };
>> +
>> fpgamgr0: fpgamgr@ff706000 {
>> compatible = "altr,socfpga-fpga-mgr";
>> reg = <0xff706000 0x1000
>> @@ -694,6 +720,11 @@
>> arm,prefetch-offset = <7>;
>> };
>>
>> + l3regs@0xff800000 {
>> + compatible = "altr,l3regs", "syscon";
>> + reg = <0xff800000 0x1000>;
>> + };
>> +
>> mmc: dwmmc0@ff704000 {
>> compatible = "altr,socfpga-dw-mshc";
>> reg = <0xff704000 0x1000>;
>> --
>> 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
--
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 V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rob Herring @ 2017-01-05 16:34 UTC (permalink / raw)
To: Johannes Berg
Cc: Rafał Miłecki, linux-wireless, Martin Blumenstingl,
Felix Fietkau, Arend van Spriel, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <1483617089.4394.13.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On Thu, Jan 5, 2017 at 5:51 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Do I take that to mean that we'll merge it through the subsystem tree,
> and not go through some common DT tree?
Yes, that's generally the case when bindings are in a series with
driver changes.
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
* [PATCHv2 0/3] Configure USB Ethernet mac for omap4 and 5
From: Tony Lindgren @ 2017-01-05 16:37 UTC (permalink / raw)
To: Tony Lindgren
Cc: Benoît Cousson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi,
Here are these patches reposted using the hub naming.
Regards,
Tony
Tony Lindgren (3):
ARM: dts: pandaboard: Allow bootloader to configure USB Ethernet MAC
ARM: dts: omap5-uevm: Allow bootloader to configure USB Ethernet MAC
ARM: dts: omap5-igep0050: Allow bootloader to configure USB Ethernet
MAC
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 ++++++++++++++++
arch/arm/boot/dts/omap5-igep0050.dts | 21 +++++++++++++++++++++
arch/arm/boot/dts/omap5-uevm.dts | 21 +++++++++++++++++++++
3 files changed, 58 insertions(+)
--
2.11.0
--
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 1/3] ARM: dts: pandaboard: Allow bootloader to configure USB Ethernet MAC
From: Tony Lindgren @ 2017-01-05 16:37 UTC (permalink / raw)
To: Tony Lindgren
Cc: Benoît Cousson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Laurent Pinchart
In-Reply-To: <20170105163703.1982-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Inspired by a patch for beagleboard xm by Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>, similar patch also works for
pandaboard. The only difference is that the hub is address 1 instead
of 2.
Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,6 +16,7 @@
aliases {
display0 = &dvi0;
display1 = &hdmi0;
+ ethernet = ðernet;
};
leds: leds {
@@ -520,6 +521,21 @@
&usbhsehci {
phys = <&hsusb1_phy>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@1 {
+ compatible = "usb424,9514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb424,ec00";
+ reg = <1>;
+ };
+ };
};
&dss {
--
2.11.0
--
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 2/3] ARM: dts: omap5-uevm: Allow bootloader to configure USB Ethernet MAC
From: Tony Lindgren @ 2017-01-05 16:37 UTC (permalink / raw)
To: Tony Lindgren
Cc: Benoît Cousson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Laurent Pinchart
In-Reply-To: <20170105163703.1982-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Note that with 9730 the wiring is different compared to 9514 found on
beagleboard xm for example.
On beagleboard xm we have:
/sys/bus/usb/devices/1-2 hub
/sys/bus/usb/devices/1-2.1 9514
While on omap5-uevm we have:
/sys/bus/usb/devices/1-2 hub
/sys/bus/usb/devices/1-3 9730
Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap5-uevm.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -18,6 +18,10 @@
reg = <0 0x80000000 0 0x7f000000>; /* 2032 MB */
};
+ aliases {
+ ethernet = ðernet;
+ };
+
leds {
compatible = "gpio-leds";
led1 {
@@ -164,6 +168,23 @@
>;
};
+&usbhsehci {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@2 {
+ compatible = "usb424,3503";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ ethernet: usbether@3 {
+ compatible = "usb424,9730";
+ reg = <3>;
+ };
+};
+
&wlcore {
compatible = "ti,wl1837";
};
--
2.11.0
--
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 3/3] ARM: dts: omap5-igep0050: Allow bootloader to configure USB Ethernet MAC
From: Tony Lindgren @ 2017-01-05 16:37 UTC (permalink / raw)
To: Tony Lindgren
Cc: Benoît Cousson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Laurent Pinchart
In-Reply-To: <20170105163703.1982-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
This is slightly different wiring compared to omap5-uevm or pandaboard:
/sys/bus/usb/devices/3-2 hub
/sys/bus/usb/devices/3-2.3 7500
Cc: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap5-igep0050.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-igep0050.dts b/arch/arm/boot/dts/omap5-igep0050.dts
--- a/arch/arm/boot/dts/omap5-igep0050.dts
+++ b/arch/arm/boot/dts/omap5-igep0050.dts
@@ -19,6 +19,10 @@
reg = <0x0 0x80000000 0 0x7f000000>; /* 2032 MB */
};
+ aliases {
+ ethernet = ðernet;
+ };
+
gpio_keys {
compatible = "gpio-keys";
pinctrl-0 = <&power_button_pin>;
@@ -116,3 +120,20 @@
OMAP5_IOPAD(0x1ca, PIN_OUTPUT | MUX_MODE6) /* perslimbus2_clock.gpio5_145 */
>;
};
+
+&usbhsehci {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@2 {
+ compatible = "usb424,3503";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@3 {
+ compatible = "usb424,7500";
+ reg = <3>;
+ };
+ };
+};
--
2.11.0
--
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 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Rob Herring @ 2017-01-05 16:39 UTC (permalink / raw)
To: Appana Durga Kedareswara Rao
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org,
Soren Brinkmann,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
luis-HiykPkW1eAzzDCI4PIEvbQC/G2K4zDHf@public.gmane.org,
Jose.Abreu-HKixBCOQz3hWk0Htik3J/w@public.gmane.org,
dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <C246CAC1457055469EF09E3A7AC4E11A4A660958-4lKfpRxZ5enZMOc0yg5rMog+Gb3gawCHQz34XiSyOiE@public.gmane.org>
On Wed, Jan 4, 2017 at 11:00 AM, Appana Durga Kedareswara Rao
<appana.durga.rao-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
> Hi Rob,
>
> Thanks for the review....
>
>> On Wed, Jan 04, 2017 at 07:05:53PM +0530, Kedareswara rao Appana wrote:
>> > When VDMA is configured for more than one frame in the h/w for example
>> > h/w is configured for n number of frames and user Submits n number of
>> > frames and triggered the DMA using issue_pending API.
>> > In the current driver flow we are submitting one frame at a time but
>> > we should submit all the n number of frames at one time as the h/w Is
>> > configured for n number of frames.
>>
>> Please fix run-on sentences, capitalization, and word wrapping.
>
> Sure will fix in the next version....
>
> [Snip]
> -- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
>> > +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
>> > @@ -66,6 +66,8 @@ Optional child node properties:
>> > Optional child node properties for VDMA:
>> > - xlnx,genlock-mode: Tells Genlock synchronization is
>> > enabled/disabled in hardware.
>> > +- xlnx,fstore-config: Tells Whether Frame Store Configuration is
>> > + enabled/disabled in hardware.
>>
>> What's the default (when not present)? That should be the most common case.
>> Looks like the code treats this as bool, but that's not clear here. The name is not
>> clear what it is doing. Enabling or disabling the feature?
>
> Default value is zero...
> When this property is present it tells hardware is configured for frame store configuration.
So most people will not want "frame store configuration"?
> Will fix the explanation part in the next version like below.
> xlnx,fstore-config: Tells hardware is configured for frame store configuration.
> Is the above explanation clear???
No, I mean make it obvious from the name of the property:
xlnx,fstore-config-enable or xlnx,fstore-enable
And the description needs to say it is boolean.
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] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2017-01-05 16:39 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, linux-omap,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Benoît Cousson
In-Reply-To: <CAL_Jsq+M7RWiytEA7zPZvR+7CK37WCxN5ZBOQkpjdswjLHL4fA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170105 08:28]:
> On Fri, Dec 2, 2016 at 3:11 PM, Laurent Pinchart
> <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> > The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
> > connected to port 2 of the OMAP EHCI controller. The board however has
> > no EEPROM to store the ethernet MAC address, which is programmed by the
> > boot loader.
> >
> > To allow Linux to use the same MAC address as the boot loader (or for
> > that matter any fixed MAC address), we need a node in the device tree
> > for the ethernet controller that the boot loader can update at runtime
> > with a local-mac-address property. Add it, along with an alias for the
> > ethernet controller to let the boot loader locate it easily.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> > ---
> > Changes since v1:
> >
> > - Renamed usb2 DT node to hub
> > ---
> > arch/arm/boot/dts/omap3-beagle-xm.dts | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
> > index 85e297ed0ea1..673cee2234b2 100644
> > --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> > +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> > @@ -27,6 +27,7 @@
> > aliases {
> > display0 = &dvi0;
> > display1 = &tv0;
> > + ethernet = ðernet;
>
> Sorry, just noticed this, but this should be dropped. It's not used
> nor do we want an alias here.
OK, will update locally as I have not pushed out yet.
> P.S. The display ones are questionable, too. Only OMAP has them and
> per platform alias names is not something we want.
OK. What about the mmc ones? Otherwise the MMC devices keep moving
around depending on the kernel version..
Tony
--
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 01/22] dt-bindings: iio: adc: add AXP20X/AXP22X ADC DT binding
From: Maxime Ripard @ 2017-01-05 16:40 UTC (permalink / raw)
To: Quentin Schulz
Cc: mark.rutland, devicetree, lars, linux-pm, linux-iio, linux-kernel,
sre, linux, wens, robh+dt, linux-arm-kernel, pmeerw, knaack.h,
bonbons, lee.jones, thomas.petazzoni, jic23, icenowy
In-Reply-To: <20170102163723.7939-2-quentin.schulz@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 654 bytes --]
On Mon, Jan 02, 2017 at 05:37:01PM +0100, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
> battery voltage, battery charge and discharge currents, AC-in and VBUS
> voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
>
> This adds the device tree binding documentation for the X-Powers AXP20X
> and AXP22X PMICs ADCs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 03/22] iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
From: Maxime Ripard @ 2017-01-05 16:46 UTC (permalink / raw)
To: Quentin Schulz
Cc: Mark Rutland, devicetree, Lars-Peter Clausen, open list:THERMAL,
linux-iio, linux-kernel, Sebastian Reichel, Russell King,
Chen-Yu Tsai, Rob Herring, linux-arm-kernel,
Peter Meerwald-Stadler, knaack.h, Bruno Prémont, Lee Jones,
Thomas Petazzoni, Jonathan Cameron, Icenowy Zheng
In-Reply-To: <cf4590d1-5381-f1da-7271-e6e7fee0c479@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 1415 bytes --]
On Thu, Jan 05, 2017 at 10:50:33AM +0100, Quentin Schulz wrote:
> >>>> +static int axp20x_remove(struct platform_device *pdev)
> >>>> +{
> >>>> + struct axp20x_adc_iio *info;
> >>>> + struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> >>>> +
> >>>> + info = iio_priv(indio_dev);
> >>>
> >>> Nit: you could just reverse the 2 declarations above and join this
> >>> line after struct axp20x_adc_iio *info;
> >>>
> >>>> + regmap_write(info->regmap, AXP20X_ADC_EN1, 0);
> >>>> + regmap_write(info->regmap, AXP20X_ADC_EN2, 0);
> >>>
> >>> The existing VBUS power supply driver enables the VBUS ADC bits itself,
> >>> and does not check them later on. This means if one were to remove this
> >>> axp20x-adc module, the voltage/current readings in the VBUS power supply
> >>> would be invalid. Some sort of workaround would be needed here in this
> >>> driver of the VBUS driver.
> >>>
> >>
> >> That would be one reason to migrate the VBUS driver to use the IIO
> >> channels, wouldn't it?
> >
> > It is, preferably without changing the device tree.
> >
>
> Yes, of course.
Note that you can have something like a test for the iio channel
property in the VBUS driver, and keep the old behaviour in the case
where we wouldn't have it.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: am335x-chilisom: Wakeup from RTC-only state by power on event
From: Tony Lindgren @ 2017-01-05 16:47 UTC (permalink / raw)
To: Marcin Niestroj
Cc: Benoît Cousson, Rob Herring, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161209113327.19727-1-m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
* Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org> [161209 03:33]:
> On chiliSOM TPS65217 nWAKEUP pin is connected to AM335x internal RTC
> EXT_WAKEUP input. In RTC-only state TPS65217 is notifying about power on
> events (such as power buton presses) by setting nWAKEUP output
> low. After that it waits 5s for proper device boot. Currently it doesn't
> happen, as the processor doesn't listen for such events. Consequently
> TPS65217 changes state from SLEEP (RTC-only state) to OFF.
>
> Enable EXT_WAKEUP input of AM335x's RTC, so the processor can properly
> detect power on events and recover immediately from RTC-only states,
> without powering off RTC and losing time.
Applying into omap-for-v4.11/dt thanks.
Tony
--
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] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Laurent Pinchart @ 2017-01-05 16:48 UTC (permalink / raw)
To: Tony Lindgren
Cc: Rob Herring, linux-omap,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Benoît Cousson
In-Reply-To: <20170105163928.GD4310-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Hello,
On Thursday 05 Jan 2017 08:39:29 Tony Lindgren wrote:
> * Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170105 08:28]:
> > On Fri, Dec 2, 2016 at 3:11 PM, Laurent Pinchart wrote:
> >> The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
> >> connected to port 2 of the OMAP EHCI controller. The board however has
> >> no EEPROM to store the ethernet MAC address, which is programmed by the
> >> boot loader.
> >>
> >> To allow Linux to use the same MAC address as the boot loader (or for
> >> that matter any fixed MAC address), we need a node in the device tree
> >> for the ethernet controller that the boot loader can update at runtime
> >> with a local-mac-address property. Add it, along with an alias for the
> >> ethernet controller to let the boot loader locate it easily.
> >>
> >> Signed-off-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> >> ---
> >> Changes since v1:
> >>
> >> - Renamed usb2 DT node to hub
> >> ---
> >>
> >> arch/arm/boot/dts/omap3-beagle-xm.dts | 16 ++++++++++++++++
> >> 1 file changed, 16 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> >> b/arch/arm/boot/dts/omap3-beagle-xm.dts index
> >> 85e297ed0ea1..673cee2234b2 100644
> >> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> >> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> >> @@ -27,6 +27,7 @@
> >> aliases {
> >> display0 = &dvi0;
> >> display1 = &tv0;
> >> + ethernet = ðernet;
> >
> > Sorry, just noticed this, but this should be dropped. It's not used
> > nor do we want an alias here.
>
> OK, will update locally as I have not pushed out yet.
The ethernet alias is used by U-Boot to locate the ethernet controller and
update the MAC address.
> > P.S. The display ones are questionable, too. Only OMAP has them and
> > per platform alias names is not something we want.
>
> OK. What about the mmc ones? Otherwise the MMC devices keep moving
> around depending on the kernel version..
--
Regards,
Laurent Pinchart
--
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] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2017-01-05 16:51 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Rob Herring, linux-omap,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Benoît Cousson
In-Reply-To: <2557392.58vudoaMIY@avalon>
* Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> [170105 08:49]:
> On Thursday 05 Jan 2017 08:39:29 Tony Lindgren wrote:
> > * Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [170105 08:28]:
> > > On Fri, Dec 2, 2016 at 3:11 PM, Laurent Pinchart wrote:
> > >> The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
> > >> connected to port 2 of the OMAP EHCI controller. The board however has
> > >> no EEPROM to store the ethernet MAC address, which is programmed by the
> > >> boot loader.
> > >>
> > >> To allow Linux to use the same MAC address as the boot loader (or for
> > >> that matter any fixed MAC address), we need a node in the device tree
> > >> for the ethernet controller that the boot loader can update at runtime
> > >> with a local-mac-address property. Add it, along with an alias for the
> > >> ethernet controller to let the boot loader locate it easily.
> > >>
> > >> Signed-off-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> > >> ---
> > >> Changes since v1:
> > >>
> > >> - Renamed usb2 DT node to hub
> > >> ---
> > >>
> > >> arch/arm/boot/dts/omap3-beagle-xm.dts | 16 ++++++++++++++++
> > >> 1 file changed, 16 insertions(+)
> > >>
> > >> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> > >> b/arch/arm/boot/dts/omap3-beagle-xm.dts index
> > >> 85e297ed0ea1..673cee2234b2 100644
> > >> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> > >> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> > >> @@ -27,6 +27,7 @@
> > >> aliases {
> > >> display0 = &dvi0;
> > >> display1 = &tv0;
> > >> + ethernet = ðernet;
> > >
> > > Sorry, just noticed this, but this should be dropped. It's not used
> > > nor do we want an alias here.
> >
> > OK, will update locally as I have not pushed out yet.
>
> The ethernet alias is used by U-Boot to locate the ethernet controller and
> update the MAC address.
OK let's wait a bit on this one then.
Tony
--
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 03/22] iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
From: Maxime Ripard @ 2017-01-05 16:51 UTC (permalink / raw)
To: Quentin Schulz
Cc: mark.rutland, devicetree, lars, linux-pm, linux-iio, linux-kernel,
sre, linux, wens, robh+dt, linux-arm-kernel, pmeerw, knaack.h,
bonbons, lee.jones, thomas.petazzoni, jic23, icenowy
In-Reply-To: <20170102163723.7939-4-quentin.schulz@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 1575 bytes --]
On Mon, Jan 02, 2017 at 05:37:03PM +0100, Quentin Schulz wrote:
> + switch (axp20x_id) {
> + case AXP209_ID:
> + indio_dev->info = &axp20x_adc_iio_info;
> + indio_dev->num_channels = ARRAY_SIZE(axp20x_adc_channels);
> + indio_dev->channels = axp20x_adc_channels;
> +
> + /* Enable the ADCs on IP */
> + regmap_write(info->regmap, AXP20X_ADC_EN1, AXP20X_ADC_EN1_MASK);
> +
> + /* Enable GPIO0/1 and internal temperature ADCs */
> + regmap_update_bits(info->regmap, AXP20X_ADC_EN2,
> + AXP20X_ADC_EN2_MASK, AXP20X_ADC_EN2_MASK);
> +
> + /* Configure ADCs rate */
> + regmap_update_bits(info->regmap, AXP20X_ADC_RATE,
> + AXP20X_ADC_RATE_MASK, AXP20X_ADC_RATE_50HZ);
> + break;
> +
> + case AXP221_ID:
> + indio_dev->info = &axp22x_adc_iio_info;
> + indio_dev->num_channels = ARRAY_SIZE(axp22x_adc_channels);
> + indio_dev->channels = axp22x_adc_channels;
> +
> + /* Enable the ADCs on IP */
> + regmap_write(info->regmap, AXP20X_ADC_EN1, AXP22X_ADC_EN1_MASK);
> +
> + /* Configure ADCs rate */
> + regmap_update_bits(info->regmap, AXP20X_ADC_RATE,
> + AXP20X_ADC_RATE_MASK, AXP22X_ADC_RATE_200HZ);
> + break;
> +
> + default:
> + return -EINVAL;
> + }
I'm not a big fan of those IDs. It always ends up with a ever
increasing list of cases without any consolidation.
In this case, the only thing you need is a list of pointers and values
that can definitely be stored in a structure.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Myir AM437x Rico board support (DTS) for Linux mainline 4.9 and 4.4 Ti Processor SDK 03.02.00.05
From: Pavel Pisa @ 2017-01-05 16:54 UTC (permalink / raw)
To: Tony Lindgren
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-xIg/pKzrS19vn6HldHNs0ANdhmdF6hFW, Dan Murphy,
support-0A6ZgDe55FJWk0Htik3J/w, Tomi Valkeinen
Hello Tony and others,
I have found some personal time during holydays[*] and proceed
furhers with RICO board support for perspective kernel versions.
I have prepared a device tree which provides quite complete
board support for the most of peripherals found on MyIR
AM437x Ricoboard. I have tested the kernel on the real board
which I have bought for myself to do testing and can contribute
previous work to to mainline.
LEDs, Ethernet, LEDs, SDcard, eMMC, onboard SPI NVM etc.
works. Generally the AM437x mainline support is great except
for SGX. It has been pleasant to work with it. I used TFTP boot
and ramdisk overlay over NFS exported Debian Jessie RO chroot
install.
Only significant missing piece is HDMI support. I have put
setup which I prepared for Ti kernels to device-tree.
But mainline supports SII9022 HDMI encoder only by
drivers/gpu/drm/bridge/sii902x.c
but OMAP DSS changes "sil,sii9022" in device-tree
to omapdss,sil,sii9022 which seems to be customized
version found in Texas Instruments tree
drivers/gpu/drm/omapdrm/displays/encoder-sii9022-video.c
Do you know if there are some plans to support combination
of this driver or include customized version in mainline
for OMAP?
I expect that non accelerated graphic with parallel
LCD panel would work with 4.9 mainline kernel and
the prepared device tree if #if 0 is changed to #if 1.
The 4.9 mainline support files can be found there
http://pikron.com/files/linux/rico/linux-4.9/am437x-myir-ricoboard.dts
http://pikron.com/files/linux/rico/linux-4.9/am437x-myir-ricoboard.dtb
http://pikron.com/files/linux/rico/linux-4.9/config-4.9-mainline-myir-ricoboard
I would be happy if they can help others, some feedback
and cooperation would be great as well. I would be happy
to contribute DTS to mainline if it is found acceptable.
I can prepare version without HDMI or complete DSS section
if actual untested/able section is unacceptable.
Because of missing HDMI support and attempt to test SGX
accelerated support, I have tried official Ti
Processor SDK image for AM437x (am437x-evm-linux-03.02.00.05).
I have prepared DTS and tested it with my overlay enabled
kernel and Debian and Ti root filesystems as well as with
original Ti kernel.
There are files for use with HDMI connected monitor
files/linux/rico/linux-ti-4.4/am437x-myir-ricoboard-hdmi.dts
files/linux/rico/linux-ti-4.4/am437x-myir-ricoboard-hdmi.dtb
files/linux/rico/linux-ti-4.4/config-ti-4.4-myir-ricoboard
and another set for parallel LCD panel (untested)
files/linux/rico/linux-ti-4.4/am437x-myir-ricoboard.dts
files/linux/rico/linux-ti-4.4/am437x-myir-ricoboard.dtb
I have managed to build SGX driver for my kernel configuration
and from the testing of Ti image it seem to be used same way
as for original Ti kernel build.
I have no luck with accelerated Xorg. But Ti release notes
states that Xorg support is missing in 03.02.00.05.
There is question if it is permanent status or if there is some
change.
Is there chance that Ti includes this prepared DTS in their
kernel branch?
For sure mainline 4.9 support is even more interesting
for me and future.
Best wishes,
Pavel
[*] Our company partner cares mainly (and may be pays something)
for my work on maintenance of ancient MyIR Linux 3.12.10 kernel
in their products. And MyIR company does not seem to really
care about users and updates at all even if the enhancements
are sent them for free. Typical experience but great thing about
this board is that a schematic diagram is provided which makes
possible to develop proper support.
--
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 17/22] power: supply: add battery driver for AXP20X and AXP22X PMICs
From: Maxime Ripard @ 2017-01-05 17:02 UTC (permalink / raw)
To: Quentin Schulz
Cc: mark.rutland, devicetree, lars, linux-pm, linux-iio, linux-kernel,
sre, linux, wens, robh+dt, linux-arm-kernel, pmeerw, knaack.h,
bonbons, lee.jones, thomas.petazzoni, jic23, icenowy
In-Reply-To: <20170102163723.7939-18-quentin.schulz@free-electrons.com>
[-- Attachment #1.1: Type: text/plain, Size: 1726 bytes --]
On Mon, Jan 02, 2017 at 05:37:17PM +0100, Quentin Schulz wrote:
> + /*
> + * IIO framework gives mV but Power Supply framework gives µV.
> + */
> + val->intval *= 1000;
s/gives/wants/ ?
> +static int axp20x_battery_set_max_voltage(struct axp20x_batt_ps *axp20x_batt,
> + int val)
> +{
> + switch (val) {
> + case 4100000:
> + return regmap_update_bits(axp20x_batt->regmap,
> + AXP20X_CHRG_CTRL1,
> + AXP20X_CHRG_CTRL1_TGT_VOLT,
> + AXP20X_CHRG_CTRL1_TGT_4_1V);
> + case 4150000:
> + if (axp20x_batt->axp_id == AXP221_ID)
> + return -EINVAL;
> +
> + return regmap_update_bits(axp20x_batt->regmap,
> + AXP20X_CHRG_CTRL1,
> + AXP20X_CHRG_CTRL1_TGT_VOLT,
> + AXP20X_CHRG_CTRL1_TGT_4_15V);
> + case 4200000:
> + return regmap_update_bits(axp20x_batt->regmap,
> + AXP20X_CHRG_CTRL1,
> + AXP20X_CHRG_CTRL1_TGT_VOLT,
> + AXP20X_CHRG_CTRL1_TGT_4_2V);
> + default:
> + /*
> + * AXP20x max voltage can be set to 4.36V and AXP22X max voltage
> + * can be set to 4.22V and 4.24V, but these voltages are too
> + * high for Lithium based batteries (AXP PMICs are supposed to
> + * be used with these kinds of battery).
> + */
> + return -EINVAL;
> + }
Since all your calls to regmap are the same, something like:
case 4100000:
val = AXP20X_CHRG_CTRL1_TGT_4_1V;
break;
case 4150000:
val = AXP20X_CHRG_CTRL1_TGT_4_15V;
break;
regmap_update_bits(axp20x_batt->regmap, AXP20X_CHRG_CTRL1,
AXP20X_CHRG_CTRL1_TGT_VOLT, val);
It would also get rid of your warnings in checkpatch.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Robin Murphy @ 2017-01-05 17:03 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Jordan Crouse
In-Reply-To: <20170105160755.GN679-5wv7dgnIgG8@public.gmane.org>
On 05/01/17 16:07, Will Deacon wrote:
> On Thu, Jan 05, 2017 at 03:32:50PM +0000, Robin Murphy wrote:
>> On 05/01/17 14:47, Will Deacon wrote:
>>> On Thu, Jan 05, 2017 at 02:07:31PM +0000, Mark Rutland wrote:
>>>> Ok. It would be good to elaborate on what "stalling is useable" means in
>>>> the property description. i.e. what specificallty the implementation and
>>>> integration need to ensure.
>>>
>>> We can describe some of those guarantees in the property description, but
>>> it's difficult to enumerate them exhaustively. For example, you wouldn't
>>> want stalling to lead to data corruption, denial of service, or for the
>>> thing to catch fire, but having those as explicit requirements is a bit
>>> daft. It's also impossible to check that you thought of everything.
>>>
>>> Aside from renaming the option, I'm really after an opinion on whether
>>> it's better to have one property or combine it with the compatible
>>> string, because I can see benefits of both and don't much care either
>>> way.
>>
>> The SMMU implementation side of the decision (i.e. independence of IRQ
>> assertion vs. SS) seems like exactly the sort of stuff the compatible
>> string already has covered. The integration side I'm less confident can
>> be described this way at all - the "this device definitely won't go
>> wrong if stalled for an indefinite length of time" is inherently a
>> per-master thing, so a single property on the SMMU implying that for
>> every device connected to it seems a bit optimistic, and breaks down as
>> soon as you have one device in the system for which that isn't true (a
>> PCI root complex, say), even if that guy's traffic never crosses paths
>> with whichever few devices you actually care about using stalls with.
>>
>> I think this needs to be some kind of "arm,smmu-stall-safe" property
>> placed on individual master device nodes (mad idea: or even an extra
>> cell of flags in the IOMMU specifier) to encapsulate both that the given
>> device itself is OK with being stalled, and that it's integrated in such
>> a way that its stalled transactions cannot disrupt any *other* device
>> (e.g. it has a TBU all to itself). Then upon initialising a context bank
>> on a suitable SMMU implementation, we set CFCFG based on whatever device
>> is being attached to the corresponding domain, and refuse any subsequent
>> attempts to attach a non-stallable device to a stalling domain (and
>> possibly even vice-versa).
>
> If we're going to add per-master properties, I'd *really* like them to be
> independent of the IOMMU in use. That is, we should be able to re-use this
> property as part of supporting SVM for platform devices in future.
I'd argue that they are still fairly separate things despite the
overlap: stalling is a specific ARM SMMU architecture thing (in both
architectures) which may be used for purposes unrelated to SVM;
conversely SVM implemented via PRI or similar mechanisms should be
pretty much oblivious to the transaction fault model.
> But I think we agree that we need:
>
> 1. A compatible string for the SMMU that can be used to infer the SS
> behaviour in the driver
>
> 2. A property on the SMMU to say that it's been integrated in such a
> way that stalling is safe (doesn't deadlock)
That's still got to be a per-master property, not a SMMU property, I
think. To illustrate:
[A] [B] [C]
| |_____|
__|______________|___
| TBU | | TBU |
|_____| SMMU |_____|
|__|______________|__|
| |
Say A and B are instances of some device happy to be stalled, and C is a
PCIe RC, and each is attached to their own context bank - enabling
stalls for A is definitely fine. However even though B and C are using
different context banks, enabling stalls for B might deadlock C if it
results in more total outstanding transactions than the TBU's slave port
supports. Therefore A can happily claim to be stall-safe, but B cannot
due to its integration with respect to C.
And yes, I can point you at some existing hardware which really does
posess a topology like that.
> 3. A generic master property that says that the device can DMA to
> unpinned memory
That sounds a bit *too* generic to me, given that there are multiple
incompatible ways that could be implemented. I'm not the biggest fan of
properties with heavily context-specific interpretations, especially
when there's more than a hint of software implementation details in the mix.
Robin.
>
> Anything else?
>
> Will
>
^ permalink raw reply
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