This patchset adds device tree support for GIC and Interrupt Combiner modules
in Exynos4 SoC.
Patch 1 moves the statically mapped timer irqs 11 to 15 to the end of the
statically mapped linux irq space for all s5p platforms. This patch is
applicable for s5p64x0, s5pc100, s5pv210 and exynos4.
For
ioremap() request for statically remapped regions are intercepted and the
statically assigned virtual address is returned. For requests for which
there are no statically remapped regions, the requests are let through.
Cc: Kukjin Kim
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos4/cpu.c
All of Samsung's s5p platforms have timer irqs statically mapped from linux
irq numbers 11 to 15. These timer irqs are moved to end of the statically
mapped linux irq space and the hardware irqs, which were statically mapped
starting from 32 is moved to start from 0. The NR_IRQS macro is consolidat
Add support for conversion of device tree interrupt specifier to linux
virq domain for GIC and Interrupt combiner controllers.
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/irq/samsung-combiner.txt | 24 ++
arch/arm/mach-exynos4/cpu.c| 20 +++
Changes since v1:
- Included the missing dt bindings documentation in the last patch.
- Rebased and tested with linux 3.1-rc9 on linux-samsung-soc tree.
- Commit messages are modified to be elaborate.
- No changes in code.
This patchset reworks the lookup of parent clocks for baud rate generator
Add a pointer to the location of the platform data in the driver's private
data. When instantiated using device tree, pdev->dev->platform_data does not
necessarily point to a valid instance of platform data. The platform data
pointer in the driver's private data could be set to pdev->dev->platform_
s3c2440 uses fclk/n (fclk divided by n) clock as one of the possible clocks used
to generate the baud rate clock. The divider 'n' in this case can be logically
represented outside of the uart controller.
This patch creates a new clock by name "fclk_n" for s3c2440 based platforms to
represent the f
Instead of using clock names supplied in platform data, use a generic
clock name 'clk_uart_baud' to look up clocks. The platform code should
register clocks with the name 'clk_uart_baud' which can be used by the
baud rate generator. The clock lookup and selection of the best clock
as baud rate cloc
With clkdev based clock lookup added to samsung serial driver, the use
of 'struct s3c24xx_uart_clksrc' to supply clock names in platform
data is removed from all the Samsung platform code.
Cc: Ben Dooks
Cc: Ramax Lo
Cc: Vasily Khoruzhick
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos4
With clkdev based clock lookup support, the clock set and get operation
using clock names communicated between the samsung uart driver and the
SoC specific extension can be removed.
In addition to that, for each platform specific extension, add the
default clock selection, number of clock options
The port reset function in each of the platform specific extension performs
the same operations and hence all the reset port functions can be merged into
one and moved into the common samsung uart driver. The SoC specific port reset
functions are removed from SoC extensions.
Cc: Ben Dooks
Signed-
With reset port, set clock and get clock functions in SoC specific extentions
being removed, only the driver probe is left over in these extensions. The
probe function itself can be merged into one and moved into the samsung common
serial driver. With driver probe also moved, all the SoC specific e
Samsung uart driver lookups the clock using the connection id 'clk_uart_baud'.
The uart clocks for all Samsung platforms are reorganized to register them
with the lookup name as required by the uart driver.
Cc: Ben Dooks
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos4/clock.c |
Add device tree based discovery support for Samsung's uart controller.
Cc: Ben Dooks
Cc: Grant Likely
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/serial/samsung_uart.txt| 14
drivers/tty/serial/samsung.c | 36 ++-
2 files cha
Hi Benoit,
On Mon, Sep 26, 2011 at 7:50 PM, Benoit Cousson wrote:
> +++ b/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
> @@ -0,0 +1,5 @@
> +* HW spinlock on OMAP4 platform:
> +
> +Required properties:
> +- compatible : Must be "ti,omap4-spinlock";
> +- ti,hwmods : "spinlock"
> d
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak
Acked-by: Mark Brown
---
drivers/regulator/twl-regulator.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/
Hi Mark, Grant,
I have reworked the regulator-dt-suppport series based
on your reviews and also split it so I remove any dependency
with the omap specific dt conversion for i2c/twl.
So this latest series is based on mainline 3.1-rc9.
I will post the twl-regulator driver adaptation to dt and
the o
Add empty of_device_is_compatible(), of_find_property()
and of_parse_phandle() for non-dt builds to work.
Signed-off-by: Rajendra Nayak
---
include/linux/of.h | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index
The fixed regulator driver uses of_get_fixed_voltage_config()
to extract fixed_voltage_config structure contents from device tree.
Also add documenation for additional bindings for fixed
regulators that can be passed through dt.
Signed-off-by: Rajendra Nayak
---
.../bindings/regulator/fixed-reg
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure from the data
that is passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
imp
Device nodes in DT can associate themselves with one or more
regulators/supply by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = <®ulator1>;
On Mon, Oct 10, 2011 at 09:49:34PM +0530, Rajendra Nayak wrote:
> Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
> each regulator from the twl driver and let the boards pass it.
>
> Signed-off-by: Rajendra Nayak
> Acked-by: Mark Brown
Please update this changelog - as I said in
Changes since v4:
- Tested with linux 3.1-rc9. No changes in code.
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:
- A
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 opt
Add device tree based discovery support for Samsung's keypad controller.
Cc: Joonyoung Shim
Cc: Donghwa Lee
Signed-off-by: Thomas Abraham
Acked-by: Grant Likely
---
.../devicetree/bindings/input/samsung-keypad.txt | 88 ++
drivers/input/keyboard/samsung-keypad.c| 174
On Monday 10 October 2011 09:55 PM, Mark Brown wrote:
On Mon, Oct 10, 2011 at 09:49:34PM +0530, Rajendra Nayak wrote:
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak
Acked-by: Mark Brown
Device tree support on at91sam9g45 family SoC. Only call
platform_device_register() if no dma-controller node is
found in device tree.
Signed-off-by: Nicolas Ferre
---
arch/arm/mach-at91/at91sam9g45_devices.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/a
DMA controller can deduce its configuration data from
the platform. Remove the platform data and match device
types with the compatible ones.
Signed-off-by: Nicolas Ferre
---
arch/arm/mach-at91/at91sam9g45_devices.c |9 +
arch/arm/mach-at91/at91sam9rl_devices.c |8 +---
2 fi
Add device tree probe support for atmel at_hdmac DMA driver.
Bindings are added to specify DMA controller configuration.
Signed-off-by: Nicolas Ferre
---
.../devicetree/bindings/dma/atmel-dma.txt | 14 +
drivers/dma/at_hdmac.c | 30 +++
We remove platform data from DMA controller and move
to the use of .id_table to distinguish between compatible
types. The two implementations allow to determine the
number of channels and the capabilities of the controller.
Signed-off-by: Nicolas Ferre
---
drivers/dma/at_hdmac.c | 48
Device tree support on at91sam9g45 family SoC. Only call
platform_device_register() if no compatible dma-controller
node is found in device tree.
Signed-off-by: Nicolas Ferre
---
V2: use compatible string to match device.
arch/arm/mach-at91/at91sam9g45_devices.c |8 +++-
1 files changed
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
> +- regulator-change-voltage: boolean, Output voltage can be changed by
> software
> +- regulator-change-current: boolean, Output current can be chnaged by
> software
> +- regulator-change-mode: boolean, Operating mode can be chang
On Mon, Oct 10, 2011 at 09:49:38PM +0530, Rajendra Nayak wrote:
> Device nodes in DT can associate themselves with one or more
> regulators/supply by providing a list of phandles (to regulator nodes)
> and corresponding supply names.
Mostly looks good.
> +/**
> + * of_get_regulator - get a regul
@@ -1178,6 +1225,10 @@ static struct regulator *_regulator_get(struct device
*dev, const char *id,
goto found;
}
}
+ if (!dev)
+ list_for_each_entry(rdev,®ulator_list, list)
+ if (strcmp(rdev_get_name(rd
On Monday 10 October 2011 10:52 PM, Mark Brown wrote:
On Mon, Oct 10, 2011 at 09:49:36PM +0530, Rajendra Nayak wrote:
+- regulator-change-voltage: boolean, Output voltage can be changed by software
+- regulator-change-current: boolean, Output current can be chnaged by software
+- regulator-chan
35 matches
Mail list logo
