* [PATCH 2/2] kvm: arm/arm64: Fix race in resetting stage2 PGD
From: Christoffer Dall @ 2017-04-24 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493028624-29837-3-git-send-email-suzuki.poulose@arm.com>
On Mon, Apr 24, 2017 at 11:10:24AM +0100, Suzuki K Poulose wrote:
> In kvm_free_stage2_pgd() we check the stage2 PGD before holding
> the lock and proceed to take the lock if it is valid. And we unmap
> the page tables, followed by releasing the lock. We reset the PGD
> only after dropping this lock, which could cause a race condition
> where another thread waiting on the lock could potentially see that
> the PGD is still valid and proceed to perform a stage2 operation.
>
> This patch moves the stage2 PGD manipulation under the lock.
>
> Reported-by: Alexander Graf <agraf@suse.de>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
> ---
> arch/arm/kvm/mmu.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 582a972..9c4026d 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -835,16 +835,18 @@ void stage2_unmap_vm(struct kvm *kvm)
> */
> void kvm_free_stage2_pgd(struct kvm *kvm)
> {
> - if (kvm->arch.pgd == NULL)
> - return;
> + void *pgd = NULL;
>
> spin_lock(&kvm->mmu_lock);
> - unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
> + if (kvm->arch.pgd) {
> + unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
> + pgd = kvm->arch.pgd;
> + kvm->arch.pgd = NULL;
> + }
> spin_unlock(&kvm->mmu_lock);
> -
> /* Free the HW pgd, one page at a time */
> - free_pages_exact(kvm->arch.pgd, S2_PGD_SIZE);
> - kvm->arch.pgd = NULL;
> + if (pgd)
> + free_pages_exact(pgd, S2_PGD_SIZE);
> }
>
> static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache *cache,
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 2/7] Documentation: dt: Remove bindings for STM32 pinctrl
From: Linus Walleij @ 2017-04-24 12:25 UTC (permalink / raw)
To: linux-arm-kernel
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
* [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: linux-arm-kernel
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@gmail.com>
> > ---
> > 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
* [PATCH 2/4] pinctrl: stm32: replace device_initcall() with arch_initcall()
From: Linus Walleij @ 2017-04-24 12:22 UTC (permalink / raw)
To: linux-arm-kernel
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
* [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: linux-arm-kernel
In-Reply-To: <1491568984-20169-2-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 2:42 PM, Alexandre TORGUE
<alexandre.torgue@st.com> 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@st.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-24 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ=mVXBbVf1iHg8nQ6pYUkvpB+egH+stoMrkD8V_vaYpg@mail.gmail.com>
So I touched something in gmail and it shot off the mail prematurely.
My apologies.
But my review was done anyways.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-24 12:14 UTC (permalink / raw)
To: linux-arm-kernel
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
* [PATCH v3 07/12] dt-bindings: add AXP803's regulator info
From: Lee Jones @ 2017-04-24 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-8-icenowy@aosc.io>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 have the most regulators in currently supported AXP PMICs.
>
> Add info for the regulators in the dt-bindings document.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Changes in v3:
> - Added Rob's ACK.
> Changes in v2:
> - Place AXP803 regulators before AXP806/809 ones.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 27 ++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 44df88be3c89..aca09af66514 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -96,6 +96,33 @@ LDO_IO1 : LDO : ips-supply : GPIO 1
> RTC_LDO : LDO : ips-supply : always on
> DRIVEVBUS : Enable output : drivevbus-supply : external regulator
>
> +AXP803 regulators, type, and corresponding input supply names:
> +
> +Regulator Type Supply Name Notes
> +--------- ---- ----------- -----
> +DCDC1 : DC-DC buck : vin1-supply
> +DCDC2 : DC-DC buck : vin2-supply : poly-phase capable
> +DCDC3 : DC-DC buck : vin3-supply : poly-phase capable
> +DCDC4 : DC-DC buck : vin4-supply
> +DCDC5 : DC-DC buck : vin5-supply : poly-phase capable
> +DCDC6 : DC-DC buck : vin6-supply : poly-phase capable
> +DC1SW : On/Off Switch : : DCDC1 secondary output
> +ALDO1 : LDO : aldoin-supply : shared supply
> +ALDO2 : LDO : aldoin-supply : shared supply
> +ALDO3 : LDO : aldoin-supply : shared supply
> +DLDO1 : LDO : dldoin-supply : shared supply
> +DLDO2 : LDO : dldoin-supply : shared supply
> +DLDO3 : LDO : dldoin-supply : shared supply
> +DLDO4 : LDO : dldoin-supply : shared supply
> +ELDO1 : LDO : eldoin-supply : shared supply
> +ELDO2 : LDO : eldoin-supply : shared supply
> +ELDO3 : LDO : eldoin-supply : shared supply
> +FLDO1 : LDO : fldoin-supply : shared supply
> +FLDO2 : LDO : fldoin-supply : shared supply
> +LDO_IO0 : LDO : ips-supply : GPIO 0
> +LDO_IO1 : LDO : ips-supply : GPIO 1
> +RTC_LDO : LDO : ips-supply : always on
> +
> AXP806 regulators, type, and corresponding input supply names:
>
> Regulator Type Supply Name Notes
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 05/12] mfd: axp20x: support AXP803 variant
From: Lee Jones @ 2017-04-24 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-6-icenowy@aosc.io>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64
> via RSB bus. The PMIC itself is like AXP288, but with RSB support and
> dedicated VBUS and ACIN.
>
> Add support for it in the axp20x mfd driver.
>
> Currently only power key function is supported.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> This patch is said to be applied by Lee Jones, however, I didn't see it
> in the linux-next, so I included it in the patchset now.
>
> Changes in v2:
> - Share regmap configs with AXP288.
> - Place AXP803 bits before AXP806/809.
>
> drivers/mfd/axp20x-rsb.c | 1 +
> drivers/mfd/axp20x.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 40 ++++++++++++++++++++++-
> 3 files changed, 119 insertions(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
> index a732cb50bcff..fd5c7267b136 100644
> --- a/drivers/mfd/axp20x-rsb.c
> +++ b/drivers/mfd/axp20x-rsb.c
> @@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
>
> static const struct of_device_id axp20x_rsb_of_match[] = {
> { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
> + { .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
> { .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
> { .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
> { },
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index e6f55079876e..1dc6235778eb 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
> "AXP221",
> "AXP223",
> "AXP288",
> + "AXP803",
> "AXP806",
> "AXP809",
> };
> @@ -117,6 +118,7 @@ static const struct regmap_access_table axp22x_volatile_table = {
> .n_yes_ranges = ARRAY_SIZE(axp22x_volatile_ranges),
> };
>
> +/* AXP288 ranges are shared with the AXP803, as they cover the same range */
> static const struct regmap_range axp288_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP288_FG_TUNE5),
> @@ -264,6 +266,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
> },
> };
>
> +static struct resource axp803_pek_resources[] = {
> + {
> + .name = "PEK_DBR",
> + .start = AXP803_IRQ_PEK_RIS_EDGE,
> + .end = AXP803_IRQ_PEK_RIS_EDGE,
> + .flags = IORESOURCE_IRQ,
> + }, {
> + .name = "PEK_DBF",
> + .start = AXP803_IRQ_PEK_FAL_EDGE,
> + .end = AXP803_IRQ_PEK_FAL_EDGE,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> static struct resource axp809_pek_resources[] = {
> {
> .name = "PEK_DBR",
> @@ -457,6 +473,43 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
> INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG, 5, 1),
> };
>
> +static const struct regmap_irq axp803_regmap_irqs[] = {
> + INIT_REGMAP_IRQ(AXP803, ACIN_OVER_V, 0, 7),
> + INIT_REGMAP_IRQ(AXP803, ACIN_PLUGIN, 0, 6),
> + INIT_REGMAP_IRQ(AXP803, ACIN_REMOVAL, 0, 5),
> + INIT_REGMAP_IRQ(AXP803, VBUS_OVER_V, 0, 4),
> + INIT_REGMAP_IRQ(AXP803, VBUS_PLUGIN, 0, 3),
> + INIT_REGMAP_IRQ(AXP803, VBUS_REMOVAL, 0, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_PLUGIN, 1, 7),
> + INIT_REGMAP_IRQ(AXP803, BATT_REMOVAL, 1, 6),
> + INIT_REGMAP_IRQ(AXP803, BATT_ENT_ACT_MODE, 1, 5),
> + INIT_REGMAP_IRQ(AXP803, BATT_EXIT_ACT_MODE, 1, 4),
> + INIT_REGMAP_IRQ(AXP803, CHARG, 1, 3),
> + INIT_REGMAP_IRQ(AXP803, CHARG_DONE, 1, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH, 2, 7),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH_END, 2, 6),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW, 2, 5),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW_END, 2, 4),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH, 2, 3),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH_END, 2, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW, 2, 1),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW_END, 2, 0),
> + INIT_REGMAP_IRQ(AXP803, DIE_TEMP_HIGH, 3, 7),
> + INIT_REGMAP_IRQ(AXP803, GPADC, 3, 2),
> + INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL1, 3, 1),
> + INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL2, 3, 0),
> + INIT_REGMAP_IRQ(AXP803, TIMER, 4, 7),
> + INIT_REGMAP_IRQ(AXP803, PEK_RIS_EDGE, 4, 6),
> + INIT_REGMAP_IRQ(AXP803, PEK_FAL_EDGE, 4, 5),
> + INIT_REGMAP_IRQ(AXP803, PEK_SHORT, 4, 4),
> + INIT_REGMAP_IRQ(AXP803, PEK_LONG, 4, 3),
> + INIT_REGMAP_IRQ(AXP803, PEK_OVER_OFF, 4, 2),
> + INIT_REGMAP_IRQ(AXP803, GPIO1_INPUT, 4, 1),
> + INIT_REGMAP_IRQ(AXP803, GPIO0_INPUT, 4, 0),
> + INIT_REGMAP_IRQ(AXP803, BC_USB_CHNG, 5, 1),
> + INIT_REGMAP_IRQ(AXP803, MV_CHNG, 5, 0),
> +};
> +
> static const struct regmap_irq axp806_regmap_irqs[] = {
> INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV1, 0, 0),
> INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV2, 0, 1),
> @@ -557,6 +610,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip = {
>
> };
>
> +static const struct regmap_irq_chip axp803_regmap_irq_chip = {
> + .name = "axp803",
> + .status_base = AXP20X_IRQ1_STATE,
> + .ack_base = AXP20X_IRQ1_STATE,
> + .mask_base = AXP20X_IRQ1_EN,
> + .mask_invert = true,
> + .init_ack_masked = true,
> + .irqs = axp803_regmap_irqs,
> + .num_irqs = ARRAY_SIZE(axp803_regmap_irqs),
> + .num_regs = 6,
> +};
> +
> static const struct regmap_irq_chip axp806_regmap_irq_chip = {
> .name = "axp806",
> .status_base = AXP20X_IRQ1_STATE,
> @@ -778,6 +843,14 @@ static struct mfd_cell axp288_cells[] = {
> },
> };
>
> +static struct mfd_cell axp803_cells[] = {
> + {
> + .name = "axp20x-pek",
> + .num_resources = ARRAY_SIZE(axp803_pek_resources),
> + .resources = axp803_pek_resources,
> + }
> +};
> +
> static struct mfd_cell axp806_cells[] = {
> {
> .id = 2,
> @@ -864,6 +937,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> axp20x->regmap_irq_chip = &axp288_regmap_irq_chip;
> axp20x->irq_flags = IRQF_TRIGGER_LOW;
> break;
> + case AXP803_ID:
> + axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
> + axp20x->cells = axp803_cells;
> + axp20x->regmap_cfg = &axp288_regmap_config;
> + axp20x->regmap_irq_chip = &axp803_regmap_irq_chip;
> + break;
> case AXP806_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
> axp20x->cells = axp806_cells;
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index dc8798cf2a24..cde56cfe8446 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -20,6 +20,7 @@ enum axp20x_variants {
> AXP221_ID,
> AXP223_ID,
> AXP288_ID,
> + AXP803_ID,
> AXP806_ID,
> AXP809_ID,
> NR_AXP20X_VARIANTS,
> @@ -234,7 +235,7 @@ enum axp20x_variants {
> #define AXP22X_TS_ADC_L 0x59
> #define AXP22X_BATLOW_THRES1 0xe6
>
> -/* AXP288 specific registers */
> +/* AXP288/AXP803 specific registers */
> #define AXP288_POWER_REASON 0x02
> #define AXP288_BC_GLOBAL 0x2c
> #define AXP288_BC_VBUS_CNTL 0x2d
> @@ -475,6 +476,43 @@ enum axp288_irqs {
> AXP288_IRQ_BC_USB_CHNG,
> };
>
> +enum axp803_irqs {
> + AXP803_IRQ_ACIN_OVER_V = 1,
> + AXP803_IRQ_ACIN_PLUGIN,
> + AXP803_IRQ_ACIN_REMOVAL,
> + AXP803_IRQ_VBUS_OVER_V,
> + AXP803_IRQ_VBUS_PLUGIN,
> + AXP803_IRQ_VBUS_REMOVAL,
> + AXP803_IRQ_BATT_PLUGIN,
> + AXP803_IRQ_BATT_REMOVAL,
> + AXP803_IRQ_BATT_ENT_ACT_MODE,
> + AXP803_IRQ_BATT_EXIT_ACT_MODE,
> + AXP803_IRQ_CHARG,
> + AXP803_IRQ_CHARG_DONE,
> + AXP803_IRQ_BATT_CHG_TEMP_HIGH,
> + AXP803_IRQ_BATT_CHG_TEMP_HIGH_END,
> + AXP803_IRQ_BATT_CHG_TEMP_LOW,
> + AXP803_IRQ_BATT_CHG_TEMP_LOW_END,
> + AXP803_IRQ_BATT_ACT_TEMP_HIGH,
> + AXP803_IRQ_BATT_ACT_TEMP_HIGH_END,
> + AXP803_IRQ_BATT_ACT_TEMP_LOW,
> + AXP803_IRQ_BATT_ACT_TEMP_LOW_END,
> + AXP803_IRQ_DIE_TEMP_HIGH,
> + AXP803_IRQ_GPADC,
> + AXP803_IRQ_LOW_PWR_LVL1,
> + AXP803_IRQ_LOW_PWR_LVL2,
> + AXP803_IRQ_TIMER,
> + AXP803_IRQ_PEK_RIS_EDGE,
> + AXP803_IRQ_PEK_FAL_EDGE,
> + AXP803_IRQ_PEK_SHORT,
> + AXP803_IRQ_PEK_LONG,
> + AXP803_IRQ_PEK_OVER_OFF,
> + AXP803_IRQ_GPIO1_INPUT,
> + AXP803_IRQ_GPIO0_INPUT,
> + AXP803_IRQ_BC_USB_CHNG,
> + AXP803_IRQ_MV_CHNG,
> +};
> +
> enum axp806_irqs {
> AXP806_IRQ_DIE_TEMP_HIGH_LV1,
> AXP806_IRQ_DIE_TEMP_HIGH_LV2,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 04/12] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Lee Jones @ 2017-04-24 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-5-icenowy@aosc.io>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
> bus.
>
> Add a compatible for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Changes in v3:
> - Make the compatible one-liner.
> Changes in v2:
> - Place AXP803 before AXP806/809.
> - Added Chen-Yu's ACK.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index a3e813f6060a..44df88be3c89 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -6,6 +6,7 @@ axp202 (X-Powers)
> axp209 (X-Powers)
> axp221 (X-Powers)
> axp223 (X-Powers)
> +axp803 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> @@ -15,6 +16,7 @@ Required properties:
> * "x-powers,axp209"
> * "x-powers,axp221"
> * "x-powers,axp223"
> + * "x-powers,axp803"
> * "x-powers,axp806"
> * "x-powers,axp809"
> - reg: The I2C slave address or RSB hardware address for the AXP chip
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 03/12] dt-bindings: make AXP20X compatible strings one per line
From: Lee Jones @ 2017-04-24 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170417115747.7300-4-icenowy@aosc.io>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> In the binding documentation of AXP20X mfd, the compatible strings used
> to be listed for three per line, which leads to some mess when trying to
> add AXP803 compatible string (as we have already AXP806 and AXP809
> compatibles, which is after AXP803 in ascending order).
>
> Make the compatible strings one per line, so that inserting a new
> compatible string will be directly a new line.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> New patch in v3.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index b41d2601c6ba..a3e813f6060a 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -9,9 +9,14 @@ axp223 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> -- compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> - "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
> - "x-powers,axp809"
> +- compatible: should be one of:
> + * "x-powers,axp152"
> + * "x-powers,axp202"
> + * "x-powers,axp209"
> + * "x-powers,axp221"
> + * "x-powers,axp223"
> + * "x-powers,axp806"
> + * "x-powers,axp809"
> - reg: The I2C slave address or RSB hardware address for the AXP chip
> - interrupt-parent: The parent interrupt controller
> - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Increase SMMU CMD queue poll timeout
From: Geetha sowjanya @ 2017-04-24 11:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Geetha <gakula@cavium.com>
When large memory is being unmapped, huge no of tlb invalidation cmds are
submitted followed by a SYNC command. This sometimes hits CMD queue full and
poll on queue drain is being timedout throwing error message 'CMD_SYNC timeout'.
Although there is no functional issue, error message confuses user. Hence increased
poll timeout to 500us
Signed-off-by: Geetha <gakula@cavium.com>
---
drivers/iommu/arm-smmu-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 591bb96..1dcd154 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -407,7 +407,7 @@
#define PRIQ_1_ADDR_MASK 0xfffffffffffffUL
/* High-level queue structures */
-#define ARM_SMMU_POLL_TIMEOUT_US 100
+#define ARM_SMMU_POLL_TIMEOUT_US 500
#define MSI_IOVA_BASE 0x8000000
#define MSI_IOVA_LENGTH 0x100000
--
1.9.1
^ permalink raw reply related
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Fabio Estevam @ 2017-04-24 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424114343.GS26900@vireshk-i7>
On Mon, Apr 24, 2017 at 8:43 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> 110 ms is your sampling rate right now. Looks too high.
>
> Try doing this:
>
> echo 10000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
>
> and retry your tests.
Tried 10ms and also 1ms, but touchscreen also failed in both cases.
^ permalink raw reply
* [PATCH 5/7] regulator: arizona-ldo1: Move pdata into a separate structure
From: Lee Jones @ 2017-04-24 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-7-git-send-email-rf@opensource.wolfsonmicro.com>
On Tue, 18 Apr 2017, Richard Fitzgerald wrote:
> In preparation for sharing this driver with Madera, move the pdata
> for the LDO1 regulator out of struct arizona_pdata into a dedicated
> pdata struct for this driver. As a result the code in
> arizona_ldo1_of_get_pdata() can be made independent of struct arizona.
>
> This patch also updates the definition of struct arizona_pdata and
> the use of this pdata in mach-crag6410-module.c
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> arch/arm/mach-s3c64xx/mach-crag6410-module.c | 8 ++++--
> drivers/regulator/arizona-ldo1.c | 39 +++++++++++++++-------------
> include/linux/mfd/arizona/pdata.h | 4 +--
Acked-by: Lee Jones <lee.jones@linaro.org>
> include/linux/regulator/arizona-ldo1.h | 24 +++++++++++++++++
> 4 files changed, 53 insertions(+), 22 deletions(-)
> create mode 100644 include/linux/regulator/arizona-ldo1.h
>
> diff --git a/arch/arm/mach-s3c64xx/mach-crag6410-module.c b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> index ccc3ab8..ea5f216 100644
> --- a/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> +++ b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
> @@ -209,7 +209,9 @@
> };
>
> static struct arizona_pdata wm5102_reva_pdata = {
> - .ldoena = S3C64XX_GPN(7),
> + .ldo1 = {
> + .ldoena = S3C64XX_GPN(7),
> + },
> .gpio_base = CODEC_GPIO_BASE,
> .irq_flags = IRQF_TRIGGER_HIGH,
> .micd_pol_gpio = CODEC_GPIO_BASE + 4,
> @@ -239,7 +241,9 @@
> };
>
> static struct arizona_pdata wm5102_pdata = {
> - .ldoena = S3C64XX_GPN(7),
> + .ldo1 = {
> + .ldoena = S3C64XX_GPN(7),
> + },
> .gpio_base = CODEC_GPIO_BASE,
> .irq_flags = IRQF_TRIGGER_HIGH,
> .micd_pol_gpio = CODEC_GPIO_BASE + 2,
> diff --git a/drivers/regulator/arizona-ldo1.c b/drivers/regulator/arizona-ldo1.c
> index b726fa1..f5bc75a 100644
> --- a/drivers/regulator/arizona-ldo1.c
> +++ b/drivers/regulator/arizona-ldo1.c
> @@ -25,6 +25,8 @@
> #include <linux/gpio.h>
> #include <linux/slab.h>
>
> +#include <linux/regulator/arizona-ldo1.h>
> +
> #include <linux/mfd/arizona/core.h>
> #include <linux/mfd/arizona/pdata.h>
> #include <linux/mfd/arizona/registers.h>
> @@ -186,20 +188,19 @@ static int arizona_ldo1_hc_get_voltage_sel(struct regulator_dev *rdev)
> .num_consumer_supplies = 1,
> };
>
> -static int arizona_ldo1_of_get_pdata(struct device *dev,
> - struct arizona *arizona,
> +static int arizona_ldo1_of_get_pdata(struct arizona_ldo1_pdata *pdata,
> struct regulator_config *config,
> - const struct regulator_desc *desc)
> + const struct regulator_desc *desc,
> + bool *external_dcvdd)
> {
> - struct arizona_pdata *pdata = &arizona->pdata;
> struct arizona_ldo1 *ldo1 = config->driver_data;
> - struct device_node *np = arizona->dev->of_node;
> + struct device_node *np = config->dev->of_node;
> struct device_node *init_node, *dcvdd_node;
> struct regulator_init_data *init_data;
>
> pdata->ldoena = of_get_named_gpio(np, "wlf,ldoena", 0);
> if (pdata->ldoena < 0) {
> - dev_warn(arizona->dev,
> + dev_warn(config->dev,
> "LDOENA GPIO property missing/malformed: %d\n",
> pdata->ldoena);
> pdata->ldoena = 0;
> @@ -213,19 +214,19 @@ static int arizona_ldo1_of_get_pdata(struct device *dev,
> if (init_node) {
> config->of_node = init_node;
>
> - init_data = of_get_regulator_init_data(dev, init_node, desc);
> -
> + init_data = of_get_regulator_init_data(config->dev, init_node,
> + desc);
> if (init_data) {
> init_data->consumer_supplies = &ldo1->supply;
> init_data->num_consumer_supplies = 1;
>
> if (dcvdd_node && dcvdd_node != init_node)
> - arizona->external_dcvdd = true;
> + *external_dcvdd = true;
>
> - pdata->ldo1 = init_data;
> + pdata->init_data = init_data;
> }
> } else if (dcvdd_node) {
> - arizona->external_dcvdd = true;
> + *external_dcvdd = true;
> }
>
> of_node_put(dcvdd_node);
> @@ -239,10 +240,9 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
> const struct regulator_desc *desc;
> struct regulator_config config = { };
> struct arizona_ldo1 *ldo1;
> + bool external_dcvdd = false;
> int ret;
>
> - arizona->external_dcvdd = false;
> -
> ldo1 = devm_kzalloc(&pdev->dev, sizeof(*ldo1), GFP_KERNEL);
> if (!ldo1)
> return -ENOMEM;
> @@ -283,17 +283,18 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
>
> if (IS_ENABLED(CONFIG_OF)) {
> if (!dev_get_platdata(arizona->dev)) {
> - ret = arizona_ldo1_of_get_pdata(&pdev->dev, arizona,
> - &config, desc);
> + ret = arizona_ldo1_of_get_pdata(&arizona->pdata.ldo1,
> + &config, desc,
> + &external_dcvdd);
> if (ret < 0)
> return ret;
> }
> }
>
> - config.ena_gpio = arizona->pdata.ldoena;
> + config.ena_gpio = arizona->pdata.ldo1.ldoena;
>
> - if (arizona->pdata.ldo1)
> - config.init_data = arizona->pdata.ldo1;
> + if (arizona->pdata.ldo1.init_data)
> + config.init_data = arizona->pdata.ldo1.init_data;
> else
> config.init_data = &ldo1->init_data;
>
> @@ -303,6 +304,8 @@ static int arizona_ldo1_probe(struct platform_device *pdev)
> */
> if (config.init_data->num_consumer_supplies == 0)
> arizona->external_dcvdd = true;
> + else
> + arizona->external_dcvdd = external_dcvdd;
>
> ldo1->regulator = devm_regulator_register(&pdev->dev, desc, &config);
>
> diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h
> index 43e875f..bfeecf1 100644
> --- a/include/linux/mfd/arizona/pdata.h
> +++ b/include/linux/mfd/arizona/pdata.h
> @@ -12,6 +12,7 @@
> #define _ARIZONA_PDATA_H
>
> #include <dt-bindings/mfd/arizona.h>
> +#include <linux/regulator/arizona-ldo1.h>
> #include <linux/regulator/arizona-micsupp.h>
>
> #define ARIZONA_GPN_DIR_MASK 0x8000 /* GPN_DIR */
> @@ -77,13 +78,12 @@ struct arizona_micd_range {
>
> struct arizona_pdata {
> int reset; /** GPIO controlling /RESET, if any */
> - int ldoena; /** GPIO controlling LODENA, if any */
>
> /** Regulator configuration for MICVDD */
> struct arizona_micsupp_pdata micvdd;
>
> /** Regulator configuration for LDO1 */
> - struct regulator_init_data *ldo1;
> + struct arizona_ldo1_pdata ldo1;
>
> /** If a direct 32kHz clock is provided on an MCLK specify it here */
> int clk32k_src;
> diff --git a/include/linux/regulator/arizona-ldo1.h b/include/linux/regulator/arizona-ldo1.h
> new file mode 100644
> index 0000000..c685f12
> --- /dev/null
> +++ b/include/linux/regulator/arizona-ldo1.h
> @@ -0,0 +1,24 @@
> +/*
> + * Platform data for Arizona LDO1 regulator
> + *
> + * Copyright 2017 Cirrus Logic
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef ARIZONA_LDO1_H
> +#define ARIZONA_LDO1_H
> +
> +struct regulator_init_data;
> +
> +struct arizona_ldo1_pdata {
> + /** GPIO controlling LDOENA, if any */
> + int ldoena;
> +
> + /** Regulator configuration for LDO1 */
> + const struct regulator_init_data *init_data;
> +};
> +
> +#endif
> --
> 1.9.1
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 2/7] regulator: arizona-micsupp: Move pdata into a separate structure
From: Lee Jones @ 2017-04-24 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492512234-19210-4-git-send-email-rf@opensource.wolfsonmicro.com>
On Tue, 18 Apr 2017, Richard Fitzgerald wrote:
> In preparation for sharing this driver with Madera, move the pdata
> for the micsupp regulator out of struct arizona_pdata into a dedicated
> pdata struct for this driver. As a result the code in
> arizona_micsupp_of_get_pdata() can be made independent of struct arizona.
>
> This patch also updates the definition of struct arizona_pdata and
> the use of this pdata in mach-crag6410-module.c
>
> Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
> ---
> MAINTAINERS | 1 +
> drivers/regulator/arizona-micsupp.c | 21 +++++++++++----------
> include/linux/mfd/arizona/pdata.h | 3 ++-
Acked-by: Lee Jones <lee.jones@linaro.org>
> include/linux/regulator/arizona-micsupp.h | 21 +++++++++++++++++++++
> 4 files changed, 35 insertions(+), 11 deletions(-)
> create mode 100644 include/linux/regulator/arizona-micsupp.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c35e0ce..6ed8ef1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13623,6 +13623,7 @@ F: include/linux/mfd/arizona/
> F: include/linux/mfd/wm831x/
> F: include/linux/mfd/wm8350/
> F: include/linux/mfd/wm8400*
> +F: include/linux/regulator/arizona*
> F: include/linux/wm97xx.h
> F: include/sound/wm????.h
> F: sound/soc/codecs/arizona.?
> diff --git a/drivers/regulator/arizona-micsupp.c b/drivers/regulator/arizona-micsupp.c
> index 5e38861..5f8b5a7 100644
> --- a/drivers/regulator/arizona-micsupp.c
> +++ b/drivers/regulator/arizona-micsupp.c
> @@ -30,6 +30,8 @@
> #include <linux/mfd/arizona/pdata.h>
> #include <linux/mfd/arizona/registers.h>
>
> +#include <linux/regulator/arizona-micsupp.h>
> +
> struct arizona_micsupp {
> struct regulator_dev *regulator;
> struct arizona *arizona;
> @@ -199,28 +201,26 @@ static int arizona_micsupp_set_bypass(struct regulator_dev *rdev, bool ena)
> .num_consumer_supplies = 1,
> };
>
> -static int arizona_micsupp_of_get_pdata(struct device *dev,
> - struct arizona *arizona,
> +static int arizona_micsupp_of_get_pdata(struct arizona_micsupp_pdata *pdata,
> struct regulator_config *config,
> const struct regulator_desc *desc)
> {
> - struct arizona_pdata *pdata = &arizona->pdata;
> struct arizona_micsupp *micsupp = config->driver_data;
> struct device_node *np;
> struct regulator_init_data *init_data;
>
> - np = of_get_child_by_name(arizona->dev->of_node, "micvdd");
> + np = of_get_child_by_name(config->dev->of_node, "micvdd");
>
> if (np) {
> config->of_node = np;
>
> - init_data = of_get_regulator_init_data(dev, np, desc);
> + init_data = of_get_regulator_init_data(config->dev, np, desc);
>
> if (init_data) {
> init_data->consumer_supplies = &micsupp->supply;
> init_data->num_consumer_supplies = 1;
>
> - pdata->micvdd = init_data;
> + pdata->init_data = init_data;
> }
> }
>
> @@ -232,6 +232,7 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
> struct arizona *arizona = dev_get_drvdata(pdev->dev.parent);
> const struct regulator_desc *desc;
> struct regulator_config config = { };
> + struct arizona_micsupp_pdata *pdata = &arizona->pdata.micvdd;
> struct arizona_micsupp *micsupp;
> int ret;
>
> @@ -269,15 +270,15 @@ static int arizona_micsupp_probe(struct platform_device *pdev)
>
> if (IS_ENABLED(CONFIG_OF)) {
> if (!dev_get_platdata(arizona->dev)) {
> - ret = arizona_micsupp_of_get_pdata(&pdev->dev, arizona,
> - &config, desc);
> + ret = arizona_micsupp_of_get_pdata(pdata, &config,
> + desc);
> if (ret < 0)
> return ret;
> }
> }
>
> - if (arizona->pdata.micvdd)
> - config.init_data = arizona->pdata.micvdd;
> + if (pdata->init_data)
> + config.init_data = pdata->init_data;
> else
> config.init_data = &micsupp->init_data;
>
> diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h
> index 64faeef..43e875f 100644
> --- a/include/linux/mfd/arizona/pdata.h
> +++ b/include/linux/mfd/arizona/pdata.h
> @@ -12,6 +12,7 @@
> #define _ARIZONA_PDATA_H
>
> #include <dt-bindings/mfd/arizona.h>
> +#include <linux/regulator/arizona-micsupp.h>
>
> #define ARIZONA_GPN_DIR_MASK 0x8000 /* GPN_DIR */
> #define ARIZONA_GPN_DIR_SHIFT 15 /* GPN_DIR */
> @@ -79,7 +80,7 @@ struct arizona_pdata {
> int ldoena; /** GPIO controlling LODENA, if any */
>
> /** Regulator configuration for MICVDD */
> - struct regulator_init_data *micvdd;
> + struct arizona_micsupp_pdata micvdd;
>
> /** Regulator configuration for LDO1 */
> struct regulator_init_data *ldo1;
> diff --git a/include/linux/regulator/arizona-micsupp.h b/include/linux/regulator/arizona-micsupp.h
> new file mode 100644
> index 0000000..6168426
> --- /dev/null
> +++ b/include/linux/regulator/arizona-micsupp.h
> @@ -0,0 +1,21 @@
> +/*
> + * Platform data for Arizona micsupp regulator
> + *
> + * Copyright 2017 Cirrus Logic
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef ARIZONA_MICSUPP_H
> +#define ARIZONA_MICSUPP_H
> +
> +struct regulator_init_data;
> +
> +struct arizona_micsupp_pdata {
> + /** Regulator configuration for micsupp */
> + const struct regulator_init_data *init_data;
> +};
> +
> +#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v4 4/7] pinctrl: armada-37xx: Add gpio support
From: Linus Walleij @ 2017-04-24 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83a4f4c08275b41333a2583f01ceb0453b009d9f.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:
> GPIO management is pretty simple and is part of the same IP than the pin
> controller for the Armada 37xx SoCs. This patch adds the GPIO support to
> the pinctrl-armada-37xx.c file, it also allows sharing common functions
> between the gpiolib and the pinctrl drivers.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Viresh Kumar @ 2017-04-24 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BpAsJAKv-p=WPevUnx71fxbLtunJe-0ijVT7T9m7AMSQ@mail.gmail.com>
On 24-04-17, 08:37, Fabio Estevam wrote:
> On Mon, Apr 24, 2017 at 8:29 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> > So clearly the system isn't changing the frequency a lot here and you stayed at
> > the min freq for ever. Please give output of this as well:
> >
> > grep . /sys/devices/system/cpu/cpufreq/ondemand/*
>
> # grep . /sys/devices/system/cpu/cpufreq/ondemand/*
> /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load:0
> /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy:0
> /sys/devices/system/cpu/cpufreq/ondemand/min_sampling_rate:10000
> /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias:0
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor:1
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:109000
110 ms is your sampling rate right now. Looks too high.
Try doing this:
echo 10000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
and retry your tests.
> /sys/devices/system/cpu/cpufreq/ondemand/up_threshold:95
>
> > I am also worried if the interrupts from the touchscreen will be enough to boost
> > the frequency of the CPU ?
>
> It does not seem that the interrupts from the touchscreen boost the
> frequency of the CPU.
>
> When I keep touching the panel, the CPU frequency stays at 396 MHz.
>
> Thanks
--
viresh
^ permalink raw reply
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Fabio Estevam @ 2017-04-24 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424112906.GR26900@vireshk-i7>
On Mon, Apr 24, 2017 at 8:29 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> So clearly the system isn't changing the frequency a lot here and you stayed at
> the min freq for ever. Please give output of this as well:
>
> grep . /sys/devices/system/cpu/cpufreq/ondemand/*
# grep . /sys/devices/system/cpu/cpufreq/ondemand/*
/sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load:0
/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy:0
/sys/devices/system/cpu/cpufreq/ondemand/min_sampling_rate:10000
/sys/devices/system/cpu/cpufreq/ondemand/powersave_bias:0
/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor:1
/sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:109000
/sys/devices/system/cpu/cpufreq/ondemand/up_threshold:95
> I am also worried if the interrupts from the touchscreen will be enough to boost
> the frequency of the CPU ?
It does not seem that the interrupts from the touchscreen boost the
frequency of the CPU.
When I keep touching the panel, the CPU frequency stays at 396 MHz.
Thanks
^ permalink raw reply
* [PATCH] arm64: pmuv3: Support v8.1 PMUv3 extension
From: Jayachandran C @ 2017-04-24 11:31 UTC (permalink / raw)
To: linux-arm-kernel
The PMUVer field can have a value 4 for PMUv3 which supports 16 bit
evtCount field (this is documented in ARM Architecture Reference Manual
Supplement ARMv8.1).
The current check for PMUVer to be equal to 1 fails on ThunderX2 which
has value 4 in PMUVer field. Fix this.
Signed-off-by: Jayachandran C <jnair@caviumnetworks.com>
---
This applies on top of the current arm64 tree and fixes a breakage due
to the ACPI perf patches.
arch/arm64/kernel/perf_event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 98c7493..5388ed8 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -972,7 +972,7 @@ static void __armv8pmu_probe_pmu(void *info)
dfr0 = read_sysreg(id_aa64dfr0_el1);
pmuver = cpuid_feature_extract_unsigned_field(dfr0,
ID_AA64DFR0_PMUVER_SHIFT);
- if (pmuver != 1)
+ if (pmuver != 1 && pmuver != 4)
return;
probe->present = true;
--
2.7.4
^ permalink raw reply related
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Viresh Kumar @ 2017-04-24 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5B4_xrLcWQGF=yRfj-14XQKudzjyr2roGRkzofkHCfuHg@mail.gmail.com>
On 24-04-17, 08:20, Fabio Estevam wrote:
> Here it goes, thanks.
>
> # grep . /sys/devices/system/cpu/cpufreq/policy0/*
> /sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq:396000
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:996000
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:396000
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:109036
> /sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
> /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:396000
> 792000 996000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand
> performance
> /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:396000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_driver:imx6q-cpufreq
> /sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand
> /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:996000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:396000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
>
> # grep . /sys/devices/system/cpu/cpufreq/policy0/stats/*
> grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Permission denied
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:396000 2869
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:792000 76
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:996000 33
> /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:8
So clearly the system isn't changing the frequency a lot here and you stayed at
the min freq for ever. Please give output of this as well:
grep . /sys/devices/system/cpu/cpufreq/ondemand/*
I am also worried if the interrupts from the touchscreen will be enough to boost
the frequency of the CPU ?
--
viresh
^ permalink raw reply
* [PATCH] kvm: pass the virtual SEI syndrome to guest OS
From: Laszlo Ersek @ 2017-04-24 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3fdc8c8c-1cd9-b609-c7af-52d40e6141c5@huawei.com>
On 04/21/17 15:27, gengdongjiu wrote:
> Hi all/Laszlo,
>
> sorry, I have a question to consult with you.
>
>
> On 2017/4/7 2:55, Laszlo Ersek wrote:
>> On 04/06/17 14:35, gengdongjiu wrote:
>>> Dear, Laszlo
>>> Thanks for your detailed explanation.
>>>
>>> On 2017/3/29 19:58, Laszlo Ersek wrote:
>>>> (This ought to be one of the longest address lists I've ever seen :)
>>>> Thanks for the CC. I'm glad Shannon is already on the CC list. For good
>>>> measure, I'm adding MST and Igor.)
>>>>
>>>> On 03/29/17 12:36, Achin Gupta wrote:
>>>>> Hi gengdongjiu,
>>>>>
>>>>> On Wed, Mar 29, 2017 at 05:36:37PM +0800, gengdongjiu wrote:
>>>>>>
>>>>>> Hi Laszlo/Biesheuvel/Qemu developer,
>>>>>>
>>>>>> Now I encounter a issue and want to consult with you in ARM64 platform? as described below:
>>>>>>
>>>>>> when guest OS happen synchronous or asynchronous abort, kvm needs
>>>>>> to send the error address to Qemu or UEFI through sigbus to
>>>>>> dynamically generate APEI table. from my investigation, there are
>>>>>> two ways:
>>>>>>
>>>>>> (1) Qemu get the error address, and generate the APEI table, then
>>>>>> notify UEFI to know this generation, then inject abort error to
>>>>>> guest OS, guest OS read the APEI table.
>>>>>> (2) Qemu get the error address, and let UEFI to generate the APEI
>>>>>> table, then inject abort error to guest OS, guest OS read the APEI
>>>>>> table.
>>>>>
>>>>> Just being pedantic! I don't think we are talking about creating the APEI table
>>>>> dynamically here. The issue is: Once KVM has received an error that is destined
>>>>> for a guest it will raise a SIGBUS to Qemu. Now before Qemu can inject the error
>>>>> into the guest OS, a CPER (Common Platform Error Record) has to be generated
>>>>> corresponding to the error source (GHES corresponding to memory subsystem,
>>>>> processor etc) to allow the guest OS to do anything meaningful with the
>>>>> error. So who should create the CPER is the question.
>>>>>
>>>>> At the EL3/EL2 interface (Secure Firmware and OS/Hypervisor), an error arrives
>>>>> at EL3 and secure firmware (at EL3 or a lower secure exception level) is
>>>>> responsible for creating the CPER. ARM is experimenting with using a Standalone
>>>>> MM EDK2 image in the secure world to do the CPER creation. This will avoid
>>>>> adding the same code in ARM TF in EL3 (better for security). The error will then
>>>>> be injected into the OS/Hypervisor (through SEA/SEI/SDEI) through ARM Trusted
>>>>> Firmware.
>>>>>
>>>>> Qemu is essentially fulfilling the role of secure firmware at the EL2/EL1
>>>>> interface (as discussed with Christoffer below). So it should generate the CPER
>>>>> before injecting the error.
>>>>>
>>>>> This is corresponds to (1) above apart from notifying UEFI (I am assuming you
>>>>> mean guest UEFI). At this time, the guest OS already knows where to pick up the
>>>>> CPER from through the HEST. Qemu has to create the CPER and populate its address
>>>>> at the address exported in the HEST. Guest UEFI should not be involved in this
>>>>> flow. Its job was to create the HEST at boot and that has been done by this
>>>>> stage.
>>>>>
>>>>> Qemu folk will be able to add but it looks like support for CPER generation will
>>>>> need to be added to Qemu. We need to resolve this.
>>>>>
>>>>> Do shout if I am missing anything above.
>>>>
>>>> After reading this email, the use case looks *very* similar to what
>>>> we've just done with VMGENID for QEMU 2.9.
>>>>
>>>> We have a facility between QEMU and the guest firmware, called "ACPI
>>>> linker/loader", with which QEMU instructs the firmware to
>>>>
>>>> - allocate and download blobs into guest RAM (AcpiNVS type memory) --
>>>> ALLOCATE command,
>>>>
>>>> - relocate pointers in those blobs, to fields in other (or the same)
>>>> blobs -- ADD_POINTER command,
>>>>
>>>> - set ACPI table checksums -- ADD_CHECKSUM command,
>>>>
>>>> - and send GPAs of fields within such blobs back to QEMU --
>>>> WRITE_POINTER command.
>>>>
>>>> This is how I imagine we can map the facility to the current use case
>>>> (note that this is the first time I read about HEST / GHES / CPER):
>
> Laszlo lists a Qemu GHES table generation solution, Mainly use the
> four commands: "ALLOCATE/ADD_POINTER/ADD_CHECKSUM/WRITE_POINTER" to
> communicate with BIOS so whether the four commands needs to be
> supported by the guest firware/UEFI. I found the "WRITE_POINTER"
> always failed. so I suspect guest UEFI/firmware not support the
> "WRITE_POINTER" command. please help me confirm it, thanks so much.
That's incorrect, both OVMF and ArmVirtQemu support the WRITE_POINTER
command (see <https://bugzilla.tianocore.org/show_bug.cgi?id=359>.) A
number of OvmfPkg/ modules are included in ArmVirtPkg binaries as well.
In QEMU, the WRITE_POINTER command is currently generated for the
VMGENID device only. If you try to test VMGENID with qemu-system-aarch64
(for the purposes of WRITE_POINTER testing), that won't work, because
the VMGENID device is not available for aarch64. (The Microsoft spec
that describes the device lists Windows OS versions that are x86 only.)
In other words, no QEMU code exists at the moment that would allow you
to readily test WRITE_POINTER in aarch64 guests. However, the
firmware-side code is not architecture specific, and WRITE_POINTER
support is already being built into ArmVirtQemu.
Thanks,
Laszlo
^ permalink raw reply
* [PATCH v3 15/18] arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled
From: Catalin Marinas @ 2017-04-24 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7c03009-3b21-0bce-74f5-b11dd359eb97@arm.com>
On Mon, Apr 24, 2017 at 10:33:29AM +0100, Marc Zyngier wrote:
> On 24/04/17 10:14, Hanjun Guo wrote:
> > On 2017/4/24 16:40, Marc Zyngier wrote:
> >> On 24/04/17 09:25, Lixiaoping (Timmy) wrote:
> >>> Sorry about previous email's confidential info. Please forget it.
> >>>
> >>> +#define ESR_ELx_SYS64_ISS_SYS_CNTFRQ (ESR_ELx_SYS64_ISS_SYS_VAL(3, 3, 14, 0, 0) | \
> >>> + ESR_ELx_SYS64_ISS_DIR_READ)
> >>>
> >>> I think (3, 3, 14, 0, 0) should be (3, 3, 0, 14, 0)?
> >> Thanks for spotting this. I assumed that the sys_reg() and
> >> SR_ELx_SYS64_ISS_SYS_VAL() macros took their arguments in the same
> >> order. That would have been too easy... ;-)
> >>
> >> Amended patch below, please let me know if it works for you.
> >>
> >> Thanks,
> >>
> >> M.
> >>
> >> >From 4444c86a97c1a487e12c319fdc197c88631d72b5 Mon Sep 17 00:00:00 2001
> >> From: Marc Zyngier <marc.zyngier@arm.com>
> >> Date: Mon, 24 Apr 2017 09:04:03 +0100
> >> Subject: [PATCH] arm64: Add CNTFRQ_EL0 trap handler
> >>
> >> We now trap accesses to CNTVCT_EL0 when the counter is broken
> >> enough to require the kernel to mediate the access. But it
> >> turns out that some existing userspace (such as OpenMPI) do
> >> probe for the counter frequency, leading to an UNDEF exception
> >> as CNTVCT_EL0 and CNTFRQ_EL0 share the same control bit.
> >>
> >> The fix is to handle the exception the same way we do for CNTVCT_EL0.
> >>
> >> Fixes: a86bd139f2ae ("arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled")
> >> Reported-by: Hanjun Guo <guohanjun@huawei.com>
> >> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> >> ---
> >
> > I tested this patch and the undefined instruction error is gone, I can
> > get the FREQ in the user space now, thank you very much for the quick
> > response.
> >
> > Tested-by: Hanjun Guo <guohanjun@huawei.com>
> > Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
>
> Thanks for giving it a go. Catalin, can you queue this via the arm64 tree?
Done. Thanks for the quick fix.
--
Catalin
^ permalink raw reply
* Touchscreen failure with CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
From: Fabio Estevam @ 2017-04-24 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424040709.GG26900@vireshk-i7>
Hi Viresh,
On Mon, Apr 24, 2017 at 1:07 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> So as Rafael pointed out the problem doesn't happen if you stay at the max
> frequencies, but otherwise.
>
> You need to investigate on why that is the case. You can go to the cpufreq sysfs
> directory and see what frequencies are getting selected, etc..
Yes, when the CPU frequency stays at 996 MHz I do not see the
touchscreen failure. When it goes to 396MHz I do see see touchscreeen
events getting lost.
> Give me output of this for now:
>
> grep . /sys/devices/system/cpu/cpufreq/policy0/*
> grep . /sys/devices/system/cpu/cpufreq/policy0/stats/*
Here it goes, thanks.
# grep . /sys/devices/system/cpu/cpufreq/policy0/*
/sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq:396000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:996000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:396000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:109036
/sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:396000
792000 996000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand
performance
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:396000
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver:imx6q-cpufreq
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:996000
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:396000
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
# grep . /sys/devices/system/cpu/cpufreq/policy0/stats/*
grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Permission denied
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:396000 2869
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:792000 76
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:996000 33
/sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:8
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table: From : To
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table: :
396000 792000 996000
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table: 396000:
0 2 0
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table: 792000:
2 0 2
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table: 996000:
1 1 0
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD and IIO due for the v4.12 merge window
From: Lee Jones @ 2017-04-24 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0f30afec-ff42-e125-96d6-35893324f7ef@kernel.org>
On Fri, 14 Apr 2017, Jonathan Cameron wrote:
> On 11/04/17 11:05, Lee Jones wrote:
> > Enjoy!
> >
> > The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
> >
> > Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-iio-v4.12
> >
> > for you to fetch changes up to f2499ab450d3052097ba53a7d763f767935c0c59:
> >
> > iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs (2017-04-11 11:02:33 +0100)
> >
> > ----------------------------------------------------------------
> > Immutable branch between MFD and IIO due for the v4.12 merge window
> >
> > ----------------------------------------------------------------
> > Quentin Schulz (1):
> > iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
> >
> > drivers/iio/adc/Kconfig | 10 +
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/axp20x_adc.c | 617 +++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 628 insertions(+)
> > create mode 100644 drivers/iio/adc/axp20x_adc.c
> >
> Hi Lee,
>
> Thanks for doing this, but the reason it was going to go through your
> tree in the first place was a dependency on
> commit 4707274714ef ("mfd: axp20x: Correct name of temperature data ADC registers")
>
> Not present in the immutable branch.
>
> There isn't much time for anything else going on around this driver though
> so other than a possible merge conflict on the Kconfig and Makefile shouldn't
> matter if this just goes through mfd. (famous last words ;)
It's not as though you committed it to text and sent it out to a
public mailing list for us all to reference though is it? Doh!
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Geert Uytterhoeven @ 2017-04-24 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58F06092.9080409@mentor.com>
Hi Jiada,
On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang <jiada_wang@mentor.com> wrote:
> On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:
>> On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown<broonie@kernel.org> wrote:
>>> On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_wang at mentor.com wrote:
>>>> From: Jiada Wang<jiada_wang@mentor.com>
>>>>
>>>> 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.
> 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 at linux-m68k.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
^ 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