* [PATCH 1/2] ARM: OMAP: hwmod: align the SmartReflex fck names
From: Tony Lindgren @ 2012-10-03 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349279277-7634-2-git-send-email-j-pihet@ti.com>
* jean.pihet at newoldbits.com <jean.pihet@newoldbits.com> [121003 08:48]:
> @@ -1036,8 +1036,8 @@ static struct omap_clk am33xx_clks[] = {
> CLK("davinci-mcasp.1", NULL, &mcasp1_fck, CK_AM33XX),
> CLK("NULL", "mmc2_fck", &mmc2_fck, CK_AM33XX),
> CLK(NULL, "mmu_fck", &mmu_fck, CK_AM33XX),
> - CLK(NULL, "smartreflex0_fck", &smartreflex0_fck, CK_AM33XX),
> - CLK(NULL, "smartreflex1_fck", &smartreflex1_fck, CK_AM33XX),
> + CLK(NULL, "smartreflex.0", &smartreflex_mpu_fck, CK_AM33XX),
> + CLK(NULL, "smartreflex.1", &smartreflex_core_fck, CK_AM33XX),
> CLK(NULL, "timer1_fck", &timer1_fck, CK_AM33XX),
> CLK(NULL, "timer2_fck", &timer2_fck, CK_AM33XX),
> CLK(NULL, "timer3_fck", &timer3_fck, CK_AM33XX),
I think this should be something like this instead:
CLK("smartreflex.0", "fck", &smartreflex_mpu_fck, CK_AM33XX),
CLK("smartreflex.1", "fck", &smartreflex_core_fck, CK_AM33XX),
Where the first one is the dev name, the second one is the
alias you want to use in the client driver?
Regards,
Tony
^ permalink raw reply
* [PATCH v6 3/5] watchdog: at91sam9_wdt: add device tree support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-03 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHkwnC_uS1Q_oxr61w8k-7MJWyNfHx=maF_jMZ97tyGxPOn1kg@mail.gmail.com>
On 18:32 Wed 03 Oct , Fabio Porcedda wrote:
> On Tue, Oct 2, 2012 at 9:00 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> > On 17:04 Tue 02 Oct , Fabio Porcedda wrote:
> >> On Mon, Oct 1, 2012 at 3:06 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> > On Mon, Oct 01, 2012 at 02:54:55PM +0200, Fabio Porcedda wrote:
> >> >> On Mon, Oct 1, 2012 at 2:48 PM, Fabio Porcedda <fabio.porcedda@gmail.com> wrote:
> >> >> > On Mon, Oct 1, 2012 at 2:45 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> >> >> On Mon, Oct 01, 2012 at 02:24:39PM +0200, Fabio Porcedda wrote:
> >> >> >>> Tested on an at91sam9260 board (evk-pro3)
> >> >> >>>
> >> >> >>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> >> >> >>> ---
> >> >> >>> .../devicetree/bindings/watchdog/atmel-wdt.txt | 19 +++++++++++++++++++
> >> >> >>> drivers/watchdog/at91sam9_wdt.c | 21 +++++++++++++++++++++
> >> >> >>> 2 files changed, 40 insertions(+)
> >> >> >>> ...
> >> >> >>
> >> >> >> In patch #1 you add a function to do this, and then you don't make use
> >> >> >> of it here ?
> >> >> >>
> >> >> >> Or am i missing something?
> >> >> >
> >> >> > I'm using it on the patch #2 for the orion_wdt driver.
> >> >> > Do you think it's better to join the #1 and the #2 patch?
> >> >> >
> >> >> > Best regards
> >> >> > --
> >> >> > Fabio Porcedda
> >> >>
> >> >> I'm sorry, only now i understand your question.
> >> >> The at91sam9_wdt driver don't use the watchdog core framework si i
> >> >> can't use that function cleanly.
> >> >
> >> >> The patch #1 and #2 are for introducing the same property as the
> >> >> at91sam9_wdt driver.
> >> >
> >> > So maybe split this up into two different patchsets. One patchset to
> >> > add the helper function, and the use of this helper to all watchdog
> >> > divers that can use it. I think the following drivers should be
> >> > modified:
> >> >
> >> > orion_wdt.c
> >> > pnx4008_wdt.c
> >> > s3c2410_wdt.c
> >> >
> >> > In a second patchset, convert the AT91SAM9 driver over to the watchdog
> >> > core framework, and then use the helper function.
> >>
> >> I was thinking to add a more generic helper function like this:
> >>
> >> static inline void watchdog_get_dttimeout(struct device_node *node,
> >> u32 *timeout)
> >> {
> >> if (node)
> >> of_property_read_u32(node, "timeout", &wdd->timeout);
> >> }
> >>
> >> This way i can use this helper function in the at91sam9_wdt driver too.
> >> What do you think?
> > timeout_sec and this can be move at of.h level
> >
> > as this is not watchdog framework secific
>
> I can not find any property with the "_sec" suffix, you think it's
> still fine to use that suffix?
>
> You are speaking about a of_watchdog.h header with a
> of_watchdog_get_timeout function?
no a global helper not watchdog specific for timeout binding
that why I said of.h not of_watchdog.h
Best Regards,
J.
^ permalink raw reply
* [PATCH 1/2] ARM: OMAP: hwmod: align the SmartReflex fck names
From: Jean Pihet @ 2012-10-03 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003170059.GD4840@atomide.com>
Hi Tony,
On Wed, Oct 3, 2012 at 7:00 PM, Tony Lindgren <tony@atomide.com> wrote:
> * jean.pihet at newoldbits.com <jean.pihet@newoldbits.com> [121003 08:48]:
>> @@ -1036,8 +1036,8 @@ static struct omap_clk am33xx_clks[] = {
>> CLK("davinci-mcasp.1", NULL, &mcasp1_fck, CK_AM33XX),
>> CLK("NULL", "mmc2_fck", &mmc2_fck, CK_AM33XX),
>> CLK(NULL, "mmu_fck", &mmu_fck, CK_AM33XX),
>> - CLK(NULL, "smartreflex0_fck", &smartreflex0_fck, CK_AM33XX),
>> - CLK(NULL, "smartreflex1_fck", &smartreflex1_fck, CK_AM33XX),
>> + CLK(NULL, "smartreflex.0", &smartreflex_mpu_fck, CK_AM33XX),
>> + CLK(NULL, "smartreflex.1", &smartreflex_core_fck, CK_AM33XX),
>> CLK(NULL, "timer1_fck", &timer1_fck, CK_AM33XX),
>> CLK(NULL, "timer2_fck", &timer2_fck, CK_AM33XX),
>> CLK(NULL, "timer3_fck", &timer3_fck, CK_AM33XX),
>
> I think this should be something like this instead:
>
> CLK("smartreflex.0", "fck", &smartreflex_mpu_fck, CK_AM33XX),
> CLK("smartreflex.1", "fck", &smartreflex_core_fck, CK_AM33XX),
>
> Where the first one is the dev name, the second one is the
> alias you want to use in the client driver?
Ok, thanks for the suggestion.
It works however I get a ' smartreflex.0: alias fck already exists'
warning at boot, coming from _add_hwmod_clocks_clkdev (called from
omap_device_alloc).
Since an "fck" is implicitly added for every device (in
_add_hwmod_clocks_clkdev) I replaced "fck" in the alias definition by
NULL but the warning is still present.
What do you think? /me dives into the omap_device code for details...
> Regards,
>
> Tony
Thanks,
Jean
^ permalink raw reply
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Jason Gunthorpe @ 2012-10-03 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003104335.GA2254@linaro.org>
On Wed, Oct 03, 2012 at 11:43:35AM +0100, Dave Martin wrote:
> I'm not sure exactly what you mean by linking the DTB into vmlinux.
> I don't think this is supported upstream, at least for ARM. It could
> be done externally by post-processing vmlinux to add extra sections
> and some boot shim code which initialises the registers appropriately
> for kernel entry ... but you're really inventing a bootloader if you
> start to do that.
We use the existing build infrastructure (see cmd_dt_S_dtb) and add a
4 line patch to head.S to put the dtb address into the right
register. I think it would be great to have a CONFIG_ARM_BUILT_IN_DTB
for applications like mine, but it is really no problem to carry the
head.S patch. The normal build process produces a vmlinux that is self
contained, no post processing required.
> Making a simple bootloader DT-aware is not actually that hard: libfdt
> is intentionally pretty straightforward to integrate.
Sure, but we have several major issues with that entire idea:
1) Our bootloader (on PPC and ARM) is in redundant NOR flash and
is limited to 16K. That is just enough to do gzip, elf, cramfs
and tftpv6 - there is no space left for dtb or fdt code.
2) Experience using DT with PPC has shown that the vmlinux is very
sensitive to the DTB. Every DTB/vmlinux combination must be tested
to ensure it works. By far the best way to manage this *for us* is
to guarentee that the vmlinux sees only the DTB it was designed
for by including it in vmlinux.
3) The DTB *changes*. We change it because we've changed things in the
programmable part of our environment and we change it because the
kernel has shifted. Planning for this inevitable change is
necessary.
4) On our ARM platforms updating the boot loader in the field is more
challenging than updating the vmlinux, not impossible, but not
something we want to do every day. Our PPC boot loader has
survived without change since 2007, and has booted kernels from
2.6.12 to 3.6 with and without DT. This is a time tested,
field proven approach.
Fundamentally we treat the DTB like the .config - an integral,
internal, part of vmlinux.
As far as I can see, the *only* argument to put the DT in the boot
loader is to support standard, distribution kernels.
> It's more than 100 lines, but not _that_ much more, and contains
> some implementation features you probably don't need.
But that is not enough, variations of our platforms use bit bang I2C,
SPI and NOR FLASH to store things like the MAC address and other
DT-relevant information. So, swaths of that code would need to go into
the boot loader/zImage as well.
At that point we may as well take our chances with uBoot. :)
> From my side, I think that the fact this takes arch/arm/vmlinux.lds.S
> closer to some other common arches means that this is low risk and should
> be mostly harmless, but I will take another look at the patch first.
This matches my opinion..
> > > You store vmlinux.gz in a cramfs? Is that a typo, or have you already
> > > compressed the kernel twice?
> >
> > The compression can either be intrisic to cramfs or a raw elf that has
> > been gzip'd.
>
> If you can have files with intrinsic compression such that they don't
> get double-compressed, why can you not do this for zImage?
>
> Am I still misunderstanding something?
We have two boot modes, one boots ELF.gz (for development), the other
boots ELF in CRAMFS (for deployment). Both are compressed, one is
compressed using gzip and one is compressed using zlib in CRAMFS. It
is hard to see how to store a zImage in CRAMFS and avoid double
de-compression. We never store an ELF.gz in CRAMFS.
Since the entire point of zImage is to introduce compression it is
hard to see *why* we'd want to store a zImage in a CRAMFS.
Jason
^ permalink raw reply
* [PATCH 3/4] ARM: OMAP2: gpmc: Add support for BCH ECC scheme
From: Ivan Djelic @ 2012-10-03 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349274589-11389-4-git-send-email-avinashphilip@ti.com>
On Wed, Oct 03, 2012 at 03:29:48PM +0100, Philip, Avinash wrote:
> Add support for BCH ECC scheme to gpmc driver and also enabling multi
> sector read/write. This helps in doing single shot NAND page read and
> write.
>
> ECC engine configurations
> BCH 4 bit support
> 1. write => ECC engine configured in wrap mode 6 and with ecc_size0 as 32.
> 2. read => ECC engine configured in wrap mode 1 and with ecc_size0 as
> 13 and ecc_size1 as 1.
>
> BCH 8 bit support
> 1. write => ECC engine configured in wrap mode 6 and with ecc_size0 as 32.
> 2. read => ECC engine configured in wrap mode 1 and with ecc_size0 as
> 26 and ecc_size1 as 2.
>
> Note: For BCH8 ECC bytes set to 14 to make compatible with RBL.
>
Hi Philip,
I have a few comments/questions below,
(...)
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 72428bd..c9bc3cf 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -24,6 +24,7 @@
> #include <linux/io.h>
> #include <linux/module.h>
> #include <linux/interrupt.h>
> +#include <linux/mtd/nand.h>
>
> #include <asm/mach-types.h>
> #include <plat/gpmc.h>
> @@ -83,6 +84,18 @@
> #define ENABLE_PREFETCH (0x1 << 7)
> #define DMA_MPU_MODE 2
>
> +/* GPMC ecc engine settings for read */
> +#define BCH_WRAPMODE_1 1 /* BCH wrap mode 6 */
Comment should say "mode 1".
(...)
> /**
> + * gpmc_calculate_ecc_bch - Generate ecc bytes per block of 512 data bytes for entire page
> + * @cs: chip select number
> + * @dat: The pointer to data on which ECC is computed
> + * @ecc: The ECC output buffer
> + */
> +int gpmc_calculate_ecc_bch(int cs, const u_char *dat, u_char *ecc)
> +{
> + int i, eccbchtsel;
> + u32 nsectors, reg, bch_val1, bch_val2, bch_val3, bch_val4;
> +
> + if (gpmc_ecc_used != cs)
> + return -EINVAL;
> +
> + /* read number of sectors for ecc to be calculated */
> + nsectors = ((gpmc_read_reg(GPMC_ECC_CONFIG) >> 4) & 0x7) + 1;
> + /*
> + * find BCH scheme used
> + * 0 -> BCH4
> + * 1 -> BCH8
> + */
> + eccbchtsel = ((gpmc_read_reg(GPMC_ECC_CONFIG) >> 12) & 0x3);
> +
> + /* update ecc bytes for entire page */
> + for (i = 0; i < nsectors; i++) {
> +
> + reg = GPMC_ECC_BCH_RESULT_0 + 16 * i;
> +
> + /* Read hw-computed remainder */
> + bch_val1 = gpmc_read_reg(reg + 0);
> + bch_val2 = gpmc_read_reg(reg + 4);
> + if (eccbchtsel) {
> + bch_val3 = gpmc_read_reg(reg + 8);
> + bch_val4 = gpmc_read_reg(reg + 12);
> + }
> +
> + if (eccbchtsel) {
> + /* BCH8 ecc scheme */
> + *ecc++ = (bch_val4 & 0xFF);
> + *ecc++ = ((bch_val3 >> 24) & 0xFF);
> + *ecc++ = ((bch_val3 >> 16) & 0xFF);
> + *ecc++ = ((bch_val3 >> 8) & 0xFF);
> + *ecc++ = (bch_val3 & 0xFF);
> + *ecc++ = ((bch_val2 >> 24) & 0xFF);
> + *ecc++ = ((bch_val2 >> 16) & 0xFF);
> + *ecc++ = ((bch_val2 >> 8) & 0xFF);
> + *ecc++ = (bch_val2 & 0xFF);
> + *ecc++ = ((bch_val1 >> 24) & 0xFF);
> + *ecc++ = ((bch_val1 >> 16) & 0xFF);
> + *ecc++ = ((bch_val1 >> 8) & 0xFF);
> + *ecc++ = (bch_val1 & 0xFF);
> + /* 14th byte of ecc not used */
> + *ecc++ = 0;
> + } else {
> + /* BCH4 ecc scheme */
> + *ecc++ = ((bch_val2 >> 12) & 0xFF);
> + *ecc++ = ((bch_val2 >> 4) & 0xFF);
> + *ecc++ = (((bch_val2 & 0xF) << 4) |
> + ((bch_val1 >> 28) & 0xF));
> + *ecc++ = ((bch_val1 >> 20) & 0xFF);
> + *ecc++ = ((bch_val1 >> 12) & 0xFF);
> + *ecc++ = ((bch_val1 >> 4) & 0xFF);
> + *ecc++ = ((bch_val1 & 0xF) << 4);
> + }
> + }
> +
> + gpmc_ecc_used = -EINVAL;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(gpmc_calculate_ecc_bch);
Here you introduce a function very similar to gpmc_calculate_ecc_bch4 and
gpmc_calculate_ecc_bch8, but without the added benefit (IMHO) of the constant
polynomial that allows to get an ecc sequence of 0xFFs for a buffer filled with
0xFFs. Why ?
If using the ELM prevents you from reusing gpmc_calculate_ecc_bch[48], could you explain in which way ?
Best regards,
--
Ivan
^ permalink raw reply
* [PATCH] ARM: footbridge: remove RTC_IRQ definition
From: Arnd Bergmann @ 2012-10-03 19:02 UTC (permalink / raw)
To: linux-arm-kernel
Since commit bd8abc9a32c "ARM: mc146818rtc: remove unnecessary include of
mach/irqs.h", building footbridge_defconfig results in this warning:
In file included from include/linux/mc146818rtc.h:16:0,
from arch/arm/mach-footbridge/isa-rtc.c:21:
arch/arm/include/asm/mc146818rtc.h:10:0: warning: "RTC_IRQ" redefined [enabled by default]
arch/arm/mach-footbridge/include/mach/irqs.h:93:0: note: this is the location of the previous definition
The above commit was intentionally made to catch errors like this,
where code relies on the RTC_IRQ definition. The only driver using
it is the legacy PC-style drivers/char/rtc.c driver.
However, the ARM architecture has been using the RTC_LIB framework
since at least 2006, and that doesn't use it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: rtc-linux at googlegroups.com
Cc: Russell King <linux@arm.linux.org.uk>
---
I've queued this in late/fixes for the current merge window. Will
send later unless someone objects.
diff --git a/arch/arm/mach-footbridge/include/mach/irqs.h b/arch/arm/mach-footbridge/include/mach/irqs.h
index 400551e..61c714c 100644
--- a/arch/arm/mach-footbridge/include/mach/irqs.h
+++ b/arch/arm/mach-footbridge/include/mach/irqs.h
@@ -89,8 +89,6 @@
#define IRQ_NETWINDER_VGA _ISA_IRQ(11)
#define IRQ_NETWINDER_SOUND _ISA_IRQ(12)
-#undef RTC_IRQ
-#define RTC_IRQ IRQ_ISA_RTC_ALARM
#define I8042_KBD_IRQ IRQ_ISA_KEYBOARD
#define I8042_AUX_IRQ (machine_is_netwinder() ? IRQ_NETWINDER_PS2MOUSE : IRQ_ISA_PS2MOUSE)
#define IRQ_FLOPPYDISK IRQ_ISA_FLOPPY
^ permalink raw reply related
* [PATCH] ARM: mv78xx0: correct addr_map_cfg __initdata annotation
From: Arnd Bergmann @ 2012-10-03 19:06 UTC (permalink / raw)
To: linux-arm-kernel
The annotation on the addr_map_cfg variable is in the wrong place.
Without this patch, building mv78xx0_defconfig results in:
/home/arnd/linux-arm/arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: initialization from incompatible pointer type [enabled by default]
/home/arnd/linux-arm/arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: (near initialization for 'addr_map_cfg.win_cfg_base') [enabled by default]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
---
Queued in the late/fixes branch
diff --git a/arch/arm/mach-mv78xx0/addr-map.c b/arch/arm/mach-mv78xx0/addr-map.c
index a9bc841..03f7486 100644
--- a/arch/arm/mach-mv78xx0/addr-map.c
+++ b/arch/arm/mach-mv78xx0/addr-map.c
@@ -53,7 +53,7 @@ static void __init __iomem *win_cfg_base(const struct orion_addr_map_cfg *cfg, i
/*
* Description of the windows needed by the platform code
*/
-static struct __initdata orion_addr_map_cfg addr_map_cfg = {
+static struct orion_addr_map_cfg addr_map_cfg __initdata = {
.num_wins = 14,
.remappable_wins = 8,
.win_cfg_base = win_cfg_base,
^ permalink raw reply related
* [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib
From: Mark Brown @ 2012-10-03 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348780923-27428-1-git-send-email-stigge@antcom.de>
On Thu, Sep 27, 2012 at 11:22:02PM +0200, Roland Stigge wrote:
> The recurring task of providing simultaneous access to GPIO lines (especially
> for bit banging protocols) needs an appropriate API.
> This patch adds a kernel internal "Block GPIO" API that enables simultaneous
> access to several GPIOs in the same gpio_chip (bit mapped). Further, it adds a
> sysfs interface (/sys/class/gpio/gpiochipXX/block).
It would be very useful if this had the option of falling back to
addressing the GPIOs one by one. There's some usages that aren't
performance dependent and it'd make drivers able to run even if they're
suboptimal.
^ permalink raw reply
* [PATCH] ARM: footbridge: nw_gpio_lock is raw_spin_lock
From: Arnd Bergmann @ 2012-10-03 19:12 UTC (permalink / raw)
To: linux-arm-kernel
bd31b85960a "locking, ARM: Annotate low level hw locks as raw"
made nw_gpio_lock a raw spinlock, but did not change all the
users in device drivers. This fixes the remaining ones.
sound/oss/waveartist.c: In function 'vnc_mute_spkr':
sound/oss/waveartist.c:1485:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
drivers/char/ds1620.c: In function 'netwinder_lock':
drivers/char/ds1620.c:77:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
drivers/char/nwflash.c: In function 'kick_open':
drivers/char/nwflash.c:620:2: warning: passing argument 1 of 'spinlock_check' from incompatible pointer type [enabled by default]
include/linux/spinlock.h:272:102: note: expected 'struct spinlock_t *' but argument is of type 'struct raw_spinlock_t *'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
queued in the late/fixes branch, will submit later in the merge window
unless I hear objections.
diff --git a/drivers/char/ds1620.c b/drivers/char/ds1620.c
index aab9605..24ffd8c 100644
--- a/drivers/char/ds1620.c
+++ b/drivers/char/ds1620.c
@@ -74,21 +74,21 @@ static inline void netwinder_ds1620_reset(void)
static inline void netwinder_lock(unsigned long *flags)
{
- spin_lock_irqsave(&nw_gpio_lock, *flags);
+ raw_spin_lock_irqsave(&nw_gpio_lock, *flags);
}
static inline void netwinder_unlock(unsigned long *flags)
{
- spin_unlock_irqrestore(&nw_gpio_lock, *flags);
+ raw_spin_unlock_irqrestore(&nw_gpio_lock, *flags);
}
static inline void netwinder_set_fan(int i)
{
unsigned long flags;
- spin_lock_irqsave(&nw_gpio_lock, flags);
+ raw_spin_lock_irqsave(&nw_gpio_lock, flags);
nw_gpio_modify_op(GPIO_FAN, i ? GPIO_FAN : 0);
- spin_unlock_irqrestore(&nw_gpio_lock, flags);
+ raw_spin_unlock_irqrestore(&nw_gpio_lock, flags);
}
static inline int netwinder_get_fan(void)
diff --git a/drivers/char/nwflash.c b/drivers/char/nwflash.c
index d45c334..04e2a94 100644
--- a/drivers/char/nwflash.c
+++ b/drivers/char/nwflash.c
@@ -617,9 +617,9 @@ static void kick_open(void)
* we want to write a bit pattern XXX1 to Xilinx to enable
* the write gate, which will be open for about the next 2ms.
*/
- spin_lock_irqsave(&nw_gpio_lock, flags);
+ raw_spin_lock_irqsave(&nw_gpio_lock, flags);
nw_cpld_modify(CPLD_FLASH_WR_ENABLE, CPLD_FLASH_WR_ENABLE);
- spin_unlock_irqrestore(&nw_gpio_lock, flags);
+ raw_spin_unlock_irqrestore(&nw_gpio_lock, flags);
/*
* let the ISA bus to catch on...
diff --git a/sound/oss/waveartist.c b/sound/oss/waveartist.c
index 24c430f..672af8b 100644
--- a/sound/oss/waveartist.c
+++ b/sound/oss/waveartist.c
@@ -1482,9 +1482,9 @@ vnc_mute_spkr(wavnc_info *devc)
{
unsigned long flags;
- spin_lock_irqsave(&nw_gpio_lock, flags);
+ raw_spin_lock_irqsave(&nw_gpio_lock, flags);
nw_cpld_modify(CPLD_UNMUTE, devc->spkr_mute_state ? 0 : CPLD_UNMUTE);
- spin_unlock_irqrestore(&nw_gpio_lock, flags);
+ raw_spin_unlock_irqrestore(&nw_gpio_lock, flags);
}
static void
^ permalink raw reply related
* [PATCH 4/4] mtd: nand: omap2: Add data correction support
From: Ivan Djelic @ 2012-10-03 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349274589-11389-5-git-send-email-avinashphilip@ti.com>
On Wed, Oct 03, 2012 at 03:29:49PM +0100, Philip, Avinash wrote:
> ELM module can be used for error correction of BCH 4 & 8 bit. Also
> support read & write page in one shot by adding custom read_page &
> write_page methods. This helps in optimizing code.
>
> New structure member "is_elm_used" is added to know the status of
> whether the ELM module is used for error correction or not.
>
> Note:
> ECC layout of BCH8 uses 14 bytes for 512 byte of data to make compatible
> with RBL ECC layout, even though the requirement was only 13 byte. This
> results a common ecc layout across RBL, U-boot & Linux.
>
See a few comments below,
(...)
> +static int omap_elm_correct_data(struct mtd_info *mtd, u_char *dat,
> + u_char *read_ecc, u_char *calc_ecc)
> +{
> + struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
> + mtd);
> + int eccsteps = info->nand.ecc.steps;
> + int i , j, stat = 0;
> + int eccsize, eccflag, size;
> + struct elm_errorvec err_vec[ERROR_VECTOR_MAX];
> + u_char *ecc_vec = calc_ecc;
> + enum bch_ecc type;
> + bool is_error_reported = false;
> +
> + /* initialize elm error vector to zero */
> + memset(err_vec, 0, sizeof(err_vec));
> + if (info->nand.ecc.strength == BCH8_MAX_ERROR) {
> + size = BCH8_SIZE;
> + eccsize = BCH8_ECC_OOB_BYTES;
> + type = BCH8_ECC;
> + } else {
> + size = BCH4_SIZE;
> + eccsize = BCH4_SIZE;
> + type = BCH4_ECC;
> + }
> +
> + for (i = 0; i < eccsteps ; i++) {
> + eccflag = 0; /* initialize eccflag */
> +
> + for (j = 0; (j < eccsize); j++) {
> + if (read_ecc[j] != 0xFF) {
> + eccflag = 1; /* data area is flashed */
Just a reminder: this way of checking if a page has been programmed is not robust to bitflips,
so you may get into trouble with UBIFS on a fairly recent device.
(...)
> @@ -1039,14 +1180,45 @@ static void omap3_enable_hwecc_bch(struct mtd_info *mtd, int mode)
>
> nerrors = info->nand.ecc.strength;
> dev_width = (chip->options & NAND_BUSWIDTH_16) ? 1 : 0;
> +#ifdef CONFIG_MTD_NAND_OMAP_BCH
> + if (info->is_elm_used) {
> + /*
> + * Program GPMC to perform correction on (steps * 512) byte
> + * sector at a time.
> + */
> + gpmc_enable_hwecc_bch(info->gpmc_cs, mode, dev_width,
> + info->nand.ecc.steps, nerrors);
> + return;
> + }
> +#endif
> /*
> - * Program GPMC to perform correction on one 512-byte sector at a time.
> - * Using 4 sectors at a time (i.e. ecc.size = 2048) is also possible and
> - * gives a slight (5%) performance gain (but requires additional code).
> + * Program GPMC to perform correction on one 512-byte sector at
> + * a time.
Why removing the comment about 4-sector perf gain ? :-)
(...)
> @@ -1146,35 +1402,62 @@ static int omap3_init_bch(struct mtd_info *mtd, int ecc_opt)
> goto fail;
> }
>
> - /* initialize GPMC BCH engine */
> - ret = gpmc_init_hwecc_bch(info->gpmc_cs, 1, max_errors);
> - if (ret)
> - goto fail;
> -
> - /* software bch library is only used to detect and locate errors */
> - info->bch = init_bch(13, max_errors, 0x201b /* hw polynomial */);
> - if (!info->bch)
> - goto fail;
> + info->nand.ecc.size = 512;
> + info->nand.ecc.hwctl = omap3_enable_hwecc_bch;
> + info->nand.ecc.mode = NAND_ECC_HW;
> + info->nand.ecc.strength = hw_errors;
>
> - info->nand.ecc.size = 512;
> - info->nand.ecc.hwctl = omap3_enable_hwecc_bch;
> - info->nand.ecc.correct = omap3_correct_data_bch;
> - info->nand.ecc.mode = NAND_ECC_HW;
> + if (info->is_elm_used && (mtd->writesize <= 4096)) {
> + enum bch_ecc bch_type;
>
> - /*
> - * The number of corrected errors in an ecc block that will trigger
> - * block scrubbing defaults to the ecc strength (4 or 8).
> - * Set mtd->bitflip_threshold here to define a custom threshold.
> - */
> + if (hw_errors == BCH8_MAX_ERROR) {
> + bch_type = BCH8_ECC;
> + info->nand.ecc.bytes = BCH8_SIZE;
> + } else {
> + bch_type = BCH4_ECC;
> + info->nand.ecc.bytes = BCH4_SIZE;
> + }
>
> - if (max_errors == 8) {
> - info->nand.ecc.strength = 8;
> - info->nand.ecc.bytes = 13;
> - info->nand.ecc.calculate = omap3_calculate_ecc_bch8;
> + info->nand.ecc.correct = omap_elm_correct_data;
> + info->nand.ecc.calculate = omap3_calculate_ecc_bch;
> + info->nand.ecc.read_page = omap_read_page_bch;
> + info->nand.ecc.write_page = omap_write_page_bch;
> + info->elm_dev = elm_request(bch_type);
> + if (!info->elm_dev) {
> + pr_err("Request to elm module failed\n");
> + goto fail;
> + }
> } else {
> - info->nand.ecc.strength = 4;
> - info->nand.ecc.bytes = 7;
> - info->nand.ecc.calculate = omap3_calculate_ecc_bch4;
> +
> + /* initialize GPMC BCH engine */
> + ret = gpmc_init_hwecc_bch(info->gpmc_cs, 1, max_errors);
> + if (ret)
> + goto fail;
> +
> + /*
> + * software bch library is only used to detect and
> + * locateerrors
s/locateerrors/locate errors/
BTW, did you check that your patch does not break the software BCH case (i.e. no ELM) ?
BR,
--
Ivan
^ permalink raw reply
* [PATCH] ARM: mv78xx0: correct addr_map_cfg __initdata annotation
From: Andrew Lunn @ 2012-10-03 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210031906.35123.arnd@arndb.de>
On Wed, Oct 03, 2012 at 07:06:34PM +0000, Arnd Bergmann wrote:
> The annotation on the addr_map_cfg variable is in the wrong place.
>
> Without this patch, building mv78xx0_defconfig results in:
>
> /home/arnd/linux-arm/arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: initialization from incompatible pointer type [enabled by default]
> /home/arnd/linux-arm/arch/arm/mach-mv78xx0/addr-map.c:59:2: warning: (near initialization for 'addr_map_cfg.win_cfg_base') [enabled by default]
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> ---
> Queued in the late/fixes branch
>
> diff --git a/arch/arm/mach-mv78xx0/addr-map.c b/arch/arm/mach-mv78xx0/addr-map.c
> index a9bc841..03f7486 100644
> --- a/arch/arm/mach-mv78xx0/addr-map.c
> +++ b/arch/arm/mach-mv78xx0/addr-map.c
> @@ -53,7 +53,7 @@ static void __init __iomem *win_cfg_base(const struct orion_addr_map_cfg *cfg, i
> /*
> * Description of the windows needed by the platform code
> */
> -static struct __initdata orion_addr_map_cfg addr_map_cfg = {
> +static struct orion_addr_map_cfg addr_map_cfg __initdata = {
> .num_wins = 14,
> .remappable_wins = 8,
> .win_cfg_base = win_cfg_base,
Humm, been there, done that once. Must of forgotten to post it. :-(
Acked-by: Andrew Lunn <andrew@lunn.ch>
^ permalink raw reply
* [PATCH v2 8/9] ARM: OMAP: iommu: add device tree support
From: Omar Ramirez Luna @ 2012-10-03 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002212523.GA11180@beef>
Hi Matt,
On 2 October 2012 16:25, Matt Porter <mporter@ti.com> wrote:
...
> I can see why you went this path with the iommu driver as it already had
> some integration code present here. I have some concerns going forward
> about how this should be long-term. Take any platform booting only with
> DT populated, we'd like to avoid having to use this approach where
> platform private APIs are called via pdata. In fact, it's going to makes
> thing ugly to carry any sort of pdata for a driver that's otherwise
> driven exclusively from DT.
>
> For AM335x, I can implement this approach, but it means adding some
> pruss specific integration code just to have it create the pdata for
> reset_name and assert/deassert.
Yes I agree, it looks a bit ugly for devices that have more than one
reset line name too, but right now there is no other way to keep the
reset names and also provide flexibility to the driver to control them
in a given order.
> From reading all the threads on hardresets and OMAP, it seems we may not
> be able to come up with a generic OMAP handler for these resets and
> that's really reflected in the fact that this API exists. So given that,
> it reasons that OMAP isn't the only one needing a reset API for drivers.
> I'm thinking that (as trivial as it may seem), this support may need to
> move to a reset subsystem such that drivers have a clean way to access
> reset resources in an SoC.
Well, there was a point where the OMAP hwmod code contained the reset
code and at least for me it was working fine, with iommu and ipu
processor, just with a minor misleading warning print... however then
this code got stripped out and since there appeared to be people
needing to handle their reset lines in unknown ways it was advised
that everybody should implement their own reset functions, but in my
case I could reuse most of the disabled code at the expense of almost
duplicating _enable (omap_hwmod) function while waiting all the reset
line users started asking for changes.
> I'm curious if you or others have thought about where this needs to go
> next.
I haven't planned for a reset subsystem or a more generic
implementation, although I have been looking for a way to avoid using
the pdata function pointers.
> When I first thought about a reset subsystem it seemed to trivial
> to bother with but looking at the reasoning behind the power_seq
> subsystem, it seems to have similar justification to get this machine
> specific logic out of the platform code and under standardized control
> of the driver.
IMHO, the reset code even if made a subsystem or a library, would
still need to interface with machine specific code and definitions
(say omap_hwmod), so I don't see much difference in making the
omap_device reset handlers as exported symbols for the time being,
with acceptance of the owners of omap_device code.
And then if power_seq makes it to mainline perhaps extending it to
handle deassert, assert and softreset events, but then again this
would have the same hooks to omap_hwmod which is the one with the prcm
information.
Regards,
Omar
^ permalink raw reply
* [PATCH 1/1] Fix segfault in DTC
From: Stephen Warren @ 2012-10-03 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121002000851.GA29302@truffula.fritz.box>
On 10/01/2012 06:08 PM, David Gibson wrote:
> On Mon, Oct 01, 2012 at 10:41:09AM -0600, Stephen Warren wrote:
>> On 10/01/2012 12:46 AM, David Gibson wrote:
>>> On Sun, Sep 30, 2012 at 11:34:50PM -0600, Stephen Warren wrote:
>>>> On 09/29/2012 05:53 PM, David Gibson wrote:
>>>>> On Fri, Sep 28, 2012 at 01:05:33PM -0600, Stephen Warren wrote:
>>>>>> On 09/28/2012 12:53 PM, Jon Loeliger wrote:
>>>>>>>>>
>>>>>>>>> Yeah, seems like the kernel DTC is quite old.
>>>>>>>>
>>>>>>>> FYI, I'm working on a patch to the kernel to bring in the latest dtc.
>>>>>>>
>>>>>>> Awesome. Thank you.
>>>>>>>
>>>>>>>> I've run a regression test vs. the old dtc in the kernel ...
>>>>>>>
>>>>>>> Which is the icky step. Again, thank you.
>>>>>>>
>>>>>>>> ... and found that
>>>>>>>> some of the PowerPC .dts files don't compile with the new dtc (but did
>>>>>>>> with the old), all due to non-existent labels/paths being referenced.
>>>>>>>> I'll try and track down whether this is a regression in dtc, or simply
>>>>>>>> buggy .dts files that weren't noticed before.
>>>>>>>
>>>>>>> I think you should just smack the PowerPC guys. :-)
>>>>>>
>>>>>> For the record in this thread, it was a regression I introduced into dtc
>>>>>> - the patch I just sent was for this.
>>>>>
>>>>> I would be nice to add a testcase for this regression into dtc.
>>>>
>>>> The issue here was caused by uninitialized memory, so it would, I think,
>>>> be basically impossible to create a test-case that would be guaranteed
>>>> to fail because of this; it'd depend on the internal details of the
>>>> malloc library and how/when it re-used previously free()d memory blocks.
>>>
>>> It doesn't have to be guaranteed to fail to be useful. Plus, we
>>> already have the infrastructure to run the tests under valgrind, which
>>> would catch it.
>>
>> I certainly disagree here; the absolute worst kind of test is one which
>> gives different results each time it's run, or statically gives
>> different results to different people. People will either ignore the
>> test because it's flaky, or it'll end up blaming the wrong person due to
>> some entirely unrelated and correct change just happening to tickle the
>> test.
>
> I'd agree 100% if the test could give false failures. But in this
> case it can only give false passes.
That is true. I still dislike flaky tests irrespective of
false-{negative,positive} though.
> If the test fails there is a bug
> *somewhere*, even if it's not actually in whatever changed last. The
> test framework actually has a "PASS (inconclusive)" result for exactly
> this sort of case.
>
>> If we were to force any such new test to always run under valgrind, then
>> hopefully the test would always fail (assuming the test harness triggers
>> failure if valgrind finds problems).
>
> Aside: it's supposed to; if it doesn't, that's a bug. You can try it
> easily enough with "make checkm".
Ah, I didn't know about that make target (or even "make check"; I'd
always run run_tests.sh manually).
Incidentally, before commit 317a5d9 "dtc: zero out new label objects"
the following two tests fail under make checkm:
dtc -I dts -O dtb -o multilabel.test.dtb multilabel.dts: FAIL
Returned error code 126
dtc -I dts -O dtb -o multilabel_merge.test.dtb multilabel_merge.dts:
FAIL Returned error code 126
However, they pass at/after that commit.
Equally, those failures were introduced with commit 45013d8 "dtc: Add
ability to delete nodes and properties", which is exactly what I'd
expect given the fix was a fix for that commit.
So, it seems like we already have tests that catch this problem. Do we
need to do anything given that?
I am slightly surprised that the problem didn't cause all tests to fail
make checkm though (I'd expect any usage of a label to trigger the
problem); I'll have to think about why some more...
^ permalink raw reply
* [PATCH v3] Enable USB peripheral on dm365 EVM
From: const at MakeLinux.com @ 2012-10-03 22:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Constantine Shulyupin <const@MakeLinux.com>
From: Miguel Aguilar <miguel.aguilar@ridgerun.com>
Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
---
Tested with usb gadget g_zero.
This patch is based on code from Arago, Angstom, and RidgeRun projects.
Original patch is three years ago:
http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg14741.html
---
arch/arm/mach-davinci/board-dm365-evm.c | 8 ++++++++
arch/arm/mach-davinci/usb.c | 2 ++
drivers/usb/musb/davinci.h | 1 +
drivers/usb/musb/musb_core.c | 20 ++++++++++++--------
4 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c
index 3a4743b..dfcb67f 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,8 @@
#include <mach/mmc.h>
#include <mach/nand.h>
#include <mach/keyscan.h>
+#include <mach/usb.h>
+#include <mach/hardware.h>
#include <media/tvp514x.h>
@@ -92,6 +94,9 @@ static inline int have_tvp7002(void)
#define CPLD_CCD_DIR3 CPLD_OFFSET(0x3f,0)
#define CPLD_CCD_IO3 CPLD_OFFSET(0x3f,1)
+#define USBPHY_CTL_PADDR 0x01c40034
+#define USBPHY_CLKFREQ_24MHZ BIT(13)
+
static void __iomem *cpld;
@@ -613,6 +618,9 @@ static __init void dm365_evm_init(void)
dm365_init_spi0(BIT(0), dm365_evm_spi_info,
ARRAY_SIZE(dm365_evm_spi_info));
+ writel(readl(IO_ADDRESS(USBPHY_CTL_PADDR)) | USBPHY_CLKFREQ_24MHZ,
+ IO_ADDRESS(USBPHY_CTL_PADDR));
+ davinci_setup_usb(500, 8);
}
MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM")
diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
index 23d2b6d..664c689 100644
--- a/arch/arm/mach-davinci/usb.c
+++ b/arch/arm/mach-davinci/usb.c
@@ -49,6 +49,8 @@ static struct musb_hdrc_platform_data usb_data = {
.mode = MUSB_PERIPHERAL,
#elif defined(CONFIG_USB_MUSB_HOST)
.mode = MUSB_HOST,
+#else
+ .mode = MUSB_OTG,
#endif
.clock = "usb",
.config = &musb_config,
diff --git a/drivers/usb/musb/davinci.h b/drivers/usb/musb/davinci.h
index 371baa0..e737d97 100644
--- a/drivers/usb/musb/davinci.h
+++ b/drivers/usb/musb/davinci.h
@@ -16,6 +16,7 @@
/* Integrated highspeed/otg PHY */
#define USBPHY_CTL_PADDR 0x01c40034
+#define USBPHY_CLKFREQ_24MHZ BIT(13)
#define USBPHY_DATAPOL BIT(11) /* (dm355) switch D+/D- */
#define USBPHY_PHYCLKGD BIT(8)
#define USBPHY_SESNDEN BIT(7) /* v(sess_end) comparator */
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 26f1bef..277fe65 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2051,9 +2051,17 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
dev_info(dev, "USB %s mode controller at %p using %s, IRQ %d\n",
({char *s;
switch (musb->board_mode) {
- case MUSB_HOST: s = "Host"; break;
- case MUSB_PERIPHERAL: s = "Peripheral"; break;
- default: s = "OTG"; break;
+ case MUSB_HOST:
+ s = "Host";
+ break;
+ case MUSB_PERIPHERAL:
+ s = "Peripheral";
+ break;
+ case MUSB_OTG:
+ s = "OTG";
+ break;
+ default:
+ s = "Undefined";
}; s; }),
ctrl,
(is_dma_capable() && musb->dma_controller)
@@ -2402,11 +2410,7 @@ static int __init musb_init(void)
if (usb_disabled())
return 0;
- pr_info("%s: version " MUSB_VERSION ", "
- "?dma?"
- ", "
- "otg (peripheral+host)",
- musb_driver_name);
+ pr_info("%s: version %s\n", MUSB_VERSION, musb_driver_name);
return platform_driver_register(&musb_driver);
}
module_init(musb_init);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: kirkwood: DT board setup for Network Space v2 and parents
From: Simon Guinot @ 2012-10-03 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003154310.GI11837@lunn.ch>
On Wed, Oct 03, 2012 at 05:43:10PM +0200, Andrew Lunn wrote:
> On Wed, Oct 03, 2012 at 05:14:30PM +0200, Simon Guinot wrote:
> > This patch adds DT board setup for LaCie Network Space v2 and parents,
> > based the Marvell Kirkwood 6281 SoC. This includes Network Space (Max)
> > v2 and Internet Space v2.
>
> Hi Simon
>
> At a first look, this looks good. Also nice to see you use the new
> gpio-fan binding.
Hi Andrew,
It is nice to have this binding. It works fine.
>
> > --- a/arch/arm/mach-kirkwood/board-dt.c
> > +++ b/arch/arm/mach-kirkwood/board-dt.c
> > @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void)
> > if (of_machine_is_compatible("keymile,km_kirkwood"))
> > km_kirkwood_init();
> >
> > + if (of_machine_is_compatible("lacie,inetspace_v2") ||
> > + of_machine_is_compatible("lacie,netspace_v2") ||
> > + of_machine_is_compatible("lacie,netspace_max_v2"))
> > + ns2_init();
> > +
> > of_platform_populate(NULL, kirkwood_dt_match_table,
> > kirkwood_auxdata_lookup, NULL);
>
> I'm not a DT policy expert. Could this be one compatibility string for
> all the boards? Maybe ask on the DT mainline list?
Maybe I could use "lacie,ns2_common" as a compatibility string. But this
does not match any existing device. I don't know if it is correct.
>
> > +#define NETSPACE_V2_GPIO_BLUE_LED_SLOW 29
> > +#define NETSPACE_V2_GPIO_BLUE_LED_CMD 30
> > +
> > +static struct ns2_led ns2_led_pins[] = {
> > + {
> > + .name = "ns_v2:blue:sata",
> > + .cmd = NETSPACE_V2_GPIO_BLUE_LED_CMD,
> > + .slow = NETSPACE_V2_GPIO_BLUE_LED_SLOW,
> > + },
> > +};
> > +
> > +static struct ns2_led_platform_data ns2_leds_data = {
> > + .num_leds = ARRAY_SIZE(ns2_led_pins),
> > + .leds = ns2_led_pins,
> > +};
> > +
> > +static struct platform_device ns2_leds = {
> > + .name = "leds-ns2",
> > + .id = -1,
> > + .dev = {
> > + .platform_data = &ns2_leds_data,
> > + },
> > +};
>
> Have you thought about adding a DT binding for this driver?
Yes. I am on it.
>
> It would be nice if you could respin the patches for -rc1, when it
> comes out. There are changes to Makefile.boot at least required.
OK. I will.
Note that this patch is based against the branch kirkwood/boards from
the git repository git://git.infradead.org/users/jcooper/linux.git. Is
that correct ?
Thanks.
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121004/b1121644/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS
From: Kevin Hilman @ 2012-10-03 22:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Kevin Hilman <khilman@ti.com>
Currently, a dummy omap_device is created for the MPU sub-system so
that a device node exists for MPU DVFS. Specifically, for the
association of MPU OPPs to a device node, and so that a voltage
regulator can be mapped to a device node.
For drivers to get a handle to this device node, an OMAP-specific API
has been used. However, the kernel already has device nodes for the
CPU(s) in the system, so we can use those instead of an OMAP-specific
dummy device and then drivers (like OMAP CPUfreq) can use generic
APIs.
To use the existing CPU device nodes, modify the OPP creation and
regulator registration to use the CPU0 device node for registraion.
NOTE: this patch always uses CPU0 as the device node. On all
OMAPs today, MPU DVFS scales all CPUs together, so this will
not be a problem, but this assumption will need to be changed
if independently scalable CPUs are introduced.
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
Applies on current Linus master.
Targetted for v3.7-rc1 so CPUfreq driver can be cleaned of plat includes
(follow on series)
arch/arm/mach-omap2/opp.c | 23 +++++++++++++++++------
arch/arm/mach-omap2/pm.c | 11 ++++++++++-
arch/arm/mach-omap2/twl-common.c | 2 +-
3 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/opp.c b/arch/arm/mach-omap2/opp.c
index 45ad7f7..58e16ae 100644
--- a/arch/arm/mach-omap2/opp.c
+++ b/arch/arm/mach-omap2/opp.c
@@ -18,6 +18,7 @@
*/
#include <linux/module.h>
#include <linux/opp.h>
+#include <linux/cpu.h>
#include <plat/omap_device.h>
@@ -62,13 +63,23 @@ int __init omap_init_opp_table(struct omap_opp_def *opp_def,
__func__, i);
return -EINVAL;
}
- oh = omap_hwmod_lookup(opp_def->hwmod_name);
- if (!oh || !oh->od) {
- pr_debug("%s: no hwmod or odev for %s, [%d] cannot add OPPs.\n",
- __func__, opp_def->hwmod_name, i);
- continue;
+
+ if (!strncmp(opp_def->hwmod_name, "mpu", 3)) {
+ /*
+ * All current OMAPs share voltage rail and
+ * clock source, so CPU0 is used to represent
+ * the MPU-SS.
+ */
+ dev = get_cpu_device(0);
+ } else {
+ oh = omap_hwmod_lookup(opp_def->hwmod_name);
+ if (!oh || !oh->od) {
+ pr_debug("%s: no hwmod or odev for %s, [%d] cannot add OPPs.\n",
+ __func__, opp_def->hwmod_name, i);
+ continue;
+ }
+ dev = &oh->od->pdev->dev;
}
- dev = &oh->od->pdev->dev;
r = opp_add(dev, opp_def->freq, opp_def->u_volt);
if (r) {
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 939bd6f..173c2be 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -16,6 +16,7 @@
#include <linux/opp.h>
#include <linux/export.h>
#include <linux/suspend.h>
+#include <linux/cpu.h>
#include <asm/system_misc.h>
@@ -168,7 +169,15 @@ static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
goto exit;
}
- dev = omap_device_get_by_hwmod_name(oh_name);
+ if (!strncmp(oh_name, "mpu", 3))
+ /*
+ * All current OMAPs share voltage rail and clock
+ * source, so CPU0 is used to represent the MPU-SS.
+ */
+ dev = get_cpu_device(0);
+ else
+ dev = omap_device_get_by_hwmod_name(oh_name);
+
if (IS_ERR(dev)) {
pr_err("%s: Unable to get dev pointer for hwmod %s\n",
__func__, oh_name);
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 45f7741..3f5eacc 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -158,7 +158,7 @@ static struct regulator_init_data omap3_vpll2_idata = {
};
static struct regulator_consumer_supply omap3_vdd1_supply[] = {
- REGULATOR_SUPPLY("vcc", "mpu.0"),
+ REGULATOR_SUPPLY("vcc", "cpu0"),
};
static struct regulator_consumer_supply omap3_vdd2_supply[] = {
--
1.7.9.2
^ permalink raw reply related
* [PATCH 09/17] serial/8250: Limit the omap workarounds to omap1
From: Tony Lindgren @ 2012-10-03 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120911201919.58d44dcb@bob.linux.org.uk>
* Alan Cox <alan@linux.intel.com> [120911 12:02]:
> > > Even better would be if for other cases is_omap_port and friends
> > > returned 0...
> >
> > Yes it seems that those macros could be moved from plat-omap/serial.h
> > to live in drivers/tty/serial/8250/8250.h? Or do you have some better
> > place in mind?
>
> I've not looked at it enough to decide if it's doable or not. I'm happy
> either way - both patches are progress the right way!
FYI, I'll send something along these lines as a separate patch as
"[PATCH] tty/serial/8250: Make omap hardware workarounds local to 8250.h"
Regards,
Tony
^ permalink raw reply
* [PATCH 0/4] cpufreq: OMAP: fixes for v3.7-rc2
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Kevin Hilman <khilman@ti.com>
Here's a series with a couple bug fixes and a couple fixes that
make this driver support newer OMAP-based SoCs.
The 'get_cpu_device' patch is needed due to a change in the OMAP
OMAP PM core code which enforces use of get_cpu_device() instead of
a deprecated OMAP-specific API.
The usage of plat/*.h headers breaks single zImage, so platforms are
cleaning up and/or removing plat/*.h so the driver needs to be fixed
accordingly.
This series is based on the merge of Rafael's pm-for-3.7-rc1 tag into
Linus' master branch: commit 16642a2e7be23bbda013fc32d8f6c68982eab603.
Tested CPUfreq on OMAP platforms: 3430/n900, 3530/Overo,
3730/OveroSTORM, 3730/Beagle-XM, 4430/Panda.
Rafael, if you're OK with this series, I'll get a pull request
ASAP so it can be included for v3.7-rc2.
Kevin Hilman (3):
cpufreq: OMAP: ensure valid clock rate before scaling
cpufreq: OMAP: remove unused <plat/omap-pm.h>
cpufreq: OMAP: use get_cpu_device() instead of omap_device API
Paul Walmsley (1):
cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/
includes
drivers/cpufreq/omap-cpufreq.c | 36 ++++++++++++------------------------
1 file changed, 12 insertions(+), 24 deletions(-)
--
1.7.9.2
^ permalink raw reply
* [PATCH 1/4] cpufreq: OMAP: ensure valid clock rate before scaling
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Kevin Hilman <khilman@ti.com>
Ensure the clock rate that will be used is a valid one before
attempting to scale the voltage. Currently the driver assumes it has
a valid frequency from the OPP table, but boards using different
system oscillators might not have exact matches with the OPP table,
and result in a failing call to clk_set_rate().
This is particularily bad because the voltage may be scaled even
though the frequency is not. This will obviously lead to some
unpredictable behavior, especially if the frequency is high and
the voltage is dropped.
Thanks to Joni Lapilainen for reporting crashes seen on 3430/n900.
Reported-by: Joni Lapilainen <joni.lapilainen@gmail.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 65f8e9a..0fe395a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -108,6 +108,14 @@ static int omap_target(struct cpufreq_policy *policy,
}
freq = freqs.new * 1000;
+ ret = clk_round_rate(mpu_clk, freq);
+ if (IS_ERR_VALUE(ret)) {
+ dev_warn(mpu_dev,
+ "CPUfreq: Cannot find matching frequency for %lu\n",
+ freq);
+ return ret;
+ }
+ freq = ret;
if (mpu_reg) {
opp = opp_find_freq_ceil(mpu_dev, &freq);
--
1.7.9.2
^ permalink raw reply related
* [PATCH 2/4] cpufreq: OMAP: remove unused <plat/omap-pm.h>
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Kevin Hilman <khilman@ti.com>
The <plat/*.h> headers are going away, and this one is not used. remove it.
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 0fe395a..7d4d455 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -31,7 +31,6 @@
#include <asm/cpu.h>
#include <plat/clock.h>
-#include <plat/omap-pm.h>
#include <plat/common.h>
#include <plat/omap_device.h>
--
1.7.9.2
^ permalink raw reply related
* [PATCH 3/4] cpufreq: OMAP: fix clock usage to be SoC independent, remove plat/ includes
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Paul Walmsley <paul@pwsan.com>
OMAP core code now has SoC-independent clock alias for the scalable
CPU clock. Using it means driver is SoC independent and will work for
AM3xxx SoCs as well as OMAP1/3/4.
While here, remove some unnecessary plat/ includes that are
interfering with multi-subarch ARM kernels.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
[tony at atomide.com: updated already changed clock aliases]
Signed-off-by: Tony Lindgren <tony@atomide.com>
[khilman at ti.com: minor shortlog/changelog updates]
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 7d4d455..5d1f5e4 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -30,19 +30,14 @@
#include <asm/smp_plat.h>
#include <asm/cpu.h>
-#include <plat/clock.h>
-#include <plat/common.h>
#include <plat/omap_device.h>
-#include <mach/hardware.h>
-
/* OPP tolerance in percentage */
#define OPP_TOLERANCE 4
static struct cpufreq_frequency_table *freq_table;
static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
-static char *mpu_clk_name;
static struct device *mpu_dev;
static struct regulator *mpu_reg;
@@ -179,7 +174,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
- mpu_clk = clk_get(NULL, mpu_clk_name);
+ mpu_clk = clk_get(NULL, "cpufreq_ck");
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
@@ -260,18 +255,6 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
- if (cpu_is_omap24xx())
- mpu_clk_name = "virt_prcm_set";
- else if (cpu_is_omap34xx())
- mpu_clk_name = "dpll1_ck";
- else if (cpu_is_omap44xx())
- mpu_clk_name = "dpll_mpu_ck";
-
- if (!mpu_clk_name) {
- pr_err("%s: unsupported Silicon?\n", __func__);
- return -EINVAL;
- }
-
mpu_dev = omap_device_get_by_hwmod_name("mpu");
if (IS_ERR(mpu_dev)) {
pr_warning("%s: unable to get the mpu device\n", __func__);
--
1.7.9.2
^ permalink raw reply related
* [PATCH 4/4] cpufreq: OMAP: use get_cpu_device() instead of omap_device API
From: Kevin Hilman @ 2012-10-03 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349305229-28480-1-git-send-email-khilman@deeprootsystems.com>
From: Kevin Hilman <khilman@ti.com>
OMAP PM core code has moved to using the existing, generic CPU devices
for attaching OPPs, so the CPUfreq driver can now use the generic
get_cpu_device() API instead of the OMAP-specific omap_device API.
This allows us to remove the last <plat/*> include from this driver.
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
drivers/cpufreq/omap-cpufreq.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 5d1f5e4..1f3417a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -30,8 +30,6 @@
#include <asm/smp_plat.h>
#include <asm/cpu.h>
-#include <plat/omap_device.h>
-
/* OPP tolerance in percentage */
#define OPP_TOLERANCE 4
@@ -255,10 +253,10 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
- mpu_dev = omap_device_get_by_hwmod_name("mpu");
- if (IS_ERR(mpu_dev)) {
+ mpu_dev = get_cpu_device(0);
+ if (!mpu_dev) {
pr_warning("%s: unable to get the mpu device\n", __func__);
- return PTR_ERR(mpu_dev);
+ return -EINVAL;
}
mpu_reg = regulator_get(mpu_dev, "vcc");
--
1.7.9.2
^ permalink raw reply related
* [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib
From: Linus Walleij @ 2012-10-03 23:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50682402.8020402@antcom.de>
On Sun, Sep 30, 2012 at 12:50 PM, Roland Stigge <stigge@antcom.de> wrote:
> Besides what I discussed with JC and Linus, I find the unsigned int
> (i.e. u32 or u64, depending on the arch) quite appealing. It is a nice
> compromise between my general bit mapped data model (variable size *u8
> array) and the bool *values list. Even maps easily onto a single sysfs
> entry for values, by abstracting a gpio list to an actual data word.
>
> What do others think? JC? Linus? I'm considering this (unsigned int
> data) a valid option.
I think we mostly use an unsigned long for such stuff as IRQ flags
and ioctl() parameters in the kernel.
In this case it has the upside that it will be 32bit on 32bit systems
and 64bit on 64bit systems if I'm not mistaken.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib
From: Linus Walleij @ 2012-10-03 23:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50686955.8040503@antcom.de>
On Sun, Sep 30, 2012 at 5:46 PM, Roland Stigge <stigge@antcom.de> wrote:
> On 30/09/12 17:19, Stijn Devriendt wrote:
>>
>> Rules are rules, but why make the interface overly complex when
>> the multi-value file is saner, cleaner and simpler?
>
> Simply because they won't (and probably shouldn't) accept it mainline.
We, including you and Stijn *are* the mainline ... ;-)
The only reason I really dislike it is that the GPIO sysfs interface is
scary as it is, so I don't want to add to it if we can instead push to
reform it into something more sane.
Linus Walleij
^ permalink raw reply
* [PATCH v3] Enable USB peripheral on dm365 EVM
From: Greg KH @ 2012-10-03 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349301859-31306-1-git-send-email-const@MakeLinux.com>
On Thu, Oct 04, 2012 at 12:04:19AM +0200, const at MakeLinux.com wrote:
> From: Constantine Shulyupin <const@MakeLinux.com>
>
> From: Miguel Aguilar <miguel.aguilar@ridgerun.com>
> Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
> ---
> Tested with usb gadget g_zero.
> This patch is based on code from Arago, Angstom, and RidgeRun projects.
> Original patch is three years ago:
> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg14741.html
You can't have two "From:" lines.
And put the information above, in the changelog entry.
Also, it looks like you are modifying printk lines for no reason, why do
that in this patch? That shouldn't be needed, right?
greg k-h
^ 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