* ARM: CPU hotplug: fix hard-coded control register constants
From: Russell King - ARM Linux @ 2011-01-14 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D30386B.7020200@st.com>
On Fri, Jan 14, 2011 at 05:20:03PM +0530, viresh kumar wrote:
> > diff --git a/arch/arm/mach-s5pv310/hotplug.c b/arch/arm/mach-s5pv310/hotplug.c
> > index 951ba6d..afa5392 100644
> > --- a/arch/arm/mach-s5pv310/hotplug.c
> > +++ b/arch/arm/mach-s5pv310/hotplug.c
> > @@ -30,13 +30,13 @@ static inline void cpu_enter_lowpower(void)
> > * Turn off coherency
> > */
> > " mrc p15, 0, %0, c1, c0, 1\n"
> > - " bic %0, %0, #0x20\n"
> > + " bic %0, %0, %2\n"
>
> but why replace 0x20 with CR_C instead of CR_D
Looks like a mistake - it should've been the one below.
> > " mcr p15, 0, %0, c1, c0, 1\n"
> > " mrc p15, 0, %0, c1, c0, 0\n"
> > " bic %0, %0, #0x04\n"
> > " mcr p15, 0, %0, c1, c0, 0\n"
> > : "=&r" (v)
> > - : "r" (0)
> > + : "r" (0), "Ir" (CR_C)
> > : "cc");
In any case, this code is probably doing the wrong thing - if s5pv310
is not an ARMv6 MPCore the its fiddling with the auxillary control
register is already broken.
> > diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
> > index 17faf77..a5cb1ce 100644
> > --- a/arch/arm/mach-tegra/hotplug.c
> > +++ b/arch/arm/mach-tegra/hotplug.c
> > @@ -26,13 +26,13 @@ static inline void cpu_enter_lowpower(void)
> > * Turn off coherency
> > */
> > " mrc p15, 0, %0, c1, c0, 1\n"
> > - " bic %0, %0, #0x20\n"
> > + " bic %0, %0, %2\n"
>
> here also.
Same comment.
^ permalink raw reply
* ARM: CPU hotplug: fix hard-coded control register constants
From: Russell King - ARM Linux @ 2011-01-14 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114120437.GB15996@n2100.arm.linux.org.uk>
Here's the fix which restores the old (but probably still broken)
behaviour:
Subject: [PATCH] ARM: fix wrongly patched constants
e3d9c625 (ARM: CPU hotplug: fix hard-coded control register constants)
changed the wrong constants in the hotplug assembly code. Fix this.
Reported-by: viresh kumar <viresh.kumar@st.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/mach-s5pv310/hotplug.c | 4 ++--
arch/arm/mach-tegra/hotplug.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-s5pv310/hotplug.c b/arch/arm/mach-s5pv310/hotplug.c
index afa5392..c24235c 100644
--- a/arch/arm/mach-s5pv310/hotplug.c
+++ b/arch/arm/mach-s5pv310/hotplug.c
@@ -30,10 +30,10 @@ static inline void cpu_enter_lowpower(void)
* Turn off coherency
*/
" mrc p15, 0, %0, c1, c0, 1\n"
- " bic %0, %0, %2\n"
+ " bic %0, %0, #0x20\n"
" mcr p15, 0, %0, c1, c0, 1\n"
" mrc p15, 0, %0, c1, c0, 0\n"
- " bic %0, %0, #0x04\n"
+ " bic %0, %0, %2\n"
" mcr p15, 0, %0, c1, c0, 0\n"
: "=&r" (v)
: "r" (0), "Ir" (CR_C)
diff --git a/arch/arm/mach-tegra/hotplug.c b/arch/arm/mach-tegra/hotplug.c
index a5cb1ce..f329404 100644
--- a/arch/arm/mach-tegra/hotplug.c
+++ b/arch/arm/mach-tegra/hotplug.c
@@ -26,10 +26,10 @@ static inline void cpu_enter_lowpower(void)
* Turn off coherency
*/
" mrc p15, 0, %0, c1, c0, 1\n"
- " bic %0, %0, %2\n"
+ " bic %0, %0, #0x20\n"
" mcr p15, 0, %0, c1, c0, 1\n"
" mrc p15, 0, %0, c1, c0, 0\n"
- " bic %0, %0, #0x04\n"
+ " bic %0, %0, %2\n"
" mcr p15, 0, %0, c1, c0, 0\n"
: "=&r" (v)
: "r" (0), "Ir" (CR_C)
--
1.6.2.5
^ permalink raw reply related
* [PATCHv3] hwrng: add support for picoxcell TRNG
From: Jamie Iles @ 2011-01-14 12:16 UTC (permalink / raw)
To: linux-arm-kernel
This driver adds support for the True Random Number Generator in
the Picochip PC3X3 and later devices.
v3: add a timeout of 20us to the read() method and add fault detection
and reset.
v2: fix indentation and cleanup read function to remove single use
variables and to take advantage of the rng buffer being aligned.
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
drivers/char/hw_random/Kconfig | 12 ++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/picoxcell-rng.c | 208 ++++++++++++++++++++++++++++++++
3 files changed, 221 insertions(+), 0 deletions(-)
create mode 100644 drivers/char/hw_random/picoxcell-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index d31483c..beecd1c 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -198,3 +198,15 @@ config HW_RANDOM_NOMADIK
module will be called nomadik-rng.
If unsure, say Y.
+
+config HW_RANDOM_PICOXCELL
+ tristate "Picochip picoXcell true random number generator support"
+ depends on HW_RANDOM && ARCH_PICOXCELL && PICOXCELL_PC3X3
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Picochip PC3x3 and later devices.
+
+ To compile this driver as a module, choose M here: the
+ module will be called picoxcell-rng.
+
+ If unsure, say Y.
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 4273308..3db4eb8 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o
obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o
obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o
+obj-$(CONFIG_HW_RANDOM_PICOXCELL) += picoxcell-rng.o
diff --git a/drivers/char/hw_random/picoxcell-rng.c b/drivers/char/hw_random/picoxcell-rng.c
new file mode 100644
index 0000000..990d55a
--- /dev/null
+++ b/drivers/char/hw_random/picoxcell-rng.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright (c) 2010-2011 Picochip Ltd., Jamie Iles
+ *
+ * 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.
+ *
+ * All enquiries to support at picochip.com
+ */
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#define DATA_REG_OFFSET 0x0200
+#define CSR_REG_OFFSET 0x0278
+#define CSR_OUT_EMPTY_MASK (1 << 24)
+#define CSR_FAULT_MASK (1 << 1)
+#define TRNG_BLOCK_RESET_MASK (1 << 0)
+#define TAI_REG_OFFSET 0x0380
+
+/*
+ * The maximum amount of time in microseconds to spend waiting for data if the
+ * core wants us to wait. The TRNG should generate 32 bits every 320ns so a
+ * timeout of 20us seems reasonable. The TRNG does builtin tests of the data
+ * for randomness so we can't always assume there is data present.
+ */
+#define PICO_TRNG_TIMEOUT 20
+
+static void __iomem *rng_base;
+static struct clk *rng_clk;
+struct device *rng_dev;
+
+static inline u32 picoxcell_trng_read_csr(void)
+{
+ return __raw_readl(rng_base + CSR_REG_OFFSET);
+}
+
+static inline bool picoxcell_trng_is_empty(void)
+{
+ return picoxcell_trng_read_csr() & CSR_OUT_EMPTY_MASK;
+}
+
+/*
+ * Take the random number generator out of reset and make sure the interrupts
+ * are masked. We shouldn't need to get large amounts of random bytes so just
+ * poll the status register. The hardware generates 32 bits every 320ns so we
+ * shouldn't have to wait long enough to warrant waiting for an IRQ.
+ */
+static void picoxcell_trng_start(void)
+{
+ __raw_writel(0, rng_base + TAI_REG_OFFSET);
+ __raw_writel(0, rng_base + CSR_REG_OFFSET);
+}
+
+static void picoxcell_trng_reset(void)
+{
+ __raw_writel(TRNG_BLOCK_RESET_MASK, rng_base + CSR_REG_OFFSET);
+ __raw_writel(TRNG_BLOCK_RESET_MASK, rng_base + TAI_REG_OFFSET);
+ picoxcell_trng_start();
+}
+
+/*
+ * Get some random data from the random number generator. The hw_random core
+ * layer provides us with locking.
+ */
+static int picoxcell_trng_read(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+{
+ int i;
+
+ /* Wait for some data to become available. */
+ for (i = 0; i < PICO_TRNG_TIMEOUT && picoxcell_trng_is_empty(); ++i) {
+ if (!wait)
+ return 0;
+
+ udelay(1);
+ }
+
+ if (picoxcell_trng_read_csr() & CSR_FAULT_MASK) {
+ dev_err(rng_dev, "fault detected, resetting TRNG\n");
+ picoxcell_trng_reset();
+ return -EIO;
+ }
+
+ if (i == PICO_TRNG_TIMEOUT)
+ return 0;
+
+ *(u32 *)buf = __raw_readl(rng_base + DATA_REG_OFFSET);
+ return sizeof(u32);
+}
+
+static struct hwrng picoxcell_trng = {
+ .name = "picoxcell",
+ .read = picoxcell_trng_read,
+};
+
+static int picoxcell_trng_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct resource *mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ if (!mem) {
+ dev_warn(&pdev->dev, "no memory resource\n");
+ return -ENOMEM;
+ }
+
+ if (!devm_request_mem_region(&pdev->dev, mem->start, resource_size(mem),
+ "picoxcell_trng")) {
+ dev_warn(&pdev->dev, "unable to request io mem\n");
+ return -EBUSY;
+ }
+
+ rng_base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
+ if (!rng_base) {
+ dev_warn(&pdev->dev, "unable to remap io mem\n");
+ return -ENOMEM;
+ }
+
+ rng_clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(rng_clk)) {
+ dev_warn(&pdev->dev, "no clk\n");
+ return PTR_ERR(rng_clk);
+ }
+
+ ret = clk_enable(rng_clk);
+ if (ret) {
+ dev_warn(&pdev->dev, "unable to enable clk\n");
+ goto err_enable;
+ }
+
+ picoxcell_trng_start();
+ ret = hwrng_register(&picoxcell_trng);
+ if (ret)
+ goto err_register;
+
+ rng_dev = &pdev->dev;
+ dev_info(&pdev->dev, "pixoxcell random number generator active\n");
+
+ return 0;
+
+err_register:
+ clk_disable(rng_clk);
+err_enable:
+ clk_put(rng_clk);
+
+ return ret;
+}
+
+static int __devexit picoxcell_trng_remove(struct platform_device *pdev)
+{
+ hwrng_unregister(&picoxcell_trng);
+ clk_disable(rng_clk);
+ clk_put(rng_clk);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int picoxcell_trng_suspend(struct device *dev)
+{
+ clk_disable(rng_clk);
+
+ return 0;
+}
+
+static int picoxcell_trng_resume(struct device *dev)
+{
+ return clk_enable(rng_clk);
+}
+
+static const struct dev_pm_ops picoxcell_trng_pm_ops = {
+ .suspend = picoxcell_trng_suspend,
+ .resume = picoxcell_trng_resume,
+};
+#endif /* CONFIG_PM */
+
+static struct platform_driver picoxcell_trng_driver = {
+ .probe = picoxcell_trng_probe,
+ .remove = __devexit_p(picoxcell_trng_remove),
+ .driver = {
+ .name = "picoxcell-trng",
+ .owner = THIS_MODULE,
+#ifdef CONFIG_PM
+ .pm = &picoxcell_trng_pm_ops,
+#endif /* CONFIG_PM */
+ },
+};
+
+static int __init picoxcell_trng_init(void)
+{
+ return platform_driver_register(&picoxcell_trng_driver);
+}
+module_init(picoxcell_trng_init);
+
+static void __exit picoxcell_trng_exit(void)
+{
+ platform_driver_unregister(&picoxcell_trng_driver);
+}
+module_exit(picoxcell_trng_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jamie Iles");
+MODULE_DESCRIPTION("Picochip picoXcell TRNG driver");
--
1.7.3.4
^ permalink raw reply related
* [PATCH V3 25/63] Newly erased page read workaround
From: Linus Walleij @ 2011-01-14 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6187de0568d1ea8a6aeb6c3ca54ac6684bee9973.1292833228.git.viresh.kumar@st.com>
2010/12/20 Viresh Kumar <viresh.kumar@st.com>:
> From: Vipin Kumar <vipin.kumar@st.com>
>
> A newly erased page contains ff in data as well as spare area. While reading an
> erased page, the read out ecc from spare area does not match the ecc generated
> by fsmc ecc hardware accelarator. This is because ecc of data ff ff is not ff
> ff. This leads to errors when jffs2 fs erases and reads back the pages to
> ensure consistency.
>
> This patch adds a software workaround to ensure that the ecc check is not
> performed for erased pages. An erased page is checked by checking data as ff ff.
>
> Signed-off-by: Vipin Kumar <vipin.kumar@st.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Sorry for missing it before.
Yours,
Linus Walleij
^ permalink raw reply
* i.MX & IRQF_ONESHOT
From: Uwe Kleine-König @ 2011-01-14 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101141138480.2678@localhost6.localdomain6>
Hello,
On Fri, Jan 14, 2011 at 11:57:34AM +0100, Thomas Gleixner wrote:
> So there are several things wrong here:
>
> 1) Using handle_level_irq for an edge interrupt is wrong. That's not
> restricted to the TS driver problem at hand. That's wrong in
> general. Other set_type() functions adjust the handler as well when
> they switch the edge/level types.
That was introduced by 060d20d32ae7c6a20a8eac465795ed5bc9b37f7c.
As a quick test you can try to revert that. If that helps I can look
deeper into it. That won't help on at91 though.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v4 05/10] net/fec: add dual fec support for mx28
From: Shawn Guo @ 2011-01-14 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114075223.GC24920@pengutronix.de>
On Fri, Jan 14, 2011 at 08:52:23AM +0100, Uwe Kleine-K?nig wrote:
> On Fri, Jan 14, 2011 at 01:48:40PM +0800, Shawn Guo wrote:
> > Hi Uwe,
> >
> > On Thu, Jan 13, 2011 at 03:48:05PM +0100, Uwe Kleine-K?nig wrote:
> >
> > [...]
> >
> > > > +/* Controller is ENET-MAC */
> > > > +#define FEC_QUIRK_ENET_MAC (1 << 0)
> > > does this really qualify to be a quirk?
> > >
> > My understanding is that ENET-MAC is a type of "quirky" FEC
> > controller.
> >
> > > > +/* Controller needs driver to swap frame */
> > > > +#define FEC_QUIRK_SWAP_FRAME (1 << 1)
> > > IMHO this is a bit misnamed. FEC_QUIRK_NEEDS_BE_DATA or similar would
> > > be more accurate.
> > >
> > When your make this change, you may want to pick a better name for
> > function swap_buffer too.
> >
> > [...]
> >
> > > > +static void *swap_buffer(void *bufaddr, int len)
> > > > +{
> > > > + int i;
> > > > + unsigned int *buf = bufaddr;
> > > > +
> > > > + for (i = 0; i < (len + 3) / 4; i++, buf++)
> > > > + *buf = cpu_to_be32(*buf);
> > > if len isn't a multiple of 4 this accesses bytes behind len. Is this
> > > generally OK here? (E.g. because skbs always have a length that is a
> > > multiple of 4?)
> > The len may not be a multiple of 4. But I believe bufaddr is always
> > a buffer allocated in a length that is a multiple of 4, and the 1~3
> > bytes exceeding the len very likely has no data that matters. But
> > yes, it deserves a safer implementation.
> Did you test what happens if bufaddr isn't aligned? Does it work at all
> then?
>
I see many calls passing a len that is not a multiple of 4, but it
works good.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v4 08/10] ARM: mxs: add ocotp read function
From: Shawn Guo @ 2011-01-14 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114083320.GK26617@pengutronix.de>
On Fri, Jan 14, 2011 at 09:33:20AM +0100, Sascha Hauer wrote:
> On Thu, Jan 13, 2011 at 04:19:39PM +0100, Uwe Kleine-K?nig wrote:
> > On Thu, Jan 06, 2011 at 03:13:16PM +0800, Shawn Guo wrote:
> > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > ---
> > > Changes for v4:
> > > - Call cpu_relax() during polling
> > >
> > > Changes for v2:
> > > - Add mutex locking for mxs_read_ocotp()
> > > - Use type size_t for count and i
> > > - Add comment for clk_enable/disable skipping
> > > - Add ERROR bit clearing and polling step
> > >
> > > arch/arm/mach-mxs/Makefile | 2 +-
> > > arch/arm/mach-mxs/include/mach/common.h | 1 +
> > > arch/arm/mach-mxs/ocotp.c | 79 +++++++++++++++++++++++++++++++
> > > 3 files changed, 81 insertions(+), 1 deletions(-)
> > > create mode 100644 arch/arm/mach-mxs/ocotp.c
> > >
> > > diff --git a/arch/arm/mach-mxs/Makefile b/arch/arm/mach-mxs/Makefile
> > > index 39d3f9c..f23ebbd 100644
> > > --- a/arch/arm/mach-mxs/Makefile
> > > +++ b/arch/arm/mach-mxs/Makefile
> > > @@ -1,5 +1,5 @@
> > > # Common support
> > > -obj-y := clock.o devices.o gpio.o icoll.o iomux.o system.o timer.o
> > > +obj-y := clock.o devices.o gpio.o icoll.o iomux.o ocotp.o system.o timer.o
> > is it worth to make ocotp optional? (and let evk select
> > CONFIG_MXS_OCOTP)
>
> I think not.
>
I thought it depends on how we think about it. If we think that
ocotp is a block of soc and should be on every system based on
the soc, we should build it unconditional. However, if we think
ocotp is a function that could either be used on a machine or not,
it should be built conditional, so that the machine does not use
ocotp function could save the ocotp build and the memory of
u32 ocotp_words[0x20].
--
Regards,
Shawn
^ permalink raw reply
* [GIT PULL] pxa: fixes for 2.6.38-rc
From: Russell King - ARM Linux @ 2011-01-14 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110113230235.GE24149@n2100.arm.linux.org.uk>
On Thu, Jan 13, 2011 at 11:02:35PM +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 13, 2011 at 03:15:21PM -0600, Eric Miao wrote:
> > Hi Russell,
> >
> > The following changes since commit aebf2fc9dc974270b4b25a83816c7051c73f07c8:
> >
> > it8152: add IT8152_LAST_IRQ definition to fix build error
> > (2011-01-02 23:21:14 +0800)
>
> Nope, not pulling.
>
> I don't have this in my tree, and it doesn't appear to exist in Linus'
> tree either. There is this commit:
Eric, I'm planning to do my final push for this merge window this
evening, so I'd like to know whether it's likely that you'll have
this fixed by then?
Thanks.
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Catalin Marinas @ 2011-01-14 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114120229.GA15996@n2100.arm.linux.org.uk>
On Fri, 2011-01-14 at 12:02 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 14, 2011 at 11:43:04AM +0000, Catalin Marinas wrote:
> > > pr_debug("VFP: bounce: trigger %08x fpexc %08x\n", trigger, fpexc);
> > >
> > > /*
> > > + * If the exception occured in thumb mode, pc is exception location + 2,
> > > + * the middle of the 32-bit VFP instruction. Add 2 to get exception
> > > + * location + 4, the same we get in ARM mode.
> > > + */
> > > +#ifdef CONFIG_ARM_THUMB
> > > + if (regs->ARM_cpsr & PSR_T_BIT)
> > > + regs->ARM_pc += 2;
> > > +#endif
> >
> > You can use "if (thumb_mode(regs))" and avoid the #ifdef entirely.
>
> I don't think this is correct. On entry to the undefined instruction
> handler, we get the uncorrected PC value, so PC points to the
> instruction after the faulting instruction.
>
> If it was an ARM instruction, that is located at PC-4. If it was a
> Thumb instruction, it is located at PC-2. This PC value is passed
> unmodified to the VFP entry code, and the passed r2 reflect the
> value in regs->ARM_pc.
The entry-armv.S code adds 2 to the r2 register in case of a 32-bit
Thumb instruction, so it is no longer the same as the ARM_pc.
Since the VFP instructions in Thumb mode are always 32-bit, Colin's
patch made sense to me.
> I think that the undefined instruction handling needs reworking for
> Thumb entirely as we could be dealing with a 16-bit or 32-bit thumb
> instruction, and we have no way of knowing without repeatedly
> decoding that instruction.
We already handle the r2 for in __und_usr. We don't deal with ARM_pc but
we could either do it in __und_usr or let the code handling the undef
fix it up.
--
Catalin
^ permalink raw reply
* [GIT PULL] pxa: fixes for 2.6.38-rc
From: Eric Miao @ 2011-01-14 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114133435.GD15996@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 7:34 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jan 13, 2011 at 11:02:35PM +0000, Russell King - ARM Linux wrote:
>> On Thu, Jan 13, 2011 at 03:15:21PM -0600, Eric Miao wrote:
>> > Hi Russell,
>> >
>> > The following changes since commit aebf2fc9dc974270b4b25a83816c7051c73f07c8:
>> >
>> > ? it8152: add IT8152_LAST_IRQ definition to fix build error
>> > (2011-01-02 23:21:14 +0800)
>>
>> Nope, not pulling.
>>
>> I don't have this in my tree, and it doesn't appear to exist in Linus'
>> tree either. ?There is this commit:
>
> Eric, I'm planning to do my final push for this merge window this
> evening, so I'd like to know whether it's likely that you'll have
> this fixed by then?
Sorry, working on this right now. Will send out the pull minutes later
again.
>
> Thanks.
>
^ permalink raw reply
* [PATCH 2/2] arm: mx50_rdp: add i2c bus support
From: Jason Liu @ 2011-01-14 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294988137-24654-2-git-send-email-richard.zhao@freescale.com>
Hi, Richard,
2011/1/14 Richard Zhao <richard.zhao@freescale.com>:
> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
> ---
> ?arch/arm/mach-mx5/board-mx50_rdp.c ? ? ? ? ? | ? ?7 +++++++
> ?arch/arm/mach-mx5/devices-mx50.h ? ? ? ? ? ? | ? ?3 +++
We need align the naming convention with i.mx53/i.mx50 fordevices-mx50.h ,
I have send out one patch for it.It seems not good when using devices-mx50.h
while using devices-imx53 and devices-imx51.h in the same directory.
I think we need use imx as much as possible since i.mx is FSL chip brand name.
Sascha, please help merge the following patch if you don't have some
comments about it.
http://lists.arm.linux.org.uk/lurker/message/20110110.223149.e2d1fe51.en.html
BR,
Jason
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Sebastian Andrzej Siewior @ 2011-01-14 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105202136.GI817@trinity.fluff.org>
* Ben Dooks | 2011-01-05 20:21:36 [+0000]:
[cut]
I fixed up all your comments (unless I forgot something by accident). Is
it possible for this to go in this merge window or do I have to wait for
the next one?
Sebastian
^ permalink raw reply
* [GIT PULL v2] pxa: patches for v2.6.37-rc
From: Eric Miao @ 2011-01-14 14:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
Didn't realize that some of the fixing patches are in my devel branch, sorry
for the noise. Please pull again and let know if there's any issue.
The following changes since commit 581548db3b3c0f6e25b500329eb02e3c72e7acbe:
Merge branch 'release' of
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
(2011-01-13 11:02:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git devel
Eric Miao (1):
ARM: pxa: fix recursive calls in pxa_low_gpio_chip
Marek Vasut (4):
ARM: pxa: fix warning in zeus.c
ARM: pxa: remove unused variable in clock-pxa3xx.c
ARM: pxa: use cpu_has_ipr() consistently in irq.c
ARM: pxa: fix suspend/resume array index miscalculation
Pavel Machek (1):
ARM: sa1111: fix typo in sa1111_retrigger_lowirq()
Philip Rakity (2):
ARM: mmp: MMP2 drive strength FAST using wrong value
ARM: mmp: PXA910 drive strength FAST using wrong value
arch/arm/common/sa1111.c | 2 +-
arch/arm/mach-mmp/include/mach/mfp-mmp2.h | 2 +-
arch/arm/mach-mmp/include/mach/mfp-pxa910.h | 2 +-
arch/arm/mach-pxa/clock-pxa3xx.c | 1 -
arch/arm/mach-pxa/irq.c | 49 ++++++++++-----------------
arch/arm/mach-pxa/zeus.c | 4 +-
6 files changed, 23 insertions(+), 37 deletions(-)
^ permalink raw reply
* [PATCH 2/2] arm: mx50_rdp: add i2c bus support
From: Richard Zhao @ 2011-01-14 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTik2fL=viMrd=va0VwwNEJzk=hwkPVgFwcqhf5m0@mail.gmail.com>
On Fri, Jan 14, 2011 at 10:27 PM, Jason Liu <liu.h.jason@gmail.com> wrote:
> Hi, Richard,
>
> 2011/1/14 Richard Zhao <richard.zhao@freescale.com>:
>> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
>> ---
>> ?arch/arm/mach-mx5/board-mx50_rdp.c ? ? ? ? ? | ? ?7 +++++++
>> ?arch/arm/mach-mx5/devices-mx50.h ? ? ? ? ? ? | ? ?3 +++
>
> We need align the naming convention with i.mx53/i.mx50 fordevices-mx50.h ,
> I have send out one patch for it.It seems not good when using devices-mx50.h
> while using devices-imx53 and devices-imx51.h in the same directory.
>
> I think we need use imx as much as possible since i.mx is FSL chip brand name.
>
> Sascha, please help merge the following patch if you don't have some
> comments about it.
> http://lists.arm.linux.org.uk/lurker/message/20110110.223149.e2d1fe51.en.html
I have comments on that thread too. I past here:
I noticed that too. Sometimes we use imx as part of file name or macro
name, but other times we use mx . We'd better make some rule that when
and where we suppose to use what.
I suggest we move all to mx for short. Reasons:
- For freescale internal, starting from mx5, we all use mx.
- macros in soc header files all use mx.
- soc header file name all use mx too.
- mach-types all use mx. (count in freescale board only)
Thanks
Richard
>
> BR,
> Jason
>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
^ permalink raw reply
* [PATCH v3 1/1] ARM: Thumb-2: Symbol manipulation macros for function body copying
From: Jean Pihet @ 2011-01-14 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294958503-6537-2-git-send-email-dave.martin@linaro.org>
On Thu, Jan 13, 2011 at 11:41 PM, Dave Martin <dave.martin@linaro.org> wrote:
> In low-level board support code, there is sometimes a need to
> copy a function body to another location at run-time.
>
> A straightforward call to memcpy doesn't work in Thumb-2,
> because bit 0 of external Thumb function symbols is set to 1,
> indicating that the function is Thumb. ?Without corrective
> measures, this will cause an off-by-one copy, and the copy
> may be called using the wrong instruction set.
>
> This patch adds macros to help with such cases.
>
> Particular care is needed, because C doesn't guarantee any
> defined behaviour when casting a function pointer to any other
> type. ?This has been observed to lead to strange optimisation
> side-effects when doing the arithmetic which is required in
> order to copy/move function bodies correctly in Thumb-2.
>
> Thanks to Russell King and Nicolas Pitre for their input.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
Tested OK on OMAP3 in low power modes (RET/OFF) with !CONFIG_THUMB2_KERNEL.
Tested-by: Jean Pihet <j-pihet@ti.com>
> ---
> KernelVersion: v2.6.37
>
> ?arch/arm/include/asm/fncpy.h | ?110 ++++++++++++++++++++++++++++++++++++++++++
> ?1 files changed, 110 insertions(+), 0 deletions(-)
> ?create mode 100644 arch/arm/include/asm/fncpy.h
>
> diff --git a/arch/arm/include/asm/fncpy.h b/arch/arm/include/asm/fncpy.h
> new file mode 100644
> index 0000000..6399265
> --- /dev/null
> +++ b/arch/arm/include/asm/fncpy.h
> @@ -0,0 +1,110 @@
> +/*
> + * arch/arm/include/asm/fncpy.h - helper macros for function body copying
> + *
> + * Copyright (C) 2011 Linaro Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +/*
> + * These macros are intended for use when there is a need to copy a low-level
> + * function body into special memory.
> + *
> + * For example, when reconfiguring the SDRAM controller, the code doing the
> + * reconfiguration may need to run from SRAM.
> + *
> + * NOTE: that the copied function body must be entirely self-contained and
> + * position-independent in order for this to work properly.
> + *
> + *
> + * Typical usage example:
> + *
> + * extern int f(args);
> + * extern uint32_t size_of_f;
> + * int (*copied_f)(args);
> + * void *sram_buffer;
> + *
> + * copied_f = fncpy(sram_buffer, &f, size_of_f);
> + *
> + * ... do any required D-side/I-side synchronisation ...
> + *
> + * ... later, call the function: ...
> + *
> + * copied_f(args);
> + *
> + * The size of the function to be copied can't be determined from C:
> + * this must be determined by other means, such as adding assmbler directives
> + * in the file where f is defined.
> + */
> +
> +#ifndef __ASM_FNCPY_H
> +#define __ASM_FNCPY_H
> +
> +#include <linux/types.h>
> +#include <linux/string.h>
> +
> +#include <asm/cacheflush.h>
> +
> +/* Function pointer casting macros */
> +
> +/* Cast function pointer to integer: */
> +#define __funcp_to_uint(funcp) ({ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? ? ? ? ? uintptr_t __result; ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? ? ? ? ? asm("" : "=r" (__result) : "0" (funcp)); ? ? ? ?\
> + ? ? ? ? ? ? ? __result; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? })
> +
> +/* Cast integer to function pointer with type matching funcp: */
> +#define __uint_to_funcp(i, funcp) ({ ? ? ? ? ? ? ? ? ? \
> + ? ? ? ? ? ? ? typeof(funcp) __result; ? ? ? ? ? ? ? ? \
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? ? ? ? ? asm("" : "=r" (__result) : "0" (i)); ? ?\
> + ? ? ? ? ? ? ? __result; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? })
> +
> +
> +/* Function symbol manipulation macros */
> +
> +/*
> + * FSYM_REBASE: Determine the correct function pointer for funcp,
> + * after the function has been copied to dest_buf:
> + */
> +#define FSYM_REBASE(funcp, dest_buf) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? __uint_to_funcp((uintptr_t)(dest_buf) | FSYM_TYPE(funcp), funcp)
> +
> +/*
> + * FSYM_BASE: Determine the base address in memory of the function funcp
> + * FSYM_TYPE: Determine the instruction set type (ARM/Thumb) of funcp
> + * (both defined below)
> + */
> +
> +#ifdef CONFIG_THUMB2_KERNEL
> +#define FSYM_BASE(funcp) ((void *)(__funcp_to_uint(funcp) & ~(uintptr_t)1))
> +#define FSYM_TYPE(funcp) (__funcp_to_uint(funcp) & 1)
> +#else /* !CONFIG_THUMB2_KERNEL */
> +#define FSYM_BASE(funcp) ((void *)__funcp_to_uint(funcp))
> +#define FSYM_TYPE(funcp) 0
> +#endif /* !CONFIG_THUMB2_KERNEL */
> +
> +/* Function copy helper */
> +#define fncpy(dest_buf, funcp, size) ({ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? ? ? ? ? memcpy(dest_buf, FSYM_BASE(funcp), size); ? ? ? \
> + ? ? ? ? ? ? ? flush_icache_range((unsigned long)(dest_buf), ? \
> + ? ? ? ? ? ? ? ? ? ? ? (unsigned long)(dest_buf) + (size)); ? ?\
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? ? ? ? ? FSYM_REBASE(funcp, dest_buf); ? ? ? ? ? ? ? ? ? \
> + ? ? ? })
> +
> +#endif /* !__ASM_FNCPY_H */
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] Introduce VPR200 board.
From: Fabio Estevam @ 2011-01-14 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294962532-15790-2-git-send-email-marc@cpdesign.com.au>
Hi Marc,
On Thu, Jan 13, 2011 at 9:48 PM, Marc Reilly <marc@cpdesign.com.au> wrote:
....
>
> +config MACH_VPR200
> + ? ? ? bool "Support VPR200 platform"
> + ? ? ? select SOC_IMX35
> + ? ? ? select IMX_HAVE_PLATFORM_FSL_USB2_UDC
> + ? ? ? select IMX_HAVE_PLATFORM_IMX2_WDT
> + ? ? ? select IMX_HAVE_PLATFORM_IMX_UART
> + ? ? ? select IMX_HAVE_PLATFORM_IMX_I2C
> + ? ? ? select IMX_HAVE_PLATFORM_MXC_EHCI
> + ? ? ? select IMX_HAVE_PLATFORM_MXC_NAND
NAND seems to be unused on you board currently.
> + ? ? ? select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
> + ? ? ? select IMX_HAVE_PLATFORM_MXC_PWM
PWM seems to be unused on you board currently.
I think you also need:
select MXC_ULPI if USB_ULPI
Please try building a kernel with only your board selected to make
sure it builds fine.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH] Fix dmaengine_submit() return type
From: Linus Walleij @ 2011-01-14 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110101230023.GE25924@n2100.arm.linux.org.uk>
2011/1/2 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> desc->tx_submit's return type is dma_cookie_t, not int. ?Therefore,
> dmaengine_submit() should match this return type as it's just
> wrapping this detail.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
FWIW
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v6 08/10] ARM: mxs: add ocotp read function
From: Shawn Guo @ 2011-01-14 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294297998-26930-1-git-send-email-shawn.guo@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
---
arch/arm/mach-mxs/Kconfig | 4 ++
arch/arm/mach-mxs/Makefile | 2 +
arch/arm/mach-mxs/include/mach/common.h | 1 +
arch/arm/mach-mxs/ocotp.c | 90 +++++++++++++++++++++++++++++++
4 files changed, 97 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mxs/ocotp.c
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 8bfc8df..cd2fbdf 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -2,6 +2,9 @@ if ARCH_MXS
source "arch/arm/mach-mxs/devices/Kconfig"
+config MXS_OCOTP
+ bool
+
config SOC_IMX23
bool
select CPU_ARM926T
@@ -26,6 +29,7 @@ config MACH_MX28EVK
select SOC_IMX28
select MXS_HAVE_AMBA_DUART
select MXS_HAVE_PLATFORM_FEC
+ select MXS_OCOTP
default y
help
Include support for MX28EVK platform. This includes specific
diff --git a/arch/arm/mach-mxs/Makefile b/arch/arm/mach-mxs/Makefile
index 39d3f9c..df501a8 100644
--- a/arch/arm/mach-mxs/Makefile
+++ b/arch/arm/mach-mxs/Makefile
@@ -1,6 +1,8 @@
# Common support
obj-y := clock.o devices.o gpio.o icoll.o iomux.o system.o timer.o
+obj-$(CONFIG_MXS_OCOTP) += ocotp.o
+
obj-$(CONFIG_SOC_IMX23) += clock-mx23.o mm-mx23.o
obj-$(CONFIG_SOC_IMX28) += clock-mx28.o mm-mx28.o
diff --git a/arch/arm/mach-mxs/include/mach/common.h b/arch/arm/mach-mxs/include/mach/common.h
index 59133eb..635bb5d 100644
--- a/arch/arm/mach-mxs/include/mach/common.h
+++ b/arch/arm/mach-mxs/include/mach/common.h
@@ -13,6 +13,7 @@
struct clk;
+extern const u32 *mxs_get_ocotp(void);
extern int mxs_reset_block(void __iomem *);
extern void mxs_timer_init(struct clk *, int);
diff --git a/arch/arm/mach-mxs/ocotp.c b/arch/arm/mach-mxs/ocotp.c
new file mode 100644
index 0000000..65157a3
--- /dev/null
+++ b/arch/arm/mach-mxs/ocotp.c
@@ -0,0 +1,90 @@
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+
+#include <mach/mxs.h>
+
+#define OCOTP_WORD_OFFSET 0x20
+#define OCOTP_WORD_COUNT 0x20
+
+#define BM_OCOTP_CTRL_BUSY (1 << 8)
+#define BM_OCOTP_CTRL_ERROR (1 << 9)
+#define BM_OCOTP_CTRL_RD_BANK_OPEN (1 << 12)
+
+static DEFINE_MUTEX(ocotp_mutex);
+static u32 ocotp_words[OCOTP_WORD_COUNT];
+
+const u32 *mxs_get_ocotp(void)
+{
+ void __iomem *ocotp_base = MXS_IO_ADDRESS(MXS_OCOTP_BASE_ADDR);
+ int timeout = 0x400;
+ size_t i;
+ static int once = 0;
+
+ if (once)
+ return ocotp_words;
+
+ mutex_lock(&ocotp_mutex);
+
+ /*
+ * clk_enable(hbus_clk) for ocotp can be skipped
+ * as it must be on when system is running.
+ */
+
+ /* try to clear ERROR bit */
+ __mxs_clrl(BM_OCOTP_CTRL_ERROR, ocotp_base);
+
+ /* check both BUSY and ERROR cleared */
+ while ((__raw_readl(ocotp_base) &
+ (BM_OCOTP_CTRL_BUSY | BM_OCOTP_CTRL_ERROR)) && --timeout)
+ cpu_relax();
+
+ if (unlikely(!timeout))
+ goto error_unlock;
+
+ /* open OCOTP banks for read */
+ __mxs_setl(BM_OCOTP_CTRL_RD_BANK_OPEN, ocotp_base);
+
+ /* approximately wait 32 hclk cycles */
+ udelay(1);
+
+ /* poll BUSY bit becoming cleared */
+ timeout = 0x400;
+ while ((__raw_readl(ocotp_base) & BM_OCOTP_CTRL_BUSY) && --timeout)
+ cpu_relax();
+
+ if (unlikely(!timeout))
+ goto error_unlock;
+
+ for (i = 0; i < OCOTP_WORD_COUNT; i++)
+ ocotp_words[i] = __raw_readl(ocotp_base + OCOTP_WORD_OFFSET +
+ i * 0x10);
+
+ /* close banks for power saving */
+ __mxs_clrl(BM_OCOTP_CTRL_RD_BANK_OPEN, ocotp_base);
+
+ once = 1;
+
+ mutex_unlock(&ocotp_mutex);
+
+ return ocotp_words;
+
+error_unlock:
+ mutex_unlock(&ocotp_mutex);
+ pr_err("%s: timeout in reading OCOTP\n", __func__);
+ return NULL;
+}
--
1.7.1
^ permalink raw reply related
* [PATCH] davinci: tnetv107x: fix register indexing for GPIOs numbers > 31
From: Hirosh Dabui @ 2011-01-14 15:18 UTC (permalink / raw)
To: linux-arm-kernel
Changelog:
This patch fix a bug in the register indexing for GPIOs numbers > 31
to get the relevant hardware registers of tnetv107x to control the GPIOs.
In the structure tnetv107x_gpio_regs:
struct tnetv107x_gpio_regs {
u32 idver;
u32 data_in[3];
u32 data_out[3];
u32 direction[3];
u32 enable[3];
};
The GPIO hardware register addresses of tnetv107x are stored.
The chip implements 3 registers of each entity to serve 96 GPIOs,
each register provides a subset of 32 GPIOs.
The driver provides these macros: gpio_reg_set_bit, gpio_reg_get_bit
and gpio_reg_clear_bit.
The bug implied the use of macros to access the relevant hardware
register e.g. the driver code used the macro like this:
'gpio_reg_clear_bit(®->data_out, gpio)'
But it has to be used like this:
'gpio_reg_clear_bit(reg->data_out, gpio)'.
The different results are shown here:
- ®->data_out + 1 (it will add the full array size of data_out i.e. 12 bytes)
- reg->data_out + 1 (it will increment only the size of data_out i.e. only 4 bytes)
Signed-off-by: Hirosh Dabui <hirosh.dabui@snom.com>
---
arch/arm/mach-davinci/gpio-tnetv107x.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-davinci/gpio-tnetv107x.c b/arch/arm/mach-davinci/gpio-tnetv107x.c
index d102986..3fa3e28 100644
--- a/arch/arm/mach-davinci/gpio-tnetv107x.c
+++ b/arch/arm/mach-davinci/gpio-tnetv107x.c
@@ -58,7 +58,7 @@ static int tnetv107x_gpio_request(struct gpio_chip *chip, unsigned offset)
spin_lock_irqsave(&ctlr->lock, flags);
- gpio_reg_set_bit(®s->enable, gpio);
+ gpio_reg_set_bit(regs->enable, gpio);
spin_unlock_irqrestore(&ctlr->lock, flags);
@@ -74,7 +74,7 @@ static void tnetv107x_gpio_free(struct gpio_chip *chip, unsigned offset)
spin_lock_irqsave(&ctlr->lock, flags);
- gpio_reg_clear_bit(®s->enable, gpio);
+ gpio_reg_clear_bit(regs->enable, gpio);
spin_unlock_irqrestore(&ctlr->lock, flags);
}
@@ -88,7 +88,7 @@ static int tnetv107x_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
spin_lock_irqsave(&ctlr->lock, flags);
- gpio_reg_set_bit(®s->direction, gpio);
+ gpio_reg_set_bit(regs->direction, gpio);
spin_unlock_irqrestore(&ctlr->lock, flags);
@@ -106,11 +106,11 @@ static int tnetv107x_gpio_dir_out(struct gpio_chip *chip,
spin_lock_irqsave(&ctlr->lock, flags);
if (value)
- gpio_reg_set_bit(®s->data_out, gpio);
+ gpio_reg_set_bit(regs->data_out, gpio);
else
- gpio_reg_clear_bit(®s->data_out, gpio);
+ gpio_reg_clear_bit(regs->data_out, gpio);
- gpio_reg_clear_bit(®s->direction, gpio);
+ gpio_reg_clear_bit(regs->direction, gpio);
spin_unlock_irqrestore(&ctlr->lock, flags);
@@ -124,7 +124,7 @@ static int tnetv107x_gpio_get(struct gpio_chip *chip, unsigned offset)
unsigned gpio = chip->base + offset;
int ret;
- ret = gpio_reg_get_bit(®s->data_in, gpio);
+ ret = gpio_reg_get_bit(regs->data_in, gpio);
return ret ? 1 : 0;
}
@@ -140,9 +140,9 @@ static void tnetv107x_gpio_set(struct gpio_chip *chip,
spin_lock_irqsave(&ctlr->lock, flags);
if (value)
- gpio_reg_set_bit(®s->data_out, gpio);
+ gpio_reg_set_bit(regs->data_out, gpio);
else
- gpio_reg_clear_bit(®s->data_out, gpio);
+ gpio_reg_clear_bit(regs->data_out, gpio);
spin_unlock_irqrestore(&ctlr->lock, flags);
}
--
1.7.1
^ permalink raw reply related
* [PATCH] OMAP: use fncpy to copy the PM code functions to SRAM
From: jean.pihet at newoldbits.com @ 2011-01-14 15:21 UTC (permalink / raw)
To: linux-arm-kernel
From: Jean Pihet <j-pihet@ti.com>
The new fncpy API is better suited for copying some
code to SRAM at runtime. This patch changes the ad-hoc
code to the more generic fncpy API.
Tested OK on OMAP3 in low power modes (RET/OFF)
with !CONFIG_THUMB2_KERNEL
Signed-off-by: Jean Pihet <j-pihet@ti.com>
---
arch/arm/plat-omap/sram.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index e26e504..e2982b0 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -23,7 +23,7 @@
#include <asm/tlb.h>
#include <asm/cacheflush.h>
-
+#include <asm/fncpy.h>
#include <asm/mach/map.h>
#include <plat/sram.h>
@@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
omap_sram_ceil -= size;
omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
- memcpy((void *)omap_sram_ceil, start, size);
- flush_icache_range((unsigned long)omap_sram_ceil,
- (unsigned long)(omap_sram_ceil + size));
+
+ fncpy((void *)omap_sram_ceil, start, size);
return (void *)omap_sram_ceil;
}
--
1.7.2.3
^ permalink raw reply related
* [PATCH] OMAP: use fncpy to copy the PM code functions to SRAM
From: Jean Pihet @ 2011-01-14 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295018470-18099-1-git-send-email-j-pihet@ti.com>
On Fri, Jan 14, 2011 at 4:21 PM, <jean.pihet@newoldbits.com> wrote:
> From: Jean Pihet <j-pihet@ti.com>
>
> The new fncpy API is better suited for copying some
> code to SRAM at runtime. This patch changes the ad-hoc
> code to the more generic fncpy API.
>
> Tested OK on OMAP3 in low power modes (RET/OFF)
> with !CONFIG_THUMB2_KERNEL
>
> Signed-off-by: Jean Pihet <j-pihet@ti.com>
This patch depends on Dave's '[PATCH v3 1/1] ARM: Thumb-2: Symbol
manipulation macros for function' patch, cf.
http://marc.info/?l=linux-arm-kernel&m=129495865831165&w=2
Regards,
Jean
> ---
> ?arch/arm/plat-omap/sram.c | ? ?7 +++----
> ?1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> index e26e504..e2982b0 100644
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -23,7 +23,7 @@
>
> ?#include <asm/tlb.h>
> ?#include <asm/cacheflush.h>
> -
> +#include <asm/fncpy.h>
> ?#include <asm/mach/map.h>
>
> ?#include <plat/sram.h>
> @@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
>
> ? ? ? ?omap_sram_ceil -= size;
> ? ? ? ?omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
> - ? ? ? memcpy((void *)omap_sram_ceil, start, size);
> - ? ? ? flush_icache_range((unsigned long)omap_sram_ceil,
> - ? ? ? ? ? ? ? (unsigned long)(omap_sram_ceil + size));
> +
> + ? ? ? fncpy((void *)omap_sram_ceil, start, size);
>
> ? ? ? ?return (void *)omap_sram_ceil;
> ?}
> --
> 1.7.2.3
>
>
^ permalink raw reply
* [PATCH 1/1 v2] ARM: Thumb-2: Symbol manipulation macros for function body copying
From: Dave Martin @ 2011-01-14 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110113235524.GB28040@n2100.arm.linux.org.uk>
On Thu, Jan 13, 2011 at 5:55 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jan 13, 2011 at 02:51:45PM -0600, Dave Martin wrote:
>> +/* Cast function pointer to integer: */
>> +#define __funcp_to_uint(funcp) ({ ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
>
> uint is confusing here - it suggests casting a pointer to an unsigned int,
> rather than a uintptr_t. ?Please use uintptr here.
>
>> +/*
>> + * FSYM_REBASE: Determine the correct function pointer for funcp,
>> + * after the function has been copied to dest_buf:
>> + */
>> +#define FSYM_REBASE(funcp, dest_buf) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
>> + ? ? __uint_to_funcp((uintptr_t)(dest_buf) | FSYM_TYPE(funcp), funcp)
>> +
>> +/*
>> + * FSYM_BASE: Determine the base address in memory of the function funcp
>> + * FSYM_TYPE: Determine the instruction set type (ARM/Thumb) of funcp
>> + * (both defined below)
>> + */
>> +
>> +#ifdef CONFIG_THUMB2_KERNEL
>> +#define FSYM_BASE(funcp) ((void *)(__funcp_to_uint(funcp) & ~(uintptr_t)1))
>> +#define FSYM_TYPE(funcp) (__funcp_to_uint(funcp) & 1)
>> +#else /* !CONFIG_THUMB2_KERNEL */
>> +#define FSYM_BASE(funcp) ((void *)__funcp_to_uint(funcp))
>> +#define FSYM_TYPE(funcp) 0
>> +#endif /* !CONFIG_THUMB2_KERNEL */
>
> I'd really like to see these gone - otherwise they'll end up being used
> in code inappropriately. ?I like things to be kept as simple as possible
> with as few opportunities for people to needlessly hook into internal
> implementation details.
>
> If you expose implementation details, people will use them, and then if
> you need to change the implementation, you've got a lot of code to deal
> with.
I guess I agree with that now ... with fncpy() implemented, there's
little legitimate use for the other macros, including the casting
macros.
I'll fold it all into fncpy() and see how that looks.
>
> I don't think we need to make this conditional on THUMB2 either - we're
> probably not wasting much by always clearing and copying the LSB. ?And
> this isn't particularly performance code.
>
Agreed. I originally tried to avoid impacting the ARM case, but that
adds complexity for little benefit.
Cheers
---Dave
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Russell King - ARM Linux @ 2011-01-14 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295014231.7901.41.camel@e102109-lin.cambridge.arm.com>
On Fri, Jan 14, 2011 at 02:10:31PM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-14 at 12:02 +0000, Russell King - ARM Linux wrote:
> > I don't think this is correct. On entry to the undefined instruction
> > handler, we get the uncorrected PC value, so PC points to the
> > instruction after the faulting instruction.
> >
> > If it was an ARM instruction, that is located at PC-4. If it was a
> > Thumb instruction, it is located at PC-2. This PC value is passed
> > unmodified to the VFP entry code, and the passed r2 reflect the
> > value in regs->ARM_pc.
>
> The entry-armv.S code adds 2 to the r2 register in case of a 32-bit
> Thumb instruction, so it is no longer the same as the ARM_pc.
That's something that should be fixed - the entry conditions should be
the same irrespective of thumb or arm encoding.
> Since the VFP instructions in Thumb mode are always 32-bit, Colin's
> patch made sense to me.
I looked up the VADD instruction in the ARM ARM. It has both a 16-bit
and 32-bit encoding.
> > I think that the undefined instruction handling needs reworking for
> > Thumb entirely as we could be dealing with a 16-bit or 32-bit thumb
> > instruction, and we have no way of knowing without repeatedly
> > decoding that instruction.
>
> We already handle the r2 for in __und_usr. We don't deal with ARM_pc but
> we could either do it in __und_usr or let the code handling the undef
> fix it up.
At the moment its just confusing as things stand, as some things are
changed in one place and not the other. Let's kill the pointless
addition of 2 in the undefined instruction handler so that in every
case we enter handlers with r2 == regs->ARM_pc, and regs->ARM_pc
as per the ARM ARM undefined exception entry LR.
Undefined instruction exception handlers can then rely on the meaning
of both of these.
^ permalink raw reply
* [GIT PULL v2] pxa: patches for v2.6.37-rc
From: Russell King - ARM Linux @ 2011-01-14 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin_LK7MtJiz7e417k4XCumOBq+dnTgLBCe8HYj1@mail.gmail.com>
On Fri, Jan 14, 2011 at 08:37:13AM -0600, Eric Miao wrote:
> Didn't realize that some of the fixing patches are in my devel branch, sorry
> for the noise. Please pull again and let know if there's any issue.
>
> The following changes since commit 581548db3b3c0f6e25b500329eb02e3c72e7acbe:
>
> Merge branch 'release' of
> git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
> (2011-01-13 11:02:55 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git devel
Thanks. I'll wait until just before sending the pull request as this
commit is based on something beyond 9e9bc973, which is what I'm using
internally as the basis for anything I'm doing (as that is the last
commit where the kernels I care about are buildable.)
^ permalink raw reply
* [PATCH] OMAP: use fncpy to copy the PM code functions to SRAM
From: Russell King - ARM Linux @ 2011-01-14 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295018470-18099-1-git-send-email-j-pihet@ti.com>
On Fri, Jan 14, 2011 at 04:21:10PM +0100, jean.pihet at newoldbits.com wrote:
> From: Jean Pihet <j-pihet@ti.com>
>
> The new fncpy API is better suited for copying some
> code to SRAM at runtime. This patch changes the ad-hoc
> code to the more generic fncpy API.
>
> Tested OK on OMAP3 in low power modes (RET/OFF)
> with !CONFIG_THUMB2_KERNEL
>
> Signed-off-by: Jean Pihet <j-pihet@ti.com>
> ---
> arch/arm/plat-omap/sram.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> index e26e504..e2982b0 100644
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -23,7 +23,7 @@
>
> #include <asm/tlb.h>
> #include <asm/cacheflush.h>
> -
> +#include <asm/fncpy.h>
> #include <asm/mach/map.h>
>
> #include <plat/sram.h>
> @@ -251,9 +251,8 @@ void * omap_sram_push(void * start, unsigned long size)
>
> omap_sram_ceil -= size;
> omap_sram_ceil = ROUND_DOWN(omap_sram_ceil, sizeof(void *));
> - memcpy((void *)omap_sram_ceil, start, size);
> - flush_icache_range((unsigned long)omap_sram_ceil,
> - (unsigned long)(omap_sram_ceil + size));
> +
> + fncpy((void *)omap_sram_ceil, start, size);
>
> return (void *)omap_sram_ceil;
That's actually wrong usage, as you won't get the T bit set if the original
function had it.
The right solution to this is to change omap_sram_push() to become just an
allocator, and then use fncpy() outside of that.
So:
extern int my_func_size;
extern void my_func(int blah);
void (*sram_my_func)(int);
void *sram = omap_sram_push(my_func_size);
if (sram)
sram_my_func = fncpy(sram, my_func, my_func_size);
Two benefits: 1. you get the thumb mode bit propagated (which is the
point of fncpy), and 2. you get the security of type safety between
my_func and the sram function pointer.
If you cast things to a void pointer and ignore the return value of fncpy
then you lose the whole point of this API _and_ any form of type safety.
^ 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