Re: HTTP url not working
* Felipe Contreras <[EMAIL PROTECTED]> [081006 17:44]:
> Hi,
>
> The http url doesn't seem to be working anymore:
> http://www.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
>
> Can you?
> mv .git/post-update{.sample,}
Hmm, I just did a git-clone over http, and it worked fine.
Kevin just told me that the new pm branched don't show up over http,
but do appear over git. Trying to debug.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] MUSB: BULK request on different available endpoints
> -Original Message- > From: David Brownell [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 07, 2008 11:35 AM > To: Gupta, Ajay Kumar > Cc: [EMAIL PROTECTED]; linux-omap@vger.kernel.org; [EMAIL PROTECTED] > Subject: Re: [PATCH] MUSB: BULK request on different available endpoints > > On Monday 06 October 2008, Ajay Kumar Gupta wrote: > > + if (is_in) > > + musb->periodic[2 * ep->epnum - 2] = NULL; > > + else > > + musb->periodic[2 * ep->epnum - 1] = NULL; > > Can we use musb->in[], musb->out[] or somesuch? > Magic index math is kind of error prone ... Will submit separate patch for this fix. > > > > - case USB_ENDPOINT_XFER_CONTROL: > > - case USB_ENDPOINT_XFER_BULK: > > - /* fifo policy for these lists, except that NAKing > > - * should rotate a qh to the end (for fairness). > > - */ > > You just moved that bit earlier. Please just leave it > in the same place, so it's easier to tell what changed... When (qh->mux == 0) then qh freeing logic is same as for periodic transfers so I moved it above periodic case. > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3 NAND: move NAND_BLOCK_SIZE macro to board-3430sdp-flash.c
Moving NAND_BLOCK_SIZE definition to board-3430sdp-flash.c
Signed-off-by: Vimal Singh <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-3430sdp-flash.c |2 ++
include/linux/mtd/nand.h |2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-omap-2.6_27_08_2008/arch/arm/mach-omap2/board-3430sdp-flash.c
===
---
linux-omap-2.6_27_08_2008.orig/arch/arm/mach-omap2/board-3430sdp-flash.c
2008-10-07
11:28:53.0 +0530
+++
linux-omap-2.6_27_08_2008/arch/arm/mach-omap2/board-3430sdp-flash.c
2008-10-07
11:30:12.0 +0530
@@ -26,6 +26,8 @@
#include
#include
+#define NAND_BLOCK_SIZESZ_128K
+
static struct mtd_partition sdp_nor_partitions[] = {
/* bootloader (U-Boot, etc) in first sector */
{
Index: linux-omap-2.6_27_08_2008/include/linux/mtd/nand.h
===
--- linux-omap-2.6_27_08_2008.orig/include/linux/mtd/nand.h 2008-10-07
11:29:00.0 +0530
+++ linux-omap-2.6_27_08_2008/include/linux/mtd/nand.h 2008-10-07
11:29:56.0 +0530
@@ -45,7 +45,7 @@
*/
#define NAND_MAX_OOBSIZE 64
#define NAND_MAX_PAGESIZE 2048
-#define NAND_BLOCK_SIZESZ_128K
+
/*
* Constants for hardware specific CLE/ALE/NCE function
*
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MUSB: BULK request on different available endpoints
On Mon, Oct 6, 2008 at 10:42 PM, Ajay Kumar Gupta <[EMAIL PROTECTED]> wrote: > Fixes co-working issue of usb serial device with usb/net devices while > oter endpoints are free and can be used.This patch implements the policy > that if endpoint resources are available then different BULK request goes > to different endpoint otherwise they are multiplexed to one reserved > endpoint as currently done. Tested with current linux-omap git (plus other MUSB patches from Ajay). It works great for me. No problems running serial, wifi, and cameras at once off MUSB host. Thank you! - Nathan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MUSB: BULK request on different available endpoints
On Monday 06 October 2008, Ajay Kumar Gupta wrote: > + if (is_in) > + musb->periodic[2 * ep->epnum - 2] = NULL; > + else > + musb->periodic[2 * ep->epnum - 1] = NULL; Can we use musb->in[], musb->out[] or somesuch? Magic index math is kind of error prone ... > - case USB_ENDPOINT_XFER_CONTROL: > - case USB_ENDPOINT_XFER_BULK: > - /* fifo policy for these lists, except that NAKing > - * should rotate a qh to the end (for fairness). > - */ You just moved that bit earlier. Please just leave it in the same place, so it's easier to tell what changed... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MUSB: BULK request on different available endpoints
Fixes co-working issue of usb serial device with usb/net devices while
oter endpoints are free and can be used.This patch implements the policy
that if endpoint resources are available then different BULK request goes
to different endpoint otherwise they are multiplexed to one reserved
endpoint as currently done.
NAK limit scheme has to be added for multiplexed BULK request scenario
to avoid endpoint starvation due to usb/net devices.
musb->periodic[] flag setting is also updated.It use to set this flag for
an endpoint even when only rx or tx is used.Now flag setting is done on
rx/tx basis of an endpoint.
Signed-off-by: Ajay Kumar Gupta <[EMAIL PROTECTED]>
---
drivers/usb/musb/musb_host.c | 94 --
drivers/usb/musb/musb_host.h |1 +
2 files changed, 55 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 8b4be01..07652c1 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -379,27 +379,32 @@ musb_giveback(struct musb_qh *qh, struct urb *urb, int
status)
switch (qh->type) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ case USB_ENDPOINT_XFER_BULK:
+ /* fifo policy for these lists, except that NAKing
+* should rotate a qh to the end (for fairness).
+*/
+ if (qh->mux == 1) {
+ head = qh->ring.prev;
+ list_del(&qh->ring);
+ kfree(qh);
+ qh = first_qh(head);
+ break;
+ }
case USB_ENDPOINT_XFER_ISOC:
case USB_ENDPOINT_XFER_INT:
/* this is where periodic bandwidth should be
* de-allocated if it's tracked and allocated;
* and where we'd update the schedule tree...
*/
- musb->periodic[ep->epnum] = NULL;
+ if (is_in)
+ musb->periodic[2 * ep->epnum - 2] = NULL;
+ else
+ musb->periodic[2 * ep->epnum - 1] = NULL;
kfree(qh);
qh = NULL;
break;
- case USB_ENDPOINT_XFER_CONTROL:
- case USB_ENDPOINT_XFER_BULK:
- /* fifo policy for these lists, except that NAKing
-* should rotate a qh to the end (for fairness).
-*/
- head = qh->ring.prev;
- list_del(&qh->ring);
- kfree(qh);
- qh = first_qh(head);
- break;
}
}
return qh;
@@ -1672,22 +1677,9 @@ static int musb_schedule(
struct list_head*head = NULL;
/* use fixed hardware for control and bulk */
- switch (qh->type) {
- case USB_ENDPOINT_XFER_CONTROL:
+ if (qh->type == USB_ENDPOINT_XFER_CONTROL) {
head = &musb->control;
hw_ep = musb->control_ep;
- break;
- case USB_ENDPOINT_XFER_BULK:
- hw_ep = musb->bulk_ep;
- if (is_in)
- head = &musb->in_bulk;
- else
- head = &musb->out_bulk;
- break;
- }
- if (head) {
- idle = list_empty(head);
- list_add_tail(&qh->ring, head);
goto success;
}
@@ -1715,7 +1707,8 @@ static int musb_schedule(
for (epnum = 1; epnum < musb->nr_endpoints; epnum++) {
int diff;
- if (musb->periodic[epnum])
+ if ((is_in && musb->periodic[2 * epnum - 2]) ||
+ (!is_in && musb->periodic[2 * epnum - 1]))
continue;
hw_ep = &musb->endpoints[epnum];
if (hw_ep == musb->bulk_ep)
@@ -1726,19 +1719,36 @@ static int musb_schedule(
else
diff = hw_ep->max_packet_sz_tx - qh->maxpacket;
- if (diff > 0 && best_diff > diff) {
+ if (diff >= 0 && best_diff > diff) {
best_diff = diff;
best_end = epnum;
}
}
- if (best_end < 0)
+ /* use bulk reserved ep1 if no other ep is free*/
+ if (best_end < 0 && qh->type == USB_ENDPOINT_XFER_BULK) {
+ hw_ep = musb->bulk_ep;
+ if (is_in)
+ head = &musb->in_bulk;
+ else
+ head = &musb->out_bulk;
+ goto success;
+ } else if (best_end < 0)
return -ENOSPC;
idle = 1;
+ qh->mux = 0;
RE: [RESENDING][PATCH 1/2]OMAP3 NAND: Add NAND support on OMAP3430
On Modday 06 October 2008, Devid Brownell wrote: > On Monday 06 October 2008, Tony Lindgren wrote: > > > --- linux-omap-2.6_27_08_2008.orig/include/linux/mtd/nand.h > > > +++ linux-omap-2.6_27_08_2008/include/linux/mtd/nand.h > > > @@ -45,7 +45,7 @@ > > > */ > > > #define NAND_MAX_OOBSIZE 64 > > > #define NAND_MAX_PAGESIZE2048 > > > - > > > +#define NAND_BLOCK_SIZE SZ_128K > > > /* > > This is specific to 3430 SDP though ... there are plenty > of other NAND block sizes in the world. > > Suggest moving this definition to board-3430sdp-flash.c > where it's relevant. Agree. I will send a patch to move it. ... vimal-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: android on omap
twebb, As far as I know Android root file system cannot reside on jffs2 partition as jffs2 does not have support for memory mapped IO. One workaround may be to create an EXT2 image for the Android root FS and place it in the jffs2 partition and try mounting it as loop device. A brief procedure can be as shown here: 1. create EXT2/EXT3 image for android root FS 2. store the image under the jffs2 partition in NAND (booting out of NFS, mount MTD partition and place the image file) 3. Boot your device using NFS or ramdisk 4. After boot completes, mount the EXT2/EXT3 image as loop device 5. chroot into that mounted directory and run android. NB: i've tried the above steps for an SD card formatted as FAT but never tried this for NAND/jffs2 combination. Warm Regards, Anil On Tue, Oct 7, 2008 at 3:11 AM, twebb <[EMAIL PROTECTED]> wrote: > > > Does the root file system reside on NFS? Have you enabled "Networking" while > > configuring the kernel? > > > > Anil, > I've now moved filesystem to target (jffs2). Things are a little > better, and different. Using logcat, I'm now seeing dalvikvm errors > and warnings as shown below. It's particularly odd since I wasn't > seeing this error when rootfs mounted via NFS. Any ideas? > > I really appreciate your input. > > Thanks, > twebb > > D/dalvikvm( 483): DexOpt: --- BEGIN 'core.jar' (bootstrap=1) > --- > E/dalvikvm( 501): unable to mmap DEX cache: Invalid > argument > E/dalvikvm( 501): Optimization > failed > D/dalvikvm( 483): DexOpt: waiting for verify+opt, > pid=501 > W/dalvikvm( 483): DexOpt: --- END 'core.jar' --- status=0xff00, > process failed > E/dalvikvm( 483): Unable to extract+optimize DEX from '/system/ > framework/ > core.jar' > D/dalvikvm( 483): Failed on '/system/framework/ > core.jar' (boot=1) > D/dalvikvm( 483): VM cleaning > up > D/dalvikvm( 483): LinearAlloc 0x0 used 4100 of 4194304 > (0%) > W/dalvikvm( 483): JNI_CreateJavaVM > failed > E/AndroidRuntime( 483): JNI_CreateJavaVM > failed > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB serial devices not working on linux-omap musb.
Thanks for your comments. > On Wednesday 01 October 2008, Gupta, Ajay Kumar wrote: > > Currently all the BULK request are multiplexed on one hardware endpoint > > and when a wifi or eth device is in use they never release BULK hardware > > endpoint so that it can be used by other devices. This causes failure of > > serial device when any of wifi/eth is in use. > > Any driver that keeps a bulk request posted at all times, usually > an IN transfer as with most stuff in drivers/net, has this issue. > > > > I am working on to use different hardware endpoint for different BULK > > devices and would submit a patch once it is done. > > Be careful of that strategy. It'll die quickly on a number of the > non-OMAP platforms, which don't populte as many endpoints. > The strategy I had thought about was to allow use of more endpoints > if they were available, as a way to improve performance if enough > resources were available ... but primarily, act more like "normal" > hardware, and use a mechanism that's currently disabled. I agree and this is exactly what I am doing in my patch and currently under test. It will use different endpoint for different BULK devices if endpoint resource is available otherwise it will multiplex bulk request on one reserved endpoint as it is done today. > That mechanism being NAK limits. See the REVISIT comment in > the musb_urb_enqueue() function, where it sets interval to zero > for bulk and control transfers. > > The way it would work: if the NAK limit gets hit, the transfer > will stop "early". Finish cleaning it up (DMA might be an issue), > rotate that bulk transfer to the end of that bulk queue, stuff the > next transfer where that one was, repeat. > > Using that mechanism on one bulk endpoint would mean it wouldn't be > possible for transfers on it to starve everything else going the > same direction. We are working on NAK limit scheme also for bulk request when they are multiplexed on one reserved endpoint. > > Using that on a periodic endpoint would mean not tying down one > endpoint doing, say, an every-256-msec hub poll for one hub, > while there's no endpoint free for an every-8-msec mouse or > keyboard poll ... > > In short: I strongly encourage you to find a way to use the > NAK limit scheme to let incomplete host side transfers stop > themselves and free up their resources for re-use, without > giving up the ability to continue those transfers later. > > - Dave > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/2 rc8-omap-git] twl4030-core irq simplification
From: David Brownell <[EMAIL PROTECTED]>
Simplify twl4030 IRQ handling by removing a needless custom flow
handler. The top level IRQs, from the PIH, are well suited for
handle_simple_irq() ... they can't be acked or masked.
Switching resolves some issues with how IRQs were dispatched.
Notably, abuse of desc->status, IRQ accounting, and handling
of various faults.
In short, use standard genirq code.
Drivers that request_irq() to the PIH will need to pay more
attention to things like setting IRQF_DISABLED (since it's
no longer ignored), and making I2C calls from handlers (you'll
need a lockdep workaround).
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Tested with the updated TWL GPIO and pwrirq drivers (now using
handle_edge_irq). It should behave without those updates, too.
drivers/mfd/twl4030-core.c | 75 ++-
1 file changed, 4 insertions(+), 71 deletions(-)
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -535,68 +535,6 @@ EXPORT_SYMBOL(twl4030_i2c_read_u8);
/*--*/
-/*
- * do_twl4030_module_irq() is the desc->handle method for each of the twl4030
- * module interrupts that doesn't chain to another irq_chip (GPIO, power, etc).
- * It executes in kernel thread context. On entry, cpu interrupts are
disabled.
- */
-static void do_twl4030_module_irq(unsigned int irq, irq_desc_t *desc)
-{
- struct irqaction *action;
- const unsigned int cpu = smp_processor_id();
-
- /*
-* Earlier this was desc->triggered = 1;
-*/
- desc->status |= IRQ_LEVEL;
-
- /*
-* The desc->handle method would normally call the desc->chip->ack
-* method here, but we won't bother since our ack method is NULL.
-*/
-
- if (!desc->depth) {
- kstat_cpu(cpu).irqs[irq]++;
-
- action = desc->action;
- if (action) {
- int ret;
- int status = 0;
- int retval = 0;
-
- local_irq_enable();
-
- do {
- /* Call the ISR with cpu interrupts enabled */
- ret = action->handler(irq, action->dev_id);
- if (ret == IRQ_HANDLED)
- status |= action->flags;
- retval |= ret;
- action = action->next;
- } while (action);
-
- if (status & IRQF_SAMPLE_RANDOM)
- add_interrupt_randomness(irq);
-
- local_irq_disable();
-
- if (retval != IRQ_HANDLED)
- printk(KERN_ERR "ISR for TWL4030 module"
- " irq %d can't handle interrupt\n",
- irq);
-
- /*
-* Here is where we should call the unmask method, but
-* again we won't bother since it is NULL.
-*/
- } else
- printk(KERN_CRIT "TWL4030 module irq %d has no ISR"
- " but can't be masked!\n", irq);
- } else
- printk(KERN_CRIT "TWL4030 module irq %d is disabled but can't"
- " be masked!\n", irq);
-}
-
static unsigned twl4030_irq_base;
static struct completion irq_event;
@@ -611,7 +549,6 @@ static int twl4030_irq_thread(void *data
static unsigned i2c_errors;
const static unsigned max_i2c_errors = 100;
- daemonize("twl4030-irq");
current->flags |= PF_NOFREEZE;
while (!kthread_should_stop()) {
@@ -691,8 +625,7 @@ static struct task_struct * __init start
struct task_struct *thread;
init_completion(&irq_event);
- thread = kthread_run(twl4030_irq_thread, (void *)irq,
-"twl4030 irq %ld", irq);
+ thread = kthread_run(twl4030_irq_thread, (void *)irq, "twl4030-irq");
if (!thread)
pr_err("%s: could not create twl4030 irq %ld thread!\n",
DRIVER_NAME, irq);
@@ -1126,7 +1059,7 @@ static void twl_init_irq(int irq_num, un
/* install an irq handler for each of the PIH modules */
for (i = irq_base; i < irq_end; i++) {
set_irq_chip_and_handler(i, &twl4030_irq_chip,
- do_twl4030_module_irq);
+ handle_simple_irq);
activate_irq(i);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/2 rc8-omap-git] twl4030 "subdriver" irq tweaks
From: David Brownell <[EMAIL PROTECTED]>
Bugfixes to TWL subdriver irq handler setup ... lockdep
workarounds, remove IRQF_DISABLED. NOPs with current code.
These changes are specific to the drivers which register
directly with the PIH irq_chip (in twl4030-core), and are
prerequsites to a cleanup patch for that PIH infrastructure.
(Unless you don't use these drivers.)
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
I can't test any of these, but "what could go wrong" ...
drivers/i2c/chips/twl4030-madc.c| 10 +-
drivers/input/keyboard/omap-twl4030keypad.c | 11 +--
drivers/power/twl4030_bci_battery.c | 18 +-
3 files changed, 35 insertions(+), 4 deletions(-)
--- a/drivers/i2c/chips/twl4030-madc.c
+++ b/drivers/i2c/chips/twl4030-madc.c
@@ -148,6 +148,14 @@ static irqreturn_t twl4030_madc_irq_hand
u8 isr_val, imr_val;
int i;
+#ifdef CONFIG_LOCKDEP
+ /* WORKAROUND for lockdep forcing IRQF_DISABLED on us, which
+* we don't want and can't tolerate. Although it might be
+* friendlier not to borrow this thread context...
+*/
+ local_irq_enable();
+#endif
+
/* Use COR to ack interrupts since we have no shared IRQs in ISRx */
isr_val = twl4030_madc_read(madc, madc->isr);
imr_val = twl4030_madc_read(madc, madc->imr);
@@ -451,7 +459,7 @@ static int __init twl4030_madc_probe(str
regval, TWL4030_BCI_BCICTL1);
ret = request_irq(TWL4030_MODIRQ_MADC, twl4030_madc_irq_handler,
- IRQF_DISABLED, "twl4030_madc", madc);
+ 0, "twl4030_madc", madc);
if (ret) {
dev_dbg(&pdev->dev, "could not request irq\n");
goto err_irq;
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -208,6 +208,14 @@ static irqreturn_t do_kp_irq(int irq, vo
u8 reg;
int ret;
+#ifdef CONFIG_LOCKDEP
+ /* WORKAROUND for lockdep forcing IRQF_DISABLED on us, which
+* we don't want and can't tolerate. Although it might be
+* friendlier not to borrow this thread context...
+*/
+ local_irq_enable();
+#endif
+
/* Read & Clear TWL4030 pending interrupt */
ret = twl4030_kpread(kp, TWL4030_MODULE_KEYPAD, ®, KEYP_ISR1, 1);
@@ -340,8 +348,7 @@ static int __init omap_kp_probe(struct p
* This ISR will always execute in kernel thread context because of
* the need to access the TWL4030 over the I2C bus.
*/
- ret = request_irq(kp->irq, do_kp_irq, IRQF_DISABLED,
- "TWL4030 Keypad", kp);
+ ret = request_irq(kp->irq, do_kp_irq, 0, pdev->name, kp);
if (ret < 0) {
dev_info(kp->dbg_dev, "request_irq failed for irq no=%d\n",
kp->irq);
--- a/drivers/power/twl4030_bci_battery.c
+++ b/drivers/power/twl4030_bci_battery.c
@@ -210,6 +210,14 @@ static irqreturn_t twl4030charger_interr
{
struct twl4030_bci_device_info *di = _di;
+#ifdef CONFIG_LOCKDEP
+ /* WORKAROUND for lockdep forcing IRQF_DISABLED on us, which
+* we don't want and can't tolerate. Although it might be
+* friendlier not to borrow this thread context...
+*/
+ local_irq_enable();
+#endif
+
twl4030charger_presence_evt();
power_supply_changed(&di->bat);
@@ -310,6 +318,14 @@ static irqreturn_t twl4030battery_interr
u8 isr1a_val, isr2a_val, clear_2a, clear_1a;
int ret;
+#ifdef CONFIG_LOCKDEP
+ /* WORKAROUND for lockdep forcing IRQF_DISABLED on us, which
+* we don't want and can't tolerate. Although it might be
+* friendlier not to borrow this thread context...
+*/
+ local_irq_enable();
+#endif
+
ret = twl4030_i2c_read_u8(TWL4030_MODULE_INTERRUPTS, &isr1a_val,
REG_BCIISR1A);
if (ret)
@@ -943,7 +959,7 @@ static int __init twl4030_bci_battery_pr
/* request BCI interruption */
ret = request_irq(TWL4030_MODIRQ_BCI, twl4030battery_interrupt,
- IRQF_DISABLED, pdev->name, NULL);
+ 0, pdev->name, NULL);
if (ret) {
dev_dbg(&pdev->dev, "could not request irq %d, status %d\n",
TWL4030_MODIRQ_BCI, ret);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB serial devices not working on linux-omap musb.
On Wednesday 01 October 2008, Gupta, Ajay Kumar wrote: > Currently all the BULK request are multiplexed on one hardware endpoint > and when a wifi or eth device is in use they never release BULK hardware > endpoint so that it can be used by other devices. This causes failure of > serial device when any of wifi/eth is in use. Any driver that keeps a bulk request posted at all times, usually an IN transfer as with most stuff in drivers/net, has this issue. > I am working on to use different hardware endpoint for different BULK > devices and would submit a patch once it is done. Be careful of that strategy. It'll die quickly on a number of the non-OMAP platforms, which don't populte as many endpoints. The strategy I had thought about was to allow use of more endpoints if they were available, as a way to improve performance if enough resources were available ... but primarily, act more like "normal" hardware, and use a mechanism that's currently disabled. That mechanism being NAK limits. See the REVISIT comment in the musb_urb_enqueue() function, where it sets interval to zero for bulk and control transfers. The way it would work: if the NAK limit gets hit, the transfer will stop "early". Finish cleaning it up (DMA might be an issue), rotate that bulk transfer to the end of that bulk queue, stuff the next transfer where that one was, repeat. Using that mechanism on one bulk endpoint would mean it wouldn't be possible for transfers on it to starve everything else going the same direction. Using that on a periodic endpoint would mean not tying down one endpoint doing, say, an every-256-msec hub poll for one hub, while there's no endpoint free for an every-8-msec mouse or keyboard poll ... In short: I strongly encourage you to find a way to use the NAK limit scheme to let incomplete host side transfers stop themselves and free up their resources for re-use, without giving up the ability to continue those transfers later. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/5] OMAP SSI driver interface
On Monday 06 October 2008, Felipe Balbi wrote: > looks much better and much easier to type: #include Does this work on non-OMAP kernels? If not, or similar would seem more sensible ... Agreed about there being way too many headers, too. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HEAD unbootable on 2430SDP
On Mon, Oct 6, 2008 at 4:46 PM, Woodruff, Richard <[EMAIL PROTECTED]> wrote: > > >> I am running into a weird problem with the current HEAD on OMAP2430SDP. >> >> It seems the execution goes into infinite loop in intc_bank_read_reg() >> function. >> >> In the: >> while (!(intc_bank_read_reg(bank, INTC_SYSSTATUS) & 0x1)) >> /* Wait for reset to complete */; > > Did your board boot loader setup the peripheral port remap register? I'm using the u-boot snapshot from http://linux.omap.com/pub/bootloader/2430sdp/source/u-boot-Sept2507.tar.gz. And it seems to map it. - Juha -- Madness takes it's toll. Please have exact change. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 4/5] OMAP SSI integration into misc drivers
On Fri, Oct 03, 2008 at 02:52:29PM +0300, Carlos Chinea wrote: > > Signed-off-by: Carlos Chinea <[EMAIL PROTECTED]> > --- > drivers/misc/Kconfig |2 ++ > drivers/misc/Makefile |1 + > 2 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index f0202ee..b09dc68 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -488,4 +488,6 @@ config SGI_GRU_DEBUG > This option enables addition debugging code for the SGI GRU driver. If > you are unsure, say N. > > +source "drivers/misc/ssi/Kconfig" > + > endif # MISC_DEVICES > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile > index b6167e7..39e153d 100644 > --- a/drivers/misc/Makefile > +++ b/drivers/misc/Makefile > @@ -31,3 +31,4 @@ obj-$(CONFIG_KGDB_TESTS)+= kgdbts.o > obj-$(CONFIG_SGI_XP) += sgi-xp/ > obj-$(CONFIG_SGI_GRU)+= sgi-gru/ > obj-$(CONFIG_HP_ILO) += hpilo.o > +obj-$(CONFIG_OMAP_SSI) += ssi/ I believe the whole ssi should sit under drivers/ssi -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: HEAD unbootable on 2430SDP
> I am running into a weird problem with the current HEAD on OMAP2430SDP. > > It seems the execution goes into infinite loop in intc_bank_read_reg() > function. > > In the: > while (!(intc_bank_read_reg(bank, INTC_SYSSTATUS) & 0x1)) > /* Wait for reset to complete */; Did your board boot loader setup the peripheral port remap register? If not you must make sure the INTC is mapped to non-shared-device mapping else you won't be seeing the INTC registers properly. Using the remap register works, but if you inspect TLBs you'll see it uses all 4k'ers instead of a single 1M section entry for L4 range. This will cut performance some. In a local hack a while back we had used some reserved L4 space to provide a separate mapping for the INTC with non-shared-device mapping. If you do this you can shut down the remap register. Probably most people are not appreciating benefit of that setup. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] ARM: OMAP2: Remove OMAP_PRM_REGADDR, OMAP_CM_REGADDR
On Mon, Oct 06, 2008 at 05:18:49PM +0100, Russell King - ARM Linux wrote: > On Thu, Oct 02, 2008 at 10:37:52AM -0600, Paul Walmsley wrote: > > From: Tony Lindgren <[EMAIL PROTECTED]> > > > > Remove OMAP_PRM_REGADDR and OMAP_CM_REGADDR. Use > > prm_read/write_mod_reg() or cm_read/write_mod_reg() instead. For > > assembly, use OMAP_PRM_REGADDR or OMAP_CM_REGADDR macros. > > I do have concerns about this patch as well - hating those casts > that are required to store an offset in 'enable_reg', which then > have to be un-casted to add the correct base address. > > I've been trying to work out if there's a better way to do this > using the existing structures. How about: I've modified this idea slightly, since using a mask instead of bit numbers makes it possible to remove more special casing... and I also have a perl script to convert the clock definitions. One thing I've noticed, however, is that there seem to be clocks which result in omap2_clk_wait_ready() being called, which checks the "other" F or I clock register, but there's no corresponding clock defined in the source for that bit. Eg, iva1_ifck in clock24xx.h. What does it mean? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: android on omap
Haven't seen that error - sorry. Unable to mmap stands out. I know there was a lot of updates to the shared memory subsystem and there was some Android share memory driver introduced with the Android patch set. Seems like it's trying to mmap some shared memory and failing. The rest just seems to be fallout because it can't do what it wants to now. ...Kd > -Original Message- > From: twebb [mailto:[EMAIL PROTECTED] > Sent: Monday, October 06, 2008 4:46 PM > To: Deacon, Keith; linux-omap@vger.kernel.org Mailing List > Subject: Re: android on omap > > > > > Had problems with using NFS because Android tries to set specific > permission and ownership of files - and has a nasty habit of testing those > permissions frequently. If you have any local storage options - that > would help. Also, check your init.rc file for things like mount trying to > remount the filesystem readonly - Android assumes a very specific > partition layout - which can be consolidated into one partition as long as > init.rc is adjusted to match. > > > > > Does the root file system reside on NFS? Have you enabled "Networking" > while > > configuring the kernel? > > > > I've now moved filesystem to target (jffs2). Things are a little > better, and different. Using logcat, I'm now seeing dalvikvm errors > and warnings as shown below. Particularly odd since I wasn't seeing > this error when rootfs was mounted via NFS. Any ideas? > > I really appreciate your input. > > Thanks, > twebb > > D/dalvikvm( 483): DexOpt: --- BEGIN 'core.jar' (bootstrap=1) --- > E/dalvikvm( 501): unable to mmap DEX cache: Invalid argument > E/dalvikvm( 501): Optimization failed > D/dalvikvm( 483): DexOpt: waiting for verify+opt, pid=501 > W/dalvikvm( 483): DexOpt: --- END 'core.jar' --- status=0xff00, process > failed > E/dalvikvm( 483): Unable to extract+optimize DEX from > '/system/framework/core.jar' > D/dalvikvm( 483): Failed on '/system/framework/core.jar' (boot=1) > D/dalvikvm( 483): VM cleaning up > D/dalvikvm( 483): LinearAlloc 0x0 used 4100 of 4194304 (0%) > W/dalvikvm( 483): JNI_CreateJavaVM failed > E/AndroidRuntime( 483): JNI_CreateJavaVM failed -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
HEAD unbootable on 2430SDP
Hi, I am running into a weird problem with the current HEAD on OMAP2430SDP. It seems the execution goes into infinite loop in intc_bank_read_reg() function. In the: while (!(intc_bank_read_reg(bank, INTC_SYSSTATUS) & 0x1)) /* Wait for reset to complete */; to be specific. It seems that the address in bank->base_reg does not point to a virtual address that is mapped to the INTC registers. I'm using the omap_2430sdp_defconfig with CONFIG_GPIO_TWL4030 added. Toolchain I used is: gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126) Before digging deeper I was wondering if anyone else sees this? -- Madness takes it's toll. Please have exact change. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 2/5] OMAP SSI driver interface
On Fri, Oct 03, 2008 at 02:52:27PM +0300, Carlos Chinea wrote:
add a patch description body here.
> Signed-off-by: Carlos Chinea <[EMAIL PROTECTED]>
> ---
> include/linux/ssi_driver_if.h | 137
> +
> 1 files changed, 137 insertions(+), 0 deletions(-)
> create mode 100644 include/linux/ssi_driver_if.h
>
> diff --git a/include/linux/ssi_driver_if.h b/include/linux/ssi_driver_if.h
> new file mode 100644
> index 000..3379dd0
> --- /dev/null
> +++ b/include/linux/ssi_driver_if.h
why wouldn't ssi.h be enough as a header name ?
looks much better and much easier to type: #include
> @@ -0,0 +1,137 @@
> +/*
> + * ssi_driver_if.h
> + *
> + * Header for the SSI driver low level interface.
> + *
> + * Copyright (C) 2007-2008 Nokia Corporation. All rights reserved.
> + *
> + * Contact: Carlos Chinea <[EMAIL PROTECTED]>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + */
> +#ifndef __SSI_DRIVER_IF_H__
> +#define __SSI_DRIVER_IF_H__
> +
> +#include
> +
> +#define SSI_IOMEM_NAME "SSI_IO_MEM"
> +#define SSI_P1_MPU_IRQ0_NAME "SSI_P1_MPU_IRQ0"
> +#define SSI_P2_MPU_IRQ0_NAME "SSI_P2_MPU_IRQ0"
> +#define SSI_P1_MPU_IRQ1_NAME "SSI_P1_MPU_IRQ1"
> +#define SSI_P2_MPU_IRQ1_NAME "SSI_P2_MPU_IRQ1"
> +#define SSI_GDD_MPU_IRQ_NAME "GDD_MPU_IRQ"
hmm... I wonder you really need these ? Maybe I have to wait until I
review the other patches but at least for the irq names, they look
weird. Are them used for request_irq() only ? If so, remove them and
pass it in the driver. There's no need for such a global definition.
> +
> +/* IRQ values */
> +#define SSI_P1_MPU_IRQ0 67
> +#define SSI_P2_MPU_IRQ0 68
> +#define SSI_P1_MPU_IRQ1 69
> +#define SSI_P2_MPU_IRQ1 70
> +#define SSI_GDD_MPU_IRQ 71
Most likely this will be platform_specific right ? So pass it to the
driver using a struct resource.
> +
> +/* The number of ports handled by the driver. (MAX:2) */
> +#define SSI_MAX_PORTS1
> +
> +/*
> + * Masks used to enable or disable the reception of certain hardware events
> + * for the ssi_device_drivers
> + */
> +#define SSI_EVENT_CLEAR 0x00
> +#define SSI_EVENT_MASK 0xFF
> +#define SSI_EVENT_BREAK_DETECTED_MASK0x01
> +#define SSI_EVENT_ERROR_MASK 0x02
> +
> +#define ANY_SSI_CONTROLLER -1
> +#define ANY_CHANNEL -1
> +#define CHANNEL(channel) (1< +
> +enum {
> + SSI_EVENT_BREAK_DETECTED = 0,
> + SSI_EVENT_ERROR,
> +};
> +
> +enum {
> + SSI_IOCTL_WAKE_UP,
> + SSI_IOCTL_WAKE_DOWN,
> + SSI_IOCTL_SEND_BREAK,
> + SSI_IOCTL_WAKE,
> +};
hmm... ioctls, let's if they're really needed later.
> +
> +/* Forward references */
> +struct ssi_device;
> +struct ssi_dev;
> +struct ssi_port;
> +struct ssi_channel;
> +
> +struct ssi_port_pd {
> + u32 tx_mode;
> + u32 tx_frame_size;
> + u32 divisor;
> + u32 tx_ch;
> + u32 arb_mode;
> + u32 rx_mode;
> + u32 rx_frame_size;
> + u32 rx_ch;
> + u32 timeout;
> + u8 n_irq;
> +};
> +
> +struct ssi_platform_data {
> + unsigned char *clk_name;
please don't pass clock names via platform_data. It's ugly and we're
having quite a big amount of work trying to find a solution to clean
omap drivers. Looks like we're gonna introduce omap_clk_associate()
which will associate the user device with the clock structure and
introduce a clk alias name (called function name) to avoid the problem
we have now with different omap versions (different clock names).
> + struct ssi_dev *ssi_ctrl;
> + struct ssi_port_pd *ports;
> + u8 num_ports;
> +};
> +
> +struct ssi_device {
> + int n_ctrl;
> + unsigned int n_p;
> + unsigned int n_ch;
> + char modalias[BUS_ID_SIZE];
> + struct ssi_channel *ch;
> + struct device device;
> +};
> +
> +#define to_ssi_device(dev) container_of(dev, struct ssi_device, device)
> +
> +struct ssi_device_driver {
> + unsigned long ctrl_mask;
> + unsigned long ch_mask[SSI_MAX_PORTS];
> + unsigned long event_mask;
> + void(*port_event) (int c_id, unsigned int port,
^ trailing whitespace
> + unsigned int event, void *arg);
> + int
Re: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches
> >> Where I observed a new oddity: the boot hung right after > >> listing the MTD partitions. Which is where the EHCI code > >> would come up ... took that driver out of the build, and > >> the hang went away. Clue, oh clue; where art thou? > >> > > > > Well... Any chance this bit of code here helps? This infinite loop > > shouldn't even have been here. Oh well. Didn't help. :( This code has so many infinite loops for hardware handshaking (none with timeouts!) that it's hard to say which one might be causing this ... if indeed one of them is indeed the cause. > > CUT_HERE= > > Remove infinite loop in DPLL 5 programming. Ideally, DPLL5 should be > > taken care of by the clock framework. > > --- > > drivers/usb/host/ehci-omap.c |2 ++ > > 1 files changed, 2 insertions(+) > > > > Index: linux-omap-2.6/drivers/usb/host/ehci-omap.c > > === > > --- linux-omap-2.6.orig/drivers/usb/host/ehci-omap.c2008-09-18 > > 14:59:34.0 +0530 > > +++ linux-omap-2.6/drivers/usb/host/ehci-omap.c 2008-09-18 > > 15:00:09.737475758 +0530 > > @@ -170,10 +170,12 @@ static int omap_start_ehc(struct platfor > >(7 << OMAP3430ES2_EN_PERIPH2_DPLL_SHIFT), > >PLL_MOD, OMAP3430ES2_CM_CLKEN2); > > > > +#if 0 > >while (!(cm_read_mod_reg(PLL_MOD, CM_IDLEST2) & > >OMAP3430ES2_ST_PERIPH2_CLK_MASK)) > >dev_dbg(hcd->self.controller, "idlest2 = 0x%x\n", > >cm_read_mod_reg(PLL_MOD, CM_IDLEST2)); > > +#endif > >/* End DPLL5 programming */ > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/5] OMAP SSI hardware interface definitions
On Fri, Oct 03, 2008 at 02:52:26PM +0300, Carlos Chinea wrote: > > Signed-off-by: Carlos Chinea <[EMAIL PROTECTED]> > --- > arch/arm/plat-omap/include/mach/ssi/ssi_gdd_reg.h | 145 > > .../plat-omap/include/mach/ssi/ssi_reg_common.h| 73 ++ > arch/arm/plat-omap/include/mach/ssi/ssi_ssr_reg.h | 56 > arch/arm/plat-omap/include/mach/ssi/ssi_sst_reg.h | 65 + > arch/arm/plat-omap/include/mach/ssi/ssi_sys_reg.h | 107 ++ > 5 files changed, 446 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/plat-omap/include/mach/ssi/ssi_gdd_reg.h > create mode 100644 arch/arm/plat-omap/include/mach/ssi/ssi_reg_common.h > create mode 100644 arch/arm/plat-omap/include/mach/ssi/ssi_ssr_reg.h > create mode 100644 arch/arm/plat-omap/include/mach/ssi/ssi_sst_reg.h > create mode 100644 arch/arm/plat-omap/include/mach/ssi/ssi_sys_reg.h > > diff --git a/arch/arm/plat-omap/include/mach/ssi/ssi_gdd_reg.h > b/arch/arm/plat-omap/include/mach/ssi/ssi_gdd_reg.h > new file mode 100644 > index 000..5ed91cc > --- /dev/null > +++ b/arch/arm/plat-omap/include/mach/ssi/ssi_gdd_reg.h > @@ -0,0 +1,145 @@ > +/* > + * ssi_gdd_reg.h > + * > + * Hardware defintions for SSI Controller GDD registers. > + * > + * HARDWARE: OMAP 2420, OMAP 3430 This is unnecessary, if we happen to use the same in omap4 we're gonna have to update. Please remove. > + * Copyright (C) 2007-2008 Nokia Corporation. All rights reserved. > + * > + * Contact: Carlos Chinea <[EMAIL PROTECTED]> > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA > + */ > +#ifndef __SSI_GDD_REG_H__ > +#define __SSI_GDD_REG_H__ > + > +#include "ssi_reg_common.h" > + > +#define SSI_GDD_HW_ID_REGSSI_GDD_REG32(0x) this is not a good practice, use the correct offsets for all registers > +#define SSI_GDD_PPORT_ID_REG SSI_GDD_REG32(0x0010) > +#define SSI_GDD_MPORT_ID_REG SSI_GDD_REG32(0x0014) > + > +#define SSI_GDD_PPORT_SR_REG SSI_GDD_REG32(0x0020) > +#define SSI_PPORT_ACTIVE_LCH_NUMBER_MASK 0xFF > + > +#define SSI_GDD_MPORT_SR_REG SSI_GDD_REG32(0x0024) > +#define SSI_MPORT_ACTIVE_LCH_NUMBER_MASK 0xFF > + > +#define SSI_GDD_TEST_REG SSI_GDD_REG32(0x0040) ^ trailing whitespace > +#define SSI_TEST 0x1 > + > +#define SSI_GDD_GCR_REG SSI_GDD_REG32(0x0100) > +#define SSI_CLK_AUTOGATING_ON (1<<3) ^^ add spaces around << > +#define SSI_FREE(1<<2) > +#define SSI_SWITCH_OFF 0x1 > + > +#define SSI_GDD_GRST_REG SSI_GDD_REG32(0x0200) ^ trailing whitespace > +#define SSI_SWRESET 0x1 > + > +#define SSI_GDD_CSDP_BASE0x0800 > +#define SSI_GDD_CSDP_OFFSET 0x40 > +#define SSI_GDD_CSDP_REG(channel)SSI_GDD_REG16(SSI_GDD_CSDP_BASE +\ ^ trailing whitespace > + (channel*SSI_GDD_CSDP_OFFSET)) ^ add spaces around * > +#define SSI_DST_BURST_EN_MASK0xC000 > +#define SSI_DST_SINGLE_ACCESS0 0x0 > +#define SSI_DST_SINGLE_ACCESS(0x1<<14) > +#define SSI_DST_BURST_4X32_BIT (0x2<<14) > +#define SSI_DST_BURST_8x32_BIT (0x3<<14) /*NOTE: NOT SUPPORTED */ (1 << 14), (2 << 14) and (3 << 14) (up to 9) is enough. ^ add a space before NOTE > + > +#define SSI_DST_MASK 0x1E00 make all the hex numbers lower case > +#define SSI_DST_MEMORY_PORT (0x8<<9) > +#define SSI_DST_PERIPHERAL_PORT (0x9<<9) > + > +#define SSI_SRC_BURST_EN_MASK0x0180 > +#define SSI_SRC_SINGLE_ACCESS0 0x0 > +#define SSI_SRC_SINGLE_ACCESS(0x1<<7) > +#define SSI_SRC_BURST_4x32_BIT (0x2<<7) > +#define SSI_SRC_BURST_8x32_BIT (0x3<<7)/*NOTE: NOT SUPPORTED */ > + > +#define SSI_SRC_MASK 0x003C > +#define SSI_SRC_MEMORY_PORT (0x8<<2) > +#define SSI_SRC_PERIPHERAL_PORT (0x9<<2) > + > +#define SSI_DATA_TYPE_MASK 0x0003 > +#define SSI_DATA_TYPE_S320x2 > + > +#define SSI_GDD_CCR_BASE 0x0802 ^ trailing whitespace > +#define SSI_GDD_CCR_OF
[PATCH 3/3] clk: use clk_associate on watchdog driver
From: Felipe Balbi <[EMAIL PROTECTED]>
Get rid of clk mess on omap_watchdog driver by
using clk_associate.
Cc: Wim Van Sebroeck <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
Documentation/arm/OMAP/clk_function_name.txt |4 +
arch/arm/plat-omap/devices.c | 18 --
drivers/watchdog/omap_wdt.c | 87 --
3 files changed, 43 insertions(+), 66 deletions(-)
diff --git a/Documentation/arm/OMAP/clk_function_name.txt
b/Documentation/arm/OMAP/clk_function_name.txt
index 0828812..f5ddcc6 100644
--- a/Documentation/arm/OMAP/clk_function_name.txt
+++ b/Documentation/arm/OMAP/clk_function_name.txt
@@ -7,3 +7,7 @@ function name given to the clks in omap1, omap2 and omap3.
Function name | OMAP1 | OMAP2 | OMAP3
---
musb_ick | - | osc_ck/usbhs_ick| hsotgusb_ick
+---
+wdt_fck| armwdt_ck | mpu_wdt_fck |
wdt2_fck
+---
+wdt_ick| - | mpu_wdt_fck |
wdt2_ick
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index c22bd5f..c1e253c 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -298,16 +298,24 @@ static struct platform_device omap_wdt_device = {
static void omap_init_wdt(void)
{
- if (cpu_is_omap16xx())
+ if (cpu_is_omap16xx()) {
+ omap_clk_associate("armwdt_ck", &omap_wdt_device.dev,
"wdt_fck");
wdt_resources[0].start = 0xfffeb000;
- else if (cpu_is_omap2420())
+ } else if (cpu_is_omap2420()) {
+ omap_clk_associate("mpu_wdt_fck", &omap_wdt_device.dev,
"wdt_fck");
+ omap_clk_associate("mpu_wdt_ick", &omap_wdt_device.dev,
"wdt_ick");
wdt_resources[0].start = 0x48022000; /* WDT2 */
- else if (cpu_is_omap2430())
+ } else if (cpu_is_omap2430()) {
+ omap_clk_associate("mpu_wdt_fck", &omap_wdt_device.dev,
"wdt_fck");
+ omap_clk_associate("mpu_wdt_ick", &omap_wdt_device.dev,
"wdt_ick");
wdt_resources[0].start = 0x49016000; /* WDT2 */
- else if (cpu_is_omap343x())
+ } else if (cpu_is_omap343x()) {
+ omap_clk_associate("wdt2_fck", &omap_wdt_device.dev, "wdt_fck");
+ omap_clk_associate("wdt2_ick", &omap_wdt_device.dev, "wdt_ick");
wdt_resources[0].start = 0x48314000; /* WDT2 */
- else
+ } else {
return;
+ }
wdt_resources[0].end = wdt_resources[0].start + 0x4f;
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 7bcbb7f..e31d7f5 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -60,9 +60,8 @@ struct omap_wdt_dev {
void __iomem*base; /* physical */
struct device *dev;
int omap_wdt_users;
- struct clk *armwdt_ck;
- struct clk *mpu_wdt_ick;
- struct clk *mpu_wdt_fck;
+ struct clk *ick;
+ struct clk *fck;
struct resource *mem;
struct miscdevice omap_wdt_miscdev;
};
@@ -146,13 +145,10 @@ static int omap_wdt_open(struct inode *inode, struct file
*file)
if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
return -EBUSY;
- if (cpu_is_omap16xx())
- clk_enable(wdev->armwdt_ck);/* Enable the clock */
-
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
- clk_enable(wdev->mpu_wdt_ick);/* Enable the interface clock
*/
- clk_enable(wdev->mpu_wdt_fck);/* Enable the functional
clock */
- }
+ if (wdev->fck)
+ clk_enable(wdev->fck);/* Enable the functional clock */
+ if (wdev->ick)
+ clk_enable(wdev->ick);/* Enable the interface clock */
/* initialize prescaler */
while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x01)
@@ -303,44 +299,20 @@ static int __init omap_wdt_probe(struct platform_device
*pdev)
wdev->omap_wdt_users = 0;
wdev->mem = mem;
- if (cpu_is_omap16xx()) {
- wdev->armwdt_ck = clk_get(&pdev->dev, "armwdt_ck");
- if (IS_ERR(wdev->armwdt_ck)) {
- ret = PTR_ERR(wdev->armwdt_ck);
- wdev->armwdt_ck = NULL;
- goto err_clk;
- }
+ wdev->fck = clk_get(&pdev->dev, "wdt_fck");
+ if (IS_ERR(wdev->fck)) {
+ ret = PTR_ERR(wdev->fck);
+ wdev->fck = NULL;
+ goto err_clk;
}
- if (cpu_is_omap24xx()) {
- wdev->mpu
[PATCH 2/3] clk: use clk_associate for musb driver
From: Felipe Balbi <[EMAIL PROTECTED]>
Let musb use clk_associate to avoid introducing non-standard
clk functions and passing a clk name via pdata.
Also introduce txt file to track clk function names.
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
Documentation/arm/OMAP/clk_function_name.txt |9 +++
arch/arm/mach-omap2/board-n800-usb.c | 26 ---
arch/arm/mach-omap2/usb-musb.c | 34 +++---
arch/arm/mach-omap2/usb-tusb6010.c |2 +
drivers/usb/musb/musb_core.c | 23 +
5 files changed, 27 insertions(+), 67 deletions(-)
create mode 100644 Documentation/arm/OMAP/clk_function_name.txt
diff --git a/Documentation/arm/OMAP/clk_function_name.txt
b/Documentation/arm/OMAP/clk_function_name.txt
new file mode 100644
index 000..0828812
--- /dev/null
+++ b/Documentation/arm/OMAP/clk_function_name.txt
@@ -0,0 +1,9 @@
+ OMAP Clock Function Names
+
+When moving a new driver to use clk_associate, please add here the clk
+function name given to the clks in omap1, omap2 and omap3.
+
+
+Function name | OMAP1 | OMAP2 | OMAP3
+---
+musb_ick | - | osc_ck/usbhs_ick| hsotgusb_ick
diff --git a/arch/arm/mach-omap2/board-n800-usb.c
b/arch/arm/mach-omap2/board-n800-usb.c
index f8df19e..820f285 100644
--- a/arch/arm/mach-omap2/board-n800-usb.c
+++ b/arch/arm/mach-omap2/board-n800-usb.c
@@ -25,7 +25,6 @@
#define GPIO_TUSB_ENABLE 0
static int tusb_set_power(int state);
-static int tusb_set_clock(struct clk *osc_ck, int state);
#ifdefined(CONFIG_USB_MUSB_OTG)
# define BOARD_MODE MUSB_OTG
@@ -82,10 +81,8 @@ static struct musb_hdrc_config musb_config = {
static struct musb_hdrc_platform_data tusb_data = {
.mode = BOARD_MODE,
.set_power = tusb_set_power,
- .set_clock = tusb_set_clock,
.min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
.power = 100, /* Max 100 mA VBUS for host mode */
- .clock = "osc_ck",
.config = &musb_config,
};
@@ -121,29 +118,6 @@ static int tusb_set_power(int state)
return retval;
}
-static int osc_ck_on;
-
-static int tusb_set_clock(struct clk *osc_ck, int state)
-{
- if (state) {
- if (osc_ck_on > 0)
- return -ENODEV;
-
- omap2_block_sleep();
- clk_enable(osc_ck);
- osc_ck_on = 1;
- } else {
- if (osc_ck_on == 0)
- return -ENODEV;
-
- clk_disable(osc_ck);
- osc_ck_on = 0;
- omap2_allow_sleep();
- }
-
- return 0;
-}
-
void __init n800_usb_init(void)
{
int ret = 0;
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 61c5709..44f2ab0 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_USB_MUSB_SOC
static struct resource musb_resources[] = {
@@ -53,27 +54,6 @@ static struct resource musb_resources[] = {
},
};
-static int clk_on;
-
-static int musb_set_clock(struct clk *clk, int state)
-{
- if (state) {
- if (clk_on > 0)
- return -ENODEV;
-
- clk_enable(clk);
- clk_on = 1;
- } else {
- if (clk_on == 0)
- return -ENODEV;
-
- clk_disable(clk);
- clk_on = 0;
- }
-
- return 0;
-}
-
static struct musb_hdrc_eps_bits musb_eps[] = {
{ "ep1_tx", 10, },
{ "ep1_rx", 10, },
@@ -127,10 +107,6 @@ static struct musb_hdrc_platform_data musb_plat = {
#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
.mode = MUSB_PERIPHERAL,
#endif
- .clock = cpu_is_omap34xx()
- ? "hsotgusb_ick"
- : "usbhs_ick",
- .set_clock = musb_set_clock,
.config = &musb_config,
/* REVISIT charge pump on TWL4030 can supply up to
@@ -159,6 +135,14 @@ static struct platform_device musb_device = {
void __init usb_musb_init(void)
{
#ifdef CONFIG_USB_MUSB_SOC
+ /* associate musb clocks with musb device */
+
+ if (cpu_is_omap34xx())
+ omap_clk_associate("hsotgusb_ick", &musb_device.dev,
"musb_ick");
+
+ if (cpu_is_omap24xx())
+ omap_clk_associate("usbhs_ick", &musb_device.dev, "musb_ick");
+
if (platform_device_register(&musb_device) < 0) {
printk(KERN_ERR "Unable to register HS-USB (MUSB) device\n");
return;
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
inde
[PATCH 1/3] clk: introduce omap_clk_associate
From: Felipe Balbi <[EMAIL PROTECTED]>
Introduce a new mechanism to omap's clk implementation to
associate the device with its clock during platform_device
registration. Also gives the clock a function name (like
mmc_fck, uart_fck, ehci_fck, etc) so drivers won't have to
care about clk names any longer.
With this mechanism we can also be sure drivers won't be able
to clk_get the wrong clk (only true when we move all drivers
to this new mechanism and drop the old ones).
Clk's function names will be defined as they come necessary
but let's try to keep it as simple as possible.
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/clock.c | 38 +-
arch/arm/plat-omap/include/mach/clock.h |6 +
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 7bbfba2..c090f23 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -43,7 +43,7 @@ static struct clk_functions *arch_clock;
*/
struct clk * clk_get(struct device *dev, const char *id)
{
- struct clk *p, *clk = ERR_PTR(-ENOENT);
+ struct clk *p, *clk;
int idno;
if (dev == NULL || dev->bus != &platform_bus_type)
@@ -53,6 +53,15 @@ struct clk * clk_get(struct device *dev, const char *id)
mutex_lock(&clocks_mutex);
+ list_for_each_entry(clk, &clocks, node) {
+ if (clk->function && (dev == clk->dev) &&
+ strcmp(id, clk->function) == 0)
+ goto found;
+
+ if (strcmp(id, clk->name) == 0)
+ goto found;
+ }
+
list_for_each_entry(p, &clocks, node) {
if (p->id == idno &&
strcmp(id, p->name) == 0 && try_module_get(p->owner)) {
@@ -64,10 +73,14 @@ struct clk * clk_get(struct device *dev, const char *id)
list_for_each_entry(p, &clocks, node) {
if (strcmp(id, p->name) == 0 && try_module_get(p->owner)) {
clk = p;
- break;
+ goto found;
}
}
+ mutex_unlock(&clocks_mutex);
+
+ return ERR_PTR(-ENOENT);
+
found:
mutex_unlock(&clocks_mutex);
@@ -75,6 +88,27 @@ found:
}
EXPORT_SYMBOL(clk_get);
+/**
+ * omap_clk_associate - associates a user to a clock so device drivers don't
+ * have to care about clock names
+ *
+ * @id: clock id as defined in arch/arm/mach-omapX/clk.h
+ * @dev: device pointer for the clock user
+ * @f: a function for the clock (uart_[if]ck, musb_ick, ehci_[if]ck, etc)
+ */
+void __init omap_clk_associate(const char *id, struct device *dev, const char
*f)
+{
+ struct clk *clk = clk_get(NULL, id);
+
+ if (!dev || !clk || !IS_ERR(clk_get(dev, f)))
+ return;
+
+ clk->function = f;
+ clk->dev = dev;
+
+ clk_put(clk);
+};
+
int clk_enable(struct clk *clk)
{
unsigned long flags;
diff --git a/arch/arm/plat-omap/include/mach/clock.h
b/arch/arm/plat-omap/include/mach/clock.h
index 9088925..21f18ca 100644
--- a/arch/arm/plat-omap/include/mach/clock.h
+++ b/arch/arm/plat-omap/include/mach/clock.h
@@ -13,6 +13,8 @@
#ifndef __ARCH_ARM_OMAP_CLOCK_H
#define __ARCH_ARM_OMAP_CLOCK_H
+#include
+
struct module;
struct clk;
struct clockdomain;
@@ -61,8 +63,10 @@ struct dpll_data {
struct clk {
struct list_headnode;
+ struct device *dev;
struct module *owner;
const char *name;
+ const char *function;
int id;
struct clk *parent;
unsigned long rate;
@@ -116,6 +120,8 @@ struct clk_functions {
extern unsigned int mpurate;
+extern void omap_clk_associate(const char *id,
+ struct device *dev, const char *func);
extern int clk_init(struct clk_functions *custom_clocks);
extern int clk_register(struct clk *clk);
extern void clk_unregister(struct clk *clk);
--
1.6.0.1.196.g01914
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] omap_clk_associate
From: Felipe Balbi <[EMAIL PROTECTED]> In the following patches we introduce omap_clk_associate hook to simplify clk handling for drivers. The main idea is that we let struct clk know which device is the user for that clk source and create a function name (or alias) for the clk so drivers doesn't have to care about different clk names between omap versions. Felipe Balbi (3): clk: introduce omap_clk_associate clk: use clk_associate for musb driver clk: use clk_associate on watchdog driver Documentation/arm/OMAP/clk_function_name.txt | 13 arch/arm/mach-omap2/board-n800-usb.c | 26 arch/arm/mach-omap2/usb-musb.c | 34 +++--- arch/arm/mach-omap2/usb-tusb6010.c |2 + arch/arm/plat-omap/clock.c | 38 +++- arch/arm/plat-omap/devices.c | 18 -- arch/arm/plat-omap/include/mach/clock.h |6 ++ drivers/usb/musb/musb_core.c | 23 ++- drivers/watchdog/omap_wdt.c | 87 -- 9 files changed, 112 insertions(+), 135 deletions(-) create mode 100644 Documentation/arm/OMAP/clk_function_name.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current git head oops'es at boot on Overo
On Mon, Oct 6, 2008 at 2:15 PM, Nathan Monson <[EMAIL PROTECTED]> wrote: > I'm set up as host, using a BeagleBoard, and with the current > linux-omap git I can get USB working by unplugging and replugging the > A side of the cable (at the mini-AB connector on the BeagleBoard). > > Just disconnecting the cable at the B side is not enough. It must > have something to do with the ID pin. So, if you have a soldered ID > pin it wouldn't work either. > > Also, my cable is going into a powered 4 port high speed hub. That > might make a difference. Same here -- 4 port high speed hub, disconnect/reconnect cable at the A (board) side. No joy on Overo. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: android on omap
> > Had problems with using NFS because Android tries to set specific permission > and ownership of files - and has a nasty habit of testing those permissions > frequently. If you have any local storage options - that would help. Also, > check your init.rc file for things like mount trying to remount the > filesystem readonly - Android assumes a very specific partition layout - > which can be consolidated into one partition as long as init.rc is adjusted > to match. > > Does the root file system reside on NFS? Have you enabled "Networking" while > configuring the kernel? > I've now moved filesystem to target (jffs2). Things are a little better, and different. Using logcat, I'm now seeing dalvikvm errors and warnings as shown below. Particularly odd since I wasn't seeing this error when rootfs was mounted via NFS. Any ideas? I really appreciate your input. Thanks, twebb D/dalvikvm( 483): DexOpt: --- BEGIN 'core.jar' (bootstrap=1) --- E/dalvikvm( 501): unable to mmap DEX cache: Invalid argument E/dalvikvm( 501): Optimization failed D/dalvikvm( 483): DexOpt: waiting for verify+opt, pid=501 W/dalvikvm( 483): DexOpt: --- END 'core.jar' --- status=0xff00, process failed E/dalvikvm( 483): Unable to extract+optimize DEX from '/system/framework/core.jar' D/dalvikvm( 483): Failed on '/system/framework/core.jar' (boot=1) D/dalvikvm( 483): VM cleaning up D/dalvikvm( 483): LinearAlloc 0x0 used 4100 of 4194304 (0%) W/dalvikvm( 483): JNI_CreateJavaVM failed E/AndroidRuntime( 483): JNI_CreateJavaVM failed -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current git head oops'es at boot on Overo
On Monday 06 October 2008, Nathan Monson wrote: > I'm set up as host, using a BeagleBoard, and with the current > linux-omap git I can get USB working by unplugging and replugging the > A side of the cable (at the mini-AB connector on the BeagleBoard). > > Just disconnecting the cable at the B side is not enough. It must > have something to do with the ID pin. So, if you have a soldered ID > pin it wouldn't work either. Right. That's a bug in the transciever support, note ... on host side there are TWO relevant cable events: ID pin grounded, and D+/D- rising. It only understands the former for now, and doesn't check for the state very well unless poked by an IRQ. (All that can be a PITA to get right. It helps to have a cable tester that will let you do things like switch the ID ground, apply a variable VBUS load, apply D+/D- pullups/pulldowns, and so on.) > Also, my cable is going into a powered 4 port high speed hub. That > might make a difference. That's what I was doing too. It's a common setup ... just a bit easier to preconfigure networking that way than through a bridgede configuration. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current git head oops'es at boot on Overo
On Monday 06 October 2008, Steve Sakoman wrote: > How does your kernel config set up musb -- host or OTG? Mine is set up as > host. For now, host-only. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current git head oops'es at boot on Overo
I'm set up as host, using a BeagleBoard, and with the current linux-omap git I can get USB working by unplugging and replugging the A side of the cable (at the mini-AB connector on the BeagleBoard). Just disconnecting the cable at the B side is not enough. It must have something to do with the ID pin. So, if you have a soldered ID pin it wouldn't work either. Also, my cable is going into a powered 4 port high speed hub. That might make a difference. - Nathan On Mon, Oct 6, 2008 at 2:04 PM, Steve Sakoman <[EMAIL PROTECTED]> wrote: > On Mon, Oct 6, 2008 at 12:53 PM, David Brownell <[EMAIL PROTECTED]> wrote: >> On Monday 06 October 2008, Steve Sakoman wrote: > >>> However unlike others, I find that musb is not functional -- and the >>> trick of disconnecting the USB cable and then reconnecting it does not >>> work. >> >> I observed the same thing. More specifically, no IRQs arrive at >> the twl4030-usb driver. >> >> The *very same kernel* works fine on Beagle... is there something >> different about the USB setup that might explain this? > > I took a look at the schematics for that section of both boards and as > far as I can tell the two boards are identical in their omap/twl4030 > interconnect for the musb section. The linux board files are > extremely similar too -- nothing significant as far as I can tell. > > I tried the same experiment and used my Overo kernel on Beagle. I got > exactly the same behavior on Beagle as I did on Overo. So my results > are different than yours. > > How does your kernel config set up musb -- host or OTG? Mine is set up as > host. > > Steve > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current git head oops'es at boot on Overo
On Mon, Oct 6, 2008 at 12:53 PM, David Brownell <[EMAIL PROTECTED]> wrote: > On Monday 06 October 2008, Steve Sakoman wrote: >> However unlike others, I find that musb is not functional -- and the >> trick of disconnecting the USB cable and then reconnecting it does not >> work. > > I observed the same thing. More specifically, no IRQs arrive at > the twl4030-usb driver. > > The *very same kernel* works fine on Beagle... is there something > different about the USB setup that might explain this? I took a look at the schematics for that section of both boards and as far as I can tell the two boards are identical in their omap/twl4030 interconnect for the musb section. The linux board files are extremely similar too -- nothing significant as far as I can tell. I tried the same experiment and used my Overo kernel on Beagle. I got exactly the same behavior on Beagle as I did on Overo. So my results are different than yours. How does your kernel config set up musb -- host or OTG? Mine is set up as host. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc7-omap1-git] beagle: two more GPIOs
From: David Brownell <[EMAIL PROTECTED]>
Request two more GPIOs on Beagle: MMC write protect, DVI enable.
Also define the first OMAP3 GPIO mux config symbols, with a new
naming convention. Examples:
- GPIO42 is bidirectional, and uses external pull up/down (if any);
- GPIO42_UP is bidirectional, with an internal pullup;
- GPIO42_DOWN is bidirectional, with an internal pulldown.
- GPIO42_OUT is output-only, and needs no pullup or pulldown.
All of those would be fully functional through the standard GPIO
interface as well as the legacy OMAP-only one, except GPIO42_OUT
which won't let you read the actual pin value after setting it.
There's no special off-mode support for these particular pins;
on Beagle they have external pullups or pulldowns.
(OMAP2 can use this naming convention too, except that since it
has no input-enable the "_OUT" convention can't be used there.)
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
REFRESHED against 2.6.27-rc8-omap-git as of today ...
arch/arm/mach-omap2/board-omap3beagle.c | 11 +++
arch/arm/mach-omap2/mux.c |8
arch/arm/plat-omap/include/mach/mux.h |8
3 files changed, 27 insertions(+)
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#define GPMC_CS0_BASE 0x60
@@ -291,7 +292,17 @@ static void __init omap3_beagle_init(voi
omap_board_config = omap3_beagle_config;
omap_board_config_size = ARRAY_SIZE(omap3_beagle_config);
omap_serial_init();
+
+ omap_cfg_reg(AH8_34XX_GPIO29);
+ gpio_request(29, "mmc0_wp");
+ gpio_direction_input(29);
hsmmc_init();
+
+ omap_cfg_reg(J25_34XX_GPIO170);
+ gpio_request(170, "DVI_nPD");
+ /* REVISIT leave DVI powered down until it's needed ... */
+ gpio_direction_output(170, true);
+
usb_musb_init();
usb_ehci_init();
omap3beagle_flash_init();
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -416,6 +416,14 @@ MUX_CFG_34XX("AD2_3430_USB3FS_PHY_MM3_TX
MUX_CFG_34XX("AC1_3430_USB3FS_PHY_MM3_TXEN_N", 0x18a,
OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
+
+/* 34XX GPIO - bidirectional, unless the name has an "_OUT" suffix.
+ * No internal pullup/pulldown without "_UP" or "_DOWN" suffix.
+ */
+MUX_CFG_34XX("AH8_34XX_GPIO29", 0x5fa,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
};
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
--- a/arch/arm/plat-omap/include/mach/mux.h
+++ b/arch/arm/plat-omap/include/mach/mux.h
@@ -749,6 +749,14 @@ enum omap34xx_index {
AD2_3430_USB3FS_PHY_MM3_TXDAT,
AC1_3430_USB3FS_PHY_MM3_TXEN_N,
+ /* 34xx GPIO
+* - normally these are bidirectional, no internal pullup/pulldown
+* - "_UP" suffix (GPIO3_UP) if internal pullup is configured
+* - "_DOWN" suffix (GPIO3_DOWN) with internal pulldown
+* - "_OUT" suffix (GPIO3_OUT) for output-only pins (unlike 24xx)
+*/
+ AH8_34XX_GPIO29,
+ J25_34XX_GPIO170,
};
struct omap_mux_cfg {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current git head oops'es at boot on Overo
On Monday 06 October 2008, Steve Sakoman wrote: > Build is stock 62c36fdd962de2db5d62a326490913f41c442a5c, no additional > patches. > > Without DEBUG_LL, boot silently fails. With DEBUG_LL, one can see that > the failure is due to a NULL pointer dereference in musb. > > I suspect that the root cause is related to: > > <3>i2c_omap i2c_omap.1: controller timed out > <4>twl4030_usb: probe of twl4030_usb failed with error -22 > > Adding David Brownell's i2c-omap timeout workaround patch eliminates > this error Right. I'd suggest merging that, except that would provide zero incentive to actually fix the i2c-omap problem. And I *have* seen those timeout errors on other requests... > and the boot then fails on EHCI. > > I disabled EHCI in defconfig and was able to get the boot to complete. Ditto. I suspect one of those no-timeout busy-waits is just neglecting to complete... :( > However unlike others, I find that musb is not functional -- and the > trick of disconnecting the USB cable and then reconnecting it does not > work. I observed the same thing. More specifically, no IRQs arrive at the twl4030-usb driver. The *very same kernel* works fine on Beagle... is there something different about the USB setup that might explain this? - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [RFC] clk: introduce clk_associate
On Mon, Oct 06, 2008 at 11:42:08AM -0700, David Brownell wrote: > They're all OMAP-specific drivers. They can know that they > need to ask for both clocks. If perchance only one of them > were actually needed, that would be exceptional ... and the > driver should be able to assume the device was properly > set up, and continue without it. exactly, look at the changes to watchdog driver for an example :-) if interface clock fails, we continue anyways since we could be using it in an omap1-based board. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [RFC] clk: introduce clk_associate
On Thursday 02 October 2008, Hiroshi DOYU wrote:
> For some of the above drivers, omap's "functional clock" and
> "interface clock" doesn't make sense.
Actually, I thought OMAP was pretty consistent about having
both on all modules where it made sense.
> For such device drivers, those
> clocks may look just a single necessary clock and there's no "one to
> one" correspondence from the omap clock functionality definitions
> ("ick"/"fck") perspective.
They're all OMAP-specific drivers. They can know that they
need to ask for both clocks. If perchance only one of them
were actually needed, that would be exceptional ... and the
driver should be able to assume the device was properly
set up, and continue without it.
> I think that this is one of the examples,
> where the flexibily is required. Since required functionaliies for
> clocks depends on each device drivers, I think that it would give a
> wider solution to let device drivers to define their logical
> clocks(functionality) flexibly(not 1-to-1), rather than statically
> pre-defined standardized functional names, which is the 1-to-1
> correspondence of ick and fck in the TRM with aliasing.
The ICK/FCK example is not IMO persuasive; this is OMAP, so
the assumption can be that all drivers have both.
Having the clocks set up by clk_associate() would suffice
for most devices and drivers. Are there ones where that's
not enough ... where a device needs more than those "logical"
clock identifiers?
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] alsa: add Beagleboard SoC configuration.
On Mon, Oct 06, 2008 at 11:01:53AM -0700, David Brownell wrote:
> On Monday 06 October 2008, Paul Walmsley wrote:
> > > [ INFO: possible recursive locking detected ]
> > > 2.6.27-rc8-omap1 #174
> > > -
> > > aplay/1816 is trying to acquire lock:
> > > (clockfw_lock){}, at: [] clk_enable+0x24/0x70
> > >
> > > but task is already holding lock:
> > > (clockfw_lock){}, at: [] clk_enable+0x24/0x70
> >
> > Yeah, the code that's in that driver is broken. The driver
> > sets up a custom clk_enable() function that calls clk_enable() again. And
> > clk_enable() takes clockfw_lock.
>
> I don't follow. Could you point at those lines of code?
> The only clkfw_lock I see is in plat-omap/clock.c code ...
> which isn't part of this ASoC driver or even its board glue.
>
>
> > The omap_clk_associate() code should resolve this problem.
>
> Time to resolve that, then... are you saying that the patches
> Felipe posted will, if merged, make this lockdep report go
> away so it's safe to run lockdep and ALSA on twl4030 codecs?
heh, I'll repost tomorrow changing the name to omap_clk_associate()
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Current git head oops'es at boot on Overo
Build is stock 62c36fdd962de2db5d62a326490913f41c442a5c, no additional patches. Without DEBUG_LL, boot silently fails. With DEBUG_LL, one can see that the failure is due to a NULL pointer dereference in musb. I suspect that the root cause is related to: <3>i2c_omap i2c_omap.1: controller timed out <4>twl4030_usb: probe of twl4030_usb failed with error -22 Adding David Brownell's i2c-omap timeout workaround patch eliminates this error and the boot then fails on EHCI. I disabled EHCI in defconfig and was able to get the boot to complete. However unlike others, I find that musb is not functional -- and the trick of disconnecting the USB cable and then reconnecting it does not work. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Compilation broken for 3430SDP defconfig
Ok, I just noticed from the mails what happened.. :) Sorry for the unnecessary alert. > -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-omap- > [EMAIL PROTECTED] On Behalf Of Aguirre Rodriguez, Sergio Alberto > Sent: Monday, October 06, 2008 1:20 PM > To: David Brownell; [EMAIL PROTECTED] > Cc: Gadiyar, Anand; linux-omap@vger.kernel.org; [EMAIL PROTECTED] > Subject: RE: Compilation broken for 3430SDP defconfig > > Hi all, > > Today I did a pull from the linux-omap tree, and I have this error in > compilation with the sdp defconfig: > > CC arch/arm/mach-omap2/board-3430sdp.o > arch/arm/mach-omap2/board-3430sdp.c:43:35: error: linux/i2c/twl4030-rtc.h: > No such file or directory > arch/arm/mach-omap2/board-3430sdp.c: In function 'msecure_init': > arch/arm/mach-omap2/board-3430sdp.c:132: warning: initialization makes > integer from pointer without a cast > make[1]: *** [arch/arm/mach-omap2/board-3430sdp.o] Error 1 > make: *** [arch/arm/mach-omap2] Error 2 > > So, I just did a git pull, then a git gc. I'm not seeing that > linux/i2c/twl4030-rtc.h file now. Has someone moved it? Or do you think it > could be something related to my clone? > > Regards, > Sergio > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:linux-omap- > > [EMAIL PROTECTED] On Behalf Of David Brownell > > Sent: Monday, October 06, 2008 11:42 AM > > To: [EMAIL PROTECTED] > > Cc: Gadiyar, Anand; linux-omap@vger.kernel.org; [EMAIL PROTECTED] > > Subject: Re: Compilation broken for 3430SDP defconfig > > > > On Monday 06 October 2008, Felipe Balbi wrote: > > > Yes, we need defconfig changes since Kconfig is not asking about the > new > > > CONFIG_GPIO_TWL4030 symbol added. > > > > I seem to have tested with "make oldconfig" not "make ..._defconfig". > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Compilation broken for 3430SDP defconfig
Hi all, Today I did a pull from the linux-omap tree, and I have this error in compilation with the sdp defconfig: CC arch/arm/mach-omap2/board-3430sdp.o arch/arm/mach-omap2/board-3430sdp.c:43:35: error: linux/i2c/twl4030-rtc.h: No such file or directory arch/arm/mach-omap2/board-3430sdp.c: In function 'msecure_init': arch/arm/mach-omap2/board-3430sdp.c:132: warning: initialization makes integer from pointer without a cast make[1]: *** [arch/arm/mach-omap2/board-3430sdp.o] Error 1 make: *** [arch/arm/mach-omap2] Error 2 So, I just did a git pull, then a git gc. I'm not seeing that linux/i2c/twl4030-rtc.h file now. Has someone moved it? Or do you think it could be something related to my clone? Regards, Sergio > -Original Message- > From: [EMAIL PROTECTED] [mailto:linux-omap- > [EMAIL PROTECTED] On Behalf Of David Brownell > Sent: Monday, October 06, 2008 11:42 AM > To: [EMAIL PROTECTED] > Cc: Gadiyar, Anand; linux-omap@vger.kernel.org; [EMAIL PROTECTED] > Subject: Re: Compilation broken for 3430SDP defconfig > > On Monday 06 October 2008, Felipe Balbi wrote: > > Yes, we need defconfig changes since Kconfig is not asking about the new > > CONFIG_GPIO_TWL4030 symbol added. > > I seem to have tested with "make oldconfig" not "make ..._defconfig". > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] alsa: add Beagleboard SoC configuration.
On Monday 06 October 2008, Paul Walmsley wrote:
> > [ INFO: possible recursive locking detected ]
> > 2.6.27-rc8-omap1 #174
> > -
> > aplay/1816 is trying to acquire lock:
> > (clockfw_lock){}, at: [] clk_enable+0x24/0x70
> >
> > but task is already holding lock:
> > (clockfw_lock){}, at: [] clk_enable+0x24/0x70
>
> Yeah, the code that's in that driver is broken. The driver
> sets up a custom clk_enable() function that calls clk_enable() again. And
> clk_enable() takes clockfw_lock.
I don't follow. Could you point at those lines of code?
The only clkfw_lock I see is in plat-omap/clock.c code ...
which isn't part of this ASoC driver or even its board glue.
> The omap_clk_associate() code should resolve this problem.
Time to resolve that, then... are you saying that the patches
Felipe posted will, if merged, make this lockdep report go
away so it's safe to run lockdep and ALSA on twl4030 codecs?
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compilation broken for 3430SDP defconfig
On Monday 06 October 2008, Felipe Balbi wrote: > Yes, we need defconfig changes since Kconfig is not asking about the new > CONFIG_GPIO_TWL4030 symbol added. I seem to have tested with "make oldconfig" not "make ..._defconfig". -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch twl 1/2] remove
On Monday 06 October 2008, Kevin Hilman wrote: > --- a/arch/arm/mach-omap2/board-3430sdp.c > +++ b/arch/arm/mach-omap2/board-3430sdp.c > @@ -40,7 +40,6 @@ > #include > #include > #include > -#include > > #include > #include Good catch -- my bad. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESENDING][PATCH 1/2]OMAP3 NAND: Add NAND support on OMAP3430
On Monday 06 October 2008, Tony Lindgren wrote: > > --- linux-omap-2.6_27_08_2008.orig/include/linux/mtd/nand.h > > +++ linux-omap-2.6_27_08_2008/include/linux/mtd/nand.h > > @@ -45,7 +45,7 @@ > > */ > > #define NAND_MAX_OOBSIZE 64 > > #define NAND_MAX_PAGESIZE2048 > > - > > +#define NAND_BLOCK_SIZE SZ_128K > > /* This is specific to 3430 SDP though ... there are plenty of other NAND block sizes in the world. Suggest moving this definition to board-3430sdp-flash.c where it's relevant. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lp5521: move to drivers/leds
On Monday 06 October 2008, mathias nyman wrote: > The driver for the next version of the lp552x chip uses the led class > for the direct mode That sounds like the way to start ... any reason why the current driver couldn't be changed do the same? This would seem like a good motivation to add some features to the LED framework. Here are three types of LED that it doesn't support well today: - Bicolor leds with two leads ... R-or-G, two wires, opposite diode directions. - Bicolor LEDs with three leads ... like R-and-Y, three wires, common anode or common cathode - RGB leds, four leads ... like R-and-G-and-B, etc Except for the first case, these can be stuffed into the framework by modeling them as multiple LEDs. But when you do that it gets awkward to make sure that for example you get a purple (+R, -G, +B) blink, since the timers need to be exactly in phase. Or to combine blinking with PWM, so you could for example mix in a little green... Surely some features that would support RGB (RG, YG, etc) LEDs better could support both fancy (lp5521) and simple (GPIO without PWM) implementations ... - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] ARM: OMAP2: Remove OMAP_PRM_REGADDR, OMAP_CM_REGADDR
On Thu, Oct 02, 2008 at 10:37:52AM -0600, Paul Walmsley wrote:
> From: Tony Lindgren <[EMAIL PROTECTED]>
>
> Remove OMAP_PRM_REGADDR and OMAP_CM_REGADDR. Use
> prm_read/write_mod_reg() or cm_read/write_mod_reg() instead. For
> assembly, use OMAP_PRM_REGADDR or OMAP_CM_REGADDR macros.
I do have concerns about this patch as well - hating those casts
that are required to store an offset in 'enable_reg', which then
have to be un-casted to add the correct base address.
I've been trying to work out if there's a better way to do this
using the existing structures. How about:
struct clk {
...
void __iomem*base;
struct clk *other_clk; /* associated func/interface clock */
u16 enable_offset;
u16 idlest_offset;
u16 clksel_offset;
u8 enable_bit;
u8 idlest_bit;
...
int (*enable)(struct clk *);
void(*disable)(struct clk *);
...
};
(or use u8 if the offsets always fit.)
The setup of apll96_ck becomes:
static struct clk apll96_ck = {
.name = "apll96_ck",
.parent = &sys_ck,
.rate = 9600,
.flags = CLOCK_IN_OMAP242X | CLOCK_IN_OMAP243X |
RATE_FIXED | RATE_PROPAGATES | ENABLE_ON_INIT,
.clkdm_name = "wkup_clkdm",
.enable_offset = CM_REG_OFFSET(PLL_MOD, CM_CLKEN),
.idlest_offset = CM_REG_OFFSET(PLL_MOD, CM_IDLEST),
.enable_bit = OFFSET_OF_BIT(EN_APLL_LOCKED <<
OMAP24XX_EN_96M_PLL_SHIFT),
.idlest_bit = OFFSET_OF_BIT(OMAP24XX_ST_96M_APLL),
.enable = clkll_enable32_and_wait,
.disable= clkll_disable32,
.recalc = &propagate_rate,
};
(replacing OFFSET_OF_BIT() with the appropriate real bit position number).
You register all such clocks thusly:
void clk_register_offset_clks(void __iomem *base, struct clk **clks, size_t num)
{
size_t i;
for (i = 0; i < num; i++) {
struct clk *clk = clks[i];
clk->base = base;
clk_register(clk);
}
}
static struct clk cm_clks[] = {
&apll96_ck,
};
clk_register_offset_clks(cm_base, cm_clks, ARRAY_SIZE(cm_clks);
and, eg, the accesses to the enable register become:
int clkll_enable32(struct clk *clk)
{
u32 val, mask = 1 << clk->enable_bit;
val = __raw_readl(clk->base + clk->enable_offset);
if (clk->flags & INVERT_ENABLE)
val &= ~mask;
else
val |= mask;
__raw_writel(val, clk->base + clk->enable_offset);
wmb();
return 0;
}
void clkll_disable32(struct clk *clk)
{
u32 val, mask = 1 << clk->enable_bit;
val = __raw_readl(clk->base + clk->enable_offset);
if (clk->flags & INVERT_ENABLE)
val |= mask;
else
val &= ~mask;
__raw_writel(val, clk->base + clk->enable_offset);
wmb();
}
int clkll_is_running32(struct clk *clk)
{
u32 val, mask = 1 << clk->enable_bit;
val = __raw_readl(clk->base + clk->enable_offset) & mask;
return clk->flags & INVERT_ENABLE ? !val : !!val;
}
int clkll_enable32_and_wait(struct clk *clk)
{
u32 mask, result, val;
unsigned int tries = 0;
if (!clkll_is_running32(clk))
clkll_enable32(clk);
/* check if other clock, if any, is running */
if (clk->other_clk && !clkll_is_running32(clk->other_clk))
return 0;
val = mask = 1 << clk->idlest_bit;
if (inverted_on_this_cpu)
val = 0;
for (tries = 0; tries < MAX_CLOCK_ENABLE_WAIT; tries++, udelay(1)) {
result = __raw_readl(clk->base + clk->idlest_offset) & mask;
if (result == val)
break;
}
if (result == val)
pr_debug("Clock %s stable after %uus\n", clk->name, tries);
else
pr_err("Clock %s failed to stablize after %uus\n",
clk->name, tries);
return result == val ? 0 : -ETIMEDOUT;
}
Then, you use clkll_enable32() if you don't need to wait for the clock
to stablize, or clkll_enable32_and_wait() if you do.
If you need 16-bit, which I think I've seen, obviously create the
corresponding versions.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc8-omap 4/7] twl4030-core cleanup
On Monday 06 October 2008, Felipe Balbi wrote: > would be nice to have the patch moving tlw4030-core to drivers/mfd > coming from you so we know everything is fine. That's in current OMAP git already ... 56d33dd99b13c4f18df838e766c595299f7e1e0f -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Compilation broken for 3430SDP defconfig
> -Original Message- > From: Felipe Balbi [mailto:[EMAIL PROTECTED] > On Mon, Oct 06, 2008 at 09:14:19PM +0530, Gadiyar, Anand wrote: > > CONFIG_GPIO_TWL4030 needs to be set in menuconfig otherwise, > > for OMAP3 defconfig we get the below build error. > > > > arch/arm/mach-omap2/built-in.o: In function `hsmmc_card_detect': > > /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:50: undefined reference to > > `twl4030_get_gpio_datain' > > arch/arm/mach-omap2/built-in.o: In function `hsmmc_cleanup': > > /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:82: undefined reference to > > `twl4030_free_gpio' > > arch/arm/mach-omap2/built-in.o: In function `hsmmc_late_init': > > /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:63: undefined reference to > > `twl4030_request_gpio' > > /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:67: undefined reference to > > `twl4030_set_gpio_debounce' > > make: *** [.tmp_vmlinux1] Error 1 > > Yes, we need defconfig changes since Kconfig is not asking about the new > CONFIG_GPIO_TWL4030 symbol added. > > That'll probably change soon when we start using standard gpio calls but > please, provide the defconfig change. You could even do it for all omap3 > plus 2430. Will it help if we have a 'default' option in drivers/gpio/Kconfig? Something like: + default y if ARCH_OMAP34XX || MACH_OMAP_2430SDP -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch/rfc/rft 2.6.27-rc8-omap-git] twl4030-pwrirq simplification, cleanup
On Monday 06 October 2008, Felipe Balbi wrote:
> On Mon, Oct 06, 2008 at 01:19:18AM -0700, David Brownell wrote:
> > ...
> >
> > (This is similar to the GPIO patch I just sent, but simpler
> > except for the impact on the few drivers thinking oddly
> > about IRQs. Those patches cover the key SIH modules, and
> > a similar one affects the PIH in twl4030-core.)
>
> What are the dependencies for this patch ? It doesn't apply cleanly.
Applies against current GIT with a few minor offsets caused
by the patch working around the i2c-omap timeouts. I've sent
that before; it's appended for reference.
---
drivers/i2c/chips/twl4030-pwrirq.c | 10 ++
1 file changed, 10 insertions(+)
--- a/drivers/i2c/chips/twl4030-pwrirq.c
+++ b/drivers/i2c/chips/twl4030-pwrirq.c
@@ -161,6 +161,8 @@ static int twl4030_pwrirq_thread(void *d
return 0;
}
+#include
+
static int __init twl4030_pwrirq_init(void)
{
int i, err;
@@ -168,8 +170,16 @@ static int __init twl4030_pwrirq_init(vo
twl4030_pwrirq_mask = 0xff;
twl4030_pwrirq_pending_unmask = 0;
+/* HEY: core already did this.
+ * But that's surely not why we
+ * sometimes see i2c timeouts here ...
+ */
+for (i = 0; i < 5; i++) {
err = twl4030_i2c_write_u8(TWL4030_MODULE_INT, twl4030_pwrirq_mask,
TWL4030_INT_PWR_IMR1);
+if (!err) break;
+msleep(10);
+}
if (err)
return err;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compilation broken for 3430SDP defconfig
On Mon, Oct 06, 2008 at 09:14:19PM +0530, Gadiyar, Anand wrote: > CONFIG_GPIO_TWL4030 needs to be set in menuconfig otherwise, > for OMAP3 defconfig we get the below build error. > > arch/arm/mach-omap2/built-in.o: In function `hsmmc_card_detect': > /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:50: undefined reference to > `twl4030_get_gpio_datain' > arch/arm/mach-omap2/built-in.o: In function `hsmmc_cleanup': > /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:82: undefined reference to > `twl4030_free_gpio' > arch/arm/mach-omap2/built-in.o: In function `hsmmc_late_init': > /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:63: undefined reference to > `twl4030_request_gpio' > /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:67: undefined reference to > `twl4030_set_gpio_debounce' > make: *** [.tmp_vmlinux1] Error 1 Yes, we need defconfig changes since Kconfig is not asking about the new CONFIG_GPIO_TWL4030 symbol added. That'll probably change soon when we start using standard gpio calls but please, provide the defconfig change. You could even do it for all omap3 plus 2430. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Compilation broken for 3430SDP defconfig
CONFIG_GPIO_TWL4030 needs to be set in menuconfig otherwise, for OMAP3 defconfig we get the below build error. arch/arm/mach-omap2/built-in.o: In function `hsmmc_card_detect': /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:50: undefined reference to `twl4030_get_gpio_datain' arch/arm/mach-omap2/built-in.o: In function `hsmmc_cleanup': /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:82: undefined reference to `twl4030_free_gpio' arch/arm/mach-omap2/built-in.o: In function `hsmmc_late_init': /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:63: undefined reference to `twl4030_request_gpio' /share/anand/tony/arch/arm/mach-omap2/hsmmc.c:67: undefined reference to `twl4030_set_gpio_debounce' make: *** [.tmp_vmlinux1] Error 1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] ARM: OMAP: Fix sparse, checkpatch warnings in OMAP2/3 PRCM/PM code
On Mon, 6 Oct 2008, Russell King - ARM Linux wrote: > On Mon, Oct 06, 2008 at 08:52:46AM -0600, Paul Walmsley wrote: > > OK. Tony's tree contains some patches which thoroughly clean this > > function up, but they are large. Would you like me to send those along > > with this patch set, or would you prefer that I just drop this part of the > > patch and repost? > > Probably the most productive solution is to drop that part and repost. Will do. > However, my thoughts from looking over the existing clock code is that, > at some point, I'd like to rewrite the entire OMAP clk code to get rid > of stuff like this. Realistically, I'm scared to do so - the current > implementation is very complex that getting a proper overview is rather > difficult... Perhaps the current code in Tony's tree at: http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/clock.c;h=c3af24e8e3e557029f3cc07a7c8384d3a4befdd2;hb=HEAD#l298 is more reasonable? (human readable reference: line 298 of arch/arm/mach-omap2/clock.c) - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP clock updates for post 2.6.27
On Mon, Oct 06, 2008 at 08:48:38AM -0600, Paul Walmsley wrote: > On Thu, 2 Oct 2008, Russell King - ARM Linux wrote: > > > On Thu, Oct 02, 2008 at 10:37:46AM -0600, Paul Walmsley wrote: > > > The series can be pulled from: > > > > > >git://git.pwsan.com/linux-2.6 omap-clock-upstream > > > > > > The branch is based on rmk/devel, since powerdomain and clockdomain > > > changes are not yet in mainline. > > > > I assume then you haven't read the top commit on my devel branch, which > > reads: > > > > DO NOT BASE YOUR TREE ON THE DEVEL BRANCH > > > > Merge branch 'master' into devel > > > > The reason is that 'devel' is a convenience merge branch of currently > > about 25 other sub-branches for people who want to get the entire lot > > of changes. As such, the merges found there are frequently discarded > > and recreated. > > Sorry about that - thanks for the explanation. > > > If you want something more stable and omap related, that can be > > arranged. > > That would be great. Is this the omap-all branch? Yes - I doubt that there'll be many differences in the changes between the two, so probably just rebasing them will be sufficient. (FYI, you can rebase a range of commits onto another branch using 'git rebase' - git rebase --onto target-branch first-commit^ branch-name - see the help.) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] alsa: add Beagleboard SoC configuration.
Hi David,
On Fri, 3 Oct 2008, David Brownell wrote:
> On Tuesday 16 September 2008, Felipe Contreras wrote:
> > This is exactly the same as the overo configuration. It might make sense
> > to have them in a single one.
>
> I got a hard lockup (no timer ticking), no blinkenlights, etc ...
> doesn't look like the issue is *this* driver.
...
> [ INFO: possible recursive locking detected ]
> 2.6.27-rc8-omap1 #174
> -
> aplay/1816 is trying to acquire lock:
> (clockfw_lock){}, at: [] clk_enable+0x24/0x70
>
> but task is already holding lock:
> (clockfw_lock){}, at: [] clk_enable+0x24/0x70
Yeah, the code that's in that driver is broken. The driver
sets up a custom clk_enable() function that calls clk_enable() again. And
clk_enable() takes clockfw_lock.
The omap_clk_associate() code should resolve this problem.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] ARM: OMAP: Fix sparse, checkpatch warnings in OMAP2/3 PRCM/PM code
On Mon, Oct 06, 2008 at 08:52:46AM -0600, Paul Walmsley wrote: > OK. Tony's tree contains some patches which thoroughly clean this > function up, but they are large. Would you like me to send those along > with this patch set, or would you prefer that I just drop this part of the > patch and repost? Probably the most productive solution is to drop that part and repost. However, my thoughts from looking over the existing clock code is that, at some point, I'd like to rewrite the entire OMAP clk code to get rid of stuff like this. Realistically, I'm scared to do so - the current implementation is very complex that getting a proper overview is rather difficult... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch twl 1/2] remove
David Brownell <[EMAIL PROTECTED]> writes: > From: David Brownell <[EMAIL PROTECTED]> > > Remove by moving all the relevant contents > into the driver itself, and removing the rest. Stuff removed included > many useless bitmasks, and remnants of the platform data hook. > > Add markers inside the rtc driver to split sections apart: first > data structure declarations, then the RTC driver, then platform bus > glue for it all. > > There's still an issue with the twl4030-pwrirq.h registers ... this > driver has no business touching them! This patch at least switches > away from having private versions of those register definitions, and > removes some unnecessary accesses to them. > > No functional changes, just shrinkage. > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> In addition, remove the #include of twl4030-rtc.h from board-3430sdp.c Kevin >From aa394ce81d3c63f64ae27e89c2588950aaee2995 Mon Sep 17 00:00:00 2001 From: Kevin Hilman <[EMAIL PROTECTED]> Date: Mon, 6 Oct 2008 17:52:43 +0300 Subject: [PATCH] ARM: OMAP3: Remove include of removed twl4030-rtc.h Signed-off-by: Kevin Hilman <[EMAIL PROTECTED]> --- arch/arm/mach-omap2/board-3430sdp.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index 4264b68..56f28ae 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -40,7 +40,6 @@ #include #include #include -#include #include #include -- 1.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] ARM: OMAP: Fix sparse, checkpatch warnings in OMAP2/3 PRCM/PM code
Hello Russell,
On Sat, 4 Oct 2008, Russell King - ARM Linux wrote:
> On Thu, Oct 02, 2008 at 10:37:50AM -0600, Paul Walmsley wrote:
> > static void omap2_clk_wait_ready(struct clk *clk)
> > {
> > - void __iomem *reg, *other_reg, *st_reg;
> > - u32 bit;
> > -
> > - /*
> > -* REVISIT: This code is pretty ugly. It would be nice to generalize
> > -* it and pull it into struct clk itself somehow.
> > -*/
> > - reg = clk->enable_reg;
> > - if u32)reg & 0xff) >= CM_FCLKEN1) &&
> > - (((u32)reg & 0xff) <= OMAP24XX_CM_FCLKEN2))
> > - other_reg = (void __iomem *)(((u32)reg & ~0xf0) | 0x10); /*
> > CM_ICLKEN* */
> > - else if u32)reg & 0xff) >= CM_ICLKEN1) &&
> > -(((u32)reg & 0xff) <= OMAP24XX_CM_ICLKEN4))
> > - other_reg = (void __iomem *)(((u32)reg & ~0xf0) | 0x00); /*
> > CM_FCLKEN* */
> > + u32 bit, other_reg, st_reg;
> > + unsigned long reg;
> > +
> > + reg = (unsigned long)clk->enable_reg;
> > + if (((reg & 0xff) >= CM_FCLKEN1) &&
> > + ((reg & 0xff) <= OMAP24XX_CM_FCLKEN2))
> > + other_reg = ((reg & ~0xf0) | 0x10); /* CM_ICLKEN* */
> > + else if (((reg & 0xff) >= CM_ICLKEN1) &&
> > +((reg & 0xff) <= OMAP24XX_CM_ICLKEN4))
> > + other_reg = ((reg & ~0xf0) | 0x00); /* CM_FCLKEN* */
> > else
> > return;
> >
> > /* REVISIT: What are the appropriate exclusions for 34XX? */
> > /* No check for DSS or cam clocks */
> > - if (cpu_is_omap24xx() && ((u32)reg & 0x0f) == 0) { /* CM_{F,I}CLKEN1 */
> > + if (cpu_is_omap24xx() && (reg & 0x0f) == 0) { /* CM_{F,I}CLKEN1 */
> > if (clk->enable_bit == OMAP24XX_EN_DSS2_SHIFT ||
> > clk->enable_bit == OMAP24XX_EN_DSS1_SHIFT ||
> > clk->enable_bit == OMAP24XX_EN_CAM_SHIFT)
> > @@ -249,25 +245,25 @@ static void omap2_clk_wait_ready(struct clk *clk)
> > /* REVISIT: What are the appropriate exclusions for 34XX? */
> > /* OMAP3: ignore DSS-mod clocks */
> > if (cpu_is_omap34xx() &&
> > - (((u32)reg & ~0xff) == (u32)OMAP_CM_REGADDR(OMAP3430_DSS_MOD, 0) ||
> > -u32)reg & ~0xff) == (u32)OMAP_CM_REGADDR(CORE_MOD, 0)) &&
> > -clk->enable_bit == OMAP3430_EN_SSI_SHIFT)))
> > + ((reg & ~0xff) == (u32)OMAP_CM_REGADDR(OMAP3430_DSS_MOD, 0) ||
> > +(((reg & ~0xff) == (u32)OMAP_CM_REGADDR(CORE_MOD, 0)) &&
> > + clk->enable_bit == OMAP3430_EN_SSI_SHIFT)))
> > return;
> >
> > /* Check if both functional and interface clocks
> > * are running. */
> > bit = 1 << clk->enable_bit;
> > - if (!(__raw_readl(other_reg) & bit))
> > + if (!(__raw_readl((void __iomem *)other_reg) & bit))
>
> This isn't an improvement. Moving casts to the readl/writel macros is
> a definite no no.
OK. Tony's tree contains some patches which thoroughly clean this
function up, but they are large. Would you like me to send those along
with this patch set, or would you prefer that I just drop this part of the
patch and repost?
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] OMAP clock updates for post 2.6.27
On Thu, 2 Oct 2008, Russell King - ARM Linux wrote: > On Thu, Oct 02, 2008 at 10:37:46AM -0600, Paul Walmsley wrote: > > The series can be pulled from: > > > >git://git.pwsan.com/linux-2.6 omap-clock-upstream > > > > The branch is based on rmk/devel, since powerdomain and clockdomain > > changes are not yet in mainline. > > I assume then you haven't read the top commit on my devel branch, which > reads: > > DO NOT BASE YOUR TREE ON THE DEVEL BRANCH > > Merge branch 'master' into devel > > The reason is that 'devel' is a convenience merge branch of currently > about 25 other sub-branches for people who want to get the entire lot > of changes. As such, the merges found there are frequently discarded > and recreated. Sorry about that - thanks for the explanation. > If you want something more stable and omap related, that can be > arranged. That would be great. Is this the omap-all branch? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] New PM branch: pm-20081006
Hello, The latest PM branch, is now available in the linux-omap tree. The git-shortlog is below[1], but from a high level, this branch includes support for - full-chip retention in dynamic idle - full-chip retention in suspend - full-chip OFF in dynamic idle - full-chip OFF in suspend The choice of retention versus off-mode can be selected using /sys/power/enable_off_mode (zero by default.) Tested on 3430SDP. To test: # echo 1 > /sys/power/clocks_off_while_idle # echo 1 > /sys/power/sleep_while_idle # echo 1 > /sys/power/voltage_off_while_idle and optionally for off-mode # echo 1 > /sys/power/enable_off_mode Kevin [1] git shortlog: Amit Kucheria (2): PM: Typo fix for clock_allow_idle HSMMC: Make driver support dynamic idle Kalle Jokiniemi (3): OMAP3: Remove CONFIG_OMAP_SYSOFFMODE flag OMAP: Sysfs interface for enabling voltage off in idle OMAP3: OFF command integration Kevin Hilman (5): ARM: OMAP3: HSMMC: Ensure HSMMC is fully reset on boot PM: serial: ensure padconf wake-enable bits are set for UARTs ARM: OMAP3: PM: allow runtime enable/disable of OFF mode TEMP: Merge into IRQ save/restore patch ARM: OMAP3: PM: remove unused 'context_mem' var from sleep34xx.S Paul Walmsley (1): OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer. Rajendra Nayak (16): OMAP3: Adds missing CM offset defs OMAP3: GPMC context save/restore OMAP3: Serial context save/restore OMAP3: GPIO context save/restore OMAP3: I2C context save/restore OMAP3: INTC context save/restore OMAP3: PRCM context save/restore OMAP3: Populate scratchpad contents OMAP3: SCM context save/restore OMAP3: SRAM restore function OMAP3: PER/NEON/CORE control in idle OMAP3: Restore MMU table entry OMAP3: MPU Off support OMAP3: CORE Off support OMAP3: Dynamic enable/disable of OFF support OMAP3: 3430SDP minimal kernel defconfig Tero Kristo (2): PM: Added sleep support to UART PM debug support for 34xx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
HTTP url not working
Hi,
The http url doesn't seem to be working anymore:
http://www.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
Can you?
mv .git/post-update{.sample,}
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/05] ARM: OMAP2: Add support for the Gumstix Overo board (rev 3)
* Tony Lindgren <[EMAIL PROTECTED]> [081003 15:47]:
> * Tony Lindgren <[EMAIL PROTECTED]> [081003 15:26]:
> > From: Steve Sakoman <[EMAIL PROTECTED]>
> >
> > This patch adds support for basic features: nand, uarts, i2c,
> > mmc, rtc, and usb
>
> Hmm, looks like I need to update this description as mmc and
> usb code is not ready yet.
Here's this one updated. I also added the missing call to
omap2_init_common_hw() to get overo booting.
Tony
>From 84f97a65a3dec412a32ed7e9d2f308fd4f45625e Mon Sep 17 00:00:00 2001
From: Steve Sakoman <[EMAIL PROTECTED]>
Date: Mon, 6 Oct 2008 15:52:56 +0300
Subject: [PATCH] ARM: OMAP2: Add support for the Gumstix Overo board (rev 3)
This patch adds minimal overo support.
Signed-off-by: Steve Sakoman <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 23fd1cc..aef043b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -48,3 +48,6 @@ config MACH_OMAP3_BEAGLE
bool "OMAP3 BEAGLE board"
depends on ARCH_OMAP3 && ARCH_OMAP34XX
+config MACH_OVERO
+ bool "Gumstix Overo board"
+ depends on ARCH_OMAP3 && ARCH_OMAP34XX
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 420ad9a..feb9caf 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o
obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o
+obj-$(CONFIG_MACH_OVERO) += board-overo.o
diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
new file mode 100644
index 000..e09aa59
--- /dev/null
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -0,0 +1,242 @@
+/*
+ * board-overo.c (Gumstix Overo)
+ *
+ * Initial code: Steve Sakoman <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NAND_BLOCK_SIZE SZ_128K
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE 0x30
+
+static struct mtd_partition overo_nand_partitions[] = {
+ {
+ .name = "xloader",
+ .offset = 0, /* Offset = 0x0 */
+ .size = 4 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE
+ },
+ {
+ .name = "uboot",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 14 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "uboot environment",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x24 */
+ .size = 2 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "linux",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 32 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "rootfs",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x68 */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct omap_nand_platform_data overo_nand_data = {
+ .parts = overo_nand_partitions,
+ .nr_parts = ARRAY_SIZE(overo_nand_partitions),
+ .dma_channel = -1, /* disable DMA in OMAP NAND driver */
+};
+
+static struct resource overo_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device overo_nand_device = {
+ .name = "omap2-nand",
+ .id = -1,
+ .dev = {
+ .platform_data = &overo_nand_data,
+ },
+ .num_resources = 1,
+ .resource = &overo_nand_resource,
+};
+
+
+static void __init overo_flash_init(void)
+{
+ u8 cs = 0;
+ u8 nandcs = GPMC_CS_NUM + 1;
+
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ /* find out the chip-select on which NAND exists */
+ while (cs < GPMC_CS_NUM) {
+ u32 ret = 0;
+ ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+ if ((ret & 0xC00) == 0x800) {
+ printk(KERN_INFO "Found NAND on CS%d\n", cs);
+ if (nandcs > GPMC_CS_NUM)
+nandcs = cs;
+ }
+ cs++;
+ }
+
+ if (nandcs > GPMC_CS_NUM) {
+ printk(KERN_INFO "NAND: Unable to find configuration "
+ "in GPMC\n ");
+ return;
+ }
+
+ if (nandcs < GPMC_CS_NUM) {
+ overo_nand_data.cs = nandcs;
+ overo_nand_data.gpmc_cs_baseaddr = (void *)
+ (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE);
+ overo_n
Re: [PATCH 01/05] ARM: OMAP2: Add minimal omap3430 support
* Tony Lindgren <[EMAIL PROTECTED]> [081005 11:15]:
> On Fri, Oct 03, 2008 at 03:09:35PM +0300, Tony Lindgren wrote:
> > Add minimal omap3430 support based on earlier patches from
> > Syed Mohammed Khasim. Also merge in omap34xx SRAM support
> > from Karthik Dasu and use consistent naming for sram init
> > functions.
> >
> > Also do following changes that make 34xx support usable:
> >
> > - Rename IRQ_SIR_IRQ to INTCPS_SIR_IRQ and define it locally
> > in entry-macro.S
> >
> > - Update mach-omap2/io.c to support 2420, 2430, and 34xx
> >
> > - Also merge in 34xx GPMC changes to add fields wr_access and
> > wr_data_mux_bus from Adrian Hunter
> >
> > - Remove memory initialization call omap2_init_memory() until
> > until more generic memory initialization patches are posted.
> > It's OK to rely on bootloader initialization until then.
> >
> > Signed-off-by: Syed Mohammed Khasim <[EMAIL PROTECTED]>
> > Signed-off-by: Karthik Dasu<[EMAIL PROTECTED]>
> > Signed-off-by: Adrian Hunter <[EMAIL PROTECTED]>
> > Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
>
>
>
> Looks like there are at least some formatting issues with the sram code
> above. Will check and repost this patch on Monday.
Here's this one cleaned up a bit. I also merged in few more
pin mux configurations.
> Tony
>From e017570454eaa3d664106867841db6b92c1c2651 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <[EMAIL PROTECTED]>
Date: Mon, 6 Oct 2008 15:52:32 +0300
Subject: [PATCH] ARM: OMAP3: Add minimal omap3430 support
Add minimal omap3430 support based on earlier patches from
Syed Mohammed Khasim. Also merge in omap34xx SRAM support
from Karthik Dasu and use consistent naming for sram init
functions.
Also do following changes that make 34xx support usable:
- Remove unused sram.c functions for 34xx
- Rename IRQ_SIR_IRQ to INTCPS_SIR_IRQ and define it locally
in entry-macro.S
- Update mach-omap2/io.c to support 2420, 2430, and 34xx
- Also merge in 34xx GPMC changes to add fields wr_access and
wr_data_mux_bus from Adrian Hunter
- Remove memory initialization call omap2_init_memory() until
until more generic memory initialization patches are posted.
It's OK to rely on bootloader initialization until then.
Signed-off-by: Syed Mohammed Khasim <[EMAIL PROTECTED]>
Signed-off-by: Karthik Dasu<[EMAIL PROTECTED]>
Signed-off-by: Adrian Hunter <[EMAIL PROTECTED]>
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 703a44f..552ea6d 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -118,6 +118,7 @@ endif
machine-$(CONFIG_ARCH_IXP23XX):= ixp23xx
machine-$(CONFIG_ARCH_OMAP1) := omap1
machine-$(CONFIG_ARCH_OMAP2) := omap2
+ machine-$(CONFIG_ARCH_OMAP3) := omap2
plat-$(CONFIG_ARCH_OMAP) := omap
machine-$(CONFIG_ARCH_S3C2410) := s3c2410 s3c2400 s3c2412 s3c2440 s3c2442 s3c2443
plat-$(CONFIG_PLAT_S3C24XX) := s3c24xx
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 7069c9d..e2481e4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -15,8 +15,17 @@ config ARCH_OMAP2430
bool "OMAP2430 support"
depends on ARCH_OMAP24XX
+config ARCH_OMAP34XX
+ bool "OMAP34xx Based System"
+ depends on ARCH_OMAP3
+
+config ARCH_OMAP3430
+ bool "OMAP3430 support"
+ depends on ARCH_OMAP3 && ARCH_OMAP34XX
+ select ARCH_OMAP_OTG
+
comment "OMAP Board Type"
- depends on ARCH_OMAP2
+ depends on ARCH_OMAP2 || ARCH_OMAP3
config MACH_OMAP_GENERIC
bool "Generic OMAP board"
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 800639e..0dc40db 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
# Functions loaded to SRAM
obj-$(CONFIG_ARCH_OMAP2420) += sram242x.o
obj-$(CONFIG_ARCH_OMAP2430) += sram243x.o
+obj-$(CONFIG_ARCH_OMAP3) += sram34xx.o
# Power Management
ifeq ($(CONFIG_PM),y)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 149bfba..375ad27 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -220,6 +220,11 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
+ if (cpu_is_omap34xx()) {
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
+ }
+
/* caller is expected to have initialized CONFIG1 to cover
* at least sync vs async
*/
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 03c6ab1..71a9de3 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -43,7 +43,9 @@
* The machine specific code may provide the extra mapping besides the
* default mapping provided here.
*/
-static struct map_desc omap2_io_desc[] __initdata = {
+
+#ifdef CONFIG_ARCH_OMAP24XX
+static struct map_desc omap24xx_io_desc[] __initdata = {
{
.virtual = L3_24XX_VIRT,
.pfn = __phy
Re: [PATCH 3/3] lp5521: move to drivers/leds
Felipe Balbi wrote: On Mon, Oct 06, 2008 at 03:54:57PM +0300, ext Riku Voipio wrote: On Mon, Oct 06, 2008 at 02:51:03PM +0300, Felipe Balbi wrote: On Mon, Oct 06, 2008 at 02:17:23PM +0300, Tony Lindgren wrote: * Riku Voipio <[EMAIL PROTECTED]> [081006 14:09]: On Mon, Oct 06, 2008 at 12:11:31PM +0300, Felipe Balbi wrote: This driver should be sitting together with the other led drivers. But this driver actually doesn't implement the led sysfs interface. If the driver is changed to implement the led framework interface, we break the existing n810 userland and expose only limited subset of lp5521 features for userland.. Maybe this feature should be a distro specific hack on top of the mainline tree? the problem is that led api (afaict) doesn't really have abstraction for rgb leds like the one we use. It can only handle blinky leds and on/off transitions and we need more functionality. RGB can somewhat be handled, by creating three led devices: n810:red:foo n810:gree:foo n810:blue:foo If that's the case I'd expect the driver author to do it since I have no time left for that. A few fixes here and there to the driver is fine and preparing the driver for mainline integration is also fine since it's a simple cp iteration. The driver and chip supports lots of functionality that is not yet in the led framework. Even if there is now support for some "Hardware accelerated blink of LEDs" it is not enough. The lp5521 chip can be programmed with blinking patterns including fades, triggers between R, G and B channels and other nice features Chip has three modes: direct,(set brightness of leds directly through sysfs) load (load a pattern to channel) and run. RGB direct mode could be handled with three led devices but the rest of the functionality is a bit trickier. Patterns are mainly used in n810 as it doesn't require any CPU interaction At the time of writing this driver led-class.txt stated that: "Some leds can be programmed to flash in hardware. As this isn't a generic LED device property, this should be exported as a device specific sysfs attribute rather than part of the class if this functionality is required." The driver for the next version of the lp552x chip uses the led class for the direct mode -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/10] HDQ driver: Remove global pointer
- Original Message - From: "Tony Lindgren" <[EMAIL PROTECTED]> To: "Evgeniy Polyakov" <[EMAIL PROTECTED]> Cc: "Gadiyar, Anand" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; ; "Chikkature Rajashekar, Madhusudhan" <[EMAIL PROTECTED]> Sent: Monday, October 06, 2008 4:01 PM Subject: Re: [PATCH 1/10] HDQ driver: Remove global pointer >* Evgeniy Polyakov <[EMAIL PROTECTED]> [081006 12:36]: >> Hi. >> >> On Mon, Oct 06, 2008 at 12:17:06PM +0300, Tony Lindgren ([EMAIL PROTECTED]) >> wrote: >> > Great, pushing to linux-omap tree. >> > >> > Evgeniy, are these already in your queue for upstream? >> >> Not really, since I do not follow omap tree and will not be able to >> handle dependency there. Please push w1 part when appropriate changes in >> the arch tree are ready. > > * Madhusudhan Chikkature <[EMAIL PROTECTED]> [081006 12:38]: >> >> These patches are against the L-o tree. We need to send the complete > driver patches against the LKML kernel tree to Evgeniy. > > OK, Madhu, can you please do the patches against the mainline kernel > for Evgeniy? I will create the patches and send them to Evgeniy. Regards, Madhu > > Tony > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lp5521: move to drivers/leds
On Mon, Oct 06, 2008 at 03:54:57PM +0300, ext Riku Voipio wrote: > On Mon, Oct 06, 2008 at 02:51:03PM +0300, Felipe Balbi wrote: > > On Mon, Oct 06, 2008 at 02:17:23PM +0300, Tony Lindgren wrote: > > > * Riku Voipio <[EMAIL PROTECTED]> [081006 14:09]: > > > > On Mon, Oct 06, 2008 at 12:11:31PM +0300, Felipe Balbi wrote: > > > > > This driver should be sitting together with the other > > > > > led drivers. > > > > > > > > But this driver actually doesn't implement the led sysfs interface. > > > > If the driver is changed to implement the led framework interface, > > > > we break the existing n810 userland and expose only limited subset > > > > of lp5521 features for userland.. > > > > > > Maybe this feature should be a distro specific hack on top of > > > the mainline tree? > > > > the problem is that led api (afaict) doesn't really have abstraction for > > rgb leds like the one we use. It can only handle blinky leds and on/off > > transitions and we need more functionality. > > RGB can somewhat be handled, by creating three led devices: > > n810:red:foo > n810:gree:foo > n810:blue:foo If that's the case I'd expect the driver author to do it since I have no time left for that. A few fixes here and there to the driver is fine and preparing the driver for mainline integration is also fine since it's a simple cp iteration. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lp5521: move to drivers/leds
On Mon, Oct 06, 2008 at 02:51:03PM +0300, Felipe Balbi wrote: > On Mon, Oct 06, 2008 at 02:17:23PM +0300, Tony Lindgren wrote: > > * Riku Voipio <[EMAIL PROTECTED]> [081006 14:09]: > > > On Mon, Oct 06, 2008 at 12:11:31PM +0300, Felipe Balbi wrote: > > > > This driver should be sitting together with the other > > > > led drivers. > > > > > > But this driver actually doesn't implement the led sysfs interface. > > > If the driver is changed to implement the led framework interface, > > > we break the existing n810 userland and expose only limited subset > > > of lp5521 features for userland.. > > > > Maybe this feature should be a distro specific hack on top of > > the mainline tree? > > the problem is that led api (afaict) doesn't really have abstraction for > rgb leds like the one we use. It can only handle blinky leds and on/off > transitions and we need more functionality. RGB can somewhat be handled, by creating three led devices: n810:red:foo n810:gree:foo n810:blue:foo blinking could also be done, but that would be suboptimal. Mainly we would lose all the cool fading etc stuff than can be programmed to run on lp5521 without main cpu intervention.. > This driver will probably loop around for a while until we find out that > led api needs to be extended. Or implement a minimal led api (off/brightness) as well as keep the custom interface for time being, if that's ok with Richard (the led subsystem maintainer). -- "rm -rf" only sounds scary if you don't have backups -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: mmc: fix compile breakage on board-n800-mmc.c
* Felipe Balbi <[EMAIL PROTECTED]> [081006 14:50]: > On Mon, Oct 06, 2008 at 01:32:27PM +0300, Jarkko Nikula wrote: > > On Mon, 6 Oct 2008 12:09:22 +0300 > > "ext Felipe Balbi" <[EMAIL PROTECTED]> wrote: > > > > > Commit 81d2c7d87a9c1eb724788fce7312922effa1b1ae broke > > > compilation of board-n800-mmc.c, this patch fixes it. > > > > > > Still n810 doesn't boot anymore with current linux-omap. > > > Will look into that soon. > > > > > > Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]> > > > --- > > > arch/arm/mach-omap2/board-n800-mmc.c |6 +++--- > > > 1 files changed, 3 insertions(+), 3 deletions(-) > > > > > Heh, I did the very same patch already last week :-) > > > > http://marc.info/?l=linux-omap&m=122286380121424&w=2 > > > > I'm not sure but I think N810 was booting then. Or I was using N800. > > cool, let's push your patch then ;-) Sorry already pushed Felipe's version. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lp5521: move to drivers/leds
On Mon, Oct 06, 2008 at 02:17:23PM +0300, Tony Lindgren wrote: > * Riku Voipio <[EMAIL PROTECTED]> [081006 14:09]: > > On Mon, Oct 06, 2008 at 12:11:31PM +0300, Felipe Balbi wrote: > > > This driver should be sitting together with the other > > > led drivers. > > > > But this driver actually doesn't implement the led sysfs interface. > > If the driver is changed to implement the led framework interface, > > we break the existing n810 userland and expose only limited subset > > of lp5521 features for userland.. > > Maybe this feature should be a distro specific hack on top of > the mainline tree? the problem is that led api (afaict) doesn't really have abstraction for rgb leds like the one we use. It can only handle blinky leds and on/off transitions and we need more functionality. This driver will probably loop around for a while until we find out that led api needs to be extended. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: mmc: fix compile breakage on board-n800-mmc.c
On Mon, Oct 06, 2008 at 01:32:27PM +0300, Jarkko Nikula wrote: > On Mon, 6 Oct 2008 12:09:22 +0300 > "ext Felipe Balbi" <[EMAIL PROTECTED]> wrote: > > > Commit 81d2c7d87a9c1eb724788fce7312922effa1b1ae broke > > compilation of board-n800-mmc.c, this patch fixes it. > > > > Still n810 doesn't boot anymore with current linux-omap. > > Will look into that soon. > > > > Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]> > > --- > > arch/arm/mach-omap2/board-n800-mmc.c |6 +++--- > > 1 files changed, 3 insertions(+), 3 deletions(-) > > > Heh, I did the very same patch already last week :-) > > http://marc.info/?l=linux-omap&m=122286380121424&w=2 > > I'm not sure but I think N810 was booting then. Or I was using N800. cool, let's push your patch then ;-) -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linux-fbdev-devel] [PATCH] OMAP 2/3 V4L2 display driver on video planes
On Mon, 6 Oct 2008, Shah, Hardik wrote:
> > -Original Message-
> > From: Hans Verkuil [mailto:[EMAIL PROTECTED]
> > On Monday 06 October 2008 08:06:30 Shah, Hardik wrote:
> > > > -Original Message-
> > > > From: Mauro Carvalho Chehab [mailto:[EMAIL PROTECTED]
> > > 4. VIDIOC_S/G_OMAP2_COLORKEY: Color keying allows the pixels with
> > > the defined color on the video pipelines to be replaced with the
> > > pixels on the graphics pipelines. I believe similar feature must be
> > > available on almost all next generation of video hardware. We can add
> > > new ioctl for this feature in V4L2 framework. I think VIDIOC_S_FBUF
> > > ioctl is used for setting up the buffer parameters on per buffer
> > > basis. So IMHO this ioctl is not a natural fit for the above
> > > functionality. Please provide your comments on same.
> >
> > Do I understand correctly that if the color in the *video* streams
> > matches the colorkey, then it is replaced by the color in the
> > *framebuffer* (aka menu/overlay)? Usually it is the other way around:
> > if the framebuffer (menu) has chromakey pixels, then those pixels are
> > replaced by pixels from the video stream. That's what the current API
> > does
> [Shah, Hardik] This is a hardware provided feature. It can be both ways as
> hardware supports both the features. It means replacing the graphics
> pipelines pixels with video pipeline pixels and other way is also true.
> When both graphics and video pipelines are going to the same output device
> and when the colorkeying is enabled then the pixels of the video pipelines
> of specific color are replaced by the pixels of the graphics pipeline.
> This is done automatically done by the overlay manager aka compositor.
> Graphics pipeline can be controlled by frame buffer interface or V4L2
> interface.
> In driver we only need to enable the color keying and state that whether
> it is a source color keying or destination color keying along with the
> color code.
As video input usually contains noise: is it an exact color match, or a
range? IIRC, I saw a similar feature on a different chip some years ago,
and there the color key was a (YCbCr) range.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2]OMAP3 NAND: Enable support for nand driver on OMAP3430
* Singh, Vimal <[EMAIL PROTECTED]> [080826 13:19]: > From: Teerth Reddy <[EMAIL PROTECTED]> > > This patch enables the support for nand driver on 3430sdp Pushing today. Tony > Signed-off-by: Teerth Reddy <[EMAIL PROTECTED]> > --- > arch/arm/configs/omap_3430sdp_defconfig | 12 +++- > 1 files changed, 11 insertions(+), 1 deletion(-) > > Index : linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig > = > --- a/arch/arm/configs/omap_3430sdp_defconfig 2008-08-06 13:03:38.859241000 > +0530 > +++ b/arch/arm/configs/omap_3430sdp_defconfig 2008-08-05 16:02:20.037348000 > +0530 > @@ -493,7 +493,17 @@ CONFIG_MTD_OMAP_NOR=y > # CONFIG_MTD_DOC2000 is not set > # CONFIG_MTD_DOC2001 is not set > # CONFIG_MTD_DOC2001PLUS is not set > -# CONFIG_MTD_NAND is not set > +CONFIG_MTD_NAND=y > +# CONFIG_MTD_NAND_VERIFY_WRITE is not set > +CONFIG_MTD_NAND_ECC_SMC=y > +# CONFIG_MTD_NAND_MUSEUM_IDS is not set > +CONFIG_MTD_NAND_OMAP2=y > +CONFIG_MTD_NAND_OMAP_HWECC=y > +CONFIG_MTD_NAND_IDS=y > +# CONFIG_MTD_NAND_DISKONCHIP is not set > +# CONFIG_MTD_NAND_NANDSIM is not set > +# CONFIG_MTD_NAND_PLATFORM is not set > +# CONFIG_MTD_ALAUDA is not set > CONFIG_MTD_ONENAND=y > CONFIG_MTD_ONENAND_VERIFY_WRITE=y > # CONFIG_MTD_ONENAND_GENERIC is not set-- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESENDING][PATCH 1/2]OMAP3 NAND: Add NAND support on OMAP3430
* vimal singh <[EMAIL PROTECTED]> [080911 13:07]:
> From: Teerth Reddy <[EMAIL PROTECTED]>
>
> This patch adds NAND support on 3430sdp board
>
> [VS: updated for NAND_BLOCK_SIZE macros]
Pushing today.
Tony
> Signed-off-by: Teerth Reddy <[EMAIL PROTECTED]>
> Signed-off-by: Vimal Singh <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/board-3430sdp-flash.c | 87
> --
> arch/arm/plat-omap/include/mach/gpmc.h| 10 +++
> include/linux/mtd/nand.h |2
> 3 files changed, 93 insertions(+), 6 deletions(-)
>
> Index: linux-omap-2.6_27_08_2008/arch/arm/mach-omap2/board-3430sdp-flash.c
> ===
> ---
> linux-omap-2.6_27_08_2008.orig/arch/arm/mach-omap2/board-3430sdp-flash.c
> 2008-08-27
> 11:40:26.0 +0530
> +++
> linux-omap-2.6_27_08_2008/arch/arm/mach-omap2/board-3430sdp-flash.c
> 2008-09-11
> 15:21:10.0 +0530
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> static struct mtd_partition sdp_nor_partitions[] = {
> /* bootloader (U-Boot, etc) in first sector */
> @@ -137,6 +138,61 @@
> /* Onenand setup does nothing at present */
> return 0;
> }
> +
> +static struct mtd_partition sdp_nand_partitions[] = {
> + /* All the partition sizes are listed in terms of NAND block size */
> + {
> + .name = "X-Loader-NAND",
> + .offset = 0,
> + .size = 4 * NAND_BLOCK_SIZE,
> + .mask_flags = MTD_WRITEABLE,/* force read-only */
> + },
> + {
> + .name = "U-Boot-NAND",
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
> + .size = 4 * NAND_BLOCK_SIZE,
> + .mask_flags = MTD_WRITEABLE,/* force read-only */
> + },
> + {
> + .name = "Boot Env-NAND",
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x10 */
> + .size = 2 * NAND_BLOCK_SIZE,
> + },
> + {
> + .name = "Kernel-NAND",
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x14 */
> + .size = 32 * NAND_BLOCK_SIZE,
> + },
> + {
> + .name = "File System - NAND",
> + .size = MTDPART_SIZ_FULL,
> + .offset = MTDPART_OFS_APPEND, /* Offset = 0x54 */
> + },
> +};
> +
> +static struct omap_nand_platform_data sdp_nand_data = {
> + .parts = sdp_nand_partitions,
> + .nr_parts = ARRAY_SIZE(sdp_nand_partitions),
> + .nand_setup = NULL,
> + .dma_channel= -1, /* disable DMA in OMAP NAND driver */
> + .dev_ready = NULL,
> +};
> +
> +static struct resource sdp_nand_resource = {
> + .flags = IORESOURCE_MEM,
> +};
> +
> +static struct platform_device sdp_nand_device = {
> + .name = "omap2-nand",
> + .id = 0,
> + .dev= {
> + .platform_data = &sdp_nand_data,
> + },
> + .num_resources = 1,
> + .resource = &sdp_nand_resource,
> +};
> +
> +
> /**
> * sdp3430_flash_init - Identify devices connected to GPMC and register.
> *
> @@ -145,7 +201,11 @@
> void __init sdp3430_flash_init(void)
> {
> u8 cs = 0;
> + u8 nandcs = GPMC_CS_NUM + 1;
> u8 onenandcs = GPMC_CS_NUM + 1;
> + unsigned long gpmc_base_add;
> +
> + gpmc_base_add = OMAP34XX_GPMC_VIRT;
>
> /* Configure start address and size of NOR device */
> if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)) {
> @@ -163,25 +223,42 @@
>
> while (cs < GPMC_CS_NUM) {
> u32 ret = 0;
> - ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
> + ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
>
> /*
> - * xloader/Uboot would have programmed the oneNAND
> + * xloader/Uboot would have programmed the NAND/oneNAND
> * base address for us This is a ugly hack. The proper
> * way of doing this is to pass the setup of u-boot up
> * to kernel using kernel params - something on the
> * lines of machineID. Check if oneNAND is configured
> */
> - if ((ret & 0x3F) == (ONENAND_MAP >> 24))
> + if ((ret & 0xC00) == 0x800) {
> + /* Found it!! */
> + if (nandcs > GPMC_CS_NUM)
> + nandcs = cs;
> + } else {
> + ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
> + if ((ret & 0x3F) == (ONENAND_MAP >> 24))
> onenandcs = cs;
> + }
> cs++;
> }
> - if (onenandcs > GPMC_CS_NUM) {
> - printk(KERN_INFO "OneNAND: Unable to fi
Re: [PATCH 3/3] lp5521: move to drivers/leds
* Riku Voipio <[EMAIL PROTECTED]> [081006 14:09]:
> On Mon, Oct 06, 2008 at 12:11:31PM +0300, Felipe Balbi wrote:
> > This driver should be sitting together with the other
> > led drivers.
>
> But this driver actually doesn't implement the led sysfs interface.
> If the driver is changed to implement the led framework interface,
> we break the existing n810 userland and expose only limited subset
> of lp5521 features for userland..
Maybe this feature should be a distro specific hack on top of
the mainline tree?
Tony
> > Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> > ---
> > drivers/i2c/chips/Kconfig |7 ---
> > drivers/i2c/chips/Makefile |1 -
> > drivers/leds/Kconfig |7 +++
> > drivers/leds/Makefile |1 +
> > drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} |0
> > 5 files changed, 8 insertions(+), 8 deletions(-)
> > rename drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} (100%)
> >
> > diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
> > index e6ac6a2..1b9bc11 100644
> > --- a/drivers/i2c/chips/Kconfig
> > +++ b/drivers/i2c/chips/Kconfig
> > @@ -225,13 +225,6 @@ config SENSORS_TSL2563
> > This driver can also be built as a module. If so, the module
> > will be called tsl2563.
> >
> > -config LP5521
> > - tristate "LP5521 LED driver chip"
> > - depends on I2C
> > - help
> > - If you say yes here you get support for the National Semiconductor
> > - LP5521 LED driver.
> > -
> > config MENELAUS
> > bool "TWL92330/Menelaus PM chip"
> > depends on I2C=y && ARCH_OMAP24XX
> > diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
> > index 75c531a..7523e58 100644
> > --- a/drivers/i2c/chips/Makefile
> > +++ b/drivers/i2c/chips/Makefile
> > @@ -30,7 +30,6 @@ obj-$(CONFIG_TWL4030_POWEROFF)+= twl4030-poweroff.o
> > obj-$(CONFIG_TWL4030_PWRBUTTON)+= twl4030-pwrbutton.o
> > obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> > obj-$(CONFIG_RTC_X1205_I2C)+= x1205.o
> > -obj-$(CONFIG_LP5521) += lp5521.o
> >
> > ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
> > EXTRA_CFLAGS += -DDEBUG
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index 6a2f441..bd7c4dc 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -146,6 +146,13 @@ config LEDS_CM_X270
> > help
> > This option enables support for the CM-X270 LEDs.
> >
> > +config LEDS_LP5521
> > + tristate "LED Support for LP5521 RGB LEDs"
> > + depends on LEDS_CLASS && I2C
> > + help
> > + If you say yes here you get support for the National Semiconductor
> > + LP5521 LED driver used in n8x0 boards.
> > +
> > config LEDS_CLEVO_MAIL
> > tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
> > depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > index fd6316e..ce5c8cd 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_LEDS_COBALT_RAQ) +=
> > leds-cobalt-raq.o
> > obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
> > obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
> > obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
> > +obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
> > obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
> > obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
> > obj-$(CONFIG_LEDS_FSG) += leds-fsg.o
> > diff --git a/drivers/i2c/chips/lp5521.c b/drivers/leds/leds-lp5521.c
> > similarity index 100%
> > rename from drivers/i2c/chips/lp5521.c
> > rename to drivers/leds/leds-lp5521.c
> > --
> > 1.6.0.2.307.gc427
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> "rm -rf" only sounds scary if you don't have backups
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lp5521: move to drivers/leds
On Mon, Oct 06, 2008 at 12:11:31PM +0300, Felipe Balbi wrote:
> This driver should be sitting together with the other
> led drivers.
But this driver actually doesn't implement the led sysfs interface.
If the driver is changed to implement the led framework interface,
we break the existing n810 userland and expose only limited subset
of lp5521 features for userland..
> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/i2c/chips/Kconfig |7 ---
> drivers/i2c/chips/Makefile |1 -
> drivers/leds/Kconfig |7 +++
> drivers/leds/Makefile |1 +
> drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} |0
> 5 files changed, 8 insertions(+), 8 deletions(-)
> rename drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} (100%)
>
> diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
> index e6ac6a2..1b9bc11 100644
> --- a/drivers/i2c/chips/Kconfig
> +++ b/drivers/i2c/chips/Kconfig
> @@ -225,13 +225,6 @@ config SENSORS_TSL2563
> This driver can also be built as a module. If so, the module
> will be called tsl2563.
>
> -config LP5521
> - tristate "LP5521 LED driver chip"
> - depends on I2C
> - help
> - If you say yes here you get support for the National Semiconductor
> - LP5521 LED driver.
> -
> config MENELAUS
> bool "TWL92330/Menelaus PM chip"
> depends on I2C=y && ARCH_OMAP24XX
> diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
> index 75c531a..7523e58 100644
> --- a/drivers/i2c/chips/Makefile
> +++ b/drivers/i2c/chips/Makefile
> @@ -30,7 +30,6 @@ obj-$(CONFIG_TWL4030_POWEROFF) += twl4030-poweroff.o
> obj-$(CONFIG_TWL4030_PWRBUTTON) += twl4030-pwrbutton.o
> obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> obj-$(CONFIG_RTC_X1205_I2C) += x1205.o
> -obj-$(CONFIG_LP5521) += lp5521.o
>
> ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
> EXTRA_CFLAGS += -DDEBUG
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 6a2f441..bd7c4dc 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -146,6 +146,13 @@ config LEDS_CM_X270
> help
> This option enables support for the CM-X270 LEDs.
>
> +config LEDS_LP5521
> + tristate "LED Support for LP5521 RGB LEDs"
> + depends on LEDS_CLASS && I2C
> + help
> + If you say yes here you get support for the National Semiconductor
> + LP5521 LED driver used in n8x0 boards.
> +
> config LEDS_CLEVO_MAIL
> tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
> depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index fd6316e..ce5c8cd 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_LEDS_COBALT_RAQ) +=
> leds-cobalt-raq.o
> obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
> obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
> obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
> +obj-$(CONFIG_LEDS_LP5521)+= leds-lp5521.o
> obj-$(CONFIG_LEDS_CLEVO_MAIL)+= leds-clevo-mail.o
> obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
> obj-$(CONFIG_LEDS_FSG) += leds-fsg.o
> diff --git a/drivers/i2c/chips/lp5521.c b/drivers/leds/leds-lp5521.c
> similarity index 100%
> rename from drivers/i2c/chips/lp5521.c
> rename to drivers/leds/leds-lp5521.c
> --
> 1.6.0.2.307.gc427
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
"rm -rf" only sounds scary if you don't have backups
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP3: Update USBHOST pinmux settings
* Gadiyar, Anand <[EMAIL PROTECTED]> [080930 18:19]:
> From: Anand Gadiyar <[EMAIL PROTECTED]>
>
> Add pin-mux settings for OHCI in PHY mode.
> Also change settings for EHCI in TLL mode.
Pushing to linux-omap, and will also merge in to the minimal 34xx
support patch for mainline.
Tony
> Signed-off-by: Anand Gadiyar <[EMAIL PROTECTED]>
> ---
> Fixed comments below. Also fixed one pin that should
> have been marked output, but was wrongly marked input.
>
> arch/arm/mach-omap2/mux.c | 67
> +++---
> arch/arm/plat-omap/include/mach/mux.h | 26 -
> 2 files changed, 80 insertions(+), 13 deletions(-)
>
> Index: tony/arch/arm/mach-omap2/mux.c
> ===
> --- tony.orig/arch/arm/mach-omap2/mux.c 2008-09-26 22:53:19.0
> +0530
> +++ tony/arch/arm/mach-omap2/mux.c2008-09-30 20:37:42.572206850 +0530
> @@ -298,13 +298,13 @@ MUX_CFG_34XX("T2_3430_USB2HS_PHY_D7", 0x
>
> /* TLL - HSUSB: 12-pin TLL Port 1*/
> MUX_CFG_34XX("Y8_3430_USB1HS_TLL_CLK", 0x5da,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> -MUX_CFG_34XX("Y9_3430_USB1HS_TLL_STP", 0x5d8,
> OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("Y9_3430_USB1HS_TLL_STP", 0x5d8,
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AA14_3430_USB1HS_TLL_DIR", 0x5ec,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AA11_3430_USB1HS_TLL_NXT", 0x5ee,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("W13_3430_USB1HS_TLL_D0", 0x5dc,
> OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("W12_3430_USB1HS_TLL_D1", 0x5de,
> @@ -324,13 +324,13 @@ MUX_CFG_34XX("Y13_3430_USB1HS_TLL_D7", 0
>
> /* TLL - HSUSB: 12-pin TLL Port 2*/
> MUX_CFG_34XX("AA8_3430_USB2HS_TLL_CLK", 0x5f0,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> -MUX_CFG_34XX("AA10_3430_USB2HS_TLL_STP", 0x5f2,
> OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AA10_3430_USB2HS_TLL_STP", 0x5f2,
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AA9_3430_USB2HS_TLL_DIR", 0x5f4,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AB11_3430_USB2HS_TLL_NXT", 0x5f6,
> - OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AB10_3430_USB2HS_TLL_D0", 0x5f8,
> OMAP34XX_MUX_MODE6 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AB9_3430_USB2HS_TLL_D1", 0x5fa,
> @@ -350,13 +350,13 @@ MUX_CFG_34XX("T2_3430_USB2HS_TLL_D7", 0x
>
> /* TLL - HSUSB: 12-pin TLL Port 3*/
> MUX_CFG_34XX("AA6_3430_USB3HS_TLL_CLK", 0x180,
> - OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_OUTPUT)
> -MUX_CFG_34XX("AB3_3430_USB3HS_TLL_STP", 0x166,
> OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AB3_3430_USB3HS_TLL_STP", 0x166,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AA3_3430_USB3HS_TLL_DIR", 0x168,
> - OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("Y3_3430_USB3HS_TLL_NXT", 0x16a,
> - OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_OUTPUT)
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AA5_3430_USB3HS_TLL_D0", 0x186,
> OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("Y4_3430_USB3HS_TLL_D1", 0x184,
> @@ -373,6 +373,49 @@ MUX_CFG_34XX("AA13_3430_USB3HS_TLL_D6",
> OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> MUX_CFG_34XX("AA12_3430_USB3HS_TLL_D7", 0x172,
> OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +
> +/* PHY FSUSB: FS Serial for Port 1 (multiple PHY modes supported) */
> +MUX_CFG_34XX("AF10_3430_USB1FS_PHY_MM1_RXDP", 0x5d8,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("AG9_3430_USB1FS_PHY_MM1_RXDM", 0x5ee,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("W13_3430_USB1FS_PHY_MM1_RXRCV", 0x5dc,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("W12_3430_USB1FS_PHY_MM1_TXSE0", 0x5de,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("W11_3430_USB1FS_PHY_MM1_TXDAT", 0x5e0,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_INPUT_PULLDOWN)
> +MUX_CFG_34XX("Y11_3430_USB1FS_PHY_MM1_TXEN_N", 0x5ea,
> + OMAP34XX_MUX_MODE5 | OMAP34XX_PIN_OUTPUT)
> +
> +/* PHY FSUSB: FS Serial for Port 2 (multiple PHY modes supported) */
> +MUX_CFG_34XX("AF7_3430_USB2FS_PHY_MM2_RXDP", 0x5f2,
> +
Re: [PATCH] omap: mmc: fix compile breakage on board-n800-mmc.c
On Mon, 6 Oct 2008 12:09:22 +0300 "ext Felipe Balbi" <[EMAIL PROTECTED]> wrote: > Commit 81d2c7d87a9c1eb724788fce7312922effa1b1ae broke > compilation of board-n800-mmc.c, this patch fixes it. > > Still n810 doesn't boot anymore with current linux-omap. > Will look into that soon. > > Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]> > --- > arch/arm/mach-omap2/board-n800-mmc.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > Heh, I did the very same patch already last week :-) http://marc.info/?l=linux-omap&m=122286380121424&w=2 I'm not sure but I think N810 was booting then. Or I was using N800. Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/10] HDQ driver: Remove global pointer
* Evgeniy Polyakov <[EMAIL PROTECTED]> [081006 12:36]: > Hi. > > On Mon, Oct 06, 2008 at 12:17:06PM +0300, Tony Lindgren ([EMAIL PROTECTED]) > wrote: > > Great, pushing to linux-omap tree. > > > > Evgeniy, are these already in your queue for upstream? > > Not really, since I do not follow omap tree and will not be able to > handle dependency there. Please push w1 part when appropriate changes in > the arch tree are ready. * Madhusudhan Chikkature <[EMAIL PROTECTED]> [081006 12:38]: > > These patches are against the L-o tree. We need to send the complete driver patches against the LKML kernel tree to Evgeniy. OK, Madhu, can you please do the patches against the mainline kernel for Evgeniy? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] i2c: lp5521: remove dead code
On Mon, Oct 06, 2008 at 12:47:22PM +0300, Daniel Stone wrote: > On Mon, Oct 06, 2008 at 12:11:29PM +0300, ext Felipe Balbi wrote: > > That LED_CONNECTED_WRONG was never defined so removing. > > If someone needs those hooks, add back via proper > > platform_data instead of nasty ifdefery. > > > > Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]> > > Signed-off-by: Daniel Stone <[EMAIL PROTECTED]> > > IIRC, LED_CONNECTED_WRONG was only for early hardware builds of the > N810. yeah and it's really weird to keep that since it was a bad hw mistake :-p -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] i2c: lp5521: remove dead code
On Mon, Oct 06, 2008 at 12:11:29PM +0300, ext Felipe Balbi wrote: > That LED_CONNECTED_WRONG was never defined so removing. > If someone needs those hooks, add back via proper > platform_data instead of nasty ifdefery. > > Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]> Signed-off-by: Daniel Stone <[EMAIL PROTECTED]> IIRC, LED_CONNECTED_WRONG was only for early hardware builds of the N810. Cheers, Daniel signature.asc Description: Digital signature
Re: [PATCH 1/10] HDQ driver: Remove global pointer
- Original Message - From: "Tony Lindgren" <[EMAIL PROTECTED]> To: "Evgeniy Polyakov" <[EMAIL PROTECTED]> Cc: "Gadiyar, Anand" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; ; "Chikkature Rajashekar, Madhusudhan" <[EMAIL PROTECTED]> Sent: Monday, October 06, 2008 2:47 PM Subject: Re: [PATCH 1/10] HDQ driver: Remove global pointer >* Evgeniy Polyakov <[EMAIL PROTECTED]> [080925 14:41]: >> Hi. >> >> On Thu, Sep 25, 2008 at 12:19:44PM +0530, Gadiyar, Anand ([EMAIL PROTECTED]) >> wrote: >> > From: Madhusudhan Chikkature <[EMAIL PROTECTED]> >> > >> > This patch provides the necessary modifications to the driver to >> > remove the global ptr hdq_data. >> > >> > Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]> >> >> Looks ok, IA ck the whole serie. > > Great, pushing to linux-omap tree. > > Evgeniy, are these already in your queue for upstream? Tony, These patches are against the L-o tree. We need to send the complete driver patches against the LKML kernel tree to Evgeniy. Regards, Madhu > > Tony > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/10] HDQ driver: Remove global pointer
Hi. On Mon, Oct 06, 2008 at 12:17:06PM +0300, Tony Lindgren ([EMAIL PROTECTED]) wrote: > Great, pushing to linux-omap tree. > > Evgeniy, are these already in your queue for upstream? Not really, since I do not follow omap tree and will not be able to handle dependency there. Please push w1 part when appropriate changes in the arch tree are ready. -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: mmc: fix compile breakage on board-n800-mmc.c
On Mon, Oct 06, 2008 at 12:21:38PM +0300, Tony Lindgren wrote: > * Felipe Balbi <[EMAIL PROTECTED]> [081006 12:10]: > > Commit 81d2c7d87a9c1eb724788fce7312922effa1b1ae broke > > compilation of board-n800-mmc.c, this patch fixes it. > > Thanks, pushing. > > > Still n810 doesn't boot anymore with current linux-omap. > > Will look into that soon. > > Could it be because of the removal of the 0 byte I2C hack? could be but I don't really think so. I'll try reverting that hack and see if it works. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: mmc: fix compile breakage on board-n800-mmc.c
* Felipe Balbi <[EMAIL PROTECTED]> [081006 12:10]:
> Commit 81d2c7d87a9c1eb724788fce7312922effa1b1ae broke
> compilation of board-n800-mmc.c, this patch fixes it.
Thanks, pushing.
> Still n810 doesn't boot anymore with current linux-omap.
> Will look into that soon.
Could it be because of the removal of the 0 byte I2C hack?
Tony
>
> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/board-n800-mmc.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-n800-mmc.c
> b/arch/arm/mach-omap2/board-n800-mmc.c
> index 2cf8213..2c5c97c 100644
> --- a/arch/arm/mach-omap2/board-n800-mmc.c
> +++ b/arch/arm/mach-omap2/board-n800-mmc.c
> @@ -336,7 +336,7 @@ void __init n800_mmc_init(void)
>
> {
> if (machine_is_nokia_n810()) {
> - n800_mmc1_data.slots[0].name = "external";
> + mmc1_data.slots[0].name = "external";
>
> /*
>* Some Samsung Movinand chips do not like open-ended
> @@ -344,8 +344,8 @@ void __init n800_mmc_init(void)
>* while doing so. Reducing the number of blocks in
>* the transfer or delays in clock disable do not help
>*/
> - n800_mmc1_data.slots[1].name = "internal";
> - n800_mmc1_data.slots[1].ban_openended = 1;
> + mmc1_data.slots[1].name = "internal";
> + mmc1_data.slots[1].ban_openended = 1;
> }
>
> if (omap_request_gpio(slot_switch_gpio) < 0)
> --
> 1.6.0.2.307.gc427
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/10] HDQ driver: Remove global pointer
* Evgeniy Polyakov <[EMAIL PROTECTED]> [080925 14:41]: > Hi. > > On Thu, Sep 25, 2008 at 12:19:44PM +0530, Gadiyar, Anand ([EMAIL PROTECTED]) > wrote: > > From: Madhusudhan Chikkature <[EMAIL PROTECTED]> > > > > This patch provides the necessary modifications to the driver to > > remove the global ptr hdq_data. > > > > Signed-off-by: Madhusudhan Chikkature <[EMAIL PROTECTED]> > > Looks ok, IA ck the whole serie. Great, pushing to linux-omap tree. Evgeniy, are these already in your queue for upstream? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] lp5521: move to drivers/leds
This driver should be sitting together with the other
led drivers.
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig |7 ---
drivers/i2c/chips/Makefile |1 -
drivers/leds/Kconfig |7 +++
drivers/leds/Makefile |1 +
drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} |0
5 files changed, 8 insertions(+), 8 deletions(-)
rename drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} (100%)
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index e6ac6a2..1b9bc11 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -225,13 +225,6 @@ config SENSORS_TSL2563
This driver can also be built as a module. If so, the module
will be called tsl2563.
-config LP5521
- tristate "LP5521 LED driver chip"
- depends on I2C
- help
- If you say yes here you get support for the National Semiconductor
- LP5521 LED driver.
-
config MENELAUS
bool "TWL92330/Menelaus PM chip"
depends on I2C=y && ARCH_OMAP24XX
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 75c531a..7523e58 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -30,7 +30,6 @@ obj-$(CONFIG_TWL4030_POWEROFF)+= twl4030-poweroff.o
obj-$(CONFIG_TWL4030_PWRBUTTON)+= twl4030-pwrbutton.o
obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_RTC_X1205_I2C)+= x1205.o
-obj-$(CONFIG_LP5521) += lp5521.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 6a2f441..bd7c4dc 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -146,6 +146,13 @@ config LEDS_CM_X270
help
This option enables support for the CM-X270 LEDs.
+config LEDS_LP5521
+ tristate "LED Support for LP5521 RGB LEDs"
+ depends on LEDS_CLASS && I2C
+ help
+ If you say yes here you get support for the National Semiconductor
+ LP5521 LED driver used in n8x0 boards.
+
config LEDS_CLEVO_MAIL
tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index fd6316e..ce5c8cd 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
obj-$(CONFIG_LEDS_FSG) += leds-fsg.o
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/leds/leds-lp5521.c
similarity index 100%
rename from drivers/i2c/chips/lp5521.c
rename to drivers/leds/leds-lp5521.c
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] i2c: lp5521: cosmetic fixes
General cleanup to the code. Preparing to send it to
mainline.
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/i2c/chips/lp5521.c | 159
1 files changed, 73 insertions(+), 86 deletions(-)
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c
index 7fb8091..e040c4d 100644
--- a/drivers/i2c/chips/lp5521.c
+++ b/drivers/i2c/chips/lp5521.c
@@ -1,5 +1,5 @@
/*
- * drivers/i2c/chips/lp5521.c
+ * lp5521.c - LP5521 LED Driver
*
* Copyright (C) 2007 Nokia Corporation
*
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#define LP5521_DRIVER_NAME "lp5521"
@@ -71,6 +70,7 @@
#define LP5521_PROGRAM_LENGTH 32 /* in bytes */
struct lp5521_chip {
+ /* device lock */
struct mutexlock;
struct i2c_client *client;
char*mode;
@@ -81,20 +81,14 @@ struct lp5521_chip {
static int lp5521_set_mode(struct lp5521_chip *chip, char *mode);
-static int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
+static inline int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
{
return i2c_smbus_write_byte_data(client, reg, value);
}
-static int lp5521_read(struct i2c_client *client, u8 reg, u8 *buf)
+static inline int lp5521_read(struct i2c_client *client, u8 reg)
{
- s32 ret = i2c_smbus_read_byte_data(client, reg);
-
- if (ret < 0)
- return -EIO;
-
- *buf = ret;
- return 0;
+ return i2c_smbus_read_byte_data(client, reg);
}
static int lp5521_configure(struct i2c_client *client)
@@ -136,19 +130,19 @@ static int lp5521_load_program(struct lp5521_chip *chip,
u8 *pattern)
if (chip->red)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_R_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_R_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
if (chip->green)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_G_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_G_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
if (chip->blue)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_B_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_B_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
return ret;
}
@@ -156,31 +150,33 @@ static int lp5521_load_program(struct lp5521_chip *chip,
u8 *pattern)
static int lp5521_run_program(struct lp5521_chip *chip)
{
struct i2c_client *client = chip->client;
- int ret;
+ int reg;
u8 mask = 0xc0;
u8 exec_state = 0;
- u8 enable_reg;
- ret = lp5521_read(client, LP5521_REG_ENABLE, &enable_reg);
- if (ret)
- goto fail;
+ reg = lp5521_read(client, LP5521_REG_ENABLE);
+ if (reg < 0)
+ return reg;
- enable_reg &= mask;
+ reg &= mask;
/* set all active channels exec state to countinous run*/
- exec_state |= (chip->red << 5);
+ exec_state |= (chip->red << 5);
exec_state |= (chip->green << 3);
- exec_state |= (chip->blue << 1);
+ exec_state |= (chip->blue << 1);
- enable_reg |= exec_state;
+ reg |= exec_state;
- ret |= lp5521_write(client, LP5521_REG_ENABLE, enable_reg);
+ if (lp5521_write(client, LP5521_REG_ENABLE, reg))
+ dev_dbg(&client->dev, "failed writing to register %02x\n",
+ LP5521_REG_ENABLE);
/* set op-mode to run for active channels, disabled for others */
- ret |= lp5521_write(client, LP5521_REG_OP_MODE, exec_state);
+ if (lp5521_write(client, LP5521_REG_OP_MODE, exec_state))
+ dev_dbg(&client->dev, "failed writing to register %02x\n",
+ LP5521_REG_OP_MODE);
-fail:
- return ret;
+ return 0;
}
/*--*/
@@ -188,8 +184,8 @@ fail:
/*--*/
static ssize_t show_active_channels(struct device *dev,
- struct device_attribute *attr,
-
[PATCH 0/3] lp5521
A few cleanups and moving to drivers/leds. This driver
is probably ok for making its way to mainline, by the morning
I'll generate a patch against mainline and send to Richard
(led maintainer) for integration.
*** Note: compile tested only due to the fact n810 doesn't boot.
Felipe Balbi (3):
i2c: lp5521: remove dead code
i2c: lp5521: cosmetic fixes
lp5521: move to drivers/leds
drivers/i2c/chips/Kconfig |7 -
drivers/i2c/chips/Makefile |1 -
drivers/leds/Kconfig |7 +
drivers/leds/Makefile |1 +
drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} | 181
5 files changed, 81 insertions(+), 116 deletions(-)
rename drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} (79%)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] i2c: lp5521: remove dead code
That LED_CONNECTED_WRONG was never defined so removing. If someone needs those hooks, add back via proper platform_data instead of nasty ifdefery. Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]> --- drivers/i2c/chips/lp5521.c | 22 -- 1 files changed, 0 insertions(+), 22 deletions(-) diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c index c0862d9..7fb8091 100644 --- a/drivers/i2c/chips/lp5521.c +++ b/drivers/i2c/chips/lp5521.c @@ -28,13 +28,8 @@ #define LP5521_DRIVER_NAME "lp5521" -#ifdef LED_CONNECTED_WRONG -#define LP5521_REG_R_PWM 0x04 -#define LP5521_REG_B_PWM 0x02 -#else #define LP5521_REG_R_PWM 0x02 #define LP5521_REG_B_PWM 0x04 -#endif #define LP5521_REG_ENABLE 0x00 #define LP5521_REG_OP_MODE 0x01 #define LP5521_REG_G_PWM 0x03 @@ -200,22 +195,12 @@ static ssize_t show_active_channels(struct device *dev, char channels[4]; int pos = 0; -#ifdef LED_CONNECTED_WRONG - if (chip->blue) - pos += sprintf(channels + pos, "r"); - if (chip->green) - pos += sprintf(channels + pos, "g"); - if (chip->red) - pos += sprintf(channels + pos, "b"); - -#else if (chip->red) pos += sprintf(channels + pos, "r"); if (chip->green) pos += sprintf(channels + pos, "g"); if (chip->blue) pos += sprintf(channels + pos, "b"); -#endif channels[pos] = '\0'; @@ -232,17 +217,10 @@ static ssize_t store_active_channels(struct device *dev, chip->green = 0; chip->blue = 0; -#ifdef LED_CONNECTED_WRONG - if (strchr(buf, 'r') != NULL) - chip->blue = 1; - if (strchr(buf, 'b') != NULL) - chip->red = 1; -#else if (strchr(buf, 'r') != NULL) chip->red = 1; if (strchr(buf, 'b') != NULL) chip->blue = 1; -#endif if (strchr(buf, 'g') != NULL) chip->green = 1; -- 1.6.0.2.307.gc427 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: mmc: fix compile breakage on board-n800-mmc.c
Commit 81d2c7d87a9c1eb724788fce7312922effa1b1ae broke
compilation of board-n800-mmc.c, this patch fixes it.
Still n810 doesn't boot anymore with current linux-omap.
Will look into that soon.
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-n800-mmc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n800-mmc.c
b/arch/arm/mach-omap2/board-n800-mmc.c
index 2cf8213..2c5c97c 100644
--- a/arch/arm/mach-omap2/board-n800-mmc.c
+++ b/arch/arm/mach-omap2/board-n800-mmc.c
@@ -336,7 +336,7 @@ void __init n800_mmc_init(void)
{
if (machine_is_nokia_n810()) {
- n800_mmc1_data.slots[0].name = "external";
+ mmc1_data.slots[0].name = "external";
/*
* Some Samsung Movinand chips do not like open-ended
@@ -344,8 +344,8 @@ void __init n800_mmc_init(void)
* while doing so. Reducing the number of blocks in
* the transfer or delays in clock disable do not help
*/
- n800_mmc1_data.slots[1].name = "internal";
- n800_mmc1_data.slots[1].ban_openended = 1;
+ mmc1_data.slots[1].name = "internal";
+ mmc1_data.slots[1].ban_openended = 1;
}
if (omap_request_gpio(slot_switch_gpio) < 0)
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP 2/3 V4L2 display driver on video planes
Hi, > -Original Message- > From: Hans Verkuil [mailto:[EMAIL PROTECTED] > Sent: Monday, October 06, 2008 11:59 AM > To: Shah, Hardik > Cc: Mauro Carvalho Chehab; [EMAIL PROTECTED]; linux-omap@vger.kernel.org; > linux-fbdev- > [EMAIL PROTECTED]; Hadli, Manjunath > Subject: Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes > > On Monday 06 October 2008 08:06:30 Shah, Hardik wrote: > > Hi, > > > > > -Original Message- > > > From: Mauro Carvalho Chehab [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, October 05, 2008 4:50 PM > > > To: Shah, Hardik > > > Cc: Hans Verkuil; [EMAIL PROTECTED]; > > > linux-omap@vger.kernel.org; linux-fbdev- > > > [EMAIL PROTECTED] > > > Subject: Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes > > > > > > On Fri, 3 Oct 2008 20:10:36 +0530 > > > "Shah, Hardik" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I don't like the idea of having private ioctls. This generally > > > means that only a very restricted subset of userspace apps that are > > > aware of the that API will work. This is really bad. > > > > > > So, I prefer to discuss the need for newer ioctls and add it into > > > the standard whenever make some sense (ok, maybe you might have > > > some ioctls that are really very specific for your app and that > > > won't break userspace apps - I've acked with 2 private ioctls on > > > uvc driver in the past due to that). > > > > [Shah, Hardik] Following are the custom IOCTLs used in the V4L2 > > display driver of DSS. > > > > 1. VIDIOC_S/G_OMAP2_MIRROR: This ioctl is used to enable the > > mirroring of the image. Hardware supports mirroring. As pointed out > > by Hans it will be better to move it to VIDIOC_S_CTRL ioctl. we can > > add the new control id for the mirroring. > > HFLIP and VFLIP user controls already exist. > > > 2. VIDIOC_S/G_OMAP2_ROTATION: Rotation is used to enable the > > rotation of the image. This also can be moved to the VIDIOC_S_CTRL > > ioctl. Need to add new control id for the rotation also. > > A new standard user control can be added for this. > > > 3. VIDIOC_S/G_OMAP2_LINK: This feature is software provided. OMAP > > DSS is having two video pipelines. Using this feature user can link > > the two video pipelines. This means the streaming of the video on one > > pipeline will be linked to the other pipeline with the same > > parameters as the original pipeline. Same image can be streamed on > > both the pipelines, one of the pipeline's output going to TV and > > other one to LCD. I believe this feature is very specific to OMAP, > > and should remain as the custom ioctl. > > I agree. > > > 4. VIDIOC_S/G_OMAP2_COLORKEY: Color keying allows the pixels with > > the defined color on the video pipelines to be replaced with the > > pixels on the graphics pipelines. I believe similar feature must be > > available on almost all next generation of video hardware. We can add > > new ioctl for this feature in V4L2 framework. I think VIDIOC_S_FBUF > > ioctl is used for setting up the buffer parameters on per buffer > > basis. So IMHO this ioctl is not a natural fit for the above > > functionality. Please provide your comments on same. > > Do I understand correctly that if the color in the *video* streams > matches the colorkey, then it is replaced by the color in the > *framebuffer* (aka menu/overlay)? Usually it is the other way around: > if the framebuffer (menu) has chromakey pixels, then those pixels are > replaced by pixels from the video stream. That's what the current API > does [Shah, Hardik] This is a hardware provided feature. It can be both ways as hardware supports both the features. It means replacing the graphics pipelines pixels with video pipeline pixels and other way is also true. When both graphics and video pipelines are going to the same output device and when the colorkeying is enabled then the pixels of the video pipelines of specific color are replaced by the pixels of the graphics pipeline. This is done automatically done by the overlay manager aka compositor. Graphics pipeline can be controlled by frame buffer interface or V4L2 interface. In driver we only need to enable the color keying and state that whether it is a source color keying or destination color keying along with the color code. > > > 5. VIDIOC_S/G_OMAP2_BGCOLOR: This ioctl is used to set the Background > > color on either TV or LCD. It takes two inputs, first is the output > > device second is the color to be set. I think this can be added to > > the standard ioctl list but is it ok to have the output device as one > > of the parameters in the input structure? Instead we can set the > > background color for the current output. > > Setting the background color for the current output is the more logical > choice. It would also be a nice addition for e.g. the ivtv driver where > a similar functionality exists (currently unused). > > I assume that background color refers to the part of the display not > covered by a men
Re: [Patch] OMAP: ARM: Fix Comp for LDP on DeviceType
* Zavala Trujillo, Diego <[EMAIL PROTECTED]> [080920 10:11]:
>
>
> Regards,
> Fix the compilation for the 3430LDP.
> Replace omap_device_type for omap_type.
Thanks, looks like I've already pushed a similar patch from Felipe.
Tony
> ---
> arch/arm/mach-omap2/board-ldp.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> mode change 100644 => 100755 arch/arm/mach-omap2/board-ldp.c
>
> diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
> old mode 100644
> new mode 100755
> index 9263be9..02359d5
> --- a/arch/arm/mach-omap2/board-ldp.c
> +++ b/arch/arm/mach-omap2/board-ldp.c
> @@ -54,7 +54,7 @@ static int __init msecure_init(void)
>
> #ifdef CONFIG_RTC_DRV_TWL4030
> /* 3430ES2.0 doesn't have msecure/gpio-22 line connected to T2 */
> - if (omap_device_type() == OMAP2_DEVICE_TYPE_GP &&
> + if (omap_type() == OMAP2_DEVICE_TYPE_GP &&
> system_rev < OMAP3430_REV_ES2_0) {
> u32 msecure_pad_config_reg = omap_ctrl_base_get() + 0xA3C;
> int mux_mask = 0x04;
> --
> 1.5.6.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc8-omap 4/7] twl4030-core cleanup
On Fri, Oct 03, 2008 at 09:00:48AM -0700, David Brownell wrote: > From: David Brownell <[EMAIL PROTECTED]> > > A variety of twl4030-core cleanups: > > - SIH register declarations moved from core.c to twl4030.h, for >keypad, madc, bci; this decouples from twl4030-madc.h; add >several omitted register decls; remove a duplicate. > > - Use a global "inuse" flag, not a per-slave one; > > - Remove pointless SLAVENUM_NUM symbols; just use 0/1/2/3 > > - Comments: > * Add comments: header, register values > * Add some section delimiters > * Correct clock init and other comments > > - Minor stuff: > * Group some variables and code with sibling > * Make clock init a bit simpler > * List twl5030 in supported i2c chips list > * Remove needless "return;" > > And one IRQ-related bugfix: if the I2C timeout bug strikes while > reading PIH interrupt status, force an immediate retry. Otherwise > the twl4030 IRQ will never get re-enabled... > > Object size shrinks by 180 bytes, w00t! > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> would be nice to have the patch moving tlw4030-core to drivers/mfd coming from you so we know everything is fine. > --- > drivers/mfd/twl4030-core.c | 263 ++--- > include/linux/i2c/twl4030-madc.h |8 - > include/linux/i2c/twl4030.h | 51 +++ > 3 files changed, 181 insertions(+), 141 deletions(-) > > --- a/drivers/mfd/twl4030-core.c > +++ b/drivers/mfd/twl4030-core.c > @@ -39,7 +39,20 @@ > > #include > #include > -#include > + > + > +/* > + * The TWL4030 "Triton 2" is one of a family of a multi-function "Power > + * Management and System Companion Device" chips originally designed for > + * use in OMAP2 and OMAP 3 based systems. Its control interfaces use I2C, > + * often at around 3 Mbit/sec, including for interrupt handling. > + * > + * This driver core provides genirq support for the interrupts emitted, > + * by the various modules, and exports register access primitives. > + * > + * FIXME this driver currently requires use of the first interrupt line > + * (and associated registers). > + */ > > #define DRIVER_NAME "twl4030" > > @@ -108,23 +121,20 @@ static inline void activate_irq(int irq) > > #define TWL4030_NUM_SLAVES 4 > > -/* Slave address */ > -#define TWL4030_SLAVENUM_NUM00x00 > -#define TWL4030_SLAVENUM_NUM10x01 > -#define TWL4030_SLAVENUM_NUM20x02 > -#define TWL4030_SLAVENUM_NUM30x03 > > -/* Base Address defns */ > -/* USB ID */ > +/* Base Address defns for twl4030_map[] */ > + > +/* subchip/slave 0 - USB ID */ > #define TWL4030_BASEADD_USB 0x > -/* AUD ID */ > + > +/* subchip/slave 1 - AUD ID */ > #define TWL4030_BASEADD_AUDIO_VOICE 0x > #define TWL4030_BASEADD_GPIO 0x0098 > - > #define TWL4030_BASEADD_INTBR0x0085 > #define TWL4030_BASEADD_PIH 0x0080 > #define TWL4030_BASEADD_TEST 0x004C > -/* AUX ID */ > + > +/* subchip/slave 2 - AUX ID */ > #define TWL4030_BASEADD_INTERRUPTS 0x00B9 > #define TWL4030_BASEADD_LED 0x00EE > #define TWL4030_BASEADD_MADC 0x > @@ -135,7 +145,8 @@ static inline void activate_irq(int irq) > #define TWL4030_BASEADD_PWMA 0x00EF > #define TWL4030_BASEADD_PWMB 0x00F1 > #define TWL4030_BASEADD_KEYPAD 0x00D2 > -/* POWER ID */ > + > +/* subchip/slave 3 - POWER ID */ > #define TWL4030_BASEADD_BACKUP 0x0014 > #define TWL4030_BASEADD_INT 0x002E > #define TWL4030_BASEADD_PM_MASTER0x0036 > @@ -143,44 +154,26 @@ static inline void activate_irq(int irq) > #define TWL4030_BASEADD_RTC 0x001C > #define TWL4030_BASEADD_SECURED_REG 0x > > -/* TWL4030 BCI registers */ > -#define TWL4030_INTERRUPTS_BCIIMR1A 0x2 > -#define TWL4030_INTERRUPTS_BCIIMR2A 0x3 > -#define TWL4030_INTERRUPTS_BCIIMR1B 0x6 > -#define TWL4030_INTERRUPTS_BCIIMR2B 0x7 > -#define TWL4030_INTERRUPTS_BCIISR1A 0x0 > -#define TWL4030_INTERRUPTS_BCIISR2A 0x1 > -#define TWL4030_INTERRUPTS_BCIISR1B 0x4 > -#define TWL4030_INTERRUPTS_BCIISR2B 0x5 > - > -/* TWL4030 keypad registers */ > -#define TWL4030_KEYPAD_KEYP_IMR1 0x12 > -#define TWL4030_KEYPAD_KEYP_IMR2 0x14 > -#define TWL4030_KEYPAD_KEYP_ISR1 0x11 > -#define TWL4030_KEYPAD_KEYP_ISR2 0x13 > - > - > /* Triton Core internal information (END) */ > > + > /* Few power values */ > #define R_CFG_BOOT 0x05 > #define R_PROTECT_KEY0x0E > > -/* access control */ > +/* access control values for R_PROTECT_KEY */ > #define KEY_UNLOCK1 0xce > #define KEY_UNLOCK2 0xec > #define KEY_LOCK 0x00 > > +/* some fields in R_CFG_BOOT */ > #define HFCLK_FREQ_19p2_MHZ (1 << 0) > #define HFCLK_FREQ_26_MHZ(2 << 0) > #define HFCLK_FREQ_38p4_
Re: [patch/rfc/rft 2.6.27-rc8-omap-git] twl4030-pwrirq simplification, cleanup
On Mon, Oct 06, 2008 at 01:19:18AM -0700, David Brownell wrote: > I can't test the pwrbutton stuff, but rtc and musb behave... > > With one issue: the usb transceiver glue misbehaves on > startup if the device is connected. (Again.) I looked at > this a bit, and I think the issue is probably caused by > not actually using key USB registers ... IRQ trigger > mode state transitions are at best a fragile proxy for the > real state. > > (This is similar to the GPIO patch I just sent, but simpler > except for the impact on the few drivers thinking oddly > about IRQs. Those patches cover the key SIH modules, and > a similar one affects the PIH in twl4030-core.) What are the dependencies for this patch ? It doesn't apply cleanly. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP 2/3 V4L2 display driver on video planes
Hans Verkuil <[EMAIL PROTECTED]> writes: > On Monday 06 October 2008 08:06:30 Shah, Hardik wrote: >> 4. VIDIOC_S/G_OMAP2_COLORKEY: Color keying allows the pixels with >> the defined color on the video pipelines to be replaced with the >> pixels on the graphics pipelines. I believe similar feature must be >> available on almost all next generation of video hardware. We can add >> new ioctl for this feature in V4L2 framework. I think VIDIOC_S_FBUF >> ioctl is used for setting up the buffer parameters on per buffer >> basis. So IMHO this ioctl is not a natural fit for the above >> functionality. Please provide your comments on same. > > Do I understand correctly that if the color in the *video* streams > matches the colorkey, then it is replaced by the color in the > *framebuffer* (aka menu/overlay)? Usually it is the other way around: > if the framebuffer (menu) has chromakey pixels, then those pixels are > replaced by pixels from the video stream. That's what the current API > does. The OMAP3 hardware supports both type of keying, but not simultaneously. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM:OMAP2: Add OVERO_GPIO_BT_XGATE to Overo board init
* Steve Sakoman <[EMAIL PROTECTED]> [080914 08:18]:
> Drive OVERO_GPIO_BT_XGATE low rather than relying on the pin mux pull
> down set by U-boot
Pushing today. Will also merge into the minimal board support patch
for mainline kernel.
Tony
>
> Signed-off-by: Steve Sakoman <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/board-overo.c |6 ++
> arch/arm/plat-omap/include/mach/board-overo.h |1 +
> 2 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-overo.c
> b/arch/arm/mach-omap2/board-overo.c
> index 396ec33..5c23b4d 100644
> --- a/arch/arm/mach-omap2/board-overo.c
> +++ b/arch/arm/mach-omap2/board-overo.c
> @@ -207,6 +207,12 @@ static void __init overo_init(void)
> printk(KERN_ERR "could not obtain gpio for
> OVERO_GPIO_W2W_NRESET\n");
> }
>
> + if ((gpio_request(OVERO_GPIO_BT_XGATE, "OVERO_GPIO_BT_XGATE") == 0) &&
> + (gpio_direction_output(OVERO_GPIO_BT_XGATE, 0) == 0))
> + gpio_export(OVERO_GPIO_BT_XGATE, 0);
> + else
> + printk(KERN_ERR "could not obtain gpio for
> OVERO_GPIO_BT_XGATE\n");
> +
> if ((gpio_request(OVERO_GPIO_BT_NRESET, "OVERO_GPIO_BT_NRESET") == 0) &&
> (gpio_direction_output(OVERO_GPIO_BT_NRESET, 1) == 0)) {
> gpio_export(OVERO_GPIO_BT_NRESET, 0);
> diff --git a/arch/arm/plat-omap/include/mach/board-overo.h
> b/arch/arm/plat-omap/include/mach/board-overo.h
> index b70f22a..7ecae66 100644
> --- a/arch/arm/plat-omap/include/mach/board-overo.h
> +++ b/arch/arm/plat-omap/include/mach/board-overo.h
> @@ -16,6 +16,7 @@
> #ifndef __ASM_ARCH_OVERO_H
> #define __ASM_ARCH_OVERO_H
>
> +#define OVERO_GPIO_BT_XGATE 15
> #define OVERO_GPIO_W2W_NRESET16
> #define OVERO_GPIO_BT_NRESET 164
> #define OVERO_GPIO_USBH_CPEN 168
> --
> 1.5.4.5
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: ldp: fix compile breakage and physical/virtual address usage
* Felipe Balbi <[EMAIL PROTECTED]> [080922 18:11]:
> commit bf9454a3aaf2cad2321aa8f97bfd5d8c4ebc7bf5 broke compilation
> for ldp board. The following patch fixes it. Also fixes a wrong
> cast from a void __iomem * to u32.
Pushing today.
Tony
> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/board-ldp.c |9 +
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
> index 9263be9..8b0256c 100644
> --- a/arch/arm/mach-omap2/board-ldp.c
> +++ b/arch/arm/mach-omap2/board-ldp.c
> @@ -54,9 +54,10 @@ static int __init msecure_init(void)
>
> #ifdef CONFIG_RTC_DRV_TWL4030
> /* 3430ES2.0 doesn't have msecure/gpio-22 line connected to T2 */
> - if (omap_device_type() == OMAP2_DEVICE_TYPE_GP &&
> + if (omap_type() == OMAP2_DEVICE_TYPE_GP &&
> system_rev < OMAP3430_REV_ES2_0) {
> - u32 msecure_pad_config_reg = omap_ctrl_base_get() + 0xA3C;
> + void __iomem *msecure_pad_config_reg =
> + omap_ctrl_base_get() + 0xA3C;
> int mux_mask = 0x04;
> u16 tmp;
>
> @@ -72,10 +73,10 @@ static int __init msecure_init(void)
>* TWL4030 RTC time and calender registers.
>*/
>
> - tmp = omap_readw(msecure_pad_config_reg);
> + tmp = __raw_readw(msecure_pad_config_reg);
> tmp &= 0xF8;/* To enable mux mode 03/04 = GPIO_RTC */
> tmp |= mux_mask;/* To enable mux mode 03/04 = GPIO_RTC */
> - omap_writew(tmp, msecure_pad_config_reg);
> + __raw_writew(tmp, msecure_pad_config_reg);
>
> gpio_direction_output(TWL4030_MSECURE_GPIO, 1);
> }
> --
> 1.6.0.1.308.gede4c
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Clean up header file duplication
* Hiroshi DOYU <[EMAIL PROTECTED]> [080915 06:02]: > Signed-off-by: Hiroshi DOYU <[EMAIL PROTECTED]> > --- > arch/arm/mach-omap1/board-h2-mmc.c |1 - > arch/arm/mach-omap1/board-h3-mmc.c |1 - > arch/arm/mach-omap1/board-h3.c |1 - > arch/arm/mach-omap2/board-h4.c |1 - > arch/arm/mach-omap2/board-n800-mmc.c |1 - > arch/arm/mach-omap2/board-omap3evm.c |2 -- > drivers/input/keyboard/innovator_ps2.c |1 - > drivers/mtd/nand/omap-hw.c |1 - > drivers/mtd/nand/omap-nand-flash.c |2 -- > drivers/mtd/onenand/omap2.c|1 - > sound/oss/omap-audio-tsc2101.c |1 - > 11 files changed, 0 insertions(+), 13 deletions(-) Pushing this today, modified for board-omap3evm.c. Sorry it took so long, it's been busy recently. Tony > > diff --git a/arch/arm/mach-omap1/board-h2-mmc.c > b/arch/arm/mach-omap1/board-h2-mmc.c > index 37031e0..d2cddf1 100644 > --- a/arch/arm/mach-omap1/board-h2-mmc.c > +++ b/arch/arm/mach-omap1/board-h2-mmc.c > @@ -14,7 +14,6 @@ > > #include > #include > -#include > > #ifdef CONFIG_MMC_OMAP > static int slot_cover_open; > diff --git a/arch/arm/mach-omap1/board-h3-mmc.c > b/arch/arm/mach-omap1/board-h3-mmc.c > index 44e9d53..541fa6e 100644 > --- a/arch/arm/mach-omap1/board-h3-mmc.c > +++ b/arch/arm/mach-omap1/board-h3-mmc.c > @@ -14,7 +14,6 @@ > > #include > #include > -#include > > #ifdef CONFIG_MMC_OMAP > static int slot_cover_open; > diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c > index 0c1b001..eaba9f3 100644 > --- a/arch/arm/mach-omap1/board-h3.c > +++ b/arch/arm/mach-omap1/board-h3.c > @@ -28,7 +28,6 @@ > #include > #include > #include > -#include > #include > #include > > diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c > index c65358b..733e134 100644 > --- a/arch/arm/mach-omap2/board-h4.c > +++ b/arch/arm/mach-omap2/board-h4.c > @@ -18,7 +18,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/arch/arm/mach-omap2/board-n800-mmc.c > b/arch/arm/mach-omap2/board-n800-mmc.c > index bcbba94..b8aa7a3 100644 > --- a/arch/arm/mach-omap2/board-n800-mmc.c > +++ b/arch/arm/mach-omap2/board-n800-mmc.c > @@ -17,7 +17,6 @@ > > #include > #include > -#include > > #ifdef CONFIG_MMC_OMAP > > diff --git a/arch/arm/mach-omap2/board-omap3evm.c > b/arch/arm/mach-omap2/board-omap3evm.c > index 92f70ce..dbbf1db 100644 > --- a/arch/arm/mach-omap2/board-omap3evm.c > +++ b/arch/arm/mach-omap2/board-omap3evm.c > @@ -27,8 +27,6 @@ > #include > #include > #include > -#include > -#include > > #include > #include > diff --git a/drivers/input/keyboard/innovator_ps2.c > b/drivers/input/keyboard/innovator_ps2.c > index b3c4a06..5f88839 100644 > --- a/drivers/input/keyboard/innovator_ps2.c > +++ b/drivers/input/keyboard/innovator_ps2.c > @@ -82,7 +82,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/mtd/nand/omap-hw.c b/drivers/mtd/nand/omap-hw.c > index 1eb19ce..7eb9894 100644 > --- a/drivers/mtd/nand/omap-hw.c > +++ b/drivers/mtd/nand/omap-hw.c > @@ -27,7 +27,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/mtd/nand/omap-nand-flash.c > b/drivers/mtd/nand/omap-nand-flash.c > index 63a7968..6b8fb44 100644 > --- a/drivers/mtd/nand/omap-nand-flash.c > +++ b/drivers/mtd/nand/omap-nand-flash.c > @@ -26,8 +26,6 @@ > #include > #include > > -#include > -#include > #include > > #define DRIVER_NAME "omapnand" > diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c > index 24dd54f..a9885d1 100644 > --- a/drivers/mtd/onenand/omap2.c > +++ b/drivers/mtd/onenand/omap2.c > @@ -38,7 +38,6 @@ > #include > #include > #include > -#include > #include > > #include > diff --git a/sound/oss/omap-audio-tsc2101.c b/sound/oss/omap-audio-tsc2101.c > index 9cbb0e8..4931ecf 100644 > --- a/sound/oss/omap-audio-tsc2101.c > +++ b/sound/oss/omap-audio-tsc2101.c > @@ -39,7 +39,6 @@ > #include > #include > #include > -#include > > #include > #include > -- > 1.5.5.1.357.g1af8b > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch/rfc/rft 2.6.27-rc8-omap-git] twl4030-pwrirq simplification, cleanup
I can't test the pwrbutton stuff, but rtc and musb behave...
With one issue: the usb transceiver glue misbehaves on
startup if the device is connected. (Again.) I looked at
this a bit, and I think the issue is probably caused by
not actually using key USB registers ... IRQ trigger
mode state transitions are at best a fragile proxy for the
real state.
(This is similar to the GPIO patch I just sent, but simpler
except for the impact on the few drivers thinking oddly
about IRQs. Those patches cover the key SIH modules, and
a similar one affects the PIH in twl4030-core.)
- Dave
Streamline the "power irq" code, and some of the mechanisms
it uses:
- Support IRQ masking, not just unmasking; simpler code.
- Use the standard handle_edge_irq() handler for these edge IRQs.
- Use generic_handle_irq() instead of a manual expansion thereof.
- Provide a missing spinlock for the shared data.
In short, use more of the standard genirq code ... more correctly.
Also, update the drivers using the "power IRQ" accordingly:
- Don't request IRQF_DISABLED if the handler makes I2C calls;
and defend against lockdep forcing it on us.
- Let the irq_chip handle IRQ mask/unmask; it handles mutual
exclusion between drivers, among other things.
- (Unrelated) remove useless MODULE_ALIAS in pwrbutton.
The USB transceiver driver still places some dodgey games with IRQ
enable/disable, and IRQ trigger flags. At least some of them seem
like they'd be simplified by using USB transceiver registers ...
notably, startup code, which doesn't seem to check state before
it enters an irq-driven mode.
For the moment, these drivers still (wrongly) try to configure IRQ
trigger modes themselves ... again, that's something that an irq_chip
handles (but not yet, for this one).
NOTE: tested (MUSB and RTC only) along with the init/retry hack
to make twl4030-pwrirq work around the i2c-omap timeout problems.
---
drivers/i2c/chips/twl4030-pwrbutton.c | 33 --
drivers/i2c/chips/twl4030-pwrirq.c| 98 ++--
drivers/i2c/chips/twl4030-usb.c | 57 --
drivers/rtc/rtc-twl4030.c |8 ++
4 files changed, 80 insertions(+), 116 deletions(-)
--- a/drivers/i2c/chips/twl4030-pwrbutton.c
+++ b/drivers/i2c/chips/twl4030-pwrbutton.c
@@ -49,6 +49,14 @@ static irqreturn_t powerbutton_irq(int i
int err;
u8 value;
+#ifdef CONFIG_LOCKDEP
+ /* WORKAROUND for lockdep forcing IRQF_DISABLED on us, which
+* we don't want and can't tolerate. Although it might be
+* friendlier not to borrow this thread context...
+*/
+ local_irq_enable();
+#endif
+
err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_MASTER, &value,
STS_HW_CONDITIONS);
if (!err) {
@@ -67,6 +75,7 @@ static int __init twl4030_pwrbutton_init
int err = 0;
u8 value;
+ /* PWRBTN == PWRON */
if (request_irq(TWL4030_PWRIRQ_PWRBTN, powerbutton_irq, 0,
"PwrButton", NULL) < 0) {
printk(KERN_ERR "Unable to allocate IRQ for power button\n");
@@ -92,22 +101,9 @@ static int __init twl4030_pwrbutton_init
goto free_irq_and_out;
}
- err = twl4030_i2c_read_u8(TWL4030_MODULE_INT, &value, PWR_IMR1);
- if (err) {
- printk(KERN_WARNING "I2C error %d while reading TWL4030"
- " INT PWR_IMR1 register\n", err);
-
- goto free_input_dev;
- }
-
- err = twl4030_i2c_write_u8(TWL4030_MODULE_INT,
- value & (~PWR_PWRON_IRQ), PWR_IMR1);
- if (err) {
- printk(KERN_WARNING "I2C error %d while writing TWL4030"
- " INT PWR_IMR1 register\n", err);
- goto free_input_dev;
- }
-
+ /* FIXME just pass IRQF_EDGE_FALLING | IRQF_EDGE_RISING
+* to request_irq(), once MODULE_INT supports them...
+*/
err = twl4030_i2c_read_u8(TWL4030_MODULE_INT, &value, PWR_EDR1);
if (err) {
printk(KERN_WARNING "I2C error %d while reading TWL4030"
@@ -136,19 +132,16 @@ free_irq_and_out:
out:
return err;
}
+module_init(twl4030_pwrbutton_init);
static void __exit twl4030_pwrbutton_exit(void)
{
free_irq(TWL4030_PWRIRQ_PWRBTN, NULL);
input_unregister_device(powerbutton_dev);
input_free_device(powerbutton_dev);
-
}
-
-module_init(twl4030_pwrbutton_init);
module_exit(twl4030_pwrbutton_exit);
-MODULE_ALIAS("i2c:twl4030-pwrbutton");
MODULE_DESCRIPTION("Triton2 Power Button");
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Peter De Schrijver");
--- a/drivers/i2c/chips/twl4030-pwrirq.c
+++ b/drivers/i2c/chips/twl4030-pwrirq.c
@@ -29,21 +29,35 @@
#include
+static DEFINE_SPINLOCK(pwr_lock);
static u8 twl4030_pwrirq_mask;
-static u8 twl4030_pwrirq_pending_unmask;
static struct
[patch 2.6.28-rc8-omap-git] twl4030-gpio irq simplification
From: David Brownell <[EMAIL PROTECTED]>
Simplify and correct TWL4030 GPIO IRQ handling:
- support mask() not just unmask()
- use genirq handle_edge_irq() handler not custom hacks
- let that handle (correct) accounting of chained IRQ counts
- use the more efficient clear-on-read mechanism
- don't misuse IRQ_LEVEL
- remove some superfluous locking
- locking fix: all irq_chip data needs spinlock protection
Cleanups:
- give the helper thread a more accurate name
- don't name the NOP ack() method misleadingly
- use generic_handle_irq(), not a manually unrolled version thereof
- comment fixes
Note that the previous IRQ dispatch code was somewhat confused.
It seemed not to know that it was working with edge triggered
interrupts, much less ones which could be transparently acked.
(Also note that COR=1 doesn't enable Clear-On-Read for all modules;
some are documented as using COR=0 for that. GPIO uses COR=1.)
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
First step of the plan to share more core irq code ...
drivers/gpio/twl4030-gpio.c | 265 +++---
1 file changed, 96 insertions(+), 169 deletions(-)
--- a/drivers/gpio/twl4030-gpio.c
+++ b/drivers/gpio/twl4030-gpio.c
@@ -26,11 +26,8 @@
*/
#include
-#include
#include
-#include
#include
-#include
#include
#include
#include
@@ -92,17 +89,18 @@ static DEFINE_MUTEX(gpio_lock);
/* store usage of each GPIO. - each bit represents one GPIO */
static unsigned int gpio_usage_count;
-/* shadow the imr register */
-static unsigned int gpio_imr_shadow;
+/* protect what irq_chip modifies through its helper task */
+static DEFINE_SPINLOCK(gpio_spinlock);
-/* bitmask of pending requests to unmask gpio interrupts */
-static unsigned int gpio_pending_unmask;
+/* shadow the imr register; updates are delayed */
+static u32 gpio_imr_shadow;
+static bool gpio_pending_mask;
/* bitmask of requests to set gpio irq trigger type */
static unsigned int gpio_pending_trigger;
-/* pointer to gpio unmask thread struct */
-static struct task_struct *gpio_unmask_thread;
+/* pointer to helper thread */
+static struct task_struct *gpio_helper_thread;
/*
* Helper functions to read and write the GPIO ISR and IMR registers as
@@ -110,6 +108,9 @@ static struct task_struct *gpio_unmask_t
* The caller must hold gpio_lock.
*/
+/* NOTE: only the IRQ dispatcher may read ISR; reading it has
+ * side effects, because of the clear-on-read mechanism (COR=1).
+ */
static int gpio_read_isr(unsigned int *isr)
{
int ret;
@@ -123,19 +124,9 @@ static int gpio_read_isr(unsigned int *i
return ret;
}
-static int gpio_write_isr(unsigned int isr)
-{
- isr &= GPIO_32_MASK;
- /*
-* The buffer passed to the twl4030_i2c_write() routine must have an
-* extra byte at the beginning reserved for its internal use.
-*/
- isr <<= 8;
- isr = cpu_to_le32(isr);
- return twl4030_i2c_write(TWL4030_MODULE_GPIO, (u8 *) &isr,
- REG_GPIO_ISR1A, 3);
-}
-
+/* IMR is written only during initialization and
+ * by request of the irq_chip code.
+ */
static int gpio_write_imr(unsigned int imr)
{
imr &= GPIO_32_MASK;
@@ -150,66 +141,54 @@ static int gpio_write_imr(unsigned int i
}
/*
- * These routines are analagous to the irqchip methods, but they are designed
- * to be called from thread context with cpu interrupts enabled and with no
- * locked spinlocks. We call these routines from our custom IRQ handler
- * instead of the usual irqchip methods.
- */
-static void twl4030_gpio_mask_and_ack(unsigned int irq)
-{
- int gpio = irq - twl4030_gpio_irq_base;
-
- mutex_lock(&gpio_lock);
- /* mask */
- gpio_imr_shadow |= (1 << gpio);
- gpio_write_imr(gpio_imr_shadow);
- /* ack */
- gpio_write_isr(1 << gpio);
- mutex_unlock(&gpio_lock);
-}
-
-static void twl4030_gpio_unmask(unsigned int irq)
-{
- int gpio = irq - twl4030_gpio_irq_base;
-
- mutex_lock(&gpio_lock);
- gpio_imr_shadow &= ~(1 << gpio);
- gpio_write_imr(gpio_imr_shadow);
- mutex_unlock(&gpio_lock);
-}
-
-/*
* These are the irqchip methods for the TWL4030 GPIO interrupts.
* Our IRQ handle method doesn't call these, but they will be called by
* other routines such as setup_irq() and enable_irq(). They are called
- * with cpu interrupts disabled and with a lock on the irq_controller_lock
+ * with cpu interrupts disabled and with a lock on the irq_desc.lock
* spinlock. This complicates matters, because accessing the TWL4030 GPIO
* interrupt controller requires I2C bus transactions that can't be initiated
* in this context. Our solution is to defer accessing the interrupt
- * controller to a kernel thread. We only need to support the unmask method.
+ * controller to a kernel thread.
*/
-static void twl4030_gpio_irq_mask_and_ack(unsigned int irq)
+static void twl4030_gpio_irq_ack(u
Re: [PATCH] OMAP: Increase VMALLOC_END to allow 256MB RAM
* Koen Kooi <[EMAIL PROTECTED]> [081004 12:39]: > > Op 2 okt 2008, om 11:29 heeft Kevin Hilman het volgende geschreven: > >> Mans Rullgard <[EMAIL PROTECTED]> writes: >> >>> This increases VMALLOC_END to 0x1800, making room for 256MB >>> RAM with the default 128MB vmalloc region. >>> >>> Signed-off-by: Mans Rullgard <[EMAIL PROTECTED]> >>> --- >>> arch/arm/plat-omap/include/mach/vmalloc.h |2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/ >>> plat-omap/include/mach/vmalloc.h >>> index d8515cb..b97dfaf 100644 >>> --- a/arch/arm/plat-omap/include/mach/vmalloc.h >>> +++ b/arch/arm/plat-omap/include/mach/vmalloc.h >>> @@ -17,5 +17,5 @@ >>> * along with this program; if not, write to the Free Software >>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA >>> 02111-1307 USA >>> */ >>> -#define VMALLOC_END (PAGE_OFFSET + 0x1700) >>> +#define VMALLOC_END (PAGE_OFFSET + 0x1800) >> >> Acked-by: Kevin Hilman <[EMAIL PROTECTED]> >> >> I have a similar patch locally, but the problem I currently have with >> it is that there is no longer any hole between vmalloc space and the >> beginning of IO space (the first virtual mappings start at >> 0xd800.) >> >> It's a bit unsafe, but IMO it's is probably OK for the short term. >> Longer term I think the virtual address space of the OMAP kernels >> needs to be reworked. It currenly just maps directly onto the >> physical address space, which makes the IO_ADDRESS() conversion macros >> simple, but leaves lots of wasted space in the virtual address space. Seems to be also safe for omap1, so I've pushed it. > I was told that omap3 support 512MB of ram, so is it possible to account > for that as well, or can we revisit that when the actual LP-DDR become > available? Well, to make room for a long term solution let's do the following: - Use OMAP1_IO_ADDRESS and OMAP2_IO_ADDRES and get rid of OMAP_IO_ADDRESS. This allows compiling in more code into a single binary - Remove the remaining io_v2p() and any XXX_IO_ADDRESS() in the drivers. Drivers should be now using ioremap() as noted earlier - Then we can further split OMAP2_IO_ADDRESS() into L3_IO_ADDRESS() and L4_IO_ADDRESS(), which allows us to move L4__VIRT out of the way Anybody got better ideas? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
