* [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
From: martin at neutronstar.dyndns.org @ 2011-09-19 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19F8576C6E063C45BE387C64729E739404EC8111DE@dbde02.ent.ti.com>
On Mon, Sep 19, 2011 at 11:37:37AM +0530, Hiremath, Vaibhav wrote:
>
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> > owner at vger.kernel.org] On Behalf Of Laurent Pinchart
> > Sent: Monday, September 19, 2011 3:29 AM
> > To: Martin Hostettler
> > Cc: Tony Lindgren; linux-omap at vger.kernel.org; linux-
> > media at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based
> > camera board.
> >
> > Hi Martin,
> >
> > On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote:
> > > Adds board support for an MT9M032 based camera to omap3evm.
> > >
> > > Sigend-off-by: Martin Hostettler <martin@neutronstar.dyndns.org>
> > > ---
> > > arch/arm/mach-omap2/Makefile | 1 +
> > > arch/arm/mach-omap2/board-omap3evm-camera.c | 183
> > > +++++++++++++++++++++++++++ 2 files changed, 184 insertions(+), 0
> > > deletions(-)
> > > create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
> > >
> > > Changes in V2:
> > > * ported to current mainline
> > > * Style fixes
> > > * Fix error handling
> > >
> > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> > > index f343365..8ae3d25 100644
> > > --- a/arch/arm/mach-omap2/Makefile
> > > +++ b/arch/arm/mach-omap2/Makefile
> > > @@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO) +=
> > > board-omap3logic.o \ obj-$(CONFIG_MACH_OVERO) += board-overo.o \
> > > hsmmc.o
> > > obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
> > > + board-omap3evm-camera.o \
> > > hsmmc.o
> > > obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
> > > hsmmc.o
> > > diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
> > > b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644
> > > index 0000000..be987d9
> > > --- /dev/null
> > > +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
> > > @@ -0,0 +1,183 @@
> > > +/*
> > > + * Copyright (C) 2010-2011 Lund Engineering
> > > + * Contact: Gil Lund <gwlund@lundeng.com>
> > > + * Author: Martin Hostettler <martin@neutronstar.dyndns.org>
> > > + *
> [Hiremath, Vaibhav] The file below seems copied from (which is coming from all older releases of TI)
>
> http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/board-omap3evm-camera.c;h=2e6ccfef69027dee880d507b98b5a7998d4bbe7e;hb=adcd067326836777c049e3cb32a5b7d9d401fc31
>
> So I would appreciate if you keep original copyright and authorship of the file and add your sign-off to the patch.
>
First of all i don't have any problem Adding your name and the TI
copyright.
Maybe i should have been more careful when looking at and adeption
omap3evm_set_mux as i really took that from the TI code.
I honestly don't remember if i took any other code from that file or not.
It ends up doing what the hardware needs anyway. For me it doesn't matter
with such trival things, but i should have been more careful.
Do you consider it resolved if use the following at the start?
/*
* Copyright (C) 2010 Texas Instruments Inc
* Copyright (C) 2010-2011 Lund Engineering
* Contact: Gil Lund <gwlund@lundeng.com>
* Authors:
* Vaibhav Hiremath <hvaibhav@ti.com>
* Martin Hostettler <martin@neutronstar.dyndns.org>
*/
But then again the copy on my harddisk has these too...
* Contributors:
* Anuj Aggarwal <anuj.aggarwal@ti.com>
* Sivaraj R <sivaraj@ti.com>
Maybe i should add them too.
Not sure really...
- Martin Hostettler
^ permalink raw reply
* [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
From: Hiremath, Vaibhav @ 2011-09-19 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919192442.GE9244@neutronstar.dyndns.org>
> -----Original Message-----
> From: martin at neutronstar.dyndns.org [mailto:martin at neutronstar.dyndns.org]
> Sent: Tuesday, September 20, 2011 12:55 AM
> To: Hiremath, Vaibhav
> Cc: Laurent Pinchart; Tony Lindgren; linux-omap at vger.kernel.org; linux-
> media at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based
> camera board.
>
> On Mon, Sep 19, 2011 at 11:37:37AM +0530, Hiremath, Vaibhav wrote:
> >
> > > -----Original Message-----
> > > From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> > > owner at vger.kernel.org] On Behalf Of Laurent Pinchart
> > > Sent: Monday, September 19, 2011 3:29 AM
> > > To: Martin Hostettler
> > > Cc: Tony Lindgren; linux-omap at vger.kernel.org; linux-
> > > media at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> > > Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032
> based
> > > camera board.
> > >
> > > Hi Martin,
> > >
> > > On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote:
> > > > Adds board support for an MT9M032 based camera to omap3evm.
> > > >
> > > > Sigend-off-by: Martin Hostettler <martin@neutronstar.dyndns.org>
> > > > ---
> > > > arch/arm/mach-omap2/Makefile | 1 +
> > > > arch/arm/mach-omap2/board-omap3evm-camera.c | 183
> > > > +++++++++++++++++++++++++++ 2 files changed, 184 insertions(+), 0
> > > > deletions(-)
> > > > create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
> > > >
> > > > Changes in V2:
> > > > * ported to current mainline
> > > > * Style fixes
> > > > * Fix error handling
> > > >
> > > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-
> omap2/Makefile
> > > > index f343365..8ae3d25 100644
> > > > --- a/arch/arm/mach-omap2/Makefile
> > > > +++ b/arch/arm/mach-omap2/Makefile
> > > > @@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO) +=
> > > > board-omap3logic.o \ obj-$(CONFIG_MACH_OVERO) += board-
> overo.o \
> > > > hsmmc.o
> > > > obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
> > > > + board-omap3evm-camera.o \
> > > > hsmmc.o
> > > > obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
> > > > hsmmc.o
> > > > diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
> > > > b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644
> > > > index 0000000..be987d9
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
> > > > @@ -0,0 +1,183 @@
> > > > +/*
> > > > + * Copyright (C) 2010-2011 Lund Engineering
> > > > + * Contact: Gil Lund <gwlund@lundeng.com>
> > > > + * Author: Martin Hostettler <martin@neutronstar.dyndns.org>
> > > > + *
> > [Hiremath, Vaibhav] The file below seems copied from (which is coming
> from all older releases of TI)
> >
> > http://arago-project.org/git/projects/?p=linux-
> omap3.git;a=blob;f=arch/arm/mach-omap2/board-omap3evm-
> camera.c;h=2e6ccfef69027dee880d507b98b5a7998d4bbe7e;hb=adcd067326836777c04
> 9e3cb32a5b7d9d401fc31
> >
> > So I would appreciate if you keep original copyright and authorship of
> the file and add your sign-off to the patch.
> >
>
> First of all i don't have any problem Adding your name and the TI
> copyright.
> Maybe i should have been more careful when looking at and adeption
> omap3evm_set_mux as i really took that from the TI code.
>
The best practice it to always keep copy-right of the file intact... I wouldn't mind if you use and modify any part of the code and also add your authorship.
I feel, Copy-right is important part.
> I honestly don't remember if i took any other code from that file or not.
> It ends up doing what the hardware needs anyway. For me it doesn't matter
> with such trival things, but i should have been more careful.
>
> Do you consider it resolved if use the following at the start?
>
> /*
> * Copyright (C) 2010 Texas Instruments Inc
Change it to 2011.
> * Copyright (C) 2010-2011 Lund Engineering
> * Contact: Gil Lund <gwlund@lundeng.com>
Not sure do you really need above line...
> * Authors:
> * Vaibhav Hiremath <hvaibhav@ti.com>
> * Martin Hostettler <martin@neutronstar.dyndns.org>
> */
>
>
Looks ok to me.
> But then again the copy on my harddisk has these too...
>
> * Contributors:
> * Anuj Aggarwal <anuj.aggarwal@ti.com>
> * Sivaraj R <sivaraj@ti.com>
>
> Maybe i should add them too.
>
> Not sure really...
>
>
I think we should not pollute source file with all our names, so I would recommend to put copy rights and probably author.
Thanks,
Vaibhav
> - Martin Hostettler
^ permalink raw reply
* Link failures due to __bug_table in current -next
From: Russell King - ARM Linux @ 2011-09-19 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919120954.GA20314@opensource.wolfsonmicro.com>
On Mon, Sep 19, 2011 at 01:09:54PM +0100, Mark Brown wrote:
> I'm seeing linker failures in -next as of today:
>
> `.exit.text' referenced in section `__bug_table' of fs/built-in.o:
> defined in discarded section `.exit.text' of fs/built-in.o
> `.exit.text' referenced in section `__bug_table' of crypto/built-in.o:
> defined in discarded section `.exit.text' of crypto/built-in.o
> `.exit.text' referenced in section `__bug_table' of net/built-in.o:
> defined in discarded section `.exit.text' of net/built-in.o
> `.exit.text' referenced in section `__bug_table' of net/built-in.o:
> defined in discarded section `.exit.text' of net/built-in.o
>
> which appears to be due to the chnage to use generic BUG() introduced in
> commit 5254a3 (ARM: 7017/1: Use generic BUG() handler), reverting that
> commit resolves the issue for me.
This might solve the problem - could you check please?
arch/arm/kernel/vmlinux.lds.S | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 7b2541e..20b3041 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -24,8 +24,10 @@
#if (defined(CONFIG_SMP_ON_UP) && !defined(CONFIG_DEBUG_SPINLOCK)) || \
defined(CONFIG_GENERIC_BUG)
#define ARM_EXIT_KEEP(x) x
+#define ARM_EXIT_DISCARD(x)
#else
#define ARM_EXIT_KEEP(x)
+#define ARM_EXIT_DISCARD(x) x
#endif
OUTPUT_ARCH(arm)
@@ -40,6 +42,11 @@ jiffies = jiffies_64 + 4;
SECTIONS
{
/*
+ * XXX: The linker does not define how output sections are
+ * assigned to input sections when there are multiple statements
+ * matching the same input section name. There is no documented
+ * order of matching.
+ *
* unwind exit sections must be discarded before the rest of the
* unwind sections get included.
*/
@@ -48,6 +55,9 @@ SECTIONS
*(.ARM.extab.exit.text)
ARM_CPU_DISCARD(*(.ARM.exidx.cpuexit.text))
ARM_CPU_DISCARD(*(.ARM.extab.cpuexit.text))
+ ARM_EXIT_DISCARD(EXIT_TEXT)
+ ARM_EXIT_DISCARD(EXIT_DATA)
+ EXIT_CALL
#ifndef CONFIG_HOTPLUG
*(.ARM.exidx.devexit.text)
*(.ARM.extab.devexit.text)
@@ -59,6 +69,8 @@ SECTIONS
#ifndef CONFIG_SMP_ON_UP
*(.alt.smp.init)
#endif
+ *(.discard)
+ *(.discard.*)
}
#ifdef CONFIG_XIP_KERNEL
@@ -280,9 +292,6 @@ SECTIONS
STABS_DEBUG
.comment 0 : { *(.comment) }
-
- /* Default discards */
- DISCARDS
}
/*
^ permalink raw reply related
* [PATCH] arm/dt: Add SoC detection macros
From: Olof Johansson @ 2011-09-19 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3C7A7ACA8617D24290826EC008B5CD083E17B00988@HQMAIL03.nvidia.com>
On Mon, Sep 19, 2011 at 10:26 AM, Allen Martin <AMartin@nvidia.com> wrote:
>> What I'm saying is that in that scenario it should not be necessary to edit the
>> kernel to invent new SoC types, and then teach it that Tegra4 is mostly the
>> same as Tegra3. ?That information should all be encoded into the DT rather
>> than the C code in the kernel.
>>
>> So, I think adding this SoC type stuff is the wrong approach to the problem.
>
> What ends up happening in practice for a lot of hw blocks inside the SoC, is that tegra4 is mostly the same as tegra3 with a few new registers and bug fixes that slightly change the programming model. ?So either we have to add device quirks to teach device tree about the differences, and pass those in as flags to the driver, or we can do SoC detection at runtime in the driver. ?It sounds like the consensus from you and Olof is that the first is preferable.
Well, my fear of making a performance-optimized implementation of this
is that it will be overused at runtime. As an example on how it should
not look when starting out on a new driver today, look at the gpio
driver for omap. It looks the way it does because they merged the 3
separate implementations together, but they have a bunch of functions
in there that have three completely different code paths depending on
which platform they are on. For those, having three different
functions, and a function pointer to reach it through, makes more
sense.
But for to-be-upstreamed SoC support for, for example, tegra3 -- a
platform that has device-tree support -- it would be better to do a
new compatible field in the device tree for it, and thus at the time
of probing of the device (in the driver) you will know if it's a
tegra2 or tegra3 gpio controller you are configuring. Based on that,
you can setup your driver to behave appropriately -- some of that
might of course still be runtime checks, but hopefully not too much of
it.
The SoC detection-at-runtime doesn't scale and map to drivers all that
cleanly either. Today you have a linear roadmap of devices where
development happens on the "family number" field. What if there is a
future T32 that is an evolution of T30 but with tegra4's gpio
controller, for example [assuming numbering is similar to today's
tegra2 t20/t25/etc]? It's better to do the versioning per
IP/device/driver, than trying to map a global version/product number
per-driver to different behavior.
-Olof
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Grant Likely @ 2011-09-19 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E76615C.3000005@gmail.com>
On Sun, Sep 18, 2011 at 04:23:40PM -0500, Rob Herring wrote:
> On 09/15/2011 11:43 AM, Rob Herring wrote:
> > I see 2 options (besides leaving it as is):
> >
> > - Revert back to my previous binding where PPIs are a sub-node and a
> > different interrupt parent.
> >
> > - Use the current binding, but allow SPIs to start at 0. We can still
> > distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
> > SPI. If there was ever a reason to have a cpu mask for an SPI, you would
> > not be able to with this scheme.
> >
> > Either way you will still have the above issue with the cell size changing.
> >
>
> I was headed down the path of implementing the 2nd option above, but had
> a dilemma. What would be the numbering base for PPIs in this case?
> Should it be 0 in the DT as proposed for SPIs or does it stay at 16?
> Numbering PPIs at 0 will just cause confusion as will numbering
> differently from SPIs. There is absolutely no mention of SPI0 or SPIx
> numbering in the GIC spec. All interrupt number references refer to the
> absolute interrupt ID, not a relative number based on the type.
Hi Rob,
See here[1] and [2] (figures 3.14 and 3.16). In both cases, there is
clearly a reference to PPI numbering from 0-15 and SPI numbering from
0-987 (as inputs to the distributor block).
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0416b/Bhacbfdb.html
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0416b/Cihebcbg.html
g.
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Grant Likely @ 2011-09-19 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E774847.3020104@gmail.com>
On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>> I was headed down the path of implementing the 2nd option above,
>>> but had a dilemma. What would be the numbering base for PPIs in
>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>> stay at 16?
>>
>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>> processor has its own private timers that can generate interrupts,
>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>> its own watchdog timers that can generate interrupts, using ID30.
>>
>> So in that case, it can makes sense to use the ID. But it is
>> interesting to note that the PPI is identified with a 0 based index
>> number.
>>
> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
> for the timer interrupt. The first would match 0 based SPI convention.
> The last 2 would both match the documentation. We could never use 2 as
> this will for sure be different and the GIC code will have no way to
> know how to do the translation to ID. The only sane choice is using the
> ID as you say.
>
> But you can't have it both ways. It does not make sense to use the ID
> for some interrupts and a different scheme for others.
Hmmm, it seems to me that some orthogonal issues are getting
conflated. Specifically, the binding vs. what the GIC driver using
internally. For my own understanding, let me see if I can summarize
and clarify the problem.
Each GIC IRQ is represented in 5 different ways:
1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
2) The DT binding to represent the connection.
3) The Interrupt ID as specified by the GIC architecture reference[1]
(SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
4) The internal HWIRQ representation used by the GIC driver
5) The Linux VIRQ number that #4 maps to.
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html
Some thoughts:
- Generally the DT binding (#2) should reflect the HW view of the
system (#1) since that is the number most likely to be represented in
hardware manuals. The interrupt ID is an internal detail of the GIC,
and isn't really exposed in the block diagram of the hardware.
- Presumably it is preferable for the GIC to directly use the
Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
efficient from an interrupt handling perspective, and indeed this is
currently what the GIC driver does.
- Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
(#3/#4) is trivial, and easily managed by the GIC's irq_domain.
- Though not necessarily as trivial, the mapping between Linux VIRQ
and HWIRQ is not fixed, and when migrating to DT it should be assumed
to be assigned at runtime. Perhaps not so important for a core IRQ
controller like the GIC (as opposed to an i2c irq expander), but
assuming an fixed offset still should be avoided. We may still force
a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
necessary and the driver still needs to support remapping for a
secondary GIC.
So, for the GIC DT binding, I'm inclined to agree with Benoit that the
binding should reflect the hardware connections, not the values used
by software for decoding IRQs. Also, I see absolutely no need to use
separate nodes for each GIC interrupt space. The DT interrupt
specifier number space can more than handle the features of the GIC in
a clear and concise manor. So, here's my counter proposal for a GIC
bindings (using Rob's text as the starting point):
----
* ARM Generic Interrupt Controller
ARM SMP cores are often associated with a GIC, providing per processor
interrupts (PPI), shared processor interrupts (SPI) and software
generated interrupts (SGI).
Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
Secondary GICs are cascaded into the upward interrupt controller and do not
have PPIs or SGIs.
Main node required properties:
- compatible : should be one of:
"arm,cortex-a9-gic"
"arm,arm11mp-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
bits[15:8] PPI interrupt cpu mask. Each bit corresponds to
each of the 8 possible cpus attached to the GIC. A bit set to '1'
indicated the interrupt is wired to that CPU. Only valid for PPI
interrupts.
(Alternately, if there is no need for a CPU mask because PPI
interrupts will never be wired to more than one CPU, then it would be
better to encode the CPU number into the second cell with the SPI
number).
- reg : Specifies base physical address(s) and size of the GIC registers. The
first 2 values are the GIC distributor register base and size. The 2nd 2
values are the GIC cpu interface register base and size.
Optional
- interrupts : Interrupt source of the parent interrupt controller. Only
present on secondary GICs.
Example:
intc: interrupt-controller at fff11000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
#address-cells = <1>;
interrupt-controller;
reg = <0xfff11000 0x1000>,
<0xfff10100 0x100>;
};
^ permalink raw reply
* [PATCH 1/2] ARM: debug: Add CLSP711X_UART1 config choice
From: Will Deacon @ 2011-09-19 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316455300-5752-1-git-send-email-sboyd@codeaurora.org>
Hi Stephen,
On Mon, Sep 19, 2011 at 07:01:39PM +0100, Stephen Boyd wrote:
> ARM patch 7072/1 (debug: use kconfig choice for selecting
> DEBUG_LL UART) only allowed CLSP711X_UART2 to be selected because
> there is no NONE option in a choice menu. Add a UART1 choice so
> that users can still choose UART1 explicitly.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> On 09/16/11 04:41, Will Deacon wrote:
> > Ah yes. This will need to be added as part of the platform updates to go via
> > Arnd. It should be easy enough just to have a DEBUG_CLPS711X_UART1 option,
> > for example, and the platform code will fall back to the first UART.
>
> I couldn't find these patches applied in Arnd's tree so I based it off of
> Russell's for-next branch.
Thanks for cooking the patch, it was somewhere on my list of things to do
this week! I think we also need to fix the DEBUG_DC21285_PORT option as that
has a similar `if not selected then use a different UART' behaviour. It can be
fixed in the same way as you have done in this patch.
Would you like me to take the three patches in with the ones I currently
have for other platforms (Realview, Samsung, imx) or would you prefer to
handle these separately? I was planning to send all of the platform bits to
Arnd once I've got my branches sorted out (been on holiday for the past two
weeks).
Cheers,
Will
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Rob Herring @ 2011-09-19 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6v9nd5f5x-eu9hUyAqdS1+p3h6ixyutECYLdNo3ewDH0w@mail.gmail.com>
On 09/19/2011 04:14 PM, Grant Likely wrote:
> On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring <robherring2@gmail.com> wrote:
>> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>>> I was headed down the path of implementing the 2nd option above,
>>>> but had a dilemma. What would be the numbering base for PPIs in
>>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>>> stay at 16?
>>>
>>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>>> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
>>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>>> processor has its own private timers that can generate interrupts,
>>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>>> its own watchdog timers that can generate interrupts, using ID30.
>>>
>>> So in that case, it can makes sense to use the ID. But it is
>>> interesting to note that the PPI is identified with a 0 based index
>>> number.
>>>
>> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
>> for the timer interrupt. The first would match 0 based SPI convention.
>> The last 2 would both match the documentation. We could never use 2 as
>> this will for sure be different and the GIC code will have no way to
>> know how to do the translation to ID. The only sane choice is using the
>> ID as you say.
>>
>> But you can't have it both ways. It does not make sense to use the ID
>> for some interrupts and a different scheme for others.
>
> Hmmm, it seems to me that some orthogonal issues are getting
> conflated. Specifically, the binding vs. what the GIC driver using
> internally. For my own understanding, let me see if I can summarize
> and clarify the problem.
>
> Each GIC IRQ is represented in 5 different ways:
> 1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
> 2) The DT binding to represent the connection.
> 3) The Interrupt ID as specified by the GIC architecture reference[1]
> (SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
> 4) The internal HWIRQ representation used by the GIC driver
> 5) The Linux VIRQ number that #4 maps to.
>
> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html
>
> Some thoughts:
> - Generally the DT binding (#2) should reflect the HW view of the
> system (#1) since that is the number most likely to be represented in
> hardware manuals. The interrupt ID is an internal detail of the GIC,
> and isn't really exposed in the block diagram of the hardware.
> - Presumably it is preferable for the GIC to directly use the
> Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
> efficient from an interrupt handling perspective, and indeed this is
> currently what the GIC driver does.
> - Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
> (#3/#4) is trivial, and easily managed by the GIC's irq_domain.
> - Though not necessarily as trivial, the mapping between Linux VIRQ
> and HWIRQ is not fixed, and when migrating to DT it should be assumed
> to be assigned at runtime. Perhaps not so important for a core IRQ
> controller like the GIC (as opposed to an i2c irq expander), but
> assuming an fixed offset still should be avoided. We may still force
> a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
> necessary and the driver still needs to support remapping for a
> secondary GIC.
The irq base is dynamic in my series, but is typically still GIC ID =
VIRQ for a primary GIC for now. A platform can adjust this with
irq_alloc_descs if necessary (but recommended not to of course).
>
> So, for the GIC DT binding, I'm inclined to agree with Benoit that the
> binding should reflect the hardware connections, not the values used
> by software for decoding IRQs. Also, I see absolutely no need to use
> separate nodes for each GIC interrupt space. The DT interrupt
> specifier number space can more than handle the features of the GIC in
> a clear and concise manor. So, here's my counter proposal for a GIC
> bindings (using Rob's text as the starting point):
>
> ----
>
> * ARM Generic Interrupt Controller
>
> ARM SMP cores are often associated with a GIC, providing per processor
> interrupts (PPI), shared processor interrupts (SPI) and software
> generated interrupts (SGI).
>
> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> Secondary GICs are cascaded into the upward interrupt controller and do not
> have PPIs or SGIs.
>
> Main node required properties:
>
> - compatible : should be one of:
> "arm,cortex-a9-gic"
> "arm,arm11mp-gic"
> - interrupt-controller : Identifies the node as an interrupt controller
> - #interrupt-cells : Specifies the number of cells needed to encode an
> interrupt source. The type shall be a <u32> and the value shall be 3.
>
> The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> interrupts.
> The 2nd cell contains the interrupt number for the interrupt type.
> SPI interrupts are in the range [0-987]. PPI interrupts are in the
> range [0-15].
> The 3rd cell is the flags, encoded as follows:
> bits[3:0] trigger type and level flags.
> 1 = low-to-high edge triggered
> 2 = high-to-low edge triggered
> 4 = active high level-sensitive
> 8 = active low level-sensitive
> bits[15:8] PPI interrupt cpu mask. Each bit corresponds to
> each of the 8 possible cpus attached to the GIC. A bit set to '1'
> indicated the interrupt is wired to that CPU. Only valid for PPI
> interrupts.
>
How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
drop the first cell.
> (Alternately, if there is no need for a CPU mask because PPI
> interrupts will never be wired to more than one CPU, then it would be
> better to encode the CPU number into the second cell with the SPI
> number).
You meant PPI number, right? ^^^
The common case at least on the A9 is a PPI is routed to all cores. QC
is different though. This was discussed previously. Basically, anything
is possible here, so the mask is needed for sure.
Overall I'm fine with this and just happy to have some conclusion. I
will send out an updated series if there are no further comments.
Rob
>
> - reg : Specifies base physical address(s) and size of the GIC registers. The
> first 2 values are the GIC distributor register base and size. The 2nd 2
> values are the GIC cpu interface register base and size.
>
> Optional
> - interrupts : Interrupt source of the parent interrupt controller. Only
> present on secondary GICs.
>
> Example:
> intc: interrupt-controller at fff11000 {
> compatible = "arm,cortex-a9-gic";
> #interrupt-cells = <3>;
> #address-cells = <1>;
> interrupt-controller;
> reg = <0xfff11000 0x1000>,
> <0xfff10100 0x100>;
> };
^ permalink raw reply
* [PATCH] arm: Add unwinding annotations for 64bit division functions
From: Laura Abbott @ 2011-09-19 22:11 UTC (permalink / raw)
To: linux-arm-kernel
The 64bit division functions never had unwinding annotations
added. This prevents a backtrace from being printed within
the function and if a division by 0 occurs. Add the annotations.
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
---
arch/arm/lib/div64.S | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/div64.S b/arch/arm/lib/div64.S
index faa7748..e55c484 100644
--- a/arch/arm/lib/div64.S
+++ b/arch/arm/lib/div64.S
@@ -13,6 +13,7 @@
*/
#include <linux/linkage.h>
+#include <asm/unwind.h>
#ifdef __ARMEB__
#define xh r0
@@ -44,6 +45,7 @@
*/
ENTRY(__do_div64)
+UNWIND(.fnstart)
@ Test for easy paths first.
subs ip, r4, #1
@@ -189,7 +191,12 @@ ENTRY(__do_div64)
moveq yh, xh
moveq xh, #0
moveq pc, lr
+UNWIND(.fnend)
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+Ldiv0_64:
@ Division by 0:
str lr, [sp, #-8]!
bl __div0
@@ -200,4 +207,5 @@ ENTRY(__do_div64)
mov xh, #0
ldr pc, [sp], #8
+UNWIND(.fnend)
ENDPROC(__do_div64)
--
1.7.3.3
^ permalink raw reply related
* [PATCH 1/2] ARM: debug: Add CLSP711X_UART1 config choice
From: Stephen Boyd @ 2011-09-19 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919212502.GB23613@e102144-lin.cambridge.arm.com>
On 09/19/11 14:25, Will Deacon wrote:
> Hi Stephen,
>
> On Mon, Sep 19, 2011 at 07:01:39PM +0100, Stephen Boyd wrote:
>> ARM patch 7072/1 (debug: use kconfig choice for selecting
>> DEBUG_LL UART) only allowed CLSP711X_UART2 to be selected because
>> there is no NONE option in a choice menu. Add a UART1 choice so
>> that users can still choose UART1 explicitly.
>>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>
>> On 09/16/11 04:41, Will Deacon wrote:
>>> Ah yes. This will need to be added as part of the platform updates to go via
>>> Arnd. It should be easy enough just to have a DEBUG_CLPS711X_UART1 option,
>>> for example, and the platform code will fall back to the first UART.
>> I couldn't find these patches applied in Arnd's tree so I based it off of
>> Russell's for-next branch.
> Thanks for cooking the patch, it was somewhere on my list of things to do
> this week! I think we also need to fix the DEBUG_DC21285_PORT option as that
> has a similar `if not selected then use a different UART' behaviour. It can be
> fixed in the same way as you have done in this patch.'
Ah my eyes glossed over the DC21285 one. Here's one on top of patch 2.
Feel free to squash, etc.
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9661c51..b976e04 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -93,14 +93,19 @@ choice
It does include a timeout to ensure that the system does not
totally freeze when there is nothing connected to read.
+ config DEBUG_DC21285_PORT1
+ bool "Kernel low-level debugging messages via footbridge serial port 1"
+ depends on FOOTBRIDGE
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the first serial port in the DC21285.
+
config DEBUG_DC21285_PORT
- bool "Kernel low-level debugging messages via footbridge serial port"
+ bool "Kernel low-level debugging messages via footbridge serial port 2"
depends on FOOTBRIDGE
help
Say Y here if you want the debug print routines to direct
- their output to the serial port in the DC21285 (Footbridge).
- Saying N will cause the debug messages to appear on the first
- 16550 serial port.
+ their output to the second serial port in the DC21285.
config DEBUG_CLPS711X_UART1
bool "Kernel low-level debugging messages via UART1"
>
> Would you like me to take the three patches in with the ones I currently
> have for other platforms (Realview, Samsung, imx) or would you prefer to
> handle these separately? I was planning to send all of the platform bits to
> Arnd once I've got my branches sorted out (been on holiday for the past two
> weeks).
>
If you want to handle them that sounds fine. I can't figure out who is
coordinating the DEBUG_LL changes. It seems that Russell has at least
applied the initial DEBUG_LL patches, so his tree will have some
breakage without this fixup patch.
I have some more patches on top of this one for MSM DEBUG_LL support
too. Hopefully I can send them out in a little bit.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* alloc_safe_buffer/map_single problem related to ath9k on ARM
From: B. J. @ 2011-09-19 22:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I've been fighting with a DMA problem on my ARM system, and have reached the point of crying out for a bit of help. Hopefully someone has some ideas on what I can do to get past this...
The platform in question is an IXP43x-based processor with an ath9k WiFi on the PCI bus, running a late 2.6.3x kernel (have been experimenting with different versions to no avail).
The original problem is that, under network load over the WiFi, I get these messages:
ath9k 0000:00:02.0: alloc_safe_buffer: could not alloc dma memory (size=87)
ath9k 0000:00:02.0: map_single: unable to map unsafe buffer cf733828!
ath9k 0000:00:02.0: alloc_safe_buffer: could not alloc dma memory (size=174)
ath9k 0000:00:02.0: map_single: unable to map unsafe buffer c7ea4c5e!
ath9k 0000:00:02.0: alloc_safe_buffer: could not alloc dma memory (size=1484)
ath9k 0000:00:02.0: map_single: unable to map unsafe buffer cf734028!
and eventually the system runs out of kernel memory and the OOM killer kicks in (yeah, so there's multiple problems here).
I've been experimenting with various DMA/bounce-buffer patches, HIGHMEM configuration, and changing CONSISTENT_DMA_SIZE from 2M to 4M, but none of the changes resolve this problem, and the latter just causes a kernel assertion failure.
My understanding of what's causing this is that there is a really tiny amount of DMA-able memory available - 2MB - and I'm overrunning that while beating on the WiFi. I'm not knowledgeable enough about the particulars of this platform to understand if it really is limited to 2MB of DMA memory (that seems crazily tiny!) or if this is a problem in the ath9k driver itself.
Here are some details:
Linux 2.6.35.12 armv5teb
...
CPU: XScale-IXP43x Family [69054041] revision 1 (ARMv5TE), cr=000039ff
...
free_area_init_node: node 0, pgdat c03dc890, node_mem_map c4000000
DMA zone: 128 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 16256 pages, LIFO batch:3
Normal zone: 384 pages used for memmap
Normal zone: 48768 pages, LIFO batch:15
...
Memory: 256MB = 256MB total
Memory: 255756k/255756k available, 6388k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.init : 0xc0008000 - 0xc0023000 ( 108 kB)
.text : 0xc0023000 - 0xc03b6000 (3660 kB)
.data : 0xc03b6000 - 0xc03de260 ( 161 kB)
# cat /sys/devices/pci0000\:00/0000\:00\:02.0/pools
poolinfo - 0.1
large_dmabounce_pool 0 0 4096 0
small_dmabounce_pool 21 50 2048 25
# cat /sys/devices/pci0000\:00/0000\:00\:02.0/dmabounce_stats
1113 0 0 1113 28292 1092
#
Any advice appreciated!
--
-bp
^ permalink raw reply
* alloc_safe_buffer/map_single problem related to ath9k on ARM
From: Russell King - ARM Linux @ 2011-09-19 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <769353EF-E030-494A-B1FE-7D6614B2C1AF@comcast.net>
On Mon, Sep 19, 2011 at 03:26:54PM -0700, B. J. wrote:
> The original problem is that, under network load over the WiFi, I get
> these messages:
>
> ath9k 0000:00:02.0: alloc_safe_buffer: could not alloc dma memory (size=87)
> ath9k 0000:00:02.0: map_single: unable to map unsafe buffer cf733828!
> ath9k 0000:00:02.0: alloc_safe_buffer: could not alloc dma memory (size=174)
> ath9k 0000:00:02.0: map_single: unable to map unsafe buffer c7ea4c5e!
> ath9k 0000:00:02.0: alloc_safe_buffer: could not alloc dma memory (size=1484)
> ath9k 0000:00:02.0: map_single: unable to map unsafe buffer cf734028!
>
> and eventually the system runs out of kernel memory and the OOM killer
> kicks in (yeah, so there's multiple problems here).
It shouldn't end up running out of memory - that implies there's a leak
somewhere. And I think I know where it is - could you try this patch
please? It won't solve the messages above but it should prevent the
resulting OOM.
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 0a0a1e7..c3ff82f 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -324,6 +324,8 @@ __dma_alloc(struct device *dev, size_t size, dma_addr_t *handle, gfp_t gfp,
if (addr)
*handle = pfn_to_dma(dev, page_to_pfn(page));
+ else
+ __dma_free_buffer(page, size);
return addr;
}
^ permalink raw reply related
* [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Troy Kisky @ 2011-09-19 22:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316346852-17090-4-git-send-email-shawn.guo@linaro.org>
On 9/18/2011 4:54 AM, Shawn Guo wrote:
> With the unnecessary 1 bit left-shift on fep->phy_speed during the
> calculation, the phy_speed always runs at the half frequency of the
> optimal one 2.5 MHz.
>
> The patch removes that 1 bit left-shift to get the optimal phy_speed.
>
> Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
> ---
> drivers/net/fec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 5ef0e34..04206e4 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> /*
> * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
> */
> - fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000)<< 1;
> + fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
> writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
>
> fep->mii_bus = mdiobus_alloc();
Do you need to round up to an even value? Is the hardware documentation
wrong?
Does this need a quirk? What boards has this been verified to fix?
Thanks
Troy
^ permalink raw reply
* [PATCH 1/2] ARM: debug: Add CLSP711X_UART1 config choice
From: Russell King - ARM Linux @ 2011-09-19 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E77BE34.6070702@codeaurora.org>
On Mon, Sep 19, 2011 at 03:12:04PM -0700, Stephen Boyd wrote:
> On 09/19/11 14:25, Will Deacon wrote:
> > Thanks for cooking the patch, it was somewhere on my list of things to do
> > this week! I think we also need to fix the DEBUG_DC21285_PORT option as that
> > has a similar `if not selected then use a different UART' behaviour. It can be
> > fixed in the same way as you have done in this patch.'
>
> Ah my eyes glossed over the DC21285 one. Here's one on top of patch 2.
> Feel free to squash, etc.
Err, the DC21285 only has one serial port.
Some footbridge platforms expose the DC21285 to the outside world, others
don't. Some footbridge platforms have a separate 8250 UART at the standard
PCI COM1 address, others don't.
What DEBUG_DC21285_PORT is selecting between is whether to use the DC21285
port (when set) or the 8250 at PCI COM1 (when unset).
^ permalink raw reply
* [PATCH 1/2] ARM: debug: Add CLSP711X_UART1 config choice
From: Stephen Boyd @ 2011-09-19 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919224151.GB28237@n2100.arm.linux.org.uk>
On 09/19/11 15:41, Russell King - ARM Linux wrote:
> On Mon, Sep 19, 2011 at 03:12:04PM -0700, Stephen Boyd wrote:
>> On 09/19/11 14:25, Will Deacon wrote:
>>> Thanks for cooking the patch, it was somewhere on my list of things to do
>>> this week! I think we also need to fix the DEBUG_DC21285_PORT option as that
>>> has a similar `if not selected then use a different UART' behaviour. It can be
>>> fixed in the same way as you have done in this patch.'
>> Ah my eyes glossed over the DC21285 one. Here's one on top of patch 2.
>> Feel free to squash, etc.
> Err, the DC21285 only has one serial port.
>
> Some footbridge platforms expose the DC21285 to the outside world, others
> don't. Some footbridge platforms have a separate 8250 UART at the standard
> PCI COM1 address, others don't.
>
> What DEBUG_DC21285_PORT is selecting between is whether to use the DC21285
> port (when set) or the 8250 at PCI COM1 (when unset).
Ah ok. How about this instead?
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 9661c51..31896f4 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -93,14 +93,19 @@ choice
It does include a timeout to ensure that the system does not
totally freeze when there is nothing connected to read.
+ config DEBUG_FOOTBRIDGE_COM1
+ bool "Kernel low-level debugging messages via footbridge 8250 at PCI COM1"
+ depends on FOOTBRIDGE
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the 8250 at PCI COM1.
+
config DEBUG_DC21285_PORT
bool "Kernel low-level debugging messages via footbridge serial port"
depends on FOOTBRIDGE
help
Say Y here if you want the debug print routines to direct
their output to the serial port in the DC21285 (Footbridge).
- Saying N will cause the debug messages to appear on the first
- 16550 serial port.
config DEBUG_CLPS711X_UART1
bool "Kernel low-level debugging messages via UART1"
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* READ THIS: the next mach-types update
From: H Hartley Sweeten @ 2011-09-19 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110915102528.GI6267@n2100.arm.linux.org.uk>
On Thursday, September 15, 2011 3:25 AM, Russell King wrote:
>
> I'm going to be merging a mach-types update (the cut-down and the
> policy-conforming version) for the next merge window. This will mean
> that things WILL BREAK, and I will not notice that things have broken.
>
> In order to fix this, entries need to be fixed to conform to the
> requirements - where the machine_is_xxx() name is the same as the
> MACH_TYPE_xxx name and the CONFIG_MACH_xxx name too.
>
> Moreover, entries older than 12 months which have not been merged will
> be removed. It is not possible to automatically check for machine_is_xxx()
> usages as these could conflict with other architectures, and I'm
> certainly NOT checking for them by hand (I estimate that'd take a
> significant amount of manual effort to do.) What that means is that it
> is _important_ to get the core platform support in _first_ before any
> drivers which may make use of this.
Russell,
I posted support for MACH_VISION_EP9307 back in March and it's in your
patch tracker as 6851/1. I assumed it was still there because of the
work to clean up the ARM tree.
Is it possible to still get this patch merged and add the following
back to mach-types:
vision_ep9307 MACH_VISION_EP9307 VISION_EP9307 1578
Thanks,
Hartley
^ permalink raw reply
* [PATCH 1/2] ARM: debug: Add CLSP711X_UART1 config choice
From: Will Deacon @ 2011-09-19 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E77BE34.6070702@codeaurora.org>
On Mon, Sep 19, 2011 at 11:12:04PM +0100, Stephen Boyd wrote:
> On 09/19/11 14:25, Will Deacon wrote:
> >
> > Would you like me to take the three patches in with the ones I currently
> > have for other platforms (Realview, Samsung, imx) or would you prefer to
> > handle these separately? I was planning to send all of the platform bits to
> > Arnd once I've got my branches sorted out (been on holiday for the past two
> > weeks).
> >
>
> If you want to handle them that sounds fine. I can't figure out who is
> coordinating the DEBUG_LL changes. It seems that Russell has at least
> applied the initial DEBUG_LL patches, so his tree will have some
> breakage without this fixup patch.
I sent the main changes via Russell and I plan to send new platforms moving
to the Kconfig choice via Arnd. However, as you point out, there's some breakage
without your three patches applied, so actually it's probably best if you
send these via the patch system. In which case:
Acked-by: Will Deacon <will.deacon@arm.com>
(this is for the second version of the Footbridge patch too)
> I have some more patches on top of this one for MSM DEBUG_LL support
> too. Hopefully I can send them out in a little bit.
Ok, great. These are the ones that can go via Arnd with imx, Realview etc.
Cheers,
Will
^ permalink raw reply
* Sept 14th struct_clk discussion meetings notes
From: Deepak Saxena @ 2011-09-19 23:14 UTC (permalink / raw)
To: linux-arm-kernel
[Resend with update of l-a-k address in my alias to the correct
one on infradead].
A group of us met at Linux Plumber's Conf two weeks ago to
discuss struct clk and how we move forward with it. Several
of us had a follow up phone call last week, on Wed the 14th,
and what follows are meeting notes from this follow up
discussion (I've seem to have lost the notepad on which I
took notes during the LPC discussion).
Attendees:
Arnd Bergman
Stephen Boyd
Mark Brown
Thomas Gleixner
Shawn Guo
Saravana Kannan
Nicolas Pitre
Mike Turquette
Linus Walleij
Paul Walmsley
- Mike T.
- Remove set_parent and upstream clock arbitration
- Functionality is limited, but would work for OMAP as is
- We can add new features as needed
- Shawn
- Does not want to block new SoC support due to common clock
support not being ready. This is gating mx6 support being
merged upstream.
- Arnd
- Pre-req: Device Tree representation of struct clk before we
let these patches in.
- Mike T: Can we split the problems.
- Arnd: Yes?
- Thomas: Is not entirely separate.
Current patches are not enough to do actual representation of
building blocks. Need more than just the ops pointer structure.
Will look into what it would take the current patches and
then slowly add changes to building block.
- Stephen
- Want 1 tree lock instead of a framework lock:
+ Have 2 trees, 1 fast (1ms), 1 really slow (5ms)
- Thomas: Should be trivial to implement
- Once the traverse code is fixed, will be hard to change
the locking code, so need to get this right.
- Thomas: Need a clock tree base with its own lock and put
a struct clk tree into that tree base.
- Paul W.: How rate propagation would work across bases?
- Thomas: Should be doable with proper locking order, and
should not be too hard to solve. Non fast path.
- Can implement separate root clocks for right now
- tglx: separate struct clk from building block devices such
as frequency management.
- Paul W.
- Have multiple root clocks, but only one lock right now
- Figure out the scope of the patches to be.
Goal: get basic support for common struct clk upstream.
Get imx6 upstream w/o common struct clk
Has some bugs and races on existing code.
set_rate: Can parents be switched at same time?
operate under set_rate and set_parent as distinct operations.
clk_rate sample implementation: will only work in some limited
cases. Need to guarantee that clock is stable. There are lot
of hw specific that may not be possible to abstract.
Not true: "All parents are equal and should be treated the
same" during set_rate. From tglx: Looked at existing stuff
and noted that a lot of implementations share concepts...
walking a freq table or a divisor table. Paul: Agree,
can go into some sort of library code down the road.
in-tree vs out-of-tree: what's shipping on most device
is quite a bit more hacky and complex than what is
currently in mainline. Will need clock notifiers
before being able to use on real shipping devices.
Much code that calls clk_set_rate() assumes that code
will not be changed in the future.
Patch 1: good
Patch 2: needs a bit more thought
Patch 3: no comments yet
What do people think about having initial patches to convert
to using common clk struct but having sub-arch specific
set_rate and get_rate? General consensus: seems like a
good idea.
- Linus W.:
No major comments
- Nicolas:
Just listening in to understand the issues involved.
ACTION ITEMS:
- Thomas: will post updated patches by end of the week
- Others: Will post initial patches porting their platforms
to new patches as follow up.
- Deepak: Organize follow up call in two weeks and post to wider
audience to attend.
^ permalink raw reply
* [PATCH] arm: Add unwinding annotations for 64bit division functions
From: Nicolas Pitre @ 2011-09-19 23:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316470297-5063-1-git-send-email-lauraa@codeaurora.org>
On Mon, 19 Sep 2011, Laura Abbott wrote:
> The 64bit division functions never had unwinding annotations
> added. This prevents a backtrace from being printed within
> the function and if a division by 0 occurs. Add the annotations.
>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> ---
> arch/arm/lib/div64.S | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/lib/div64.S b/arch/arm/lib/div64.S
> index faa7748..e55c484 100644
> --- a/arch/arm/lib/div64.S
> +++ b/arch/arm/lib/div64.S
> @@ -13,6 +13,7 @@
> */
>
> #include <linux/linkage.h>
> +#include <asm/unwind.h>
>
> #ifdef __ARMEB__
> #define xh r0
> @@ -44,6 +45,7 @@
> */
>
> ENTRY(__do_div64)
> +UNWIND(.fnstart)
>
> @ Test for easy paths first.
> subs ip, r4, #1
> @@ -189,7 +191,12 @@ ENTRY(__do_div64)
> moveq yh, xh
> moveq xh, #0
> moveq pc, lr
> +UNWIND(.fnend)
>
> +UNWIND(.fnstart)
> +UNWIND(.pad #4)
> +UNWIND(.save {lr})
> +Ldiv0_64:
Why this phony fnend+fnstart here?
Nicolas
^ permalink raw reply
* [PATCH] CPUIdle: Reevaluate C-states under CPU load to favor deeper C-states
From: Kevin Hilman @ 2011-09-19 23:35 UTC (permalink / raw)
To: linux-arm-kernel
From: Nicole Chalhoub <n-chalhoub@ti.com>
While there is CPU load, program a C-state specific one-shot timer in
order to give CPUidle another opportunity to pick a deeper C-state
instead of spending potentially long idle times in a shallow C-state.
Long winded version:
When going idle with a high load average, CPUidle menu governor will
decide to pick a shallow C-state since one of the guiding principles
of the menu governor is "The busier the system, the less impact of
C-states is acceptable" (taken from cpuidle/governors/menu.c.)
That makes perfect sense.
However, there are missed power-saving opportunities for bursty
workloads with long idle times (e.g. MP3 playback.) Given such a
workload, because of the load average, CPUidle tends to pick a shallow
C-state. Because we also go tickless, this shallow C-state is used
for the duration of the idle period. If the idle period is long, a
deeper C state would've resulted in better power savings.
This patch provides an additional opportuntity for CPUidle to pick a
deeper C-state by programming a timer (with a C-state specific timeout)
such that the CPUidle governor will have another opportunity to pick a
deeper C-state.
Adding this timer for C-state reevaluation improved the load estimation
on our ARM/OMAP4 platform and increased the time spent in deep C-states
(~50% of idle time in C-states deeper than C1). A power saving of ~10mA
at battery level is observed during MP3 playback on OMAP4/Blaze board.
Signed-off-by: Nicole Chalhoub <n-chalhoub@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpuidle/cpuidle.c | 28 +++++++++++++++++++++++++-
| 39 ++++++++++++++++++++++++++++++++-----
include/linux/cpuidle.h | 4 +++
3 files changed, 63 insertions(+), 8 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 1994885..4b1ac0c 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -92,13 +92,33 @@ static void cpuidle_idle_call(void)
target_state->time += (unsigned long long)dev->last_residency;
target_state->usage++;
- /* give the governor an opportunity to reflect on the outcome */
- if (cpuidle_curr_governor->reflect)
+ hrtimer_cancel(&dev->cstate_timer);
+
+ /*
+ * Give the governor an opportunity to reflect on the outcome
+ * Do not take into account the wakeups due to the hrtimer, they
+ * should not impact the predicted idle time.
+ */
+ if ((!dev->hrtimer_expired) && cpuidle_curr_governor->reflect)
cpuidle_curr_governor->reflect(dev);
trace_power_end(0);
}
/**
+ * cstate_reassessment_timer - interrupt handler of the cstate hrtimer
+ * @handle: the expired hrtimer
+ */
+static enum hrtimer_restart cstate_reassessment_timer(struct hrtimer *handle)
+{
+ struct cpuidle_device *data =
+ container_of(handle, struct cpuidle_device, cstate_timer);
+
+ data->hrtimer_expired = 1;
+
+ return HRTIMER_NORESTART;
+}
+
+/**
* cpuidle_install_idle_handler - installs the cpuidle idle loop handler
*/
void cpuidle_install_idle_handler(void)
@@ -185,6 +205,10 @@ int cpuidle_enable_device(struct cpuidle_device *dev)
dev->enabled = 1;
+ dev->hrtimer_expired = 0;
+ hrtimer_init(&dev->cstate_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ dev->cstate_timer.function = cstate_reassessment_timer;
+
enabled_devices++;
return 0;
--git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 1b12870..fd54584 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -125,10 +125,21 @@ struct menu_device {
#define LOAD_INT(x) ((x) >> FSHIFT)
#define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
-static int get_loadavg(void)
+static int get_loadavg(struct cpuidle_device *dev)
{
- unsigned long this = this_cpu_load();
+ unsigned long this;
+ /*
+ * this_cpu_load() returns the value of rq->load.weight
+ * at the previous scheduler tick and not the current value.
+ * If the timer expired, that means we are in idle,there
+ * are no more runnable processes in the current queue
+ * =>return the current value of rq->load.weight which is 0.
+ */
+ if (dev->hrtimer_expired == 1)
+ return 0;
+ else
+ this = this_cpu_load();
return LOAD_INT(this) * 10 + LOAD_FRAC(this) / 10;
}
@@ -166,13 +177,13 @@ static inline int which_bucket(unsigned int duration)
* to be, the higher this multiplier, and thus the higher
* the barrier to go to an expensive C state.
*/
-static inline int performance_multiplier(void)
+static inline int performance_multiplier(struct cpuidle_device *dev)
{
int mult = 1;
/* for higher loadavg, we are more reluctant */
- mult += 2 * get_loadavg();
+ mult += 2 * get_loadavg(dev);
/* for IO wait tasks (per cpu!) we add 5x each */
mult += 10 * nr_iowait_cpu(smp_processor_id());
@@ -236,6 +247,7 @@ static int menu_select(struct cpuidle_device *dev)
int latency_req = pm_qos_request(PM_QOS_CPU_DMA_LATENCY);
int i;
int multiplier;
+ ktime_t timeout;
if (data->needs_update) {
menu_update(dev);
@@ -256,7 +268,7 @@ static int menu_select(struct cpuidle_device *dev)
data->bucket = which_bucket(data->expected_us);
- multiplier = performance_multiplier();
+ multiplier = performance_multiplier(dev);
/*
* if the correction factor is 0 (eg first time init or cpu hotplug
@@ -287,12 +299,27 @@ static int menu_select(struct cpuidle_device *dev)
break;
if (s->exit_latency > latency_req)
break;
- if (s->exit_latency * multiplier > data->predicted_us)
+ if (s->exit_latency * multiplier > data->predicted_us) {
+ /*
+ * Could not enter the next C-state because of a high
+ * load. Set a timer in order to check the load again
+ * after the timeout expires and re-evaluate cstate.
+ */
+ if (s->hrtimer_timeout != 0 && get_loadavg(dev)) {
+ timeout =
+ ktime_set(0,
+ s->hrtimer_timeout * NSEC_PER_USEC);
+ hrtimer_start(&dev->cstate_timer, timeout,
+ HRTIMER_MODE_REL);
+ }
break;
+ }
data->exit_us = s->exit_latency;
data->last_state_idx = i;
}
+ /* Reset hrtimer_expired which is set when the hrtimer fires */
+ dev->hrtimer_expired = 0;
return data->last_state_idx;
}
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 55215cc..8d11b52 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -16,6 +16,7 @@
#include <linux/module.h>
#include <linux/kobject.h>
#include <linux/completion.h>
+#include <linux/hrtimer.h>
#define CPUIDLE_STATE_MAX 8
#define CPUIDLE_NAME_LEN 16
@@ -37,6 +38,7 @@ struct cpuidle_state {
unsigned int exit_latency; /* in US */
unsigned int power_usage; /* in mW */
unsigned int target_residency; /* in US */
+ unsigned int hrtimer_timeout; /* in US */
unsigned long long usage;
unsigned long long time; /* in US */
@@ -97,6 +99,8 @@ struct cpuidle_device {
struct completion kobj_unregister;
void *governor_data;
struct cpuidle_state *safe_state;
+ struct hrtimer cstate_timer;
+ unsigned int hrtimer_expired;
};
DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ARM: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
From: Pedanekar, Hemant @ 2011-09-19 23:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110919174054.GE2937@atomide.com>
Tony Lindgren wrote on Monday, September 19, 2011 11:11 PM:
> device driver)
>
> * Pedanekar, Hemant <hemantp@ti.com> [110918 20:32]:
>>
>> Tony,
>> Kernel boots fine on TI816X (should also boot on TI814X) with your patch
>> and patches (including OSC clock fix) from series
>> http://www.spinics.net/lists/linux-omap/msg57011.html
>
> OK good to hear, I assume I can add your Tested-by then?
>
> Regards,
>
> Tony
Yes.
Thanks.
Hemant
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Grant Likely @ 2011-09-20 0:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E77B9E3.40004@gmail.com>
On Mon, Sep 19, 2011 at 3:53 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
>> * ARM Generic Interrupt Controller
>>
>> ARM SMP cores are often associated with a GIC, providing per processor
>> interrupts (PPI), shared processor interrupts (SPI) and software
>> generated interrupts (SGI).
>>
>> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> Secondary GICs are cascaded into the upward interrupt controller and do not
>> have PPIs or SGIs.
>>
>> Main node required properties:
>>
>> - compatible : should be one of:
>> ? ? ? ?"arm,cortex-a9-gic"
>> ? ? ? ?"arm,arm11mp-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>> ? interrupt source. ?The type shall be a <u32> and the value shall be 3.
>>
>> ? The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> interrupts.
>> ? The 2nd cell contains the interrupt number for the interrupt type.
>> SPI interrupts are in the range [0-987]. ?PPI interrupts are in the
>> range [0-15].
>> ? The 3rd cell is the flags, encoded as follows:
>> ? ? ? ? bits[3:0] trigger type and level flags.
>> ? ? ? ? ? ? ? ? ? ? 1 = low-to-high edge triggered
>> ? ? ? ? ? ? ? ? ? ? 2 = high-to-low edge triggered
>> ? ? ? ? ? ? ? ? ? ? 4 = active high level-sensitive
>> ? ? ? ? ? ? ? ? ? ? 8 = active low level-sensitive
>> ? ? ? ? bits[15:8] PPI interrupt cpu mask. ?Each bit corresponds to
>> each of the 8 possible cpus attached to the GIC. ?A bit set to '1'
>> indicated the interrupt is wired to that CPU. ?Only valid for PPI
>> interrupts.
>>
> How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
> drop the first cell.
Cells are cheap, and it is better to be explicit. It is certainly
easier to extend in the future too if the type cell is used.
g.
^ permalink raw reply
* Temporary change the URL of s5p tree for linux-next
From: Stephen Rothwell @ 2011-09-20 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001701cc76b6$50db0c40$f29124c0$%kim@samsung.com>
Hi,
On Mon, 19 Sep 2011 19:24:29 +0900 Kukjin Kim <kgene.kim@samsung.com> wrote:
>
> As you know, git.kernel.org has been down :(
>
> So please change the URL of s5p tree for linux-next.
> git://github.com/kgene/linux-samsung.git for-next.
I will switch from today.
> As a note, I'd like to restore to use git.kernel.org after available of
> git.kernel.org.
Understood.
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110920/fa29d334/attachment.sig>
^ permalink raw reply
* [PATCH] arm: Add unwinding annotations for 64bit division functions
From: Laura Abbott @ 2011-09-20 1:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1109191913210.12663@xanadu.home>
On Mon, September 19, 2011 4:22 pm, Nicolas Pitre wrote:
> On Mon, 19 Sep 2011, Laura Abbott wrote:
>
>> The 64bit division functions never had unwinding annotations
>> added. This prevents a backtrace from being printed within
>> the function and if a division by 0 occurs. Add the annotations.
>>
>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>> ---
>> arch/arm/lib/div64.S | 8 ++++++++
>> 1 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/lib/div64.S b/arch/arm/lib/div64.S
>> index faa7748..e55c484 100644
>> --- a/arch/arm/lib/div64.S
>> +++ b/arch/arm/lib/div64.S
>> @@ -13,6 +13,7 @@
>> */
>>
>> #include <linux/linkage.h>
>> +#include <asm/unwind.h>
>>
>> #ifdef __ARMEB__
>> #define xh r0
>> @@ -44,6 +45,7 @@
>> */
>>
>> ENTRY(__do_div64)
>> +UNWIND(.fnstart)
>>
>> @ Test for easy paths first.
>> subs ip, r4, #1
>> @@ -189,7 +191,12 @@ ENTRY(__do_div64)
>> moveq yh, xh
>> moveq xh, #0
>> moveq pc, lr
>> +UNWIND(.fnend)
>>
>> +UNWIND(.fnstart)
>> +UNWIND(.pad #4)
>> +UNWIND(.save {lr})
>> +Ldiv0_64:
>
> Why this phony fnend+fnstart here?
>
If a division by 0 occurs, we need to be able to access the saved LR on
the stack which is setup right before calling the __div0 function. This
can't go at the top of __do_div64 because if we try to do a backtrace from
within __do_div64 the annotation won't be correct as the LR was never
saved on the stack. (yes, __do_div64 is all register math but it's still
possible to take a prefetch abort in the middle of that function. Taking a
prefetch abort in the middle of __do_div64 is what found this issue in the
first place.) This setup handles both cases correctly.
>
> Nicolas
>
Laura
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 3/4] net/fec: set phy_speed to the optimal frequency 2.5 MHz
From: Shawn Guo @ 2011-09-20 2:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E77C4A2.1060802@boundarydevices.com>
On Mon, Sep 19, 2011 at 03:39:30PM -0700, Troy Kisky wrote:
> On 9/18/2011 4:54 AM, Shawn Guo wrote:
> >With the unnecessary 1 bit left-shift on fep->phy_speed during the
> >calculation, the phy_speed always runs at the half frequency of the
> >optimal one 2.5 MHz.
> >
> >The patch removes that 1 bit left-shift to get the optimal phy_speed.
> >
> >Signed-off-by: Shawn Guo<shawn.guo@linaro.org>
> >---
> > drivers/net/fec.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> >diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> >index 5ef0e34..04206e4 100644
> >--- a/drivers/net/fec.c
> >+++ b/drivers/net/fec.c
> >@@ -1007,7 +1007,7 @@ static int fec_enet_mii_init(struct platform_device *pdev)
> > /*
> > * Set MII speed to 2.5 MHz (= clk_get_rate() / 2 * phy_speed)
> > */
> >- fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000)<< 1;
> >+ fep->phy_speed = DIV_ROUND_UP(clk_get_rate(fep->clk), 5000000);
> > writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED);
> >
> > fep->mii_bus = mdiobus_alloc();
> Do you need to round up to an even value? Is the hardware
> documentation wrong?
The round up is something existed, and the patch does not touch that
part.
> Does this need a quirk? What boards has this been verified to fix?
>
I tested this on i.mx28, i.mx53 and i.mx6q. Do you see problem on
your platform?
--
Regards,
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