* [PATCH 14/26] mfd: ab8500-debugfs: Fix introduced compiler time warnings
From: Samuel Ortiz @ 2013-01-27 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358254566-12419-15-git-send-email-lee.jones@linaro.org>
Hi Lee,
On Tue, Jan 15, 2013 at 12:55:54PM +0000, Lee Jones wrote:
> From: Philippe Langlais <philippe.langlais@stericsson.com>
>
> Some simple fixes regarding pre-processor usage.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
> ---
> drivers/mfd/ab8500-debugfs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Here again, please squash this one with the previous one.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [PATCH 25/26] mfd: ab8500-gpadc: Reduce conversion timeout
From: Samuel Ortiz @ 2013-01-27 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358254566-12419-26-git-send-email-lee.jones@linaro.org>
Hi Lee,
On Tue, Jan 15, 2013 at 12:56:05PM +0000, Lee Jones wrote:
> @@ -598,8 +601,6 @@ static int ab8500_gpadc_runtime_resume(struct device *dev)
>
> static int ab8500_gpadc_runtime_idle(struct device *dev)
> {
> - struct ab8500_gpadc *gpadc = dev_get_drvdata(dev);
> -
Unrelated change, please remove that part.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [PATCH 23/26] mfd: ab8500-pwm: Enable support for AB8505 PWMLED blink
From: Samuel Ortiz @ 2013-01-27 23:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358254566-12419-24-git-send-email-lee.jones@linaro.org>
Hi Lee,
On Tue, Jan 15, 2013 at 12:56:03PM +0000, Lee Jones wrote:
> From: Naga Radhesh <naga.radheshy@stericsson.com>
>
> Enable support for PWM OUT LED blinking for AB8505. Instead of
> having 3 pwm instances from ab8500 core file add it as platform data.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Naga Radhesh <naga.radheshy@stericsson.com>
> Reviewed-by: Arun MURTHY <arun.murthy@stericsson.com>
> Reviewed-by: Srinidhi KASAGAR <srinidhi.kasagar@stericsson.com>
> ---
> drivers/mfd/ab8500-core.c | 10 --
> drivers/misc/ab8500-pwm.c | 282 ++++++++++++++++++++++++++++++++++++
> include/linux/mfd/ab8500/pwmleds.h | 20 +++
> include/linux/mfd/abx500/ab8500.h | 2 +
> 4 files changed, 304 insertions(+), 10 deletions(-)
> create mode 100644 drivers/misc/ab8500-pwm.c
This pretty much looks like the already existing and PWM API compliant
drivers/pwm/ab8500-pwm.c. What's the point here ?
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [PATCH 26/26] mfd: ab8500-gpadc: Use new ab8500_gpadc_get() with name parameter
From: Samuel Ortiz @ 2013-01-27 23:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358254566-12419-27-git-send-email-lee.jones@linaro.org>
Hi Lee,
On Tue, Jan 15, 2013 at 12:56:06PM +0000, Lee Jones wrote:
> From: Philippe Langlais <philippe.langlais@linaro.org>
>
> The new format of ab8500_gpadc_get() accepts a device name as a
> parameter to specify which device to retrieve. This patch
> enforces the use of that new format.
Where is that new API coming from ? I couldn't find it in the previous 25
patches. If it's there, this one should be merged with the patch that changes
this API.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [PATCH 01/19] ARM: shmobile: fix defconfig warning on CONFIG_USB
From: Simon Horman @ 2013-01-28 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359153858-31992-2-git-send-email-arnd@arndb.de>
On Fri, Jan 25, 2013 at 10:44:00PM +0000, Arnd Bergmann wrote:
> A recent update to the marzen_defconfig introduced a
> duplicate CONFIG_USB=y line. This removes one of the
> two.
>
> arch/arm/configs/marzen_defconfig:86:warning: override: reassigning to symbol USB
Acked-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH 12/15] ARM: mach-shmobile: sh73a0: Allow initialisation of GIC by DT
From: Simon Horman @ 2013-01-28 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125102210.GJ3075@e106331-lin.cambridge.arm.com>
On Fri, Jan 25, 2013 at 10:22:10AM +0000, Mark Rutland wrote:
> On Fri, Jan 25, 2013 at 03:55:30AM +0000, Simon Horman wrote:
> > This allows the GIC interrupt controller of the sh73a0 SoC to be
> > initialised using a flattened device tree blob.
> >
> > It does not allow the INTC interrupt controller which is also present on
> > the sh73a0 SoC to be enabled via device tree. Nor does it handle sharing
> > of interrupts between the GIC and INTC interrupt controllers.
> >
> > This limits the usefulness of this code to applications which only wish to
> > access devices which use interrupts that can be handled by the GIC
> > interrupt controller. Other applications should, for now, continue using
> > non-device tree initialisation of the sh72a0 interrupt controllers.
> >
> > Includes update to use irqchip_init() by Thierry Reding
> >
> > Cc: Thierry Reding <thierry.reding@avionic-design.de>
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> > arch/arm/boot/dts/sh73a0.dtsi | 33 ++++++++++++++++++++++++++
> > arch/arm/mach-shmobile/include/mach/common.h | 1 +
> > arch/arm/mach-shmobile/intc-sh73a0.c | 9 +++++++
> > 3 files changed, 43 insertions(+)
> > create mode 100644 arch/arm/boot/dts/sh73a0.dtsi
> >
> > diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
> > new file mode 100644
> > index 0000000..7dae1f4
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/sh73a0.dtsi
> > @@ -0,0 +1,33 @@
> > +/*
> > + * Device Tree Source for the SH73A0 SoC
> > + *
> > + * Copyright (C) 2012 Renesas Solutions Corp.
> > + *
> > + * This file is licensed under the terms of the GNU General Public License
> > + * version 2. This program is licensed "as is" without any warranty of any
> > + * kind, whether express or implied.
> > + */
> > +
> > +/include/ "skeleton.dtsi"
> > +
> > +/ {
> > + compatible = "renesas,sh73a0";
> > +
> > + cpus {
> > + cpu at 0 {
> > + compatible = "arm,cortex-a9";
> > + };
> > + cpu at 1 {
> > + compatible = "arm,cortex-a9";
> > + };
>
> I replied to v1, not realising you'd posted a v2:
>
> It would be good to have the reg and device_type properties set here for the
> logical map.
Thanks.
I'd prefer to handle this as an incremental patch to be applied after the
pull-request in which the patch above appears. The patch below is what
I have in mind.
I also believe that the following files seem to be targets for a similar
change. The latter two are for UP boards, could you comment on if reg
and device_type are appropriate for them too.
arch/arm/boot/dts/emev2.dtsi
arch/arm/boot/dts/r8a7740.dtsi
arch/arm/boot/dts/sh7372.dtsi
From: Simon Horman <horms+renesas@verge.net.au>
ARM: mach-shmobile: sh73a0: Add reg and device_type properties to cpus
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
diff --git a/arch/arm/boot/dts/sh73a0.dtsi b/arch/arm/boot/dts/sh73a0.dtsi
index 721f486..f202298 100644
--- a/arch/arm/boot/dts/sh73a0.dtsi
+++ b/arch/arm/boot/dts/sh73a0.dtsi
@@ -15,10 +15,14 @@
cpus {
cpu at 0 {
+ device_type = "cpu";
compatible = "arm,cortex-a9";
+ reg = <0>;
};
cpu at 1 {
+ device_type = "cpu";
compatible = "arm,cortex-a9";
+ reg = <1>;
};
};
^ permalink raw reply related
* [PATCH 0/3] ARM: shmobile: sh-eth pins in DT for armadillo800eva
From: Simon Horman @ 2013-01-28 1:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1531226.VAPa4M6s5W@avalon>
On Fri, Jan 25, 2013 at 10:57:08AM +0100, Laurent Pinchart wrote:
> Hi Simon,
>
> On Friday 25 January 2013 18:05:44 Simon Horman wrote:
> > On Fri, Jan 25, 2013 at 09:09:54AM +0100, Guennadi Liakhovetski wrote:
> > > On Fri, 25 Jan 2013, Simon Horman wrote:
> > > > On Thu, Jan 24, 2013 at 05:07:30PM +0100, Guennadi Liakhovetski wrote:
> > > > > This patch series gets rid of gpio_request()-style ethernet pin
> > > > > configuration on armadillo800eva in reference implementation.
> > > >
> > > > Hi Guennadi,
> > > >
> > > > these changes seem to be reasonable to me.
> > > >
> > > > Are there any dependencies for the sh_eth patch?
> > > > I assume this will be handled by David Miller through the net-next tree.
> > > > Are there any dependencies? The last time I checked the DT bindings
> > > > for sh_eth had not been merged.
> > >
> > > Obviously, it can only be applied, if the
> > > Documentation/devicetree/bindings/net/sh_ether.txt file and the
> > > sh_eth_parse_dt() function exist. Also, if there are no objections against
> > > the new phy-reset-gpios DT property. Otherwise there are no dependencies -
> > > as long as the phy-reset-gpios property isn't found in DT, the patch
> > > doesn't affect the driver.
> >
> > Thanks, I'm slightly concerned that the other patch(es) relating
> > to Documentation/devicetree/bindings/net/sh_ether.txt have gone missing in
> > action.
> >
> > Do you have an interest in chasing them down or would you like me to?
> >
> > > > For the remaining two patches, which I assume will go through my renesas
> > > > tree:
> > > > * Are there any dependencies that aren't satisfied by the of-intc
> > > > branch?
> > >
> > > AFAICS, that your branch doesn't contain Laurent's pinctrl patches, which
> > > are needed for patch 1 to apply and for patch 3 to make sense. My earlier
> > > MMC DT / pinctrl patches aren't required for these patches to function,
> > > but these patches won't apply cleanly without them, since they touch the
> > > same code fragments. So, it would be easier to merge them in the order of
> > > submission.
> > >
> > > > * Could you get some Acks. At least from Laurent?
> > >
> > > Sure, let's give reviewers some more time :)
> >
> > Indeed.
> >
> > Laurent, if there are patches ready for me to take into the renesas tree
> > please let me know. I'm reluctant to add any more pinmux changes for 3.9.
> > But if a topic branch would help let me know.
>
> I'd like the gpio_request_one() patches to go to v3.9 if possible. The other
> pinctrl patches will need to wait until v3.10 I'm afraid.
Understood. I have now queued the gpio_request_one() patches up for v3.9.
^ permalink raw reply
* [PATCH 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Simon Horman @ 2013-01-28 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130125092527.GA6619@arm.com>
On Fri, Jan 25, 2013 at 09:25:28AM +0000, Catalin Marinas wrote:
> On Fri, Jan 25, 2013 at 04:30:39AM +0000, Simon Horman wrote:
> > On Wed, Jan 23, 2013 at 05:59:34PM +0000, Catalin Marinas wrote:
> > > All the calls to gic_secondary_init() pass 0 as the first argument.
> > > Since this function is called on each CPU when starting, it can be done
> > > in a platform-independent way via a CPU notifier registered by the GIC
> > > code.
> > >
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Cc: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: Kukjin Kim <kgene.kim@samsung.com>
> > > Cc: Rob Herring <rob.herring@calxeda.com>
> > > Cc: Sascha Hauer <kernel@pengutronix.de>
> > > Cc: David Brown <davidb@codeaurora.org>
> > > Cc: Daniel Walker <dwalker@fifo99.com>
> > > Cc: Bryan Huntsman <bryanh@codeaurora.org>
> > > Cc: Tony Lindgren <tony@atomide.com>
> > > Cc: Simon Horman <horms@verge.net.au>
> > > Cc: Magnus Damm <magnus.damm@gmail.com>
> > > Cc: Dinh Nguyen <dinguyen@altera.com>
> > > Cc: Viresh Kumar <viresh.linux@gmail.com>
> > > Cc: Shiraz Hashim <shiraz.hashim@st.com>
> > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
> > > Cc: Linus Walleij <linus.walleij@linaro.org>
> >
> > mach-shmobile portion:
> >
> > Acked-by: Simon Horman <horms+renesas@verge.net.au>
> >
> > For the record, I tested this on the kzm9g, kzm9d and marzen boards
> > which use the r8a7779, EMEV2 and r8a7779 SoCs respectively.
>
> Thanks. Can I add a Tested-by as well?
Sure.
Tested-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH v3 2/3] gpio: pca953x: add support for pca9505
From: Haojian Zhuang @ 2013-01-28 1:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51045261.5020709@free-electrons.com>
On 27 January 2013 06:02, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> On 01/25/2013 09:51 AM, Linus Walleij wrote:
>> On Fri, Jan 25, 2013 at 9:36 AM, Gregory CLEMENT
>> <gregory.clement@free-electrons.com> wrote:
>>
>>> Well, at the beginning I thought adding support for pca9505 was just a matter
>>> of a couple of lines to add. Then I realized that I need to handle the 40 bits
>>> case, and I ended up refactoring all access to the registers. So now I am on it,
>>> it seems I am volunteer to continue to improve this driver.
>>
>> I like the sound of this ;-)
>
> I was about to fix the issues you have pointed but I didn't find anything like
>
> #ifdef CONFIG_ARCH_PXA
> if (cpu_is_pxa25x()) {
> #ifdef CONFIG_CPU_PXA26x
> count = 89;
> gpio_type = PXA26X_GPIO;
> #elif defined(CONFIG_PXA25x)
>
>
> in the pca953x driver! I think you messed up with another patch set!
>
> I saw that Haojian Zhuang have sent a patch set for gpio-pxa and
> among this set the patch "[PATCH 06/10] gpio: pxa: define nr gpios
> in platform data" seemed to exactly what you've expected.
>
PCA953X is a GPIO expander that is relied on I2C bus. It's a device in
the cirucit,
not in the PXA chips. So there's no cpu related code in this driver.
Gregory's concern is that he found that this device is used on pxa27x
platform, and
he don't have the hardware to test. I also don't have pxa27x platform.
I think that
he can ping the volunteers in the mailing list.
Regards
Haojian
^ permalink raw reply
* [PATCH 1/3] ARM: Dove: split legacy and DT setup
From: Jason Cooper @ 2013-01-28 2:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355790269-10596-1-git-send-email-sebastian.hesselbarth@gmail.com>
On Tue, Dec 18, 2012 at 01:24:27AM +0100, Sebastian Hesselbarth wrote:
> In the beginning of DT for Dove it was reasonable to have it close to
> non-DT code. With improved DT support, it became more and more difficult
> to not break non-DT while changing DT code.
>
> This patch splits up DT board setup and introduces a DOVE_LEGACY config
> to allow to remove legacy code for DT-only kernels.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
> arch/arm/mach-dove/Kconfig | 5 ++
> arch/arm/mach-dove/Makefile | 4 +-
> arch/arm/mach-dove/board-dt.c | 102 +++++++++++++++++++++++++++++++++++++++++
> arch/arm/mach-dove/common.c | 85 ----------------------------------
> 4 files changed, 110 insertions(+), 86 deletions(-)
> create mode 100644 arch/arm/mach-dove/board-dt.c
Applied to mvebu/boards
thx,
Jason.
^ permalink raw reply
* [PATCH 2/3] ARM: Dove: cleanup includes
From: Jason Cooper @ 2013-01-28 2:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355790269-10596-2-git-send-email-sebastian.hesselbarth@gmail.com>
On Tue, Dec 18, 2012 at 01:24:28AM +0100, Sebastian Hesselbarth wrote:
> With DT board setup removed from common code, it is a good time
> to cleanup unneccessary includes from common dove code.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
> arch/arm/mach-dove/common.c | 30 +++++++++---------------------
> 1 file changed, 9 insertions(+), 21 deletions(-)
Applied to mvebu/cleanup
thx,
Jason.
^ permalink raw reply
* [PATCH 19/19] [INCOMPLETE] ARM: make return_address available for ARM_UNWIND
From: Keun-O Park @ 2013-01-28 2:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301260045.28804.arnd@arndb.de>
Hello guys,
Could you please review the patch of fixing bug first of returning
wrong address when using frame pointer?
I am wondering if the first patch is not delivered to the mailing.
~~~~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~~~~~~~~
>From 3a60b536d22a2043d735c890a9aac9e7cb72de8f Mon Sep 17 00:00:00 2001
From: sahara <keun-o.park@windriver.com>
Date: Thu, 3 Jan 2013 17:12:37 +0900
Subject: [PATCH 1/2] arm: fix returning wrong CALLER_ADDRx
This makes return_address return correct value for ftrace feature.
unwind_frame does not update frame->lr but frame->pc for backtrace.
And, the initialization for data.addr was missing so that wrong value
returned when unwind_frame failed.
Signed-off-by: sahara <keun-o.park@windriver.com>
---
arch/arm/kernel/return_address.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index 8085417..fafedd8 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -26,7 +26,7 @@ static int save_return_addr(struct stackframe *frame, void *d)
struct return_address_data *data = d;
if (!data->level) {
- data->addr = (void *)frame->lr;
+ data->addr = (void *)frame->pc;
return 1;
} else {
@@ -41,7 +41,8 @@ void *return_address(unsigned int level)
struct stackframe frame;
register unsigned long current_sp asm ("sp");
- data.level = level + 1;
+ data.level = level + 2;
+ data.addr = NULL;
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.sp = current_sp;
--
1.7.1
~~~~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~~~~~~~~
Without this patch, when I added the following printk line and did
sync command,
it returned wrong return addresses using frame pointer.
Added line in __bdi_start_writeback():
+ printk("TEST: CALLER_ADDR0=(%pS), CALLER_ADDR1=(%pS),
CALLER_ADDR2=(%pS)\n", (void *)CALLER_ADDR0, (void *)CALLER_ADDR1,
(void *)CALLER_ADDR2);
Call sequence:
sys_sync() -> wakeup_flusher_threads() -> __bdi_start_writeback()
Result of sync after boot up:
~ # sync
TEST: CALLER_ADDR0=(wakeup_flusher_threads+0x9c/0xb8),
CALLER_ADDR1=(__bdi_start_writeback+0x30/0x120),
CALLER_ADDR2=(__bdi_start_writeback+0x3c/0x120)
As you see, the result of CALLER_ADDR1 and CALLER_ADDR2 is wrong.
With this patch, you will be able to see the following result.
~ # sync
TEST: CALLER_ADDR0=(wakeup_flusher_threads+0x9c/0xb8),
CALLER_ADDR1=(sys_sync+0x34/0xac),
CALLER_ADDR2=(ret_fast_syscall+0x0/0x48)
Based on this patch, if you apply the second patch which enables the
arm unwind,
and turning on CONFIG_ARM_UNWIND, you will see the correct result.
What I am currently concerning is if I use unwind info and ftrace's irqsoff,
I presume the ftrace might need architecture specific function to make
irqsoff work correctly.
For example, when I tried to test irqsoff, I got the message from
trace like the following.
cat-563 0d... 2us+: __irq_svc <-_raw_spin_unlock_irqrestore
Actually I could see the call sequence from the end of the trace.
~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~
=> gic_handle_irq
=> __irq_svc
=> _raw_spin_unlock_irqrestore
=> uart_start
=> uart_write
~~~~~~~~~~~~~~~~~~snip~~~~~~~~~~~~~~~~~~
Seeing this call sequences, the output need to be
'_raw_spin_unlock_irqrestore <- uart_start'.
But, the CALLER_ADDR1 in trace_hardirqs_off() returned correct value.
So there's no problem in output.
I think trace_hardirqs_off() should call CALLER_ADDR1 and CALLER_ADDR2
respectively for its arguments for start_critical_timing(). This
thought leads me to the necessity of creating architecture specific
trace_hardirqs_off function. Any opinion on this?
-- kpark
^ permalink raw reply related
* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Viresh Kumar @ 2013-01-28 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127171717.GL29973@lunn.ch>
On 27 January 2013 22:47, Andrew Lunn <andrew@lunn.ch> wrote:
> I expect Debian, Fedora etc will strongly disagree with you
> there. They want one kernel that will run on as many products they
> support as possible. Kirkwood is mostly used in NAS boxes and is
> supported by all these distributions.
>
> Now for a SoC used in a deeply embedded system, using a custom
> distribution, buildroot, etc, multiplatform is probably not
> wanted. But the products i've seen using Kirkwood don't fit this use
> case.
Accepted. I was wrong with my comment here :)
>> So, even this kind of delay is really not a big issue. On the other
>> hand with platform driver too, we will hit lot of other code and
>> would consume some extra memory for keeping its structures
>
> Kirkwood has many platform drivers, all this code is already pulled
> in, lots of structures already exist. The incremental costs of another
> platform device is minimal.
Its about delay executing other code too for platform device.
Other than that, there is one more issue with this style. It against DT
philosophy. :(
We really shouldn't add any devices from arch/arm/mach-* for any new
drivers. And when we have DT support in driver, then it doesn't make
any sense. So, you really need to pass this from cpu node in DT.
--
viresh
^ permalink raw reply
* [RESEND PATCH v5 3/7] usb: chipidea: add otg id switch and vbus connect/disconnect detect
From: Peter Chen @ 2013-01-28 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wqv1bnyd.fsf@ashishki-desk.ger.corp.intel.com>
On Fri, Jan 25, 2013 at 11:40:10AM +0200, Alexander Shishkin wrote:
> Peter Chen <peter.chen@freescale.com> writes:
>
> > On Thu, Jan 24, 2013 at 05:25:17PM +0200, Alexander Shishkin wrote:
>
> What doesn't happen is the reset into device mode (unless you have
> _REGS_SHARED set, which by the way seems a bit misleading) and we're
> still doing nothing till the vbus interrupt comes. So the REGS_SHARED is
> the real problem in this case.
Yes, at imx it sets REGS_SHARD. The REGS_SHARED is needed at below
conditions:
- System boots up with usb device at OTG port using A-plug cable, at this
situation, any gadget initialization should not do any registers operation,
the related functions are udc_start and ci13xxx_start.
- At udc_irq, we do not want any wakeup, id, and host interrupt to call
internal code.
>
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH] cpufreq: instantiate cpufreq-cpu0 as a platform_driver
From: Viresh Kumar @ 2013-01-28 4:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359208550-16402-1-git-send-email-shawn.guo@linaro.org>
On Sat, Jan 26, 2013 at 7:25 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> As multiplatform build is being adopted by more and more ARM platforms,
> initcall function should be used very carefully. For example, when
> GENERIC_CPUFREQ_CPU0 is built in the kernel, cpu0_cpufreq_driver_init()
> will be called on all the platforms to initialize cpufreq-cpu0 driver.
>
> To eliminate this undesired the effect, the patch changes cpufreq-cpu0
> driver to have it instantiated as a platform_driver. Then it will only
> run on platforms that create the platform_device "cpufreq-cpu0".
>
> Along with the change, it also changes cpu_dev to be &pdev->dev,
> so that managed functions can start working, and module build gets
> supported too.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> Rafael,
>
> The patch depends patch "power: export opp cpufreq functions".
> https://patchwork.kernel.org/patch/1847261/
>
> AnilKumar,
>
> Unfortunately, the change will require some platform level adoption
> to have cpufreq-cpu0 driver continue working for am33xx. But it should
> be as simple as something like below.
>
> struct platform_device_info devinfo = { .name = "cpufreq-cpu0", };
> platform_device_register_full(&devinfo);
Something similar was being discussed with Andrew (cc'd) on his patch
for kikwood cpufreq driver.
We shouldn't encourage addition of above as we are moving towards DT.
So, i would except an compatible array too in your patch and then driver
can be probed based on compatible string being present in cpu node.
What do you say?
--
viresh
^ permalink raw reply
* [PATCH 01/10] gpio: pxa: set initcall level to module init
From: Haojian Zhuang @ 2013-01-28 4:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ham5nfi7.fsf@free.fr>
On 26 January 2013 05:01, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Haojian Zhuang <haojian.zhuang@linaro.org> writes:
>
>> gpio & pinctrl driver are used together. The pinctrl driver is already
>> launched before gpio driver in Makefile. So set gpio driver to module
>> init level. Otherwise, the sequence will be inverted.
> Hi Haojian,
>
> If you switch gpio to module level, and as some modules use gpios in their init
> path, isn't it possible that some modules will fail their init, as GPIO API
> won't provide the gpio_*_value() functions ?
>
gpio_request() should return EPROBE_DEFER, then the driver is using gpio API
fails and it should be retried after a while. At that time, gpio
driver should be launched
properly.
Regards
Haojian
^ permalink raw reply
* [PATCH 5/6] ARM: regulator: add tps6507x device tree data
From: Vishwanathrao Badarkhe, Manish @ 2013-01-28 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130126051206.GE10580@opensource.wolfsonmicro.com>
On Sat, Jan 26, 2013 at 10:42:08, Mark Brown wrote:
> On Fri, Jan 25, 2013 at 06:29:49AM +0000, Vishwanathrao Badarkhe, Manish wrote:
> > On Thu, Jan 24, 2013 at 17:30:51, Mark Brown wrote:
>
> > I too doubt that whether it should be in architecture specific folder,
>
> > My code is in reference to below patch:
> > arm/dts: regulator: Add tps65910 device tree
> > data(d5d08e2e1672da627d7c9d34a9dc1089c653e23a)
>
> > Could you please suggest me if it can be moved somewhere else?
>
> We should have somewhere to put this sort of generic stuff, yes. Not sure where, possibly under drivers/of or some non-drivers part of the tree.
>
Right now, nobody has put this kind of generic stuff other than architecture folder.
Later on We can move these kind of generic stuff somewhere else in one shot.
Regards,
Manish
^ permalink raw reply
* [PATCH 2/6] ARM: davinci: da850: add DT node for I2C0
From: Vishwanathrao Badarkhe, Manish @ 2013-01-28 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51026365.1020402@ti.com>
On Fri, Jan 25, 2013 at 16:20:13, Nori, Sekhar wrote:
> On 1/24/2013 5:05 PM, Vishwanathrao Badarkhe, Manish wrote:
> > Add I2C0 device tree node information to da850-evm.
> > Also, add I2C0 pin muxing information in da850-evm.
> >
> > Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
> > ---
> > Depends on patch
> > http://comments.gmane.org/gmane.linux.davinci/25993
> >
> > arch/arm/boot/dts/da850-evm.dts | 15 +++++++++++++++
> > arch/arm/boot/dts/da850.dtsi | 10 ++++++++++
> > 2 files changed, 25 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/da850-evm.dts
> > b/arch/arm/boot/dts/da850-evm.dts index 8cac9d2..3d8290a 100755
> > --- a/arch/arm/boot/dts/da850-evm.dts
> > +++ b/arch/arm/boot/dts/da850-evm.dts
> > @@ -27,5 +27,20 @@
> > serial2: serial at 1d0d000 {
> > status = "okay";
> > };
> > + i2c0 at 1c22000 {
>
> This should be
> i2c0: i2c at 1c22000
>
> to follow the convention elsewhere in file.
Ok, I will change this in next version.
>
> > + status = "okay";
> > + };
> > + };
> > +};
> > +&pmx_core {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <
> > + &i2c0_pins
> > + >;
> > +
> > + i2c0_pins: pinmux_i2c0_pins{
> > + pinctrl-single,bits = <
> > + 0x10 0x00002200 0x0000ff00 /* I2C0_SDA,I2C0_SCL */
> > + >;
>
> This should go into the dtsi file. See the discussion on NAND DT support submitted by Anil Kumar.
I have seen Anil Kumar's discussion for pin-muxing which includes Linus patch of grab pin
control handles from device core at following location:
http://lkml.indiana.edu/hypermail/linux/kernel/1301.2/00094.html
I have done changes accordingly for I2C0 pin muxing and seen kernel crashes giving message
like "i2c_davinci i2c_davinci.1: could not find pctldev for node /soc/
pinmux at 1c14120/pinmux_i2c0_pins, deferring probe". This is happened because I2C0 driver
gets probed before pin mux driver.
To resolve this issue, I made changes in code to ensure pin control driver gets probed before
I2C0 driver by registering pin control driver during arch_init call.
Hence, in order to move I2C0 pin muxing in dtsi file above fix is required.
>
> Thanks,
> Sekhar
>
> PS: You are using an old address for Kevin Hilman. The MAINTAINERS file has been updated for a long time now. Liam's address is also wrong but I don't have his updated e-mail.
>
Regards,
Manish
^ permalink raw reply
* [RESEND PATCH v5 4/7] usb: chipidea: consolidate ci_role_driver's API for both roles
From: Peter Chen @ 2013-01-28 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87sj5pbgwr.fsf@ashishki-desk.ger.corp.intel.com>
On Fri, Jan 25, 2013 at 02:12:20PM +0200, Alexander Shishkin wrote:
> Peter Chen <peter.chen@freescale.com> writes:
>
> > On Thu, Jan 24, 2013 at 04:35:30PM +0200, Alexander Shishkin wrote:
> >> Peter Chen <peter.chen@freescale.com> writes:
> >>
> >> > - Create init/destroy API for probe and remove
> >> > - start/stop API are only used otg id switch process
> >> > - Create the gadget at ci_hdrc_probe if the gadget is supported
> >> > at that port, the main purpose for this is to avoid gadget module
> >> > load fail at init.rc
> >>
> @@ -402,6 +402,12 @@ static ssize_t store_role(struct device *dev, struct device_attribute *attr,
> if (ret)
> return ret;
>
> + /*
> + * there won't be an interrupt in case of manual switching,
> + * so we need to check vbus session manually
> + */
> + ci_handle_vbus_change(ci);
> +
It may not be used as there will be a vbus interrupt.
> return count;
> }
>
> }
> dbg_remove_files(&ci->gadget.dev);
> device_unregister(&ci->gadget.dev);
> - /* my kobject is dynamic, I swear! */
> - memset(&ci->gadget, 0, sizeof(ci->gadget));
Any reason to delete it, another fix?
> }
>
> /**
> @@ -1842,13 +1839,11 @@ int ci_hdrc_gadget_init(struct ci13xxx *ci)
> if (!rdrv)
> return -ENOMEM;
>
> - rdrv->init = udc_start;
> rdrv->start = udc_id_switch_for_device;
> rdrv->stop = udc_id_switch_for_host;
> - rdrv->destroy = udc_stop;
Where we call udc_start and udc_stop? And the udc_start should only be called
one time.
>
> Which is shorter (32 insertions(+), 53 deletions(-)) and makes the main
> probe easier on the eyes. What do you think?
OK, not matter how to change it, it needs to cover below things:
(Covers last email)
- Gadget needs to be only initialized one time.
- Host/device function should be OK when the device on it or
the usb cable connects to host during the boots up.
- When the OTG port is at host mode, it should not call any
register writing operations at gadget's API.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [GIT PULL V2 2/4] ARM: mvebu: drivers for v3.9
From: Olof Johansson @ 2013-01-28 5:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358909285.ca5b742.21555@triton>
On Wed, Jan 23, 2013 at 02:48:05AM +0000, Jason Cooper wrote:
> The following changes since commit 4b53ab9cb853e446f628e561ce6fcc527df30a76:
>
> Merge branch 'mvebu/fixes' into mvebu/drivers (2013-01-23 01:42:14 +0000)
>
> are available in the git repository at:
>
>
> git://git.infradead.org/users/jcooper/linux.git tags/drivers_for_v3.9
>
> for you to fetch changes up to 43076a4c4e5fb92721bedc5d05b93468d6d76b2c:
>
> mmc: mvsdio: add pinctrl integration (2013-01-23 01:42:29 +0000)
>
> ----------------------------------------------------------------
> mvebu drivers for v3.9
> - mvsdio
> - use slot-gpio for card detect and write protect
> - add DT binding
> - add pinctrl integration
> - use rtc-mv in mvebu armv7 SoCs
> - add pci-e hotplug for kirkwood
Hi,
I didn't see any acks by Chris Ball on these, he's usually pretty
responsive on code reviews so I just wanted to make sure he's OK with
us taking this through arm-soc, and aware of it.
Looks like this whole branch could go through the mmc tree? The dtsi
updates from the last branch would still go through arm-soc.
Either way is fine with me, I just don't want to make life difficult for Chris
in case he has some sweeping changes planned that might cause conflicts, etc.
-Olof
^ permalink raw reply
* [GIT PULL V2 1/4] ARM: mvebu: cleanup for v3.9
From: Olof Johansson @ 2013-01-28 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358909283.6D1c74D1.21555@triton>
On Wed, Jan 23, 2013 at 02:48:03AM +0000, Jason Cooper wrote:
> The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
>
> Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
>
> are available in the git repository at:
>
> git://git.infradead.org/users/jcooper/linux.git tags/cleanup_for_v3.9
>
> for you to fetch changes up to b96e1b1c3c5319294edb0970b6d5bf099c0e85eb:
>
> ARM: Kirkwood: Cleanup unneeded include files (2013-01-12 21:50:10 +0000)
>
> ----------------------------------------------------------------
> mvebu cleanup for v3.9
> - remove unneeded includes due to DT conversion
>
> ----------------------------------------------------------------
> Andrew Lunn (1):
> ARM: Kirkwood: Cleanup unneeded include files
>
> Thomas Petazzoni (1):
> arm: kirkwood: dockstar: remove useless include of SDIO header
>
> arch/arm/mach-kirkwood/board-ib62x0.c | 1 -
> arch/arm/mach-kirkwood/board-mplcec4.c | 1 -
> arch/arm/mach-kirkwood/dockstar-setup.c | 1 -
> 3 files changed, 3 deletions(-)
Hi,
This one I pulled as mvebu/cleanup. I'm holding off on the others based
on my reply, since the drivers branch is base for the later branches.
-Olof
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Santosh Shilimkar @ 2013-01-28 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FEAABA.6050307@ti.com>
On Tuesday 22 January 2013 08:35 PM, Santosh Shilimkar wrote:
> On Tuesday 22 January 2013 08:21 PM, Russell King - ARM Linux wrote:
>> On Tue, Jan 22, 2013 at 03:44:03PM +0530, Santosh Shilimkar wrote:
>>> Sorry for not being clear enough. On OMAP, 32KHz is the only clock which
>>> is always running(even during low power states) and hence the clock
>>> source and clock event have been clocked using 32KHz clock. As mentioned
>>> by RMK, with 32768 Hz clock and HZ = 100, there will be always an
>>> error of 0.1 %. This accuracy also impacts the timer tick interval.
>>> This was the reason, OMAP has been using the HZ = 128.
>>
>> Ok. Let's look at this. As far as time-of-day is concerned, this
>> shouldn't really matter with the clocksource/clockevent based system
>> that we now have (where *important point* platforms have been converted
>> over.)
>>
>> Any platform providing a clocksource will override the jiffy-based
>> clocksource. The measurement of time-of-day passing is now based on
>> the difference in values read from the clocksource, not from the actual
>> tick rate.
>>
>> Anything _not_ providing a clock source will be reliant on jiffies
>> incrementing, which in turn _requires_ one timer interrupt per jiffies
>> at a known rate (which is HZ).
>>
>> Now, that's the time of day, what about jiffies? Well, jiffies is
>> incremented based on a certain number of nsec having passed since the
>> last jiffy update. That means the code copes with dropped ticks and
>> the like.
>>
>> However, if your actual interrupt rate is close to the desired HZ, then
>> it can lead to some interesting effects (and noise):
>>
>> - if the interrupt rate is slightly faster than HZ, then you can end up
>> with updates being delayed by 2x interrupt rate.
>> - if the interrupt rate is slightly slower than HZ, you can occasionally
>> end up with jiffies incrementing by two.
>> - if your interrupt rate is dead on HZ, then other system noise can come
>> into effect and you may get maybe zero, one or two jiffy increments
>> per
>> interrupt.
>>
>> (You have to think about time passing in NS, where jiffy updates should
>> be vs where the timer interrupts happen.) See tick_do_update_jiffies64()
>> for the details.
>>
>> The timer infrastructure is jiffy based - which includes scheduling where
>> the scheduler does not use hrtimers. That means a slight discrepency
>> between HZ and the actual interrupt rate can cause around 1/HZ jitter.
>> That's a matter of fact due to how the code works.
>>
>> So, actually, I think the accuracy of HZ has much overall effect
>> _provided_
>> a platform provides a clocksource to the accuracy of jiffy based timers
>> nor timekeeping. For those which don't, the accuracy of the timer
>> interrupt to HZ is very important.
>>
>> (This is just based on reading some code and not on practical
>> experiments - I'd suggest some research of this is done, trying HZ=100
>> on OMAP's 32kHz timers, checking whether there's any drift, checking
>> how accurately a single task can be woken from various select/poll/epoll
>> delays, and checking whether NTP works.)
>>
> Thanks for expanding it. It is really helpful.
>
>> And I think further discussion is pointless until such research has been
>> done (or someone who _really_ knows the time keeping/timer/sched code
>> inside out comments.)
>>
> Fully agree about experimentation to re-asses the drift.
> From what I recollect from past, few OMAP customers did
> report the time drift issue and that is how the switch
> from 100 --> 128 happened.
>
> Anyway I have added the suggested task to my long todo list.
>
So I tried to see if any time drift with HZ = 100 on OMAP. I ran the
setup for 62 hours and 27 mins with time synced up once with NTP server.
I measure about ~174 millisecond drift which is almost noise considering
the observed duration was ~224820000 milliseconds.
Am re-running the setup with HZ = 128 for similar time frame to see if
the minimal drift observed goes away.
Once through that, I will send a patch to update the OMAP to use
HZ = 100 and possibly get rid of the custom OMAP HZ config.
Regards,
Santosh
^ permalink raw reply
* [GIT PULL v2] arm-soc: Xilinx zynq timer changes for v3.9
From: Olof Johansson @ 2013-01-28 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHTX3dLSp5_OZmuvU18s=A19e7F1Jq7tgTjayV8qFDJ1FTJztA@mail.gmail.com>
On Fri, Jan 25, 2013 at 04:48:43PM +0100, Michal Simek wrote:
> Hi Arnd and Olof,
>
> can you please look at this pull request?
Hi,
Sorry for the delay. I was out sick part of last week and dealing with
backlog when I got back on my feet. Doing a sweep of pull requests now.
Two comments.
1. mach-pxa/time.c conflict resolution doesn't seem right -- you for some
reason deleted the suspend/resume struct members from the
clock_event_device.
2. Below:
> > Soren Brinkmann (7):
> > arm: zynq: timer: Replace PSS through PS
This is pure churn. :( We can't keep renaming things in the kernel just
because some document writer decides to change a term, we tend to stick
to what's already there. As long as it's not completely misleading, at least.
I' shortly push a new "depends/cleanup" branch to arm-soc. It essentially
contains the next/cleanup contents that you merged together yourself,
but as a branch that you can just pull in. Since others might need to
do the same, providing the branch from us just makes sense.
So, can you please rebase on top of that and send a fresh pull request? If
you really want the PSS->PS rename included I'll give you a first-time
pass for it but please keep it in mind for the future.
Thanks!
-Olof
^ permalink raw reply
* [GIT PULL][for 3.8] request from armsoc/fix branch in pxa git tree
From: Olof Johansson @ 2013-01-28 6:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN1soZyvN_bY-+scb6_UQGxqiC235+yuxhZ0H22JdZy6-8y_vg@mail.gmail.com>
On Thu, Jan 24, 2013 at 12:37:29PM +0800, Haojian Zhuang wrote:
> On Thu, Jan 24, 2013 at 12:33 PM, Olof Johansson <olof@lixom.net> wrote:
> > Hi,
> >
> > On Wed, Jan 23, 2013 at 1:15 AM, Haojian Zhuang
> > <haojian.zhuang@gmail.com> wrote:
> >> Hi Arnd & Olof,
> >>
> >> Please help to pull armsoc/fix branch in pxa git tree.
> >>
> >> Regards
> >> Haojian
> >>
> >> The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
> >>
> >> Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
> >>
> >> are available in the git repository at:
> >>
> >> git://github.com/hzhuang1/linux.git armsoc/fix
> >>
> >> for you to fetch changes up to eea6e39b916dd282c7fa4629be8934b5ad60e62b:
> >>
> >> ARM: pxa: Minor naming fixes in spitz.c (2013-01-23 17:13:07 +0800)
> >>
> >> ----------------------------------------------------------------
> >> Igor Grinberg (1):
> >> ARM: PXA3xx: program the CSMSADRCFG register
> >>
> >> Marko Katic (1):
> >> ARM: pxa: Minor naming fixes in spitz.c
> >>
> >> Mike Dunn (2):
> >> ARM: palmtreo: fix lcd initilialization on treo680
> >> ARM: palmtreo: fix #ifdefs for leds-gpio device
> >
> > I don't think some of those really are regressions, are they? I.e. the
> > palmtreo fixes are for code that never in recent times worked I think?
> >
> > If so, I'd prefer to queue this for 3.9 as a fixes-non-critical
> > instead, please let me know if that's ok.
> >
> > Thanks,
> >
> > -Olof
>
> It's fine to me. You can queue all of them into 3.9 release cycle.
Great, merged into next/fixes-non-critical. Thanks!
-Olof
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Shawn Guo @ 2013-01-28 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127172358.GM29973@lunn.ch>
On Sun, Jan 27, 2013 at 06:23:58PM +0100, Andrew Lunn wrote:
> > > + clkspec.np = np;
> > > + clkspec.args_count = 1;
> > > + clkspec.args[0] = 1;
> > > +
> > > + priv.cpu_clk = of_clk_get_from_provider(&clkspec);
> >
> > Oh, yet another way to get clocks...
>
> Yep. I didn't like it, but could not find a better way. It has been
> argued that cpufreq drivers should not have nodes in DT. So the normal
> of_clk_get() does not work. Since the clocks themselves are
> instantiated from DT, there are no clkdev alias, so plain clk_get()
> also does not work.
>
But you should have a cpu node in DT, and it will be perfectly fine to
have cpu node consume that core_clk.
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