[PATCH v2] cbus: Fix initialization of cached IRQ masks
This fixes the initialization of retu/tahvo cached IRQ masks. Signed-off-by: Michael Buesch m...@bues.ch --- v2: lowercase Index: linux-3.1.1/drivers/cbus/retu.c === --- linux-3.1.1.orig/drivers/cbus/retu.c2011-11-17 23:09:26.498214061 +0100 +++ linux-3.1.1/drivers/cbus/retu.c 2011-11-17 23:15:50.280659655 +0100 @@ -451,7 +451,8 @@ static int __devinit retu_probe(struct p (rev 4) 0x07, rev 0x0f); /* Mask all RETU interrupts */ - __retu_write_reg(retu, RETU_REG_IMR, 0x); + retu-mask = 0x; + __retu_write_reg(retu, RETU_REG_IMR, retu-mask); ret = request_threaded_irq(retu-irq, NULL, retu_irq_handler, IRQF_ONESHOT, retu, retu); Index: linux-3.1.1/drivers/cbus/tahvo.c === --- linux-3.1.1.orig/drivers/cbus/tahvo.c 2011-11-17 23:15:46.684674232 +0100 +++ linux-3.1.1/drivers/cbus/tahvo.c2011-11-17 23:15:50.280659655 +0100 @@ -346,7 +346,8 @@ static int __devinit tahvo_probe(struct (rev 4) 0x0f, rev 0x0f); /* Mask all TAHVO interrupts */ - __tahvo_write_reg(tahvo, TAHVO_REG_IMR, 0x); + tahvo-mask = 0x; + __tahvo_write_reg(tahvo, TAHVO_REG_IMR, tahvo-mask); ret = request_threaded_irq(irq, NULL, tahvo_irq_handler, IRQF_TRIGGER_RISING | IRQF_ONESHOT, -- Greetings, Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] cbus: Fix nested IRQ acking
chip-irq_ack is never called for nested threaded IRQs, because they
don't have a primary IRQ handler.
So we must ACK the IRQs in the toplevel retu and tahvo IRQ handler threads.
Signed-off-by: Michael Buesch m...@bues.ch
---
Index: linux-3.1.1/drivers/cbus/retu.c
===
--- linux-3.1.1.orig/drivers/cbus/retu.c2011-11-17 23:23:53.542699149
+0100
+++ linux-3.1.1/drivers/cbus/retu.c 2011-11-17 23:23:55.830689859 +0100
@@ -53,9 +53,6 @@ struct retu {
int irq;
- int ack;
- boolack_pending;
-
int mask;
boolmask_pending;
@@ -191,9 +188,10 @@ static irqreturn_t retu_irq_handler(int
mutex_lock(retu-mutex);
idr = __retu_read_reg(retu, RETU_REG_IDR);
imr = __retu_read_reg(retu, RETU_REG_IMR);
+ idr = ~imr;
+ __retu_write_reg(retu, RETU_REG_IDR, idr);
mutex_unlock(retu-mutex);
- idr = ~imr;
if (!idr) {
dev_vdbg(retu-dev, No IRQ, spurious?\n);
return IRQ_NONE;
@@ -232,15 +230,6 @@ static void retu_irq_unmask(struct irq_d
}
-static void retu_irq_ack(struct irq_data *data)
-{
- struct retu *retu = irq_data_get_irq_chip_data(data);
- int irq = data-irq;
-
- retu-ack |= (1 (irq - retu-irq_base));
- retu-ack_pending = true;
-}
-
static void retu_bus_lock(struct irq_data *data)
{
struct retu *retu = irq_data_get_irq_chip_data(data);
@@ -257,11 +246,6 @@ static void retu_bus_sync_unlock(struct
retu-mask_pending = false;
}
- if (retu-ack_pending) {
- __retu_write_reg(retu, RETU_REG_IDR, retu-ack);
- retu-ack_pending = false;
- }
-
mutex_unlock(retu-mutex);
}
@@ -271,7 +255,6 @@ static struct irq_chip retu_irq_chip = {
.irq_bus_sync_unlock= retu_bus_sync_unlock,
.irq_mask = retu_irq_mask,
.irq_unmask = retu_irq_unmask,
- .irq_ack= retu_irq_ack,
};
static inline void retu_irq_setup(int irq)
@@ -291,8 +274,7 @@ static void retu_irq_init(struct retu *r
for (irq = base; irq end; irq++) {
irq_set_chip_data(irq, retu);
- irq_set_chip_and_handler(irq, retu_irq_chip,
- handle_simple_irq);
+ irq_set_chip(irq, retu_irq_chip);
irq_set_nested_thread(irq, 1);
retu_irq_setup(irq);
}
Index: linux-3.1.1/drivers/cbus/tahvo.c
===
--- linux-3.1.1.orig/drivers/cbus/tahvo.c 2011-11-17 23:23:54.358695836
+0100
+++ linux-3.1.1/drivers/cbus/tahvo.c2011-11-17 23:23:55.830689859 +0100
@@ -48,11 +48,9 @@ struct tahvo {
int irq_end;
int irq;
- int ack;
int mask;
unsigned intmask_pending:1;
- unsigned intack_pending:1;
unsigned intis_betty:1;
};
@@ -138,9 +136,12 @@ static irqreturn_t tahvo_irq_handler(int
u16 id;
u16 im;
+ mutex_lock(tahvo-mutex);
id = __tahvo_read_reg(tahvo, TAHVO_REG_IDR);
im = __tahvo_read_reg(tahvo, TAHVO_REG_IMR);
id = ~im;
+ __tahvo_write_reg(tahvo, TAHVO_REG_IDR, id);
+ mutex_unlock(tahvo-mutex);
if (!id) {
dev_vdbg(tahvo-dev, No IRQ, spurious ?\n);
@@ -177,11 +178,6 @@ static void tahvo_irq_bus_sync_unlock(st
tahvo-mask_pending = false;
}
- if (tahvo-ack_pending) {
- __tahvo_write_reg(tahvo, TAHVO_REG_IDR, tahvo-ack);
- tahvo-ack_pending = false;
- }
-
mutex_unlock(tahvo-mutex);
}
@@ -203,22 +199,12 @@ static void tahvo_irq_unmask(struct irq_
tahvo-mask_pending = true;
}
-static void tahvo_irq_ack(struct irq_data *data)
-{
- struct tahvo*tahvo = irq_data_get_irq_chip_data(data);
- int irq = data-irq;
-
- tahvo-ack |= (1 (irq - tahvo-irq_base));
- tahvo-ack_pending = true;
-}
-
static struct irq_chip tahvo_irq_chip = {
.name = tahvo,
.irq_bus_lock = tahvo_irq_bus_lock,
.irq_bus_sync_unlock= tahvo_irq_bus_sync_unlock,
.irq_mask = tahvo_irq_mask,
.irq_unmask = tahvo_irq_unmask,
- .irq_ack= tahvo_irq_ack,
};
static inline void tahvo_irq_setup(int irq)
@@ -238,8 +224,7 @@ static void tahvo_irq_init(struct tahvo
for (irq = base; irq end; irq++) {
irq_set_chip_data(irq, tahvo);
- irq_set_chip_and_handler(irq, tahvo_irq_chip,
-
[PATCH 2/2] cbus: Fix initialization of cached IRQ masks
This fixes the initialization of retu/tahvo cached IRQ masks. Signed-off-by: Michael Buesch m...@bues.ch --- Index: linux-3.1.1/drivers/cbus/retu.c === --- linux-3.1.1.orig/drivers/cbus/retu.c2011-11-17 23:09:26.498214061 +0100 +++ linux-3.1.1/drivers/cbus/retu.c 2011-11-17 23:15:50.280659655 +0100 @@ -451,7 +451,8 @@ static int __devinit retu_probe(struct p (rev 4) 0x07, rev 0x0f); /* Mask all RETU interrupts */ - __retu_write_reg(retu, RETU_REG_IMR, 0x); + retu-mask = 0x; + __retu_write_reg(retu, RETU_REG_IMR, retu-mask); ret = request_threaded_irq(retu-irq, NULL, retu_irq_handler, IRQF_ONESHOT, retu, retu); Index: linux-3.1.1/drivers/cbus/tahvo.c === --- linux-3.1.1.orig/drivers/cbus/tahvo.c 2011-11-17 23:15:46.684674232 +0100 +++ linux-3.1.1/drivers/cbus/tahvo.c2011-11-17 23:15:50.280659655 +0100 @@ -346,7 +346,8 @@ static int __devinit tahvo_probe(struct (rev 4) 0x0f, rev 0x0f); /* Mask all TAHVO interrupts */ - __tahvo_write_reg(tahvo, TAHVO_REG_IMR, 0x); + tahvo-mask = 0x; + __tahvo_write_reg(tahvo, TAHVO_REG_IMR, tahvo-mask); ret = request_threaded_irq(irq, NULL, tahvo_irq_handler, IRQF_TRIGGER_RISING | IRQF_ONESHOT, -- Greetings, Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cbus-tahvo: Add tahvo_write_reg locking
On Mon, 7 Nov 2011 08:10:45 +0200
Felipe Balbi ba...@ti.com wrote:
Hi,
On Sat, Nov 05, 2011 at 05:19:54PM +0100, Michael Büsch wrote:
tahvo_write_reg() needs to take the mutex to avoid a race
condition with tahvo_set_clear_reg_bits:
tahvo_set_clear_reg_bits(): | tahvo_write_reg():
__tahvo_read_reg()|
| __tahvo_write_reg() -- race here
__tahvo_write_reg() |
Signed-off-by: Michael Buesch m...@bues.ch
---
Index: linux-3.1/drivers/cbus/tahvo.c
===
--- linux-3.1.orig/drivers/cbus/tahvo.c 2011-11-05 17:03:39.598846119
+0100
+++ linux-3.1/drivers/cbus/tahvo.c 2011-11-05 17:04:36.274768324 +0100
@@ -104,7 +104,9 @@ void tahvo_write_reg(struct device *chil
{
struct tahvo*tahvo = dev_get_drvdata(child-parent);
+ mutex_lock(tahvo-mutex);
__tahvo_write_reg(tahvo, reg, val);
+ mutex_unlock(tahvo-mutex);
yeah, my bad. The same should be done with tahvo_read_reg(). Care to
resend this patch adding the change to tahvo_read_reg() too...
I think tahvo_read_reg is fine without a lock.
read vs write is already atomic due to the cbus lock.
it's the same situation as for retu. where we also don't need the lock in
retu_read_reg.
--
Greetings, Michael.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cbus-tahvo: Add tahvo_write_reg locking
tahvo_write_reg() needs to take the mutex to avoid a race
condition with tahvo_set_clear_reg_bits:
tahvo_set_clear_reg_bits(): | tahvo_write_reg():
__tahvo_read_reg()|
| __tahvo_write_reg() -- race here
__tahvo_write_reg() |
Signed-off-by: Michael Buesch m...@bues.ch
---
Index: linux-3.1/drivers/cbus/tahvo.c
===
--- linux-3.1.orig/drivers/cbus/tahvo.c 2011-11-05 17:03:39.598846119 +0100
+++ linux-3.1/drivers/cbus/tahvo.c 2011-11-05 17:04:36.274768324 +0100
@@ -104,7 +104,9 @@ void tahvo_write_reg(struct device *chil
{
struct tahvo*tahvo = dev_get_drvdata(child-parent);
+ mutex_lock(tahvo-mutex);
__tahvo_write_reg(tahvo, reg, val);
+ mutex_unlock(tahvo-mutex);
}
EXPORT_SYMBOL(tahvo_write_reg);
--
Greetings, Michael.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/22] Tahvo cleanups and Retu optimization
On Mon, 11 Jul 2011 14:17:13 +0300 Felipe Balbi ba...@ti.com wrote: Hi Tony, here's the complete series... I'll stop playing with these for a while. If you have some free time to boot test on n8x0, I'd be really glad ;-) Maybe Michael could test too ?? Felipe Balbi (22): cbus: tahvo: convert spinlock into mutex cbus: tahvo: move to __devinit/__devexit sections cbus: tahvo: a switch looks better cbus: tahvo: don't go over 80 columns cbus: tahvo: drop the tasklet cbus: retu: set IRQF_ONESHOT flag cbus: tahvo: git it a context structure cbus: tahvo: pass tahvo to IRQ handler cbus: tahvo: introduce __tahvo_(read/write)_reg cbus: tahvo: drop some unneded defines cbus: retu: IRQ demux optimization cbus: tahvo: give it an irq_chip cbus: tahvo: start using irq_chip cbus: tahvo: usb: fix up to use threaded irqs cbus: tahvo drop the legacy interfaces cbus: tahvo: usb: drop unused variable cbus: tahvo: no need to mask interrupts on exit cbus: tahvo: drop the get_status hack cbus: tahvo: drop more unused interfaces cbus: tahvo: pass child device pointer cbus: tahvo: drop backlight interfaces cbus: tahvo: drop static global pointer arch/arm/mach-omap1/board-nokia770.c |6 - arch/arm/mach-omap2/board-n8x0.c |6 - drivers/cbus/retu.c | 18 +- drivers/cbus/tahvo-usb.c | 58 ++--- drivers/cbus/tahvo.c | 462 ++ drivers/cbus/tahvo.h | 16 +- 6 files changed, 283 insertions(+), 283 deletions(-) I currently lack a bit of time for testing, however I'll check it I can test them at some point. Don't hold your breath, though. Are you planning to implement a backlight driver for tahvo? I'm actually using the functionality that you removed in this patchset in the OpenWRT distribution. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/22] Tahvo cleanups and Retu optimization
On Mon, 11 Jul 2011 16:12:32 +0300 Felipe Balbi ba...@ti.com wrote: Are you planning to implement a backlight driver for tahvo? I'm actually using the functionality that you removed in this patchset in the OpenWRT distribution. if you have some extra documentation available, I could implement it whenever I have some extra couple hours to play with this again... I have no docs at all, but a led-tahvo.c would be really simple to get done :-) All I have is the old code. No docs. It seems rather simple, though. Only a PWM register. That's pretty straightforward. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/22] Tahvo cleanups and Retu optimization
On Mon, 11 Jul 2011 16:45:53 +0300 Felipe Balbi ba...@ti.com wrote: On Mon, Jul 11, 2011 at 03:41:26PM +0200, Michael Büsch wrote: On Mon, 11 Jul 2011 16:12:32 +0300 Felipe Balbi ba...@ti.com wrote: Are you planning to implement a backlight driver for tahvo? I'm actually using the functionality that you removed in this patchset in the OpenWRT distribution. if you have some extra documentation available, I could implement it whenever I have some extra couple hours to play with this again... I have no docs at all, but a led-tahvo.c would be really simple to get done :-) All I have is the old code. No docs. It seems rather simple, though. Only a PWM register. That's pretty straightforward. cool, any pointers would be good ;-) Pointers to what? How PWM works? http://en.wikipedia.org/wiki/Pulse_width_modulation You probably don't need to know the details, though. Just write a 0 to the register to turn the LED off. And write a 0xF (or 0x7F depending on tahvo revision) to the register to turn it fully on. Any value in between to dim the LED. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/22] Tahvo cleanups and Retu optimization
On Mon, 11 Jul 2011 17:03:28 +0300 Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Jul 11, 2011 at 03:51:23PM +0200, Michael Büsch wrote: On Mon, 11 Jul 2011 16:45:53 +0300 Felipe Balbi ba...@ti.com wrote: On Mon, Jul 11, 2011 at 03:41:26PM +0200, Michael Büsch wrote: On Mon, 11 Jul 2011 16:12:32 +0300 Felipe Balbi ba...@ti.com wrote: Are you planning to implement a backlight driver for tahvo? I'm actually using the functionality that you removed in this patchset in the OpenWRT distribution. if you have some extra documentation available, I could implement it whenever I have some extra couple hours to play with this again... I have no docs at all, but a led-tahvo.c would be really simple to get done :-) All I have is the old code. No docs. It seems rather simple, though. Only a PWM register. That's pretty straightforward. cool, any pointers would be good ;-) Pointers to what? How PWM works? http://en.wikipedia.org/wiki/Pulse_width_modulation You probably don't need to know the details, though. Just write a 0 to the register to turn the LED off. And write a 0xF (or 0x7F depending on tahvo revision) to the register to turn it fully on. Any value in between to dim the LED. no, not to PWM... pointers to the code using the old interface ;-) Oh, got it now. :D This patch connects the tahvo backlight API to the MIPID/omapfb backlight API: https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.38/820-backlight-fixes.patch The actual backlight control is done in userspace: http://bues.ch/gitweb?p=pwrtray.git;a=summary http://bues.ch/gitweb?p=pwrtray.git;a=blob;f=backend/backlight_omapfb.c;hb=HEAD -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: N8x0 display support (was: Re: The old omapfb support)
On Fri, 2011-04-29 at 16:33 +0300, Tomi Valkeinen wrote: So, my question is: what are the uses of N800's display with the mainline kernel? Are we happy with just having basic display functionality, or do people need all the features in the older blizzard driver? Well, not sure. The OpenWRT project runs an X server on the n810. It does so by using the X.org omapfb driver module, which accesses the hardware through /dev/fb0. http://git.pingu.fi/xf86-video-omapfb/ So we basically need that to work in one way or another. Another thing that we require is turning off the display for power saving reasons. We currently do this through FBIOBLANK ioctl with parameters FB_BLANK_POWERDOWN/FB_BLANK_UNBLANK. (The backlight is turned off by other means with the device asic) -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: N8x0 display support (was: Re: The old omapfb support)
On Fri, 2011-04-29 at 23:04 +0200, Michael Büsch wrote: On Fri, 2011-04-29 at 16:33 +0300, Tomi Valkeinen wrote: So, my question is: what are the uses of N800's display with the mainline kernel? Are we happy with just having basic display functionality, or do people need all the features in the older blizzard driver? Well, not sure. The OpenWRT project runs an X server on the n810. It does so by using the X.org omapfb driver module, which accesses the hardware through /dev/fb0. http://git.pingu.fi/xf86-video-omapfb/ So we basically need that to work in one way or another. Another thing that we require is turning off the display for power saving reasons. We currently do this through FBIOBLANK ioctl with parameters FB_BLANK_POWERDOWN/FB_BLANK_UNBLANK. (The backlight is turned off by other means with the device asic) Oh and we currently run the framebuffer in auto-update mode. I don't have any idea what would be needed to get it working in manual update mode. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The old omapfb support
On Wed, 2011-04-20 at 11:06 +0300, Tomi Valkeinen wrote: So if you first port the stuff and then add the depends-on OMAP1, I'm fine with it. Does the display even work on N8x0 with mainline kernel? I don't see any code for it in the board file. It needs some additional glue code, which can be found here: https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.38/301-nokia-board-additional.patch But with that code it works fine. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The old omapfb support
On Wed, 2011-04-20 at 14:31 +0300, Tomi Valkeinen wrote: On Wed, 2011-04-20 at 13:18 +0200, Michael Büsch wrote: On Wed, 2011-04-20 at 11:06 +0300, Tomi Valkeinen wrote: So if you first port the stuff and then add the depends-on OMAP1, I'm fine with it. Does the display even work on N8x0 with mainline kernel? I don't see any code for it in the board file. It needs some additional glue code, which can be found here: https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.38/301-nokia-board-additional.patch But with that code it works fine. Ok, thanks. I found an N810 from my HW stash, but as I don't have a serial adapter for it, kernel work will be rather difficult. I'll port the display driver, but I'm probably not able to test it at all. Ok thanks. I'll test it. I have access to the serial console. Also see the other patches in that SVN directory. If all those patches are applied, it does boot on 2.6.38. I'm not sure which ones are really required to make it boot. So you should probably first try to boot with the old driver to check if your setup works. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The old omapfb support
On Tue, 2011-04-19 at 15:30 +0300, Tony Lindgren wrote: But this again reminded me of the mess of having two display drivers, the old omapfb and the new DSS2. Many of the OMAP2 boards using the old driver should be quite easy to port to DSS2, with the exception of N800. DSS2 doesn't support OMAP1, so there's not much that can be done with those boards currently. Yeh we can just make old omapfb depends on ARCH_OMAP1. As he said, the old omapfb code is used on n8x0, which is OMAP2. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The old omapfb support
On Tue, 2011-04-19 at 15:41 +0300, Tomi Valkeinen wrote: On Tue, 2011-04-19 at 14:34 +0200, Michael Büsch wrote: On Tue, 2011-04-19 at 15:30 +0300, Tony Lindgren wrote: But this again reminded me of the mess of having two display drivers, the old omapfb and the new DSS2. Many of the OMAP2 boards using the old driver should be quite easy to port to DSS2, with the exception of N800. DSS2 doesn't support OMAP1, so there's not much that can be done with those boards currently. Yeh we can just make old omapfb depends on ARCH_OMAP1. As he said, the old omapfb code is used on n8x0, which is OMAP2. But as I also said, the old OMAP2 panel drivers can be ported to the new DSS driver. I just mentioned N800 because the panel driver for N800 is rather difficult to port and will require more work than the other OMAP2 panel drivers. So if you first port the stuff and then add the depends-on OMAP1, I'm fine with it. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] n810 USB: Initialize USB-FS
On Wed, 2011-03-09 at 19:20 +0100, Michael Buesch wrote:
The omap_otg platform device has to be registered in order
to get USB working on the n810.
I currently do this by calling the USB-FS init, which in turn
registers the omap_otg platform device.
The omap_usb_config structure values were copied from n770 code, so
I have no idea whether this is correct or not.
However, with all the patches I just sent (including this one),
I get USB working properly on the n810.
Not-yet-signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: linux-2.6.38-rc7/arch/arm/mach-omap2/board-n8x0.c
===
--- linux-2.6.38-rc7.orig/arch/arm/mach-omap2/board-n8x0.c2011-03-09
18:47:07.749508720 +0100
+++ linux-2.6.38-rc7/arch/arm/mach-omap2/board-n8x0.c 2011-03-09
18:59:14.355835051 +0100
@@ -40,6 +40,7 @@
#include plat/serial.h
#include plat/cbus.h
#include plat/gpio-switch.h
+#include plat/usb.h
#include mux.h
@@ -395,6 +396,14 @@ static struct musb_hdrc_platform_data tu
.config = musb_config,
};
+static struct omap_usb_config n8x0_omap_usb_config __initdata = {
+ .otg= 1,
+ .register_host = 1,
+ .register_dev = 1,
+ .hmc_mode = 16,
+ .pins[0]= 6,
+};
+
static void __init n8x0_usb_init(void)
{
int ret = 0;
@@ -417,6 +426,8 @@ static void __init n8x0_usb_init(void)
if (ret != 0)
goto err;
+ omap2_usbfs_init(n8x0_omap_usb_config);
+
printk(announce);
return;
Is there any news on this one?
If not, I'd suggest merging this in its current form, even if
we're unsure whether it's 100% correct, because it actually
makes the USB work on the n810.
If you merge this, you can add a
Signed-off-by: Michael Buesch m...@bu3sch.de
--
Greetings Michael.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nokia n810 LCD (MIPID/blizzard) on 2.6.38
On Wed, 2011-03-09 at 18:18 -0700, Paul Walmsley wrote: Perhaps this patch will do: http://marc.info/?l=linux-omapm=129971920806386w=2 Afterwards, it should be possible to look up the GPIO1 hwmod in mach-omap2/board-n8x0.c after the call to omap2_init_common_infrastructure(), and then to call omap_hwmod_no_setup_reset() on it. Perhaps you might wish to try it? Yep, this looks like the short-term fix I was looking for. We're still working on a possible long-term fix by fixing up the blizzard driver, but that will eventually take some time, if we finally get it sorted out... -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cbus-retu-wdt: Store all data in device struct
On Mon, 2011-03-07 at 09:43 +0200, Felipe Balbi wrote: - struct miscdevice retu_wdt_miscdev; + struct miscdevice miscdev; this rename is not part of $SUBJECT Well, that element is used in several new container_of() instances. retu_wdt_miscdev is needlessly long and just increases the line-length pain on the container_of() lines. The retu_wdt prefix is useless, because it's an element of the retu_wdt data structure. struct delayed_work ping_work; + struct mutexmutex; checkpatch.pl --strict will complain about this mutex not having a comment explaining it. Can you add something ? Is that really required? I mean, it's obvious what the mutex is used for and what it is protecting (the whole struct). -static int _retu_modify_counter(unsigned int new) +static inline void _retu_modify_counter(struct retu_wdt_dev *wdev, + unsigned int new) let the compiler inline it, maybe ?!? Ok, it doesn't change the object code either way. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cbus-retu-wdt: Remove unused nonstandard interfaces
On Thu, 2011-03-03 at 11:42 +0200, Felipe Balbi wrote: On Wed, Mar 02, 2011 at 05:11:58PM +0100, Michael Buesch wrote: @@ -175,9 +124,9 @@ static int retu_wdt_release(struct inode struct retu_wdt_dev *wdev = file-private_data; #ifndef CONFIG_WATCHDOG_NOWAYOUT - retu_wdt_ping_enable(retu_wdt); + retu_wdt_ping_enable(wdev); #endif - clear_bit(0, retu_wdt-users); + clear_bit(0, wdev-users); this hunk isn't part of this patch. Well, it's a compiler warning cleanup, so I thought it would be fine to go with the big cleanup patch. Is it necessary to do a separate patch for this? -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cbus-retu-wdt: Fix bitfield access
On Thu, 2011-03-03 at 11:43 +0200, Felipe Balbi wrote: On Wed, Mar 02, 2011 at 05:11:53PM +0100, Michael Buesch wrote: An unsigned int pointer must not be casted to an unsigned long pointer before use. Convert the bitfield to unsigned long to fix this. Also use clear_bit() in the release path. Signed-off-by: Michael Buesch m...@bu3sch.de This looks ok, I'm just wondering if the change on test_and_set_bit() from bit 1 to bit 0 should be on this patch. I guess not. Uh, well. If that's worth doing a separate patch, I'll do it. It doesn't actually really matter if we use bit 0, 1 or ... for this. I just thought it was weird to use the second bit. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cbus-retu-wdt: Fix bitfield access
On Thu, 2011-03-03 at 16:27 +0200, Felipe Balbi wrote: On Thu, Mar 03, 2011 at 03:21:29PM +0100, Michael Büsch wrote: On Thu, 2011-03-03 at 11:43 +0200, Felipe Balbi wrote: On Wed, Mar 02, 2011 at 05:11:53PM +0100, Michael Buesch wrote: An unsigned int pointer must not be casted to an unsigned long pointer before use. Convert the bitfield to unsigned long to fix this. Also use clear_bit() in the release path. Signed-off-by: Michael Buesch m...@bu3sch.de This looks ok, I'm just wondering if the change on test_and_set_bit() from bit 1 to bit 0 should be on this patch. I guess not. Uh, well. If that's worth doing a separate patch, I'll do it. It doesn't actually really matter if we use bit 0, 1 or ... for this. I just thought it was weird to use the second bit. yeah, I didn't read the whole code before making the comment, if you're sure no-one is using bit 0, then go for it. Having it separate, would help on bisecting should things go wrong. All users of the bitfield (two) are visible in the patch ;) -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nokia n810 LCD (MIPID/blizzard) on 2.6.38
On Tue, 2011-03-01 at 11:20 +0200, Felipe Balbi wrote: On Mon, Feb 28, 2011 at 09:45:43PM +0100, Michael Buesch wrote: The n810 LCD does not work on the 2.6.38(-rc6) kernel due to changes in the OMAP GPIO-hwmod code. The hwmod code performs a soft-reset on the GPIO module. The first GPIO module carries the MIPID nreset line, which is toggled due to the hwmod soft reset. This resets Blizzard and breaks it, because it assumes the LCD was left in the state that the bootloader initialized it to: so that's the bug which needs to be fixed. Unfortunately I don't have any documentation available anymore. Maybe someone from Nokia would fix that ? I'm wondering if a better fix suitable for the mainline kernel inclusion could be found. Any ideas? Don't depend on the bootloader :-) Yeah that's the obvious fix, of course. However, it requires deep knowledge of the device and/or hardware documentation. Both of which I don't have. The driver also doesn't seem to have a maintainer. If someone can get me documentation, I'm willing to implement the required bits to remove the bootloader dependency. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nokia n810 LCD (MIPID/blizzard) on 2.6.38
On Tue, 2011-03-01 at 11:23 -0500, Varadarajan, Charulatha wrote:
My temporary workaround to this issue is to disable
soft reset for the first GPIO module:
static struct omap_hwmod omap2420_gpio1_hwmod = {
.name = gpio1,
.flags = HWMOD_INIT_NO_RESET, /* Workaround: Don't
reset the n810 MIPID */
NACK.
As the problem is specific to the board settings, this shall be handled
in the board file itself.
Yeah, sure. But how can I handle this in the board file? Is
there a hwmod API for this?
I'm wondering if a better fix suitable for the mainline
kernel inclusion could be found.
Any ideas?
Re-initialize the nreset line of the Blizzard in the
corresponding board file.
That is not sufficient. The blizzard chip has to be reinitialized
completely.
Code for that doesn't exist in the current driver. It currently depends
on the bootloader doing the lowlevel init. As long as I don't have
documentation for that chip, I'm stuck with that.
--
Greetings Michael.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cbus-retu: Acquire mutex on write operation
On Mon, 2011-02-28 at 10:33 +0200, Felipe Balbi wrote: On Sun, Feb 27, 2011 at 12:34:33AM +0100, Michael Buesch wrote: The mutex has to be acquired on register write to avoid interference with a simultaneous retu_set_clear_reg_bits operation. Signed-off-by: Michael Buesch m...@bu3sch.de good catch, please do the same for retu_read_reg() I don't think this is necessary, because cbus_read_reg() and cbus_write_reg() are atomic due to the cbus host-lock. I think we can depend on this. We could probably improve the comment on the lock in cbus_transfer(), though. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cbus-retu: Fix nested IRQ handling
On Mon, 2011-02-28 at 10:36 +0200, Felipe Balbi wrote: On Sun, Feb 27, 2011 at 06:17:01PM +0100, Michael Buesch wrote: handle_nested_irq() expects a global IRQ number, so the irq_base has to be added to the RETU irq number. Signed-off-by: Michael Buesch m...@bu3sch.de Good catch, while at that, could you also cook another patch to add locking on retu_irq_handler ? We are using the internal lockless version of the read/write functions, so we need to hold the mutex before reading/writing to avoid problems. Ok, it probably is safe without locking (due to the reads being atomic), but I agree that it's more robust to add some locking here. I'll send a patch. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Booting n8x0 on mainline without UART
On Tue, 2011-02-22 at 10:41 +0530, Anand Gadiyar wrote: I'm trying to boot up the mainline kernel on an n800 device. I don't have a functional UART up and running - so I cannot see any console messages. I don't know about the n800, but for the n810 there are quite some patches needed to get it working correctly. https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.37 Not all of those patches are strictly required for basic bootup, though. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Nokia CBUS code
Hi there, I was wondering if somebody was working on mainline integration of the cbus code. That probably is a major effort, as it needs a rewrite in some parts, but I'm certainly interested in getting it mainlined, because I'm currently developing a driver on top of it. It's a battery management driver. If somebody is interested, it can be found here: https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.37/900-n810-battery-management.patch It currently doesn't support charging, however, almost all information for the charging hardware is available. Registers and bits are known. The only thing that's missing is the interpreter of the calibration data. That's going to be some major effort, though, because bme uses software floating point for that. That's currently screwing my brains, but it should be doable. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Nokia CBUS code
On Tue, 2011-02-22 at 13:05 +0200, Felipe Balbi wrote: That probably is a major effort, as it needs a rewrite in some parts, but I'm certainly interested in getting it mainlined, because I'm currently developing a driver on top of it. We're almost there actually. Retu is in great shape and tahvo is a lot simpler, but it still needs help. Probably porting the changes I made on retu would be the way to go. Ok, that's pretty cool. I'll try to port this to OpenWRT, soon, to check how it works. On another issue: Did you try tahvo-usb recently? I was trying it with the OpenWRT cbus codebase (which is some months old) and I couldn't get it to work. It would always crash with some weird NULL pointer accesses and stuff like this. I was wondering if the omap-tree tahvo code would actually work on the USB device. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Booting n8x0 on mainline without UART
On Tue, 2011-02-22 at 09:18 -0800, Tony Lindgren wrote: * Michael Büsch m...@bu3sch.de [110222 02:33]: On Tue, 2011-02-22 at 10:41 +0530, Anand Gadiyar wrote: I'm trying to boot up the mainline kernel on an n800 device. I don't have a functional UART up and running - so I cannot see any console messages. I don't know about the n800, but for the n810 there are quite some patches needed to get it working correctly. https://dev.openwrt.org/browser/trunk/target/linux/omap24xx/patches-2.6.37 Not all of those patches are strictly required for basic bootup, though. Care to put together a series of patches that could be integrated to mainline kernel for 2.6.39? As I just said in the other thread: The patchset is not ready for inclusion. The omap tree CBUS code is more advanced, in fact. -- Greetings Michael. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
