* Building for MMU-less vexpress targets
From: Rob Herring @ 2012-11-06 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106221437.GQ28327@n2100.arm.linux.org.uk>
On 11/06/2012 04:14 PM, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2012 at 09:14:49PM +0000, Arnd Bergmann wrote:
>> The other point is being able to build such a kernel, and this is what Will
>> seems to be interested in more. We have made VEXPRESS depend on
>> MULTIPLATFORM, which broke support for building a non-MMU vexpress kernel,
>> and I think we should fix that. The two options are either to make
>> vexpress be single-platform when building for !MMU, or to allow multiplatform
>> kernels to be built without MMU support in principle. I think the second
>> option is more logical and avoids complex Kconfig constructs.
>
> The other thing here is... why does a platform which _was_ able to be
> built in isolation from every other platform suddenly become incapable
> of being so when they join the multiplatform conglomerate? This just
> sounds totally perverse and wrong.
Arnd and I discussed this some at Connect regarding VExpress being
selected. This is only to prevent the warning that no machine is enabled
in a randconfig or user error case. We could simply remove this error or
make it a warning instead. Then selecting a single platform is a matter
of only selecting 1 platform.
> Surely it should be: platforms _not_ yet converted to multiplatform
> can't be selected with multi-platform support enabled?
>
> So, maybe the _proper_ solution here is:
>
> - change the big choice to be: config SINGLE_xxx
> - these select config MACH_FOO / PLAT_FOO / ARCH_FOO
> eg,
> config SINGLE_FOO
> bool "Support for foo platforms in single kernel"
> select MACH_FOO
> - add a final option: config MULTIPLATFORM
> - then add:
>
> config MULTI_FOO
> bool "Include support for foo platforms"
> select MACH_FOO
> depends on MULTIPLATFORM || !MMU
> ...
>
> config MACH_FOO
> bool
>
I'd rather see less xxx_FOO config symbols rather than more.
Wouldn't this break defconfigs?
Rob
> Now, we don't _have_ to have the single and multi variants if they aren't
> appropriate for the platform, but we can cover all the cases: a platform
> where it's part of the multi-platform kernel when built for MMU, but is
> incapable of being a multi-platform kernel when built without MMU.
>
> And we can do it without _too_ much Kconfig pain, and certainly without
> having to delve into anything beyond arch/arm/Kconfig.
>
> I'd suggest at that point we separate out this stuff into a separate
> file - arch/arm/Kconfig.mach, which contains all the platform selection
> stuff.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [RFC PATCH 4/4] ARM: gic: use a private mapping for CPU target interfaces
From: Nicolas Pitre @ 2012-11-06 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106221651.GE21764@mudshark.cambridge.arm.com>
On Tue, 6 Nov 2012, Will Deacon wrote:
> On Tue, Oct 16, 2012 at 02:21:48PM +0100, Lorenzo Pieralisi wrote:
> > From: Nicolas Pitre <nicolas.pitre@linaro.org>
> >
> > The GIC interface numbering does not necessarily follow the logical
> > CPU numbering, especially for complex topologies such as multi-cluster
> > systems.
> >
> > Fortunately we can easily probe the GIC to create a mapping as the
> > Interrupt Processor Targets Registers for the first 32 interrupts are
> > read-only, and each field returns a value that always corresponds to
> > the processor reading the register.
> >
> > Initially all mappings target all CPUs in case an IPI is required to
> > boot secondary CPUs. It is refined as those CPUs discover what their
> > actual mapping is.
> >
> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> This is a really neat idea!
>
> > ---
> > arch/arm/common/gic.c | 42 ++++++++++++++++++++++++++++++++++--------
> > 1 file changed, 34 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> > index aa52699..1338a55 100644
> > --- a/arch/arm/common/gic.c
> > +++ b/arch/arm/common/gic.c
> > @@ -70,6 +70,13 @@ struct gic_chip_data {
> > static DEFINE_RAW_SPINLOCK(irq_controller_lock);
> >
> > /*
> > + * The GIC mapping of CPU interfaces does not necessarily match
> > + * the logical CPU numbering. Let's use a mapping as returned
> > + * by the GIC itself.
> > + */
> > +static u8 gic_cpu_map[8] __read_mostly;
>
> Can we have a #define for the number CPUs supported by the GIC? It gets
> used a fair amount in this patch for loop bounds etc.
Sure. I'll respin the patch.
>
> > +/*
> > * Supported arch specific GIC irq extension.
> > * Default make them NULL.
> > */
> > @@ -242,7 +249,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
> > return -EINVAL;
> >
> > mask = 0xff << shift;
> > - bit = 1 << (cpu_logical_map(cpu) + shift);
> > + bit = gic_cpu_map[cpu] << shift;
> >
> > raw_spin_lock(&irq_controller_lock);
> > val = readl_relaxed(reg) & ~mask;
> > @@ -349,11 +356,6 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
> > u32 cpumask;
> > unsigned int gic_irqs = gic->gic_irqs;
> > void __iomem *base = gic_data_dist_base(gic);
> > - u32 cpu = cpu_logical_map(smp_processor_id());
> > -
> > - cpumask = 1 << cpu;
> > - cpumask |= cpumask << 8;
> > - cpumask |= cpumask << 16;
> >
> > writel_relaxed(0, base + GIC_DIST_CTRL);
> >
> > @@ -366,6 +368,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
> > /*
> > * Set all global interrupts to this CPU only.
> > */
> > + cpumask = readl_relaxed(base + GIC_DIST_TARGET + 0);
> > for (i = 32; i < gic_irqs; i += 4)
> > writel_relaxed(cpumask, base + GIC_DIST_TARGET + i * 4 / 4);
> >
> > @@ -389,9 +392,25 @@ static void __cpuinit gic_cpu_init(struct gic_chip_data *gic)
> > {
> > void __iomem *dist_base = gic_data_dist_base(gic);
> > void __iomem *base = gic_data_cpu_base(gic);
> > + unsigned int cpu_mask, cpu = smp_processor_id();
> > int i;
> >
> > /*
> > + * Get what the GIC says our CPU mask is.
> > + */
> > + BUG_ON(cpu >= 8);
> > + cpu_mask = readl_relaxed(dist_base + GIC_DIST_TARGET + 0);
>
> Making the mask a u8 and using readb_relaxed here makes this bit of code
> clearer to me (and the GIC apparently allows such an access to this
> register).
Not always. At least RTSM throws an exception if you do so.
Been there.
> > + gic_cpu_map[cpu] = cpu_mask;
> > +
> > + /*
> > + * Clear our mask from the other map entries in case they're
> > + * still undefined.
> > + */
> > + for (i = 0; i < 8; i++)
> > + if (i != cpu)
> > + gic_cpu_map[i] &= ~cpu_mask;
> > +
> > + /*
> > * Deal with the banked PPI and SGI interrupts - disable all
> > * PPI interrupts, ensure all SGI interrupts are enabled.
> > */
> > @@ -646,7 +665,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
> > {
> > irq_hw_number_t hwirq_base;
> > struct gic_chip_data *gic;
> > - int gic_irqs, irq_base;
> > + int gic_irqs, irq_base, i;
> >
> > BUG_ON(gic_nr >= MAX_GIC_NR);
> >
> > @@ -683,6 +702,13 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
> > }
> >
> > /*
> > + * Initialize the CPU interface map to all CPUs.
> > + * It will be refined as each CPU probes its ID.
> > + */
> > + for (i = 0; i < 8; i++)
> > + gic_cpu_map[i] = 0xff;
> > +
> > + /*
> > * For primary GICs, skip over SGIs.
> > * For secondary GICs, skip over PPIs, too.
> > */
> > @@ -737,7 +763,7 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> >
> > /* Convert our logical CPU mask into a physical one. */
> > for_each_cpu(cpu, mask)
> > - map |= 1 << cpu_logical_map(cpu);
> > + map |= gic_cpu_map[cpu];
> >
> > /*
> > * Ensure that stores to Normal memory are visible to the
>
> With those changes:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
> Will
>
^ permalink raw reply
* [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP
From: Sören Moch @ 2012-11-06 23:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106223257.GB30428@lunn.ch>
>>> For Armada 370/XP we have the same problem that for the commit
>>> cb01b63, so we applied the same solution: "The default 256 KiB
>>> coherent pool may be too small for some of the Kirkwood devices, so
>>> increase it to make sure that devices will be able to allocate their
>>> buffers with GFP_ATOMIC flag"
>>
>> I see a regression from linux-3.5 to linux-3.6 and think there might
>> be a fundamental problem
>> with this patch. On my Kirkwood system (guruplug server plus) with
>> linux-3.6.2 I see following
>> errors and corresponding malfunction even with further increased
>> (2M, 4M) pool size:
>>
>> Oct 19 00:41:22 guru kernel: ERROR: 4096 KiB atomic DMA coherent
>> pool is too small!
>> Oct 19 00:41:22 guru kernel: Please increase it with coherent_pool=
>> kernel parameter!
>>
>> So I had to downgrade to linux-3.5 which is running without problems.
>>
>> I use SATA and several DVB sticks (em28xx / drxk and dib0700).
>
> I'm guess its the DVB sticks which are causing the problems. We have a
> number of kirkwood devices with two SATA devices which had problems
> until we extended the coherent_pool. The DVB sticks are probably take
> more coherent RAM. There was also an issue found recently:
>
> http://www.spinics.net/lists/arm-kernel/msg203962.html
>
> That conversation has gone quiet, but that could be because the
> participants are at ELCE.
>
> Andrew
OK, I hope this GFP flag correction will help.
Could there be a fragmentation problem in the coherent_pool with the
different drivers running under heavy load?
With a pool size of 1M I see this error after several minutes, with a 4M
pool I see this error after several 10 minutes. Difficult to test, but not
acceptable on a production system.
Soeren
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Nicolas Pitre @ 2012-11-06 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211062114.49933.arnd@arndb.de>
On Tue, 6 Nov 2012, Arnd Bergmann wrote:
> On Tuesday 06 November 2012, Nicolas Pitre wrote:
> > I really think that it makes no sense at all to support !MMU kernels in
> > a multi-platform kernel build, even if the set of included platforms
> > were all !MMU. The kernel has to be linked for the physical address of
> > the target and not a common invariant virtual address.
>
> There are two separate aspects here: One is to run a kernel on !MMU that is
> built to support multiple platforms. I agree that this is rather pointless
> and not interesting.
>
> The other point is being able to build such a kernel, and this is what Will
> seems to be interested in more.
What's the point of building a pointless and uninteresting kernel?
Sure, wide build coverage is good. But pointless builds are not.
Comes a point where Kconfig should serve its purpose i.e. help the user
make a valid kernel configuration for himself. And I really think that
multi-platform and !MMU together don't make for a valid configuration
anymore.
> We have made VEXPRESS depend on MULTIPLATFORM, which broke support for
> building a non-MMU vexpress kernel, and I think we should fix that.
No argument there.
> The two options are either to make
> vexpress be single-platform when building for !MMU, or to allow multiplatform
> kernels to be built without MMU support in principle. I think the second
> option is more logical and avoids complex Kconfig constructs.
Well, I'd rather prefer to think that the first option is the most
logical between those 2 options, regardless of Kconfig complexity
issues.
I didn't look, but just making MULTIPLATFORM depend on !MMU, and
VEXPRESS depend on MULTIPLATFORM || MMU should be close to what is
needed, no?
Nicolas
^ permalink raw reply
* [PATCH 0/2 v2] net: at91_ether add dt and pinctrl support
From: David Miller @ 2012-11-06 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105073015.GM19021@game.jcrosoft.org>
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date: Mon, 5 Nov 2012 08:30:15 +0100
> Hi,
>
> v2: fix typo in doc + miising empty line
>
> This patch serie add dt and pinctrl support to the at91 ether
>
> this is need to use the network on at91rm9200 as we now have dt
> support on it
>
> Jean-Christophe PLAGNIOL-VILLARD (2):
> net: at91_ether: add dt support
> net: at91_ether: add pinctrl support
Series applied, thanks.
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Nicolas Pitre @ 2012-11-06 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106225105.GD10187@jl-vm1.vm.bytemark.co.uk>
On Tue, 6 Nov 2012, Jamie Lokier wrote:
> Nicolas Pitre wrote:
> > I really think that it makes no sense at all to support !MMU kernels in
> > a multi-platform kernel build, even if the set of included platforms
> > were all !MMU. The kernel has to be linked for the physical address of
> > the target and not a common invariant virtual address.
>
> Although there's likely to be approximately zero interest in
> multi-platform !MMU, relocating at boot time doesn't sound onerous,
> should it be needed. x86 kernels already do that. Maybe ARM kernels
> will eventually do that anyway for the same reason as x86.
We already have something similar but simpler: CONFIG_ARM_PATCH_PHYS_VIRT.
Except that the virtual address the kernel is using always remains the
same, even if the physical address can move. Although this is not the
case at the moment, the ARM kdump implementation could take advantage of
this ability and avoid the copying of memory around.
Nicolas
^ permalink raw reply
* Building for MMU-less vexpress targets
From: Jamie Lokier @ 2012-11-06 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1211061826090.21033@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 6 Nov 2012, Jamie Lokier wrote:
>
> > Nicolas Pitre wrote:
> > > I really think that it makes no sense at all to support !MMU kernels in
> > > a multi-platform kernel build, even if the set of included platforms
> > > were all !MMU. The kernel has to be linked for the physical address of
> > > the target and not a common invariant virtual address.
> >
> > Although there's likely to be approximately zero interest in
> > multi-platform !MMU, relocating at boot time doesn't sound onerous,
> > should it be needed. x86 kernels already do that. Maybe ARM kernels
> > will eventually do that anyway for the same reason as x86.
>
> We already have something similar but simpler: CONFIG_ARM_PATCH_PHYS_VIRT.
> Except that the virtual address the kernel is using always remains the
> same, even if the physical address can move. Although this is not the
> case at the moment, the ARM kdump implementation could take advantage of
> this ability and avoid the copying of memory around.
I wonder why x86 didn't go that route. Not that it matters.
-- Jamie
^ permalink raw reply
* [GIT PULL] OMAP: PM: misc. fixes for v3.8
From: Kevin Hilman @ 2012-11-06 23:47 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
Here's a small series that fixes some errata to make suspend/resume
work on OMAP4460.
This is not a regression and has been broken for awhile, so this is v3.8
material, not v3.7.
Kevin
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-fixes-pm
for you to fetch changes up to cd8ce159031813eb870a5f3d5b27c3be36cd6e3a:
ARM: OMAP4: retrigger localtimers after re-enabling gic (2012-11-05 14:26:43 -0800)
----------------------------------------------------------------
Some non-regression fixes for OMAP4460 PM support.
----------------------------------------------------------------
Colin Cross (1):
ARM: OMAP4: retrigger localtimers after re-enabling gic
Santosh Shilimkar (1):
ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.
Tero Kristo (1):
ARM: OMAP4: PM: add errata support
arch/arm/mach-omap2/common.h | 4 +++
arch/arm/mach-omap2/omap-headsmp.S | 38 ++++++++++++++++++++++++++++
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 9 ++++++-
arch/arm/mach-omap2/omap-smp.c | 39 +++++++++++++++++++++++++++-
arch/arm/mach-omap2/omap4-common.c | 42 ++++++++++++++++++++++++++++++-
arch/arm/mach-omap2/pm.h | 9 +++++++
arch/arm/mach-omap2/pm44xx.c | 1 +
7 files changed, 139 insertions(+), 3 deletions(-)
^ permalink raw reply
* [GIT PULL] OMAP: PM: cleanups for v3.8
From: Kevin Hilman @ 2012-11-06 23:49 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
Here is some PM related cleanup targetted for v3.8.
Kevin
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-cleanup-pm
for you to fetch changes up to 9bb053787d5ca12ec388bb5f871c79ffb83762ab:
ARM: OMAP2+: PM: VP: minor pr_warn updates (2012-10-25 14:32:34 -0700)
----------------------------------------------------------------
Minor pr_warn() cleanup for OMAP2+ Voltage Processor (VP)
----------------------------------------------------------------
Nishanth Menon (1):
ARM: OMAP2+: PM: VP: minor pr_warn updates
arch/arm/mach-omap2/vp.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
^ permalink raw reply
* [GIT PULL] OMAP: PM: SmartReflex updates for v3.8
From: Kevin Hilman @ 2012-11-06 23:50 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
Here's some minor platform_data related updates for SR for v3.8.
Kevin
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-sr
for you to fetch changes up to 98aed08e16c5f18d0c31fc07127bc163ccd0d04c:
ARM: OMAP: SmartReflex: pass device dependent data via platform data (2012-10-15 15:22:24 -0700)
----------------------------------------------------------------
OMAP: SmartReflex: pass device-independent data via platform_data
----------------------------------------------------------------
Jean Pihet (2):
ARM: OMAP: hwmod: align the SmartReflex fck names
ARM: OMAP: SmartReflex: pass device dependent data via platform data
arch/arm/mach-omap2/clock33xx_data.c | 12 +++----
arch/arm/mach-omap2/clock3xxx_data.c | 12 +++----
arch/arm/mach-omap2/clock44xx_data.c | 6 ++--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 ++---
arch/arm/mach-omap2/sr_device.c | 13 +++++++
drivers/power/avs/smartreflex.c | 54 ++++++++++--------------------
include/linux/power/smartreflex.h | 14 ++++++--
7 files changed, 61 insertions(+), 58 deletions(-)
^ permalink raw reply
* [GIT PULL] OMAP: PM: voltage layer updates for v3.8
From: Kevin Hilman @ 2012-11-06 23:56 UTC (permalink / raw)
To: linux-arm-kernel
Tony,
Here's a set of voltage layer updates for v3.8.
This implements all the framework changes necessary to get
auto-ret/auto-off working, but the main change to enable
auto-ret/auto-off is awaiting the functional power state changes that
are still under review/rework.
Also, this fixes that pesky VC warning about I2C config not matching
other channels that was reported by Russell.
Kevin
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-voltage
for you to fetch changes up to df7cded30ced539d3b4e6bae9f3011d98c069d41:
ARM: OMAP4: OPP: add OMAP4460 definitions (2012-11-05 15:31:49 -0800)
----------------------------------------------------------------
OMAP voltage layer updates towards supporting auto-retention/auto-off
----------------------------------------------------------------
Nishanth Menon (1):
ARM: OMAP3+: PM: VP: use uV for max and min voltage limits
Tero Kristo (13):
ARM: OMAP: voltage: renamed vp_vddmin and vp_vddmax fields
ARM: OMAP3+: voltage: introduce omap vc / vp params for voltagedomains
ARM: OMAP3: VC: calculate ramp times
ARM: OMAP4: voltage: add support for VOLTSETUP_x_OFF register
ARM: OMAP4: VC: calculate ramp times
ARM: OMAP: add support for oscillator setup
ARM: OMAP3+: vp: use new vp_params for calculating vddmin and vddmax
ARM: OMAP3+: voltage: use oscillator data to calculate setup times
ARM: OMAP: TWL: change the vddmin / vddmax voltages to spec
ARM: OMAP3+: voltage: remove unused volt_setup_time parameter
ARM: OMAP4: vc: fix channel configuration
ARM: OMAP4: VC: setup I2C parameters based on board data
ARM: OMAP4: TWL: enable high speed mode for PMIC communication
Vishwanath Sripathy (1):
ARM: OMAP4: OPP: add OMAP4460 definitions
arch/arm/mach-omap2/control.h | 1 +
arch/arm/mach-omap2/omap_opp_data.h | 9 +-
arch/arm/mach-omap2/omap_twl.c | 73 +----
arch/arm/mach-omap2/opp4xxx_data.c | 98 +++++-
arch/arm/mach-omap2/pm.c | 30 ++
arch/arm/mach-omap2/pm.h | 10 +
arch/arm/mach-omap2/vc.c | 451 ++++++++++++++++++++++++--
arch/arm/mach-omap2/vc.h | 8 +-
arch/arm/mach-omap2/vc3xxx_data.c | 22 ++
arch/arm/mach-omap2/vc44xx_data.c | 28 ++
arch/arm/mach-omap2/voltage.h | 44 ++-
arch/arm/mach-omap2/voltagedomains3xxx_data.c | 5 +
arch/arm/mach-omap2/voltagedomains44xx_data.c | 23 +-
arch/arm/mach-omap2/vp.c | 6 +-
arch/arm/mach-omap2/vp.h | 7 +
arch/arm/mach-omap2/vp3xxx_data.c | 10 +
arch/arm/mach-omap2/vp44xx_data.c | 15 +
17 files changed, 725 insertions(+), 115 deletions(-)
^ permalink raw reply
* [PATCHv3 1/6] arch: Change defconfigs to point to g_mass_storage.
From: Hans-Christian Egtvedt @ 2012-11-07 0:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <007d0b4e8872b877076918bd3268832e9ea9d667.1352237765.git.mina86@mina86.com>
Around Tue 06 Nov 2012 22:52:35 +0100 or thereabout, Michal Nazarewicz wrote:
> From: Michal Nazarewicz <mina86@mina86.com>
>
> The File-backed Storage Gadget (g_file_storage) is being removed, since
> it has been replaced by Mass Storage Gadget (g_mass_storage). This commit
> changes defconfigs point to the new gadget.
>
> Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> (fort AT91)
> Acked-by: Tony Lindgren <tony@atomide.com> (for omap1)
> ---
> arch/arm/configs/afeb9260_defconfig | 2 +-
> arch/arm/configs/at91sam9260_defconfig | 2 +-
> arch/arm/configs/at91sam9261_defconfig | 2 +-
> arch/arm/configs/at91sam9263_defconfig | 2 +-
> arch/arm/configs/at91sam9g20_defconfig | 2 +-
> arch/arm/configs/corgi_defconfig | 2 +-
> arch/arm/configs/davinci_all_defconfig | 2 +-
> arch/arm/configs/h7202_defconfig | 3 +--
> arch/arm/configs/magician_defconfig | 2 +-
> arch/arm/configs/mini2440_defconfig | 2 +-
> arch/arm/configs/omap1_defconfig | 3 +--
> arch/arm/configs/prima2_defconfig | 1 -
> arch/arm/configs/spitz_defconfig | 2 +-
> arch/arm/configs/stamp9g20_defconfig | 2 +-
> arch/arm/configs/viper_defconfig | 2 +-
> arch/arm/configs/zeus_defconfig | 2 +-
> arch/avr32/configs/atngw100_defconfig | 2 +-
> arch/avr32/configs/atngw100_evklcd100_defconfig | 2 +-
> arch/avr32/configs/atngw100_evklcd101_defconfig | 2 +-
> arch/avr32/configs/atngw100_mrmt_defconfig | 2 +-
> arch/avr32/configs/atngw100mkii_defconfig | 2 +-
> .../avr32/configs/atngw100mkii_evklcd100_defconfig | 2 +-
> .../avr32/configs/atngw100mkii_evklcd101_defconfig | 2 +-
> arch/avr32/configs/atstk1002_defconfig | 2 +-
> arch/avr32/configs/atstk1003_defconfig | 2 +-
> arch/avr32/configs/atstk1004_defconfig | 2 +-
> arch/avr32/configs/atstk1006_defconfig | 2 +-
> arch/avr32/configs/favr-32_defconfig | 2 +-
> arch/avr32/configs/hammerhead_defconfig | 2 +-
For all the AVR32 related changes +1 (-:
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
IMHO this patch is trivial and needed since you change all the users of a
certain symbol. Thanks for doing the maintenance.
<snipp diff>
--
mvh
Hans-Christian Egtvedt
^ permalink raw reply
* [GIT PULL] ARM: OMAP: DTS for 3.8
From: Tony Lindgren @ 2012-11-07 0:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5092ADE7.1030709@ti.com>
* Benoit Cousson <b-cousson@ti.com> [121101 10:16]:
> Hi Tony,
>
> Please pull some more OMAP5 and AM33xx data for 3.8.
> The branch contains as well some cleanup and the omap3-beagle support since the previous one was in fact a beagle-xm.
Thanks pulling into omap-for-v3.8/dt.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] ARM: OMAP: Timer and Counter DT Updates for v3.8
From: Tony Lindgren @ 2012-11-07 0:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50941812.2070501@ti.com>
* Jon Hunter <jon-hunter@ti.com> [121102 12:01]:
> Hi Tony,
>
> Please pull the remaining patches to migrate OMAP timers and counters
> over to use device-tree. I recommend applying this after Benoit's DT
> series for v3.8 [1].
>
> This branch contains ...
> - Handling OMAP3 secure timers with device-tree
> - Requesting timer by capability/feature
> - Adds new DT machine descriptor for OMAP3 GP devices
> - Look-up of clocksource/events timers from DT
> - Migrate dmtimer driver to use DT
>
> Cheers
> Jon
>
> [1] http://marc.info/?l=linux-omap&m=135179007210696&w=2
>
>
> The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
>
> Linux 3.7-rc3 (2012-10-28 12:24:48 -0700)
>
> are available in the git repository at:
>
> git at github.com:jonhunter/linux.git dev-dt-timer
Thanks pulling into omap-for-v3.8/dt branch.
Regards,
Tony
> for you to fetch changes up to 9883f7c8dd21acb90697582ca331f3f8a66ac054:
>
> ARM: OMAP2+: Add device-tree support for 32kHz counter (2012-11-02 13:16:31 -0500)
>
> ----------------------------------------------------------------
> Jon Hunter (5):
> ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
> ARM: OMAP: Add function to request a timer by capability
> ARM: OMAP3: Add generic machine descriptor for boards with OMAP3 GP devices
> ARM: OMAP: Add DT support for timer driver
> ARM: OMAP2+: Add device-tree support for 32kHz counter
>
> arch/arm/mach-omap2/board-generic.c | 17 +++
> arch/arm/mach-omap2/timer.c | 203 ++++++++++++++++++++++++-----
> arch/arm/plat-omap/dmtimer.c | 93 ++++++++++++-
> arch/arm/plat-omap/include/plat/dmtimer.h | 1 +
> 4 files changed, 275 insertions(+), 39 deletions(-)
^ permalink raw reply
* [GIT PULL] OMAP: PM: misc. fixes for v3.8
From: Tony Lindgren @ 2012-11-07 0:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877gpy2t0n.fsf@deeprootsystems.com>
* Kevin Hilman <khilman@deeprootsystems.com> [121106 15:49]:
> Tony,
>
> Here's a small series that fixes some errata to make suspend/resume
> work on OMAP4460.
>
> This is not a regression and has been broken for awhile, so this is v3.8
> material, not v3.7.
>
> Kevin
>
> The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
>
> Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-fixes-pm
Thanks pulling into omap-for-v3.8/fixes-non-critical.
Regards,
Tony
>
> for you to fetch changes up to cd8ce159031813eb870a5f3d5b27c3be36cd6e3a:
>
> ARM: OMAP4: retrigger localtimers after re-enabling gic (2012-11-05 14:26:43 -0800)
>
> ----------------------------------------------------------------
> Some non-regression fixes for OMAP4460 PM support.
>
> ----------------------------------------------------------------
> Colin Cross (1):
> ARM: OMAP4: retrigger localtimers after re-enabling gic
>
> Santosh Shilimkar (1):
> ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.
>
> Tero Kristo (1):
> ARM: OMAP4: PM: add errata support
>
> arch/arm/mach-omap2/common.h | 4 +++
> arch/arm/mach-omap2/omap-headsmp.S | 38 ++++++++++++++++++++++++++++
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 9 ++++++-
> arch/arm/mach-omap2/omap-smp.c | 39 +++++++++++++++++++++++++++-
> arch/arm/mach-omap2/omap4-common.c | 42 ++++++++++++++++++++++++++++++-
> arch/arm/mach-omap2/pm.h | 9 +++++++
> arch/arm/mach-omap2/pm44xx.c | 1 +
> 7 files changed, 139 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 0/6] OMAPDSS: enable DSS for Panda & SDP with devtree
From: Tony Lindgren @ 2012-11-07 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352121259-5836-1-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121105 05:16]:
> Hi,
>
> OMAPDSS device tree support is still some way in the future. Tony has requested
> to get DSS working for Panda & SDP boards with DT kernel, so that we'll have
> fully working boards with DT.
>
> This series makes a few hacks to get a working display on OMAP4 Panda and SDP
> boards. The idea is to setup the omapdss with the non-DT method, creating the
> omapdss devices and passing platform data to them. This setup code is called
> from board-generic for Panda and SDP boards.
>
> There was one problem with this approach: omapdss cannot get regulators using
> the omapdss's names fro the regulators. Thus there's a hack patch to get the
> regulators using the OMAP4 "native" regulator names, thus circumventing the
> problem.
>
> Tony, if these look good, how do you want to merge these? There are three parts
> here, and I think they can be merged independently if so wished:
>
> * .dts changes for the pinmuxing (2 patches)
Let's let Benoit queue these.
> * dss-common.c and board-generic.c changes (3 patches)
And I can take these.
> * DSS hack for the regulators (1 patch)
And you can take this.
> If one of those parts is missing, DSS won't start with DT kernel, but otherwise
> there shouldn't be any problems. So to avoid conflicts, I suggest that you take
> the first two parts, and I'll merge the DSS hack via omapdss tree.
Cool thanks for doing this. Looks OK to me until we have the DT bindings ready.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 1/2] mailbox: OMAP: introduce mailbox framework
From: Omar Ramirez Luna @ 2012-11-07 1:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509886A2.5060509@wwwdotorg.org>
Hi Stephen,
On 5 November 2012 21:40, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/05/2012 07:55 PM, Omar Ramirez Luna wrote:
>> Actually moving it from plat-omap, as this framework/driver code is
>> supposed to be under drivers/ folder. The framework should work with
>> the current supported OMAP processors (OMAP1+) that have mailbox and
>> can be used as a method of interprocessor communication.
>>
>> The mailbox hardware (in OMAP) uses a queued mailbox-interrupt mechanism
>> that provides a communication channel between processors through a set of
>> registers and their associated interrupt signals by sending and receiving
>> messages.
>
>> diff --git a/drivers/mailbox/mailbox.h b/drivers/mailbox/mailbox.h
>
> Is this a public interface to the driver? If so, shouldn't the header be
> in include/linux somewhere?
>
> Is this a generic interface to any mailbox driver? If so, then I don't
> think having "omap" in the symbol names is appropriate. If the header is
> specific to the OMAP driver, I don't think using the very generic
> filename "mailbox.h" is appropriate; use omap_mailbox.h instead?
It was a mixture between the two, the next patch splits the API from
the mailbox driver interfaces.
I kept the files named as plain mailbox.[ch], in hopes that we could
progress with the cleanup after moving the files from plat-omap, as it
seems they interfere with the current single Image effort, but if it
is preferred (as it seems to be) I can resend again after removing the
omap_ prefixes from the intended-to-be generic code.
Thanks,
Omar
^ permalink raw reply
* [PATCH 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
From: Kevin Hilman @ 2012-11-07 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EC04AE5@DBDE01.ent.ti.com>
"Bedia, Vaibhav" <vaibhav.bedia@ti.com> writes:
> On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote:
[...]
>>
>> Also, if there are drivers for these devices, won't this interfere?
>>
>
> Hmm, I can think of the following scenarios
>
> 1. Runtime PM adapted drivers are compiled in - We'll have to ensure that
> in their suspend callbacks they end up doing omap_hwmod_idle() via the
> runtime PM APIs.
That already happens for all omap_devices.
> In this case the omap_hwmod_enable() followed by omap_hwmod_idle() is
> not necessary in the PM code.
Correct.
> 2. The drivers are not compiled in - In this case, the hwmod code puts
> the IPs in standby during bootup so the first suspend-resume iteration
> will pass. During resuming, the SYSC configuration for forced standby will
> be lost,
Please clarify how the SYSC is lost in this case.
> so in the subsequent iterations these IPs won't go standby and the
> hwmod code does not touch them since they never got enabled. In this case
> we do need the sequence that is there currently.
>
> 3. For some reason the respective drivers don't idle the IPs during suspend -
> (no_idle_on_suspend flag for the hwmod in DT?). In this scenario I think
> we should abort the suspend process since we know that the suspend is not
> going to work.
Agreed.
> Is there some other scenario that needs to be covered?
You covered the ones I was thinking of.
> How about adding some flag in hwmod code for handling this? Something
> similar to what was done for MMC [1]. I think the problem that we have
> is in some ways similar to the one addressed in [1].
Except that in the absence of drivers, no hwmod code is executed on the
suspend/resume path.
Kevin
^ permalink raw reply
* [GIT PULL] OMAP: PM: cleanups for v3.8
From: Tony Lindgren @ 2012-11-07 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zk2u1edh.fsf@deeprootsystems.com>
* Kevin Hilman <khilman@deeprootsystems.com> [121106 15:51]:
> Tony,
>
> Here is some PM related cleanup targetted for v3.8.
>
> Kevin
>
>
> The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
>
> Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-cleanup-pm
>
> for you to fetch changes up to 9bb053787d5ca12ec388bb5f871c79ffb83762ab:
>
> ARM: OMAP2+: PM: VP: minor pr_warn updates (2012-10-25 14:32:34 -0700)
>
> ----------------------------------------------------------------
> Minor pr_warn() cleanup for OMAP2+ Voltage Processor (VP)
Thanks pulling into omap-for-v3.8/pm.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] OMAP: PM: SmartReflex updates for v3.8
From: Tony Lindgren @ 2012-11-07 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r4o61eax.fsf@deeprootsystems.com>
* Kevin Hilman <khilman@deeprootsystems.com> [121106 15:52]:
> Tony,
>
> Here's some minor platform_data related updates for SR for v3.8.
>
> Kevin
>
>
> The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
>
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-sr
>
> for you to fetch changes up to 98aed08e16c5f18d0c31fc07127bc163ccd0d04c:
>
> ARM: OMAP: SmartReflex: pass device dependent data via platform data (2012-10-15 15:22:24 -0700)
>
> ----------------------------------------------------------------
> OMAP: SmartReflex: pass device-independent data via platform_data
Thanks pulling into omap-for-v3.8/pm.
Regards,
Tony
^ permalink raw reply
* [GIT PULL] OMAP: PM: voltage layer updates for v3.8
From: Tony Lindgren @ 2012-11-07 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bofa1e11.fsf@deeprootsystems.com>
* Kevin Hilman <khilman@deeprootsystems.com> [121106 15:58]:
> Tony,
>
> Here's a set of voltage layer updates for v3.8.
>
> This implements all the framework changes necessary to get
> auto-ret/auto-off working, but the main change to enable
> auto-ret/auto-off is awaiting the functional power state changes that
> are still under review/rework.
>
> Also, this fixes that pesky VC warning about I2C config not matching
> other channels that was reported by Russell.
>
> Kevin
>
>
> The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
>
> Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/for_3.8-pm-voltage
>
> for you to fetch changes up to df7cded30ced539d3b4e6bae9f3011d98c069d41:
>
> ARM: OMAP4: OPP: add OMAP4460 definitions (2012-11-05 15:31:49 -0800)
>
> ----------------------------------------------------------------
> OMAP voltage layer updates towards supporting auto-retention/auto-off
Thanks pulling into omap-for-v3.8/pm.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 1/2] mailbox: OMAP: introduce mailbox framework
From: Omar Ramirez Luna @ 2012-11-07 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106085931.GA26335@kroah.com>
Hi Greg,
On 6 November 2012 02:59, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Tue, Nov 06, 2012 at 09:55:52AM +0100, Linus Walleij wrote:
>> On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>
>> > Is this a public interface to the driver? If so, shouldn't the header be
>> > in include/linux somewhere?
>>
>> I think the split out of the public header is done in patch 2/2.
>
> Yes, but the names are still omap_*, which doesn't make much sense here.
Ok, I have no problem with this...
I was under the impression that moving this code out of plat-omap was
blocking single zImage support hence the minimal changes to move it to
drivers/.
I will strip the generic portions from omap_ prefixes and resend.
Cheers,
Omar
^ permalink raw reply
* [PATCH 1/1] ARM: OMAP: Add maintainer entry for IGEP machines
From: Tony Lindgren @ 2012-11-07 1:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349686054-7486-1-git-send-email-javier@dowhile0.org>
* Javier Martinez Canillas <javier@dowhile0.org> [121008 01:49]:
> Enric and I have been mantained this machine and while we
> are moving to device trees, it is good that people cc us
> when reporting bugs or regression on the board file until
> we have proper DT support.
Thanks applying into omap-for-v3.8/board branch.
Regards,
Tony
^ permalink raw reply
* [RESEND] [PATCH 3.6.0- 1/6] ARM/omap1: use module_platform_driver macro
From: Tony Lindgren @ 2012-11-07 1:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350025868-30482-1-git-send-email-srinivas.kandagatla@st.com>
* Srinivas KANDAGATLA <srinivas.kandagatla@st.com> [121012 00:14]:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> This patch removes some code duplication by using
> module_platform_driver.
Sorry for delay on these, we're moving the mailbox code to
live under drivers, so these may need to wait a little bit.
Regards,
Tony
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> ---
> arch/arm/mach-omap1/mailbox.c | 14 +-------------
> 1 files changed, 1 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
> index e962926..45c8719 100644
> --- a/arch/arm/mach-omap1/mailbox.c
> +++ b/arch/arm/mach-omap1/mailbox.c
> @@ -179,19 +179,7 @@ static struct platform_driver omap1_mbox_driver = {
> .name = "omap-mailbox",
> },
> };
> -
> -static int __init omap1_mbox_init(void)
> -{
> - return platform_driver_register(&omap1_mbox_driver);
> -}
> -
> -static void __exit omap1_mbox_exit(void)
> -{
> - platform_driver_unregister(&omap1_mbox_driver);
> -}
> -
> -module_init(omap1_mbox_init);
> -module_exit(omap1_mbox_exit);
> +module_platform_driver(omap1_mbox_driver);
>
> MODULE_LICENSE("GPL v2");
> MODULE_DESCRIPTION("omap mailbox: omap1 architecture specific functions");
> --
> 1.7.0.4
>
^ permalink raw reply
* what's the purpose for the few bytes at the end of kernel stack
From: He, Dander @ 2012-11-07 1:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Recently I?m studying linux kernel. I have a question about the space after struct pt_regs in kernel stack.
Why reserved 8 bytes at the end of kernel stack for ARM and 32 bytes for MIPS?
Do you know what?s the purpose for it? Who and where use it?
I checked the real kernel stack for some processes. Some of them are all zero. Some of them are not.
Here are some sample data on ARM for those 8 bytes in different kernel stack:
0x55555575 0x55155545
0x5d555574 0xf17d5552
0x55155555 0x15155151
0x51555d55 0x55515545
0x5d555574 0x7579d552
0x55795534 0xf1055515
0xa83fc821 0xa83fcc21
0x55795534 0xf1055d15
0x557555dd 0x55659155
0x51555d55 0x55515545
0x5355545d 0x54c45135
0x57555455 0x6f45f545
Br/Dander
1. In arm, it?s reserved 8 bytes
kernel/arch/arm/include/asm/thread_info.h
#define THREAD_START_SP (THREAD_SIZE - 8)
2. In mips, it?s reserved 32 bytes.
kernel/arch/mips/kernel/r4k_switch.S
/*
* Offset to the current process status flags, the first 32 bytes of the
* stack are not used.
*/
#define ST_OFF (_THREAD_SIZE - 32 - PT_SIZE + PT_STATUS)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121107/6af4d04a/attachment-0001.html>
^ 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