* [PATCH v3 0/3] introduce static_vm for ARM-specific static mapped area
From: Nicolas Pitre @ 2013-01-29 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129065656.GC5131@lge.com>
On Tue, 29 Jan 2013, Joonsoo Kim wrote:
> On Mon, Jan 28, 2013 at 01:04:24PM -0500, Nicolas Pitre wrote:
> > On Mon, 28 Jan 2013, Will Deacon wrote:
> >
> > > Hello,
> > >
> > > On Thu, Jan 24, 2013 at 01:28:51AM +0000, Joonsoo Kim wrote:
> > > > In current implementation, we used ARM-specific flag, that is,
> > > > VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area.
> > > > The purpose of static mapped area is to re-use static mapped area when
> > > > entire physical address range of the ioremap request can be covered
> > > > by this area.
> > > >
> > > > This implementation causes needless overhead for some cases.
> > > > For example, assume that there is only one static mapped area and
> > > > vmlist has 300 areas. Every time we call ioremap, we check 300 areas for
> > > > deciding whether it is matched or not. Moreover, even if there is
> > > > no static mapped area and vmlist has 300 areas, every time we call
> > > > ioremap, we check 300 areas in now.
> > > >
> > > > If we construct a extra list for static mapped area, we can eliminate
> > > > above mentioned overhead.
> > > > With a extra list, if there is one static mapped area,
> > > > we just check only one area and proceed next operation quickly.
> > > >
> > > > In fact, it is not a critical problem, because ioremap is not frequently
> > > > used. But reducing overhead is better idea.
> > > >
> > > > Another reason for doing this work is for removing vm_struct list management,
> > > > entirely. For more information, look at the following link.
> > > > http://lkml.org/lkml/2012/12/6/184
> > >
> > > First patch looks good (removing the unused vmregion stuff) but I'm not so
> > > sure about the rest of it. If you really care about ioremap performance,
> > > perhaps it would be better to have a container struct around the vm_struct
> > > for static mappings and then stick them in an augmented rbtree so you can
> > > efficiently find the mapping encompassing a particular physical address?
> >
> > How can ioremap performance be a problem is the question I had since the
> > beginning.
> >
> > Firstly, ioremap is _not_ meant to be used in performance critical
> > paths.
> >
> > Secondly, there shouldn't be _that_ many entries on the vmlist such as
> > 300. That sounds a bit excessive.
> >
> > So please, can we discuss the reasons that motivated those patches in
> > the first place? Maybe that's where the actual problem is.
>
> Hello, Wiil and Nicolas.
> First of all, thanks for reviewing.
>
> There is another reason for doing this work.
> As mentioned above, I try to remove list management for vm_struct(vmlist),
> entirely. For that purpose, removing architecture dependency against vmlist
> is needed. Below link is for my RFC patch trying to remove list management
> for vm_struct.
>
> http://lkml.org/lkml/2012/12/6/184
OK, I get it now.
I do have comments on your patches. I'll provide them as a reply to
them.
Nicolas
^ permalink raw reply
* [GIT PULL] vexpress: fixes for v3.9
From: Olof Johansson @ 2013-01-29 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359484379.8090.25.camel@hornet>
On Tue, Jan 29, 2013 at 10:32 AM, Pawel Moll <pawel.moll@arm.com> wrote:
> git://git.linaro.org/people/pawelmoll/linux.git tags/vexpress/fixes-for-3.9
Applied to next/fixes-non-critical, i.e. for 3.9.
Thanks!
-Olof
^ permalink raw reply
* [RFC PATCH 1/2] ARM: kernel: update cpuinfo to print CPU model name
From: Ruslan Bilovol @ 2013-01-29 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129160827.GJ2637@n2100.arm.linux.org.uk>
Hi,
On Tue, Jan 29, 2013 at 6:08 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 29, 2013 at 05:54:24PM +0200, Ruslan Bilovol wrote:
>> CPU implementer : 0x41
>> CPU name : OMAP4470 ES1.0 HS
>
> Sigh. No. Look at what you're doing - look carefully at the above.
>
> "CPU implementer" - 0x41. That's A. For ARM Ltd. ARM Ltd implemented
> this CPU. Did ARM Ltd really implement OMAP4470 ? I think TI would be
> very upset if that were to be the case.
Yes, it would be very surprisingly :)
>
> So no, OMAP4470 is _NOT_ a CPU. It is a SoC. The CPU inside the SoC is
> a collection of ARM Ltd Cortex A9 _CPUs_.
>
> See? Please, learn what a CPU is as opposed to a SoC.
Completely agree with you. I will fix this
^ permalink raw reply
* [PATCH v2 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Catalin Marinas @ 2013-01-29 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301291734140.6300@xanadu.home>
On Tue, Jan 29, 2013 at 10:35:46PM +0000, Nicolas Pitre wrote:
> On Tue, 29 Jan 2013, Catalin Marinas wrote:
>
> > All the calls to gic_secondary_init() pass 0 as the first argument.
> > Since this function is called on each CPU when starting, it can be done
> > in a platform-independent way via a CPU notifier registered by the GIC
> > code.
> >
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Acked-by: Stephen Warren <swarren@nvidia.com>
> > Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Acked-by: Rob Herring <rob.herring@calxeda.com>
> > Acked-by: Simon Horman <horms+renesas@verge.net.au>
> > Tested-by: Simon Horman <horms+renesas@verge.net.au>
> > Acked-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Kukjin Kim <kgene.kim@samsung.com>
> > Cc: Sascha Hauer <kernel@pengutronix.de>
> > Cc: David Brown <davidb@codeaurora.org>
> > Cc: Bryan Huntsman <bryanh@codeaurora.org>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Magnus Damm <magnus.damm@gmail.com>
> > Cc: Dinh Nguyen <dinguyen@altera.com>
> > Cc: Shiraz Hashim <shiraz.hashim@st.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
>
> Acked-by: Nicolas Pitre <nico@linaro.org>
Thanks.
> What is your plan in terms of merge path and schedule? My mcpm series
> would depend on this.
I would like to get them in as soon as possible (ideally 3.9) as AArch64
needs GIC support. I can base them on Rob's branch (already in -next)
and send them the same route (the arm-soc tree if Olof/Arnd are ok to
take them).
--
Catalin
^ permalink raw reply
* [PATCH] mailbox: prevent pl320-ipc code from breaking none-AMBA systems
From: Rafael J. Wysocki @ 2013-01-29 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21672683C5A3814BB4DB938EBE482DE435D976610A@IAD2MBX09.mex02.mlsrvr.com>
On Tuesday, January 29, 2013 05:13:09 PM Mark Langsdorf wrote:
> > From: Rafael J. Wysocki [rjw at sisk.pl]
> > On Tuesday, January 29, 2013 10:36:53 AM Mark Langsdorf wrote:
> > > The pl320-ipc code depends on ARM AMBA, and should have the dependency
> > > in its Kconfig.
> >
> > May I fold this into "ARM / highbank: add support for pl320 IPC"?
>
> Yes. I didn't want to regenerate the patch series =)
Done.
Thanks,
Rafael
> > Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
> > ---
> > drivers/mailbox/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> > index 9489554..9545c9f 100644
> > --- a/drivers/mailbox/Kconfig
> > +++ b/drivers/mailbox/Kconfig
> > @@ -8,6 +8,7 @@ menuconfig MAILBOX
> > if MAILBOX
> > config PL320_MBOX
> > bool "ARM PL320 Mailbox"
> > + depends on ARM_AMBA
> > help
> > An implementation of the ARM PL320 Interprocessor Communication
> > Mailbox (IPCM), tailored for the Calxeda Highbank. It is used to
> >
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [RFC PATCH 0/2] ARM: update cpuinfo to print CPU model name
From: Ruslan Bilovol @ 2013-01-29 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129160243.GA3389@kahuna>
Hi,
On Tue, Jan 29, 2013 at 6:02 PM, Nishanth Menon <nm@ti.com> wrote:
>
> On 17:54-20130129, Ruslan Bilovol wrote:
> > Hi,
> >
> > The following patches update cpuinfo to print CPU
> > model name for ARM. First patch exactly makes needed
> > changes for ARM architecture.
> > Second patch adds this ability to OMAP4 SoCs.
> >
> > This adds a common approach to show SoC name.
> >
> > Looks like there were few attempts to do similar
> > changes to cpuinfo without any luck.
> >
> > So - comments are welcome
> >
> > Ruslan Bilovol (2):
> > ARM: kernel: update cpuinfo to print CPU model name
> > ARM: OMAP4: setup CPU model name during ID initialisation
>
> We had an discussion on similar lines but a generic suggestion:
> https://patchwork.kernel.org/patch/98720/
> SoCinfo framework which was supposed to introduce this
>
> Would'nt that be a better approach to take than an OMAP only solution?
My goal is only to say what is the SoC model name in the /proc/cpuinfo
(And it is not an OMAP-only solution - it is common. Support for OMAP
is added in second patch)
This is the only type of information that we can apply for any SoC.
My point is - any SoC-specific information should go through some other
way - like SoCinfo framework mentioned by you.
And additional point - in cpuinfo we already have CPU name and Machine name.
The SoC name (that is something between these two things) looks also relevant
>
> Ccying eduardo who had driven this for some time.
Yes, let's have additional comments
> --
> Regards,
> Nishanth Menon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 08/27] pci: implement an emulated PCI-to-PCI bridge
From: Arnd Bergmann @ 2013-01-29 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo6ajS87mh7u58sLeN6oL5ixiPhaD7O7BrH1Av28mTk=qQ@mail.gmail.com>
On Tuesday 29 January 2013, Bjorn Helgaas wrote:
> If you need this, it can be done in architecture code, can't it? It's
> true that there's nothing architecture-specific in this patch (other
> than the fact that ARM is the only arch that needs it), but I'm not
> sure there's anything useful for sharing here.
Since we're moving the host bridge code to drivers/pci/host now, I think
this code should live in the same place. It's entirely possible that
it will be shared between arch/arm and arch/arm64, although I would
hope that we can do away with the emulated bridge code entirely.
More generally speaking, this is infrastructure code, and for any
piece of infrastructure my rule is
* don't add platform specific infrastructure if it can be done at
the architecture level
* don't add architecture specific infrastructure if it can be
written in an architecture independent way
* don't add global infrastructure if you can use or extend the
existing infrastructure.
> In fact, it seems like what you're after is not so much an emulated
> bridge that has no corresponding hardware, as it is a wrapper that
> presents a standard PCIe interface to hardware that exists but doesn't
> conform to the PCIe spec. If you really do need to ultimately connect
> this pci_sw_pci_bridge to a piece of hardware, that will certainly be
> arch-specific.
As Jason Gunthorpe suggested, we might not need this at all, if the
Linux PCI code can be convinced not to need a configuration space
for the devices that in case of the Marvell hardware don't provide
one.
Arnd
^ permalink raw reply
* [BUG] snowball board locks up on boot
From: Linus Walleij @ 2013-01-29 23:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359047682.21576.154.camel@gandalf.local.home>
On Thu, Jan 24, 2013 at 6:14 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> I tried to get my snowball board working on the latest kernel, but it
> locks up hard very early on boot up.
>
> I bisected it down to this commit:
>
> commit ebc96db7632f987e0b9bffcb782cf5cfb8afb0dd
> Author: Ulf Hansson <ulf.hansson@linaro.org>
> Date: Mon Aug 27 15:45:53 2012 +0200
>
> ARM: ux500: Switch to use common clock framework
Yeah the new common clock framework is a bit like a heart
transplant on the platforms you convert, some fallout is expected.
However I thought we had all the clk fixes covered by -rc4 :-(
I don't have a Snowball right now myself, so have to ask
for help here (non snowball ux500's work just fine for me).
Lee, are you still booting the Snowball on new kernels
everyday, and do you know if some fix is still missing?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/5] ARM: sunxi: Increase the number of GPIOs available
From: Arnd Bergmann @ 2013-01-29 22:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbZhS1APd6bFEnh9OLJEnNMgtFOCmW8vz1fVP3+yKy7LQ@mail.gmail.com>
On Tuesday 29 January 2013, Linus Walleij wrote:
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1632,7 +1632,7 @@ config ARCH_NR_GPIO
> > default 355 if ARCH_U8500
> > default 264 if MACH_H4700
> > default 512 if SOC_OMAP5
> > - default 288 if ARCH_VT8500
> > + default 288 if ARCH_VT8500 || ARCH_SUNXI
>
> Can I have an ACK from the ARM SoC maintainers on this?
>
Acked-by: Arnd Bergmann <arnd@arndb.de>
for the change. Maybe you could also do a second patch on top that
sorts the lines by descending numbers and adds a comment? I think
for any multiplatform kernel, we have to pick the largest number
required by any of the enabled platforms.
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: David Sterba @ 2013-01-29 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359179447-31118-1-git-send-email-kyungsik.lee@lge.com>
On Sat, Jan 26, 2013 at 02:50:43PM +0900, Kyungsik Lee wrote:
> This patchset is for supporting LZ4 compressed kernel and initial ramdisk on
> the x86 and ARM architectures.
Have you considered the 'high compression' mode of lz4?
http://code.google.com/p/lz4/source/browse/trunk/lz4hc.c
The compression format remains the same, the compressor tries harder
(but is slower), resulting compression ratio is better.
an examle compression for vmlinux.bin of x86_64 build:
input size: 16509520 bytes
lz4 (svn 88):
output size: 6393684 (38.7%)
compression time: 41.7 ms (395 MB/s)
decompression time: 13.7 ms (1204 MB/s)
lz4hc (svn 88):
output size: 5319137 (32.2%)
compression time: 683 ms (24 MB/s)
decompression time: 13.1 ms (1259 MB/s)
compressed file delta: 6393684 - 5319137 = 1074547 ~ 1MB
tested on a Nehalem box; same test on my slow desktop gives
lz4:
compression time: 97 ms (169 MB/s)
decompression time: 25.7 ms (643 MB/s)
lz4hc:
compression time: 1386 ms (11 MB/s)
decompression time: 26 ms (619 MB/s)
While the decompression time is almost the same, image size is smaller.
The kernel image compression is run in userspace and the low speed is
not much of concern for a one-time operation.
For the reference, lzo (current kernel version) run on the destktop:
output size: 6026256 (36.5%)
decompression time: 79.6 ms (207 MB/s)
> It seems that it?s worth trying LZ4 compressed kernel image or ramdisk
> for making the kernel boot more faster.
There's another potential user of lz4: btrfs. I've submitted a feature
preview integrating lz4 compression
http://thread.gmane.org/gmane.comp.file-systems.btrfs/15744
and we have tried to integrate the HC mode as well
http://thread.gmane.org/gmane.comp.file-systems.btrfs/18165
.
So far it's on a slow track, conceptually it works, but I the code needs
some work so it could live under lib/* (we've used the svn sources
with minor changes, no kernel coding style). It would be easier for me
to enhance the existing lib/lz4/* codebase.
Also zram could consider lz4, I'm not sure if there are other potential
users.
david
^ permalink raw reply
* [PATCH 1/3] pinctrl: sunxi: Add of_xlate function
From: Maxime Ripard @ 2013-01-29 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZi0zCNf6LDd9UAcd57kFqqWyteVqxL8WfDrFfrt9_5sQ@mail.gmail.com>
Le 29/01/2013 23:41, Linus Walleij a ?crit :
> On Sun, Jan 27, 2013 at 8:02 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>
>> Since the pin controller of sunxi chips is represented as a single bank
>> in the driver.
>> Since this is neither convenient nor represented that way in the
>> datasheets, define a custom of_xlate function with the layout <bank pin
>> flag>
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> This does not apply and I only have 1/3 it seems?
>
> Sorry, help me understand which order these patches go in...
My bad, I forgot to mention the order of the patchsets, and to cc you
for the all series... Sorry about that.
This patch should come after the patch series that adds the support for
the A10 SoCs in the pinctrl driver.
Do you want me to resend this serie and cc you?
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Arnd Bergmann @ 2013-01-29 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129213308.7e845064@skate>
On Tuesday 29 January 2013, Thomas Petazzoni wrote:
> Does this still allows me to give the Linux PCI one global range of
> addresses for I/O space, and one global range of addresses for memory
> space, and the the Linux PCI core assign ranges, within those global
> ranges, to each host bridge?
>
> This is absolutely essential for me, as I then read those allocated
> ranges to configure the address decoding windows.
>
> Basically, I have currently two suggestions:
>
> * From Jason Gunthorpe, to not use any host bridge, and instead use
> only PCI-to-PCI bridges, one per PCIe interface.
>
> * From you, to not use any PCI-to-PCI bridge, and use only host
> bridges, one per PCIe interface.
>
> Would it be possible to get some consensus on this? In the review of
> RFCv1, I was already told to use one global host bridge, and then one
> PCI-to-PCI bridge per PCIe interface, and now we're talking about doing
> something different. I'd like to avoid having to try gazillions of
> different possible implementations :-)
I'm actually fine with either of the two suggestions you mentioned above,
whichever is easier to implement and/or more closely matches what the
hardware actually implements is better IMHO.
The part that I did not like about having emulated PCI-to-PCI bridges
is that it seems to just work around a (percieved or real) limitation
in the Linux kernel by adding a piece of infrastructure, rather than
lifting that limitation by making the kernel deal with what the
hardware provides. That reminded me of the original mach-vt8500
PCI implementation that faked a complete PCI host bridge and a
bunch of PCI devices on it, in order to use the via-velocity
ethernet controller, instead of adding a simple 'platform_driver'
struct to that driver.
Arnd
^ permalink raw reply
* [PATCHv4] ARM: sunxi: gpio: Add Allwinner SoCs GPIO drivers
From: Maxime Ripard @ 2013-01-29 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaNz6szEu6v=C97MfUzQzM3rG1hGHtHdO-aWXLCgHQEeQ@mail.gmail.com>
Hi Linus,
Le 29/01/2013 23:38, Linus Walleij a ?crit :
> On Mon, Jan 28, 2013 at 9:33 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>
>> The IP responsible for the muxing on the Allwinner SoCs are also
>> handling the GPIOs on the system. This patch adds the needed driver that
>> relies on the pinctrl driver for most of its operations.
>>
>> The number of pins available for GPIOs operations are already declared
>> in the pinctrl driver, we only need to probe a generic driver to handle
>> the banks available for each SoC.
>>
>> This driver has been tested on a A13-Olinuxino.
>>
>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Applied to my allwinner branch.
>
> I'm a bit confused with other patches floating around,
> I hope I'm supposed to apply this first...
Ah, yes, sorry, I forgot to mention the order of the patchset.
This one is indeed the first one, then comes "Add pinctrl/gpio support
for A10 SoCs", and finally "Add support for user LED on the A13-Olinuxino".
Since you already started to merge most of the patches for the sunxi
device tree, maybe the most reasonnable thing to do to avoid merge
conflicts would be for you to merge all of these patches.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/3] pinctrl: sunxi: Add of_xlate function
From: Linus Walleij @ 2013-01-29 22:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359313332-12305-2-git-send-email-maxime.ripard@free-electrons.com>
On Sun, Jan 27, 2013 at 8:02 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Since the pin controller of sunxi chips is represented as a single bank
> in the driver.
> Since this is neither convenient nor represented that way in the
> datasheets, define a custom of_xlate function with the layout <bank pin
> flag>
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
This does not apply and I only have 1/3 it seems?
Sorry, help me understand which order these patches go in...
Here is my allwinner branch:
http://git.kernel.org/?p=linux/kernel/git/linusw/linux-pinctrl.git;a=shortlog;h=refs/heads/allwinner-sunxi
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/5] ARM: sunxi: Increase the number of GPIOs available
From: Linus Walleij @ 2013-01-29 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359211016-24097-2-git-send-email-maxime.ripard@free-electrons.com>
On Sat, Jan 26, 2013 at 3:36 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The Allwinner A10 has 9 banks of 32 GPIOs available, so it doesn't fit
> in the usual 256 limit set by gpio.h. Increase this number to 288.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> arch/arm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f95ba14..1e86fa9 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1632,7 +1632,7 @@ config ARCH_NR_GPIO
> default 355 if ARCH_U8500
> default 264 if MACH_H4700
> default 512 if SOC_OMAP5
> - default 288 if ARCH_VT8500
> + default 288 if ARCH_VT8500 || ARCH_SUNXI
Can I have an ACK from the ARM SoC maintainers on this?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv4] ARM: sunxi: gpio: Add Allwinner SoCs GPIO drivers
From: Linus Walleij @ 2013-01-29 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359405192-1192-1-git-send-email-maxime.ripard@free-electrons.com>
On Mon, Jan 28, 2013 at 9:33 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The IP responsible for the muxing on the Allwinner SoCs are also
> handling the GPIOs on the system. This patch adds the needed driver that
> relies on the pinctrl driver for most of its operations.
>
> The number of pins available for GPIOs operations are already declared
> in the pinctrl driver, we only need to probe a generic driver to handle
> the banks available for each SoC.
>
> This driver has been tested on a A13-Olinuxino.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied to my allwinner branch.
I'm a bit confused with other patches floating around,
I hope I'm supposed to apply this first...
Thanks,
Linus Walleij
^ permalink raw reply
* [GIT PULL] ARM: OMAP2+: powerdomain & clockdomain cleanup and fixes for 3.9
From: Paul Walmsley @ 2013-01-29 22:36 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony,
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-b-for-3.9
for you to fetch changes up to 562e54d13b6e0b17f72c9e629e1fd0b71e2a8a36:
ARM: OMAP2+: powerdomain: fix whitespace, improve flag comments (2013-01-29 14:59:58 -0700)
- ----------------------------------------------------------------
Several OMAP2+ power management fixes, optimizations, and cleanup.
This series is a prerequisite for the functional powerdomain
conversion series.
Basic test logs for this branch are here:
http://www.pwsan.com/omap/testlogs/pm_cleanup_fixes_3.9/20130129150017/
- ----------------------------------------------------------------
vmlinux object size
(delta in bytes from test_v3.8-rc5 (949db153b6466c6f7cad5a427ecea94985927311)):
text data bss total kernel
+452 -400 0 +52 am33xx_only
+372 -464 0 -92 n800_multi_omap2xxx
+404 -144 0 +260 n800_only_a
0 0 0 0 omap1_defconfig
0 0 0 0 omap1_defconfig_1510innovator_only
0 0 0 0 omap1_defconfig_5912osk_only
+64 -1784 0 -1720 omap2plus_defconfig
+232 -208 0 +24 omap2plus_defconfig_2430sdp_only
+12 -1792 0 -1780 omap2plus_defconfig_cpupm
+48 -1576 0 -1528 omap2plus_defconfig_no_pm
+60 -1016 0 -956 omap2plus_defconfig_omap2_4_only
+300 -1336 0 -1036 omap2plus_defconfig_omap3_4_only
+636 -560 -144 -68 rmk_omap3430_ldp_allnoconfig
+420 -616 0 -196 rmk_omap3430_ldp_oldconfig
+636 -560 -144 -68 rmk_omap4430_sdp_allnoconfig
+344 -328 0 +16 rmk_omap4430_sdp_oldconfig
Boot-time memory difference
(delta in bytes from test_v3.8-rc5 (949db153b6466c6f7cad5a427ecea94985927311))
avail rsrvd high freed board kconfig
4k -4k . . 2430sdp omap2plus_defconfig
4k -4k . . 3530es3beagle omap2plus_defconfig
4k -4k . . 3730beaglexm omap2plus_defconfig
4k -4k . . 37xxevm omap2plus_defconfig
4k -4k . . 4430es2panda omap2plus_defconfig
4k -4k . . 4460pandaes omap2plus_defconfig
4k -4k . . cmt3517 omap2plus_defconfig
Jean Pihet (1):
ARM: OMAP2+: powerdomain: fix powerdomain trace integration
Paul Walmsley (13):
ARM: OMAP2xxx: powerdomain: core powerdomain missing logic retention states
ARM: OMAP3xxx: CPUIdle: simplify the PER next-state code
ARM: OMAP3xxx: CPUIdle: optimize __omap3_enter_idle()
ARM: OMAP4: MPUSS PM: remove unnecessary shim functions for powerdomain control
ARM: OMAP2+: clockdomain: add pwrdm_state_switch() call to clkdm_sleep()
ARM: OMAP2xxx: PM: clean up some crufty powerstate programming code
ARM: OMAP2: PM/powerdomain: drop unnecessary pwrdm_wait_transition()
ARM: OMAP2+: PM/powerdomain: move omap_set_pwrdm_state() to powerdomain code
ARM: OMAP2+: powerdomain/clockdomain: add a per-powerdomain spinlock
ARM: OMAP2xxx: CM: remove autodep handling
ARM: OMAP2+: clockdomain: work on wkdep/sleepdep functions
ARM: OMAP2+: clockdomain: convert existing atomic usecounts into spinlock-protected shorts/ints
ARM: OMAP2+: powerdomain: fix whitespace, improve flag comments
arch/arm/mach-omap2/clockdomain.c | 569 ++++++++++++++--------
arch/arm/mach-omap2/clockdomain.h | 17 +-
arch/arm/mach-omap2/cm2xxx.c | 33 +-
arch/arm/mach-omap2/cm3xxx.c | 14 +-
arch/arm/mach-omap2/cminst44xx.c | 2 +-
arch/arm/mach-omap2/cpuidle34xx.c | 79 +--
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 44 +-
arch/arm/mach-omap2/pm-debug.c | 6 +-
arch/arm/mach-omap2/pm.c | 65 +--
arch/arm/mach-omap2/pm.h | 1 -
arch/arm/mach-omap2/pm24xx.c | 30 +-
arch/arm/mach-omap2/powerdomain.c | 232 +++++++--
arch/arm/mach-omap2/powerdomain.h | 52 +-
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c | 4 +-
arch/arm/mach-omap2/powerdomains2xxx_data.c | 9 +-
arch/arm/mach-omap2/powerdomains3xxx_data.c | 44 +-
arch/arm/mach-omap2/prm2xxx_3xxx.c | 3 +-
17 files changed, 710 insertions(+), 494 deletions(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJRCE2vAAoJEMePsQ0LvSpLKI0P/3fFmnbbsOvjLL5J2i0TK8gL
rtfy5pOlx2k9GVAx98j5JsJMSHQfdUQ7xZ4yY1AtLrr76pY6df9cSL9hDB/Sfcf8
sqDITtL+POzZIRxtmwnffmvkNJ1hqhbOt0vg4Qlu2mSjTpdfZweDcqKD9u393Wp9
pkFLfvb/+boCdHGj/0v7Tzidi1TLSPV2ezdHY6gPwB+uM2pMO1Zw746cCxHpz16v
4tcGCZ9NKj4iMQJzJG/rdI1oIPrQ735jXZgZhF+BsXEZ7GyKymlWhLZ9iLF7gMPa
p4s2TKE0GoObYeWB1n2lRoWBNOxVfPJGt1ZOJfSEM2kw/S2X0HnEwHJCss1LKhPb
MzJAXhflhVMqb+wZglUF29xIQD7yv71cgdWWdXe3pdAhs7ivqiwhAMpWvl8HHVZO
Y+ASmuQBvzHPtu1GmRv+gXlBRoLUsyuZfTlhyCX7hHGx7beZ3L0TngAlVbAL6F9J
Y0l5vbcjPep8PIa20Wlx3mHw3yTPVBo6NLo5av5ZOW1uo1g3ve94tpb8KAqNyOaN
eBnKhHgLgZHRFV5V0FInWhdPVHqGDFFVT5QtL/1/lMBxe7oOlTvFM3qiFyGRZsI7
R/ur+i0XNt+LFPRNdSY1kCF5BubJZlDCtFeJg1/99IAMa/64ofVEOW+C5+TGf8jV
Bs4eluyYc1agVkfuZfye
=XH66
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v2 4/4] irqchip: gic: Perform the gic_secondary_init() call via CPU notifier
From: Nicolas Pitre @ 2013-01-29 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359476319-23720-5-git-send-email-catalin.marinas@arm.com>
On Tue, 29 Jan 2013, Catalin Marinas wrote:
> All the calls to gic_secondary_init() pass 0 as the first argument.
> Since this function is called on each CPU when starting, it can be done
> in a platform-independent way via a CPU notifier registered by the GIC
> code.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Acked-by: Stephen Warren <swarren@nvidia.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Acked-by: Rob Herring <rob.herring@calxeda.com>
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
> Tested-by: Simon Horman <horms+renesas@verge.net.au>
> Acked-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: David Brown <davidb@codeaurora.org>
> Cc: Bryan Huntsman <bryanh@codeaurora.org>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Dinh Nguyen <dinguyen@altera.com>
> Cc: Shiraz Hashim <shiraz.hashim@st.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
What is your plan in terms of merge path and schedule? My mcpm series
would depend on this.
> ---
> arch/arm/mach-exynos/platsmp.c | 8 --------
> arch/arm/mach-highbank/platsmp.c | 7 -------
> arch/arm/mach-imx/platsmp.c | 12 ------------
> arch/arm/mach-msm/platsmp.c | 8 --------
> arch/arm/mach-omap2/omap-smp.c | 7 -------
> arch/arm/mach-shmobile/smp-emev2.c | 7 -------
> arch/arm/mach-shmobile/smp-r8a7779.c | 7 -------
> arch/arm/mach-shmobile/smp-sh73a0.c | 7 -------
> arch/arm/mach-socfpga/platsmp.c | 12 ------------
> arch/arm/mach-spear13xx/platsmp.c | 8 --------
> arch/arm/mach-tegra/platsmp.c | 8 --------
> arch/arm/mach-ux500/platsmp.c | 8 --------
> arch/arm/plat-versatile/platsmp.c | 8 --------
> drivers/irqchip/irq-gic.c | 28 +++++++++++++++++++++-------
> include/linux/irqchip/arm-gic.h | 1 -
> 15 files changed, 21 insertions(+), 115 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
> index a083e05..a0e8ff7 100644
> --- a/arch/arm/mach-exynos/platsmp.c
> +++ b/arch/arm/mach-exynos/platsmp.c
> @@ -20,7 +20,6 @@
> #include <linux/jiffies.h>
> #include <linux/smp.h>
> #include <linux/io.h>
> -#include <linux/irqchip/arm-gic.h>
>
> #include <asm/cacheflush.h>
> #include <asm/smp_plat.h>
> @@ -77,13 +76,6 @@ static DEFINE_SPINLOCK(boot_lock);
> static void __cpuinit exynos_secondary_init(unsigned int cpu)
> {
> /*
> - * if any interrupts are already enabled for the primary
> - * core (e.g. timer irq), then they will not have been enabled
> - * for us: do so
> - */
> - gic_secondary_init(0);
> -
> - /*
> * let the primary processor know we're out of the
> * pen, then head off into the C entry point
> */
> diff --git a/arch/arm/mach-highbank/platsmp.c b/arch/arm/mach-highbank/platsmp.c
> index 8797a70..a984573 100644
> --- a/arch/arm/mach-highbank/platsmp.c
> +++ b/arch/arm/mach-highbank/platsmp.c
> @@ -17,7 +17,6 @@
> #include <linux/init.h>
> #include <linux/smp.h>
> #include <linux/io.h>
> -#include <linux/irqchip/arm-gic.h>
>
> #include <asm/smp_scu.h>
>
> @@ -25,11 +24,6 @@
>
> extern void secondary_startup(void);
>
> -static void __cpuinit highbank_secondary_init(unsigned int cpu)
> -{
> - gic_secondary_init(0);
> -}
> -
> static int __cpuinit highbank_boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> highbank_set_cpu_jump(cpu, secondary_startup);
> @@ -67,7 +61,6 @@ static void __init highbank_smp_prepare_cpus(unsigned int max_cpus)
> struct smp_operations highbank_smp_ops __initdata = {
> .smp_init_cpus = highbank_smp_init_cpus,
> .smp_prepare_cpus = highbank_smp_prepare_cpus,
> - .smp_secondary_init = highbank_secondary_init,
> .smp_boot_secondary = highbank_boot_secondary,
> #ifdef CONFIG_HOTPLUG_CPU
> .cpu_die = highbank_cpu_die,
> diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
> index b2872ec..7f63dda 100644
> --- a/arch/arm/mach-imx/platsmp.c
> +++ b/arch/arm/mach-imx/platsmp.c
> @@ -12,7 +12,6 @@
>
> #include <linux/init.h>
> #include <linux/smp.h>
> -#include <linux/irqchip/arm-gic.h>
> #include <asm/page.h>
> #include <asm/smp_scu.h>
> #include <asm/mach/map.h>
> @@ -42,16 +41,6 @@ void __init imx_scu_map_io(void)
> scu_base = IMX_IO_ADDRESS(base);
> }
>
> -static void __cpuinit imx_secondary_init(unsigned int cpu)
> -{
> - /*
> - * if any interrupts are already enabled for the primary
> - * core (e.g. timer irq), then they will not have been enabled
> - * for us: do so
> - */
> - gic_secondary_init(0);
> -}
> -
> static int __cpuinit imx_boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> imx_set_cpu_jump(cpu, v7_secondary_startup);
> @@ -86,7 +75,6 @@ static void __init imx_smp_prepare_cpus(unsigned int max_cpus)
> struct smp_operations imx_smp_ops __initdata = {
> .smp_init_cpus = imx_smp_init_cpus,
> .smp_prepare_cpus = imx_smp_prepare_cpus,
> - .smp_secondary_init = imx_secondary_init,
> .smp_boot_secondary = imx_boot_secondary,
> #ifdef CONFIG_HOTPLUG_CPU
> .cpu_die = imx_cpu_die,
> diff --git a/arch/arm/mach-msm/platsmp.c b/arch/arm/mach-msm/platsmp.c
> index 42932865..00cdb0a 100644
> --- a/arch/arm/mach-msm/platsmp.c
> +++ b/arch/arm/mach-msm/platsmp.c
> @@ -15,7 +15,6 @@
> #include <linux/jiffies.h>
> #include <linux/smp.h>
> #include <linux/io.h>
> -#include <linux/irqchip/arm-gic.h>
>
> #include <asm/cacheflush.h>
> #include <asm/cputype.h>
> @@ -42,13 +41,6 @@ static inline int get_core_count(void)
> static void __cpuinit msm_secondary_init(unsigned int cpu)
> {
> /*
> - * if any interrupts are already enabled for the primary
> - * core (e.g. timer irq), then they will not have been enabled
> - * for us: do so
> - */
> - gic_secondary_init(0);
> -
> - /*
> * let the primary processor know we're out of the
> * pen, then head off into the C entry point
> */
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index 3616779..c6ce880 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -67,13 +67,6 @@ static void __cpuinit omap4_secondary_init(unsigned int cpu)
> 4, 0, 0, 0, 0, 0);
>
> /*
> - * If any interrupts are already enabled for the primary
> - * core (e.g. timer irq), then they will not have been enabled
> - * for us: do so
> - */
> - gic_secondary_init(0);
> -
> - /*
> * Synchronise with the boot thread.
> */
> spin_lock(&boot_lock);
> diff --git a/arch/arm/mach-shmobile/smp-emev2.c b/arch/arm/mach-shmobile/smp-emev2.c
> index 953eb1f..384e27d 100644
> --- a/arch/arm/mach-shmobile/smp-emev2.c
> +++ b/arch/arm/mach-shmobile/smp-emev2.c
> @@ -23,7 +23,6 @@
> #include <linux/spinlock.h>
> #include <linux/io.h>
> #include <linux/delay.h>
> -#include <linux/irqchip/arm-gic.h>
> #include <mach/common.h>
> #include <mach/emev2.h>
> #include <asm/smp_plat.h>
> @@ -85,11 +84,6 @@ static int __maybe_unused emev2_cpu_kill(unsigned int cpu)
> }
>
>
> -static void __cpuinit emev2_secondary_init(unsigned int cpu)
> -{
> - gic_secondary_init(0);
> -}
> -
> static int __cpuinit emev2_boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> cpu = cpu_logical_map(cpu);
> @@ -124,7 +118,6 @@ static void __init emev2_smp_init_cpus(void)
> struct smp_operations emev2_smp_ops __initdata = {
> .smp_init_cpus = emev2_smp_init_cpus,
> .smp_prepare_cpus = emev2_smp_prepare_cpus,
> - .smp_secondary_init = emev2_secondary_init,
> .smp_boot_secondary = emev2_boot_secondary,
> #ifdef CONFIG_HOTPLUG_CPU
> .cpu_kill = emev2_cpu_kill,
> diff --git a/arch/arm/mach-shmobile/smp-r8a7779.c b/arch/arm/mach-shmobile/smp-r8a7779.c
> index 3a4acf2..9949065 100644
> --- a/arch/arm/mach-shmobile/smp-r8a7779.c
> +++ b/arch/arm/mach-shmobile/smp-r8a7779.c
> @@ -23,7 +23,6 @@
> #include <linux/spinlock.h>
> #include <linux/io.h>
> #include <linux/delay.h>
> -#include <linux/irqchip/arm-gic.h>
> #include <mach/common.h>
> #include <mach/r8a7779.h>
> #include <asm/smp_plat.h>
> @@ -132,11 +131,6 @@ static int __maybe_unused r8a7779_cpu_kill(unsigned int cpu)
> }
>
>
> -static void __cpuinit r8a7779_secondary_init(unsigned int cpu)
> -{
> - gic_secondary_init(0);
> -}
> -
> static int __cpuinit r8a7779_boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> struct r8a7779_pm_ch *ch = NULL;
> @@ -186,7 +180,6 @@ static void __init r8a7779_smp_init_cpus(void)
> struct smp_operations r8a7779_smp_ops __initdata = {
> .smp_init_cpus = r8a7779_smp_init_cpus,
> .smp_prepare_cpus = r8a7779_smp_prepare_cpus,
> - .smp_secondary_init = r8a7779_secondary_init,
> .smp_boot_secondary = r8a7779_boot_secondary,
> #ifdef CONFIG_HOTPLUG_CPU
> .cpu_kill = r8a7779_cpu_kill,
> diff --git a/arch/arm/mach-shmobile/smp-sh73a0.c b/arch/arm/mach-shmobile/smp-sh73a0.c
> index 9812ea3..f3b4912 100644
> --- a/arch/arm/mach-shmobile/smp-sh73a0.c
> +++ b/arch/arm/mach-shmobile/smp-sh73a0.c
> @@ -23,7 +23,6 @@
> #include <linux/spinlock.h>
> #include <linux/io.h>
> #include <linux/delay.h>
> -#include <linux/irqchip/arm-gic.h>
> #include <mach/common.h>
> #include <asm/cacheflush.h>
> #include <asm/smp_plat.h>
> @@ -59,11 +58,6 @@ static unsigned int __init sh73a0_get_core_count(void)
> return scu_get_core_count(scu_base);
> }
>
> -static void __cpuinit sh73a0_secondary_init(unsigned int cpu)
> -{
> - gic_secondary_init(0);
> -}
> -
> static int __cpuinit sh73a0_boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> cpu = cpu_logical_map(cpu);
> @@ -138,7 +132,6 @@ static void sh73a0_cpu_die(unsigned int cpu)
> struct smp_operations sh73a0_smp_ops __initdata = {
> .smp_init_cpus = sh73a0_smp_init_cpus,
> .smp_prepare_cpus = sh73a0_smp_prepare_cpus,
> - .smp_secondary_init = sh73a0_secondary_init,
> .smp_boot_secondary = sh73a0_boot_secondary,
> #ifdef CONFIG_HOTPLUG_CPU
> .cpu_kill = sh73a0_cpu_kill,
> diff --git a/arch/arm/mach-socfpga/platsmp.c b/arch/arm/mach-socfpga/platsmp.c
> index 4e9e69d..4b468ef 100644
> --- a/arch/arm/mach-socfpga/platsmp.c
> +++ b/arch/arm/mach-socfpga/platsmp.c
> @@ -22,7 +22,6 @@
> #include <linux/io.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> -#include <linux/irqchip/arm-gic.h>
>
> #include <asm/cacheflush.h>
> #include <asm/smp_scu.h>
> @@ -33,16 +32,6 @@
> extern void __iomem *sys_manager_base_addr;
> extern void __iomem *rst_manager_base_addr;
>
> -static void __cpuinit socfpga_secondary_init(unsigned int cpu)
> -{
> - /*
> - * if any interrupts are already enabled for the primary
> - * core (e.g. timer irq), then they will not have been enabled
> - * for us: do so
> - */
> - gic_secondary_init(0);
> -}
> -
> static int __cpuinit socfpga_boot_secondary(unsigned int cpu, struct task_struct *idle)
> {
> int trampoline_size = &secondary_trampoline_end - &secondary_trampoline;
> @@ -106,7 +95,6 @@ static void socfpga_cpu_die(unsigned int cpu)
> struct smp_operations socfpga_smp_ops __initdata = {
> .smp_init_cpus = socfpga_smp_init_cpus,
> .smp_prepare_cpus = socfpga_smp_prepare_cpus,
> - .smp_secondary_init = socfpga_secondary_init,
> .smp_boot_secondary = socfpga_boot_secondary,
> #ifdef CONFIG_HOTPLUG_CPU
> .cpu_die = socfpga_cpu_die,
> diff --git a/arch/arm/mach-spear13xx/platsmp.c b/arch/arm/mach-spear13xx/platsmp.c
> index af4ade6..551c69c 100644
> --- a/arch/arm/mach-spear13xx/platsmp.c
> +++ b/arch/arm/mach-spear13xx/platsmp.c
> @@ -15,7 +15,6 @@
> #include <linux/jiffies.h>
> #include <linux/io.h>
> #include <linux/smp.h>
> -#include <linux/irqchip/arm-gic.h>
> #include <asm/cacheflush.h>
> #include <asm/smp_scu.h>
> #include <mach/spear.h>
> @@ -28,13 +27,6 @@ static void __iomem *scu_base = IOMEM(VA_SCU_BASE);
> static void __cpuinit spear13xx_secondary_init(unsigned int cpu)
> {
> /*
> - * if any interrupts are already enabled for the primary
> - * core (e.g. timer irq), then they will not have been enabled
> - * for us: do so
> - */
> - gic_secondary_init(0);
> -
> - /*
> * let the primary processor know we're out of the
> * pen, then head off into the C entry point
> */
> diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
> index c72e249..dea94d2 100644
> --- a/arch/arm/mach-tegra/platsmp.c
> +++ b/arch/arm/mach-tegra/platsmp.c
> @@ -18,7 +18,6 @@
> #include <linux/jiffies.h>
> #include <linux/smp.h>
> #include <linux/io.h>
> -#include <linux/irqchip/arm-gic.h>
> #include <linux/clk/tegra.h>
>
> #include <asm/cacheflush.h>
> @@ -45,13 +44,6 @@ static void __iomem *scu_base = IO_ADDRESS(TEGRA_ARM_PERIF_BASE);
>
> static void __cpuinit tegra_secondary_init(unsigned int cpu)
> {
> - /*
> - * if any interrupts are already enabled for the primary
> - * core (e.g. timer irq), then they will not have been enabled
> - * for us: do so
> - */
> - gic_secondary_init(0);
> -
> cpumask_set_cpu(cpu, &tegra_cpu_init_mask);
> }
>
> diff --git a/arch/arm/mach-ux500/platsmp.c b/arch/arm/mach-ux500/platsmp.c
> index b8adac9..b4d0735 100644
> --- a/arch/arm/mach-ux500/platsmp.c
> +++ b/arch/arm/mach-ux500/platsmp.c
> @@ -16,7 +16,6 @@
> #include <linux/device.h>
> #include <linux/smp.h>
> #include <linux/io.h>
> -#include <linux/irqchip/arm-gic.h>
>
> #include <asm/cacheflush.h>
> #include <asm/smp_plat.h>
> @@ -55,13 +54,6 @@ static DEFINE_SPINLOCK(boot_lock);
> static void __cpuinit ux500_secondary_init(unsigned int cpu)
> {
> /*
> - * if any interrupts are already enabled for the primary
> - * core (e.g. timer irq), then they will not have been enabled
> - * for us: do so
> - */
> - gic_secondary_init(0);
> -
> - /*
> * let the primary processor know we're out of the
> * pen, then head off into the C entry point
> */
> diff --git a/arch/arm/plat-versatile/platsmp.c b/arch/arm/plat-versatile/platsmp.c
> index f2ac155..1e1b2d7 100644
> --- a/arch/arm/plat-versatile/platsmp.c
> +++ b/arch/arm/plat-versatile/platsmp.c
> @@ -14,7 +14,6 @@
> #include <linux/device.h>
> #include <linux/jiffies.h>
> #include <linux/smp.h>
> -#include <linux/irqchip/arm-gic.h>
>
> #include <asm/cacheflush.h>
> #include <asm/smp_plat.h>
> @@ -37,13 +36,6 @@ static DEFINE_SPINLOCK(boot_lock);
> void __cpuinit versatile_secondary_init(unsigned int cpu)
> {
> /*
> - * if any interrupts are already enabled for the primary
> - * core (e.g. timer irq), then they will not have been enabled
> - * for us: do so
> - */
> - gic_secondary_init(0);
> -
> - /*
> * let the primary processor know we're out of the
> * pen, then head off into the C entry point
> */
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index ef1429a..f103cb8 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -28,6 +28,7 @@
> #include <linux/module.h>
> #include <linux/list.h>
> #include <linux/smp.h>
> +#include <linux/cpu.h>
> #include <linux/cpu_pm.h>
> #include <linux/cpumask.h>
> #include <linux/io.h>
> @@ -678,6 +679,25 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
> return 0;
> }
>
> +#ifdef CONFIG_SMP
> +static int __cpuinit gic_secondary_init(struct notifier_block *nfb,
> + unsigned long action, void *hcpu)
> +{
> + if (action == CPU_STARTING)
> + gic_cpu_init(&gic_data[0]);
> + return NOTIFY_OK;
> +}
> +
> +/*
> + * Notifier for enabling the GIC CPU interface. Set an arbitrarily high
> + * priority because the GIC needs to be up before the ARM generic timers.
> + */
> +static struct notifier_block __cpuinitdata gic_cpu_notifier = {
> + .notifier_call = gic_secondary_init,
> + .priority = 100,
> +};
> +#endif
> +
> const struct irq_domain_ops gic_irq_domain_ops = {
> .map = gic_irq_domain_map,
> .xlate = gic_irq_domain_xlate,
> @@ -768,6 +788,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
>
> #ifdef CONFIG_SMP
> set_smp_cross_call(gic_raise_softirq);
> + register_cpu_notifier(&gic_cpu_notifier);
> #endif
>
> set_handle_irq(gic_handle_irq);
> @@ -778,13 +799,6 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
> gic_pm_init(gic);
> }
>
> -void __cpuinit gic_secondary_init(unsigned int gic_nr)
> -{
> - BUG_ON(gic_nr >= MAX_GIC_NR);
> -
> - gic_cpu_init(&gic_data[gic_nr]);
> -}
> -
> #ifdef CONFIG_OF
> static int gic_cnt __initdata = 0;
>
> diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
> index a67ca55..59e59b3 100644
> --- a/include/linux/irqchip/arm-gic.h
> +++ b/include/linux/irqchip/arm-gic.h
> @@ -36,7 +36,6 @@ extern struct irq_chip gic_arch_extn;
>
> void gic_init_bases(unsigned int, int, void __iomem *, void __iomem *,
> u32 offset, struct device_node *);
> -void gic_secondary_init(unsigned int);
> void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
>
> static inline void gic_init(unsigned int nr, int start,
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [GIT PULL] ARM: OMAP2+: first set of clock and device integration cleanups for 3.9
From: Paul Walmsley @ 2013-01-29 22:35 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony,
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-a-for-3.9
for you to fetch changes up to aff2f7d90fc6553aa309db2a635d8e5d70d84916:
ARM: OMAP2420: hwmod data/PM: use hwmod to block WFI when I2C active (2013-01-26 01:42:33 -0700)
- ----------------------------------------------------------------
Remove some dead OMAP clock and device integration code and data.
Also, clean up the way that the OMAP device integration code blocks
WFI/WFE to use a consistent mechanism, controlled by a data flag.
Basic test logs for this branch are here:
http://www.pwsan.com/omap/testlogs/cleanup_a_3.9/20130126014242/
- ----------------------------------------------------------------
vmlinux object size
(delta in bytes from test_v3.8-rc5 (949db153b6466c6f7cad5a427ecea94985927311)):
text data bss total kernel
-1502 +8 0 -1494 am33xx_only
-1574 -664 0 -2238 n800_multi_omap2xxx
-1574 -344 0 -1918 n800_only_a
0 0 0 0 omap1_defconfig
0 0 0 0 omap1_defconfig_1510innovator_only
0 0 0 0 omap1_defconfig_5912osk_only
-5702 -6200 0 -11902 omap2plus_defconfig
-5586 -320 0 -5906 omap2plus_defconfig_2430sdp_only
-5706 -6208 0 -11914 omap2plus_defconfig_cpupm
-1546 -6200 0 -7746 omap2plus_defconfig_no_pm
-5670 -6200 0 -11870 omap2plus_defconfig_omap2_4_only
-13830 -5624 0 -19454 omap2plus_defconfig_omap3_4_only
-2164 -6216 +600 -7780 rmk_omap3430_ldp_allnoconfig
-1538 -64 0 -1602 rmk_omap3430_ldp_oldconfig
-2164 -6216 +600 -7780 rmk_omap4430_sdp_allnoconfig
-1526 -5640 -64 -7230 rmk_omap4430_sdp_oldconfig
Boot-time memory difference
(delta in bytes from test_v3.8-rc5 (949db153b6466c6f7cad5a427ecea94985927311))
avail rsrvd high freed board kconfig
16k -16k . . 2430sdp omap2plus_defconfig
16k -16k . . 3530es3beagle omap2plus_defconfig
16k -16k . . 3730beaglexm omap2plus_defconfig
16k -16k . . 37xxevm omap2plus_defconfig
16k -16k . . 4430es2panda omap2plus_defconfig
16k -16k . . 4460pandaes omap2plus_defconfig
16k -16k . . cmt3517 omap2plus_defconfig
Paul Walmsley (6):
ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device code
ARM: OMAP4: clock/hwmod data: start to remove some IP block control "clocks"
ARM: OMAP4: clock/hwmod data: remove MODULEMODE entries in mux + gate combos
ARM: OMAP2xxx: clock data: clean up unused null clocks
ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active
ARM: OMAP2420: hwmod data/PM: use hwmod to block WFI when I2C active
arch/arm/mach-omap2/am35xx-emac.c | 2 +-
arch/arm/mach-omap2/cclock2420_data.c | 16 +-
arch/arm/mach-omap2/cclock2430_data.c | 16 +-
arch/arm/mach-omap2/cclock44xx_data.c | 578 ++++++----------------------
arch/arm/mach-omap2/devices.c | 25 +-
arch/arm/mach-omap2/display.c | 2 +-
arch/arm/mach-omap2/dma.c | 2 +-
arch/arm/mach-omap2/drm.c | 3 +-
arch/arm/mach-omap2/gpio.c | 3 +-
arch/arm/mach-omap2/gpmc.c | 2 +-
arch/arm/mach-omap2/hdq1w.c | 2 +-
arch/arm/mach-omap2/hsmmc.c | 2 +-
arch/arm/mach-omap2/hwspinlock.c | 3 +-
arch/arm/mach-omap2/i2c.c | 3 +-
arch/arm/mach-omap2/mcbsp.c | 2 +-
arch/arm/mach-omap2/msdi.c | 2 +-
arch/arm/mach-omap2/omap-iommu.c | 3 +-
arch/arm/mach-omap2/omap_device.c | 537 +++-----------------------
arch/arm/mach-omap2/omap_device.h | 79 +---
arch/arm/mach-omap2/omap_hwmod.c | 8 +
arch/arm/mach-omap2/omap_hwmod.h | 9 +
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 7 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99 +++--
arch/arm/mach-omap2/pm.c | 4 +-
arch/arm/mach-omap2/pm24xx.c | 13 -
arch/arm/mach-omap2/pmu.c | 3 +-
arch/arm/mach-omap2/serial.c | 3 +-
arch/arm/mach-omap2/sr_device.c | 3 +-
arch/arm/mach-omap2/timer.c | 3 +-
arch/arm/mach-omap2/usb-host.c | 16 +-
arch/arm/mach-omap2/usb-musb.c | 2 +-
arch/arm/mach-omap2/wd_timer.c | 3 +-
32 files changed, 292 insertions(+), 1163 deletions(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJRCE54AAoJEMePsQ0LvSpLMQkP/35hjU9fAf/6SZk8NUNffUaP
nRGVW34v9wbsT8tkcEQzIRiGUGeQXqOk0wczHJEf0daxmkZgzIWr/hjU9z3kUnDf
QIan3CU0YvfcQOXR9PYR7ZB2Zz2HFxySkUy99ioriWjSUE3ff0CdLNq/fB7TEeLc
2D/ourAzRfqJdCs49tGK9qbLUVEtmLDbS5+dN1KmldunZ6bvhhNtuYs72RQ+kWN0
9WkCmJYVNYS8dTg6uZi2rBSStfYJkUJ1IDjtnBe6815KiZ3q2G21KTJUrywqd324
iASZ2cnUVzFsNdWNGBHMQvWW/SmlbP7F4pimlfyd8rDHUv0K3KZEW110AB8nMpAz
XzvuseiA+OWteTa2GLrsQJg8/wx5yAYZBkgyia2Vp1o79nfgOZ54X5LsZcyuOS/w
jALgJJi2zAsqjNWpmt7BCGlCOfRQOu1I67rN6K6JdO1j66Nnc8MfpV6npds2hsH5
xArNIlj95q2frQwlC5tVvXGTpY0lJZmAz0R9eAMZ3PFF08VTSdmUCdgTK5SNUIWO
2ITee1s9BxbJxJir7YKI8c/sW5FS/oeERn6p9nR0LUWX+9+raWdx/wcZfoRRSshe
d2odyViDuHiUbE2zKK513Sikb1XNrE5A5kB+40M011BEv3DjSWXv6opbfNNsB1eF
fCuBsikVIJ+PWykLJt1F
=bbcC
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v2 08/27] pci: implement an emulated PCI-to-PCI bridge
From: Bjorn Helgaas @ 2013-01-29 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359399397-29729-9-git-send-email-thomas.petazzoni@free-electrons.com>
On Mon, Jan 28, 2013 at 11:56 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> drivers/pci/Kconfig | 3 +
> drivers/pci/Makefile | 1 +
> drivers/pci/sw-pci-pci-bridge.c | 185 +++++++++++++++++++++++++++++++++++++++
> include/linux/pci.h | 43 +++++++++
> 4 files changed, 232 insertions(+)
> create mode 100644 drivers/pci/sw-pci-pci-bridge.c
If you need this, it can be done in architecture code, can't it? It's
true that there's nothing architecture-specific in this patch (other
than the fact that ARM is the only arch that needs it), but I'm not
sure there's anything useful for sharing here.
In fact, it seems like what you're after is not so much an *emulated*
bridge that has no corresponding hardware, as it is a wrapper that
presents a standard PCIe interface to hardware that exists but doesn't
conform to the PCIe spec. If you really do need to ultimately connect
this pci_sw_pci_bridge to a piece of hardware, that will certainly be
arch-specific.
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index f7548e2..6ed3db1 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -122,3 +122,6 @@ config PCI_LABEL
>
> config PCI_SW_HOST_BRIDGE
> bool
> +
> +config PCI_SW_PCI_PCI_BRIDGE
> + bool
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index 44ce914..5b48961 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_PCI_IOAPIC) += ioapic.o
>
> # Emulated PCI elements
> obj-$(CONFIG_PCI_SW_HOST_BRIDGE) += sw-host-bridge.o
> +obj-$(CONFIG_PCI_SW_PCI_PCI_BRIDGE) += sw-pci-pci-bridge.o
>
> # Build the PCI Hotplug drivers if we were asked to
> obj-$(CONFIG_HOTPLUG_PCI) += hotplug/
> diff --git a/drivers/pci/sw-pci-pci-bridge.c b/drivers/pci/sw-pci-pci-bridge.c
> new file mode 100644
> index 0000000..25679cc
> --- /dev/null
> +++ b/drivers/pci/sw-pci-pci-bridge.c
> @@ -0,0 +1,185 @@
> +/*
> + * Implementation of a simple emulated PCI-to-PCI bridge.
> + *
> + * Thierry Reding <thierry.reding@avionic-design.de>
> + * Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/pci.h>
> +#include <linux/module.h>
> +
> +int pci_sw_pci_bridge_init(struct pci_sw_pci_bridge *bridge)
> +{
> + if (!bridge)
> + return -EINVAL;
> +
> + memset(bridge, 0, sizeof(struct pci_sw_pci_bridge));
> +
> + bridge->status = PCI_STATUS_CAP_LIST;
> + bridge->class = PCI_CLASS_BRIDGE_PCI;
> + bridge->header_type = PCI_HEADER_TYPE_BRIDGE;
> + bridge->cache_line_size = 0x10;
> +
> + /* We support 32 bits I/O addressing */
> + bridge->iobase = PCI_IO_RANGE_TYPE_32;
> + bridge->iolimit = PCI_IO_RANGE_TYPE_32;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_sw_pci_bridge_init);
> +
> +int pci_sw_pci_bridge_read(struct pci_sw_pci_bridge *bridge,
> + unsigned int where, int size, u32 *value)
> +{
> + switch (where & ~3) {
> + case PCI_VENDOR_ID:
> + *value = bridge->device << 16 | bridge->vendor;
> + break;
> +
> + case PCI_COMMAND:
> + *value = bridge->status << 16 | bridge->command;
> + break;
> +
> + case PCI_CLASS_REVISION:
> + *value = bridge->class << 16 | bridge->interface << 8 |
> + bridge->revision;
> + break;
> +
> + case PCI_CACHE_LINE_SIZE:
> + *value = bridge->bist << 24 | bridge->header_type << 16 |
> + bridge->latency_timer << 8 | bridge->cache_line_size;
> + break;
> +
> + case PCI_BASE_ADDRESS_0 ... PCI_BASE_ADDRESS_1:
> + *value = bridge->bar[((where & ~3) - PCI_BASE_ADDRESS_0) / 4];
> + break;
> +
> + case PCI_PRIMARY_BUS:
> + *value = (bridge->secondary_latency_timer << 24 |
> + bridge->subordinate_bus << 16 |
> + bridge->secondary_bus << 8 |
> + bridge->primary_bus);
> + break;
> +
> + case PCI_IO_BASE:
> + *value = (bridge->secondary_status << 16 |
> + bridge->iolimit << 8 |
> + bridge->iobase);
> + break;
> +
> + case PCI_MEMORY_BASE:
> + *value = (bridge->memlimit << 16 | bridge->membase);
> + break;
> +
> + case PCI_PREF_MEMORY_BASE:
> + *value = (bridge->prefmemlimit << 16 | bridge->prefmembase);
> + break;
> +
> + case PCI_PREF_BASE_UPPER32:
> + *value = bridge->prefbaseupper;
> + break;
> +
> + case PCI_PREF_LIMIT_UPPER32:
> + *value = bridge->preflimitupper;
> + break;
> +
> + case PCI_IO_BASE_UPPER16:
> + *value = (bridge->iolimitupper << 16 | bridge->iobaseupper);
> + break;
> +
> + case PCI_ROM_ADDRESS1:
> + *value = 0;
> + break;
> +
> + default:
> + *value = 0xffffffff;
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> + }
> +
> + if (size == 2)
> + *value = (*value >> (8 * (where & 3))) & 0xffff;
> + else if (size == 1)
> + *value = (*value >> (8 * (where & 3))) & 0xff;
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
> +EXPORT_SYMBOL_GPL(pci_sw_pci_bridge_read);
> +
> +int pci_sw_pci_bridge_write(struct pci_sw_pci_bridge *bridge,
> + unsigned int where, int size, u32 value)
> +{
> + u32 mask, reg;
> + int err;
> +
> + if (size == 4)
> + mask = 0x0;
> + else if (size == 2)
> + mask = ~(0xffff << ((where & 3) * 8));
> + else if (size == 1)
> + mask = ~(0xff << ((where & 3) * 8));
> + else
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> +
> + err = pci_sw_pci_bridge_read(bridge, where & ~3, 4, ®);
> + if (err)
> + return err;
> +
> + value = (reg & mask) | value << ((where & 3) * 8);
> +
> + switch (where & ~3) {
> + case PCI_COMMAND:
> + bridge->command = value & 0xffff;
> + bridge->status = value >> 16;
> + break;
> +
> + case PCI_BASE_ADDRESS_0 ... PCI_BASE_ADDRESS_1:
> + bridge->bar[((where & ~3) - PCI_BASE_ADDRESS_0) / 4] = value;
> + break;
> +
> + case PCI_IO_BASE:
> + /*
> + * We also keep bit 1 set, it is a read-only bit that
> + * indicates we support 32 bits addressing for the
> + * I/O
> + */
> + bridge->iobase = (value & 0xff) | PCI_IO_RANGE_TYPE_32;
> + bridge->iolimit = ((value >> 8) & 0xff) | PCI_IO_RANGE_TYPE_32;
> + bridge->secondary_status = value >> 16;
> + break;
> +
> + case PCI_MEMORY_BASE:
> + bridge->membase = value & 0xffff;
> + bridge->memlimit = value >> 16;
> + break;
> +
> + case PCI_PREF_MEMORY_BASE:
> + bridge->prefmembase = value & 0xffff;
> + bridge->prefmemlimit = value >> 16;
> + break;
> +
> + case PCI_PREF_BASE_UPPER32:
> + bridge->prefbaseupper = value;
> + break;
> +
> + case PCI_PREF_LIMIT_UPPER32:
> + bridge->preflimitupper = value;
> + break;
> +
> + case PCI_IO_BASE_UPPER16:
> + bridge->iobaseupper = value & 0xffff;
> + bridge->iolimitupper = value >> 16;
> + break;
> +
> + default:
> + break;
> + }
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
> +EXPORT_SYMBOL_GPL(pci_sw_pci_bridge_write);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index c93e258..b83b4c8 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1864,4 +1864,47 @@ extern int pci_sw_host_bridge_read(struct pci_sw_host_bridge *bridge,
> extern int pci_sw_host_bridge_write(struct pci_sw_host_bridge *bridge,
> unsigned int where, int size, u32 value);
>
> +struct pci_sw_pci_bridge {
> + u16 vendor;
> + u16 device;
> + u16 command;
> + u16 status;
> + u16 class;
> + u8 interface;
> + u8 revision;
> + u8 bist;
> + u8 header_type;
> + u8 latency_timer;
> + u8 cache_line_size;
> + u32 bar[2];
> + u8 primary_bus;
> + u8 secondary_bus;
> + u8 subordinate_bus;
> + u8 secondary_latency_timer;
> + u8 iobase;
> + u8 iolimit;
> + u16 secondary_status;
> + u16 membase;
> + u16 memlimit;
> + u16 prefmembase;
> + u16 prefmemlimit;
> + u32 prefbaseupper;
> + u32 preflimitupper;
> + u16 iobaseupper;
> + u16 iolimitupper;
> + u8 cappointer;
> + u8 reserved1;
> + u16 reserved2;
> + u32 romaddr;
> + u8 intline;
> + u8 intpin;
> + u16 bridgectrl;
> +};
> +
> +extern int pci_sw_pci_bridge_init(struct pci_sw_pci_bridge *bridge);
> +extern int pci_sw_pci_bridge_read(struct pci_sw_pci_bridge *bridge,
> + unsigned int where, int size, u32 *value);
> +extern int pci_sw_pci_bridge_write(struct pci_sw_pci_bridge *bridge,
> + unsigned int where, int size, u32 value);
> +
> #endif /* LINUX_PCI_H */
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Bjorn Helgaas @ 2013-01-29 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo4Zvy7=ROajygecfsEFVJxy-yNbSntdQdDFcQBPz=Qgfg@mail.gmail.com>
On Tue, Jan 29, 2013 at 12:38 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Tue, Jan 29, 2013 at 12:18 PM, Jason Gunthorpe
> <jgunthorpe@obsidianresearch.com> wrote:
>> On Tue, Jan 29, 2013 at 12:07:00PM -0700, Bjorn Helgaas wrote:
>>> > So when I say set aside, I mean for instance, the PCI-E entry in DT
>>> > has 128M of physical address space marked for PCI MMIO use. The kernel
>>> > does PCI resource allocation and the HW decoders in each link will be
>>> > set to claim some portion of the 128M - based on the MMIO windows
>>> > programmed on the PCI-PCI root port bridges. The reamining part of the
>>> > 128M is dead address space, not claimed by any hardware block at all.
>>>
>>> Thanks, this really helps get to the issue that the PCI core will care
>>> about. The root ports look like normal bridges, so the core assumes
>>> it can manage their windows as needed, as long as the windows stay
>>> inside the host bridge apertures that are logically upstream from the
>>> root ports.
>>
>> Yes, that is basically correct. This is what the PCI-E specification
>> says the root complex/root port should look like and this is what some
>> SOC hardware implements fully in hardware. The small wrinkle with
>> Marvell is that the PCI-PCI bridge config space is created by the
>> driver since the HW does not expose a standard config space.
>
> Oh, so the actual *root port* itself doesn't conform to the spec?
> Wow, that's worse than I expected.
>
> Then I guess you have emulate it and make sure its config space is
> complete enough and functional enough so that all the link management,
> power management, AER, etc., code in the core works as well as it
> would with a conforming device.
I'm not sure the existing emulation in these patches is sufficient.
For example, pci_sw_pci_bridge_write() updates bridge->membase when we
write to the window register, but I don't see anything that updates
the actual hardware decoder. That might be done in
mvebu_pcie_window_config_port() via armada_370_xp_alloc_pcie_window(),
but that looks like it's only done once. If the PCI core updates a
root port window later, I don't see where the hardware decoder will be
updated.
Maybe you're counting on the window assignments to be static? The PCI
core doesn't guarantee anything like that, though in the absence of
hotplug I don't know any reason why it would change things.
I also forgot about the bus number munging in mvebu_pcie_rd_conf().
The PCI core can update the bridge secondary/subordinate registers.
It looks like you don't support writing to them, and the read path
(pci_sw_pci_bridge_read()) looks like it doesn't do any translation
between the hardware and Linux bus numbers. I don't understand the
system well enough to know if this is an issue.
^ permalink raw reply
* Oddities with Energymicro's efm32
From: Uwe Kleine-König @ 2013-01-29 22:25 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I'm stuck with debugging a problem on my GiantGecko board (Cortex-M3
efm32 SoC).
Up to now I used the flash built into the SoC. But as it only has a size
of 1 MiB I had to switch to the external flash---at least for
development.
I guess because of changed timing settings this triggers a problem with
the stack pointer. The following code is executed:
8c009e80 <update_process_times>:
8c009e80: b570 push {r4, r5, r6, lr}
8c009e82: 466b mov r3, sp
8c009e84: f423 54ff bic.w r4, r3, #8160 ; 0x1fe0
8c009e88: f024 041f bic.w r4, r4, #31
8c009e8c: 4606 mov r6, r0
8c009e8e: 4810 ldr r0, [pc, #64] ; (8c009ed0 <update_process_times+0x50>)
8c009e90: 68e5 ldr r5, [r4, #12]
8c009e92: f7f8 fc9b bl 8c0027cc <printascii>
8c009e96: f5b4 5f00 cmp.w r4, #8192 ; 0x2000
8c009e9a: d806 bhi.n 8c009eaa <update_process_times+0x2a>
8c009e9c: 4668 mov r0, sp
8c009e9e: f7f8 fc6b bl 8c002778 <printhex8>
8c009ea2: 480c ldr r0, [pc, #48] ; (8c009ed4 <update_process_times+0x54>)
8c009ea4: f7f8 fc92 bl 8c0027cc <printascii>
8c009ea8: e7fe b.n 8c009ea8 <update_process_times+0x28>
printascii is a function to print out a debug message, printhex prints
out the value of r0. The code corresponds to this C-Code:
#define THREAD_SIZE 8192
static inline struct thread_info *current_thread_info(void)
{
register unsigned long sp asm ("sp");
return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
}
void update_process_times(int user_tick)
{
...
printascii("up1\n");
if (current_thread_info() <= 0x2000) {
asm volatile("mov r0, sp\n" "bl printhex8" : : : "cc", "r0", "r1", "r2", "r3");
printascii("br0ken\n");
while (1) {}
}
...
}
That is the condition of the if is
(sp & ~0x1fff) <= 0x2000
. If it triggers, the value of sp is printed. When the function in
question is called for the second time the condition is true and sp is
printed as 0x88009e88. The value of r4 is 0 then. The values on the
stack don't look reasonable:
88009e70: 8c0ed2b8 8c01c75f 8c01c78d 88016980
88009e80: 88018de4 8c01c797 88016900 88016900
88009e90: 88016980 88018de4 0000001d 00000000
88009ea0: 00000000 8c00306b 8c00305d 8c01d0a5
88009eb0: 88018de4 88016980 88018de4 00000000
88009ec0: 88026820 00000000 88009f44 88009f70
88009ed0: 8c0ed2b1 8c01d1a7 88018de4 8c01e5c9
88009ee0: 0000001d 8c01cd6b 0000001d 8c000cdb
which means that the value saved on the stack for lr would have been
0x88018de4 which is outside of the kernel image. It's a RAM address. So
sp probably was wrong when the function was entered, too. But even in
the case that the caller corrupted sp, why isn't it < 0x2000 when
printed out in the body of the if?
The code is run with irqs off (PRIMASK=1). So the only things that could
happen to influence sp between 0x8c009e82 and 0x8c009e9c are Reset, NMI
and HardFault. For each of them the handler wouldn't return, so they can
be ruled out.
The timing settings for flash and sram are copied from Energymicro's
Board Support Package, so they should be ok, too.
This is hard to debug because I cannot set breakpoints in the external
flash and I didn't get tracing up and running up to now. Also the
problem is very sensible to changes: If I add instrumentation to the
exception entry code the problem doesn't reproduce any more.
I'm out of ideas now. So if you have an idea that would be great. If you
want to reproduce I can provide you source code and/or binaries. Also if
you have questions or see a gap in my conclusions, don't hesitate to
contact me.
Thanks for your time,
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Stephen Warren @ 2013-01-29 22:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129225932.01efb45b@skate>
On 01/29/2013 02:59 PM, Thomas Petazzoni wrote:
> Arnd,
>
> On Tue, 29 Jan 2013 21:33:08 +0100, Thomas Petazzoni wrote:
>
>> Basically, I have currently two suggestions:
>>
>> * From Jason Gunthorpe, to not use any host bridge, and instead use
>> only PCI-to-PCI bridges, one per PCIe interface.
>>
>> * From you, to not use any PCI-to-PCI bridge, and use only host
>> bridges, one per PCIe interface.
>
> Thinking more about this, this solution (using one emulated host bridge
> per PCIe interface) would cause one problem: the PCIe device itself
> would no longer be in slot 0.
I think that's device 0 not slot 0 right?
> If I'm correct, with one host bridge per PCIe interface, we would have
> the following topology:
>
> bus 0, slot 0: emulated host bridge 0
> bus 0, slot 1: PCIe device connected to PCIe interface 0
I /think/ the bus that the root port itself is on is different from the
bus that the downstream device is on, so wouldn't you end up with:
bus 0, slot 0: emulated host bridge 0
bus 1, slot 0: PCIe device connected to PCIe interface 0
(and isn't that "root port" not "host bridge" in the first line above?)
^ permalink raw reply
* [PATCH] mailbox: prevent pl320-ipc code from breaking none-AMBA systems
From: Mark Langsdorf @ 2013-01-29 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1807311.dyJeq56cRL@vostro.rjw.lan>
> From: Rafael J. Wysocki [rjw at sisk.pl]
> On Tuesday, January 29, 2013 10:36:53 AM Mark Langsdorf wrote:
> > The pl320-ipc code depends on ARM AMBA, and should have the dependency
> > in its Kconfig.
>
> May I fold this into "ARM / highbank: add support for pl320 IPC"?
Yes. I didn't want to regenerate the patch series =)
--Mark Langsdorf
Calxeda, Inc.
> Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
> ---
> drivers/mailbox/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 9489554..9545c9f 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -8,6 +8,7 @@ menuconfig MAILBOX
> if MAILBOX
> config PL320_MBOX
> bool "ARM PL320 Mailbox"
> + depends on ARM_AMBA
> help
> An implementation of the ARM PL320 Interprocessor Communication
> Mailbox (IPCM), tailored for the Calxeda Highbank. It is used to
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH] ARM: call disable_nonboot_cpus() from machine_shutdown()
From: Stephen Warren @ 2013-01-29 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87obgwb5d1.fsf@xmission.com>
On 01/10/2013 11:28 PM, Eric W. Biederman wrote:
...
> I don't have any problem with generic code in the reboot path
> doing:
> if (cpu_online(0))
> set_cpus_allowed_ptr(current, cpumask_of(0));
It looks like that API just affects the scheduler, and not whether the
other CPUs are actually active/hot-plugged-in. At least for my use-case,
I need something that really disables the other CPUs so they aren't
executing code, hence my tendency to hot-un-plug them using
disable_nonboot_cpus(), rather than just shift task execution off them
using the code above.
I wonder if all architectures shouldn't always do the following in all
reboot/shutdown/kexec cases:
* set_cpus_allowed_ptr() to limit code execution to a single CPU.
* disable_nonboot_cpus() (or equivalent) if it's available to turn off
all the other CPUs.
The issue here would be that disable_nonboot_cpus() isn't always
available; I assume that's part of the reason that there are
arch-specific machine_xxx() hooks, so that architectures can
power-off/reset their CPUs even when hotplug isn't enabled? I wonder if
that can be refactored so that reboot/poweroff/kexec can share some
CPU-disable code with CPU hotplug?
^ 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