* [PATCH] Fix ep93xx-fb init/exit annotations
From: H Hartley Sweeten @ 2011-01-10 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2A4AFD.4050008@bluewatersys.com>
Sunday, January 09, 2011 4:56 PM, Ryan Mallon wrote:
>
> Fix section mismatch errors in the ep93xx-fb driver resulting from
> incorrect init/exit annotations.
>
> Reported-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Signed-off-by: Ryan Mallon <ryan@bluewatersys.com>
That fixed it.
Tested-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [PATCH 4/5 v4] msm: convert 7x30 to gpiomux.
From: Daniel Walker @ 2011-01-10 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikrLnGxNSJgv3KDNAQ5kvjNd8aPrOEBwftiiyrQ@mail.gmail.com>
On Sun, 2011-01-09 at 14:53 -0800, Dima Zavin wrote:
> Greg,
>
> Just rebased on top of 2.6.37 and this patch is totally the wrong way
> to go about this.
>
> I should have commented at the appropriate time, so sorry for the late reply.
>
> Having this msm_gpiomux_configs be always compiled in for all msm7x30
> devices makes this entire system completely inflexible since you have
> to modify common code to provide board specific initialization. The
> definition of "msm_gpiomux_configs" belongs in the board file, not in
> gpiomux-7x30.c. I think we need to delete this new file and move the
> definition back into board-msm7x30.c, but just use the new gpiomux
> APIs.
>
> I can provide a patch if you like.
I would just provide the patch .. It would be easier to understand what
your talking about.
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Marc Kleine-Budde @ 2011-01-10 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294680035.3349.19.camel@heimdal.trondhjem.org>
On 01/10/2011 06:20 PM, Trond Myklebust wrote:
>> Is this patch a candidate for stable?
>
> Yes. I'm planning on sending it to the stable list after Linus merges it
> into mainline.
Fine!
regards, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110110/110762ce/attachment.sig>
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Trond Myklebust @ 2011-01-10 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2B3D03.8050504@pengutronix.de>
On Mon, 2011-01-10 at 18:08 +0100, Marc Kleine-Budde wrote:
> On 01/10/2011 05:25 PM, Trond Myklebust wrote:
> > On Mon, 2011-01-10 at 11:50 +0100, Uwe Kleine-K?nig wrote:
> >> Hi Trond,
> >>
> >> On Sat, Jan 08, 2011 at 06:15:51PM -0500, Trond Myklebust wrote:
> >>> -----------------------------------------------------------------------------------
> >> It would be great if you could add a "8<" in the line above next time.
> >> Then git-am -c does the right thing (at least I think so).
> >
> > Sorry. I wasn't aware of that particular idiom. So something like
> >
> > 8<------------------------------------------------------------
> > From: Trond Myklebust <Trond.Myklebust@netapp.com>
> > Subject: .....
>
> Yes.
>
> From "man git-mailinfo":
> "A line that mainly consists of scissors (either ">8" or "8<") and
> perforation (dash "-")"
>
> BTW:
> Is this patch a candidate for stable?
Yes. I'm planning on sending it to the stable list after Linus merges it
into mainline.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust at netapp.com
www.netapp.com
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Marc Kleine-Budde @ 2011-01-10 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294676734.3349.10.camel@heimdal.trondhjem.org>
On 01/10/2011 05:25 PM, Trond Myklebust wrote:
> On Mon, 2011-01-10 at 11:50 +0100, Uwe Kleine-K?nig wrote:
>> Hi Trond,
>>
>> On Sat, Jan 08, 2011 at 06:15:51PM -0500, Trond Myklebust wrote:
>>> -----------------------------------------------------------------------------------
>> It would be great if you could add a "8<" in the line above next time.
>> Then git-am -c does the right thing (at least I think so).
>
> Sorry. I wasn't aware of that particular idiom. So something like
>
> 8<------------------------------------------------------------
> From: Trond Myklebust <Trond.Myklebust@netapp.com>
> Subject: .....
Yes.
>From "man git-mailinfo":
"A line that mainly consists of scissors (either ">8" or "8<") and
perforation (dash "-")"
BTW:
Is this patch a candidate for stable?
regards, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110110/db4d5898/attachment.sig>
^ permalink raw reply
* [PATCH] ep93xx: add framebuffer support to edb93xx boards
From: H Hartley Sweeten @ 2011-01-10 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=uw2sxizgDBSnDQVMaokikirDQgxt1w6sP4C05@mail.gmail.com>
On Saturday, January 08, 2011 12:53 PM, Martin Guy wrote:
> On Fri, Jan 7, 2011 at 11:38 PM, H Hartley Sweeten <hartleys@visionengravers.com> wrote:
>> The ep9307, ep9312, and ep9315 variants of the ep93xx processor include the
>> raster engine needed for framebuffer support.
>>
>> This allows the EDB93xx boards with those processors to use the framebuffer
>> driver.
>>
>> Tested on an EDB9307A with the following kernel parameters:
>> ? ? ? ?video=640x480-16 at 60
>> ? ? ? ?video=1024x768-16 at 60
>>
>> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
>
> The code looks good, but there are hardware bugs in the EP93XX that
> make the screen image jump a few pixels to the right once every few
> seconds. We found that 800x600-16 and 1024x768-8 were the highest
> modes that are stable.
Hardware bugs in the EP93XX... No... ;-)
> Did you find 1024x768-16 to be stable, say when running X and moving a
> window? The effect was most visible on a phosphor CRT, less noticeable
> on an LCD.
I don't have any use for X on the EP93XX so, no I have not tested that.
My app uses the SDL library and has very little actual "motion" going on
so the screen looks pretty stable in my tests.
I have noticed some timing issues with the framebuffer driver, the requested
60Hz refresh is being reported as either 59 or 61Hz on the display, but I
haven't taken the time to look into it yet.
Could the problem you are seeing just be a bandwidth limitation? Have you
tried changing the AHB master priority order with the SysCon BysMstrArb
register (0x8093_0054)? The default priority (00) has the following order:
1 - Raster Cursor
2 - MAC
3 - USB
4 - DMA
5 - ARM920T
6 - Raster
The other priority's put the Raster first and shuffle the others around
various ways.
Regards,
Hartley
^ permalink raw reply
* [PATCH] ARM: imx/mx27_3ds: Add debug board support
From: Fabio Estevam @ 2011-01-10 16:42 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/mach-mx27_3ds.c | 7 +++++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 17d2e60..56684b5 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -243,6 +243,7 @@ config MACH_MX27_3DS
select IMX_HAVE_PLATFORM_MXC_EHCI
select IMX_HAVE_PLATFORM_MXC_MMC
select IMX_HAVE_PLATFORM_SPI_IMX
+ select MXC_DEBUG_BOARD
select MXC_ULPI if USB_ULPI
help
Include support for MX27PDK platform. This includes specific
diff --git a/arch/arm/mach-imx/mach-mx27_3ds.c b/arch/arm/mach-imx/mach-mx27_3ds.c
index 83f8e2b..4d72891 100644
--- a/arch/arm/mach-imx/mach-mx27_3ds.c
+++ b/arch/arm/mach-imx/mach-mx27_3ds.c
@@ -37,12 +37,15 @@
#include <mach/common.h>
#include <mach/iomux-mx27.h>
#include <mach/ulpi.h>
+#include <mach/irqs.h>
+#include <mach/3ds_debugboard.h>
#include "devices-imx27.h"
#define SD1_EN_GPIO (GPIO_PORTB + 25)
#define OTG_PHY_RESET_GPIO (GPIO_PORTB + 23)
#define SPI2_SS0 (GPIO_PORTD + 21)
+#define EXPIO_PARENT_INT (MXC_INTERNAL_IRQS + GPIO_PORTC + 28)
static const int mx27pdk_pins[] __initconst = {
/* UART1 */
@@ -276,6 +279,10 @@ static void __init mx27pdk_init(void)
imx27_add_spi_imx1(&spi2_pdata);
spi_register_board_info(mx27_3ds_spi_devs,
ARRAY_SIZE(mx27_3ds_spi_devs));
+
+ if (mxc_expio_init(MX27_CS5_BASE_ADDR, EXPIO_PARENT_INT))
+ pr_warn("Init of the debugboard failed, all "
+ "devices on the debugboard are unusable.\n");
}
static void __init mx27pdk_timer_init(void)
--
1.6.0.4
^ permalink raw reply related
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Trond Myklebust @ 2011-01-10 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110110105019.GC24920@pengutronix.de>
On Mon, 2011-01-10 at 11:50 +0100, Uwe Kleine-K?nig wrote:
> Hi Trond,
>
> On Sat, Jan 08, 2011 at 06:15:51PM -0500, Trond Myklebust wrote:
> > -----------------------------------------------------------------------------------
> It would be great if you could add a "8<" in the line above next time.
> Then git-am -c does the right thing (at least I think so).
Sorry. I wasn't aware of that particular idiom. So something like
8<------------------------------------------------------------
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: .....
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust at netapp.com
www.netapp.com
^ permalink raw reply
* [PATCH] watchdog: add support for the Synopsys DesignWare WDT
From: Jamie Iles @ 2011-01-10 15:59 UTC (permalink / raw)
To: linux-arm-kernel
The Synopsys DesignWare watchdog is found in several ARM based systems
and provides a choice of 16 timeout periods depending on the clock
input. The watchdog cannot be disabled once started.
If the platform does not provide a clk for the watchdog then the user
can specify the input frequency with the struct dw_wdt_platform_data in
<linux/platform_data/dw_wdt.h>
v5:
- don't select CONFIG_WATCHDOG_NOWAYOUT, use a software
heartbeat to keep the wdt alive if we allow close.
v4:
- cleanups as suggested by Viresh Kumar and Wim
- provide a mechanism to handle NULL clks and allow
platform_data to specify the clk_rate
- provide open-once protection
v3:
- convert pm to dev_pm_ops
- use devres for resource allocation
v2:
- constify fops
- request_mem_region() before ioremap()
- disable clk if misc_register() fails
Cc: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Jamie Iles <jamie@jamieiles.com>
---
drivers/watchdog/Kconfig | 9 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/dw_wdt.c | 405 ++++++++++++++++++++++++++++++++++
include/linux/platform_data/dw_wdt.h | 27 +++
4 files changed, 442 insertions(+), 0 deletions(-)
create mode 100644 drivers/watchdog/dw_wdt.c
create mode 100644 include/linux/platform_data/dw_wdt.h
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 8a3aa2f..62c607a 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -331,6 +331,15 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config DW_WATCHDOG
+ tristate "Synopsys DesignWare watchdog"
+ depends on ARM
+ help
+ Say Y here if to include support for the Synopsys DesignWare
+ watchdog timer found in many ARM chips.
+ To compile this driver as a module, choose M here: the
+ module will be called dw_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 4b0ef38..3b3da4a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_ADX_WATCHDOG) += adx_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_DW_WATCHDOG) += dw_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
new file mode 100644
index 0000000..45fa1fb
--- /dev/null
+++ b/drivers/watchdog/dw_wdt.c
@@ -0,0 +1,405 @@
+/*
+ * Copyright 2010-2011 Picochip Ltd., Jamie Iles
+ * http://www.picochip.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * This file implements a driver for the Synopsys DesignWare watchdog device
+ * in the many ARM subsystems. The watchdog has 16 different timeout periods
+ * and these are a function of the input clock frequency.
+ *
+ * The DesignWare watchdog cannot be stopped once it has been started so we
+ * use a software timer to implement a ping that will keep the watchdog alive.
+ * If we receive an expected close for the watchdog then we keep the timer
+ * running, otherwise the timer is stopped and the watchdog will expire.
+ */
+#define pr_fmt(fmt) "dw_wdt: " fmt
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/fs.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/pm.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/timer.h>
+#include <linux/uaccess.h>
+#include <linux/watchdog.h>
+
+#include <linux/platform_data/dw_wdt.h>
+
+#define WDOG_CONTROL_REG_OFFSET 0x00
+#define WDOG_CONTROL_REG_WDT_EN_MASK 0x01
+#define WDOG_TIMEOUT_RANGE_REG_OFFSET 0x04
+#define WDOG_CURRENT_COUNT_REG_OFFSET 0x08
+#define WDOG_COUNTER_RESTART_REG_OFFSET 0x0c
+#define WDOG_COUNTER_RESTART_KICK_VALUE 0x76
+
+/* The maximum TOP (timeout period) value that can be set in the watchdog. */
+#define DW_WDT_MAX_TOP 15
+
+static int nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
+ "(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+#define WDT_TIMEOUT (HZ / 2)
+
+static struct {
+ spinlock_t lock;
+ void __iomem *regs;
+ struct clk *clk;
+ unsigned long clk_rate;
+ unsigned long in_use;
+ unsigned long next_heartbeat;
+ struct timer_list timer;
+ int expect_close;
+} dw_wdt;
+
+static inline int dw_wdt_is_enabled(void)
+{
+ return readl(dw_wdt.regs + WDOG_CONTROL_REG_OFFSET) &
+ WDOG_CONTROL_REG_WDT_EN_MASK;
+}
+
+static inline int dw_wdt_top_in_seconds(unsigned top)
+{
+ /*
+ * There are 16 possible timeout values in 0..15 where the number of
+ * cycles is 2 ^ (16 + i) and the watchdog counts down.
+ */
+ return (1 << (16 + top)) / dw_wdt.clk_rate;
+}
+
+static int dw_wdt_get_top(void)
+{
+ int top = readl(dw_wdt.regs + WDOG_TIMEOUT_RANGE_REG_OFFSET) & 0xF;
+
+ return dw_wdt_top_in_seconds(top);
+}
+
+static inline void dw_wdt_set_next_heartbeat(void)
+{
+ dw_wdt.next_heartbeat = jiffies + dw_wdt_get_top() * HZ;
+}
+
+static int dw_wdt_set_top(unsigned top_s)
+{
+ int i, top_val = -1;
+
+ /*
+ * Iterate over the timeout values until we find the closest match. We
+ * always look for >=.
+ */
+ for (i = 0; i <= DW_WDT_MAX_TOP; ++i)
+ if (dw_wdt_top_in_seconds(i) >= top_s) {
+ top_val = i;
+ break;
+ }
+
+ /*
+ * If we didn't find a suitable value, it must have been too large. Go
+ * with the biggest that we can.
+ */
+ if (top_val < 0)
+ top_val = DW_WDT_MAX_TOP;
+
+ /* Set the new value in the watchdog. */
+ writel(top_val, dw_wdt.regs + WDOG_TIMEOUT_RANGE_REG_OFFSET);
+
+ dw_wdt_set_next_heartbeat();
+
+ return dw_wdt_top_in_seconds(top_val);
+}
+
+static void dw_wdt_keepalive(void)
+{
+ writel(WDOG_COUNTER_RESTART_KICK_VALUE, dw_wdt.regs +
+ WDOG_COUNTER_RESTART_REG_OFFSET);
+}
+
+static void dw_wdt_ping(unsigned long data)
+{
+ if (time_before(jiffies, dw_wdt.next_heartbeat) ||
+ (!nowayout && !dw_wdt.in_use)) {
+ dw_wdt_keepalive();
+ mod_timer(&dw_wdt.timer, jiffies + WDT_TIMEOUT);
+ } else
+ pr_crit("keepalive missed, machine will reset\n");
+}
+
+static int dw_wdt_open(struct inode *inode, struct file *filp)
+{
+ if (test_and_set_bit(0, &dw_wdt.in_use))
+ return -EBUSY;
+
+ /* Make sure we don't get unloaded. */
+ __module_get(THIS_MODULE);
+
+ spin_lock(&dw_wdt.lock);
+ if (!dw_wdt_is_enabled()) {
+ /*
+ * The watchdog is not currently enabled. Set the timeout to
+ * the maximum and then start it.
+ */
+ dw_wdt_set_top(DW_WDT_MAX_TOP);
+ writel(WDOG_CONTROL_REG_WDT_EN_MASK,
+ dw_wdt.regs + WDOG_CONTROL_REG_OFFSET);
+ }
+
+ dw_wdt_set_next_heartbeat();
+
+ spin_unlock(&dw_wdt.lock);
+
+ return nonseekable_open(inode, filp);
+}
+
+ssize_t dw_wdt_write(struct file *filp, const char __user *buf, size_t len,
+ loff_t *offset)
+{
+ if (!len)
+ return 0;
+
+ if (!nowayout) {
+ size_t i;
+
+ dw_wdt.expect_close = 0;
+
+ for (i = 0; i < len; ++i) {
+ char c;
+
+ if (get_user(c, buf + i))
+ return -EFAULT;
+
+ if (c == 'V') {
+ dw_wdt.expect_close = 1;
+ break;
+ }
+ }
+ }
+
+ dw_wdt_set_next_heartbeat();
+ mod_timer(&dw_wdt.timer, jiffies + WDT_TIMEOUT);
+
+ return len;
+}
+
+static u32 dw_wdt_time_left(void)
+{
+ return readl(dw_wdt.regs + WDOG_CURRENT_COUNT_REG_OFFSET) /
+ dw_wdt.clk_rate;
+}
+
+static const struct watchdog_info dw_wdt_ident = {
+ .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT |
+ WDIOF_MAGICCLOSE,
+ .identity = "Synopsys DesignWare Watchdog",
+};
+
+static long dw_wdt_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
+{
+ unsigned long val;
+ int timeout;
+
+ switch (cmd) {
+ case WDIOC_GETSUPPORT:
+ return copy_to_user((struct watchdog_info *)arg, &dw_wdt_ident,
+ sizeof(dw_wdt_ident)) ? -EFAULT : 0;
+
+ case WDIOC_GETSTATUS:
+ case WDIOC_GETBOOTSTATUS:
+ return put_user(0, (int *)arg);
+
+ case WDIOC_KEEPALIVE:
+ dw_wdt_set_next_heartbeat();
+ return 0;
+
+ case WDIOC_SETTIMEOUT:
+ if (get_user(val, (int __user *)arg))
+ return -EFAULT;
+ timeout = dw_wdt_set_top(val);
+ return put_user(timeout , (int __user *)arg);
+
+ case WDIOC_GETTIMEOUT:
+ return put_user(dw_wdt_get_top(), (int __user *)arg);
+
+ case WDIOC_GETTIMELEFT:
+ /* Get the time left until expiry. */
+ if (get_user(val, (int __user *)arg))
+ return -EFAULT;
+ return put_user(dw_wdt_time_left(), (int __user *)arg);
+
+ default:
+ return -ENOTTY;
+ }
+}
+
+static int dw_wdt_release(struct inode *inode, struct file *filp)
+{
+ clear_bit(0, &dw_wdt.in_use);
+
+ if (!dw_wdt.expect_close) {
+ del_timer(&dw_wdt.timer);
+
+ if (!nowayout)
+ pr_crit("unexpected close, system will reboot soon\n");
+ else
+ pr_crit("watchdog cannot be disabled, system will reboot soon\n");
+ }
+
+ dw_wdt.expect_close = 0;
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int dw_wdt_suspend(struct device *dev)
+{
+ clk_disable(dw_wdt.clk);
+
+ return 0;
+}
+
+static int dw_wdt_resume(struct device *dev)
+{
+ int err = clk_enable(dw_wdt.clk);
+
+ if (err)
+ return err;
+
+ dw_wdt_keepalive();
+
+ return 0;
+}
+
+static const struct dev_pm_ops dw_wdt_pm_ops = {
+ .suspend = dw_wdt_suspend,
+ .resume = dw_wdt_resume,
+};
+#endif /* CONFIG_PM */
+
+static const struct file_operations wdt_fops = {
+ .owner = THIS_MODULE,
+ .llseek = no_llseek,
+ .open = dw_wdt_open,
+ .write = dw_wdt_write,
+ .unlocked_ioctl = dw_wdt_ioctl,
+ .release = dw_wdt_release
+};
+
+static struct miscdevice dw_wdt_miscdev = {
+ .fops = &wdt_fops,
+ .name = "watchdog",
+ .minor = WATCHDOG_MINOR,
+};
+
+static int __devinit dw_wdt_drv_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct resource *mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ struct dw_wdt_platform_data *pdata = pdev->dev.platform_data;
+
+ if (!mem)
+ return -EINVAL;
+
+ if (!devm_request_mem_region(&pdev->dev, mem->start, resource_size(mem),
+ "dw_wdt"))
+ return -ENOMEM;
+
+ dw_wdt.regs = devm_ioremap(&pdev->dev, mem->start,
+ resource_size(mem));
+ if (!dw_wdt.regs)
+ return -ENOMEM;
+
+ dw_wdt.clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(dw_wdt.clk))
+ return -ENODEV;
+
+ ret = clk_enable(dw_wdt.clk);
+ if (ret)
+ goto out_put_clk;
+
+ /*
+ * The timeout period of the watchdog is derived from the input clock
+ * frequency. For platforms that don't have a clk for the watchdog,
+ * they can specify the WDT clock rate through the clk_rate field of
+ * the struct dw_wdt_platform_data platform data.
+ */
+ if (pdata && pdata->clk_rate > 0)
+ dw_wdt.clk_rate = pdata->clk_rate;
+ else
+ dw_wdt.clk_rate = clk_get_rate(dw_wdt.clk);
+
+ if (!dw_wdt.clk_rate) {
+ dev_err(&pdev->dev, "no clk rate defined for watchdog, cannot enable\n");
+ ret = -EINVAL;
+ goto out_disable_clk;
+ }
+
+ spin_lock_init(&dw_wdt.lock);
+
+ ret = misc_register(&dw_wdt_miscdev);
+ if (ret)
+ goto out_put_clk;
+
+ dw_wdt_set_next_heartbeat();
+ setup_timer(&dw_wdt.timer, dw_wdt_ping, 0);
+ mod_timer(&dw_wdt.timer, jiffies + WDT_TIMEOUT);
+
+ return 0;
+
+out_disable_clk:
+ clk_disable(dw_wdt.clk);
+out_put_clk:
+ clk_put(dw_wdt.clk);
+
+ return ret;
+}
+
+static int __devexit dw_wdt_drv_remove(struct platform_device *pdev)
+{
+ misc_deregister(&dw_wdt_miscdev);
+
+ clk_disable(dw_wdt.clk);
+ clk_put(dw_wdt.clk);
+
+ return 0;
+}
+
+static struct platform_driver dw_wdt_driver = {
+ .probe = dw_wdt_drv_probe,
+ .remove = __devexit_p(dw_wdt_drv_remove),
+ .driver = {
+ .name = "dw_wdt",
+ .owner = THIS_MODULE,
+#ifdef CONFIG_PM
+ .pm = &dw_wdt_pm_ops,
+#endif /* CONFIG_PM */
+ },
+};
+
+static int __init dw_wdt_watchdog_init(void)
+{
+ return platform_driver_register(&dw_wdt_driver);
+}
+module_init(dw_wdt_watchdog_init);
+
+static void __exit dw_wdt_watchdog_exit(void)
+{
+ platform_driver_unregister(&dw_wdt_driver);
+}
+module_exit(dw_wdt_watchdog_exit);
+
+MODULE_AUTHOR("Jamie Iles");
+MODULE_DESCRIPTION("Synopsys DesignWare Watchdog Driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
diff --git a/include/linux/platform_data/dw_wdt.h b/include/linux/platform_data/dw_wdt.h
new file mode 100644
index 0000000..0af10ef
--- /dev/null
+++ b/include/linux/platform_data/dw_wdt.h
@@ -0,0 +1,27 @@
+/*
+ * Copyright 2010 Picochip Ltd., Jamie Iles
+ * http://www.picochip.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * This file implements a driver for the Synopsys DesignWare watchdog device
+ * in the many ARM subsystems. The watchdog has 16 different timeout periods
+ * and these are a function of the input clock frequency.
+ */
+#ifndef __DW_WDT_H__
+#define __DW_WDT_H__
+
+/**
+ * struct dw_wdt_platform_data - DesignWare WDT platform data
+ *
+ * @clk_rate: The frequency (HZ) at which the watchdog is driven. The timeout
+ * periods are derived from this frequency.
+ */
+struct dw_wdt_platform_data {
+ unsigned long clk_rate;
+};
+
+#endif /* __DW_WDT_H__ */
--
1.7.3.4
^ permalink raw reply related
* [PATCH v5 3/3] ahci_platforms: add support for CNS3xxx SoC devices
From: Lin Mac @ 2011-01-10 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB0373E1D99B@dbde02.ent.ti.com>
2011/1/10 Basheer, Mansoor Ahamed <mansoor.ahamed@ti.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.
>>
>
> Is this issue only with your ahci platform controller? I came across another
> thread here,
>
> http://www.spinics.net/lists/linux-ide/msg39865.html
Thanks for mentioning this.
They do look alike. I'll confirm with them.
> Also, the ahci platform controller on Texas Instruments OMAP L138 platform
> behaves in a similar fashion.
>
> Currently I see only Cavium Networks, Faraday and TI using ahci platform
> controller and all 3 facing same issue.
>
> Hence, should we fix this in ahci_platform.c conditionally using platform data,
> otherwise we will end-up adding file for every platform (just for one
> function).
We can add quirk in ahci platform data, just like sdhci_pltfm.c and
sdhci_cns3xxx.c.
Thus, in cns3xxx's case, all we need is to include
<linux/ahci_platform.h>, and all the SoC specific code could exist in
arch folder, similar to my v1 patchset.
Best Regards,
Mac Lin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libahci-Fixup-for-softwreset-failures-with-direct-co.patch
Type: text/x-diff
Size: 1002 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110110/acb4bf7f/attachment.bin>
^ permalink raw reply
* [PATCH] mmc, ARM: Add zboot from MMC support for SuperH Mobile ARM
From: Paul Mundt @ 2011-01-10 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1e9db480d82d1804930ddcc7bb0db02@rootnode.net>
On Mon, Jan 10, 2011 at 10:10:19AM +0000, Pawel Moll wrote:
> On Mon, 10 Jan 2011 07:50:42 +0900, Simon Horman <horms@verge.net.au>
> wrote:
> >>> Documentation/arm/SH-Mobile/Makefile | 8 +
> >>> Documentation/arm/SH-Mobile/vrl4.c | 169
> >>+++++++++++++++++++++
> >>How about putting those two into "tools" (in particular "tools/arm")
> >>instead of "Documentation"?
> >>Just a thought... ;-)
> >
> >Thats fine by me except that tools/arm doesn't exist yet.
> >It would be good to get some consensus before creating it.
>
> I think there is consensus regarding "tools" as a place for user-space
> tools - eg. perf tools used to live in "Documentation/..." and then were
> moved to "tools/perf".
>
> Now, whether your stuff should be in "tools/SH-Mobile" or
> "tools/arm/SH-Mobile", I have no opinion ;-)
>
I agree that this is a worthwhile direction to move to, but we're a long
way from a consensus. x86 has traditionally littered scripts/ and others
have sunk to arch/<foo>/tools hostprogs abuse and so forth. perf is a bit
of a special case in that it's fairly architecture agnostic.
^ permalink raw reply
* AT91: Fix power-saving in idle-mode on 926T processors
From: Peter Korsgaard @ 2011-01-10 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294673540l.26200l.0l@i-dmzi_al.realan.de>
>>>>> "Anders" == Anders Larsen <al@alarsen.net> writes:
Hi,
>> Is there a known interaction with this and the JTAG controller?
Anders> indeed there is - disabling the processor clock blocks JTAG debugging.
Ok - And apparently it completely blocks the JTAG controller, so you
cannot even put it in bypass mode and access other devices on the same
JTAG chain.
>> I haven't had time to look closer into it yet, but with this applied
>> I can no longer access an Altera FPGA on a chain shared with a 9G45
>> through Quartus.
Anders> If you boot with the kernel parameter "nohlt", arch_idle() is
Anders> not called, and JTAG should work again (but of course power
Anders> consumption will be substantially higher).
Anders> This was noted by Uwe Kleine-K?nig in
Anders> https://lkml.org/lkml/2010/5/5/342
Thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* AT91: Fix power-saving in idle-mode on 926T processors
From: Anders Larsen @ 2011-01-10 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimGTVybe4LmspxWj6vkM_zNnPcaUbk6sqvpJ032@mail.gmail.com>
Hej Peter,
On 2011-01-10 16:05:36, Peter Korsgaard wrote:
> On Thu, Oct 7, 2010 at 9:44 PM, Anders Larsen <al@alarsen.net> wrote:
> > According to Atmel, their 926T processors (AT91 post RM9200) requires
> > 'Wait for Interrupt' mode be entered right after disabling the processor clock
> > in order to minimise current consumption when idle, so do both provided we're
> > not running on a 920T (an RM9200).
>
> Is there a known interaction with this and the JTAG controller?
indeed there is - disabling the processor clock blocks JTAG debugging.
> I haven't had time to look closer into it yet, but with this applied
> I can no longer access an Altera FPGA on a chain shared with a 9G45
> through Quartus.
If you boot with the kernel parameter "nohlt", arch_idle() is not called,
and JTAG should work again (but of course power consumption will be
substantially higher).
This was noted by Uwe Kleine-K?nig in https://lkml.org/lkml/2010/5/5/342
Cheers
Anders
^ permalink raw reply
* AT91: Fix power-saving in idle-mode on 926T processors
From: Peter Korsgaard @ 2011-01-10 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101007194415.GA24709@alarsen.net>
On Thu, Oct 7, 2010 at 9:44 PM, Anders Larsen <al@alarsen.net> wrote:
> According to Atmel, their 926T processors (AT91 post RM9200) requires
> 'Wait for Interrupt' mode be entered right after disabling the processor clock
> in order to minimise current consumption when idle, so do both provided we're
> not running on a 920T (an RM9200).
>
> Furthermore, get rid of the #ifndef CONFIG_DEBUG_KERNEL, since arch_idle()
> can be turned off completely with the kernel parameter 'nohlt'.
>
> Signed-off-by: Anders Larsen <al@alarsen.net>
> Cc: Andrew Victor <avictor.za@gmail.com>
Is there a known interaction with this and the JTAG controller? I
haven't had time to look closer into it yet, but with this applied I
can no longer access an Altera FPGA on a chain shared with a 9G45
through Quartus.
> +++ b/arch/arm/mach-at91/include/mach/system.h
> @@ -28,17 +28,16 @@
>
> ?static inline void arch_idle(void)
> ?{
> -#ifndef CONFIG_DEBUG_KERNEL
> ? ? ? ?/*
> ? ? ? ? * Disable the processor clock. ?The processor will be automatically
> ? ? ? ? * re-enabled by an interrupt or by a reset.
> ? ? ? ? */
> ? ? ? ?at91_sys_write(AT91_PMC_SCDR, AT91_PMC_PCK);
> -#else
> +#ifndef CONFIG_CPU_ARM920T
> ? ? ? ?/*
> ? ? ? ? * Set the processor (CP15) into 'Wait for Interrupt' mode.
> - ? ? ? ?* Unlike disabling the processor clock via the PMC (above)
> - ? ? ? ?* ?this allows the processor to be woken via JTAG.
> + ? ? ? ?* Post-RM9200 processors need this in conjunction with the above
> + ? ? ? ?* to save power when idle.
> ? ? ? ? */
> ? ? ? ?cpu_do_idle();
> ?#endif
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH v4 3/3] omap3: beaglexm: fix power on of DVI
From: Nishanth Menon @ 2011-01-10 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.1.10.1101101445080.18906@esdhcp041196.research.nokia.com>
Aaro Koskinen had written, on 01/10/2011 06:51 AM, the following:
[..]
>> + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
>> + gpio_request(gpio + 1, "nDVI_PWR_EN");
>> + gpio_direction_output(gpio + 1, 0);
>> + gpio_request(gpio + 2, "DVI_LDO_EN");
>> + gpio_direction_output(gpio + 2, 1);
>
> FYI, gpiolib provides gpio_request_one() and gpio_request_array() calls
> which make code simpler. I think any new code should use those _and_
> do proper error checking.
Thanks for pointing this out. Funny why it is in
include/asm-generic/gpio.h instead of in include/linux/gpio.h
considering it implemented in drivers/gpio/gpiolib.c :(
Am I right in understanding that you are mentioning about DVI gpios
alone? in that case, the LDO gpio is used for other functions as well in
addition to driving DVI. I suppose we dont want to loose that function
because dvi pwr_en gpio failed.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v4 1/3] omap3: beaglexm: fix EHCI power up GPIO dir
From: Nishanth Menon @ 2011-01-10 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.1.10.1101101442460.18906@esdhcp041196.research.nokia.com>
Aaro Koskinen had written, on 01/10/2011 06:44 AM, the following:
> Hi,
>
> On Fri, 7 Jan 2011, Nishanth Menon wrote:
>> From: Koen Kooi <koen@beagleboard.org>
>>
>> EHCI enable power pin is inverted (active high) in comparison
>> to vanilla beagle which is active low. Handle this case conditionally.
>>
>> Without this fix, Beagle XM 4 port EHCI will not function and no
>> networking will be available
>>
>> [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 | 9 ++++++++-
>> 1 files changed, 8 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
>> b/arch/arm/mach-omap2/board-omap3beagle.c
>> index 6c12760..1b5aa7a 100644
>> --- a/arch/arm/mach-omap2/board-omap3beagle.c
>> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
>> @@ -297,9 +297,16 @@ static int beagle_twl_gpio_setup(struct device *dev,
>> gpio_request(gpio + 1, "EHCI_nOC");
>> gpio_direction_input(gpio + 1);
>>
>> - /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active
>> low) */
>> + /*
>> + * TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
>> + * high / others active low)
>> + */
>> gpio_request(gpio + TWL4030_GPIO_MAX, "nEN_USB_PWR");
>> gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
>
> This call should be deleted.
yikes. yep. thanks for catching.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [patch 2/5] ulpi: handle ULPI_OTG_CTRL_CHRGVBUS
From: Arnaud Patard (Rtp) @ 2011-01-10 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2B0D7E.3080801@compulab.co.il>
Igor Grinberg <grinberg@compulab.co.il> writes:
> Hi Arnaud,
Hi,
>
>
> Can you, please, send patches inline and not as attachments next time?
> It is very inconvenient to review and comment on attached patches.
This patch a quick rewrite&test. It was more meant to understand if the
direction was right rather than a formal submission. (I use quilt to
send patches and not my mailer). There are some comment in the code
needed and I've not put them.
> Comments below.
>
> On 01/07/11 11:02, Arnaud Patard (Rtp) wrote:
>> Hi
>>
>> Igor Grinberg <grinberg@compulab.co.il> writes:
>> [...]
>>> Thanks for the information. Now I am finally getting the picture of what's is
>>> going on there...
>>>
>>>> On the Smartbook at least both USB host ports (H1 and H2) on the board
>>>> (one port each) are connected directly to 4-port USB hubs (SMSC2514).
>>>> We don't have anything on there except that connection: the hub should
>>>> handle VBUS properly. Both ports use an SMSC3317 (just a 3311 with a
>>>> built in 3.3V supply so the id and behavior should be identical).
>>> OK, so the SMSC331x ulpi transceiver is connected to the SMSC2514 usb hub,
>>> so all the peripheral devices (ethernet/wifi/bt/hid) are connected to the
>>> downstream ports of that hub and thus get their Vbus as expected. This is fine.
>>>
>>>> On the Smarttop H1 is connected to a 4-port USB hub (Terminus FE1.1)
>>>> with the same configuration. Same PHY. The DR port is connected
>>>> directly to an ASIX ethernet controller. VBUS seems routed to a test
>>>> point.
>>>>
>>>> I'm curious exactly what the real problem here is: that VBUS is
>>>> basically not being handled correctly? It should be driven or not? I'm
>>>> not entirely familiar with the specification.
>>> SMSC2514 usb hub will not provide power to its D+ and D- pull-up resistors
>>> until it detects a Vbus enabled on the upstream port. This is totally fine.
>>>
>>> SMSC331x ulpi transceiver does not have either an integrated Vbus switch or
>>> an integrated charge pump - this means that it cannot provide a Vbus to the hub.
>>>
>>> The hub in its turn does not power the pull-up resistors and peripheral devices
>>> are not being connected to the usb subsystem.
>>>
>>> With this patch applied, SMSC331x ulpi transceiver issues an SRP pulses on the Vbus
>>> and hub senses that there is something that looks like Vbus and then enables the
>>> pull-up resistors -> peripheral devices are being connected to the usb subsystem.
>>> This behavior violates the ULPI (and mostly certain OTG and may be also USB 2.0)
>>> specification and SMSC2514 usb hub datasheet.
>>>
>>> According to the SMSC2514 usb hub datasheet, VBUS_DET pin has to be connected
>>> to a valid Vbus from the upstream port, but SMSC331x does not provide this Vbus.
>>> This means that you should have add a Vbus switch or a charge pump to the
>>> VBUS_DET pin of the usb hub and provide means (like GPIO) to enable/disable that
>>> switch or charge pump.
>>> This is h/w design bug we are dealing with.
>>>
>>> The best solution to this would be to add a missing h/w component.
>>> Now, I understand that it can be kind a problematic ;)
>>> But, we cannot violate the ULPI spec and the generic driver to workaround
>>> some h/w problem that is existing in some specific configuration and hopefully will
>>> be fixed in the next h/w revisions. Therefore, as I said before, this patch is NAK.
>>>
>>> What we can do is:
>>> 1) implement the int (*start_srp)(struct otg_transceiver *otg);
>>> method as defined by the ULPI spec.
>>>
>>> 2) and then add a call (along with huge comment explaining this workaround)
>>> to otg_start_srp(). I'd recommend to restrict this call to that specific board somehow,
>>> but it is up to Sascha to decide where to put it.
>> What about the following patch ?
>> ulpi: provide start_srp
>>
>> Add support for setting CHRGVBUS thanks to start_srp and use it
>> to workaround a hardware bug on efika mx/sb boards.
>> See http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/037341.html
>>
>> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
>> Index: linux-2.6-submit/drivers/usb/otg/ulpi.c
>> ===================================================================
>> --- linux-2.6-submit.orig/drivers/usb/otg/ulpi.c 2011-01-04 17:12:26.000000000 +0100
>> +++ linux-2.6-submit/drivers/usb/otg/ulpi.c 2011-01-06 14:44:50.000000000 +0100
>> @@ -247,6 +247,14 @@
>> return otg_io_write(otg, flags, ULPI_OTG_CTRL);
>> }
>>
>> +static int ulpi_start_srp(struct otg_transceiver *otg, bool on)
>> +{
>> + unsigned int flags = otg_io_read(otg, ULPI_OTG_CTRL);
>> +
>> + flags |= ULPI_OTG_CTRL_CHRGVBUS;
>> + return otg_io_write(otg, flags, ULPI_OTG_CTRL);
>> +}
>> +
>
> I went through the OTG spec. and found that there are much more things
> should be done for the start_srp() function to be implemented properly.
> For example, it says that we should make sure that the Vbus is discharged
> (means, the previous session has finished) before attempting to start a new
> session, but that is only a half of the problem. The real problem for you, is that
> the duration of the SRP should be no more then 100ms.
oops. That's really annoying. (fwiw, I think that original code from fsl
doesn't take care of that 100ms delay otherwise I guess I would have
detected it too).
> This means that my proposal under 1) is not good for you, sorry...
>
>> struct otg_transceiver *
>> otg_ulpi_create(struct otg_io_access_ops *ops,
>> unsigned int flags)
>> @@ -263,6 +271,7 @@
>> otg->init = ulpi_init;
>> otg->set_host = ulpi_set_host;
>> otg->set_vbus = ulpi_set_vbus;
>> + otg->start_srp = ulpi_start_srp;
>>
>> return otg;
>> }
>> Index: linux-2.6-submit/drivers/usb/host/ehci-mxc.c
>> ===================================================================
>> --- linux-2.6-submit.orig/drivers/usb/host/ehci-mxc.c 2011-01-06 14:45:14.000000000 +0100
>> +++ linux-2.6-submit/drivers/usb/host/ehci-mxc.c 2011-01-06 15:48:16.000000000 +0100
>> @@ -25,6 +25,8 @@
>>
>> #include <mach/mxc_ehci.h>
>>
>> +#include <asm/mach-types.h>
>> +
>> #define ULPI_VIEWPORT_OFFSET 0x170
>>
>> struct ehci_mxc_priv {
>> @@ -239,6 +241,13 @@
>> dev_err(dev, "unable to enable vbus on transceiver\n");
>> goto err_add;
>> }
>> + if (machine_is_mx51_efikamx() || machine_is_mx51_efikasb()) {
>> + ret = otg_start_srp(pdata->otg);
>> + if (ret) {
>> + dev_err(dev, "unable to start srp\n");
>> + goto err_add;
>> + }
>> + }
>
> In light of the problem described above, here you will need to write directly
> to the view port instead of calling the otg_start_srp() function.
ok. I don't think it's a problem. Looks otg_io_(read|write) are
available here.
>
> I'd recommend to move this to the machine (board) specific code.
> May be to platform init (pdata->init) call back?
oh, no. I've put this call in this place for some good reasons. This
trick is working only if it's done _after_ add_hcd. Any other place
won't work. For instance, pdata->init is meant to be called before
mxc_initialise_usb_hw iirc which is _before_ add_hcd.
>
> IMHO, the explanation of the h/w bug workaround in the commit message
> is not enough - in-code comment regarding the bug workaround should be added.
I know. As I said this patch was not the final submission. It was
probably not clear enough.
Arnaud
^ permalink raw reply
* [PATCH 2/3] omap3: igep3: Fix IGEP module second MMC channel power supply.
From: Marc Zyngier @ 2011-01-10 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294665974-10590-3-git-send-email-eballetbo@gmail.com>
On Mon, 10 Jan 2011 14:26:13 +0100, Enric Balletbo i Serra
<eballetbo@gmail.com> wrote:
> The second MMC channel (used by the WLAN/BT module) is not linked to
> power regulator. This causes the WLAN/BT module to fail being detected
if
> CONFIG_REGULATOR_DUMMY is not set.
>
> This patch adds the two regulators that actually feed the WLAN/BT module
> (1v8 from the TWL4030 VIO LDO, and a fixed 3v3). With that patch, the
> second channel is properly detected.
>
> Also change vmmc1 to use symbolic names instead of direct device
> reference.
>
> Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Acked-by: Marc Zyngier <maz@misterjones.org>
--
Who you jivin' with that Cosmik Debris?
^ permalink raw reply
* [PATCH 2/3] perf: add OMAP support for the new power events
From: Thomas Renninger @ 2011-01-10 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=3pek3+Vv+c1TCxBH2RJcoSXq8TL8CyK9ABMeu@mail.gmail.com>
On Wednesday 05 January 2011 12:05:18 Jean Pihet wrote:
> Hi Paul,
>
> On Tue, Jan 4, 2011 at 7:48 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > Hello Jean,
> >
> > On Tue, 4 Jan 2011, jean.pihet at newoldbits.com wrote:
> >
> >> From: Jean Pihet <j-pihet@ti.com>
> >>
> >> The patch adds the new power management trace points for
> >> the OMAP architecture.
> >>
> >> The trace points are for:
> >> - default idle handler. Since the cpuidle framework is
> >> instrumented in the generic way there is no need to
> >> add trace points in the OMAP specific cpuidle handler;
> >> - cpufreq (DVFS),
> >> - clocks changes (enable, disable, set_rate),
> >
> > A question about these. Are these only meant to track calls to these
> > functions from outside the clock code? Or meant to track actual hardware
> > clock changes?
> The former: this is used to track the clock requests from outside the
> clock framework.
>
> > If the latter, then it might make sense to put these
> > trace points into the functions that actually change the hardware
> > registers, e.g., omap2_dflt_clk_{enable,disable}(), etc., since a
> > clk_enable() on a leaf clock may result in many internal system clocks
> > being enabled up the clock tree.
> I agree with you it is better to track the actual clock changes instead.
> I propose to move the tracepoints to omap2_clk_{enable...} which
> enables all the clocks irrespectively of the installed handler.
> Note about the clock handlers: omap2_dflt_clk_enable happens to be the
> handler for all controllable clocks but could that change in the
> future?
Looks like there is cpuidle34xx using cpuidle framework on specific boards
only.
And pm34xx.c and others override pm_idle and use the same low level
functions to reduce power consumption as cpuidle34xx.
Ideally pm34xx.c (and others) would not override pm_idle, but register as
a cpuidle driver. Then the idle events would be tracked by the
cpuidle subsystem automatically (with my latest patches).
But this would be a more intrusive change (are there efforts to do that?).
Even if it should happen at some point, adding some additional events for
people to better debug/monitor the stuff now does not hurt.
Thomas
^ permalink raw reply
* [PATCH] watchdog: add support for the Synopsys DesignWare WDT
From: Wim Van Sebroeck @ 2011-01-10 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294656906-24239-1-git-send-email-jamie@jamieiles.com>
Hi Jamie,
> +config DW_WATCHDOG
> + tristate "Synopsys DesignWare watchdog"
> + select WATCHDOG_NOWAYOUT
I overlooked something: If your watchdog driver cannot be stopped once it's started,
then it's best to add a comment about that in your code. Selecting the WATCHDOG_NOWAYOUT
feauture (which is overall for all drivers) is not the way to do it properly.
What you should do is add a timer that ticks the watchdog if /dev/watchdog is closed.
Examples for this functionality can be found in at91sam9_wdt.c, pika_wdt.c, ...
Sorry,
Wim.
^ permalink raw reply
* [PATCH] ARM: sched_clock: improve mult/shift accuracy with high frequency clocks
From: Nicolas Pitre @ 2011-01-10 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110110105120.GA12552@n2100.arm.linux.org.uk>
On Mon, 10 Jan 2011, Russell King - ARM Linux wrote:
> With a 32-bit or smaller cyclecounter, as 32-bit x 32-bit can never
> overflow a 64-bit destination, so if anything zero should be passed in
> this case.
That's the alternative suggestion I made as well.
Nicolas
^ permalink raw reply
* [patch 2/5] ulpi: handle ULPI_OTG_CTRL_CHRGVBUS
From: Igor Grinberg @ 2011-01-10 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87hbdl6q96.fsf@lechat.rtp-net.org>
Hi Arnaud,
Can you, please, send patches inline and not as attachments next time?
It is very inconvenient to review and comment on attached patches.
Comments below.
On 01/07/11 11:02, Arnaud Patard (Rtp) wrote:
> Hi
>
> Igor Grinberg <grinberg@compulab.co.il> writes:
> [...]
>> Thanks for the information. Now I am finally getting the picture of what's is
>> going on there...
>>
>>> On the Smartbook at least both USB host ports (H1 and H2) on the board
>>> (one port each) are connected directly to 4-port USB hubs (SMSC2514).
>>> We don't have anything on there except that connection: the hub should
>>> handle VBUS properly. Both ports use an SMSC3317 (just a 3311 with a
>>> built in 3.3V supply so the id and behavior should be identical).
>> OK, so the SMSC331x ulpi transceiver is connected to the SMSC2514 usb hub,
>> so all the peripheral devices (ethernet/wifi/bt/hid) are connected to the
>> downstream ports of that hub and thus get their Vbus as expected. This is fine.
>>
>>> On the Smarttop H1 is connected to a 4-port USB hub (Terminus FE1.1)
>>> with the same configuration. Same PHY. The DR port is connected
>>> directly to an ASIX ethernet controller. VBUS seems routed to a test
>>> point.
>>>
>>> I'm curious exactly what the real problem here is: that VBUS is
>>> basically not being handled correctly? It should be driven or not? I'm
>>> not entirely familiar with the specification.
>> SMSC2514 usb hub will not provide power to its D+ and D- pull-up resistors
>> until it detects a Vbus enabled on the upstream port. This is totally fine.
>>
>> SMSC331x ulpi transceiver does not have either an integrated Vbus switch or
>> an integrated charge pump - this means that it cannot provide a Vbus to the hub.
>>
>> The hub in its turn does not power the pull-up resistors and peripheral devices
>> are not being connected to the usb subsystem.
>>
>> With this patch applied, SMSC331x ulpi transceiver issues an SRP pulses on the Vbus
>> and hub senses that there is something that looks like Vbus and then enables the
>> pull-up resistors -> peripheral devices are being connected to the usb subsystem.
>> This behavior violates the ULPI (and mostly certain OTG and may be also USB 2.0)
>> specification and SMSC2514 usb hub datasheet.
>>
>> According to the SMSC2514 usb hub datasheet, VBUS_DET pin has to be connected
>> to a valid Vbus from the upstream port, but SMSC331x does not provide this Vbus.
>> This means that you should have add a Vbus switch or a charge pump to the
>> VBUS_DET pin of the usb hub and provide means (like GPIO) to enable/disable that
>> switch or charge pump.
>> This is h/w design bug we are dealing with.
>>
>> The best solution to this would be to add a missing h/w component.
>> Now, I understand that it can be kind a problematic ;)
>> But, we cannot violate the ULPI spec and the generic driver to workaround
>> some h/w problem that is existing in some specific configuration and hopefully will
>> be fixed in the next h/w revisions. Therefore, as I said before, this patch is NAK.
>>
>> What we can do is:
>> 1) implement the int (*start_srp)(struct otg_transceiver *otg);
>> method as defined by the ULPI spec.
>>
>> 2) and then add a call (along with huge comment explaining this workaround)
>> to otg_start_srp(). I'd recommend to restrict this call to that specific board somehow,
>> but it is up to Sascha to decide where to put it.
> What about the following patch ?
> ulpi: provide start_srp
>
> Add support for setting CHRGVBUS thanks to start_srp and use it
> to workaround a hardware bug on efika mx/sb boards.
> See http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/037341.html
>
> Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
> Index: linux-2.6-submit/drivers/usb/otg/ulpi.c
> ===================================================================
> --- linux-2.6-submit.orig/drivers/usb/otg/ulpi.c 2011-01-04 17:12:26.000000000 +0100
> +++ linux-2.6-submit/drivers/usb/otg/ulpi.c 2011-01-06 14:44:50.000000000 +0100
> @@ -247,6 +247,14 @@
> return otg_io_write(otg, flags, ULPI_OTG_CTRL);
> }
>
> +static int ulpi_start_srp(struct otg_transceiver *otg, bool on)
> +{
> + unsigned int flags = otg_io_read(otg, ULPI_OTG_CTRL);
> +
> + flags |= ULPI_OTG_CTRL_CHRGVBUS;
> + return otg_io_write(otg, flags, ULPI_OTG_CTRL);
> +}
> +
I went through the OTG spec. and found that there are much more things
should be done for the start_srp() function to be implemented properly.
For example, it says that we should make sure that the Vbus is discharged
(means, the previous session has finished) before attempting to start a new
session, but that is only a half of the problem. The real problem for you, is that
the duration of the SRP should be no more then 100ms.
This means that my proposal under 1) is not good for you, sorry...
> struct otg_transceiver *
> otg_ulpi_create(struct otg_io_access_ops *ops,
> unsigned int flags)
> @@ -263,6 +271,7 @@
> otg->init = ulpi_init;
> otg->set_host = ulpi_set_host;
> otg->set_vbus = ulpi_set_vbus;
> + otg->start_srp = ulpi_start_srp;
>
> return otg;
> }
> Index: linux-2.6-submit/drivers/usb/host/ehci-mxc.c
> ===================================================================
> --- linux-2.6-submit.orig/drivers/usb/host/ehci-mxc.c 2011-01-06 14:45:14.000000000 +0100
> +++ linux-2.6-submit/drivers/usb/host/ehci-mxc.c 2011-01-06 15:48:16.000000000 +0100
> @@ -25,6 +25,8 @@
>
> #include <mach/mxc_ehci.h>
>
> +#include <asm/mach-types.h>
> +
> #define ULPI_VIEWPORT_OFFSET 0x170
>
> struct ehci_mxc_priv {
> @@ -239,6 +241,13 @@
> dev_err(dev, "unable to enable vbus on transceiver\n");
> goto err_add;
> }
> + if (machine_is_mx51_efikamx() || machine_is_mx51_efikasb()) {
> + ret = otg_start_srp(pdata->otg);
> + if (ret) {
> + dev_err(dev, "unable to start srp\n");
> + goto err_add;
> + }
> + }
In light of the problem described above, here you will need to write directly
to the view port instead of calling the otg_start_srp() function.
I'd recommend to move this to the machine (board) specific code.
May be to platform init (pdata->init) call back?
IMHO, the explanation of the h/w bug workaround in the commit message
is not enough - in-code comment regarding the bug workaround should be added.
--
Regards,
Igor.
^ permalink raw reply
* [PATCH] omap3: clocks: Fix build error 'CK_3430ES2' undeclared here
From: Santosh Shilimkar @ 2011-01-10 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2B0B86.3010201@ti.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Anand Gadiyar
> Sent: Monday, January 10, 2011 7:07 PM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; tony at atomide.com; linux-arm-
> kernel at lists.infradead.org; Paul Walmsley
> Subject: Re: [PATCH] omap3: clocks: Fix build error 'CK_3430ES2'
> undeclared here
>
> On 1/10/2011 3:46 AM, Santosh Shilimkar wrote:
> > At latest mainline commit 0c21e3aaf6a, omap2plus build is broken.
> This
> > patch is trivial fix for the missed usb clock node for
> CK_3430ES2PLUS
> > flag update.
> >
> > CHK include/generated/compile.h
> > CC arch/arm/mach-omap2/clock3xxx_data.o
> > arch/arm/mach-omap2/clock3xxx_data.c:3289: error: 'CK_3430ES2'
> undeclared
> > here (not in a function)
> > make[1]: *** [arch/arm/mach-omap2/clock3xxx_data.o] Error 1
> > make: *** [arch/arm/mach-omap2] Error 2
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > ---
> > arch/arm/mach-omap2/clock3xxx_data.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-
> omap2/clock3xxx_data.c
> > index d3ab1c9..c54cc33 100644
> > --- a/arch/arm/mach-omap2/clock3xxx_data.c
> > +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> > @@ -3286,7 +3286,7 @@ static struct omap_clk omap3xxx_clks[] = {
> > CLK(NULL, "cpefuse_fck", &cpefuse_fck, CK_3430ES2PLUS
> | CK_AM35XX | CK_36XX),
> > CLK(NULL, "ts_fck", &ts_fck, CK_3430ES2PLUS |
CK_AM35XX
> | CK_36XX),
> > CLK(NULL, "usbtll_fck", &usbtll_fck, CK_3430ES2PLUS
> | CK_AM35XX | CK_36XX),
> > - CLK("ehci-omap.0", "usbtll_fck", &usbtll_fck,
> CK_3430ES2 | CK_AM35XX),
> > + CLK("ehci-omap.0", "usbtll_fck", &usbtll_fck,
> CK_3430ES2PLUS | CK_AM35XX),
>
> Was about to post something similar.
>
> Can you update this line to add CK_36XX as well. Without this, we
> won't be able to use
> the USBHOST on 36xx/37xx platforms.
>
> With this, feel free to add my
> Acked-by: Anand Gadiyar <gadiyar@ti.com>
>
ok. I can add CK_36XX and repost it with your ack
> - Anand
>
> > CLK("omap-mcbsp.1", "prcm_fck", &core_96m_fck,
> CK_3XXX),
> > CLK("omap-mcbsp.5", "prcm_fck", &core_96m_fck,
> CK_3XXX),
> > CLK(NULL, "core_96m_fck", &core_96m_fck, CK_3XXX),
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] omap3: clocks: Fix build error 'CK_3430ES2' undeclared here
From: Anand Gadiyar @ 2011-01-10 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294611373-1992-1-git-send-email-santosh.shilimkar@ti.com>
On 1/10/2011 3:46 AM, Santosh Shilimkar wrote:
> At latest mainline commit 0c21e3aaf6a, omap2plus build is broken. This
> patch is trivial fix for the missed usb clock node for CK_3430ES2PLUS
> flag update.
>
> CHK include/generated/compile.h
> CC arch/arm/mach-omap2/clock3xxx_data.o
> arch/arm/mach-omap2/clock3xxx_data.c:3289: error: 'CK_3430ES2' undeclared
> here (not in a function)
> make[1]: *** [arch/arm/mach-omap2/clock3xxx_data.o] Error 1
> make: *** [arch/arm/mach-omap2] Error 2
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/mach-omap2/clock3xxx_data.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
> index d3ab1c9..c54cc33 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3286,7 +3286,7 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK(NULL, "cpefuse_fck", &cpefuse_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "ts_fck", &ts_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "usbtll_fck", &usbtll_fck, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> - CLK("ehci-omap.0", "usbtll_fck", &usbtll_fck, CK_3430ES2 | CK_AM35XX),
> + CLK("ehci-omap.0", "usbtll_fck", &usbtll_fck, CK_3430ES2PLUS | CK_AM35XX),
Was about to post something similar.
Can you update this line to add CK_36XX as well. Without this, we won't be able to use
the USBHOST on 36xx/37xx platforms.
With this, feel free to add my
Acked-by: Anand Gadiyar <gadiyar@ti.com>
- Anand
> CLK("omap-mcbsp.1", "prcm_fck", &core_96m_fck, CK_3XXX),
> CLK("omap-mcbsp.5", "prcm_fck", &core_96m_fck, CK_3XXX),
> CLK(NULL, "core_96m_fck", &core_96m_fck, CK_3XXX),
^ permalink raw reply
* [PATCH v4] ARM: mxs: Change duart device to use amba-pl011
From: Wolfram Sang @ 2011-01-10 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294122052-18329-1-git-send-email-shawn.guo@freescale.com>
On Tue, Jan 04, 2011 at 02:20:52PM +0800, Shawn Guo wrote:
> The mxs duart is actually an amba-pl011 device. This commit changes
> the duart device code to dynamically allocate amba-pl011 device,
> so that drivers/serial/amba-pl011.c can be used on mxs.
>
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Tested-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110110/ea3d0e4f/attachment-0001.sig>
^ 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