* [PATCH v6 01/19] clocksource: orion: Use atomic access for shared registers
From: Daniel Lezcano @ 2014-02-11 0:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391707226-18258-2-git-send-email-ezequiel.garcia@free-electrons.com>
On 02/06/2014 06:20 PM, Ezequiel Garcia wrote:
> Replace the driver-specific thread-safe shared register API
> by the recently introduced atomic_io_clear_set().
>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Tested-by: Willy Tarreau <w@1wt.eu>
> Acked-by: Jason Cooper <jason@lakedaemon.net>
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
The patch looks good for me.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH] ARM: tegra: don't timeout if CPU is powergated
From: Stefan Agner @ 2014-02-11 0:44 UTC (permalink / raw)
To: linux-arm-kernel
When booting secondary CPU(s) which are not yet powergated, a wrong
check lead to a timeout after 100 jiffies. With this patch, we only
delay powergating if CPUs are still not powered yet.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
I happend to come accross this while working on Colibri T30 support.
Obviously, the downstream U-Boot doesn't powergate all CPUs, so
the Linux kernel always timed out when booting CPU 1 through 3...
arch/arm/mach-tegra/platsmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index eb72ae7..929d104 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -114,7 +114,7 @@ static int tegra30_boot_secondary(unsigned int cpu, struct task_struct *idle)
/* Wait for the power to come up. */
timeout = jiffies + msecs_to_jiffies(100);
- while (tegra_pmc_cpu_is_powered(cpu)) {
+ while (!tegra_pmc_cpu_is_powered(cpu)) {
if (time_after(jiffies, timeout))
return -ETIMEDOUT;
udelay(10);
--
1.8.5.4
^ permalink raw reply related
* [PATCH v4 0/3] serial: fsl_lpuart: add DMA support
From: Yao Yuan @ 2014-02-11 1:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127075025.GC4765@S2101-09.ap.freescale.net>
Hi, Shawn
Here I just want the DMA be a selectable property for each board.
Is it suitable?
> -----Original Message-----
> From: Shawn Guo [mailto:shawn.guo at linaro.org]
> Sent: Monday, January 27, 2014 3:50 PM
> To: Yuan Yao-B46683
> Cc: gregkh at linuxfoundation.org; linux at arm.linux.org.uk; arnd at arndb.de;
> mark.rutland at arm.com; linux-arm-kernel at lists.infradead.org; linux-
> serial at vger.kernel.org
> Subject: Re: [PATCH v4 0/3] serial: fsl_lpuart: add DMA support
>
> On Wed, Jan 22, 2014 at 12:09:30PM +0800, Yuan Yao wrote:
> > Changed in v4:
> > - Move dma properties from dtsi to dts.
>
> Why this change? DMA is a SoC level resource rather than board one.
>
> Shawn
^ permalink raw reply
* [PATCH v1 0/1] Boot all secondary cores on Exynos SoC's
From: Tarek Dakhran @ 2014-02-11 2:15 UTC (permalink / raw)
To: linux-arm-kernel
Due to implementation of exynos_boot_secondary function
only one secondary core boots on Exynos SoC's.
Two new functions added to power up and power down secondary cores:
static int exynos_core_power_up(unsigned int cpu);
static int exynos_core_power_down(unsigned int cpu).
Tested on linux kernel v3.14-rc2.
Comments and additions would be appreciated.
Thank you.
Tarek.
Tarek Dakhran (1):
ARM: EXYNOS: enable boot all secondary cpus instead 2
arch/arm/mach-exynos/hotplug.c | 11 ++++--
arch/arm/mach-exynos/platsmp.c | 75 ++++++++++++++++++++++++++++-----------
arch/arm/mach-exynos/regs-pmu.h | 5 +++
3 files changed, 68 insertions(+), 23 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH v1 1/1] ARM: EXYNOS: enable boot all secondary cpus instead 2
From: Tarek Dakhran @ 2014-02-11 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392084929-14116-1-git-send-email-t.dakhran@samsung.com>
Functions to boot secondary cpus added.
exynos_core_power_up(unsigned int cpu) added for power up any cpu.
exynos_core_power_down(unsigned int cpu) for power down any cpu.
Signed-off-by: Tarek Dakhran <t.dakhran@samsung.com>
---
arch/arm/mach-exynos/hotplug.c | 11 ++++--
arch/arm/mach-exynos/platsmp.c | 75 ++++++++++++++++++++++++++++-----------
arch/arm/mach-exynos/regs-pmu.h | 5 +++
3 files changed, 68 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..71982fa 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -90,13 +90,18 @@ static inline void cpu_leave_lowpower(void)
: "cc");
}
+static void exynos_core_power_down(unsigned int cpu)
+{
+ writel_relaxed(0, S5P_ARM_CORE_CONFIGURATION(cpu));
+}
+
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
{
for (;;) {
- /* make cpu1 to be turned off at next WFI command */
- if (cpu == 1)
- __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+ /* make cpu to be turned off at next WFI command */
+ if (cpu)
+ exynos_core_power_down(cpu);
/*
* here's the WFI
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 8ea02f6..4008fc8 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -88,10 +88,61 @@ static void exynos_secondary_init(unsigned int cpu)
spin_unlock(&boot_lock);
}
+/*
+ * core_power_state is used to get core power state.
+ * returns:
+ * 0x0 - powered off;
+ * 0x3 - powered on;
+ * other values - in process;
+ */
+static unsigned int core_power_state(unsigned int cpu)
+{
+ unsigned int status = readl_relaxed(S5P_ARM_CORE_STATUS(cpu));
+
+ return status & CORE_PWR_STATE_MASK;
+}
+
+#define TIMEOUT 10
+#define DELAY_TIME 1
+
+static int wait_core_power_up(unsigned int cpu)
+{
+ int timeout = TIMEOUT;
+
+ do {
+ /* checking if power controller in reset */
+ if (core_power_state(cpu) == S5P_CORE_LOCAL_PWR_EN)
+ return 0;
+ mdelay(DELAY_TIME);
+ timeout -= DELAY_TIME;
+ } while (timeout > 0);
+
+ return -ETIMEDOUT; /* timeout */
+}
+
+static int exynos_core_power_up(unsigned int cpu)
+{
+ int ret;
+
+ if (core_power_state(cpu) != S5P_CORE_LOCAL_PWR_EN) {
+ writel_relaxed(S5P_CORE_LOCAL_PWR_EN,
+ S5P_ARM_CORE_CONFIGURATION(cpu));
+
+ ret = wait_core_power_up(cpu);
+ if (ret) {
+ pr_debug("timeout powering on CPU%d\n", cpu);
+ return ret; /* timeout */
+ }
+ }
+
+ return 0;
+}
+
static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
unsigned long timeout;
unsigned long phys_cpu = cpu_logical_map(cpu);
+ int ret;
/*
* Set synchronisation state between this boot processor
@@ -109,26 +160,10 @@ static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle)
*/
write_pen_release(phys_cpu);
- if (!(__raw_readl(S5P_ARM_CORE1_STATUS) & S5P_CORE_LOCAL_PWR_EN)) {
- __raw_writel(S5P_CORE_LOCAL_PWR_EN,
- S5P_ARM_CORE1_CONFIGURATION);
-
- timeout = 10;
-
- /* wait max 10 ms until cpu1 is on */
- while ((__raw_readl(S5P_ARM_CORE1_STATUS)
- & S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
- if (timeout-- == 0)
- break;
-
- mdelay(1);
- }
-
- if (timeout == 0) {
- printk(KERN_ERR "cpu1 power enable failed");
- spin_unlock(&boot_lock);
- return -ETIMEDOUT;
- }
+ ret = exynos_core_power_up(cpu);
+ if (ret) {
+ spin_unlock(&boot_lock);
+ return ret;
}
/*
* Send the secondary CPU a soft interrupt, thereby causing
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 7c029ce..4fc1e8f 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -104,6 +104,11 @@
#define S5P_GPS_LOWPWR S5P_PMUREG(0x139C)
#define S5P_GPS_ALIVE_LOWPWR S5P_PMUREG(0x13A0)
+#define CORE_PWR_STATE_MASK 0x3
+
+#define S5P_ARM_CORE_CONFIGURATION(_nr) (S5P_PMUREG(0x2000) + ((_nr) * 0x80))
+#define S5P_ARM_CORE_STATUS(_nr) (S5P_PMUREG(0x2004) + ((_nr) * 0x80))
+
#define S5P_ARM_CORE1_CONFIGURATION S5P_PMUREG(0x2080)
#define S5P_ARM_CORE1_STATUS S5P_PMUREG(0x2084)
--
1.7.10.4
^ permalink raw reply related
* [RFC PATCH V2 3/4] arm64: mm: Enable HAVE_RCU_TABLE_FREE logic
From: Ming Lei @ 2014-02-11 2:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391703531-12845-4-git-send-email-steve.capper@linaro.org>
On Fri, Feb 7, 2014 at 12:18 AM, Steve Capper <steve.capper@linaro.org> wrote:
> In order to implement fast_get_user_pages we need to ensure that the
> page table walker is protected from page table pages being freed from
> under it.
>
> This patch enables HAVE_RCU_TABLE_FREE and incorporates it into the
> existing arm64 TLB logic. Any page table pages belonging to address
> spaces with multiple users will be call_rcu_sched freed. Meaning
> that disabling interrupts will block the free and protect the fast
> gup page walker.
>
> Signed-off-by: Steve Capper <steve.capper@linaro.org>
Tested-by: Ming Lei <ming.lei@canonical.com>
Without patch 3 and 4 in this patchset, we can't run go script
successfully with thp enabled on arm64, after applying the two
patches, go can start working.
Thanks,
--
Ming Lei
^ permalink raw reply
* [RFC PATCH V2 4/4] arm64: mm: implement get_user_pages_fast
From: Ming Lei @ 2014-02-11 2:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391703531-12845-5-git-send-email-steve.capper@linaro.org>
On Fri, Feb 7, 2014 at 12:18 AM, Steve Capper <steve.capper@linaro.org> wrote:
> An implementation of get_user_pages_fast for arm64. It is based on the
> arm implementation (it has the added ability to walk huge puds) which
> is loosely on the PowerPC implementation. We disable interrupts in the
> walker to prevent the call_rcu_sched pagetable freeing code from
> running under us.
>
> We also explicitly fire an IPI in the Transparent HugePage splitting
> case to prevent splits from interfering with the fast_gup walker.
> As THP splits are relatively rare, this should not have a noticable
> overhead.
>
> Signed-off-by: Steve Capper <steve.capper@linaro.org>
Tested-by: Ming Lei <ming.lei@canonical.com>
Thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH] video: imxfb: Use regulator API with LCD class for powering
From: Shawn Guo @ 2014-02-11 2:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F8C449.2080502@ti.com>
On Mon, Feb 10, 2014 at 02:21:29PM +0200, Tomi Valkeinen wrote:
> The drivers/video side looks fine. I can either merge this via fbdev
> tree if I get an ack from arch/arm/mach-imx/mach-mx27ads.c's maintainer,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* [PATCH] bus: imx-weim: support weim-cs-gpr for imx6q-weim
From: Shawn Guo @ 2014-02-11 2:50 UTC (permalink / raw)
To: linux-arm-kernel
For imx6q-weim type of device, there might a WEIM CS space configuration
register in General Purpose Register controller, e.g. IOMUXC_GPR1 on
i.MX6Q.
Depending on which configuration of the following 4 is chosen for given
system, IOMUXC_GPR1[11:0] should be set up as 0x5, 0x1b, 0x4b or 0x249
correspondingly.
CS0(128M) CS1(0M) CS2(0M) CS3(0M)
CS0(64M) CS1(64M) CS2(0M) CS3(0M)
CS0(64M) CS1(32M) CS2(32M) CS3(0M)
CS0(32M) CS1(32M) CS2(32M) CS3(32M)
The patch creates a table in the driver for above configurations, and
detects which one is being used for the booting system by looking at
'ranges' property of WEIM node. Thus the WEIM CS GPR can be set up
automatically at boot time.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
Documentation/devicetree/bindings/bus/imx-weim.txt | 6 ++
drivers/bus/imx-weim.c | 83 ++++++++++++++++++++
2 files changed, 89 insertions(+)
diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt
index 0fd76c4..d114460f 100644
--- a/Documentation/devicetree/bindings/bus/imx-weim.txt
+++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
@@ -19,6 +19,12 @@ Required properties:
<cs-number> 0 <physical address of mapping> <size>
+Optional properties:
+
+ - fsl,weim-cs-gpr: Should be the phandle to the General Purpose Register
+ controller that contains WEIM CS GPR register, e.g.
+ IOMUXC_GPR1 on i.MX6Q.
+
Timing property for child nodes. It is mandatory, not optional.
- fsl,weim-cs-timing: The timing array, contains timing values for the
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index 3ef58c8..9c8a522 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -11,6 +11,9 @@
#include <linux/clk.h>
#include <linux/io.h>
#include <linux/of_device.h>
+#include <linux/mfd/syscon.h>
+#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
+#include <linux/regmap.h>
struct imx_weim_devtype {
unsigned int cs_count;
@@ -56,6 +59,83 @@ static const struct of_device_id weim_id_table[] = {
};
MODULE_DEVICE_TABLE(of, weim_id_table);
+struct imx6q_weim_gpr {
+ u32 cssize[4];
+ u32 gprval;
+};
+
+static const struct imx6q_weim_gpr imx6q_weim_gpr_data[] __initconst = {
+ {
+ /* CS0(128M) CS1(0M) CS2(0M) CS3(0M) */
+ .cssize = { 128, 0, 0, 0 },
+ .gprval = 0x5,
+ }, {
+ /* CS0(64M) CS1(64M) CS2(0M) CS3(0M) */
+ .cssize = { 64, 64, 0, 0 },
+ .gprval = 0x1b,
+ }, {
+ /* CS0(64M) CS1(32M) CS2(32M) CS3(0M) */
+ .cssize = { 64, 32, 32, 0 },
+ .gprval = 0x4b,
+ }, {
+ /* CS0(64M) CS1(32M) CS2(32M) CS3(0M) */
+ .cssize = { 32, 32, 32, 32 },
+ .gprval = 0x249,
+ },
+};
+
+static int __init imx6q_weim_gpr_setup(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const struct property *prop;
+ struct regmap *gpr;
+ u32 cssize[4] = { 0, 0, 0, 0 };
+ int len;
+ int ret;
+ int i;
+
+ gpr = syscon_regmap_lookup_by_phandle(np, "fsl,weim-cs-gpr");
+ if (IS_ERR(gpr)) {
+ dev_dbg(&pdev->dev, "No weim-cs-gpr to set up\n");
+ return 0;
+ }
+
+ prop = of_find_property(np, "ranges", &len);
+ if (prop == NULL)
+ return -ENOENT;
+ if (len % (sizeof(u32) * 4))
+ return -EINVAL;
+
+ for (i = 0; i < len / (sizeof(u32) * 4); i++) {
+ int cs;
+ /* read cs index */
+ ret = of_property_read_u32_index(np, "ranges", i * 4, &cs);
+ if (ret)
+ return ret;
+ /* read cs size */
+ ret = of_property_read_u32_index(np, "ranges", i * 4 + 3,
+ &cssize[cs]);
+ if (ret)
+ return ret;
+ /* turn to MB */
+ cssize[cs] >>= 20;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(imx6q_weim_gpr_data); i++) {
+ ret = memcmp(cssize, imx6q_weim_gpr_data[i].cssize,
+ sizeof(cssize));
+ if (ret == 0) {
+ /* Find it. Set up IOMUXC_GPR1[11:0] with the gprval. */
+ regmap_update_bits(gpr, IOMUXC_GPR1, 0xfff,
+ imx6q_weim_gpr_data[i].gprval);
+ return 0;
+ }
+ }
+
+ dev_err(&pdev->dev, "Invalid 'ranges' configuration\n");
+ return -EINVAL;
+}
+
/* Parse and set the timing for this device. */
static int __init weim_timing_setup(struct device_node *np, void __iomem *base,
const struct imx_weim_devtype *devtype)
@@ -92,6 +172,9 @@ static int __init weim_parse_dt(struct platform_device *pdev,
struct device_node *child;
int ret;
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx6q-weim"))
+ imx6q_weim_gpr_setup(pdev);
+
for_each_child_of_node(pdev->dev.of_node, child) {
if (!child->name)
continue;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
From: Kukjin Kim @ 2014-02-11 2:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2286031.FWmKXGrGIV@wuerfel>
On 02/13/14 04:14, Arnd Bergmann wrote:
> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote:
>> On Feb 12, 2014, at 12:12 PM, Catalin Marinas<catalin.marinas@arm.com> wrote:
>>> On 12 Feb 2014, at 16:25, Kumar Gala<galak@codeaurora.org> wrote:
>>>> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it.
>>>
>>> We already converted some of them (those depending on ARCH_VEXPRESS) to
>>> just depend on ARM64. Ideally, at some point I?d like to see them as
>>> defaulting to modules but I don?t think we are there yet (we had some
>>> discussions at the last KS, I?m not sure anyone started looking into
>>> this).
>>
>> I?m torn about this, I think for something like VEXPRESS it makes sense,
>> however I think its reasonable to still have an config symbol for a full
>> SoC family or something of that nature.
>
> I think for SBSA compliant systems, we should be able to live with a
> generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms,
> we may need something more specific.
>
Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need
to define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about
compliant with SBSA Level1 and having some specific features?
- Kukjin
^ permalink raw reply
* [PATCH v4 0/3] serial: fsl_lpuart: add DMA support
From: Shawn Guo @ 2014-02-11 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1c2915231eb4595b89327e589bc521d@BL2PR03MB338.namprd03.prod.outlook.com>
On Tue, Feb 11, 2014 at 01:50:14AM +0000, Yao Yuan wrote:
> Hi, Shawn
>
> Here I just want the DMA be a selectable property for each board.
> Is it suitable?
No, it's not. Just like IRQ line, DMA channel is a SoC level resource.
It should just be there once the SoC is out there. Nothing to do with
board level configuration.
Shawn
>
> > -----Original Message-----
> > From: Shawn Guo [mailto:shawn.guo at linaro.org]
> > Sent: Monday, January 27, 2014 3:50 PM
> > To: Yuan Yao-B46683
> > Cc: gregkh at linuxfoundation.org; linux at arm.linux.org.uk; arnd at arndb.de;
> > mark.rutland at arm.com; linux-arm-kernel at lists.infradead.org; linux-
> > serial at vger.kernel.org
> > Subject: Re: [PATCH v4 0/3] serial: fsl_lpuart: add DMA support
> >
> > On Wed, Jan 22, 2014 at 12:09:30PM +0800, Yuan Yao wrote:
> > > Changed in v4:
> > > - Move dma properties from dtsi to dts.
> >
> > Why this change? DMA is a SoC level resource rather than board one.
> >
> > Shawn
>
^ permalink raw reply
* [PATCH 0/7] Remove HAVE_PWM config option
From: Jingoo Han @ 2014-02-11 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <003901cf25fc$73002790$590076b0$%han@samsung.com>
On Monday, February 10, 2014 10:07 AM, Jingoo Han wrote:
>
> The HAVE_PWM symbol is only for legacy platforms that provide
> the PWM API without using the generic framework, while PWM symbol
> is used for PWM drivers using the generic PWM framework.
>
> I looked at all HAVE_PWMs in the latest mainline kernel 3.14-rc1.
> Three platforms are still using HAVE_PWM as below:
>
> 1. ARM - PXA
> ./arch/arm/mach-pxa/Kconfig
>
> 2. ARM - NXP LPC32XX
> ./arch/arm/Kconfig
> config ARCH_LPC32XX
> select HAVE_PWM
>
> 3. MIPS - Ingenic JZ4740 based machines
> ./arch/mips/Kconfig
> config MACH_JZ4740
> select HAVE_PWM
>
> However, the legacy PWM drivers for PXA, LPC32XX, and JZ474 were
> already moved to the generic PWM framework.
> ./drivers/pwm/pwm-pxa.c
> ./drivers/pwm/pwm-lpc32xx.c
> ./drivers/pwm/pwm-jz4740.c
>
> In conclusion, HAVE_PWM should be removed, because HAVE_PWM is
> NOT required anymore.
>
> Jingoo Han (7):
> ARM: pxa: don't select HAVE_PWM
> ARM: lpc32xx: don't select HAVE_PWM
> ARM: remove HAVE_PWM config option
> MIPS: jz4740: don't select HAVE_PWM
> Input: max8997_haptic: remove HAVE_PWM dependencies
> Input: pwm-beepe: remove HAVE_PWM dependencies
> pwm: don't use IS_ENABLED(CONFIG_HAVE_PWM)
>
> arch/arm/Kconfig | 4 ----
> arch/arm/mach-pxa/Kconfig | 15 ---------------
> arch/mips/Kconfig | 1 -
> drivers/input/misc/Kconfig | 4 ++--
> include/linux/pwm.h | 2 +-
> 5 files changed, 3 insertions(+), 23 deletions(-)
(+cc Sascha Hauer, Roland Stigge)
The same patch was already submitted by Sascha Hauer. [1]
So, please ignore this patch. Thank you.
[1] https://lkml.org/lkml/2014/1/16/262
Best regards,
Jingoo Han
>
> I would like to merge these patches as below:
>
> 1. Through arm-soc tree
> [PATCH 1/7] ARM: pxa: don't select HAVE_PWM
> [PATCH 2/7] ARM: lpc32xx: don't select HAVE_PWM
> [PATCH 3/7] ARM: remove HAVE_PWM config option
>
> 2. Through MIPS tree
> [PATCH 4/7] MIPS: jz4740: don't select HAVE_PWM
>
> 3. Through Input tree
> [PATCH 5/7] Input: max8997_haptic: remove HAVE_PWM dependencies
> [PATCH 6/7] Input: pwm-beepe: remove HAVE_PWM dependencies
>
> 4. Through PWM tree
> [PATCH 7/7] pwm: don't use IS_ENABLED(CONFIG_HAVE_PWM)
>
> After merging these patches, all HAVE_PWM will be removed from
> the mainline kernel. Thank you. :-)
>
> Best regards,
> Jingoo Han
^ permalink raw reply
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
From: Kukjin Kim @ 2014-02-11 3:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FB5DB1.4090609@arm.com>
On 02/12/14 20:40, Marc Zyngier wrote:
> On 12/02/14 11:29, Mark Rutland wrote:
>>>>> + gic: interrupt-controller at 1C000000 {
>>>>> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>>>>
>>>> This looks incorrect -- you should at the very least have a more
>>>> specific one than a15-gic? Marc?
>>>
>>> "arm,cortex-a9-gic" is definitely wrong (the A9 GIC doesn't have the
>>> virt extensions). This binding matches what the A15 GIC has, so
>>> "arm,cortex-a15-gic" is probably fine. Main issue here is that the GICv2
>>> driver has no compatible string for anything else.
>>>
>>> Should we define something more generic (like "arm,gic-v2")? Or carry on
>>> adding more compatible strings?
>>
>> It's been proposed repeatedly, and it probably makes sense to add the
>> generic versions to the driver, and allow for more specific ones in the
>> binding which DTs can use. That way we don't get an explosion of strings
>> in the driver, but if we need to handle any particular GIC specially in
>> future we can do so.
>>
>> I guess for Linux we'd want to add "arm,gic-v1" and "arm,gic-v2" to the
>> driver. We could just add "arm,gic-v1" and expect it later in the
>> compatible list if v2 is a strict superset of v1; I think it is but I'm
>> not a GIC expert.
>
> Sounds good to me.
>
OK, so did you guys agree to use version for gic? I'm fine to use gic-v2.
And so who will take changing for others in mainline? ;-)
- Kukjin
^ permalink raw reply
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
From: Kukjin Kim @ 2014-02-11 3:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140211181529.GC15200@e106331-lin.cambridge.arm.com>
On 02/12/14 03:15, Mark Rutland wrote:
> On Tue, Feb 11, 2014 at 06:29:41AM +0000, Kukjin Kim wrote:
>> Signed-off-by: Kukjin Kim<kgene.kim@samsung.com>
>> Reviewed-by: Thomas Abraham<thomas.ab@samsung.com>
>> Cc: Catalin Marinas<catalin.marinas@arm.com>
>> ---
>> arch/arm64/boot/dts/samsung-gh7.dtsi | 108 ++++++++++++++++++++++++++++++
>> arch/arm64/boot/dts/samsung-ssdk-gh7.dts | 26 +++++++
>> 2 files changed, 134 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/samsung-gh7.dtsi
>> create mode 100644 arch/arm64/boot/dts/samsung-ssdk-gh7.dts
>>
>> diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi b/arch/arm64/boot/dts/samsung-gh7.dtsi
>> new file mode 100644
>> index 0000000..5b8785c
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi
>> @@ -0,0 +1,108 @@
>> +/*
>> + * SAMSUNG GH7 SoC device tree source
>> + *
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * 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.
>> +*/
>> +
>> +/dts-v1/;
>> +
>> +/memreserve/ 0x80000000 0x0C400000;
>
> That looks _very_ large. What is this for?
>
Yes, I know but we need to reserve that for EL3 monitor, UEFI services,
secure, hypervisor and scan chanin...
> [...]
>
>> + timer {
>> + compatible = "arm,armv8-timer";
>> + interrupts =<1 13 0xff01>, /* Secure Phys IRQ */
>> + <1 14 0xff01>, /* Non-secure Phys IRQ */
>> + <1 11 0xff01>, /* Virt IRQ */
>> + <1 10 0xff01>; /* Hyp IRQ */
>> + clock-frequency =<100000000>;
>
> Please, get your bootloader to set CNTFREQ. The clock frequency property
> for the timer node is a horrible hack for buggy firmware.
>
You're right. OK.
> [...]
>
>> + amba {
>> + compatible = "arm,amba-bus";
>> + #address-cells =<1>;
>> + #size-cells =<1>;
>> + ranges;
>> +
>> + serial at 12c00000 {
>> + compatible = "arm,pl011", "arm,primecell";
>> + reg =<0x12c00000 0x10000>;
>> + interrupts =<418>;
>> + };
>> +
>> + serial at 12c20000 {
>> + compatible = "arm,pl011", "arm,primecell";
>> + reg =<0x12c20000 0x10000>;
>> + interrupts =<420>;
>> + };
>
> Don't these need clocks?
>
We don't need and the clocks will be handled by bootloader...
> [...]
>
>> + memory at 80000000 {
>> + device_type = "memory";
>> + reg =<0x00000000 0x80000000 0 0x80000000>;
>
> Minor nit, but it would be nice for the 0 values to be consistently padded.
>
OK.
Thanks,
Kukjin
^ permalink raw reply
* [PATCH 1/3] arm64: dts: add initial dts for Samsung GH7 SoC and SSDK-GH7 board
From: Kukjin Kim @ 2014-02-11 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjE=zOStKoZQhYLhYtL_aWD73DcF4w6STboZPMfHkLtxA@mail.gmail.com>
On 02/12/14 08:36, Olof Johansson wrote:
> Hi,
>
Hi Olof,
> Besides what Mark Rutland already commented on:
>
OK, thanks :-)
> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim<kgene.kim@samsung.com> wrote:
>> +/ {
>> + model = "SAMSUNG GH7";
>> + compatible = "samsung,gh7";
>
> Model and compatible in the dtsi should probably always be overridden
> by a dts that includes it, so there's little use in having it here.
>
OK, makes sense.
>> + interrupt-parent =<&gic>;
>> + #address-cells =<2>;
>> + #size-cells =<2>;
>> +
>> + cpus {
>> + #address-cells =<2>;
>> + #size-cells =<0>;
>> +
>> + cpu at 000 {
>> + device_type = "cpu";
>> + compatible = "arm,armv8";
>> + reg =<0x0 0x000>;
>
> No need to zero-pad cpu numbers in unit address or reg.
>
Yes it's correct without any consideration, but I'm going to add more
cpus next time and they should be separated from this. So I used.
>> + enable-method = "spin-table";
>> + cpu-release-addr =<0x0 0x8000fff8>;
>> + };
>> + cpu at 001 {
>> + device_type = "cpu";
>> + compatible = "arm,armv8";
>> + reg =<0x0 0x001>;
>> + enable-method = "spin-table";
>> + cpu-release-addr =<0x0 0x8000fff8>;
>> + };
>> + cpu at 002 {
>> + device_type = "cpu";
>> + compatible = "arm,armv8";
>> + reg =<0x0 0x002>;
>> + enable-method = "spin-table";
>> + cpu-release-addr =<0x0 0x8000fff8>;
>> + };
>> + cpu at 003 {
>> + device_type = "cpu";
>> + compatible = "arm,armv8";
>> + reg =<0x0 0x003>;
>> + enable-method = "spin-table";
>> + cpu-release-addr =<0x0 0x8000fff8>;
>> + };
>> + };
>> +
>> + gic: interrupt-controller at 1C000000 {
>> + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
>
> This looks incorrect -- you should at the very least have a more
> specific one than a15-gic? Marc?
>
OK, you're right. And I replied on other e-mail.
Thanks,
Kukjin
^ permalink raw reply
* [PATCH 13/28] Remove S3C24XX_GPIO_EXTRA64
From: Kukjin Kim @ 2014-02-11 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391971686-9517-14-git-send-email-richard@nod.at>
On 02/10/14 03:47, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger<richard@nod.at>
> ---
> arch/arm/mach-s3c24xx/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index d876431..1c67f04 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -521,7 +521,6 @@ config MACH_ANUBIS
> select HAVE_PATA_PLATFORM
> select S3C2440_XTAL_12000000
> select S3C24XX_DCLK
> - select S3C24XX_GPIO_EXTRA64
> select S3C24XX_SIMTEC_PM if PM
> select S3C_DEV_USB_HOST
> help
OK, I will take this into samsung tree.
Thanks,
Kukjin
^ permalink raw reply
* [PATCH 22/28] Remove S3C24XX_GPIO_EXTRA128
From: Kukjin Kim @ 2014-02-11 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391971686-9517-23-git-send-email-richard@nod.at>
On 02/10/14 03:48, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger<richard@nod.at>
> ---
> arch/arm/mach-s3c24xx/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index 1c67f04..bb1fa603 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -561,7 +561,6 @@ config MACH_OSIRIS
> select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
> select S3C2440_XTAL_12000000
> select S3C24XX_DCLK
> - select S3C24XX_GPIO_EXTRA128
> select S3C24XX_SIMTEC_PM if PM
> select S3C_DEV_NAND
> select S3C_DEV_USB_HOST
OK good, but I will squash this with 13th for mach-s3c24xx/Kconfig when
I apply.
Thanks,
Kukjin
^ permalink raw reply
* [PATCHv3 2/2] arm: Get rid of meminfo
From: Kukjin Kim @ 2014-02-11 3:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392153265-14439-3-git-send-email-lauraa@codeaurora.org>
On 02/12/14 06:14, Laura Abbott wrote:
> memblock is now fully integrated into the kernel and is the prefered
> method for tracking memory. Rather than reinvent the wheel with
> meminfo, migrate to using memblock directly instead of meminfo as
> an intermediate.
>
> Acked-by: Jason Cooper<jason@lakedaemon.net>
> Acked-by: Catalin Marinas<catalin.marinas@arm.com>
> Acked-by: Santosh Shilimkar<santosh.shilimkar@ti.com>
> Tested-by: Leif Lindholm<leif.lindholm@linaro.org>
> Signed-off-by: Laura Abbott<lauraa@codeaurora.org>
> ---
> arch/arm/include/asm/mach/arch.h | 4 +-
> arch/arm/include/asm/memblock.h | 3 +-
> arch/arm/include/asm/setup.h | 23 ------
> arch/arm/kernel/atags_parse.c | 5 +-
> arch/arm/kernel/devtree.c | 5 --
> arch/arm/kernel/setup.c | 30 ++------
> arch/arm/mach-clps711x/board-clep7312.c | 7 +-
> arch/arm/mach-clps711x/board-edb7211.c | 10 +--
> arch/arm/mach-clps711x/board-p720t.c | 2 +-
> arch/arm/mach-footbridge/cats-hw.c | 2 +-
> arch/arm/mach-footbridge/netwinder-hw.c | 2 +-
> arch/arm/mach-msm/board-halibut.c | 6 --
> arch/arm/mach-msm/board-mahimahi.c | 13 +---
> arch/arm/mach-msm/board-msm7x30.c | 3 +-
> arch/arm/mach-msm/board-sapphire.c | 13 ++--
> arch/arm/mach-msm/board-trout.c | 8 +--
> arch/arm/mach-orion5x/common.c | 3 +-
> arch/arm/mach-orion5x/common.h | 3 +-
> arch/arm/mach-pxa/cm-x300.c | 3 +-
> arch/arm/mach-pxa/corgi.c | 10 +--
> arch/arm/mach-pxa/eseries.c | 9 +--
> arch/arm/mach-pxa/poodle.c | 8 +--
> arch/arm/mach-pxa/spitz.c | 8 +--
> arch/arm/mach-pxa/tosa.c | 8 +--
> arch/arm/mach-realview/core.c | 11 +--
> arch/arm/mach-realview/core.h | 3 +-
> arch/arm/mach-realview/realview_pb1176.c | 8 +--
> arch/arm/mach-realview/realview_pbx.c | 17 ++---
> arch/arm/mach-s3c24xx/mach-smdk2413.c | 8 +--
> arch/arm/mach-s3c24xx/mach-vstms.c | 8 +--
For s3c24xx,
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> arch/arm/mach-sa1100/assabet.c | 2 +-
> arch/arm/mm/init.c | 67 +++++++-----------
> arch/arm/mm/mmu.c | 115 +++++++++---------------------
> 33 files changed, 136 insertions(+), 291 deletions(-)
Thanks,
Kukjin
^ permalink raw reply
* [PATCH] ARM: pxa: Add dummy backlight power supply on Mitac Mio A701
From: Haojian Zhuang @ 2014-02-11 3:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k3deiuox.fsf@free.fr>
On 02/02/2014 01:55 AM, Robert Jarzmik wrote:
> Robert Jarzmik <robert.jarzmik@free.fr> writes:
>>> Hi Arnd,
>>>
>>> I cannot reach Haojian, and my platform is currently screen-broken without
>>> Thierry's patch (see [1] and [2]). I'm trying to have it since -rc6, with no luck.
> ... zip ...
>
> Hi Eric and Russell,
>
> Since more than a month I've been trying to have a fix applied in the PXA tree,
> since v3.13-rc6. I cannot reach Haojian, and Arnd seems unresponsive too.
>
> The history mails are in [1], the patch in [2].
>
> Your are the 2 other maintainers of the PXA tree, Could you please help me ?
>
> Cheers.
>
> --
> Robert
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/223116.html
>
>
> [2]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/221013.html
>
> ---8>---
>
> From: Thierry Reding <thierry.reding@gmail.com>
> Subject: [PATCH] ARM: pxa: Add dummy backlight power supply on Mitac Mio A701
> To: Haojian Zhuang <haojian.zhuang@gmail.com>, Robert Jarzmik <robert.jarzmik@free.fr>
> Cc: linux-pwm at vger.kernel.org, linux-arm-kernel at lists.infradead.org
> Date: Fri, 20 Dec 2013 10:46:52 +0100 (6 weeks, 1 day, 8 hours ago)
> Message-Id: <1387532812-11742-1-git-send-email-thierry.reding@gmail.com>
> X-Mailer: git-send-email 1.8.4.2
>
> Recent changes to the pwm-backlight driver have made the power supply
> mandatory. There is code in the regulator core to deal with situations
> where no regulator is specified and provide a dummy, but that works on
> DT-based boards only.
>
> The situation can be remedied by adding a dummy regulator during board
> initialization.
>
> Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
> ---
> arch/arm/mach-pxa/mioa701.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
> index f70583fee59f..29997bde277d 100644
> --- a/arch/arm/mach-pxa/mioa701.c
> +++ b/arch/arm/mach-pxa/mioa701.c
> @@ -38,6 +38,7 @@
> #include <linux/mtd/physmap.h>
> #include <linux/usb/gpio_vbus.h>
> #include <linux/reboot.h>
> +#include <linux/regulator/fixed.h>
> #include <linux/regulator/max1586.h>
> #include <linux/slab.h>
> #include <linux/i2c/pxa-i2c.h>
> @@ -714,6 +715,10 @@ static struct gpio global_gpios[] = {
> { GPIO56_MT9M111_nOE, GPIOF_OUT_INIT_LOW, "Camera nOE" },
> };
>
> +static struct regulator_consumer_supply fixed_5v0_consumers[] = {
> + REGULATOR_SUPPLY("power", "pwm-backlight"),
> +};
> +
> static void __init mioa701_machine_init(void)
> {
> int rc;
> @@ -753,6 +758,10 @@ static void __init mioa701_machine_init(void)
> pxa_set_i2c_info(&i2c_pdata);
> pxa27x_set_i2c_power_info(NULL);
> pxa_set_camera_info(&mioa701_pxacamera_platform_data);
> +
> + regulator_register_always_on(0, "fixed-5.0V", fixed_5v0_consumers,
> + ARRAY_SIZE(fixed_5v0_consumers),
> + 5000000);
> }
>
> static void mioa701_machine_exit(void)
>
Hi Robert,
Excuse me to response late. Now it's applied.
Regards
Haojian
^ permalink raw reply
* [GIT PULL][for v3.14] pull request from pxa to fix PWM
From: Haojian Zhuang @ 2014-02-11 3:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Please help to merge this pull request for pxa git tree.
The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/hzhuang1/linux.git
tags/pwm_pxa_for_v3.14
for you to fetch changes up to 902e6a0c7eba08ec978cea8304c6cb2ddce7b9dc:
ARM: pxa: Add dummy backlight power supply on Mitac Mio A701
(2014-02-11 11:33:09 +0800)
----------------------------------------------------------------
Thierry Reding (1):
ARM: pxa: Add dummy backlight power supply on Mitac Mio A701
arch/arm/mach-pxa/mioa701.c | 9 +++++++++
1 file changed, 9 insertions(+)
Best Regards
Haojian
^ permalink raw reply
* [PATCH V5 4/8] phy: st-miphy-40lp: Add skeleton driver
From: Mohit KUMAR DCG @ 2014-02-11 3:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201402101654.22187.arnd@arndb.de>
Hello Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Monday, February 10, 2014 9:24 PM
> To: Mohit KUMAR DCG
> Cc: Pratyush ANAND; Kishon Vijay Abraham I; spear-devel; linux-arm-
> kernel at lists.infradead.org; devicetree at vger.kernel.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH V5 4/8] phy: st-miphy-40lp: Add skeleton driver
>
> On Monday 10 February 2014, Mohit Kumar wrote:
> > diff --git a/Documentation/devicetree/bindings/phy/st-miphy40lp.txt
> > b/Documentation/devicetree/bindings/phy/st-miphy40lp.txt
> > new file mode 100644
> > index 0000000..d0c7096
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/st-miphy40lp.txt
> > @@ -0,0 +1,12 @@
> > +Required properties:
> > +- compatible : should be "st,miphy40lp-phy"
> > + Other supported soc specific compatible:
> > + "st,spear1310-miphy"
> > + "st,spear1340-miphy"
> > +- reg : offset and length of the PHY register set.
> > +- misc: phandle for the syscon node to access misc registers
> > +- phy-id: Instance id of the phy.
> > +- #phy-cells : from the generic PHY bindings, must be 1.
> > + - 1st cell: phandle to the phy node.
> > + - 2nd cell: 0 if phy (in 1st cell) is to be used for SATA, 1 for PCIe
> > + and 2 for Super Speed USB.
>
> It's common to start this file with a small header explaining what this
> hardware is.
- OK
>
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
> > afa2354..2f58993 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -64,4 +64,10 @@ config BCM_KONA_USB2_PHY
> > help
> > Enable this to support the Broadcom Kona USB 2.0 PHY.
> >
> > +config PHY_ST_MIPHY40LP
> > + tristate "ST MIPHY 40LP driver"
> > + help
> > + Support for ST MIPHY 40LP which can be used for PCIe, SATA and
> Super Speed USB.
> > + select GENERIC_PHY
> > +
> > endmenu
>
> The 'select' statement should come before 'help', for consistency with the
> rest of the kernel.
- OK
> Maybe mention that this phy is used inside the spear13xx
> SoC here rather than a standalone phy.
- Yes, for spear13xx its used internally. Do you think that it requires to be mentioned here?
We have few prototype boards that uses this as external phy.
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv) {
> > + dev_err(dev, "can't alloc miphy40lp private date
> memory\n");
> > + return -ENOMEM;
> > + }
> > +
> > + priv->plat_ops = (struct miphy40lp_plat_ops *)of_id->data;
>
> The cast would incorrectly remove the 'const' attribute of the pointer.
> Better remove the cast and make priv->plat_ops const.
- OK
>
> > +static int __init miphy40lp_phy_init(void) {
> > +
> > + return platform_driver_probe(&miphy40lp_driver,
> > + miphy40lp_probe);
> > +}
> > +module_init(miphy40lp_phy_init);
>
> There should certainly be a module_exit() function here so you can unload
> the driver.
- yes, will add it in v6.
Thanks
Mohit
>
> Arnd
^ permalink raw reply
* [PATCH V2 2/3] ARM: dts: add dts files for exynos5260 SoC
From: Rahul Sharma @ 2014-02-11 5:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52F38C42.5030508@samsung.com>
Hi Tomasz,
On 6 February 2014 18:51, Tomasz Figa <t.figa@samsung.com> wrote:
> Hi Rahul, Pankaj, Arun,
>
> [adding linux-arm-kernel, devicetree MLs and DT people on Cc]
>
> I think it's good time to stop accepting DTS files like this and force new
> ones to use the proper structure with soc node, labels for every node and
> node references.
I am unable to find information on SoC node and grouping inside SoC node. Please
share some pointers.
>
> In case of previous Exynos 5 SoCs I hadn't complained, because they shared a
> lot of data with already existing exynos5.dtsi, but since Exynos5260 is
> completely different, I'd say it should be converted to the new layout.
>
> As an example you can look at arch/arm/boot/dts/s3c64xx.dtsi and files that
> include it or, for more complete structures, DTS of other platforms, such as
> imx6*.
>
> Btw. Please remember that linux-samsung-soc mailing list is just a
> convenient utility for reviewers of Samsung-specific patches to have all of
> them in one place. Sending patches to it alone is not enough - a general
> kernel ML list needs to be CCed as well, in this case linux-arm-kernel.
>
I will take care of this.
> Also, please see my comments inline, for review comments unrelated to the
> issue described above.
>
>
> On 05.02.2014 06:16, Rahul Sharma wrote:
>>
>> The patch adds the dts files for exynos5260.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
>> Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
>> ---
>> arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 572
>> +++++++++++++++++++++++++++++
>> arch/arm/boot/dts/exynos5260.dtsi | 317 ++++++++++++++++
>> 2 files changed, 889 insertions(+)
>> create mode 100644 arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> create mode 100644 arch/arm/boot/dts/exynos5260.dtsi
>>
>> diff --git a/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> new file mode 100644
>> index 0000000..3f2c5c4
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5260-pinctrl.dtsi
>> @@ -0,0 +1,572 @@
>> +/*
>> + * Samsung's Exynos5260 SoC pin-mux and pin-config device tree source
>> + *
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * Samsung's Exynos5260 SoC pin-mux and pin-config options are listed as
>> device
>> + * tree nodes are listed in this file.
>> + *
>> + * 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.
>> +*/
>> +
>> +/ {
>> + pinctrl at 11600000 {
>
>
> [snip]
>
>
>> + spi0_bus: spi0-bus {
>> + samsung,pins = "gpa2-0", "gpa2-1", "gpa2-2",
>> "gpa2-3";
>
>
> What is the reason for SPI0 to have 4 pins, while SPI1 has just 3?
>
I should align SPI1 with SPI0.
>
>> + samsung,pin-function = <2>;
>> + samsung,pin-pud = <3>;
>> + samsung,pin-drv = <0>;
>> + };
>
>
> [snip]
>
>
>> diff --git a/arch/arm/boot/dts/exynos5260.dtsi
>> b/arch/arm/boot/dts/exynos5260.dtsi
>> new file mode 100644
>> index 0000000..32a95c7
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5260.dtsi
>> @@ -0,0 +1,317 @@
>> +/*
>> + * SAMSUNG EXYNOS5260 SoC device tree source
>> + *
>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +#include "skeleton.dtsi"
>> +#include "exynos5260-pinctrl.dtsi"
>> +
>> +#include <dt-bindings/clk/exynos5260-clk.h>
>> +
>> +/ {
>> + compatible = "samsung,exynos5260";
>> + interrupt-parent = <&gic>;
>> +
>> + aliases {
>> + pinctrl0 = &pinctrl_0;
>> + pinctrl1 = &pinctrl_1;
>> + pinctrl2 = &pinctrl_2;
>> + };
>> +
>> + chipid at 10000000 {
>> + compatible = "samsung,exynos4210-chipid";
>> + reg = <0x10000000 0x100>;
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu at 0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a15";
>> + reg = <0>;
>
>
> nit: Please make this consistent with CPUs 10x below, by using hex here as
> well.
>
Done.
>
>> + cci-control-port = <&cci_control1>;
>> + };
>
>
> nit: Please keep 1 blank line of spacing between nodes.
>
ok.
>
>> + cpu at 1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a15";
>> + reg = <1>;
>> + cci-control-port = <&cci_control1>;
>> + };
>> + cpu at 100 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x100>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu at 101 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x101>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu at 102 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x102>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + cpu at 103 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a7";
>> + reg = <0x103>;
>> + cci-control-port = <&cci_control0>;
>> + };
>> + };
>> +
>> + cmus {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>
>
> I don't think there is a need to group these nodes under a parent node that
> doesn't give any additional information, especially when the CMUs are
> scattered trough the whole address space, while we'd like to keep the nodes
> ordered by their addresses, as most platforms do.
>
This is exactly the same case as "cpus". I mean, "cpus" also doesn't provide
any common information about child cpu nodes. This looks to me as a logical
grouping and I have implemented same thing for cmu nodes.
I am ok with removing this grouping Just want to understand the rational behind
grouping cpus which seems similar to cmus.
Similarly "soc" is just a logical entity used to group SoC elements which looks
optional to me. What are we achieving with this? Please help me in understanding
this better.
>
>> + cmu_top: clock-controller at 10010000 {
>> + compatible = "exynos5260-cmu-top",
>> "samsung,exynos5260-clock";
>
>
> I don't think that having the "samsung,exynos5260-clock" compatible string
> for every CMU is appropriate here, because there is no way to automatically
> recognize which CMU it is. Since every CMU instance is different, they need
> to have different compatible strings.
>
Changed.
>
>> + reg = <0x10010000 0x10000>;
>> + #clock-cells = <1>;
>> + };
>
>
> [snip]
>
>
>> + mct at 100B0000 {
>> + compatible = "samsung,exynos4210-mct";
>> + reg = <0x100B0000 0x1000>;
>> + interrupt-controller;
>> + #interrups-cells = <1>;
>
>
> MCT is not an interrupt controller, so the 2 properties above are incorrect.
>
Agree. I will change this.
>
>> + interrupt-parent = <&mct_map>;
>> + interrupts = <0>, <1>, <2>, <3>,
>> + <4>, <5>, <6>, <7>,
>> + <8>, <9>, <10>, <11>;
>> + clocks = <&cmu_top FIN_PLL>, <&cmu_peri PERI_CLK_MCT>;
>> + clock-names = "fin_pll", "mct";
>> +
>> + mct_map: mct-map {
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = <0 &gic 0 104 0>,
>> + <1 &gic 0 105 0>,
>> + <2 &gic 0 106 0>,
>> + <3 &gic 0 107 0>,
>> + <4 &gic 0 122 0>,
>> + <5 &gic 0 123 0>,
>> + <6 &gic 0 124 0>,
>> + <7 &gic 0 125 0>,
>> + <8 &gic 0 126 0>,
>> + <9 &gic 0 127 0>,
>> + <10 &gic 0 128 0>,
>> + <11 &gic 0 129 0>;
>> + };
>
>
> There is no need for interrupt-map here, because all the interrupts are from
> GIC.
>
Done.
Regards,
Rahul Sharma.
>> + };
>
>
> [snip]
>
>
>> + mmc_0: mmc0 at 12140000 {
>> + compatible = "samsung,exynos5250-dw-mshc";
>> + reg = <0x12140000 0x2000>;
>> + interrupts = <0 156 0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + clocks = <&cmu_fsys FSYS_CLK_MMC0>, <&cmu_top
>> TOP_SCLK_MMC0>;
>> + clock-names = "biu", "ciu";
>> + fifo-depth = <0x40>;
>
>
> nit: It might be more readable to use decimal 64 here.
>
> Best regards,
> Tomasz
^ permalink raw reply
* [PATCH v4 0/3] serial: fsl_lpuart: add DMA support
From: Yao Yuan @ 2014-02-11 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140211025932.GB31484@S2101-09.ap.freescale.net>
> -----Original Message-----
> From: Shawn Guo [mailto:shawn.guo at linaro.org]
> Sent: Tuesday, February 11, 2014 11:00 AM
> To: Yuan Yao-B46683
> Cc: gregkh at linuxfoundation.org; linux at arm.linux.org.uk; arnd at arndb.de;
> mark.rutland at arm.com; linux-arm-kernel at lists.infradead.org; linux-
> serial at vger.kernel.org
> Subject: Re: [PATCH v4 0/3] serial: fsl_lpuart: add DMA support
>
> On Tue, Feb 11, 2014 at 01:50:14AM +0000, Yao Yuan wrote:
> > Hi, Shawn
> >
> > Here I just want the DMA be a selectable property for each board.
> > Is it suitable?
>
> No, it's not. Just like IRQ line, DMA channel is a SoC level resource.
> It should just be there once the SoC is out there. Nothing to do with
> board level configuration.
>
> Shawn
Here I also have a confusion.
IRQ is must. But DMA isn't very necessary.
How to deal with if one board is need DMA but another is not need?
You mean if DMA is be support once all of them must use dma as first?
--
Best Regards,
YuanYao
>
> >
> > > -----Original Message-----
> > > From: Shawn Guo [mailto:shawn.guo at linaro.org]
> > > Sent: Monday, January 27, 2014 3:50 PM
> > > To: Yuan Yao-B46683
> > > Cc: gregkh at linuxfoundation.org; linux at arm.linux.org.uk;
> > > arnd at arndb.de; mark.rutland at arm.com;
> > > linux-arm-kernel at lists.infradead.org; linux- serial at vger.kernel.org
> > > Subject: Re: [PATCH v4 0/3] serial: fsl_lpuart: add DMA support
> > >
> > > On Wed, Jan 22, 2014 at 12:09:30PM +0800, Yuan Yao wrote:
> > > > Changed in v4:
> > > > - Move dma properties from dtsi to dts.
> > >
> > > Why this change? DMA is a SoC level resource rather than board one.
> > >
> > > Shawn
> >
^ permalink raw reply
* [PATCH v3 2/5] clocksource: qcom: Move clocksource code out of mach-msm
From: Stephen Boyd @ 2014-02-11 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391725484-6673-3-git-send-email-galak@codeaurora.org>
On 02/06, Kumar Gala wrote:
> diff --git a/arch/arm/mach-msm/timer.c b/drivers/clocksource/qcom-timer.c
> similarity index 98%
> rename from arch/arm/mach-msm/timer.c
> rename to drivers/clocksource/qcom-timer.c
> index fd16449..dca829e 100644
> --- a/arch/arm/mach-msm/timer.c
> +++ b/drivers/clocksource/qcom-timer.c
> @@ -1,7 +1,7 @@
> /*
> *
> * Copyright (C) 2007 Google, Inc.
> - * Copyright (c) 2009-2012, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2009-2012,2014, The Linux Foundation. All rights reserved.
> *
> * This software is licensed under the terms of the GNU General Public
> * License version 2, as published by the Free Software Foundation, and
> @@ -26,10 +26,6 @@
> #include <linux/of_irq.h>
> #include <linux/sched_clock.h>
>
> -#include <asm/mach/time.h>
> -
> -#include "common.h"
> -
This will cause sparse warnings because we no longer have the header included.
CHECK drivers/clocksource/qcom-timer.c
drivers/clocksource/qcom-timer.c:304:13: warning: symbol 'msm7x01_timer_init' was not declared. Should it be static?
drivers/clocksource/qcom-timer.c:317:13: warning: symbol 'msm7x30_timer_init' was not declared. Should it be static?
drivers/clocksource/qcom-timer.c:324:13: warning: symbol 'qsd8x50_timer_init' was not declared. Should it be static?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v4 0/3] serial: fsl_lpuart: add DMA support
From: Shawn Guo @ 2014-02-11 5:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c2b2798647d44d3c950ce17f23551555@DM2PR03MB349.namprd03.prod.outlook.com>
On Tue, Feb 11, 2014 at 05:34:49AM +0000, Yao Yuan wrote:
> Here I also have a confusion.
> IRQ is must. But DMA isn't very necessary.
> How to deal with if one board is need DMA but another is not need?
> You mean if DMA is be support once all of them must use dma as first?
That's the point. Why whether using DMA or not is a board decision?
The DMA resource should be defined at SoC level from the beginning
just like IO and interrupt resource. And using DMA or PIO should be a
decision made by device driver not device tree.
Shawn
^ 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