* [PATCH 1/2] PWM: let of_xlate handlers check args count
From: Lothar Waßmann @ 2014-01-23 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390467898-9216-2-git-send-email-s.hauer@pengutronix.de>
Hi,
Sascha Hauer wrote:
> of_pwm_n_cells for the of_xlate handler is stored in struct pwm_chip,
> but it is only ever used by the of_xlate handler itsel. Remove
> of_pwm_n_cells from struct pwm_chip and let the handler do the argument
> count checking to simplify the code.
>
This still does not make the PWM_POLARITY flag in the pwms node
optional as was the goal because of_parse_phandle_with_args() requires
at least #pwm-cells arguments in the node.
So, with a DT configuration like:
pwm0: pwm at 0 {
#pwm-cells = <3>;
};
backlight {
pwms = <&pwm0 0 100000>;
};
the driver will bail out at of_parse_phandle_with_args() in
of_pwm_get() with the error message:
"/backlight: arguments longer than property" and never reach your
clever xlate function.
Thus you will still need to replace of_parse_phandle_with_args()
with different code that copies most but not all of the functionality.
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH V2 0/8] PCI: Add SPEAr13xx PCIe support
From: Mohit Kumar @ 2014-01-23 10:56 UTC (permalink / raw)
To: linux-arm-kernel
First five patches are improvement and fixes for SPEAr13xx support.
PCIe driver support for SPEAr1310/40 platform board is added.
These patches are tested with SPEAr1310 evaluation board:
- INTEL PRO 100/100 EP card
- USB xhci gen2 card
- Above cards connected through LeCROY PTC switch
Modifications for SATA are tested with SPEAr1340-evb board
Changes since v1:
- Few patches of the series are already accepted and applied to mainline e.g.
pcie designware driver improvements,fixes for IO translation bug, PCIe dw
driver maintainer. So dropped these from v2.
- Incorporated comment to move the common/reset PCIe code to the seperate driver
- PCIe and SATA share common PHY configuration registers, so move SATA
platform code to the system config driver
- Incorporated comments for FUSE_FS option for defconfig
- Incorporated comments to move back the SPEAr1340 definations from .h file
Mohit Kumar (3):
SPEAr13xx: Set dt field entry <stmmac,phy-addr> for phy probe
SPEAr13xx: defconfig: Update
MAINTAINERS: Add ST SPEAr13xx PCIe driver maintainer
Pratyush Anand (5):
ahci: Add a driver_data field to struct ahci_platform_data
SPEAr13xx: Fixup: Move SPEAr1340 SATA platform code to system cfg
driver
clk: SPEAr13xx: Fix pcie clock name
SPEAr13xx: Fix static mapping table
pcie: SPEAr13xx: Add designware pcie support
MAINTAINERS | 6 +
arch/arm/boot/dts/spear13xx.dtsi | 63 ++++-
arch/arm/configs/spear13xx_defconfig | 16 +
arch/arm/mach-spear/Kconfig | 2 +
arch/arm/mach-spear/include/mach/spear.h | 4 +-
arch/arm/mach-spear/spear1340.c | 127 +---------
arch/arm/mach-spear/spear13xx.c | 2 +-
drivers/clk/spear/spear1310_clock.c | 6 +-
drivers/clk/spear/spear1340_clock.c | 2 +-
drivers/mfd/Makefile | 1 +
drivers/mfd/spear13xx-cfg.c | 444 ++++++++++++++++++++++++++++++
drivers/pci/host/Kconfig | 5 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-spear13xx.c | 394 ++++++++++++++++++++++++++
include/linux/ahci_platform.h | 1 +
15 files changed, 939 insertions(+), 135 deletions(-)
create mode 100644 drivers/mfd/spear13xx-cfg.c
create mode 100644 drivers/pci/host/pcie-spear13xx.c
^ permalink raw reply
* [PATCH 1/2] PWM: let of_xlate handlers check args count
From: Sascha Hauer @ 2014-01-23 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123115632.6d3f1a58@ipc1.ka-ro>
On Thu, Jan 23, 2014 at 11:56:32AM +0100, Lothar Wa?mann wrote:
> Hi,
>
> Sascha Hauer wrote:
> > of_pwm_n_cells for the of_xlate handler is stored in struct pwm_chip,
> > but it is only ever used by the of_xlate handler itsel. Remove
> > of_pwm_n_cells from struct pwm_chip and let the handler do the argument
> > count checking to simplify the code.
> >
> This still does not make the PWM_POLARITY flag in the pwms node
> optional as was the goal because of_parse_phandle_with_args() requires
> at least #pwm-cells arguments in the node.
>
> So, with a DT configuration like:
> pwm0: pwm at 0 {
> #pwm-cells = <3>;
> };
> backlight {
> pwms = <&pwm0 0 100000>;
> };
We misunderstood each other. My goal was to allow the driver to also
work with old devicetrees which specify #pwm-cells = <2>, not to allow
inconsistent devicetrees like the snippet above.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Willy Tarreau @ 2014-01-23 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87sisfjeba.fsf@natisbad.org>
On Thu, Jan 23, 2014 at 09:24:41AM +0100, Arnaud Ebalard wrote:
> Hi Sarah,
>
> Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
>
> >> > Can you pinpoint the commit that introduced the regression?
> >>
> >> f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts."
> >>
> >> Technically, this is not per se the commit which introduced the
> >> regression but the one that *partially* fixed it by introducing the XHCI
> >> quirk to skip MSI enabling for Fresco Logic chips. The thing is it
> >> should have included the FL1009 in the targets. Sarah, can you confirm
> >> this?
> >
> > I don't know if it should have included FL1009, it was just a guess,
> > based on the fact that the 0x1000 and 0x1400 devices did need MSI
> > disabled. I can attempt to ask the Fresco Logic folks I know, but I'm
> > not sure if/when I'll get a response back.
> >
> > That still doesn't necessarily rule out MSI issues in the Marvell PCI
> > host controller code. Can you attach another PCI device with MSI
> > support under the host and see if it works?
>
> The various Armada-based devices I have are NAS which do not have PCIe
> slots to plug additional devices (everything is soldered). I don't know
> which device Thomas used for its tests. Just in case, I also added Willy
> in CC: who have various boards and may also have done more test with
> additional PCIe devices and CONFIG_PCI_MSI enabled on 3.13 kernel.
I've been running an intel i350 dual-port NIC (igb driver) supporting
MSI on the mirabox, and it used to work in 3.10+many of the patches
coming from the Free-electrons team. Some recent changes to the PCI
code introduced a regression preventing this driver from correctly
registering an MSI interrupt, and I did not have enough time to
investigate it deep enough to fix it. That said, I know how to hack
it to work again, so if it can be of any use, I can run a test on
the mirabox (armada370) and on the XPGP board (armadaXP).
Willy
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Ezequiel Garcia @ 2014-01-23 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0591E.6030009@gmail.com>
On Thu, Jan 23, 2014 at 12:49:50AM +0100, Sebastian Hesselbarth wrote:
[..]
> > Notice that Ezequiel has added an IRQ handler that just calls panic,
> > so a spurious interrupt call is VERY VERY BAD.
>
> And I understand that he now clears watchdog's register before
> requesting an irq. All that is missing is bridge_irq driver clearing
> CAUSE register after masking all irqs, right?
>
Are you sure clearing the CAUSE register after masking the IRQs will be enough?
AFAICS, until now nobody unmasks the watchdog IRQ (at least the orion_wdt
driver didn't request the interruption) but *still* the CAUSE register is set
upon watchdog expiration. So I would guessed a masked interrupt still raises a
bit in the CAUSE register.
Although I'm no sure I'm making sense here or just noise...
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 6/6] arm64: add EFI runtime services
From: Catalin Marinas @ 2014-01-23 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389392950-22457-7-git-send-email-msalter@redhat.com>
On Fri, Jan 10, 2014 at 10:29:10PM +0000, Mark Salter wrote:
> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
> new file mode 100644
> index 0000000..a835b2c
> --- /dev/null
> +++ b/arch/arm64/include/asm/efi.h
> @@ -0,0 +1,12 @@
> +#ifndef _ASM_ARM64_EFI_H
> +#define _ASM_ARM64_EFI_H
__ASM_EFI_H please for consistency with the other files.
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> new file mode 100644
> index 0000000..a42dc38
> --- /dev/null
> +++ b/arch/arm64/kernel/efi.c
> @@ -0,0 +1,353 @@
> +/*
> + * Extensible Firmware Interface
> + *
> + * Based on Extensible Firmware Interface Specification version 2.4
> + *
> + * Copyright (C) 2013 Linaro Ltd.
> + *
> + * 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/efi.h>
> +#include <linux/export.h>
> +#include <linux/memblock.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +
> +#include <asm/cacheflush.h>
> +#include <asm/efi.h>
> +#include <asm/tlbflush.h>
> +#include <asm/mmu_context.h>
> +
> +struct efi_memory_map memmap;
Is this variable used outside this file or from common code? It has a
too generic name, may clash with other things.
> +static unsigned long arm_efi_facility;
You could drop the "arm_" prefix here, that's just local to this file.
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 5516f54..7a45095 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -41,6 +41,7 @@
> #include <linux/memblock.h>
> #include <linux/of_fdt.h>
> #include <linux/of_platform.h>
> +#include <linux/efi.h>
>
> #include <asm/fixmap.h>
> #include <asm/cputype.h>
> @@ -55,6 +56,7 @@
> #include <asm/traps.h>
> #include <asm/memblock.h>
> #include <asm/psci.h>
> +#include <asm/efi.h>
>
> unsigned int processor_id;
> EXPORT_SYMBOL(processor_id);
> @@ -229,9 +231,13 @@ void __init setup_arch(char **cmdline_p)
>
> arm64_memblock_init();
>
> + efi_init();
> paging_init();
> request_standard_resources();
>
> + if (efi_enabled(EFI_BOOT))
> + efi_enter_virtual_mode();
The common start_kernel() function already has this call:
#ifdef CONFIG_X86
if (efi_enabled(EFI_RUNTIME_SERVICES))
efi_enter_virtual_mode();
#endif
Could we not use it for arm64 as well? Ideally with an empty
efi_enter_virtual_mode() in include/linux/efi.h if !CONFIG_EFI but I
noticed that ia64 does a separate call and they don't seem to have
efi_enabled(), so probably not feasible for them.
--
Catalin
^ permalink raw reply
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Lars-Peter Clausen @ 2014-01-23 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390409565-4200-2-git-send-email-sthokal@xilinx.com>
On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
[...]
> +/**
> + * xilinx_vdma_device_control - Configure DMA channel of the device
> + * @dchan: DMA Channel pointer
> + * @cmd: DMA control command
> + * @arg: Channel configuration
> + *
> + * Return: '0' on success and failure value on error
> + */
> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
> + enum dma_ctrl_cmd cmd, unsigned long arg)
> +{
> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> +
> + switch (cmd) {
> + case DMA_TERMINATE_ALL:
> + xilinx_vdma_terminate_all(chan);
> + return 0;
> + case DMA_SLAVE_CONFIG:
> + return xilinx_vdma_slave_config(chan,
> + (struct xilinx_vdma_config *)arg);
You really shouldn't be overloading the generic API with your own semantics.
DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
> + default:
> + return -ENXIO;
> + }
> +}
> +
[...]
> +
> + /* Request the interrupt */
> + chan->irq = irq_of_parse_and_map(node, 0);
> + err = devm_request_irq(xdev->dev, chan->irq, xilinx_vdma_irq_handler,
> + IRQF_SHARED, "xilinx-vdma-controller", chan);
This is a clasic example of where to not use devm_request_irq. 'chan' is
accessed in the interrupt handler, but if you use devm_request_irq 'chan'
will be freed before the interrupt handler has been released, which means
there is now a race condition where the interrupt handler can access already
freed memory.
> + if (err) {
> + dev_err(xdev->dev, "unable to request IRQ\n");
> + return err;
> + }
> +
> + /* Initialize the DMA channel and add it to the DMA engine channels
> + * list.
> + */
> + chan->common.device = &xdev->common;
> +
> + list_add_tail(&chan->common.device_node, &xdev->common.channels);
> + xdev->chan[chan->id] = chan;
> +
> + /* Reset the channel */
> + err = xilinx_vdma_chan_reset(chan);
> + if (err < 0) {
> + dev_err(xdev->dev, "Reset channel failed\n");
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * struct of_dma_filter_xilinx_args - Channel filter args
> + * @dev: DMA device structure
> + * @chan_id: Channel id
> + */
> +struct of_dma_filter_xilinx_args {
> + struct dma_device *dev;
> + u32 chan_id;
> +};
> +
> +/**
> + * xilinx_vdma_dt_filter - VDMA channel filter function
> + * @chan: DMA channel pointer
> + * @param: Filter match value
> + *
> + * Return: true/false based on the result
> + */
> +static bool xilinx_vdma_dt_filter(struct dma_chan *chan, void *param)
> +{
> + struct of_dma_filter_xilinx_args *args = param;
> +
> + return chan->device == args->dev && chan->chan_id == args->chan_id;
> +}
> +
> +/**
> + * of_dma_xilinx_xlate - Translation function
> + * @dma_spec: Pointer to DMA specifier as found in the device tree
> + * @ofdma: Pointer to DMA controller data
> + *
> + * Return: DMA channel pointer on success and NULL on error
> + */
> +static struct dma_chan *of_dma_xilinx_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct of_dma_filter_xilinx_args args;
> + dma_cap_mask_t cap;
> +
> + args.dev = ofdma->of_dma_data;
> + if (!args.dev)
> + return NULL;
> +
> + if (dma_spec->args_count != 1)
> + return NULL;
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> +
> + args.chan_id = dma_spec->args[0];
> +
> + return dma_request_channel(cap, xilinx_vdma_dt_filter, &args);
There is a new helper function called dma_get_slave_channel, which makes
this much easier. Take a look at the k3dma.c driver for an example.
> +}
^ permalink raw reply
* [PATCH V2 3/8] ahci: Add a driver_data field to struct ahci_platform_data
From: Tejun Heo @ 2014-01-23 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <af75111fb61aebfee6e0233b39dc4cf006906402.1390471111.git.mohit.kumar@st.com>
On Thu, Jan 23, 2014 at 04:02:43PM +0530, Mohit Kumar wrote:
> diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
> index 73a2500..76d35e8 100644
> --- a/include/linux/ahci_platform.h
> +++ b/include/linux/ahci_platform.h
> @@ -28,6 +28,7 @@ struct ahci_platform_data {
> const struct ata_port_info *ata_port_info;
> unsigned int force_port_map;
> unsigned int mask_port_map;
> + void *driver_data;
Please use private_data instead for consistency with other ata data
structures.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH 2/2] clocksource: Make clocksource register functions void
From: David Laight @ 2014-01-23 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0C889.6000106@prisktech.co.nz>
From: Linuxppc-dev Tony Prisk
> On 23/01/14 20:12, Yijing Wang wrote:
> > Currently, clocksource_register() and __clocksource_register_scale()
> > functions always return 0, it's pointless, make functions void.
> > And remove the dead code that check the clocksource_register_hz()
> > return value.
> ......
> > -static inline int clocksource_register_hz(struct clocksource *cs, u32 hz)
> > +static inline void clocksource_register_hz(struct clocksource *cs, u32 hz)
> > {
> > return __clocksource_register_scale(cs, 1, hz);
> > }
>
> This doesn't make sense - you are still returning a value on a function
> declared void, and the return is now from a function that doesn't return
> anything either ?!?!
> Doesn't this throw a compile-time warning??
It depends on the compiler.
Recent gcc allow it.
I don't know if it is actually valid C though.
There is no excuse for it on lines like the above though.
David
^ permalink raw reply
* [PATCHv2 2/2] pwm: imx: support polarity inversion
From: Russell King - ARM Linux @ 2014-01-23 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123083714.3c6e86ae@ipc1.ka-ro>
On Thu, Jan 23, 2014 at 08:37:14AM +0100, Lothar Wa?mann wrote:
> This wouldn't buy much without a material change to of_pwm_get().
> The function of_parse_phandle_with_args() called by of_pwm_get()
> requires the number of args in the pwms property be greater or equal to
> the #pwm-cells property in the pwm node. Thus, the interesting case of
> having #pwm-cells = <3> without changing the existing users is
> prohibited by of_parse_phandle_with_args().
I really don't think that's a problem we need to be concerned with at
the moment. What we need is for the kernel to be able to parse files
with #pwm-cells = <2> with the pwms property containing two arguments,
and when they're updated to #pwm-cells = <3> with the pwms property
containing three arguments.
Yes, that means all the board dt files need to be updated at the same
time to include the additional argument, but I don't see that as a big
problem.
What we do need to do is to adjust the PWM parsing code such that it's
possible to use either specification without causing any side effects.
I would test this, but as u-boot is rather fscked at the moment and the
networking has broken on my cubox-i as a result... and it seems that the
u-boot developers have pissed off cubox-i u-boot hackers soo much that
they've dropped u-boot in favour of barebox...
drivers/pwm/core.c | 59 +++++++++++++++++++++++++++++------------------------
include/linux/pwm.h | 2 ++
2 files changed, 34 insertions(+), 27 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 2ca95042a0b9..40adbce8ef0c 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -132,14 +132,11 @@ static int pwm_device_request(struct pwm_device *pwm, const char *label)
}
struct pwm_device *
-of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args)
+of_pwm_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
{
struct pwm_device *pwm;
- if (pc->of_pwm_n_cells < 3)
- return ERR_PTR(-EINVAL);
-
- if (args->args[0] >= pc->npwm)
+ if (args->args_count < 2)
return ERR_PTR(-EINVAL);
pwm = pwm_request_from_chip(pc, args->args[0], NULL);
@@ -148,33 +145,45 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args)
pwm_set_period(pwm, args->args[1]);
- if (args->args[2] & PWM_POLARITY_INVERTED)
- pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
- else
- pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
+ if (args->args_count > 2) {
+ int err;
+
+ if (args->args[2] & PWM_POLARITY_INVERTED)
+ err = pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
+ else
+ err = pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
+
+ pwm_put(pwm);
+ return ERR_PTR(err);
+ }
return pwm;
}
+EXPORT_SYMBOL(of_pwm_xlate);
+
+struct pwm_device *
+of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args)
+{
+ if (pc->of_pwm_n_cells < 3)
+ return ERR_PTR(-EINVAL);
+
+ if (args->args_count != pc->of_pwm_n_cells)
+ return ERR_PTR(-EINVAL);
+
+ return of_pwm_xlate(pc, args);
+}
EXPORT_SYMBOL_GPL(of_pwm_xlate_with_flags);
static struct pwm_device *
of_pwm_simple_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
{
- struct pwm_device *pwm;
-
if (pc->of_pwm_n_cells < 2)
return ERR_PTR(-EINVAL);
- if (args->args[0] >= pc->npwm)
+ if (args->args_count != pc->of_pwm_n_cells)
return ERR_PTR(-EINVAL);
- pwm = pwm_request_from_chip(pc, args->args[0], NULL);
- if (IS_ERR(pwm))
- return pwm;
-
- pwm_set_period(pwm, args->args[1]);
-
- return pwm;
+ return of_pwm_xlate(pc, args);
}
static void of_pwmchip_add(struct pwm_chip *chip)
@@ -536,16 +545,12 @@ struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id)
goto put;
}
- if (args.args_count != pc->of_pwm_n_cells) {
- pr_debug("%s: wrong #pwm-cells for %s\n", np->full_name,
- args.np->full_name);
- pwm = ERR_PTR(-EINVAL);
- goto put;
- }
-
pwm = pc->of_xlate(pc, &args);
- if (IS_ERR(pwm))
+ if (IS_ERR(pwm)) {
+ pr_debug("%s: of_xlate failed for %s: %d\n", np->full_name,
+ args.np->full_name, (int)PTR_ERR(pwm));
goto put;
+ }
/*
* If a consumer name was not given, try to look it up from the
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index f0feafd184a0..14a823f77c31 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -188,6 +188,8 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip,
unsigned int index,
const char *label);
+struct pwm_device *of_pwm_xlate(struct pwm_chip *pc,
+ const struct of_phandle_args *args);
struct pwm_device *of_pwm_xlate_with_flags(struct pwm_chip *pc,
const struct of_phandle_args *args);
--
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 related
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Ezequiel Garcia @ 2014-01-23 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123111049.GB6065@localhost>
Sebastian,
On Thu, Jan 23, 2014 at 08:10:49AM -0300, Ezequiel Garcia wrote:
> On Thu, Jan 23, 2014 at 12:49:50AM +0100, Sebastian Hesselbarth wrote:
> [..]
> > > Notice that Ezequiel has added an IRQ handler that just calls panic,
> > > so a spurious interrupt call is VERY VERY BAD.
> >
> > And I understand that he now clears watchdog's register before
> > requesting an irq. All that is missing is bridge_irq driver clearing
> > CAUSE register after masking all irqs, right?
> >
>
> Are you sure clearing the CAUSE register after masking the IRQs will be enough?
>
> AFAICS, until now nobody unmasks the watchdog IRQ (at least the orion_wdt
> driver didn't request the interruption) but *still* the CAUSE register is set
> upon watchdog expiration. So I would guessed a masked interrupt still raises a
> bit in the CAUSE register.
>
Let me add some real information instead of my speculations. Taken from
the Kirkwood specification:
Table 136: Mbus-L to Mbus Bridge Interrupt Mask Register
Offset: 0x00020114
Field: Mask
Type/InitVal: RW 0x0
Description: There is a mask bit per each cause bit. Mask only affects the
assertion of interrupt pins. It does not affect the setting of
bits in the Cause register.
So I guess this is why Jason has been insisting with the introduction of
the irq_startup.
(Just for reference, the little patch I attached yesterday proved to work here.)
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 06/15] watchdog: orion: Remove unneeded BRIDGE_CAUSE clear
From: Ezequiel Garcia @ 2014-01-23 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123001934.GY18269@obsidianresearch.com>
On Wed, Jan 22, 2014 at 05:19:34PM -0700, Jason Gunthorpe wrote:
[..]
>
> On Kirkwood this means all of the main interrupt controller bits are
> level and all the bridge bits are edge. Which means edge is
> definitely correct for the bridge handler, and level correct for the
> main handler.
>
Which means we should change the bridge handler to edge?
Is there any _noticeable_ side-effect in doing the handling via level?
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [GIT PULL]ARM: sirf: machine update for 3.14
From: Barry Song @ 2014-01-23 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ob33y4r2.fsf@paris.lan>
2014/1/23 Kevin Hilman <khilman@linaro.org>:
> Barry Song <21cnbao@gmail.com> writes:
>
>> Hi Olof/Kevin,
>> this series was missed?
>
> It was skipped because it came well after the normal cutoff of -rc6
> (Dec. 29th) or -rc7 (Jan 4th). This time we extended things a little
> due to the end of year holidays, but yours came well after that as well.
>
> If we have time we may try to get it into a late/* branch which might
> still make it for v3.13, but it's unlikely at this point.
sorry for that. the reset controller was ready too close to merge window.
i guess i can rebase these two againest 3.14-rc1 for 3.14:
- MAINTAINERS: ARM: SiRF: use regex patterns to involve all SiRF drivers
- ARM: prima2: make sirfsoc_init_late function static
and queue the below for 3.15:
- ARM: prima2: move to generic reset controller driver framework
>
> Kevin
>
>
>> 2014/1/15 Barry Song <21cnbao@gmail.com>:
>>> Hi Kevin/Olof,
>>>
>>> The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
>>>
>>> Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
>>>
>>> are available in the git repository at:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/baohua/linux.git
>>> tags/sirf-soc-for-3.14
>>>
>>> for you to fetch changes up to dbd1b42baa6ec8082bce6eec37de5e1b46aff19c:
>>>
>>> ARM: prima2: make sirfsoc_init_late function static (2014-01-15
>>> 10:42:26 +0800)
>>>
>>> ----------------------------------------------------------------
>>> ARM: sirf: machine update for 3.14
>>>
>>> Among them:
>>> - ARM: prima2: move to generic reset controller driver framework
>>> - MAINTAINERS: ARM: SiRF: use regex patterns to involve all SiRF drivers
>>> - ARM: prima2: make sirfsoc_init_late function static
>>>
>>> ----------------------------------------------------------------
>>> Barry Song (3):
>>> ARM: prima2: move to generic reset controller driver framework
>>> MAINTAINERS: ARM: SiRF: use regex patterns to involve all SiRF drivers
>>> ARM: prima2: make sirfsoc_init_late function static
>>>
>>> .../devicetree/bindings/reset/sirf,rstc.txt | 42 +++++++++
>>> MAINTAINERS | 9 +-
>>> arch/arm/boot/dts/atlas6.dtsi | 3 +-
>>> arch/arm/boot/dts/marco.dtsi | 3 +-
>>> arch/arm/boot/dts/prima2.dtsi | 3 +-
>>> arch/arm/mach-prima2/Kconfig | 1 +
>>> arch/arm/mach-prima2/common.c | 2 +-
>>> arch/arm/mach-prima2/rstc.c | 93 +++++++++++++-------
>>> 8 files changed, 110 insertions(+), 46 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/reset/sirf,rstc.txt
>>>
>>> -barry
-barry
^ permalink raw reply
* [PATCH V2 6/8] SPEAr13xx: Fix static mapping table
From: Arnd Bergmann @ 2014-01-23 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22d2e7d6fbd5a291cdecf6a4d1e294d9c9ede617.1390471111.git.mohit.kumar@st.com>
On Thursday 23 January 2014, Mohit Kumar wrote:
> From: Pratyush Anand <pratyush.anand@st.com>
>
> SPEAr13xx was using virtual address space 0xFE000000 to map physical address
> space 0xB3000000. pci_remap_io uses 0xFEE00000 as virtual address. So
> change 0xFE000000 to 0xF9000000.
>
> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> Tested-by: Mohit Kumar <mohit.kumar@st.com>
> Cc: Viresh Kumar <viresh.linux@gmail.com>
> Cc: spear-devel at list.st.com
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Arnd Bergmann <arnd@arndb.de>
Surely this is needed in backports, so please add stable at vger.kernel.org
to the Cc list in the changeset text. Otherwise
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH V2 4/8] SPEAr13xx: Fixup: Move SPEAr1340 SATA platform code to system cfg driver
From: Arnd Bergmann @ 2014-01-23 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c4bf78f2a843625f3175cdf259fad653bd2e86d.1390471111.git.mohit.kumar@st.com>
On Thursday 23 January 2014, Mohit Kumar wrote:
> diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
> index 3518803..2b4e58e 100644
> --- a/arch/arm/boot/dts/spear13xx.dtsi
> +++ b/arch/arm/boot/dts/spear13xx.dtsi
> @@ -78,6 +78,10 @@
> status = "disabled";
> };
>
> + cfg {
> + compatible = "st,spear13xx-cfg";
> + };
> +
> ahb {
> #address-cells = <1>;
> #size-cells = <1>;
I only saw some of the patches, and did not get a patch with the binding
description for this device. Please forward that patch to me, or add it
to the series if you didn't have one.
I assume you'd want a phandle pointing to the syscon device in here
as well?
Regarding the naming, please do not use 'xx' wildcards in DT compatible
strings. Instead, use the exact model name of the first supported
version of the hardware (e.g. spear1300 or spear600) that remains
compatible. If there are minor variations between the versions,
use a list with the most specific version as well as the older ones
it's compatible with.
> @@ -221,6 +225,11 @@
> 0xd8000000 0xd8000000 0x01000000
> 0xe0000000 0xe0000000 0x10000000>;
>
> + misc: misc at e0700000 {
> + compatible = "st,spear13xx-misc", "syscon";
> + reg = <0xe0700000 0x1000>;
> + };
> +
Same here. Also, I would make this 'misc: syscon at e0700000', since 'misc'
does not seem like an appropriate device name.
> +/* SPEAr1340 Registers */
> +/* Power Management Registers */
> +#define SPEAR1340_PCM_CFG 0x100
> + #define SPEAR1340_PCM_CFG_SATA_POWER_EN 0x800
> +#define SPEAR1340_PCM_WKUP_CFG 0x104
> +#define SPEAR1340_SWITCH_CTR 0x108
> +
> +#define SPEAR1340_PERIP1_SW_RST 0x318
> + #define SPEAR1340_PERIP1_SW_RST_SATA 0x1000
> +#define SPEAR1340_PERIP2_SW_RST 0x31C
> +#define SPEAR1340_PERIP3_SW_RST 0x320
> +
> +/* PCIE - SATA configuration registers */
> +#define SPEAR1340_PCIE_SATA_CFG 0x424
> + /* PCIE CFG MASks */
> + #define SPEAR1340_PCIE_CFG_DEVICE_PRESENT (1 << 11)
> + #define SPEAR1340_PCIE_CFG_POWERUP_RESET (1 << 10)
> + #define SPEAR1340_PCIE_CFG_CORE_CLK_EN (1 << 9)
> + #define SPEAR1340_PCIE_CFG_AUX_CLK_EN (1 << 8)
> + #define SPEAR1340_SATA_CFG_TX_CLK_EN (1 << 4)
> + #define SPEAR1340_SATA_CFG_RX_CLK_EN (1 << 3)
> + #define SPEAR1340_SATA_CFG_POWERUP_RESET (1 << 2)
> + #define SPEAR1340_SATA_CFG_PM_CLK_EN (1 << 1)
> + #define SPEAR1340_PCIE_SATA_SEL_PCIE (0)
> + #define SPEAR1340_PCIE_SATA_SEL_SATA (1)
> + #define SPEAR1340_PCIE_SATA_CFG_MASK 0xF1F
> + #define SPEAR1340_PCIE_CFG_VAL (SPEAR1340_PCIE_SATA_SEL_PCIE | \
> + SPEAR1340_PCIE_CFG_AUX_CLK_EN | \
> + SPEAR1340_PCIE_CFG_CORE_CLK_EN | \
> + SPEAR1340_PCIE_CFG_POWERUP_RESET | \
> + SPEAR1340_PCIE_CFG_DEVICE_PRESENT)
> + #define SPEAR1340_SATA_CFG_VAL (SPEAR1340_PCIE_SATA_SEL_SATA | \
> + SPEAR1340_SATA_CFG_PM_CLK_EN | \
> + SPEAR1340_SATA_CFG_POWERUP_RESET | \
> + SPEAR1340_SATA_CFG_RX_CLK_EN | \
> + SPEAR1340_SATA_CFG_TX_CLK_EN)
> +
> +#define SPEAR1340_PCIE_MIPHY_CFG 0x428
> + #define SPEAR1340_MIPHY_OSC_BYPASS_EXT (1 << 31)
> + #define SPEAR1340_MIPHY_CLK_REF_DIV2 (1 << 27)
> + #define SPEAR1340_MIPHY_CLK_REF_DIV4 (2 << 27)
> + #define SPEAR1340_MIPHY_CLK_REF_DIV8 (3 << 27)
> + #define SPEAR1340_MIPHY_PLL_RATIO_TOP(x) (x << 0)
> + #define SPEAR1340_PCIE_MIPHY_CFG_MASK 0xF80000FF
> + #define SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA \
> + (SPEAR1340_MIPHY_OSC_BYPASS_EXT | \
> + SPEAR1340_MIPHY_CLK_REF_DIV2 | \
> + SPEAR1340_MIPHY_PLL_RATIO_TOP(60))
> + #define SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA_25M_CRYSTAL_CLK \
> + (SPEAR1340_MIPHY_PLL_RATIO_TOP(120))
> + #define SPEAR1340_PCIE_SATA_MIPHY_CFG_PCIE \
> + (SPEAR1340_MIPHY_OSC_BYPASS_EXT | \
> + SPEAR1340_MIPHY_PLL_RATIO_TOP(25))
> +
> +struct spear13xx_cfg_priv {
> + struct regmap *misc;
> +};
> +
> +/* SATA device registration */
> +static void spear1340_sata_miphy_init(struct spear13xx_cfg_priv *cfgpriv)
> +{
> + regmap_update_bits(cfgpriv->misc, SPEAR1340_PCIE_SATA_CFG,
> + SPEAR1340_PCIE_SATA_CFG_MASK, SPEAR1340_SATA_CFG_VAL);
> + regmap_update_bits(cfgpriv->misc, SPEAR1340_PCIE_MIPHY_CFG,
> + SPEAR1340_PCIE_MIPHY_CFG_MASK,
> + SPEAR1340_PCIE_SATA_MIPHY_CFG_SATA_25M_CRYSTAL_CLK);
> + /* Switch on sata power domain */
> + regmap_update_bits(cfgpriv->misc, SPEAR1340_PCM_CFG,
> + SPEAR1340_PCM_CFG_SATA_POWER_EN,
> + SPEAR1340_PCM_CFG_SATA_POWER_EN);
> + msleep(20);
> + /* Disable PCIE SATA Controller reset */
> + regmap_update_bits(cfgpriv->misc, SPEAR1340_PERIP1_SW_RST,
> + SPEAR1340_PERIP1_SW_RST_SATA, 0);
> + msleep(20);
> +}
Looking at the actual code now, this very much looks like it ought to
be a "phy" driver and get put in drivers/phy/.
Please see the recent mailing list discussions about making the ahci
driver more generic. Once you put this code in a proper phy driver,
you should be able to avoid a lot of your workaround and just use
the regular ahci-platform driver without any hand-crafted platform
data callbacks.
Arnd
^ permalink raw reply
* [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Mark Brown @ 2014-01-23 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0D9AD.1040409@monstr.eu>
On Thu, Jan 23, 2014 at 09:58:21AM +0100, Michal Simek wrote:
> On 01/17/2014 06:04 PM, Arnd Bergmann wrote:
> >> I thought the solution with deferring registration of the resource for
> >> dev_get_regmap() until a proper device materialised seemed simple and
> >> enough, did you folks run into any problems with that? I had assumed a
> >> patch was likely to materialise so wasn't worrying about it myself.
> > I'm still hoping that Michal will do that patch.
> And what was the resolution/recommendation how to do it?
Split the regmap creation so the managed resource registration could be
done later on with an already allocated regmap instead of requiring it
to be done at creation time.
-------------- 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/20140123/722a9d1b/attachment-0001.sig>
^ permalink raw reply
* [PATCHv2 2/2] pwm: imx: support polarity inversion
From: Russell King - ARM Linux @ 2014-01-23 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123115203.GV15937@n2100.arm.linux.org.uk>
On Thu, Jan 23, 2014 at 11:52:03AM +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 23, 2014 at 08:37:14AM +0100, Lothar Wa?mann wrote:
> > This wouldn't buy much without a material change to of_pwm_get().
> > The function of_parse_phandle_with_args() called by of_pwm_get()
> > requires the number of args in the pwms property be greater or equal to
> > the #pwm-cells property in the pwm node. Thus, the interesting case of
> > having #pwm-cells = <3> without changing the existing users is
> > prohibited by of_parse_phandle_with_args().
>
> I really don't think that's a problem we need to be concerned with at
> the moment. What we need is for the kernel to be able to parse files
> with #pwm-cells = <2> with the pwms property containing two arguments,
> and when they're updated to #pwm-cells = <3> with the pwms property
> containing three arguments.
>
> Yes, that means all the board dt files need to be updated at the same
> time to include the additional argument, but I don't see that as a big
> problem.
>
> What we do need to do is to adjust the PWM parsing code such that it's
> possible to use either specification without causing any side effects.
>
> I would test this, but as u-boot is rather fscked at the moment and the
> networking has broken on my cubox-i as a result... and it seems that the
> u-boot developers have pissed off cubox-i u-boot hackers soo much that
> they've dropped u-boot in favour of barebox...
Oh, and another reason... the u-boot video settings are totally and utterly
buggered to the point that it doesn't produce correct timings, and it seems
that u-boot people have zero interest in fixing that, so u-boot mainline is
basically refusing to fix this - another reason to stay away from it.
(1024x768 @ 60Hz produces 70Hz refresh on iMX6Q here - I've seen it produce
51Hz on iMX6S, both of which are far enough out that lots of display devices
will not accept it as a valid signal.)
--
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 1/3 RESEND] mfd: tc3589x: Add device tree bindings
From: Linus Walleij @ 2014-01-23 12:43 UTC (permalink / raw)
To: linux-arm-kernel
This defines the device tree bindings for the Toshiba TC3589x
series of multi-purpose expanders. Only the stuff I can test
is defined: GPIO and keypad. Others may implement more
subdevices further down the road.
This is to complement
commit a435ae1d51e2f18414f2a87219fdbe068231e692
"mfd: Enable the tc3589x for Device Tree" which left off
the definition of the device tree bindings.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Fix the keys/rows bindings to be u32 rather than
/bits/ 8, inconsistency noted by Mark Rutland.
ChangeLog v1->v2:
- Include a verbose example in the DT bindings.
- Explain why this is a stand-alone bindings patch.
---
Documentation/devicetree/bindings/mfd/tc3589x.txt | 107 ++++++++++++++++++++++
1 file changed, 107 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/tc3589x.txt
diff --git a/Documentation/devicetree/bindings/mfd/tc3589x.txt b/Documentation/devicetree/bindings/mfd/tc3589x.txt
new file mode 100644
index 000000000000..c6ac5bd2ce51
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tc3589x.txt
@@ -0,0 +1,107 @@
+* Toshiba TC3589x multi-purpose expander
+
+The Toshiba TC3589x series are I2C-based MFD devices which may expose the
+following built-in devices: gpio, keypad, rotator (vibrator), PWM (for
+e.g. LEDs or vibrators) The included models are:
+
+- TC35890
+- TC35892
+- TC35893
+- TC35894
+- TC35895
+- TC35896
+
+Required properties:
+ - compatible : must be "toshiba,tc35890", "toshiba,tc35892", "toshiba,tc35893",
+ "toshiba,tc35894", "toshiba,tc35895" or "toshiba,tc35896"
+ - reg : I2C address of the device
+ - interrupt-parent : specifies which IRQ controller we're connected to
+ - interrupts : the interrupt on the parent the controller is connected to
+ - interrupt-controller : marks the device node as an interrupt controller
+ - #interrupt-cells : should be <1>, the first cell is the IRQ offset on this
+ TC3589x interrupt controller.
+
+Optional nodes:
+
+- GPIO
+ This GPIO module inside the TC3589x has 24 (TC35890, TC35892) or 20
+ (other models) GPIO lines.
+ - compatible : must be "toshiba,tc3589x-gpio"
+ - interrupts : interrupt on the parent, which must be the tc3589x MFD device
+ - interrupt-controller : marks the device node as an interrupt controller
+ - #interrupt-cells : should be <2>, the first cell is the IRQ offset on this
+ TC3589x GPIO interrupt controller, the second cell is the interrupt flags
+ in accordance with <dt-bindings/interrupt-controller/irq.h>. The following
+ flags are valid:
+ - IRQ_TYPE_LEVEL_LOW
+ - IRQ_TYPE_LEVEL_HIGH
+ - IRQ_TYPE_EDGE_RISING
+ - IRQ_TYPE_EDGE_FALLING
+ - IRQ_TYPE_EDGE_BOTH
+ - gpio-controller : marks the device node as a GPIO controller
+ - #gpio-cells : should be <2>, the first cell is the GPIO offset on this
+ GPIO controller, the second cell is the flags.
+
+- Keypad
+ This keypad is the same on all variants, supporting up to 96 different
+ keys. The linux-specific properties are modeled on those already existing
+ in other input drivers.
+ - compatible : must be "toshiba,tc3589x-keypad"
+ - debounce-delay-ms : debounce interval in milliseconds
+ - keypad,num-rows : number of rows in the matrix, see
+ bindings/input/matrix-keymap.txt
+ - keypad,num-columns : number of columns in the matrix, see
+ bindings/input/matrix-keymap.txt
+ - linux,keymap: the definition can be found in
+ bindings/input/matrix-keymap.txt
+ - linux,no-autorepeat: do no enable autorepeat feature.
+ - linux,wakeup: use any event on keypad as wakeup event.
+
+Example:
+
+tc35893 at 44 {
+ compatible = "toshiba,tc35893";
+ reg = <0x44>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <26 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ tc3589x_gpio {
+ compatible = "toshiba,tc3589x-gpio";
+ interrupts = <0>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ tc3589x_keypad {
+ compatible = "toshiba,tc3589x-keypad";
+ interrupts = <6>;
+ debounce-delay-ms = <4>;
+ keypad,num-columns = <8>;
+ keypad,num-rows = <8>;
+ linux,no-autorepeat;
+ linux,wakeup;
+ linux,keymap = <0x0301006b
+ 0x04010066
+ 0x06040072
+ 0x040200d7
+ 0x0303006a
+ 0x0205000e
+ 0x0607008b
+ 0x0500001c
+ 0x0403000b
+ 0x03040034
+ 0x05020067
+ 0x0305006c
+ 0x040500e7
+ 0x0005009e
+ 0x06020073
+ 0x01030039
+ 0x07060069
+ 0x050500d9>;
+ };
+};
--
1.8.4.2
^ permalink raw reply related
* [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
From: Linus Walleij @ 2014-01-23 12:43 UTC (permalink / raw)
To: linux-arm-kernel
This changes the following mechanisms in the TC3589x device tree
probing path:
- Use the .of_match_table in struct device_driver to match the
device in the device tree.
- Add matches for the proper compatible strings "toshiba,..."
and all sub-variants, just as is done for the .id matches.
- Move over all the allocation of platform data etc to the
tc3589x_of_probe() function and follow the pattern of passing
a platform data pointer back, or an error pointer on error,
as found in the STMPE driver.
- Match the new (proper) compatible strings for the GPIO and
keypad MFD cells.
- Use of_device_is_compatible() rather than just !strcmp()
to discover which cells to instantiate.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/mfd/tc3589x.c | 84 ++++++++++++++++++++++++++++++++++++---------------
1 file changed, 59 insertions(+), 25 deletions(-)
diff --git a/drivers/mfd/tc3589x.c b/drivers/mfd/tc3589x.c
index 87ea51dc6234..ed1ee2634809 100644
--- a/drivers/mfd/tc3589x.c
+++ b/drivers/mfd/tc3589x.c
@@ -13,8 +13,10 @@
#include <linux/slab.h>
#include <linux/i2c.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/mfd/core.h>
#include <linux/mfd/tc3589x.h>
+#include <linux/err.h>
/**
* enum tc3589x_version - indicates the TC3589x version
@@ -160,7 +162,7 @@ static struct mfd_cell tc3589x_dev_gpio[] = {
.name = "tc3589x-gpio",
.num_resources = ARRAY_SIZE(gpio_resources),
.resources = &gpio_resources[0],
- .of_compatible = "tc3589x-gpio",
+ .of_compatible = "toshiba,tc3589x-gpio",
},
};
@@ -169,7 +171,7 @@ static struct mfd_cell tc3589x_dev_keypad[] = {
.name = "tc3589x-keypad",
.num_resources = ARRAY_SIZE(keypad_resources),
.resources = &keypad_resources[0],
- .of_compatible = "tc3589x-keypad",
+ .of_compatible = "toshiba,tc3589x-keypad",
},
};
@@ -318,45 +320,74 @@ static int tc3589x_device_init(struct tc3589x *tc3589x)
return ret;
}
-static int tc3589x_of_probe(struct device_node *np,
- struct tc3589x_platform_data *pdata)
+#ifdef CONFIG_OF
+static const struct of_device_id tc3589x_match[] = {
+ /* Legacy compatible string */
+ { .compatible = "tc3589x", .data = (void *) TC3589X_UNKNOWN },
+ { .compatible = "toshiba,tc35890", .data = (void *) TC3589X_TC35890 },
+ { .compatible = "toshiba,tc35892", .data = (void *) TC3589X_TC35892 },
+ { .compatible = "toshiba,tc35893", .data = (void *) TC3589X_TC35893 },
+ { .compatible = "toshiba,tc35894", .data = (void *) TC3589X_TC35894 },
+ { .compatible = "toshiba,tc35895", .data = (void *) TC3589X_TC35895 },
+ { .compatible = "toshiba,tc35896", .data = (void *) TC3589X_TC35896 },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, tc3589x_match);
+
+static struct tc3589x_platform_data *
+tc3589x_of_probe(struct device *dev, enum tc3589x_version *version)
{
+ struct device_node *np = dev->of_node;
+ struct tc3589x_platform_data *pdata;
struct device_node *child;
+ const struct of_device_id *of_id;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ of_id = of_match_device(tc3589x_match, dev);
+ if (!of_id)
+ return ERR_PTR(-ENODEV);
+ *version = (enum tc3589x_version) of_id->data;
for_each_child_of_node(np, child) {
- if (!strcmp(child->name, "tc3589x_gpio")) {
+ if (of_device_is_compatible(child, "toshiba,tc3589x-gpio"))
pdata->block |= TC3589x_BLOCK_GPIO;
- }
- if (!strcmp(child->name, "tc3589x_keypad")) {
+ if (of_device_is_compatible(child, "toshiba,tc3589x-keypad"))
pdata->block |= TC3589x_BLOCK_KEYPAD;
- }
}
- return 0;
+ return pdata;
}
+#else
+static inline struct tc3589x_platform_data *
+tc3589x_of_probe(struct device *dev, enum tc3589x_version *version)
+{
+ dev_err(dev, "no device tree support\n");
+ return ERR_PTR(-ENODEV);
+}
+#endif
static int tc3589x_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
- struct tc3589x_platform_data *pdata = dev_get_platdata(&i2c->dev);
struct device_node *np = i2c->dev.of_node;
+ struct tc3589x_platform_data *pdata = dev_get_platdata(&i2c->dev);
struct tc3589x *tc3589x;
+ enum tc3589x_version version;
int ret;
if (!pdata) {
- if (np) {
- pdata = devm_kzalloc(&i2c->dev, sizeof(*pdata), GFP_KERNEL);
- if (!pdata)
- return -ENOMEM;
-
- ret = tc3589x_of_probe(np, pdata);
- if (ret)
- return ret;
- }
- else {
+ pdata = tc3589x_of_probe(&i2c->dev, &version);
+ if (IS_ERR(pdata)) {
dev_err(&i2c->dev, "No platform data or DT found\n");
- return -EINVAL;
+ return PTR_ERR(pdata);
}
+ } else {
+ /* When not probing from device tree we have this ID */
+ version = id->driver_data;
}
if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_SMBUS_BYTE_DATA
@@ -375,7 +406,7 @@ static int tc3589x_probe(struct i2c_client *i2c,
tc3589x->pdata = pdata;
tc3589x->irq_base = pdata->irq_base;
- switch (id->driver_data) {
+ switch (version) {
case TC3589X_TC35893:
case TC3589X_TC35895:
case TC3589X_TC35896:
@@ -471,9 +502,12 @@ static const struct i2c_device_id tc3589x_id[] = {
MODULE_DEVICE_TABLE(i2c, tc3589x_id);
static struct i2c_driver tc3589x_driver = {
- .driver.name = "tc3589x",
- .driver.owner = THIS_MODULE,
- .driver.pm = &tc3589x_dev_pm_ops,
+ .driver = {
+ .name = "tc3589x",
+ .owner = THIS_MODULE,
+ .pm = &tc3589x_dev_pm_ops,
+ .of_match_table = of_match_ptr(tc3589x_match),
+ },
.probe = tc3589x_probe,
.remove = tc3589x_remove,
.id_table = tc3589x_id,
--
1.8.4.2
^ permalink raw reply related
* [PATCH 3/3 RESEND] input: tc3589x-keypad: support probing from device tree
From: Linus Walleij @ 2014-01-23 12:43 UTC (permalink / raw)
To: linux-arm-kernel
Implement device tree probing for the tc3589x keypad driver.
This is modeled on the STMPE keypad driver and tested on the
Ux500 TVK1281618 UIB.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Use two local u32 variables to avoid weirdness in u8 casting
of the resulting values to the pointers.
ChangeLog v1->v2:
- Fix rows/columns binding to read two u32's insead of two
u8 /bits/ as noted by Mark Rutland.
---
drivers/input/keyboard/tc3589x-keypad.c | 66 ++++++++++++++++++++++++++++++++-
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/tc3589x-keypad.c b/drivers/input/keyboard/tc3589x-keypad.c
index 208de7cbb7fa..7f36e7addb86 100644
--- a/drivers/input/keyboard/tc3589x-keypad.c
+++ b/drivers/input/keyboard/tc3589x-keypad.c
@@ -297,6 +297,65 @@ static void tc3589x_keypad_close(struct input_dev *input)
tc3589x_keypad_disable(keypad);
}
+#ifdef CONFIG_OF
+static const struct tc3589x_keypad_platform_data *
+tc3589x_keypad_of_probe(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct tc3589x_keypad_platform_data *plat;
+ u32 cols, rows;
+ u32 debounce_ms;
+ int proplen;
+
+ if (!np)
+ return ERR_PTR(-ENODEV);
+
+ plat = devm_kzalloc(dev, sizeof(*plat), GFP_KERNEL);
+ if (!plat)
+ return ERR_PTR(-ENOMEM);
+
+ of_property_read_u32(np, "keypad,num-columns", &cols);
+ of_property_read_u32(np, "keypad,num-rows", &rows);
+ plat->kcol = (u8) cols;
+ plat->krow = (u8) rows;
+ if (!plat->krow || !plat->kcol ||
+ plat->krow > TC_KPD_ROWS || plat->kcol > TC_KPD_COLUMNS) {
+ dev_err(dev,
+ "keypad columns/rows not properly specified (%ux%u)\n",
+ plat->kcol, plat->krow);
+ return ERR_PTR(-EINVAL);
+ }
+
+ if (!of_get_property(np, "linux,keymap", &proplen)) {
+ dev_err(dev, "property linux,keymap not found\n");
+ return ERR_PTR(-ENOENT);
+ }
+
+ plat->no_autorepeat = of_property_read_bool(np, "linux,no-autorepeat");
+ plat->enable_wakeup = of_property_read_bool(np, "linux,wakeup");
+
+ /* The custom delay format is ms/16 */
+ of_property_read_u32(np, "debounce-delay-ms", &debounce_ms);
+ if (debounce_ms)
+ plat->debounce_period = debounce_ms * 16;
+ else
+ plat->debounce_period = TC_KPD_DEBOUNCE_PERIOD;
+
+ plat->settle_time = TC_KPD_SETTLE_TIME;
+ /* FIXME: should be property of the IRQ resource? */
+ plat->irqtype = IRQF_TRIGGER_FALLING;
+
+ return plat;
+}
+#else
+static inline const struct tc3589x_keypad_platform_data *
+tc3589x_keypad_of_probe(struct device *dev)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
+
static int tc3589x_keypad_probe(struct platform_device *pdev)
{
struct tc3589x *tc3589x = dev_get_drvdata(pdev->dev.parent);
@@ -307,8 +366,11 @@ static int tc3589x_keypad_probe(struct platform_device *pdev)
plat = tc3589x->pdata->keypad;
if (!plat) {
- dev_err(&pdev->dev, "invalid keypad platform data\n");
- return -EINVAL;
+ plat = tc3589x_keypad_of_probe(&pdev->dev);
+ if (IS_ERR(plat)) {
+ dev_err(&pdev->dev, "invalid keypad platform data\n");
+ return PTR_ERR(plat);
+ }
}
irq = platform_get_irq(pdev, 0);
--
1.8.4.2
^ permalink raw reply related
* [PATCH] pwm: Remove obsolete HAVE_PWM Kconfig symbol
From: Thierry Reding @ 2014-01-23 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389884494-13729-1-git-send-email-s.hauer@pengutronix.de>
On Thu, Jan 16, 2014 at 04:01:34PM +0100, Sascha Hauer wrote:
> Before we had the PWM framework we used to have a barebone PWM api. The
> HAVE_PWM Kconfig symbol used to be selected by the PWM drivers to specify
> the PWM API is present in the kernel. Since the last legacy driver is gone
> the HAVE_PWM symbol can go aswell.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>
> I suggest that Thierry as PWM Maintainer takes the patch through his tree.
> Is that ok for you Thierry?
Yes, that'd be my preference as well. Perhaps you can resend and add a
few more people on Cc. In particular I'd like at least Russell's (ARM)
and Ralf's (MIPS) Acked-by. Dmitry was already Cc'ed for input/misc.
The patch is rather minimal, but I'd still like to give them an
opportunity to object or at least see the patch.
Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140123/41881aa1/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 1/4] pinctrl: st: Add Interrupt support.
From: srinivas kandagatla @ 2014-01-23 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZV7TBP7Ac1MPVSAgJeqWtDQEuT3dHjUJHgDTeX9_datw@mail.gmail.com>
On 23/01/14 07:22, Linus Walleij wrote:
> I've applied this patch so that it won't just sit idle.
> Besides you've done a real good job on it Srinivas.
Thanks Linus W.
>
> It'll be for v3.15 though and I'm still waiting to see if
> the device tree people say something about it.
>
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH v2 3/4] ARM:STi: STiH416: Add interrupt support for pin controller
From: srinivas kandagatla @ 2014-01-23 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ7xK_2zt8XK87YrHGtimjOgVuVnGBNc11eGQcd3uySfw@mail.gmail.com>
On 23/01/14 07:30, Linus Walleij wrote:
> On Thu, Jan 16, 2014 at 4:37 PM, <srinivas.kandagatla@st.com> wrote:
>
>> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>>
>> This patch adds interrupt support for STiH416 pin controllers.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
Thankyou Linus W.
> Please merge this through the ARM SoC tree with the rest of
> your device tree stuff.
>
I will include these in my next DT pull request.
Thanks,
srini
> Yours,
> Linus Walleij
>
>
^ permalink raw reply
* [PATCH 19/73] arm: mach-s3c64xx mach-crag6410-module.c is not modular
From: Charles Keepax @ 2014-01-23 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390339396-3479-20-git-send-email-paul.gortmaker@windriver.com>
On Tue, Jan 21, 2014 at 04:22:22PM -0500, Paul Gortmaker wrote:
> Despite the name mach-crag6410-module.c, the code is built for
> MACH_WLF_CRAGG_6410 -- which is bool, and hence this code is
> either present or absent. It will never be modular, so using
> module_init as an alias for __initcall can be somewhat
> misleading.
>
> Fix this up now, so that we can relocate module_init from
> init.h into module.h in the future. If we don't do this, we'd
> have to add module.h to obviously non-modular code, and that
> would be a worse thing.
>
> Note that direct use of __initcall is discouraged, vs. one
> of the priority categorized subgroups. As __initcall gets
> mapped onto device_initcall, our use of device_initcall
> directly in this change means that the runtime impact is
> zero -- it will remain at level 6 in initcall ordering.
>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: patches at opensource.wolfsonmicro.com
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
Tested-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Thanks,
Charles
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Jean-Jacques Hiblot @ 2014-01-23 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdap7mhGyAr6WcM-cOzbKBJp6S-Qi+oDoM-Pwos14SGyyg@mail.gmail.com>
2014/1/22 Linus Walleij <linus.walleij@linaro.org>:
> On Thu, Jan 16, 2014 at 1:02 PM, Jean-Jacques Hiblot
> <jjhiblot@traphandler.com> wrote:
>
>> Linus,
>> the root of the issue is the fact that a GPIO can't be requested
>> twice. But IMO it's safe for a single device to request it more than
>> once and use it for different purposes (irq and electrical signal
>> value). Maybe we can rework the GPIO request to include this ownership
>> information. I can post a draft implementation for this if you think
>> it's worthwhile.
>
> You are right and actually Jean-Christophe's patch is a good
> start.
Hi Linus,
I've been thinking hard on the gpio ownership and I'd like your
opinion on the following assumptions:
- a gpio used as an interrupt is always a gpio configured as an input.
(corollary : a gpio used for interrupt cannot not be an ouput)
- a gpio used as an input or interrupt only, could be safely accessed
by multiple users.
- a gpio used as an output should be used as such by only one user.
Still other users should be allowed to read its value.
If those assumptions are true, I believe they can lead to a new
exclusion scheme:
- ouput is mutually exclusive with interrupt but not with input
- only 1 ouput user at a time.
It would do away with our sharing issue and more (chained interrupt
handlers on gpio interrupt, read/interrupt access through sysfs to a
gpio requested by a driver)
And I believe that most of the infrastructure is in place to implement this :
- direction flags in gpio_request_one
- gpio_lock_as_irq/gpio_unlock_as_irq
Jean-Jacques
>
> You also need to use the gpio_lock_as_irq() API as shown in
> other patches to the subsystem e.g. this.
> commit eb7cce1ea96b6399672abce787598f6e7a4352c3
>
> Also check my other mail in this thread.
>
> Yours,
> Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox