* [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
* [PATCH 2/2] arm: mx50_rdp: add i2c bus support
From: Jason Liu @ 2011-01-14 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinahps3SxrSy+SRD_H+ifHnQTpuFpC4+2mTFLaC@mail.gmail.com>
Hi, Richard,
2011/1/14 Richard Zhao <linuxzsc@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)
No, I prefer to use imx since imx is the chip brand and FSL IC doc
stat it clearly it's i.mx.
And the most important is to keep compatible, we had better keep the
same naming convention.
Otherwise, it will make the directory a little mess.
>
> 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] hwrng: add support for picoxcell TRNG
From: Jamie Iles @ 2011-01-14 16:10 UTC (permalink / raw)
To: linux-arm-kernel
This driver adds support for the True Random Number Generator in
the Picochip PC3X3 and later devices.
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
ARCH_PICOXCELL machine support patches have been posted the ARM mailing
lists for review (with another revision to follow soon).
drivers/char/hw_random/Kconfig | 12 ++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/picoxcell-rng.c | 175 ++++++++++++++++++++++++++++++++
3 files changed, 188 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..e750056
--- /dev/null
+++ b/drivers/char/hw_random/picoxcell-rng.c
@@ -0,0 +1,175 @@
+/*
+ * 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/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 TAI_REG_OFFSET 0x0380
+
+static void __iomem *rng_base;
+static struct clk *rng_clk;
+
+/*
+ * Get some random data from the random number generator. The hw_random core
+ * layer provides us with locking. We can't rely on data being word aligned
+ * though so we'll need to do a memcpy.
+ */
+static int picoxcell_trng_read(struct hwrng *rng, void *buf, size_t max,
+ bool wait)
+{
+ u32 __iomem *csr = rng_base + CSR_REG_OFFSET;
+ int data_avail = !(__raw_readl(csr) & CSR_OUT_EMPTY_MASK);
+ u32 data;
+
+ if (!data_avail && !wait)
+ return 0;
+
+ /* Wait for some data to become available. */
+ while (!data_avail) {
+ data_avail = !(__raw_readl(csr) & CSR_OUT_EMPTY_MASK);
+ cpu_relax();
+ }
+
+ data = __raw_readl(rng_base + DATA_REG_OFFSET);
+ memcpy(buf, &data, min(max, sizeof(data)));
+
+ return sizeof(data);
+}
+
+static struct hwrng picoxcell_trng = {
+ .name = "picoxcell",
+ .read = picoxcell_trng_read,
+};
+
+/*
+ * 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 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;
+
+ 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] OMAP: use fncpy to copy the PM code functions to SRAM
From: Jean Pihet @ 2011-01-14 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114155806.GA22505@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 4:58 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> 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.
Oops ok got 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);
Is the name 'omap_sram_push' wrong then?
What about the following?
@@ -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));
- return (void *)omap_sram_ceil;
+ return fncpy((void *)omap_sram_ceil, start, 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.
>
Thanks for reviewing the patch.
Regards,
Jean
^ permalink raw reply
* [GIT PULL v2] pxa: patches for v2.6.37-rc
From: Russell King - ARM Linux @ 2011-01-14 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114155229.GF15996@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 03:52:29PM +0000, Russell King - ARM Linux wrote:
> 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.)
I just tried merging this on my devel-stable branch (which is where
Lennert's irq work was merged) and the result was some nasty conflicts.
I wouldn't like to guess what the right solution for this is:
diff --cc arch/arm/mach-pxa/irq.c
index 3f7f5bf,6107253..0000000
--- a/arch/arm/mach-pxa/irq.c
+++ b/arch/arm/mach-pxa/irq.c
@@@ -53,12 -53,23 +53,27 @@@ static inline int cpu_has_ipr(void
return !cpu_is_pxa25x();
}
++<<<<<<< HEAD:arch/arm/mach-pxa/irq.c
+static void pxa_mask_irq(struct irq_data *d)
++=======
+ static inline void __iomem *irq_base(int i)
+ {
+ static unsigned long phys_base[] = {
+ 0x40d00000,
+ 0x40d0009c,
+ 0x40d00130,
+ };
+
+ return (void __iomem *)io_p2v(phys_base[i]);
+ }
+
+ static void pxa_mask_irq(unsigned int irq)
++>>>>>>> 9c39c4df81fb0e8ec410714b689dbb6af9c70b54:arch/arm/mach-pxa/irq.c
{
- void __iomem *base = get_irq_chip_data(irq);
+ void __iomem *base = irq_data_get_irq_chip_data(d);
uint32_t icmr = __raw_readl(base + ICMR);
- icmr &= ~(1 << IRQ_BIT(irq));
+ icmr &= ~(1 << IRQ_BIT(d->irq));
__raw_writel(icmr, base + ICMR);
}
@@@ -103,31 -114,17 +118,40 @@@ static int pxa_set_low_gpio_type(struc
return 0;
}
-static void pxa_ack_low_gpio(unsigned int irq)
+static void pxa_ack_low_gpio(struct irq_data *d)
+{
+ GEDR0 = (1 << (d->irq - IRQ_GPIO0));
+}
+
++<<<<<<< HEAD:arch/arm/mach-pxa/irq.c
+static void pxa_mask_low_gpio(struct irq_data *d)
+{
+ struct irq_desc *desc = irq_to_desc(d->irq);
+
+ desc->irq_data.chip->irq_mask(d);
+}
+
+static void pxa_unmask_low_gpio(struct irq_data *d)
{
- GEDR0 = (1 << (irq - IRQ_GPIO0));
+ struct irq_desc *desc = irq_to_desc(d->irq);
+
+ desc->irq_data.chip->irq_unmask(d);
}
static struct irq_chip pxa_low_gpio_chip = {
.name = "GPIO-l",
+ .irq_ack = pxa_ack_low_gpio,
+ .irq_mask = pxa_mask_low_gpio,
+ .irq_unmask = pxa_unmask_low_gpio,
+ .irq_set_type = pxa_set_low_gpio_type,
++=======
++static struct irq_chip pxa_low_gpio_chip = {
++ .name = "GPIO-l",
+ .ack = pxa_ack_low_gpio,
+ .mask = pxa_mask_irq,
+ .unmask = pxa_unmask_irq,
+ .set_type = pxa_set_low_gpio_type,
++>>>>>>> 9c39c4df81fb0e8ec410714b689dbb6af9c70b54:arch/arm/mach-pxa/irq.c
};
static void __init pxa_init_low_gpio_irq(set_wake_t fn)
@@@ -145,20 -143,9 +170,9 @@@
set_irq_flags(irq, IRQF_VALID);
}
- pxa_low_gpio_chip.set_wake = fn;
+ pxa_low_gpio_chip.irq_set_wake = fn;
}
- static inline void __iomem *irq_base(int i)
- {
- static unsigned long phys_base[] = {
- 0x40d00000,
- 0x40d0009c,
- 0x40d00130,
- };
-
- return (void __iomem *)io_p2v(phys_base[i >> 5]);
- }
-
void __init pxa_init_irq(int irq_nr, set_wake_t fn)
{
int irq, i, n;
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Catalin Marinas @ 2011-01-14 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114154919.GE15996@n2100.arm.linux.org.uk>
On Fri, 2011-01-14 at 15:49 +0000, Russell King - ARM Linux wrote:
> 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.
But in this case you have to fix the vfphw.S code to check for Thumb and
subtract 2 rather than 4 from r2.
> > 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.
Are you sure? The Thumb encoding is made up of two 16-bit values but it
is still 32-bit in total.
> > > 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.
That's an alternative, though we may end up with checking the encoding
twice. The Undef handler already reads the instruction opcode and it
needs to know whether it is a 16 or a 32-bit wide instruction.
But I agree that the current implementation is a bit confusing.
--
Catalin
^ permalink raw reply
* [PATCH 01/54] ARM: core irq_data conversion.
From: Russell King - ARM Linux @ 2011-01-14 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101130132532.GB15575@mail.wantstofly.org>
On Tue, Nov 30, 2010 at 02:25:32PM +0100, Lennert Buytenhek wrote:
> @@ -169,10 +169,11 @@ int __init arch_probe_nr_irqs(void)
>
> static void route_irq(struct irq_desc *desc, unsigned int irq, unsigned int cpu)
> {
> - pr_debug("IRQ%u: moving from cpu%u to cpu%u\n", irq, desc->node, cpu);
> + pr_debug("IRQ%u: moving from cpu%u to cpu%u\n", irq, desc->irq_data.node, cpu);
>
> raw_spin_lock_irq(&desc->lock);
> - desc->chip->set_affinity(irq, cpumask_of(cpu));
> + desc->irq_data.chip->irq_set_affinity(&desc->irq_data,
> + cpumask_of(cpu), false);
Shouldn't this be 'true' to force the IRQ to move? The old CPU is
going down so it's not really optional.
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Dave Martin @ 2011-01-14 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295014231.7901.41.camel@e102109-lin.cambridge.arm.com>
Hi,
On Fri, Jan 14, 2011 at 8:10 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> 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.
Is the comment preceding __und_usr_unknown causing some confusion here?
/*
* The FP module is called with these registers set:
* r0 = instruction
* r2 = PC+4
...
That reflects the ARM case only: for Thumb, r2 is always PC+2 (?)
The comment at the start of do_undefinstr() (which receives these
registers) is correct though:
/*
* According to the ARM ARM, PC is 2 or 4 bytes ahead,
* depending whether we're in Thumb mode or not.
* Correct this offset.
Cheers
---Dave
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Russell King - ARM Linux @ 2011-01-14 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295022193.7901.56.camel@e102109-lin.cambridge.arm.com>
On Fri, Jan 14, 2011 at 04:23:12PM +0000, Catalin Marinas wrote:
> On Fri, 2011-01-14 at 15:49 +0000, Russell King - ARM Linux wrote:
> > 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.
>
> But in this case you have to fix the vfphw.S code to check for Thumb and
> subtract 2 rather than 4 from r2.
So is this right for Thumb? Or does it need to be 2 for thumb and 4 for
ARM? Maybe it needs documenting to say why 4 is always correct (if that
is the case).
check_for_exception:
tst r1, #FPEXC_EX
bne process_exception @ might as well handle the pending
@ exception before retrying branch
@ out before setting an FPEXC that
@ stops us reading stuff
VFPFMXR FPEXC, r1 @ restore FPEXC last
sub r2, r2, #4
str r2, [sp, #S_PC] @ retry the instruction
> > > 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.
>
> Are you sure? The Thumb encoding is made up of two 16-bit values but it
> is still 32-bit in total.
No, I'm not sure - it looks like it is made up from two 16-bit
instructions.
> > 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.
>
> That's an alternative, though we may end up with checking the encoding
> twice. The Undef handler already reads the instruction opcode and it
> needs to know whether it is a 16 or a 32-bit wide instruction.
At the moment we add 2 in one place, take off 4 in another, and now
we're going to add 2 in a completely different place. This is insane.
It's a big mess, one which it's impossible to tell if anything is
correct or even easy to follow what's going on.
I don't really care what it's replaced with provided its replaced by
something sane, easy to follow and obviously correct.
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Russell King - ARM Linux @ 2011-01-14 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=4=c0B3Qo+boguUw-DvEihBej5Zz_d2QWmoucm@mail.gmail.com>
On Fri, Jan 14, 2011 at 10:24:52AM -0600, Dave Martin wrote:
> Is the comment preceding __und_usr_unknown causing some confusion here?
>
> /*
> * The FP module is called with these registers set:
> * r0 = instruction
> * r2 = PC+4
> ...
>
> That reflects the ARM case only: for Thumb, r2 is always PC+2 (?)
Actually, referring to 'PC' here is confusing (and yes, I probably wrote
it) - does 'PC' refer to the address of the faulting instruction or the
current PC value...
Your '(?)' there is exactly the problem I'm referring to - I don't think
there's much of a clear idea really what's going on here...
> The comment at the start of do_undefinstr() (which receives these
> registers) is correct though:
>
> /*
> * According to the ARM ARM, PC is 2 or 4 bytes ahead,
> * depending whether we're in Thumb mode or not.
> * Correct this offset.
The ARM ARM says that in order to return to the instruction which
generated the exception, subtract 2 bytes for thumb or 4 bytes for
ARM.
So, in order to point at the instruction which generated the exception,
we have to subtract this value from the PC value we were passed. I
suggest changing this comment to:
/*
* According to the ARM ARM, the PC is 2 or 4 bytes ahead
* depending on Thumb mode. Correct this offset so that
* regs->ARM_pc points at the faulting instruction.
*/
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Catalin Marinas @ 2011-01-14 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114163520.GH15996@n2100.arm.linux.org.uk>
On Fri, 2011-01-14 at 16:35 +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 14, 2011 at 04:23:12PM +0000, Catalin Marinas wrote:
> > On Fri, 2011-01-14 at 15:49 +0000, Russell King - ARM Linux wrote:
> > > 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.
> >
> > But in this case you have to fix the vfphw.S code to check for Thumb and
> > subtract 2 rather than 4 from r2.
>
> So is this right for Thumb? Or does it need to be 2 for thumb and 4 for
> ARM? Maybe it needs documenting to say why 4 is always correct (if that
> is the case).
>
> check_for_exception:
> tst r1, #FPEXC_EX
> bne process_exception @ might as well handle the pending
> @ exception before retrying branch
> @ out before setting an FPEXC that
> @ stops us reading stuff
> VFPFMXR FPEXC, r1 @ restore FPEXC last
> sub r2, r2, #4
> str r2, [sp, #S_PC] @ retry the instruction
If we don't touch r2 in __und_usr, than in vfphw.S we would need to
subtract 2 for Thumb and 4 for ARM. But since we did +2 in __und_usr, we
always subtracted 4 here (confusingly though).
> > > 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.
> >
> > That's an alternative, though we may end up with checking the encoding
> > twice. The Undef handler already reads the instruction opcode and it
> > needs to know whether it is a 16 or a 32-bit wide instruction.
>
> At the moment we add 2 in one place, take off 4 in another, and now
> we're going to add 2 in a completely different place. This is insane.
> It's a big mess, one which it's impossible to tell if anything is
> correct or even easy to follow what's going on.
I agree, this code needs some clean-up. Maybe for Undef we could unify
the ARM and Thumb-2 offsets so that they are both 4 (it may confuse the
breakpoint code, I haven't checked).
Otherwise just let the code handling the undef deal with the ARM/Thumb
difference. For SVC, it makes sense to have different offsets as we
always return to the next instruction.
--
Catalin
^ permalink raw reply
* [GIT PULL v3] pxa: patches for v2.6.38-rc
From: Eric Miao @ 2011-01-14 17:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
I rebased the branch on top of devel-stable. The conflict in irq.c is
fixed. And there is a one-liner patch fixing a building issue in spitz.c
missing of physmap.h. Please re-pull and let know any other issue.
Sorry for the inconvenience.
The following changes since commit 5b88128fd70dcf0d5d7c0ae7d7849777ff925bde:
ARM: plat-stmp3xxx: irq_data conversion. (2011-01-13 17:19:14 +0100)
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 (2):
ARM: pxa: fix recursive calls in pxa_low_gpio_chip
ARM: pxa: fix building issue of missing physmap.h
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 | 53 ++++++++++-----------------
arch/arm/mach-pxa/spitz.c | 1 +
arch/arm/mach-pxa/zeus.c | 4 +-
7 files changed, 26 insertions(+), 39 deletions(-)
^ permalink raw reply
* [PATCH 1/1 v2] ARM: Thumb-2: Symbol manipulation macros for function body copying
From: Dave Martin @ 2011-01-14 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=QRDt62wgnHW6ya+956BS9x7pQj2voTiF+H0vs@mail.gmail.com>
Hi again,
There's another problem which I hadn't spotted before:
In the Thumb case, we risk violating the alignment constraints of the
code which gets copied (actually, this is also true of the ARM case,
but less likely to bite). This matters because the code may contain
literals and other data words -- quite likely given the requirement
for self-containedness.
In the simplest case, we could just require the caller to ensure that
there are is at least size+2 bytes of space at dest_buf: then we can
actually copy the function to dest_buf+2 if this is needed to preserve
word alignment. But this does make the API harder to use. For
Thumb-2, at least word alignment is always needed, even if the start
address of the function is only halfword-aligned, because of the way
literals are addressed.
There could also be a need for alignment greater than word alignment
in some cases; for example, where ldrd/strd or some hardware operation
needs an aligned buffer. This would be rarer though; perhaps we could
get away without it.
We could provide a helper to determine how much space to request from
the allocator:
dest_size = fncpy_size(function, size_of_function, alignment);
dest_buf = allocate(dest_size);
fncpy(dest_buf, &function, size_of_function, alignment);
If we don't know what alignment guarantee is provided by the allocator
itself, we might have to define this conservatively, e.g.:
size_t fncpy_size(function, size_of_function, alignment)
{
return size_of_function + alignment - 1;
}
...to guarantee the possibility of rounding the copied function
address up far enough to achieve the required alignment without
overrunning the buffer. Of course, we can probably get simpler that
that...
Any thoughts?
Cheers
---Dave
On Fri, Jan 14, 2011 at 9:42 AM, Dave Martin <dave.martin@linaro.org> wrote:
> 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] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Tony Lindgren @ 2011-01-14 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110113164957.GA28040@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 08:49]:
> On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110113 01:15]:
> > > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > > that this kind of stuff is still going on...
> >
> > At least I boot test the patches I send..
>
> Which is why OMAP3 and OMAP4 can't be built in mainline because they
> spit out lots of compile errors in the OMAP code... As they won't
> even compile they couldn't have been boot tested.
Huh? I have fixes queued up for the issues that showed up with
merges with various other trees.
I certainly make sure everything I merge is compile and boot
tested. Sure there are still tons of issues still remaining,
but people are working on those. That's why we have the -rc
releases.
Tony
^ permalink raw reply
* [PATCH] ARM: vfp: Fix up exception location in Thumb mode
From: Russell King - ARM Linux @ 2011-01-14 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295024327.7901.70.camel@e102109-lin.cambridge.arm.com>
On Fri, Jan 14, 2011 at 04:58:47PM +0000, Catalin Marinas wrote:
> I agree, this code needs some clean-up. Maybe for Undef we could unify
> the ARM and Thumb-2 offsets so that they are both 4 (it may confuse the
> breakpoint code, I haven't checked).
>
> Otherwise just let the code handling the undef deal with the ARM/Thumb
> difference. For SVC, it makes sense to have different offsets as we
> always return to the next instruction.
I think it just needs better documentation.
Having been through all this, there _are_ bugs lurking in the code exactly
because of this randomness with what PC value is means what.
When the VFP support code tests the state of the VFP hardware during boot,
it sets the VFP handler to point at vfp_testing_entry, bypassing the normal
VFP handling code, and executes a VFP instruction.
If this VFP instruction faults (eg, because there is no VFP hardware
present or we're not permitted to use it), it could end up resuming
execution in the middle of the 16-bit paired instruction because
regs->ARM_pc points in the middle of it.
So vfp_testing_entry should at least store r2 into regs->ARM_pc to
guarantee resuming at the following instruction.
So maybe the right answer is to store r2 into regs->ARM_pc in
process_exception in the VFP assembly code too?
Or maybe we should just make it unconditional that whenever we have an
undefined instruction exception, the regs->ARM_pc value will always be
set for resuming execution after the faulted instruction. That makes
it consistent with r2 throughout the code in every case.
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 2b46fea..5876eec 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -461,27 +461,35 @@ ENDPROC(__irq_usr)
.align 5
__und_usr:
usr_entry
-
- @
- @ fall through to the emulation code, which returns using r9 if
- @ it has emulated the instruction, or the more conventional lr
- @ if we are to treat this as a real undefined instruction
@
- @ r0 - instruction
+ @ The emulation code returns using r9 if it has emulated the
+ @ instruction, or the more conventional lr if we are to treat
+ @ this as a real undefined instruction
@
adr r9, BSYM(ret_from_exception)
adr lr, BSYM(__und_usr_unknown)
+ @
+ @ r2 = regs->ARM_pc, which is either 2 or 4 bytes ahead of the
+ @ faulting instruction depending on Thumb mode.
+ @ r3 = regs->ARM_cpsr
+ @
tst r3, #PSR_T_BIT @ Thumb mode?
- itet eq @ explicit IT needed for the 1f label
+ itttt eq @ explicit IT needed for the 1f label
subeq r4, r2, #4 @ ARM instr at LR - 4
- subne r4, r2, #2 @ Thumb instr at LR - 2
1: ldreqt r0, [r4]
#ifdef CONFIG_CPU_ENDIAN_BE8
reveq r0, r0 @ little endian instruction
#endif
+ @
+ @ r0 = 32-bit ARM instruction which caused the exception
+ @ r2 = PC value for the following instruction (:= regs->ARM_pc)
+ @ r4 = PC value for the faulting instruction
+ @
beq call_fpe
+
@ Thumb instruction
#if __LINUX_ARM_ARCH__ >= 7
+ sub r4, r2, #2 @ Thumb instr at LR - 2
2:
ARM( ldrht r5, [r4], #2 )
THUMB( ldrht r5, [r4] )
@@ -492,18 +500,19 @@ __und_usr:
3: ldrht r0, [r4]
add r2, r2, #2 @ r2 is PC + 2, make it PC + 4
orr r0, r0, r5, lsl #16
+ @
+ @ r0 = the two 16-bit Thumb instructions which caused the exception
+ @ r2 = PC value for the following Thumb instruction (:= regs->ARM_pc+2)
+ @ r4 = PC value for the first 16-bit Thumb instruction
+ @
#else
b __und_usr_unknown
#endif
- UNWIND(.fnend )
+ UNWIND(.fnend)
ENDPROC(__und_usr)
- @
- @ fallthrough to call_fpe
- @
-
/*
- * The out of line fixup for the ldrt above.
+ * The out of line fixup for the ldrt instructions above.
*/
.pushsection .fixup, "ax"
4: mov pc, r9
@@ -534,11 +543,12 @@ ENDPROC(__und_usr)
* NEON handler code.
*
* Emulators may wish to make use of the following registers:
- * r0 = instruction opcode.
- * r2 = PC+4
+ * r0 = instruction opcode (32-bit ARM or two 16-bit Thumb)
+ * r2 = PC value to resume execution after successful emulation
* r9 = normal "successful" return address
- * r10 = this threads thread_info structure.
+ * r10 = this threads thread_info structure
* lr = unrecognised instruction return address
+ * IRQs disabled, FIQs enabled.
*/
@
@ Fall-through from Thumb-2 __und_usr
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index ee57640..eeb9250 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -347,9 +347,9 @@ asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
void __user *pc;
/*
- * According to the ARM ARM, PC is 2 or 4 bytes ahead,
- * depending whether we're in Thumb mode or not.
- * Correct this offset.
+ * According to the ARM ARM, the PC is 2 or 4 bytes ahead
+ * depending on Thumb mode. Correct this offset so that
+ * regs->ARM_pc points at the faulting instruction.
*/
regs->ARM_pc -= correction;
diff --git a/arch/arm/vfp/entry.S b/arch/arm/vfp/entry.S
index 4fa9903..2bf6089 100644
--- a/arch/arm/vfp/entry.S
+++ b/arch/arm/vfp/entry.S
@@ -19,6 +19,14 @@
#include <asm/vfpmacros.h>
#include "../kernel/entry-header.S"
+@ VFP entry point.
+@
+@ r0 = instruction opcode (32-bit ARM or two 16-bit Thumb)
+@ r2 = PC value to resume execution after successful emulation
+@ r9 = normal "successful" return address
+@ r10 = this threads thread_info structure
+@ lr = unrecognised instruction return address
+@
ENTRY(do_vfp)
#ifdef CONFIG_PREEMPT
ldr r4, [r10, #TI_PREEMPT] @ get preempt count
diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index 9897dcf..7292921 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -61,13 +61,13 @@
@ VFP hardware support entry point.
@
-@ r0 = faulted instruction
-@ r2 = faulted PC+4
-@ r9 = successful return
+@ r0 = instruction opcode (32-bit ARM or two 16-bit Thumb)
+@ r2 = PC value to resume execution after successful emulation
+@ r9 = normal "successful" return address
@ r10 = vfp_state union
@ r11 = CPU number
-@ lr = failure return
-
+@ lr = unrecognised instruction return address
+@ IRQs enabled.
ENTRY(vfp_support_entry)
DBGSTR3 "instr %08x pc %08x state %p", r0, r2, r10
@@ -138,9 +138,12 @@ check_for_exception:
@ exception before retrying branch
@ out before setting an FPEXC that
@ stops us reading stuff
- VFPFMXR FPEXC, r1 @ restore FPEXC last
- sub r2, r2, #4
- str r2, [sp, #S_PC] @ retry the instruction
+ VFPFMXR FPEXC, r1 @ Restore FPEXC last
+ sub r2, r2, #4 @ Retry current instruction - if Thumb
+ str r2, [sp, #S_PC] @ mode it's two 16-bit instructions,
+ @ else it's one 32-bit instruction, so
+ @ always subtract 4 from the following
+ @ instruction address.
#ifdef CONFIG_PREEMPT
get_thread_info r10
ldr r4, [r10, #TI_PREEMPT] @ get preempt count
^ permalink raw reply related
* [GIT PULL v3] pxa: patches for v2.6.38-rc
From: Russell King - ARM Linux @ 2011-01-14 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=B3sfBXS3vN1+nnRa5m64jiaqmzRFfi6w07dJB@mail.gmail.com>
On Fri, Jan 14, 2011 at 11:08:59AM -0600, Eric Miao wrote:
> Hi Russell,
>
> I rebased the branch on top of devel-stable. The conflict in irq.c is
> fixed. And there is a one-liner patch fixing a building issue in spitz.c
> missing of physmap.h. Please re-pull and let know any other issue.
Pulled cleanly, thanks.
^ permalink raw reply
* [PATCH] OMAP: use fncpy to copy the PM code functions to SRAM
From: Russell King - ARM Linux @ 2011-01-14 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikz_gSQE5QfO6ZXwbp9w+HTNMtb6RLBY+3Z0XF6@mail.gmail.com>
On Fri, Jan 14, 2011 at 05:13:01PM +0100, Jean Pihet wrote:
> Is the name 'omap_sram_push' wrong then?
> What about the following?
> @@ -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));
>
> - return (void *)omap_sram_ceil;
> + return fncpy((void *)omap_sram_ceil, start, size);
It's more correct, but still missing out on the type safety which we've
tried to provide with fncpy. Note also the other issue with Dave Martin
has raised though - this isn't ready for merging yet.
^ permalink raw reply
* [PATCH 1/1 v2] ARM: Thumb-2: Symbol manipulation macros for function body copying
From: Russell King - ARM Linux @ 2011-01-14 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikiR+XN4Jb9GSEdUUiOciLvxqXB+NA3DEWhNCga@mail.gmail.com>
On Fri, Jan 14, 2011 at 11:15:19AM -0600, Dave Martin wrote:
> There's another problem which I hadn't spotted before:
>
> In the Thumb case, we risk violating the alignment constraints of the
> code which gets copied (actually, this is also true of the ARM case,
> but less likely to bite). This matters because the code may contain
> literals and other data words -- quite likely given the requirement
> for self-containedness.
There's a solution to this - require that the thumb function is
preceded by a .align 3 (which according to the GAS documentation I
have means for ARM, it aligns the PC to 1 << 3 not 3 bytes.)
Also require 8-byte alignment from the allocation function, and make
fncpy() bug if the destination isn't 8-byte aligned. Same for the
source function argument (but ignoring bit 0 of course.)
We don't then have to mess with rounding allocation sizes up, nor worry
about aligning the destination according to the source or any other
games like that.
The down-side is wastage of maybe 7 bytes a function, but that's
probably going to happen anyway.
^ permalink raw reply
* [PATCH] hwrng: add support for picoxcell TRNG
From: Matt Mackall @ 2011-01-14 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295021448-25018-1-git-send-email-jamie@jamieiles.com>
On Fri, 2011-01-14 at 16:10 +0000, Jamie Iles wrote:
> This driver adds support for the True Random Number Generator in
> the Picochip PC3X3 and later devices.
>
> Cc: Matt Mackall <mpm@selenic.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> ---
>
> ARCH_PICOXCELL machine support patches have been posted the ARM mailing
> lists for review (with another revision to follow soon).
>
> drivers/char/hw_random/Kconfig | 12 ++
> drivers/char/hw_random/Makefile | 1 +
> drivers/char/hw_random/picoxcell-rng.c | 175 ++++++++++++++++++++++++++++++++
> 3 files changed, 188 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..e750056
> --- /dev/null
> +++ b/drivers/char/hw_random/picoxcell-rng.c
> @@ -0,0 +1,175 @@
> +/*
> + * 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/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 TAI_REG_OFFSET 0x0380
Some whitespace weirdness here. Recommend never using tabs except at the
beginning of a line.
> +static void __iomem *rng_base;
> +static struct clk *rng_clk;
> +
> +/*
> + * Get some random data from the random number generator. The hw_random core
> + * layer provides us with locking. We can't rely on data being word aligned
> + * though so we'll need to do a memcpy.
> + */
> +static int picoxcell_trng_read(struct hwrng *rng, void *buf, size_t max,
> + bool wait)
> +{
> + u32 __iomem *csr = rng_base + CSR_REG_OFFSET;
> + int data_avail = !(__raw_readl(csr) & CSR_OUT_EMPTY_MASK);
> + u32 data;
> +
> + if (!data_avail && !wait)
> + return 0;
> +
> + /* Wait for some data to become available. */
> + while (!data_avail) {
> + data_avail = !(__raw_readl(csr) & CSR_OUT_EMPTY_MASK);
> + cpu_relax();
> + }
This could be simplified a bit:
- deduplicate avail check
- only relax when data's not available
- drop some one use vars
while (!__raw_read(rng_base + ...) {
if (!wait)
return;
cpu_relax();
}
> + data = __raw_readl(rng_base + DATA_REG_OFFSET);
> + memcpy(buf, &data, min(max, sizeof(data)));
The buffer passed in is guaranteed aligned:
static u8 rng_buffer[SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES]
__cacheline_aligned;
...
return rng->read(rng, (void *)buffer, size, wait);
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* [PATCH 1/1 v2] ARM: Thumb-2: Symbol manipulation macros for function body copying
From: Dave Martin @ 2011-01-14 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114174339.GC22505@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 11:43 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 14, 2011 at 11:15:19AM -0600, Dave Martin wrote:
>> There's another problem which I hadn't spotted before:
>>
>> In the Thumb case, we risk violating the alignment constraints of the
>> code which gets copied (actually, this is also true of the ARM case,
>> but less likely to bite). ?This matters because the code may contain
>> literals and other data words -- quite likely given the requirement
>> for self-containedness.
>
> There's a solution to this - require that the thumb function is
> preceded by a .align 3 (which according to the GAS documentation I
> have means for ARM, it aligns the PC to 1 << 3 not 3 bytes.)
>
> Also require 8-byte alignment from the allocation function, and make
> fncpy() bug if the destination isn't 8-byte aligned. ?Same for the
> source function argument (but ignoring bit 0 of course.)
>
> We don't then have to mess with rounding allocation sizes up, nor worry
> about aligning the destination according to the source or any other
> games like that.
>
> The down-side is wastage of maybe 7 bytes a function, but that's
> probably going to happen anyway.
>
OK, that sounds like a practical compromise.
I'll roll this in and repost the patch.
Cheers
---Dave
^ permalink raw reply
* [GIT PULL] AT91: patches for v2.6.38-rc1
From: Nicolas Ferre @ 2011-01-14 18:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
Can you please pull those little changes for AT91? They add two
new boards already discussed on the mailing list and a little
cleanup patch:
The following changes since commit 9e9bc9736756f25d6c47b4eba0ebf25b20a6f153:
Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 (2011-01-06 18:32:12 -0800)
are available in the git repository at:
git://github.com/at91linux/linux-2.6-at91.git for_rmk
Igor Plyatov (1):
AT91: Support for gsia18s board
Jesper Juhl (1):
AT91: board-sam9m10g45ek.c: Remove duplicate inclusion of mach/hardware.h
Sergio Tanzilli (1):
AT91: Acme Systems FOX Board G20 board files
arch/arm/mach-at91/Kconfig | 13 +
arch/arm/mach-at91/Makefile | 2 +
arch/arm/mach-at91/board-foxg20.c | 274 ++++++++++++++
arch/arm/mach-at91/board-gsia18s.c | 584 +++++++++++++++++++++++++++++
arch/arm/mach-at91/board-sam9m10g45ek.c | 1 -
arch/arm/mach-at91/include/mach/gsia18s.h | 33 ++
6 files changed, 906 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-at91/board-foxg20.c
create mode 100644 arch/arm/mach-at91/board-gsia18s.c
create mode 100644 arch/arm/mach-at91/include/mach/gsia18s.h
Thanks, best regards,
--
Nicolas Ferre
^ permalink raw reply
* [GIT PULL] AT91: patches for v2.6.38-rc1
From: Russell King - ARM Linux @ 2011-01-14 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D308F30.6070503@atmel.com>
On Fri, Jan 14, 2011 at 07:00:16PM +0100, Nicolas Ferre wrote:
> Hi Russell,
>
> Can you please pull those little changes for AT91? They add two
> new boards already discussed on the mailing list and a little
> cleanup patch:
Has this already been in linux-next?
We should only be merging new code during a merge window which has
already had visibility in linux-next, with the exception of bug fixes
and regression fixes.
Regression fixes can be merged at any time provided they're obvious.
Any regression fix should be acceptable during the merge window.
Bug fixes any time up until (I'd say) the last week of the -rc series.
^ permalink raw reply
* [GIT PULL] AT91: patches for v2.6.38-rc1
From: Nicolas Ferre @ 2011-01-14 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114180455.GL15996@n2100.arm.linux.org.uk>
Le 14/01/2011 19:04, Russell King - ARM Linux :
> On Fri, Jan 14, 2011 at 07:00:16PM +0100, Nicolas Ferre wrote:
>> Hi Russell,
>>
>> Can you please pull those little changes for AT91? They add two
>> new boards already discussed on the mailing list and a little
>> cleanup patch:
>
> Has this already been in linux-next?
I must admit that... no.
> We should only be merging new code during a merge window which has
> already had visibility in linux-next, with the exception of bug fixes
> and regression fixes.
I understand your point but those are only *board* files that are lying
around for one or two months.
I was really wishing to see them included in mainline during merge
window as they are not core ARM nor AT91 files...
BTW the git tree is based on the tree you specify to Eric: "9e9bc973".
> Regression fixes can be merged at any time provided they're obvious.
> Any regression fix should be acceptable during the merge window.
>
> Bug fixes any time up until (I'd say) the last week of the -rc series.
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] hwrng: add support for picoxcell TRNG
From: Jamie Iles @ 2011-01-14 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295027353.30392.20.camel@calx>
Hi Matt,
Many thanks for the quick feedback!
On Fri, Jan 14, 2011 at 11:49:13AM -0600, Matt Mackall wrote:
> On Fri, 2011-01-14 at 16:10 +0000, Jamie Iles wrote:
> > This driver adds support for the True Random Number Generator in
> > 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..e750056
> > --- /dev/null
> > +++ b/drivers/char/hw_random/picoxcell-rng.c
> > @@ -0,0 +1,175 @@
> > +/*
> > + * 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/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 TAI_REG_OFFSET 0x0380
>
> Some whitespace weirdness here. Recommend never using tabs except at the
> beginning of a line.
I'll fix that up, not sure what happened there.
> > +static void __iomem *rng_base;
> > +static struct clk *rng_clk;
> > +
> > +/*
> > + * Get some random data from the random number generator. The hw_random core
> > + * layer provides us with locking. We can't rely on data being word aligned
> > + * though so we'll need to do a memcpy.
> > + */
> > +static int picoxcell_trng_read(struct hwrng *rng, void *buf, size_t max,
> > + bool wait)
> > +{
> > + u32 __iomem *csr = rng_base + CSR_REG_OFFSET;
> > + int data_avail = !(__raw_readl(csr) & CSR_OUT_EMPTY_MASK);
> > + u32 data;
> > +
> > + if (!data_avail && !wait)
> > + return 0;
> > +
> > + /* Wait for some data to become available. */
> > + while (!data_avail) {
> > + data_avail = !(__raw_readl(csr) & CSR_OUT_EMPTY_MASK);
> > + cpu_relax();
> > + }
>
> This could be simplified a bit:
>
> - deduplicate avail check
> - only relax when data's not available
> - drop some one use vars
>
> while (!__raw_read(rng_base + ...) {
> if (!wait)
> return;
> cpu_relax();
> }
Yes, that's much neater.
> > + data = __raw_readl(rng_base + DATA_REG_OFFSET);
> > + memcpy(buf, &data, min(max, sizeof(data)));
>
> The buffer passed in is guaranteed aligned:
>
> static u8 rng_buffer[SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES]
> __cacheline_aligned;
> ...
> return rng->read(rng, (void *)buffer, size, wait);
Ok, that makes sense. I must have confused myself with the __user
buffer which doesn't have any alignment guarantees.
Thanks again for the review, I'll get a respin out early next week.
Jamie
^ permalink raw reply
* [PATCH] ARM: msm: 7x30: don't force a gpiomux table for the whole arch
From: David Brown @ 2011-01-14 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294686030-9817-1-git-send-email-dima@android.com>
On Mon, Jan 10 2011, Dima Zavin wrote:
> This is completely board specific and therefore must be provided
> on a per-board basis.
>
> Change-Id: I96f922ad9bb9cbce7874c5ae6ac0d7479b7a2124
> Signed-off-by: Dima Zavin <dima@android.com>
I'll pull this into msm-next once rc8-rc1 comes out.
I'll take out the Change-Id line, though.
David
^ 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