* [PATCH v4 2/3] arm/tegra: add support for ventana pinmuxing
From: Peter De Schrijver @ 2011-09-28 1:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317171902-14736-1-git-send-email-pdeschrijver@nvidia.com>
Add support for ventana pinmuxing as a seaboard derivative. This is a cut down
version of work done by Jong Kim <jongk@nvidia.com>.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/board-seaboard-pinmux.c | 49 +++++++++++++++++++++++++-
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index f11b910..91a07e1 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -31,6 +31,7 @@ obj-${CONFIG_MACH_SEABOARD} += board-seaboard-pinmux.o
obj-${CONFIG_MACH_TEGRA_DT} += board-dt.o
obj-${CONFIG_MACH_TEGRA_DT} += board-harmony-pinmux.o
+obj-${CONFIG_MACH_TEGRA_DT} += board-seaboard-pinmux.o
obj-${CONFIG_MACH_TRIMSLICE} += board-trimslice.o
obj-${CONFIG_MACH_TRIMSLICE} += board-trimslice-pinmux.o
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index b31c765..b62b04d 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -158,8 +158,26 @@ static __initdata struct tegra_pingroup_config seaboard_pinmux[] = {
{TEGRA_PINGROUP_XM2D, TEGRA_MUX_NONE, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
};
-
-
+static __initdata struct tegra_pingroup_config ventana_pinmux[] = {
+ {TEGRA_PINGROUP_DAP3, TEGRA_MUX_DAP3, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_DDC, TEGRA_MUX_RSVD2, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTA, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTB, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTC, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTD, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_GMD, TEGRA_MUX_SFLASH, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_LPW0, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LPW2, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LSC1, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LSCK, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_LSDA, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_PTA, TEGRA_MUX_RSVD2, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SLXC, TEGRA_MUX_SDIO3, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SLXK, TEGRA_MUX_SDIO3, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SPIA, TEGRA_MUX_GMI, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_SPIC, TEGRA_MUX_GMI, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_SPIG, TEGRA_MUX_SPI2_ALT, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+};
static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_SD2_CD, .enable = true },
@@ -172,6 +190,26 @@ static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_USB1, .enable = true },
};
+static void __init update_pinmux(struct tegra_pingroup_config *newtbl, int size)
+{
+ int i, j;
+ struct tegra_pingroup_config *new_pingroup, *base_pingroup;
+
+ /* Update base seaboard pinmux table with secondary board
+ * specific pinmux table table.
+ */
+ for (i = 0; i < size; i++) {
+ new_pingroup = &newtbl[i];
+ for (j = 0; j < ARRAY_SIZE(seaboard_pinmux); j++) {
+ base_pingroup = &seaboard_pinmux[j];
+ if (new_pingroup->pingroup == base_pingroup->pingroup) {
+ *base_pingroup = *new_pingroup;
+ break;
+ }
+ }
+ }
+}
+
static void __init seaboard_common_pinmux_init(void)
{
tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
@@ -186,3 +224,10 @@ void __init seaboard_pinmux_init(void)
{
seaboard_common_pinmux_init();
}
+
+void __init ventana_pinmux_init(void)
+{
+ update_pinmux(ventana_pinmux, ARRAY_SIZE(ventana_pinmux));
+ seaboard_common_pinmux_init();
+}
+
--
1.7.0.4
^ permalink raw reply related
* [PATCH v4 3/3] arm/tegra: device tree support for ventana board
From: Peter De Schrijver @ 2011-09-28 1:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317171902-14736-1-git-send-email-pdeschrijver@nvidia.com>
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/boot/dts/tegra-ventana.dts | 32 ++++++++++++++++++++++++++++++++
arch/arm/mach-tegra/Kconfig | 6 ++++++
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 5 ++++-
4 files changed, 43 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-ventana.dts
diff --git a/arch/arm/boot/dts/tegra-ventana.dts b/arch/arm/boot/dts/tegra-ventana.dts
new file mode 100644
index 0000000..9b29a62
--- /dev/null
+++ b/arch/arm/boot/dts/tegra-ventana.dts
@@ -0,0 +1,32 @@
+/dts-v1/;
+
+/memreserve/ 0x1c000000 0x04000000;
+/include/ "tegra20.dtsi"
+
+/ {
+ model = "NVIDIA Tegra2 Ventana evaluation board";
+ compatible = "nvidia,ventana", "nvidia,tegra20";
+
+ chosen {
+ bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/ram rdinit=/sbin/init";
+ };
+
+ memory {
+ reg = < 0x00000000 0x40000000 >;
+ };
+
+ serial at 70006300 {
+ clock-frequency = < 216000000 >;
+ };
+
+ sdhci at c8000400 {
+ cd-gpios = <&gpio 69 0>; /* gpio PI5 */
+ wp-gpios = <&gpio 57 0>; /* gpio PH1 */
+ power-gpios = <&gpio 155 0>; /* gpio PT3 */
+ };
+
+ sdhci at c8000600 {
+ power-gpios = <&gpio 70 0>; /* gpio PI6 */
+ support-8bit;
+ };
+};
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index d82ebab..91aff7c 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -69,6 +69,12 @@ config MACH_WARIO
help
Support for the Wario version of Seaboard
+config MACH_VENTANA
+ bool "Ventana board"
+ select MACH_TEGRA_DT
+ help
+ Support for the nVidia Ventana development platform
+
choice
prompt "Low-level debug console UART"
default TEGRA_DEBUG_UART_NONE
diff --git a/arch/arm/mach-tegra/Makefile.boot b/arch/arm/mach-tegra/Makefile.boot
index 5e870d2..bd12c9f 100644
--- a/arch/arm/mach-tegra/Makefile.boot
+++ b/arch/arm/mach-tegra/Makefile.boot
@@ -4,3 +4,4 @@ initrd_phys-$(CONFIG_ARCH_TEGRA_2x_SOC) := 0x00800000
dtb-$(CONFIG_MACH_HARMONY) += tegra-harmony.dtb
dtb-$(CONFIG_MACH_SEABOARD) += tegra-seaboard.dtb
+dtb-$(CONFIG_MACH_VENTANA) += tegra-ventana.dtb
diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
index 9f47e04..5885102 100644
--- a/arch/arm/mach-tegra/board-dt.c
+++ b/arch/arm/mach-tegra/board-dt.c
@@ -47,7 +47,7 @@
void harmony_pinmux_init(void);
void seaboard_pinmux_init(void);
-
+void ventana_pinmux_init(void);
struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC1_BASE, "sdhci-tegra.0", NULL),
@@ -95,6 +95,8 @@ static void __init tegra_dt_init(void)
harmony_pinmux_init();
else if (of_machine_is_compatible("nvidia,seaboard"))
seaboard_pinmux_init();
+ else if (of_machine_is_compatible("nvidia,ventana"))
+ ventana_pinmux_init();
/*
* Finished with the static registrations now; fill in the missing
@@ -106,6 +108,7 @@ static void __init tegra_dt_init(void)
static const char * tegra_dt_board_compat[] = {
"nvidia,harmony",
"nvidia,seaboard",
+ "nvidia,ventana",
NULL
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Peter De Schrijver @ 2011-09-28 1:07 UTC (permalink / raw)
To: linux-arm-kernel
This patch causes the kernel uncompressor to determine the physical address
of the SDRAM at runtime. This allows the kernel to boot on both tegra20 and
tegra30 even though SDRAM is at different physical addresses on both SoCs.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 472a7f8..474737b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -596,6 +596,7 @@ config ARCH_TEGRA
select HAVE_CLK
select HAVE_SCHED_CLOCK
select ARCH_HAS_CPUFREQ
+ select AUTO_ZRELADDR
help
This enables support for NVIDIA Tegra based systems (Tegra APX,
Tegra 6xx and Tegra 2 series).
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] devicetree: Add ARM pl061 gpio controller binding doc
From: Rob Herring @ 2011-09-28 1:45 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
Add binding documentation for ARM's Primecell PL061 GPIO controller.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
.../devicetree/bindings/gpio/pl061-gpio.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/pl061-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/pl061-gpio.txt b/Documentation/devicetree/bindings/gpio/pl061-gpio.txt
new file mode 100644
index 0000000..a2c416b
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/pl061-gpio.txt
@@ -0,0 +1,10 @@
+ARM PL061 GPIO controller
+
+Required properties:
+- compatible : "arm,pl061", "arm,primecell"
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional parameters:
+ - bit 0 specifies polarity (0 for normal, 1 for inverted)
+- gpio-controller : Marks the device node as a GPIO controller.
+- interrupts : Interrupt mapping for GPIO IRQ.
+
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] devicetree: Add ARM pl022 spi controller binding doc
From: Rob Herring @ 2011-09-28 1:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317174314-16122-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Add binding documentation for ARM's Primecell PL022 SPI controller.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
.../devicetree/bindings/spi/spi_pl022.txt | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi_pl022.txt
diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt b/Documentation/devicetree/bindings/spi/spi_pl022.txt
new file mode 100644
index 0000000..306ec3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi_pl022.txt
@@ -0,0 +1,12 @@
+ARM PL022 SPI controller
+
+Required properties:
+- compatible : "arm,pl022", "arm,primecell"
+- reg : Offset and length of the register set for the device
+- interrupts : Should contain SPI controller interrupt
+
+Optional properties:
+- cs-gpios : should specify GPIOs used for chipselects.
+ The gpios will be referred to as reg = <index> in the SPI child nodes.
+ If unspecified, a single SPI device without a chip select can be used.
+
--
1.7.5.4
^ permalink raw reply related
* [linux-pm Query] Power Management Device Suspend/ Resume
From: Viresh Kumar @ 2011-09-28 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAO1yOm2pbApTwa0gj3Q9RsC1mxNGGirxm6FzaDC7zbgjHdkKDw@mail.gmail.com>
Hi,
Can somebody please help us understand suspend/resume.
It would be a great help, even if you can point us to some earlier fruitful
discussion.
--
viresh
On 9/22/2011 4:19 PM, Deepak Sikri wrote:
> Hi,
>
> We are in the process of adding Suspend/ Resume call backs for the devices on SPEAr platform.
> The platform makes use of various power domains which could be turned off (during suspend, implying
> the devices in those power domains lose their context).
>
> *There are certain queries*.
>
> *Query- 1*. Suppose my platform has a ADC driver under char framework, which internally uses the
> DMA driver (channels). Now, ADC driver can be used by other kernel drivers or directly from user application.
>
> *1. a.* What are the expectations from the suspend and resume routines of both the devices, DMA & ADC ?
>
> */-- Given that few of the options are/*
> */1.a.1. On suspend,/*
> In ADC suspend function: ADC releases all the DMA channels, latches its registers; and
> DMA suspend function: DMA does nothing except for lataching of registers if required.
>
> */1.a.2. On suspend, /*
> ADC suspend function: ADC just latches its registers and stops R/W through DMA, no DMA channel release;
> DMA suspend function: DMA halts its operating channels, and latches its registers if required.
>
> */1.a.3 Some other alternative/*
> *//*
>
> *1.b* Will the suspend resume for the dependent drivers follow sequencing, i.e. Suspend of ADC followed by
> Suspend of DMA? (Assume both of these devices are hooked on to Platform bus, given that ADC uses DMA)
>
> *Query-2*
>
> 2.1 The user space threads freeze first followed by kernel space. In case the user space process issues a a system
> call (lets assume an ioctl system call), how will the user space thread respond in case of suspend to ram?
>
> 2.2 Will the kernel thread running on behalf of user space process complete the ioctl call OR
> freeze upon in the middle of execution?
>
> *Query-3*
> **
> Are there any modalities w.r.t latching and restoring the contents at the driver level ?
> that is: Should this process be handled at drier level or platform specific code can also handle this
>
>
> Thanks & Regards
> Deepak
^ permalink raw reply
* [linux-pm Query] Power Management Device Suspend/ Resume
From: Vinod Koul @ 2011-09-28 3:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8293C4.5090009@st.com>
On Wed, 2011-09-28 at 08:55 +0530, Viresh Kumar wrote:
> Hi,
>
> Can somebody please help us understand suspend/resume.
> It would be a great help, even if you can point us to some earlier fruitful
> discussion.
are you trying to do runtime power management or traditional suspend and
resume? IMO both should be done...
>
> --
> viresh
>
> On 9/22/2011 4:19 PM, Deepak Sikri wrote:
> > Hi,
> >
> > We are in the process of adding Suspend/ Resume call backs for the devices on SPEAr platform.
> > The platform makes use of various power domains which could be turned off (during suspend, implying
> > the devices in those power domains lose their context).
> >
> > *There are certain queries*.
> >
> > *Query- 1*. Suppose my platform has a ADC driver under char framework, which internally uses the
> > DMA driver (channels). Now, ADC driver can be used by other kernel drivers or directly from user application.
> >
> > *1. a.* What are the expectations from the suspend and resume routines of both the devices, DMA & ADC ?
> >
> > */-- Given that few of the options are/*
> > */1.a.1. On suspend,/*
> > In ADC suspend function: ADC releases all the DMA channels, latches its registers; and
> > DMA suspend function: DMA does nothing except for lataching of registers if required.
> >
> > */1.a.2. On suspend, /*
> > ADC suspend function: ADC just latches its registers and stops R/W through DMA, no DMA channel release;
> > DMA suspend function: DMA halts its operating channels, and latches its registers if required.
Well channel release/alloc is not really required. You can goto suspend
in between as well. if you have queued but not active descriptors on all
channels then dmac is idle and you can use this time to goto suspend.
> >
> > */1.a.3 Some other alternative/*
> > *//*
> >
> > *1.b* Will the suspend resume for the dependent drivers follow sequencing, i.e. Suspend of ADC followed by
> > Suspend of DMA? (Assume both of these devices are hooked on to Platform bus, given that ADC uses DMA)
why do you care?
Each driver is independent and should manage its own resources properly
> >
> > *Query-2*
> >
> > 2.1 The user space threads freeze first followed by kernel space. In case the user space process issues a a system
> > call (lets assume an ioctl system call), how will the user space thread respond in case of suspend to ram?
all user space processes are frozen on STR
> >
> > 2.2 Will the kernel thread running on behalf of user space process complete the ioctl call OR
> > freeze upon in the middle of execution?
IIRC, It will be frozen
> >
> > *Query-3*
> > **
> > Are there any modalities w.r.t latching and restoring the contents at the driver level ?
> > that is: Should this process be handled at drier level or platform specific code can also handle this
kernel context is not lost during suspend, so I don't think you need to
do much apart from resuming your device properly
--
~Vinod
^ permalink raw reply
* [PATCH] dma/imx-sdma+imx-dma: explicitly #include <linux/module.h>
From: Vinod Koul @ 2011-09-28 3:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E824821.8040105@windriver.com>
On Tue, 2011-09-27 at 18:03 -0400, Paul Gortmaker wrote:
> On 11-09-26 02:26 AM, Uwe Kleine-K?nig wrote:
> > This is needed after commit
> >
> > include: replace linux/module.h with "struct module" wherever possible
> >
> > (currently 25215aa in next).
> >
> > Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Acked-by Vinod Koul <vinod.koul@intel.com>
> > ---
> > Hello,
> >
> > maybe it's sensible for Paul to take that before his commit?
>
> Thanks, I'll blend it into the commit adding module.h to the other
> drivers/dma files. It seems the imx boards don't have a defconfig
> in the arch/arm/configs that enables this (CONFIG_IMX_[S]DMA).
You can find imx_v4_v5_defconfig in linux-next tree.
>
> What is really interesting (at least to me anyway) is that I
> didn't get one iMX build in some 6000+ ARM randconfig builds....
>
> I would have thought it would have showed up at least a couple
> times, given that number of builds. Maybe randconfig doesn't
> deal so well with "choice" Kconfig items?
>
> ~/git/module.h/linux-2.6.git$ ls -1 ../build-10*arm |wc -l
> 6399
> ~/git/module.h/linux-2.6.git$ grep CONFIG_ARCH_[A-Z0-9]*=y ../build-10*arm*/.config | sed 's/.*CON/CON/'|sort |uniq
> CONFIG_ARCH_EBSA110=y
> CONFIG_ARCH_H7201=y
> CONFIG_ARCH_H7202=y
> CONFIG_ARCH_H720X=y
> CONFIG_ARCH_VERSATILE=y
> ~/git/module.h/linux-2.6.git$
>
> No ARCH_MXC, no ARCH_MXS, PXA, or any of the other 20+ variants.
> Definitely not a random spread there, with all 6000 builds falling
> in just 5 buckets.
>
> Paul.
>
>
> >
> > Best regards
> > Uwe
> >
> > drivers/dma/imx-dma.c | 1 +
> > drivers/dma/imx-sdma.c | 1 +
> > 2 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
> > index d99f71c..3732de8 100644
> > --- a/drivers/dma/imx-dma.c
> > +++ b/drivers/dma/imx-dma.c
> > @@ -23,6 +23,7 @@
> > #include <linux/slab.h>
> > #include <linux/platform_device.h>
> > #include <linux/dmaengine.h>
> > +#include <linux/module.h>
> >
> > #include <asm/irq.h>
> > #include <mach/dma-v1.h>
> > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> > index b5cc27d..86fb6e5 100644
> > --- a/drivers/dma/imx-sdma.c
> > +++ b/drivers/dma/imx-sdma.c
> > @@ -34,6 +34,7 @@
> > #include <linux/dmaengine.h>
> > #include <linux/of.h>
> > #include <linux/of_device.h>
> > +#include <linux/module.h>
> >
> > #include <asm/irq.h>
> > #include <mach/sdma.h>
--
~Vinod
^ permalink raw reply
* [PATCH 0/4] arm/tegra: Convert gpio & pinmux to platform devices
From: Stephen Warren @ 2011-09-28 3:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109231848.52318.arnd@arndb.de>
Arnd Bergmann wrote at Friday, September 23, 2011 10:49 AM:
> On Thursday 22 September 2011, Stephen Warren wrote:
> >
> > This series converts the Tegra GPIO and pinmux drivers to be regular
> > platform devices.
>
> Looks good overall.
Thanks.
> > The series is extracted from an earlier series I posted that augmented
> > these drivers to initialize HW state from the device-tree. I'm holding
> > off on that aspect of the changes, since it's not entirely clear to me
> > whether the new pinmux API should drive the initial pinmux state setup
> > via "system hog" definitions, or whether pinmux drivers should indeed
> > do their own thing.
>
> I think at least you should try to do an ioremap of the pinmux register
> area in the pinmux probe function and make sure that it's called early
> enough, if at all possible.
>
> Right now, there is an empty probe() function, which is a bit silly,
> and the pg_readl()/pg_writel() functions use hardcoded register
> addresses.
For GPIO, calling ioremap() should be pretty easy.
For pinmux, there are complications: The pinmux HW doesn't have a dedicated
address range, but rather the registers are somewhat scattered in groups
throughout the "APB_MISC" address range. APB_MISC also includes strapping,
JTAG configuration, and USB PHY registers, all of which exist between the
various groups of pinmux registers. On Tegra30, there's slightly less of
this, yet in turn this means that the number of chunks of address space used
by the pinmux module differs from Tegra20.
Right now, the pinmux driver data tables (which define the set of pin groups
known to the pinmux driver) all store register addresses as offsets from the
base of this APB_MISC region for simplicity.
What are your thoughts here; should I go ahead and update the pinmux driver
to ioremap() each of these chunks individually, and update the data tables
to be a tuple (chunk ID, offset_from_chunk), or leave things as is?
Thanks.
--
nvpublic
^ permalink raw reply
* [PATCH 2/7] ARM: SAMSUNG: Add CLK Macro for clkdev support
From: padma venkat @ 2011-09-28 4:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110923202606.GT17169@n2100.arm.linux.org.uk>
Hi Russell,
On Sat, Sep 24, 2011 at 1:56 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>
> On Fri, Sep 23, 2011 at 05:23:42PM +0530, Padmavathi Venna wrote:
> > diff --git a/arch/arm/plat-samsung/include/plat/clock.h b/arch/arm/plat-samsung/include/plat/clock.h
> > index 73c66d4..c864825 100644
> > --- a/arch/arm/plat-samsung/include/plat/clock.h
> > +++ b/arch/arm/plat-samsung/include/plat/clock.h
> > @@ -17,6 +17,13 @@
> >
> > ?struct clk;
> >
> > +#define CLK(dev, con, ck) ? ?\
> > + ? ? { ? ? ? ? ? ? ? ? ? ? ? \
> > + ? ? ? ? ? ? .dev_id = dev, ?\
> > + ? ? ? ? ? ? .con_id = con, ?\
> > + ? ? ? ? ? ? .clk = ck, ? ? ?\
> > + ? ? }
> > +
>
> How about a patch series which moves this to include/linux/clkdev.h,
> preferably called CLKDEV_INIT() ?
>
Thanks for the review. I am currently working on preparing the patch series
as per your suggestion.
> There's versions of this already in:
> arch/arm/mach-ux500/clock.h
> arch/arm/mach-tegra/tegra2_clocks.c
> arch/arm/mach-nomadik/clock.c
> arch/arm/mach-davinci/clock.h
>
> so let's have it standardized instead of everyone inventing their own.
>
> (Remember, that's what we're supposed to already being looking out for
> since Linus' whinge about how ARM stuff tends to grow out of control...)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
Best Regards
Padma
^ permalink raw reply
* [PATCH v4 0/2] Add device tree support for Samsung's keypad controller driver
From: Thomas Abraham @ 2011-09-28 5:15 UTC (permalink / raw)
To: linux-arm-kernel
Changes since v3:
- Addressed comments from Grant Likely.
- Set num_rows and num_cols to zero in samsung_keypad_parse_dt function.
- Fixed the wierd looking if-else block in samsung_keypad_probe function.
Changes since v2:
- Addressed comments from Grant Likely.
- Renamed 'keypad,key-code' property name to 'linux,code'.
- Fixed incorrect data types for all instances of of_property+read_u32.
- linux,input-type binding was not added as suggested since the driver
supports only EV_KEY event type.
Changes since v1:
- Addressed comments from Dmitry Torokhov.
- Type of controller is cached in driver's private data and the function
that determines the type of the controller for each keypad scan is
removed.
- pdata allocated during probe is explicitly freed after probe completes
without any error. In case of exit from probe due a error, no explicit
deallocation of pdata memory is performed and it is left to devres to
handle that.
- The generic code to translate KEY(x,y,code) is retained in the driver
itself. I am unsure of a right common place for it.
- Driver continues with the probe even if one or more gpio configuration
fails.
- Patch 1 that adds a new config option is still retained in this patchset.
This patchset adds device tree support for samsung's keypad controller driver.
First patch adds a new config option to be used by device tree enabled platforms
for selecting the samsung's keypad controller driver. The second patch adds device
tree support for the keypad driver.
Thomas Abraham (2):
input: samsung-keypad: Add HAVE_SAMSUNG_KEYPAD config option
input: samsung-keypad: Add device tree support
.../devicetree/bindings/input/samsung-keypad.txt | 88 ++++++++++
drivers/input/keyboard/Kconfig | 9 +-
drivers/input/keyboard/samsung-keypad.c | 174 ++++++++++++++++++--
3 files changed, 258 insertions(+), 13 deletions(-)
^ permalink raw reply
* [PATCH v4 1/2] input: samsung-keypad: Add HAVE_SAMSUNG_KEYPAD config option
From: Thomas Abraham @ 2011-09-28 5:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317186926-17822-1-git-send-email-thomas.abraham@linaro.org>
For platforms using device tree, the static keypad device instances
are not required and SAMSUNG_DEV_KEYPAD is not selected. Since,
samsung keypad driver has dependency on SAMSUNG_DEV_KEYPAD config
option, the driver is left out of the compilation for dt enabled
platforms.
An additional config option 'HAVE_SAMSUNG_KEYPAD' is added
which the device tree based platforms can select. This config
option is added as an alternative dependency for keypad driver.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
drivers/input/keyboard/Kconfig | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index b4dee9d..7c322a3 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -423,9 +423,16 @@ config KEYBOARD_PMIC8XXX
To compile this driver as a module, choose M here: the module will
be called pmic8xxx-keypad.
+config HAVE_SAMSUNG_KEYPAD
+ bool
+ help
+ This will include Samsung Keypad controller driver support. If you
+ want to include Samsung Keypad support for any machine, kindly
+ select this in the respective mach-xxxx/Kconfig file.
+
config KEYBOARD_SAMSUNG
tristate "Samsung keypad support"
- depends on SAMSUNG_DEV_KEYPAD
+ depends on SAMSUNG_DEV_KEYPAD || HAVE_SAMSUNG_KEYPAD
help
Say Y here if you want to use the Samsung keypad.
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH v4 2/2] input: samsung-keypad: Add device tree support
From: Thomas Abraham @ 2011-09-28 5:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317186926-17822-1-git-send-email-thomas.abraham@linaro.org>
Add device tree based discovery support for Samsung's keypad controller.
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
.../devicetree/bindings/input/samsung-keypad.txt | 88 ++++++++++
drivers/input/keyboard/samsung-keypad.c | 174 ++++++++++++++++++--
2 files changed, 250 insertions(+), 12 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/samsung-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt b/Documentation/devicetree/bindings/input/samsung-keypad.txt
new file mode 100644
index 0000000..ce3e394
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt
@@ -0,0 +1,88 @@
+* Samsung's Keypad Controller device tree bindings
+
+Samsung's Keypad controller is used to interface a SoC with a matrix-type
+keypad device. The keypad controller supports multiple row and column lines.
+A key can be placed at each intersection of a unique row and a unique column.
+The keypad controller can sense a key-press and key-release and report the
+event using a interrupt to the cpu.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - "samsung,s3c6410-keypad": For controllers compatible with s3c6410 keypad
+ controller.
+ - "samsung,s5pv210-keypad": For controllers compatible with s5pv210 keypad
+ controller.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- interrupts: The interrupt number to the cpu.
+
+Required Board Specific Properties:
+- samsung,keypad-num-rows: Number of row lines connected to the keypad
+ controller.
+
+- samsung,keypad-num-columns: Number of column lines connected to the
+ keypad controller.
+
+- row-gpios: List of gpios used as row lines. The gpio specifier for
+ this property depends on the gpio controller to which these row lines
+ are connected.
+
+- col-gpios: List of gpios used as column lines. The gpio specifier for
+ this property depends on the gpio controller to which these column
+ lines are connected.
+
+- Keys represented as child nodes: Each key connected to the keypad
+ controller is represented as a child node to the keypad controller
+ device node and should include the following properties.
+ - keypad,row: the row number to which the key is connected.
+ - keypad,column: the column number to which the key is connected.
+ - linux,code: the key-code to be reported when the key is pressed
+ and released.
+
+Optional Properties specific to linux:
+- linux,keypad-no-autorepeat: do no enable autorepeat feature.
+- linux,keypad-wakeup: use any event on keypad as wakeup event.
+
+
+Example:
+ keypad at 100A0000 {
+ compatible = "samsung,s5pv210-keypad";
+ reg = <0x100A0000 0x100>;
+ interrupts = <173>;
+ samsung,keypad-num-rows = <2>;
+ samsung,keypad-num-columns = <8>;
+ linux,input-no-autorepeat;
+ linux,input-wakeup;
+
+ row-gpios = <&gpx2 0 3 3 0
+ &gpx2 1 3 3 0>;
+
+ col-gpios = <&gpx1 0 3 0 0
+ &gpx1 1 3 0 0
+ &gpx1 2 3 0 0
+ &gpx1 3 3 0 0
+ &gpx1 4 3 0 0
+ &gpx1 5 3 0 0
+ &gpx1 6 3 0 0
+ &gpx1 7 3 0 0>;
+
+ key_1 {
+ keypad,row = <0>;
+ keypad,column = <3>;
+ linux,code = <2>;
+ };
+
+ key_2 {
+ keypad,row = <0>;
+ keypad,column = <4>;
+ linux,code = <3>;
+ };
+
+ key_3 {
+ keypad,row = <0>;
+ keypad,column = <5>;
+ linux,code = <4>;
+ };
+ };
diff --git a/drivers/input/keyboard/samsung-keypad.c b/drivers/input/keyboard/samsung-keypad.c
index f689f49..ded9f4f 100644
--- a/drivers/input/keyboard/samsung-keypad.c
+++ b/drivers/input/keyboard/samsung-keypad.c
@@ -21,6 +21,8 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/sched.h>
#include <plat/keypad.h>
@@ -68,31 +70,26 @@ struct samsung_keypad {
wait_queue_head_t wait;
bool stopped;
int irq;
+ enum samsung_keypad_type type;
unsigned int row_shift;
unsigned int rows;
unsigned int cols;
unsigned int row_state[SAMSUNG_MAX_COLS];
+#ifdef CONFIG_OF
+ int row_gpios[SAMSUNG_MAX_ROWS];
+ int col_gpios[SAMSUNG_MAX_COLS];
+#endif
unsigned short keycodes[];
};
-static int samsung_keypad_is_s5pv210(struct device *dev)
-{
- struct platform_device *pdev = to_platform_device(dev);
- enum samsung_keypad_type type =
- platform_get_device_id(pdev)->driver_data;
-
- return type == KEYPAD_TYPE_S5PV210;
-}
-
static void samsung_keypad_scan(struct samsung_keypad *keypad,
unsigned int *row_state)
{
- struct device *dev = keypad->input_dev->dev.parent;
unsigned int col;
unsigned int val;
for (col = 0; col < keypad->cols; col++) {
- if (samsung_keypad_is_s5pv210(dev)) {
+ if (keypad->type == KEYPAD_TYPE_S5PV210) {
val = S5PV210_KEYIFCOLEN_MASK;
val &= ~(1 << col) << 8;
} else {
@@ -235,6 +232,126 @@ static void samsung_keypad_close(struct input_dev *input_dev)
samsung_keypad_stop(keypad);
}
+#ifdef CONFIG_OF
+static struct samsung_keypad_platdata *samsung_keypad_parse_dt(
+ struct device *dev)
+{
+ struct samsung_keypad_platdata *pdata;
+ struct matrix_keymap_data *keymap_data;
+ uint32_t *keymap, num_rows = 0, num_cols = 0;
+ struct device_node *np = dev->of_node, *key_np;
+ unsigned int key_count = 0;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(dev, "could not allocate memory for platform data\n");
+ return NULL;
+ }
+
+ of_property_read_u32(np, "samsung,keypad-num-rows", &num_rows);
+ of_property_read_u32(np, "samsung,keypad-num-columns", &num_cols);
+ if (!num_rows || !num_cols) {
+ dev_err(dev, "number of keypad rows/columns not specified\n");
+ return NULL;
+ }
+ pdata->rows = num_rows;
+ pdata->cols = num_cols;
+
+ keymap_data = devm_kzalloc(dev, sizeof(*keymap_data), GFP_KERNEL);
+ if (!keymap_data) {
+ dev_err(dev, "could not allocate memory for keymap data\n");
+ return NULL;
+ }
+ pdata->keymap_data = keymap_data;
+
+ for_each_child_of_node(np, key_np)
+ key_count++;
+
+ keymap_data->keymap_size = key_count;
+ keymap = devm_kzalloc(dev, sizeof(uint32_t) * key_count, GFP_KERNEL);
+ if (!keymap) {
+ dev_err(dev, "could not allocate memory for keymap\n");
+ return NULL;
+ }
+ keymap_data->keymap = keymap;
+
+ for_each_child_of_node(np, key_np) {
+ u32 row, col, key_code;
+ of_property_read_u32(key_np, "keypad,row", &row);
+ of_property_read_u32(key_np, "keypad,column", &col);
+ of_property_read_u32(key_np, "linux,code", &key_code);
+ *keymap++ = KEY(row, col, key_code);
+ }
+
+ if (of_get_property(np, "linux,input-no-autorepeat", NULL))
+ pdata->no_autorepeat = true;
+ if (of_get_property(np, "linux,input-wakeup", NULL))
+ pdata->wakeup = true;
+
+ return pdata;
+}
+
+static void samsung_keypad_parse_dt_gpio(struct device *dev,
+ struct samsung_keypad *keypad)
+{
+ struct device_node *np = dev->of_node;
+ int gpio, ret, row, col;
+
+ for (row = 0; row < keypad->rows; row++) {
+ gpio = of_get_named_gpio(np, "row-gpios", row);
+ keypad->row_gpios[row] = gpio;
+ if (!gpio_is_valid(gpio)) {
+ dev_err(dev, "keypad row[%d]: invalid gpio %d\n",
+ row, gpio);
+ continue;
+ }
+
+ ret = gpio_request(gpio, "keypad-row");
+ if (ret)
+ dev_err(dev, "keypad row[%d] gpio request failed\n",
+ row);
+ }
+
+ for (col = 0; col < keypad->cols; col++) {
+ gpio = of_get_named_gpio(np, "col-gpios", col);
+ keypad->col_gpios[col] = gpio;
+ if (!gpio_is_valid(gpio)) {
+ dev_err(dev, "keypad column[%d]: invalid gpio %d\n",
+ col, gpio);
+ continue;
+ }
+
+ ret = gpio_request(col, "keypad-col");
+ if (ret)
+ dev_err(dev, "keypad column[%d] gpio request failed\n",
+ col);
+ }
+}
+
+static void samsung_keypad_dt_gpio_free(struct samsung_keypad *keypad)
+{
+ int cnt;
+
+ for (cnt = 0; cnt < keypad->rows; cnt++)
+ if (gpio_is_valid(keypad->row_gpios[cnt]))
+ gpio_free(keypad->row_gpios[cnt]);
+
+ for (cnt = 0; cnt < keypad->cols; cnt++)
+ if (gpio_is_valid(keypad->col_gpios[cnt]))
+ gpio_free(keypad->col_gpios[cnt]);
+}
+#else
+static
+struct samsung_keypad_platdata *samsung_keypad_parse_dt(struct device *dev)
+{
+ return NULL;
+}
+
+static void samsung_keypad_dt_gpio_free(struct samsung_keypad *keypad)
+{
+}
+#endif
+
static int __devinit samsung_keypad_probe(struct platform_device *pdev)
{
const struct samsung_keypad_platdata *pdata;
@@ -246,7 +363,10 @@ static int __devinit samsung_keypad_probe(struct platform_device *pdev)
unsigned int keymap_size;
int error;
- pdata = pdev->dev.platform_data;
+ if (pdev->dev.of_node)
+ pdata = samsung_keypad_parse_dt(&pdev->dev);
+ else
+ pdata = pdev->dev.platform_data;
if (!pdata) {
dev_err(&pdev->dev, "no platform data defined\n");
return -EINVAL;
@@ -303,6 +423,16 @@ static int __devinit samsung_keypad_probe(struct platform_device *pdev)
keypad->cols = pdata->cols;
init_waitqueue_head(&keypad->wait);
+ if (pdev->dev.of_node) {
+#ifdef CONFIG_OF
+ samsung_keypad_parse_dt_gpio(&pdev->dev, keypad);
+ keypad->type = of_device_is_compatible(pdev->dev.of_node,
+ "samsung,s5pv210-keypad");
+#endif
+ } else {
+ keypad->type = platform_get_device_id(pdev)->driver_data;
+ }
+
input_dev->name = pdev->name;
input_dev->id.bustype = BUS_HOST;
input_dev->dev.parent = &pdev->dev;
@@ -343,12 +473,19 @@ static int __devinit samsung_keypad_probe(struct platform_device *pdev)
device_init_wakeup(&pdev->dev, pdata->wakeup);
platform_set_drvdata(pdev, keypad);
+
+ if (pdev->dev.of_node) {
+ devm_kfree(&pdev->dev, (void *)pdata->keymap_data->keymap);
+ devm_kfree(&pdev->dev, (void *)pdata->keymap_data);
+ devm_kfree(&pdev->dev, (void *)pdata);
+ }
return 0;
err_free_irq:
free_irq(keypad->irq, keypad);
err_put_clk:
clk_put(keypad->clk);
+ samsung_keypad_dt_gpio_free(keypad);
err_unmap_base:
iounmap(keypad->base);
err_free_mem:
@@ -374,6 +511,7 @@ static int __devexit samsung_keypad_remove(struct platform_device *pdev)
free_irq(keypad->irq, keypad);
clk_put(keypad->clk);
+ samsung_keypad_dt_gpio_free(keypad);
iounmap(keypad->base);
kfree(keypad);
@@ -447,6 +585,17 @@ static const struct dev_pm_ops samsung_keypad_pm_ops = {
};
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id samsung_keypad_dt_match[] = {
+ { .compatible = "samsung,s3c6410-keypad" },
+ { .compatible = "samsung,s5pv210-keypad" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, samsung_keypad_dt_match);
+#else
+#define samsung_keypad_dt_match NULL
+#endif
+
static struct platform_device_id samsung_keypad_driver_ids[] = {
{
.name = "samsung-keypad",
@@ -465,6 +614,7 @@ static struct platform_driver samsung_keypad_driver = {
.driver = {
.name = "samsung-keypad",
.owner = THIS_MODULE,
+ .of_match_table = samsung_keypad_dt_match,
#ifdef CONFIG_PM
.pm = &samsung_keypad_pm_ops,
#endif
--
1.6.6.rc2
^ permalink raw reply related
* [PATCH 0/4] mmc: mmci: Improvements and bugfixes for SDIO
From: Linus Walleij @ 2011-09-28 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317109517-17869-1-git-send-email-ulf.hansson@stericsson.com>
On Tue, Sep 27, 2011 at 9:45 AM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> This patchserie fixes a couple of SDIO related issues for the mmci host
> driver. The intention is to keep each patch small and to have one patch
> for one problem. It might makes sence to squash some of the patches, but
> I leave this for discussion.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
For this patch series, nice small steps!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/3] mmc: mmci: Put power register deviations in variant data
From: Linus Walleij @ 2011-09-28 5:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317123725-29832-1-git-send-email-ulf.hansson@stericsson.com>
On Tue, Sep 27, 2011 at 1:42 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 4da20ec..32de82b 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -53,6 +53,7 @@ static unsigned int fmax = 515633;
> ?* @st_clkdiv: true if using a ST-specific clock divider algorithm
> ?* @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl register
> ?* @non_power_of_2_blksize: true if block sizes can be other than power of two
> + * @pwrreg_powerup: power up value for MMCIPOWER register
> ?*/
> ?struct variant_data {
> ? ? ? ?unsigned int ? ? ? ? ? ?clkreg;
> @@ -64,18 +65,21 @@ struct variant_data {
> ? ? ? ?bool ? ? ? ? ? ? ? ? ? ?st_clkdiv;
> ? ? ? ?bool ? ? ? ? ? ? ? ? ? ?blksz_datactrl16;
> ? ? ? ?bool ? ? ? ? ? ? ? ? ? ?non_power_of_2_blksize;
> + ? ? ? unsigned int ? ? ? ? ? ?pwrreg_powerup;
This should probably be u32, no big deal but easy to fix.
Can be done when putting it into Russells patch tracker I guess.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/3] mmc: mmci: Provide option to configure bus signal direction
From: Linus Walleij @ 2011-09-28 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317123738-29867-1-git-send-email-ulf.hansson@stericsson.com>
On Tue, Sep 27, 2011 at 1:42 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> @@ -30,6 +43,8 @@ struct dma_chan;
> ?* @cd_invert: true if the gpio_cd pin value is active low
> ?* @capabilities: the capabilities of the block as implemented in
> ?* this platform, signify anything MMC_CAP_* from mmc/host.h
> + * @sigdir: a bit field indicating for what bits in the MMC bus the host
> + * should enable signal direction indication.
> ?* @dma_filter: function used to select an appropriate RX and TX
> ?* DMA channel to be used for DMA, if and only if you're deploying the
> ?* generic DMA engine
> @@ -52,6 +67,7 @@ struct mmci_platform_data {
> ? ? ? ?int ? ? gpio_cd;
> ? ? ? ?bool ? ?cd_invert;
> ? ? ? ?unsigned long capabilities;
> + ? ? ? unsigned int sigdir;
u32 again, no big deal. Can be fixed when submitting it to the patch tracker.
Acked-by.
Yours,
Linus Walleij
^ permalink raw reply
* CODEC support for s3c2440
From: GIGIN JOSE @ 2011-09-28 5:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I am using s3c2440 with linux 2.6.30. The camera driver for s3c2440
currently supports preview mode. Should I enable my camera to RGB
configuration to interface with the processor ?
The camera device also gives YCbCr output.How can I configure
the processor to see the YCbCr output from the camera ? Is it
necessary that I should enable the codec mode of the s3c2440
camera controller to get the YCbCr output.
What is the advantage of using codec path of the camera
controller with respect to the preview path ?
Thank You
^ permalink raw reply
* [PATCH 3/3] mmc: mmci: Change vdd_handler to a generic ios_handler
From: Linus Walleij @ 2011-09-28 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317123753-29902-1-git-send-email-ulf.hansson@stericsson.com>
On Tue, Sep 27, 2011 at 1:42 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> The purpose of the vdd_handler does not make sense. We remove it
> and use a generic approach instead. A new ios_handler is added, the
> purpose of which e.g. can be to control GPIO pins to a levelshifter.
>
> Previously the vdd_handler was also used for making additional
> changes to the power register bits. This option is superfluous and is
> therefore removed.
>
> Adaptaptions from the old vdd_handler to the new ios_handler is done for
> mach-ux500 board, which was the only one using the vdd_handler.
I've tried to undestand (by reading the data sheets I have) what the
purpose of the original 4 power bits handled by the mechanism that
nobody really use is, and I'm still lost.
I'm guessing it was some feature intended to control e.g. a
regulator of some kind by routing them off-chip (since mixed-signal
chips rarely have MMC controllers inside...) and most designers
already have their own regulator designs so it made no sense
for anyone to actually implement it that way.
If some vendor would actually start using these bits for the
intended purpose I guess we could adapt. (The pirate driver
msm_sdcc.c does not seem to use these bits either BTW.)
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2 0/1] dmaengine/amba-pl08x: Add support for s3c64xx DMAC
From: Alim Akhtar @ 2011-09-28 5:50 UTC (permalink / raw)
To: linux-arm-kernel
This patch modifies the amba-pl08x driver for s3c64xx.
The DMA controller of S3C64XX is a variant of PrimeCell pl080 DMAC.
S3C64xx contents extra register to hold the TransferSize.
Below diagram explains the s3c64xx LLI structure and offsets.
-----------------------------------------------------------------
| Offset | Contents |
-----------------------------------------------------------------
| Next LLI Address | Source Address for Next xfer |
-----------------------------------------------------------------
| Next LLI Address+0x04 | Destination Address for Next xfer |
-----------------------------------------------------------------
| Next LLI Address+0x08 | Next LLI address for Next xfer |
-----------------------------------------------------------------
| Next LLI Address+0x0c | DMACCxControl0 data for Next xfer |
-----------------------------------------------------------------
| Next LLI Address+0x10 | DMACCxControl1 xfer size for Next xfer|
-----------------------------------------------------------------
Changes since v1:
- Rebased with "samsung_dma" branch of
http://git.infradead.org/users/vkoul/slave-dma.git
- Addressed review comments from linus.walleij
http://www.spinics.net/lists/arm-kernel/msg135411.html
Alim Akhtar (1):
dmaengine/amba-pl08x: Add support for s3c64xx DMAC
drivers/dma/amba-pl08x.c | 135 ++++++++++++++++++++++++++++++++++++++--------
1 files changed, 112 insertions(+), 23 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH V2 1/1] dmaengine/amba-pl08x: Add support for s3c64xx DMAC
From: Alim Akhtar @ 2011-09-28 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317189007-23033-1-git-send-email-alim.akhtar@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
drivers/dma/amba-pl08x.c | 135 ++++++++++++++++++++++++++++++++++++++--------
1 files changed, 112 insertions(+), 23 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index cd8df7f..501540f 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -66,8 +66,25 @@
* after the final transfer signalled by LBREQ or LSREQ. The DMAC
* will then move to the next LLI entry.
*
- * Global TODO:
- * - Break out common code from arch/arm/mach-s3c64xx and share
+ * Samsung S3C64xx SoCs uses a variant of PL080 DMAC. It contains an extra
+ * control register to hold the TransferSize. Below is the LLI structure
+ * and offsets of S3C64xx DMAC.
+ * -----------------------------------------------------------------
+ * | Offset | Contents |
+ * -----------------------------------------------------------------
+ * | Next LLI Address | Source Address for Next xfer |
+ * -----------------------------------------------------------------
+ * | Next LLI Address+0x04 | Destination Address for Next xfer |
+ * -----------------------------------------------------------------
+ * | Next LLI Address+0x08 | Next LLI address for next xfer |
+ * -----------------------------------------------------------------
+ * | Next LLI Address+0x0c | DMACCxControl0 data for next xfer |
+ * -----------------------------------------------------------------
+ * | Next LLI Address+0x10 | DMACCxControl1 xfer size for next xfer|
+ * -----------------------------------------------------------------
+ * Also S3C64XX has a config register at offset 0x14
+ * Have a look at arch/arm/include/asm/hardware/pl080.h for complete register
+ * details.
*/
#include <linux/amba/bus.h>
#include <linux/amba/pl08x.h>
@@ -97,6 +114,8 @@ static struct amba_driver pl08x_amba_driver;
struct vendor_data {
u8 channels;
bool dualmaster;
+ /* To identify samsung DMAC */
+ bool is_pl080_s3c;
};
/*
@@ -110,6 +129,11 @@ struct pl08x_lli {
u32 dst;
u32 lli;
u32 cctl;
+ /*
+ * Samsung pl080 DMAC has one exrta control register
+ * which is used to hold the transfer_size
+ */
+ u32 cctl1;
};
/**
@@ -171,9 +195,20 @@ static inline struct pl08x_txd *to_pl08x_txd(struct dma_async_tx_descriptor *tx)
/* Whether a certain channel is busy or not */
static int pl08x_phy_channel_busy(struct pl08x_phy_chan *ch)
{
+ struct pl08x_dma_chan *plchan = ch->serving;
+ struct pl08x_driver_data *pl08x;
unsigned int val;
- val = readl(ch->base + PL080_CH_CONFIG);
+ if (plchan == NULL)
+ return false;
+
+ pl08x = plchan->host;
+
+ if (pl08x->vd->is_pl080_s3c)
+ val = readl(ch->base + PL080S_CH_CONFIG);
+ else
+ val = readl(ch->base + PL080_CH_CONFIG);
+
return val & PL080_CONFIG_ACTIVE;
}
@@ -207,7 +242,12 @@ static void pl08x_start_txd(struct pl08x_dma_chan *plchan,
writel(lli->dst, phychan->base + PL080_CH_DST_ADDR);
writel(lli->lli, phychan->base + PL080_CH_LLI);
writel(lli->cctl, phychan->base + PL080_CH_CONTROL);
- writel(txd->ccfg, phychan->base + PL080_CH_CONFIG);
+
+ if (pl08x->vd->is_pl080_s3c) {
+ writel(txd->ccfg, phychan->base + PL080S_CH_CONFIG);
+ writel(lli->cctl1, phychan->base + PL080S_CH_CONTROL2);
+ } else
+ writel(txd->ccfg, phychan->base + PL080_CH_CONFIG);
/* Enable the DMA channel */
/* Do not access config register until channel shows as disabled */
@@ -215,11 +255,23 @@ static void pl08x_start_txd(struct pl08x_dma_chan *plchan,
cpu_relax();
/* Do not access config register until channel shows as inactive */
- val = readl(phychan->base + PL080_CH_CONFIG);
- while ((val & PL080_CONFIG_ACTIVE) || (val & PL080_CONFIG_ENABLE))
+ if (pl08x->vd->is_pl080_s3c) {
+ val = readl(phychan->base + PL080S_CH_CONFIG);
+ while ((val & PL080_CONFIG_ACTIVE) ||
+ (val & PL080_CONFIG_ENABLE))
+ val = readl(phychan->base + PL080S_CH_CONFIG);
+
+ writel(val | PL080_CONFIG_ENABLE,
+ phychan->base + PL080S_CH_CONFIG);
+ } else {
val = readl(phychan->base + PL080_CH_CONFIG);
+ while ((val & PL080_CONFIG_ACTIVE) ||
+ (val & PL080_CONFIG_ENABLE))
+ val = readl(phychan->base + PL080_CH_CONFIG);
- writel(val | PL080_CONFIG_ENABLE, phychan->base + PL080_CH_CONFIG);
+ writel(val | PL080_CONFIG_ENABLE,
+ phychan->base + PL080_CH_CONFIG);
+ }
}
/*
@@ -236,12 +288,19 @@ static void pl08x_pause_phy_chan(struct pl08x_phy_chan *ch)
{
u32 val;
int timeout;
+ struct pl08x_dma_chan *plchan = ch->serving;
+ struct pl08x_driver_data *pl08x = plchan->host;
/* Set the HALT bit and wait for the FIFO to drain */
- val = readl(ch->base + PL080_CH_CONFIG);
- val |= PL080_CONFIG_HALT;
- writel(val, ch->base + PL080_CH_CONFIG);
-
+ if (pl08x->vd->is_pl080_s3c) {
+ val = readl(ch->base + PL080S_CH_CONFIG);
+ val |= PL080_CONFIG_HALT;
+ writel(val, ch->base + PL080S_CH_CONFIG);
+ } else {
+ val = readl(ch->base + PL080_CH_CONFIG);
+ val |= PL080_CONFIG_HALT;
+ writel(val, ch->base + PL080_CH_CONFIG);
+ }
/* Wait for channel inactive */
for (timeout = 1000; timeout; timeout--) {
if (!pl08x_phy_channel_busy(ch))
@@ -255,11 +314,19 @@ static void pl08x_pause_phy_chan(struct pl08x_phy_chan *ch)
static void pl08x_resume_phy_chan(struct pl08x_phy_chan *ch)
{
u32 val;
+ struct pl08x_dma_chan *plchan = ch->serving;
+ struct pl08x_driver_data *pl08x = plchan->host;
/* Clear the HALT bit */
- val = readl(ch->base + PL080_CH_CONFIG);
- val &= ~PL080_CONFIG_HALT;
- writel(val, ch->base + PL080_CH_CONFIG);
+ if (pl08x->vd->is_pl080_s3c) {
+ val = readl(ch->base + PL080S_CH_CONFIG);
+ val &= ~PL080_CONFIG_HALT;
+ writel(val, ch->base + PL080S_CH_CONFIG);
+ } else {
+ val = readl(ch->base + PL080_CH_CONFIG);
+ val &= ~PL080_CONFIG_HALT;
+ writel(val, ch->base + PL080_CH_CONFIG);
+ }
}
/*
@@ -271,12 +338,17 @@ static void pl08x_resume_phy_chan(struct pl08x_phy_chan *ch)
static void pl08x_terminate_phy_chan(struct pl08x_driver_data *pl08x,
struct pl08x_phy_chan *ch)
{
- u32 val = readl(ch->base + PL080_CH_CONFIG);
-
- val &= ~(PL080_CONFIG_ENABLE | PL080_CONFIG_ERR_IRQ_MASK |
- PL080_CONFIG_TC_IRQ_MASK);
-
- writel(val, ch->base + PL080_CH_CONFIG);
+ if (pl08x->vd->is_pl080_s3c) {
+ u32 val = readl(ch->base + PL080S_CH_CONFIG);
+ val &= ~(PL080_CONFIG_ENABLE | PL080_CONFIG_ERR_IRQ_MASK |
+ PL080_CONFIG_TC_IRQ_MASK);
+ writel(val, ch->base + PL080S_CH_CONFIG);
+ } else {
+ u32 val = readl(ch->base + PL080_CH_CONFIG);
+ val &= ~(PL080_CONFIG_ENABLE | PL080_CONFIG_ERR_IRQ_MASK |
+ PL080_CONFIG_TC_IRQ_MASK);
+ writel(val, ch->base + PL080_CH_CONFIG);
+ }
writel(1 << ch->id, pl08x->base + PL080_ERR_CLEAR);
writel(1 << ch->id, pl08x->base + PL080_TC_CLEAR);
@@ -569,6 +641,7 @@ static int pl08x_fill_llis_for_desc(struct pl08x_driver_data *pl08x,
u32 cctl, early_bytes = 0;
size_t max_bytes_per_lli, total_bytes = 0;
struct pl08x_lli *llis_va;
+ size_t lli_len = 0, target_len, tsize, odd_bytes;
txd->llis_va = dma_pool_alloc(pl08x->pool, GFP_NOWAIT, &txd->llis_bus);
if (!txd->llis_va) {
@@ -700,7 +773,7 @@ static int pl08x_fill_llis_for_desc(struct pl08x_driver_data *pl08x,
* width left
*/
while (bd.remainder > (mbus->buswidth - 1)) {
- size_t lli_len, tsize, width;
+ size_t width;
/*
* If enough left try to send max possible,
@@ -759,6 +832,9 @@ static int pl08x_fill_llis_for_desc(struct pl08x_driver_data *pl08x,
llis_va[num_llis - 1].lli = 0;
/* The final LLI element shall also fire an interrupt. */
llis_va[num_llis - 1].cctl |= PL080_CONTROL_TC_IRQ_EN;
+ /* Keep the TransferSize seperate to fill samsung specific register */
+ if (pl08x->vd->is_pl080_s3c)
+ llis_va[num_llis - 1].cctl1 |= lli_len;
#ifdef VERBOSE_DEBUG
{
@@ -771,8 +847,8 @@ static int pl08x_fill_llis_for_desc(struct pl08x_driver_data *pl08x,
dev_vdbg(&pl08x->adev->dev,
"%3d @%p: 0x%08x 0x%08x 0x%08x 0x%08x\n",
i, &llis_va[i], llis_va[i].src,
- llis_va[i].dst, llis_va[i].lli, llis_va[i].cctl
- );
+ llis_va[i].dst, llis_va[i].lli,
+ llis_va[i].cctl);
}
}
#endif
@@ -1979,6 +2055,12 @@ static struct vendor_data vendor_pl081 = {
.dualmaster = false,
};
+static struct vendor_data vendor_pl080_s3c = {
+ .channels = 8,
+ .dualmaster = true,
+ .is_pl080_s3c = true,
+};
+
static struct amba_id pl08x_ids[] = {
/* PL080 */
{
@@ -1998,6 +2080,13 @@ static struct amba_id pl08x_ids[] = {
.mask = 0x00ffffff,
.data = &vendor_pl080,
},
+ /* Samsung DMAC is PL080 variant*/
+ {
+ .id = 0x00041082,
+ .mask = 0x000fffff,
+ .data = &vendor_pl080_s3c,
+
+ },
{ 0, 0 },
};
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
From: Hiremath, Vaibhav @ 2011-09-28 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109272006.30130.laurent.pinchart@ideasonboard.com>
> -----Original Message-----
> From: Laurent Pinchart [mailto:laurent.pinchart at ideasonboard.com]
> Sent: Tuesday, September 27, 2011 11:36 PM
> To: Hiremath, Vaibhav
> Cc: Ravi, Deepthy; linux-media at vger.kernel.org; tony at atomide.com;
> linux at arm.linux.org.uk; linux-omap at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> mchehab at infradead.org; g.liakhovetski at gmx.de
> Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
>
> Hi Vaibhav,
>
> On Monday 19 September 2011 17:31:02 Hiremath, Vaibhav wrote:
> > On Friday, September 16, 2011 6:36 PM Laurent Pinchart wrote:
> > > On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
> > > > On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:
> > > > > On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
> > > > >> From: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > >>
> > > > >> In order to support TVP5146 (for that matter any video decoder),
> > > > >> it is important to support G/S/ENUM_STD ioctl on /dev/videoX
> > > > >> device node.
> > > > >
> > > > > Why so ? Shouldn't it be queried on the subdev output pad
> directly ?
> > > >
> > > > Because standard v4l2 application for analog devices will call these
> > > > std ioctls on the streaming device node. So it's done on /dev/video
> to
> > > > make the existing apllication work.
> > >
> > > Existing applications can't work with the OMAP3 ISP (and similar
> complex
> > > embedded devices) without userspace support anyway, either in the form
> of
> > > a GStreamer element or a libv4l plugin. I still believe that analog
> video
> > > standard operations should be added to the subdev pad operations and
> > > exposed through subdev device nodes, exactly as done with formats.
> >
> > I completely agree with your point that, existing application will not
> work
> > without setting links properly. But I believe the assumption here is,
> > media-controller should set the links (along with pad formants) and all
> > existing application should work as is. Isn't it?
>
> The media controller is an API used (among other things) to set the links.
> You
> still need to call it from userspace. That won't happen magically. The
> userspace component that sets up the links and configures the formats, be
> it a
> GStreamer element, a libv4l plugin, or something else, can as well setup
> the
> standard on the TVP5146 subdev.
>
Please look at from analog device point of view which is interfaced to ISP.
OMAP3 ISP => TVP5146 (video decoder)
As a user I would want to expect the standard to be supported on streaming device node, since all standard streaming applications (for analog devices/interfaces) does this.
Setting up the links and format is still something got added with MC framework, and I would consider it as a separate plug-in along with existing applications.
Why do I need to write/use two different streaming application one for MC compatible device and another for non-MC?
> > The way it is being done currently is, set the format at the pad level
> > which is same as analog standard resolution and use existing application
> > for streaming...
>
> At then end of the OMAP3 ISP pipeline video data has long lost its analog
> roots. I don't think standards make sense there.
>
I don't agree with you here, I think we made it clear when we started with MC development activity, we will not break existing standard applications. Media-controller will play a roll to setup the links, connecting the pads and stuff.
Thanks,
Vaibhav
> > I am ok, if we add s/g/enum_std api support at sub-dev level but this
> > should also be supported on streaming device node.
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* [PATCH v3 4/6] arm/imx6q: add smp and cpu hotplug support
From: Sascha Hauer @ 2011-09-28 6:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110927151546.GF17997@S2100-06.ap.freescale.net>
On Tue, Sep 27, 2011 at 11:15:47PM +0800, Shawn Guo wrote:
> >
> > I do not want to add mxc_cpu_type and cpu_is_mx6q() stuff, so I intend
> > to remove early_initcall there, and let imx31/35_soc_init() explicitly
> > calls mxc_init_l2x0().
> >
> I'm changing my mind (so quickly). It turns out we will fall into a
> number of other traps if we build imx6q with imx3 without mxc_cpu_type
> set up for imx6q, arch_idle(), __imx_ioremap(), etc. So for now, I
> want to add mxc_cpu_type for imx6q to cooperate with all these traps.
I'm fine with reducing the usage of cpu_is_* macros up to the point when
we don't need them anymore. But as you already found out, it's better to
do this seperately.
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
* [PATCH v2 1/2] S3C2443/S3C2416: Add adc registers
From: Heiko Stübner @ 2011-09-28 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201109182242.55394.heiko@sntech.de>
The adc blocks of the S3C2443 and S3C2416 define some
additional registers and bits.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes since v1: add spaces around <<
arch/arm/plat-samsung/include/plat/regs-adc.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/regs-adc.h b/arch/arm/plat-samsung/include/plat/regs-adc.h
index 035e8c3..7061210 100644
--- a/arch/arm/plat-samsung/include/plat/regs-adc.h
+++ b/arch/arm/plat-samsung/include/plat/regs-adc.h
@@ -20,6 +20,7 @@
#define S3C2410_ADCDAT0 S3C2410_ADCREG(0x0C)
#define S3C2410_ADCDAT1 S3C2410_ADCREG(0x10)
#define S3C64XX_ADCUPDN S3C2410_ADCREG(0x14)
+#define S3C2443_ADCMUX S3C2410_ADCREG(0x18)
#define S3C64XX_ADCCLRINT S3C2410_ADCREG(0x18)
#define S5P_ADCMUX S3C2410_ADCREG(0x1C)
#define S3C64XX_ADCCLRINTPNDNUP S3C2410_ADCREG(0x20)
@@ -33,6 +34,7 @@
#define S3C2410_ADCCON_PRSCVLMASK (0xFF<<6)
#define S3C2410_ADCCON_SELMUX(x) (((x)&0x7)<<3)
#define S3C2410_ADCCON_MUXMASK (0x7<<3)
+#define S3C2416_ADCCON_RESSEL (1 << 3)
#define S3C2410_ADCCON_STDBM (1<<2)
#define S3C2410_ADCCON_READ_START (1<<1)
#define S3C2410_ADCCON_ENABLE_START (1<<0)
@@ -40,6 +42,7 @@
/* ADCTSC Register Bits */
+#define S3C2443_ADCTSC_UD_SEN (1 << 8)
#define S3C2410_ADCTSC_YM_SEN (1<<7)
#define S3C2410_ADCTSC_YP_SEN (1<<6)
#define S3C2410_ADCTSC_XM_SEN (1<<5)
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 2/2] s3c-adc: describe features via quirk constants
From: Heiko Stübner @ 2011-09-28 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <005801cc785a$7e46a310$7ad3e930$%kim@samsung.com>
The adc blocks of S3C2410 through S5P have a multitude of
quirks, i.e. moved bits or whole new registers.
This patch tries to describe these individual features
through constants which can be used to describe an adc.
As SoCs sometimes share only some of these quirks defining
TYPE_ADCVx values for each one wouldn't scale well when
adding more variants.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes since v1: add spaces around <<
arch/arm/plat-samsung/adc.c | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/adc.c b/arch/arm/plat-samsung/adc.c
index ee8deef..4fc4deb 100644
--- a/arch/arm/plat-samsung/adc.c
+++ b/arch/arm/plat-samsung/adc.c
@@ -45,6 +45,35 @@ enum s3c_cpu_type {
TYPE_ADCV3, /* S5PV210, S5PC110, EXYNOS4210 */
};
+/*
+ * Resolution of the ADC - 10 or 12 bit
+ */
+#define S3C_ADC_QUIRK_10BIT 0
+#define S3C_ADC_QUIRK_12BIT (1 << 0)
+
+/*
+ * 12bit ADC can switch resolution between 10 bit and 12 bit
+ * ADCCON bit 03 for S3C2416
+ * ADCCON bit 16 for S3C64XX and up
+ */
+#define S3C_ADC_QUIRK_RESSEL03 (1 << 1)
+#define S3C_ADC_QUIRK_RESSEL16 (1 << 2)
+
+/*
+ * Input channel select can either be in
+ * - reg ADCCON, bit for S3C24XX and S3C64XX
+ * - reg base+0x18 for 2443/2416/2450
+ * - reg base+0x1C for S5P
+ */
+#define S3C_ADC_QUIRK_MUXADCCON (1 << 3)
+#define S3C_ADC_QUIRK_MUX18 (1 << 4)
+#define S3C_ADC_QUIRK_MUX1C (1 << 5)
+
+/*
+ * CLRINT register on S3C64xx
+ */
+#define S3C_ADC_QUIRK_CLRINT (1 << 6)
+
struct s3c_adc_client {
struct platform_device *pdev;
struct list_head pend;
--
1.7.5.4
^ permalink raw reply related
* [linux-pm Query] Power Management Device Suspend/ Resume
From: Viresh Kumar @ 2011-09-28 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317181365.1573.1636.camel@vkoul-udesk3>
Vinod,
Thanks for mailing us back.
On 9/28/2011 9:12 AM, Vinod Koul wrote:
> On Wed, 2011-09-28 at 08:55 +0530, Viresh Kumar wrote:
>> On 9/22/2011 4:19 PM, Deepak Sikri wrote:
> are you trying to do runtime power management or traditional suspend and
> resume? IMO both should be done...
We will first be testing traditional suspend/resume, but obviously we would
try to design drivers in order to support runtime PM too.
>>> *Query- 1*. Suppose my platform has a ADC driver under char framework, which internally uses the
>>> DMA driver (channels). Now, ADC driver can be used by other kernel drivers or directly from user application.
>>>
>>> *1. a.* What are the expectations from the suspend and resume routines of both the devices, DMA & ADC ?
>>>
>>> */-- Given that few of the options are/*
>>> */1.a.1. On suspend,/*
>>> In ADC suspend function: ADC releases all the DMA channels, latches its registers; and
>>> DMA suspend function: DMA does nothing except for lataching of registers if required.
>>>
>>> */1.a.2. On suspend, /*
>>> ADC suspend function: ADC just latches its registers and stops R/W through DMA, no DMA channel release;
>>> DMA suspend function: DMA halts its operating channels, and latches its registers if required.
> Well channel release/alloc is not really required. You can goto suspend
> in between as well. if you have queued but not active descriptors on all
> channels then dmac is idle and you can use this time to goto suspend.
But the time suspend is called for DMA, we may in middle of DMA transfers
on few channels. So should we wait for them to finish or simply disable
channel transfer? And in case of resume what will happen to transfers that
were active during suspend?
>>> *1.b* Will the suspend resume for the dependent drivers follow sequencing, i.e. Suspend of ADC followed by
>>> Suspend of DMA? (Assume both of these devices are hooked on to Platform bus, given that ADC uses DMA)
> why do you care?
Suppose suspend of DMA occurs first and we disable its clock in the suspend
routine. Now before the suspend of ADC is called, ADC requests for DMA
transfers and because not every routine of DMA keeps track of clk is on/off,
it may try to access DMA register.
So, we must ensure that all children are suspended before the parent is
requested to suspend. And probably this is the correct way.
So, here we need ADC to suspend before DMA. How is this sequencing ensured?
>>> 2.1 The user space threads freeze first followed by kernel space. In case the user space process issues a a system
>>> call (lets assume an ioctl system call), how will the user space thread respond in case of suspend to ram?
> all user space processes are frozen on STR
Yes, but what will be its state. Will the system calls complete? Will it
close all devices opened by it before freezing?
Suppose a user applications is accessing few ADC channels. ADC controller
and its channel are all configured. Now, suspend is requested. What should
ADC driver do? As power will be turned off, its register will loose their
value.
Should ADC reconfigure all its channel registers by keeping their state?
Also it is not very straight forward to reconfigure channels directly, as
registers are required to be programmed in certain sequence, so there
needs to be good amount of intelligence put into driver for that.
IIRC, i couldn't find any such stuff in other mainline drivers. And that's
why we are confused on this topic.
--
viresh
^ 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