Re: [PATCH 00/34] omap drivers going upstream
On Mon, Sep 01, 2008 at 03:22:23AM +0200, andrzej zaborowski wrote:
> 2008/9/1 Felipe Balbi <[EMAIL PROTECTED]>:
> > On Sat, Aug 30, 2008 at 08:16:00PM +0300, Felipe Balbi wrote:
> >> From: Felipe Balbi <[EMAIL PROTECTED]>
> >>
> >> The following drivers are going upstream for integration.
> >> They have been sitting on linux-omap for quite a while just
> >> increasing the diff against mainline and probability of
> >> merge conflicts.
> >
> > Just one comment to this. I had to left bluetooth driver out of the
> > series because it's using omap2_block/allow_sleep in the driver code.
> > That should be fixed and the set_clock function should come via
> > platform_data to the driver.
> >
> > 53 static void hci_h4p_set_clk(struct hci_h4p_info *info, int *clock, int
> > enable)
> > 54 {
> > 55 unsigned long flags;
> > 56
> > 57 spin_lock_irqsave(&info->clocks_lock, flags);
> > 58 if (enable && !*clock) {
> > 59 NBT_DBG_POWER("Enabling %p\n", clock);
> > 60 clk_enable(info->uart_fclk);
> > 61 #ifdef CONFIG_ARCH_OMAP2
> > 62 if (cpu_is_omap24xx()) {
> > 63 clk_enable(info->uart_iclk);
> > 64 omap2_block_sleep();
> > 65 }
> > 66 #endif
> > 67 }
> > 68 if (!enable && *clock) {
> > 69 NBT_DBG_POWER("Disabling %p\n", clock);
> > 70 clk_disable(info->uart_fclk);
> > 71 #ifdef CONFIG_ARCH_OMAP2
> > 72 if (cpu_is_omap24xx()) {
> > 73 clk_disable(info->uart_iclk);
> > 74 omap2_allow_sleep();
> > 75 }
> > 76 #endif
> > 77 }
> > 78
> > 79 *clock = enable;
> > 80 spin_unlock_irqrestore(&info->clocks_lock, flags);
> > 81 }
> >
> > That driver is full of arch specific code and should be cleaned up ASAP.
> >
> > A few things I could get by briefly looking at the driver (actualy only
> > drivers/bluetooth/hci_h4p/core.c):
>
> There's also a curious issue in hci_h4p_interrupt I hit recently but
> after looking at the rest of the driver thought it was beating a dead
> horse..., but just in case it isn't:
> the driver assumes the OMAP UART, but then it uses UART_IIR_ID which
> is only valid for standard UARTs, causing OMAP-specific Rx errors to
> be ignored silently. Turns out that on my N810 there are actually Rx
> errors reported during firmware upload, but I didn't find a better way
> to handle them than to ignore them:
>
> --- a/drivers/bluetooth/hci_h4p/core.c
> +++ b/drivers/bluetooth/hci_h4p/core.c
> @@ -482,7 +491,14 @@ static irqreturn_t hci_h4p_interrupt(int irq, void *data)
>
> NBT_DBG("In interrupt handler iir 0x%.2x\n", iir);
>
> - iir &= UART_IIR_ID;
> + iir &= 0x1e; /* OMAP UART has wider INT than UART_IIR_ID */
> +
> + /*
> +* Often Rx errors are reported but reading the receive buffer
> +* gives the correct data, so treat it as an Rx interrupt.
> +*/
> + if (iir == 0xc)
> + iir = 0x4;
>
> if (iir == UART_IIR_MSI) {
> msr = hci_h4p_inb(info, UART_MSR);
>
> The tsc210x drivers should be upstreamable with the exception of ALSA
> code which needs to be converted to ASoC. Maruk Vasut found a leak in
> one error path, but I can't charge the device that has the tsc2102
> that I used for testing.
>
> I have some improvements to drivers/net/irda/omap-ir.c (clean-up and
> removing OMAP16xx specific bits to support OMAP1) but again, have no
> charger for the device.
Let's put Ville on the loop as he might be interested in it. Ville, any
comments ?
--
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 00/34] omap drivers going upstream
2008/8/30 Felipe Balbi <[EMAIL PROTECTED]>: > Add omap touchscreen driver This is just a tsc2101 touchscreen + pin multiplexing, I'm not really sure it should be upstream (but don't drop it without someone who knows commenting). I think someone even experimented with using a tsc2101 driver on the Hx board, but I may be wrong. Regards -- 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/34] omap drivers going upstream
2008/9/1 Felipe Balbi <[EMAIL PROTECTED]>:
> On Sat, Aug 30, 2008 at 08:16:00PM +0300, Felipe Balbi wrote:
>> From: Felipe Balbi <[EMAIL PROTECTED]>
>>
>> The following drivers are going upstream for integration.
>> They have been sitting on linux-omap for quite a while just
>> increasing the diff against mainline and probability of
>> merge conflicts.
>
> Just one comment to this. I had to left bluetooth driver out of the
> series because it's using omap2_block/allow_sleep in the driver code.
> That should be fixed and the set_clock function should come via
> platform_data to the driver.
>
> 53 static void hci_h4p_set_clk(struct hci_h4p_info *info, int *clock, int
> enable)
> 54 {
> 55 unsigned long flags;
> 56
> 57 spin_lock_irqsave(&info->clocks_lock, flags);
> 58 if (enable && !*clock) {
> 59 NBT_DBG_POWER("Enabling %p\n", clock);
> 60 clk_enable(info->uart_fclk);
> 61 #ifdef CONFIG_ARCH_OMAP2
> 62 if (cpu_is_omap24xx()) {
> 63 clk_enable(info->uart_iclk);
> 64 omap2_block_sleep();
> 65 }
> 66 #endif
> 67 }
> 68 if (!enable && *clock) {
> 69 NBT_DBG_POWER("Disabling %p\n", clock);
> 70 clk_disable(info->uart_fclk);
> 71 #ifdef CONFIG_ARCH_OMAP2
> 72 if (cpu_is_omap24xx()) {
> 73 clk_disable(info->uart_iclk);
> 74 omap2_allow_sleep();
> 75 }
> 76 #endif
> 77 }
> 78
> 79 *clock = enable;
> 80 spin_unlock_irqrestore(&info->clocks_lock, flags);
> 81 }
>
> That driver is full of arch specific code and should be cleaned up ASAP.
>
> A few things I could get by briefly looking at the driver (actualy only
> drivers/bluetooth/hci_h4p/core.c):
There's also a curious issue in hci_h4p_interrupt I hit recently but
after looking at the rest of the driver thought it was beating a dead
horse..., but just in case it isn't:
the driver assumes the OMAP UART, but then it uses UART_IIR_ID which
is only valid for standard UARTs, causing OMAP-specific Rx errors to
be ignored silently. Turns out that on my N810 there are actually Rx
errors reported during firmware upload, but I didn't find a better way
to handle them than to ignore them:
--- a/drivers/bluetooth/hci_h4p/core.c
+++ b/drivers/bluetooth/hci_h4p/core.c
@@ -482,7 +491,14 @@ static irqreturn_t hci_h4p_interrupt(int irq, void *data)
NBT_DBG("In interrupt handler iir 0x%.2x\n", iir);
- iir &= UART_IIR_ID;
+ iir &= 0x1e; /* OMAP UART has wider INT than UART_IIR_ID */
+
+ /*
+* Often Rx errors are reported but reading the receive buffer
+* gives the correct data, so treat it as an Rx interrupt.
+*/
+ if (iir == 0xc)
+ iir = 0x4;
if (iir == UART_IIR_MSI) {
msr = hci_h4p_inb(info, UART_MSR);
The tsc210x drivers should be upstreamable with the exception of ALSA
code which needs to be converted to ASoC. Maruk Vasut found a leak in
one error path, but I can't charge the device that has the tsc2102
that I used for testing.
I have some improvements to drivers/net/irda/omap-ir.c (clean-up and
removing OMAP16xx specific bits to support OMAP1) but again, have no
charger for the device.
Thanks
--
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/34] omap drivers going upstream
On Mon, Sep 01, 2008 at 01:37:37AM +0300, Felipe Balbi wrote: > On Sat, Aug 30, 2008 at 08:16:00PM +0300, Felipe Balbi wrote: > > From: Felipe Balbi <[EMAIL PROTECTED]> > > > > The following drivers are going upstream for integration. > > They have been sitting on linux-omap for quite a while just > > increasing the diff against mainline and probability of > > merge conflicts. > > Just one comment to this. I had to left bluetooth driver out of the typo, 'I had to leave' -- 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 00/34] omap drivers going upstream
On Sat, Aug 30, 2008 at 08:16:00PM +0300, Felipe Balbi wrote:
> From: Felipe Balbi <[EMAIL PROTECTED]>
>
> The following drivers are going upstream for integration.
> They have been sitting on linux-omap for quite a while just
> increasing the diff against mainline and probability of
> merge conflicts.
Just one comment to this. I had to left bluetooth driver out of the
series because it's using omap2_block/allow_sleep in the driver code.
That should be fixed and the set_clock function should come via
platform_data to the driver.
53 static void hci_h4p_set_clk(struct hci_h4p_info *info, int *clock, int
enable)
54 {
55 unsigned long flags;
56
57 spin_lock_irqsave(&info->clocks_lock, flags);
58 if (enable && !*clock) {
59 NBT_DBG_POWER("Enabling %p\n", clock);
60 clk_enable(info->uart_fclk);
61 #ifdef CONFIG_ARCH_OMAP2
62 if (cpu_is_omap24xx()) {
63 clk_enable(info->uart_iclk);
64 omap2_block_sleep();
65 }
66 #endif
67 }
68 if (!enable && *clock) {
69 NBT_DBG_POWER("Disabling %p\n", clock);
70 clk_disable(info->uart_fclk);
71 #ifdef CONFIG_ARCH_OMAP2
72 if (cpu_is_omap24xx()) {
73 clk_disable(info->uart_iclk);
74 omap2_allow_sleep();
75 }
76 #endif
77 }
78
79 *clock = enable;
80 spin_unlock_irqrestore(&info->clocks_lock, flags);
81 }
That driver is full of arch specific code and should be cleaned up ASAP.
A few things I could get by briefly looking at the driver (actualy only
drivers/bluetooth/hci_h4p/core.c):
* set_clock should come via platform_data
* gpio handling should use gpiolib instead of omap-specific ones
* irq should come via platform_data to avoid 'if (cpu_is_xxx())'
* unnecessary casts should be removed
* one line ifs do not need {}
* there's a memory leak on probe if no platform_data is found
* use of io_p2v() should be avoided on drivers, refer to Russel King's
patch
* OMAP_GPIO_IRQ() should not be used on the driver.
--
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
[PATCH 00/34] omap drivers going upstream
From: Felipe Balbi <[EMAIL PROTECTED]> The following drivers are going upstream for integration. They have been sitting on linux-omap for quite a while just increasing the diff against mainline and probability of merge conflicts. Idealy, we would have people maintaining those drivers but unfortunately it looks like it won't happen soon. linux-omap will be kept on the loop so we can comment on the patches and see the comments coming for the proper mailing lists. If anyone has objections to the patches, please say now before I send them to mainline. I'm planning to send them on next 9/11. Here's the dirstat between l-o and mainline tree before and after the patches: before: $ git diff --dirstat linus | sort -n 3.2% drivers/input/keyboard/ 4.2% arch/arm/plat-omap/ 4.2% drivers/cbus/ 4.2% drivers/spi/ 4.8% sound/oss/ 6.0% drivers/i2c/chips/ 7.0% sound/arm/omap/ 7.2% drivers/media/video/ 8.4% drivers/dsp/dspgateway/ 9.0% arch/arm/configs/ 15.6% arch/arm/mach-omap2/ 20.6% drivers/ after: $ git diff --dirstat linus | sort -n 4.8% drivers/bluetooth/ 7.0% arch/arm/plat-omap/ 7.7% drivers/ 7.9% sound/oss/ 11.6% sound/arm/omap/ 13.9% drivers/dsp/dspgateway/ 14.9% arch/arm/configs/ 25.7% arch/arm/mach-omap2/ Felipe Balbi (33): add lp5521 driver Add cbus driver add omap-sha1 driver add omap gpio expander driver add tlv320aic23 driver add tsl2563 driver add twl4030 drivers add innovator ps2 keypad driver add lm8323 keypad driver Add twl4030 keypad driver add tsc2301 keypad driver Add tsc2005 touchscreen driver Add omap touchscreen driver add tsc210x touchscreen driver add tsc2301 touchscreen driver add omap led drivers add tea5761 radio driver add ov9640 sensor driver add omap video drivers add omap Serial Trace Interface driver add OMAP HighSpeed mmc controller driver add omap nand drivers add omap irda driver add bq27x00 battery driver add TWL4030 Battery Charger Interface driver add TWL4030 RealTime Clock driver add tsc210x driver add tsc2301 driver add omap ehci bus glue add omap backlight support add several omap lcd drivers add omap 1-wire interface driver add bq27000 1-wire slave driver arch/arm/mach-omap2/board-2430sdp.c | 59 + arch/arm/plat-omap/include/mach/irqs.h |2 + arch/arm/plat-omap/include/mach/keypad.h|1 + drivers/Makefile|2 +- drivers/cbus/Kconfig| 89 ++ drivers/cbus/Makefile | 14 + drivers/cbus/cbus.c | 293 drivers/cbus/cbus.h | 36 + drivers/cbus/retu-headset.c | 355 + drivers/cbus/retu-pwrbutton.c | 118 ++ drivers/cbus/retu-rtc.c | 477 +++ drivers/cbus/retu-user.c| 423 ++ drivers/cbus/retu-wdt.c | 202 +++ drivers/cbus/retu.c | 466 +++ drivers/cbus/retu.h | 77 ++ drivers/cbus/tahvo-usb.c| 777 +++ drivers/cbus/tahvo-user.c | 405 ++ drivers/cbus/tahvo.c| 441 ++ drivers/cbus/tahvo.h| 61 + drivers/cbus/user_retu_tahvo.h | 75 ++ drivers/crypto/Kconfig |7 + drivers/crypto/Makefile |1 + drivers/crypto/omap-sha1-md5.c | 575 drivers/i2c/chips/Kconfig | 90 ++ drivers/i2c/chips/Makefile | 11 +- drivers/i2c/chips/gpio_expander_omap.c | 71 + drivers/i2c/chips/lp5521.c | 585 drivers/i2c/chips/tlv320aic23.c | 675 ++ drivers/i2c/chips/tsl2563.c | 739 +++ drivers/i2c/chips/twl4030-core.c| 1006 ++ drivers/i2c/chips/twl4030-gpio.c| 788 +++ drivers/i2c/chips/twl4030-madc.c| 455 +++ drivers/i2c/chips/twl4030-poweroff.c| 76 ++ drivers/i2c/chips/twl4030-pwrbutton.c | 163 +++ drivers/i2c/chips/twl4030-pwrirq.c | 226 drivers/i2c/chips/twl4030-usb.c | 779 +++ drivers/input/keyboard/Kconfig | 33 + drivers/input/keyboard/Makefile |4 + drivers/input/keyboard/innovator_ps2.c | 1280 ++ drivers/input/keyboard/lm8323.c | 925 + drivers/input/keyboard/omap-twl4030keypad.c | 415 ++ drivers/input/keyboard/tsc2301_kp.c | 475 +++ drivers/input/keyboard/twl4030-keypad.h | 82 ++ drivers/input/touchscreen/Kconfig | 25 + drivers/input/touchscreen/Makefile |4 + drivers/input/touchscreen/omap/Makefile | 10 + drivers/input/touchscreen/omap/omap_ts.c| 267 drivers/input/touchscreen/omap/omap_t
