* [PATCH] ARM:mach-msm: seting tail NUL after strncpy
From: Chen Gang @ 2013-02-01 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510997DD.8080600@codeaurora.org>
? 2013?01?31? 05:59, Stephen Boyd ??:
> On 01/30/13 13:33, David Brown wrote:
>> I believe that Stephen Boyd is putting some significant work into this
>> code. Stephen, can you see if this bug is still in your current
>> version of the code, and make sure that it is fixed there?
>>
>
> This entire file is deleted in my set of patches that moves the current
> MSM clock code to the common clock framework.
>
ok, thank you.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH] ARM:boot: support the command with COMMAND_LINE_SIZE - 1 useful chars
From: Chen Gang @ 2013-02-01 1:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130154051.GA18119@lnx-rg.pr>
? 2013?01?30? 23:40, Richard GENOUD ??:
> On [mer., 30.01.2013 20:32:21], Chen Gang wrote:
>> >
>> > originally, not support the command with COMMAND_LINE_SIZE - 1 useful chars.
>> > but in fact, we can support it:
>> >
> You're right.
> Reviewed-by: Richard Genoud <richard.genoud@gmail.com>
ok, thank you.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH 2/2] USB chipidea i.MX: use devm_usb_get_phy_by_phandle to get phy
From: Peter Chen @ 2013-02-01 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510A7C07.5010901@ti.com>
On Thu, Jan 31, 2013 at 07:43:27PM +0530, kishon wrote:
> Hi,
>
> On Thursday 31 January 2013 05:02 PM, Sascha Hauer wrote:
> >Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Some maintainers don't accept patches without a commit message.
>
> Apart from that you can add,
> Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Peter Chen <peter.chen@freescale.com>
>
> Thanks
> Kishon
>
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH 1/2] USB mxs-phy: Register phy with framework
From: Peter Chen @ 2013-02-01 1:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359631937-26646-2-git-send-email-s.hauer@pengutronix.de>
On Thu, Jan 31, 2013 at 12:32:16PM +0100, Sascha Hauer wrote:
> We now have usb_add_phy_dev(), so use it to register with the framework
> to be able to find the phy from the USB driver.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/usb/otg/mxs-phy.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
> index 5158332..5b39885 100644
> --- a/drivers/usb/otg/mxs-phy.c
> +++ b/drivers/usb/otg/mxs-phy.c
> @@ -127,6 +127,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
> void __iomem *base;
> struct clk *clk;
> struct mxs_phy *mxs_phy;
> + int ret;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> @@ -166,11 +167,19 @@ static int mxs_phy_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, &mxs_phy->phy);
>
> + ret = usb_add_phy_dev(&mxs_phy->phy);
> + if (ret)
> + return ret;
> +
> return 0;
> }
>
> static int mxs_phy_remove(struct platform_device *pdev)
> {
> + struct mxs_phy *mxs_phy = platform_get_drvdata(pdev);
> +
> + usb_remove_phy(&mxs_phy->phy);
> +
> platform_set_drvdata(pdev, NULL);
>
> return 0;
Reviewed-by: Peter Chen <peter.chen@freescale.com>
--
Best Regards,
Peter Chen
^ permalink raw reply
* [RFC] arm: use built-in byte swap function
From: Russell King - ARM Linux @ 2013-02-01 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131145947.f62474a0600848df86548b96@freescale.com>
On Thu, Jan 31, 2013 at 02:59:47PM -0600, Kim Phillips wrote:
> On Thu, 31 Jan 2013 09:28:01 +0000
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>
> > On Wed, Jan 30, 2013 at 08:09:00PM -0600, Kim Phillips wrote:
> > > v2:
> > > - at91 and lpd270 builds fixed by limiting to ARMv6 and above
> > > (i.e., ARM cores that have support for the 'rev' instruction).
> > > Otherwise, the compiler emits calls to libgcc's __bswapsi2 on
> > > these ARMv4/v5 builds (and arch ARM doesn't link with libgcc).
> >
> > Which compiler version? gcc 4.5.4 doesn't do this, except for the 16-bit
> > swap, so I doubt that any later compiler does.
>
> I've tried both gcc 4.6.3 [1] and 4.6.4 [2]. If you can point me to
> a 4.5.x, I'll try that, too, but as it stands now, if one moves the
> code added to swab.h below outside of its armv6 protection,
> gcc adds calls to __bswapsi2.
Take a look at the message I sent on the 29th towards the beginning of
this thread for details of gcc 4.5.4 behaviour.
^ permalink raw reply
* [rtc-linux] [PATCH] rtc: pl031: fix the missing operation on enable
From: Haojian Zhuang @ 2013-02-01 1:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131144459.39f9a978.akpm@linux-foundation.org>
On 1 February 2013 06:44, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 30 Jan 2013 09:04:25 +0800
> Haojian Zhuang <haojian.zhuang@linaro.org> wrote:
>
>> RTC control register should be enabled in the process of initliazing.
>>
>> ...
>>
>> --- a/drivers/rtc/rtc-pl031.c
>> +++ b/drivers/rtc/rtc-pl031.c
>> @@ -44,6 +44,7 @@
>> #define RTC_YMR 0x34 /* Year match register */
>> #define RTC_YLR 0x38 /* Year data load register */
>>
>> +#define RTC_CR_EN (1 << 0) /* counter enable bit */
>> #define RTC_CR_CWEN (1 << 26) /* Clockwatch enable bit */
>>
>> #define RTC_TCR_EN (1 << 1) /* Periodic timer enable bit */
>> @@ -320,7 +321,7 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
>> struct pl031_local *ldata;
>> struct pl031_vendor_data *vendor = id->data;
>> struct rtc_class_ops *ops = &vendor->ops;
>> - unsigned long time;
>> + unsigned long time, data;
>>
>> ret = amba_request_regions(adev, NULL);
>> if (ret)
>> @@ -345,10 +346,11 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
>> dev_dbg(&adev->dev, "designer ID = 0x%02x\n", amba_manf(adev));
>> dev_dbg(&adev->dev, "revision = 0x%01x\n", amba_rev(adev));
>>
>> + data = readl(ldata->base + RTC_CR);
>> /* Enable the clockwatch on ST Variants */
>> if (vendor->clockwatch)
>> - writel(readl(ldata->base + RTC_CR) | RTC_CR_CWEN,
>> - ldata->base + RTC_CR);
>> + data |= RTC_CR_CWEN;
>> + writel(data | RTC_CR_EN, ldata->base + RTC_CR);
>
> Does this patch fix some user-visible misbehaviour? If so, please
> fully describe that misbehaviour.
>
Hi Andrew,
I copy the description from rtc pl031 user manual (page 33 of
DDI0224.pdf) in below.
RTCCR is a 1-bit control register. When HIGH, the counter enable
signal is asserted to
enable the counter. Table 3-5 shows the bit assignments for the RTCCR register.
Table 3-5 RTCCR register
-----------------------------------------------------------------------------------------------------------------------
Bits Name Type Function
31:1 - Read/write Reserved. Read
unpredictable. Should
be written as 0.
0 RTC start Read/write If set to 1, the
RTC is enabled. Once it is
enabled, any writes to this bit have no
effect
on the RTC until a system reset.
A read
returns the status of the RTC.
-----------------------------------------------------------------------------------------------------------------------
>From this document, RTCCR must be enabled before usage. Without this
patch, I really
failed to enable RTC in Hisilicon Hi3620 SoC. It results that the
register mapping section
in RTC is always read as zero. So I doubt that ST guys may already
enable this register
in bootloader. So they won't meet this issue.
Best Regards
Haojian
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-02-01 1:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510B0D9C.1000101@wwwdotorg.org>
On Thu, Jan 31, 2013 at 05:34:36PM -0700, Stephen Warren wrote:
> On 01/28/2013 11:56 AM, Thomas Petazzoni wrote:
> > This driver implements the support for the PCIe interfaces on the
> > Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
> > cover earlier families of Marvell SoCs, such as Dove, Orion and
> > Kirkwood.
>
> Bjorn and I happen to live very close, so we got together today and
> talked about PCIe on ARM.
>
> One of the questions he asked is: why does the window management on the
> Marvell SoCs need to be dynamic?
> (Sorry if this was covered earlier; I vaguely recall some discussion on
> the topic, but couldn't find it quickly)
Well I've answered it several times, so has Thomas.. Lets try again,
please save for future reference :)
Lets seperate two things.
The CPU physical address ranges reserved for PCI bus access are not
dynamic. This is set in DT, or whatever, statically. Just like every
other PCI case on ARM. Just like Tegra. That is not the issue.
What is required is that the division of this space amongst the 10
physical PCI-E links must be dynamic. Just like x86. Just like the new
tegra driver. [1]
Is that clear?
> As background, PCIe enumeration in Linux usually works like:
>
> 1) You start off with some CPU physical address regions that generate
> transactions on the PCIe bus.
>
> 2) You enumerate all the PCIe devices, and assign an address to each BAR
> found, carved out of the PCIe address range corresponding to the regions
> you knew from (1).
Step 2 also includes 'assign address windows to all the physical PCI-E
links'. This is very important because it is what this entire
discussion is about.
Look at how tegra or x86 works, the CPU physical addresses for PCI-E
do nothing until the PCI-to-PCI bridge window registers in each link's
configuration space are setup. Until that is done the SOC doesn't know
which link to send the transaction to.
Marvell is the same, until the link's window registers are setup the
CPU addresses don't go anywhere.
Notice this has absolutely no effect on the host bridge aperture.
This is a link-by-link configuration of what addresses *go down that
link*.
The big difference is the link window registers for Marvell do not
conform to the PCI configuration space specification. They are Marvell
specific.
This is what the glue code in the host driver does, it converts the
Marvell specificness into something the kernel can undertstand and
control. There are countless ways to do this, but please accept it
is necessary that it be done...
> Now, I recall that a related issue was that you are tight on CPU
> physical address space, and the second algorithm above would allow the
> size of the PCIe controller's window configuration to be as small as
> possible, and hence there would be more CPU physical address space
> available to fit in other peripherals.
Physical address space is certainly a concern, but availability of
decoder windows is the major one. Each link requires one decoder
window for MMIO and one for IO, and possibly one for prefetch. The
chip doesn't have 30 decoder windows. So the allocation of decoders to
links must be dynamic, based on the requirements of the downstream
endports on the link.
> However, why does this need to be dynamic? On a particular board, you
> know all the other (non-PCIe) peripherals that you need to fit into the
> CPU physical address space, so you know how much is left over for PCIe,
> so why not always make the PCIe window fill up all the available
> space,
Because there is no such thing as an all-links PCIe window on this
hardware.
Each link has a seperate window.
If you get rid of all the dynamic allocation then every link must
statically reserve some portion of physical address space and some
number of decoder windows.
That more or less means you need to know what is going to be on the
other side of every link when you write the DT.
> With a static window configuration in DT, you'd end up with a system
> that worked much like any x86 system or Tegra, with some static memory
> range available to PCIe. It's just that in your case, the region
> location/size could change from boot to boot based on DT, whereas it's
> hard-coded in HW for Tegra and I assume x86 too.
How is this better? Now you have a system where you have to customize
the DT before you connect a PCI-E device. What if someone uses this
chip in a configuration with physical slots? How does that work? What
about hotplug? What about a unified kernel? That is *not* like x86 or
tegra.
IMHO Thomas's direction in his proposed driver ends up working very
close to the new tegra driver, and has the sort of dynamic allocation
and discovery people expect from PCI-E.
Jason
1 - The new tegra driver switches from calling ARM's pci_common_init
once for every physical link, to once for the SOC. It does this by
fixing the routing of config transactions so that the kernel sees
the per-link PCI-PCI root port bridge config space provided by the
hardware at the correct place. By doing this it changes from
statically allocating a physical memory region for each link to
statically allocating a region for all the links, and dynamically
dividing that region amongst the links.
^ permalink raw reply
* [PATCH 2/4] ARM: mach-shmobile: r8a7779: Allow initialisation of GIC by DT
From: Simon Horman @ 2013-02-01 1:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201003410.GA30007@verge.net.au>
On Fri, Feb 01, 2013 at 09:34:10AM +0900, Simon Horman wrote:
> On Fri, Feb 01, 2013 at 09:11:19AM +0900, Simon Horman wrote:
> > On Thu, Jan 31, 2013 at 12:32:13PM +0000, Mark Rutland wrote:
> > > Hi Simon,
> > >
> > > On Thu, Jan 31, 2013 at 01:50:49AM +0000, Simon Horman wrote:
> > > > This allows the GIC interrupt controller of the r8a7779 SoC to be
> > > > initialised using a flattened device tree blob.
> > > >
> > > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > > ---
> > > > arch/arm/boot/dts/r8a7779.dtsi | 40 ++++++++++++++++++++++++++
> > > > arch/arm/mach-shmobile/include/mach/common.h | 1 +
> > > > arch/arm/mach-shmobile/intc-r8a7779.c | 27 +++++++++++++----
> > > > 3 files changed, 62 insertions(+), 6 deletions(-)
> > > > create mode 100644 arch/arm/boot/dts/r8a7779.dtsi
> > > >
> > > > diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
> > > > new file mode 100644
> > > > index 0000000..eadc12e
> > > > --- /dev/null
> > > > +++ b/arch/arm/boot/dts/r8a7779.dtsi
> > > > @@ -0,0 +1,40 @@
> > > > +/*
> > > > + * Device Tree Source for Renesas r8a7740
> > > > + *
> > > > + * Copyright (C) 2013 Renesas Solutions Corp.
> > > > + * Copyright (C) 2013 Simon Horman
> > > > + *
> > > > + * This file is licensed under the terms of the GNU General Public License
> > > > + * version 2. This program is licensed "as is" without any warranty of any
> > > > + * kind, whether express or implied.
> > > > + */
> > > > +
> > > > +/include/ "skeleton.dtsi"
> > > > +
> > > > +/ {
> > > > + compatible = "renesas,r8a7779";
> > > > +
> > > > + cpus {
> > > > + cpu at 0 {
> > > > + compatible = "arm,cortex-a9";
> > > > + };
> > > > + cpu at 1 {
> > > > + compatible = "arm,cortex-a9";
> > > > + };
> > > > + cpu at 2 {
> > > > + compatible = "arm,cortex-a9";
> > > > + };
> > > > + cpu at 3 {
> > > > + compatible = "arm,cortex-a9";
> > > > + };
> > > > + };
> > >
> > > Sorry to sound like a broken record, but it'd be good to see reg and
> > > device_type set here.
> >
> > Sure, will do.
> >
> > > > +
> > > > + gic: interrupt-controller at f0001000 {
> > > > + compatible = "arm,cortex-a9-gic";
> > > > + #interrupt-cells = <3>;
> > > > + #address-cells = <1>;
> > >
> > > Why is #address-cells needed here (and without #size-cells)? I see it's in the
> > > binding document example, but I can't figure out why.
> >
> > Its here because I copied the example.
> > I will see about removing it from here.
> >
> > > > + interrupt-controller;
> > > > + reg = <0xf0001000 0x1000>,
> > > > + <0xf0000100 0x100>;
> > > > + };
> > > > +};
>
> A revised patch is below. I should also remove "#address-cells = <1>" from
> gic in arch/arm/boot/dts/sh73a0.dtsi if it is indeed unnecessary.
>
>
> >From f08f5df1bd6e2133232d06b8cfb847424d6d4cc8 Mon Sep 17 00:00:00 2001
> From: Simon Horman <horms+renesas@verge.net.au>
> Date: Tue, 29 Jan 2013 14:21:46 +0900
> Subject: [PATCH] ARM: mach-shmobile: r8a7779: Allow initialisation of GIC by
> DT
>
> This allows the GIC interrupt controller of the r8a7779 SoC to be
> initialised using a flattened device tree blob.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> arch/arm/boot/dts/r8a7779.dtsi | 50 ++++++++++++++++++++++++++
> arch/arm/mach-shmobile/include/mach/common.h | 1 +
> arch/arm/mach-shmobile/intc-r8a7779.c | 27 ++++++++++----
> 3 files changed, 72 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm/boot/dts/r8a7779.dtsi
>
> v2
> As suggested by Mark Rutland
> * Add reg and device_type to cpus
> * Remove #address-cells from gic
>
> diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
> new file mode 100644
> index 0000000..d1fde48
> --- /dev/null
> +++ b/arch/arm/boot/dts/r8a7779.dtsi
> @@ -0,0 +1,50 @@
> +/*
> + * Device Tree Source for Renesas r8a7740
> + *
> + * Copyright (C) 2013 Renesas Solutions Corp.
> + * Copyright (C) 2013 Simon Horman
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + compatible = "renesas,r8a7779";
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0>;
> + };
> + cpu at 1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0>;
> + };
> + cpu at 2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0>;
> + };
> + cpu at 3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + reg = <0>;
> + };
> + };
Sorry, the above reg values are rubbish. I'll fix them and repost.
> +
> + gic: interrupt-controller at f0001000 {
> + compatible = "arm,cortex-a9-gic";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0xf0001000 0x1000>,
> + <0xf0000100 0x100>;
> + };
> +};
> diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
> index 16dab18..8ef7ebb 100644
> --- a/arch/arm/mach-shmobile/include/mach/common.h
> +++ b/arch/arm/mach-shmobile/include/mach/common.h
> @@ -63,6 +63,7 @@ extern void r8a7740_pinmux_init(void);
> extern void r8a7740_pm_init(void);
>
> extern void r8a7779_init_irq(void);
> +extern void r8a7779_init_irq_dt(void);
> extern void r8a7779_map_io(void);
> extern void r8a7779_earlytimer_init(void);
> extern void r8a7779_add_early_devices(void);
> diff --git a/arch/arm/mach-shmobile/intc-r8a7779.c b/arch/arm/mach-shmobile/intc-r8a7779.c
> index 8807c27..f9cc4bc 100644
> --- a/arch/arm/mach-shmobile/intc-r8a7779.c
> +++ b/arch/arm/mach-shmobile/intc-r8a7779.c
> @@ -24,6 +24,7 @@
> #include <linux/io.h>
> #include <linux/irqchip/arm-gic.h>
> #include <mach/common.h>
> +#include <linux/irqchip.h>
> #include <mach/intc.h>
> #include <mach/r8a7779.h>
> #include <asm/mach-types.h>
> @@ -43,13 +44,8 @@ static int r8a7779_set_wake(struct irq_data *data, unsigned int on)
> return 0; /* always allow wakeup */
> }
>
> -void __init r8a7779_init_irq(void)
> +static void __init r8a7779_init_irq_common(void)
> {
> - void __iomem *gic_dist_base = IOMEM(0xf0001000);
> - void __iomem *gic_cpu_base = IOMEM(0xf0000100);
> -
> - /* use GIC to handle interrupts */
> - gic_init(0, 29, gic_dist_base, gic_cpu_base);
> gic_arch_extn.irq_set_wake = r8a7779_set_wake;
>
> /* route all interrupts to ARM */
> @@ -63,3 +59,22 @@ void __init r8a7779_init_irq(void)
> __raw_writel(0xbffffffc, INT2SMSKCR3);
> __raw_writel(0x003fee3f, INT2SMSKCR4);
> }
> +
> +void __init r8a7779_init_irq(void)
> +{
> + void __iomem *gic_dist_base = IOMEM(0xf0001000);
> + void __iomem *gic_cpu_base = IOMEM(0xf0000100);
> +
> + /* use GIC to handle interrupts */
> + gic_init(0, 29, gic_dist_base, gic_cpu_base);
> +
> + r8a7779_init_irq_common();
> +}
> +
> +#ifdef CONFIG_OF
> +void __init r8a7779_init_irq_dt(void)
> +{
> + irqchip_init();
> + r8a7779_init_irq_common();
> +}
> +#endif
> --
> 1.7.10.4
>
^ permalink raw reply
* [Consult]: how to join to linux-arm-kernel@lists.infradead.org
From: Chen Gang F T @ 2013-02-01 1:47 UTC (permalink / raw)
To: linux-arm-kernel
Hello All:
May I join into linux-arm-kernel at lists.infradead.org mailing list ?
for I can not find it in http://vger.kernel.org/vger-lists.html
maybe:
A) need some qualifications.
B) or there is another place for it.
C) or it is my fault (still in http://vger.kernel.org/vger-lists.html)
D) none of above.
welcome any members to providing relative informations.
thanks.
--
Chen Gang
Flying Transformer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chen_gang_flying_transformer.vcf
Type: text/x-vcard
Size: 67 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130201/dbd8b7e7/attachment.vcf>
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Stephen Warren @ 2013-02-01 2:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201014138.GA16234@obsidianresearch.com>
On 01/31/2013 06:41 PM, Jason Gunthorpe wrote:
> On Thu, Jan 31, 2013 at 05:34:36PM -0700, Stephen Warren wrote:
>> On 01/28/2013 11:56 AM, Thomas Petazzoni wrote:
>>> This driver implements the support for the PCIe interfaces on the
>>> Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
>>> cover earlier families of Marvell SoCs, such as Dove, Orion and
>>> Kirkwood.
>>
>> Bjorn and I happen to live very close, so we got together today and
>> talked about PCIe on ARM.
>>
>> One of the questions he asked is: why does the window management on the
>> Marvell SoCs need to be dynamic?
>
>> (Sorry if this was covered earlier; I vaguely recall some discussion on
>> the topic, but couldn't find it quickly)
>
> Well I've answered it several times, so has Thomas.. Lets try again,
> please save for future reference :)
>
> Lets seperate two things.
>
> The CPU physical address ranges reserved for PCI bus access are not
> dynamic. This is set in DT, or whatever, statically. Just like every
> other PCI case on ARM. Just like Tegra. That is not the issue.
>
> What is required is that the division of this space amongst the 10
> physical PCI-E links must be dynamic. Just like x86. Just like the new
> tegra driver. [1]
>
> Is that clear?
Yes.
>> As background, PCIe enumeration in Linux usually works like:
>>
>> 1) You start off with some CPU physical address regions that generate
>> transactions on the PCIe bus.
>>
>> 2) You enumerate all the PCIe devices, and assign an address to each BAR
>> found, carved out of the PCIe address range corresponding to the regions
>> you knew from (1).
>
> Step 2 also includes 'assign address windows to all the physical PCI-E
> links'. This is very important because it is what this entire
> discussion is about.
OK.
> Look at how tegra or x86 works, the CPU physical addresses for PCI-E
> do nothing until the PCI-to-PCI bridge window registers in each link's
> configuration space are setup. Until that is done the SOC doesn't know
> which link to send the transaction to.
>From my perspective, this is slightly the wrong way of describing the
issue, but I see what you mean:
At least on Tegra and I think x86, any transaction that goes to the
physical PCIe aperture is translated onto (internal) PCIe bus 0, so the
lack of window or PCIe/PCIe bridge BAR register programming doesn't
prevent the transaction going /somewhere/ (even if "somewhere" is only
half way to where it's useful!). The difference is pretty subtle. The
issue is that without the PCIe/PCIe bridge BARs programmed, the PCIe
transactions won't get off bus 0 and onto a downstream bus of one of the
PCIe/PCIe bridges, or put another way, no PCIe/PCIe will claim the
transaction that happens on PCIe bus 0
(Using "PCIe/PCIe bridge" above to mean "PCIe root port")
> Marvell is the same, until the link's window registers are setup the
> CPU addresses don't go anywhere.
>
> Notice this has absolutely no effect on the host bridge aperture.
> This is a link-by-link configuration of what addresses *go down that
> link*.
Right.
> The big difference is the link window registers for Marvell do not
> conform to the PCI configuration space specification. They are Marvell
> specific.
>
> This is what the glue code in the host driver does, it converts the
> Marvell specificness into something the kernel can undertstand and
> control. There are countless ways to do this, but please accept it
> is necessary that it be done...
Sure.
>> Now, I recall that a related issue was that you are tight on CPU
>> physical address space, and the second algorithm above would allow the
>> size of the PCIe controller's window configuration to be as small as
>> possible, and hence there would be more CPU physical address space
>> available to fit in other peripherals.
>
> Physical address space is certainly a concern, but availability of
> decoder windows is the major one. Each link requires one decoder
> window for MMIO and one for IO, and possibly one for prefetch. The
> chip doesn't have 30 decoder windows. So the allocation of decoders to
> links must be dynamic, based on the requirements of the downstream
> endports on the link.
Oh I see...
I originally thought the issue was that the windows were between CPU
physical address space and the PCIe host controller itself. But in fact,
the windows are between PCIe bus 0 and the root ports, so they're the
equivalent of the standard PCIe root port (or PCIe/PCIe bridge) BAR
registers. And related, these BAR/window registers are usually part of
each PCIe root port itself, and hence there's a whole number dedicated
to each root port, but on Marvell there's a *global* pool of these
BARs/windows instead.
Now I think I finally understand the architecture of your HW.
>> However, why does this need to be dynamic? On a particular board, you
>> know all the other (non-PCIe) peripherals that you need to fit into the
>> CPU physical address space, so you know how much is left over for PCIe,
>> so why not always make the PCIe window fill up all the available
>> space,
>
> Because there is no such thing as an all-links PCIe window on this
> hardware.
>
> Each link has a seperate window.
>
> If you get rid of all the dynamic allocation then every link must
> statically reserve some portion of physical address space and some
> number of decoder windows.
>
> That more or less means you need to know what is going to be on the
> other side of every link when you write the DT.
So, the dynamic programming of the windows on Marvell HW is the exact
logical equivalent of programming a standard PCIe root port's BAR
registers. It makes perfect sense that should be dynamic. Presumably
this is something you can make work inside your emulated PCIe/PCIe
bridge module, simply by capturing writes to the BAR registers, and
translating them into writes to the Marvell window registers.
Now, I do have one follow-on question: You said you don't have 30
windows, but how many do you have free after allocating windows to any
other peripherals that need them, relative to (3 *
number-of-root-ports-in-the-SoC)? (3 being IO+Mem+PrefetchableMem.)
The thing here is that when the PCIe core writes to a root port BAR
window to configure/enable it the first time, you'll need to capture
that transaction and dynamically allocate a window and program it in a
way equivalent to what the BAR register write would have achieved on
standard HW. Later, the window might need resizing, or even to be
completely disabled, if the PCIe core were to change the standard BAR
register. Dynamically allocating a window when the BAR is written seems
a little heavy-weight.
So while it's obvious that window base address and size shouldn't be
static, I wonder if the assignment of a specific window ID to a specific
root port ID shouldn be dynamic or static. For example, if your HW
configuration leaves you with 6 windows available, you could support 2
PCIe root ports by statically assigning 3 windows to serve each of those
2 root ports. Would that work, or are there systems where over-commit is
needed, e.g. if there's no IO space behind a root port, you could get
away with two windows per root port, and hence be able to run 3 root
ports rather than just 2? Still, if you know which PCIe devices are
being the root ports, you could still represent the over-commit
statically in DT
Still, I supose doing it dynamically in the driver does end up being a
lot less to think about for someone creating the DT for a new board.
Having to translate standard root port BAR register writes to Marvell
window register allocation/writes would imply that the emulated root
port code has to be very closely tied into the Marvell PCIe driver, and
not something that could be at all generic in the most part.
>> With a static window configuration in DT, you'd end up with a system
>> that worked much like any x86 system or Tegra, with some static memory
>> range available to PCIe. It's just that in your case, the region
>> location/size could change from boot to boot based on DT, whereas it's
>> hard-coded in HW for Tegra and I assume x86 too.
>
> How is this better? Now you have a system where you have to customize
> the DT before you connect a PCI-E device. What if someone uses this
> chip in a configuration with physical slots? How does that work? What
> about hotplug? What about a unified kernel? That is *not* like x86 or
> tegra.
Right. Now that I really understand what the windows are doing, I can
see that a static window configuration (address/size, perhaps rather
than windows are used) would not be appropriate.
> IMHO Thomas's direction in his proposed driver ends up working very
> close to the new tegra driver, and has the sort of dynamic allocation
> and discovery people expect from PCI-E.
>
> Jason
>
> 1 - The new tegra driver switches from calling ARM's pci_common_init
> once for every physical link, to once for the SOC. It does this by
> fixing the routing of config transactions so that the kernel sees
> the per-link PCI-PCI root port bridge config space provided by the
> hardware at the correct place. By doing this it changes from
> statically allocating a physical memory region for each link to
> statically allocating a region for all the links, and dynamically
> dividing that region amongst the links.
Right, we have both (or all 3) root ports show up in the same PCIe domain.
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: Nicolas Pitre @ 2013-02-01 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510AEDC2.80107@zytor.com>
On Thu, 31 Jan 2013, H. Peter Anvin wrote:
> On 01/31/2013 02:16 PM, Nicolas Pitre wrote:
> >>
> >> Some utterly weird things like the Xen domain builder do that, because
> >> they have to. That is why we explicitly document that the payload is
> >> ELF and how to access it in the bzImage spec.
> >
> > Are you kidding?
> >
> > And what format do they expect?
> >
>
> I think they can be fairly flexible. Obviously gzip is always
> supported. I don't know the details.
>
> > If people are doing weird things with formats we're about to remove then
> > it's their fault if they didn't make upstream developers aware of it.
> > And if the reason they didn't tell anyone is because it is too nasty for
> > public confession then they simply deserve to be broken and come up with
> > a more sustainable solution.
>
> Well, it is too nasty for public confession, but it's called
> "paravirtualization".
The fact that you are aware of it means we're not going to break them.
But my point is that we must not be held back just in case someone out
there might have painted himself in a corner without telling anyone.
Nicolas
^ permalink raw reply
* [PATCH v4 2/3] ARM: ioremap: introduce an infrastructure for static mapped area
From: Nicolas Pitre @ 2013-02-01 3:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359594008-14688-3-git-send-email-iamjoonsoo.kim@lge.com>
On Thu, 31 Jan 2013, 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 architecture dependency
> on vmalloc layer. I think that vmlist and vmlist_lock is internal data
> structure for vmalloc layer. Some codes for debugging and stat inevitably
> use vmlist and vmlist_lock. But it is preferable that they are used
> as least as possible in outside of vmalloc.c
>
> Now, I introduce an ARM-specific infrastructure for static mapped area. In
> the following patch, we will use this and resolve above mentioned problem.
>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Much better. Comments below.
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index 88fd86c..ceb34ae 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -39,6 +39,78 @@
> #include <asm/mach/pci.h>
> #include "mm.h"
>
> +
> +LIST_HEAD(static_vmlist);
> +static DEFINE_RWLOCK(static_vmlist_lock);
In fact you don't need a lock at all. The only writer is
add_static_vm_early() and we know it is only used during boot when the
kernel is still single-threaded.
> +
> +static struct static_vm *find_static_vm_paddr(phys_addr_t paddr,
> + size_t size, unsigned long flags)
> +{
> + struct static_vm *svm;
> + struct vm_struct *vm;
> +
> + read_lock(&static_vmlist_lock);
> + list_for_each_entry(svm, &static_vmlist, list) {
> + if (svm->flags != flags)
> + continue;
> +
> + vm = &svm->vm;
> + if (vm->phys_addr > paddr ||
> + paddr + size - 1 > vm->phys_addr + vm->size - 1)
> + continue;
> +
> + read_unlock(&static_vmlist_lock);
> + return svm;
> + }
> +
> + return NULL;
> +}
> +
> +struct static_vm *find_static_vm_vaddr(void *vaddr)
> +{
> + struct static_vm *svm;
> + struct vm_struct *vm;
> +
> + read_lock(&static_vmlist_lock);
> + list_for_each_entry(svm, &static_vmlist, list) {
> + vm = &svm->vm;
> +
> + /* static_vmlist is ascending order */
> + if (vm->addr > vaddr)
> + break;
> +
> + if (vm->addr <= vaddr && vm->addr + vm->size > vaddr) {
> + read_unlock(&static_vmlist_lock);
> + return svm;
> + }
> + }
> + read_unlock(&static_vmlist_lock);
> +
> + return NULL;
> +}
> +
> +void add_static_vm_early(struct static_vm *svm, unsigned long flags)
This should be marked with __init. This way, it is less likely to be
used after boot, especially with no locking. And vm_area_add_early() is
valid only if !vmap_initialized anyway, and also __init.
> +{
> + struct static_vm *curr_svm;
> + struct vm_struct *vm;
> + void *vaddr;
> +
> + vm_area_add_early(&svm->vm);
> +
> + vaddr = svm->vm.addr;
> + svm->flags = flags;
> +
> + write_lock(&static_vmlist_lock);
> + list_for_each_entry(curr_svm, &static_vmlist, list) {
> + vm = &curr_svm->vm;
> +
> + if (vm->addr > vaddr)
> + break;
> + }
> + list_add_tail(&svm->list, &curr_svm->list);
> + write_unlock(&static_vmlist_lock);
> +}
> +
> int ioremap_page(unsigned long virt, unsigned long phys,
> const struct mem_type *mtype)
> {
> diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
> index a8ee92d..fb45c79 100644
> --- a/arch/arm/mm/mm.h
> +++ b/arch/arm/mm/mm.h
> @@ -1,4 +1,6 @@
> #ifdef CONFIG_MMU
> +#include <linux/list.h>
> +#include <linux/vmalloc.h>
>
> /* the upper-most page table pointer */
> extern pmd_t *top_pmd;
> @@ -65,6 +67,24 @@ extern void __flush_dcache_page(struct address_space *mapping, struct page *page
> /* consistent regions used by dma_alloc_attrs() */
> #define VM_ARM_DMA_CONSISTENT 0x20000000
>
> +
> +/* ARM specific static_vm->flags bits */
> +#define STATIC_VM_MEM 0x00000001
> +#define STATIC_VM_EMPTY 0x00000002
> +#define STATIC_VM_MTYPE(mtype) ((mtype) << 20)
> +
> +#define STATIC_VM_TYPE(type, mtype) (type | STATIC_VM_MTYPE(mtype))
> +
> +struct static_vm {
> + struct vm_struct vm;
> + struct list_head list;
> + unsigned long flags;
> +};
What is your motivation for having separate flags instead of simply
keeping the current vm->flags usage?
Nicolas
^ permalink raw reply
* [PATCH v4 02/13] ARM: LPAE: use phys_addr_t in alloc_init_pud()
From: Hui Wang @ 2013-02-01 3:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359669512-31276-3-git-send-email-cyril@ti.com>
Cyril Chemparathy wrote:
> From: Vitaly Andrianov <vitalya@ti.com>
>
> This patch fixes the alloc_init_pud() function to use phys_addr_t instead of
> unsigned long when passing in the phys argument.
>
> This is an extension to commit 97092e0c56830457af0639f6bd904537a150ea4a (ARM:
> pgtable: use phys_addr_t for physical addresses), which applied similar changes
> elsewhere in the ARM memory management code.
>
> Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
> Signed-off-by: Cyril Chemparathy <cyril@ti.com>
> Acked-by: Nicolas Pitre <nico@linaro.org>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm/mm/mmu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 9f06102..ef43689 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -612,7 +612,8 @@ static void __init alloc_init_section(pud_t *pud, unsigned long addr,
> }
>
> static void __init alloc_init_pud(pgd_t *pgd, unsigned long addr,
> - unsigned long end, unsigned long phys, const struct mem_type *type)
> + unsigned long end, phys_addr_t phys,
> + const struct mem_type *type)
>
The change is correct but seems useless so far. This function only be
called from map_lowmem and devicemaps_init, from i know neither lowmem
nor device io registers of existing platforms exceed 32bit address.
regards,
Hui.
> {
> pud_t *pud = pud_offset(pgd, addr);
> unsigned long next;
>
^ permalink raw reply
* [PATCH v4 02/13] ARM: LPAE: use phys_addr_t in alloc_init_pud()
From: Nicolas Pitre @ 2013-02-01 3:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510B327E.3050502@gmail.com>
On Fri, 1 Feb 2013, Hui Wang wrote:
> Cyril Chemparathy wrote:
> > From: Vitaly Andrianov <vitalya@ti.com>
> >
> > This patch fixes the alloc_init_pud() function to use phys_addr_t instead of
> > unsigned long when passing in the phys argument.
> >
> > This is an extension to commit 97092e0c56830457af0639f6bd904537a150ea4a
> > (ARM:
> > pgtable: use phys_addr_t for physical addresses), which applied similar
> > changes
> > elsewhere in the ARM memory management code.
> >
> > Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
> > Signed-off-by: Cyril Chemparathy <cyril@ti.com>
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> > arch/arm/mm/mmu.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > index 9f06102..ef43689 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -612,7 +612,8 @@ static void __init alloc_init_section(pud_t *pud,
> > unsigned long addr,
> > }
> > static void __init alloc_init_pud(pgd_t *pgd, unsigned long addr,
> > - unsigned long end, unsigned long phys, const struct mem_type *type)
> > + unsigned long end, phys_addr_t phys,
> > + const struct mem_type *type)
> >
> The change is correct but seems useless so far. This function only be called
> from map_lowmem and devicemaps_init, from i know neither lowmem nor device io
> registers of existing platforms exceed 32bit address.
It is not because you are not aware of any existing platforms with RAM
or device IO above the 4GB mark that they don't exist.
For example, some LPAE systems have all their RAM located above the 4G
physical address mark. A simple (potentially non DMA capable) alias
exists in the low 32-bit address space to allow the system to boot and
switch to the real physical RAM addresses once the MMU is turned on.
Some of that RAM is still qualified as "low mem" i.e. the portion of RAM
that the kernel keeps permanently mapped in the 32-bit virtual space
even if all of it is above the 4G mark in physical space.
Nicolas
^ permalink raw reply
* [GIT PULL] Renesas ARM-based SoC for v3.9 #2
From: Olof Johansson @ 2013-02-01 3:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359613442-26038-1-git-send-email-horms+renesas@verge.net.au>
On Thu, Jan 31, 2013 at 03:23:53PM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> The following changes since commit 42dd581bc4dba82e8756bb881fa974742250b4c6:
>
> ARM: shmobile: Include sh73a0 DTSI in kzm9g (2013-01-25 09:26:33 +0900)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-boards2-for-v3.9
Pulled. And thanks for using a tag!
-Olof
^ permalink raw reply
* [GIT PULL] Renesas ARM-based SoC for v3.9 #2
From: Olof Johansson @ 2013-02-01 3:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359613569-26981-1-git-send-email-horms+renesas@verge.net.au>
On Thu, Jan 31, 2013 at 03:26:05PM +0900, Simon Horman wrote:
> Hi Olof, Hi Arnd,
>
> The following changes since commit ff8de98d50e551057978ea90d09255c528fde1ac:
>
> ARM: shmobile: r8a7779: scif .irqs used SCIx_IRQ_MUXED() (2013-01-25 12:43:50 +0900)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-soc2-for-v3.9
>
Pulled.
-Olof
^ permalink raw reply
* [PATCH v4 07/13] ARM: LPAE: define ARCH_LOW_ADDRESS_LIMIT for bootmem
From: Nicolas Pitre @ 2013-02-01 3:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359669512-31276-8-git-send-email-cyril@ti.com>
On Thu, 31 Jan 2013, Cyril Chemparathy wrote:
> This patch adds an architecture defined override for ARCH_LOW_ADDRESS_LIMIT.
> On PAE systems, the absence of this override causes bootmem to incorrectly
> limit itself to 32-bit addressable physical memory.
>
> Signed-off-by: Cyril Chemparathy <cyril@ti.com>
> Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/include/asm/memory.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 73cf03a..8825abb 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -275,6 +275,8 @@ static inline __deprecated void *bus_to_virt(unsigned long x)
> #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
> #define virt_addr_valid(kaddr) ((unsigned long)(kaddr) >= PAGE_OFFSET && (unsigned long)(kaddr) < (unsigned long)high_memory)
>
> +#define ARCH_LOW_ADDRESS_LIMIT PHYS_MASK
> +
> #endif
>
> #include <asm-generic/memory_model.h>
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCHv2 for soc 1/4] arm: socfpga: Add new device tree source for actual socfpga HW
From: Olof Johansson @ 2013-02-01 3:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359651943-21752-2-git-send-email-dinguyen@altera.com>
On Thu, Jan 31, 2013 at 11:05:40AM -0600, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
>
> Up to this point, support for socfpga has only been on a virtual
> platform. Now that actual hardware is available, we add the appropriate
> device tree source files.
>
> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> Tested-by: Pavel Machek <pavel@denx.de>
> Reviewed-by: Pavel Machek <pavel@denx.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
Are you planning on sending us a merge request, or do you want us to apply this
to a branch in arm-soc for you?
(Note comment below though)
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dts b/arch/arm/boot/dts/socfpga_cyclone5.dts
> index ab7e4a9..7ad3cc6 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5.dts
> @@ -20,7 +20,7 @@
>
> / {
> model = "Altera SOCFPGA Cyclone V";
> - compatible = "altr,socfpga-cyclone5";
> + compatible = "altr,socfpga-cyclone5", "altr,socfpga";
>
> chosen {
> bootargs = "console=ttyS0,57600";
[...]
> diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
> new file mode 100644
> index 0000000..a0c6c65
> --- /dev/null
> +++ b/arch/arm/boot/dts/socfpga_vt.dts
[...]
> +
> +/ {
> + model = "Altera SOCFPGA VT";
> + compatible = "altr,socfpga-vt", "altr,socfpga";
> +
> + chosen {
> + bootargs = "console=ttyS0,57600";
> + };
> +
[...]
> diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
> index 6732924..198f491 100644
> --- a/arch/arm/mach-socfpga/socfpga.c
> +++ b/arch/arm/mach-socfpga/socfpga.c
> @@ -99,6 +99,7 @@ static void __init socfpga_cyclone5_init(void)
> static const char *altera_dt_match[] = {
> "altr,socfpga",
> "altr,socfpga-cyclone5",
> + "altr,socfpga-vt",
> NULL
> };
Since you have altr,socfpga in the compatible for the new board, you don't need
to add an explicit check for the more specific one here. Same for cyclone5, you
should even be able to remove that.
-Olof
^ permalink raw reply
* [PATCHv2 for soc 3/4] arm: Add v7_invalidate_l1 to cache-v7.S
From: Olof Johansson @ 2013-02-01 3:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359651943-21752-4-git-send-email-dinguyen@altera.com>
Hi,
On Thu, Jan 31, 2013 at 11:05:42AM -0600, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
>
> mach-socfpga is another platform that needs to use
> v7_invalidate_l1 to bringup additional cores. There was a comment that
> the ideal place for v7_invalidate_l1 should be in arm/mm/cache-v7.S
>
> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
> Tested-by: Pavel Machek <pavel@denx.de>
> Reviewed-by: Pavel Machek <pavel@denx.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
This should be merged through Russell's tree. Please feed it to his patch
tracker.
-Olof
^ permalink raw reply
* [PATCH] cpufreq: exynos: Broadcast frequency change notifications for all cores
From: Viresh Kumar @ 2013-02-01 3:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpo=_cR7dk_V2+6bQwUMk-raa3ENAJqBCSe_mYfS+Ur8PnA@mail.gmail.com>
On 31 January 2013 21:42, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 31 January 2013 21:37, Tomasz Figa <t.figa@samsung.com> wrote:
>> Hmm. Now as I think of it, there might be another confusing aspect:
>>
>> Could you explain what "sw coordination" and "any coordination" mean?
>> I mean specifically cpufreq_policy.cpus and cpufreq_policy.related_cpus
>> masks.
>
> Check this out:
>
> https://lkml.org/lkml/2013/1/30/587
You would really like to look and ack this one too:
https://lkml.org/lkml/2013/1/30/592
^ permalink raw reply
* [PATCH v4 09/13] ARM: LPAE: accomodate >32-bit addresses for page table base
From: Nicolas Pitre @ 2013-02-01 3:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359669512-31276-10-git-send-email-cyril@ti.com>
On Thu, 31 Jan 2013, Cyril Chemparathy wrote:
> This patch redefines the early boot time use of the R4 register to steal a few
> low order bits (ARCH_PGD_SHIFT bits) on LPAE systems. This allows for up to
> 38-bit physical addresses.
>
> Signed-off-by: Cyril Chemparathy <cyril@ti.com>
> Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/include/asm/memory.h | 16 ++++++++++++++++
> arch/arm/kernel/head.S | 10 ++++------
> arch/arm/kernel/smp.c | 11 +++++++++--
> arch/arm/mm/proc-v7-3level.S | 8 ++++++++
> 4 files changed, 37 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 8825abb..f3a7f76 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -18,6 +18,8 @@
> #include <linux/types.h>
> #include <linux/sizes.h>
>
> +#include <asm/cache.h>
> +
> #ifdef CONFIG_NEED_MACH_MEMORY_H
> #include <mach/memory.h>
> #endif
> @@ -141,6 +143,20 @@
> #define page_to_phys(page) (__pfn_to_phys(page_to_pfn(page)))
> #define phys_to_page(phys) (pfn_to_page(__phys_to_pfn(phys)))
>
> +/*
> + * Minimum guaranted alignment in pgd_alloc(). The page table pointers passed
> + * around in head.S and proc-*.S are shifted by this amount, in order to
> + * leave spare high bits for systems with physical address extension. This
> + * does not fully accomodate the 40-bit addressing capability of ARM LPAE, but
> + * gives us about 38-bits or so.
> + */
> +#ifdef CONFIG_ARM_LPAE
> +#define ARCH_PGD_SHIFT L1_CACHE_SHIFT
> +#else
> +#define ARCH_PGD_SHIFT 0
> +#endif
> +#define ARCH_PGD_MASK ((1 << ARCH_PGD_SHIFT) - 1)
> +
> #ifndef __ASSEMBLY__
>
> /*
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 4eee351..916af3e 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -156,7 +156,7 @@ ENDPROC(stext)
> *
> * Returns:
> * r0, r3, r5-r7 corrupted
> - * r4 = physical page table address
> + * r4 = page table (see ARCH_PGD_SHIFT in asm/memory.h)
> */
> __create_page_tables:
> pgtbl r4, r8 @ page table address
> @@ -310,6 +310,7 @@ __create_page_tables:
> #endif
> #ifdef CONFIG_ARM_LPAE
> sub r4, r4, #0x1000 @ point to the PGD table
> + mov r4, r4, lsr #ARCH_PGD_SHIFT
> #endif
> mov pc, lr
> ENDPROC(__create_page_tables)
> @@ -387,7 +388,7 @@ __secondary_data:
> * r0 = cp#15 control register
> * r1 = machine ID
> * r2 = atags or dtb pointer
> - * r4 = page table pointer
> + * r4 = page table (see ARCH_PGD_SHIFT in asm/memory.h)
> * r9 = processor ID
> * r13 = *virtual* address to jump to upon completion
> */
> @@ -406,10 +407,7 @@ __enable_mmu:
> #ifdef CONFIG_CPU_ICACHE_DISABLE
> bic r0, r0, #CR_I
> #endif
> -#ifdef CONFIG_ARM_LPAE
> - mov r5, #0
> - mcrr p15, 0, r4, r5, c2 @ load TTBR0
> -#else
> +#ifndef CONFIG_ARM_LPAE
> mov r5, #(domain_val(DOMAIN_USER, DOMAIN_MANAGER) | \
> domain_val(DOMAIN_KERNEL, DOMAIN_MANAGER) | \
> domain_val(DOMAIN_TABLE, DOMAIN_MANAGER) | \
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 84f4cbf..042e12d 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -78,6 +78,13 @@ void __init smp_set_ops(struct smp_operations *ops)
> smp_ops = *ops;
> };
>
> +static unsigned long get_arch_pgd(pgd_t *pgd)
> +{
> + phys_addr_t pgdir = virt_to_phys(pgd);
> + BUG_ON(pgdir & ARCH_PGD_MASK);
> + return pgdir >> ARCH_PGD_SHIFT;
> +}
> +
> int __cpuinit __cpu_up(unsigned int cpu, struct task_struct *idle)
> {
> int ret;
> @@ -87,8 +94,8 @@ int __cpuinit __cpu_up(unsigned int cpu, struct task_struct *idle)
> * its stack and the page tables.
> */
> secondary_data.stack = task_stack_page(idle) + THREAD_START_SP;
> - secondary_data.pgdir = virt_to_phys(idmap_pgd);
> - secondary_data.swapper_pg_dir = virt_to_phys(swapper_pg_dir);
> + secondary_data.pgdir = get_arch_pgd(idmap_pgd);
> + secondary_data.swapper_pg_dir = get_arch_pgd(swapper_pg_dir);
> __cpuc_flush_dcache_area(&secondary_data, sizeof(secondary_data));
> outer_clean_range(__pa(&secondary_data), __pa(&secondary_data + 1));
>
> diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
> index e6576f5..c02c1cc 100644
> --- a/arch/arm/mm/proc-v7-3level.S
> +++ b/arch/arm/mm/proc-v7-3level.S
> @@ -113,6 +113,7 @@ ENDPROC(cpu_v7_set_pte_ext)
> */
> .macro v7_ttb_setup, zero, ttbr0, ttbr1, tmp
> ldr \tmp, =swapper_pg_dir @ swapper_pg_dir virtual address
> + mov \tmp, \tmp, lsr #ARCH_PGD_SHIFT
> cmp \ttbr1, \tmp @ PHYS_OFFSET > PAGE_OFFSET?
> mrc p15, 0, \tmp, c2, c0, 2 @ TTB control register
> orr \tmp, \tmp, #TTB_EAE
> @@ -127,8 +128,15 @@ ENDPROC(cpu_v7_set_pte_ext)
> */
> orrls \tmp, \tmp, #TTBR1_SIZE @ TTBCR.T1SZ
> mcr p15, 0, \tmp, c2, c0, 2 @ TTBCR
> + mov \tmp, \ttbr1, lsr #(32 - ARCH_PGD_SHIFT) @ upper bits
> + mov \ttbr1, \ttbr1, lsl #ARCH_PGD_SHIFT @ lower bits
> addls \ttbr1, \ttbr1, #TTBR1_OFFSET
> mcrr p15, 1, \ttbr1, \zero, c2 @ load TTBR1
> + mov \tmp, \ttbr0, lsr #(32 - ARCH_PGD_SHIFT) @ upper bits
> + mov \ttbr0, \ttbr0, lsl #ARCH_PGD_SHIFT @ lower bits
> + mcrr p15, 0, \ttbr0, \zero, c2 @ load TTBR0
> + mcrr p15, 1, \ttbr1, \zero, c2 @ load TTBR1
> + mcrr p15, 0, \ttbr0, \zero, c2 @ load TTBR0
> .endm
>
> __CPUINIT
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCHv2 for soc 4/4] arm: socfpga: Add SMP support for actual socfpga harware
From: Olof Johansson @ 2013-02-01 3:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359651943-21752-5-git-send-email-dinguyen@altera.com>
Hi,
On Thu, Jan 31, 2013 at 11:05:43AM -0600, dinguyen at altera.com wrote:
> From: Dinh Nguyen <dinguyen@altera.com>
>
> Because the CPU1 start address is different for socfpga-vt and
> socfpga-cyclone5, we add code to use the correct CPU1 start addr.
>
> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Pavel Machek <pavel@denx.de>
> ---
> .../bindings/arm/altera/socfpga-system.txt | 2 ++
> arch/arm/boot/dts/socfpga_cyclone5.dts | 4 ++++
> arch/arm/boot/dts/socfpga_vt.dts | 4 ++++
> arch/arm/mach-socfpga/core.h | 4 +++-
> arch/arm/mach-socfpga/headsmp.S | 16 ++++++++++++----
> arch/arm/mach-socfpga/platsmp.c | 3 ++-
> arch/arm/mach-socfpga/socfpga.c | 8 ++++++++
> 7 files changed, 35 insertions(+), 6 deletions(-)
> @@ -72,6 +73,13 @@ void __init socfpga_sysmgr_init(void)
> struct device_node *np;
>
> np = of_find_compatible_node(NULL, NULL, "altr,sys-mgr");
> +
> + if (of_property_read_u32(np, "cpu1-start-addr",
> + (u32 *) &cpu1start_addr)) {
> + early_printk("Need cpu1-start-addr in device tree.\n");
> + panic("Need cpu1-start-addr in device tree.\n");
> + }
> +
> sys_manager_base_addr = of_iomap(np, 0);
Wouldn't it be easier to diagnose this failure if you just printed the error
and continued booting without the second CPU? An early panic is usually really
hard to debug since you might not get early console without extra work.
-Olof
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-02-01 3:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510B268E.2040104@wwwdotorg.org>
On Thu, Jan 31, 2013 at 07:21:02PM -0700, Stephen Warren wrote:
> I originally thought the issue was that the windows were between CPU
> physical address space and the PCIe host controller itself. But in fact,
> the windows are between PCIe bus 0 and the root ports, so they're
> the
Donno what exactly is inside tegra, but on Marvell the docs describe
an an internal bus cross bar/whatever and each PCI-E link gets a port
on that structure. There is no such physical thing as a 'PCI bus 0',
and they didn't arrange the hardware in a way that makes it easy for
the host driver to create one like tegra did :(
> equivalent of the standard PCIe root port (or PCIe/PCIe bridge) BAR
> registers. And related, these BAR/window registers are usually part of
> each PCIe root port itself, and hence there's a whole number dedicated
> to each root port, but on Marvell there's a *global* pool of these
> BARs/windows instead.
Right, that is all following the PCI-E spec, and is reasonable and
sane. What Marvell did is take an *end port core* and jam'd it on
their internal bus without adjusting things to follow the PCI-E spec
regarding config space and what not.
> > That more or less means you need to know what is going to be on the
> > other side of every link when you write the DT.
>
> So, the dynamic programming of the windows on Marvell HW is the exact
> logical equivalent of programming a standard PCIe root port's BAR
> registers. It makes perfect sense that should be dynamic. Presumably
> this is something you can make work inside your emulated PCIe/PCIe
> bridge module, simply by capturing writes to the BAR registers, and
> translating them into writes to the Marvell window registers.
Yes, that is exactly the idea.
> Now, I do have one follow-on question: You said you don't have 30
> windows, but how many do you have free after allocating windows to any
> other peripherals that need them, relative to (3 *
> number-of-root-ports-in-the-SoC)? (3 being IO+Mem+PrefetchableMem.)
Thomas will have to answer this, it varies depending on the SOC, and
what other on chip peripherals are in use. For instance Kirkwood has
the same design but there are plenty of windows for the two PCI-E
links.
Still how would you even connect a limited number of regions on a link
by link basis to the common PCI code?
> The thing here is that when the PCIe core writes to a root port BAR
> window to configure/enable it the first time, you'll need to capture
> that transaction and dynamically allocate a window and program it in a
> way equivalent to what the BAR register write would have achieved on
> standard HW. Later, the window might need resizing, or even to be
> completely disabled, if the PCIe core were to change the standard
> BAR
Right. This is pretty straightforward except for the need to hook the
alignment fixup..
> register. Dynamically allocating a window when the BAR is written seems
> a little heavy-weight.
I think what Thomas had here was pretty small, and the windows need to
be shared with other on chip periphals beyond PCI-E..
> needed, e.g. if there's no IO space behind a root port, you could get
> away with two windows per root port, and hence be able to run 3 root
> ports rather than just 2?
Right, this is the main point. If you plug in 3 devices and they all
only use MMIO regions then you only need to grab 3 windows. The kernel
disables the unused windows on the bridge so it is easy to tell when
they are disused.
> Still, I supose doing it dynamically in the driver does end up being a
> lot less to think about for someone creating the DT for a new board.
Agreed, these restrictions are all so HW specific, subtle and have
nothing to do with the PCI-E spec. Codifying them once in the driver
seems like the way to keep this crazyness out of the PCI core and away
from users of the SOC.
> Having to translate standard root port BAR register writes to Marvell
> window register allocation/writes would imply that the emulated root
> port code has to be very closely tied into the Marvell PCIe driver, and
> not something that could be at all generic in the most part.
Agreed.. At the very least generic code would need call back
functions to the driver... It has a fair bit to do for Marvell:
- Translate MMIO, prefetch and IO ranges to mbus windows
- Keep track of the secondary/subordinate bus numbers and fiddle
with other hardware registers to set those up
- Copy the link state/control regsiters from the end port config
space into the bridge express root port capability
- Probably ditto for AER as well..
Probably simpler just to make one for marvell then mess excessively
with callbacks..
Cheers,
Jason
^ permalink raw reply
* [PATCH v4 13/13] ARM: fix type of PHYS_PFN_OFFSET to unsigned long
From: Nicolas Pitre @ 2013-02-01 3:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359669512-31276-14-git-send-email-cyril@ti.com>
On Thu, 31 Jan 2013, Cyril Chemparathy wrote:
> On LPAE machines, PHYS_OFFSET evaluates to a phys_addr_t and this type is
> inherited by the PHYS_PFN_OFFSET definition as well. Consequently, the kernel
> build emits warnings of the form:
>
> init/main.c: In function 'start_kernel':
> init/main.c:588:7: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'phys_addr_t' [-Wformat]
>
> This patch fixes this warning by pinning down the PFN type to unsigned long.
>
> Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/include/asm/memory.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index f3a7f76..32e9e5a 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -223,7 +223,7 @@ static inline unsigned long __phys_to_virt(unsigned long x)
> * direct-mapped view. We assume this is the first page
> * of RAM in the mem_map as well.
> */
> -#define PHYS_PFN_OFFSET (PHYS_OFFSET >> PAGE_SHIFT)
> +#define PHYS_PFN_OFFSET ((unsigned long)(PHYS_OFFSET >> PAGE_SHIFT))
>
> /*
> * These are *only* valid on the kernel direct mapped RAM memory.
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] ARM: imx: fix imx31-dt.c time-related warning
From: Olof Johansson @ 2013-02-01 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359518177-21245-1-git-send-email-swarren@wwwdotorg.org>
On Tue, Jan 29, 2013 at 08:56:17PM -0700, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Commit 6bb27d7 "ARM: delete struct sys_timer" caused the following:
>
> arch/arm/mach-imx/imx31-dt.c:56:2: warning: initialization from incompatible pointer type [enabled by default]
> arch/arm/mach-imx/imx31-dt.c:56:2: warning: (near initialization for ?__mach_desc_IMX31_DT.init_time?) [enabled by default]
>
> This is because mx31_clocks_init_dt() returns int, whereas the .init_time
> field prototype expects a function returning void. Implement a wrapper so
> that the prototypes match.
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> This patch is based on arm-soc's timer/cleanup branch, which contains
> the commit mentioned above.
Applied.
-Olof
^ 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