* [PATCH 09/16] pinctrl: exynos: Use one IRQ domain per pin bank
From: Linus Walleij @ 2012-10-10 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349685556-23718-10-git-send-email-t.figa@samsung.com>
On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> Instead of registering one IRQ domain for all pin banks of a pin
> controller, this patch implements registration of per-bank domains.
>
> At a cost of a little memory overhead (~2.5KiB for all GPIO interrupts
> of Exynos4x12) it simplifies driver code and device tree sources,
> because GPIO interrupts can be now specified per banks.
>
> Example:
> device {
> /* ... */
> interrupt-parent = <&gpa1>;
> interrupts = <3 0>;
> /* ... */
> };
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
This looks like a very good patch!
Can it be applied in isolation from the other patches?
Thomas A: can you ACK this?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 10/16] pinctrl: samsung: Do not pass gpio_chip to pin_to_reg_bank
From: Linus Walleij @ 2012-10-10 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349685556-23718-11-git-send-email-t.figa@samsung.com>
On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> The pointer to gpio_chip passed to pin_to_reg_bank utility function is
> used only to retrieve a pointer to samsung_pinctrl_drv_data structure.
>
> This patch modifies the function and its users to pass a pointer to
> samsung_pinctrl_drv_data directly.
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Looks good, can it be applied without the others?
Maybe you can make a patch series without all the
stuff moving register offsets to the DT so I can begin
with merging that and we can discuss the movement
of register info separately?
Thomas A: is this ACK:able?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 11/16] pinctrl: samsung: Use one GPIO chip per pin bank
From: Linus Walleij @ 2012-10-10 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349685556-23718-12-git-send-email-t.figa@samsung.com>
On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> This patch modifies the pinctrl-samsung driver to register one GPIO chip
> per pin bank, instead of a single chip for all pin banks of the
> controller.
>
> It simplifies GPIO accesses a lot (constant time instead of looping
> through the list of banks to find the right one) and should have a good
> effect on performance of any bit-banging driver.
>
> In addition it allows to reference GPIO pins by a phandle to the bank
> node and a local pin offset inside of the bank (similar to previous
> gpiolib driver), which is more clear and readable than using indices
> relative to the whole pin controller.
>
> Example:
> device {
> /* ... */
> gpios = <&gpk0 4 0>;
> /* ... */
> };
>
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
This also looks good (and I think it has been discussed before)
so needs to be applied in isolation from the regs-to-DT stuff.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 00/16] pinctrl: samsung: Usability and extensibiltiy improvements
From: Linus Walleij @ 2012-10-10 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349685556-23718-1-git-send-email-t.figa@samsung.com>
On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> This patch series is a work on improving usability and extensibiltiy of the
> pinctrl-samsung driver. It consists of three main parts:
> - moving SoC-specific data to device tree
> - converting the driver to use one GPIO chip and one IRQ domain per pin bank
> - introducing generic wake-up interrupt capability description
So can you prepare a patch series which does all but the first
bullet to begin with, and a SoC-and register offset patch
on top of that as a separate series, because it is controversial?
I don't like that these two things are mingled together like this
in an all-or-nothing manner.
So I'm OK with a patch series for bulle (2) and (3) but not (1).
And I'd like to have Thomas A:s ACK on the series too.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] ARM: mx27_3ds: Reserve memory for camera usage
From: Sascha Hauer @ 2012-10-10 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349839770-13848-1-git-send-email-festevam@gmail.com>
On Wed, Oct 10, 2012 at 12:29:29AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Reserve dedicated memory block for camera usage.
Why not use CMA?
Sascha
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> arch/arm/mach-imx/mach-mx27_3ds.c | 32 +++++++++++++++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
> index 05996f3..d3b9a60 100644
> --- a/arch/arm/mach-imx/mach-mx27_3ds.c
> +++ b/arch/arm/mach-imx/mach-mx27_3ds.c
> @@ -30,6 +30,7 @@
> #include <linux/spi/spi.h>
> #include <linux/regulator/machine.h>
> #include <linux/spi/l4f00242t03.h>
> +#include <asm/memblock.h>
>
> #include <media/soc_camera.h>
>
> @@ -165,6 +166,9 @@ static const int mx27pdk_pins[] __initconst = {
> PC19_PF_SSI4_CLK,
> };
>
> +static phys_addr_t mx2_camera_base __initdata;
> +#define MX27PDK_CAM_BUF_SIZE SZ_8M
> +
> static struct gpio mx27_3ds_camera_gpios[] = {
> { CSI_PWRDWN, GPIOF_OUT_INIT_HIGH, "camera-power" },
> { CSI_RESET, GPIOF_OUT_INIT_HIGH, "camera-reset" },
> @@ -478,6 +482,24 @@ static const struct mx2_camera_platform_data mx27_3ds_cam_pdata __initconst = {
> .clk = 26000000,
> };
>
> +static void __init mx27pdk_init_camera(void)
> +{
> + struct platform_device *pdev;
> + int dma;
> +
> + pdev = imx27_add_mx2_camera(&mx27_3ds_cam_pdata);
> +
> + if (IS_ERR(pdev))
> + return;
> +
> + dma = dma_declare_coherent_memory(&pdev->dev,
> + mx2_camera_base, mx2_camera_base,
> + MX27PDK_CAM_BUF_SIZE,
> + DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
> + if (!(dma & DMA_MEMORY_MAP))
> + return;
> +}
> +
> static const struct imxi2c_platform_data mx27_3ds_i2c0_data __initconst = {
> .bitrate = 100000,
> };
> @@ -527,7 +549,7 @@ static void __init mx27pdk_init(void)
> iclink_ov2640.power = NULL;
> }
>
> - imx27_add_mx2_camera(&mx27_3ds_cam_pdata);
> + mx27pdk_init_camera();
> imx27_add_imx_ssi(0, &mx27_3ds_ssi_pdata);
>
> imx_add_platform_device("imx_mc13783", 0, NULL, 0, NULL, 0);
> @@ -542,6 +564,13 @@ static struct sys_timer mx27pdk_timer = {
> .init = mx27pdk_timer_init,
> };
>
> +static void __init mx27pdk_reserve(void)
> +{
> + /* reserve MX27_3DS_CAMERA_BUF_SIZE bytes for mx2-camera */
> + mx2_camera_base = arm_memblock_steal(MX27PDK_CAM_BUF_SIZE,
> + MX27PDK_CAM_BUF_SIZE);
> +}
> +
> MACHINE_START(MX27_3DS, "Freescale MX27PDK")
> /* maintainer: Freescale Semiconductor, Inc. */
> .atag_offset = 0x100,
> @@ -551,5 +580,6 @@ MACHINE_START(MX27_3DS, "Freescale MX27PDK")
> .handle_irq = imx27_handle_irq,
> .timer = &mx27pdk_timer,
> .init_machine = mx27pdk_init,
> + .reserve = mx27pdk_reserve,
> .restart = mxc_restart,
> MACHINE_END
> --
> 1.7.9.5
>
>
--
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
* [PATCH] pinctrl: sirf: remove sirfsoc_gpio_set_pull function
From: Linus Walleij @ 2012-10-10 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091535.56487.arnd@arndb.de>
On Tue, Oct 9, 2012 at 5:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The prima2 platform advertises needing no mach/gpio.h header file,
> but its pinctrl driver now has a sirfsoc_gpio_set_pull function
> that uses constants defined in arch/arm/mach-prima2/include/mach/gpio.h,
> which fails to build.
Applied to my pinctrl "fixes" branch with Barry's ACK.
Thanks!
Linus Walleij
^ permalink raw reply
* [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Ian Campbell @ 2012-10-10 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091821.27818.arnd@arndb.de>
On Tue, 2012-10-09 at 19:21 +0100, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > > config XEN
> > > bool "Xen guest support on ARM (EXPERIMENTAL)"
> > > depends on EXPERIMENTAL && ARM && OF
> > > + depends on !CPU_V6
> > > help
> > > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
> >
> > Considering that we rely on the virtualization extensions, this one can
> > be:
> >
> > depends on CPU_V7
> >
> > The rest looks fine. I can submit a second patch to change !CPU_V6 into
> > CPU_V7 later, if you prefer.
>
> CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
> combined kernel for both V6 and V7. The code also needs to depend on ARMv7
> with virtualization extensions, but that is a different issue. We don't
> actually have a configuration symbol for that yet, as far as I can tell.
I don't think the guest kernels (including dom0) need the extensions to
run under Xen, they are only need by Xen itself. The guests should just
see a relatively normal v7 processor.
Stefano, does that sound right?
Ian.
^ permalink raw reply
* [PATCH] i.MX25 clk fixes
From: Sascha Hauer @ 2012-10-10 8:01 UTC (permalink / raw)
To: linux-arm-kernel
The following are some fixes for the i.MX25 clk support. I came
up with these when matching the clocks with the datasheet. They
are untested as I currently have no hardware which makes use of
these clocks, so I'd be happy if someone could have a look before
they get applied.
BTW I have prepared another patch which adds the missing gates
to the i.MX25 clk support. I'll come up with this after the merge
window when I have rebased the i.MX25 devicetree support on it.
Sascha
----------------------------------------------------------------
Sascha Hauer (3):
ARM i.MX25: Fix lcdc_ipg_per parent clock
ARM i.MX25 clk: Fix nfc_ipg_per parent
ARM i.MX25: Fix PWM per clock lookups
arch/arm/mach-imx/clk-imx25.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 1/3] ARM i.MX25: Fix lcdc_ipg_per parent clock
From: Sascha Hauer @ 2012-10-10 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349856119-22363-1-git-send-email-s.hauer@pengutronix.de>
It's per7, not per6.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-imx/clk-imx25.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index d20d479..334c839 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -127,7 +127,7 @@ int __init mx25_clocks_init(void)
clk[esdhc2_ipg_per] = imx_clk_gate("esdhc2_ipg_per", "per4", ccm(CCM_CGCR0), 4);
clk[gpt_ipg_per] = imx_clk_gate("gpt_ipg_per", "per5", ccm(CCM_CGCR0), 5);
clk[i2c_ipg_per] = imx_clk_gate("i2c_ipg_per", "per6", ccm(CCM_CGCR0), 6);
- clk[lcdc_ipg_per] = imx_clk_gate("lcdc_ipg_per", "per8", ccm(CCM_CGCR0), 7);
+ clk[lcdc_ipg_per] = imx_clk_gate("lcdc_ipg_per", "per7", ccm(CCM_CGCR0), 7);
clk[nfc_ipg_per] = imx_clk_gate("nfc_ipg_per", "ipg_per", ccm(CCM_CGCR0), 8);
clk[ssi1_ipg_per] = imx_clk_gate("ssi1_ipg_per", "per13", ccm(CCM_CGCR0), 13);
clk[ssi2_ipg_per] = imx_clk_gate("ssi2_ipg_per", "per14", ccm(CCM_CGCR0), 14);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] ARM i.MX25 clk: Fix nfc_ipg_per parent
From: Sascha Hauer @ 2012-10-10 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349856119-22363-1-git-send-email-s.hauer@pengutronix.de>
It's per8, there is no ipg_per clk.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-imx/clk-imx25.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index 334c839..01e2f84 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -128,7 +128,7 @@ int __init mx25_clocks_init(void)
clk[gpt_ipg_per] = imx_clk_gate("gpt_ipg_per", "per5", ccm(CCM_CGCR0), 5);
clk[i2c_ipg_per] = imx_clk_gate("i2c_ipg_per", "per6", ccm(CCM_CGCR0), 6);
clk[lcdc_ipg_per] = imx_clk_gate("lcdc_ipg_per", "per7", ccm(CCM_CGCR0), 7);
- clk[nfc_ipg_per] = imx_clk_gate("nfc_ipg_per", "ipg_per", ccm(CCM_CGCR0), 8);
+ clk[nfc_ipg_per] = imx_clk_gate("nfc_ipg_per", "per8", ccm(CCM_CGCR0), 8);
clk[ssi1_ipg_per] = imx_clk_gate("ssi1_ipg_per", "per13", ccm(CCM_CGCR0), 13);
clk[ssi2_ipg_per] = imx_clk_gate("ssi2_ipg_per", "per14", ccm(CCM_CGCR0), 14);
clk[uart_ipg_per] = imx_clk_gate("uart_ipg_per", "per15", ccm(CCM_CGCR0), 15);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/3] ARM i.MX25: Fix PWM per clock lookups
From: Sascha Hauer @ 2012-10-10 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349856119-22363-1-git-send-email-s.hauer@pengutronix.de>
They are behind the gate pwm_ipg_per, not directly behind per10.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-imx/clk-imx25.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index 01e2f84..840fdfa 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -203,13 +203,13 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[cspi2_ipg], NULL, "imx35-cspi.1");
clk_register_clkdev(clk[cspi3_ipg], NULL, "imx35-cspi.2");
clk_register_clkdev(clk[pwm1_ipg], "ipg", "mxc_pwm.0");
- clk_register_clkdev(clk[per10], "per", "mxc_pwm.0");
+ clk_register_clkdev(clk[pwm_ipg_per], "per", "mxc_pwm.0");
clk_register_clkdev(clk[pwm1_ipg], "ipg", "mxc_pwm.1");
- clk_register_clkdev(clk[per10], "per", "mxc_pwm.1");
+ clk_register_clkdev(clk[pwm_ipg_per], "per", "mxc_pwm.1");
clk_register_clkdev(clk[pwm1_ipg], "ipg", "mxc_pwm.2");
- clk_register_clkdev(clk[per10], "per", "mxc_pwm.2");
+ clk_register_clkdev(clk[pwm_ipg_per], "per", "mxc_pwm.2");
clk_register_clkdev(clk[pwm1_ipg], "ipg", "mxc_pwm.3");
- clk_register_clkdev(clk[per10], "per", "mxc_pwm.3");
+ clk_register_clkdev(clk[pwm_ipg_per], "per", "mxc_pwm.3");
clk_register_clkdev(clk[kpp_ipg], NULL, "imx-keypad");
clk_register_clkdev(clk[tsc_ipg], NULL, "mx25-adc");
clk_register_clkdev(clk[i2c_ipg_per], NULL, "imx-i2c.0");
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ARM: mxc: platform-mxc-mmc: Fix register region size
From: Sascha Hauer @ 2012-10-10 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349810713-12307-1-git-send-email-fabio.estevam@freescale.com>
On Tue, Oct 09, 2012 at 04:25:13PM -0300, Fabio Estevam wrote:
> Do not hardcode the register region to SZ_4K as this is not correct for mx31.
>
> Use data->iosize instead which works for both mx27 and mx31 cases.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thanks
Sascha
> ---
> arch/arm/plat-mxc/devices/platform-mxc-mmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/plat-mxc/devices/platform-mxc-mmc.c b/arch/arm/plat-mxc/devices/platform-mxc-mmc.c
> index 540d3a7..e7b920b 100644
> --- a/arch/arm/plat-mxc/devices/platform-mxc-mmc.c
> +++ b/arch/arm/plat-mxc/devices/platform-mxc-mmc.c
> @@ -55,7 +55,7 @@ struct platform_device *__init imx_add_mxc_mmc(
> struct resource res[] = {
> {
> .start = data->iobase,
> - .end = data->iobase + SZ_4K - 1,
> + .end = data->iobase + data->iosize - 1,
> .flags = IORESOURCE_MEM,
> }, {
> .start = data->irq,
> --
> 1.7.9.5
>
>
>
--
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
* [RFC PATCH] arm: vt8500: Convert irq.c for multiplatform integration
From: Tony Prisk @ 2012-10-10 8:08 UTC (permalink / raw)
To: linux-arm-kernel
This patch converts arch-vt8500/irq.c to MULTI_IRQ_HANDLER and
SPARSE_IRQ. IRQ domain is changed from legacy to linear.
Also, remove legacy code in include/mach/entry-macro.S and
include/mach/irq.h to prepare for multiplatform.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
arch/arm/Kconfig | 2 +
arch/arm/mach-vt8500/common.h | 3 +
arch/arm/mach-vt8500/include/mach/entry-macro.S | 26 ------
arch/arm/mach-vt8500/include/mach/irqs.h | 22 -----
arch/arm/mach-vt8500/irq.c | 111 +++++++++++++++--------
arch/arm/mach-vt8500/vt8500.c | 1 +
6 files changed, 79 insertions(+), 86 deletions(-)
delete mode 100644 arch/arm/mach-vt8500/include/mach/entry-macro.S
delete mode 100644 arch/arm/mach-vt8500/include/mach/irqs.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d2f7f5..32b62ac 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -949,6 +949,8 @@ config ARCH_VT8500
select COMMON_CLK
select HAVE_CLK
select CLKDEV_LOOKUP
+ select MULTI_IRQ_HANDLER
+ select SPARSE_IRQ
help
Support for VIA/WonderMedia VT8500/WM85xx System-on-Chip.
diff --git a/arch/arm/mach-vt8500/common.h b/arch/arm/mach-vt8500/common.h
index 2b24196..6f2b843 100644
--- a/arch/arm/mach-vt8500/common.h
+++ b/arch/arm/mach-vt8500/common.h
@@ -25,4 +25,7 @@ int __init vt8500_irq_init(struct device_node *node,
/* defined in drivers/clk/clk-vt8500.c */
void __init vtwm_clk_init(void __iomem *pmc_base);
+/* defined in irq.c */
+asmlinkage void vt8500_handle_irq(struct pt_regs *regs);
+
#endif
diff --git a/arch/arm/mach-vt8500/include/mach/entry-macro.S b/arch/arm/mach-vt8500/include/mach/entry-macro.S
deleted file mode 100644
index 367d1b5..0000000
--- a/arch/arm/mach-vt8500/include/mach/entry-macro.S
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * arch/arm/mach-vt8500/include/mach/entry-macro.S
- *
- * Low-level IRQ helper macros for VIA VT8500
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
- .macro get_irqnr_preamble, base, tmp
- @ physical 0xd8140000 is virtual 0xf8140000
- mov \base, #0xf8000000
- orr \base, \base, #0x00140000
- .endm
-
- .macro get_irqnr_and_base, irqnr, irqstat, base, tmp
- ldr \irqnr, [\base]
- cmp \irqnr, #63 @ may be false positive, check interrupt status
- bne 1001f
- ldr \irqstat, [\base, #0x84]
- ands \irqstat, #0x80000000
- moveq \irqnr, #0
-1001:
- .endm
-
diff --git a/arch/arm/mach-vt8500/include/mach/irqs.h b/arch/arm/mach-vt8500/include/mach/irqs.h
deleted file mode 100644
index a129fd1..0000000
--- a/arch/arm/mach-vt8500/include/mach/irqs.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * arch/arm/mach-vt8500/include/mach/irqs.h
- *
- * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-/* This value is just to make the core happy, never used otherwise */
-#define NR_IRQS 128
diff --git a/arch/arm/mach-vt8500/irq.c b/arch/arm/mach-vt8500/irq.c
index f8f9ab9..7e5fee9 100644
--- a/arch/arm/mach-vt8500/irq.c
+++ b/arch/arm/mach-vt8500/irq.c
@@ -36,7 +36,7 @@
#include <linux/of_address.h>
#include <asm/irq.h>
-
+#include <asm/exception.h>
#define VT8500_ICPC_IRQ 0x20
#define VT8500_ICPC_FIQ 0x24
@@ -66,30 +66,35 @@
#define VT8500_EDGE ( VT8500_TRIGGER_RISING \
| VT8500_TRIGGER_FALLING)
-static int irq_cnt;
+/* vt8500 has 1 intc, wm8505 and wm8650 have 2 */
+#define VT8500_INTC_MAX 2
-struct vt8500_irq_priv {
- void __iomem *base;
+struct vt8500_irq_data {
+ void __iomem *base; /* IO Memory base address */
+ struct irq_domain *domain; /* Domain for this controller */
};
+/* Global variable for accessing io-mem addresses */
+static struct vt8500_irq_data intc[VT8500_INTC_MAX];
+static u32 active_cnt = 0;
+
static void vt8500_irq_mask(struct irq_data *d)
{
- struct vt8500_irq_priv *priv =
- (struct vt8500_irq_priv *)(d->domain->host_data);
+ struct vt8500_irq_data *priv =
+ (struct vt8500_irq_data *)(d->domain->host_data);
void __iomem *base = priv->base;
- u8 edge;
+ void __iomem *stat_reg = base + VT8500_ICIS + (d->hwirq < 32 ? 0 : 4);
+ u8 edge, dctr;
+ u32 status;
edge = readb(base + VT8500_ICDC + d->hwirq) & VT8500_EDGE;
if (edge) {
- void __iomem *stat_reg = base + VT8500_ICIS
- + (d->hwirq < 32 ? 0 : 4);
- unsigned status = readl(stat_reg);
+ status = readl(stat_reg);
status |= (1 << (d->hwirq & 0x1f));
writel(status, stat_reg);
} else {
- u8 dctr = readb(base + VT8500_ICDC + d->hwirq);
-
+ dctr = readb(base + VT8500_ICDC + d->hwirq);
dctr &= ~VT8500_INT_ENABLE;
writeb(dctr, base + VT8500_ICDC + d->hwirq);
}
@@ -97,8 +102,8 @@ static void vt8500_irq_mask(struct irq_data *d)
static void vt8500_irq_unmask(struct irq_data *d)
{
- struct vt8500_irq_priv *priv =
- (struct vt8500_irq_priv *)(d->domain->host_data);
+ struct vt8500_irq_data *priv =
+ (struct vt8500_irq_data *)(d->domain->host_data);
void __iomem *base = priv->base;
u8 dctr;
@@ -109,8 +114,8 @@ static void vt8500_irq_unmask(struct irq_data *d)
static int vt8500_irq_set_type(struct irq_data *d, unsigned int flow_type)
{
- struct vt8500_irq_priv *priv =
- (struct vt8500_irq_priv *)(d->domain->host_data);
+ struct vt8500_irq_data *priv =
+ (struct vt8500_irq_data *)(d->domain->host_data);
void __iomem *base = priv->base;
u8 dctr;
@@ -148,17 +153,15 @@ static struct irq_chip vt8500_irq_chip = {
static void __init vt8500_init_irq_hw(void __iomem *base)
{
- unsigned int i;
+ u32 i;
/* Enable rotating priority for IRQ */
writel(ICPC_ROTATE, base + VT8500_ICPC_IRQ);
writel(0x00, base + VT8500_ICPC_FIQ);
- for (i = 0; i < 64; i++) {
- /* Disable all interrupts and route them to IRQ */
- writeb(VT8500_INT_DISABLE | ICDC_IRQ,
- base + VT8500_ICDC + i);
- }
+ /* Disable all interrupts and route them to IRQ */
+ for (i = 0; i < 64; i++)
+ writeb(VT8500_INT_DISABLE | ICDC_IRQ, base + VT8500_ICDC + i);
}
static int vt8500_irq_map(struct irq_domain *h, unsigned int virq,
@@ -175,33 +178,67 @@ static struct irq_domain_ops vt8500_irq_domain_ops = {
.xlate = irq_domain_xlate_onecell,
};
+asmlinkage void __exception_irq_entry vt8500_handle_irq(struct pt_regs *regs)
+{
+ u32 stat, i;
+ int irqnr, virq;
+ void __iomem *base;
+
+ /* Loop through each active controller */
+ for (i=0; i<active_cnt; i++) {
+ base = intc[i].base;
+ irqnr = readl_relaxed(base) & 0x3F;
+ /*
+ Highest Priority register default = 63, so check that this
+ is a real interrupt by checking the status register
+ */
+ if (irqnr == 63) {
+ stat = readl_relaxed(base + VT8500_ICIS + 4);
+ if (!(stat & BIT(31)))
+ continue;
+ }
+
+ virq = irq_find_mapping(intc[i].domain, irqnr);
+ handle_IRQ(virq, regs);
+ }
+}
+
int __init vt8500_irq_init(struct device_node *node, struct device_node *parent)
{
- struct irq_domain *vt8500_irq_domain;
- struct vt8500_irq_priv *priv;
int irq, i;
struct device_node *np = node;
- priv = kzalloc(sizeof(struct vt8500_irq_priv), GFP_KERNEL);
- priv->base = of_iomap(np, 0);
+ if (active_cnt == VT8500_INTC_MAX) {
+ pr_err("%s: Interrupt controllers > VT8500_INTC_MAX\n",
+ __func__);
+ goto out;
+ }
+
+ intc[active_cnt].base = of_iomap(np, 0);
+ intc[active_cnt].domain = irq_domain_add_linear(node, 64,
+ &vt8500_irq_domain_ops, &intc[active_cnt]);
- vt8500_irq_domain = irq_domain_add_legacy(node, 64, irq_cnt, 0,
- &vt8500_irq_domain_ops, priv);
- if (!vt8500_irq_domain)
- pr_err("%s: Unable to add wmt irq domain!\n", __func__);
+ if (!intc[active_cnt].base) {
+ pr_err("%s: Unable to map IO memory\n", __func__);
+ goto out;
+ }
+
+ if (!intc[active_cnt].domain) {
+ pr_err("%s: Unable to add irq domain!\n", __func__);
+ goto out;
+ }
- irq_set_default_host(vt8500_irq_domain);
+ vt8500_init_irq_hw(intc[active_cnt].base);
- vt8500_init_irq_hw(priv->base);
+ pr_info("vt8500-irq: Added interrupt controller\n");
- pr_info("Added IRQ Controller @ %x [virq_base = %d]\n",
- (u32)(priv->base), irq_cnt);
+ active_cnt++;
/* check if this is a slaved controller */
if (of_irq_count(np) != 0) {
/* check that we have the correct number of interrupts */
if (of_irq_count(np) != 8) {
- pr_err("%s: Incorrect IRQ map for slave controller\n",
+ pr_err("%s: Incorrect IRQ map for slaved controller\n",
__func__);
return -EINVAL;
}
@@ -213,9 +250,7 @@ int __init vt8500_irq_init(struct device_node *node, struct device_node *parent)
pr_info("vt8500-irq: Enabled slave->parent interrupts\n");
}
-
- irq_cnt += 64;
-
+out:
return 0;
}
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 8d3871f..14def0f 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -194,5 +194,6 @@ DT_MACHINE_START(WMT_DT, "VIA/Wondermedia SoC (Device Tree Support)")
.timer = &vt8500_timer,
.init_machine = vt8500_init,
.restart = vt8500_restart,
+ .handle_irq = vt8500_handle_irq,
MACHINE_END
--
1.7.9.5
^ permalink raw reply related
* [PATCH 01/16] ARM: dts: exynos4210: Replace legacy GPIO bank nodes with pinctrl bank nodes
From: Tomasz Figa @ 2012-10-10 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZgH9TSr2uWQW+-8-U7BxJCscQgStVOndGixGmRz74TWw@mail.gmail.com>
On Wednesday 10 of October 2012 09:26:51 Linus Walleij wrote:
> On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > Seuqential patches from this series introduce SoC-specific data parsing
> > from device tree.
> >
> > This patch removes legacy GPIO bank nodes from exynos4210.dtsi and
> > replaces them with nodes and properties required for these patches.
>
> So to be clear:
> > + pinctrl-bank-types {
> > + bank_off: bank-off {
> > + samsung,reg-names = "func", "dat", "pud",
> > + "drv", "conpdn",
> > "pudpdn"; + samsung,reg-params = <0x00 4>, <0x04
> > 1>, <0x08 2>, + <0x0C
> > 2>, <0x10 2>, <0x14 2>; + };
>
> This is starting to look like a firmware language, I have mixed
> feelings about this. Shall this be read:
>
> "Poke 4 into 0x00, poke 1 into 0x04, poke 2 into 0x08" etc?
I'm not sure if I understood you correctly, so let me explain how this
works.
Each specifier defines register offset inside bank registers and how many
bits are used for one pin in this register to specify configuration value.
E.g. func register is available at offset 0x00 and pin 0 occupies bits 0-3,
pin 1 bit 4-7, etc.
>
> We really need to discuss this, Grant has already NACK:ed
> such approaches once.
>
> If you're still going to do this, it is mandatory
> to NOT use magic hex numbers anymore, because Stephen has
> merged preprocessor support to the DTC compiler so you
> can use #defined macros.
>
> See commit:
> cd296721a9645f9f28800a072490fa15458d1fb7
That's definitely nice. I have seen the work going on this before, but
haven't followed it recently. Good to know that now it can be used.
> > + pinctrl at 11400000 {
> > + gpa0: gpa0 {
> > + gpio-controller;
> > + samsung,pctl-offset = <0x000>;
> > + samsung,pin-count = <8>;
> > + samsung,bank-type = <&bank_off>;
> > + #gpio-cells = <2>;
>
> This part is OK.
>
> > +
> > + interrupt-controller;
> > + samsung,eint-offset = <0x00>;
>
> This property is *NOT* OK. IMHO the driver should know these
> offsets, not the device tree. The driver only needs the offset to
> the register range, what registers there are and their names
> should be #defined.
This is an offset inside of EINT register group. EINT registers are
organized in groups as following:
EINT_CON_0
EINT_CON_1
...
EINT_CON_N
...
EINT_MASK_0
EINT_MASK_1
...
EINT_MASK_N
...
EINT_PEND_0
EINT_PEND_1
...
EINT_PEND_N
With arbitrary order of particular groups, arbitrary space between groups
and arbitrary mapping of particular registers to pin banks, although the
mapping is the same for all groups of registers, that's why there is only
one eint-offset property. Also holes (reserved/unused registers) inside
groups might exist.
So if we want to access EINT_MASK register of bank A0 (of pinctrl 0), we
must construct the address as following:
eint_mask_a0 = pinctrl_0_base + pinctrl_0_geint_mask + bank_a0_eint_offset
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH 02/16] pinctrl: exynos: Parse wakeup-eint parameters from DT
From: Tomasz Figa @ 2012-10-10 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ97BRHo1Usen-D9CnojU4HLqkNb5CKNOmx7uP1A9ttgw@mail.gmail.com>
On Wednesday 10 of October 2012 09:18:51 Linus Walleij wrote:
> On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > This patch converts the pinctrl-exynos driver to parse wakeup interrupt
> > count and register offsets from device tree. It reduces the amount of
> > static platform-specific data and facilitates adding further SoC
> > variants to pinctrl-samsung driver.
>
> So these are:
> > + ret = of_property_read_u32(wkup_np, "samsung,weint-count",
> > &val); + ret = of_property_read_u32(wkup_np,
> > "samsung,weint-con", &val); + ret =
> > of_property_read_u32(wkup_np, "samsung,weint-mask", &val); + ret
> > = of_property_read_u32(wkup_np, "samsung,weint-pend", &val);
> Are these all four register offsets?
>
> I don't think it's proper for the device tree to contain register
> offsets.
>
> Base address, "regs" property, yes. Individual registers, no. That just
> makes the code hard to read and compare to the datasheet.
>
> Or what are you aiming at here?
See my reply to your comments for patch 1. I think it should explain how
these values are used.
One thing worth mentioning is that registers for GPIO interrupts and wakeup
interrupts can be located at different areas of pin controller address
space, so these offsets have to be specified for both (using geint-* and
weint-* properties).
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH 03/16] pinctrl: samsung: Detect and handle unsupported configuration types
From: Tomasz Figa @ 2012-10-10 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda8mBsetmkWSfed0VpGA_Aw4vNUSGZcTx=bY8LDRzxFdA@mail.gmail.com>
On Wednesday 10 of October 2012 09:37:42 Linus Walleij wrote:
> On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > This patch modifies the pinctrl-samsung driver to detect when width of
> > a
> > bit field is set to zero (which means that such configuraton type is
> > not
> > supported) and return an error instead of trying to modify an
> > inexistent
> > register.
> >
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > ---
> >
> > drivers/pinctrl/pinctrl-samsung.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/pinctrl/pinctrl-samsung.c
> > b/drivers/pinctrl/pinctrl-samsung.c index dd108a9..c660fa5 100644
> > --- a/drivers/pinctrl/pinctrl-samsung.c
> > +++ b/drivers/pinctrl/pinctrl-samsung.c
> > @@ -391,6 +391,9 @@ static int samsung_pinconf_rw(struct pinctrl_dev
> > *pctldev, unsigned int pin,>
> > return -EINVAL;
> >
> > }
> >
> > + if (!width)
> > + return -EINVAL;
> > +
>
> Can this patch be applied in isolation from the others?
Yes, I don't see any problem here.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH v2] ARM : i.MX27 : split code for allocation of ressources of camera and eMMA
From: Sascha Hauer @ 2012-10-10 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5074202F.2020107@gmail.com>
On Tue, Oct 09, 2012 at 03:01:35PM +0200, Ga?tan Carlier wrote:
> Hi Sascha,
> On 09/11/2012 01:17 PM, Sascha Hauer wrote:
> >On Tue, Sep 11, 2012 at 01:13:03PM +0200, javier Martin wrote:
> >>Hi,
> >>
> >>On 11 September 2012 11:47, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >>>Hi Javier,
> >>>
> >>>Since you worked in this area recently, can I have your Ack on this?
> >>
> >>Acked-by: Javier Martin <javier.martin@vista-silicon.com>
> >
> >Thanks
> This patch is missing in next-20121008 and seems to be never
> committed. Is there any reason ?
Sorry, I simply missed to apply it :(
Did that now.
Sascha
> >
> >>
> >>>As a side note: Please be prepared that all this should be removed in
> >>>the not-so-far future. It would be good if you start converting your
> >>>boards to devicetree soon. You may be doing so internally already, I
> >>>don't know.
> >>
> >>We made some tests regarding devicetree this summer but we found that
> >>there are some things missing yet:
> >>- pinctrl
> >>- soc-camera and video sensor
> >>
> >>I don't know if people from Linaro is planning to deal with pinctrl
> >>for i.MX27 or not.
> >
> >I don't think Linaro will do anything for the older i.MX like the
> >i.MX27. With soc-camera I'm optimistic that someone will come up
> >with patches soon.
> >
> >Sascha
> >
> Thank you.
> Best regards,
> Ga?tan Carlier.
>
--
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
* [RFC PATCH] arm: vt8500: Convert irq.c for multiplatform integration
From: Arnd Bergmann @ 2012-10-10 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349856509-20480-1-git-send-email-linux@prisktech.co.nz>
On Wednesday 10 October 2012, Tony Prisk wrote:
> This patch converts arch-vt8500/irq.c to MULTI_IRQ_HANDLER and
> SPARSE_IRQ. IRQ domain is changed from legacy to linear.
>
> Also, remove legacy code in include/mach/entry-macro.S and
> include/mach/irq.h to prepare for multiplatform.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Excellent!
Acked-by: Arnd Bergmann <arnd@arndb.de>
One small style comment for a preexisting issue I had not noticed before:
> static void vt8500_irq_mask(struct irq_data *d)
> {
> - struct vt8500_irq_priv *priv =
> - (struct vt8500_irq_priv *)(d->domain->host_data);
> + struct vt8500_irq_data *priv =
> + (struct vt8500_irq_data *)(d->domain->host_data);
host_data is a void pointer, so you don't need the type cast. Writing this
as
struct vt8500_irq_priv *priv = d->domain->host_data;
is both the common convention and easier to read.
Arnd
^ permalink raw reply
* [PATCH 2/6] ARM: EXYNOS5: DT Support for SATA and SATA PHY
From: Vasanth Ananthan @ 2012-10-10 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009182828.GA20879@quad.lixom.net>
Hi,
On Tue, Oct 9, 2012 at 11:58 PM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
>
> On Tue, Oct 09, 2012 at 05:18:48PM +0530, Vasanth Ananthan wrote:
> > This patch adds Device Nodes for SATA and SATA PHY device.
> >
> > Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
> > ---
> > arch/arm/boot/dts/exynos5250-smdk5250.dts | 11 +++++++++++
> > arch/arm/boot/dts/exynos5250.dtsi | 20 ++++++++++++++++++++
> > arch/arm/mach-exynos/include/mach/map.h | 7 +++++++
> > arch/arm/mach-exynos/mach-exynos5-dt.c | 6 ++++++
> > 4 files changed, 44 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> > index 8a5e348..bb262ce 100644
> > --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> > +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> > @@ -48,6 +48,17 @@
> > };
> > };
> >
> > + i2c at 121D0000 {
> > + samsung,i2c-sda-delay = <100>;
> > + samsung,i2c-max-bus-freq = <40000>;
> > + samsung,i2c-slave-addr = <0x38>;
>
> Whitespace is off above.
>
> > +
> > + sataphy at 70 {
>
> sata-phy would be a more conventional name.
>
> > + compatible = "samsung,i2c-phy";
>
> i2c-phy? Seems like an odd choice of name. What is this device?
>
The SATA physical layer controller is both a platform device and a i2c
slave device.
This compatible string is for the i2c client driver. Hence I have used
i2c-phy here.
>
> > + reg = <0x38>;
>
> 70 is unit address but here it's 0x38? One of them is wrong. No need for a
> unit
> address if it's a unique name, by the way.
>
>
> > + };
> > + };
> > +
> > i2c at 12C80000 {
> > status = "disabled";
> > };
> > diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> > index 004aaa8..5a47a8f 100644
> > --- a/arch/arm/boot/dts/exynos5250.dtsi
> > +++ b/arch/arm/boot/dts/exynos5250.dtsi
> > @@ -88,6 +88,18 @@
> > interrupts = <0 54 0>;
> > };
> >
> > + sata at 122F0000 {
> > + compatible = "samsung,exynos-sata-ahci";
> > + reg = <0x122F0000 0x1ff>;
> > + interrupts = <0 115 0>;
>
> More whitespace damage. And need binding.
>
> > + };
> > +
> > + sata-phy at 12170000 {
> > + compatible = "samsung,exynos-sata-phy";
> > + reg = <0x12170000 0x1ff>;
> > + };
>
> Should have binding too. How does this relate to the i2c device above.
>
As mentioned earlier SATA physical layer controller is both a platform
device and also an i2c slave device.
This Node is for the SATA physical layer platform device, the previous node
is for i2c slave device.
Certain initialization settings done directly and other settings has to be
done through i2c.
> > +
> > i2c at 12C60000 {
> > compatible = "samsung,s3c2440-i2c";
> > reg = <0x12C60000 0x100>;
> > @@ -152,6 +164,13 @@
> > #size-cells = <0>;
> > };
> >
> > + i2c at 121D0000 {
> > + compatible = "samsung,s3c2440-sataphy-i2c";
>
> Is this a unique i2c controller, or is it just another one like the others
> on
> the chip? If it's the latter, it should use the regular compatible string.
>
Yes, its a unique i2c controller which lacks an interrupt line while others
are interrupt driven.
Hence I have used a distinct compatible string for the driver to
distinguish the controller.
> > + reg = <0x121D0000 0x100>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > spi_0: spi at 12d20000 {
> > compatible = "samsung,exynos4210-spi";
> > reg = <0x12d20000 0x100>;
> > @@ -460,4 +479,5 @@
> > #gpio-cells = <4>;
> > };
> > };
> > +
>
> Stray whitespace change.
>
> > };
> > diff --git a/arch/arm/mach-exynos/include/mach/map.h
> b/arch/arm/mach-exynos/include/mach/map.h
> > index c72b675..6827190 100644
> > --- a/arch/arm/mach-exynos/include/mach/map.h
> > +++ b/arch/arm/mach-exynos/include/mach/map.h
> > @@ -177,9 +177,16 @@
> > #define EXYNOS4_PA_HSOTG 0x12480000
> > #define EXYNOS4_PA_USB_HSPHY 0x125B0000
> >
> > +#ifdef CONFIG_ARCH_EXYNOS4
>
> No need to ifdef since namespace isn't overlapped.
>
> > #define EXYNOS4_PA_SATA 0x12560000
> > #define EXYNOS4_PA_SATAPHY 0x125D0000
> > #define EXYNOS4_PA_SATAPHY_CTRL 0x126B0000
> > +#endif
> > +#ifdef CONFIG_ARCH_EXYNOS5
>
> Same here.
>
> > +#define EXYNOS5_PA_SATA_PHY_CTRL 0x12170000
> > +#define EXYNOS5_PA_SATA_PHY_I2C 0x121D0000
> > +#define EXYNOS5_PA_SATA_BASE 0x122F0000
> > +#endif
>
>
> -Olof
>
I will incorporate the other comments and resubmit the patch. Thanks.
--
Vasanth Ananthan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121010/7856e75d/attachment-0001.html>
^ permalink raw reply
* [PATCH 04/16] pinctrl: samsung: Parse pin banks from DT
From: Tomasz Figa @ 2012-10-10 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdafuxbO_peOBgmrjXk7ioVBF6D-D7d=shUd-GpHOdNxqg@mail.gmail.com>
On Wednesday 10 of October 2012 09:34:05 Linus Walleij wrote:
> On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > Currently SoC-specific properties such as list of pin banks, register
> > offsets and bitfield sizes are being taken from static data structures
> > residing in pinctrl-exynos.c.
> >
> > This patch modifies the pinctrl-samsung driver to parse all
> > SoC-specific
> > data from device tree, which will allow to remove the static data
> > structures and facilitate adding of further SoC variants to the
> > pinctrl-samsung driver.
>
> So why? Two approaches:
>
> - Put as much info as possible into the device tree
> - Put as much info as possible into the driver
>
> The first approach is currently only used by pinctrl-single.c.
>
> That driver is designed for the case where all info about
> the hardware arrives in some description language that
> can be translated into a simple DT description.
>
> If you want to use that approach, you should use that
> driver. If that driver does not work for you, then it's not
> fulfilling it's purpose as a one-stop shop for simple
> pin controllers entirely contained within the device tree,
> and should be renamed or redesigned.
>
> If you will end up with a hybrid approach with some
> stuff in the device tree and some stuff in the code,
> it's better to keep the old driver.
This will allow us to cover all the existing Samsung SoCs, starting from
S3C24xx, through S3C64xx, S5P*, all supported Exynos SoCs and ending on any
future SoCs using this kind of pin controller, without bloating the driver
with hardly readable macros, lots of (often duplicated) static data and
similar.
If there are some serious problems with this approach, just let me know and
I will reconsider it, but if not, I'd like to keep it, because of the
benefits it gives.
(Even if I moved all those SoC-specific data to static structures located
in the driver, to keep the most readable way of GPIO specification in DT, I
would have to create nodes for all banks in DT anyway and the driver would
have to match particular nodes with their static data. I don't like this
kind of approach.)
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH 09/16] pinctrl: exynos: Use one IRQ domain per pin bank
From: Tomasz Figa @ 2012-10-10 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbNHqwt2X-SNRv3=7Ca-WrDERb=t01K7pFuvRzTNk1+4Q@mail.gmail.com>
On Wednesday 10 of October 2012 09:40:16 Linus Walleij wrote:
> On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > Instead of registering one IRQ domain for all pin banks of a pin
> > controller, this patch implements registration of per-bank domains.
> >
> > At a cost of a little memory overhead (~2.5KiB for all GPIO interrupts
> > of Exynos4x12) it simplifies driver code and device tree sources,
> > because GPIO interrupts can be now specified per banks.
> >
> > Example:
> > device {
> >
> > /* ... */
> > interrupt-parent = <&gpa1>;
> > interrupts = <3 0>;
> > /* ... */
> >
> > };
> >
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
>
> This looks like a very good patch!
> Can it be applied in isolation from the other patches?
This is heavily dependent on previous patches, because each pin bank must
have its own node that can be bound to the IRQ domain and used as an
interrupt-controller in interrupt-parent property.
I can imagine kind of hybrid solution, where bank nodes contain almost no
data, other than gpio-controller, interrupt-controller and #*-cells
properties, but this would introduce the need of matching bank nodes with
banks statically defined in the driver.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH 11/16] pinctrl: samsung: Use one GPIO chip per pin bank
From: Tomasz Figa @ 2012-10-10 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY3rk41xDQbG9Ft8iVYZnyk3vu3Fs9Ehin2Q1oSZ3JO-Q@mail.gmail.com>
On Wednesday 10 of October 2012 09:43:25 Linus Walleij wrote:
> On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > This patch modifies the pinctrl-samsung driver to register one GPIO
> > chip
> > per pin bank, instead of a single chip for all pin banks of the
> > controller.
> >
> > It simplifies GPIO accesses a lot (constant time instead of looping
> > through the list of banks to find the right one) and should have a good
> > effect on performance of any bit-banging driver.
> >
> > In addition it allows to reference GPIO pins by a phandle to the bank
> > node and a local pin offset inside of the bank (similar to previous
> > gpiolib driver), which is more clear and readable than using indices
> > relative to the whole pin controller.
> >
> > Example:
> > device {
> >
> > /* ... */
> > gpios = <&gpk0 4 0>;
> > /* ... */
> >
> > };
> >
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
>
> This also looks good (and I think it has been discussed before)
> so needs to be applied in isolation from the regs-to-DT stuff.
Please see my reply for patch 9.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH] ARM: imx: configs: Enable CONFIG_MEDIA_CAMERA_SUPPORT
From: Sascha Hauer @ 2012-10-10 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349631857-31556-1-git-send-email-festevam@gmail.com>
On Sun, Oct 07, 2012 at 02:44:17PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Since commit b4c184e5 (edia] media: reorganize the main Kconfig items),
> it is necessary to select CONFIG_MEDIA_CAMERA_SUPPORT in order to be able
> to use the SoC camera drivers.
>
> Select CONFIG_MEDIA_CAMERA_SUPPORT so that we can use mx2-camera/mx3-camera
> by default as previously.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thanks
Sascha
> ---
> arch/arm/configs/imx_v4_v5_defconfig | 1 +
> arch/arm/configs/imx_v6_v7_defconfig | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig
> index 78ed575..d100401 100644
> --- a/arch/arm/configs/imx_v4_v5_defconfig
> +++ b/arch/arm/configs/imx_v4_v5_defconfig
> @@ -121,6 +121,7 @@ CONFIG_REGULATOR_MC13892=y
> CONFIG_MEDIA_SUPPORT=y
> CONFIG_VIDEO_DEV=y
> CONFIG_V4L_PLATFORM_DRIVERS=y
> +CONFIG_MEDIA_CAMERA_SUPPORT=y
> CONFIG_SOC_CAMERA=y
> CONFIG_SOC_CAMERA_OV2640=y
> CONFIG_VIDEO_MX2=y
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
> index 66aa7a6..fcb4b62 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -151,6 +151,7 @@ CONFIG_REGULATOR_MC13892=y
> CONFIG_MEDIA_SUPPORT=y
> CONFIG_VIDEO_DEV=y
> CONFIG_V4L_PLATFORM_DRIVERS=y
> +CONFIG_MEDIA_CAMERA_SUPPORT=y
> CONFIG_SOC_CAMERA=y
> CONFIG_SOC_CAMERA_OV2640=y
> CONFIG_VIDEO_MX3=y
> --
> 1.7.9.5
>
>
--
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
* [PATCH 10/16] pinctrl: samsung: Do not pass gpio_chip to pin_to_reg_bank
From: Tomasz Figa @ 2012-10-10 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYinRRictTsH-zp=Y7FPAd92NP6E1WMU6YoupJDeYre8A@mail.gmail.com>
On Wednesday 10 of October 2012 09:42:10 Linus Walleij wrote:
> On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > The pointer to gpio_chip passed to pin_to_reg_bank utility function is
> > used only to retrieve a pointer to samsung_pinctrl_drv_data structure.
> >
> > This patch modifies the function and its users to pass a pointer to
> > samsung_pinctrl_drv_data directly.
> >
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
>
> Looks good, can it be applied without the others?
Yes, I think this one should apply fine.
> Maybe you can make a patch series without all the
> stuff moving register offsets to the DT so I can begin
> with merging that and we can discuss the movement
> of register info separately?
I already considered this approach, but it introduces some problems, as I
mentioned in my other replies.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH 00/16] pinctrl: samsung: Usability and extensibiltiy improvements
From: Tomasz Figa @ 2012-10-10 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbUmM2=vhjhCq_qN2v=8RUDeWV4b8A8oXXPE4e8Z9C7zg@mail.gmail.com>
On Wednesday 10 of October 2012 09:46:28 Linus Walleij wrote:
> On Mon, Oct 8, 2012 at 10:39 AM, Tomasz Figa <t.figa@samsung.com> wrote:
> > This patch series is a work on improving usability and extensibiltiy of
> > the>
> > pinctrl-samsung driver. It consists of three main parts:
> > - moving SoC-specific data to device tree
> > - converting the driver to use one GPIO chip and one IRQ domain per
> > pin bank - introducing generic wake-up interrupt capability
> > description
>
> So can you prepare a patch series which does all but the first
> bullet to begin with, and a SoC-and register offset patch
> on top of that as a separate series, because it is controversial?
>
> I don't like that these two things are mingled together like this
> in an all-or-nothing manner.
>
> So I'm OK with a patch series for bulle (2) and (3) but not (1).
As I already stated in my other replies, patches for (2) and (3) depend on
(1), because current architecture of the driver makes it hard to implement
in an elegant way, so some code would have to be reworked anyway.
I should still have some preliminary work on this in one of my branches in
my working tree, but it was heavily incomplete, as it turned out that using
DT would simplify some things.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
^ 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