* Re: [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-24 12:14 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio@vger.kernel.org, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Rob Herring,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <70ffe3343c13d01737bf74e5de4898d0c0be07a0.1491405475.git-series.gregory.clement@free-electrons.com>
On Wed, Apr 5, 2017 at 5:18 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Armada 37xx SoCs can handle interrupt through GPIO. However it can
> only manage the edge ones.
>
> The way the interrupt are managed are classical so we can use the generic
> interrupt chip model.
>
> The only unusual "feature" is that many interrupts are connected to the
> parent interrupt controller. But we do not take advantage of this and use
> the chained irq with all of them.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
There are some issues with this patch.
First:
You need to add
select GPIOLIB_IRQCHIP
to the Kconfig entry. It's only working in your setup
because something else is selecting this for you, probably.
At all places like this:
> + u32 mask = d->mask;
(...)
> + if (on)
> + val |= mask;
> + else
> + val &= ~mask;
Isn't it simpler to just use d->mask directly in the code and skip the local
variable?
if (on)
val |= d->mask;
(...)
> +static void armada_37xx_irq_handler(struct irq_desc *desc)
> +{
> + struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct armada_37xx_pinctrl *info = gpiochip_get_data(gc);
> + struct irq_domain *d = gc->irqdomain;
> + int i;
> +
> + chained_irq_enter(chip, desc);
> + for (i = 0; i <= d->revmap_size / GPIO_PER_REG; i++) {
> + u32 status;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&info->irq_lock, flags);
> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
> + /* Manage only the interrupt that was enabled */
> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
> + spin_unlock_irqrestore(&info->irq_lock, flags);
> + while (status) {
> + u32 hwirq = ffs(status) - 1;
> + u32 virq = irq_find_mapping(d, hwirq +
> + i * GPIO_PER_REG);
> +
> + generic_handle_irq(virq);
> + status &= ~BIT(hwirq);
> + }
You hae a problem here is a new IRQ appears while you are inside
of this loop. You need to re-read the status register for each iteration
(and &= with the IRQ_EN I guess).
> +static int armada_37xx_irqchip_register(struct platform_device *pdev,
> + struct armada_37xx_pinctrl *info)
> +{
> + struct device_node *np = info->dev->of_node;
> + int nrirqs = info->data->nr_pins;
> + struct gpio_chip *gc = &info->gpio_chip;
> + struct irq_chip *irqchip = &info->irq_chip;
> + struct resource res;
> + int ret = -ENODEV, i, nr_irq_parent;
> +
This warrants a comment:
/* Check if we have at least one gpio-controller child node */
> + for_each_child_of_node(info->dev->of_node, np) {
> + if (of_find_property(np, "gpio-controller", NULL)) {
> + ret = 0;
> + break;
> + }
Rewrite:
if (of_property_read_bool(np, "gpio-controller"))
> + };
> + if (ret)
> + return ret;
> +
> + nr_irq_parent = of_irq_count(np);
> + spin_lock_init(&info->irq_lock);
> +
> + if (!nr_irq_parent) {
> + dev_err(&pdev->dev, "Invalid or no IRQ\n");
> + return 0;
> + }
> +
> + if (of_address_to_resource(info->dev->of_node, 1, &res)) {
> + dev_err(info->dev, "cannot find IO resource\n");
> + return -ENOENT;
> + }
> +
> + info->base = devm_ioremap_resource(info->dev, &res);
> + if (IS_ERR(info->base))
> + return PTR_ERR(info->base);
> +
> + irqchip->irq_ack = armada_37xx_irq_ack;
> + irqchip->irq_mask = armada_37xx_irq_mask;
> + irqchip->irq_unmask = armada_37xx_irq_unmask;
> + irqchip->irq_set_wake = armada_37xx_irq_set_wake;
> + irqchip->irq_set_type = armada_37xx_irq_set_type;
> + irqchip->name = info->data->name;
> +
> + ret = gpiochip_irqchip_add(gc, irqchip, 0,
> + handle_edge_irq, IRQ_TYPE_NONE);
> + if (ret) {
> + dev_info(&pdev->dev, "could not add irqchip\n");
> + return ret;
> + }
> +
> + /*
> + * Many interrupts are connected to the parent interrupt
> + * controller. But we do not take advantage of this and use
> + * the chained irq with all of them.
> + */
> + for (i = 0; i < nrirqs; i++) {
> + struct irq_data *d = irq_get_irq_data(gc->irq_base + i);
> +
> + /*
> + * The mask field is a "precomputed bitmask for
> + * accessing the chip registers" which was introduced
> + * for the generic irqchip framework. As we don't use
> + * this framework, we can reuse this field for our own
> + * usage.
> + */
> + d->mask = BIT(i % GPIO_PER_REG);
> + }
> +
> + for (i = 0; i < nr_irq_parent; i++) {
> + int irq = irq_of_parse_and_map(np, i);
> +
> + if (irq < 0)
> + continue;
> +
> + gpiochip_set_chained_irqchip(gc, irqchip, irq,
> + armada_37xx_irq_handler);
> + }
> +
> + return 0;
> +}
> +
> static int armada_37xx_gpiochip_register(struct platform_device *pdev,
> struct armada_37xx_pinctrl *info)
> {
> @@ -496,6 +714,9 @@ static int armada_37xx_gpiochip_register(struct platform_device *pdev,
> ret = devm_gpiochip_add_data(&pdev->dev, gc, info);
> if (ret)
> return ret;
> + ret = armada_37xx_irqchip_register(pdev, info);
> + if (ret)
> + return ret;
>
> return 0;
> }
> --
> git-series 0.9.1
^ permalink raw reply
* Re: [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-24 12:16 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <CACRpkdZ=mVXBbVf1iHg8nQ6pYUkvpB+egH+stoMrkD8V_vaYpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
So I touched something in gmail and it shot off the mail prematurely.
My apologies.
But my review was done anyways.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/7] pinctrl: stm32: add possibility to use gpio-ranges to declare bank range
From: Linus Walleij @ 2017-04-24 12:20 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491568984-20169-2-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On Fri, Apr 7, 2017 at 2:42 PM, Alexandre TORGUE
<alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
> Use device tree entries to declare gpio range. It will allow to use
> no contiguous gpio bank and holes inside a bank.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] pinctrl: stm32: replace device_initcall() with arch_initcall()
From: Linus Walleij @ 2017-04-24 12:22 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Patrice Chotard, Paul Gortmaker, Rob Herring,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <1491577811-26989-3-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Pinctrl has to be registered earlier. Mainly to register bank irqdomain
> earlier as other devices could use interrupts from those irqdomain.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Yeah I also see that a lot. I guess workarounds like this is
necessary.
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 13/18] arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
From: Corentin Labbe @ 2017-04-24 12:24 UTC (permalink / raw)
To: Maxime Ripard
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170412124153.q6zvdvqkroizaxgb@lukather>
On Wed, Apr 12, 2017 at 02:41:53PM +0200, Maxime Ripard wrote:
> On Wed, Apr 12, 2017 at 01:13:55PM +0200, Corentin Labbe wrote:
> > The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit
> > connections. It is very similar to the device found in the Allwinner
> > H3, but lacks the internal 100 Mbit PHY and its associated control
> > bits.
> > This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps
> > it disabled at this level.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 37 +++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 0b0f4ab..2569827 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -287,6 +287,23 @@
> > bias-pull-up;
> > };
> >
> > + rmii_pins: rmii_pins {
> > + pins = "PD10", "PD11", "PD13", "PD14",
> > + "PD17", "PD18", "PD19", "PD20",
> > + "PD22", "PD23";
>
> Please align the wrapped lines on the first pin.
>
OK
> > + function = "emac";
> > + drive-strength = <40>;
>
> Do you actually need that for all the boards, or only a few of them?
I have tried to use lower value without success on some boards. (opipc/pine64 in my memory)
Regards
Corentin Labbe
^ permalink raw reply
* Re: [PATCH v2 2/7] Documentation: dt: Remove bindings for STM32 pinctrl
From: Linus Walleij @ 2017-04-24 12:25 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491568984-20169-3-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 2:42 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Remove "ngpios" bindings definition as it is no more used in stm32 pinctrl
> driver.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Fixed up Subject and applied with Rob's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 4/7] pinctrl: stm32: Add STM32F469 MCU support
From: Linus Walleij @ 2017-04-24 12:27 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491568984-20169-5-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On Fri, Apr 7, 2017 at 2:43 PM, Alexandre TORGUE
<alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
> This patch which adds STM32F469 pinctrl and GPIO support, relies on the
> generic STM32 pinctrl driver.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/7] Documentation: dt: Add new compatible to STM32 pinctrl driver bindings
From: Linus Walleij @ 2017-04-24 12:29 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491568984-20169-6-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 2:43 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Add new compatible for stm32f469 MCU.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Fixed up subject and applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 6/7] ARM: Kconfig: Introduce MACH_STM32F469 flag
From: Linus Walleij @ 2017-04-24 12:30 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491568984-20169-7-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 2:43 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> This patch introduces the MACH_STM32F469 to make possible to only select
> STM32F469 pinctrl driver
>
> By default, all the MACH_STM32Fxxx flags will be set with STM32 defconfig.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Please funnel this through the ARM SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/4] pinctrl: stm32: set pin to gpio input when used as interrupt
From: Linus Walleij @ 2017-04-24 12:36 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Patrice Chotard, Paul Gortmaker, Rob Herring,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <1491577811-26989-2-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> This patch ensures that pin is correctly set as gpio input when it is used
> as an interrupt.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
(...)
> +static int stm32_gpio_irq_request_resources(struct irq_data *irq_data)
> +{
> + struct stm32_gpio_bank *bank = irq_data->domain->host_data;
> + u32 ret;
> +
> + if (!gpiochip_is_requested(&bank->gpio_chip, irq_data->hwirq)) {
> + ret = stm32_gpio_request(&bank->gpio_chip, irq_data->hwirq);
> + if (ret)
> + return ret;
> + }
This is wrong. You should only use gpiochip_lock_as_irq(), because of the
following in Documentation/gpio/driver.txt:
---------------
It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
irq_chip are orthogonal, and offering their services independent of each
other.
(...)
So always prepare the hardware and make it ready for action in respective
callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
been called first.
This orthogonality leads to ambiguities that we need to solve: if there is
competition inside the subsystem which side is using the resource (a certain
GPIO line and register for example) it needs to deny certain operations and
keep track of usage inside of the gpiolib subsystem. This is why the API
below exists.
Locking IRQ usage
-----------------
Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
to mark the GPIO as being used as an IRQ:
int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
is released:
void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
When implementing an irqchip inside a GPIO driver, these two functions should
typically be called in the .startup() and .shutdown() callbacks from the
irqchip.
When using the gpiolib irqchip helpers, these callback are automatically
assigned.
--------------
It is because of easy to make errors like this that I prefer that people try
to use GPIOLIB_IRQCHIP helpers insteaf of rolling their own irqchip code.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/4] pinctrl: stm32: Implement .get_direction gpio_chip callback
From: Linus Walleij @ 2017-04-24 12:37 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Patrice Chotard, Paul Gortmaker, Rob Herring,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <1491577811-26989-4-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Add .get_direction() gpiochip callback in STM32 pinctrl driver.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
(...)
> +#include <linux/gpio.h>
No this is wrong, drivers should never include this file.
It is a deprecated consumer header.
> + if ((alt == 0) && (mode == 0))
> + ret = GPIOF_DIR_IN;
> + else if ((alt == 0) && (mode == 1))
> + ret = GPIOF_DIR_OUT;
Just return 0 or 1, that is the driver-internal API.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes
From: Philipp Zabel @ 2017-04-24 12:38 UTC (permalink / raw)
To: Peter Rosin
Cc: Jonathan Cameron, linux-kernel, Greg Kroah-Hartman, Wolfram Sang,
Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jonathan Corbet, linux-i2c, devicetree,
linux-iio, linux-doc, Andrew Morton, Colin Ian King,
Paul Gortmaker, kernel
In-Reply-To: <2d978956-d247-917d-4150-a6723917a733@axentia.se>
On Mon, 2017-04-24 at 13:37 +0200, Peter Rosin wrote:
[...]
> Ok, so the difference is probably that the rwsem locking primitive
> don't have any lockdep checking hooked up. Because the rwsem was
> definitely held in the same way in v13 as the mutex is now held in
> v14, so there's no fundamental difference.
>
> So, yes, we can use some kind of refcount scheme to not hold an actual
> mutex for the duration of the mux select/deselect, but that doesn't
> really change anything. Userspace is still locking something, and that
> seems dangerous. How do you make sure that mux_control_deselect is
> called as it should?
My current video_mux link setup implementation looks like this (it is
called from userspace via the MEDIA_IOC_SETUP_LINK ioctl):
----------8<----------
static int video_mux_link_setup(struct media_entity *entity,
const struct media_pad *local,
const struct media_pad *remote, u32 flags)
{
struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
struct video_mux *video_mux = v4l2_subdev_to_video_mux(sd);
int ret;
/*
* The mux state is determined by the enabled sink pad link.
* Enabling or disabling the source pad link has no effect.
*/
if (!is_sink_pad(video_mux, local->index))
return 0;
dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]", remote->entity->name,
remote->index, local->entity->name, local->index,
flags & MEDIA_LNK_FL_ENABLED);
if (flags & MEDIA_LNK_FL_ENABLED) {
if (video_mux->active == local->index)
return 0;
if (video_mux->active >= 0)
return -EBUSY;
dev_dbg(sd->dev, "setting %d active\n", local->index);
ret = mux_control_try_select(video_mux->mux, local->index);
if (ret < 0)
return ret;
video_mux->active = local->index;
} else {
if (video_mux->active != local->index)
return 0;
dev_dbg(sd->dev, "going inactive\n");
mux_control_deselect(video_mux->mux);
video_mux->active = -1;
}
return 0;
}
---------->8----------
If a mux state was already selected, this should return -EBUSY, until a
call to disable the active link deselects the mux.
> What I don't like about abandoning the lock is that there is still a
> need to support the multi-consumer case and then you need some way
> of keeping track of waiters. A lock does this, and any attempt to open
> code that will get messy.
>
> What might be better is to support some kind of exclusive mux, i.e. a
> mux that only allows one consumer per mux controller. Then the mux core
> could trust that exclusive consumer to not fuck things up for itself and
> thus have no lock at all for select/deselect for the exclusive case. Or
> perhaps keep a refcount (as you suggested) for the exclusive case so
> that mux_control_try_select still makes sense, because you still want
> that, right?
In the case of an exclusive mux without lock, I don't see any need for a
try_select call.
> The question then becomes how to best tell the mux core that you want
> an exclusive mux. I see two options. Either you declare a mux controller
> as exclusive up front somehow (in the device tree presumably), or you
> add a mux_control_get_exclusive call that makes further calls to
> mux_control_get{,_exclusive} fail with -EBUSY. I think I like the
> latter better, if that can be made to work...
There is a precedent for the latter in the reset controller framework
(reset_control_get_shared and reset_control_get_exclusive variants).
Since this distinction is a matter of usage, and not a hardware property
of the mux/reset controller itself, I'd also prefer that.
regards
Philipp
^ permalink raw reply
* Re: [PATCH V7 4/7] mfd: da9061: MFD core support
From: Lee Jones @ 2017-04-24 12:38 UTC (permalink / raw)
To: Steve Twiss
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <6ED8E3B22081A4459DAC7699F3695FB7018CD71434@SW-EX-MBX02.diasemi.com>
On Mon, 24 Apr 2017, Steve Twiss wrote:
> On 04 April 2017 09:39, Lee Jones wrote:
> > Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support
> >
> > On Mon, 03 Apr 2017, Steve Twiss wrote:
> > > From: Steve Twiss <stwiss.opensource@diasemi.com>
> > > MFD support for DA9061 is provided as part of the DA9062 device driver.
> > >
> > > The registers header file adds two new chip variant IDs defined in DA9061
> > > and DA9062 hardware. The core header file adds new software enumerations
> > > for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
> > > for distinguishing between DA9061/62 devices in software.
> > >
> > > The core source code adds a new .compatible of_device_id entry. This is
> > > extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
> > > .data entry now holds a reference to the enumerated device type.
> > >
> > > A new regmap_irq_chip model is added for DA9061 and this supports the new
> > > list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
> > > new sub system components for DA9061. Support is added for a new DA9061
> > > regmap_config which lists the correct readable, writable and volatile
> > > ranges for this chip.
> > >
> > > The probe function uses the device tree compatible string to switch on the
> > > da9062_compatible_types and configure the correct mfd cells, irq chip and
> > > regmap config.
> > >
> > > Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
> > >
> > > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> >
> > Ah, here it is.
> >
> > Applied, thanks.
>
> Hi Lee,
>
> I noticed the DA9061 core support has been added into linux-next, however
> the commit message was changed from the original title:
>
> "mfd: da9061: MFD core support"
>
> to add the mistake:
>
> "mfd: Add suppfor for DA9061"
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d3fe0806025cacdab1462d5704e1c98ab9db4564
>
> Can this be fixed please?
> This patch has not been upstreamed into linux-mainline and is still in linux-next.
You're right, thanks for pointing that out.
Now fixed.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: stm32: Set gpio controller also as interrupt controller
From: Linus Walleij @ 2017-04-24 12:38 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Patrice Chotard, Paul Gortmaker, Rob Herring,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491577811-26989-5-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
<alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
> This patch set each gpio controller as a interrupt controller. User who
> wants to use gpio as interrupt will have choice to use either "gpiolib"
> interface or "common" interrupt interface.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 0/4] mtd: extend support for "fixed-partitions"
From: Rafał Miłecki @ 2017-04-24 12:41 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Jonas Gorski, Rafał Miłecki
In-Reply-To: <20170420135731.13272-2-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
My recent work on adding wide support for linux,part-probe was reviewed and
kind of Nack-ed, but fortunately I was pointed to the old (!) patchset from
Brian doing similar thing in a cleaner way.
This patchset picks the important changes from Brian, cleans them and rebases.
Original patches:
(not picked) [RFC PATCH 1/7] mtd: move partition parsers to drivers/mtd/partitions/
(not picked) [RFC PATCH 2/7] mtd: move partition parsers' Kconfig under a sub-menu
(partially) [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding
(picked) [RFC PATCH 4/7] mtd: add of_match_mtd_parser() and of_mtd_match_mtd_parser() helpers
(partially) [RFC PATCH 5/7] mtd: partitions: factor out "match by name" handling
(picked) [RFC PATCH 6/7] RFC: mtd: partitions: enable of_match_table matching
(not picked) [RFC PATCH 7/7] mtd: partitions: add Google's FMAP partition parser
At this point this simply adds a full support for "fixed-partitions" binding.
It should also make adding new bindings (like Google's FMAP) easier in the
future.
I've successfully tested this with bcm47xxsflash driver on Tenda AC9 device. I
used following DT node to get "ofpart" driver parse & register my partitions.
&bcma-sflash {
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "cfe";
reg = <0x0000000 0x40000>;
read-only;
};
firmware@40000 {
label = "firmware";
reg = <0x40000 0x7f0000>;
};
};
};
V2: Modify patch 1/4
Include list of original patches in 0/4
Include changelog in every patch
Add Brian's tags (Acked/Reviewed/Tested)
Brian Norris (3):
dt-bindings: mtd: make partitions doc a bit more generic
mtd: partitions: factor out code calling parser
mtd: partitions: add of_match_table parser matching
Rafał Miłecki (1):
mtd: ofpart: add of_match_table with "fixed-partitions"
.../devicetree/bindings/mtd/partition.txt | 30 ++++++--
drivers/mtd/mtdpart.c | 80 +++++++++++++++++++---
drivers/mtd/ofpart.c | 7 ++
include/linux/mtd/partitions.h | 1 +
4 files changed, 103 insertions(+), 15 deletions(-)
--
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 V2 1/4] dt-bindings: mtd: make partitions doc a bit more generic
From: Rafał Miłecki @ 2017-04-24 12:41 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Jonas Gorski, Rafał Miłecki
In-Reply-To: <20170424124120.31613-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Currently the only documented partitioning is "fixed-partitions" but
there are more methods in use that we may want to support in the future.
Mention them and make it clear Fixed Partitions are just a single case.
Signed-off-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
This is based on Brian's patch:
[RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding
V1: Dropped "Section B: On-Flash Partition Tables" with Google's FMAP as this
patchset doesn't add that new parser.
V2: Add "We currently only document a binding for fixed layouts." part
---
.../devicetree/bindings/mtd/partition.txt | 30 +++++++++++++++++-----
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
index 81a224da63be..b5de311b967a 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -1,29 +1,47 @@
-Representing flash partitions in devicetree
+Flash partitions in device tree
+===============================
-Partitions can be represented by sub-nodes of an mtd device. This can be used
+Flash devices can be partitioned into one or more functional ranges (e.g. "boot
+code", "nvram", "kernel").
+
+Different devices may be partitioned in a different ways. Some may use a fixed
+flash layout set at production time. Some may use on-flash table that describes
+the geometry and naming/purpose of each functional region. It is also possible
+to see these methods mixed.
+
+To assist system software in locating partitions, we provide a binding to
+describe which method is used for a given flash.
+
+We currently only document a binding for fixed layouts.
+
+
+Fixed Partitions
+================
+
+Partitions can be represented by sub-nodes of a flash device. This can be used
on platforms which have strong conventions about which portions of a flash are
used for what purposes, but which don't use an on-flash partition table such
as RedBoot.
-The partition table should be a subnode of the mtd node and should be named
+The partition table should be a subnode of the flash node and should be named
'partitions'. This node should have the following property:
- compatible : (required) must be "fixed-partitions"
Partitions are then defined in subnodes of the partitions node.
-For backwards compatibility partitions as direct subnodes of the mtd device are
+For backwards compatibility partitions as direct subnodes of the flash device are
supported. This use is discouraged.
NOTE: also for backwards compatibility, direct subnodes that have a compatible
string are not considered partitions, as they may be used for other bindings.
#address-cells & #size-cells must both be present in the partitions subnode of the
-mtd device. There are two valid values for both:
+flash device. There are two valid values for both:
<1>: for partitions that require a single 32-bit cell to represent their
size/address (aka the value is below 4 GiB)
<2>: for partitions that require two 32-bit cells to represent their
size/address (aka the value is 4 GiB or greater).
Required properties:
-- reg : The partition's offset and size within the mtd bank.
+- reg : The partition's offset and size within the flash
Optional properties:
- label : The label / name for this partition. If omitted, the label is taken
--
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 related
* [PATCH V2 2/4] mtd: partitions: factor out code calling parser
From: Rafał Miłecki @ 2017-04-24 12:41 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Jonas Gorski, Rafał Miłecki
In-Reply-To: <20170424124120.31613-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This code is going to be reused for parsers matched using OF so let's
factor it out to make this easier.
Signed-off-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Acked-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
This is based on Brian's patch:
[RFC PATCH 5/7] mtd: partitions: factor out "match by name" handling
V1: Do not factor out mtd_part_parser_get_by_name as it's not required by this
patchset.
---
drivers/mtd/mtdpart.c | 33 ++++++++++++++++++++++++---------
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 81e0b80237df..73c52f1a2e4c 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -840,6 +840,27 @@ static const char * const default_mtd_part_types[] = {
NULL
};
+static int mtd_part_do_parse(struct mtd_part_parser *parser,
+ struct mtd_info *master,
+ struct mtd_partitions *pparts,
+ struct mtd_part_parser_data *data)
+{
+ int ret;
+
+ ret = (*parser->parse_fn)(master, &pparts->parts, data);
+ pr_debug("%s: parser %s: %i\n", master->name, parser->name, ret);
+ if (ret <= 0)
+ return ret;
+
+ pr_notice("%d %s partitions found on MTD device %s\n", ret,
+ parser->name, master->name);
+
+ pparts->nr_parts = ret;
+ pparts->parser = parser;
+
+ return ret;
+}
+
/**
* parse_mtd_partitions - parse MTD partitions
* @master: the master partition (describes whole MTD device)
@@ -880,16 +901,10 @@ int parse_mtd_partitions(struct mtd_info *master, const char *const *types,
parser ? parser->name : NULL);
if (!parser)
continue;
- ret = (*parser->parse_fn)(master, &pparts->parts, data);
- pr_debug("%s: parser %s: %i\n",
- master->name, parser->name, ret);
- if (ret > 0) {
- printk(KERN_NOTICE "%d %s partitions found on MTD device %s\n",
- ret, parser->name, master->name);
- pparts->nr_parts = ret;
- pparts->parser = parser;
+ ret = mtd_part_do_parse(parser, master, pparts, data);
+ /* Found partitions! */
+ if (ret > 0)
return 0;
- }
mtd_part_parser_put(parser);
/*
* Stash the first error we see; only report it if no parser
--
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 related
* [PATCH V2 3/4] mtd: partitions: add of_match_table parser matching
From: Rafał Miłecki @ 2017-04-24 12:41 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Jonas Gorski, Rafał Miłecki
In-Reply-To: <20170424124120.31613-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Partition parsers can now provide an of_match_table to enable
flash<-->parser matching via device tree.
This support is currently limited to built-in parsers as it uses
request_module() and friends. This should be sufficient for most cases
though as compiling parsers as modules isn't a common choice.
Signed-off-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Acked-by: Brian Norris <computersforpeac-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
This is based on Brian's patches:
[RFC PATCH 4/7] mtd: add of_match_mtd_parser() and of_mtd_match_mtd_parser() helpers
[RFC PATCH 6/7] RFC: mtd: partitions: enable of_match_table matching
V1: Put helpers in mtdpart.c instead of drivers/of/of_mtd.c
Merge helpers into a single of_mtd_match_mtd_parser
---
drivers/mtd/mtdpart.c | 47 ++++++++++++++++++++++++++++++++++++++++++
include/linux/mtd/partitions.h | 1 +
2 files changed, 48 insertions(+)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 73c52f1a2e4c..d0cb1a892ed2 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -861,6 +861,41 @@ static int mtd_part_do_parse(struct mtd_part_parser *parser,
return ret;
}
+static bool of_mtd_match_mtd_parser(struct mtd_info *mtd,
+ struct mtd_part_parser *parser)
+{
+ struct device_node *np;
+ bool ret;
+
+ np = mtd_get_of_node(mtd);
+ np = of_get_child_by_name(np, "partitions");
+
+ ret = !!of_match_node(parser->of_match_table, np);
+
+ of_node_put(np);
+
+ return ret;
+}
+
+static struct mtd_part_parser *mtd_part_get_parser_by_of(struct mtd_info *mtd)
+{
+ struct mtd_part_parser *p, *ret = NULL;
+
+ spin_lock(&part_parser_lock);
+
+ list_for_each_entry(p, &part_parsers, list) {
+ if (of_mtd_match_mtd_parser(mtd, p) &&
+ try_module_get(p->owner)) {
+ ret = p;
+ break;
+ }
+ }
+
+ spin_unlock(&part_parser_lock);
+
+ return ret;
+}
+
/**
* parse_mtd_partitions - parse MTD partitions
* @master: the master partition (describes whole MTD device)
@@ -913,6 +948,18 @@ int parse_mtd_partitions(struct mtd_info *master, const char *const *types,
if (ret < 0 && !err)
err = ret;
}
+
+ parser = mtd_part_get_parser_by_of(master);
+ if (!parser)
+ return err;
+
+ ret = mtd_part_do_parse(parser, master, pparts, data);
+ if (ret > 0)
+ return 0;
+ mtd_part_parser_put(parser);
+ if (ret < 0 && !err)
+ err = ret;
+
return err;
}
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 2787e76c030f..073e1d8d5d17 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -77,6 +77,7 @@ struct mtd_part_parser {
struct list_head list;
struct module *owner;
const char *name;
+ const struct of_device_id *of_match_table;
int (*parse_fn)(struct mtd_info *, const struct mtd_partition **,
struct mtd_part_parser_data *);
void (*cleanup)(const struct mtd_partition *pparts, int nr_parts);
--
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 related
* [PATCH V2 4/4] mtd: ofpart: add of_match_table with "fixed-partitions"
From: Rafał Miłecki @ 2017-04-24 12:41 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Jonas Gorski, Rafał Miłecki
In-Reply-To: <20170424124120.31613-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This allows using this parser with any flash driver that takes care of
setting of_node (using mtd_set_of_node helper) correctly. Up to now
support for "fixed-partitions" DT compatibility string was working only
with flash drivers that were specifying "ofpart" (manually or by letting
mtd use the default set of parsers).
This matches existing bindings documentation.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Reviewed-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Tested-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/mtd/ofpart.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 2861c7079d7b..fb6f3df40e94 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -140,9 +140,16 @@ static int parse_ofpart_partitions(struct mtd_info *master,
return ret;
}
+static const struct of_device_id parse_ofpart_match_table[] = {
+ { .compatible = "fixed-partitions" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, parse_ofpart_match_table);
+
static struct mtd_part_parser ofpart_parser = {
.parse_fn = parse_ofpart_partitions,
.name = "ofpart",
+ .of_match_table = parse_ofpart_match_table,
};
static int parse_ofoldpart_partitions(struct mtd_info *master,
--
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 related
* Re: [PATCH v2 1/4] pinctrl: aspeed: Document pinconf in devicetree bindings
From: Linus Walleij @ 2017-04-24 12:42 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Joel Stanley, Benjamin Herrenschmidt,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, OpenBMC Maillist
In-Reply-To: <20170407125713.15678-2-andrew@aj.id.au>
On Fri, Apr 7, 2017 at 2:57 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Patch applied with the ACKs.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/4] gpio: aspeed: dt: Fix description alignment in bindings document
From: Linus Walleij @ 2017-04-24 12:46 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Joel Stanley, Benjamin Herrenschmidt,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
OpenBMC Maillist
In-Reply-To: <20170407125902.15960-2-andrew-zrmu5oMJ5Fs@public.gmane.org>
On Fri, Apr 7, 2017 at 2:58 PM, Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org> wrote:
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
Patch applied with Rob's ACK.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/4] gpio: aspeed: dt: Add optional clocks property
From: Linus Walleij @ 2017-04-24 12:47 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Joel Stanley, Benjamin Herrenschmidt,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, OpenBMC Maillist
In-Reply-To: <20170407125902.15960-3-andrew@aj.id.au>
On Fri, Apr 7, 2017 at 2:59 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> We need a reference to the HPLL to calculate debounce cycles. If the
> clocks property is not supplied in the GPIO node then the consumer
> should deny any debounce requests.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Patch applied with Rob's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Jiada Wang @ 2017-04-24 12:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Brown, Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer,
Fabio Estevam, linux-spi,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAMuHMdXa_O6RsqUciiNWQ0Zp6dniS47AUmPN9UWAWitP0csx=Q@mail.gmail.com>
Hello Geert
On 04/24/2017 03:55 AM, Geert Uytterhoeven wrote:
> Hi Jiada,
>
> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
>> On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:
>>> On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown<broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>> On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org wrote:
>>>>> From: Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>>>>>
>>>>> v1:
>>>>> add Slave mode support in SPI core
>>>>> spidev create slave device when SPI controller work in slave mode
>>>>> spi-imx support to work in slave mode
>>>> Adding Geert who also had a series doing this in progress that was
>>>> getting very near to being merged.
>>> Thank you!
>>>
>>> Actually my plan is to fix the last remaining issues and resubmit for
>>> v4.13.
>> I noticed your patch set for SPI slave support,
>> (I am sure you can find out some of the change
>> in this patch set is based on your work).
>> we have similar requirement to add slave mode support to ecspi IP on imx6
>> Soc.
>>
>> Our use case is to use spidev as an interface to communicate with external
>> SPI master devices.
>> meanwhile the SPI bus controller can also act as master device to send data
>> to other
>> SPI slave devices on the board.
> That sounds a bit hackish to me. SPI was never meant to be a multi-master bus.
> While it can be done, you will need external synchronization (signals) to
> avoid conflicts between the SPI masters.
It doesn't need to be a multi-master bus,
for example A is master device for slave device B.
while B has its own slave device C
for each SPI connection A <=> B, and B <=> C, there is only one master
device.
and I think from use case point of view, it's very normal,
one CPU upon receives command from external SPI master device,
it writes data to its own slave device (EEPROM) connected to it.
Thanks,
Jiada
>> I found in your implementation, SPI bus controller is limited to either work
>> in master mode or
>> slave mode, is there any reasoning to not configure SPI mode based on SPI
>> devices use case?
> If you really need both master and slave support, you can use 2 subnodes
> in DT, the first representing the master, the second the slave.
>
> Mark, what's your opinion about this?
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 3/4] gpio: aspeed: Add debounce support
From: Linus Walleij @ 2017-04-24 12:50 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Joel Stanley, Benjamin Herrenschmidt,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, OpenBMC Maillist
In-Reply-To: <20170407125902.15960-4-andrew@aj.id.au>
On Fri, Apr 7, 2017 at 2:59 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> Each GPIO in the Aspeed GPIO controller can choose one of four input
> debounce states: to disable debouncing for an input, or select from one
> of three programmable debounce timer values. Each GPIO in a
> four-bank-set is assigned one bit in each of two debounce configuration
> registers dedicated to the set, and selects a debounce state by
> configuring the two bits to select one of the four options.
>
> The limitation on debounce timer values is managed by mapping offsets
> onto a configured timer value and keeping count of the number of users
> a timer has. Timer values are configured on a first-come-first-served
> basis.
>
> A small twist in the hardware design is that the debounce configuration
> register numbering is reversed with respect to the binary representation
> of the debounce timer of interest (i.e. debounce register 1 represents
> bit 1, and debounce register 2 represents bit 0 of the timer numbering).
>
> Tested on an AST2500EVB with additional inspection under QEMU's
> romulus-bmc machine.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 4/4] gpio: aspeed: Add open-source and open-drain support
From: Linus Walleij @ 2017-04-24 12:52 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Joel Stanley, Benjamin Herrenschmidt,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, OpenBMC Maillist
In-Reply-To: <20170407125902.15960-5-andrew@aj.id.au>
On Fri, Apr 7, 2017 at 2:59 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> As per the datasheet, manage the IO and value states to implement
> open-source/open-drain, but do this by falling back to gpiolib's
> emulation.
>
> This commit simply makes the behaviour explicit for clarity, rather than
> relying on the implicit return of -ENOTSUPP to trigger the emulation.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Patch applied.
Yours,
Linus Walleij
^ 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