* [PATCH v3 1/2] ahci_platform: switch to module device table matching
From: mkl0301 at gmail.com @ 2011-01-06 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294336393-920-1-git-send-email-mkl0301@gmail.com>
From: Mac Lin <mkl0301@gmail.com>
Switch the driver to use module device table matching mechanism to add SoC-specific parts to the generic driver.
Signed-off-by: Mac Lin <mkl0301@gmail.com>
---
drivers/ata/ahci_platform.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 6fef1fa..25d98c8 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -19,6 +19,7 @@
#include <linux/interrupt.h>
#include <linux/device.h>
#include <linux/platform_device.h>
+#include <linux/mod_devicetable.h>
#include <linux/libata.h>
#include <linux/ahci_platform.h>
#include "ahci.h"
@@ -29,6 +30,7 @@ static struct scsi_host_template ahci_platform_sht = {
static int __init ahci_probe(struct platform_device *pdev)
{
+ const struct platform_device_id *platid = platform_get_device_id(pdev);
struct device *dev = &pdev->dev;
struct ahci_platform_data *pdata = dev->platform_data;
struct ata_port_info pi = {
@@ -46,6 +48,9 @@ static int __init ahci_probe(struct platform_device *pdev)
int i;
int rc;
+ if (!pdata && platid && platid->driver_data)
+ pdata = (void *)platid->driver_data;
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(dev, "no mmio space\n");
@@ -171,12 +176,19 @@ static int __devexit ahci_remove(struct platform_device *pdev)
return 0;
}
+static const struct platform_device_id ahci_pltfm_ids[] = {
+ { "ahci", },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, ahci_pltfm_ids);
+
static struct platform_driver ahci_driver = {
.remove = __devexit_p(ahci_remove),
.driver = {
.name = "ahci",
.owner = THIS_MODULE,
},
+ .id_table = ahci_pltfm_ids,
};
static int __init ahci_init(void)
@@ -194,4 +206,3 @@ module_exit(ahci_exit);
MODULE_DESCRIPTION("AHCI SATA platform driver");
MODULE_AUTHOR("Anton Vorontsov <avorontsov@ru.mvista.com>");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:ahci");
--
1.7.3
^ permalink raw reply related
* [PATCH v3 2/2] ahci_platform: add support for CNS3xxx SoC devices
From: mkl0301 at gmail.com @ 2011-01-06 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294336393-920-1-git-send-email-mkl0301@gmail.com>
From: Mac Lin <mkl0301@gmail.com>
CNS3xxx override the softreset function of ahci_platform ahci_softreset by
cns3xxx_ahci_softreset, which would retry ahci_do_softreset again with pmp=0 if
pmp=15 failed, for the controller has problem receiving D2H Reg FIS of the
different PMP setting of the previous sent H2D Reg FIS.
Following describe the isssue with original ahci_platform driver on
linux-2.6.37-rc3, arm/cns3xxx.
If CONFIG_SATA_PMP is enabled, while not using multiplier and connect the disks
directly to the board, the disk cannot be found due to software reset always
failed.
ahci ahci.0: forcing PORTS_IMPL to 0x3
ahci ahci.0: AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl platform mode
ahci ahci.0: flags: ncq sntf pm led clo only pmp pio slum part ccc
scsi0 : ahci_platform
scsi1 : ahci_platform
ata1: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 65
ata2: SATA max UDMA/133 mmio [mem 0x83000000-0x83ffffff] port 0x180 irq 65
ata2: SATA link down (SStatus 0 SControl 300)
ata1: link is slow to respond, please be patient (ready=0)
ata1: softreset failed (device not ready)
ata1: link is slow to respond, please be patient (ready=0)
ata1: softreset failed (device not ready)
ata1: link is slow to respond, please be patient (ready=0)
ata1: softreset failed (device not ready)
ata1: limiting SATA link speed to 1.5 Gbps
ata1: SATA link down (SStatus 1 SControl 310)
While using multiplier with CONFIG_SATA_PMP enabled, or using disks directly
without CONFIG_SATA_PMP have no issue. It seems the device is sending D2H Reg
FIS, but controller is not reflecting it on any known means.
Signed-off-by: Mac Lin <mkl0301@gmail.com>
---
arch/arm/mach-cns3xxx/devices.c | 2 +-
drivers/ata/Kconfig | 11 +++++++++++
drivers/ata/ahci_platform.c | 39 +++++++++++++++++++++++++++++++++++++++
3 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-cns3xxx/devices.c b/arch/arm/mach-cns3xxx/devices.c
index 50b4d31..b496f02 100644
--- a/arch/arm/mach-cns3xxx/devices.c
+++ b/arch/arm/mach-cns3xxx/devices.c
@@ -40,7 +40,7 @@ static struct resource cns3xxx_ahci_resource[] = {
static u64 cns3xxx_ahci_dmamask = DMA_BIT_MASK(32);
static struct platform_device cns3xxx_ahci_pdev = {
- .name = "ahci",
+ .name = "ahci-cns3xxx",
.id = 0,
.resource = cns3xxx_ahci_resource,
.num_resources = ARRAY_SIZE(cns3xxx_ahci_resource),
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 36e2319..5d8b1a3 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -75,6 +75,17 @@ config SATA_AHCI_PLATFORM
If unsure, say N.
+config SATA_AHCI_CNS3XXX
+ bool "AHCI Support on the Cavium Networks CNS3xxx SOC"
+ depends on ARCH_CNS3XXX
+ depends on SATA_AHCI_PLATFORM
+ help
+ This option enables AHCI platform driver to support CNS3xxx
+ System-on-Chip devices. This is only needed when using CNS3xxx AHCI
+ controller.
+
+ If unsure, say N.
+
config SATA_FSL
tristate "Freescale 3.0Gbps SATA support"
depends on FSL_SOC
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 25d98c8..7d6957f 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -176,8 +176,47 @@ static int __devexit ahci_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_SATA_AHCI_CNS3XXX
+/*
+ * TODO: move cns3xxx_ahci_init to here after cns3xxx_pwr*() calls are
+ * thread-safe
+ */
+
+static int cns3xxx_ahci_softreset(struct ata_link *link, unsigned int *class,
+ unsigned long deadline)
+{
+ int pmp = sata_srst_pmp(link);
+ int ret;
+
+ ret = ahci_do_softreset(link, class, pmp, deadline, ahci_check_ready);
+ if (pmp && ret)
+ return ahci_do_softreset(link, class, 0, deadline,
+ ahci_check_ready);
+ return ret;
+}
+
+static struct ata_port_operations cns3xxx_ahci_ops = {
+ .inherits = &ahci_ops,
+ .softreset = cns3xxx_ahci_softreset,
+};
+
+static const struct ata_port_info cns3xxx_ata_port_info = {
+ .flags = AHCI_FLAG_COMMON,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &cns3xxx_ahci_ops,
+};
+
+struct ahci_platform_data cns3xxx_ahci_platform_data = {
+ .ata_port_info = &cns3xxx_ata_port_info,
+};
+#endif
+
static const struct platform_device_id ahci_pltfm_ids[] = {
{ "ahci", },
+#ifdef CONFIG_SATA_AHCI_CNS3XXX
+ { "ahci-cns3xxx", (kernel_ulong_t)&cns3xxx_ahci_platform_data},
+#endif
{ },
};
MODULE_DEVICE_TABLE(platform, ahci_pltfm_ids);
--
1.7.3
^ permalink raw reply related
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Linus Torvalds @ 2011-01-06 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294336054.2905.1.camel@heimdal.trondhjem.org>
On Thu, Jan 6, 2011 at 9:47 AM, Trond Myklebust
<Trond.Myklebust@netapp.com> wrote:
>
> Why is this line needed? We're not writing through the virtual mapping.
I haven't looked at the sequence of accesses, but you need to be
_very_ aware that "write-through" is absolutely NOT sufficient for
cache coherency.
In cache coherency, you have three options:
- true coherency (eg physically indexed/tagged caches)
- exclusion (eg virtual caches, but with an exclusion guarantee that
guarantees that aliases cannot happen: either by using physical
tagging or by not allowing cases that could cause virtual aliases)
- write-through AND non-cached reads (ie "no caching at all").
You seem to be forgetting the "no cached reads" part. It's not
sufficient to flush after a write - you need to make sure that you
also don't have a cached copy of the alias for the read.
So "We're not writing through the virtual mapping" is NOT a sufficient
excuse. If you're reading through the virtual mapping, you need to
make sure that the virtual mapping is flushed _after_ any writes
through any other mapping and _before_ any reads through the virtual
one.
This is why you really really really generally don't want to have
aliasing. Purely virtual caches are pure crap. Really.
Linus
^ permalink raw reply
* [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
From: Paul Walmsley @ 2011-01-06 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294225024-21857-2-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh
On Wed, 5 Jan 2011, Santosh Shilimkar wrote:
> omap2plus_defocnfig build breaks when customised with only ARCH_OMAP4
> selected. This is because common files make references to the functions
> which are defined only for omap2xxx and omap3xxx.
...
>
> This patch adds stubs for these functions so that build continues to work.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/prm2xxx_3xxx.h | 63 +++++++++++++++++++++++++++++++++++-
> 1 files changed, 62 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h b/arch/arm/mach-omap2/prm2xxx_3xxx.h
> index 53d44f6..843f329 100644
> --- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
> +++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
> @@ -228,7 +228,67 @@
>
>
> #ifndef __ASSEMBLER__
> -
> +/*
> + * Stub omap2xxx/omap3xxx functions so that common files
> + * continue to build when custom builds are used
> + */
> +#if defined(CONFIG_ARCH_OMAP4) && !(defined(CONFIG_ARCH_OMAP2) || \
> + defined(CONFIG_ARCH_OMAP3))
> +static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
> +{
> + WARN_ONCE(1, "prm: omap2xxx/omap3xxx specific function and "
> + "not suppose to be used on omap4\n");
> + return 0;
> +}
I think it would be best to use WARN() on these, rather than WARN_ONCE().
That's because these could be called from different parts of the code
base, and the stack backtrace will help someone figure out all the code
that needs to be fixed.
Once you do that, this patch is
Acked-by: Paul Walmsley <paul@pwsan.com>
- Paul
^ permalink raw reply
* [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Paul Walmsley @ 2011-01-06 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294225024-21857-1-git-send-email-santosh.shilimkar@ti.com>
On Wed, 5 Jan 2011, Santosh Shilimkar wrote:
> struct clockdomain member clktrctrl_mask is available for only for OMAP2
> and OMAP3 architectures. Technially it is also used only for these archs
> but this breaks the build with custom OMAP4 configuration.
...
> Fix the build break by dropping the #ifdef as suggested by Paul Walmsley
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
- Paul
^ permalink raw reply
* [PATCH 1/1] arm: omap: gpio: define .disable callback for gpio irq chip
From: Kevin Hilman @ 2011-01-06 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106062404.GA14141@besouro.research.nokia.com>
Eduardo Valentin <eduardo.valentin@nokia.com> writes:
> On Wed, Jan 05, 2011 at 03:22:51PM -0800, ext Kevin Hilman wrote:
>> Eduardo Valentin <eduardo.valentin@nokia.com> writes:
>>
>> > Hello Russell,
>> >
>> > On Wed, Jan 05, 2011 at 06:19:18PM +0000, Russell King wrote:
>> >> On Wed, Jan 05, 2011 at 07:58:03PM +0200, Eduardo Valentin wrote:
>> >> > Currently, if one calls disable_irq(gpio_irq), the irq
>> >> > won't get disabled.
>> >> >
>> >> > This is happening because the omap gpio code defines only
>> >> > a .mask callback. And the default_disable function is just
>> >> > a stub. The result is that, when someone calls disable_irq
>> >> > for an irq in a gpio line, it will be kept enabled.
>> >> >
>> >> > This patch solves this issue by setting the .disable
>> >> > callback to point to the same .mask callback.
>> >>
>> >> Amd this is a problem because?
>> >
>> > errr.. because the interrupt is enabled when it was supposed to be disabled?
>> >
>>
>> As Russell pointed out, it's not actually "supposed" to be.
>>
>> With lazy disable, what disable_irq() does is prevent the *handler* from
>> ever being called. If another interrupt arrives, it will be caught by
>> the genirq core, marked as IRQ_PENDING and then masked. This "don't
>> disable unless we really have to" is the desired behavior of the lazy
>> disable feature.
>
> Right. I'm convinced that the handler won't be called because of the lazy
> disable mechanism.
>
>>
>> >>
>> >> The way this works is that although it isn't disabled at that point,
>> >> if it never triggers, then everything remains happy. However, if it
>> >> does trigger, the genirq code will then mask the interrupt and won't
>> >> call the handler.
>> >
>> > Right.. I didn't see from this point. I will check how that gets unmasked.
>> > But even so, if I understood correctly what you described, it would still
>> > open a time window which the system would see at least 1 interrupt during
>> > the time it was not suppose to. And that can wakeup a system which is in
>> > deep sleep mode, either via dynamic idle or static suspend.
>> >
>> > It is unlikely, I know. But it can still happen. And can be avoided.
>>
>> If the GPIO is configured as a wakeup source, then wouldn't you want
>> activity on that GPIO to wake up the system?
>
> Yes I would want it.. of course, if the interrupt is enabled though..
>
> I'm still trying to find a valid situation where someone disables an irq
> but still wants its activity to be a wakeup source. I couldn't find so far..
>
>
>>
>> If you don't want wakeups on that GPIO, then the driver should probably
>> be using disable_irq_wake().
>
> Yes. Let's take this situation. Let's assume a driver, at its suspend callback,
> explicitly reports to the system that its irq can be disabled and also should
> not be seen as a wakeup source, by calling disable_irq(gpio_irq) and
> disable_irq_wake(gpio_irq).
>
> What should be the expected system behavior when the user says echo mem > /sys/power/state?
>
> From the point we are done with devices suspend, that gpio will still
> be marked as an irq, at the bank level. But its corresponding pad will
> have its wakeup bit disabled. Would that work? I think yes, in most cases.
>
> Now let's take the WFI instruction as a divisor for 2 situations:
>
> A - common / working case: an interrupt on that gpio still happens after the WFI instruction.
> Since the system is in sleep mode and the pad for that gpio is not wakeup
> capable, then nothing would happen and the system won't wakeup. Then, I think
> everyone is happy here.
>
> B - corner case: an interrupt on that gpio happens before the WFI instruction.
> Since the system is active, the gpio bank can still report this interrupt
> and will do it. The suspend won't happen due to a irq which has been
> explicitly marked as disabled and wakeup incapable.
> Then, would that be the expected behavior? Assuming that the driver
> has explicitly said to the system, you should not bother about this at all.
Well, expected behaviour would be that GPIO bank should not be reporting
the this interrupt at all since it has been disabled.
However, since you're asking, I assume that you're not seeing this
expected behavior.
Ignoring wakeups for a second, if this corner case happens on a
non-wakeup capable GPIO using lazy disable, I would not expect suspend
to be prevented. The genirq core would see the IRQ, mark it as
IRQ_PENDING, mask it and return. and suspend should continue.
hmm... however, if the IRQ happens after interrupts are disabled, the
genirq core won't handle it, and our PM core will see a pending
interrupt and abort idle/suspend.
Are you seeing this corner case for a wakeup-enable GPIO or a non
wakeup-enabled GPIO?
/me looks at code
I'm assuming now it's for a wakeup-enabled GPIO.
Another more likely possibility is that the IRQ arrives between the time
the driver does its disable_irq_wake() and when the GPIO driver actually
suspends. We currently defer disalbing the bank-level IRQ wakeup
capabilities until the suspend method of the GPIO driver is run (which
is very late in the suspend cycle, since it is a sysdev.) Thinking
about this some more, I'm not sure exactly why we do this. The current
code seems to only manage GPIO wakeups for suspend/resume but not for
idle, so it defers the actual register writes until the suspend hook.
Since we presumably also want wakeup-enabled GPIOs to wake up from idle,
we probably shouldn't be deferring the wakeup enable/disable.
Here's an expirement. If you have a use case that is
preventing a suspend in this corner case, let's try to immediately
enable/disable wakeups instead of waiting for the suspend/resume hooks.
Below is a test patch only briefly tested on Zoom3 which has it's
network interface on a GPIO IRQ. It does not have wakeups enabled, and
under ping flood from a host (ping -f), it suspended just fine. I added
an enable_irq_wake() the driver and it was still able to suspend during
ping flood.
If you suspect the above might be happening in your corner case, can you
give this a try to see if it changes?
It's also worth noting that we are currently not managing IO pad wakeups
in the GPIO core. We are only mananging GPIO module level wakeups,
which only are in effect if CORE is active. Now that we have a mux
framework that can probably handle this, we need a mapping of GPIO lines
to pads so we can also manage IO pad level wakeups from the GPIO core
code. However, if your corner case is arriving before WFI, than I
suspect CORE is active, and module level wakeups is what you're running into.
Kevin
commit 3af8a1051a44462c62c5a5d47a8256626e32fbba
Author: Kevin Hilman <khilman@ti.com>
Date: Thu Jan 6 09:45:24 2011 -0800
GPIO: enable/disable wakeups immediately
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index ccf2660..1418423 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -977,34 +977,39 @@ static inline void _set_gpio_irqenable(struct gpio_bank *bank, int gpio, int ena
static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
{
unsigned long uninitialized_var(flags);
+ void __iomem *wake_status;
+ void __iomem *wake_clear;
+ void __iomem *wake_set;
+
+ printk("KJH: %s: bank IRQ %d, GPIO %d enable=%d\n", __func__,
+ bank->irq, gpio, enable);
switch (bank->method) {
#ifdef CONFIG_ARCH_OMAP16XX
case METHOD_MPUIO:
case METHOD_GPIO_1610:
- spin_lock_irqsave(&bank->lock, flags);
- if (enable)
- bank->suspend_wakeup |= (1 << gpio);
- else
- bank->suspend_wakeup &= ~(1 << gpio);
- spin_unlock_irqrestore(&bank->lock, flags);
+ wake_status = bank->base + OMAP1610_GPIO_WAKEUPENABLE;
+ wake_clear = bank->base + OMAP1610_GPIO_CLEAR_WAKEUPENA;
+ wake_set = bank->base + OMAP1610_GPIO_SET_WAKEUPENA;
return 0;
#endif
#ifdef CONFIG_ARCH_OMAP2PLUS
case METHOD_GPIO_24XX:
- case METHOD_GPIO_44XX:
+ wake_status = bank->base + OMAP24XX_GPIO_WAKE_EN;
+ wake_clear = bank->base + OMAP24XX_GPIO_CLEARWKUENA;
+ wake_set = bank->base + OMAP24XX_GPIO_SETWKUENA;
+
if (bank->non_wakeup_gpios & (1 << gpio)) {
printk(KERN_ERR "Unable to modify wakeup on "
"non-wakeup GPIO%d\n",
(bank - gpio_bank) * 32 + gpio);
return -EINVAL;
}
- spin_lock_irqsave(&bank->lock, flags);
- if (enable)
- bank->suspend_wakeup |= (1 << gpio);
- else
- bank->suspend_wakeup &= ~(1 << gpio);
- spin_unlock_irqrestore(&bank->lock, flags);
+ break;
+ case METHOD_GPIO_44XX:
+ wake_status = bank->base + OMAP4_GPIO_IRQWAKEN0;
+ wake_clear = bank->base + OMAP4_GPIO_IRQWAKEN0;
+ wake_set = bank->base + OMAP4_GPIO_IRQWAKEN0;
return 0;
#endif
default:
@@ -1012,6 +1017,16 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
bank->method);
return -EINVAL;
}
+
+ spin_lock_irqsave(&bank->lock, flags);
+ if (enable)
+ __raw_writel((1 << gpio), wake_set);
+ else
+ __raw_writel((1 << gpio), wake_clear);
+
+ spin_unlock_irqrestore(&bank->lock, flags);
+
+ return 0;
}
static void _reset_gpio(struct gpio_bank *bank, int gpio)
@@ -1755,105 +1770,9 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
}
#if defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP2PLUS)
-static int omap_gpio_suspend(struct sys_device *dev, pm_message_t mesg)
-{
- int i;
-
- if (!cpu_class_is_omap2() && !cpu_is_omap16xx())
- return 0;
-
- for (i = 0; i < gpio_bank_count; i++) {
- struct gpio_bank *bank = &gpio_bank[i];
- void __iomem *wake_status;
- void __iomem *wake_clear;
- void __iomem *wake_set;
- unsigned long flags;
-
- switch (bank->method) {
-#ifdef CONFIG_ARCH_OMAP16XX
- case METHOD_GPIO_1610:
- wake_status = bank->base + OMAP1610_GPIO_WAKEUPENABLE;
- wake_clear = bank->base + OMAP1610_GPIO_CLEAR_WAKEUPENA;
- wake_set = bank->base + OMAP1610_GPIO_SET_WAKEUPENA;
- break;
-#endif
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
- case METHOD_GPIO_24XX:
- wake_status = bank->base + OMAP24XX_GPIO_WAKE_EN;
- wake_clear = bank->base + OMAP24XX_GPIO_CLEARWKUENA;
- wake_set = bank->base + OMAP24XX_GPIO_SETWKUENA;
- break;
-#endif
-#ifdef CONFIG_ARCH_OMAP4
- case METHOD_GPIO_44XX:
- wake_status = bank->base + OMAP4_GPIO_IRQWAKEN0;
- wake_clear = bank->base + OMAP4_GPIO_IRQWAKEN0;
- wake_set = bank->base + OMAP4_GPIO_IRQWAKEN0;
- break;
-#endif
- default:
- continue;
- }
-
- spin_lock_irqsave(&bank->lock, flags);
- bank->saved_wakeup = __raw_readl(wake_status);
- __raw_writel(0xffffffff, wake_clear);
- __raw_writel(bank->suspend_wakeup, wake_set);
- spin_unlock_irqrestore(&bank->lock, flags);
- }
-
- return 0;
-}
-
-static int omap_gpio_resume(struct sys_device *dev)
-{
- int i;
-
- if (!cpu_class_is_omap2() && !cpu_is_omap16xx())
- return 0;
-
- for (i = 0; i < gpio_bank_count; i++) {
- struct gpio_bank *bank = &gpio_bank[i];
- void __iomem *wake_clear;
- void __iomem *wake_set;
- unsigned long flags;
-
- switch (bank->method) {
-#ifdef CONFIG_ARCH_OMAP16XX
- case METHOD_GPIO_1610:
- wake_clear = bank->base + OMAP1610_GPIO_CLEAR_WAKEUPENA;
- wake_set = bank->base + OMAP1610_GPIO_SET_WAKEUPENA;
- break;
-#endif
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
- case METHOD_GPIO_24XX:
- wake_clear = bank->base + OMAP24XX_GPIO_CLEARWKUENA;
- wake_set = bank->base + OMAP24XX_GPIO_SETWKUENA;
- break;
-#endif
-#ifdef CONFIG_ARCH_OMAP4
- case METHOD_GPIO_44XX:
- wake_clear = bank->base + OMAP4_GPIO_IRQWAKEN0;
- wake_set = bank->base + OMAP4_GPIO_IRQWAKEN0;
- break;
-#endif
- default:
- continue;
- }
-
- spin_lock_irqsave(&bank->lock, flags);
- __raw_writel(0xffffffff, wake_clear);
- __raw_writel(bank->saved_wakeup, wake_set);
- spin_unlock_irqrestore(&bank->lock, flags);
- }
-
- return 0;
-}
static struct sysdev_class omap_gpio_sysclass = {
.name = "gpio",
- .suspend = omap_gpio_suspend,
- .resume = omap_gpio_resume,
};
static struct sys_device omap_gpio_device = {
^ permalink raw reply related
* [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Paul Walmsley @ 2011-01-06 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fwt7z1p3.fsf@ti.com>
On Wed, 5 Jan 2011, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> > struct clockdomain member clktrctrl_mask is available for only for OMAP2
> > and OMAP3 architectures. Technially it is also used only for these archs
> > but this breaks the build with custom OMAP4 configuration.
>
> I'll queue patches 3-5 for the 2.6.38-rc fixes cycle.
>
> With Paul's ack, I can queue the others too, or Paul can decide to take
> them via his tree. Paul can decide.
I've acked one and requested minor changes on the other, after which it
can be acked by me. You're welcome to take them at that point. Just a
request, maybe you can post a branch with just these patches in them; that
way Rajendra and/or I can rebase his new clockdomain changes on it until
-rc1 comes out.
- Paul
^ permalink raw reply
* Current OMAP build failures
From: Russell King - ARM Linux @ 2011-01-06 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106174950.GU7771@atomide.com>
On Thu, Jan 06, 2011 at 09:49:51AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 09:09]:
> > On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> > > Hi Russell,
> > >
> > > Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> > >
> > > > I've observed the following issues while building 2.6.37 + my devel
> > > > branch. I don't believe any of them to be due to anything in my tree,
> > > > so would be in 2.6.37 as well.
> > >
> > > What defconfig are you using for these builds?
> >
> > I couldn't say offhand because they're built from configs created a while
> > back. I tend to just re-run the build with appropriate O= arguments to
> > test things.
> >
> > I can send the defconfigs if it'd help.
>
> I have the following patch queued up as commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
> which should fix the compile error you're seeing. This seems to be related
> to some option in the .config that's not happening with any of the
> defconfigs.
That'll be because I have:
CONFIG_I2C_OMAP=y
in my config, whereas most OMAP1 defconfigs don't have it enabled with
the exception of omap_h2_1610_defconfig.
^ permalink raw reply
* [PATCH v3 2/2] ahci_platform: add support for CNS3xxx SoC devices
From: Lin Mac @ 2011-01-06 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294336393-920-3-git-send-email-mkl0301@gmail.com>
Hi Jeff,
2011/1/7 <mkl0301@gmail.com>:
> From: Mac Lin <mkl0301@gmail.com>
>
> CNS3xxx override the softreset function of ahci_platform ahci_softreset by
> cns3xxx_ahci_softreset, which would retry ahci_do_softreset again with pmp=0 if
> pmp=15 failed, for the controller has problem receiving D2H Reg FIS of the
> different PMP setting of the previous sent H2D Reg FIS.
>
> Following describe the isssue with original ahci_platform driver on
> linux-2.6.37-rc3, arm/cns3xxx.
>
> If CONFIG_SATA_PMP is enabled, while not using multiplier and connect the disks
> directly to the board, the disk cannot be found due to software reset always
> failed.
>
> ? ?ahci ahci.0: forcing PORTS_IMPL to 0x3
> ? ?ahci ahci.0: AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl platform mode
> ? ?ahci ahci.0: flags: ncq sntf pm led clo only pmp pio slum part ccc
> ? ?scsi0 : ahci_platform
> ? ?scsi1 : ahci_platform
> ? ?ata1: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 65
> ? ?ata2: SATA max UDMA/133 mmio [mem 0x83000000-0x83ffffff] port 0x180 irq 65
> ? ?ata2: SATA link down (SStatus 0 SControl 300)
> ? ?ata1: link is slow to respond, please be patient (ready=0)
> ? ?ata1: softreset failed (device not ready)
> ? ?ata1: link is slow to respond, please be patient (ready=0)
> ? ?ata1: softreset failed (device not ready)
> ? ?ata1: link is slow to respond, please be patient (ready=0)
> ? ?ata1: softreset failed (device not ready)
> ? ?ata1: limiting SATA link speed to 1.5 Gbps
> ? ?ata1: SATA link down (SStatus 1 SControl 310)
>
> While using multiplier with CONFIG_SATA_PMP enabled, or using disks directly
> without CONFIG_SATA_PMP have no issue. It seems the device is sending D2H Reg
> FIS, but controller is not reflecting it on any known means.
>
> Signed-off-by: Mac Lin <mkl0301@gmail.com>
> ---
> ?arch/arm/mach-cns3xxx/devices.c | ? ?2 +-
> ?drivers/ata/Kconfig ? ? ? ? ? ? | ? 11 +++++++++++
> ?drivers/ata/ahci_platform.c ? ? | ? 39 +++++++++++++++++++++++++++++++++++++++
> ?3 files changed, 51 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-cns3xxx/devices.c b/arch/arm/mach-cns3xxx/devices.c
> index 50b4d31..b496f02 100644
> --- a/arch/arm/mach-cns3xxx/devices.c
> +++ b/arch/arm/mach-cns3xxx/devices.c
> @@ -40,7 +40,7 @@ static struct resource cns3xxx_ahci_resource[] = {
> ?static u64 cns3xxx_ahci_dmamask = DMA_BIT_MASK(32);
>
> ?static struct platform_device cns3xxx_ahci_pdev = {
> - ? ? ? .name ? ? ? ? ? = "ahci",
> + ? ? ? .name ? ? ? ? ? = "ahci-cns3xxx",
> ? ? ? ?.id ? ? ? ? ? ? = 0,
> ? ? ? ?.resource ? ? ? = cns3xxx_ahci_resource,
> ? ? ? ?.num_resources ?= ARRAY_SIZE(cns3xxx_ahci_resource),
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index 36e2319..5d8b1a3 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -75,6 +75,17 @@ config SATA_AHCI_PLATFORM
>
> ? ? ? ? ?If unsure, say N.
>
> +config SATA_AHCI_CNS3XXX
> + ? ? ? bool "AHCI Support on the Cavium Networks CNS3xxx SOC"
> + ? ? ? depends on ARCH_CNS3XXX
> + ? ? ? depends on SATA_AHCI_PLATFORM
> + ? ? ? help
> + ? ? ? ? This option enables AHCI platform driver to support CNS3xxx
> + ? ? ? ? System-on-Chip devices. This is only needed when using CNS3xxx AHCI
> + ? ? ? ? controller.
> +
> + ? ? ? ? If unsure, say N.
> +
> ?config SATA_FSL
> ? ? ? ?tristate "Freescale 3.0Gbps SATA support"
> ? ? ? ?depends on FSL_SOC
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 25d98c8..7d6957f 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -176,8 +176,47 @@ static int __devexit ahci_remove(struct platform_device *pdev)
> ? ? ? ?return 0;
> ?}
>
> +#ifdef CONFIG_SATA_AHCI_CNS3XXX
> +/*
> + * TODO: move cns3xxx_ahci_init to here after cns3xxx_pwr*() calls are
> + * thread-safe
> + */
> +
> +static int cns3xxx_ahci_softreset(struct ata_link *link, unsigned int *class,
> + ? ? ? ? ? ? ? ? ? ? ? ? unsigned long deadline)
> +{
> + ? ? ? int pmp = sata_srst_pmp(link);
> + ? ? ? int ret;
> +
> + ? ? ? ret = ahci_do_softreset(link, class, pmp, deadline, ahci_check_ready);
> + ? ? ? if (pmp && ret)
> + ? ? ? ? ? ? ? return ahci_do_softreset(link, class, 0, deadline,
> + ? ? ? ? ? ? ? ? ? ? ? ahci_check_ready);
> + ? ? ? return ret;
> +}
> +
> +static struct ata_port_operations cns3xxx_ahci_ops = {
> + ? ? ? .inherits ? ? ? ? ? ? ? = &ahci_ops,
> + ? ? ? .softreset ? ? ? ? ? ? ?= cns3xxx_ahci_softreset,
> +};
> +
> +static const struct ata_port_info cns3xxx_ata_port_info = {
> + ? ? ? .flags ? ? ? ? ?= AHCI_FLAG_COMMON,
> + ? ? ? .pio_mask ? ? ? = ATA_PIO4,
> + ? ? ? .udma_mask ? ? ?= ATA_UDMA6,
> + ? ? ? .port_ops ? ? ? = &cns3xxx_ahci_ops,
> +};
> +
> +struct ahci_platform_data cns3xxx_ahci_platform_data = {
> + ? ? ? .ata_port_info ?= &cns3xxx_ata_port_info,
> +};
> +#endif
> +
> ?static const struct platform_device_id ahci_pltfm_ids[] = {
> ? ? ? ?{ "ahci", },
> +#ifdef CONFIG_SATA_AHCI_CNS3XXX
> + ? ? ? { "ahci-cns3xxx", (kernel_ulong_t)&cns3xxx_ahci_platform_data},
> +#endif
> ? ? ? ?{ },
> ?};
> ?MODULE_DEVICE_TABLE(platform, ahci_pltfm_ids);
> --
> 1.7.3
>
>
The code is less readable with macro here and there. It would be more
complicated if more SoC-specific code added.
I really prefer the original way.
Best Regards,
Mac Lin
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Russell King - ARM Linux @ 2011-01-06 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294335614.22825.154.camel@mulgrave.site>
On Thu, Jan 06, 2011 at 11:40:13AM -0600, James Bottomley wrote:
> On Wed, 2011-01-05 at 23:28 +0000, James Bottomley wrote:
> > Can you explain how the code works? it looks to me like you read the xdr
> > stuff through the vmap region then write it out directly to the pages?
>
> OK, I think I see how this is supposed to work: It's a sequential loop
> of reading in via the pages (i.e. through the kernel mapping) and then
> updating those pages via the vmap. In which case, I think this patch is
> what you need.
>
> The theory of operation is that the readdir on pages actually uses the
> network DMA operations to perform, so when it's finished, the underlying
What network DMA operations - what if your NIC doesn't do DMA because
it's an SMSC device?
^ permalink raw reply
* [PATCH v3 2/2] ahci_platform: add support for CNS3xxx SoC devices
From: Ben Dooks @ 2011-01-06 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinO-feQkpfoZhmOV7VyPbyL=f8KV1_Qysps04ve@mail.gmail.com>
On Fri, Jan 07, 2011 at 02:04:33AM +0800, Lin Mac wrote:
> Hi Jeff,
>
> 2011/1/7 <mkl0301@gmail.com>:
> > From: Mac Lin <mkl0301@gmail.com>
> >
> > CNS3xxx override the softreset function of ahci_platform ahci_softreset by
> > cns3xxx_ahci_softreset, which would retry ahci_do_softreset again with pmp=0 if
> > pmp=15 failed, for the controller has problem receiving D2H Reg FIS of the
> > different PMP setting of the previous sent H2D Reg FIS.
> >
> > Following describe the isssue with original ahci_platform driver on
> > linux-2.6.37-rc3, arm/cns3xxx.
> >
> > If CONFIG_SATA_PMP is enabled, while not using multiplier and connect the disks
> > directly to the board, the disk cannot be found due to software reset always
> complicated if more SoC-specific code added.
> I really prefer the original way.
Is there a reference to the original?
--
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
^ permalink raw reply
* [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
From: Kevin Hilman @ 2011-01-06 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <65442ed447ba6e1fc8dab9f9d944c03a@mail.gmail.com>
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>> -----Original Message-----
>> From: Premi, Sanjeev [mailto:premi at ti.com]
>> Sent: Thursday, January 06, 2011 8:03 PM
>> To: Shilimkar, Santosh; linux-omap at vger.kernel.org
>> Cc: Hilman, Kevin; tony at atomide.com; linux-arm-
>> kernel at lists.infradead.org; Shilimkar, Santosh; Paul Walmsley
>> Subject: RE: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix
>> for undefined reference to 'omap2_prm_read_mod_reg'
>>
>> > -----Original Message-----
>> > From: linux-omap-owner at vger.kernel.org
>> > [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of
>> > Santosh Shilimkar
>> > Sent: Wednesday, January 05, 2011 4:27 PM
>> > To: linux-omap at vger.kernel.org
>> > Cc: Hilman, Kevin; tony at atomide.com;
>> > linux-arm-kernel at lists.infradead.org; Shilimkar, Santosh;
>> > Paul Walmsley
>> > Subject: [PATCH v2 2/5] omap2plus: prm: Trvial build break
>> > fix for undefined reference to 'omap2_prm_read_mod_reg'
>>
>> [snip]
>>
>> >
>> > #ifndef __ASSEMBLER__
>> > -
>> > +/*
>> > + * Stub omap2xxx/omap3xxx functions so that common files
>> > + * continue to build when custom builds are used
>> > + */
>> > +#if defined(CONFIG_ARCH_OMAP4) &&
>> > !(defined(CONFIG_ARCH_OMAP2) || \
>> > + defined(CONFIG_ARCH_OMAP3))
>> > +static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
>> > +{
>> > + WARN_ONCE(1, "prm: omap2xxx/omap3xxx specific function and "
>> > + "not suppose to be used on omap4\n");
>> > + return 0;
>> > +}
>> Looking forward, the warning of incorrect SOC may be required
>> for when kernel is build for one specific SOC.
>>
>> Wouldn't it be easy/better to have common global function:
>>
>> void wrong_soc(char* func, int soc_id)
>> {
>> WARN_ONCE(1, "Function %s cannot be used for %d", func,
>> soc_id);
>> }
>>
>> OR we could have soc specific functions e.g.
>>
>> void omap2xxx_only (char* func)
>> {
>> WARN_ONCE(1, "Function %s is specific to OMAP2XXX");
>> }
>> ..etc..
>>
>> Later these functions can be called from the stubs.
>>
>> This is prelim idea, will need to be worked upon.
>>
> Not sure. May appear like over engineering considering it's a
> stub.
> Paul can comment.
I guess Sanjeev's approach is meant eliminate duplicate strings that
waste space.
Sanjeev, did you check whether multiple copies of the exact same string
actually exist in the binary? I'm wondering if gcc is smart enough to
only have one copy of the string (but have doubts.)
Kevin
^ permalink raw reply
* [PATCH] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
From: Mika Westerberg @ 2011-01-06 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87oc7v1eav.fsf@ti.com>
Hi Kevin,
On Wed, Jan 05, 2011 at 08:54:48AM -0800, Kevin Hilman wrote:
>
> I had assumed it was recent changes since the patch didn't apply
> cleanly, but am glad to be wrong. :)
The patch should apply cleanly on the latest mainline. Do you want me to
rebase it against some other tree and resend?
Thanks,
MW
^ permalink raw reply
* [PATCH v3 2/2] ahci_platform: add support for CNS3xxx SoC devices
From: Lin Mac @ 2011-01-06 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106180948.GX27131@trinity.fluff.org>
2011/1/7 Ben Dooks <ben@trinity.fluff.org>:
> On Fri, Jan 07, 2011 at 02:04:33AM +0800, Lin Mac wrote:
>> Hi Jeff,
>>
>> 2011/1/7 ?<mkl0301@gmail.com>:
>> > From: Mac Lin <mkl0301@gmail.com>
>> >
>> > CNS3xxx override the softreset function of ahci_platform ahci_softreset by
>> > cns3xxx_ahci_softreset, which would retry ahci_do_softreset again with pmp=0 if
>> > pmp=15 failed, for the controller has problem receiving D2H Reg FIS of the
>> > different PMP setting of the previous sent H2D Reg FIS.
>> >
>> > Following describe the isssue with original ahci_platform driver on
>> > linux-2.6.37-rc3, arm/cns3xxx.
>> >
>> > If CONFIG_SATA_PMP is enabled, while not using multiplier and connect the disks
>> > directly to the board, the disk cannot be found due to software reset always
>
>> complicated if more SoC-specific code added.
>> I really prefer the original way.
>
> Is there a reference to the original?
v2: http://www.spinics.net/lists/linux-ide/msg39766.html
Best Regards,
Mac Lin
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-06 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106180530.GI31708@n2100.arm.linux.org.uk>
On Thu, 2011-01-06 at 18:05 +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 06, 2011 at 11:40:13AM -0600, James Bottomley wrote:
> > On Wed, 2011-01-05 at 23:28 +0000, James Bottomley wrote:
> > > Can you explain how the code works? it looks to me like you read the xdr
> > > stuff through the vmap region then write it out directly to the pages?
> >
> > OK, I think I see how this is supposed to work: It's a sequential loop
> > of reading in via the pages (i.e. through the kernel mapping) and then
> > updating those pages via the vmap. In which case, I think this patch is
> > what you need.
> >
> > The theory of operation is that the readdir on pages actually uses the
> > network DMA operations to perform, so when it's finished, the underlying
>
> What network DMA operations - what if your NIC doesn't do DMA because
> it's an SMSC device?
So this is the danger area ... we might be caught by our own flushing
tricks. I can't test this on parisc since all my network drivers use
DMA (which automatically coheres the kernel mapping by
flush/invalidate).
What should happen is that the kernel mapping pages go through the
->readdir() path. Any return from this has to be ready to map the pages
back to user space, so the kernel alias has to be flushed to make the
underlying page up to date.
The exception is pages we haven't yet mapped to userspace. Here we set
the PG_dcache_dirty bit (sparc trick) but don't flush the page, since we
expect the addition of a userspace mapping will detect this case and do
the flush and clear the bit before the mapping goes live. I assume
you're thinking that because this page is allocated and freed internally
to NFS, it never gets a userspace mapping and therefore, we can return
from ->readdir() with a dirty kernel cache (and the corresponding flag
set)? I think that is a possible hypothesis in certain cases.
James
^ permalink raw reply
* [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM
From: Paul Walmsley @ 2011-01-06 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294234855-6623-1-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh,
On Wed, 5 Jan 2011, Santosh Shilimkar wrote:
> Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup mechanism'
> introduced watchdog timer state state management using postsetup_state.
> This was done to allow some board files to support watchdog coverage
> throughout kernel initialization and it work as intended when RUNTIME_PM
> is enabled.
>
> With !CONFIG_RUNTIME_PM and no board is specifically requests watchdog
> to remain enabled the omap_wdt_probe crashesh. This is because hwmod
> in absense of runtime PM unable to turn watchdog clocks because it's
> state is set to be disabled. For rest of the device, the state is
> set as enabled in absense of RUNTIME_PM
>
> [ 1.372558] Unhandled fault: imprecise external abort (0x1406) at 0xad733eeb
> [ 1.379913] Internal error: : 1406 [#1] SMP
> [ 1.384277] last sysfs file:
> [ 1.387359] Modules linked in:
> [ 1.390563] CPU: 0 Tainted: G W (2.6.37-rc7-00265-g4298a4c-dirty #23)
> [ 1.398468] PC is at omap_wdt_disable+0x2c/0x3c
> [ 1.403198] LR is at omap_wdt_probe+0x124/0x1e0
> [ 1.407928] pc : [<c02f5bf4>] lr : [<c03be10c>] psr: 60000013
> [ 1.407958] sp : df833f00 ip : 00000000 fp : 00000000
> [ 1.419921] r10: c0ac57ac r9 : df959e00 r8 : 00000000
> [ 1.425384] r7 : df959e08 r6 : df8000c0 r5 : df95bebc r4 : df87dde0
> [ 1.432189] r3 : fc314000 r2 : 00005555 r1 : fc314034 r0 : df87dde0
>
> This patch make the default watchdog state to be enabled in case of
> !CONFIG_RUNTIME_PM. This fixes the crash
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> Paul, I am not too sure if it breaks your _shutdown idea of watchdog
> timer.
Maybe. What happens in a case where the bootloader enables the watchdog,
but the booting kernel is compiled with !CONFIG_OMAP_WATCHDOG and
!CONFIG_PM_RUNTIME? Won't the watchdog reset the MPU unexpectedly in that
case? Or am I missing something...
- Paul
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-06 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294337670.22825.199.camel@mulgrave.site>
On Thu, 2011-01-06 at 12:14 -0600, James Bottomley wrote:
> On Thu, 2011-01-06 at 18:05 +0000, Russell King - ARM Linux wrote:
> > What network DMA operations - what if your NIC doesn't do DMA because
> > it's an SMSC device?
>
> So this is the danger area ... we might be caught by our own flushing
> tricks. I can't test this on parisc since all my network drivers use
> DMA (which automatically coheres the kernel mapping by
> flush/invalidate).
>
> What should happen is that the kernel mapping pages go through the
> ->readdir() path. Any return from this has to be ready to map the pages
> back to user space, so the kernel alias has to be flushed to make the
> underlying page up to date.
>
> The exception is pages we haven't yet mapped to userspace. Here we set
> the PG_dcache_dirty bit (sparc trick) but don't flush the page, since we
> expect the addition of a userspace mapping will detect this case and do
> the flush and clear the bit before the mapping goes live. I assume
> you're thinking that because this page is allocated and freed internally
> to NFS, it never gets a userspace mapping and therefore, we can return
> from ->readdir() with a dirty kernel cache (and the corresponding flag
> set)? I think that is a possible hypothesis in certain cases.
OK, so thinking about this, it seems that the only danger is actually
what NFS is doing: reading cache pages via a vmap. In that case, since
the requirement is to invalidate the vmap range to prepare for read, we
could have invalidate_kernel_vmap_range loop over the underlying pages
and flush them through the kernel alias if the architecture specific
flag indicates their contents might be dirty.
The loop adds expense that is probably largely unnecessary to
invalidate_kernel_vmap_range() but the alternative is adding to the API
proliferation with something that only flushes the kernel pages if the
arch specific flag says they're dirty.
James
^ permalink raw reply
* [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Kevin Hilman @ 2011-01-06 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101061059590.22048@utopia.booyaka.com>
Paul Walmsley <paul@pwsan.com> writes:
> On Wed, 5 Jan 2011, Kevin Hilman wrote:
>
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>> > struct clockdomain member clktrctrl_mask is available for only for OMAP2
>> > and OMAP3 architectures. Technially it is also used only for these archs
>> > but this breaks the build with custom OMAP4 configuration.
>>
>> I'll queue patches 3-5 for the 2.6.38-rc fixes cycle.
>>
>> With Paul's ack, I can queue the others too, or Paul can decide to take
>> them via his tree. Paul can decide.
>
> I've acked one and requested minor changes on the other, after which it
> can be acked by me. You're welcome to take them at that point. Just a
> request, maybe you can post a branch with just these patches in them; that
> way Rajendra and/or I can rebase his new clockdomain changes on it until
> -rc1 comes out.
Sure, will do.
I currently have a 'fixes-for-tony' branch in my tree which has all the
fixes I've collected for the -rc cycle.
If you prefer something separate with only the prm and clockdomain
patches from this series, I can do that as well.
Kevin
^ permalink raw reply
* [PATCH] OMAP: GPIO: fix _set_gpio_triggering() for OMAP2+
From: Kevin Hilman @ 2011-01-06 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106181249.GA2466@acer>
Mika Westerberg <mika.westerberg@iki.fi> writes:
> Hi Kevin,
>
> On Wed, Jan 05, 2011 at 08:54:48AM -0800, Kevin Hilman wrote:
>>
>> I had assumed it was recent changes since the patch didn't apply
>> cleanly, but am glad to be wrong. :)
>
> The patch should apply cleanly on the latest mainline. Do you want me to
> rebase it against some other tree and resend?
No, it's fine. I'll be queueing it for .38-rc2 and it's in my
'fixes-for-tony' branch.
Kevin
^ permalink raw reply
* [PATCH V2] ST SPEAr: PCIE gadget suppport
From: Greg KH @ 2011-01-06 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <137dfad4a093ea0ac80396f5eb7fbf0c382be698.1294314772.git.viresh.kumar@st.com>
On Thu, Jan 06, 2011 at 05:29:10PM +0530, Viresh Kumar wrote:
> From: Pratyush Anand <pratyush.anand@st.com>
>
> This is a configurable gadget. can be configured by sysfs interface. Any
> IP available at PCIE bus can be programmed to be used by host
> controller.It supoorts both INTX and MSI.
> By default, gadget is configured for INTX and SYSRAM1 is mapped to BAR0
> with size 0x1000
>
> Changes since V1:
> - __iomem added for register addresses
> - kerneldoc comment removed whereever not required.
> - help node moved from sysfs to documentation/misc-devices
> - strict_strtoul used instead of sscanf
>
> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> ---
> Documentation/misc-devices/spear-pcie-gadget.txt | 125 ++++
New sysfs entries require updates to the Documentation/ABI/ directory
for them.
Please rework the patch to include these entries.
> +read behaviour of nodes:
> +------------------------------
> +link :gives ltssm status.
> +int_type :type of supported interrupt
> +no_of_msi read :zero if MSI is not enabled by host.A positive value is the
> + number of MSI vector granted.
> +vendor_id :returns programmed vendor id (hex)
> +device_id :returns programmed device id(hex)
> +bar0_size: :retruns size of bar0 in hex.
> +bar0_address :returns address of bar0 mapped area in hex.
> +bar0_rw_offset :returns offset of bar0 for which bar0_data will return value.
> +bar0_data :returns data at bar0_rw_offset.
> +
> +write behaviour of nodes:
> +------------------------------
> +link :write UP to enable ltsmm DOWN to disable
> +int_type :write interrupt type to be configured and (int_type could be
> + INTA, MSI or NO_INT).select MSI only when you have programmed
> + no_of_msi node.
> +no_of_msi :number of MSI vector needed.
> +inta :write 1 to assert INTA and 0 to de-assert.
> +send_msi :write MSI vector to be send.
> +vendor_id :write vendor id(hex) to be programmed.
> +device_id :write device id(hex) to be programmed.
> +bar0_size :write size of bar0 in hex. default bar0 size is 1000 (hex)
> + bytes.
> +bar0_address :write address of bar0 mapped area in hex. (default mapping of
> + bar0 is SYSRAM1(E0800000).Aalways program bar size before bar
> + address. kernel might modify bar size and address to align. So
> + read back bar size and address after writing to cross check.
> +bar0_rw_offset :write offset of bar0 for which bar0_data will write value.
> +bar0_data :write data to be written at bar0_rw_offset.
Should you use configfs for this instead of sysfs? It looks like that
is what you are looking for here.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 1/1] mtd: msm_nand: Add initial msm nand driver support.
From: Artem Bityutskiy @ 2011-01-06 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294335542.24440.4.camel@c-dwalke-linux.qualcomm.com>
On Thu, 2011-01-06 at 09:39 -0800, Daniel Walker wrote:
> On Wed, 2011-01-05 at 22:39 +0200, Artem Bityutskiy wrote:
> > On Wed, 2011-01-05 at 09:12 -0800, Daniel Walker wrote:
> > > On Wed, 2011-01-05 at 10:41 +0200, Artem Bityutskiy wrote:
> > > > On Fri, 2010-12-31 at 14:24 +0530, Murali Nalajala wrote:
> > > > > From: Arve Hj?nnev?g <arve@android.com>
> > > > >
> > > > > Add initial msm nand driver support for Qualcomm MSM and QSD platforms.
> > > > > This driver is currently capable of handling 2K page nand devices.
> > > > >
> > > > > This driver is originally
> > > > > developed by Google and its source is available at
> > > > > http://android.git.kernel.org/?p=kernel/experimental.git
> > > > >
> > > > > CC: Brian Swetland <swetland@google.com>
> > > > > Signed-off-by: Arve Hj?nnev?g <arve@android.com>
> > > > > Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>
> > > >
> > > > Pushed to l2-mtd-2.6.git.
> > >
> > > This patch had incorrect authorship .. Can you replace it with the
> > > second one that was sent ?
> >
> > Yes, I did that actually, noticed the second one later.
>
> Is it too late for you to drop this ? It's got some additional issues
> that we need some time to address ..
Sure, I do not merge stuff to upstream, I barely take it to my tree to
make sure David Woodhouse does not miss it. Everything he does not merge
to mtd tree is automatically dropped from my l2-mtd then.
--
Best Regards,
Artem Bityutskiy (???????? ?????)
^ permalink raw reply
* [PATCH] PM: fix suspend_set_ops() to take const pointer
From: Kevin Hilman @ 2011-01-06 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294273373-8967-1-git-send-email-khilman@ti.com>
On Wed, 2011-01-05 at 16:22 -0800, Kevin Hilman wrote:
> checkpatch warns that pointers for certain structs should be const,
> and platform_suspend_ops is one of those structs. If you follow this
> suggestion you trade a checkpatch warning for a compiler warning of
> the form:
>
> warning: passing argument 1 of 'suspend_set_ops' discards qualifiers from pointer target type
>
> Fix suspend_set_ops() to take a const pointer so everyone expects
> const.
>
> Signed-off-by: Kevin Hilman <khilman@ti.com>
> ---
> Applies to v2.6.37, but also applies cleanly to suspend-2.6/linux-next
Oops, plese disregard. This is already fixed in linux-next.
Kevin
> include/linux/suspend.h | 4 ++--
> kernel/power/suspend.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/suspend.h b/include/linux/suspend.h
> index 2669751..bb98383 100644
> --- a/include/linux/suspend.h
> +++ b/include/linux/suspend.h
> @@ -122,7 +122,7 @@ struct platform_suspend_ops {
> * suspend_set_ops - set platform dependent suspend operations
> * @ops: The new suspend operations to set.
> */
> -extern void suspend_set_ops(struct platform_suspend_ops *ops);
> +extern void suspend_set_ops(const struct platform_suspend_ops *ops);
> extern int suspend_valid_only_mem(suspend_state_t state);
>
> /**
> @@ -147,7 +147,7 @@ extern int pm_suspend(suspend_state_t state);
> #else /* !CONFIG_SUSPEND */
> #define suspend_valid_only_mem NULL
>
> -static inline void suspend_set_ops(struct platform_suspend_ops *ops) {}
> +static inline void suspend_set_ops(const struct platform_suspend_ops *ops) {}
> static inline int pm_suspend(suspend_state_t state) { return -ENOSYS; }
> #endif /* !CONFIG_SUSPEND */
>
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index ecf7705..0c0af3d 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -36,7 +36,7 @@ static struct platform_suspend_ops *suspend_ops;
> * suspend_set_ops - Set the global suspend method table.
> * @ops: Pointer to ops structure.
> */
> -void suspend_set_ops(struct platform_suspend_ops *ops)
> +void suspend_set_ops(const struct platform_suspend_ops *ops)
> {
> mutex_lock(&pm_mutex);
> suspend_ops = ops;
^ permalink raw reply
* [PATCH v6 3/3] omap3: beaglexm: fix power on of DVI
From: Koen Kooi @ 2011-01-06 19:29 UTC (permalink / raw)
To: linux-arm-kernel
TFP410 DVI chip is used to provide display out.
This chip is controlled by 2 lines:
LDO which supplies the power is controlled over gpio + 2
and the enable of the chip itself is done over gpio + 1
NOTE: the LDO is necessary for LED, serial blocks as well.
gpio + 1 was used to sense USB overcurrent in vanilla beagle.
Without this fix, the display would not function as the LDO
remains shut down.
[nm at ti.com: split up, added descriptive changelogs]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
---
arch/arm/mach-omap2/board-omap3beagle.c | 42 ++++++++++++++++++++++++++++--
1 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 673deb9..28dfe8e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -273,6 +273,8 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int r;
+
if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
@@ -293,9 +295,16 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
-
- gpio_request(gpio + 1, "EHCI_nOC");
- gpio_direction_input(gpio + 1);
+ if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
+ r = gpio_request(gpio + 1, "EHCI_nOC");
+ if (!r) {
+ r = gpio_direction_input(gpio + 1);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err("%s: unable to configure EHCI_nOC\n", __func__);
+ }
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
@@ -316,6 +325,33 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+ /*
+ * gpio + 1 on Xm controls the TFP410's enable line (active low)
+ * gpio + 2 control varies depending on the board rev as follows:
+ * P7/P8 revisions(prototype): Camera EN
+ * A2+ revisions (production): LDO (supplies DVI, serial, led blocks)
+ */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ r = gpio_request(gpio + 1, "nDVI_PWR_EN");
+ if (!r) {
+ r = gpio_direction_output(gpio + 1, 0);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err("%s: unable to configure nDVI_PWR_EN\n",
+ __func__);
+ r = gpio_request(gpio + 2, "DVI_LDO_EN");
+ if (!r) {
+ r = gpio_direction_output(gpio + 2, 1);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err("%s: unable to configure DVI_LDO_EN\n",
+ __func__);
+ }
+
return 0;
}
--
1.6.3.3
--------------030608000406040903000005
Content-Type: text/x-patch;
name="gpio-check.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="gpio-check.patch"
^ permalink raw reply related
* [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD
From: Arnd Bergmann @ 2011-01-06 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7E0D4C72-717F-495B-98FE-35F40C7CDCAE@marvell.com>
On Friday 31 December 2010, Philip Rakity wrote:
> The patch selects ARCH-MMP (as now) but adds the ability
> to also know which specific SoC was chosen. (This is sort of done by choosing the development board today).
On a larger scale, we try to go in the opposite direction: make it possible to
have kernels run on as many boards as possible by decreasing the code differences
between SoCs and even SoC families.
> > Your patches will make them mess.
>
> suggest a solution.
>
> The current mechanism of having the development board select the CPU does not seem right.
> One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU
> are different and not compatible. (for example cache handling).
The optimal solution would be to make sure that working support for both CPUs can be built into
a single kernel. There is a lot of infrastructure in arch/arm/mm/* that tries to do this, but
I don't know of that actually works for the combination of CPU_MOHAWK and CPU_V6. It does
work for some other combinations of CPU cores though, so it's certainly possible.
For instance, arch/arm/include/asm/cacheflush.h has abstractions to select the cache handling
at boot time.
To go even further, it might make sense to combine the PXA and MMP platforms, since they already
share some code through the plat-pxa directory.
Getting it running for MMP with mohawk and v6 cores could be a significant amount of work if
nobody has tries this in that platform, so for now, I would recommend you just keep ARCH_MMP as
a global option in arch/arm/Kconfig for now and add another 'choice' statement in
arch/arm/mach-mmp/Kconfig to select the CPU core, with the board selection depending on that.
Arnd
^ permalink raw reply
* [PATCH 0/7] ARM: S3C24XX: H1940 and RX1950 series
From: Vasily Khoruzhick @ 2011-01-06 19:52 UTC (permalink / raw)
To: linux-arm-kernel
This series improves HP iPAQ H1940 and RX1950 support.
Changes introduced by these patches:
1. Add support for H1940 buttons
2. Compile fix for h1940-bluetooth.c
3. Use leds-gpio to drive LEDs on H1940
4. Add support for battery monitoring and charging on H1940
5. Improve LCD power-on sequence
6. Retain LEDs state on RX1950 in suspend
7. Add support for HW LEDs blinking on RX1950
^ 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