* [PATCH] mvebu-gpio: Disable blinking when enabling a GPIO for output
From: Linus Walleij @ 2012-10-30 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351427004-32110-1-git-send-email-jm@lentin.co.uk>
On Sun, Oct 28, 2012 at 1:23 PM, Jamie Lentin <jm@lentin.co.uk> wrote:
> The plat-orion GPIO driver would disable any pin blinking whenever
> using a pin for output. Do the same here, as a blinking LED will
> continue to blink regardless of what the GPIO pin level is.
>
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> ---
> The power LED on the DNS-320/DNS-325 is left blinking by the bootloader,
> the LED turning steady indicates it's booted. The blinking needs to be
> disabled before setting the GPIO pin level has any effect.
>
> Apart from the custom init code running too soon, I think everything is
> working now.
>
> I haven't tested this on any other boards, so not sure if it's sensible
> beyond the kirkwood/orion world.
Can I have some ACK on this thing from Andrew or Thomas say...
Also is this a thing for the stable kernel -rc series or next
merge window? I couldn't quite figure out if it was a regression.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-10-30 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030183704.GX4511@opensource.wolfsonmicro.com>
On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> More seriously the amount of time we seem to have been spending recently
> on changes which end up requiring us to go through essentially every
> driver and add code to them (often several times) doesn't seem like
> we're doing a good job here.
If this is your main concern you should be made aware that there
are people out there planning to supplant the existing DT probe paths
that are now being added to each and every ARM-related driver
with an ACPI probe path as ARM servers come into the picture.
> pinctrl is really noticable because it's
> new but it's not the only thing. As a subsystem maintainer this code
> just makes me want to add new subsystem features to pull the code out of
> drivers but obviously that's not something that should be being done at
> the subsystem level.
We did manage to drag the power/voltage domain per se out
of the AMBA bus, and recommend that people (like us) do that
business using the power domains.
I think most people (including OMAP) have bought
into the concept of using the runtime PM framework and power
domains to control the power domain switches.
It's this wider concept of using the loose concept "PM resource
domains" to control also clocks and pins that is at stake, and so
far the runtime PM core people (Rafael and Magnus) has not said
much so I think we need some kind of indication from them as to
what is to happen, long-term, with drivers handling their own clocks
and pins. Should it be centralized or not? If it's to be centralized it
needs to become a large piece of infrastructure refactoring and
needs the attention of Linaro and the like to happen.
I've CC:ed a few people into this thread so we get some traction,
we need more subsystem maintainers in here.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm/dts: Add basic support for gta04 (Openmoko next generation) board.
From: Marek Belisko @ 2012-10-30 21:42 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
---
arch/arm/boot/dts/omap3-gta04.dts | 65 +++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-gta04.dts
diff --git a/arch/arm/boot/dts/omap3-gta04.dts b/arch/arm/boot/dts/omap3-gta04.dts
new file mode 100644
index 0000000..76efd13
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -0,0 +1,65 @@
+/*
+ * Copyright (C) 2012 Marek Belisko <marek.belisko@open-nandra.com>
+ *
+ * Based on omap3-beagle-xm.dts
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ "omap3.dtsi"
+
+/ {
+ model = "OMAP3 GTA04";
+ compatible = "ti,omap3-gta04", "ti,omap3";
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x20000000>; /* 512 MB */
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ aux-button {
+ label = "AUX";
+ linux,code = <169>;
+ gpios = <&gpio1 7 1>;
+ gpio-key,wakeup;
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <2600000>;
+
+ twl: twl at 48 {
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = <&intc>;
+ };
+};
+
+/include/ "twl4030.dtsi"
+
+&i2c2 {
+ clock-frequency = <400000>;
+ /* Pressure Sensor */
+ bmp085 at 77 {
+ compatible = "bosch,bmp085";
+ reg = <0x77>;
+ };
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+};
+
+&mmc1 {
+ vmmc-supply = <&vmmc1>;
+ bus-width = <4>;
+};
+
--
1.7.9.5
^ permalink raw reply related
* [GIT PULL] Renesas ARM-based SoC defconfig for v3.8
From: Arnd Bergmann @ 2012-10-30 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030074508.GG12329@verge.net.au>
On Tuesday 30 October 2012, Simon Horman wrote:
> While I am more than happy to help address the issues raised in this
> thread, and others that arise. There do seem to be a number of issues
> between where we are now and a more generic shmobile_defconfig. I would
> like consideration given to allowing the exixting, working, well-maintained,
> per-board defconfigs to be updated until these issues have been resolved.
Yes, no problem. This seemed like a low-hanging fruit initially but has
turned into something much bigger now.
Instead of attacking all these at ones, we can leave them as something
worthwhile doing later. I noticed that out of the 11 shmobile defconfigs,
only three (marzen, kzm9d and kzm9g) actually have a nonzero MEMORY_START.
Maybe it's possible to consolidate all or some of the others first, since
they should still work with the same uImage at the expense of just making
the early debugging a little harder, as we discussed earlier.
For all I know, these three boards are also the ones seeing the most
ongoing development, so you could start by using a shared defconfig
for the oldest (ARM11 based) boards at first that are also less likely
to impact new development starting from the defconfig.
Arnd
^ permalink raw reply
* [PATCH 1/2] input: qt1070: add pinctrl consumer
From: Linus Walleij @ 2012-10-30 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350998942-713-1-git-send-email-plagnioj@jcrosoft.com>
On Tue, Oct 23, 2012 at 3:29 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> If no pinctrl available just report a warning as some architecture may not
> need to do anything.
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: linux-input at vger.kernel.org
We're having a discussion on the level of where to impose pinctrl.
Jean-Christophe, could you please check the thread
"Input: omap4-keypad: Add pinctrl support"
and tell us what you think is the best approach?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: Peter Korsgaard @ 2012-10-30 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351498881-32482-6-git-send-email-hvaibhav@ti.com>
>>>>> "Vaibhav" == Vaibhav Hiremath <hvaibhav@ti.com> writes:
Vaibhav> From: Mugunthan V N <mugunthanvnm@ti.com>
Vaibhav> Add CPSW and MDIO related device tree data for AM33XX.
Vaibhav> Also enable them into board/evm dts files by providing
Vaibhav> respective phy-id.
Vaibhav> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Vaibhav> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Vaibhav> Cc: Richard Cochran <richardcochran@gmail.com>
Vaibhav> Cc: Benoit Cousson <b-cousson@ti.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH 3/4] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
From: Peter Korsgaard @ 2012-10-30 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351498881-32482-5-git-send-email-hvaibhav@ti.com>
>>>>> "Vaibhav" == Vaibhav Hiremath <hvaibhav@ti.com> writes:
Vaibhav> From: Mugunthan V N <mugunthanvnm@ti.com>
Vaibhav> This patch adds hwmod entry for davinci MDIO module,
Vaibhav> creating parent<->child relationship between CPSW and MDIO module.
Vaibhav> This Parent-child relation is required in order to use common resources
Vaibhav> like, clock, but still maintaining the logical separation between them.
Vaibhav> CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
Vaibhav> cpsw, etc... These sub-modules are also used in some of Davinci
Vaibhav> family of devices, so separate and independent platform devices &
Vaibhav> drivers for CPSW and MDIO is implemented.
Vaibhav> In case of AM33XX, the resources are shared and common register
Vaibhav> bit-field is provided to control module/clock enable/disable,
Vaibhav> makes it difficult to handle common resources from both drivers.
Vaibhav> So the solution is, create parent<->child relationship between
Vaibhav> CPGMAC & MDIO modules.
Vaibhav> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Vaibhav> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Vaibhav> Cc: Richard Cochran <richardcochran@gmail.com>
Vaibhav> Cc: Paul Walmsley <paul@pwsan.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH 2/4] net: cpsw: Add parent<->child relation support between cpsw and mdio
From: Peter Korsgaard @ 2012-10-30 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351498881-32482-4-git-send-email-hvaibhav@ti.com>
>>>>> "Vaibhav" == Vaibhav Hiremath <hvaibhav@ti.com> writes:
Vaibhav> CPGMAC SubSystem consist of various sub-modules, like, mdio,
Vaibhav> cpdma, cpsw, etc... These sub-modules are also used in some of
Vaibhav> Davinci family of devices. Now based on requirement, use-case
Vaibhav> and available technology nodes the integration of these
Vaibhav> sub-modules varies across devices.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH 1/4] net: davinci_mdio: Fix typo mistake in calling runtime-pm api
From: Peter Korsgaard @ 2012-10-30 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351498881-32482-3-git-send-email-hvaibhav@ti.com>
>>>>> "Vaibhav" == Vaibhav Hiremath <hvaibhav@ti.com> writes:
Vaibhav> By mistake (most likely a copy-paste), instead of pm_runtime_get_sync()
Vaibhav> api, driver is calling pm_runtime_put_sync() api in resume callback
Vaibhav> function. The bug was introduced by commit id (ae2c07aaf74:
Vaibhav> davinci_mdio: runtime PM support).
Vaibhav> Now, the reason why it didn't impact functionality is, the patch has
Vaibhav> been tested on AM335x-EVM and BeagleBone platform while submitting;
Vaibhav> and in case of AM335x the MDIO driver doesn't control the module
Vaibhav> enable/disable part, which is handled by CPSW driver.
Vaibhav> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Vaibhav> Cc: Mugunthan V N <mugunthanvnm@ti.com>
Vaibhav> Cc: Richard Cochran <richardcochran@gmail.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Vasily Khoruzhick @ 2012-10-30 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509032F6.1050301@gmail.com>
On Tue, Oct 30, 2012 at 11:05 PM, Daniel Mack <zonque@gmail.com> wrote:
>> One more question: what should I use instead of pxa2xx_mfp_config in
>> DT board to configure pin modes?
>
> Haojian was working on the PXA pinctrl drivers, but I don't know how far
> that is yet.
>
> If that's not yet there, have a look at the pinctrl-single driver. It's
> admittedly not as nice to use as the constants in the board file as DT
> lacks defines for numerical constants, but's at least a workaround.
>
> On a more general note, it's arguable whether this kind of setup should
> be done in the bootloader after all.
>
>
> Daniel
OK, thanks for suggestion!
Regards
Vasily
^ permalink raw reply
* [PATCH 1/6] arm: use devicetree to get smp_twd clock
From: Mark Langsdorf @ 2012-10-30 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351631056-25938-1-git-send-email-mark.langsdorf@calxeda.com>
From: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/kernel/smp_twd.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index b22d700..600fbcc 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -237,12 +237,15 @@ static irqreturn_t twd_handler(int irq, void *dev_id)
return IRQ_NONE;
}
-static struct clk *twd_get_clock(void)
+static struct clk *twd_get_clock(struct device_node *np)
{
- struct clk *clk;
+ struct clk *clk = NULL;
int err;
- clk = clk_get_sys("smp_twd", NULL);
+ if (np)
+ clk = of_clk_get(np, 0);
+ if (!clk)
+ clk = clk_get_sys("smp_twd", NULL);
if (IS_ERR(clk)) {
pr_err("smp_twd: clock not found: %d\n", (int)PTR_ERR(clk));
return clk;
@@ -263,6 +266,7 @@ static struct clk *twd_get_clock(void)
return ERR_PTR(err);
}
+ twd_timer_rate = clk_get_rate(clk);
return clk;
}
@@ -273,12 +277,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
{
struct clock_event_device **this_cpu_clk;
- if (!twd_clk)
- twd_clk = twd_get_clock();
-
- if (!IS_ERR_OR_NULL(twd_clk))
- twd_timer_rate = clk_get_rate(twd_clk);
- else
+ if (IS_ERR_OR_NULL(twd_clk))
twd_calibrate_rate();
__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
@@ -349,6 +348,10 @@ int __init twd_local_timer_register(struct twd_local_timer *tlt)
if (!twd_base)
return -ENOMEM;
+ twd_clk = twd_get_clock(NULL);
+
+ twd_clk = twd_get_clock(NULL);
+
return twd_local_timer_common_register();
}
@@ -383,6 +386,8 @@ void __init twd_local_timer_of_register(void)
goto out;
}
+ twd_clk = twd_get_clock(np);
+
err = twd_local_timer_common_register();
out:
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
From: Greg Kroah-Hartman @ 2012-10-30 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030162441.GF11908@atomide.com>
On Tue, Oct 30, 2012 at 09:24:42AM -0700, Tony Lindgren wrote:
> * Omar Ramirez Luna <omar.luna@linaro.org> [121030 05:20]:
> > Tony,
> >
> > On 29 October 2012 12:52, Tony Lindgren <tony@atomide.com> wrote:
> > >> --- /dev/null
> > >> +++ b/include/linux/platform_data/omap_mailbox.h
> > >> @@ -0,0 +1,105 @@
> > >
> > > This file should only contain pure platform data needed
> > > by the core omap code to pass to the mailbox driver.
> >
> > Ok, looking at it closely, this header file is related to the API
> > itself, there is nothing that could be actually considered as pure
> > platform data, the structures are related with the mailbox framework
> > and even if I split this file into two, the additional header would
> > end up including the "platform_data" header unless I move
> > save/restore_ctx functions and then export them as symbols for the
> > API.
> >
> > So, it might be better for the entire file to sit in
> > linux/include/mailbox/ then.
>
> OK to me.
>
> > > The mailbox API header should be somewhere else,
> > > like include/linux/mailbox/mailbox-omap.h or similar.
> >
> > Ok.
> >
> > > But shouldn't this all now be handled by using the
> > > remoteproc framework?
> >
> > Remoteproc doesn't handle the mailbox hardware directly, it still
> > relies in the mailbox framework for the low level communications.
> > E.g.: Proc1 has a message (virtqueue msg) queued to Proc2, uses
> > mailbox msg to generate an interrupt to Proc2, Proc2 queries the
> > message (virtqueue) based on the mailbox message received.
>
> OK.
>
> Greg, do these patches look OK to you to move to live under
> drivers/mailbox?
Um, I don't know, I wasn't paying attention here, sorry.
greg k-h
^ permalink raw reply
* [PATCH] arm: dt: tegra: fix length of pad control and mux registers
From: Stephen Warren @ 2012-10-30 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351591629-671-1-git-send-email-praithatha@nvidia.com>
On 10/30/2012 04:07 AM, Pritesh Raithatha wrote:
>...
(a commit description wouuld have been nice; I'll add one)
Applied to Tegra's for-3.7/fixes-for-rc4 branch.
^ permalink raw reply
* [PATCH V3 0/4] ARM: tegra: Enable SLINK controller driver
From: Stephen Warren @ 2012-10-30 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351580726-17350-1-git-send-email-ldewangan@nvidia.com>
On 10/30/2012 01:05 AM, Laxman Dewangan wrote:
> This series modify the dts file to add the slink addresses,
> make AUXDATA in board dt files, enable slink4 for tegra30-cardhu and
> enable slink controller defconfig.
This series only instantiates the SPI controller, and not any SPI
devices. I tried to solve this:
> diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> index 700f0a3..3689853 100644
> --- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
> +++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
> @@ -278,6 +278,11 @@
> spi at 7000da00 {
> status = "okay";
> spi-max-frequency = <25000000>;
> + flash at 0 {
> + reg = <0>;
> + compatible = "atmel,at25df321a";
> + spi-max-frequency = <25000000>;
> + };
> };
>
> ahub {
However, this didn't work. Has the driver been tested? I'm seeing the
exact same problems I saw with the old driver, namely that the SPI flash
chip can't be identified; I think the ID bytes are read back as 0, and
hence drivers/mtd/devices/m25p80.c falls back to identifying the device
as mr25h256. Attempting to hexdump -C /dev/mtd0 gives me 32K of zeros,
whereas the device is 4M and full of non-zero data according to U-Boot.
Do you know what the problem is here? Can you please update the patch
series so that the SPI flash is instantiated and works correctly?
^ permalink raw reply
* [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
From: Joel A Fernandes @ 2012-10-30 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1BAFE6F6C881BF42822005164F1491C33EAB8596@DBDE01.ent.ti.com>
Hi Gururaja,
On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja
<gururaja.hebbar@ti.com> wrote:
> Matt,
>
> On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote:
>> 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
>> exposes a bug in the AM33XX clock data for mcasp. After moving to
>> clk_get() usage, the _init() of all registered hwmods fails on mcasp0
>> due to incorrect clock data causing clk_get() to fail. This causes all
>> successive hwmods to fail to _init() leaving them in a bad state.
>>
>> This patch updates the mcasp clock entries so clk_get() will succeed.
>> It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx
>> boot.
>
>
> I want to test Audio on AM335x Evm with your EDMA patches. I have few
> patches for AM335x.
> Can you share the link to the repo & branch on which I need to rebase?
> The patches are related to mcasp dt node, mcasp pinmux in dt, etc...
>
I was wondering about the status of following patches you wrote, not
added to mainline yet:
(1)
ASoC: Davinci: machine: Add device tree binding
https://patchwork.kernel.org/patch/1380511/ - will this be resubmitted?
(2)
ASoC: AM33XX: Add support for AM33xx SoC Audio
https://github.com/joelagnel/linux-kernel/commit/973cfb48bdb70018b3869a21595bde8630efb29d
Are you planning on sending/resending these patches again? I could do this too.
I guess all other audio patches except for audio dts stuff is already in.
Thanks,
Joel
^ permalink raw reply
* [RFC 2/7] capebus: Add beaglebone board support
From: Pantelis Antoniou @ 2012-10-30 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030193939.GR11908@atomide.com>
On Oct 30, 2012, at 9:39 PM, Tony Lindgren wrote:
> * Pantelis Antoniou <panto@antoniou-consulting.com> [121030 12:00]:
>> +
>> + priv->lcdc_oh = omap_hwmod_lookup("lcdc");
>> + if (priv->lcdc_oh == NULL) {
>> + dev_err(&pdev->dev, "Failed to lookup omap_hwmod lcdc\n");
>> + return -ENODEV;
>> + }
>> +
>> + priv->lcdc_pdev = omap_device_build("da8xx_lcdc", 0, priv->lcdc_oh,
>> + &priv->lcd_pdata,
>> + sizeof(struct da8xx_lcdc_platform_data),
>> + NULL, 0, 0);
>> + if (priv->lcdc_pdev == NULL) {
>> + dev_err(&pdev->dev, "Failed to build LCDC device\n");
>> + return -ENODEV;
>> + }
>
> ..and these kind of things need to become private to
> arch/arm/mach-omap2, we already have it working for other
> devices with device tree.
>
> Regards,
>
> Tony
I see,
I know that if the device driver is DTified it will pick up the hwmod automatically.
The issue is that the driver is question is not yet; how would I go about
creating the platform device and having it pick up the hwmod automatically?
Regards
-- Pantelis
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Daniel Mack @ 2012-10-30 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVchrOXAL+cPD0-bZKSAjgyjoEFEqajva+SPtJBPOVGE=w@mail.gmail.com>
On 30.10.2012 21:01, Vasily Khoruzhick wrote:
> On Mon, Oct 29, 2012 at 2:14 PM, Daniel Mack <zonque@gmail.com> wrote:
>> On 29.10.2012 12:12, Vasily Khoruzhick wrote:
>>> On Mon, Oct 29, 2012 at 2:00 PM, Daniel Mack <zonque@gmail.com> wrote:
>>>
>>>>> Well, there's an issue - Z2 does not preserve memory contents in deep sleep
>>>>> (but it does in sleep), so userspace can't be fixed here unfortunatelly.
>>>>> There's no another possibility to turn Z2 off, and plain sleep is too
>>>>> power hungry.
>>>>> So the only way to keep Z2 in low-power mode is fake power off, which just puts
>>>>> Z2 in deep sleep.
>>>>
>>>> Why can't the userspace trigger a deep sleep then instead of powering
>>>> off? Which details do I lack?
>>>
>>> How? echo mem >/sys/power/state puts system into non-deep sleep. Anyway, kernel
>>> is not ready for fake power off instead of suspend (we can't resume
>>> from deep sleep,
>>> memory content is not preserved), so there can be some data loss.
>>> Adding some sysfs file to control sleep type does not look like a good
>>> idea to me.
>>>
>>> Btw, how other DT-capable boards handle power off?
>>
>> No idea. I never actually used that kind of power state.
>
> Hi Daniel,
>
> One more question: what should I use instead of pxa2xx_mfp_config in
> DT board to configure pin modes?
Haojian was working on the PXA pinctrl drivers, but I don't know how far
that is yet.
If that's not yet there, have a look at the pinctrl-single driver. It's
admittedly not as nice to use as the constants in the board file as DT
lacks defines for numerical constants, but's at least a workaround.
On a more general note, it's arguable whether this kind of setup should
be done in the bootloader after all.
Daniel
^ permalink raw reply
* [PATCH 2/5] ARM: PXA: Zipit Z2: Add USB host and device support
From: Vasily Khoruzhick @ 2012-10-30 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508E651A.5070009@gmail.com>
On Mon, Oct 29, 2012 at 2:14 PM, Daniel Mack <zonque@gmail.com> wrote:
> On 29.10.2012 12:12, Vasily Khoruzhick wrote:
>> On Mon, Oct 29, 2012 at 2:00 PM, Daniel Mack <zonque@gmail.com> wrote:
>>
>>>> Well, there's an issue - Z2 does not preserve memory contents in deep sleep
>>>> (but it does in sleep), so userspace can't be fixed here unfortunatelly.
>>>> There's no another possibility to turn Z2 off, and plain sleep is too
>>>> power hungry.
>>>> So the only way to keep Z2 in low-power mode is fake power off, which just puts
>>>> Z2 in deep sleep.
>>>
>>> Why can't the userspace trigger a deep sleep then instead of powering
>>> off? Which details do I lack?
>>
>> How? echo mem >/sys/power/state puts system into non-deep sleep. Anyway, kernel
>> is not ready for fake power off instead of suspend (we can't resume
>> from deep sleep,
>> memory content is not preserved), so there can be some data loss.
>> Adding some sysfs file to control sleep type does not look like a good
>> idea to me.
>>
>> Btw, how other DT-capable boards handle power off?
>
> No idea. I never actually used that kind of power state.
Hi Daniel,
One more question: what should I use instead of pxa2xx_mfp_config in
DT board to configure pin modes?
Regards
Vasily
^ permalink raw reply
* [PATCH] Add device tree file for the armadeus apf27 (v2)
From: Philippe Reynes @ 2012-10-30 19:57 UTC (permalink / raw)
To: linux-arm-kernel
v2: avoid enable again the watchdog
Signed-off-by: Philippe Reynes <tremyfr@yahoo.fr>
Signed-off-by: Eric Jarrige <eric.jarrige@armadeus.org>
---
arch/arm/boot/dts/imx27-apf27.dts | 92 +++++++++++++++++++++++++++++++++++++
1 files changed, 92 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/imx27-apf27.dts
diff --git a/arch/arm/boot/dts/imx27-apf27.dts b/arch/arm/boot/dts/imx27-apf27.dts
new file mode 100644
index 0000000..3054d8e
--- /dev/null
+++ b/arch/arm/boot/dts/imx27-apf27.dts
@@ -0,0 +1,92 @@
+/*
+ * Copyright 2012 Philippe Reynes <tremyfr@yahoo.fr>
+ * Copyright 2012 Armadeus Systems <support@armadeus.com>
+ *
+ * Based on code which is: Copyright 2012 Sascha Hauer, Pengutronix
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "imx27.dtsi"
+
+/ {
+ model = "Armadeus apf27";
+ compatible = "armadeus,imx27-apf27", "fsl,imx27";
+
+ memory {
+ reg = <0xa0000000 0x04000000>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc26m {
+ compatible = "fsl,imx-osc26m", "fixed-clock";
+ clock-frequency = <33554432>;
+ };
+ };
+
+ soc {
+ aipi at 10000000 {
+ serial at 1000a000 {
+ status = "okay";
+ };
+
+ ethernet at 1002b000 {
+ status = "okay";
+ };
+
+ };
+
+ nand at d8000000 {
+ status = "okay";
+ nand-bus-width = <16>;
+ nand-ecc-mode = "hw";
+ nand-on-flash-bbt;
+
+ partition at 0 {
+ label = "u-boot";
+ reg = <0x0 0x100000>;
+ };
+
+ partition at 100000 {
+ label = "env";
+ reg = <0x100000 0x80000>;
+ };
+
+ partition at 180000 {
+ label = "env2";
+ reg = <0x180000 0x80000>;
+ };
+
+ partition at 200000 {
+ label = "firmware";
+ reg = <0x200000 0x80000>;
+ };
+
+ partition at 280000 {
+ label = "dtb";
+ reg = <0x280000 0x80000>;
+ };
+
+ partition at 300000 {
+ label = "kernel";
+ reg = <0x300000 0x500000>;
+ };
+
+ partition at 800000 {
+ label = "rootfs";
+ reg = <0x800000 0xf800000>;
+ };
+ };
+
+ };
+
+};
--
1.7.4.4
^ permalink raw reply related
* [PATCH] Add device tree file for the armadeus apf27
From: Philippe Reynes @ 2012-10-30 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121029211015.GX1641@pengutronix.de>
Hi Sascha,
>> +??? ??? osc26m {
>> +??? ??? ??? compatible = "fsl,imx-osc26m", "fixed-clock";
>> +??? ??? ??? clock-frequency = <33554432>;
>Is this really correct? The Datasheet specificies 26MHz, some boards
>have 27Mhz, but 33?
The clock value on this board is? 32.768kHz, so 32768 * 1024.
I've tried others value, all others produce weird behaviour on the serial.
>> +??? soc {
>> +??? ??? aipi at 10000000 {
>> +??? ??? ??? wdog at 10002000 {
>> +??? ??? ??? ??? status = "okay";
>> +??? ??? ??? };
>This node is not necessary. The watchdog is enabled already in the dtsi
>file.
Yes, you're right, I'll send a v2 of this patch without the watchdog.
Regards,
Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/02b8b831/attachment-0001.html>
^ permalink raw reply
* [RFC 2/7] capebus: Add beaglebone board support
From: Tony Lindgren @ 2012-10-30 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351702333-8456-3-git-send-email-panto@antoniou-consulting.com>
* Pantelis Antoniou <panto@antoniou-consulting.com> [121030 12:00]:
> +
> + priv->lcdc_oh = omap_hwmod_lookup("lcdc");
> + if (priv->lcdc_oh == NULL) {
> + dev_err(&pdev->dev, "Failed to lookup omap_hwmod lcdc\n");
> + return -ENODEV;
> + }
> +
> + priv->lcdc_pdev = omap_device_build("da8xx_lcdc", 0, priv->lcdc_oh,
> + &priv->lcd_pdata,
> + sizeof(struct da8xx_lcdc_platform_data),
> + NULL, 0, 0);
> + if (priv->lcdc_pdev == NULL) {
> + dev_err(&pdev->dev, "Failed to build LCDC device\n");
> + return -ENODEV;
> + }
..and these kind of things need to become private to
arch/arm/mach-omap2, we already have it working for other
devices with device tree.
Regards,
Tony
^ permalink raw reply
* [RFC 2/7] capebus: Add beaglebone board support
From: Tony Lindgren @ 2012-10-30 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351702333-8456-3-git-send-email-panto@antoniou-consulting.com>
* Pantelis Antoniou <panto@antoniou-consulting.com> [121030 12:00]:
> +#include <plat/clock.h>
> +#include <plat/omap_device.h>
We already have queued patches to make omap_device.h
private to arch/arm/mach-omap2. Then plat/clock.h will
be gone with the common clock framework patches.
Regards,
Tony
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Felipe Balbi @ 2012-10-30 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030175856.GK11908@atomide.com>
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [121030 10:34]:
> > Hi,
> >
> > On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > > * Vaibhav Hiremath <hvaibhav@ti.com> [121030 07:50]:
> > > > >
> > > > > MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
> > > > > already submitted to the list recently. So MMC support will come along with
> > > > > EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
> > >
> > > This is a bogus dependency, the MMC driver needs to also work
> > > without DMA.
> >
> > heh, too bad driver errors out when it doesn't find DMA channels :-)
>
> It should just print a warning instead and continue.
>
> > 1869 host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
> > 1870 if (!host->rx_chan) {
> > 1871 dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel %u\n", rx_req);
> > 1872 ret = -ENXIO;
> > 1873 goto err_irq;
> > 1874 }
> > 1875
> > 1876 host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
> > 1877 if (!host->tx_chan) {
> > 1878 dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine channel %u\n", tx_req);
> > 1879 ret = -ENXIO;
> > 1880 goto err_irq;
> > 1881 }
> >
> > in fact, if DMAENGINE isn't enabled, this won't even compile due to
> > omap_dma_filter_fn() right ?
>
> It should, CONFIG_DMADEVICES is optional. If it does not compile,
> then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
--
balbi
-------------- 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/20121030/222e00ed/attachment.sig>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-30 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030182007.GA21851@core.coreip.homeip.net>
Hi,
On Tue, Oct 30, 2012 at 11:20:07AM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> > On Tue, Oct 30, 2012 at 03:58:21PM +0000, Mark Brown wrote:
> > >
> > > But then this comes round to the mindless code that ought to be factored
> > > out :) Only the more interesting cases that do something unusual really
> > > register here.
> >
> > fair enough. I see your point. Not saying I agree though, just that this
> > discussion has been flying for far too long, so feel free to provide
> > patches implementing what you're defending here ;-)
> >
> > Guess code will speak for itself. On way or another, we need OMAP keypad
> > driver working in mainline
>
> Are you saying that introducing pincrtl infrastructure actually _broke_
> the driver in mainline?
no dude, I'm saying we need pinctrl working for this driver because we
need to remove OMAP-specific MUX settings. One way or another, this has
to work.
--
balbi
-------------- 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/20121030/aed14ccb/attachment.sig>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-10-30 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030172513.GA3993@arwen.pp.htv.fi>
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 03:58:21PM +0000, Mark Brown wrote:
> > But then this comes round to the mindless code that ought to be factored
> > out :) Only the more interesting cases that do something unusual really
> > register here.
> fair enough. I see your point. Not saying I agree though, just that this
> discussion has been flying for far too long, so feel free to provide
> patches implementing what you're defending here ;-)
> Guess code will speak for itself. On way or another, we need OMAP keypad
> driver working in mainline and I don't think your arguments are strong
> enough to keep $SUBJECT from being merged, unless you can provide
> something stable/tested for v3.8 merge window.
Ship me an OMAP5 system and I might see what I can do :)
More seriously the amount of time we seem to have been spending recently
on changes which end up requiring us to go through essentially every
driver and add code to them (often several times) doesn't seem like
we're doing a good job here. pinctrl is really noticable because it's
new but it's not the only thing. As a subsystem maintainer this code
just makes me want to add new subsystem features to pull the code out of
drivers but obviously that's not something that should be being done at
the subsystem level.
-------------- 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/20121030/650651d2/attachment.sig>
^ 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