[PATCH] ARM: EXYNOS5440: DTS: Add virtual GIC DT bindings
Exynos5440 has GIC which has virtualization support
in them. These are used by KVM.
Signed-off-by: Giridhar Maruthy giridha...@samsung.com
---
arch/arm/boot/dts/exynos5440.dtsi |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index c374a31..25c6134 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -26,7 +26,11 @@
compatible = arm,cortex-a15-gic;
#interrupt-cells = 3;
interrupt-controller;
- reg = 0x2E1000 0x1000, 0x2E2000 0x1000;
+ reg = 0x2E1000 0x1000,
+ 0x2E2000 0x1000,
+ 0x2E4000 0x2000,
+ 0x2E6000 0x2000;
+ interrupts = 1 9 0xf04;
};
cpus {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [PATCH] ARM: EXYNOS5440: DTS: Add virtual GIC DT bindings
This patch is similar to the ones already submitted by Alexander Graf
and also in Christoffer's tree in linux-kvm-arm for Arndale board,
while this is required for exynos5440.
Exynos5440 has GIC which has virtualization support
in them. These are used by KVM.
Signed-off-by: Giridhar Maruthy giridha...@samsung.com
---
arch/arm/boot/dts/exynos5440.dtsi |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index c374a31..25c6134 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -26,7 +26,11 @@
compatible = arm,cortex-a15-gic;
#interrupt-cells = 3;
interrupt-controller;
- reg = 0x2E1000 0x1000, 0x2E2000 0x1000;
+ reg = 0x2E1000 0x1000,
+ 0x2E2000 0x1000,
+ 0x2E4000 0x2000,
+ 0x2E6000 0x2000;
+ interrupts = 1 9 0xf04;
};
cpus {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: s3c24xx: allow device core to setup default pin configuration
On Mon, Mar 04, 2013 at 07:12:53PM +0530, Thomas Abraham wrote: With device core now able to setup the default pin configuration, the call to devm_pinctrl_get_select_default can be removed. And the pin configuration code based on the deprecated Samsung specific gpio bindings is also removed. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- Hi Heiko, Tomasz, We have to make a choice on the path forward for pinctrl support on Samsung platforms. We have three cases to deal with. A. Samsung platforms without DT support. B. Samsung platforms with DT support using old Samsung specific gpio bindings for pin-configuration (s3c24xx and s3x64xx). C. Samsung platforms with DT support using using pinctrl based pin-configurations (Exynos4 and Exynos5). For [A], we just let the platform specific callbacks handle the pin setup. For [B] and [C], based on Linus Walleij's pin grab by device core patch and subsequent discussions with him on the mailing list, would it be acceptable that we discontinue support for [B] in Samsung SoC device drivers. This will impact your current DT work on s3c24xx and s3c64xx platforms. Pinctrl is inevitable and we have to migrate to it. Instead of workarounds to maintain support for [B], it might be better that we migrate s3c24xx and s3c64xx platforms to pinctrl. Please do let us know your opinion on this. Dropping [B] sounds good, but I think it makes sense to wait with this patch until pinctrl support for s3c24xx is in place? -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] DMA: PL330: Add check if device tree compatible
On Tue, Mar 05, 2013 at 02:55:31PM +0530, Padmavathi Venna wrote:
This patch register the dma controller with generic dma helpers only
in DT case. This also adds some extra error handling in the driver.
Signed-off-by: Padmavathi Venna padm...@samsung.com
Reported-by: Sachin Kamat sachin.ka...@linaro.org
---
Based on Vinod Koul next branch.
Changes since V1:
- return silently when of_dma_controller_register fails, as
suggested by Arnd.
drivers/dma/pl330.c | 38 +++---
1 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 7181531..5dbc594 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2882,7 +2882,7 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
{
struct dma_pl330_platdata *pdat;
struct dma_pl330_dmac *pdmac;
- struct dma_pl330_chan *pch;
+ struct dma_pl330_chan *pch, *_p;
struct pl330_info *pi;
struct dma_device *pd;
struct resource *res;
@@ -2984,7 +2984,16 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
ret = dma_async_device_register(pd);
if (ret) {
dev_err(adev-dev, unable to register DMAC\n);
- goto probe_err2;
+ goto probe_err3;
+ }
+
+ if (adev-dev.of_node) {
+ ret = of_dma_controller_register(adev-dev.of_node,
+ of_dma_pl330_xlate, pdmac);
+ if (ret) {
+ dev_err(adev-dev,
+ unable to register DMA to the generic DT DMA
helpers\n);
Indent?
+ }
}
dev_info(adev-dev,
@@ -2995,16 +3004,21 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
pi-pcfg.data_bus_width / 8, pi-pcfg.num_chan,
pi-pcfg.num_peri, pi-pcfg.num_events);
- ret = of_dma_controller_register(adev-dev.of_node,
- of_dma_pl330_xlate, pdmac);
- if (ret) {
- dev_err(adev-dev,
- unable to register DMA to the generic DT DMA helpers\n);
- goto probe_err2;
- }
-
return 0;
+probe_err3:
+ amba_set_drvdata(adev, NULL);
+ /* Idle the DMAC */
+ list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,
+ chan.device_node) {
+
+ /* Remove the channel */
+ list_del(pch-chan.device_node);
+
+ /* Flush the channel */
+ pl330_control(pch-chan, DMA_TERMINATE_ALL, 0);
+ pl330_free_chan_resources(pch-chan);
free_chan for error handling in probe?
+ }
probe_err2:
pl330_del(pi);
probe_err1:
@@ -3023,8 +3037,10 @@ static int pl330_remove(struct amba_device *adev)
if (!pdmac)
return 0;
- of_dma_controller_free(adev-dev.of_node);
+ if (adev-dev.of_node)
+ of_dma_controller_free(adev-dev.of_node);
+ dma_async_device_unregister(pdmac-ddma);
amba_set_drvdata(adev, NULL);
/* Idle the DMAC */
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: s3c24xx: allow device core to setup default pin configuration
Am Donnerstag, 21. März 2013, 11:00:32 schrieb Wolfram Sang: On Mon, Mar 04, 2013 at 07:12:53PM +0530, Thomas Abraham wrote: With device core now able to setup the default pin configuration, the call to devm_pinctrl_get_select_default can be removed. And the pin configuration code based on the deprecated Samsung specific gpio bindings is also removed. Signed-off-by: Thomas Abraham thomas.abra...@linaro.org --- Hi Heiko, Tomasz, We have to make a choice on the path forward for pinctrl support on Samsung platforms. We have three cases to deal with. A. Samsung platforms without DT support. B. Samsung platforms with DT support using old Samsung specific gpio bindings for pin-configuration (s3c24xx and s3x64xx). C. Samsung platforms with DT support using using pinctrl based pin-configurations (Exynos4 and Exynos5). For [A], we just let the platform specific callbacks handle the pin setup. For [B] and [C], based on Linus Walleij's pin grab by device core patch and subsequent discussions with him on the mailing list, would it be acceptable that we discontinue support for [B] in Samsung SoC device drivers. This will impact your current DT work on s3c24xx and s3c64xx platforms. Pinctrl is inevitable and we have to migrate to it. Instead of workarounds to maintain support for [B], it might be better that we migrate s3c24xx and s3c64xx platforms to pinctrl. Please do let us know your opinion on this. Dropping [B] sounds good, but I think it makes sense to wait with this patch until pinctrl support for s3c24xx is in place? s3c24xx does not currently have dt support in mainline at all and the non-dt init is not touched at all. Also it seems the legacy gpio based dt init does not work at all currently, because the pinctrl function are no-ops and therefore the legacy gpio init is never reached on such systems. So I would vote for dropping [B]. I'm already working a bit on a pinctrl driver for s3c24xx, so when I reintroduce s3c24xx dt support again, it should already have pinctrl support then. Heiko -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c: s3c2410: move mach/regs-iic.h into i2c-s3c2410 device driver
Hi Wolfram, Am Donnerstag, 21. März 2013, 10:57:58 schrieb Wolfram Sang: On Fri, Feb 08, 2013 at 12:57:00AM +0100, Heiko Stübner wrote: The register definitions are only used in the driver itself. This also removes the last dependency on plat/ includes from the i2c driver. Signed-off-by: Heiko Stuebner he...@sntech.de What tree is this against? I can't apply it on top of v3.8 or 3.9-rc3. I'm not sure anymore ... probably some linux-next. I'll redo them on top of your (i2c) for-next branch. Heiko -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c: s3c2410: move mach/regs-iic.h into i2c-s3c2410 device driver
I'm not sure anymore ... probably some linux-next. I'll redo them on top of your (i2c) for-next branch. Thanks, but please use 3.9-rc3. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
Hi Rob,
(adding Marc to Cc as he may have comments).
On Wed, Mar 20, 2013 at 10:34:35PM +, Rob Herring wrote:
From: Rob Herring rob.herr...@calxeda.com
This converts arm and arm64 to use CLKSRC_OF DT based initialization for
the arch timer. A new function arch_timer_arch_init is added to allow for
arch specific setup.
This has a side effect of enabling sched_clock on omap5 and exynos5. There
should not be any reason not to use the arch timers for sched_clock.
Nice! I was just about to post a (slightly updated) version of Thomas Abraham's
arch_timer clocksource_of_init patch, but this seems much more comprehensive.
I have some other arch_timer patches which may clash, but they could be rebased
atop of this.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Kukjin Kim kgene@samsung.com
Cc: Tony Lindgren t...@atomide.com
Cc: Simon Horman ho...@verge.net.au
Cc: Magnus Damm magnus.d...@gmail.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: John Stultz john.stu...@linaro.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux...@vger.kernel.org
---
This is dependent on my CLKSRC_OF clean-up in arm-soc, my 64-bit sched_clock
support series, and Arnd's default machine descriptor patch (for default
clocksource_of_init call). This is only compile tested on arm.
The full series (including sp804 work) is available here:
git://sources.calxeda.com/kernel/linux.git arm-timers
Rob
[...]
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index d0ad789..6215717 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -1,6 +1,7 @@
/*
* Versatile Express V2M Motherboard Support
*/
+#include linux/clocksource.h
#include linux/device.h
#include linux/amba/bus.h
#include linux/amba/mmci.h
@@ -23,7 +24,6 @@
#include linux/regulator/machine.h
#include linux/vexpress.h
-#include asm/arch_timer.h
#include asm/mach-types.h
#include asm/sizes.h
#include asm/mach/arch.h
@@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void)
irq_of_parse_and_map(node, 0));
}
- arch_timer_of_register();
-
- if (arch_timer_sched_clock_init() != 0)
- versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
+ versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
2400);
}
On TC2 this series leads to using the vexpress 24MHz clock as the sched clock
in preference to the architected timer:
Architected local timer running at 24.00MHz (virt).
Switching to timer-based delay loop
Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source
As they both have the same frequency, neither overrides the other, and
whichever gets registered last is used as the sched_clock. As accesses to the
architected timer are going to have a much lower overhead, this isn't very nice
(and it could be better to use it even if it had a lower frequency).
We could move the versatile_sched_clock_init call before the
clocksource_of_init, but that doesn't feel like an ideal solution. We may have
similar problems elsewhere.
[...]
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index b0ef18d..a551f88 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -32,6 +32,7 @@
#include linux/timer.h
#include linux/irq.h
#include linux/delay.h
+#include linux/clocksource.h
#include clocksource/arm_arch_timer.h
@@ -77,10 +78,11 @@ void __init time_init(void)
{
u32 arch_timer_rate;
- if (arch_timer_init())
- panic(Unable to initialise architected timer.\n);
+ clocksource_of_init();
arch_timer_rate = arch_timer_get_rate();
+ if (!arch_timer_rate)
+ panic(Unable to initialise architected timer.\n);
/* Cache the sched_clock multiplier to save a divide in the hot path.
*/
sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index e507ab7..d98e7e1 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -62,6 +62,7 @@ config CLKSRC_DBX500_PRCMU_SCHED_CLOCK
config ARM_ARCH_TIMER
bool
+ select CLKSRC_OF if OF
config CLKSRC_METAG_GENERIC
def_bool y if METAG
[...]
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index d7ad425..afb70aa 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -337,24 +337,11 @@ out:
return err;
}
-static const struct of_device_id
[PATCH] ARM: SAMSUNG: Remove useless Samsung GPIO related CONFIG
The Kconfig entry for S3C_GPIO_CFG_S3C64XX was missed by commit 5ec7414494ed1204c9e2ed0b8232b29860d0986f (ARM: SAMSUNG: Remove useless Samsung GPIO related CONFIGs). Remove it now. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested. arch/arm/plat-samsung/Kconfig | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 663c54f..91c2d72 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -117,12 +117,6 @@ config SAMSUNG_GPIOLIB_4BIT configuration. GPIOlib shall be compiled only for S3C64XX and S5P series of processors. -config S3C_GPIO_CFG_S3C64XX - bool - help - Internal configuration to enable S3C64XX style GPIO configuration - functions. - config S5P_GPIO_DRVSTR bool help -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] i2c: pxa: Use i2c-core to get bus number now
On Fri, Mar 01, 2013 at 08:57:32AM -0800, Doug Anderson wrote: The commit: i2c-core: dt: Pick i2c bus number from i2c alias if present adds support for automatically picking the bus number based on the alias ID. Remove the now unnecessary code from i2c-pxa that did the same thing. Signed-off-by: Doug Anderson diand...@chromium.org Thanks, applied for-next. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On 03/21/2013 06:06 AM, Mark Rutland wrote:
Hi Rob,
(adding Marc to Cc as he may have comments).
On Wed, Mar 20, 2013 at 10:34:35PM +, Rob Herring wrote:
From: Rob Herring rob.herr...@calxeda.com
This converts arm and arm64 to use CLKSRC_OF DT based initialization for
the arch timer. A new function arch_timer_arch_init is added to allow for
arch specific setup.
This has a side effect of enabling sched_clock on omap5 and exynos5. There
should not be any reason not to use the arch timers for sched_clock.
Nice! I was just about to post a (slightly updated) version of Thomas
Abraham's
arch_timer clocksource_of_init patch, but this seems much more comprehensive.
I have some other arch_timer patches which may clash, but they could be
rebased
atop of this.
[snip]
@@ -446,10 +446,7 @@ static void __init v2m_dt_timer_init(void)
irq_of_parse_and_map(node, 0));
}
- arch_timer_of_register();
-
- if (arch_timer_sched_clock_init() != 0)
- versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
+ versatile_sched_clock_init(vexpress_get_24mhz_clock_base(),
2400);
}
On TC2 this series leads to using the vexpress 24MHz clock as the sched clock
in preference to the architected timer:
Architected local timer running at 24.00MHz (virt).
Switching to timer-based delay loop
Registered arch_counter_get_cntvct+0x0/0x14 as sched_clock source
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Registered versatile_read_sched_clock+0x0/0x28 as sched_clock source
As they both have the same frequency, neither overrides the other, and
whichever gets registered last is used as the sched_clock. As accesses to the
architected timer are going to have a much lower overhead, this isn't very
nice
(and it could be better to use it even if it had a lower frequency).
We could move the versatile_sched_clock_init call before the
clocksource_of_init, but that doesn't feel like an ideal solution. We may have
similar problems elsewhere.
The intention was that a 64-bit counter is preferred. This should fix
that. It would be nice if we could describe access overhead to make a decision.
For now, I think 32 vs. 64 bit is sufficient.
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 1708357..aa18e45 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -115,7 +115,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits,
unsigned long rate)
u64 res, wrap;
char r_unit;
- if (cd.rate rate)
+ if (cd.rate rate || read_sched_clock_64)
return;
BUG_ON(bits 32);
@@ -168,7 +168,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits,
unsigned long rate)
void __init setup_sched_clock_64(u64 (*read)(void), unsigned long rate)
{
- if (cd.rate rate)
+ if (read_sched_clock_64 (cd.rate rate))
return;
WARN_ON(!irqs_disabled());
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/clocksource/arm_arch_timer.c
index d7ad425..afb70aa 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -337,24 +337,11 @@ out:
return err;
}
-static const struct of_device_id arch_timer_of_match[] __initconst = {
- { .compatible = arm,armv7-timer,},
- { .compatible = arm,armv8-timer,},
- {},
-};
-
-int __init arch_timer_init(void)
+static void __init arch_timer_init(struct device_node *np)
{
- struct device_node *np;
u32 freq;
int i;
If we the following here:
if (arch_timer_get_rate()) {
pr_warn(arch_timer: multiple nodes in dt, skipping\n);
return;
}
We may save ourselves a whole world of pain with dts which (erroneously) have
multiple timer nodes (though these are now disappearing). Otherwise we could
have a memory leak and multiple instances of the cpu0 timer registered, which
could lead to all sorts of weirdness. The existing code side-steps this issue
by only grabbing the first node, so this would keep things consistent.
Okay, I'll add.
Rob
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] i2c: s3c2410: move mach/regs-iic.h into i2c-s3c2410 device driver
The register definitions are only used in the driver itself. This also removes the last dependency on plat/ includes from the i2c driver. Signed-off-by: Heiko Stuebner he...@sntech.de Acked-by: Kukjin Kim kgene@samsung.com --- changes since v1: rebased against 3.9-rc3 arch/arm/mach-s3c24xx/mach-rx1950.c |1 - arch/arm/plat-samsung/devs.c |1 - arch/arm/plat-samsung/include/plat/regs-iic.h | 56 - drivers/i2c/busses/i2c-s3c2410.c | 41 ++- 4 files changed, 40 insertions(+), 59 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-iic.h diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c b/arch/arm/mach-s3c24xx/mach-rx1950.c index 1f9ba2a..43f3ac5 100644 --- a/arch/arm/mach-s3c24xx/mach-rx1950.c +++ b/arch/arm/mach-s3c24xx/mach-rx1950.c @@ -56,7 +56,6 @@ #include plat/cpu.h #include plat/devs.h #include plat/pm.h -#include plat/regs-iic.h #include plat/regs-serial.h #include common.h diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c index 51afedd..76209c9 100644 --- a/arch/arm/plat-samsung/devs.c +++ b/arch/arm/plat-samsung/devs.c @@ -62,7 +62,6 @@ #include linux/platform_data/usb-s3c2410_udc.h #include linux/platform_data/usb-ohci-s3c2410.h #include plat/usb-phy.h -#include plat/regs-iic.h #include plat/regs-serial.h #include plat/regs-spi.h #include linux/platform_data/spi-s3c64xx.h diff --git a/arch/arm/plat-samsung/include/plat/regs-iic.h b/arch/arm/plat-samsung/include/plat/regs-iic.h deleted file mode 100644 index 2f7c17d..000 --- a/arch/arm/plat-samsung/include/plat/regs-iic.h +++ /dev/null @@ -1,56 +0,0 @@ -/* arch/arm/mach-s3c2410/include/mach/regs-iic.h - * - * Copyright (c) 2004 Simtec Electronics li...@simtec.co.uk - * http://www.simtec.co.uk/products/SWLINUX/ - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * S3C2410 I2C Controller -*/ - -#ifndef __ASM_ARCH_REGS_IIC_H -#define __ASM_ARCH_REGS_IIC_H __FILE__ - -/* see s3c2410x user guide, v1.1, section 9 (p447) for more info */ - -#define S3C2410_IICREG(x) (x) - -#define S3C2410_IICCONS3C2410_IICREG(0x00) -#define S3C2410_IICSTAT S3C2410_IICREG(0x04) -#define S3C2410_IICADDS3C2410_IICREG(0x08) -#define S3C2410_IICDS S3C2410_IICREG(0x0C) -#define S3C2440_IICLCS3C2410_IICREG(0x10) - -#define S3C2410_IICCON_ACKEN (17) -#define S3C2410_IICCON_TXDIV_16(06) -#define S3C2410_IICCON_TXDIV_512 (16) -#define S3C2410_IICCON_IRQEN (15) -#define S3C2410_IICCON_IRQPEND (14) -#define S3C2410_IICCON_SCALE(x)((x)15) -#define S3C2410_IICCON_SCALEMASK (0xf) - -#define S3C2410_IICSTAT_MASTER_RX (26) -#define S3C2410_IICSTAT_MASTER_TX (36) -#define S3C2410_IICSTAT_SLAVE_RX (06) -#define S3C2410_IICSTAT_SLAVE_TX (16) -#define S3C2410_IICSTAT_MODEMASK (36) - -#define S3C2410_IICSTAT_START (15) -#define S3C2410_IICSTAT_BUSBUSY(15) -#define S3C2410_IICSTAT_TXRXEN (14) -#define S3C2410_IICSTAT_ARBITR (13) -#define S3C2410_IICSTAT_ASSLAVE(12) -#define S3C2410_IICSTAT_ADDR0 (11) -#define S3C2410_IICSTAT_LASTBIT(10) - -#define S3C2410_IICLC_SDA_DELAY0 (0 0) -#define S3C2410_IICLC_SDA_DELAY5 (1 0) -#define S3C2410_IICLC_SDA_DELAY10 (2 0) -#define S3C2410_IICLC_SDA_DELAY15 (3 0) -#define S3C2410_IICLC_SDA_DELAY_MASK (3 0) - -#define S3C2410_IICLC_FILTER_ON(12) - -#endif /* __ASM_ARCH_REGS_IIC_H */ diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index f6b880b..216fea1 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -42,9 +42,48 @@ #include asm/irq.h -#include plat/regs-iic.h #include linux/platform_data/i2c-s3c2410.h +/* see s3c2410x user guide, v1.1, section 9 (p447) for more info */ + +#define S3C2410_IICREG(x) (x) + +#define S3C2410_IICCONS3C2410_IICREG(0x00) +#define S3C2410_IICSTAT S3C2410_IICREG(0x04) +#define S3C2410_IICADDS3C2410_IICREG(0x08) +#define S3C2410_IICDS S3C2410_IICREG(0x0C) +#define S3C2440_IICLCS3C2410_IICREG(0x10) + +#define S3C2410_IICCON_ACKEN (17) +#define S3C2410_IICCON_TXDIV_16(06) +#define S3C2410_IICCON_TXDIV_512 (16) +#define S3C2410_IICCON_IRQEN (15) +#define S3C2410_IICCON_IRQPEND (14) +#define S3C2410_IICCON_SCALE(x)((x)15) +#define S3C2410_IICCON_SCALEMASK (0xf) + +#define S3C2410_IICSTAT_MASTER_RX (26) +#define S3C2410_IICSTAT_MASTER_TX (36) +#define S3C2410_IICSTAT_SLAVE_RX (06) +#define S3C2410_IICSTAT_SLAVE_TX (16) +#define S3C2410_IICSTAT_MODEMASK (36) + +#define S3C2410_IICSTAT_START
[PATCH v2 2/2] i2c: s3c2410: fixup the styling of the newly moved register definitions
Make them conform more to established standards. Signed-off-by: Heiko Stuebner he...@sntech.de --- changes since v1: none drivers/i2c/busses/i2c-s3c2410.c | 50 ++--- 1 files changed, 24 insertions(+), 26 deletions(-) diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index 216fea1..0a81f1f 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -46,35 +46,33 @@ /* see s3c2410x user guide, v1.1, section 9 (p447) for more info */ -#define S3C2410_IICREG(x) (x) - -#define S3C2410_IICCONS3C2410_IICREG(0x00) -#define S3C2410_IICSTAT S3C2410_IICREG(0x04) -#define S3C2410_IICADDS3C2410_IICREG(0x08) -#define S3C2410_IICDS S3C2410_IICREG(0x0C) -#define S3C2440_IICLCS3C2410_IICREG(0x10) - -#define S3C2410_IICCON_ACKEN (17) -#define S3C2410_IICCON_TXDIV_16(06) -#define S3C2410_IICCON_TXDIV_512 (16) -#define S3C2410_IICCON_IRQEN (15) -#define S3C2410_IICCON_IRQPEND (14) -#define S3C2410_IICCON_SCALE(x)((x)15) +#define S3C2410_IICCON 0x00 +#define S3C2410_IICSTAT0x04 +#define S3C2410_IICADD 0x08 +#define S3C2410_IICDS 0x0C +#define S3C2440_IICLC 0x10 + +#define S3C2410_IICCON_ACKEN (1 7) +#define S3C2410_IICCON_TXDIV_16(0 6) +#define S3C2410_IICCON_TXDIV_512 (1 6) +#define S3C2410_IICCON_IRQEN (1 5) +#define S3C2410_IICCON_IRQPEND (1 4) +#define S3C2410_IICCON_SCALE(x)((x) 0xf) #define S3C2410_IICCON_SCALEMASK (0xf) -#define S3C2410_IICSTAT_MASTER_RX (26) -#define S3C2410_IICSTAT_MASTER_TX (36) -#define S3C2410_IICSTAT_SLAVE_RX (06) -#define S3C2410_IICSTAT_SLAVE_TX (16) -#define S3C2410_IICSTAT_MODEMASK (36) +#define S3C2410_IICSTAT_MASTER_RX (2 6) +#define S3C2410_IICSTAT_MASTER_TX (3 6) +#define S3C2410_IICSTAT_SLAVE_RX (0 6) +#define S3C2410_IICSTAT_SLAVE_TX (1 6) +#define S3C2410_IICSTAT_MODEMASK (3 6) -#define S3C2410_IICSTAT_START (15) -#define S3C2410_IICSTAT_BUSBUSY(15) -#define S3C2410_IICSTAT_TXRXEN (14) -#define S3C2410_IICSTAT_ARBITR (13) -#define S3C2410_IICSTAT_ASSLAVE(12) -#define S3C2410_IICSTAT_ADDR0 (11) -#define S3C2410_IICSTAT_LASTBIT(10) +#define S3C2410_IICSTAT_START (1 5) +#define S3C2410_IICSTAT_BUSBUSY(1 5) +#define S3C2410_IICSTAT_TXRXEN (1 4) +#define S3C2410_IICSTAT_ARBITR (1 3) +#define S3C2410_IICSTAT_ASSLAVE(1 2) +#define S3C2410_IICSTAT_ADDR0 (1 1) +#define S3C2410_IICSTAT_LASTBIT(1 0) #define S3C2410_IICLC_SDA_DELAY0 (0 0) #define S3C2410_IICLC_SDA_DELAY5 (1 0) @@ -82,7 +80,7 @@ #define S3C2410_IICLC_SDA_DELAY15 (3 0) #define S3C2410_IICLC_SDA_DELAY_MASK (3 0) -#define S3C2410_IICLC_FILTER_ON(12) +#define S3C2410_IICLC_FILTER_ON(1 2) /* Treat S3C2410 as baseline hardware, anything else is supported via quirks */ #define QUIRK_S3C2440 (1 0) -- 1.7.2.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: EXYNOS5250: Register architected timers
On 14.03.2013, at 20:07, Sergei Shtylyov wrote:
Hello.
On 14-03-2013 4:59, Alexander Graf wrote:
When running on an exynos 5250 SoC, we don't initialize the architected
timers. The chip however supports architected timers.
When we don't initialize them, KVM will try to access them and run into
NULL pointer dereferences attempting to do so.
This patch is really more of a hack than a real fix, but does get me
working with KVM on Arndale.
Signed-off-by: Alexander Graf ag...@suse.de
---
arch/arm/mach-exynos/mct.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
index c9d6650..eefb8af 100644
--- a/arch/arm/mach-exynos/mct.c
+++ b/arch/arm/mach-exynos/mct.c
@@ -482,4 +482,8 @@ void __init exynos4_timer_init(void)
exynos4_timer_resources();
exynos4_clocksource_init();
exynos4_clockevent_init();
+
+if (soc_is_exynos5250()) {
+arch_timer_of_register();
+}
{} not needed here. scripts/checkpatch.pl should probabl;y warn about it.
Yeah, I'd leave it to whoever wants to apply this patch to remove the braces
:). IMHO it's not worth it to respin just for this.
Alex
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 8/9] ARM: tegra: Provide regulator to pwm-backlight
On 03/19/2013 12:59 PM, Andrew Chew wrote: The pwm-backlight driver now takes a mandatory regulator that is gotten during driver probe. Initialize a dummy regulator to satisfy this requirement. I assume these patches will get merged through the PWM tree? If so, Acked-by: Stephen Warren swar...@nvidia.com -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RE: RE: [PATCH v6 00/16] clk: exynos4/5: migrate to common clock framework
Mike Turquette wrote: [...] Furthermore if I *had* agreed on the previous version it would still have been appropriate to put my Acked-by on those patches, which is clearly missing today. BTW, how about following? http://www.spinics.net/lists/arm-kernel/msg210266.html In my understanding, it should be your agreement, it cannot be 'ack' though. I had forgotten about that email from November. Still my ack should have been added. If necessary I'll be painfully explicit in the future Agreed. about adding my acked-by. It's a simple and good rule to follow. Yeah, I know. So if you want to add your ack on drivers/clk stuff for this series in samsung tree, please let me know. Thanks, Mike. - Kukjin -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
