* [PATCH V2] arm: mm: Remove hugetlb warning from Coherent DMA allocator
From: Steve Capper @ 2014-01-16 10:07 UTC (permalink / raw)
To: linux-arm-kernel
The Coherant DMA allocator allocates pages of high order then splits
them up into smaller pages.
This splitting logic would run into problems if the allocator was
given compound pages. Thus the Coherant DMA allocator was originally
incompatible with compound pages existing and, by extension, huge
pages. A compile #error was put in place whenever huge pages were
enabled.
Compatibility with compound pages has since been introduced by the
following commit (which merely excludes GFP_COMP pages from being
requested by the coherant DMA allocator):
ea2e705 ARM: 7172/1: dma: Drop GFP_COMP for DMA memory allocations
When huge page support was introduced to ARM, the compile #error in
dma-mapping.c was replaced by a #warning when it should have been
removed instead.
This patch removes the compile #warning in dma-mapping.c when huge
pages are enabled.
Signed-off-by: Steve Capper <steve.capper@linaro.org>
---
Changed in V2: commit message completely re-written to give a better
justification.
---
arch/arm/mm/dma-mapping.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f61a570..8edd1b5 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -284,9 +284,6 @@ static void __dma_free_buffer(struct page *page, size_t size)
}
#ifdef CONFIG_MMU
-#ifdef CONFIG_HUGETLB_PAGE
-#warning ARM Coherent DMA allocator does not (yet) support huge TLB
-#endif
static void *__alloc_from_contiguous(struct device *dev, size_t size,
pgprot_t prot, struct page **ret_page,
--
1.8.1.4
^ permalink raw reply related
* [PATCH repost] at91: dt: i2c: add a new compatibility string for the at91sam9261
From: Wolfram Sang @ 2014-01-16 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389791833-7572-1-git-send-email-jjhiblot@traphandler.com>
On Wed, Jan 15, 2014 at 02:17:13PM +0100, Jean-Jacques Hiblot wrote:
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Applied to for-next, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140116/e3cf99a3/attachment.sig>
^ permalink raw reply
* [PATCH RESEND v2] pinctrl: sunxi: Honor GPIO output initial vaules
From: Chen-Yu Tsai @ 2014-01-16 10:07 UTC (permalink / raw)
To: linux-arm-kernel
Some GPIO users, such as fixed-regulator, request GPIO output with
initial value of 1. This was ignored by sunxi driver.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: stable at vger.kernel.org
---
Resend CCing stable.
Changes since v2:
* Set output value before setting the pin function to avoid a glitch.
drivers/pinctrl/pinctrl-sunxi.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index 119d2dd..6ebf306 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -469,12 +469,6 @@ static int sunxi_pinctrl_gpio_get(struct gpio_chip *chip, unsigned offset)
return val;
}
-static int sunxi_pinctrl_gpio_direction_output(struct gpio_chip *chip,
- unsigned offset, int value)
-{
- return pinctrl_gpio_direction_output(chip->base + offset);
-}
-
static void sunxi_pinctrl_gpio_set(struct gpio_chip *chip,
unsigned offset, int value)
{
@@ -498,6 +492,13 @@ static void sunxi_pinctrl_gpio_set(struct gpio_chip *chip,
spin_unlock_irqrestore(&pctl->lock, flags);
}
+static int sunxi_pinctrl_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value)
+{
+ sunxi_pinctrl_gpio_set(chip, offset, value);
+ return pinctrl_gpio_direction_output(chip->base + offset);
+}
+
static int sunxi_pinctrl_gpio_of_xlate(struct gpio_chip *gc,
const struct of_phandle_args *gpiospec,
u32 *flags)
--
1.8.5.2
^ permalink raw reply related
* [PATCH v2] drivers: i2c: silence a compile warning in i2c-s3c2410.c
From: Wolfram Sang @ 2014-01-16 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389750162-5765-1-git-send-email-y@samsung.com>
On Wed, Jan 15, 2014 at 10:42:42AM +0900, y at samsung.com wrote:
Note that your email address is wrong here. I also fixed the description
to "i2c: s3c2410: fix quirk usage for 64-bit" which is more apropriate.
Other than that: Applied to for-next, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140116/fc1231d3/attachment-0001.sig>
^ permalink raw reply
* [PATCH V5 2/4] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
From: Sricharan R @ 2014-01-16 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1386066445-28245-3-git-send-email-r.sricharan@ti.com>
Hi Thomas,
On Tuesday 03 December 2013 03:57 PM, Sricharan R wrote:
> Some socs have a large number of interrupts requests to service
> the needs of its many peripherals and subsystems. All of the
> interrupt lines from the subsystems are not needed at the same
> time, so they have to be muxed to the irq-controller appropriately.
> In such places a interrupt controllers are preceded by an CROSSBAR
> that provides flexibility in muxing the device requests to the controller
> inputs.
>
> This driver takes care a allocating a free irq and then configuring the
> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
> be called right before the irqchip_init, so that it is setup to handle the
> irqchip callbacks.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Sricharan R <r.sricharan@ti.com>
> Acked-by: Kumar Gala <galak@codeaurora.org> (for DT binding portion)
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> [v5] Used the function of_property_read_u32_index instead of raw reading
> from DT as per comments from Mark Rutland <mark.rutland@arm.com>
>
> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
> drivers/irqchip/Kconfig | 8 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-crossbar.c | 208 ++++++++++++++++++++
> include/linux/irqchip/irq-crossbar.h | 11 ++
> 5 files changed, 255 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
> create mode 100644 drivers/irqchip/irq-crossbar.c
> create mode 100644 include/linux/irqchip/irq-crossbar.h
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> new file mode 100644
> index 0000000..fb88585
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> @@ -0,0 +1,27 @@
> +Some socs have a large number of interrupts requests to service
> +the needs of its many peripherals and subsystems. All of the
> +interrupt lines from the subsystems are not needed at the same
> +time, so they have to be muxed to the irq-controller appropriately.
> +In such places a interrupt controllers are preceded by an CROSSBAR
> +that provides flexibility in muxing the device requests to the controller
> +inputs.
> +
> +Required properties:
> +- compatible : Should be "ti,irq-crossbar"
> +- reg: Base address and the size of the crossbar registers.
> +- ti,max-irqs: Total number of irqs available at the interrupt controller.
> +- ti,reg-size: Size of a individual register in bytes. Every individual
> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
> +- ti,irqs-reserved: List of the reserved irq lines that are not muxed using
> + crossbar. These interrupt lines are reserved in the soc,
> + so crossbar bar driver should not consider them as free
> + lines.
> +
> +Examples:
> + crossbar_mpu: @4a020000 {
> + compatible = "ti,irq-crossbar";
> + reg = <0x4a002a48 0x130>;
> + ti,max-irqs = <160>;
> + ti,reg-size = <2>;
> + ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
> + };
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 3792a1a..2efcde6 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -61,3 +61,11 @@ config VERSATILE_FPGA_IRQ_NR
> int
> default 4
> depends on VERSATILE_FPGA_IRQ
> +
> +config IRQ_CROSSBAR
> + bool
> + help
> + Support for a CROSSBAR ip that preceeds the main interrupt controller.
> + The primary irqchip invokes the crossbar's callback which inturn allocates
> + a free irq and configures the IP. Thus the peripheral interrupts are
> + routed to one of the free irqchip interrupt lines.
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index c60b901..2edead9 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -22,3 +22,4 @@ obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
> obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
> obj-$(CONFIG_ARCH_VT8500) += irq-vt8500.o
> obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
> +obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
> new file mode 100644
> index 0000000..ae605a3
> --- /dev/null
> +++ b/drivers/irqchip/irq-crossbar.c
> @@ -0,0 +1,208 @@
> +/*
> + * drivers/irqchip/irq-crossbar.c
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
> + * Author: Sricharan R <r.sricharan@ti.com>
> + *
> + * 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.
> + *
> + */
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/slab.h>
> +#include <linux/irqchip/arm-gic.h>
> +
> +#define IRQ_FREE -1
> +#define GIC_IRQ_START 32
> +
> +/*
> + * @int_max: maximum number of supported interrupts
> + * @irq_map: array of interrupts to crossbar number mapping
> + * @crossbar_base: crossbar base address
> + * @register_offsets: offsets for each irq number
> + */
> +struct crossbar_device {
> + uint int_max;
> + uint *irq_map;
> + void __iomem *crossbar_base;
> + int *register_offsets;
> + void (*write) (int, int);
> +};
> +
> +static struct crossbar_device *cb;
> +
> +static inline void crossbar_writel(int irq_no, int cb_no)
> +{
> + writel(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
> +}
> +
> +static inline void crossbar_writew(int irq_no, int cb_no)
> +{
> + writew(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
> +}
> +
> +static inline void crossbar_writeb(int irq_no, int cb_no)
> +{
> + writeb(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
> +}
> +
> +static inline int allocate_free_irq(int cb_no)
> +{
> + int i;
> +
> + for (i = 0; i < cb->int_max; i++) {
> + if (cb->irq_map[i] == IRQ_FREE) {
> + cb->irq_map[i] = cb_no;
> + return i;
> + }
> + }
> +
> + return -ENODEV;
> +}
> +
> +static int crossbar_domain_map(struct irq_domain *d, unsigned int irq,
> + irq_hw_number_t hw)
> +{
> + cb->write(hw - GIC_IRQ_START, cb->irq_map[hw - GIC_IRQ_START]);
> + return 0;
> +}
> +
> +static void crossbar_domain_unmap(struct irq_domain *d, unsigned int irq)
> +{
> + irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
> +
> + if (hw > GIC_IRQ_START)
> + cb->irq_map[hw - GIC_IRQ_START] = IRQ_FREE;
> +}
> +
> +static int crossbar_domain_xlate(struct irq_domain *d,
> + struct device_node *controller,
> + const u32 *intspec, unsigned int intsize,
> + unsigned long *out_hwirq,
> + unsigned int *out_type)
> +{
> + unsigned long ret;
> +
> + ret = allocate_free_irq(intspec[1]);
> +
> + if (IS_ERR_VALUE(ret))
> + return ret;
> +
> + *out_hwirq = ret + GIC_IRQ_START;
> + return 0;
> +}
> +
> +const struct irq_domain_ops routable_irq_domain_ops = {
> + .map = crossbar_domain_map,
> + .unmap = crossbar_domain_unmap,
> + .xlate = crossbar_domain_xlate
> +};
> +
> +static int __init crossbar_of_init(struct device_node *node)
> +{
> + int i, size, max, reserved = 0, entry;
> + const __be32 *irqsr;
> +
> + cb = kzalloc(sizeof(struct cb_device *), GFP_KERNEL);
> +
> + if (!cb)
> + return -ENOMEM;
> +
> + cb->crossbar_base = of_iomap(node, 0);
> + if (!cb->crossbar_base)
> + goto err1;
> +
> + of_property_read_u32(node, "ti,max-irqs", &max);
> + cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
> + if (!cb->irq_map)
> + goto err2;
> +
> + cb->int_max = max;
> +
> + for (i = 0; i < max; i++)
> + cb->irq_map[i] = IRQ_FREE;
> +
> + /* Get and mark reserved irqs */
> + irqsr = of_get_property(node, "ti,irqs-reserved", &size);
> + if (irqsr) {
> + size /= sizeof(__be32);
> +
> + for (i = 0; i < size; i++) {
> + of_property_read_u32_index(node,
> + "ti,irqs-reserved",
> + i, &entry);
> + if (entry > max) {
> + pr_err("Invalid reserved entry\n");
> + goto err3;
> + }
> + cb->irq_map[entry] = 0;
> + }
> + }
> +
> + cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
> + if (!cb->register_offsets)
> + goto err3;
> +
> + of_property_read_u32(node, "ti,reg-size", &size);
> +
> + switch (size) {
> + case 1:
> + cb->write = crossbar_writeb;
> + break;
> + case 2:
> + cb->write = crossbar_writew;
> + break;
> + case 4:
> + cb->write = crossbar_writel;
> + break;
> + default:
> + pr_err("Invalid reg-size property\n");
> + goto err4;
> + break;
> + }
> +
> + /*
> + * Register offsets are not linear because of the
> + * reserved irqs. so find and store the offsets once.
> + */
> + for (i = 0; i < max; i++) {
> + if (!cb->irq_map[i])
> + continue;
> +
> + cb->register_offsets[i] = reserved;
> + reserved += size;
> + }
> +
> + register_routable_domain_ops(&routable_irq_domain_ops);
> + return 0;
> +
> +err4:
> + kfree(cb->register_offsets);
> +err3:
> + kfree(cb->irq_map);
> +err2:
> + iounmap(cb->crossbar_base);
> +err1:
> + kfree(cb);
> + return -ENOMEM;
> +}
> +
> +static const struct of_device_id crossbar_match[] __initconst = {
> + { .compatible = "ti,irq-crossbar" },
> + {}
> +};
> +
> +int irqcrossbar_init(void)
> +{
> + struct device_node *np;
> + np = of_find_matching_node(NULL, crossbar_match);
> + if (!np)
> + return -ENODEV;
> +
> + crossbar_of_init(np);
> + return 0;
> +}
> diff --git a/include/linux/irqchip/irq-crossbar.h b/include/linux/irqchip/irq-crossbar.h
> new file mode 100644
> index 0000000..e5537b8
> --- /dev/null
> +++ b/include/linux/irqchip/irq-crossbar.h
> @@ -0,0 +1,11 @@
> +/*
> + * drivers/irqchip/irq-crossbar.h
> + *
> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
> + *
> + * 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.
> + *
> + */
> +int irqcrossbar_init(void);
I already have your reviewed-by tag for the first patch in this series.
Kevin was pointing out that irqchip maintainer tag is needed for this patch as well
to be merged. We are planning to take this series through arm-soc tree.
Can i please have your tag for this patch as well ?
Regards,
Sricharan
^ permalink raw reply
* [linux-sunxi] Re: [PATCH] ARM: sunxi: Add driver for sunxi usb phy
From: Hans de Goede @ 2014-01-16 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65rSc7iAKCcPMYaQZ+q=m85RcSE2dmpgE6MoeXNgRCwfg@mail.gmail.com>
Hi,
On 01/16/2014 08:07 AM, Chen-Yu Tsai wrote:
> Hi Hans,
>
> On Wed, Jan 15, 2014 at 11:48 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>>
>> On 01/15/2014 04:00 PM, Kishon Vijay Abraham I wrote:
>>>
>>> On Wednesday 15 January 2014 04:28 AM, Hans de Goede wrote:
> [...]
>>>> +static int sun4i_usb_phy_init(struct phy *_phy)
>>>> +{
>>>> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>>>> + struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
>>>> + int ret;
>>>> +
>>>> + ret = clk_prepare_enable(data->clk);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + ret = reset_control_deassert(phy->reset);
>>>> + if (ret) {
>>>> + clk_disable_unprepare(data->clk);
>>>> + return ret;
>>>> + }
>>>> +
>>>> + /* Adjust PHY's magnitude and rate */
>>>> + sun4i_usb_phy_write(phy, 0x20, 0x14, 5);
>>>
>>>
>>> No magic values. Use macros instead.
>>
>>
>> We don't have docs, these values come from the Android code (and the comment
>> above has been translated from Chinese). I can make up some random
>> macros for this, but seems counter-productive, it seems best to just leave
>> this as magic until the day we actually have documentation and thus can use
>> defines with the proper register names, etc.
>
> We have some names for the registers from Allwinner code:
> https://github.com/linux-sunxi/linux-sunxi/blob/lichee-3.0.8-sun4i/drivers/usb/sun4i_usb/usbc/usbc_phy.c#L39
Ah good catch, thanks. I'll use those in the next revision of the phy driver.
Regards,
Hans
^ permalink raw reply
* [PATCH v9 2/4] Documentation: Add documentation for APM X-Gene SoC SATA host controller DTS binding
From: Arnd Bergmann @ 2014-01-16 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPw-ZT=QXwOVvpgJSL5qU8J2eEuAt3nnXJDfDwPXTTo7z4Fe-A@mail.gmail.com>
On Wednesday 15 January 2014 15:59:27 Loc Ho wrote:
>
> May be I misread what Mark mentioned. The binding documentation should
> not specify the requirement of 0. And the binding of the dts should be
> as is:
>
> phy1 {
> #phy-cells = <1>;
> };
>
> sata1 {
> :::
> phys = <&phy1 0>; where 0 indicates the mode of operation?
> };
>
>
Yes, that is right. You can keep the zero in the example, but the
binding text must not require a specific phy to be used.
Arnd
^ permalink raw reply
* [PATCH] ARM64: perf: support dwarf unwinding in compat mode
From: Jean Pihet @ 2014-01-16 10:45 UTC (permalink / raw)
To: linux-arm-kernel
Add support for unwinding using the dwarf information in compat
mode. Using the correct user stack pointer allows perf to record
the frames correctly in the native and compat modes.
Note that although the dwarf frame unwinding works ok using
libunwind in native mode (on ARMv7 & ARMv8), some changes are
required to the libunwind code for the compat mode. Those changes
are posted separately on the libunwind mailing list.
Tested on ARMv8 platform with v8 and compat v7 binaries, the latter
are statically built.
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
---
arch/arm64/include/asm/ptrace.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index fbb0020..86d5b54 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -133,7 +133,7 @@ struct pt_regs {
(!((regs)->pstate & PSR_F_BIT))
#define user_stack_pointer(regs) \
- ((regs)->sp)
+ (!compat_user_mode(regs)) ? ((regs)->sp) : ((regs)->compat_sp)
/*
* Are the current registers suitable for user mode? (used to maintain
--
1.7.11.7
^ permalink raw reply related
* [PATCH v3 2/2] serial: fsl_lpuart: add DMA support
From: Arnd Bergmann @ 2014-01-16 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a519c52821b4ceb841cbefcf2a0432b@BL2PR03MB338.namprd03.prod.outlook.com>
On Thursday 16 January 2014, Yao Yuan wrote:
> > This part will result in a slight increase in data size even if dma
> > support is turned off at compile time.
> >
>
> Yes, someone also want me define a independent struct for dma and allocate the memory when dma be use.
> But I think this way will add a more memory access time, like a->b->c and a->c. And the variable
> about dma is just a few bytes but used frequently. So I think I'd better define the variable about dma in lpuart_port struct.
I agree. Just leave it unconditionally in here to make the code simpler.
Arnd
^ permalink raw reply
* [PATCH v2] mmc: dw_mmc: fix dw_mci_get_cd
From: Arnd Bergmann @ 2014-01-16 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389839502-13046-1-git-send-email-zhangfei.gao@linaro.org>
On Thursday 16 January 2014, Zhangfei Gao wrote:
> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> @@ -73,6 +73,8 @@ Optional properties:
>
> * caps2-mmc-hs200-1_2v: Supports mmc HS200 SDR 1.2V mode
>
> +* caps2-mmc-cd-active-high: cd pin is high when card present
> +
> * broken-cd: as documented in mmc core bindings.
>
> * vmmc-supply: The phandle to the regulator to use for vmmc. If this is
No, don't introduce a new flag when there is already one defined
in the generic mmc binding.
Arnd
^ permalink raw reply
* [PATCH] ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY to enforce this ACPI mode
From: Arnd Bergmann @ 2014-01-16 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D7414C.7080206@linaro.org>
On Thursday 16 January 2014, Al Stone wrote:
> On 01/14/2014 02:26 PM, Arnd Bergmann wrote:
> > On Tuesday 14 January 2014 13:37:02 al.stone at linaro.org wrote:
> >> +config ACPI_REDUCED_HARDWARE_ONLY
> >> + bool "Hardware-reduced ACPI support only"
> >> + def_bool n
> >> + depends on ACPI && EXPERT
> >
> > I think this will cause a Kconfig warning if you try to select this
> > on ARM64 without turning on EXPERT as well.
> >
> > It should be ok if you express it as
> >
> > config ACPI_REDUCED_HARDWARE_ONLY
> > bool "Hardware-reduced ACPI support only" if EXPERT
> > def_bool n
> > depends on ACPI
> >
> >
> > Arnd
> >
>
> I am very puzzled. I went back and re-did my configs from
> before, tried a few new ones, and tried with both expressions
> above, but I could not get a Kconfig warning. Do you have an
> example .config that shows the warning?
>
I don't have a source tree that allows turning on ACPI on arm64
to easily test this. To clarify: the warning will only happen if
you also add this piece to arch/arm64/Kconfig:
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
Arnd
^ permalink raw reply
* [PATCHv9 2/2] dma: Add Freescale eDMA engine driver support
From: Arnd Bergmann @ 2014-01-16 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389839400-29728-3-git-send-email-b35083@freescale.com>
On Thursday 16 January 2014, Jingchang Lu wrote:
> Add Freescale enhanced direct memory(eDMA) controller support.
> This module can be found on Vybrid and LS-1 SoCs.
>
> Signed-off-by: Alison Wang <b18965@freescale.com>
> Signed-off-by: Jingchang Lu <b35083@freescale.com>
Very nice! All my previous comments have been addressed, so
Acked-by: Arnd Bergmann <arnd@arndb.de>
One small comment still:
> +
> +static DEFINE_MUTEX(fsl_edma_mutex);
> +
I think this mutex should be part of struct fsl_edma_engine, not global.
Arnd
^ permalink raw reply
* [PATCH 3/3] Binding: atmel-wm8904: add option to choose clock
From: Mark Brown @ 2014-01-16 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D736E0.90207@atmel.com>
On Thu, Jan 16, 2014 at 09:33:20AM +0800, Bo Shen wrote:
> On 01/15/2014 07:54 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> Optional properties:
> >> - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
> >>+ - clk_from_rk_pin: according to hardware design, clk privide on rk pin
> > provide
> > ?? no example?
> If this patch set is acceptable. The sama5 audio will use it (I will
> send patch after this patch set). Do I still need to put the example
> in the binding document?
It doesn't seem terribly worthwhile to have the example include every
boolean property, it's not like people should find it hard to work out
how to use them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140116/4accd138/attachment.sig>
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Nicolas Ferre @ 2014-01-16 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D79E51.4030300@overkiz.com>
On 16/01/2014 09:54, boris brezillon :
> On 15/01/2014 19:06, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 11:35 Mon 13 Jan , boris brezillon wrote:
>>> On 13/01/2014 11:29, Jean-Jacques Hiblot wrote:
>>>> Hello Nicolas, Jean-Christophe,
>>>>
>>>> As I was trying to enable the touchscreen on the at91sam9261ek with
>>>> device-tree support, I ran into an issue. The touchscreen driver needs
>>>> to know the state of the pendown gpio and also needs it as an
>>>> interrupt source.
>>>>
>>>> The problem is that when a gpio is used as an interrupt, it's
>>>> requested by the pinctrl driver during the xlate stage, marking it
>>>> unavaliable for the other driver.
>>>> It looks like the at91 pinctrl driver is the only one to use
>>>> gpio_request() in the xlate stage. Maybe we should remove this:
>>> You should only request it as a GPIO and then use gpio_to_irq to get the
>>> related IRQ.
>> This here a HUGE issue in the hole kernel
>>
>> You should NEVER known ti's a gpio in the driver at all gpio_to_irq should never
>> exist you need to only see the irq
>>
>>> Because what is done here, is to solve the case where only the irq
>>> is request, and in this specific case we need to request the pin as a
>>> GPIO.
>> this need to be handled at irq level not drivers
>
> Then propose something (or at least give us a deadline for this new
> interrupt
> model to come out), because the ADS7843E touchscreen is not working anymore
> (at least on at91 platforms).
>
> What this driver needs is a level IRQ (not an edge IRQ). The code in
> ads7846_hard_irq<http://lxr.free-electrons.com/ident?i=ads7846_hard_irq>
> interrupt handler is here to transform an edge IRQ into a level IRQ.
>
> Is there a way to provide a generic framework to transform edge IRQs
> into level IRQs
> (because some GPIO controllers do not support level IRQs, and this is
> the case for the
> at91sam9261 one) ?
>
>
> Of cource the gpio_to_irq approach is not perfect, but at least it as
> the benefit to quickly
> fix the bug, and we will still be able to improve this later, when we
> have enough tools
> (or mechanisms) to do it.
Moreover, I do not see the rationale behind the concept of "interrupt
with an electrical value". An interrupt signals an event and this event
can be a transition or a state but an electrical value is the
responsibility of a GPIO line, not the other way around.
I see a code that could give the value of an electrical line related to
an interrupt as a twisted interpretation of the notion of "interrupt".
It surprises me that it could be thought as an enhancement that an IRQ
coming from a GPIO could give a value!
Isn't it why other people are also using this simple distinction to use
their GPIO/IRQ mechanism? Maybe this is why we are the only ones to
completely forbid this possibility.
So, let's fix the bug, submit the modification to mainline, make
platform work and see if somebody can convince me that retrieving an
electrical line status from a GPIO is a "bad" thing...
Bye,
--
Nicolas Ferre
^ permalink raw reply
* [PATCHv10][ 1/2] ARM: dts: cpuimx35 Add touchscreen support.
From: Denis Carikli @ 2014-01-16 11:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Eric B?nard <eric@eukrea.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v8->v10:
- Reduced Cc list, not to bother unrelated subsystem maintainers.
- Added the pinctrl node (because it is not anymore in the patch adding the cpuimx35).
- Cosmetic fix: reordered the tsc2007 node properties.
ChangeLog v7->v8:
- Added Shawn Guo in the cc list.
---
arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi b/arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
index 303f789..affe3a8 100644
--- a/arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
+++ b/arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
@@ -37,6 +37,17 @@
compatible = "nxp,pcf8563";
reg = <0x51>;
};
+
+ tsc2007: tsc2007 at 48 {
+ compatible = "ti,tsc2007";
+ gpios = <&gpio3 2 0>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <0x2 0x8>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tsc2007_1>;
+ reg = <0x48>;
+ ti,x-plate-ohms = <180>;
+ };
};
&iomuxc {
@@ -48,6 +59,10 @@
pinctrl_i2c1: i2c1grp {
fsl,pins = <MX35_I2C1_PINGRP1>;
};
+
+ pinctrl_tsc2007_1: tsc2007grp-1 {
+ fsl,pins = <MX35_PAD_ATA_DA2__GPIO3_2 0x80000000>;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCHv10][ 2/2] ARM: dts: cpuimx51 Add touchscreen support.
From: Denis Carikli @ 2014-01-16 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389870518-4982-1-git-send-email-denis@eukrea.com>
Cc: Eric B?nard <eric@eukrea.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v9->v10:
- Reduced Cc list, not to bother unrelated subsystem maintainers.
- Rebased: the pinctrl node is already in linux-next.
- Updated tsc2007 pinctrl properties accordingly.
- Cosmetic fix: reordered the tsc2007 node properties.
ChangeLog v8->v9:
- Rebased.
- Adapted to request the tsc2007 gpio pinctrl outside of the tsc2007 bindings.
ChangeLog v7->v8:
- Added Shawn Guo in the cc list.
---
arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi b/arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
index b22841a..d4d4257 100644
--- a/arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
+++ b/arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
@@ -42,6 +42,17 @@
compatible = "nxp,pcf8563";
reg = <0x51>;
};
+
+ tsc2007: tsc2007 at 49 {
+ compatible = "ti,tsc2007";
+ gpios = <&gpio4 0 1>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <0x0 0x8>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tsc2007_1>;
+ reg = <0x49>;
+ ti,x-plate-ohms = <180>;
+ };
};
&iomuxc {
--
1.7.9.5
^ permalink raw reply related
* [PATCHv9 2/2] dma: Add Freescale eDMA engine driver support
From: Mark Rutland @ 2014-01-16 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389839400-29728-3-git-send-email-b35083@freescale.com>
On Thu, Jan 16, 2014 at 02:30:00AM +0000, Jingchang Lu wrote:
> Add Freescale enhanced direct memory(eDMA) controller support.
> This module can be found on Vybrid and LS-1 SoCs.
>
> Signed-off-by: Alison Wang <b18965@freescale.com>
> Signed-off-by: Jingchang Lu <b35083@freescale.com>
> ---
> changes in v9:
> define endian's operating functions instead of macro definition.
> remove the filter function, using dma_get_slave_channel instead.
>
> changes in v8:
> change the edma driver according eDMA dts change.
> add big-endian and little-endian handling.
>
> no changes in v4 ~ v7.
>
> changes in v3:
> add vf610 edma dt-bindings namespace with prefix VF610_*.
>
> changes in v2:
> using generic dma-channels property instead of fsl,dma-channels.
>
>
> Documentation/devicetree/bindings/dma/fsl-edma.txt | 66 ++
> drivers/dma/Kconfig | 10 +
> drivers/dma/Makefile | 1 +
> drivers/dma/fsl-edma.c | 957 +++++++++++++++++++++
> 4 files changed, 1034 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/fsl-edma.txt
> create mode 100644 drivers/dma/fsl-edma.c
>
> diff --git a/Documentation/devicetree/bindings/dma/fsl-edma.txt b/Documentation/devicetree/bindings/dma/fsl-edma.txt
> new file mode 100644
> index 0000000..5a5fb61
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/fsl-edma.txt
> @@ -0,0 +1,66 @@
> +* Freescale enhanced Direct Memory Access(eDMA) Controller
> +
> + The eDMA channels have multiplex capability by programmble memory-mapped
> +registers. channels are split into two groups, called DMAMUX0 and DMAMUX1,
> +specific DMA request source can only be multiplexed by any channel of certain
> +group, DMAMUX0 or DMAMUX1, but not both.
> +
> +* eDMA Controller
> +Required properties:
> +- compatible :
> + - "fsl,vf610-edma" for eDMA used similar to that on Vybrid vf610 SoC
> +- reg : Specifies base physical address(s) and size of the eDMA registers.
> + The 1st region is eDMA control register's address and size.
> + The 2nd and the 3rd regions are programmable channel multiplexing
> + control register's address and size.
> +- interrupts : Should contain eDMA interrupt
> +- interrupt-names : Should be "edma-tx" for transmission interrupt and
> + "edma-err" for error interrupt
The description of interrupts and interrupt-names is a bit odd. How
about:
- interrupts: a list of interrupt-specifiers, one for each entry in
interrupt-names.
- interrupt names: should contain:
* "edma-tx" - the transmission interrupt.
* "edma-err" - the error interrupt.
> +- #dma-cells : Must be <2>.
> + The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for DMAMUX1).
> + Specific request source can only be multiplexed by specific channels
> + group called DMAMUX.
> + The 2nd cell specifies the request source(slot) ID.
> + See the SoC's reference manual for all the supported request sources.
> +- dma-channels : Number of channels supported by the controller
> +- clock-names : The channel group block clock names
> +- clocks : eDMA module clock
The set of expected clock-names should be well defined, and the example
has more than one clock..
This should be something like:
- clocks: a list of phandle + clock-specifier pairs, one for each entry
in clock-names.
- clock-names: a list of clock names. Should contain:
* "dmamux0" - <insert description here>
* "dmamux1" - <insert description here>
> +
> +
> +Examples:
> +
> +edma0: dma-controller at 40018000 {
> + #dma-cells = <2>;
> + compatible = "fsl,vf610-edma";
> + reg = <0x40018000 0x2000>,
> + <0x40024000 0x1000>,
> + <0x40025000 0x1000>;
> + interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>,
> + <0 9 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "edma-tx", "edma-err";
> + dma-channels = <32>;
> + clock-names = "dmamux0", "dmamux1";
> + clocks = <&clks VF610_CLK_DMAMUX0>,
> + <&clks VF610_CLK_DMAMUX1>;
> +};
[...]
> + for (i = 0; i < DMAMUX_NR; i++) {
> + char clkname[32];
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
> + fsl_edma->muxbase[i] = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(fsl_edma->muxbase[i]))
> + return PTR_ERR(fsl_edma->muxbase[i]);
> +
> + sprintf(clkname, "dmamux%d", i);
> + fsl_edma->muxclk[i] = of_clk_get(np, i);
> + fsl_edma->muxclk[i] = devm_clk_get(&pdev->dev, clkname);
The of_clk_get should disappear. It's always overwritten and
devm_clk_get will do what you want.
> + if (IS_ERR(fsl_edma->muxclk[i])) {
> + dev_err(&pdev->dev, "Missing DMAMUX block clock.\n");
> + return PTR_ERR(fsl_edma->muxclk[i]);
> + }
> +
> + ret = clk_prepare_enable(fsl_edma->muxclk[i]);
> + if (ret) {
> + dev_err(&pdev->dev, "DMAMUX clk block failed.\n");
> + return ret;
> + }
> +
> + }
> +
> + ret = fsl_edma_irq_init(pdev, fsl_edma);
> + if (ret)
> + return ret;
> +
> + fsl_edma->big_endian = of_property_read_bool(np, "big-endian");
This isn't in the binding.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Arnd Bergmann @ 2014-01-16 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115162210.GP15937@n2100.arm.linux.org.uk>
On Wednesday 15 January 2014, Russell King - ARM Linux wrote:
> The issue here is that we'll potentially now end up with three
> inversions. One in the GPIO layers. One in mmc_gpio_get_cd(), and
> another in every driver which uses the GPIO layer inversion. This
> is hardly the right approach as it leads to multiple points where
> confusion about the inverted status can occur.
I did not mean to suggest adding a third inversion. We already have
to deal with the one in the GPIO layer and the one in mmc_gpio_get_cd(),
which I absolutely agree is unfortunate. As was pointed out already,
the gpio driver used in this system does not support the inversion
in the DT binding, so the only proper solution is to use the
inversion from mmc_gpio_get_cd if MMC_CAP2_CD_ACTIVE_HIGH is set
in host->caps2. This flag gets set from mmc_of_parse based
on the presence of the "cd-inverted" flag, in the absence of the
gpio flags. The dw_mmc driver does not use mmc_of_parse() at the
moment, and while it probably should use that in the future,
it should definitely read the same DT properties with the
same semantics already and not introduce new properties.
Arnd
^ permalink raw reply
* [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Arnd Bergmann @ 2014-01-16 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D72FCD.1030005@gmail.com>
On Thursday 16 January 2014, Marc C wrote:
> > And then you can add a regular device driver to drivers/reset that provides a
> > device_reset() API to other drivers, or a system-reset function to be registered as
> > arm_pm_restart. This driver would use syscon_regmap_lookup_by_phandle() to get access
> > to a regmap pointer, and then use either hardcoded offsets into the regmap, or get
> > those offsets from numbers in the devicetree, as provided in the example above.
>
> I was able to port a standalone "reboot" driver using syscon + regmap. However, for the
> SMP initialization case, it turns out that syscon is configured after SMP init. Do you
> have any advice for this type of situation?
>
> I'd hate to go around in circles, but without resorting to hard-coded offsets, perhaps I
> can just add the remaining "non-regmap" register offsets in the DT?
You are not the first one to stumble over this problem. There are
two ways to get out of it, and we should probably implement both in
the long run:
1. Other platforms also require the syscon driver to be active before
the regular device driver probing starts. Michal Simek has the same
issue in the zynq clock driver that you have for SMP initialization.
We have talked about this with Mark Brown already, and I think we will
find a solution for this in the end, but it's not as straightforward
as I first hoped. We can probably use help in this area.
2. There is actually no reason for the SMP code to be called this early,
and multiple platforms would like to move SMP init to a later stage.
Stephen Boyd has recently started reworking the way we do SMP init,
and he may have some more insight.
In the meantime, I'd suggest you do the binding under the assumption
that it will work eventually, and then work around the current limitations
in the SMP code by looking for the device nodes you need and map them
manually, as you did in the previous versions of your patch set.
Arnd
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Russell King - ARM Linux @ 2014-01-16 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401161212.11246.arnd@arndb.de>
On Thu, Jan 16, 2014 at 12:12:10PM +0100, Arnd Bergmann wrote:
> On Wednesday 15 January 2014, Russell King - ARM Linux wrote:
> > The issue here is that we'll potentially now end up with three
> > inversions. One in the GPIO layers. One in mmc_gpio_get_cd(), and
> > another in every driver which uses the GPIO layer inversion. This
> > is hardly the right approach as it leads to multiple points where
> > confusion about the inverted status can occur.
>
> I did not mean to suggest adding a third inversion. We already have
> to deal with the one in the GPIO layer and the one in mmc_gpio_get_cd(),
> which I absolutely agree is unfortunate. As was pointed out already,
> the gpio driver used in this system does not support the inversion
> in the DT binding, so the only proper solution is to use the
> inversion from mmc_gpio_get_cd if MMC_CAP2_CD_ACTIVE_HIGH is set
> in host->caps2. This flag gets set from mmc_of_parse based
> on the presence of the "cd-inverted" flag, in the absence of the
> gpio flags. The dw_mmc driver does not use mmc_of_parse() at the
> moment, and while it probably should use that in the future,
> it should definitely read the same DT properties with the
> same semantics already and not introduce new properties.
Arnd,
The issue I'm pointing out is that _if_ you use the GPIO layer to do
the inversion, then you end up with _three_ inversions of the signal,
which is excessive and confusing - and makes the sense of
mmc_gpio_get_cd() completely indeterminant without reading the DT
files and the code.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v5 2/4] devicetree: bindings: Document Krait CPU/L1 EDAC
From: Lorenzo Pieralisi @ 2014-01-16 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116013840.GA674@codeaurora.org>
On Thu, Jan 16, 2014 at 01:38:40AM +0000, Stephen Boyd wrote:
> On 01/15, Stephen Boyd wrote:
> >
> > Ah sorry, I forgot to put the compatible property here like in
> > the dts change. I'll do that in the next revision. Yes we need a
> > compatible property here to match the platform driver.
> >
>
> This is the replacement patch
>
> -----8<------
> From: Stephen Boyd <sboyd@codeaurora.org>
> Subject: [PATCH v9] devicetree: bindings: Document Krait CPU/L1 EDAC
>
> The Krait CPU/L1 error reporting device is made up a per-CPU
> interrupt. While we're here, document the next-level-cache
> property that's used by the Krait EDAC driver.
>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 58 ++++++++++++++++++++++++++
> 1 file changed, 58 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> index 91304353eea4..03a529e791c4 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -62,6 +62,20 @@ nodes to be present and contain the properties described below.
> Value type: <u32>
> Definition: must be set to 0
>
> + - compatible
> + Usage: optional
> + Value type: <string>
> + Definition: should be one of the compatible strings listed
> + in the cpu node compatible property. This property
> + shall only be present if all the cpu nodes have the
> + same compatible property.
Do we really want to do that ? I am not sure. A cpus node is supposed to
be a container node, we should not define this binding just because we
know the kernel creates a platform device for it then.
interrupts is a cpu node property and I think it should be kept as such.
I know it will be duplicated and I know you can't rely on a platform
device for probing (since if I am not mistaken, removing a compatible
string from cpus prevents its platform device creation), but that's an issue
related to how the kernel works, you should not define DT bindings to solve
that IMHO.
Lorenzo
> +
> + - interrupts
> + Usage: required when node contains cpus with compatible
> + string "qcom,krait".
> + Value type: <prop-encoded-array>
> + Definition: L1/CPU error interrupt
> +
> - cpu node
>
> Description: Describes a CPU in an ARM based system
> @@ -191,6 +205,11 @@ nodes to be present and contain the properties described below.
> property identifying a 64-bit zero-initialised
> memory location.
>
> + - next-level-cache
> + Usage: optional
> + Value type: <phandle>
> + Definition: phandle pointing to the next level cache
> +
> Example 1 (dual-cluster big.LITTLE system 32-bit):
>
> cpus {
> @@ -382,3 +401,42 @@ cpus {
> cpu-release-addr = <0 0x20000000>;
> };
> };
> +
> +
> +Example 5 (Krait 32-bit system):
> +
> +cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <1 9 0xf04>;
> + compatible = "qcom,krait";
> +
> + cpu at 0 {
> + device_type = "cpu";
> + reg = <0>;
> + next-level-cache = <&L2>;
> + };
> +
> + cpu at 1 {
> + device_type = "cpu";
> + reg = <1>;
> + next-level-cache = <&L2>;
> + };
> +
> + cpu at 2 {
> + device_type = "cpu";
> + reg = <2>;
> + next-level-cache = <&L2>;
> + };
> +
> + cpu at 3 {
> + device_type = "cpu";
> + reg = <3>;
> + next-level-cache = <&L2>;
> + };
> +
> + L2: l2-cache {
> + compatible = "cache";
> + interrupts = <0 2 0x4>;
> + };
> +};
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
^ permalink raw reply
* [PATCH 02/12] SPEAr13xx: Move SPEAr1340 definitions to header file
From: Arnd Bergmann @ 2014-01-16 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116091908.GC2290@pratyush-vbox>
On Thursday 16 January 2014, Pratyush Anand wrote:
> > Though we are almost ready with v2. But few concerns:
> >
> > There are Spear soc common register used for misc configurations of clock, reset etc for all ips. Few of
> > registers from the same area are also used for pcie/sata muxing and auxiliary clock configurations.
> > For example: sata_miphy_init in arch/arm/mach-spear/spear1340.c also uses these registers.
> >
> > We have moved all these sata specific spear1340 configurations in a separate driver. On the basis of spear-ahci dt
> > Node this driver's probe is called, which further adds ahci platform driver.
> > We plan to put all spear1340/1310_pcie_miphy_init/exit functions of patch 9/12 of this series in
> > The same driver.
> >
> > Now our concern is, what could be the best place to keep that driver, phy, reset or any other framework?
> > Or we keep this new driver in arch/arm/mach-spear only.
>
> I think this misc configuration register block resource should be
> passed to syscon (drivers/mfd/syscon.c) driver.
>
> regmap_update_bits should be used to update these registers and hence
> to configure pcie/sata settings.
>
> As far as place is concerned, that can be kept into mfd and can be
> named as spear13xx-syscon.c
>
> Whats your opinion arnd?
That sounds exactly like what I would have suggested, thanks!
One question remains, which is what driver should directly use
syscon_regmap_lookup_by_phandle() to get the syscon registers themselves,
and which ones should use a higher-level abstraction from spear13xx-syscon.c.
We can decide this on a case-by-case basis, but in general I would suggest
to have drivers use syscon_regmap_lookup_by_phandle directly as long as
it doesn't cause significant code duplication between drivers.
Arnd
^ permalink raw reply
* [PATCH 02/12] SPEAr13xx: Move SPEAr1340 definitions to header file
From: Pratyush Anand @ 2014-01-16 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401161233.40811.arnd@arndb.de>
On Thu, Jan 16, 2014 at 07:33:40PM +0800, Arnd Bergmann wrote:
> On Thursday 16 January 2014, Pratyush Anand wrote:
> > > Though we are almost ready with v2. But few concerns:
> > >
> > > There are Spear soc common register used for misc configurations of clock, reset etc for all ips. Few of
> > > registers from the same area are also used for pcie/sata muxing and auxiliary clock configurations.
> > > For example: sata_miphy_init in arch/arm/mach-spear/spear1340.c also uses these registers.
> > >
> > > We have moved all these sata specific spear1340 configurations in a separate driver. On the basis of spear-ahci dt
> > > Node this driver's probe is called, which further adds ahci platform driver.
> > > We plan to put all spear1340/1310_pcie_miphy_init/exit functions of patch 9/12 of this series in
> > > The same driver.
> > >
> > > Now our concern is, what could be the best place to keep that driver, phy, reset or any other framework?
> > > Or we keep this new driver in arch/arm/mach-spear only.
> >
> > I think this misc configuration register block resource should be
> > passed to syscon (drivers/mfd/syscon.c) driver.
> >
> > regmap_update_bits should be used to update these registers and hence
> > to configure pcie/sata settings.
> >
> > As far as place is concerned, that can be kept into mfd and can be
> > named as spear13xx-syscon.c
> >
> > Whats your opinion arnd?
>
> That sounds exactly like what I would have suggested, thanks!
>
> One question remains, which is what driver should directly use
> syscon_regmap_lookup_by_phandle() to get the syscon registers themselves,
> and which ones should use a higher-level abstraction from spear13xx-syscon.c.
>
> We can decide this on a case-by-case basis, but in general I would suggest
> to have drivers use syscon_regmap_lookup_by_phandle directly as long as
> it doesn't cause significant code duplication between drivers.
Yes, I think so.
Regards
Pratyush
>
> Arnd
^ permalink raw reply
* Huge lockdep warning from sdhci/imx esdhc code
From: Russell King - ARM Linux @ 2014-01-16 11:46 UTC (permalink / raw)
To: linux-arm-kernel
======================================================
[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
3.13.0-rc7+ #401 Not tainted
------------------------------------------------------
kworker/u8:1/44 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
(prepare_lock){+.+.+.}, at: [<c04d10d4>] clk_prepare_lock+0x80/0xf4
and this task is already holding:
(&(&host->lock)->rlock){-.-...}, at: [<c04b0528>] sdhci_do_set_ios+0x20/0x740
which would create a new lock dependency:
(&(&host->lock)->rlock){-.-...} -> (prepare_lock){+.+.+.}
but this new dependency connects a HARDIRQ-irq-safe lock:
(&(&host->lock)->rlock){-.-...}
... which became HARDIRQ-irq-safe at:
[<c0062e18>] mark_lock+0x15c/0x704
[<c0063f4c>] __lock_acquire+0xb8c/0x1e14
[<c00657a0>] lock_acquire+0xa4/0x114
[<c0687c88>] _raw_spin_lock+0x34/0x44
[<c04af8f0>] sdhci_irq+0x20/0xa14
[<c006fc78>] handle_irq_event_percpu+0x68/0x254
[<c006fea8>] handle_irq_event+0x44/0x64
[<c0072eac>] handle_fasteoi_irq+0xac/0x180
[<c006f5d4>] generic_handle_irq+0x28/0x38
[<c000f294>] handle_IRQ+0x40/0x98
[<c0008548>] gic_handle_irq+0x30/0x64
[<c00132c4>] __irq_svc+0x44/0x58
[<c02f36f4>] pin_get_from_name+0x6c/0x8c
[<c02f57a8>] pinconf_map_to_setting+0x44/0xb0
[<c02f3014>] pinctrl_get+0x2fc/0x430
[<c02f35ac>] devm_pinctrl_get+0x34/0x68
[<c0384964>] pinctrl_bind_pins+0x38/0xfc
[<c036bd64>] driver_probe_device+0x74/0x248
[<c036bfd4>] __driver_attach+0x9c/0xa0
[<c036a548>] bus_for_each_dev+0x70/0x94
[<c036ba08>] driver_attach+0x24/0x28
[<c036b560>] bus_add_driver+0x14c/0x1dc
[<c036c678>] driver_register+0x80/0xfc
[<c036d424>] __platform_driver_register+0x50/0x64
[<c092847c>] sdhci_esdhc_imx_driver_init+0x18/0x20
[<c0008800>] do_one_initcall+0x38/0x168
[<c08f5c6c>] kernel_init_freeable+0x104/0x1d0
[<c06811bc>] kernel_init+0x10/0xec
[<c000ea48>] ret_from_fork+0x14/0x2c
to a HARDIRQ-irq-unsafe lock:
(prepare_lock){+.+.+.}
... which became HARDIRQ-irq-unsafe at:
... [<c0062e18>] mark_lock+0x15c/0x704
[<c006604c>] mark_held_locks+0x70/0x150
[<c00661dc>] trace_hardirqs_on_caller+0xb0/0x1b8
[<c00662f8>] trace_hardirqs_on+0x14/0x18
[<c0684c7c>] mutex_trylock+0x174/0x1f0
[<c04d1068>] clk_prepare_lock+0x14/0xf4
[<c04d1bb8>] clk_notifier_register+0x34/0xf8
[<c0015134>] twd_clk_init+0x3c/0x50
[<c0008800>] do_one_initcall+0x38/0x168
[<c08f5c6c>] kernel_init_freeable+0x104/0x1d0
[<c06811bc>] kernel_init+0x10/0xec
[<c000ea48>] ret_from_fork+0x14/0x2c
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(prepare_lock);
local_irq_disable();
lock(&(&host->lock)->rlock);
lock(prepare_lock);
<Interrupt>
lock(&(&host->lock)->rlock);
*** DEADLOCK ***
3 locks held by kworker/u8:1/44:
#0: (kmmcd){.+.+..}, at: [<c003d498>] process_one_work+0x130/0x4ac
#1: ((&(&host->detect)->work)){+.+...}, at: [<c003d498>] process_one_work+0x130/0x4ac
#2: (&(&host->lock)->rlock){-.-...}, at: [<c04b0528>] sdhci_do_set_ios+0x20/0x740
the dependencies between HARDIRQ-irq-safe lock and the holding lock:
-> (&(&host->lock)->rlock){-.-...} ops: 183 {
IN-HARDIRQ-W at:
[<c0062e18>] mark_lock+0x15c/0x704
[<c0063f4c>] __lock_acquire+0xb8c/0x1e14
[<c00657a0>] lock_acquire+0xa4/0x114
[<c0687c88>] _raw_spin_lock+0x34/0x44
[<c04af8f0>] sdhci_irq+0x20/0xa14
[<c006fc78>] handle_irq_event_percpu+0x68/0x254
[<c006fea8>] handle_irq_event+0x44/0x64
[<c0072eac>] handle_fasteoi_irq+0xac/0x180
[<c006f5d4>] generic_handle_irq+0x28/0x38
[<c000f294>] handle_IRQ+0x40/0x98
[<c0008548>] gic_handle_irq+0x30/0x64
[<c00132c4>] __irq_svc+0x44/0x58
[<c02f36f4>] pin_get_from_name+0x6c/0x8c
[<c02f57a8>] pinconf_map_to_setting+0x44/0xb0
[<c02f3014>] pinctrl_get+0x2fc/0x430
[<c02f35ac>] devm_pinctrl_get+0x34/0x68
[<c0384964>] pinctrl_bind_pins+0x38/0xfc
[<c036bd64>] driver_probe_device+0x74/0x248
[<c036bfd4>] __driver_attach+0x9c/0xa0
[<c036a548>] bus_for_each_dev+0x70/0x94
[<c036ba08>] driver_attach+0x24/0x28
[<c036b560>] bus_add_driver+0x14c/0x1dc
[<c036c678>] driver_register+0x80/0xfc
[<c036d424>] __platform_driver_register+0x50/0x64
[<c092847c>] sdhci_esdhc_imx_driver_init+0x18/0x20
[<c0008800>] do_one_initcall+0x38/0x168
[<c08f5c6c>] kernel_init_freeable+0x104/0x1d0
[<c06811bc>] kernel_init+0x10/0xec
[<c000ea48>] ret_from_fork+0x14/0x2c
IN-SOFTIRQ-W at:
[<c0062e18>] mark_lock+0x15c/0x704
[<c0063974>] __lock_acquire+0x5b4/0x1e14
[<c00657a0>] lock_acquire+0xa4/0x114
[<c0687da0>] _raw_spin_lock_irqsave+0x4c/0x60
[<c04b19c4>] sdhci_tasklet_finish+0x1c/0x120
[<c00298d4>] tasklet_action+0x6c/0x104
[<c00290ec>] __do_softirq+0x118/0x2d8
[<c0029698>] irq_exit+0xc0/0x110
[<c000f298>] handle_IRQ+0x44/0x98
[<c0008548>] gic_handle_irq+0x30/0x64
[<c00132c4>] __irq_svc+0x44/0x58
[<c02f36f4>] pin_get_from_name+0x6c/0x8c
[<c02f57a8>] pinconf_map_to_setting+0x44/0xb0
[<c02f3014>] pinctrl_get+0x2fc/0x430
[<c02f35ac>] devm_pinctrl_get+0x34/0x68
[<c0384964>] pinctrl_bind_pins+0x38/0xfc
[<c036bd64>] driver_probe_device+0x74/0x248
[<c036bfd4>] __driver_attach+0x9c/0xa0
[<c036a548>] bus_for_each_dev+0x70/0x94
[<c036ba08>] driver_attach+0x24/0x28
[<c036b560>] bus_add_driver+0x14c/0x1dc
[<c036c678>] driver_register+0x80/0xfc
[<c036d424>] __platform_driver_register+0x50/0x64
[<c092847c>] sdhci_esdhc_imx_driver_init+0x18/0x20
[<c0008800>] do_one_initcall+0x38/0x168
[<c08f5c6c>] kernel_init_freeable+0x104/0x1d0
[<c06811bc>] kernel_init+0x10/0xec
[<c000ea48>] ret_from_fork+0x14/0x2c
INITIAL USE at:
[<c0062e18>] mark_lock+0x15c/0x704
[<c00636c8>] __lock_acquire+0x308/0x1e14
[<c00657a0>] lock_acquire+0xa4/0x114
[<c0687da0>] _raw_spin_lock_irqsave+0x4c/0x60
[<c04b0528>] sdhci_do_set_ios+0x20/0x740
[<c04b0490>] sdhci_set_ios+0x2c/0x38
[<c049c8e8>] mmc_power_up+0x70/0xd4
[<c049d63c>] mmc_start_host+0x44/0x70
[<c049e0ac>] mmc_add_host+0x4c/0x70
[<c04b1490>] sdhci_add_host+0x848/0xc30
[<c04b41a8>] sdhci_esdhc_imx_probe+0x320/0x5fc
[<c036d508>] platform_drv_probe+0x24/0x54
[<c036bd94>] driver_probe_device+0xa4/0x248
[<c036bfd4>] __driver_attach+0x9c/0xa0
[<c036a548>] bus_for_each_dev+0x70/0x94
[<c036ba08>] driver_attach+0x24/0x28
[<c036b560>] bus_add_driver+0x14c/0x1dc
[<c036c678>] driver_register+0x80/0xfc
[<c036d424>] __platform_driver_register+0x50/0x64
[<c092847c>] sdhci_esdhc_imx_driver_init+0x18/0x20
[<c0008800>] do_one_initcall+0x38/0x168
[<c08f5c6c>] kernel_init_freeable+0x104/0x1d0
[<c06811bc>] kernel_init+0x10/0xec
[<c000ea48>] ret_from_fork+0x14/0x2c
}
... key at: [<c0f25cf4>] __key.24505+0x0/0x8
... acquired at:
[<c0062628>] check_usage+0x3fc/0x618
[<c00628a0>] check_irq_usage+0x5c/0xb8
[<c00644c0>] __lock_acquire+0x1100/0x1e14
[<c00657a0>] lock_acquire+0xa4/0x114
[<c0686668>] mutex_lock_nested+0x5c/0x39c
[<c04d10d4>] clk_prepare_lock+0x80/0xf4
[<c04d1f14>] clk_get_rate+0x14/0x64
[<c04b3414>] esdhc_pltfm_set_clock+0x20/0x2ac
[<c04ada78>] sdhci_set_clock+0x4c/0x410
[<c04b05f0>] sdhci_do_set_ios+0xe8/0x740
[<c04b0490>] sdhci_set_ios+0x2c/0x38
[<c049cac4>] mmc_power_off+0x64/0x84
[<c049d5b8>] mmc_rescan+0x29c/0x2dc
[<c003d51c>] process_one_work+0x1b4/0x4ac
[<c003e8fc>] worker_thread+0x13c/0x410
[<c00451a8>] kthread+0xd0/0xec
[<c000ea48>] ret_from_fork+0x14/0x2c
the dependencies between the lock to be acquired and HARDIRQ-irq-unsafe lock:
-> (prepare_lock){+.+.+.} ops: 314 {
HARDIRQ-ON-W at:
[<c0062e18>] mark_lock+0x15c/0x704
[<c006604c>] mark_held_locks+0x70/0x150
[<c00661dc>] trace_hardirqs_on_caller+0xb0/0x1b8
[<c00662f8>] trace_hardirqs_on+0x14/0x18
[<c0684c7c>] mutex_trylock+0x174/0x1f0
[<c04d1068>] clk_prepare_lock+0x14/0xf4
[<c04d1bb8>] clk_notifier_register+0x34/0xf8
[<c0015134>] twd_clk_init+0x3c/0x50
[<c0008800>] do_one_initcall+0x38/0x168
[<c08f5c6c>] kernel_init_freeable+0x104/0x1d0
[<c06811bc>] kernel_init+0x10/0xec
[<c000ea48>] ret_from_fork+0x14/0x2c
SOFTIRQ-ON-W at:
[<c0062e18>] mark_lock+0x15c/0x704
[<c006604c>] mark_held_locks+0x70/0x150
[<c0066220>] trace_hardirqs_on_caller+0xf4/0x1b8
[<c00662f8>] trace_hardirqs_on+0x14/0x18
[<c0684c7c>] mutex_trylock+0x174/0x1f0
[<c04d1068>] clk_prepare_lock+0x14/0xf4
[<c04d1bb8>] clk_notifier_register+0x34/0xf8
[<c0015134>] twd_clk_init+0x3c/0x50
[<c0008800>] do_one_initcall+0x38/0x168
[<c08f5c6c>] kernel_init_freeable+0x104/0x1d0
[<c06811bc>] kernel_init+0x10/0xec
[<c000ea48>] ret_from_fork+0x14/0x2c
RECLAIM_FS-ON-W at:
[<c0062e18>] mark_lock+0x15c/0x704
[<c006604c>] mark_held_locks+0x70/0x150
[<c00668bc>] lockdep_trace_alloc+0xac/0xf8
[<c00c8674>] __alloc_pages_nodemask+0x70/0x8dc
[<c00fb8a4>] new_slab+0x74/0x244
[<c00fcb3c>] __slab_alloc.clone.67.clone.74+0x124/0x4dc
[<c00fd000>] kmem_cache_alloc+0x10c/0x158
[<c011b3e4>] alloc_inode+0x5c/0xa4
[<c011c920>] new_inode_pseudo+0x10/0x48
[<c011c970>] new_inode+0x18/0x30
[<c0291444>] debugfs_mknod.clone.16.clone.17+0x40/0x12c
[<c02915f0>] __create_file+0xc0/0x1cc
[<c02917c8>] debugfs_create_file+0x30/0x38
[<c0291af4>] debugfs_create_x32+0x50/0x60
[<c04d1310>] clk_debug_create_subtree+0x64/0x120
[<c09296bc>] clk_debug_init+0xac/0x134
[<c0008800>] do_one_initcall+0x38/0x168
[<c08f5c6c>] kernel_init_freeable+0x104/0x1d0
[<c06811bc>] kernel_init+0x10/0xec
[<c000ea48>] ret_from_fork+0x14/0x2c
INITIAL USE at:
[<c0062e18>] mark_lock+0x15c/0x704
[<c00636c8>] __lock_acquire+0x308/0x1e14
[<c00657a0>] lock_acquire+0xa4/0x114
[<c0684c10>] mutex_trylock+0x108/0x1f0
[<c04d1068>] clk_prepare_lock+0x14/0xf4
[<c04d318c>] __clk_init+0x20/0x460
[<c04d369c>] _clk_register+0xd0/0x164
[<c04d37ec>] clk_register+0x48/0x8c
[<c04d416c>] clk_register_fixed_rate+0x8c/0xd0
[<c04d4218>] of_fixed_clk_setup+0x68/0x90
[<c0929788>] of_clk_init+0x44/0x6c
[<c08f9458>] time_init+0x2c/0x38
[<c08f59f4>] start_kernel+0x1e0/0x354
[<10008074>] 0x10008074
}
... key at: [<c09a1acc>] prepare_lock+0x38/0x48
... acquired at:
[<c0062658>] check_usage+0x42c/0x618
[<c00628a0>] check_irq_usage+0x5c/0xb8
[<c00644c0>] __lock_acquire+0x1100/0x1e14
[<c00657a0>] lock_acquire+0xa4/0x114
[<c0686668>] mutex_lock_nested+0x5c/0x39c
[<c04d10d4>] clk_prepare_lock+0x80/0xf4
[<c04d1f14>] clk_get_rate+0x14/0x64
[<c04b3414>] esdhc_pltfm_set_clock+0x20/0x2ac
[<c04ada78>] sdhci_set_clock+0x4c/0x410
[<c04b05f0>] sdhci_do_set_ios+0xe8/0x740
[<c04b0490>] sdhci_set_ios+0x2c/0x38
[<c049cac4>] mmc_power_off+0x64/0x84
[<c049d5b8>] mmc_rescan+0x29c/0x2dc
[<c003d51c>] process_one_work+0x1b4/0x4ac
[<c003e8fc>] worker_thread+0x13c/0x410
[<c00451a8>] kthread+0xd0/0xec
[<c000ea48>] ret_from_fork+0x14/0x2c
stack backtrace:
CPU: 1 PID: 44 Comm: kworker/u8:1 Not tainted 3.13.0-rc7+ #401
Workqueue: kmmcd mmc_rescan
Backtrace:
[<c0012630>] (dump_backtrace) from [<c00127cc>] (show_stack+0x18/0x1c)
r6:ea3b7bb4 r5:c0a73520 r4:00000000 r3:ea352400
[<c00127b4>] (show_stack) from [<c06831f8>] (dump_stack+0x70/0x90)
[<c0683188>] (dump_stack) from [<c0062678>] (check_usage+0x44c/0x618)
r4:00000001 r3:ea352400
[<c006222c>] (check_usage) from [<c00628a0>] (check_irq_usage+0x5c/0xb8)
r10:00000030 r9:ea3527d0 r8:ea3527e8 r7:ea3527d0 r6:c0695968 r5:ea352400
r4:00000000
[<c0062844>] (check_irq_usage) from [<c00644c0>] (__lock_acquire+0x1100/0x1e14)
r8:00000002 r7:c0f1b104 r6:c0ea98fc r5:ea352400 r4:c0a5ac00
[<c00633c0>] (__lock_acquire) from [<c00657a0>] (lock_acquire+0xa4/0x114)
r10:00000000 r9:00000002 r8:00000000 r7:00000000 r6:c09a1acc r5:ea3b6000
r4:00000000
[<c00656fc>] (lock_acquire) from [<c0686668>] (mutex_lock_nested+0x5c/0x39c)
r10:ea352400 r9:00000002 r8:ea3b6000 r7:00000000 r6:c0ea98fc r5:c04d10d4
r4:c09a1a94
[<c068660c>] (mutex_lock_nested) from [<c04d10d4>] (clk_prepare_lock+0x80/0xf4)
r10:ea3b6000 r9:00000002 r8:ea397c10 r7:20000113 r6:e9841c40 r5:ea3b6000
r4:c0f25f84
[<c04d1054>] (clk_prepare_lock) from [<c04d1f14>] (clk_get_rate+0x14/0x64)
r6:e9841c40 r5:00000000 r4:ea028280 r3:c04b33f4
[<c04d1f00>] (clk_get_rate) from [<c04b3414>] (esdhc_pltfm_set_clock+0x20/0x2ac) r5:00000000 r4:e9841c40
[<c04b33f4>] (esdhc_pltfm_set_clock) from [<c04ada78>] (sdhci_set_clock+0x4c/0x410)
r10:ea3b6000 r9:00000002 r8:00000000 r7:20000113 r6:e9841d18 r5:00000000
r4:e9841c40 r3:c04b33f4
[<c04ada2c>] (sdhci_set_clock) from [<c04b05f0>] (sdhci_do_set_ios+0xe8/0x740)
r10:ea3b6000 r9:00000002 r8:00000000 r7:20000113 r6:e9841d18 r5:e9841aa8
r4:e9841c40 r3:00000000
[<c04b0508>] (sdhci_do_set_ios) from [<c04b0490>] (sdhci_set_ios+0x2c/0x38)
r10:ea3b6000 r8:00000000 r7:ea18a100 r6:e9841aa8 r5:e9841c40 r4:e9841800
[<c04b0464>] (sdhci_set_ios) from [<c049cac4>] (mmc_power_off+0x64/0x84)
r6:c076a858 r5:c076a858 r4:e9841800 r3:c04b0464
[<c049ca60>] (mmc_power_off) from [<c049d5b8>] (mmc_rescan+0x29c/0x2dc)
[<c049d31c>] (mmc_rescan) from [<c003d51c>] (process_one_work+0x1b4/0x4ac)
r6:ea00dc00 r5:ea393080 r4:e9841af8 r3:c049d31c
[<c003d368>] (process_one_work) from [<c003e8fc>] (worker_thread+0x13c/0x410)
r10:ea00de80 r9:ea3b6000 r8:ea393098 r7:ea3b6000 r6:ea00dc30 r5:ea00dc00
r4:ea393080
[<c003e7c0>] (worker_thread) from [<c00451a8>] (kthread+0xd0/0xec)
r10:00000000 r9:00000000 r8:c003e7c0 r7:ea393080 r6:ea3b7f24 r5:ea392540
r4:00000000
[<c00450d8>] (kthread) from [<c000ea48>] (ret_from_fork+0x14/0x2c)
r8:00000000 r7:00000000 r6:00000000 r5:c00450d8 r4:ea392540
static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
{
unsigned long flags;
int vdd_bit = -1;
u8 ctrl;
spin_lock_irqsave(&host->lock, flags);
...
sdhci_set_clock(host, ios->clock);
which then goes on to call esdhc_pltfm_set_clock(), and clk_get_rate(),
where clk_get_rate() takes a mutex - and you can't take a mutex under
an IRQs-off region.
This appears to be provoked by providing the non-removable property.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] ARM64: perf: support dwarf unwinding in compat mode
From: Will Deacon @ 2014-01-16 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389869123-5884-1-git-send-email-jean.pihet@linaro.org>
Hi Jean,
On Thu, Jan 16, 2014 at 10:45:23AM +0000, Jean Pihet wrote:
> Add support for unwinding using the dwarf information in compat
> mode. Using the correct user stack pointer allows perf to record
> the frames correctly in the native and compat modes.
>
> Note that although the dwarf frame unwinding works ok using
> libunwind in native mode (on ARMv7 & ARMv8), some changes are
> required to the libunwind code for the compat mode. Those changes
> are posted separately on the libunwind mailing list.
>
> Tested on ARMv8 platform with v8 and compat v7 binaries, the latter
> are statically built.
I guess it makes sense to include this with your earlier series adding
support for compat backtracing?
> Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
> ---
> arch/arm64/include/asm/ptrace.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
> index fbb0020..86d5b54 100644
> --- a/arch/arm64/include/asm/ptrace.h
> +++ b/arch/arm64/include/asm/ptrace.h
> @@ -133,7 +133,7 @@ struct pt_regs {
> (!((regs)->pstate & PSR_F_BIT))
>
> #define user_stack_pointer(regs) \
> - ((regs)->sp)
> + (!compat_user_mode(regs)) ? ((regs)->sp) : ((regs)->compat_sp)
In your previous series, compat backtracing is actually split out into a
separate function (compat_user_backtrace), so it would be more consistent to
have a compat_user_stack_pointer macro, rather than add this check here.
Will
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox