* [PATCH RESEND] ARM: EXYNOS: dts: Set up power domain for MFC and G-scaler
From: Kukjin Kim @ 2013-01-29 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359453320-14911-1-git-send-email-prasanna.ps@samsung.com>
Prasanna Kumar wrote:
>
> This patch adds device tree nodes for MFC and G-scaler power
> domains of exynos5250.It binds these power-domain nodes to repsective
> device tree nodes
>
> It also adds support to enable PM generic domains for exynos5250.
>
> Signed-off-by: Prasanna Kumar <prasanna.ps@samsung.com>
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 15 +++++++++++++++
> arch/arm/mach-exynos/Kconfig | 1 +
> 2 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 30485de..6d0e87c 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -85,6 +85,7 @@
> compatible = "samsung,mfc-v6";
> reg = <0x11000000 0x10000>;
> interrupts = <0 96 0>;
> + samsung,power-domain = <&pd_mfc>;
> };
>
> rtc {
> @@ -554,28 +555,42 @@
> };
> };
>
> + pd_gsc: gsc-power-domain at 0x10044000 {
> + compatible = "samsung,exynos4210-pd";
> + reg = <0x10044000 0x20>;
> + };
> +
> + pd_mfc: mfc-power-domain at 0x10044040 {
> + compatible = "samsung,exynos4210-pd";
> + reg = <0x10044040 0x20>;
> + };
> +
Please put the above nodes by order of address.
> gsc_0: gsc at 0x13e00000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e00000 0x1000>;
> interrupts = <0 85 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> gsc_1: gsc at 0x13e10000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e10000 0x1000>;
> interrupts = <0 86 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> gsc_2: gsc at 0x13e20000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e20000 0x1000>;
> interrupts = <0 87 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> gsc_3: gsc at 0x13e30000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e30000 0x1000>;
> interrupts = <0 88 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> hdmi {
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-
> exynos/Kconfig
> index e103c29..96f4a9f 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -61,6 +61,7 @@ config SOC_EXYNOS5250
> bool "SAMSUNG EXYNOS5250"
> default y
> depends on ARCH_EXYNOS5
> + select PM_GENERIC_DOMAINS if PM
> select S5P_PM if PM
> select S5P_SLEEP if PM
> select S5P_DEV_MFC
> --
> 1.7.5.4
^ permalink raw reply
* [PATCH v2 1/3] arm: mvebu: Add support for USB host controllers in Armada 370/XP
From: Ezequiel Garcia @ 2013-01-29 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123174025.GV1758@titan.lakedaemon.net>
Hi Jason,
On Wed, Jan 23, 2013 at 2:40 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> On Wed, Jan 23, 2013 at 02:06:12PM -0300, Ezequiel Garcia wrote:
>> Jason,
>>
>> On Wed, Jan 23, 2013 at 12:26 PM, Ezequiel Garcia <ezequiel.garcia@free-electrons.com> wrote:
>> > The Armada 370 and Armada XP SoC has an Orion EHCI USB controller.
>> > This patch adds support for this controller in Armada 370
>> > and Armada XP SoC common device tree files.
>> >
>> > Cc: Lior Amsalem <alior@marvell.com>
>> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> > Tested-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
>> > Tested-by: Florian Fainelli <florian@openwrt.org>
>> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>> > ---
>> > Changes from v1:
>> > * Remove uneeded USB_ARCH_HAS_EHCI selection as noted by Florian.
>> >
>> > arch/arm/boot/dts/armada-370-xp.dtsi | 15 +++++++++++++++
>> > arch/arm/boot/dts/armada-370.dtsi | 9 +++++++++
>> > arch/arm/boot/dts/armada-xp.dtsi | 17 +++++++++++++++++
>> > 3 files changed, 41 insertions(+), 0 deletions(-)
>>
>> Do you think we're still in time to get this series into v3.9 (given
>> we decide soon on the OpenBlocks issue)?
>
> That shouldn't be a problem.
>
Do you think we can take this series for v3.9 as it is?
I have no problems making any changes if they are needed
but I can't move forward with the OpenBlocks issue since
I don't have access to the hardware.
I think we can sanely merge this as it is, since it has been tested in
every platform.
If there's anything to change we can do it later, when I have more
information about the
OpenBlocks hardware.
Thanks,
--
Ezequiel
^ permalink raw reply
* [PATCH] arm: zynq: Add missing irqchip.h to common.c
From: Olof Johansson @ 2013-01-29 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359376250-18841-1-git-send-email-michal.simek@xilinx.com>
On Mon, Jan 28, 2013 at 01:30:50PM +0100, Michal Simek wrote:
> The patch: "ARM: use common irqchip_init for GIC init"
> (sha1: 0529e315bbda5d502c93df2cfafba9bb337fbdf4)
> should also add linux/irqchip.h header.
>
> Error message:
> arch/arm/mach-zynq/common.c:99:14: error: 'irqchip_init'
> undeclared here (not in a function)
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Applied.
-Olof
^ permalink raw reply
* [PATCH v2 1/3] arm: mvebu: Add support for USB host controllers in Armada 370/XP
From: Jason Cooper @ 2013-01-29 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALF0-+Vg1WZA3m9G7mLU92BBuDpGLG-pmMM=XHtGm2UwnXXLUw@mail.gmail.com>
On Tue, Jan 29, 2013 at 03:56:20PM -0300, Ezequiel Garcia wrote:
> Hi Jason,
>
> On Wed, Jan 23, 2013 at 2:40 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > On Wed, Jan 23, 2013 at 02:06:12PM -0300, Ezequiel Garcia wrote:
> >> Jason,
> >>
> >> On Wed, Jan 23, 2013 at 12:26 PM, Ezequiel Garcia <ezequiel.garcia@free-electrons.com> wrote:
> >> > The Armada 370 and Armada XP SoC has an Orion EHCI USB controller.
> >> > This patch adds support for this controller in Armada 370
> >> > and Armada XP SoC common device tree files.
> >> >
> >> > Cc: Lior Amsalem <alior@marvell.com>
> >> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >> > Tested-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> >> > Tested-by: Florian Fainelli <florian@openwrt.org>
> >> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >> > Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> >> > ---
> >> > Changes from v1:
> >> > * Remove uneeded USB_ARCH_HAS_EHCI selection as noted by Florian.
> >> >
> >> > arch/arm/boot/dts/armada-370-xp.dtsi | 15 +++++++++++++++
> >> > arch/arm/boot/dts/armada-370.dtsi | 9 +++++++++
> >> > arch/arm/boot/dts/armada-xp.dtsi | 17 +++++++++++++++++
> >> > 3 files changed, 41 insertions(+), 0 deletions(-)
> >>
> >> Do you think we're still in time to get this series into v3.9 (given
> >> we decide soon on the OpenBlocks issue)?
> >
> > That shouldn't be a problem.
> >
>
> Do you think we can take this series for v3.9 as it is?
I'm working though a few other issues first. I'll take a closer look
when I get up to this series.
> I have no problems making any changes if they are needed
> but I can't move forward with the OpenBlocks issue since
> I don't have access to the hardware.
understood.
> I think we can sanely merge this as it is, since it has been tested in
> every platform.
> If there's anything to change we can do it later, when I have more
> information about the
> OpenBlocks hardware.
As long that that will be clean, there shouldn't be a problem.
thx,
Jason.
^ permalink raw reply
* [GIT PULL] CSR SiRFmarco SoC infrastructures for 3.9
From: Olof Johansson @ 2013-01-29 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129165110.GA16188@quad.lixom.net>
On Tue, Jan 29, 2013 at 8:51 AM, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Jan 28, 2013 at 06:08:27PM +0800, Barry Song wrote:
>> 2013/1/28 Olof Johansson <olof@lixom.net>:
>> > On Thu, Jan 24, 2013 at 11:21:02AM +0800, Barry Song wrote:
>> >> Hi Olof, Arnd,
>> >>
>> >> pls pull the following changes for CSR SiRFmarco SoC. it has been
>> >> rebased againest arm-soc timer/cleanup tree.
>> >>
>> >> since commit 90cf214d6a549bf482e3c5751ee256cc885b96ea:
>> >>
>> >> ARM: at91: fix board-rm9200-dt after sys_timer conversion
>> >> (2013-01-14 10:14:04 -0800)
>> >>
>> >> are available in the git repository at:
>> >> git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git
>> >> marco-timer-cleanup-rebase
>> >
>> > Pulled in as prima2/marco, included in next/soc. Thanks!
>>
>> Olof, thanks.
>>
>> >
>> > I noticed that there is no defconfig for any mach-prima2 platforms. Feel
>> > free to submit one so we get build coverage of the platform.
>>
>> there have been. arch/arm/configs/prima2_defconfig
>
> Ah, it enables ARCH_SIRF, I was searching for ARCH_PRIMA2 or ARCH_MARCO. Good.
..and it's broken due to interaction with the gic-vic move. :(
Barry, can you please follow up with a patch to do the corresponding
changes for prima?
Thanks,
-Olof
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Bjorn Helgaas @ 2013-01-29 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129184157.GA29274@obsidianresearch.com>
On Tue, Jan 29, 2013 at 11:41 AM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Tue, Jan 29, 2013 at 10:47:09AM -0700, Bjorn Helgaas wrote:
>
>> As I understand it, the DT is a description of the hardware, so in
>> that sense, the DT can't set aside physical address space. It can
>> describe what the hardware does with the address space, and I assume
>> that's what you mean. Maybe the hardware isn't configurable, e.g., it
>> is hard-wired to route certain address ranges to PCIe?
>
> The DT is largely a description of the hardware, but when it comes to
> addresses, particularly HW programmable addresess, there is an general
> expectation that the driver/bootloader will program HW address
> decoders to either match the addresses given in the DT, or to new
> values guided by the DT addresses.
>
> In a real sense that means the DT also describes the physical address
> map the kernel should use.
>
> In the PCI-E case the DT PCI-E HW description includes physical
> address ranges to use for the MMIO/IO/PREFETCH PCI-E interface windows
> and the driver is expected to program the internal HW address decoders
> based on those address ranges.
>
> The catch is that the hardware decoders are on a link-by-link basis,
> not on a root-complex basis, so the programming can only take place
> once the Linux kernel has done PCI resource assignment.
>
> 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.
In your example, it sounds like the 128M should be treated as the host
bridge aperture. Is there any reason not to do that? It sounds like
there's no place you can actually program that 128M region into the
hardware, and you would just program pieces of that region as root
port windows. But that should be OK from the core's perspective.
^ permalink raw reply
* [PATCH v4 1/1 net-next] net: fec: add napi support to improve proformance
From: David Miller @ 2013-01-29 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359433903-15605-1-git-send-email-Frank.Li@freescale.com>
From: Frank Li <Frank.Li@freescale.com>
Date: Tue, 29 Jan 2013 12:31:42 +0800
> Add napi support
...
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
> Signed-off-by: Fugang Duan <B38611@freescale.com>
Applied, thanks.
Note that it is recommended to also to TX reclaim processing
in the NAPI handler as well, in fact it's best to make the hardware
interrupt handler do nothing other than trigger NAPI and then
move everything that was in your hardware interrupt handler into
NAPI poll instead.
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-01-29 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo5K8yKqjzQ6s+imb3d5wLSkhvWp-d=pPv9CZk+o67kyaQ@mail.gmail.com>
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.
> In your example, it sounds like the 128M should be treated as the host
> bridge aperture. Is there any reason not to do that? It sounds like
> there's no place you can actually program that 128M region into the
> hardware, and you would just program pieces of that region as root
> port windows. But that should be OK from the core's perspective.
AFAIK this is already what Thomas's driver is doing..
Regards,
Jason
^ permalink raw reply
* [PATCH v3 07/15] ARM: vexpress: Select the correct SMP operations at run-time
From: Nicolas Pitre @ 2013-01-29 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359474220.3731.45.camel@linaro1.home>
On Tue, 29 Jan 2013, Jon Medhurst (Tixy) wrote:
> On Tue, 2013-01-29 at 02:51 -0500, Nicolas Pitre wrote:
> > From: Jon Medhurst <tixy@linaro.org>
> >
> > Signed-off-by: Jon Medhurst <tixy@linaro.org>
> > ---
>
> Should this patch be split into two. One to introduce the new smp_init
> hook into the generic ARM kernel code, and one to make vexpress use it?
> With, descriptions something like:
>
> -----------------------------------------------------------------------
> ARM: kernel: Enable selection of SMP operations at boot time
>
> Add a new 'smp_init' hook to machine_desc so platforms can specify a
> function to be used to setup smp ops instead of having a statically
> defined value.
> -----------------------------------------------------------------------
> ARM: vexpress: Select multi-cluster SMP operation if required
> -----------------------------------------------------------------------
That certainly makes sense. Are you willing to split your patch as such
and send me the result?
Nicolas
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Bjorn Helgaas @ 2013-01-29 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129191853.GB29274@obsidianresearch.com>
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.
>> In your example, it sounds like the 128M should be treated as the host
>> bridge aperture. Is there any reason not to do that? It sounds like
>> there's no place you can actually program that 128M region into the
>> hardware, and you would just program pieces of that region as root
>> port windows. But that should be OK from the core's perspective.
>
> AFAIK this is already what Thomas's driver is doing..
>
> Regards,
> Jason
^ permalink raw reply
* ixp4xx eth broken in 3.7.0/3.8-rc5?
From: Mikael Pettersson @ 2013-01-29 19:42 UTC (permalink / raw)
To: linux-arm-kernel
When I try to update my ixp4xx machine to a 3.8-rc5 kernel it boots
Ok but the network (CONFIG_IXP4XX_ETH=y) fails to come up, with the
following in the kernel log:
net eth0: coherent DMA mask is unset
With a 3.7.0 kernel the situation is similar, except that the "net
eth0: coherent DMA mask is unset" message repeats itself endlessly
and I can't even get in on the serial console.
With the 3.6.0 kernel everything works perfectly.
I've (quickly) reviewed the ixp4xx changes from 3.6.0 to 3.7.0, but
nothing stands out.
Any ideas?
/Mikael
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Simon Baatz @ 2013-01-29 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129004824.GB7717@titan.lakedaemon.net>
On Mon, Jan 28, 2013 at 07:48:24PM -0500, Jason Cooper wrote:
> On Mon, Jan 28, 2013 at 11:31:48PM +0100, Simon Baatz wrote:
> > Hi Jason,
> >
> > On Sun, Jan 27, 2013 at 10:24:31AM -0500, Jason Cooper wrote:
> > > On Sun, Jan 27, 2013 at 03:53:53PM +0100, Sebastian Hesselbarth wrote:
> > > > On 01/27/2013 03:46 PM, Jason Cooper wrote:
> > > > >>I _cannot_ confirm that gbe is loosing its MAC address on Dove. I will
> > > > >>post a follow-up patch to Jason's cleanup patches that will also
> > > > >>grab a clock for smi. With that patch insmod'ing/rmmod'ing mv643xx_eth
> > > > >>does work just fine here on Dove.
> > > > >
> > > > >I believe Simon's issue is that the mv643xx_eth driver is not loaded at
> > > > >boot, it's clocks get gated, then when he loads the driver, there is no
> > > > >mac address. Is that correct Simon? I don't think unloading the driver
> > > > >after boot will trigger this regression.
> > > >
> > > > Loading and unloading the driver module hangs because of the missing
> > > > clk_prepeare_enable in shared driver part. This should be fixed by the
> > > > patch I sent you.
> > > >
> > > > Dove and Kirkwood have the same gbe internally and I can boot into Dove
> > > > without mv643xx_eth, load, unload, reload the module and it always finds
> > > > its MAC address.
> > > >
> > > > I just want Simon to confirm that Kirkwood's gbe is really loosing the
> > > > contents of its MAC address registers during gated clocks, which is from
> > > > a HW point of view very unlikely.
> > >
> > > Ok, I just wanted to make sure we understood his problem correctly, and
> > > if possible, reproduce it.
> > >
> > > Simon, can you give us some steps to reproduce this on our side so we
> > > can see exactly what's happening?
> >
> > Nothing special here. My config originally based on a Debian config
> > for a Kirkwood kernel. Thus, amongst other drivers, mv643xx_eth is
> > build as a module and is loaded from an initrd.
> > Because all relevant drivers are loaded as modules, I need my
> > runit patch to boot at all.
>
> Let's back up. If you config early printk and COMMON_CLK_DEBUG and a
> vanilla v3.8-rc5 with your current config, what happens?
I thought it's clear what happens. "runit" is requested in the dts by
serial, spi, watchdog, nand, i2c. Each of these are either not built
or built as a module in my config, except serial.
of_serial.c does the following in of_platform_serial_setup():
if (of_property_read_u32(np, "clock-frequency", &clk)) {
/* Get clk rate through clk driver if present */
info->clk = clk_get(&ofdev->dev, NULL);
if (IS_ERR(info->clk)) {
dev_warn(&ofdev->dev,
"clk or clock-frequency not defined\n");
return PTR_ERR(info->clk);
}
clk_prepare_enable(info->clk);
clk = clk_get_rate(info->clk);
}
and since "clock-frequency" is still given in the standard DTS for
the IB-NAS 6210, it does not enable the clock.
Thus, no driver uses the clock, it gets disabled and the system locks
up.
The system boots when removing "clock-frequency" from the DTS.
Which lead to two questions:
- Is it safe to remove "clock-frequency" now that we have the clocks
in place?
- The behavior of of_serial.c looks strange to me, is this really the
desired behavior?
For the "runit" clock, this means that any time you hit a
configuration that does not keep the clock enabled, the system will
lockup. (We have gone through this more than once now. Especially,
this hits you hard when you try to support a new board and disable as
much as possible in the config/dts for a start...).
Thus, we should keep it enabled even if it is unused, which is
exactly the purpose of CLK_IGNORE_UNUSED if I understood this
correctly.
> Could you also please try kirkwood_defconfig and tell us if it boots?
It is very easy to get my system to boot with a stock kernel. Just
build one of the drivers I use directly into the kernel and it boots
(up to the point where the gbe driver is loaded if built as a module,
of course).
> > Here are my findings with various patches: ("non-DT" means booting
> > the IBNAS6210 with machine ID 1680 ???Marvell DB-88F6281-BP
> > Development Board???, which works reasonably well)
> >
> > 3.8-rc5 + runit patch:
> >
> > DT: Hangs at boot (when loading mv643xx_eth)
> > non-DT: Boots ok
In the DT case ge0 and ge1 are NULL, and thus, kirkwood_ge0[01]_init()
tries to enable NULL clocks, but not the gbe clocks. -> The clocks
get disabled.
As described in Sebastian's patch (and also found by Andrew some time
ago), this leads to a hanging system when loading the gbe driver.
> > 3.8-rc5 + runit patch + ge00/ge01 patch:
> >
> > DT: Boots ok
> > non-DT: Boots ok
Since the clocks are found now and kept enabled, DT behaves the same
as non-DT.
> >
> > 3.8-rc5 + runit + Sebastians get smi clock patch (modified to use
> > legacy clock names):
> >
> > DT: Boots, but no MAC
> > non-DT: Boots ok
This is the behavior originally found by Andrew. The clock patch
eliminates the lockup, but the hardware forgets its MAC address.
> >
> > 3.8-rc5 + runit + using Sebastians patch + clks not ticking at module
> > load:
> >
> > DT: Boots, but no MAC
> > non-DT: Boots, but no MAC
I think non-DT and DT gated clocks behave differently, since the
non-DT ones also enable/disable the PHY. I explicitly removed the
clk_prepare_enable() from kirkwood_ge0[01]_init() in order to see if
this makes a difference.
(Which reminds me, that we wanted to implement the PHY enabling in
the driver.)
Apparently, it does not make a difference.
- Simon
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Stephen Warren @ 2013-01-29 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129094143.1aad9377@skate>
On 01/29/2013 01:41 AM, Thomas Petazzoni wrote:
> Dear Stephen Warren,
>
> On Mon, 28 Jan 2013 15:21:45 -0700, Stephen Warren wrote:
>
>>> +Mandatory properties:
>>> +- compatible: must be "marvell,armada-370-xp-pcie"
>>> +- status: either "disabled" or "okay"
>>
>> status is a standard DT property; I certainly wouldn't expect its
>> presence to be mandatory (there's a defined default), nor would I expect
>> each device's binding to redefine this property.
>
> Ok.
>
>>> +- marvell,pcie-port: the physical PCIe port number
>>
>> Should the standardized cell-index property be used here instead? Or,
>> perhaps that property is deprecated/discouraged...
>
> The problem is that I need two identifiers, the pcie-port and
> pcie-lane, and it would be strange to have one referenced as
> cell-index, and the other one as marvell,pcie-lane, no?
Yes, using a custom property for half of the information and a standard
property for the other half would be odd.
> Unless of
> course we can put two numbers in the cell-index property, but a quick
> grep in Documentation/devicetree/bindings/ seems to indicate that all
> users of cell-index use it with a single identifier.
>
> Just tell me what to do here, I don't have a strong opinion on this.
It's probably fine as-is then. Although I wasn't sure exactly what
port/lane meant; is there some kind of mux/cross-bar between the PCIe
root ports and the physical lanes/balls/pins on the chip?
>>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>>
>>> +obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
>>> +ccflags-$(CONFIG_PCI_MVEBU) += \
>>> + -I$(srctree)/arch/arm/plat-orion/include \
>>> + -I$(srctree)/arch/arm/mach-mvebu/include
>>
>> That seems a little dangerous w.r.t. multi-platform zImage. Can the
>> required headers be moved out to somewhere more public to avoid this?
>
> Why is this dangerous for multi-platform zImage? For this specific
> driver only, some SoC-specific headers are used. I don't think it
> prevents another PCI driver (such as the Tegra one) from being built
> into the same kernel image, no?
Aren't those ccflags applied to everything that's built by that
Makefile? If they were applied only to one .o file, it'd probably be OK,
but I don't see how that's specified.
I'm not especially bothered with reaching into the mach/plat include
directories especially since you're well aware it needs cleaning up, I
just don't think that Tegra's PCIe driver is going to compile too well
against an Orion/mvebu header if one was to get picked up first.
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Simon Baatz @ 2013-01-29 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128194656.GL1758@titan.lakedaemon.net>
On Mon, Jan 28, 2013 at 02:46:56PM -0500, Jason Cooper wrote:
> Simon,
>
> Can you try this in conjunction with enabling ARM_ATAG_DTB_COMPAT ?
> Does that solve your issue?
I use
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
in my standard configuration already. I don't use the original U-Boot
that came with the device, but a mainline one which supports my box.
- Simon
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Sebastian Hesselbarth @ 2013-01-29 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129194243.GA30831@schnuecks.de>
On 01/29/2013 08:42 PM, Simon Baatz wrote:
> On Mon, Jan 28, 2013 at 07:48:24PM -0500, Jason Cooper wrote:
>> On Mon, Jan 28, 2013 at 11:31:48PM +0100, Simon Baatz wrote:
>>> Nothing special here. My config originally based on a Debian config
>>> for a Kirkwood kernel. Thus, amongst other drivers, mv643xx_eth is
>>> build as a module and is loaded from an initrd.
>>> Because all relevant drivers are loaded as modules, I need my
>>> runit patch to boot at all.
>>
>> Let's back up. If you config early printk and COMMON_CLK_DEBUG and a
>> vanilla v3.8-rc5 with your current config, what happens?
>
> I thought it's clear what happens. "runit" is requested in the dts by
> serial, spi, watchdog, nand, i2c. Each of these are either not built
> or built as a module in my config, except serial.
Simon,
it is clear what happens but just to blindly disable clock gating will
not help here. What you are suffering are several issues not only one.
> of_serial.c does the following in of_platform_serial_setup():
>
> if (of_property_read_u32(np, "clock-frequency",&clk)) {
>
> /* Get clk rate through clk driver if present */
> info->clk = clk_get(&ofdev->dev, NULL);
> if (IS_ERR(info->clk)) {
> dev_warn(&ofdev->dev,
> "clk or clock-frequency not defined\n");
> return PTR_ERR(info->clk);
> }
>
> clk_prepare_enable(info->clk);
> clk = clk_get_rate(info->clk);
> }
>
> and since "clock-frequency" is still given in the standard DTS for
> the IB-NAS 6210, it does not enable the clock.
> Thus, no driver uses the clock, it gets disabled and the system locks
> up.
> The system boots when removing "clock-frequency" from the DTS.
>
> Which lead to two questions:
> - Is it safe to remove "clock-frequency" now that we have the clocks
> in place?
Safe, as long as you replace it with the corresponding clocks=<&..> property.
> - The behavior of of_serial.c looks strange to me, is this really the
> desired behavior?
I guess it is, rely on clock-frequency because a lot of boards still use it.
There was no clocks property in of_serial when we started with kirkwood and
dove. I think we can switch now to clocks property which will also remove
all hard coded occurrences of tclk frequency.
> For the "runit" clock, this means that any time you hit a
> configuration that does not keep the clock enabled, the system will
> lockup. (We have gone through this more than once now. Especially,
> this hits you hard when you try to support a new board and disable as
> much as possible in the config/dts for a start...).
Well, if there is no device/driver using runit it should be safe to disable
it. If there is a driver using it, we need a clocks property for it. And
as you already stated, serial is using it. And you want serial in every
minimal kernel, don't you?
> Thus, we should keep it enabled even if it is unused, which is
> exactly the purpose of CLK_IGNORE_UNUSED if I understood this
> correctly.
True, but only if it is that important that it should _never_ be gated.
As long as it is 'only' used by peripheral devices, it should be safe
to gate it.
>> Could you also please try kirkwood_defconfig and tell us if it boots?
>
> It is very easy to get my system to boot with a stock kernel. Just
> build one of the drivers I use directly into the kernel and it boots
> (up to the point where the gbe driver is loaded if built as a module,
> of course).
>
>>> Here are my findings with various patches: ("non-DT" means booting
>>> the IBNAS6210 with machine ID 1680 ???Marvell DB-88F6281-BP
>>> Development Board???, which works reasonably well)
>>>
>>> 3.8-rc5 + runit patch:
>>>
>>> DT: Hangs at boot (when loading mv643xx_eth)
>>> non-DT: Boots ok
>
> In the DT case ge0 and ge1 are NULL, and thus, kirkwood_ge0[01]_init()
> tries to enable NULL clocks, but not the gbe clocks. -> The clocks
> get disabled.
>
> As described in Sebastian's patch (and also found by Andrew some time
> ago), this leads to a hanging system when loading the gbe driver.
If I got all your configs right, this DT case is with serial but no
clocks property? All other runit "users" are _not_ built into the
kernel? Maybe it is just a coincidence that it fails when loading
eth but I guess it hangs because of runit getting gated while serial
accessing it. When you replace serial's clock-frequency with clocks
property to "runit" it shouldn't hang.
(Issue 1: gated runit clock hangs kernel due to serial access)
>>> 3.8-rc5 + runit patch + ge00/ge01 patch:
>>>
>>> DT: Boots ok
>>> non-DT: Boots ok
>
> Since the clocks are found now and kept enabled, DT behaves the same
> as non-DT.
>
>>>
>>> 3.8-rc5 + runit + Sebastians get smi clock patch (modified to use
>>> legacy clock names):
>>>
>>> DT: Boots, but no MAC
>>> non-DT: Boots ok
>
> This is the behavior originally found by Andrew. The clock patch
> eliminates the lockup, but the hardware forgets its MAC address.
>
>>>
>>> 3.8-rc5 + runit + using Sebastians patch + clks not ticking at module
>>> load:
>>>
>>> DT: Boots, but no MAC
>>> non-DT: Boots, but no MAC
Ok, here my patch for smi clock enables gbe clock before accessing gbe
registers.
(Issue 2: gated gbe clock hangs kernel due to smi access)
> I think non-DT and DT gated clocks behave differently, since the
> non-DT ones also enable/disable the PHY. I explicitly removed the
> clk_prepare_enable() from kirkwood_ge0[01]_init() in order to see if
> this makes a difference.
True, DT gated clocks don't disable PHYs (and never will).
> (Which reminds me, that we wanted to implement the PHY enabling in
> the driver.)
>
> Apparently, it does not make a difference.
Leaves Issue 3, gbe forgets about its MAC address when gated or powered
down. That should be done with local-mac-address passed by DT enabled
u-boot or any other (dirty) ATAG hack ;)
Sebastian
^ permalink raw reply
* [RFC PATCH] arm: decompressor: initialize PIC offset base register for uClinux tools
From: Nicolas Pitre @ 2013-01-29 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359480546-7033-1-git-send-email-jonathan.austin@arm.com>
On Tue, 29 Jan 2013, Jonathan Austin wrote:
> Before jumping to (position independent) C-code from the decompressor's
> assembler world we set-up the C environment. This setup currently does not
> set r9, which for arm-none-uclinux-uclibceabi should be the PIC offset base
> register (IE should point to the beginning of the GOT).
>
> Currently, therefore, in order to build working kernels that use the
> decompressor it is necessary to use an arm-linux-gnueabi toolchain, or
> similar. uClinux toolchains cause a Prefetch Abort to occur at the beginning
> of the decompress_kernel function.
>
> This patch allows uClinux toolchains to build bootable zImages by setting r9
> to the beginning of the GOT when __uClinux__ is defined, allowing the
> decompressor's C functions to work correctly.
>
> Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
> ---
>
> One other possibility would be to specify -mno-single-pic-base when building
> the decompressor. This works around the problem, but forces the compiler to
> generate less optimal code.
How "less optimal"? How much bigger/slower is it?
If not significant enough then going with -mno-single-pic-base might be
fine.
> arch/arm/boot/compressed/head.S | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index fe4d9c3..4491e75 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -410,6 +410,10 @@ wont_overwrite:
> * sp = stack pointer
> */
> orrs r1, r0, r5
> +#ifdef __uClinux__
> + mov r9, r11 @ PIC offset base register
> + addne r9, r9, r0 @ Also needs relocating
> +#endif
> beq not_relocated
Please don't insert your code between the orrs and the beq as those two
go logically together.
In fact, the best location for this would probably be between the
wont_overwrite label and the comment that immediately follows it. And
then, those comments that follow until the branch into C code should be
updated accordingly.
Nicolas
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Arnd Bergmann @ 2013-01-29 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129180936.3737e550@skate>
On Tuesday 29 January 2013, Thomas Petazzoni wrote:
> Yes, it is about the emulated PCI-to-PCI bridges. Each
> emulated PCI-to-PCI bridge corresponds to one hardware PCIe interface,
> and I need the I/O base address assigned to each PCIe interface to be
> aligned on a 64 KB boundary. I am not sure to understand why you think
> this is a problem.
>
> Also, what do you mean exactly by making them appear as individual
> domains?
I mean you could make each root port look like a separate host
bridge that is not related to the others, and not have any
emulated PCI-to-PCI bridges at all.
> Remember that the very reason to use emulated PCI-to-PCI bridges is
> that we want to assign a global range of addresses of I/O regions and a
> global range of addresses of memory regions, and let the Linux PCI core
> allocate from those two ranges to the different devices connected
> downstream of the PCI-to-PCI bridges. This gives us for free the rather
> complex allocation of addresses we need to set up our address decoding
> windows.
>
> If we have have separate domains for each of our hardware PCIe
> interface, can we still benefit from this allocation of resources from
> a globally defined range of I/O addresses and memory addresses?
My interpretation of what you told me in the previous mail is that
each root port has
* A separate configuration space
* A separate 64KB I/O window that is not shared with the other ports,
or potentially multiple 64KB windows, which we would not want to use
* A configurable range of the memory space that does not overlap
with the other ports
Is the above a correct description?
If so, I think it would be most sensible to not try to put all ports
into the same domain, but give each port the full view of its own
256 buses, and 64KB I/O space. The memory space can still be directly
mapped, if you only set up the physical address window for that after
the bus scan is complete.
Arnd
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Fix selection of clockevent timer when using device-tree
From: Jon Hunter @ 2013-01-29 20:23 UTC (permalink / raw)
To: linux-arm-kernel
Commit 9725f44 (ARM: OMAP: Add DT support for timer driver) added
device-tree support for selecting a clockevent timer by property.
However, the code is currently ignoring the property passed and
selecting the first available timer found. Hence, for the OMAP3 beagle
board timer-12 is not being selected as expected. Fix this problem
by ensuring the timer property is passed to omap_get_timer_dt().
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b8ad6e6..265de51 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -228,7 +228,7 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
int r = 0;
if (of_have_populated_dt()) {
- np = omap_get_timer_dt(omap_timer_match, NULL);
+ np = omap_get_timer_dt(omap_timer_match, property);
if (!np)
return -ENODEV;
--
1.7.10.4
^ permalink raw reply related
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Sascha Hauer @ 2013-01-29 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107D253.5030400@ti.com>
On Tue, Jan 29, 2013 at 07:14:51PM +0530, kishon wrote:
> Hi,
>
> On Tuesday 29 January 2013 04:52 PM, Sascha Hauer wrote:
> >From: Michael Grzeschik <m.grzeschik@pengutronix.de>
> >
> >This adds two little devicetree helper functions for determining the
> >dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> >the devicetree.
> >
> >Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> >Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> >---
> >
> >The properties and their values have been taken from the fsl-mph-dr driver.
> >This binding is also documented (though currently not used) for the tegra
> >ehci driver (Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt).
> >This is a first attempt to parse these bindings at a common place so that
> >others can make use of it.
> >
> >Basically I want to know whether this binding is recommended for new drivers
> >since normally the devicetree uses '-' instead of '_', and maybe there are
> >other problems with it.
> >
> >I need this binding for the chipidea driver. I suspect that the fsl-mph-dr
> >driver also really handles a chipidea core.
> >
> >Should we agree on this I would convert the fsl-mph-dr driver to use these
> >helpers.
> >
> >Sascha
> >
> > drivers/usb/core/Makefile | 1 +
> > drivers/usb/core/of.c | 76 +++++++++++++++++++++++++++++++++++++++++++++
>
> This file should ideally go into drivers/usb/phy/.
I originally wanted to do that, but the host/peripheral/otg property is
not phy specific. DO you still want to move it there?
> > include/linux/usb/of.h | 22 +++++++++++++
> > include/linux/usb/phy.h | 9 ++++++
> > 4 files changed, 108 insertions(+)
> > create mode 100644 drivers/usb/core/of.c
> > create mode 100644 include/linux/usb/of.h
> >
> >diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> >index 26059b9..5378add 100644
> >--- a/drivers/usb/core/Makefile
> >+++ b/drivers/usb/core/Makefile
> >@@ -10,5 +10,6 @@ usbcore-y += devio.o notify.o generic.o quirks.o devices.o
> >
> > usbcore-$(CONFIG_PCI) += hcd-pci.o
> > usbcore-$(CONFIG_ACPI) += usb-acpi.o
> >+usbcore-$(CONFIG_OF) += of.o
>
> No Kconfig? Shouldn't this file be compiled only when some one is
> going to use the PHY?
Yes. Just skipped that for the first shot.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Cooper @ 2013-01-29 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51082C4E.5050903@gmail.com>
On Tue, Jan 29, 2013 at 09:08:46PM +0100, Sebastian Hesselbarth wrote:
> On 01/29/2013 08:42 PM, Simon Baatz wrote:
> >On Mon, Jan 28, 2013 at 07:48:24PM -0500, Jason Cooper wrote:
> >>On Mon, Jan 28, 2013 at 11:31:48PM +0100, Simon Baatz wrote:
> >>>Nothing special here. My config originally based on a Debian config
> >>>for a Kirkwood kernel. Thus, amongst other drivers, mv643xx_eth is
> >>>build as a module and is loaded from an initrd.
> >>>Because all relevant drivers are loaded as modules, I need my
> >>>runit patch to boot at all.
> >>
> >>Let's back up. If you config early printk and COMMON_CLK_DEBUG and a
> >>vanilla v3.8-rc5 with your current config, what happens?
> >
> >I thought it's clear what happens. "runit" is requested in the dts by
> >serial, spi, watchdog, nand, i2c. Each of these are either not built
> >or built as a module in my config, except serial.
>
> Simon,
>
> it is clear what happens but just to blindly disable clock gating will
> not help here. What you are suffering are several issues not only one.
Agreed.
> >of_serial.c does the following in of_platform_serial_setup():
> >
> > if (of_property_read_u32(np, "clock-frequency",&clk)) {
> >
> > /* Get clk rate through clk driver if present */
> > info->clk = clk_get(&ofdev->dev, NULL);
> > if (IS_ERR(info->clk)) {
> > dev_warn(&ofdev->dev,
> > "clk or clock-frequency not defined\n");
> > return PTR_ERR(info->clk);
> > }
> >
> > clk_prepare_enable(info->clk);
> > clk = clk_get_rate(info->clk);
> > }
> >
> >and since "clock-frequency" is still given in the standard DTS for
> >the IB-NAS 6210, it does not enable the clock.
> >Thus, no driver uses the clock, it gets disabled and the system locks
> >up.
> >The system boots when removing "clock-frequency" from the DTS.
> >
> >Which lead to two questions:
> >- Is it safe to remove "clock-frequency" now that we have the clocks
> > in place?
>
> Safe, as long as you replace it with the corresponding clocks=<&..> property.
For serial, this is in kirkwood.dtsi, so we are fine there.
> >- The behavior of of_serial.c looks strange to me, is this really the
> >desired behavior?
>
> I guess it is, rely on clock-frequency because a lot of boards still use it.
> There was no clocks property in of_serial when we started with kirkwood and
> dove. I think we can switch now to clocks property which will also remove
> all hard coded occurrences of tclk frequency.
>
> >For the "runit" clock, this means that any time you hit a
> >configuration that does not keep the clock enabled, the system will
> >lockup. (We have gone through this more than once now. Especially,
> >this hits you hard when you try to support a new board and disable as
> >much as possible in the config/dts for a start...).
>
> Well, if there is no device/driver using runit it should be safe to disable
> it. If there is a driver using it, we need a clocks property for it. And
> as you already stated, serial is using it. And you want serial in every
> minimal kernel, don't you?
>
> >Thus, we should keep it enabled even if it is unused, which is
> >exactly the purpose of CLK_IGNORE_UNUSED if I understood this
> >correctly.
>
> True, but only if it is that important that it should _never_ be gated.
> As long as it is 'only' used by peripheral devices, it should be safe
> to gate it.
>
> >>Could you also please try kirkwood_defconfig and tell us if it boots?
> >
> >It is very easy to get my system to boot with a stock kernel. Just
> >build one of the drivers I use directly into the kernel and it boots
> >(up to the point where the gbe driver is loaded if built as a module,
> >of course).
> >
> >>>Here are my findings with various patches: ("non-DT" means booting
> >>>the IBNAS6210 with machine ID 1680 ???Marvell DB-88F6281-BP
> >>>Development Board???, which works reasonably well)
> >>>
> >>>3.8-rc5 + runit patch:
> >>>
> >>>DT: Hangs at boot (when loading mv643xx_eth)
> >>>non-DT: Boots ok
> >
> >In the DT case ge0 and ge1 are NULL, and thus, kirkwood_ge0[01]_init()
> >tries to enable NULL clocks, but not the gbe clocks. -> The clocks
> >get disabled.
> >
> >As described in Sebastian's patch (and also found by Andrew some time
> >ago), this leads to a hanging system when loading the gbe driver.
>
> If I got all your configs right, this DT case is with serial but no
> clocks property? All other runit "users" are _not_ built into the
> kernel? Maybe it is just a coincidence that it fails when loading
> eth but I guess it hangs because of runit getting gated while serial
> accessing it. When you replace serial's clock-frequency with clocks
> property to "runit" it shouldn't hang.
>
> (Issue 1: gated runit clock hangs kernel due to serial access)
This can be fixed with a patch removing clock-frequency from all
kirkwood boards (dove, orion, etc?) I'll gin this up and add it to the
havoc ;-)
> >>>3.8-rc5 + runit patch + ge00/ge01 patch:
> >>>
> >>>DT: Boots ok
> >>>non-DT: Boots ok
> >
> >Since the clocks are found now and kept enabled, DT behaves the same
> >as non-DT.
> >
> >>>
> >>>3.8-rc5 + runit + Sebastians get smi clock patch (modified to use
> >>>legacy clock names):
> >>>
> >>>DT: Boots, but no MAC
> >>>non-DT: Boots ok
> >
> >This is the behavior originally found by Andrew. The clock patch
> >eliminates the lockup, but the hardware forgets its MAC address.
> >
> >>>
> >>>3.8-rc5 + runit + using Sebastians patch + clks not ticking at module
> >>>load:
> >>>
> >>>DT: Boots, but no MAC
> >>>non-DT: Boots, but no MAC
>
> Ok, here my patch for smi clock enables gbe clock before accessing gbe
> registers.
>
> (Issue 2: gated gbe clock hangs kernel due to smi access)
Here, I'm going to wait for Florian's mvmdio changes to settle out and
then readdress this. My current understanding is that there will only
be one DT node for this. iiuc, each board dts will have to say which
gate clocks to consume to prevent the mvmdio node in the dtsi from
consuming both unconditionally.
> >I think non-DT and DT gated clocks behave differently, since the
> >non-DT ones also enable/disable the PHY. I explicitly removed the
> >clk_prepare_enable() from kirkwood_ge0[01]_init() in order to see if
> >this makes a difference.
>
> True, DT gated clocks don't disable PHYs (and never will).
>
> >(Which reminds me, that we wanted to implement the PHY enabling in
> >the driver.)
> >
> >Apparently, it does not make a difference.
>
> Leaves Issue 3, gbe forgets about its MAC address when gated or powered
> down. That should be done with local-mac-address passed by DT enabled
> u-boot or any other (dirty) ATAG hack ;)
A patch to mv643xx_eth to pull this from DT should solve this.
thx,
Jason.
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Thomas Petazzoni @ 2013-01-29 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301292015.21478.arnd@arndb.de>
Dear Arnd Bergmann,
On Tue, 29 Jan 2013 20:15:21 +0000, Arnd Bergmann wrote:
> I mean you could make each root port look like a separate host
> bridge that is not related to the others, and not have any
> emulated PCI-to-PCI bridges at all.
Ok.
> > Remember that the very reason to use emulated PCI-to-PCI bridges is
> > that we want to assign a global range of addresses of I/O regions
> > and a global range of addresses of memory regions, and let the
> > Linux PCI core allocate from those two ranges to the different
> > devices connected downstream of the PCI-to-PCI bridges. This gives
> > us for free the rather complex allocation of addresses we need to
> > set up our address decoding windows.
> >
> > If we have have separate domains for each of our hardware PCIe
> > interface, can we still benefit from this allocation of resources
> > from a globally defined range of I/O addresses and memory addresses?
>
> My interpretation of what you told me in the previous mail is that
> each root port has
>
> * A separate configuration space
> * A separate 64KB I/O window that is not shared with the other ports,
> or potentially multiple 64KB windows, which we would not want to use
> * A configurable range of the memory space that does not overlap
> with the other ports
>
> Is the above a correct description?
>
> If so, I think it would be most sensible to not try to put all ports
> into the same domain, but give each port the full view of its own
> 256 buses, and 64KB I/O space. The memory space can still be directly
> mapped, if you only set up the physical address window for that after
> the bus scan is complete.
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 :-)
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 06/15] ARM: mcpm: generic SMP secondary bringup and hotplug support
From: Rob Herring @ 2013-01-29 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359445870-18925-7-git-send-email-nicolas.pitre@linaro.org>
On 01/29/2013 01:51 AM, Nicolas Pitre wrote:
> Now that the cluster power API is in place, we can use it for SMP secondary
> bringup and CPU hotplug in a generic fashion.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
> ---
> arch/arm/common/Makefile | 2 +-
> arch/arm/common/mcpm_platsmp.c | 85 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 86 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/common/mcpm_platsmp.c
>
> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> index c901a38c59..e1c9db45de 100644
> --- a/arch/arm/common/Makefile
> +++ b/arch/arm/common/Makefile
> @@ -13,4 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
> obj-$(CONFIG_SHARP_SCOOP) += scoop.o
> obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
> obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
> -obj-$(CONFIG_CLUSTER_PM) += mcpm_head.o mcpm_entry.o vlock.o
> +obj-$(CONFIG_CLUSTER_PM) += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock.o
> diff --git a/arch/arm/common/mcpm_platsmp.c b/arch/arm/common/mcpm_platsmp.c
> new file mode 100644
> index 0000000000..401298f5ee
> --- /dev/null
> +++ b/arch/arm/common/mcpm_platsmp.c
> @@ -0,0 +1,85 @@
> +/*
> + * linux/arch/arm/mach-vexpress/mcpm_platsmp.c
> + *
> + * Created by: Nicolas Pitre, November 2012
> + * Copyright: (C) 2012-2013 Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Code to handle secondary CPU bringup and hotplug for the cluster power API.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/smp.h>
> +
> +#include <asm/mcpm_entry.h>
> +#include <asm/smp_plat.h>
> +#include <asm/hardware/gic.h>
> +
> +static void __init simple_smp_init_cpus(void)
> +{
> + set_smp_cross_call(gic_raise_softirq);
In case you're not aware, you might want to base this on the gic move to
drivers/irqchips. It is in arm-soc now. Then you don't need this
set_smp_cross_call anymore. It is now set by the gic code internally.
> +}
> +
> +static int __cpuinit mcpm_boot_secondary(unsigned int cpu, struct task_struct *idle)
> +{
> + unsigned int mpidr, pcpu, pcluster, ret;
> + extern void secondary_startup(void);
> +
> + mpidr = cpu_logical_map(cpu);
> + pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> + pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> + pr_debug("%s: logical CPU %d is physical CPU %d cluster %d\n",
> + __func__, cpu, pcpu, pcluster);
> +
> + mcpm_set_entry_vector(pcpu, pcluster, NULL);
> + ret = mcpm_cpu_power_up(pcpu, pcluster);
> + if (ret)
> + return ret;
> + mcpm_set_entry_vector(pcpu, pcluster, secondary_startup);
> + gic_raise_softirq(cpumask_of(cpu), 0);
You can use arch_send_wakeup_ipi_mask here now instead. That's in 3.8-rc1.
> + dsb_sev();
> + return 0;
> +}
> +
> +static void __cpuinit mcpm_secondary_init(unsigned int cpu)
> +{
> + mcpm_cpu_powered_up();
> + gic_secondary_init(0);
Catalin's gic series will remove this.
> +}
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> +
> +static int mcpm_cpu_disable(unsigned int cpu)
> +{
> + /*
> + * We assume all CPUs may be shut down.
> + * This would be the hook to use for eventual Secure
> + * OS migration requests as described in the PSCI spec.
> + */
> + return 0;
> +}
> +
> +static void mcpm_cpu_die(unsigned int cpu)
> +{
> + unsigned int mpidr, pcpu, pcluster;
> + mpidr = read_cpuid_mpidr();
> + pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> + pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> + mcpm_set_entry_vector(pcpu, pcluster, NULL);
> + mcpm_cpu_power_down();
> +}
> +
> +#endif
> +
> +struct smp_operations __initdata mcpm_smp_ops = {
> + .smp_init_cpus = simple_smp_init_cpus,
> + .smp_boot_secondary = mcpm_boot_secondary,
> + .smp_secondary_init = mcpm_secondary_init,
> +#ifdef CONFIG_HOTPLUG_CPU
> + .cpu_disable = mcpm_cpu_disable,
> + .cpu_die = mcpm_cpu_die,
> +#endif
> +};
>
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Arnd Bergmann @ 2013-01-29 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129174546.GE23505@n2100.arm.linux.org.uk>
On Tuesday 29 January 2013, Russell King - ARM Linux wrote:
> Well, how it all works in the PL08x driver at present is:
<snip>
Thanks for the explanations. If I end up implementing the DT support
for pl08x, this will be very helpful. I looked at the git history
for mach-versatile and could not find any of it there, although
the patches were certainly on the mailing list
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017818.html
Do you (or Linus) know what happened to the patch series?
Based on your description, it sounds all doable, but the split
between platform specific code and device driver code would be
different: While the muxing that you describe all takes place
in the get_signal/put_signal functions in platform code, doing
a proper DT binding for the mux would imply moving that into the
pl080 driver itself, at least as a compile-time option for the
driver. Do you think that would be acceptable?
While I guess we could still keep the get_signal/put_signal
callbacks in mach-versatile but drop them for platforms
without a mux, I'm not sure if that would make the overall
driver better or worse.
Arnd
^ permalink raw reply
* [PATCH 5/5] mv643xx_eth: convert to use the Marvell Orion MDIO driver
From: Florian Fainelli @ 2013-01-29 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129181306.GF25646@obsidianresearch.com>
Le mardi 29 janvier 2013 19:13:06, Jason Gunthorpe a ?crit :
> On Tue, Jan 29, 2013 at 04:24:08PM +0100, Florian Fainelli wrote:
> > This patch converts the Marvell MV643XX ethernet driver to use the
> > Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
> > registering the Marvell MV643XX ethernet driver are also updated to
> > register a Marvell Orion MDIO driver. This driver voluntarily overlaps
> > with the Marvell Ethernet shared registers because it will use a subset
> > of this shared register (shared_base + 0x4 - shared_base + 0x84). The
> > Ethernet driver is also updated to look up for a PHY device using the
> > Orion MDIO bus driver.
>
> Can you finish off this job by making the mv643xx_eth driver accept
> the standard phy-handle OF property instead of using a phy address?
I can certainly do that, at the same time we need to continue supporting the
"old" platform device style registration without breaking them (PowerPC in
particular, and the hopefully yet to be converted orion5x). So the phy_scan()
as I modified it will probably still be there.
>
> Ie the end result should be something like:
>
> smi0: mdio at 72000 {
> device_type = "mdio";
> compatible = "marvell,orion-mdio";
> reg = <0x72004 0x4>;
>
> #address-cells = <1>;
> #size-cells = <0>;
> PHY1: ethernet-phy at 1 {
> reg = <1>;
> device_type = "ethernet-phy";
> phy-id = <0x01410e90>;
> };
> };
>
> egiga0 {
> device_type = "network";
> compatible = "marvell,mv643xx-eth";
> reg = <0x72000 0x4000>;
> port_number = <0>;
> phy-handle = <&PHY1>;
> interrupts = <11>;
> local-mac-address = [000000000002]; /* Filled by
> boot loader */ };
>
> Regards,
> Jason
--
Florian
^ permalink raw reply
* [PATCH 4/5] net: mvmdio: allow Device Tree and platform device to coexist
From: Florian Fainelli @ 2013-01-29 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129175912.GE25646@obsidianresearch.com>
Le mardi 29 janvier 2013 18:59:12, Jason Gunthorpe a ?crit :
> On Tue, Jan 29, 2013 at 04:24:07PM +0100, Florian Fainelli wrote:
> > - dev->err_interrupt = irq_of_parse_and_map(pdev->dev.of_node, 0);
> > + if (pdev->dev.of_node) {
> > + dev->regs = of_iomap(pdev->dev.of_node, 0);
> > + if (!dev->regs) {
> > + dev_err(&pdev->dev, "No SMI register address given in
DT\n");
> > + ret = -ENODEV;
> > + goto out_free;
> > + }
> > +
> > + dev->err_interrupt = irq_of_parse_and_map(pdev->dev.of_node, 0);
> > + } else {
> > + r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +
> > + dev->regs = ioremap(r->start, resource_size(r));
> > + if (!dev->regs) {
> > + dev_err(&pdev->dev, "No SMI register address given\n");
> > + ret = -ENODEV;
> > + goto out_free;
> > + }
> > +
> > + dev->err_interrupt = platform_get_irq(pdev, 0);
> > + }
>
> Why do you have these different paths for OF and platform? AFAIK these
> days when a OF device is automatically converted into a platform
> device all the struct resources are created too, so you can't you just
> use platform_get_resource and devm_request_and_ioremap for both flows?
>
> Ditto for the interrupt - platform_get_irq should work in both cases?
There was no particular reason and I updated the patchset to do that precisely
in version 2.
--
Florian
^ 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