* [PATCH v4 0/8] Device Tree support for the at91sam9261ek
From: Thomas Petazzoni @ 2014-02-12 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FB5795.9020708@free-electrons.com>
Dear Gregory CLEMENT,
On Wed, 12 Feb 2014 12:14:29 +0100, Gregory CLEMENT wrote:
> For dm9000 the issue is (again) related to an ordering problem:
> the Ethernet need an interrupt provided by the gpio driver. Unfortunately,
> the gpio driver initialization is called after the dm900 driver
> initialization.
And -EPROBE_DEFER doesn't solve this problem?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 0/8] Device Tree support for the at91sam9261ek
From: Jean-Jacques Hiblot @ 2014-02-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FB5795.9020708@free-electrons.com>
Hi Greg,
2014-02-12 12:14 GMT+01:00 Gregory CLEMENT <gregory.clement@free-electrons.com>:
> Hi Jean-Jacques,
>
> On 12/02/2014 11:06, Jean-Jacques Hiblot wrote:
>> This patch set aims at bringing a device tree support for the sam9261.
>> It's mostly based on the sam9263 and sam9x5 stuff.
>>
>> Changes since V3:
>> * Added support for the touchscreen
>> * Added support for the spi dataflash
>> * Activated the TCB by default
>> * Reworked the patch organization to reduce the number of patchs
>> * changed the default bootargs (no mem description, UBI on mtdpart 5)
>> * Changed the xlate implementation of the at91 pinctrl driver to lock the GPIOs
>> for IRQs instead of requesting them (needed for the touchscreen driver)
>> * some stylistic changes
>>
>> Changes since V2:
>> * removed the smc driver from the serie. It'll be posted in an independent
>> serie later.
>> * removed the DM9000 support (it'll come with the smc driver)
>> * the sam9261 now supports the Common Clock Framework (CCF). Note: to enable
>> the CCF you must remove from the kernel config the platforms that don't
>> support it.
>> * Added basic DT binding for the bus matrix
>> * Added support for USB host
>> * Added support for USB gadget
>> * in dts(i), replaced interrupt-parent with interrupts-extended
>> * changed the nand partition plan (same as for the sama5d3)
>> * removed 'mem' parameter in command line
>> * re-ordered dt-nodes in ascending address order.
>> * split the lcd support patch in 2 parts (SOC and board)
>>
>>
>> Change since V1:
>> * changed the DT representation to use address translation and separate the
>> timings' configuration from the device properties by adding a "simple-bus"
>> inetrmediate node.
>> * moved the smc driver from drivers/bus to drivers/memmory
>> * smc driver now accepts timings in nanoseconds as well as raw register values
>> * smc driver can clip the timings if they're out of bound and dump them to the
>> console
>> * DM9000 timings are now described in nanosecs (for the virtue of example)
>>
>> supported features are:
>> * working with the Common Clock Framework and the old at91 clock implementation
>> * dbgu
>> * lcdc
>> * usb host
>> * usb gadget,
>> * spi dataflash
>> * nand flash
>> * touchscreen
>> * leds
>> * user buttons
>>
>> In the TODO list:
>> * dm9000 (ethernet)
>> * audio
>> * mmc
>
>
> Besides the my comment on the 1st patch, all this series
> seems pretty neat for me.
thanks
>
> It's worth mentioning also that audio and mmc are in the
> TODO list by lack of hardware to test it. So what I suggest
actually the audio hardware is present but seems broken on my board.
Hopefully I should get another one to test this week.
> here is to send a follow-up patch set and to ask for a
> Tested-By from people being able to test it.
>
> For dm9000 the issue is (again) related to an ordering problem:
> the Ethernet need an interrupt provided by the gpio driver. Unfortunately,
> the gpio driver initialization is called after the dm900 driver
> initialization.
>
> Thanks,
>
> Gregory
>
>
>
>>
>> This serie relies on the following patchs:
>> usb: at91-udc: fix irq and iomem resource retrieval
>> ARM: at91: prepare sam9 dt boards transition to common
>>
>> Jean-Jacques
>>
>> Jean-Jacques Hiblot (8):
>> at91: dt: Adds support for the bus matrix declaration in the DT
>> at91: pinctrl: don't request GPIOs used for interrupts but lock them
>> as IRQ
>> at91: dt: Add at91sam9261 dt SoC support
>> at91: dt: defconfig: Added the sam9261 to the list of DT-enabled SOCs
>> at91: dt: sam9261: Device Tree support for the at91sam9261ek
>> at91: updated the at91_dt_defconfig with support for the ADS7846
>> ARM: at91: prepare common clk transition for sam9261 SoC
>> ARM: at91: move sam9261 SoC to common clk
>>
>> arch/arm/boot/dts/Makefile | 2 +
>> arch/arm/boot/dts/at91sam9261.dtsi | 740 ++++++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/at91sam9261ek.dts | 204 ++++++++++
>> arch/arm/configs/at91_dt_defconfig | 2 +
>> arch/arm/mach-at91/Kconfig | 1 -
>> arch/arm/mach-at91/at91sam9261.c | 25 +-
>> arch/arm/mach-at91/setup.c | 23 ++
>> drivers/pinctrl/pinctrl-at91.c | 5 +-
>> 8 files changed, 996 insertions(+), 6 deletions(-)
>> create mode 100644 arch/arm/boot/dts/at91sam9261.dtsi
>> create mode 100644 arch/arm/boot/dts/at91sam9261ek.dts
>>
>
>
> --
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
^ permalink raw reply
* [PATCH v4 0/8] Device Tree support for the at91sam9261ek
From: Jean-Jacques Hiblot @ 2014-02-12 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212133449.5c42216d@skate>
Hi Thomas,
2014-02-12 13:34 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Dear Gregory CLEMENT,
>
> On Wed, 12 Feb 2014 12:14:29 +0100, Gregory CLEMENT wrote:
>
>> For dm9000 the issue is (again) related to an ordering problem:
>> the Ethernet need an interrupt provided by the gpio driver. Unfortunately,
>> the gpio driver initialization is called after the dm900 driver
>> initialization.
>
> And -EPROBE_DEFER doesn't solve this problem?
not really the problem happens before the driver is actually probed
when the ressource for the platform driver are filled
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH 00/11] ARM: dts: sbc-t3x: add support for more boards
From: Igor Grinberg @ 2014-02-12 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389532975-28281-1-git-send-email-lifshitz@compulab.co.il>
ping!
On 01/12/14 15:22, Dmitry Lifshitz wrote:
> Add support for CompuLab SBC-T3530 and SBC-T3517 boards:
>
> https://compulab.co.il/products/sbcs/sbc-t3530/
> https://compulab.co.il/products/sbcs/sbc-t3517/
>
> along with respective CoMs - CM-T3530 and CM-T3517:
>
> https://compulab.co.il/products/computer-on-modules/cm-t3530/
> https://compulab.co.il/products/computer-on-modules/cm-t3517/
>
> The device tree files have the following structure:
>
> omap3-cm-t3x.dtsi
> |
> |<-- omap3-cm-t3x30.dtsi
> | |
> | |
> | | ----- ------- ------------
> | | | CoM | | Board | | Base board |
> | | ----- ------- ------------
> | | omap3-sb-t35.dtsi
> | | |
> | |<-- omap3-cm-t3730.dts <-- omap3-sbc-t3730.dts -->|
> | | |
> | |<-- omap3-cm-t3530.dts <-- omap3-sbc-t3530.dts -->|
> | |
> |<-------- omap3-cm-t3517.dts <-- omap3-sbc-t3517.dts -->|
>
>
> where omap3-cm-t3730.dts, omap3-cm-t3530.dts, omap3-cm-t3517.dts
> contain CoMs specific data, while omap3-sbc-t3730.dts, omap3-sbc-t3530.dts,
> omap3-sbc-t3517.dts represent eval boards with respective core modules.
>
> This series is based on Tony's omap-for-v3.14/dt branch
>
> Dmitry Lifshitz (11):
> ARM: dts: sbc-t3x: refactor DT support
> ARM: dts: sbc-t3x: disable mmc3
> ARM: dts: sb-t35: fix Ethernet power supply
> ARM: dts: cm-t3x: add gpio-led pinmux
> ARM: dts: cm-t3x30: add twl4030 gpio pullups
> ARM: dts: cm-t3x30: add HS USB Host support
> ARM: dts: sbc-t3730: add pinmux for usb hub reset
> ARM: dts: cm-t3x30: add USB OTG support
> ARM: dts: sbc-t3530: add support for sbc-t3530
> ARM: dts: sbc-t3517: add support for sbc-t3517
> ARM: OMAP2+: make reset pulse for sbc-t3x usb hubs
>
> arch/arm/boot/dts/Makefile | 4 +
> arch/arm/boot/dts/omap3-cm-t3517.dts | 137 +++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/omap3-cm-t3530.dts | 13 +++
> arch/arm/boot/dts/omap3-cm-t3730.dts | 40 ----------
> arch/arm/boot/dts/omap3-cm-t3x.dtsi | 112 +++++++++++++++++++++++++++
> arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 74 +++++++++++++-----
> arch/arm/boot/dts/omap3-sb-t35.dtsi | 30 +++++++-
> arch/arm/boot/dts/omap3-sbc-t3517.dts | 44 +++++++++++
> arch/arm/boot/dts/omap3-sbc-t3530.dts | 37 +++++++++
> arch/arm/boot/dts/omap3-sbc-t3730.dts | 24 +++---
> arch/arm/mach-omap2/pdata-quirks.c | 67 ++++++++++++++++-
> 11 files changed, 506 insertions(+), 76 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap3-cm-t3517.dts
> create mode 100644 arch/arm/boot/dts/omap3-cm-t3530.dts
> create mode 100644 arch/arm/boot/dts/omap3-cm-t3x.dtsi
> create mode 100644 arch/arm/boot/dts/omap3-sbc-t3517.dts
> create mode 100644 arch/arm/boot/dts/omap3-sbc-t3530.dts
>
--
Regards,
Igor.
^ permalink raw reply
* [PATCH] ARM: mm: cache-l2x0: Check for status property of DT node
From: Tomasz Figa @ 2014-02-12 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392206478-11530-1-git-send-email-tushar.behera@linaro.org>
[making Cc list a bit more comprehensive]
On 12.02.2014 13:01, Tushar Behera wrote:
> Currently only the DT node is checked during l2x0 cache initialization,
> but it doesn't check the status of the DT node. Thus it gets called
> even if the status of DT node for L2 controller is disabled.
>
> Add explicit check to ensure that L2 cache is initialized only for
> desired boards.
>
> Reported-by: Tomasz Figa <t.figa@samsung.com>
> Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
> ---
> arch/arm/mm/cache-l2x0.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
> index 7abde2c..f075cb1 100644
> --- a/arch/arm/mm/cache-l2x0.c
> +++ b/arch/arm/mm/cache-l2x0.c
> @@ -978,6 +978,9 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
> if (!np)
> return -ENODEV;
>
> + if (!of_device_is_available(np))
> + return -ENODEV;
> +
> if (of_address_to_resource(np, 0, &res))
> return -ENODEV;
>
>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 0/3] arm64: Use pte manipulation functions for THP
From: Russell King - ARM Linux @ 2014-02-12 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212115004.GA14527@linaro.org>
On Wed, Feb 12, 2014 at 11:50:05AM +0000, Steve Capper wrote:
> I have noticed the following for ARM:
> 36bb94b ARM: pgtable: provide RDONLY page table bit rather than WRITE bit
> Are you happy for me to re-introduce PTE_WRITE for the 3-level code
> only, and keep L_PTE_RDONLY for the 2-level code?
Sigh, yet another cleanup reverted... If you must.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v4 0/8] Device Tree support for the at91sam9261ek
From: Thomas Petazzoni @ 2014-02-12 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5Nv7u4WSXttvsnMPxwNwN6R4ZDRABOXr9XXBjy6mSDi5w@mail.gmail.com>
Dear Jean-Jacques Hiblot,
On Wed, 12 Feb 2014 13:36:08 +0100, Jean-Jacques Hiblot wrote:
> >> For dm9000 the issue is (again) related to an ordering problem:
> >> the Ethernet need an interrupt provided by the gpio driver. Unfortunately,
> >> the gpio driver initialization is called after the dm900 driver
> >> initialization.
> >
> > And -EPROBE_DEFER doesn't solve this problem?
> not really the problem happens before the driver is actually probed
> when the ressource for the platform driver are filled
Sorry, I don't have all the context. If I understand correctly what you
mean, the GPIO driver is probed through the DT, but the DM9000 driver
is probed in a legacy way from the board file, and you have the case
where the DM9000 platform_device gets registered before the GPIOs are
actually available? In this case, what about having the
of_platform_populate() call *before* the platform_device_register() for
your DM9000 ? Again, I don't have all the context, so I might very well
be getting the situation incorrectly.
Of course, ideally, the DM9000 driver should be probed using the DT,
but I guess this needs the SMC DT binding that is still being
discussed, if I followed correctly.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH RFC v2 00/35] Second preview of imx-drm cleanup series
From: Russell King - ARM Linux @ 2014-02-12 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9NwWcEAg461_aZrRjZ4o80M4ymhsg9bqsRVuVa8T1BEwAHOQ@mail.gmail.com>
On Wed, Feb 12, 2014 at 01:04:30PM +0100, Christian Gmeiner wrote:
> 2014-02-12 12:53 GMT+01:00 Fabio Estevam <festevam@gmail.com>:
> > On Mon, Feb 10, 2014 at 10:28 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> This is the latest revision of my series cleaning up imx-drm and
> >> hopefully getting it ready to be moved out of drivers/staging.
> >> This series is updated to v3.14-rc2.
> >>
> >> Since the last round of patches were posted, the component support
> >> has been merged into mainline, and thus dropped from this series.
> >> Greg has taken the first three patches and merged them into his
> >> linux-next tree - however, I include them here for completness.
> >>
> >> Most of the comments from last time still apply, and I'll look at
> >> incorporating some of the other patches that were posted in the
> >> coming week.
> >>
> >> If I can have some acks for this, I'll start sending some of it to
> >> Greg - I'd like to at least get the five or six initial imx-hdmi
> >> patches to Greg and queued up for the next merge window sooner
> >> rather than later, preferably getting most of this ready for that
> >> window too.
> >
> > Series looks good:
> >
> > Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
> >
> > Patch 04/35 will not be needed in the final submission, as there is
> > already a fix for the build issue in Greg's tree.
> >
>
> I am the only one who does not get the whole series?
>
> Even here ony a handfull of patches are listed:
> http://www.spinics.net/lists/arm-kernel/threads.html#306292
You will find it all on the devel at driverdev.osuosl.org archive.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] arm64: smp: Add a memory barrier before we start secondary cores
From: Mark Brown @ 2014-02-12 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212122727.GB29132@mudshark.cambridge.arm.com>
On Wed, Feb 12, 2014 at 12:27:28PM +0000, Will Deacon wrote:
> On Wed, Feb 12, 2014 at 11:46:34AM +0000, Mark Brown wrote:
> > Ensure that memory writes will be visible to the newly started core by
> > inserting a write barrier prior to starting. This adds robustness against
> > possible incomplete synchronisation of state.
> This is very vague. I still don't understand what this is being used for.
Me either to be honest, I wasn't entirely sure why Catalin had suggested
it.
> Without a concrete example of precisely why this is required, I'm not at all
> happy taking patches adding random memory barriers.
That's fine by me, I've no attachment to this.
-------------- 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/20140212/12b5ba9a/attachment.sig>
^ permalink raw reply
* [PATCH RFC v2 00/35] Second preview of imx-drm cleanup series
From: Shawn Guo @ 2014-02-12 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140210122802.GS26684@n2100.arm.linux.org.uk>
On Mon, Feb 10, 2014 at 12:28:03PM +0000, Russell King - ARM Linux wrote:
> This is the latest revision of my series cleaning up imx-drm and
> hopefully getting it ready to be moved out of drivers/staging.
> This series is updated to v3.14-rc2.
>
> Since the last round of patches were posted, the component support
> has been merged into mainline, and thus dropped from this series.
> Greg has taken the first three patches and merged them into his
> linux-next tree - however, I include them here for completness.
>
> Most of the comments from last time still apply, and I'll look at
> incorporating some of the other patches that were posted in the
> coming week.
>
> If I can have some acks for this, I'll start sending some of it to
> Greg - I'd like to at least get the five or six initial imx-hdmi
> patches to Greg and queued up for the next merge window sooner
> rather than later, preferably getting most of this ready for that
> window too.
For the series,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* [PATCH 1/2] pinctrl: nomadik: Silence compiler warn for !CONFIG_PM
From: Ulf Hansson @ 2014-02-12 12:59 UTC (permalink / raw)
To: linux-arm-kernel
The static suspend/resume functions were not being used while
!CONFIG_PM. Fix it and convert to CONFIG_PM_SLEEP.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pinctrl/pinctrl-nomadik.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index 53a1111..b6c5793 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -2035,6 +2035,7 @@ static const struct of_device_id nmk_pinctrl_match[] = {
{},
};
+#ifdef CONFIG_PM_SLEEP
static int nmk_pinctrl_suspend(struct platform_device *pdev, pm_message_t state)
{
struct nmk_pinctrl *npct;
@@ -2056,6 +2057,7 @@ static int nmk_pinctrl_resume(struct platform_device *pdev)
return pinctrl_force_default(npct->pctl);
}
+#endif
static int nmk_pinctrl_probe(struct platform_device *pdev)
{
@@ -2151,7 +2153,7 @@ static struct platform_driver nmk_pinctrl_driver = {
.of_match_table = nmk_pinctrl_match,
},
.probe = nmk_pinctrl_probe,
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
.suspend = nmk_pinctrl_suspend,
.resume = nmk_pinctrl_resume,
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] pinctrl: nomadik: Convert to modern pm_ops
From: Ulf Hansson @ 2014-02-12 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392209979-31636-1-git-send-email-ulf.hansson@linaro.org>
Use the SIMPLE_DEV_PM_OPS macro and convert to the modern pm ops.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pinctrl/pinctrl-nomadik.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index b6c5793..cec7762 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -2036,22 +2036,22 @@ static const struct of_device_id nmk_pinctrl_match[] = {
};
#ifdef CONFIG_PM_SLEEP
-static int nmk_pinctrl_suspend(struct platform_device *pdev, pm_message_t state)
+static int nmk_pinctrl_suspend(struct device *dev)
{
struct nmk_pinctrl *npct;
- npct = platform_get_drvdata(pdev);
+ npct = dev_get_drvdata(dev);
if (!npct)
return -EINVAL;
return pinctrl_force_sleep(npct->pctl);
}
-static int nmk_pinctrl_resume(struct platform_device *pdev)
+static int nmk_pinctrl_resume(struct device *dev)
{
struct nmk_pinctrl *npct;
- npct = platform_get_drvdata(pdev);
+ npct = dev_get_drvdata(dev);
if (!npct)
return -EINVAL;
@@ -2146,17 +2146,18 @@ static struct platform_driver nmk_gpio_driver = {
.probe = nmk_gpio_probe,
};
+static SIMPLE_DEV_PM_OPS(nmk_pinctrl_pm_ops,
+ nmk_pinctrl_suspend,
+ nmk_pinctrl_resume);
+
static struct platform_driver nmk_pinctrl_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "pinctrl-nomadik",
.of_match_table = nmk_pinctrl_match,
+ .pm = &nmk_pinctrl_pm_ops,
},
.probe = nmk_pinctrl_probe,
-#ifdef CONFIG_PM_SLEEP
- .suspend = nmk_pinctrl_suspend,
- .resume = nmk_pinctrl_resume,
-#endif
};
static int __init nmk_gpio_init(void)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 0/8] Device Tree support for the at91sam9261ek
From: Jean-Jacques Hiblot @ 2014-02-12 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212134428.4a442f31@skate>
Thomas,
I wasn't very informative indeed.
The dm9000 is instantiated from the DT, its irq is described as <&pioC
2 IRQ_TYPE_EDGE_BOTH>
The problem, as I see it, is that at the time the IRQ description is
translated the irq domain doesn't exist yet and the translation fails.
The result is that the ressource of the platform driver do not contain
any information about an IRQ.
The irq domain is added later when the gpio driver is probed
(pinctrl-at91.c:1684).
A bit later the dm9000 gets probed and fails lamely because it can't
find an IRQ ressource.
Jean-Jacques
2014-02-12 13:44 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Dear Jean-Jacques Hiblot,
>
> On Wed, 12 Feb 2014 13:36:08 +0100, Jean-Jacques Hiblot wrote:
>
>> >> For dm9000 the issue is (again) related to an ordering problem:
>> >> the Ethernet need an interrupt provided by the gpio driver. Unfortunately,
>> >> the gpio driver initialization is called after the dm900 driver
>> >> initialization.
>> >
>> > And -EPROBE_DEFER doesn't solve this problem?
>> not really the problem happens before the driver is actually probed
>> when the ressource for the platform driver are filled
>
> Sorry, I don't have all the context. If I understand correctly what you
> mean, the GPIO driver is probed through the DT, but the DM9000 driver
> is probed in a legacy way from the board file, and you have the case
> where the DM9000 platform_device gets registered before the GPIOs are
> actually available? In this case, what about having the
> of_platform_populate() call *before* the platform_device_register() for
> your DM9000 ? Again, I don't have all the context, so I might very well
> be getting the situation incorrectly.
>
> Of course, ideally, the DM9000 driver should be probed using the DT,
> but I guess this needs the SMC DT binding that is still being
> discussed, if I followed correctly.
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH] perf: ARM64: wire up perf_regs and unwind support
From: Arnaldo Carvalho de Melo @ 2014-02-12 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212113018.GA29132@mudshark.cambridge.arm.com>
Em Wed, Feb 12, 2014 at 11:30:18AM +0000, Will Deacon escreveu:
> On Wed, Feb 12, 2014 at 11:27:44AM +0000, Ingo Molnar wrote:
> > * Will Deacon <will.deacon@arm.com> wrote:
> > > This needs to go via the perf tree to avoid a repeat of the mess last time.
> > If the tooling bits are fine with Arnaldo then I have no objections
> > either - once all the bits are acked please send a single series with
> > all 4(?) patches in it, for tip:perf/core inclusion.
> I think it's just 1 patch -- the other 3 are under arch/arm64, so it would
> be easier to take those via the arm64 tree and deal with any conflicts
> there.
I don't have a problem with arch specific bits, that don't touch the
tools at all, going thru the respective arch git tree.
Jiri, can you see anything problematic in this? From a quick look I
couldn't.
- Arnaldo
^ permalink raw reply
* [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Arnd Bergmann @ 2014-02-12 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212114740.GE21992@e106331-lin.cambridge.arm.com>
On Wednesday 12 February 2014 11:47:40 Mark Rutland wrote:
> On Wed, Feb 12, 2014 at 11:21:50AM +0000, Arnd Bergmann wrote:
> > On Wednesday 12 February 2014, Mark Rutland wrote:
> > > To me it feels odd to require the last clock in the list (apb_pclk) to
> > > be named, and the rest to be in a particular order. For the dt case it
> > > seems saner to add new clocks with names as it allows arbitrary subsets
> > > of clocks to be wired up and described (though obviously in this case a
> > > missing sspclk would be problematic).
> >
> > Yes, good point about the missing clocks, and I also agree mixing ordered
> > and named clocks in one device is rather odd and can lead to trouble.
> >
> > I guess there isn't really a good way out here, and I certainly won't
> > ask for it to be done one way or the other if someone else has a
> > good argument which way it should be implemented.
>
> Having thought about it, all dts that for the ssp_pclk must have some
> name for the sspclk (though the specific name is arbitrary). I could get
> the driver to try each of those before falling back to the index
> (perhaps with a helper that takes a list of known aliases), so all
> existing dts (that we are aware of) would work with the clock requested
> by name.
Strange. Why do the even have names in there? What are those strings?
I noticed that ux500 has uses four different strings, one for each
instance, which is obviously a bug and should just be fixed. There is
no way this was intentional, and we can just rely on teh fallback
if you want to have that anyway.
> I assume that for the non-dt case it's possible to name clock inputs to
> a device without the clock being associated with the name globally? If
> so we could get rid of the index usage entirely in this case.
Sorry, I don't understand the question.
Arnd
^ permalink raw reply
* [PATCH RESEND] usb: at91-udc: fix irq and iomem resource retrieval
From: Nicolas Ferre @ 2014-02-12 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390488102-8548-1-git-send-email-jjhiblot@traphandler.com>
From: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
When using dt resources retrieval (interrupts and reg properties) there is
no predefined order for these resources in the platform dev resource
table. Also don't expect the number of resource to be always 2.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable <stable@vger.kernel.org> # 3.4
---
drivers/usb/gadget/at91_udc.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index cea8c20a1425..1926925a52a9 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -1709,16 +1709,6 @@ static int at91udc_probe(struct platform_device *pdev)
return -ENODEV;
}
- if (pdev->num_resources != 2) {
- DBG("invalid num_resources\n");
- return -ENODEV;
- }
- if ((pdev->resource[0].flags != IORESOURCE_MEM)
- || (pdev->resource[1].flags != IORESOURCE_IRQ)) {
- DBG("invalid resource type\n");
- return -ENODEV;
- }
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENXIO;
--
1.8.2.2
^ permalink raw reply related
* [PATCH] ARM: imx6: fix !CONFIG_PM and !CONFIG_CPU_IDLE build
From: Fabio Estevam @ 2014-02-12 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392201948-16311-1-git-send-email-l.stach@pengutronix.de>
On Wed, Feb 12, 2014 at 8:45 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> --- a/arch/arm/mach-imx/common.h
> +++ b/arch/arm/mach-imx/common.h
> @@ -138,7 +138,6 @@ void imx_gpc_irq_unmask(struct irq_data *d);
> void imx_anatop_init(void);
> void imx_anatop_pre_suspend(void);
> void imx_anatop_post_resume(void);
> -int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode);
> void imx6q_set_chicken_bit(void);
This function has been renamed since commit f191d820b1b (ARM: imx: Use
INT_MEM_CLK_LPM as the bit name)
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH v2] ARM: Add imprecise abort enable/disable macro
From: Fabrice GASNIER @ 2014-02-12 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392050756-11145-1-git-send-email-fabrice.gasnier@st.com>
Hi,
Any comments on this patch ?
Russell, can I add this patch to your patch tracker system ?
Thanks,
Fabrice
On 02/10/2014 05:45 PM, Fabrice GASNIER wrote:
> This patch adds imprecise abort enable/disable macros.
> It also enables imprecise aborts when starting kernel.
>
> Changes in v2:
> Only ARMv6 and later have CPSR.A bit. On earlier CPUs,
> and ARMv7M this should be a no-op.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> arch/arm/include/asm/irqflags.h | 10 ++++++++++
> arch/arm/kernel/smp.c | 1 +
> arch/arm/kernel/traps.c | 4 ++++
> 3 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/include/asm/irqflags.h b/arch/arm/include/asm/irqflags.h
> index 3b763d6..8301f87 100644
> --- a/arch/arm/include/asm/irqflags.h
> +++ b/arch/arm/include/asm/irqflags.h
> @@ -51,6 +51,14 @@ static inline void arch_local_irq_disable(void)
>
> #define local_fiq_enable() __asm__("cpsie f @ __stf" : : : "memory", "cc")
> #define local_fiq_disable() __asm__("cpsid f @ __clf" : : : "memory", "cc")
> +
> +#ifndef CONFIG_CPU_V7M
> +#define local_abt_enable() __asm__("cpsie a @ __sta" : : : "memory", "cc")
> +#define local_abt_disable() __asm__("cpsid a @ __cla" : : : "memory", "cc")
> +#else
> +#define local_abt_enable() do { } while (0)
> +#define local_abt_disable() do { } while (0)
> +#endif
> #else
>
> /*
> @@ -130,6 +138,8 @@ static inline void arch_local_irq_disable(void)
> : "memory", "cc"); \
> })
>
> +#define local_abt_enable() do { } while (0)
> +#define local_abt_disable() do { } while (0)
> #endif
>
> /*
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index dc894ab..c2093cb 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -377,6 +377,7 @@ asmlinkage void secondary_start_kernel(void)
>
> local_irq_enable();
> local_fiq_enable();
> + local_abt_enable();
>
> /*
> * OK, it's off to the idle thread for us
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 4636d56..ef15709 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
>
> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> +
> + /* Enable imprecise aborts */
> + local_abt_enable();
> +
> #else /* ifndef CONFIG_CPU_V7M */
> /*
> * on V7-M there is no need to copy the vector table to a dedicated
^ permalink raw reply
* [PATCH v2] ARM: Add imprecise abort enable/disable macro
From: Fabrice Gasnier @ 2014-02-12 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392050756-11145-1-git-send-email-fabrice.gasnier@st.com>
Hi,
Any comments on this patch ?
Russel, can I add this patch to your patch tracker system ?
Thanks,
Fabrice
On 02/10/2014 05:45 PM, Fabrice GASNIER wrote:
> This patch adds imprecise abort enable/disable macros.
> It also enables imprecise aborts when starting kernel.
>
> Changes in v2:
> Only ARMv6 and later have CPSR.A bit. On earlier CPUs,
> and ARMv7M this should be a no-op.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> arch/arm/include/asm/irqflags.h | 10 ++++++++++
> arch/arm/kernel/smp.c | 1 +
> arch/arm/kernel/traps.c | 4 ++++
> 3 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/include/asm/irqflags.h b/arch/arm/include/asm/irqflags.h
> index 3b763d6..8301f87 100644
> --- a/arch/arm/include/asm/irqflags.h
> +++ b/arch/arm/include/asm/irqflags.h
> @@ -51,6 +51,14 @@ static inline void arch_local_irq_disable(void)
>
> #define local_fiq_enable() __asm__("cpsie f @ __stf" : : : "memory", "cc")
> #define local_fiq_disable() __asm__("cpsid f @ __clf" : : : "memory", "cc")
> +
> +#ifndef CONFIG_CPU_V7M
> +#define local_abt_enable() __asm__("cpsie a @ __sta" : : : "memory", "cc")
> +#define local_abt_disable() __asm__("cpsid a @ __cla" : : : "memory", "cc")
> +#else
> +#define local_abt_enable() do { } while (0)
> +#define local_abt_disable() do { } while (0)
> +#endif
> #else
>
> /*
> @@ -130,6 +138,8 @@ static inline void arch_local_irq_disable(void)
> : "memory", "cc"); \
> })
>
> +#define local_abt_enable() do { } while (0)
> +#define local_abt_disable() do { } while (0)
> #endif
>
> /*
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index dc894ab..c2093cb 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -377,6 +377,7 @@ asmlinkage void secondary_start_kernel(void)
>
> local_irq_enable();
> local_fiq_enable();
> + local_abt_enable();
>
> /*
> * OK, it's off to the idle thread for us
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 4636d56..ef15709 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -900,6 +900,10 @@ void __init early_trap_init(void *vectors_base)
>
> flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
> modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
> +
> + /* Enable imprecise aborts */
> + local_abt_enable();
> +
> #else /* ifndef CONFIG_CPU_V7M */
> /*
> * on V7-M there is no need to copy the vector table to a dedicated
^ permalink raw reply
* [PATCH v2 02/10] ARM: mvebu: add initial support for the Armada 375 SOCs
From: Arnd Bergmann @ 2014-02-12 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392200619-3141-3-git-send-email-thomas.petazzoni@free-electrons.com>
On Wednesday 12 February 2014 11:23:31 Thomas Petazzoni wrote:
> From: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> This commit adds the basic support for the Armada 375 SOCs. These SoCs
> share most of their IP with the Armada 370/XP SoCs. The main
> difference is the use of a Cortex A9 CPU instead of the PJ4B CPU. The
> interrupt controller and the L2 cache controller are also different
> they are respectively the GIC and the PL310.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> .../devicetree/bindings/arm/armada-375.txt | 9 +++++
> arch/arm/mach-mvebu/Kconfig | 15 ++++++++
> arch/arm/mach-mvebu/Makefile | 1 +
> arch/arm/mach-mvebu/armada-375.c | 44 ++++++++++++++++++++++
I don't know what the outcome was for the first version, but just
for the record, I would prefer merging the board file into armada-370-xp.c
without renaming that file. Keeping the separate Kconfig entry makes sense
because we want to select different options there. If you have differences
between the implementations (so far the 370/xp code should just work
on 375), you can use a combination of if(IS_ENABLED(CONFIG_*)) and
if(machine_is_compatible()) to do the detection but keep a common
dt_compat list.
Arnd
^ permalink raw reply
* [PATCH] perf: ARM64: wire up perf_regs and unwind support
From: Jiri Olsa @ 2014-02-12 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391451427-31221-1-git-send-email-jean.pihet@linaro.org>
On Mon, Feb 03, 2014 at 07:17:07PM +0100, Jean Pihet wrote:
> This patch hooks in the perf_regs and libunwind code for ARM64.
> The tools/perf/arch/arm64 is created; it contains the arch specific
> code for DWARF unwinding.
>
> Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
> Acked-by: Will Deacon <will.deacon@arm.com>
SNIP
> + */
> +const char *get_arch_regstr(unsigned int n)
> +{
> + const struct pt_regs_dwarfnum *roff;
> + for (roff = regdwarfnum_table; roff->name != NULL; roff++)
> + if (roff->dwarfnum == n)
> + return roff->name;
> + return NULL;
> +}
> diff --git a/tools/perf/arch/arm64/util/unwind.c b/tools/perf/arch/arm64/util/unwind.c
> new file mode 100644
> index 0000000..8d37a4c
> --- /dev/null
> +++ b/tools/perf/arch/arm64/util/unwind.c
> @@ -0,0 +1,82 @@
> +
> +#include <errno.h>
> +#include <libunwind.h>
> +#include "perf_regs.h"
> +#include "../../util/unwind.h"
> +
> +int unwind__arch_reg_id(int regnum)
I think this ^^^ wouldn't compile over acme/perf/core, bacause of
the recent code changes for the libdw unwind:
1d86598 perf callchain: Rename unwind__arch_reg_id into libunwind__arch_reg_id
jirka
^ permalink raw reply
* [PATCH v2 03/10] ARM: mvebu: add workaround for data abort issue on Armada 375
From: Arnd Bergmann @ 2014-02-12 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392200619-3141-4-git-send-email-thomas.petazzoni@free-electrons.com>
On Wednesday 12 February 2014 11:23:32 Thomas Petazzoni wrote:
> +/*
> + * Early versions of Armada 375 SoC have a bug where the BootROM
> + * leaves an external data abort pending. The kernel is hit by this
> + * data abort as soon as it enters userspace, because it unmasks the
> + * data aborts at this moment. We register a custom abort handler
> + * below to ignore the first data abort to work around this problem.
> + */
> +static int armada_375_external_abort_wa(unsigned long addr, unsigned int fsr,
> + struct pt_regs *regs)
> +{
> + static int ignore_first;
> +
> + if (!ignore_first) {
> + ignore_first = 1;
> + return 0;
> + }
> +
> + return 1;
> +}
I think this should try to match the fsr and addr field if possible and
only ignore the one external abort you expect.
Arnd
^ permalink raw reply
* [PATCH] ARM: imx6: fix !CONFIG_PM and !CONFIG_CPU_IDLE build
From: Lucas Stach @ 2014-02-12 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DJNBQU1oL+V3r_=WfX8b_Qd_-OVbdnzVj=AMSS8ndhcg@mail.gmail.com>
Am Mittwoch, den 12.02.2014, 11:04 -0200 schrieb Fabio Estevam:
> On Wed, Feb 12, 2014 at 8:45 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
>
> > --- a/arch/arm/mach-imx/common.h
> > +++ b/arch/arm/mach-imx/common.h
> > @@ -138,7 +138,6 @@ void imx_gpc_irq_unmask(struct irq_data *d);
> > void imx_anatop_init(void);
> > void imx_anatop_pre_suspend(void);
> > void imx_anatop_post_resume(void);
> > -int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode);
> > void imx6q_set_chicken_bit(void);
>
> This function has been renamed since commit f191d820b1b (ARM: imx: Use
> INT_MEM_CLK_LPM as the bit name)
>
Which isn't in imx/fixes, where this patch should probably go to.
Also this patch doesn't touch the chicken/whatever function at all, it
just ensures that it is available for linking when needed, so there
shouldn't be any conflicts (aside from a few context mismatches).
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH RFC v2 00/35] Second preview of imx-drm cleanup series
From: Christian Gmeiner @ 2014-02-12 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140212124517.GO26684@n2100.arm.linux.org.uk>
2014-02-12 13:45 GMT+01:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Wed, Feb 12, 2014 at 01:04:30PM +0100, Christian Gmeiner wrote:
>> 2014-02-12 12:53 GMT+01:00 Fabio Estevam <festevam@gmail.com>:
>> > On Mon, Feb 10, 2014 at 10:28 AM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >> This is the latest revision of my series cleaning up imx-drm and
>> >> hopefully getting it ready to be moved out of drivers/staging.
>> >> This series is updated to v3.14-rc2.
>> >>
>> >> Since the last round of patches were posted, the component support
>> >> has been merged into mainline, and thus dropped from this series.
>> >> Greg has taken the first three patches and merged them into his
>> >> linux-next tree - however, I include them here for completness.
>> >>
>> >> Most of the comments from last time still apply, and I'll look at
>> >> incorporating some of the other patches that were posted in the
>> >> coming week.
>> >>
>> >> If I can have some acks for this, I'll start sending some of it to
>> >> Greg - I'd like to at least get the five or six initial imx-hdmi
>> >> patches to Greg and queued up for the next merge window sooner
>> >> rather than later, preferably getting most of this ready for that
>> >> window too.
>> >
>> > Series looks good:
>> >
>> > Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
>> >
>> > Patch 04/35 will not be needed in the final submission, as there is
>> > already a fix for the build issue in Greg's tree.
>> >
>>
>> I am the only one who does not get the whole series?
>>
>> Even here ony a handfull of patches are listed:
>> http://www.spinics.net/lists/arm-kernel/threads.html#306292
>
> You will find it all on the devel at driverdev.osuosl.org archive.
>
thanks - thumbs up for this series.
--
Christian Gmeiner, MSc
https://soundcloud.com/christian-gmeiner
^ permalink raw reply
* [PATCH v2 05/10] ARM: mvebu: add Device Tree for the Armada 375 DB board
From: Arnd Bergmann @ 2014-02-12 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392200619-3141-6-git-send-email-thomas.petazzoni@free-electrons.com>
On Wednesday 12 February 2014 11:23:34 Thomas Petazzoni wrote:
> + i2c0: i2c at 11000 {
> + status = "okay";
> + clock-frequency = <100000>;
> + pinctrl-0 = <&i2c0_pins>;
> + pinctrl-names = "default";
> + };
> +
> + i2c1: i2c at 11100 {
> + status = "okay";
> + clock-frequency = <100000>;
> + pinctrl-0 = <&i2c1_pins>;
> + pinctrl-names = "default";
> + };
I think you should either use the label to reference the node here,
or omit it in the board.dts file. There is no point in defining
multiple identical labels.
Arnd
^ 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