* [PATCH] spi/pl022: Activate resourses before deactivate them in suspend
From: Mark Brown @ 2012-10-14 5:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFpa8XoEy-kq3nq0dbRtM=a1wJ7cx=OzCOqMY1PmXrXJYw@mail.gmail.com>
On Fri, Oct 12, 2012 at 04:42:53PM +0200, Ulf Hansson wrote:
> Hi Mark,
>
> Just a kind remember on this. Do you see any problem merging this?
>
> Kind regards
> Ulf Hansson
>
> On 5 October 2012 09:43, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
Don't top post and don't send contentless nags less than a week after
your original mail, especially not in the merge window when only urgent
bug fixes should be applied.
^ permalink raw reply
* [PATCH 2/2] spi: mxs: Terminate DMA in case of DMA timeout
From: Marek Vasut @ 2012-10-14 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350181976-18233-1-git-send-email-marex@denx.de>
In case the SPI DMA times out, the DMA might still be in some kind of
inconsistent state. Issue dmaengine_terminate_all() on the particular
channel to kill off all operations before continuing.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chris Ball <cjb@laptop.org>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
---
drivers/spi/spi-mxs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 5a63bcd..86dd04d 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -323,6 +323,7 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi, int cs,
if (!ret) {
dev_err(ssp->dev, "DMA transfer timeout\n");
ret = -ETIMEDOUT;
+ dmaengine_terminate_all(ssp->dmach);
goto err_vmalloc;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] spi: mxs: Assign message status after transfer finished
From: Marek Vasut @ 2012-10-14 2:32 UTC (permalink / raw)
To: linux-arm-kernel
In the current code implementing the MXS SPI driver, every transferred
message had assigned status = 0, which is not correct. Properly assign
status returned from the I/O functions.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chris Ball <cjb@laptop.org>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
---
drivers/spi/spi-mxs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index edf1360..5a63bcd 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -480,7 +480,7 @@ static int mxs_spi_transfer_one(struct spi_master *master,
first = last = 0;
}
- m->status = 0;
+ m->status = status;
spi_finalize_current_message(master);
return status;
--
1.7.10.4
^ permalink raw reply related
* [PULL REQ] IXP4xx changes for Linux 3.7
From: Krzysztof Halasa @ 2012-10-13 21:22 UTC (permalink / raw)
To: linux-arm-kernel
Linus,
please pull my ARM IXP4xx changes for 3.7:
The following changes since commit 4d7127dace8cf4b05eb7c8c8531fc204fbb195f4:
"Merge branch 'for-linus' of git://git.kernel.org/.../jmorris/linux-security"
(2012-10-13 11:29:00 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git next
for you to fetch changes up to b94740b3b38fd8e37fcd3bb06a18ec2796061c7d:
IXP4xx: use __iomem for MMIO (2012-10-13 20:37:30 +0200)
Build-tested for now. This is based on your current tree tip because it
depends on commits following 3.6 release.
Thanks.
----------------------------------------------------------------
Arnd Bergmann (1):
IXP4xx: use __iomem for MMIO
Krzysztof Ha?asa (9):
IXP4xx: Fix Goramo MultiLink platform compilation.
IXP4xx: Fix off-by-one bug in Goramo MultiLink platform.
IXP4xx: HW pseudo-random generator is available on IXP45x/46x only.
IXP4xx: ixp4xx_crypto driver requires Queue Manager and NPE drivers.
IXP4xx: Remove time limit for PCI TRDY to enable use of slow devices.
WAN: Remove redundant HDLC info printed by IXP4xx HSS driver.
IXP4xx crypto: MOD_AES{128,192,256} already include key size.
IXP4xx: Always ioremap() Queue Manager MMIO region at boot.
IXP4xx: map CPU config registers within VMALLOC region.
Tim Gardner (1):
ixp4xx: Declare MODULE_FIRMWARE usage
arch/arm/mach-ixp4xx/common-pci.c | 1 +
arch/arm/mach-ixp4xx/common.c | 13 +++++--------
arch/arm/mach-ixp4xx/goramo_mlr.c | 3 ++-
arch/arm/mach-ixp4xx/include/mach/debug-macro.S | 4 ++--
arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h | 46 +++++++++++++++++++--------------------------
arch/arm/mach-ixp4xx/include/mach/qmgr.h | 12 ++++++------
arch/arm/mach-ixp4xx/ixp4xx_npe.c | 9 ++++++++-
arch/arm/mach-ixp4xx/ixp4xx_qmgr.c | 12 +-----------
drivers/char/hw_random/Kconfig | 6 +++---
drivers/char/hw_random/ixp4xx-rng.c | 5 ++++-
drivers/crypto/Kconfig | 2 +-
drivers/crypto/ixp4xx_crypto.c | 12 ++++++------
drivers/net/wan/ixp4xx_hss.c | 2 +-
13 files changed, 59 insertions(+), 68 deletions(-)
--
Krzysztof Halasa
^ permalink raw reply
* [PATCH] ARM: mxs: Add support for the Armadeus Systems APF28 module
From: julien.boibessot at free.fr @ 2012-10-13 17:25 UTC (permalink / raw)
To: linux-arm-kernel
From: Julien Boibessot <julien.boibessot@armadeus.com>
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
---
arch/arm/boot/dts/imx28-apf28.dts | 79 +++++++++++++++++++++++++++++++++++++
arch/arm/mach-mxs/mach-mxs.c | 7 +++
2 files changed, 86 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/imx28-apf28.dts
diff --git a/arch/arm/boot/dts/imx28-apf28.dts b/arch/arm/boot/dts/imx28-apf28.dts
new file mode 100644
index 0000000..83e37c1
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-apf28.dts
@@ -0,0 +1,79 @@
+/*
+ * Copyright 2012 Armadeus Systems - <support@armadeus.com>
+ *
+ * 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/ "imx28.dtsi"
+
+/ {
+ model = "Armadeus Systems APF28 module";
+ compatible = "armadeus,imx28-apf28", "fsl,imx28";
+
+ memory {
+ reg = <0x40000000 0x08000000>;
+ };
+
+ apb at 80000000 {
+ apbh at 80000000 {
+ gpmi-nand at 8000c000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpmi_pins_a &gpmi_status_cfg>;
+ status = "okay";
+
+ partition at 0 {
+ label = "u-boot";
+ reg = <0x0 0x300000>;
+ };
+ partition at 1 {
+ label = "env";
+ reg = <0x300000 0x80000>;
+ };
+ partition at 2 {
+ label = "env2";
+ reg = <0x380000 0x80000>;
+ };
+ partition at 3 {
+ label = "dtb";
+ reg = <0x400000 0x80000>;
+ };
+ partition at 4 {
+ label = "splash";
+ reg = <0x480000 0x80000>;
+ };
+ partition at 5 {
+ label = "kernel";
+ reg = <0x500000 0x800000>;
+ };
+ partition at 6 {
+ label = "rootfs";
+ reg = <0xd00000 0xf300000>;
+ };
+ };
+ };
+
+ apbx at 80040000 {
+ duart: serial at 80074000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&duart_pins_a>;
+ status = "okay";
+ };
+ };
+ };
+
+ ahb at 80080000 {
+ mac0: ethernet at 800f0000 {
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mac0_pins_a>;
+ phy-reset-gpios = <&gpio4 13 0>;
+ status = "okay";
+ };
+ };
+};
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index caf11db..93bc53d 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -357,6 +357,11 @@ static void __init tx28_post_init(void)
pinctrl_put(pctl);
}
+static void __init apf28_init(void)
+{
+ enable_clk_enet_out();
+}
+
static void __init mxs_machine_init(void)
{
if (of_machine_is_compatible("fsl,imx28-evk"))
@@ -367,6 +372,8 @@ static void __init mxs_machine_init(void)
m28evk_init();
else if (of_machine_is_compatible("bluegiga,apx4devkit"))
apx4devkit_init();
+ else if (of_machine_is_compatible("armadeus,imx28-apf28"))
+ apf28_init();
of_platform_populate(NULL, of_default_bus_match_table,
mxs_auxdata_lookup, NULL);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 0/2] ARM: sort configuration files
From: Russell King - ARM Linux @ 2012-10-13 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012132553.GK28061@n2100.arm.linux.org.uk>
On Fri, Oct 12, 2012 at 02:25:53PM +0100, Russell King - ARM Linux wrote:
> Here's a version updated to the kernel as of 7am UTC today. Two patches
> follow, the second fixes the order of the platform choice.
Ok folks, that's it, I'm not taking any further acks on this because
I've now sent the last batch of changes to Linus. This consists of
just these two patches, plus David Howells UAPI changes. And that will
be it for this merge window.
Thanks to all those who tested.
^ permalink raw reply
* [PATCH] ARM: imx6q: remove imx_src_prepare_restart() call
From: Anatolij Gustschin @ 2012-10-13 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1345180316-9209-1-git-send-email-shawn.guo@linaro.org>
Hi Shawn,
On Fri, 17 Aug 2012 13:11:56 +0800
Shawn Guo <shawn.guo@linaro.org> wrote:
> Currently, imx_src_prepare_restart which is called by imx6q_restart
> assumes that cpu0 must be the running cpu, so it disables all secondary
> cpus. However this is not the case, the restart routine could possibly
> running on cpu1 or any other secondary cores. In that case, disabling
> the cpu that runs restart routine will hang up system.
>
> Also it turns out that everything that is done by imx_src_prepare_restart
> is not really necessary, because the watchdog reset will have those
> registers reset properly. So let's remove the imx_src_prepare_restart
> call completely.
What is the fate of this patch?
Thanks,
Anatolij
^ permalink raw reply
* [PATCH 1/2] ARM: config: sort select statements alphanumerically
From: Sekhar Nori @ 2012-10-13 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012144832.GN28061@n2100.arm.linux.org.uk>
On Fri, Oct 12, 2012 at 8:18 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Instead, here's the updated script:
Tested build and boot on DA850 and DM365. For the DaVinci changes:
Acked-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply
* [PATCH V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT
From: Viresh Kumar @ 2012-10-13 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpom-P+=QfVNBsypq70+o+z_5J63RD72DA-_CakTM9LDCNA@mail.gmail.com>
On 13 October 2012 19:38, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 13 October 2012 17:52, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
>> On 14:18 Sat 13 Oct , Viresh Kumar wrote:
>>> On Oct 13, 2012 12:16 PM, "Jean-Christophe PLAGNIOL-VILLARD"
>>> <plagnioj@jcrosoft.com> wrote:
>>> >
>>> > On 22:42 Fri 12 Oct , Viresh Kumar wrote:
>>> > > On 12 October 2012 21:51, Jean-Christophe PLAGNIOL-VILLARD
>>> > > <plagnioj@jcrosoft.com> wrote:
>>> > > >> >> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL,
>>> "cf"),
>>> > > >> > ?/
>>> > > >>
>>> > > >> Sorry. can't get it :(
>>> > > > what is the "cf" as paltfrom data
>>> > >
>>> > > This is dma bus_id string, which matches with what is passed from dtb.
>>> > so pass if via dtb too
>>>
>>> Yes. Already passed in 13xx.dtsi.
Probably some confusion here. What i meant to say here is, dmac's
DT slave info has a node for cf and cf driver expects this string to come
via platform data currently.
>> so why do you keep the AUXDATA
>
> Because the compact flash driver expects it via platform data and not
> via DT. yes, it
> can be changed, but that wasn't the target of this patchset. If it has
> to be done, then
> it has to be done separately by ST guys.
--
viresh
^ permalink raw reply
* [PATCH V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT
From: Viresh Kumar @ 2012-10-13 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121013122242.GL12801@game.jcrosoft.org>
On 13 October 2012 17:52, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 14:18 Sat 13 Oct , Viresh Kumar wrote:
>> On Oct 13, 2012 12:16 PM, "Jean-Christophe PLAGNIOL-VILLARD"
>> <plagnioj@jcrosoft.com> wrote:
>> >
>> > On 22:42 Fri 12 Oct , Viresh Kumar wrote:
>> > > On 12 October 2012 21:51, Jean-Christophe PLAGNIOL-VILLARD
>> > > <plagnioj@jcrosoft.com> wrote:
>> > > >> >> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL,
>> "cf"),
>> > > >> > ?/
>> > > >>
>> > > >> Sorry. can't get it :(
>> > > > what is the "cf" as paltfrom data
>> > >
>> > > This is dma bus_id string, which matches with what is passed from dtb.
>> > so pass if via dtb too
>>
>> Yes. Already passed in 13xx.dtsi.
> so why do you keep the AUXDATA
Because the compact flash driver expects it via platform data and not
via DT. yes, it
can be changed, but that wasn't the target of this patchset. If it has
to be done, then
it has to be done separately by ST guys.
--
viresh
^ permalink raw reply
* [PATCH] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
From: Russell King - ARM Linux @ 2012-10-13 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xr4p2myre.fsf@unicorn.mansr.com>
On Sat, Oct 13, 2012 at 11:50:45AM +0100, M?ns Rullg?rd wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>
> > On Sat, Oct 13, 2012 at 04:46:18AM +0000, Paul Walmsley wrote:
> >>
> >> After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
> >> saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
> >> started crashing during boot with omap2plus_defconfig:
> >>
> >> [ 3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
> >> [ 3.915954] mmcblk0: p1
> >> [ 4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> >> [ 4.093719] Modules linked in:
> >> [ 4.096954] CPU: 0 Not tainted (3.6.0-02232-g759e00b #570)
> >> [ 4.103149] PC is at vfp_reload_hw+0x1c/0x44
> >> [ 4.107666] LR is at __und_usr_fault_32+0x0/0x8
> >>
> >> It turns out that the context save/restore fix unmasked a latent bug in
> >> commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3
> >> usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on
> >> a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP
> >> registers. These are only present on non-D16 VFPv3+, so the kernel dies
> >> with an undefined instruction exception. The kernel didn't crash before
> >> commit 846a136 because the save and restore code only touched d0-d15,
> >> present on all VFP.
> >>
> >> Fix to save and restore the d16-d31 registers only if they are
> >> present.
> >
> > No. VFPv3D16 HWCAP means that the VFP supports just 16 double registers
> > - and it communicates this information to userspace. If this bit is clear,
> > and the VFP only has 16 double registers, then _that_ is a bug.
>
> That bit will be clear on VFPv2 (because it's not v3), and this has only
> 16 D registers. The high D registers are present if (vfpv3 && !vfpv3d16).
> Pre-calculating this to avoid doing it in the context save/restore code
> is probably a good idea.
No. What we should do in that case is get away from this mixed logic.
The HWCAP fields should _always_ be telling us what we have, not what
we don't have. So, this means we should have VFPv3 and VFPv4 bits,
but also VFPD16 to say "yes, we have d16-d31 registers too".
And, these bits should be set as follows:
VFP architecture flags
VFPv2 VFP
VFPv3d16 VFP|VFPv3|VFPv3D16
VFPv3 VFP|VFPv3|VFPD16
VFPv4 VFP|VFPv3|VFPv4|VFPD16
whereas, at the present time we have the silly situation where VFPv3D16
gives us two bits of information. Note that the above combination sorts
this out for ever, and doesn't involve any userspace changes, and makes
this stuff much more sane - and ends up giving everyone exactly what they
need to make the appropriate decisions.
^ permalink raw reply
* [PATCH] ARM: OMAP4: Fix twd_local_timer_register regression
From: Santosh Shilimkar @ 2012-10-13 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012165149.GE30339@atomide.com>
On Friday 12 October 2012 10:21 PM, Tony Lindgren wrote:
> Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal)
> changed the interrupts to allow enabling sparse IRQ, but
> accidentally added the omap3 INTC base to the local IRQ.
> This causes the following:
>
> twd: can't register interrupt 45 (-22)
> twd_local_timer_register failed -22
>
> The right fix is to not add any base, as it is a local
> timer. For the OMAP44XX_IRQ_LOCALWDT we had defined earlier
> there are no users, so no need to fix that.
>
> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [PATCH V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-13 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpokfei_ryGKMh4wE9D=wyRZCkddc+Da1cq+3facTHradKQ@mail.gmail.com>
On 14:18 Sat 13 Oct , Viresh Kumar wrote:
> On Oct 13, 2012 12:16 PM, "Jean-Christophe PLAGNIOL-VILLARD"
> <plagnioj@jcrosoft.com> wrote:
> >
> > On 22:42 Fri 12 Oct , Viresh Kumar wrote:
> > > On 12 October 2012 21:51, Jean-Christophe PLAGNIOL-VILLARD
> > > <plagnioj@jcrosoft.com> wrote:
> > > >> >> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL,
> "cf"),
> > > >> > ?/
> > > >>
> > > >> Sorry. can't get it :(
> > > > what is the "cf" as paltfrom data
> > >
> > > This is dma bus_id string, which matches with what is passed from dtb.
> > so pass if via dtb too
>
> Yes. Already passed in 13xx.dtsi.
so why do you keep the AUXDATA
Best Regards,
J.
^ permalink raw reply
* [PATCH 1/1] MTD: atmel_nand: use devm_xxx gpio kzalloc, gpio and ioremap
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-13 12:06 UTC (permalink / raw)
To: linux-arm-kernel
this will allow to simply the error and remove path
Cc: linux-mtd at lists.infradead.org
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
---
drivers/mtd/nand/atmel_nand.c | 163 ++++++++++++++---------------------------
1 file changed, 54 insertions(+), 109 deletions(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 92623ac..2b43656 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -364,43 +364,33 @@ static void __devinit __iomem *pmecc_get_alpha_to(struct atmel_nand_host *host)
table_size * sizeof(int16_t);
}
-static void pmecc_data_free(struct atmel_nand_host *host)
-{
- kfree(host->pmecc_partial_syn);
- kfree(host->pmecc_si);
- kfree(host->pmecc_lmu);
- kfree(host->pmecc_smu);
- kfree(host->pmecc_mu);
- kfree(host->pmecc_dmu);
- kfree(host->pmecc_delta);
-}
-
static int __devinit pmecc_data_alloc(struct atmel_nand_host *host)
{
const int cap = host->pmecc_corr_cap;
+ int size;
+
+ size = (2 * cap + 1) * sizeof(int16_t);
+ host->pmecc_partial_syn = devm_kzalloc(host->dev, size, GFP_KERNEL);
+ host->pmecc_si = devm_kzalloc(host->dev, size, GFP_KERNEL);
+ host->pmecc_lmu = devm_kzalloc(host->dev,
+ (cap + 1) * sizeof(int16_t), GFP_KERNEL);
+ host->pmecc_smu = devm_kzalloc(host->dev,
+ (cap + 2) * (2 * cap + 1) * sizeof(int16_t), GFP_KERNEL);
+ size = (cap + 1) * sizeof(int);
+ host->pmecc_mu = devm_kzalloc(host->dev, size, GFP_KERNEL);
+ host->pmecc_dmu = devm_kzalloc(host->dev, size, GFP_KERNEL);
+ host->pmecc_delta = devm_kzalloc(host->dev, size, GFP_KERNEL);
+
+ if (!host->pmecc_partial_syn ||
+ !host->pmecc_si ||
+ !host->pmecc_lmu ||
+ !host->pmecc_smu ||
+ !host->pmecc_mu ||
+ !host->pmecc_dmu ||
+ !host->pmecc_delta)
+ return -ENOMEM;
- host->pmecc_partial_syn = kzalloc((2 * cap + 1) * sizeof(int16_t),
- GFP_KERNEL);
- host->pmecc_si = kzalloc((2 * cap + 1) * sizeof(int16_t), GFP_KERNEL);
- host->pmecc_lmu = kzalloc((cap + 1) * sizeof(int16_t), GFP_KERNEL);
- host->pmecc_smu = kzalloc((cap + 2) * (2 * cap + 1) * sizeof(int16_t),
- GFP_KERNEL);
- host->pmecc_mu = kzalloc((cap + 1) * sizeof(int), GFP_KERNEL);
- host->pmecc_dmu = kzalloc((cap + 1) * sizeof(int), GFP_KERNEL);
- host->pmecc_delta = kzalloc((cap + 1) * sizeof(int), GFP_KERNEL);
-
- if (host->pmecc_partial_syn &&
- host->pmecc_si &&
- host->pmecc_lmu &&
- host->pmecc_smu &&
- host->pmecc_mu &&
- host->pmecc_dmu &&
- host->pmecc_delta)
- return 0;
-
- /* error happened */
- pmecc_data_free(host);
- return -ENOMEM;
+ return 0;
}
static void pmecc_gen_syndrome(struct mtd_info *mtd, int sector)
@@ -923,27 +913,25 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
return 0;
}
- host->ecc = ioremap(regs->start, resource_size(regs));
+ host->ecc = devm_request_and_ioremap(&pdev->dev, regs);
if (host->ecc == NULL) {
dev_err(host->dev, "ioremap failed\n");
err_no = -EIO;
- goto err_pmecc_ioremap;
+ goto err;
}
regs_pmerr = platform_get_resource(pdev, IORESOURCE_MEM, 2);
regs_rom = platform_get_resource(pdev, IORESOURCE_MEM, 3);
if (regs_pmerr && regs_rom) {
- host->pmerrloc_base = ioremap(regs_pmerr->start,
- resource_size(regs_pmerr));
- host->pmecc_rom_base = ioremap(regs_rom->start,
- resource_size(regs_rom));
+ host->pmerrloc_base = devm_request_and_ioremap(&pdev->dev, regs_pmerr);
+ host->pmecc_rom_base = devm_request_and_ioremap(&pdev->dev, regs_rom);
}
if (!host->pmerrloc_base || !host->pmecc_rom_base) {
dev_err(host->dev,
"Can not get I/O resource for PMECC ERRLOC controller or ROM!\n");
err_no = -EIO;
- goto err_pmloc_ioremap;
+ goto err;
}
/* ECC is calculated for the whole page (1 step) */
@@ -968,7 +956,7 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
if (nand_chip->ecc.bytes > mtd->oobsize - 2) {
dev_err(host->dev, "No room for ECC bytes\n");
err_no = -EINVAL;
- goto err_no_ecc_room;
+ goto err;
}
pmecc_config_ecc_layout(&atmel_pmecc_oobinfo,
mtd->oobsize,
@@ -993,7 +981,7 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
if (err_no) {
dev_err(host->dev,
"Cannot allocate memory for PMECC computation!\n");
- goto err_pmecc_data_alloc;
+ goto err;
}
nand_chip->ecc.read_page = atmel_nand_pmecc_read_page;
@@ -1003,15 +991,7 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
return 0;
-err_pmecc_data_alloc:
-err_no_ecc_room:
-err_pmloc_ioremap:
- iounmap(host->ecc);
- if (host->pmerrloc_base)
- iounmap(host->pmerrloc_base);
- if (host->pmecc_rom_base)
- iounmap(host->pmecc_rom_base);
-err_pmecc_ioremap:
+err:
return err_no;
}
@@ -1315,7 +1295,7 @@ static int __init atmel_hw_nand_init_params(struct platform_device *pdev,
return 0;
}
- host->ecc = ioremap(regs->start, resource_size(regs));
+ host->ecc = devm_request_and_ioremap(&pdev->dev, regs);
if (host->ecc == NULL) {
dev_err(host->dev, "ioremap failed\n");
return -EIO;
@@ -1380,20 +1360,19 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
}
/* Allocate memory for the device structure (and zero it) */
- host = kzalloc(sizeof(struct atmel_nand_host), GFP_KERNEL);
+ host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
if (!host) {
printk(KERN_ERR "atmel_nand: failed to allocate device structure.\n");
return -ENOMEM;
}
- host->io_phys = (dma_addr_t)mem->start;
-
- host->io_base = ioremap(mem->start, resource_size(mem));
+ host->io_base = devm_request_and_ioremap(&pdev->dev, mem);
if (host->io_base == NULL) {
printk(KERN_ERR "atmel_nand: ioremap failed\n");
res = -EIO;
goto err_nand_ioremap;
}
+ host->io_phys = (dma_addr_t)mem->start;
mtd = &host->mtd;
nand_chip = &host->nand_chip;
@@ -1401,7 +1380,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
if (pdev->dev.of_node) {
res = atmel_of_init_port(host, pdev->dev.of_node);
if (res)
- goto err_ecc_ioremap;
+ goto err_nand_ioremap;
} else {
memcpy(&host->board, pdev->dev.platform_data,
sizeof(struct atmel_nand_data));
@@ -1420,44 +1399,42 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
if (IS_ERR(pinctrl)) {
dev_err(host->dev, "Failed to request pinctrl\n");
res = PTR_ERR(pinctrl);
- goto err_ecc_ioremap;
+ goto err_nand_ioremap;
}
if (gpio_is_valid(host->board.rdy_pin)) {
- res = gpio_request(host->board.rdy_pin, "nand_rdy");
+ res = devm_gpio_request(&pdev->dev,
+ host->board.rdy_pin, "nand_rdy");
if (res < 0) {
dev_err(&pdev->dev,
- "can't request rdy gpio %d\n",
- host->board.rdy_pin);
- goto err_ecc_ioremap;
+ "can't request rdy gpio %d\n", host->board.rdy_pin);
+ goto err_nand_ioremap;
}
res = gpio_direction_input(host->board.rdy_pin);
if (res < 0) {
dev_err(&pdev->dev,
- "can't request input direction rdy gpio %d\n",
- host->board.rdy_pin);
- goto err_ecc_ioremap;
+ "can't request input direction rdy gpio %d\n", host->board.rdy_pin);
+ goto err_nand_ioremap;
}
nand_chip->dev_ready = atmel_nand_device_ready;
}
if (gpio_is_valid(host->board.enable_pin)) {
- res = gpio_request(host->board.enable_pin, "nand_enable");
+ res = devm_gpio_request(&pdev->dev,
+ host->board.enable_pin, "nand_enable");
if (res < 0) {
dev_err(&pdev->dev,
- "can't request enable gpio %d\n",
- host->board.enable_pin);
- goto err_ecc_ioremap;
+ "can't request enable gpio %d\n", host->board.enable_pin);
+ goto err_nand_ioremap;
}
res = gpio_direction_output(host->board.enable_pin, 1);
if (res < 0) {
dev_err(&pdev->dev,
- "can't request output direction enable gpio %d\n",
- host->board.enable_pin);
- goto err_ecc_ioremap;
+ "can't request output direction enable gpio %d\n", host->board.enable_pin);
+ goto err_nand_ioremap;
}
}
@@ -1474,19 +1451,18 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
atmel_nand_enable(host);
if (gpio_is_valid(host->board.det_pin)) {
- res = gpio_request(host->board.det_pin, "nand_det");
+ res = devm_gpio_request(&pdev->dev,
+ host->board.det_pin, "nand_det");
if (res < 0) {
dev_err(&pdev->dev,
- "can't request det gpio %d\n",
- host->board.det_pin);
+ "can't request det gpio %d\n", host->board.det_pin);
goto err_no_card;
}
res = gpio_direction_input(host->board.det_pin);
if (res < 0) {
dev_err(&pdev->dev,
- "can't request input direction det gpio %d\n",
- host->board.det_pin);
+ "can't request input direction det gpio %d\n", host->board.det_pin);
goto err_no_card;
}
@@ -1552,16 +1528,8 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
return res;
err_scan_tail:
- if (host->has_pmecc && host->nand_chip.ecc.mode == NAND_ECC_HW) {
+ if (host->has_pmecc && host->nand_chip.ecc.mode == NAND_ECC_HW)
pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
- pmecc_data_free(host);
- }
- if (host->ecc)
- iounmap(host->ecc);
- if (host->pmerrloc_base)
- iounmap(host->pmerrloc_base);
- if (host->pmecc_rom_base)
- iounmap(host->pmecc_rom_base);
err_hw_ecc:
err_scan_ident:
err_no_card:
@@ -1569,10 +1537,7 @@ err_no_card:
platform_set_drvdata(pdev, NULL);
if (host->dma_chan)
dma_release_channel(host->dma_chan);
-err_ecc_ioremap:
- iounmap(host->io_base);
err_nand_ioremap:
- kfree(host);
return res;
}
@@ -1592,31 +1557,11 @@ static int __exit atmel_nand_remove(struct platform_device *pdev)
pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
pmerrloc_writel(host->pmerrloc_base, ELDIS,
PMERRLOC_DISABLE);
- pmecc_data_free(host);
}
- if (gpio_is_valid(host->board.det_pin))
- gpio_free(host->board.det_pin);
-
- if (gpio_is_valid(host->board.enable_pin))
- gpio_free(host->board.enable_pin);
-
- if (gpio_is_valid(host->board.rdy_pin))
- gpio_free(host->board.rdy_pin);
-
- if (host->ecc)
- iounmap(host->ecc);
- if (host->pmecc_rom_base)
- iounmap(host->pmecc_rom_base);
- if (host->pmerrloc_base)
- iounmap(host->pmerrloc_base);
-
if (host->dma_chan)
dma_release_channel(host->dma_chan);
- iounmap(host->io_base);
- kfree(host);
-
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
From: Måns Rullgård @ 2012-10-13 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121013090255.GT28061@n2100.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> On Sat, Oct 13, 2012 at 04:46:18AM +0000, Paul Walmsley wrote:
>>
>> After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
>> saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
>> started crashing during boot with omap2plus_defconfig:
>>
>> [ 3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
>> [ 3.915954] mmcblk0: p1
>> [ 4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
>> [ 4.093719] Modules linked in:
>> [ 4.096954] CPU: 0 Not tainted (3.6.0-02232-g759e00b #570)
>> [ 4.103149] PC is at vfp_reload_hw+0x1c/0x44
>> [ 4.107666] LR is at __und_usr_fault_32+0x0/0x8
>>
>> It turns out that the context save/restore fix unmasked a latent bug in
>> commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3
>> usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on
>> a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP
>> registers. These are only present on non-D16 VFPv3+, so the kernel dies
>> with an undefined instruction exception. The kernel didn't crash before
>> commit 846a136 because the save and restore code only touched d0-d15,
>> present on all VFP.
>>
>> Fix to save and restore the d16-d31 registers only if they are
>> present.
>
> No. VFPv3D16 HWCAP means that the VFP supports just 16 double registers
> - and it communicates this information to userspace. If this bit is clear,
> and the VFP only has 16 double registers, then _that_ is a bug.
That bit will be clear on VFPv2 (because it's not v3), and this has only
16 D registers. The high D registers are present if (vfpv3 && !vfpv3d16).
Pre-calculating this to avoid doing it in the context save/restore code
is probably a good idea.
--
M?ns Rullg?rd
mans at mansr.com
^ permalink raw reply
* [PATCH 07/12] staging/iio/lis3l02dq: fix building without irq_to_gpio
From: Jonathan Cameron @ 2012-10-13 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201209291503.40519.arnd@arndb.de>
On 09/29/2012 04:03 PM, Arnd Bergmann wrote:
> On Saturday 29 September 2012, Jonathan Cameron wrote:
>> On 09/28/2012 10:36 PM, Arnd Bergmann wrote:
>>> The driver has not been building for some time after the
>>> irq_to_gpio function has been removed from the kernel.
>>>
>>> The only board in the upstream kernel that provides
>>> this device is the "Stargate 2", which is also maintained
>>> by Jonathan Cameron. Rather than working around the problem
>>> by adding new platform data for this driver, this patch
>>> uses the of_gpio framework to get to the gpio number.
>>>
>>> However, the stargate2 code does not (yet) use DT based
>>> probing, so it is still broken, but at least building
>>> allyesconfig works again.
>> Will be optimistic to think anyone will convert a platform
>> that no one still makes (stargate 2 was pretty much intel
>> research only + some they gave to accademics - imote2 has
>> been dropped by memsic for a while now.) If nothing else
>> there is little chance anyone will bother porting a remotely
>> up to date bootloader to these boards given how few people
>> are still using them for anything.
>
> The way are converting most ARM platforms to DT, we should be
> able to replace the board files with .dts files once all
> device drivers have been converted over. This is taking a
> bit longer for mmp/pxa than for some of the other platforms,
> Updating the boot loader makes it easier to deploy a DT
> version, but you can also append a DT blob to the kernel
> if that's not possible, and we will in the future allow
> appending multiple DT blobs and let the early boot stages
> pick the right one based on the board ID.
Sounds good.
>
>> I'm happy enough with this patch. Would prefer to
>> take it post merge window as a fix than now given timing.
>
> Ok, fair enough. It has been broken for a while, so there
> is no hurry now. I just stumbled over it when doing an
> "allyesconfig" build.
Added to togreg branch of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
>
>> Long run this driver will hopefully get replaced by the
>> unified driver for all the st accelerometers (assuming that
>> ever gets back to this long obsolete part).
>
> Ok.
>
> Arnd
>
^ permalink raw reply
* [PATCH] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
From: Russell King - ARM Linux @ 2012-10-13 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210130441300.5736@utopia.booyaka.com>
On Sat, Oct 13, 2012 at 04:46:18AM +0000, Paul Walmsley wrote:
>
> After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
> saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
> started crashing during boot with omap2plus_defconfig:
>
> [ 3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
> [ 3.915954] mmcblk0: p1
> [ 4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> [ 4.093719] Modules linked in:
> [ 4.096954] CPU: 0 Not tainted (3.6.0-02232-g759e00b #570)
> [ 4.103149] PC is at vfp_reload_hw+0x1c/0x44
> [ 4.107666] LR is at __und_usr_fault_32+0x0/0x8
>
> It turns out that the context save/restore fix unmasked a latent bug in
> commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3
> usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on
> a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP
> registers. These are only present on non-D16 VFPv3+, so the kernel dies
> with an undefined instruction exception. The kernel didn't crash before
> commit 846a136 because the save and restore code only touched d0-d15,
> present on all VFP.
>
> Fix to save and restore the d16-d31 registers only if they are
> present.
No. VFPv3D16 HWCAP means that the VFP supports just 16 double registers
- and it communicates this information to userspace. If this bit is clear,
and the VFP only has 16 double registers, then _that_ is a bug.
^ permalink raw reply
* [PATCH V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT
From: Viresh Kumar @ 2012-10-13 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121013064422.GJ12801@game.jcrosoft.org>
On Oct 13, 2012 12:16 PM, "Jean-Christophe PLAGNIOL-VILLARD" <
plagnioj@jcrosoft.com> wrote:
>
> On 22:42 Fri 12 Oct , Viresh Kumar wrote:
> > On 12 October 2012 21:51, Jean-Christophe PLAGNIOL-VILLARD
> > <plagnioj@jcrosoft.com> wrote:
> > >> >> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL,
"cf"),
> > >> > ?/
> > >>
> > >> Sorry. can't get it :(
> > > what is the "cf" as paltfrom data
> >
> > This is dma bus_id string, which matches with what is passed from dtb.
> so pass if via dtb too
Yes. Already passed in 13xx.dtsi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121013/03f00db2/attachment-0001.html>
^ permalink raw reply
* [PATCH 1/1] ARM64: Remove duplicate inclusion of mmu_context.h in smp.c
From: Sachin Kamat @ 2012-10-13 8:25 UTC (permalink / raw)
To: linux-arm-kernel
asm/mmu_context.h was included twice.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
arch/arm64/kernel/smp.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index b711525..226b6bf 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -46,7 +46,6 @@
#include <asm/sections.h>
#include <asm/tlbflush.h>
#include <asm/ptrace.h>
-#include <asm/mmu_context.h>
/*
* as from 2.5, kernels no longer have an init_tasks structure
--
1.7.4.1
^ permalink raw reply related
* pm: add suspend_mem and suspend_standby support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-13 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1538974.3MUX2hoinf@vostro.rjw.lan>
On 01:05 Thu 11 Oct , Rafael J. Wysocki wrote:
> On Wednesday 10 of October 2012 12:47:31 Vaibhav Hiremath wrote:
> >
> > On 10/10/2012 3:42 AM, Rafael J. Wysocki wrote:
> > > On Tuesday 09 of October 2012 17:17:04 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >> On 07:58 Tue 09 Oct , Greg Kroah-Hartman wrote:
> > >>> On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >>>> On 22:02 Sun 07 Oct , Rafael J. Wysocki wrote:
> > >>>>> On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >>>>>> On 00:18 Sun 07 Oct , Rafael J. Wysocki wrote:
> > >>>>>>> On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >>>>>>>> Hi,
> > >>>>>>>>
> > >>>>>>>> The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
> > >>>>>>>>
> > >>>>>>>> Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
> > >>>>>>>>
> > >>>>>>>> are available in the git repository at:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
> > >>>>>>>>
> > >>>>>>>> for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
> > >>>>>>>>
> > >>>>>>>> arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
> > >>>>>>>>
> > >>>>>>>> ----------------------------------------------------------------
> > >>>>>>>> pm: add suspend_mem and suspend_standby support
> > >>>>>>>>
> > >>>>>>>> Today when we go to suspend we can not knwon at drivers level if we go in
> > >>>>>>>> STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
> > >>>>>>>> suspend_standby.
> > >>>>>>>
> > >>>>>>> No way. Device drivers shouldn't be concerned about that.
> > >>>>>> I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
> > >>>>>> need special handling when switching to slow_clock
> > >>>>>
> > >>>>> Well, my answer to that is: please fix your platform code instead of
> > >>>>> hacking the PM core to work around its problems.
> > >>>> how can I fix drivers pm issue when I no way to known at driver level the
> > >>>> real suspend, the PM core is supposed to proivde the right information to the
> > >>>> drivers so the driver can put it's in the right pm mode. If the pm core can not
> > >>>> provide such inforation the PM core is broken as we will have to do dirty
> > >>>> hack.
> > >>>
> > >>> Why do you need to know the difference in your driver? We used to
> > >>> provide this information a long time ago, but it turned out to not be
> > >>> needed at all and just caused problems.
> > >> because on at91 I need to handle the mem standby at drviers level.
> > >
> > > This is not an answer. You're basically saying "it has to be done this way,
> > > because it has to be done this way".
> > >
> > >> We do it today already by a hack in different drivers at91_udc (usb device),
> > >> atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
> > >> to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
> > >> clock - this is done at soc level - but those IP have issue and need specific
> > >> care before doing so. Ohterwise when the SoC will wakeup but those IP will not
> > >>
> > >> in this patch series I send the update of those 3 drivers too
> > >> and kill the hack
> > >
> > > Well, let's start over. What's the difference between "suspend to RAM" (mem)
> > > and "standby" on your platform?
> > >
> > >>>> Any generic framework is supposed to evolve for real user need here I've one
> > >>>> so I udpate the core to mach a need
> > >
> > > Yes, if there are more users needing a change. If there's only one, I think not
> > > really.
> > >
> >
> > We came across such a need while supporting various low-power modes in
> > AM335x SoC. I also wanted to put similar proposal, its good that Jean
> > submitted patches and we are having this discussion early.
> >
> > Let me try to describe the need and issue here,
> >
> > In case of AM33xx device, we have different low-power modes supported
> > by HW, for this discussion I will just talk about DeepSleep-0 and
> > StandBy mode supported by HW (few other modes also described in spec)-
> >
> > Below is the Spec definition of these two low-power modes,
> >
> > PowerMode Application state States
> > ========================================================================
> > DeepSleep0 Everything is preserved Master Oscillator = OFF
> > including SDRAM. VDD_MPU = 0.95v
> > VDD_CORE = 0.95v
> > PD_WKUP = ON
> > PD_MPU = OFF
> > PD_PER = OFF
> > PD_GFX = OFF
> > All IOs & RTC supplies are ON
> >
> >
> > Standby Everything is preserved Master Oscillator = ON
> > including SDRAM. One PLL is ON
> > Only required module clocks VDD_MPU = 0.95v
> > are enabled rest are clock VDD_CORE = OPP50
> > gated PD_WKUP = ON
> > PD_MPU = ON
> > PD_PER = ON
> > PD_GFX = OFF
> > All IOs & RTC supplies are ON
> > If more PLLs /power domains/
> > modules are required, the
> > power will increase
> > accordingly
> >
> >
> >
> > Now we have two major parameters here, Power Consumption and Latency
> > (Sleep + Wakeup). Since DeepSleep-0 is as good as off state, it gives
> > very less power consumption Vs huge Latency number, whereas, in case of
> > standby the power consumption is more but the Latency is reduced.
> >
> > In addition to that, there are certain HW related parameters and issues
> > contribute to these parameters. For example,
> >
> > In case of LCD driver the suspend/resume latency is in the range of
> > 10msec, which can be reduced if driver knows that he is not entering or
> > entered in DeepSleep-0 and choose not to do certain things.
> > Another example would be, USB driver, we have seen Latency numbers in
> > the range of 200msec, and of which 100 msec can simply be taken away if
> > driver knows about the sleep state.
> >
> >
> > I understand that, there is trade-off between power and latency numbers,
> > but for certain use-cases latency is more important and it is not
> > possible without telling driver about the low-power state.
>
> I understand the problem at hand, but the question is who's going to tell
> the driver about that.
>
> Arguably, the PM core is not the right source of that information, because
> if a driver is told "we're going into standby", it will have to ask the
> platform about what "standby" actually means.
who is going to tell the kernel to go to standby and which
the sysfs handle via PM core
so here the one who alwasy have the information is the pm core
Best Regards,
J.
^ permalink raw reply
* [PATCH V2 3/3] ARM: SPEAr13xx: Pass DW DMAC platform data from DT
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-13 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpok5ZOmz9CCJbTGc=_tncxnZYEW7UMh2FcFcs0dB87JAcQ@mail.gmail.com>
On 22:42 Fri 12 Oct , Viresh Kumar wrote:
> On 12 October 2012 21:51, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> >> >> + OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL, "cf"),
> >> > ?/
> >>
> >> Sorry. can't get it :(
> > what is the "cf" as paltfrom data
>
> This is dma bus_id string, which matches with what is passed from dtb.
so pass if via dtb too
Best Regards,
J.
^ permalink raw reply
* [PATCH 1/2] input: gpio-keys: Disable hardware on suspend
From: Dmitry Torokhov @ 2012-10-13 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349964927-18619-1-git-send-email-lee.jones@linaro.org>
Hi Lee,
On Thu, Oct 11, 2012 at 03:15:26PM +0100, Lee Jones wrote:
> From: Jonas Aaberg <jonas.aberg@stericsson.com>
>
> Disable hardware if active when suspending if the hw can not
> wake the system from suspend.
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: linux-input at vger.kernel.org
> Acked-by: Lee Jones <lee.jones@linaro.org>
If you are sending the patch then it should be signed-off-by, not
acked-by, and it should be the very last entry.
> Signed-off-by: Jonas Aaberg <jonas.aberg@stericsson.com>
> Signed-off-by: Philippe Langlais <philippe.langlais@linaro.org>
> Reviewed-by: Bengt Jonsson <bengt.g.jonsson@stericsson.com>
> ---
> drivers/input/keyboard/gpio_keys.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> index cbb1add..7947315 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -46,6 +46,8 @@ struct gpio_keys_drvdata {
> struct input_dev *input;
> struct mutex disable_lock;
> unsigned int n_buttons;
> + bool enabled;
> + bool enable_after_suspend;
> int (*enable)(struct device *dev);
> void (*disable)(struct device *dev);
> struct gpio_button_data data[0];
> @@ -524,6 +526,7 @@ static int gpio_keys_open(struct input_dev *input)
> {
> struct gpio_keys_drvdata *ddata = input_get_drvdata(input);
>
> + ddata->enabled = true;
> return ddata->enable ? ddata->enable(input->dev.parent) : 0;
> }
>
> @@ -533,6 +536,7 @@ static void gpio_keys_close(struct input_dev *input)
>
> if (ddata->disable)
> ddata->disable(input->dev.parent);
> + ddata->enabled = false;
> }
>
> /*
> @@ -674,6 +678,7 @@ static int __devinit gpio_keys_probe(struct platform_device *pdev)
> ddata->n_buttons = pdata->nbuttons;
> ddata->enable = pdata->enable;
> ddata->disable = pdata->disable;
> + ddata->enabled = false;
> mutex_init(&ddata->disable_lock);
>
> platform_set_drvdata(pdev, ddata);
> @@ -789,6 +794,10 @@ static int gpio_keys_suspend(struct device *dev)
> if (bdata->button->wakeup)
> enable_irq_wake(bdata->irq);
> }
> + } else {
> + ddata->enable_after_suspend = ddata->enabled;
> + if (ddata->enabled)
> + gpio_keys_close(ddata->input);
I think it should take ddata->input->mutex to avoid races with
open/close and use ddata->input->users to figure out if device shoudl be
closed and re-opened later.
Thanks.
> }
>
> return 0;
> @@ -807,6 +816,10 @@ static int gpio_keys_resume(struct device *dev)
> if (gpio_is_valid(bdata->button->gpio))
> gpio_keys_gpio_report_event(bdata);
> }
> +
> + if (!device_may_wakeup(dev) && ddata->enable_after_suspend)
> + gpio_keys_open(ddata->input);
> +
> input_sync(ddata->input);
>
> return 0;
> --
> 1.7.9.5
>
--
Dmitry
^ permalink raw reply
* [PATCH for 3.7] dtb: fix interrupt assignment for ehci/uhci on wm8505
From: Tony Prisk @ 2012-10-13 5:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350101882-6195-1-git-send-email-linux@prisktech.co.nz>
On Sat, 2012-10-13 at 17:18 +1300, Tony Prisk wrote:
> EHCI and UHCI devices in wm8505.dtsi should use IRQ 0 & 1
> respectively - not 43 as used on newer models.
Oops - should have been IRQ 1 & 0 - fixed locally.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> arch/arm/boot/dts/wm8505.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
> index b459691..330f833 100644
> --- a/arch/arm/boot/dts/wm8505.dtsi
> +++ b/arch/arm/boot/dts/wm8505.dtsi
> @@ -71,13 +71,13 @@
> ehci at d8007100 {
> compatible = "via,vt8500-ehci";
> reg = <0xd8007100 0x200>;
> - interrupts = <43>;
> + interrupts = <1>;
> };
>
> uhci at d8007300 {
> compatible = "platform-uhci";
> reg = <0xd8007300 0x200>;
> - interrupts = <43>;
> + interrupts = <0>;
> };
>
> fb at d8050800 {
I assume the usb subsystem doesn't fault when IRQ's aren't recieved as
this did give any error messages, it just made the USB extremely slow -
like it was timing-out between requests.
Regards
Tony P
^ permalink raw reply
* [RFC PATCH] ARM: vt8500: Convert arch-vt8500 to multiplatform
From: Tony Prisk @ 2012-10-13 4:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210120752.25450.arnd@arndb.de>
On Fri, 2012-10-12 at 07:52 +0000, Arnd Bergmann wrote:
> On Thursday 11 October 2012, linux at prisktech.co.nz wrote:
> > To clarify what you said (because I'm not sure I got it the first time)...
> >
> > Keep ARCH_VT8500 as the single-platform Kconfig option.
> > Add a new ARCH_VT8500_MULTI (for example) as the multiplatform Kconfig option.
> >
> > Have ARCH_VT8500_MULTI select ARCH_VT8500??
> >
> > The last bit confuses me (and seems a little backwards, although I suspect it
> > would work since none of the options would cause conflicts). Without ARCH_VT8500
> > selected, we have no driver options without changing all the Kconfig's.
> >
> > If this is correct, we are basically using _MULTI to add more options on top of
> > _VT8500.
>
> No, this would not work, because Kconfig does not let you 'select' a symbol
> that is inside of a 'choice' list.
>
> The other way round works though: rename the existing ARCH_VT8500 to
> ARCH_VT8500_SINGLE, and add a new symbol in arch/arm/mach-vt8500/Kconfig
> like
>
> config VT8500
> bool "Via/Wondermedia VT8500 / WM8505 / WM8650" if ARCH_MULTI_V5
> default ARCH_VT8500_SINGLE
>
> This one becomes visible when ARCH_MULTI_V5 is set but invisible in a
> other cases. The 'default ARCH_VT8500_SINGLE' statement means it is
> automatically enabled (but still invisible) if ARCH_VT8500_SINGLE
> is selected in the 'choice', and it's invisible and disabled in all
> other cases.
>
> Arnd
I will leave the patch as is unless someone specifically needs
earlyprintk in the mean time - at the moment, I don't need it again
until we look to add WM8750 and WM8850 (Framebuffer problems at the
moment).
There is plenty of other stuff to do for the existing platforms, and
earlyprintk will be re-enabled once the support is readded.
Tony P
^ permalink raw reply
* [PATCH] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
From: Paul Walmsley @ 2012-10-13 4:46 UTC (permalink / raw)
To: linux-arm-kernel
After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
started crashing during boot with omap2plus_defconfig:
[ 3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[ 3.915954] mmcblk0: p1
[ 4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[ 4.093719] Modules linked in:
[ 4.096954] CPU: 0 Not tainted (3.6.0-02232-g759e00b #570)
[ 4.103149] PC is at vfp_reload_hw+0x1c/0x44
[ 4.107666] LR is at __und_usr_fault_32+0x0/0x8
It turns out that the context save/restore fix unmasked a latent bug in
commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3
usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on
a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP
registers. These are only present on non-D16 VFPv3+, so the kernel dies
with an undefined instruction exception. The kernel didn't crash before
commit 846a136 because the save and restore code only touched d0-d15,
present on all VFP.
Fix to save and restore the d16-d31 registers only if they are
present.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Martin <dave.martin@linaro.org>
---
arch/arm/include/asm/vfp.h | 6 ++++++
arch/arm/include/asm/vfpmacros.h | 8 ++++----
arch/arm/vfp/vfpmodule.c | 10 ++++++++++
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/vfp.h b/arch/arm/include/asm/vfp.h
index f4ab34f..5689798 100644
--- a/arch/arm/include/asm/vfp.h
+++ b/arch/arm/include/asm/vfp.h
@@ -82,3 +82,9 @@
#define VFPOPDESC_UNUSED_BIT (24)
#define VFPOPDESC_UNUSED_MASK (0xFF << VFPOPDESC_UNUSED_BIT)
#define VFPOPDESC_OPDESC_MASK (~(VFPOPDESC_LENGTH_MASK | VFPOPDESC_UNUSED_MASK))
+
+#ifndef __ASSEMBLER__
+#include <linux/types.h>
+
+extern u32 vfp_has_d16_d31;
+#endif
diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
index 6a6f1e4..11496a9 100644
--- a/arch/arm/include/asm/vfpmacros.h
+++ b/arch/arm/include/asm/vfpmacros.h
@@ -25,9 +25,9 @@
#endif
#ifdef CONFIG_VFPv3
#if __LINUX_ARM_ARCH__ <= 6
- ldr \tmp, =elf_hwcap @ may not have MVFR regs
+ ldr \tmp, =vfp_has_d16_d31 @ have VFP regs d16-d31?
ldr \tmp, [\tmp, #0]
- tst \tmp, #HWCAP_VFPv3D16
+ cmp \tmp, #1
ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
addne \base, \base, #32*4 @ step over unused register space
#else
@@ -49,9 +49,9 @@
#endif
#ifdef CONFIG_VFPv3
#if __LINUX_ARM_ARCH__ <= 6
- ldr \tmp, =elf_hwcap @ may not have MVFR regs
+ ldr \tmp, =vfp_has_d16_d31 @ have VFP regs d16-d31?
ldr \tmp, [\tmp, #0]
- tst \tmp, #HWCAP_VFPv3D16
+ cmp \tmp, #1
stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
addne \base, \base, #32*4 @ step over unused register space
#else
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index c834b32..929b53b 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -58,6 +58,12 @@ unsigned int VFP_arch;
union vfp_state *vfp_current_hw_state[NR_CPUS];
/*
+ * If the VFP on this ARM core has registers d16-d31, vfp_has_d16_d31 will
+ * be set to 1; otherwise, 0. Only valid after startup.
+ */
+u32 vfp_has_d16_d31;
+
+/*
* Is 'thread's most up to date state stored in this CPUs hardware?
* Must be called from non-preemptible context.
*/
@@ -691,6 +697,8 @@ static int __init vfp_init(void)
thread_register_notifier(&vfp_notifier_block);
vfp_pm_init();
+ vfp_has_d16_d31 = 0;
+
/*
* We detected VFP, and the support code is
* in place; report VFP support to userspace.
@@ -706,6 +714,8 @@ static int __init vfp_init(void)
*/
if (((fmrx(MVFR0) & MVFR0_A_SIMD_MASK)) == 1)
elf_hwcap |= HWCAP_VFPv3D16;
+ else
+ vfp_has_d16_d31 = 1;
}
#endif
/*
--
1.7.10.4
^ 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