* [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
From: Maxime Ripard @ 2014-02-04 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E77FCD.5050701@redhat.com>
Hi Hans,
On Tue, Jan 28, 2014 at 11:00:45AM +0100, Hans de Goede wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> On 01/28/2014 10:44 AM, Maxime Ripard wrote:
> > On Mon, Jan 27, 2014 at 03:54:14PM +0100, Hans de Goede wrote:
> >>>> "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13
> >>>
> >>> Maybe we can just remove the gates from there? Even though they
> >>> are gates, they are also (a bit) more than that.
> >>
> >> To be clear you mean s/usb-gates-clk/usb-clk/ right ?
> >
> > Yep, exactly
> >
> >>> I guess that means that we will have the OHCI0 gate declared
> >>> with <&...-gates-clk 6>, while it's actually the first gate for
> >>> this clock?
> >>
> >> Correct.
> >>
> >>> Maybe introducing an offset field in the gates_data would be a
> >>> good idea, so that we always start from indexing the gates from
> >>> 0 in the DT?
> >>
> >> Well for the other "gates" type clks we also have holes in the
> >> range, and we always refer to the clk with the bit number in the
> >> reg as the clock-cell value.
> >
> > Yes, we have holes, but I see two majors differences here: - the
> > other gates are just gates, while the usb clocks are a bit more
> > than that.
>
> The usb-clk registers contain more then that, but the bits we are
> talking about now are gates.
>
> > - the other gates' gating bits thus all start at bit 0, while
> > - here, since it's kind of a "mixed" clock, the gating bits start
> > - at bit 6 (on the A20 at least)
>
> Right, still I believe that the consistent thing to do is keeping
> the bit-number for the bit in the register controlling the gate as
> the specifier. When adding new dts entries / reviewing existing
> ones I'm used to matching the specifier to the bit-nr in the
> data-sheet, I think making things different just for this one
> register is counter productive.
And if you turn it the other way around, it would be inconsistent that
all gates indices start at 0, and we would start at 6 here :)
Plus, this clock is already a special case, since it's the only gate
that is more than just a gate so far.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/a602e9cd/attachment.sig>
^ permalink raw reply
* [PATCH] security: select correct default LSM_MMAP_MIN_ADDR on arm on arm64
From: Will Deacon @ 2014-02-04 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391480133-27149-1-git-send-email-ccross@android.com>
On Tue, Feb 04, 2014 at 02:15:32AM +0000, Colin Cross wrote:
> Binaries compiled for arm may run on arm64 if CONFIG_COMPAT is
> selected. Set LSM_MMAP_MIN_ADDR to 32768 if ARM64 && COMPAT to
> prevent selinux failures launching 32-bit static executables that
> are mapped at 0x8000.
>
> Signed-off-by: Colin Cross <ccross@android.com>
> ---
> security/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/Kconfig b/security/Kconfig
> index e9c6ac724fef..beb86b500adf 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -103,7 +103,7 @@ config INTEL_TXT
> config LSM_MMAP_MIN_ADDR
> int "Low address space for LSM to protect from user allocation"
> depends on SECURITY && SECURITY_SELINUX
> - default 32768 if ARM
> + default 32768 if ARM || (ARM64 && COMPAT)
> default 65536
> help
> This is the portion of low virtual memory which should be protected
Since ARM64 && COMPAT implies 4k pages, this change looks ok to me.
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] ARM64: KVM: Fix VGIC compile error for Linux-3.14-rc1
From: Anup Patel @ 2014-02-04 9:37 UTC (permalink / raw)
To: linux-arm-kernel
This patch fixes VGIC compilation for Linux-3.14-rc1 ARM64 kernel.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
arch/arm64/include/uapi/asm/kvm.h | 9 +++++++++
virt/kvm/arm/vgic.c | 1 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 31c2f54..cadc318 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -149,6 +149,15 @@ struct kvm_arch_memory_slot {
#define KVM_REG_ARM_TIMER_CNT ARM64_SYS_REG(3, 3, 14, 3, 2)
#define KVM_REG_ARM_TIMER_CVAL ARM64_SYS_REG(3, 3, 14, 0, 2)
+/* Device Control API: ARM VGIC */
+#define KVM_DEV_ARM_VGIC_GRP_ADDR 0
+#define KVM_DEV_ARM_VGIC_GRP_DIST_REGS 1
+#define KVM_DEV_ARM_VGIC_GRP_CPU_REGS 2
+#define KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
+#define KVM_DEV_ARM_VGIC_CPUID_MASK (0xffULL << KVM_DEV_ARM_VGIC_CPUID_SHIFT)
+#define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
+#define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
+
/* KVM_IRQ_LINE irq field index values */
#define KVM_ARM_IRQ_TYPE_SHIFT 24
#define KVM_ARM_IRQ_TYPE_MASK 0xff
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index be456ce..55b0609 100644
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@ -21,6 +21,7 @@
#include <linux/kvm_host.h>
#include <linux/interrupt.h>
#include <linux/io.h>
+#include <linux/uaccess.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
From: Maxime Ripard @ 2014-02-04 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64+qiBqYtWyc23b6p4aWyWj7a9K1qveTsW7ZGh0ti8_Wg@mail.gmail.com>
On Tue, Feb 04, 2014 at 10:43:33AM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Feb 4, 2014 at 3:31 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Mon, Feb 03, 2014 at 11:32:19AM +0800, Chen-Yu Tsai wrote:
> >> The Allwinner A20/A31 clock module controls the transmit clock source
> >> and interface type of the GMAC ethernet controller. Model this as
> >> a single clock for GMAC drivers to use.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> ---
> >> Documentation/devicetree/bindings/clock/sunxi.txt | 26 +++++++
> >> drivers/clk/sunxi/clk-sunxi.c | 83 +++++++++++++++++++++++
> >> 2 files changed, 109 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> >> index 0cf679b..f43b4c0 100644
> >> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> >> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> >> @@ -37,6 +37,7 @@ Required properties:
> >> "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> >> "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
> >> "allwinner,sun7i-a20-out-clk" - for the external output clocks
> >> + "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
> >>
> >> Required properties for all clocks:
> >> - reg : shall be the control register address for the clock.
> >> @@ -50,6 +51,9 @@ Required properties for all clocks:
> >> If the clock module only has one output, the name shall be the
> >> module name.
> >>
>
>
> >> +For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
> >> +dummy clocks at 25 MHz and 125 MHz, respectively. See example.
> >> +
>
>
> >> Clock consumers should specify the desired clocks they use with a
> >> "clocks" phandle cell. Consumers that are using a gated clock should
> >> provide an additional ID in their clock property. This ID is the
> >> @@ -96,3 +100,25 @@ mmc0_clk: clk at 01c20088 {
> >> clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> >> clock-output-names = "mmc0";
> >> };
> >> +
> >> +mii_phy_tx_clk: clk at 2 {
> >> + #clock-cells = <0>;
> >> + compatible = "fixed-clock";
> >> + clock-frequency = <25000000>;
> >> + clock-output-names = "mii_phy_tx";
> >> +};
> >> +
> >> +gmac_int_tx_clk: clk at 3 {
> >> + #clock-cells = <0>;
> >> + compatible = "fixed-clock";
> >> + clock-frequency = <125000000>;
> >> + clock-output-names = "gmac_int_tx";
> >> +};
> >> +
> >> +gmac_clk: clk at 01c20164 {
> >> + #clock-cells = <0>;
> >> + compatible = "allwinner,sun7i-a20-gmac-clk";
> >> + reg = <0x01c20164 0x4>;
> >> + clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
> >
> > You should also document in which order you expect the parents to
> > be. Or it will probably be easier to just use clock-names here.
>
> Is it not clear from the "Required properties" section above?
I'd make it clearer. But again, using clock-names would avoid any
ambiguity, and be more flexible.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/e48653e2/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/8] ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
From: Maxime Ripard @ 2014-02-04 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v660qoKDC6SKjoD29b-r5y9OwkeKoWZ9PWBF5tC5PgeEYQ@mail.gmail.com>
On Tue, Feb 04, 2014 at 11:06:24AM +0800, Chen-Yu Tsai wrote:
> On Tue, Feb 4, 2014 at 3:34 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Mon, Feb 03, 2014 at 11:32:20AM +0800, Chen-Yu Tsai wrote:
> >> The GMAC uses 1 of 2 sources for its transmit clock, depending on the
> >> PHY interface mode. Add both sources as dummy clocks, and as parents
> >> to the GMAC clock node.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> ---
> >> arch/arm/boot/dts/sun7i-a20.dtsi | 28 ++++++++++++++++++++++++++++
> >> 1 file changed, 28 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> >> index 1595e9a..fc7f470 100644
> >> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> >> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> >> @@ -314,6 +314,34 @@
> >> };
> >>
> >> /*
> >> + * The following two are dummy clocks, placeholders used
> >> + * on gmac_tx clock. The actual frequency and availability
> >> + * depends on the external PHY, operation mode and link
> >> + * speed.
> >> + */
> >
> > If it depends on the external PHY, I guess that means it also depends
> > on the board, right? Or is the GMAC supposed to always have that clock
> > running at 25MHz, no matter what PHY is connected to it?
>
> What I meant in the comment is that we cannot control the actual clock
> rate of the TX clock. We can only select the source, and this is what
> gmac_tx clock does. It is just a clock mux. The 125MHz and 25MHz clock
> rates are used by the clk_set_rate in the stmmac glue layer to do
> auto-reparenting.
>
> The board dependent factor is what _type_ of PHY it is using, i.e.
> MII, GMII, or RGMII. If it's MII, the PHY should provide the clock.
> If it's RGMII, the internal clock would be used. GMII is a mix of
> both. The actual clock rate depends on the link speed.
>
> I should rephrase the comment along the lines of:
>
> The following two are dummy clocks, placeholders used in the gmac_tx
> clock. The gmac driver will choose one parent depending on the PHY
> interface mode, using clk_set_rate auto-reparenting.
> The actual TX clock rate is not controlled by the gmac_tx clock.
Ok, thanks for the clarification.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/e5b2cc87/attachment.sig>
^ permalink raw reply
* PCIe trouble on imx6q
From: Kamel BOUHARA @ 2014-02-04 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAM9uW_6rrXrwEKSXBZd+B=WzyoFqjrBgrmXNk0u42JFuMcTJ=g@mail.gmail.com>
2014-01-29 Kamel BOUHARA <k.bouhara@gmail.com>:
> 2014-01-29 Bjorn Helgaas <bhelgaas@google.com>:
>> [+cc linux-arm, Richard, Shawn (please keep the cc list)]
>>
>> On Wed, Jan 29, 2014 at 2:28 AM, Kamel BOUHARA <k.bouhara@gmail.com> wrote:
>>> ---------- Forwarded message ----------
>>> From: Kamel BOUHARA <k.bouhara@gmail.com>
>>> Date: 2014-01-29
>>> Subject: Re: PCIe trouble on imx6q
>>> To: Bjorn Helgaas <bhelgaas@google.com>
>>>
>>>
>>> 2014-01-28 Bjorn Helgaas <bhelgaas@google.com>:
>>>> [+cc Richard, Shawn, linux-arm-kernel (all from MAINTAINERS)]
>>>>
>>>> On Tue, Jan 28, 2014 at 1:02 AM, Kamel BOUHARA <k.bouhara@gmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> Im getting trouble with kernel 3.13 at boot time, the pcie link failed
>>>>> to get up with the following log:
>>>>> ------------[ cut here ]------------
>>>>> WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:159 gpio_to_desc+0x34/0x48()
>>>>> invalid GPIO -2
>>>>> Modules linked in:
>>>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0+ #4
>>>>> Backtrace:
>>>>> [<8001217c>] (dump_backtrace) from [<80012460>] (show_stack+0x18/0x1c)
>>>>> r6:802b9548 r5:00000000 r4:808d3060 r3:00000000
>>>>> [<80012448>] (show_stack) from [<806414fc>] (dump_stack+0x84/0x9c)
>>>>> [<80641478>] (dump_stack) from [<800289f8>] (warn_slowpath_common+0x70/0x94)
>>>>> r5:00000009 r4:bf05bcb0
>>>>> [<80028988>] (warn_slowpath_common) from [<80028a54>]
>>>>> (warn_slowpath_fmt+0x38/0x40)
>>>>> r8:01f00000 r7:00000000 r6:0011cc11 r5:808b68c0 r4:bf24fa30
>>>>> [<80028a20>] (warn_slowpath_fmt) from [<802b9548>] (gpio_to_desc+0x34/0x48)
>>>>> r3:fffffffe r2:807d23fc
>>>>> [<802b9514>] (gpio_to_desc) from [<802d9de0>] (imx6_pcie_host_init+0x174/0x434)
>>>>> [<802d9c6c>] (imx6_pcie_host_init) from [<80886dbc>]
>>>>> (dw_pcie_host_init+0x348/0x41c)
>>>>> r6:00000000 r5:808d52cc r4:00000020 r3:802d9c6c
>>>>> [<80886a74>] (dw_pcie_host_init) from [<808871d4>] (imx6_pcie_probe+0x320/0x3dc)
>>>>> r10:00000000 r9:000000c4 r8:808d539c r7:bf7e3384 r6:bf24fa30 r5:bf135810
>>>>> r4:bf24fa10
>>>>> [<80886eb4>] (imx6_pcie_probe) from [<8034b670>] (platform_drv_probe+0x20/0x50)
>>>>> r8:808d539c r7:00000000 r6:00000000 r5:808d539c r4:bf135810
>>>>> [<8034b650>] (platform_drv_probe) from [<80349c74>]
>>>>> (driver_probe_device+0x118/0x234)
>>>>> r5:bf135810 r4:80e526b8
>>>>> [<80349b5c>] (driver_probe_device) from [<80349e78>] (__driver_attach+0x9c/0xa0)
>>>>> r8:80886e90 r7:00000000 r6:bf135844 r5:808d539c r4:bf135810 r3:00000000
>>>>> [<80349ddc>] (__driver_attach) from [<8034806c>] (bus_for_each_dev+0x68/0x9c)
>>>>> r6:80349ddc r5:808d539c r4:00000000 r3:00000000
>>>>> [<80348004>] (bus_for_each_dev) from [<8034972c>] (driver_attach+0x20/0x28)
>>>>> r6:808df6a8 r5:bf1f5e00 r4:808d539c
>>>>> [<8034970c>] (driver_attach) from [<803493b0>] (bus_add_driver+0x148/0x1f4)
>>>>> [<80349268>] (bus_add_driver) from [<8034a4c8>] (driver_register+0x80/0x100)
>>>>> r7:8090e640 r6:8090e640 r5:00000005 r4:808d539c
>>>>> [<8034a448>] (driver_register) from [<8034b63c>]
>>>>> (__platform_driver_register+0x50/0x64)
>>>>> r5:00000005 r4:808d5388
>>>>> [<8034b5ec>] (__platform_driver_register) from [<8034b6e0>]
>>>>> (platform_driver_probe+0x28/0xac)
>>>>> [<8034b6b8>] (platform_driver_probe) from [<80886ea8>]
>>>>> (imx6_pcie_init+0x18/0x24)
>>>>> r5:00000005 r4:808aa104
>>>>> [<80886e90>] (imx6_pcie_init) from [<80008978>] (do_one_initcall+0x100/0x164)
>>>>> [<80008878>] (do_one_initcall) from [<8085ecc0>]
>>>>> (kernel_init_freeable+0x10c/0x1d0)
>>>>> r10:8089e060 r9:000000c4 r8:8089e050 r7:8090e640 r6:8090e640 r5:00000005
>>>>> r4:808aa104
>>>>> [<8085ebb4>] (kernel_init_freeable) from [<8063b67c>] (kernel_init+0x10/0x120)
>>>>> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8063b66c
>>>>> r4:00000000
>>>>> [<8063b66c>] (kernel_init) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
>>>>> r4:00000000 r3:ffffffff
>>>>> ---[ end trace b5e746dfc2398cd6 ]---
>>>>> ------------[ cut here ]------------
>>>>> WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:159 gpio_to_desc+0x34/0x48()
>>>>> invalid GPIO -2
>>>>> Modules linked in:
>>>>> CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 3.13.0+ #4
>>>>> Backtrace:
>>>>> [<8001217c>] (dump_backtrace) from [<80012460>] (show_stack+0x18/0x1c)
>>>>> r6:802b9548 r5:00000000 r4:808d3060 r3:00000000
>>>>> [<80012448>] (show_stack) from [<806414fc>] (dump_stack+0x84/0x9c)
>>>>> [<80641478>] (dump_stack) from [<800289f8>] (warn_slowpath_common+0x70/0x94)
>>>>> r5:00000009 r4:bf05bcb0
>>>>> [<80028988>] (warn_slowpath_common) from [<80028a54>]
>>>>> (warn_slowpath_fmt+0x38/0x40)
>>>>> r8:01f00000 r7:00000000 r6:0011cc11 r5:808b68c0 r4:bf24fa30
>>>>> [<80028a20>] (warn_slowpath_fmt) from [<802b9548>] (gpio_to_desc+0x34/0x48)
>>>>> r3:fffffffe r2:807d23fc
>>>>> [<802b9514>] (gpio_to_desc) from [<802d9df8>] (imx6_pcie_host_init+0x18c/0x434)
>>>>> [<802d9c6c>] (imx6_pcie_host_init) from [<80886dbc>]
>>>>> (dw_pcie_host_init+0x348/0x41c)
>>>>> r6:00000000 r5:808d52cc r4:00000020 r3:802d9c6c
>>>>> [<80886a74>] (dw_pcie_host_init) from [<808871d4>] (imx6_pcie_probe+0x320/0x3dc)
>>>>> r10:00000000 r9:000000c4 r8:808d539c r7:bf7e3384 r6:bf24fa30 r5:bf135810
>>>>> r4:bf24fa10
>>>>> [<80886eb4>] (imx6_pcie_probe) from [<8034b670>] (platform_drv_probe+0x20/0x50)
>>>>> r8:808d539c r7:00000000 r6:00000000 r5:808d539c r4:bf135810
>>>>> [<8034b650>] (platform_drv_probe) from [<80349c74>]
>>>>> (driver_probe_device+0x118/0x234)
>>>>> r5:bf135810 r4:80e526b8
>>>>> [<80349b5c>] (driver_probe_device) from [<80349e78>] (__driver_attach+0x9c/0xa0)
>>>>> r8:80886e90 r7:00000000 r6:bf135844 r5:808d539c r4:bf135810 r3:00000000
>>>>> [<80349ddc>] (__driver_attach) from [<8034806c>] (bus_for_each_dev+0x68/0x9c)
>>>>> r6:80349ddc r5:808d539c r4:00000000 r3:00000000
>>>>> [<80348004>] (bus_for_each_dev) from [<8034972c>] (driver_attach+0x20/0x28)
>>>>> r6:808df6a8 r5:bf1f5e00 r4:808d539c
>>>>> [<8034970c>] (driver_attach) from [<803493b0>] (bus_add_driver+0x148/0x1f4)
>>>>> [<80349268>] (bus_add_driver) from [<8034a4c8>] (driver_register+0x80/0x100)
>>>>> r7:8090e640 r6:8090e640 r5:00000005 r4:808d539c
>>>>> [<8034a448>] (driver_register) from [<8034b63c>]
>>>>> (__platform_driver_register+0x50/0x64)
>>>>> r5:00000005 r4:808d5388
>>>>> [<8034b5ec>] (__platform_driver_register) from [<8034b6e0>]
>>>>> (platform_driver_probe+0x28/0xac)
>>>>> [<8034b6b8>] (platform_driver_probe) from [<80886ea8>]
>>>>> (imx6_pcie_init+0x18/0x24)
>>>>> r5:00000005 r4:808aa104
>>>>> [<80886e90>] (imx6_pcie_init) from [<80008978>] (do_one_initcall+0x100/0x164)
>>>>> [<80008878>] (do_one_initcall) from [<8085ecc0>]
>>>>> (kernel_init_freeable+0x10c/0x1d0)
>>>>> r10:8089e060 r9:000000c4 r8:8089e050 r7:8090e640 r6:8090e640 r5:00000005
>>>>> r4:808aa104
>>>>> [<8085ebb4>] (kernel_init_freeable) from [<8063b67c>] (kernel_init+0x10/0x120)
>>>>> r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8063b66c
>>>>> r4:00000000
>>>>> [<8063b66c>] (kernel_init) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
>>>>> r4:00000000 r3:ffffffff
>>>>> ---[ end trace b5e746dfc2398cd7 ]---
>>>>> imx6q-pcie 1ffc000.pcie: phy link never came up
>>>>> PCI host bridge to bus 0000:00
>>>>> pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
>>>>> pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
>>>>> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
>>>>
>>>> Not related to the GPIO/link problem, but something's wrong here --
>>>> the host bridge driver should be telling us what bus numbers are
>>>> behind the host bridge. Since it didn't, the PCI core had to guess.
>>>>
>>>>> PCI: bus0: Fast back to back transfers disabled
>>>>> PCI: bus1: Fast back to back transfers enabled
>>>>> pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
>>>>> pci 0000:00:00.0: BAR 6: assigned [mem 0x01100000-0x0110ffff pref]
>>>>> pci 0000:00:00.0: PCI bridge to [bus 01]
>>>>> pci 0000:00:00.0: PCI bridge to [bus 01]
>>>>>
>>>>> Please, any help is welcome.
>>>>> Regards,
>>>>> Kamel.B
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>>>> the body of a message to majordomo at vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>> So I suppose, this is not a hardware issue rather a bad configuration ?
>>> Maybe the following log from lspci will be helpful ?
>>
>> It looks like a configuration issue or an imx6q host bridge issue. In
>> either case, it looks like something *before* we get to PCIe, so
>> something like your DT description of the host bridge is more likely
>> to be useful.
>>
>>> root at phyFLEX-i:~ lspci -vvv
>>> 00:00.0 PCI bridge: Device 16c3:abcd (rev 01) (prog-if 00 [Normal decode])
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>>> ParErr+ Stepping- SERR+ FastB2B- DisINTx+
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> Latency: 0, Cache Line Size: 64 bytes
>>> Region 0: Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
>>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>>> I/O behind bridge: 0000f000-00000fff
>>> Memory behind bridge: fff00000-000fffff
>>> Prefetchable memory behind bridge: fff00000-000fffff
>>> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>> <TAbort- <MAbort- <SERR- <PERR-
>>> [virtual] Expansion ROM at 01100000 [disabled] [size=64K]
>>> BridgeCtl: Parity+ SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>>> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>> Capabilities: [40] Power Management version 3
>>> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA
>>> PME(D0+,D1+,D2-,D3hot+,D3cold+)
>>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>>> Capabilities: [50] MSI: Mask+ 64bit+ Count=1/1 Enable+
>>> Address: 0000000090000000 Data: 0000
>>> Masking: 00000000 Pending: 00000000
>>> Capabilities: [70] Express (v2) Root Port (Slot-), MSI 00
>>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
>>> <64ns, L1 <1us
>>> ExtTag- RBE+ FLReset-
>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+
>>> Unsupported+
>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>> MaxPayload 128 bytes, MaxReadReq 512 bytes
>>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
>>> AuxPwr+ TransPend-
>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
>>> Latency L0 <1us, L1 <8us
>>> ClockPM- Surprise- LLActRep+ BwNot-
>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk-
>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train-
>>> SlotClk+ DLActive- BWMgmt- ABWMgmt-
>>> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal-
>>> PMEIntEna+ CRSVisible-
>>> RootCap: CRSVisible-
>>> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
>>> DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ ARIFwd-
>>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
>>> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance-
>>> SpeedDis-, Selectable De-emphasis: -6dB
>>> Transmit Margin: Normal Operating Range,
>>> EnterModifiedCompliance- ComplianceSOS-
>>> Compliance De-emphasis: -6dB
>>> LnkSta2: Current De-emphasis Level: -3.5dB
>>> Capabilities: [100] Advanced Error Reporting
>>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
>>> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>>> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
>>> UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>>> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
>>> Capabilities: [140] Virtual Channel <?>
>>> Kernel driver in use: pcieport
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Ok, actually I didn't get the host bridge set properly for my board,
> here is my DT:
>
>
> /dts-v1/;
> #include "imx6q-phytec-pfla02.dtsi"
>
> / {
> model = "Phytec phyFLEX-i.MX6 Quad Carrier-Board";
> compatible = "phytec,imx6q-pbab01", "phytec,imx6q-pfla02", "fsl,imx6q";
> };
>
> &fec {
> status = "okay";
> };
>
> &uart4 {
> status = "okay";
> };
>
> &usdhc2 {
> status = "okay";
> };
>
> &usdhc3 {
> status = "okay";
> };
>
> &pcie {
> status = "okay";
> };
>
>
> Can you give me a example of host configuration ?
>
>
> BR, Kamel.B
I finally found that I missed the disable-gpio that has to be at high level:
&pcie {
/*module pfla02 rev1 */
#if 0
reset-gpio = <&gpio2 23 0>; /* active low */
wake-up-gpio = <&gpio1 7 0>; /* active low */
disable-gpio = <&gpio1 21 1>; /* active low, don't disable endpoint gpios */
#endif
#if 1
/*module pfla02 rev2*/
reset-gpio = <&gpio2 23 0>;
wake-up-gpio = <&gpio1 7 0>;
disable-gpio = <&gpio4 17 1>;
#endif
};
But Im still stuck on the bus ressource affectation, Bjorn Helgaas
said that normally it is auto affected by the host bridge driver ?
Is there a patch to fix this ?
imx6q-pcie 1ffc000.pcie: reset-gpio number is 55
imx6q-pcie 1ffc000.pcie: power-on-gpio number is -2
imx6q-pcie 1ffc000.pcie: wake-up-gpio number is 7
imx6q-pcie 1ffc000.pcie: disable-gpio number is 113
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000-0x10000]
pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
PCI: bus1: Fast back to back transfers disabled
pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
pci 0000:00:00.0: BAR 9: assigned [mem 0x01100000-0x011fffff pref]
pci 0000:00:00.0: BAR 6: assigned [mem 0x01200000-0x0120ffff pref]
pci 0000:01:00.0: BAR 0: assigned [mem 0x01100000-0x01100fff 64bit pref]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01]
pci 0000:00:00.0: bridge window [mem 0x01100000-0x011fffff pref]
BR, Kamel B.
^ permalink raw reply
* [PATCH v3 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Maxime Ripard @ 2014-02-04 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140204002110.GP22609@sirena.org.uk>
Hi Mark,
On Tue, Feb 04, 2014 at 12:21:10AM +0000, Mark Brown wrote:
> On Fri, Jan 31, 2014 at 11:47:04PM +0100, Maxime Ripard wrote:
> > On Fri, Jan 31, 2014 at 12:48:09PM +0000, Mark Brown wrote:
> > > On Fri, Jan 31, 2014 at 11:55:50AM +0100, Maxime Ripard wrote:
>
> > > > + pm_runtime_enable(&pdev->dev);
> > > > + if (!pm_runtime_enabled(&pdev->dev)) {
> > > > + ret = sun6i_spi_runtime_resume(&pdev->dev);
> > > > + if (ret) {
> > > > + dev_err(&pdev->dev, "Couldn't resume the device\n");
> > > > + return ret;
> > > > + }
> > > > + }
>
> > > No, as discussed don't do this - notice how other drivers aren't written
> > > this way either. Like I said leave the device powered on startup and
> > > then let it be idled by runtime PM.
>
> > Well, some SPI drivers are actually written like that (all the tegra
>
> It's not been done consistently, no - that should be fixed.
>
> > SPI drivers for example). It's not an excuse, but waking up the device
> > only to put it back in suspend right away seems kind of
>
> It isn't awesome, no. Ideally the runtime PM code would do this but
> then you couldn't ifdef the operations which as far as I can tell is the
> main thing people want from disabling it and it gets complicated for
> devices that genuinely do power up on startup so here we are.
We discussed it with Kevin on IRC, and he suggested that we move that
pm_runtime initialization to the SPI core, but I guess that would also
mean that all drivers shouldn't ifdef the operations, so that the core
can call the runtime_resume callback directly.
However, I don't really get why any driver should be doing so, since
you still need these functions to at least to the device
suspend/resume in the probe/remove, and you don't really want to
duplicate the code.
Right now, about half of the SPI drivers using auto_runtime_pm are
using a ifdef, the other half is not.
> > inefficient. Plus, the pm_runtime_idle callback you suggested are
> > actually calling runtime_idle, while we want to call runtime_suspend.
>
> Yeah, I didn't actually check if I was looking at the right call there.
I was actually wrong, it does so in its very last line.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/60ce6bb9/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] clk: at91: propagate rate change on system clks
From: Nicolas Ferre @ 2014-02-04 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-4-git-send-email-b.brezillon@overkiz.com>
On 03/02/2014 12:25, Boris BREZILLON :
> System clks are just gates, and thus do not provide any rate operations.
> Authorize clk rate change to be propagated to system clk parents.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/clk/at91/clk-system.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/at91/clk-system.c b/drivers/clk/at91/clk-system.c
> index 8f7c043..a98557b 100644
> --- a/drivers/clk/at91/clk-system.c
> +++ b/drivers/clk/at91/clk-system.c
> @@ -84,7 +84,8 @@ at91_clk_register_system(struct at91_pmc *pmc, const char *name,
> * (see drivers/memory) which would request and enable the ddrck clock.
> * When this is done we will be able to remove CLK_IGNORE_UNUSED flag.
> */
> - init.flags = CLK_IGNORE_UNUSED;
> + init.flags = CLK_SET_RATE_GATE | CLK_SET_RATE_PARENT |
> + CLK_IGNORE_UNUSED;
>
> sys->id = id;
> sys->hw.init = &init;
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 2/3] clk: at91: replace prog clk round_rate with determine_rate
From: Nicolas Ferre @ 2014-02-04 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-3-git-send-email-b.brezillon@overkiz.com>
On 03/02/2014 12:25, Boris BREZILLON :
> Implement the determine_rate callback to choose the best parent clk that
> fulfills the requested rate.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Nice feature, thanks!
> ---
> drivers/clk/at91/clk-programmable.c | 56 +++++++++++++++++------------------
> 1 file changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 02f62a0..8e242c7 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -105,40 +105,40 @@ static unsigned long clk_programmable_recalc_rate(struct clk_hw *hw,
> return parent_rate >> prog->pres;
> }
>
> -static long clk_programmable_round_rate(struct clk_hw *hw, unsigned long rate,
> - unsigned long *parent_rate)
> +static long clk_programmable_determine_rate(struct clk_hw *hw,
> + unsigned long rate,
> + unsigned long *best_parent_rate,
> + struct clk **best_parent_clk)
> {
> - unsigned long best_rate = *parent_rate;
> - unsigned long best_diff;
> - unsigned long new_diff;
> - unsigned long cur_rate;
> - int shift = shift;
> -
> - if (rate > *parent_rate)
> - return *parent_rate;
> - else
> - best_diff = *parent_rate - rate;
> -
> - if (!best_diff)
> - return best_rate;
> + struct clk *parent = NULL;
> + long best_rate = -EINVAL;
> + unsigned long parent_rate;
> + unsigned long tmp_rate;
> + int shift;
> + int i;
>
> - for (shift = 1; shift < PROG_PRES_MASK; shift++) {
> - cur_rate = *parent_rate >> shift;
> + for (i = 0; i < __clk_get_num_parents(hw->clk); i++) {
> + parent = clk_get_parent_by_index(hw->clk, i);
> + if (!parent)
> + continue;
>
> - if (cur_rate > rate)
> - new_diff = cur_rate - rate;
> - else
> - new_diff = rate - cur_rate;
> + parent_rate = __clk_get_rate(parent);
> + for (shift = 0; shift < PROG_PRES_MASK; shift++) {
> + tmp_rate = parent_rate >> shift;
> + if (tmp_rate <= rate)
> + break;
> + }
>
> - if (!new_diff)
> - return cur_rate;
> + if (tmp_rate > rate)
> + continue;
>
> - if (new_diff < best_diff) {
> - best_diff = new_diff;
> - best_rate = cur_rate;
> + if (best_rate < 0 || (rate - tmp_rate) < (rate - best_rate)) {
> + best_rate = tmp_rate;
> + *best_parent_rate = parent_rate;
> + *best_parent_clk = parent;
> }
>
> - if (rate > cur_rate)
> + if (!best_rate)
> break;
> }
>
> @@ -231,7 +231,7 @@ static const struct clk_ops programmable_ops = {
> .prepare = clk_programmable_prepare,
> .is_prepared = clk_programmable_is_ready,
> .recalc_rate = clk_programmable_recalc_rate,
> - .round_rate = clk_programmable_round_rate,
> + .determine_rate = clk_programmable_determine_rate,
> .get_parent = clk_programmable_get_parent,
> .set_parent = clk_programmable_set_parent,
> .set_rate = clk_programmable_set_rate,
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 1/3] clk: at91: fix programmable clk irq handling
From: Nicolas Ferre @ 2014-02-04 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391426731-9392-2-git-send-email-b.brezillon@overkiz.com>
On 03/02/2014 12:25, Boris BREZILLON :
> The prog irq is a level irq reflecting the prog clk status. As a result the
> irq line will stay high when the prog clk is ready and the system will
> hang.
> Disable the irq when it is handled to avoid this problem.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/clk/at91/clk-programmable.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index fd792b2..02f62a0 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -55,6 +55,7 @@ static irqreturn_t clk_programmable_irq_handler(int irq, void *dev_id)
> struct clk_programmable *prog = (struct clk_programmable *)dev_id;
>
> wake_up(&prog->wait);
> + disable_irq_nosync(prog->irq);
>
> return IRQ_HANDLED;
> }
> @@ -74,8 +75,10 @@ static int clk_programmable_prepare(struct clk_hw *hw)
>
> pmc_write(pmc, AT91_PMC_PCKR(id), tmp);
>
> - while (!(pmc_read(pmc, AT91_PMC_SR) & mask))
> + while (!(pmc_read(pmc, AT91_PMC_SR) & mask)) {
> + enable_irq(prog->irq);
> wait_event(prog->wait, pmc_read(pmc, AT91_PMC_SR) & mask);
> + }
>
> return 0;
> }
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Nicolas Ferre @ 2014-02-04 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391502105-24612-1-git-send-email-jjhiblot@traphandler.com>
On 04/02/2014 09:21, Jean-Jacques Hiblot :
> The name provided to request_irq() must be valid until the irq is released.
> This patch stores the name in the internal data structure.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks. Bye,
> ---
> drivers/clk/at91/clk-programmable.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 8e242c7..799b75c 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -44,6 +44,7 @@ struct clk_programmable {
> u8 css;
> u8 pres;
> u8 slckmck;
> + char irq_name[11];
> const struct clk_programmable_layout *layout;
> };
>
> @@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> struct clk_programmable *prog;
> struct clk *clk = NULL;
> struct clk_init_data init;
> - char irq_name[11];
>
> if (id > PROG_ID_MAX)
> return ERR_PTR(-EINVAL);
> @@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> prog->irq = irq;
> init_waitqueue_head(&prog->wait);
> irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
> - snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
> + snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
> ret = request_irq(prog->irq, clk_programmable_irq_handler,
> - IRQF_TRIGGER_HIGH, irq_name, prog);
> + IRQF_TRIGGER_HIGH, prog->irq_name, prog);
> if (ret)
> return ERR_PTR(ret);
>
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-04 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqL+3S8w=_Fb-t0rVcq0sDiPSDM6nqn3mR2DHKw=VTffsg@mail.gmail.com>
On Monday 03 February 2014 17:07:48 Rob Herring wrote:
> On Mon, Feb 3, 2014 at 2:05 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> You might want to re-read the SBSA. Unless ARM provides an IP block or
> there is some other standard such as EHCI or AHCI, there is no generic
> implementation. You only have to go look at the Linux EHCI or AHCI
> drivers and see how meaningless and inadequate "use EHCI" is. For PCI,
> the text is so brief in the SBSA there will be no way PCI is going to
> just work given all the variations of root complexes, bridges, address
> windows, etc. we typically see on ARM platforms. I could be wrong and
> some AML magic will solve all the problems.
I don't think you need any AML, and SBSA seems to cover the PCI case
just fine, though I have to agree that the EHCI/AHCI/xHCI part is
rather ambiguous. What the existing PCI host controller drivers do is
essentially:
1. provide a config space access method
2. set up the I/O and memory address windows
3. set up clocks, PHYs etc
4. work around any deviations from the PCI standard
5. provide an MSI/MSI-X controller
For all I can tell, any SBSA compliant system should handle
those four like this:
1. config space is ECAM compliant, we only need to pass the
location in DT. (SBSA 8.1)
2. all address windows are set up by the boot loader, we only
need to know the location (IMHO this should be the
preferred way to do things regardless of SBSA).
3. any external hardware dependencies are set up statically
by the boot loader and are operational as we enter the
kernel.
4. deviations from PCI are not allowed (SBSA 8.8)
5. MSI has to be handled by GICv3 (SBSA 8.3.2)
So I definitely expect SBSA compliant systems to work fine with a
very simple generic PCI host bridge driver (which is likely what
Liviu has implemented and waiting for approval to submit).
The more important question is what systems will actually be
compliant with the above. X-Gene manages to get all five wrong,
for instance, and so would any system that reuses the existing
PCI hardware (alphabetically: exynos, imx6, mvebu, rcar-gen2,
tegra, designware), although points 2 and 3 are a question of
the boot loader, and it's possible that the designware based ones
get point 4 right.
Arnd
^ permalink raw reply
* [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Maxime Ripard @ 2014-02-04 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EFF96A.1020302@linaro.org>
Hi,
On Mon, Feb 03, 2014 at 09:17:46PM +0100, Daniel Lezcano wrote:
> On 02/03/2014 08:45 PM, Maxime Ripard wrote:
> >Hi Daniel,
> >
> >(Adding DT mailing-list in CC)
> >
> >On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
> >>On 02/02/2014 02:37 PM, Maxime Ripard wrote:
> >>>The Allwinner A10 compatibles were following a slightly different compatible
> >>>patterns than the rest of the SoCs for historical reasons. Add compatibles
> >>>matching the other pattern to the timer driver for consistency, and keep the
> >>>older one for backward compatibility.
> >>
> >>Hi Maxime,
> >>
> >>is it really needed to keep the old pattern ?
> >
> >We agreed during the ARM Kernel Summit to consider the DT as a stable
> >ABI.
> >
> >While I'd be ok with removing the older ones, that also means that we
> >would break the boot of newer kernels with older DT, so yes, we
> >actually need to keep the old compatibles.
>
> Thanks for the clarification.
>
> So these old compatibles will stay there 'ad vitam aeternam', right ?
Except for what Rob told, yep, that was my feeling, but Gregory and I
seem to have a different interpretation of this rule :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/418b5e4f/attachment-0001.sig>
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-04 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203213658.GA24036@e106497-lin.cambridge.arm.com>
On Monday 03 February 2014 21:36:58 Liviu Dudau wrote:
> On Mon, Feb 03, 2014 at 08:05:56PM +0000, Arnd Bergmann wrote:
> > On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
> > > So ... defining it should mean no legacy ISA devices, right?
> >
> > I would read that comment as referring to systems that don't have
> > any I/O space. If you have PCI, you can by definition have ISA
> > compatible devices behind a bridge. A typical example would be
> > a VGA card that supports the 03c0-03df port range.
>
> But if you have PCI and don't want to support ISA do you have /dev/port? I guess yes.
Right, that is my interpretation. You could still have a tool
that tries to poke /dev/port from user space for any I/O BAR
the same way you'd use /dev/mem for memory BARs of PCI devices.
It's discouraged, but it's often the easiest solution for
a quick hack, and I'd expect tools to use this.
> > > > > #define IO_SPACE_LIMIT 0xffff
> > > >
> > > > You probably want to increase this a bit, to allow multiple host bridges
> > > > to have their own I/O space.
> > >
> > > OK, but to what size?
> >
> > 2 MB was a compromise on arm32 to allow up to 32 PCI host bridges but not
> > take up too much virtual space. On arm64 it should be at least as big.
> > Could be more than that, although I don't see a reason why it should be,
> > unless we expect to see systems with tons of host bridges, or buses
> > that exceed 64KB of I/O space.
>
> I will increase the size to 2MB for v2.
Thinking about this some more, I'd go a little higher. In case of
pci_mv, we already register a 1MB region for one logical host
(which has multiple I/O spaces behind an emulated bridge), so
going to 16MB or more would let us handle multiple 1MB windows
for some amount of future proofing.
Maybe Catalin can assign us some virtual address space to use,
with the constraints that it should be 16MB or more in an
area that doesn't require additional kernel page table pages.
> > > > > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> > > > > +#define ioport_unmap(addr)
> > > >
> > > > inline functions?
> > >
> > > Will do, thanks!
> >
> > I suppose you can actually use the generic implementation from
> > asm-generic/io.h, and fix it by using the definition you have
> > above, since it's currently broken.
>
> Not exactly broken, but it makes the assumption that your IO space starts at
> physical address zero and you have not remapped it. It does guard the
> definition with #ifndef CONFIG_GENERIC_IOMAP after all, so it does not
> expect to be generic :)
Well, I/O space never starts at physical zero in reality, so it is
broken in practice. The CONFIG_GENERIC_IOMAP option tries to solve
the problem of I/O spaces that are not memory mapped, which is
actually quite rare (x86, ia64, some rare powerpc bridges, and possibly
Alpha). The norm is that if you have I/O space, it is memory mapped
and you don't need GENERIC_IOMAP. I think most of the architectures
selecting GENERIC_IOMAP have incorrectly copied that from x86.
> > > > > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> > > > > new file mode 100644
> > > > > index 0000000..dd084a3
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/include/asm/pci.h
> > > > > @@ -0,0 +1,35 @@
> > > > > +#ifndef __ASM_PCI_H
> > > > > +#define __ASM_PCI_H
> > > > > +#ifdef __KERNEL__
> > > > > +
> > > > > +#include <linux/types.h>
> > > > > +#include <linux/slab.h>
> > > > > +#include <linux/dma-mapping.h>
> > > > > +
> > > > > +#include <asm/io.h>
> > > > > +#include <asm-generic/pci-bridge.h>
> > > > > +#include <asm-generic/pci-dma-compat.h>
> > > > > +
> > > > > +#define PCIBIOS_MIN_IO 0
> > > > > +#define PCIBIOS_MIN_MEM 0
> > > >
> > > > PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.
> > >
> > > :) No ISA support! (Die ISA, die!!)
> >
> > If only it were that easy.
>
> Lets try! :)
>
> I wonder how many active devices that have an ISA slot are still supported
> by mainline kernel.
This is missing the point, but any architecture that has a PCI
slot can have an ISA device behind a bridge like this:
http://www.altera.com/products/ip/iup/pci/m-eur-pci-to-isa.html
The real reason is that a lot of PCI cards for practical reasons
expose some non-relocatable memory and I/O BARs in ISA-compatible
locations. Looking at /proc/ioports on my PC, I can spot a couple
of things that may well show up on any ARM machine:
0000-03af : PCI Bus 0000:00
02f8-02ff : serial
03c0-03df : PCI Bus 0000:40
03c0-03df : PCI Bus 0000:00
03c0-03df : vga+
03e0-0cf7 : PCI Bus 0000:00
03e8-03ef : serial
03f8-03ff : serial
0b00-0b0f : pnp 00:08
0b00-0b07 : piix4_smbus
0b20-0b3f : pnp 00:08
0b20-0b27 : piix4_smbus
0ca2-0ca3 : pnp 00:08
0ca2-0ca2 : ipmi_si
0ca3-0ca3 : ipmi_si
0cf8-0cff : PCI conf1
Nothing wrong with the above. Now, it's also possible that
someone decides to build an ARM server by using a PC south
bridge with integrated legacy PC peripherals, such as these:
0000-03af : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00b0-00b0 : APEI ERST
00c0-00df : dma2
00f0-00ff : fpu
There is some hope that it won't happen, but these things
exist and come with a regular PCIe front-end bus in some
cases.
Finally, there is the LPC bus, which can give you additional
ISAPnP compatible devices.
> I will update PCIBIOS_MIN_xxxx to match arch/arm for v2.
Ok.
> > > > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > > > new file mode 100644
> > > > > index 0000000..7b652cf
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/kernel/pci.c
> > > > > @@ -0,0 +1,112 @@
> > > >
> > > > None of this looks really arm64 specific, nor should it be. I think
> > > > we should try a little harder to move this as a default implementation
> > > > into common code, even if we start out by having all architectures
> > > > override it.
> > >
> > > Agree. This is the RFC version. I didn't dare to post a patch with fixes
> > > for all architectures. :)
> >
> > No need to change the other architectures. You can make it opt-in for
> > now and just put the code into a common location.
> >
> > An interesting question however is what the transition plan is to
> > have the code shared between arm32 and arm64: We will certainly need
> > to share at least the dw-pcie and the generic SBSA compliant pci
> > implementation.
>
> My vote would be for updating the host controllers to the new API and
> to offer the CONFIG option to choose between arch APIs. The alternative
> is to use the existing API to wrap the generic implementation.
The problem with an either/or CONFIG option is that it breaks
multiplatform support. A lot of the arm32 PCI implementations
are only used on platforms that are not multiplatform enabled
though, so we could get away by requiring all multiplatform
configurations to use the new API.
> My main concern with the existing API is the requirement to have a subsys_initcall
> in your host bridge or mach code, due to the way the initialisation is done (you
> need the DT code to probe your driver, but you cannot start the scanning of the
> PCI bus until the arch code is initialised, so it gets deferred via
> subsys_initcall when it calls pci_common_init). I bet that if one tries to
> instantiate a Tegra PCI host bridge controller on a Marvell platform things will
> break pretty quickly (random example here).
I'm not following here. All the new host controller drivers should
be platform drivers that only bind to the host devices in DT
that are present. Both mvebu and tegra use a normal "module_platform_driver"
for initialization, not a "subsys_initcall".
> > Something like this (coded in mail client, don't try to compile):
> >
> > #define IO_SPACE_PAGES (IO_SPACE_LIMIT + 1) / PAGE_SIZE)
> > static DECLARE_BITMAP(pci_iospace, IO_SPACE_PAGES);
> > unsigned long pci_ioremap_io(const struct resource *bus, const struct resource phys)
> > {
> > unsigned long start, len, virt_start;
> > int error;
> >
> > /* use logical address == bus address if possible */
> > start = bus->start / PAGE_SIZE;
> > if (start > IO_SPACE_LIMIT / PAGE_SIZE)
> > start = 0;
> >
> > /*
> > * try finding free space for the whole size first,
> > * fall back to 64K if not available
> > */
> > len = min(resource_size(bus), resource_size(phys);
> > start = bitmap_find_next_zero_area(pci_iospace, IO_SPACE_PAGES,
> > start, len / PAGE_SIZE, 0);
> > if (start == IO_SPACE_PAGES && len > SZ_64K)
> > len = SZ_64K;
> > start = 0;
> > start = bitmap_find_next_zero_area(pci_iospace, IO_SPACE_PAGES,
> > start, len / PAGE_SIZE, 0);
> > }
> >
> > /* no 64K area found */
> > if (start == IO_SPACE_PAGES)
> > return -ENOMEM;
> >
> > /* ioremap physical aperture to virtual aperture */
> > virt_start = start * PAGE_SIZE + (unsigned long)PCI_IOBASE;
> > error = ioremap_page_range(virt_start, virt_start + len,
> > phys->start, __pgprot(PROT_DEVICE_nGnRE));
> > if (error)
> > return error;
> >
> > bitmap_set(start, len / PAGE_SIZE);
> >
> > /* return io_offset */
> > return start * PAGE_SIZE - bus->start;
> > }
> > EXPORT_SYMBOL_GPL(pci_ioremap_io);
> >
> > Arnd
> >
>
> I see. I need to think how this will change the existing code. Current users
> of pci_ioremap_io ask for multiples of SZ_64K offsets regardless of the
> actual need.
Right. I guess we can support both interfaces on ARM32 for the forseeable
future (renaming the new one) and just change the existing implementation
to update the bitmap. Any cross-platform host controller driver would
have to use the new interface however.
Arnd
^ permalink raw reply
* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Boris BREZILLON @ 2014-02-04 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391502105-24612-1-git-send-email-jjhiblot@traphandler.com>
Hello JJ,
Sorry for the noise (I added Mike in the CC list).
BTW, thanks for fixing this bug.
Mike, could you take this bug fix for the next 3.14 release ?
Best Regards,
Boris
On 04/02/2014 09:21, Jean-Jacques Hiblot wrote:
> The name provided to request_irq() must be valid until the irq is released.
> This patch stores the name in the internal data structure.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
> drivers/clk/at91/clk-programmable.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 8e242c7..799b75c 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -44,6 +44,7 @@ struct clk_programmable {
> u8 css;
> u8 pres;
> u8 slckmck;
> + char irq_name[11];
> const struct clk_programmable_layout *layout;
> };
>
> @@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> struct clk_programmable *prog;
> struct clk *clk = NULL;
> struct clk_init_data init;
> - char irq_name[11];
>
> if (id > PROG_ID_MAX)
> return ERR_PTR(-EINVAL);
> @@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> prog->irq = irq;
> init_waitqueue_head(&prog->wait);
> irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
> - snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
> + snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
> ret = request_irq(prog->irq, clk_programmable_irq_handler,
> - IRQF_TRIGGER_HIGH, irq_name, prog);
> + IRQF_TRIGGER_HIGH, prog->irq_name, prog);
> if (ret)
> return ERR_PTR(ret);
>
^ permalink raw reply
* [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Maxime Ripard @ 2014-02-04 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJuSS1Hh8Fb26PMKBB_uKmLuiqnZJjz0zvt1Ux7P8cCzw@mail.gmail.com>
Hi Rob,
On Mon, Feb 03, 2014 at 02:11:28PM -0600, Rob Herring wrote:
> On Mon, Feb 3, 2014 at 1:45 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi Daniel,
> >
> > (Adding DT mailing-list in CC)
> >
> > On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
> >> On 02/02/2014 02:37 PM, Maxime Ripard wrote:
> >> >The Allwinner A10 compatibles were following a slightly different compatible
> >> >patterns than the rest of the SoCs for historical reasons. Add compatibles
> >> >matching the other pattern to the timer driver for consistency, and keep the
> >> >older one for backward compatibility.
> >>
> >> Hi Maxime,
> >>
> >> is it really needed to keep the old pattern ?
> >
> > We agreed during the ARM Kernel Summit to consider the DT as a stable
> > ABI.
> >
> > While I'd be ok with removing the older ones, that also means that we
> > would break the boot of newer kernels with older DT, so yes, we
> > actually need to keep the old compatibles.
>
> It all depends if that would really cause problems for a given
> platform. So if Allwinner DT support is a moving target, then changing
> is probably okay. For example, if anyone using the platform is going
> to need to update their DTB to add more nodes to get various features
> anyway, then breaking it is not all that important.
We keep adding new stuff to the DT, yes, so I guess we can be
considered a moving target. Thanks for your input!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/b4f57920/attachment.sig>
^ permalink raw reply
* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Boris BREZILLON @ 2014-02-04 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391502105-24612-1-git-send-email-jjhiblot@traphandler.com>
On 04/02/2014 09:21, Jean-Jacques Hiblot wrote:
> The name provided to request_irq() must be valid until the irq is released.
> This patch stores the name in the internal data structure.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
> drivers/clk/at91/clk-programmable.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 8e242c7..799b75c 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -44,6 +44,7 @@ struct clk_programmable {
> u8 css;
> u8 pres;
> u8 slckmck;
> + char irq_name[11];
> const struct clk_programmable_layout *layout;
> };
>
> @@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> struct clk_programmable *prog;
> struct clk *clk = NULL;
> struct clk_init_data init;
> - char irq_name[11];
>
> if (id > PROG_ID_MAX)
> return ERR_PTR(-EINVAL);
> @@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> prog->irq = irq;
> init_waitqueue_head(&prog->wait);
> irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
> - snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
> + snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
> ret = request_irq(prog->irq, clk_programmable_irq_handler,
> - IRQF_TRIGGER_HIGH, irq_name, prog);
> + IRQF_TRIGGER_HIGH, prog->irq_name, prog);
> if (ret)
> return ERR_PTR(ret);
>
^ permalink raw reply
* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Jean-Jacques Hiblot @ 2014-02-04 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391445961-20755-1-git-send-email-jjhiblot@traphandler.com>
The name provided to request_irq() must be valid until the irq is released.
This patch stores the name in the internal data structure.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
---
drivers/clk/at91/clk-programmable.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
index 8e242c7..799b75c 100644
--- a/drivers/clk/at91/clk-programmable.c
+++ b/drivers/clk/at91/clk-programmable.c
@@ -44,6 +44,7 @@ struct clk_programmable {
u8 css;
u8 pres;
u8 slckmck;
+ char irq_name[11];
const struct clk_programmable_layout *layout;
};
@@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
struct clk_programmable *prog;
struct clk *clk = NULL;
struct clk_init_data init;
- char irq_name[11];
if (id > PROG_ID_MAX)
return ERR_PTR(-EINVAL);
@@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
prog->irq = irq;
init_waitqueue_head(&prog->wait);
irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
- snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
+ snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
ret = request_irq(prog->irq, clk_programmable_irq_handler,
- IRQF_TRIGGER_HIGH, irq_name, prog);
+ IRQF_TRIGGER_HIGH, prog->irq_name, prog);
if (ret)
return ERR_PTR(ret);
--
1.8.5.2
^ permalink raw reply related
* [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Gregory CLEMENT @ 2014-02-04 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EFF96A.1020302@linaro.org>
Hi Daniel,
On 03/02/2014 21:17, Daniel Lezcano wrote:
> On 02/03/2014 08:45 PM, Maxime Ripard wrote:
>> Hi Daniel,
>>
>> (Adding DT mailing-list in CC)
>>
>> On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
>>> On 02/02/2014 02:37 PM, Maxime Ripard wrote:
>>>> The Allwinner A10 compatibles were following a slightly different compatible
>>>> patterns than the rest of the SoCs for historical reasons. Add compatibles
>>>> matching the other pattern to the timer driver for consistency, and keep the
>>>> older one for backward compatibility.
>>>
>>> Hi Maxime,
>>>
>>> is it really needed to keep the old pattern ?
>>
>> We agreed during the ARM Kernel Summit to consider the DT as a stable
>> ABI.
>>
>> While I'd be ok with removing the older ones, that also means that we
>> would break the boot of newer kernels with older DT, so yes, we
>> actually need to keep the old compatibles.
>
> Thanks for the clarification.
>
> So these old compatibles will stay there 'ad vitam aeternam', right ?
>From what I have understood during the ARM Kernel Summit, it was
acceptable to remove them after a few release.
Gregory
>
>
>>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>>> ---
>>>> Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt | 5 +++--
>>>> drivers/clocksource/sun4i_timer.c | 4 ++++
>>>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
>>>> index 48aeb78..d9e35ae 100644
>>>> --- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
>>>> +++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
>>>> @@ -2,7 +2,8 @@ Allwinner A1X SoCs Timer Controller
>>>>
>>>> Required properties:
>>>>
>>>> -- compatible : should be "allwinner,sun4i-timer"
>>>> +- compatible : should be "allwinner,sun4i-a10-timer"
>>>> + (Deprecated "allwinner,sun4i-timer")
>>>> - reg : Specifies base physical address and size of the registers.
>>>> - interrupts : The interrupt of the first timer
>>>> - clocks: phandle to the source clock (usually a 24 MHz fixed clock)
>>>> @@ -10,7 +11,7 @@ Required properties:
>>>> Example:
>>>>
>>>> timer {
>>>> - compatible = "allwinner,sun4i-timer";
>>>> + compatible = "allwinner,sun4i-a10-timer";
>>>> reg = <0x01c20c00 0x400>;
>>>> interrupts = <22>;
>>>> clocks = <&osc>;
>>>> diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
>>>> index bf497af..de03895 100644
>>>> --- a/drivers/clocksource/sun4i_timer.c
>>>> +++ b/drivers/clocksource/sun4i_timer.c
>>>> @@ -196,5 +196,9 @@ static void __init sun4i_timer_init(struct device_node *node)
>>>> clockevents_config_and_register(&sun4i_clockevent, rate,
>>>> TIMER_SYNC_TICKS, 0xffffffff);
>>>> }
>>>> +CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
>>>> + sun4i_timer_init);
>>>> +
>>>> +/* Deprecated */
>>>> CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-timer",
>>>> sun4i_timer_init);
>>>>
>>>
>>>
>>> --
>>> <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>>>
>>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>>
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/8] ARM: shmobile: Conditionally select SMSC_PHY
From: Simon Horman @ 2014-02-04 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389084488-25984-1-git-send-email-horms+renesas@verge.net.au>
On Tue, Jan 07, 2014 at 05:48:00PM +0900, Simon Horman wrote:
> Select the SMSC_PHY if ethernet is enabled on shmbile boards
> that have an SMSC phy. This allows the SMSC-specific phy driver
> to be used rather than relying on generic phy code.
>
> Based on the renesas-devel-v3.13-rc7-20140107 tag
> of my renesas tree.
>
> Simon Horman (8):
> ARM: shmobile: ape6evm: Conditionally select SMSC_PHY
> ARM: shmobile: armadillo800eva: Conditionally select SMSC_PHY
> ARM: shmobile: bockw: Sort Kconfig node's selections
> ARM: shmobile: bockw: Conditionally select SMSC_PHY
> ARM: shmobile: kzm9d: Conditionally select SMSC_PHY
> ARM: shmobile: kzm9g: Conditionally select SMSC_PHY
> ARM: shmobile: mackerel: Conditionally select SMSC_PHY
> ARM: shmobile: marzen: Conditionally select SMSC_PHY
>
> arch/arm/mach-shmobile/Kconfig | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
To my surprise I have discovered that the bockw and kzm9g boards
do not boot using NFS root if SMSC_PHY enabled. I have dropped
the SMSC_PHY patches for those boards pending investigation.
^ permalink raw reply
* [PATCH] regulator: core: Make regulator object reflect configured voltage
From: Bjorn Andersson @ 2014-02-04 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In the case when a regulator is initialized from DT with equal min and max
voltages the voltage is applied on initialization and future calls to
regulator_set_voltage fails. This behavious is different than if the regulator
is configured to be a span and therefor requires logic to handle this
difference in the consumer driver.
Eliminate this difference by populating the min_uV and max_uV of the newly
created regulator from the constraints so that calles to regulator_set_voltage
is considered no-ops and not a failure.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
---
drivers/regulator/core.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d85f313..9c82d37 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1209,6 +1209,16 @@ static struct regulator *create_regulator(struct regulator_dev *rdev,
_regulator_is_enabled(rdev))
regulator->always_on = true;
+ /*
+ * Make the regulator reflect the configured voltage selected in
+ * machine_constraints_voltage()
+ */
+ if (rdev->constraints->apply_uV &&
+ rdev->constraints->min_uV == rdev->constraints->max_uV) {
+ regulator->min_uV = rdev->constraints->min_uV;
+ regulator->max_uV = rdev->constraints->min_uV;
+ }
+
mutex_unlock(&rdev->mutex);
return regulator;
overflow_err:
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Vinod Koul @ 2014-02-04 5:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+mB=1LyX0_VVXZQ-=m3gR2RBeumLrnPTUW3j+Zm1nj7a4exHg@mail.gmail.com>
On Fri, Jan 31, 2014 at 12:22:52PM +0530, Srikanth Thokala wrote:
> >>> >> [...]
> >>> >>> +/**
> >>> >>> + * xilinx_vdma_device_control - Configure DMA channel of the device
> >>> >>> + * @dchan: DMA Channel pointer
> >>> >>> + * @cmd: DMA control command
> >>> >>> + * @arg: Channel configuration
> >>> >>> + *
> >>> >>> + * Return: '0' on success and failure value on error
> >>> >>> + */
> >>> >>> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
> >>> >>> + enum dma_ctrl_cmd cmd, unsigned long arg)
> >>> >>> +{
> >>> >>> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> >>> >>> +
> >>> >>> + switch (cmd) {
> >>> >>> + case DMA_TERMINATE_ALL:
> >>> >>> + xilinx_vdma_terminate_all(chan);
> >>> >>> + return 0;
> >>> >>> + case DMA_SLAVE_CONFIG:
> >>> >>> + return xilinx_vdma_slave_config(chan,
> >>> >>> + (struct xilinx_vdma_config *)arg);
> >>> >>
> >>> >> You really shouldn't be overloading the generic API with your own semantics.
> >>> >> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
> >>> >
> >>> > Ok. The driver needs few additional configuration from the slave
> >>> > device like Vertical
> >>> > Size, Horizontal Size, Stride etc., for the DMA transfers, in that case do you
> >>> > suggest me to define a separate dma_ctrl_cmd like the one FSLDMA_EXTERNAL_START
> >>> > defined for Freescale drivers?
> >>>
> >>> In my opinion it is not a good idea to have driver implement a generic API,
> >>> but at the same time let the driver have custom semantics for those API
> >>> calls. It's a bit like having a gpio driver that expects 23 and 42 as the
> >>> values passed to gpio_set_value instead of 0 and 1. It completely defeats
> >>> the purpose of a generic API, namely that you are able to write generic code
> >>> that makes use of the API without having to know about which implementation
> >>> API it is talking to. The dmaengine framework provides the
> >>> dmaengine_prep_interleaved_dma() function to setup two dimensional
> >>> transfers, e.g. take a look at sirf-dma.c or imx-dma.c.
> >>
> >> The question here i think would be waht this device supports? Is the hardware
> >> capable of doing interleaved transfers, then would make sense.
> >>
> >> While we do try to get users use dma_slave_config, but there will always be
> >> someone who have specfic params. If we can generalize then we might want to add
> >> to the dma_slave_config as well
> >
> > There are many configuration parameters which are specific to IP and I
> > would like to
> > give an overview of some of parameteres here:
> >
> > 1) Park Mode ('cfg->park'): In Park mode, engine will park on frame
> > referenced by
> > 'cfg->park_frm', so user will have control on each frame in this mode.
> >
> > 2) Interrupt Coalesce ('cfg->coalesce'): Used for setting interrupt
> > threshold. This value
> > determines the number of frame buffers to process. To use this feature,
> > 'cfg->frm_cnt_en' should be set.
> >
> > 3) Frame Synchronization Source ('cfg->ext_fsync'): Can be an
> > external/internal frame
> > synchronization source. Used to synchronize one channel (MM2S/S2MM) with
> > another (S2MM/MM2S) channel.
> >
> > 4) Genlock Synchronization ('cfg->genlock'): Used to avoid mismatch rate between
> > master and slave. In master mode (cfg->master), frames are not dropped and
> > slave can drop frames to adjust to master frame rate.
> >
> > And in future, this Engine being a soft IP, we could expect some more additional
> > parameters. Isn't a good idea to have a private member in dma_slave_config for
> > sharing additional configuration between slave device and dma engine? Or a new
> > dma_ctrl_cmd like FSLDMA_EXTERNAL_START?
The idea of a generic API is that we can use it for most of the controllers. Even
if you are planning to support a family of controllers
ATM, lets not discuss the possiblity of private member and try to exhanust all
possible options. Worst case you can embed the dma_slave_config in
xilinx_dma_slave_config and retrieve it in dmac driver
--
~Vinod
^ permalink raw reply
* [PATCH] dma: mv_xor: Silence a bunch of LPAE-related warnings
From: Vinod Koul @ 2014-02-04 5:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391476403-26099-1-git-send-email-olof@lixom.net>
On Mon, Feb 03, 2014 at 05:13:23PM -0800, Olof Johansson wrote:
> Enabling some of the mvebu platforms in the multiplatform config for ARM
> enabled these drivers, which also triggered a bunch of warnings when LPAE
> is enabled (thus making phys_addr_t 64-bit).
>
> Most changes are switching printk formats, but also a bit of changes to what
> used to be array-based pointer arithmetic that could just be done with the
> address types instead.
>
> The warnings were:
>
> drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
> drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
> 'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
> drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
> drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
> different size [-Wint-to-pointer-cast]
> drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
> different size [-Wpointer-to-int-cast]
> drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
> drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
> 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
> drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
> 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
> drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
> drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
> 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/mv_xor.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
> index 53fb0c8365b0..766b68ed505c 100644
> --- a/drivers/dma/mv_xor.c
> +++ b/drivers/dma/mv_xor.c
> @@ -497,8 +497,8 @@ mv_xor_tx_submit(struct dma_async_tx_descriptor *tx)
> if (!mv_can_chain(grp_start))
> goto submit_done;
>
> - dev_dbg(mv_chan_to_devp(mv_chan), "Append to last desc %x\n",
> - old_chain_tail->async_tx.phys);
> + dev_dbg(mv_chan_to_devp(mv_chan), "Append to last desc %pa\n",
> + &old_chain_tail->async_tx.phys);
>
> /* fix up the hardware chain */
> mv_desc_set_next_desc(old_chain_tail, grp_start->async_tx.phys);
> @@ -527,7 +527,8 @@ submit_done:
> /* returns the number of allocated descriptors */
> static int mv_xor_alloc_chan_resources(struct dma_chan *chan)
> {
> - char *hw_desc;
> + void *virt_desc;
> + dma_addr_t dma_desc;
> int idx;
> struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
> struct mv_xor_desc_slot *slot = NULL;
> @@ -542,17 +543,16 @@ static int mv_xor_alloc_chan_resources(struct dma_chan *chan)
> " %d descriptor slots", idx);
> break;
> }
> - hw_desc = (char *) mv_chan->dma_desc_pool_virt;
> - slot->hw_desc = (void *) &hw_desc[idx * MV_XOR_SLOT_SIZE];
> + virt_desc = mv_chan->dma_desc_pool_virt;
> + slot->hw_desc = virt_desc + idx * MV_XOR_SLOT_SIZE;
>
> dma_async_tx_descriptor_init(&slot->async_tx, chan);
> slot->async_tx.tx_submit = mv_xor_tx_submit;
> INIT_LIST_HEAD(&slot->chain_node);
> INIT_LIST_HEAD(&slot->slot_node);
> INIT_LIST_HEAD(&slot->tx_list);
> - hw_desc = (char *) mv_chan->dma_desc_pool;
> - slot->async_tx.phys =
> - (dma_addr_t) &hw_desc[idx * MV_XOR_SLOT_SIZE];
> + dma_desc = mv_chan->dma_desc_pool;
> + slot->async_tx.phys = dma_desc + idx * MV_XOR_SLOT_SIZE;
> slot->idx = idx++;
>
> spin_lock_bh(&mv_chan->lock);
> @@ -582,8 +582,8 @@ mv_xor_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
> int slot_cnt;
>
> dev_dbg(mv_chan_to_devp(mv_chan),
> - "%s dest: %x src %x len: %u flags: %ld\n",
> - __func__, dest, src, len, flags);
> + "%s dest: %pad src %pad len: %u flags: %ld\n",
> + __func__, &dest, &src, len, flags);
> if (unlikely(len < MV_XOR_MIN_BYTE_COUNT))
> return NULL;
>
> @@ -626,8 +626,8 @@ mv_xor_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
> BUG_ON(len > MV_XOR_MAX_BYTE_COUNT);
>
> dev_dbg(mv_chan_to_devp(mv_chan),
> - "%s src_cnt: %d len: dest %x %u flags: %ld\n",
> - __func__, src_cnt, len, dest, flags);
> + "%s src_cnt: %d len: %u dest %pad flags: %ld\n",
> + __func__, src_cnt, len, &dest, flags);
>
> spin_lock_bh(&mv_chan->lock);
> slot_cnt = mv_chan_xor_slot_count(len, src_cnt);
> --
> 1.8.4.1.601.g02b3b1d
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
^ permalink raw reply
* [PATCH 3/3] Phytec phyFLEX-i.MX6 : Added SATA Support
From: Ashutosh singh @ 2014-02-04 4:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for SATA on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh <ashutosh.s@phytec.in>
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 21c8b37..5607c33 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -25,6 +25,10 @@
status = "okay";
};
+&sata {
+ status = "okay";
+};
+
&uart4 {
status = "okay";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] Phytec phyFLEX-i.MX6 : Added GPMI-NAND Support
From: Ashutosh singh @ 2014-02-04 4:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for GPMI-NAND on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh <ashutosh.s@phytec.in>
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 4 ++++
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 7 +++++++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 91aecba..21c8b37 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -21,6 +21,10 @@
status = "okay";
};
+&gpmi {
+ status = "okay";
+};
+
&uart4 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index fb39dae..8787101 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -176,6 +176,13 @@
status = "disabled";
};
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand_1>;
+ nand-on-flash-bbt;
+ status = "disabled";
+};
+
&uart4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart4_1>;
--
1.7.9.5
^ permalink raw reply related
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