Re: [PATCH 2/2] Input: Make lm8323 sticky key to work with console
On Thu, May 15, 2008 at 10:14:24AM +0200, andrzej zaborowski wrote: On 15/05/2008, Felipe Balbi [EMAIL PROTECTED] wrote: On Wed, May 14, 2008 at 09:01:19PM -0700, Tony Lindgren wrote: This allows using N810 keyboard from console by adding optional Fn and shift sticky key handling by passing them from platform_data. Currently some not so obvious mappings are: - Pipe is Fn + Enter - Delete is Fn + Backspace - Escape is Fn + Ctrl no tab? :-( Fn + space maybe?? :-p Fn + Right is assigned in the patch (I check too :) ). But I'm not sure whther that should be done in the lm8323 driver or elsewhere. The existence of keys like Fn and Shift is N810-specific and lm8323 is just a gpio matrix keypad chip. but that's coming from board file. It should be ok. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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: N810: linux-2.6.26-rc2-omap1 with muru.com N810 patches
On Thu, 15 May 2008 09:09:14 -0500, green [EMAIL PROTECTED] wrote: Hello, I am trying to run Debian Sid on a Nokia N810. I have tried several different kernel sources and lots of different configs without seeing anything but the NOKIA splash screen. Therefore, my current goal has been reduced to simply booting a kernel and seeing some text output from it so I know it is at least attempting to boot. Once I've succeeded in that I'll continue toward my ultimate goal of running Debian Sid. I have built a Debian Sid armel chroot on the N810 and have compiled many kernels in the chroot. I send the kernels to the N810 using the flasher (-f -k $IMAGE -R). I have used these three different kernel sources with two results. maemo 2008 kernel http://repository.maemo.org/pool/maemo4.0.1/free/k/kernel-source-rx-34/ 2.6.25-omap1 http://www.muru.com/linux/omap/patches/patch-2.6.25-omap1.bz2 2.6.26-rc2-omap1 with muru.com N810 patches http://source.mvista.com/git/?p=linux-omap-2.6.git http://www.muru.com/linux/n8x0/n8x0-2008-05-12.tar.gz Always, one of these two happens after I flash the compiled zImage: - The NOKIA splash screen is displayed for about 20 seconds and then the N810 powers off. - The splash screen is shown for 1 second and the device resets (loop); I have to remove the battery. flasher --enable-rd-mode --set-rd-flags=serial-console,no-lifeguard-reset -f I have enabled CONFIG_FRAMEBUFFER_CONSOLE and disabled CONFIG_FB_OMAP_MANUAL_UPDATE. The last config I've tried (with linux-2.6.26-rc2-omap1 +N810) is attached. I'm using gcc 4.3.0-4 and binutils 2.18.1~cvs20080103-4 in Debian Sid. I have enable RD mode on the N810 and disabled the lifeguard-reset flag. One of the N810 patches from muru.com changes the N810 machine number to ; I've tried both that and the 1548, on the assumption that perhaps a bootloader update has fixed the machine number. I've used 'make n800_defconfig' (2.6.26-rc2-omap1 +N810) and changed only the default cmdline without success. Also I've used 'make nokia_2420_defconfig' with the maemo kernel. try also flasher --set-root-device mmc Note that the initfs, X-Loader, NOLO secondary bootloader, and NOLO cold flasher (2nd) images are all from the RX-44_2008SE_2.2007.51-3_PR_COMBINED_MR0_ARM.bin maemo FIASCO (I guess) image. The rootfs is probably from an older one (I never updated it) but I'm assuming that the rootfs doesn't matter anyway. Please ask for any more information that might be helpful. Oh, and one more question that I ought to know the answer to by now: Is it okay to do 'make zImage', then change the config, then 'make zImage' again without doing a 'make clean', so long as nothing in the source has been changed? That saves a lot of time. Yes, it's ok. ;-) -- Best Regards, Felipe Balbi http://felipebalbi.com [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] This patch adds the driver to turn on the TFP410 framer to get DVI output working on the beagleboard
,
+ .cleanup= omap3beagle_panel_cleanup,
+ .enable = omap3beagle_panel_enable,
+ .disable= omap3beagle_panel_disable,
+ .get_caps = omap3beagle_panel_get_caps,
+};
+
+static int omap3beagle_panel_probe(struct platform_device *pdev)
+{
+ omapfb_register_panel(omap3beagle_panel);
+ return 0;
+}
+
+static int omap3beagle_panel_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap3beagle_panel_suspend(struct platform_device *pdev,
+pm_message_t mesg)
+{
+ return 0;
+}
+
+static int omap3beagle_panel_resume(struct platform_device *pdev)
+{
+ return 0;
+}
+
+struct platform_driver omap3beagle_panel_driver = {
+ .probe = omap3beagle_panel_probe,
+ .remove = omap3beagle_panel_remove,
+ .suspend= omap3beagle_panel_suspend,
+ .resume = omap3beagle_panel_resume,
+ .driver = {
+ .name = omap3beagle_lcd,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init omap3beagle_panel_drv_init(void)
+{
+ return platform_driver_register(omap3beagle_panel_driver);
+}
+
+static void __exit omap3beagle_panel_drv_exit(void)
+{
+ platform_driver_unregister(omap3beagle_panel_driver);
+}
+
+module_init(omap3beagle_panel_drv_init);
+module_exit(omap3beagle_panel_drv_exit);
--
1.5.4.3
--
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
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[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: [RFC PATCH 1/5] USB: MUSB: Switch to a_idle when micr o/mini-a cable is attached
On Fri, 16 May 2008 10:38:43 -0700, Tony Lindgren [EMAIL PROTECTED] wrote: * Felipe Balbi [EMAIL PROTECTED] [080513 05:33]: From: ext Felipe Balbi [EMAIL PROTECTED] This is mostly cosmetic but can help us in the future making musb driver not insertion-based. I mean, whenever we attach micro-/mini-A connector to musb-based devices, we instantaneously turn vbus on where we should wait until we need to use the bus. This would break standard host behavious of basic USB devices that don't support SRP? Hmm... the way it is today yeah, but I can keep the behaviour that we try to turn vbus on whenever we attach micro/mini-a. But I was thinking on letting a file manager (or any other application that would use usb) to turn vbus on. If it's a mass storage device, you could let file manager write to session sysfs entry (which I'm changing to make it work on both roles). Tony Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- drivers/usb/musb/tusb6010.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c index 1f3643b..9f92cef 100644 --- a/drivers/usb/musb/tusb6010.c +++ b/drivers/usb/musb/tusb6010.c @@ -673,6 +673,8 @@ tusb_otg_ints(struct musb *musb, u32 int_src, void __iomem *tbase) default_a = is_host_enabled(musb); DBG(2, Default-%c\n, default_a ? 'A' : 'B'); musb-xceiv.default_a = default_a; +musb-xceiv.state = default_a ? OTG_STATE_A_IDLE +: OTG_STATE_B_IDLE; tusb_source_power(musb, default_a); /* Don't allow idling immediately */ -- 1.5.5.1.125.gc697a -- 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 -- Best Regards, Felipe Balbi http://felipebalbi.com [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: enabling uart2 on omap5912 osk
On Wed, 21 May 2008 10:44:28 -0700, Tony Lindgren [EMAIL PROTECTED] wrote:
* mohammed shareef [EMAIL PROTECTED] [080521 10:12]:
i see the following lines in the omap-osk.c file regarding the uarts:
static struct omap_uart_config osk_uart_config __initdata = {
.enabled_uarts = (1 0),
};
what does it mean? i want all my uarts (1,2,3) enabled. how do i have
to modify the above line?
How about try .enabled_uarts = 3
this would enable only uarts 1 and 2, right?
maybe it's enough :-p
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[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: enabling uart2 on omap5912 osk
On Thu, 22 May 2008 03:46:37 +0530, mohammed shareef [EMAIL PROTECTED] wrote: when i type: ls -l /dev/ttyS0 crw-rw-rw-1 root root 4, 64 Aug 8 2004 \0x1b[1;35m/dev/ttyS0\0x1b[0m # ls -l /dev/ttyS1 -rw-r-- ... that's a bit weird. What does cat /proc/tty/drivers show ? -- Best Regards, Felipe Balbi http://felipebalbi.com [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: enabling uart2 on omap5912 osk
On Thu, 22 May 2008 04:01:17 +0530, mohammed shareef [EMAIL PROTECTED] wrote: # cat /proc/tty/drivers /dev/tty /dev/tty5 0 system:/dev/tty /dev/console /dev/console5 1 system:console /dev/ptmx/dev/ptmx 5 2 system /dev/vc/0/dev/vc/0 4 0 system:vtmaster serial /dev/ttyS 4 64-67 serial Here's what you're looking for. pty_slave/dev/pts 136 0-1048575 pty:slave pty_master /dev/ptm 128 0-1048575 pty:master pty_slave/dev/ttyp 3 0-255 pty:slave pty_master /dev/pty2 0-255 pty:master unknown /dev/tty4 1-63 console this is the output.. It seems ok, no idea why the 4 doesn't appear in ls -l. Sorry :-s -- Best Regards, Felipe Balbi http://felipebalbi.com [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: omap osk and mistral touchscreen-ads7846
On Thu, 22 May 2008 12:53:11 +0530, mohammed shareef [EMAIL PROTECTED] wrote: hi arun/all, when i do cat for interrupts i get: # cat /proc/interrupts CPU0 19: 0 MPU DMA 20: 0 MPU DMA 21: 0 MPU DMA 22: 0 MPU DMA 23: 0 MPU DMA 24: 0 MPU DMA 25: 9834 MPU LCD DMA 31: 3 MPU lcdc 33: 1 MPU omap-keypad 36:313 MPU i2c_omap 46:148 MPU serial 54: 19893 MPU 32KHz timer 78: 0 MPU peripheral wakeup 85: 0 MPU DMA 86: 0 MPU DMA 87: 0 MPU DMA 88: 0 MPU DMA 89: 0 MPU DMA 90: 0 MPU DMA 91: 0 MPU DMA 92: 0 MPU DMA 93: 0 MPU DMA 94: 0 MPU DMA 160: 1409GPIO eth0 164: 24GPIO spi2.0 Here's your interrupt line (if I'm not wrong). This touchscreen is connected via spi. If you go to arch/arm/mach-omap1/board-osk.c you'll see a spi_board_info. Just to be sure issue: watch 'cat /proc/interrupts' and keep touching the touchscreen. spi2.0 value should increase. -- Best Regards, Felipe Balbi http://felipebalbi.com [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: zlib error in x-windows on omap osk
On Sat, May 31, 2008 at 12:10:31PM +0530, mohammed shareef wrote: Hi all, when i run the autogen script for Xfonf in xlibs for x-windows, i get the following error.. checking for gzopen in -lz... no configure: error: *** zlib is required [sbox-ARM-GLIBC: ~/xwin_snapshot/xlibs/Xfont] i have already installed zlib.. all the previous xlib files compiled without any error. how about zlib-dev? -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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: zlib error in x-windows on omap osk
On Sun, 1 Jun 2008 11:55:11 +0530, mohammed shareef [EMAIL PROTECTED] wrote: Hi Felipe, what is zlib-dev? as per the tutorials the dependency for the Xlib is only zlib. i have installed zlib-1.2.2. you need the development version of it. the one that comes with the correct header files. -- Best Regards, Felipe Balbi http://felipebalbi.com [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: Booting 2.6.25 on the OMAP5912OSK
Hi, On Sun, 01 Jun 2008 13:06:03 -0400, Philip Balister [EMAIL PROTECTED] wrote: i2c_omap i2c_omap.1: Transmit overflow tps65010: power off button Sounds like a bug in our i2c-omap.c Tony do you know about any issues with i2c-omap.c after highspeed i2c was introduced ? This could be a regression, I remember seeing this on some tests I was doing with twl4030 but they seemed to vanish. Looks like I missed something. I'll try to reproduce my bug with twl4030 and after that dig a bit on i2c driver and i2c omap trms (ugh). Anyways, if you could enable all debugging in i2c and get more info when it happens, that would be great ;-) -- Best Regards, Felipe Balbi http://felipebalbi.com [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: Booting 2.6.25 on the OMAP5912OSK
Hi, On Sun, 01 Jun 2008 13:06:03 -0400, Philip Balister [EMAIL PROTECTED] wrote: i2c_omap i2c_omap.1: Transmit overflow tps65010: power off button Sounds like a bug in our i2c-omap.c Tony do you know about any issues with i2c-omap.c after highspeed i2c was introduced ? This could be a regression, I remember seeing this on some tests I was doing with twl4030 but they seemed to vanish. Looks like I missed something. I'll try to reproduce my bug with twl4030 and after that dig a bit on i2c driver and i2c omap trms (ugh). Anyways, if you could enable all debugging in i2c and get more info when it happens, that would be great ;-) -- Best Regards, Felipe Balbi http://felipebalbi.com [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: zlib error in x-windows on omap osk
On Mon, 2 Jun 2008 14:36:06 +0530, mohammed shareef [EMAIL PROTECTED] wrote: Where can i get the development version of zlib? but its is not discussed in the tutorial. $ apt-cache search zlib dev ;-) Are you using maemo sdk? If they don't have zlib1g-dev you're gonna have to rebuild the library :-s -- Best Regards, Felipe Balbi http://felipebalbi.com [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: user space program for omap gpio
On Mon, Jun 02, 2008 at 10:28:02PM +0530, mohammed shareef wrote: Hi, i want to access the omap5912 GPIO pins from user space... like reading the pin or writing to it from a user space program. is it possible? Maybe you can use gpio-switch for reading. But for writing, then you would have to write your own module with, maybe, ioctl for writing to gpios. I don't know of any already implemented way for completely handling gpios via userland. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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: omap5912-osk bad magic number
On Mon, Jun 02, 2008 at 11:13:48PM +0530, mohammed shareef wrote: Hi, i tried to re-compile my kernel by adding a few features and then transfered the new image using u-boot. Unfortunately am getting the following error: ## Booting image at 0010 ... Bad Magic Number OMAP5912 OSK # The transfer seems to be complete and proper. all the environment variables are also ok. i tried replacing the new image with the previous working image. that also fails. could some one tell me whats worng? use uImage instead of zImage -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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: omap5912-osk bad magic number
Just a tip, On Tue, 3 Jun 2008 15:02:50 +0530, mohammed shareef [EMAIL PROTECTED] wrote: /tools/mkimage -A arm -O linux -T kernel -C gzip -a 0x10c08000 -e 0x10c08000 -n 'Linux Kernel Image' -d linux.bin.gz uImage.cc put mkimage in you path (/usr/local/bin, for instance) and issue make uImage when building the kernel. -- Best Regards, Felipe Balbi http://felipebalbi.com [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: user space program for omap gpio
On Tue, 3 Jun 2008 15:21:02 +0530, mohammed shareef [EMAIL PROTECTED] wrote: Hi Felipe, could you give me some useful pointers on how to use the gpio-switch and ioctl to read and write gpio? gpio-switch you can check in arch/arm/mach-omap2/board-n800.c about using ioctls for controlling the gpio, you'll have to write a module from scratch. afaict, there's no way of controlling gpio from userland. Besides gpiofs that a friend was writing and never finished :-p I'll try to reach him and ask him to send as RFC cuz it was a good work anyway :-) -- Best Regards, Felipe Balbi http://felipebalbi.com [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: user space program for omap gpio
On Tue, 3 Jun 2008 07:35:38 -0400, Eduardo Valentin [EMAIL PROTECTED] wrote: Hi Felipe, Actually, David Brownell is working on something very similar. sysfs for gpio lib. http://kerneltrap.org/mailarchive/linux-kernel/2008/4/28/1640134 That'd be really useful indeed. But I believe it is not merged yet. That's actually really good :-) -- Best Regards, Felipe Balbi http://felipebalbi.com [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: Booting 2.6.25 on the OMAP5912OSK
On Tue, Jun 03, 2008 at 09:49:27AM -0700, Tony Lindgren wrote: Hmm, yeah sounds like something is broken.. Anybody want to try to narrow it down with git-bisect? ok, there's an easy way to reproduce. echo host /sys/devices/platform/musb_hdrc/mode from 3430sdp. Some of the transfers in drivers/i2c/chips/twl4030-usb.c:twl4030_set_host() is trigerring the overflow. btw, that XUDF bit, means _underflow_ and not overflow, so anyone who finnishes the patch first care to send also a cleanup patch fixing that info ;-) I don't remember when it started to happen, but I remember that it used to work without any underflow. Still need to read more, maybe i'll do it tomorrow. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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] Fix for the i2c initialiation error on 2430sdp
On Fri, 6 Jun 2008 18:42:56 +0530, arun c
[EMAIL PROTECTED] wrote:
static int __init omap2430_i2c_init(void)
{
- omap_register_i2c_bus(1, 400, NULL, 0);
omap_register_i2c_bus(2, 2600, NULL, 0);
+ omap_register_i2c_bus(1, 400, NULL, 0);
maybe there's a hw restriction that you must initiliaze
hs bus first?
Could you check on i2c chapter of your trm?
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[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 3/3] radio-tea5761: Update driver
On Mon, Jun 09, 2008 at 04:05:43PM -0400, Eduardo Valentin wrote:
+static void tea5761_set_audout_mode(struct tea5761_device *tea, int audmode)
{
- struct tea5761_regs *r = tea-regs;
-
- if (!(r-tnctrl TEA5761_TNCTRL_PUPD0)) {
- r-tnctrl = ~(TEA5761_TNCTRL_AFM | TEA5761_TNCTRL_MU |
-TEA5761_TNCTRL_HLSI);
- r-testreg |= TEA5761_TESTREG_TRIGFR;
- r-tnctrl |= TEA5761_TNCTRL_PUPD0;
- return tea5761_write_regs(tea);
+ struct dvb_frontend *fe = tea-fe;
+ struct dvb_tuner_ops *fe_tuner_ops = fe-ops.tuner_ops;
+ struct analog_parameters params = {
+ .mode = V4L2_TUNER_RADIO,
+ .frequency = tea-freq,
+ .audmode= audmode,
+ };
+
+ if (NULL == fe_tuner_ops-set_analog_params) {
+ dev_warn(tea-dev,
+ Tuner frontend module has no way to set frequency\n);
+ return;
}
+ if (!fe_tuner_ops-set_analog_params(fe, params))
+ tea-audmode = audmode;
instead of both ifs, how about:
if (fe_tuner_ops-set_analog_params) {
tea-audmode =
fe_tuner_ops-set_analog_params(fe, params) ?
audmode : 0;
}
}
+static void tea5761_mute(struct tea5761_device *tea, int on)
+{
+ struct dvb_frontend *fe = tea-fe;
+ struct dvb_tuner_ops *fe_tuner_ops = fe-ops.tuner_ops;
+ struct analog_parameters params = {
+ .mode = on ? T_STANDBY : V4L2_TUNER_RADIO,
+ .frequency = tea-freq,
+ .audmode= tea-audmode,
+ };
+
+ if (NULL == fe_tuner_ops-set_analog_params) {
+ dev_warn(tea-dev,
+ Tuner frontend module has no way to set frequency\n);
+ return;
}
+ if (!fe_tuner_ops-set_analog_params(fe, params))
+ tea-mute = on;
samething here.
}
static int tea5761_i2c_driver_probe(struct i2c_client *client,
@@ -422,12 +407,24 @@ static int tea5761_i2c_driver_probe(struct i2c_client
*client,
mutex_init(tea-mutex);
- tea-i2c_dev = client;
+ /* Tuner attach */
+ if (!dvb_attach(tea5761_attach, tea-fe, client-adapter,
+ client-addr)) {
+ dev_err(client-dev, Could not attach tuner\n);
+ err = -ENODEV;
+ goto exit;
+ }
+
+ /* initialize and power off the chip */
+ tea5761_power_up(tea);
+ tea5761_set_audout_mode(tea, V4L2_TUNER_MODE_STEREO);
+ tea5761_mute(tea, 0);
+ tea5761_power_down(tea);
/* V4L initialization */
video_dev = video_device_alloc();
if (video_dev == NULL) {
if (!video_dev)
- dev_err(client-dev, couldn't allocate memory\n);
+ dev_err(client-dev, Could not allocate memory\n);
err = -ENOMEM;
goto exit;
}
@@ -436,25 +433,15 @@ static int tea5761_i2c_driver_probe(struct i2c_client
*client,
*video_dev = tea5761_video_device;
video_dev-dev = client-dev;
i2c_set_clientdata(client, video_dev);
-
- /* initialize and power off the chip */
- tea5761_read_regs(tea);
- tea5761_set_audout_mode(tea, V4L2_TUNER_MODE_STEREO);
- tea5761_mute(tea, 0);
- tea5761_power_down(tea);
-
- tea5761.video_dev = video_dev;
- tea5761.i2c_dev = client;
+ tea-video_dev = video_dev;
+ tea-dev = client-dev;
err = video_register_device(video_dev, VFL_TYPE_RADIO, radio_nr);
if (err) {
- dev_err(client-dev, couldn't register video device\n);
+ dev_err(client-dev, Could not register video device\n);
goto err_video_alloc;
}
- dev_info(client-dev, tea5761 (version %d) detected\n,
- (tea-regs.manid 12) 0xf);
-
return 0;
err_video_alloc:
@@ -492,7 +479,8 @@ static int __init tea5761_init(void)
{
int res;
- if ((res = i2c_add_driver(tea5761_driver))) {
+ res = i2c_add_driver(tea5761_driver);
+ if (res) {
printk(KERN_ERR DRIVER_NAME : driver registration failed\n);
return res;
not needed, return i2c_add_driver(tea5761_driver); is enough as i2c
subsystem already prints out error messages in case of failed probe.
}
--
Best Regards,
Felipe Balbi
[EMAIL PROTECTED]
http://blog.felipebalbi.com
--
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] usb: musb: MUSB_OTG should depend on PM
Current musb Kconfig causes cyclic depency on x86 arch. The best fix is to depend on PM in order to build on OTG mode. Anyone interested in reproducing the error in your linux-omap trees, just make ARCH=x86 menuconfig Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- drivers/usb/musb/Kconfig |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index a485a86..acbbd5f 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -88,10 +88,9 @@ config USB_MUSB_PERIPHERAL (With a Mini-AB connector, you should enable USB OTG.) config USB_MUSB_OTG - depends on USB USB_GADGET EXPERIMENTAL + depends on USB USB_GADGET PM EXPERIMENTAL bool Both host and peripheral: USB OTG (On The Go) Device select USB_GADGET_MUSB_HDRC - select USB_OTG select PM help The most notable feature of USB OTG is support for a -- 1.5.6.rc1 -- 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 0/3] Adding support for OMAP2EVM(Replacing 2430OSK)
On Wed, 11 Jun 2008 16:01:12 +0530, arun c [EMAIL PROTECTED] wrote: Hi all, The following set of patches adds support for Mistral's OMAP2EVM board. a) First patch replaces 2430OSK board files with omap2evm b) Second patch provides compile support c) Third patch completes the name change The problem will be with the legacy 2430osk, they still provide the old 1437 machine id, right ? If you remove all of it users won't be able to boot them until upgrading u-boot. Besides they carry a different processor (2430 on osk and 2530 on evm). Maybe we keep support for both just sharing all board files ? board-n810.c shares everything with board-n800, maybe you should do something similar? -- Best Regards, Felipe Balbi http://felipebalbi.com [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
[PATCH] i2c: twl4030: warning: mixed declarations and code
Latest patches for multi-omap support introduced
it, removing.
Trivial patch.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-usb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-usb.c b/drivers/i2c/chips/twl4030-usb.c
index 7f93b4f..f546d42 100644
--- a/drivers/i2c/chips/twl4030-usb.c
+++ b/drivers/i2c/chips/twl4030-usb.c
@@ -625,8 +625,8 @@ static int twl4030_set_suspend(struct otg_transceiver *x,
int suspend)
static int twl4030_set_peripheral(struct otg_transceiver *xceiv,
struct usb_gadget *gadget)
{
- struct twl4030_usb *twl = xceiv_to_twl(xceiv);
u32 l;
+ struct twl4030_usb *twl = xceiv_to_twl(xceiv);
if (!xceiv)
return -ENODEV;
--
1.5.6.rc1
--
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] i2c: twl4030: warning: mixed declarations and code
On Wed, Jun 11, 2008 at 09:53:45AM -0400, ext Eduardo Valentin wrote: - struct twl4030_usb *twl = xceiv_to_twl(xceiv); u32 l; + struct twl4030_usb *twl = xceiv_to_twl(xceiv); To me you are just moving the place of this declaration. Yes, because ISO C99 forbids mixed declaraction and code. build tlw4030-usb and you'll see the warning. ;-) -- - 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] Separate out 3430 LCD panel support from 2430 file
!= twl4030_i2c_write_u8(PM_RECEIVER, ENABLE_VAUX3_DEV_GRP,
+ TWL4030_VAUX3_DEV_GRP))
+ return -EIO;
+
+ return 0;
+}
+
+static void sdp3430_panel_disable(struct lcd_panel *panel)
+{
+ omap_set_gpio_dataout(enable_gpio, 0);
+ omap_set_gpio_dataout(backlight_gpio, 0);
gpiolib
+}
+
+static unsigned long sdp3430_panel_get_caps(struct lcd_panel *panel)
+{
+ return 0;
+}
+
+struct lcd_panel sdp3430_panel = {
+ .name = sdp3430,
+ .config = OMAP_LCDC_PANEL_TFT | OMAP_LCDC_INV_VSYNC |
+ OMAP_LCDC_INV_HSYNC,
+
+ .bpp= 16,
+ .data_lines = 16,
+ .x_res = 240,
+ .y_res = 320,
+ .hsw= 3,/* hsync_len (4) - 1 */
+ .hfp= 3,/* right_margin (4) - 1 */
+ .hbp= 39, /* left_margin (40) - 1 */
+ .vsw= 1,/* vsync_len (2) - 1 */
+ .vfp= 2,/* lower_margin */
+ .vbp= 7,/* upper_margin (8) - 1 */
+
+ .pixel_clock= LCD_PIXCLOCK_MAX,
+
+ .init = sdp3430_panel_init,
+ .cleanup= sdp3430_panel_cleanup,
+ .enable = sdp3430_panel_enable,
+ .disable= sdp3430_panel_disable,
+ .get_caps = sdp3430_panel_get_caps,
+};
+
+static int sdp3430_panel_probe(struct platform_device *pdev)
+{
+ omapfb_register_panel(sdp3430_panel);
+ return 0;
+}
+
+static int sdp3430_panel_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int sdp3430_panel_suspend(struct platform_device *pdev,
+ pm_message_t mesg)
+{
+ return 0;
+}
+
+static int sdp3430_panel_resume(struct platform_device *pdev)
+{
+ return 0;
+}
+
+struct platform_driver sdp3430_panel_driver = {
+ .probe = sdp3430_panel_probe,
+ .remove = sdp3430_panel_remove,
+ .suspend= sdp3430_panel_suspend,
+ .resume = sdp3430_panel_resume,
+ .driver = {
+ .name = sdp3430_lcd,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init sdp3430_panel_drv_init(void)
+{
+ return platform_driver_register(sdp3430_panel_driver);
+}
+
+static void __exit sdp3430_panel_drv_exit(void)
+{
+ platform_driver_unregister(sdp3430_panel_driver);
+}
+
+module_init(sdp3430_panel_drv_init);
+module_exit(sdp3430_panel_drv_exit);
platform devices should have MODULE_ALIAS(platform:driver_name);
in this case would be:
MODULE_ALIAS(platform:sdp3430_lcd);
--
1.5.3.2
--
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
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[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] Separate out 3430 LCD panel support from 2430 file
On Thu, 12 Jun 2008 17:24:49 +0530, Gadiyar, Anand [EMAIL PROTECTED] wrote: Separate out 3430 LCD panel support from 2430 SDP. Currently the support for the LCD on 3430SDP is added in the lcd_2430sdp.c file. This patch separates it out to a new file. You're at least missing 3430sdp defconfig updates, Kconfig changes in drivers/media/video/omap and the removal of conditional code in lcd_2430sdp.c Er... Why Kconfig in drivers/media/video/omap? brainfart :-p It uses CONFIG_MACH_OMAP_XXX :-) forget about the Kconfig :-) -- Best Regards, Felipe Balbi http://felipebalbi.com [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
[PATCH 0/4] more musb/i2c patches
Basically adding module_alias and allowing some twl drivers to be dynamically linked. There's also one patch to make hdrc_cnf.h more omap3-compliant based on the musb configuration for musb ip core on omap3. Please, comment them out. Felipe Balbi (4): usb: musb: musb on omap3 has 32 endpoints usb: musb: add MODULE_ALIAS for udev module loading i2c: allow twl modules to be built as modules i2c: add MODULE_ALIAS to twl4030 drivers drivers/i2c/chips/Kconfig |6 +++--- drivers/i2c/chips/twl4030-core.c|1 + drivers/i2c/chips/twl4030-gpio.c|1 + drivers/i2c/chips/twl4030-madc.c|1 + drivers/i2c/chips/twl4030-poweroff.c|1 + drivers/i2c/chips/twl4030-pwrbutton.c |1 + drivers/i2c/chips/twl4030-pwrirq.c |1 + drivers/i2c/chips/twl4030-usb.c |1 + drivers/input/keyboard/omap-twl4030keypad.c |1 + drivers/rtc/rtc-twl4030.c |1 + drivers/usb/musb/musb_core.c|4 +++- include/asm-arm/arch-omap/hdrc_cnf.h|6 +++--- 12 files changed, 18 insertions(+), 7 deletions(-) -- 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/4] usb: musb: musb on omap3 has 32 endpoints
Fix hdrc_cnf.h for omap3 configuration. Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- include/asm-arm/arch-omap/hdrc_cnf.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/asm-arm/arch-omap/hdrc_cnf.h b/include/asm-arm/arch-omap/hdrc_cnf.h index 74c8432..271214c 100644 --- a/include/asm-arm/arch-omap/hdrc_cnf.h +++ b/include/asm-arm/arch-omap/hdrc_cnf.h @@ -14,11 +14,11 @@ /* ** Number of Tx endpoints ** */ /* Legal values are 1 - 16 (this value includes EP0) */ -#define MUSB_C_NUM_EPT 8 +#define MUSB_C_NUM_EPT 16 /* ** Number of Rx endpoints ** */ /* Legal values are 1 - 16 (this value includes EP0) */ -#define MUSB_C_NUM_EPR 8 +#define MUSB_C_NUM_EPR 16 /* ** Endpoint 1 to 15 direction types ** */ /* C_EP1_DEF is defined if either Tx endpoint 1 or Rx endpoint 1 are used */ @@ -163,7 +163,7 @@ * Legal values are 2 - 16 * This must be equal to the larger of C_NUM_EPT, C_NUM_EPR */ -#define MUSB_C_NUM_EPS 8 +#define MUSB_C_NUM_EPS 16 /* C_EPMAX_BITS is equal to the largest endpoint FIFO word address bits */ #define MUSB_C_EPMAX_BITS 12 -- 1.5.6.rc1 -- 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/4] i2c: allow twl modules to be built as modules
Besides twl core and twl gpio, all the others can be dynamically linked. Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- drivers/i2c/chips/Kconfig |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig index cba8abf..b421727 100644 --- a/drivers/i2c/chips/Kconfig +++ b/drivers/i2c/chips/Kconfig @@ -150,7 +150,7 @@ config TWL4030_MADC called twl4030-madc.ko config TWL4030_USB - bool TWL4030 USB Transceiver Driver + tristate TWL4030 USB Transceiver Driver depends on TWL4030_CORE choice @@ -170,11 +170,11 @@ config TWL4030_USB_HS_ULPI endchoice config TWL4030_PWRBUTTON - bool TWL4030 Power button Driver + tristate TWL4030 Power button Driver depends on TWL4030_CORE config TWL4030_POWEROFF - bool TWL4030 device poweroff + tristate TWL4030 device poweroff depends on TWL4030_CORE config SENSORS_MAX6875 -- 1.5.6.rc1 -- 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/4] usb: musb: add MODULE_ALIAS for udev module loading
platform drivers should add MODULE_ALIAS for allowing udev module loading. Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- drivers/usb/musb/musb_core.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 5b92f21..75c3013 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -134,11 +134,13 @@ MODULE_PARM_DESC(debug, initial debug message level); #define DRIVER_INFO DRIVER_DESC , v MUSB_VERSION -const char musb_driver_name[] = musb_hdrc; +#define MUSB_DRIVER_NAME musb_hdrc +const char musb_driver_name[] = MUSB_DRIVER_NAME; MODULE_DESCRIPTION(DRIVER_INFO); MODULE_AUTHOR(DRIVER_AUTHOR); MODULE_LICENSE(GPL); +MODULE_ALIAS(platform: MUSB_DRIVER_NAME); /*-*/ -- 1.5.6.rc1 -- 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 4/4] i2c: add MODULE_ALIAS to twl4030 drivers
When built as module, it helps udev to probe them. Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- drivers/i2c/chips/twl4030-core.c|1 + drivers/i2c/chips/twl4030-gpio.c|1 + drivers/i2c/chips/twl4030-madc.c|1 + drivers/i2c/chips/twl4030-poweroff.c|1 + drivers/i2c/chips/twl4030-pwrbutton.c |1 + drivers/i2c/chips/twl4030-pwrirq.c |1 + drivers/i2c/chips/twl4030-usb.c |1 + drivers/input/keyboard/omap-twl4030keypad.c |1 + drivers/rtc/rtc-twl4030.c |1 + 9 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/chips/twl4030-core.c b/drivers/i2c/chips/twl4030-core.c index 8822653..adc45d4 100644 --- a/drivers/i2c/chips/twl4030-core.c +++ b/drivers/i2c/chips/twl4030-core.c @@ -908,6 +908,7 @@ static void __exit twl4030_exit(void) subsys_initcall(twl4030_init); module_exit(twl4030_exit); +MODULE_ALIAS(i2c: DRIVER_NAME); MODULE_AUTHOR(Texas Instruments, Inc.); MODULE_DESCRIPTION(I2C Core interface for TWL4030); MODULE_LICENSE(GPL); diff --git a/drivers/i2c/chips/twl4030-gpio.c b/drivers/i2c/chips/twl4030-gpio.c index a448943..f16a48b 100644 --- a/drivers/i2c/chips/twl4030-gpio.c +++ b/drivers/i2c/chips/twl4030-gpio.c @@ -827,6 +827,7 @@ static void __exit gpio_twl4030_exit(void) module_init(gpio_twl4030_init); module_exit(gpio_twl4030_exit); +MODULE_ALIAS(i2c:twl4030-gpio); MODULE_AUTHOR(Texas Instruments, Inc.); MODULE_DESCRIPTION(GPIO interface for TWL4030); MODULE_LICENSE(GPL); diff --git a/drivers/i2c/chips/twl4030-madc.c b/drivers/i2c/chips/twl4030-madc.c index f53a3db..72b126b 100644 --- a/drivers/i2c/chips/twl4030-madc.c +++ b/drivers/i2c/chips/twl4030-madc.c @@ -448,6 +448,7 @@ static void __exit twl4030_madc_exit(void) module_init(twl4030_madc_init); module_exit(twl4030_madc_exit); +MODULE_ALIAS(i2c:twl4030-adc); MODULE_AUTHOR(Nokia Corporation); MODULE_DESCRIPTION(twl4030 ADC driver); MODULE_LICENSE(GPL); diff --git a/drivers/i2c/chips/twl4030-poweroff.c b/drivers/i2c/chips/twl4030-poweroff.c index 57c7fc7..0ebab0b 100644 --- a/drivers/i2c/chips/twl4030-poweroff.c +++ b/drivers/i2c/chips/twl4030-poweroff.c @@ -70,6 +70,7 @@ static void __exit twl4030_poweroff_exit(void) module_init(twl4030_poweroff_init); module_exit(twl4030_poweroff_exit); +MODULE_ALIAS(i2c:twl4030-poweroff); MODULE_DESCRIPTION(Triton2 device power off); MODULE_LICENSE(GPL); MODULE_AUTHOR(Peter De Schrijver); diff --git a/drivers/i2c/chips/twl4030-pwrbutton.c b/drivers/i2c/chips/twl4030-pwrbutton.c index cbc31aa..09adc67 100644 --- a/drivers/i2c/chips/twl4030-pwrbutton.c +++ b/drivers/i2c/chips/twl4030-pwrbutton.c @@ -154,6 +154,7 @@ static void __exit twl4030_pwrbutton_exit(void) 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); diff --git a/drivers/i2c/chips/twl4030-pwrirq.c b/drivers/i2c/chips/twl4030-pwrirq.c index 8f1fec6..a4d2e92 100644 --- a/drivers/i2c/chips/twl4030-pwrirq.c +++ b/drivers/i2c/chips/twl4030-pwrirq.c @@ -222,5 +222,6 @@ static void __exit twl4030_pwrirq_exit(void) } } +MODULE_ALIAS(i2c:twl4030-pwrirq); subsys_initcall(twl4030_pwrirq_init); module_exit(twl4030_pwrirq_exit); diff --git a/drivers/i2c/chips/twl4030-usb.c b/drivers/i2c/chips/twl4030-usb.c index f546d42..ab335ca 100644 --- a/drivers/i2c/chips/twl4030-usb.c +++ b/drivers/i2c/chips/twl4030-usb.c @@ -770,6 +770,7 @@ static void __exit twl4030_usb_exit(void) subsys_initcall(twl4030_usb_init); module_exit(twl4030_usb_exit); +MODULE_ALIAS(i2c:twl4030-usb); MODULE_AUTHOR(Texas Instruments, Inc.); MODULE_DESCRIPTION(TWL4030 USB transceiver driver); MODULE_LICENSE(GPL); diff --git a/drivers/input/keyboard/omap-twl4030keypad.c b/drivers/input/keyboard/omap-twl4030keypad.c index 0344b4c..94ab43b 100644 --- a/drivers/input/keyboard/omap-twl4030keypad.c +++ b/drivers/input/keyboard/omap-twl4030keypad.c @@ -368,6 +368,7 @@ static void __exit omap_kp_exit(void) module_init(omap_kp_init); module_exit(omap_kp_exit); +MODULE_ALIAS(platform:omap_twl4030keypad); MODULE_AUTHOR(Texas Instruments); MODULE_DESCRIPTION(OMAP TWL4030 Keypad Driver); MODULE_LICENSE(GPL); diff --git a/drivers/rtc/rtc-twl4030.c b/drivers/rtc/rtc-twl4030.c index ef0e175..e9386ba 100644 --- a/drivers/rtc/rtc-twl4030.c +++ b/drivers/rtc/rtc-twl4030.c @@ -647,6 +647,7 @@ static void __exit twl4030_rtc_exit(void) platform_driver_unregister(twl4030rtc_driver); } +MODULE_ALIAS(platform:twl4030_rtc); MODULE_AUTHOR(Texas Instruments, MontaVista Software); MODULE_LICENSE(GPL);; -- 1.5.6.rc1 -- 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 7/8] 34XX: PM: Workaround to disable mmc
On Tue, 17 Jun 2008 10:31:11 +0300, Jouni Hogander [EMAIL PROTECTED] wrote: Current hsmmc is not pm friendly. Disable it because it prevents omap3 retention Disabling will just hide the bug. Better making it modular and let mmc guys dig on it. What do you need to make it more pm friendly? -- Best Regards, Felipe Balbi http://felipebalbi.com [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/RFC 1/2] Add Dspbridge driver to OMAP GIT kernel
On Wed, 18 Jun 2008 12:52:53 +0300, Tony Lindgren [EMAIL PROTECTED] wrote: In addition, read the following: Documentation/CodingStyle Documentation/SubmittingDrivers Documentation/SubmittingPatches Documentation/SubmitChecklist And then make sure scripts/checkpatch.pl will not produce errors or obvious warnings. Otherwise this code will just get ignored by people who should review the patches. sparse would also be quite nice :-) -- Best Regards, Felipe Balbi http://felipebalbi.com [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: FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
On Thu, 19 Jun 2008 07:54:19 -0500, Woodruff, Richard
[EMAIL PROTECTED] wrote:
Hi,
I'll resend this to the omap list. I had originally sent it with some
pictures but I guess they were too big for the lists. Individual should
have got them.
If anyone has the time this is a good to test with. If you have dynamic
tick enabled it can double performance of high rate interrupt things like
MUSB.
If anyone wants I'll re-send larger trace pictures individually.
care to send it to my nokia mail?
felipe 'dot' balbi 'at' nokia 'dot' com
I'll take a shot at this patch after summer holidays.
ps: I'm keeping the rest of the mail below so it' ll be
easier for getting the patch at work :-p
From: Woodruff, Richard, Monday, June 16, 2008 7:06 PM
It simply does a check to see if the about to be reprogrammed 1 shot
already is the last event programmed in the hardware. If it is it skips
calling the hardware.
In my device I get many interrupts from a high speed USB device in a
very short period of time. The system spends a lot of time
reprogramming the hardware timer which is in a slower timing domain as
compared to the CPU. This results in the CPU spending a huge amount of
time waiting for the timer posting to be done. All of this
reprogramming is useless as the wake up time has not changed.
As measured using ETM trace this drops my reprogramming penalty from
almost 60% CPU load down to 15% during high interrupt rate. If you like
I can send traces to show this.
Attached are some results on OMAP-ARM from USB-OTG:
As host:
[EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
[EMAIL PROTECTED] /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
real 32.51
user 0.02
sys 1.05
[EMAIL PROTECTED] /]# umount /mnt/
[EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
[EMAIL PROTECTED] /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
real 17.92
user 0.05
sys 1.57
As Client:
Attached are some visuals as of client doing gadget zero tests. Pictures
clearly show before a domination by timer reprogram and after not.
Regards,
Richard W.
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index b854a89..ff6b967 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -254,6 +254,17 @@ void tick_nohz_stop_sched_tick(void)
/* Schedule the tick, if we are at least one jiffie off */
if ((long)delta_jiffies = 1) {
+ /*
+ * calculate the expiry time for the next timer wheel
+ * timer
+ */
+ expires = ktime_add_ns(last_update, tick_period.tv64 *
+ delta_jiffies);
+
+ /* Skip reprogram of event if its not changed */
+ if(ts-tick_stopped ktime_equal(expires,
dev-next_event))
+ goto out2;
+
if (delta_jiffies 1)
cpu_set(cpu, nohz_cpu_mask);
/*
@@ -304,12 +315,7 @@ void tick_nohz_stop_sched_tick(void)
goto out;
}
- /*
-* calculate the expiry time for the next timer wheel
-* timer
-*/
- expires = ktime_add_ns(last_update, tick_period.tv64 *
- delta_jiffies);
+ /* Mark expiries */
ts-idle_expires = expires;
if (ts-nohz_mode == NOHZ_MODE_HIGHRES) {
@@ -328,6 +334,7 @@ void tick_nohz_stop_sched_tick(void)
tick_do_update_jiffies64(ktime_get());
cpu_clear(cpu, nohz_cpu_mask);
}
+out2:
raise_softirq_irqoff(TIMER_SOFTIRQ);
out:
ts-next_jiffies = next_jiffies;
--
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
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[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: FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
On Thu, 19 Jun 2008 17:06:11 -0500, Woodruff, Richard [EMAIL PROTECTED] wrote: care to send it to my nokia mail? felipe 'dot' balbi 'at' nokia 'dot' com Ok. Thanks for sending them :-) Ok. I did catch Thomas G. on IRC and he indicated it seemed fine and would try later after fixing some bugs. That's great :-) Perhaps more exciting would be to make sure x86 didn't care. My ARM targets only work better. better sending to lkml, then? I'm pretty sure at least ehci will be positively affected. We could be getting around 400mbps throughput with ehci (and musb) but last time I tried I got something around 150mbps. That was a good catch Richard :-) -- Best Regards, Felipe Balbi http://felipebalbi.com [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: [RFC/PATCH 1/2] Triton Battery charger interface driver for OMAP3430
);
+
+ return ret;
+}
+
+static int twl4030_bci_battery_remove(struct platform_device *dev)
+{
+ struct twl4030_bci_device_info *di = platform_get_drvdata(dev);
+
+ twl4030charger_ac_en(DISABLE);
+ twl4030charger_usb_en(DISABLE);
+ twl4030battery_hw_level_en(DISABLE);
+ twl4030battery_hw_presence_en(DISABLE);
+
+ free_irq(TWL4030_MODIRQ_BCI, NULL);
+ free_irq(TWL4030_MODIRQ_PWR, di);
+
+ flush_scheduled_work();
+ power_supply_unregister(di-bat);
+ power_supply_unregister(di-bk_bat);
+ platform_set_drvdata(dev, NULL);
+ kfree(di);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int twl4030_bci_battery_suspend(struct platform_device *dev,
+ pm_message_t state)
+{
+ struct twl4030_bci_device_info *di = platform_get_drvdata(dev);
+
+ di-charge_status = POWER_SUPPLY_STATUS_UNKNOWN;
+ cancel_delayed_work(di-twl4030_bci_monitor_work);
+ cancel_delayed_work(di-twl4030_bk_bci_monitor_work);
+ return 0;
+}
+
+static int twl4030_bci_battery_resume(struct platform_device *dev)
+{
+ struct twl4030_bci_device_info *di = platform_get_drvdata(dev);
+
+ schedule_delayed_work(di-twl4030_bci_monitor_work, 0);
+ schedule_delayed_work(di-twl4030_bk_bci_monitor_work, 50);
+ return 0;
+}
+#endif /* CONFIG_PM */
+
+/*
+ * Battery driver module initializer function
+ * registers battery driver structure
+ */
+static int __init twl4030_battery_init(void)
+{
+ return platform_driver_register(twl4030_bci_battery_driver);
+
+}
+
+/*
+ * Battery driver module exit function
+ * unregister battery driver structure
+ */
+static void __exit twl4030_battery_exit(void)
+{
+ platform_driver_unregister(twl4030_bci_battery_driver);
+}
+
+module_init(twl4030_battery_init);
+module_exit(twl4030_battery_exit);
+MODULE_LICENSE(GPL);
missing MODULE_AUTHOR()
and MODULE_ALIAS(platform:twl4030-bci-battery);
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[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: [RFC/PATCH 2/2] Triton Battery charger interface driver for OMAP3430
On Fri, 20 Jun 2008 17:36:00 +0530 (IST), [EMAIL PROTECTED]
wrote:
+#ifdef CONFIG_TWL4030_BCI_BATTERY
+extern int twl4030charger_usb_en(int enable);
+#else
+static inline int twl4030charger_usb_en(int enable) { return 0; }
+#endif
this should be in include/linux/i2c/twl4030.h
you should also change it for when bci is built as a
dynamically linked module.
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[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 1/4] usb: musb: musb on omap3 has 32 endpoints
On Mon, Jun 23, 2008 at 02:10:09PM +0300, Tony Lindgren wrote: * Felipe Balbi [EMAIL PROTECTED] [080613 13:05]: Fix hdrc_cnf.h for omap3 configuration. Does this break the configuration for omap2? We should set these dynamically if different for omap2 and omap3 so we can compile both into the same kernel. Should check omap2430 trm to be sure, maybe someone in TI could help us with it ? Maybe we could bring it via platform_data as well? -- - 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: [RFC/PATCH 1/2] Triton Battery charger interface driver for OMAP3430
Hi,
On Mon, 23 Jun 2008 19:04:51 +0530, Madhusudhan Chikkature
[EMAIL PROTECTED] wrote:
On Fri, 20 Jun 2008 17:33:41 +0530 (IST), [EMAIL PROTECTED]
wrote:
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2008-06-20
15:39:56.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2008-06-20
15:42:05.0
+0530
@@ -358,6 +358,22 @@
static inline void omap_hdq_init(void) {}
#endif
+#ifdef CONFIG_TWL4030_BCI_BATTERY
+static struct platform_device omap_bci_battery_device = {
+ .name = twl4030-bci-battery,
+ .id = 1,
+ .num_resources = 0,
+ .resource = NULL,
if you pass the struct resources you can use __raw_{read,write} which
would simplify a lot for you, but if you really don't want it, you
don't have to initialize it to NULL. Just because it's static, it's
enough for it to get NULLed.
The battery driver uses twl4030_i2c_read_u8 and twl4030_i2c_write_u8 as
low level interface(I2C) with
standard twl4030.h defines. So no point of _raw(read,write) and BASE
address getting initialized through resource structure. Right?.
I agree with your second point of no need to explicitely setting it to
NULL though.
The idea was to actually get rid of the i2c transfers and use
__raw_read/write
instead, but I suppose it's ok to use i2c transfers
+};
+
+static inline void omap_bci_battery_init(void)
+{
+ (void) platform_device_register(omap_bci_battery_device);
+}
+#else
+static inline void omap_bci_battery_init(void) {}
+#endif
+
don't remember if I said on last mail, but this ifdef should be in
a header file. Maybe include/linux/i2c/twl4030.h
How about creating a special battery.c for this just like usb-musb.c,
usb-ehci.c
and hsmmc.c, so it's easier to reuse it and add such support only for
boards that
has twl4030.
It would be useful for omap multiboot, I suppose.
I had put these under devices.c as there is not much board level
configurations for BCI unlike hsmmc.
I guess I can add a simple board file for battery that way it can used
based on TWL4030 if it is a good idea.
I would like to hear from Tony and the others what do they think?
would it be worthy adding an extra file for bci ??
Tony, comments?
INIT_DELAYED_WORK_DEFERRABLE()???
Do you mean INIT_DELAYED_WORK_DEFERRABLE() is a better choice here??
Yes, as it could be deferred on suspend/resume. I think INIT_DELAYED_WORK
also blocks dynamic pm ?!?
Maybe Jouni could clarify this one better. Jouni, any comments?
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[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 1/3] OMAP3 EVM: Add twl4030 keypad driver support
On Mon, Jun 23, 2008 at 03:51:09PM -0600, Miguel Angel Aguilar Ulloa wrote: Add twl4030 keypad driver support to OMAP3 EVM Generally all your patches look really good but the subject should be something more self-explanatory. For this first is ok, but second and third should be something like: OMAP3: EVM: KEYPAD: Fix Kconfig dependency OMAP3: EVM: KEYPAD: Add twl4030 keypad to defconfig or something similar ;-) -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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] OMAP3 EVM: Add twl4030 keypad driver support
On Mon, Jun 23, 2008 at 03:51:20PM -0600, Miguel Angel Aguilar Ulloa wrote: Enable twl4030 keypad driver in omap3_evm_defconfig Signed-off-by: Miguel Angel Aguilar [EMAIL PROTECTED] --- a/arch/arm/configs/omap3_evm_defconfig2008-06-11 08:32:45.0 -0600 +++ b/arch/arm/configs/omap3_evm_defconfig2008-06-23 14:35:23.0 -0600 @@ -601,7 +601,16 @@ CONFIG_INPUT=y # # Input Device Drivers # -# CONFIG_INPUT_KEYBOARD is not set +CONFIG_INPUT_KEYBOARD=y +# CONFIG_KEYBOARD_ATKBD is not set +# CONFIG_KEYBOARD_SUNKBD is not set +# CONFIG_KEYBOARD_LKKBD is not set +# CONFIG_KEYBOARD_XTKBD is not set +# CONFIG_KEYBOARD_NEWTON is not set +# CONFIG_KEYBOARD_STOWAWAY is not set +CONFIG_KEYBOARD_TWL4030=y make them modules. If something happens we can rmmod/insmod. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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/4] usb: musb: musb on omap3 has 32 endpoints
On Tue, Jun 24, 2008 at 09:52:05AM +0530, Gadiyar, Anand wrote: Fix hdrc_cnf.h for omap3 configuration. Does this break the configuration for omap2? We should set these dynamically if different for omap2 and omap3 so we can compile both into the same kernel. Should check omap2430 trm to be sure, maybe someone in TI could help us with it ? It won't break the 2430. The 2430 has 32 endpoints as well. Good. Maybe we could bring it via platform_data as well? Yep. That would be good. Cool, I'll start doing it. Tony, maybe is safe to push this one so we can use all 32 endpoints ? Meanwhile I'll create a way for different boards to tell musb driver its configuration details. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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] OMAP2EVM: add ethernet support (smc911x)
On Tue, 24 Jun 2008 18:24:11 +0530, Arun KS [EMAIL PROTECTED] wrote: it looks like drivers/net/smc911x doesn't use IORESOURCE_IRQ, am I misreading it ? Yes this driver uses platform_get_irq(pdev, 0) to get its irq number. Cool, thanks :-) -- Best Regards, Felipe Balbi http://felipebalbi.com [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: [Resend] [PATCH 1/3] OMAP2EVM: add ethernet support (smc911x)
Your patch came with spaces in place of tabs, please tabify and resend -- Best Regards, Felipe Balbi http://felipebalbi.com [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 1/7] 34XX: PM: Workaround to build omap hsmmc as a module
On Wed, 25 Jun 2008 12:13:40 +0300, Jouni Hogander [EMAIL PROTECTED] wrote: Current omap hsmmc driver is not pm friendly. Build it as a module because it prevents omap3 retention. Small comment. At least this patch shouldn't be reverted, there's no reason for not building drivers as modules. I'll do the same to musb. -- Best Regards, Felipe Balbi http://felipebalbi.com [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 1/7] 34XX: PM: Workaround to build omap hsmmc as a module
Hi, On Wed, 25 Jun 2008 16:47:30 +0530, Gadiyar, Anand [EMAIL PROTECTED] wrote: Actually there is. It really depends on what you want to do with the system. For instance, the case where you are running a tight embedded system with a ramdisk filesystem - the modules would have to sit on the filesystem and would occupy precious space there. You might be better off having everything built into the kernel. That being said, in my opinion it should be possible to have everything as modules with little difference in functionality. In this case if the OMAP HSMMC driver is not PM-friendly, then that should be fixed. Making it build as a module is at best a __temporary__ solution as Jouni points out. The choice of building drivers into the kernel or as modules should be left to whoever builds the kernel. The defconfigs make life easy during testing but otherwise there is little reason to change them. That's true but 3430sdp is far from a tight embedded system. It's a full fledged omap3430-based board with plenty of memory space for everything we need. On the other hand, building as module allow us to just unload the module if it's causing problems like preventing retetion. Besides, at least in case on the SDPs, most of the people will use nfs anyways, which makes a lot easier to upload the new modules to the board allowing us to test new features in a module without even rebooting the board, just by rmmod/insmod. Again, I agree with that with a tight embedded system, it's better to have everything into the kernel, but then again, we have to believe that every single piece of sw is working exactly the way it should, which is not always true during the development process of our drivers. At least hsmmc and musb drivers still have some stuff to be taken care of. Having them as modules, would allow faster development cycle with less reboots on the target board. And like you said, if the defconfig is all modular (or all built-in) the user/manufacturer/hacker can always change it later. Although I defend that Reference Boards' defconfigs should be as modular as possible. My 2 cents ;-) -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [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 1/7] 34XX: PM: Workaround to build omap hsmmc as a module
Hi, On Thu, 26 Jun 2008 09:55:43 +0530, Gadiyar, Anand [EMAIL PROTECTED] wrote: That wasn't what I said or meant. What I did want to bring out was that having something built-in might give it more exposure to test by someone who wasn't actively working on that area. And most bugs are caught by people other than the active developers. Not really, another usecase for modular kernel is that we don't wanna add e.g. tea (radio) driver for n810 cuz it doesn't have that chip. With modular kernel with proper MODULE_ALIAS() and udev, you just flash the same kernel and modules in both n800 and n810 and tea driver would only be probed in n800. I think this is what Igor meant when we said about validation across boards. At first glance to your email, I thought you had a valid point here. Thinking a little more, I think your point is valid only if you had a module that should not be loaded on a particular board. In such a case, you would anyway want to fix that module. Or you rely on udev rules and keep the main kernel code smaller. Yes, having a modular kernel is useful. And it is probably the way to go. But please don't tell me that you can't do the same things with almost everything built-in. some stuff you really can't. If your mmc driver get stuck somewhere, you can't modprobe -r -f omap_hsmmc and restart your work with a built-in mmc driver. With modular kernel, we really can do it: forcefully remove the driver and reset the controller, this would give us oportunity to analyze logs and try again by reloading the module. With a built-in kernel, the only way out is reboot. The 2430 defconfig has almost everything modular, while the 3430 defconfig doesn't. I propose we start a separate defconfig for the modular case or use allmodconfig. Maybe even have this as the defconfig for the multi-omap kernel. If we keep the individual defconfigs as a nearly all-built-in case, we can still get the best of both worlds. The thins is that normaly you'd have udev running anyways, and it would automatically load modules based on /sys and correct MODULE_ALIAS() and that's already another thing to test that can't be tested with built-in modules. We know that several omap drivers are missing MODULE_ALIAS() and recently I've added it to all twl4030 drivers for that purpose. We can now rely that udev will correctly load the necessary module when we need it. And when I stated that there's no reason for not building everything as dynamic module for omaps, I was considering that we have enough memory in our boards and generaly developers will use NFS root file system anyways. I think this discussion is now way too long for something really simple: For development purposes on SDPs, dynamic linked modules can increase the development cycle by decreasing the amount of build/flash/reboot cycles. -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [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
do not block sleep patch
hi all,
Resending the patch as it didn't get applied.
Searching on the archives would be painful :-p
--
- Balbi
From d8f7f708e32ad7daadf9e48e7ba0ebecdf91094c Mon Sep 17 00:00:00 2001
From: Felipe Balbi [EMAIL PROTECTED]
Date: Thu, 26 Jun 2008 16:31:44 +0300
Subject: [PATCH] ARCH: OMAP: MUSB: Do not block sleep
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Do not block sleep while musb clock is enabled
as it completely blocks dynamic sleep.
Thanks to Jouni Högander.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
Signed-off-by: Jouni Högander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/usb-musb.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index cbd59f8..d495549 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -58,14 +58,12 @@ static int musb_set_clock(struct clk *clk, int state)
if (clk_on 0)
return -ENODEV;
- omap2_block_sleep();
clk_enable(clk);
clk_on = 1;
} else {
if (clk_on == 0)
return -ENODEV;
- clk_disable(clk);
clk_on = 0;
omap2_allow_sleep();
}
--
1.5.6.49.g112db
Re: do not block sleep patch
On Thu, Jun 26, 2008 at 04:38:38PM +0300, Tony Lindgren wrote:
Did you mean to remove omap2_allow_sleep() instead of clk_disable()?
Crap... yeah.. sorry, attached is new patch.
--
- Balbi
From d096d1c215e4c519d77ba27035ea4c57fb793362 Mon Sep 17 00:00:00 2001
From: Felipe Balbi [EMAIL PROTECTED]
Date: Thu, 26 Jun 2008 16:31:44 +0300
Subject: [PATCH] ARCH: OMAP: MUSB: Do not block sleep
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Do not block sleep while musb clock is enabled
as it completely blocks dynamic sleep.
Thanks to Jouni Högander.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
Signed-off-by: Jouni Högander [EMAIL PROTECTED]
---
arch/arm/mach-omap2/usb-musb.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index cbd59f8..bd3556b 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -58,7 +58,6 @@ static int musb_set_clock(struct clk *clk, int state)
if (clk_on 0)
return -ENODEV;
- omap2_block_sleep();
clk_enable(clk);
clk_on = 1;
} else {
@@ -67,7 +66,6 @@ static int musb_set_clock(struct clk *clk, int state)
clk_disable(clk);
clk_on = 0;
- omap2_allow_sleep();
}
return 0;
--
1.5.6.49.g112db
Re: N810 power problems, bootloader upgrade, won't boot
On Thu, 26 Jun 2008 18:13:59 -0500, green [EMAIL PROTECTED] wrote: I've been having power problems with my N810. These problems appear on startup (see three links below) and are supposedly fix by a bootloader upgrade, so I upgraded using the Maemo Diablo Fiasco image RX-44_DIABLO_4.2008.23-14_PR_COMBINED_MR0_ARM.bin. Perhaps this has fixed the problem, but it has caused another: now the N810 won't boot with the kernels I build, nor will it boot with the zImage-n8x0-2008-05-15 test kernel that Tony Lindgren provided recently. By not booting I mean that I see the NOKIA splash screen only; nothing else happens. Any ideas what I need to do? I'd rather not downgrade because of problems I've had with the device suddenly powering off when idle [3]. Diablo releases are using the oficial Machine ID for n810 hw, so the hack in mach-types is not needed anymore. -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [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
[RFC][PATCH] usb: musb: pass configuration specifics via pdata
Use platform_data to pass musb configuration-specific
details to musb driver.
It's easier to maintain in the sense that neither board
will affect the other.
For now tested on n800 only, wanna hear from everybody what
guys think before test on omap3430sdp
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
Cc: Tony Lindgre [EMAIL PROTECTED]
Cc: David Brownell [EMAIL PROTECTED]
Cc: Anand Gadiyar [EMAIL PROTECTED]
Cc: Kevin Hilman [EMAIL PROTECTED]
Cc: Bryan Wu [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-3430sdp.c | 75 ++-
arch/arm/mach-omap2/board-n800-usb.c | 46 +-
arch/arm/mach-omap2/usb-musb.c | 55 +++
arch/arm/mach-omap2/usb-tusb6010.c |1 -
drivers/usb/musb/musb_core.c | 37 +++
drivers/usb/musb/musb_core.h | 14 +---
drivers/usb/musb/tusb6010.h | 169
include/asm-arm/arch-omap/hdrc_cnf.h | 177 --
include/asm-arm/arch-omap/usb-musb.h |6 +-
include/linux/usb/musb.h | 38 +++-
10 files changed, 189 insertions(+), 429 deletions(-)
delete mode 100644 include/asm-arm/arch-omap/hdrc_cnf.h
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index f6cd08b..e3db60e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -285,6 +285,79 @@ static int __init omap3430_i2c_init(void)
extern void __init sdp3430_flash_init(void);
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { ep1_tx, 10, },
+ { ep1_rx, 10, },
+ { ep2_tx, 9,},
+ { ep2_rx, 9,},
+ { ep3_tx, 3,},
+ { ep3_rx, 3,},
+ { ep4_tx, 3,},
+ { ep4_rx, 3,},
+ { ep5_tx, 3,},
+ { ep5_rx, 3,},
+ { ep6_tx, 3,},
+ { ep6_rx, 3,},
+ { ep7_tx, 3,},
+ { ep7_rx, 3,},
+ { ep8_tx, 2,},
+ { ep8_rx, 2,},
+ { ep9_tx, 2,},
+ { ep9_rx, 2,},
+ { ep10_tx, 2, },
+ { ep10_rx, 2, },
+ { ep11_tx, 2, },
+ { ep11_rx, 2, },
+ { ep12_tx, 2, },
+ { ep12_rx, 2, },
+ { ep13_tx, 2, },
+ { ep13_rx, 2, },
+ { ep14_tx, 2, },
+ { ep14_rx, 2, },
+ { ep15_tx, 2, },
+ { ep15_rx, 2, },
+};
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .soft_con = 1,
+ .dma= 1,
+ .num_eps= 32,
+ .dma_channels = 7,
+ .dma_req_chan = (1 0) | (1 1) | (1 2) | (1 3),
+ .ram_bits = 12,
+ .eps_bits = musb_eps,
+};
+
+static struct musb_hdrc_platform_data musb_plat = {
+#ifdef CONFIG_USB_MUSB_OTG
+ .mode = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_HDRC_HCD)
+ .mode = MUSB_HOST,
+#elif defined(CONFIG_USB_GADGET_MUSB_HDRC)
+ .mode = MUSB_PERIPHERAL,
+#endif
+ .clock = hsotgusb_ick,
+ .config = musb_config,
+};
+
+static struct resource musb_resources[] = {
+ [0] = {
+ .start = OMAP34XX_HSUSB_OTG_BASE,
+ .end= OMAP34XX_HSUSB_OTG_BASE + SZ_8K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = { /* general IRQ */
+ .start = INT_243X_HS_USB_MC,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = { /* DMA IRQ */
+ .start = INT_243X_HS_USB_DMA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
static void __init omap_3430sdp_init(void)
{
platform_add_devices(sdp3430_devices, ARRAY_SIZE(sdp3430_devices));
@@ -300,7 +373,7 @@ static void __init omap_3430sdp_init(void)
ads7846_dev_init();
sdp3430_flash_init();
omap_serial_init();
- usb_musb_init();
+ usb_musb_init(musb_plat, musb_resources, ARRAY_SIZE(musb_resources));
usb_ehci_init();
hsmmc_init();
}
diff --git a/arch/arm/mach-omap2/board-n800-usb.c
b/arch/arm/mach-omap2/board-n800-usb.c
index 7599f64..16ea8fc 100644
--- a/arch/arm/mach-omap2/board-n800-usb.c
+++ b/arch/arm/mach-omap2/board-n800-usb.c
@@ -35,14 +35,58 @@ static int tusb_set_clock(struct clk *osc_ck, int state);
# define BOARD_MODE MUSB_HOST
#endif
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { ep1_tx, 5,},
+ { ep1_rx, 5,},
+ { ep2_tx, 5,},
+ { ep2_rx, 5,},
+ { ep3_tx, 3,},
+ { ep3_rx, 3,},
+ { ep4_tx, 3,},
+ { ep4_rx, 3,},
+ { ep5_tx, 2,},
+ { ep5_rx, 2,},
+ { ep6_tx, 2,},
+ { ep6_rx, 2,},
+ { ep7_tx, 2
[PATCH] omap: hsmmc: Avoid NULL pointer dereference
Try if pdata provides a cleanup function pointers. For
boards which don't provide it, driver will oops in
omap_remove.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
drivers/mmc/host/omap_hsmmc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 467f146..4dfa8dd 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -887,7 +887,8 @@ static int omap_mmc_remove(struct platform_device *pdev)
platform_set_drvdata(pdev, NULL);
if (host) {
- host-pdata-cleanup(pdev-dev);
+ if (host-pdata-cleanup)
+ host-pdata-cleanup(pdev-dev);
free_irq(host-irq, host);
if (mmc_slot(host).card_detect_irq)
free_irq(mmc_slot(host).card_detect_irq, host);
--
1.5.6.49.g112db
--
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] usb: musb: pass configuration specifics via pdata
On Mon, Jun 30, 2008 at 07:56:36PM +0200, Koen Kooi wrote: I was wondering what would happen if I would test the patch on beagleboard, now I know :) The patch won't probe. But if you just copy what's added in board-omap3430sdp.c should work. afaict, they have the same configuration for musb. I'll try to finish tomorrow the other boards. -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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] usb: musb: pass configuration specifics via pdata
On Mon, Jun 30, 2008 at 11:33:15AM -0700, David Brownell wrote: On Monday 30 June 2008, Felipe Balbi wrote: The patch won't probe. But if you just copy what's added in board-omap3430sdp.c should work. Better: that controller data should be provided by SOC glue in those cases (omap2430, omap 3*, DaVinci, etc). If it's not board-specific, it doesn't belong in board-specific glue.. Hmm... will do, thanks -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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/1] musb configs
The following patch gets rid os hdrc_cnf.h and make musb configuration details more dynamic by introducing proper fields in the platform_data. I tested the patch with n810 and omap3 beagle, but please everyone interested, give it a good review and try it out. Felipe Balbi (1): usb: musb: pass configuration specifics via pdata arch/arm/mach-omap2/board-n800-usb.c | 46 +- arch/arm/mach-omap2/usb-musb.c | 51 +- arch/arm/mach-omap2/usb-tusb6010.c |1 - drivers/usb/musb/musb_core.c | 37 +++ drivers/usb/musb/musb_core.h | 14 +--- drivers/usb/musb/tusb6010.h | 169 include/asm-arm/arch-omap/hdrc_cnf.h | 177 -- include/asm-arm/arch-omap/usb-musb.h |3 + include/linux/usb/musb.h | 38 +++- 9 files changed, 147 insertions(+), 389 deletions(-) delete mode 100644 include/asm-arm/arch-omap/hdrc_cnf.h -- 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/1] usb: musb: pass configuration specifics via pdata
On Tue, Jul 01, 2008 at 03:56:51PM +0300, Felipe Balbi wrote: diff --git a/include/asm-arm/arch-omap/usb-musb.h b/include/asm-arm/arch-omap/usb-musb.h index 4f0c830..bd507e7 100644 --- a/include/asm-arm/arch-omap/usb-musb.h +++ b/include/asm-arm/arch-omap/usb-musb.h @@ -29,6 +29,9 @@ #ifndef __ASM_ARCH_OMAP_USB_MUSB_H #define __ASM_ARCH_OMAP_USB_MUSB_H +#include linux/usb/musb.h +#include linux/ioport.h + extern void usb_musb_init(void); #endif /* __ASM_ARCH_OMAP_USB_MUSB_H */ this is garbage change... I'll remove and resend. -- - 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 1/1] usb: musb: pass configuration specifics via pdata
Use platform_data to pass musb configuration-specific
details to musb driver.
It's easier to maintain in the sense that neither board
will affect the other.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
Cc: Tony Lindgre [EMAIL PROTECTED]
Cc: David Brownell [EMAIL PROTECTED]
Cc: Anand Gadiyar [EMAIL PROTECTED]
Cc: Kevin Hilman [EMAIL PROTECTED]
Cc: Bryan Wu [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-n800-usb.c | 46 +-
arch/arm/mach-omap2/usb-musb.c | 51 +-
arch/arm/mach-omap2/usb-tusb6010.c |1 -
drivers/usb/musb/musb_core.c | 37 +++
drivers/usb/musb/musb_core.h | 14 +---
drivers/usb/musb/tusb6010.h | 169
include/asm-arm/arch-omap/hdrc_cnf.h | 177 --
include/linux/usb/musb.h | 38 +++-
9 files changed, 147 insertions(+), 389 deletions(-)
delete mode 100644 include/asm-arm/arch-omap/hdrc_cnf.h
diff --git a/arch/arm/mach-omap2/board-n800-usb.c
b/arch/arm/mach-omap2/board-n800-usb.c
index 7599f64..16ea8fc 100644
--- a/arch/arm/mach-omap2/board-n800-usb.c
+++ b/arch/arm/mach-omap2/board-n800-usb.c
@@ -35,14 +35,58 @@ static int tusb_set_clock(struct clk *osc_ck, int state);
# define BOARD_MODE MUSB_HOST
#endif
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { ep1_tx, 5,},
+ { ep1_rx, 5,},
+ { ep2_tx, 5,},
+ { ep2_rx, 5,},
+ { ep3_tx, 3,},
+ { ep3_rx, 3,},
+ { ep4_tx, 3,},
+ { ep4_rx, 3,},
+ { ep5_tx, 2,},
+ { ep5_rx, 2,},
+ { ep6_tx, 2,},
+ { ep6_rx, 2,},
+ { ep7_tx, 2,},
+ { ep7_rx, 2,},
+ { ep8_tx, 2,},
+ { ep8_rx, 2,},
+ { ep9_tx, 2,},
+ { ep9_rx, 2,},
+ { ep10_tx, 2, },
+ { ep10_rx, 2, },
+ { ep11_tx, 2, },
+ { ep11_rx, 2, },
+ { ep12_tx, 2, },
+ { ep12_rx, 2, },
+ { ep13_tx, 2, },
+ { ep13_rx, 2, },
+ { ep14_tx, 2, },
+ { ep14_rx, 2, },
+ { ep15_tx, 2, },
+ { ep15_rx, 2, },
+};
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .soft_con = 1,
+ .dma= 1,
+ .num_eps= 32,
+ .dma_channels = 7,
+ .ram_bits = 12,
+ .eps_bits = musb_eps,
+};
+
static struct musb_hdrc_platform_data tusb_data = {
.mode = BOARD_MODE,
- .multipoint = 1,
.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,
};
/*
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index bd3556b..933f7c1 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -37,7 +37,7 @@ static struct resource musb_resources[] = {
: OMAP243X_HS_BASE,
.end= cpu_is_omap34xx()
? OMAP34XX_HSUSB_OTG_BASE + SZ_8K - 1
- : OMAP243X_HS_BASE + SZ_8K -1,
+ : OMAP243X_HS_BASE + SZ_8K - 1,
.flags = IORESOURCE_MEM,
},
[1] = { /* general IRQ */
@@ -71,6 +71,51 @@ static int musb_set_clock(struct clk *clk, int state)
return 0;
}
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { ep1_tx, 10, },
+ { ep1_rx, 10, },
+ { ep2_tx, 9,},
+ { ep2_rx, 9,},
+ { ep3_tx, 3,},
+ { ep3_rx, 3,},
+ { ep4_tx, 3,},
+ { ep4_rx, 3,},
+ { ep5_tx, 3,},
+ { ep5_rx, 3,},
+ { ep6_tx, 3,},
+ { ep6_rx, 3,},
+ { ep7_tx, 3,},
+ { ep7_rx, 3,},
+ { ep8_tx, 2,},
+ { ep8_rx, 2,},
+ { ep9_tx, 2,},
+ { ep9_rx, 2,},
+ { ep10_tx, 2, },
+ { ep10_rx, 2, },
+ { ep11_tx, 2, },
+ { ep11_rx, 2, },
+ { ep12_tx, 2, },
+ { ep12_rx, 2, },
+ { ep13_tx, 2, },
+ { ep13_rx, 2, },
+ { ep14_tx, 2, },
+ { ep14_rx, 2, },
+ { ep15_tx, 2, },
+ { ep15_rx, 2, },
+};
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .soft_con = 1,
+ .dma= 1,
+ .num_eps
Re: [PATCH 09/11] gpio context save/restore
On Tue, Jul 01, 2008 at 07:46:34PM +0530, Rajendra Nayak wrote:
+#ifdef CONFIG_ARCH_OMAP34XX
+/* save the registers of bank 2-6 */
+void omap_gpio_save(void)
+{
+ int i;
+ /* saving banks from 2-6 only */
+ for (i = 1; i gpio_bank_count; i++) {
+ struct gpio_bank *bank = gpio_bank[i];
+ gpio_restore_banks[i].gpio_sysconfig =
+ __raw_readl(bank-base + OMAP24XX_GPIO_SYSCONFIG);
+ gpio_restore_banks[i].gpio_wake_en =
+ __raw_readl(bank-base + OMAP24XX_GPIO_WAKE_EN);
+ gpio_restore_banks[i].gpio_ctrl =
+ __raw_readl(bank-base + OMAP24XX_GPIO_CTRL);
+ gpio_restore_banks[i].gpio_oe =
+ __raw_readl(bank-base + OMAP24XX_GPIO_OE);
+ gpio_restore_banks[i].gpio_leveldetect0 =
+ __raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT0);
+ gpio_restore_banks[i].gpio_leveldetect1 =
+ __raw_readl(bank-base + OMAP24XX_GPIO_LEVELDETECT1);
+ gpio_restore_banks[i].gpio_risingdetect =
+ __raw_readl(bank-base + OMAP24XX_GPIO_RISINGDETECT);
+ gpio_restore_banks[i].gpio_fallingdetect =
+ __raw_readl(bank-base + OMAP24XX_GPIO_FALLINGDETECT);
+ gpio_restore_banks[i].gpio_dataout =
+ __raw_readl(bank-base + OMAP24XX_GPIO_DATAOUT);
+ gpio_restore_banks[i].gpio_setwkuena =
+ __raw_readl(bank-base + OMAP24XX_GPIO_SETWKUENA);
+ gpio_restore_banks[i].gpio_setdataout =
+ __raw_readl(bank-base + OMAP24XX_GPIO_SETDATAOUT);
+ }
+}
+EXPORT_SYMBOL(omap_gpio_save);
+
+/* restore the required registers of bank 2-6 */
+void omap_gpio_restore(void)
+{
+ int i;
+ for (i = 1; i gpio_bank_count; i++) {
+ struct gpio_bank *bank = gpio_bank[i];
+ __raw_writel(gpio_restore_banks[i].gpio_sysconfig,
+ bank-base + OMAP24XX_GPIO_SYSCONFIG);
+ __raw_writel(gpio_restore_banks[i].gpio_wake_en,
+ bank-base + OMAP24XX_GPIO_WAKE_EN);
+ __raw_writel(gpio_restore_banks[i].gpio_ctrl,
+ bank-base + OMAP24XX_GPIO_CTRL);
+ __raw_writel(gpio_restore_banks[i].gpio_oe,
+ bank-base + OMAP24XX_GPIO_OE);
+ __raw_writel(gpio_restore_banks[i].gpio_leveldetect0,
+ bank-base + OMAP24XX_GPIO_LEVELDETECT0);
+ __raw_writel(gpio_restore_banks[i].gpio_leveldetect1,
+ bank-base + OMAP24XX_GPIO_LEVELDETECT1);
+ __raw_writel(gpio_restore_banks[i].gpio_risingdetect,
+ bank-base + OMAP24XX_GPIO_RISINGDETECT);
+ __raw_writel(gpio_restore_banks[i].gpio_fallingdetect,
+ bank-base + OMAP24XX_GPIO_FALLINGDETECT);
+ __raw_writel(gpio_restore_banks[i].gpio_dataout,
+ bank-base + OMAP24XX_GPIO_DATAOUT);
+ __raw_writel(gpio_restore_banks[i].gpio_setwkuena,
+ bank-base + OMAP24XX_GPIO_SETWKUENA);
+ __raw_writel(gpio_restore_banks[i].gpio_setdataout,
+ bank-base + OMAP24XX_GPIO_SETDATAOUT);
+ }
+}
+EXPORT_SYMBOL(omap_gpio_restore);
#else
inline void omap_gpio_save(void) {}
inline void omap_gpio_restore(void) {}
otherwise ifndef OMAP3 we're gonna get undef reference
or maybe do it in the header, but then use static inline, instead of
inline only.
--
Best Regards,
Felipe Balbi
[EMAIL PROTECTED]
http://blog.felipebalbi.com
--
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 01/11] Basic cpuidle driver
On Tue, Jul 01, 2008 at 07:46:07PM +0530, Rajendra Nayak wrote: OMAP3 Basic cpuidle small style comment: change __FUNCTION__ to __func__ to make checkpatch.pl happy ;-) -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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: TSC2004 touch driver
On Tue, Jul 01, 2008 at 05:42:07PM -0400, Peter Barada wrote: The TSC2004 is I2C, wheras the ADS7846 is SPI. I've found a TSC2003 driver written by Bill Gatliff for 2.4, but was wondering if anyone had a better starting point. Also, any idea where I can find a snap (as in source) of the kernel work-in-progress, or is it all in the git trees? there is tsc2005 in linux-omap. look at drivers/input/touchscreen/tsc2005.c if it helps you somehow, it's there :p -- Best Regards, Felipe Balbi [EMAIL PROTECTED] http://blog.felipebalbi.com -- 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: Suggestion required to switch to a new kernel
On Wed, Jul 02, 2008 at 02:02:37PM -0500, [EMAIL PROTECTED] wrote: We are working on a product which is based on OMAP5912 (OSK). As of now, we are using linux-omap 2.6.16-rc3. We had issues with the JFFS2 cleanmarkers on oneNAND. JFFS2 driver in 2.6.16-rc3 did not understand the segmented OOB in oneNAND. Rather than trying to backport the driver fixes, we have decided to upgrade to a new kernel which includes that fix (We noticed that it was fixed in 2.6.21). We would really appreciate suggestions from people on the list about the kernel version that would be the best to switch to. We want to know which kernel version is stable on OMAP. Some of our requirements are; 1. DSP gateway should work on that kernel without any issues. 2. Power management should be functional. Our product uses power management to a great extent. We are thinking of 2.6.24 (or 2.6.23). Please let us know your suggestions. Using current kernel versions is always a good idea. 2.6.24 should be good for osk, but testing is always good. Use the defconfig and change some options here and there and try it out. Report here if you find any issues :-) -- - 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: [Resending - PATCH 1/3] Triton BCI driver device setup for OMAP3430
On Thu, 3 Jul 2008 17:35:50 +0530 (IST), Madhusudhan Chikkature
[EMAIL PROTECTED] wrote:
Index: linux-omap-2.6/arch/arm/mach-omap2/bci.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/arch/arm/mach-omap2/bci.c 2008-07-03
16:59:40.0
+0530
@@ -0,0 +1,34 @@
+/*
+ * linux/arch/arm/mach-omap2/board-3430sdp-bci.c
just fix this name please.
Style only.
+
+static struct platform_device twl4030_bci_battery_device = {
+ .name = twl4030-bci-battery,
+ .id = 1,
use -1. There will be no other twl4030-bci-battery in the system :-)
--
Best Regards,
Felipe Balbi
http://blog.felipebalbi.com
[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
[PATCH] input: keypad: General fixes to omap-twl4030keypad.c
The following patch fixes some problems in T2 keypad
driver.
Basically we're passing irq number via platform_data,
moving globals to a structure and fixing a problem
while iterating over the keymap.
Some cleanups are also done so checkpatch.pl doesn't
complain about this driver anymore.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
Signed-off-by: Timo Kokkonen [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-2430sdp.c |5 +-
arch/arm/mach-omap2/board-3430sdp.c |5 +-
drivers/input/keyboard/omap-twl4030keypad.c | 206 ---
include/asm-arm/arch-omap/keypad.h |1 +
4 files changed, 130 insertions(+), 87 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 780913e..b54a7f0 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -176,9 +176,10 @@ static int sdp2430_keymap[] = {
static struct omap_kp_platform_data sdp2430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp2430_keymap,
- .keymapsize = ARRAY_SIZE(sdp2430_keymap),
+ .keymap = sdp2430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp2430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp2430_kp_device = {
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 7a216cc..beefae8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -107,9 +107,10 @@ static int sdp3430_keymap[] = {
static struct omap_kp_platform_data sdp3430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp3430_keymap,
- .keymapsize = ARRAY_SIZE(sdp3430_keymap),
+ .keymap = sdp3430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp3430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp3430_kp_device = {
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 20aeb3c..e27d2c3 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -31,6 +31,7 @@
#include linux/types.h
#include linux/input.h
#include linux/kernel.h
+#include linux/mutex.h
#include linux/delay.h
#include linux/bitops.h
#include linux/platform_device.h
@@ -47,52 +48,65 @@
#define KEYNUM_MASK0x00FF
/* Global variables */
-static int *keymap;
-static u16 kp_state[MAX_ROWS];
-static int n_rows, n_cols;
-static struct device *dbg_dev;
-static struct input_dev *omap_twl4030kp;
+struct omap_keypad {
+ int *keymap;
+ unsigned intkeymapsize;
+ u16 kp_state[MAX_ROWS];
+ int n_rows;
+ int n_cols;
+ int irq;
-static int twl4030_kpread(u32 module, u8 *data, u32 reg, u8 num_bytes)
+ struct device *dbg_dev;
+ struct input_dev *omap_twl4030kp;
+
+ /* sync read/write */
+ struct mutexmutex;
+};
+
+static int twl4030_kpread(struct omap_keypad *kp,
+ u32 module, u8 *data, u32 reg, u8 num_bytes)
{
int ret;
ret = twl4030_i2c_read(module, data, reg, num_bytes);
if (ret 0) {
- dev_warn(dbg_dev, Couldn't read TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Couldn't read TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int twl4030_kpwrite_u8(u32 module, u8 data, u32 reg)
+static int twl4030_kpwrite_u8(struct omap_keypad *kp,
+ u32 module, u8 data, u32 reg)
{
int ret;
ret = twl4030_i2c_write_u8(module, data, reg);
if (ret 0) {
- dev_warn(dbg_dev, Could not write TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Could not write TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int omap_kp_find_key(int col, int row)
+static int omap_kp_find_key(struct omap_keypad *kp, int col, int row)
{
int i, rc;
rc = KEY(col, row, 0);
- for (i = 0; keymap[i] != 0; i++)
- if ((keymap[i] ROWCOL_MASK) == rc)
- return keymap[i] KEYNUM_MASK;
+ for (i = 0; i kp-keymapsize; i++)
+ if ((kp-keymap[i] ROWCOL_MASK) == rc)
+ return kp-keymap[i] KEYNUM_MASK;
return -EINVAL;
}
-static inline u16 omap_kp_col_xlate(u8 col)
+static inline u16 omap_kp_col_xlate(struct omap_keypad *kp, u8 col)
{
/* If all bits in a row are active for all coloumns then
* we have that row line connected to gnd
Re: [PATCH] input: keypad: General fixes to omap-twl4030keypad.c
On Fri, Jul 04, 2008 at 12:34:21PM +0300, Felipe Balbi wrote: + mutex_lock(kp-lock); This should be mutex, final patch is coming. -- - 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] input: keypad: General fixes to omap-twl4030keypad.c
The following patch fixes some problems in T2 keypad
driver.
Basically we're passing irq number via platform_data,
moving globals to a structure and fixing a problem
while iterating over the keymap.
It might be that we still have a few locking issues
that might be solved on a later version of this same
patch.
For now, consider this one RFC.
Comments are welcome.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-2430sdp.c |5 +-
arch/arm/mach-omap2/board-3430sdp.c |5 +-
drivers/input/keyboard/omap-twl4030keypad.c | 206 ---
include/asm-arm/arch-omap/keypad.h |1 +
4 files changed, 130 insertions(+), 87 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 780913e..b54a7f0 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -176,9 +176,10 @@ static int sdp2430_keymap[] = {
static struct omap_kp_platform_data sdp2430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp2430_keymap,
- .keymapsize = ARRAY_SIZE(sdp2430_keymap),
+ .keymap = sdp2430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp2430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp2430_kp_device = {
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 7a216cc..beefae8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -107,9 +107,10 @@ static int sdp3430_keymap[] = {
static struct omap_kp_platform_data sdp3430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp3430_keymap,
- .keymapsize = ARRAY_SIZE(sdp3430_keymap),
+ .keymap = sdp3430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp3430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp3430_kp_device = {
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 20aeb3c..c60455e 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -31,6 +31,7 @@
#include linux/types.h
#include linux/input.h
#include linux/kernel.h
+#include linux/mutex.h
#include linux/delay.h
#include linux/bitops.h
#include linux/platform_device.h
@@ -47,52 +48,65 @@
#define KEYNUM_MASK0x00FF
/* Global variables */
-static int *keymap;
-static u16 kp_state[MAX_ROWS];
-static int n_rows, n_cols;
-static struct device *dbg_dev;
-static struct input_dev *omap_twl4030kp;
+struct omap_keypad {
+ int *keymap;
+ unsigned intkeymapsize;
+ u16 kp_state[MAX_ROWS];
+ int n_rows;
+ int n_cols;
+ int irq;
-static int twl4030_kpread(u32 module, u8 *data, u32 reg, u8 num_bytes)
+ struct device *dbg_dev;
+ struct input_dev *omap_twl4030kp;
+
+ /* sync read/write */
+ struct mutexmutex;
+};
+
+static int twl4030_kpread(struct omap_keypad *kp,
+ u32 module, u8 *data, u32 reg, u8 num_bytes)
{
int ret;
ret = twl4030_i2c_read(module, data, reg, num_bytes);
if (ret 0) {
- dev_warn(dbg_dev, Couldn't read TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Couldn't read TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int twl4030_kpwrite_u8(u32 module, u8 data, u32 reg)
+static int twl4030_kpwrite_u8(struct omap_keypad *kp,
+ u32 module, u8 data, u32 reg)
{
int ret;
ret = twl4030_i2c_write_u8(module, data, reg);
if (ret 0) {
- dev_warn(dbg_dev, Could not write TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Could not write TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int omap_kp_find_key(int col, int row)
+static int omap_kp_find_key(struct omap_keypad *kp, int col, int row)
{
int i, rc;
rc = KEY(col, row, 0);
- for (i = 0; keymap[i] != 0; i++)
- if ((keymap[i] ROWCOL_MASK) == rc)
- return keymap[i] KEYNUM_MASK;
+ for (i = 0; i kp-keymapsize; i++)
+ if ((kp-keymap[i] ROWCOL_MASK) == rc)
+ return kp-keymap[i] KEYNUM_MASK;
return -EINVAL;
}
-static inline u16 omap_kp_col_xlate(u8 col)
+static inline u16 omap_kp_col_xlate(struct omap_keypad *kp, u8 col)
{
/* If all bits in a row are active for all coloumns then
* we have
Re: [PATCH 3/4] Hook start_hnp into ohci struct
On Sun, Jul 06, 2008 at 02:33:32PM +0400, Dmitry Baryshkov wrote: Actually the ohci-omap.c:start_hnp does a bit more than just otg_start_hnp(tranceiver). Maybe it should be merged. I dunno. Most likely it should be merged, or at least the name should change. -- - 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: Kernel oops when shutting down program using usb device
On Wed, Jul 16, 2008 at 05:59:01PM -0400, Philip Balister wrote: Alan Stern wrote: On Wed, 16 Jul 2008, Philip Balister wrote: The program streams data from the USRP (Universal Software Radio Peripheral) and calculates a transfer rate. It looks like the test completes and the program ooops as it is exiting. Let me know if I can collect anything else. I am not much of a usb guy :( Philip [EMAIL PROTECTED]:~/gnuradio-3.1.2/usrp/host/apps# ./test_usrp_standard_rx -D 200rx_overrun eth0: set allmulti eth0: set allmulti eth0: set allmulti eth0: set allmulti xfered 1.34e+08 bytes in 116 seconds. 1.159e+06 bytes/sec. cpu time = 1.633 noverruns = 1 [ cut here ] WARNING: at lib/kref.c:43 kref_get+0x28/0x44() This is just a warning, not an oops. Nevertheless, it should not happen. What version of the kernel were you running? On what hardware and using which USB host controller driver? Is the problem reproducible? Doh, silly me for leaving out details Beagle Board, OMAP3 based. Kernel is a fairly recent git + some patches. I can backtrack to an exact collection if necessary. I ran the test program several times and the system hangs when the program ends. I do not think I get the warning message every time though, the system does hang every time. Hmm... so it's musb. Please, recompile your kernel with CONFIG_USB_MUSB_LOGLEVEL set to 3 and enable also CONFIG_USB_DEBUG and CONFIG_USB_GADGET_DEBUG. Set sysrq-trigger to 8 (echo 8 /proc/sysrq-trigger) and musb debug messages will be written to you current console. Send that output in next mail :-) I'll try to look at it tomorrow with my beagle. Which gadget driver are you using ? Get me the output of uname -r. Which test program is that ? Tell me how to reproduce the WARNING if I don't have your test program. -- 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: N800 problems with MMC, LM8323 on current linux-omap git head
On Thu, Jul 17, 2008 at 09:25:06PM -0600, ext Paul Walmsley wrote: noticed a few issues booting the N800 with the current git head d3b3ae0fe6c71641da19c8de466ec366d39847e3 today. Haven't booted the N800 for a while, so not sure when these showed up. Can you reproduce it, I just botted n800 up to maemo desktop with current linux omap (d3b3ae0fe6c71641da19c8de466ec366d39847e3) -- 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 2/2] TWL4030: convert old-style function documentation to current kerneldoc
On Thu, 17 Jul 2008 20:15:51 -0600, Paul Walmsley [EMAIL PROTECTED] wrote:
Several functions use old-style function documentation; convert those to
use the current kerneldoc style.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
drivers/i2c/chips/twl4030-core.c | 54
++
1 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/i2c/chips/twl4030-core.c
b/drivers/i2c/chips/twl4030-core.c
index 54e392b..4104fd2 100644
--- a/drivers/i2c/chips/twl4030-core.c
+++ b/drivers/i2c/chips/twl4030-core.c
@@ -389,17 +389,18 @@ static struct irq_chip twl4030_irq_chip = {
};
/* Global Functions */
-/*
- * @brief twl4030_i2c_write - Writes a n bit register in TWL4030
+
+/**
+ * twl4030_i2c_write - Writes a n bit register in TWL4030
+ * @mod_no: module number
+ * @value: an array of num_bytes+1 containing data to write
+ * @reg: register address (just offset will do)
+ * @num_bytes: number of bytes to transfer
*
- * @param mod_no - module number
- * @param *value - an array of num_bytes+1 containing data to write
- * IMPORTANT - Allocate value num_bytes+1 and valid data starts at
- *Offset 1.
- * @param reg - register address (just offset will do)
- * @param num_bytes - number of bytes to transfer
+ * IMPORTANT: for 'value' parameter: Allocate value num_bytes+1 and
+ * valid data starts at Offset 1.
*
- * @return result of operation - 0 is success
+ * Results the result of operation - 0 is success
I suppose you mean Returns here.
--
Best Regards,
Felipe Balbi
http://blog.felipebalbi.com
[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: N800 problems with MMC, LM8323 on current linux-omap git head
On Fri, Jul 18, 2008 at 02:49:45AM -0600, ext Paul Walmsley wrote: It boots to desktop, but those messages come across the serial console consistently across several boots. Do touchscreen taps play sound for you? Hmm, now I got it right. The thing is that n800 doesn't have lm8323 (keypad), so that driver shouldn't be probing. That's quite weird. I'll try to take a look at it. -- 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: N800 problems with MMC, LM8323 on current linux-omap git head
On Fri, Jul 18, 2008 at 02:49:45AM -0600, ext Paul Walmsley wrote:
It boots to desktop, but those messages come across the serial console
consistently across several boots. Do touchscreen taps play sound for
you?
The attached patch fixes lm8323 error. I'll see the others now.
--
balbi
From 2fa4882be13e00076c641bbff5d9607225ec647a Mon Sep 17 00:00:00 2001
From: Felipe Balbi [EMAIL PROTECTED]
Date: Fri, 18 Jul 2008 12:20:01 +0300
Subject: [PATCH] input: add more error checks to lm8323 driver
If we can't reach the driver, we stop trying to probe
it. Useful when building kernel for n800 and n810.
n800 doesn't have lm8323, so that driver shouldn't probe
there.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
drivers/input/keyboard/lm8323.c | 42 +-
1 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 72bb587..3d10a0f 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -348,10 +348,10 @@ static void lm8323_process_error(struct lm8323_chip *lm)
}
}
-static void lm8323_reset(struct lm8323_chip *lm)
+static int lm8323_reset(struct lm8323_chip *lm)
{
/* The docs say we must pass 0xAA as the data byte. */
- lm8323_write(lm, 2, LM8323_CMD_RESET, 0xAA);
+ return lm8323_write(lm, 2, LM8323_CMD_RESET, 0xAA);
}
static int lm8323_configure(struct lm8323_chip *lm)
@@ -360,6 +360,7 @@ static int lm8323_configure(struct lm8323_chip *lm)
int clock = (CLK_SLOWCLKEN | CLK_RCPWM_EXTERNAL);
int debounce = lm-debounce_time 2;
int active = lm-active_time 2;
+ int ret;
/*
* Active time must be greater than the debounce time: if it's
@@ -368,13 +369,25 @@ static int lm8323_configure(struct lm8323_chip *lm)
if (debounce = active)
active = debounce + 3;
- lm8323_write(lm, 2, LM8323_CMD_WRITE_CFG, 0);
- lm8323_write(lm, 2, LM8323_CMD_WRITE_CLOCK, clock);
- lm8323_write(lm, 2, LM8323_CMD_SET_KEY_SIZE, keysize);
+ ret = lm8323_write(lm, 2, LM8323_CMD_WRITE_CFG, 0);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 2, LM8323_CMD_WRITE_CLOCK, clock);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 2, LM8323_CMD_SET_KEY_SIZE, keysize);
+ if (ret)
+ goto err;
lm8323_set_active_time(lm, lm-active_time);
- lm8323_write(lm, 2, LM8323_CMD_SET_DEBOUNCE, debounce);
- lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_STATE, 0xff, 0xff);
- lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_SEL, 0, 0);
+ ret = lm8323_write(lm, 2, LM8323_CMD_SET_DEBOUNCE, debounce);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_STATE, 0xff, 0xff);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_SEL, 0, 0);
+ if (ret)
+ goto err;
/*
* Not much we can do about errors at this point, so just hope
@@ -382,6 +395,11 @@ static int lm8323_configure(struct lm8323_chip *lm)
*/
return 0;
+
+err:
+ dev_err(lm-client-dev, failed to configure lm8323\n);
+
+ return ret;
}
/*
@@ -721,7 +739,9 @@ static int lm8323_probe(struct i2c_client *client,
else if (lm-active_time == -1) /* Disable sleep. */
lm-active_time = 0;
- lm8323_reset(lm);
+ err = lm8323_reset(lm);
+ if (err)
+ goto fail2;
/* Nothing's set up to service the IRQ yet, so just spin for max.
* 100ms until we can configure. */
@@ -738,7 +758,9 @@ static int lm8323_probe(struct i2c_client *client,
msleep(1);
}
- lm8323_configure(lm);
+ err = lm8323_configure(lm);
+ if (err)
+ goto fail2;
/* If a true probe check the device */
if (lm8323_read_id(lm, data) != 0) {
--
1.5.6.1.156.ge903b
Re: [PATCH] Set correct off mode polarity
Hi, style comments inlined. On Mon, Jul 21, 2008 at 07:02:02PM +0300, Peter 'p2' De Schrijver wrote: +#define OFFMODE_POL (13) add spaces after 1 and before 3 (1 3) - unnecessary change ?!? -- 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] Load triton2 scripts.
On Mon, Jul 21, 2008 at 07:02:05PM +0300, Peter 'p2' De Schrijver wrote:
+/*
+*Power Bus Message Format
+*
+*Broadcast Message (16 Bits)
+*DEV_GRP[15:13] MT[12] RES_GRP[11:9] RES_TYPE2[8:7] RES_TYPE[6:4]
+*RES_STATE[3:0]
+*
+*Singular Message (16 Bits)
+*DEV_GRP[15:13] MT[12] RES_ID[11:4] RES_STATE[3:0]
+*
+*/
This comment should follow the coding style:
/*
* Power Bus Message Format
*
* Broadcast Message (16 Bits)
* DEV_GRP[15:13] MT[12] RES_GRP[11:9] RES_TYPE2[8:7] RES_TYPE[6:4]
* RES_STATE[3:0]
*
* Singular Message (16 Bits)
* DEV_GRP[15:13] MT[12] RES_ID[11:4] RES_STATE[3:0]
*/
+struct triton_ins {
+ u16 pmb_message;
+ u8 delay;
+};
+
+
extra line
+#define CONFIG_DISABLE_HFCLK 1
+
+#if defined(CONFIG_MACH_OMAP_3430SDP) ||
defined(CONFIG_MACH_OMAP_3430LABRADOR)
+
+struct triton_ins sleep_on_seq[] __initdata = {
+ {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 4},
could you add spaces here??
{ MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 4 },
--
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: N800 problems with MMC, LM8323 on current linux-omap git head
On Tue, 22 Jul 2008 15:47:43 +0300, Riku Voipio [EMAIL PROTECTED] wrote: Hmm. I think it would be better to avoid calling the probe in first place. git diff made the attached patch look more confusing than it actually is. Personally I'd eliminate all ifdefs from those i2c_board_info structs. I did the same thing before, but then we're gonna start adding several i2c_board_info for different hw. I mean, we should just reuse the code and the driver should know when the device is not present and stop probing without any problems to the rest of the system. -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [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: [i2c] N800 problems with MMC, LM8323 on current linux-omap git head
Hi, On Tue, 22 Jul 2008 14:43:14 +0100, Ben Dooks [EMAIL PROTECTED] wrote: Split them into a common and then machine specfic structures, you are allowed to register more than one board per bus. Good to know :-) Riku, could you update your patch then ? but it anyways doesn't annul the need of a better error handling in lm8323. I think both patches will need to be applied :-) -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [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: [Resending - PATCH 1/3] Triton BCI driver board/device setup for OMAP3430
On Wed, 23 Jul 2008 10:16:27 +0530, Madhusudhan Chikkature [EMAIL PROTECTED] wrote: Hi Felipe, Tony, weird that we still have these prototypes in these headers. Could be some merging conflict ? Yes. I see that these prototypes are still present in the board3430 and board2430 header files in the omap tree. Anyways, please apply the attached patch. We're using usb_musb_init() and usb_ehci_init() now. You mean I should apply the attached patch you sent for local use, right? And I guess I dont need to resend this perticular BCI patch, am I correct? No :-) that was to Tony. Just replied to your mail so it's easy to see why we need that patch :-) -- Best Regards, Felipe Balbi http://blog.felipebalbi.com [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] Set correct off mode polarity
On Wed, Jul 23, 2008 at 04:26:32PM +0300, Peter 'p2' De Schrijver wrote: - unnecessary change ?!? ? This change is necessary, otherwise the system dies as soon as the triton2 sysoffmode scripts become active. ehehe, i meant the whitespace :-) -- 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 0/4] OMAP: MENELAUS: Improvements on menelaus
On Tue, Jul 29, 2008 at 12:44:19PM -0400, Carlos Aguiar wrote: Hi Tony and folks, This patch series proposes some improvements on menelaus code. Basically it makes menelaus to use macros instead of some magic constant numbers, making menelaus code more legible. The menelaus header was moved to include/linux/i2c and register map (including the macros created) were moved to include/linux/i2c/menelaus.h Tested with MMC on N800 and looks fine. They look quite ok. How about syncing l-o menelaus with mainline via lm-sensors mailing list and discuss all these there as well ?? It'd be only one extra patch before this one to make everything in sync. -- 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 0/4] OMAP: MENELAUS: Improvements on menelaus
On Wed, Jul 30, 2008 at 01:07:35AM +0530, Gadiyar, Anand wrote: I think it'll be hard for a newbie to figure out what this menelaus is. Google won't help either, (unless one really thinks there is a connection between Linux and Greek Mythology ;) ). eheh, That's true :-) I second renaming the file to TWL92230. Mentioning this in Kconfig is simply not enough. Hmm... are there any other devices which would work with the same 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
Re: USB driver issue
On Wed, Jul 30, 2008 at 06:28:35PM +0530, ext Dasgupta, Romit wrote: What is the application you are using and could you turn the musb driver debug options? You can try it by echo D 3 /proc/driver/musb_hdrc (Check if MUSB_DEBUG is enabled). it's D3, together :-) This should give more helpful messages. -Original Message- From: [EMAIL PROTECTED] [mailto:linux-omap-open- [EMAIL PROTECTED] On Behalf Of SUBHRANIL CHOUDHURY Sent: Wednesday, July 30, 2008 5:50 PM To: Gadiyar, Anand Cc: [EMAIL PROTECTED] Subject: Re: USB driver issue hi, I am using Mistral OMAP3430 OSK2.1 board. It is the USB OTG port. The Philips tranciever ISP1504. I am enabling the EHCI and OHCI in the kernel menuconfig. This was the error print i was getting: Unable to handle kernel NULL pointer dereference at virtual address pgd = c54d8000 [] *pgd=81401031, *pte=, *ppte= Internal error: Oops: 817 [#1] Modules linked in: CPU: 0Not tainted (2.6.22.18-omap3 #29) PC is at consistent_sync+0x40/0xa4 LR is at usb_hcd_submit_urb+0x7b0/0x8b4 pc : [c00315ac]lr : [c02307e0]psr: 2013 sp : c1403c48 ip : c1403c58 fp : c1403c54 r10: 8003 r9 : 0020 r8 : 0020 r7 : c483dc20 r6 : c0569000 r5 : c23c040c r4 : ff2d2000 r3 : r2 : 0002 r1 : ff2dba38 r0 : ff2d2000 Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment user Control: 00c5387f Table: 854d8018 DAC: 0015 Do you get some clue from this about what is happening? there must be a backtrace right after that, can you paste it as well? -- 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: USB driver issue
On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil Kotsev wrote: Dear Felipe, I just want to tell, that while still developing kernels in the 2.6.2X series a kernel 2.6.22 can not be labeled as old. Besides it comes along with few distros as default kernel. A lot of people like me need some kind of a stable version that we can relay on for more than playing at home, which is the case with 2.4.X tree. Personally, experiments with 2.6.24 brought me into a big trouble and it took many hours to migrate back to 2.6.20, so please keep in mind that if we say something like this, there is a good reason to do so. You can always choose any kernel version you want but if you choose such an old version (2.6.22 was released in Jul 8th, 2007), please don't rely in community support and instead, backport all changes in the particular driver you're working with to 2.6.22. It's always your choice. -- 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: USB driver issue
On Wed, Jul 30, 2008 at 10:55:03PM +0530, Gadiyar, Anand wrote: Okay. That comparison wasn't warranted, I guess. But here's what went through my mind when I read Felipe's post. If you want this to work, then upgrade. And that looked exactly like MS telling me I can't help you with XP anymore, move on to Vista mate. eheh, did I really say that ? I hope not. :-p What I meant is that it's possible that recent code has that particular bug fixed. Why on earth do we have the stable trees then? Why do people put in their time porting fixes back to the 2.6.22.* 'stable' trees? There are still people out there that use them, for whatever reason. And they do run into bugs that still haven't been caught. But then again, if the problem _is_ solved in current tree then it's easier to just backport then trying to solve it again. If it _does_ exist in current code, then we fix both in a shot. I don't particularly care if people don't want to support old code. What I do care about is the attitude that's out here - Hey! Move up in life man! Get the latest, greatest, RC kernel! 2.6.24 is ancient, 2.6.26 is ancient!. Yes, I do use 2.6.27-rc1 prepatch. But I do recognize that there are people out there who don't. We do recognize as well. We're still releasing maemo sw with 2.6.21 kernel. Yes people should ideally work off the latest. But that shouldn't mean one won't get help if one is not using the latest. Or am I totally wrong here? Again, if there is more recent code to try out, I really don't see why not trying out that more recent code to see if the same bug shows up. It'll make things easier to track down. We should know if we were able to fix it since 2.6.22 until today, then we just track the changes in that particular function and it's a lot easier to backport the fix, don't you think ? -- 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: USB driver issue
Hi, I hope we end this thread some day... On Thu, Jul 31, 2008 at 01:38:59PM -0700, Emanoil Kotsev wrote: Kernel developers should fix bugs in minor kernel versions as they are meant for this purpous and do major changes only in major version. A bunch of bugfixes I see (not only usb related) are just not in place in minor kernel versions. That's my opinion at first place. Second if you want to have me as happy linux user developers should agree to support older versions to help embeded and other developers working further on their projects. And I'm writing this because (also in other forums) people tend to have such a neglecting mentality ignoring the needs of others. Just to remember the reason for this discussion was the statement that 2.6.22 was too old, which as Anand pointed out was in it's latest release was issued in the beginning of the year. This is really windows like mentality and as Anand says at least they support the versions they issue - sorry for this - but I think it's kind of truth. 2.6.22 was in Jul 2007, he pointed out a minor stable version out of 2.6.22. And yes I'm planing to try 2.6.26, but I'm pretty sure that there would be issues with drivers like uvcview, the proprietary ATI and NVidia and apps like skype Closed source drivers have issues, film at 11. Bah, take it up with them, there is NOTHING that us developers can do about that, sorry. You are neglecting the point and kind of insulting me! So you think I should spent my time convincing about 20 people from different companies to recompile their software because I was told by you to upgrade to fix a usb issue or a kind that is not related to their software and when they finally do it there is a already a new kernel version ... sorry I can not agree with any of you on this point. You want me to spent my time contacting people and not working on my projects ;-) You are really missing the whole point of the discussion. The driver in question is musb, which is not closed source at all. Closed source drivers is a different issue and Linux kernel is said that won't provide a stable API. It's always changing. Really, musb driver _has_ changed since 2.6.22 and that special 2.6.22 version was coming from a vendor we cannot support vendor kernel. We support linux mainline git tree, that's all. I just asked why using that version, I didn't ask nobody to upgrade. But really, all the changes made from 2.6.22 until now would make any musb patch from 2.6.22 to be unaplicable to recent musb code, besides, *again* it might be that the particular bug could have been fixed in all those set of changes in musb driver from 2.6.22 until now, so why spending time trying to fix again something that might have been fixed ? We could only backport that particular bug fix to 2.6.22. Why just not be able to patch my old kernel without breaking the ability to use the software I already have installed and is working with the version I use? You can do it, but you cannot expect that your patch get accepted, it might even not apply and that was my point. I think this is the question no body wants to answer and I think there is a problem with you guys. What are you doing this development if some people are not happy with it and have reasonable arguments. Talk for yourself, don't broadcast it. May be the patches should be split into smaller files related to bugs - just an idea! You experience a bug and patch - the bug is gone you are happy. May be there should be some longer period to support at least the latest stable releases ... but something should be done. If the api has changed you cannot expect that. Specialy if you're using vendor-specific kernel, it doesn't matter if it's nokia, redhat, ubuntu, TI, etc. Applications are a different story, they should just work with different kernel versions, there should not be any problems there. If there are, let the kernel developers know, we take backwards userspace compatiblity VERY seriously. gcc-4.3 ;-) is it application or what do you mean ... the compiler is not an application ;-) And it works it doesn't matter the kernel is running below it. If it can generate good binaries or not it's a different story. Has nothing to do with kernel, it's a gcc-related issue, don't you think ? Anyways, this thread is already way too big. -- 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: USB driver issue
On Sat, Aug 02, 2008 at 04:45:19PM -0700, Emanoil Kotsev wrote: I don't mind testing for you for free, but I need for few reasons something relaible. If you can not make it to offer such a kernel version then admit it and stop writing things that are insulting to hear. Did you really had a big break with linux since 2.6.20 ?? I'm using linux because I like the open source philosophy and I contribute to it for free, also because I like it so. If you are trying to earn money or to force me to pay for a support (like Novel/SuSE suggests) then forget it. We all contribute to this philosophy for free and that's why you have so much to do. And we're gonna still doing it for free. Whenever I leave work, my company is not paying me anymore. Even the work I have for publishing stuff, my company is not paying me for. The hours I spent listening and helping out, the way I can, the community my company is not paying me for. What we would like to see is something between latest and such old kernel that has fewer bugs, so I may not go to bed and think about if my data is there tomorrow or not. And with the changes you make and go forward without (I repeat) without excessive testing. You can not guarantee this! And once again you're mistaken. Just to be sure, I've been testing musb driver (the original bug report was to musb) for over 20 hours and got no problems so far. And, believe me, there people crazier than me about stress testing ;-) I just wanted to share an experience or impression I have since 2.6.20 and this impression is getting worse the way you think and put forward things. As Greg said, this model has been working quite well so far and it doesn't seem we're gonna change it. I just wanted to give you an advanced user opinion and to find out what could be done. Well, so far nothing and the only solution for me is to stick to my tested 2.4.26 kernel and wait that better times come and something changes in the kernel development community. Neither 2.6.20 nor 2.6.24 are running wihtout a problem and believe me I'm not testing 2.6.26 FOR FREE on my server where I've stored my data. Why don't you file bugs then? The thing is that we really can't stop moving forward to check something over 1 year old. We have so many changes from version to version that it's impossible to go 4 versions back on time and check what's wrong there. If you have any coding skills, you can provide support for older versions of the kernel if you feel like, but like Greg said, it's hell a of work to do. The 2.6.xx release cycle has been quite stable so far. One thing we do care is not to break something that was working before - don't reply with closed source drivers arguments, please; there's nothing we can do about them - sometimes we have a regression and something gets messed, sorry. We also commit mistakes. But generaly, things are going quite good. The fix for that regression will most likely be applied to one of the -stable team releases. If you really DO need a stable older version kernel, you can stick with the pre-compiled images coming from your distro. They are supported and somewhat frozen. Once in a while you'll get an update for that particular version. Saying that neither 2.6.20 nor 2.6.24 are running without a problem is both vague and true. True because every sw has problems, so has linux kernel. Vague because you're not telling us where are the problems ?!? I'm using 2.6.27-rc1 and it has been quite a long time (and I've been using 2.6 series since 2.6.0) that I don't have big issues with it. Suspend-to-ram and suspend-to-disk are working just fine, acpi is quite good (thanks to Arjan and the other people in linux-acpi), usb is also really good (we have an uncountable number of working drivers), wifi is working, bluetooth is working, anyways, I really don't have problems with linux. ps: only while I was writing this mail I pulled 185 new changes from linux-2.6.git, not counting merges. -- 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] usb: musb: fix hanging when rmmod gadget driver
If we try to modprobe a second gadget driver before
rmmoding the first one, the reference for the first
gadget driver would get NULLed avoiding usb to change
gadget drivers later.
Cc: Greg Kroah-Hartman [EMAIL PROTECTED]
Cc: David Brownell [EMAIL PROTECTED]
Cc: Tony Lindgren [EMAIL PROTECTED]
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
drivers/usb/musb/musb_gadget.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index b3773f1..d6a802c 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1710,17 +1710,15 @@ int usb_gadget_register_driver(struct usb_gadget_driver
*driver)
spin_unlock_irqrestore(musb-lock, flags);
- if (retval == 0)
+ if (retval == 0) {
retval = driver-bind(musb-g);
- if (retval != 0) {
- DBG(3, bind to driver %s failed -- %d\n,
- driver-driver.name, retval);
- musb-gadget_driver = NULL;
- musb-g.dev.driver = NULL;
- }
+ if (retval != 0) {
+ DBG(3, bind to driver %s failed -- %d\n,
+ driver-driver.name, retval);
+ musb-gadget_driver = NULL;
+ musb-g.dev.driver = NULL;
+ }
- /* start peripheral and/or OTG engines */
- if (retval == 0) {
spin_lock_irqsave(musb-lock, flags);
/* REVISIT always use otg_set_peripheral(), handling
--
1.6.0.rc1.11.g1ce47
--
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: Workaround for simultaneous TX and RX usage
On Mon, Aug 04, 2008 at 06:48:22PM +0530, ext Gadiyar, Anand wrote: MUSB RTL v1.4 has a hardware issue which results in a DMA controller hang when TX and RX DMA channels are simultaneously enabled. This affects at least OMAP2430 and OMAP34XX. Since RX transfers are in Mode 0 and anyway result in one DMA interrupt per packet, we can use System DMA to unload the RX fifos. MUSB DMA can be used for all TX channels as before. Tested with full-duplex TX and RX transfers using g_ether. Runs for 24 hours without a hang. Without this patch, the hang occurs within minutes. This patch is not applying against linux-omap musb neither musb on greg's queue. Could you please refresh it ? It's better to use the version on greg's queue, if it fails for linux-omap I can prepare a clean patch to avoid conflicts later. -- 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: [Resending - PATCH 1/3] Triton BCI driver board/device setup for OMAP3430
On Tue, Aug 05, 2008 at 04:35:51PM +0300, Tony Lindgren wrote: * Felipe Balbi [EMAIL PROTECTED] [080723 10:32]: On Wed, 23 Jul 2008 10:16:27 +0530, Madhusudhan Chikkature [EMAIL PROTECTED] wrote: Hi Felipe, Tony, weird that we still have these prototypes in these headers. Could be some merging conflict ? Yes. I see that these prototypes are still present in the board3430 and board2430 header files in the omap tree. Anyways, please apply the attached patch. We're using usb_musb_init() and usb_ehci_init() now. You mean I should apply the attached patch you sent for local use, right? And I guess I dont need to resend this perticular BCI patch, am I correct? No :-) that was to Tony. Just replied to your mail so it's easy to see why we need that patch :-) Pushing these today. Do you have a patch for moving the extern prototypes into the twl header? I was talking about these: From: Felipe Balbi [EMAIL PROTECTED] arch: omap: get rid of usb_init() protytpes we now use usb_musb_init() and usb_ehci_init() functions Signed-off-by: Felipe Balbi [EMAIL PROTECTED] --- diff --git a/include/asm-arm/arch-omap/board-2430sdp.h b/include/asm-arm/arch-omap/board-2430sdp.h index fde6915..83d0eec 100644 --- a/include/asm-arm/arch-omap/board-2430sdp.h +++ b/include/asm-arm/arch-omap/board-2430sdp.h @@ -36,6 +36,5 @@ /* Function prototypes */ extern void sdp2430_flash_init(void); -extern void sdp2430_usb_init(void); #endif /* __ASM_ARCH_OMAP_2430SDP_H */ diff --git a/include/asm-arm/arch-omap/board-3430sdp.h b/include/asm-arm/arch-omap/board-3430sdp.h index d583008..85f769e 100644 --- a/include/asm-arm/arch-omap/board-3430sdp.h +++ b/include/asm-arm/arch-omap/board-3430sdp.h @@ -29,7 +29,6 @@ #ifndef __ASM_ARCH_OMAP_3430SDP_H #define __ASM_ARCH_OMAP_3430SDP_H -extern void sdp3430_usb_init(void); extern void sdp3430_flash_init(void); #define DEBUG_BASE 0x0800 /* debug 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: Problems with USB Gadget on the OMAP3EVM
On Wed, Aug 06, 2008 at 01:27:40PM +0530, ext Gadiyar, Anand wrote: Also increase MUSB_LOGLEVEL to 3 in your .config file and reabuild that 2.6.22.18 kernel. Don't bother re-building the kernel. You could just do an echo D3 /proc/driver/musb_hdrc or even D5 for more detail. If low-level debug is not enabled, you can echo 8 /proc/sys/kernel/printk and you should be able to see the debug prints. Those might be useful. This should work on the linux-omap kernel as well. By the way, does g_file_storage work on this board? Didn't know you guys had that on your tree as well. Good to know :-) -- 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 RFC] MUSB: Fix index register corruption seen with g_ether and Windows host
On Tue, Aug 05, 2008 at 09:18:14PM +0530, ext Gadiyar, Anand wrote: If Indexed Mode register accesses are enabled, the ep0_rxstate() function calls musb_g_ep0_giveback() before writing to the CSR register. When control returns to this ep0_rxstate, the index register contents are over-written. This causes the CSR register write to fail. Fixed by writing the correct value into the index register before writing to the CSR. This was observed only in ep0_rxstate() with g_ether loaded and the device connected to a MS Windows host PC. Anticipatively fixed ep0_txstate() as well. Hi, can you mail me (only) this patch as an attachement or put it somewhere i can download ? -- 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 RFC] MUSB: Fix index register corruption seen with g_ether and Windows host
On Wed, Aug 06, 2008 at 01:47:33PM +0300, Felipe Balbi wrote: Hi, can you mail me (only) this patch as an attachement or put it somewhere i can download ? eheh, forget it, did it by hand :-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: musb bogosity
On Fri, Aug 08, 2008 at 11:32:45AM +0300, Felipe Balbi wrote:
other users. Why this driver isn't using ioread/writeXX_rep() is beyond
I'll try to fix io routines asap. From your next mail I could see that
it's really bogus :-p
drivers/usb/musb/musb_core.c: In function 'fifo_setup':
drivers/usb/musb/musb_core.c:1122: error: 'MUSB_C_RAM_BITS' undeclared
(first use in this function)
drivers/usb/musb/musb_core.c:1122: error: (Each undeclared identifier is
reported only once
drivers/usb/musb/musb_core.c:1122: error: for each function it appears in.)
drivers/usb/musb/musb_core.c: In function 'ep_config_from_table':
drivers/usb/musb/musb_core.c:1246: error: 'MUSB_C_RAM_BITS' undeclared
(first use in this function)
drivers/usb/musb/musb_core.c: In function 'musb_remove':
drivers/usb/musb/musb_core.c:2131: warning: unused variable 'ctrl_base'
make[1]: *** [drivers/usb/musb/musb_core.o] Error 1
make: *** [drivers/usb/musb/musb_core.o] Error 2
Below is the patch that fixes it.
I don't have sh cross-compilers, so if you could try it out and be sure
it works, I'd be glad.
cut here
From 0bbc416e8170c4169608f7496b8d67be3828d76b Mon Sep 17 00:00:00 2001
From: Felipe Balbi [EMAIL PROTECTED]
Date: Fri, 8 Aug 2008 11:39:41 +0300
Subject: [PATCH] usb: musb: pass configuration specifics via pdata
Use platform_data to pass musb configuration-specific
details to musb driver.
This patch will prevent that other platforms selecting
HAVE_CLK and enabling musb won't break tree building.
The other parts of it will come when linux-omap merge
up more omap2/3 board-files.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/usb-tusb6010.c |1 -
drivers/usb/musb/musb_core.c | 37 -
drivers/usb/musb/musb_core.h | 14 +---
drivers/usb/musb/tusb6010.h| 169
include/linux/usb/musb.h | 38 +++-
5 files changed, 51 insertions(+), 208 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-tusb6010.c
b/arch/arm/mach-omap2/usb-tusb6010.c
index 80bb42e..8fee64c 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -317,7 +317,6 @@ tusb6010_setup_interface(struct musb_hdrc_platform_data
*data,
printk(error, 6, status);
return -ENODEV;
}
- data-multipoint = 1;
tusb_device.dev.platform_data = data;
/* REVISIT let the driver know what DMA channels work */
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 462586d..d68ec6d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -990,12 +990,6 @@ static void musb_shutdown(struct platform_device *pdev)
* We don't currently use dynamic fifo setup capability to do anything
* more than selecting one of a bunch of predefined configurations.
*/
-#ifdef MUSB_C_DYNFIFO_DEF
-#definecan_dynfifo() 1
-#else
-#definecan_dynfifo() 0
-#endif
-
#if defined(CONFIG_USB_TUSB6010) || \
defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP34XX)
static ushort __initdata fifo_mode = 4;
@@ -1008,8 +1002,6 @@ module_param(fifo_mode, ushort, 0);
MODULE_PARM_DESC(fifo_mode, initial endpoint configuration);
-#define DYN_FIFO_SIZE (1(MUSB_C_RAM_BITS+2))
-
enum fifo_style { FIFO_RXTX, FIFO_TX, FIFO_RX } __attribute__ ((packed));
enum buf_mode { BUF_SINGLE, BUF_DOUBLE } __attribute__ ((packed));
@@ -1119,11 +,12 @@ fifo_setup(struct musb *musb, struct musb_hw_ep *hw_ep,
c_size = size - 3;
if (cfg-mode == BUF_DOUBLE) {
- if ((offset + (maxpacket 1)) DYN_FIFO_SIZE)
+ if ((offset + (maxpacket 1))
+ (1 (musb-config-ram_bits + 2)))
return -EMSGSIZE;
c_size |= MUSB_FIFOSZ_DPB;
} else {
- if ((offset + maxpacket) DYN_FIFO_SIZE)
+ if ((offset + maxpacket) (1 (musb-config-ram_bits + 2)))
return -EMSGSIZE;
}
@@ -1219,13 +1212,13 @@ static int __init ep_config_from_table(struct musb
*musb)
/* assert(offset 0) */
/* NOTE: for RTL versions = 1.400 EPINFO and RAMINFO would
-* be better than static MUSB_C_NUM_EPS and DYN_FIFO_SIZE...
+* be better than static musb-config-num_eps and DYN_FIFO_SIZE...
*/
for (i = 0; i n; i++) {
u8 epn = cfg-hw_ep_num;
- if (epn = MUSB_C_NUM_EPS) {
+ if (epn = musb-config-num_eps) {
pr_debug(%s: invalid ep %d\n,
musb_driver_name, epn);
continue;
@@ -1242,8 +1235,8 @@ static int __init ep_config_from_table(struct musb *musb)
printk(KERN_DEBUG %s: %d/%d max ep, %d/%d memory\n,
musb_driver_name,
- n + 1, MUSB_C_NUM_EPS * 2 - 1
omap24xx is broken in current head
Hi, at least n810 is not booting with current l-o head The problem is in clockdomain.c:omap2_clkdm_clk_enable/disable() functions. Well, just for keep hacking I returned on top of the function and it's ok so far :-p Below is the Unhandled fault exception from console. 5Kernel command line: root=1f03 rootfstype=jffs2 6Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz 1Unhandled fault: alignment exception (0x001) at 0xc02c1b4e Internal error: : 1 [#1] Modules linked in: CPU: 0Not tainted (2.6.26-omap1 #10) PC is at omap2_clkdm_clk_enable+0x2c/0x74 LR is at omap2_clk_enable+0x54/0x9c pc : [c00348e0]lr : [c0033118]psr: a1d3 sp : c0307e90 ip : c0307ea8 fp : c0307ea4 r10: 800242c0 r9 : 4107b362 r8 : 0013 r7 : c032b4c4 r6 : 0002 r5 : r4 : c02c1b42 r3 : c02c1b4e r2 : r1 : c030b5d4 r0 : c02c1b42 Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 00c5387f Table: 80004000 DAC: 0017 Process swapper (pid: 0, stack limit = 0xc0306260) Stack: (0xc0307e90 to 0xc0308000) 7e80: c030b5d4 c030b030 c0307ebc c0307ea8 7ea0: c0033118 c00348c0 c030b088 c030b030 c0307ed4 c0307ec0 c00330fc c00330d0 7ec0: c030b500 c030b030 c0307eec c0307ed8 c00330fc c00330d0 c030b6fc c030b030 7ee0: c0307f04 c0307ef0 c00330fc c00330d0 c030c09c c030b030 c0307f1c c0307f08 7f00: c00330fc c00330d0 c030dccc c030b030 c0307f34 c0307f20 c00330fc c00330d0 7f20: 81d3 c030b030 c0307f4c c0307f38 c0043260 c00330d0 c030dccc c030b030 7f40: c0307f64 c0307f50 c0043340 c004322c 0292 c030b030 c0307f94 c0307f68 7f60: c00114d0 c0043320 0149 c0309ce0 c0307f94 c032a8c0 c0025f24 7f80: c0309ce0 8002435c c0307fac c0307f98 c00107e4 c001130c c0025f28 c032a8c0 7fa0: c0307fbc c0307fb0 c0011b70 c00107c8 c0307fcc c0307fc0 c000e438 c0011b68 7fc0: c0307ff4 c0307fd0 c0008c18 c000e40c c0008568 c0025f28 7fe0: 00c5387d c032b24c c0307ff8 80008034 c0008ad4 Backtrace: [c00348b4] (omap2_clkdm_clk_enable+0x0/0x74) from [c0033118] (omap2_clk_enable+0x54/0x9c) r5:c030b030 r4:c030b5d4 [c00330c4] (omap2_clk_enable+0x0/0x9c) from [c00330fc] (omap2_clk_enable+0x38/0x9c) r5:c030b030 r4:c030b088 [c00330c4] (omap2_clk_enable+0x0/0x9c) from [c00330fc] (omap2_clk_enable+0x38/0x9c) r5:c030b030 r4:c030b500 [c00330c4] (omap2_clk_enable+0x0/0x9c) from [c00330fc] (omap2_clk_enable+0x38/0x9c) r5:c030b030 r4:c030b6fc [c00330c4] (omap2_clk_enable+0x0/0x9c) from [c00330fc] (omap2_clk_enable+0x38/0x9c) r5:c030b030 r4:c030c09c [c00330c4] (omap2_clk_enable+0x0/0x9c) from [c00330fc] (omap2_clk_enable+0x38/0x9c) r5:c030b030 r4:c030dccc [c00330c4] (omap2_clk_enable+0x0/0x9c) from [c0043260] (clk_enable+0x40/0x54) r5:c030b030 r4:81d3 [c0043220] (clk_enable+0x0/0x54) from [c0043340] (clk_enable_init_clocks+0x2c/0x4c) r5:c030b030 r4:c030dccc [c0043314] (clk_enable_init_clocks+0x0/0x4c) from [c00114d0] (omap2_clk_init+0x1d0/0x23c) r5:c030b030 r4:0292 [c0011300] (omap2_clk_init+0x0/0x23c) from [c00107e4] (omap2_init_common_hw+0x28/0x40) r8:8002435c r7:c0309ce0 r6:c0025f24 r5:c032a8c0 r4: [c00107bc] (omap2_init_common_hw+0x0/0x40) from [c0011b70] (nokia_n800_init_irq+0x14/0x5c) r5:c032a8c0 r4:c0025f28 [c0011b5c] (nokia_n800_init_irq+0x0/0x5c) from [c000e438] (init_IRQ+0x38/0x48) [c000e400] (init_IRQ+0x0/0x48) from [c0008c18] (start_kernel+0x150/0x2a8) [c0008ac8] (start_kernel+0x0/0x2a8) from [80008034] (0x80008034) r5:c032b24c r4:00c5387d Code: 03a05001 03e00015 089da830 e284300c (e1931f9f) 4---[ end trace 1b75b31a2719ed1c ]--- I'm gonna try to get more info on this later -- 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] usb: musb: get rid of MUSB_LOGLEVEL and use parameter
On Sun, Aug 10, 2008 at 10:53:19AM -0700, Greg KH wrote: On Sun, Aug 10, 2008 at 03:20:46PM +0300, Felipe Balbi wrote: From: Felipe Balbi [EMAIL PROTECTED] We can change debugging level on the fly via /sys/module/musb_hdrc/parameters/debug, there's no need for an extra command in the proc entry. Why are there any proc files in this driver? Drivers should not add proc files. Hm, should have reviewed this code a bit better, sorry... We needed a quick way to export the testmodes to userland. And it's been used for that. Can you please just remove them all? Yeah, I'm moving them to debugfs. I can remove everything and later add only the debugfs if you like. -- 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: Git tree updated to v2.6.27-rc2, help needed
On Tue, Aug 12, 2008 at 05:31:20PM +0300, Tony Lindgren wrote: For me reverting 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 fixes this. Reverting 718fc6cd4db902aa2242a736cc3feb8744a4c71a like Felipe mentioned does not help for me with gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126). But still quite weird that it only happens on 24xx. I gcc attributes to force alignment and make that union transparent, and nothing seems to help. Any thoughts from you guys ?? -- 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 0/3] my pending patches
Hi tony, following are my three pending patches since last merge. At least patch #2 for musb should be applied before next merge with mainline. Another version of that patch (without board-file changes) is already in Greg's queue and without this version of that patch in l-o, musb will be broken. It's also a good idea to apply this before you format omap2/3 patches to mainline since I'm getting rid of hdrc_conf.h file, so we don't polute mailine with an extra unused file. ps: I'm on vacations until next week and I don't have devices with me to test them on. The patches were working last time I tried, but after merge I only rebased them and made sure they build. So, please, give it a try before applying. Felipe Balbi (3): input: keypad: General fixes to omap-twl4030keypad.c usb: musb: pass configuration specifics via pdata input: add more error checks to lm8323 driver arch/arm/mach-omap2/board-2430sdp.c |5 +- arch/arm/mach-omap2/board-3430sdp.c |5 +- arch/arm/mach-omap2/board-n800-usb.c| 46 ++- arch/arm/mach-omap2/usb-musb.c | 51 +++- arch/arm/mach-omap2/usb-tusb6010.c |1 - drivers/input/keyboard/lm8323.c | 42 -- drivers/input/keyboard/omap-twl4030keypad.c | 204 --- drivers/usb/musb/musb_core.c| 37 ++--- drivers/usb/musb/musb_core.h| 14 +-- drivers/usb/musb/tusb6010.h | 169 -- include/asm-arm/arch-omap/hdrc_cnf.h| 177 --- include/asm-arm/arch-omap/keypad.h |1 + include/linux/usb/musb.h| 38 +- 13 files changed, 305 insertions(+), 485 deletions(-) delete mode 100644 include/asm-arm/arch-omap/hdrc_cnf.h -- 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] input: keypad: General fixes to omap-twl4030keypad.c
The following patch fixes some problems in T2 keypad
driver.
Basically we're passing irq number via platform_data,
moving globals to a structure and fixing a problem
while iterating over the keymap.
It might be that we still have a few locking issues
that might be solved on a later version of this same
patch.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-2430sdp.c |5 +-
arch/arm/mach-omap2/board-3430sdp.c |5 +-
drivers/input/keyboard/omap-twl4030keypad.c | 204 ---
include/asm-arm/arch-omap/keypad.h |1 +
4 files changed, 129 insertions(+), 86 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index b2f8b9c..3270ea6 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -176,9 +176,10 @@ static int sdp2430_keymap[] = {
static struct omap_kp_platform_data sdp2430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp2430_keymap,
- .keymapsize = ARRAY_SIZE(sdp2430_keymap),
+ .keymap = sdp2430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp2430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp2430_kp_device = {
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index ee4ec18..94ad839 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -113,9 +113,10 @@ static int sdp3430_keymap[] = {
static struct omap_kp_platform_data sdp3430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp3430_keymap,
- .keymapsize = ARRAY_SIZE(sdp3430_keymap),
+ .keymap = sdp3430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp3430_keymap),
.rep= 1,
+ .irq= TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp3430_kp_device = {
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 68c5b8e..05c7cf8 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -31,6 +31,7 @@
#include linux/types.h
#include linux/input.h
#include linux/kernel.h
+#include linux/mutex.h
#include linux/delay.h
#include linux/bitops.h
#include linux/platform_device.h
@@ -47,52 +48,65 @@
#define KEYNUM_MASK0x00FF
/* Global variables */
-static int *keymap;
-static u16 kp_state[MAX_ROWS];
-static int n_rows, n_cols;
-static struct device *dbg_dev;
-static struct input_dev *omap_twl4030kp;
+struct omap_keypad {
+ int *keymap;
+ unsigned intkeymapsize;
+ u16 kp_state[MAX_ROWS];
+ int n_rows;
+ int n_cols;
+ int irq;
-static int twl4030_kpread(u32 module, u8 *data, u32 reg, u8 num_bytes)
+ struct device *dbg_dev;
+ struct input_dev *omap_twl4030kp;
+
+ /* sync read/write */
+ struct mutexmutex;
+};
+
+static int twl4030_kpread(struct omap_keypad *kp,
+ u32 module, u8 *data, u32 reg, u8 num_bytes)
{
int ret;
ret = twl4030_i2c_read(module, data, reg, num_bytes);
if (ret 0) {
- dev_warn(dbg_dev, Couldn't read TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Couldn't read TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int twl4030_kpwrite_u8(u32 module, u8 data, u32 reg)
+static int twl4030_kpwrite_u8(struct omap_keypad *kp,
+ u32 module, u8 data, u32 reg)
{
int ret;
ret = twl4030_i2c_write_u8(module, data, reg);
if (ret 0) {
- dev_warn(dbg_dev, Could not write TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Could not write TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int omap_kp_find_key(int col, int row)
+static int omap_kp_find_key(struct omap_keypad *kp, int col, int row)
{
int i, rc;
rc = KEY(col, row, 0);
- for (i = 0; keymap[i] != 0; i++)
- if ((keymap[i] ROWCOL_MASK) == rc)
- return keymap[i] KEYNUM_MASK;
+ for (i = 0; i kp-keymapsize; i++)
+ if ((kp-keymap[i] ROWCOL_MASK) == rc)
+ return kp-keymap[i] KEYNUM_MASK;
return -EINVAL;
}
-static inline u16 omap_kp_col_xlate(u8 col)
+static inline u16 omap_kp_col_xlate(struct omap_keypad *kp, u8 col)
{
/* If all bits in a row are active for all coloumns then
* we have that row line connected to gnd. Mark this
@@ -100,30
[PATCH 2/3] usb: musb: pass configuration specifics via pdata
Use platform_data to pass musb configuration-specific
details to musb driver.
It's easier to maintain in the sense that neither board
will affect the other
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-n800-usb.c | 46 +-
arch/arm/mach-omap2/usb-musb.c | 51 +-
arch/arm/mach-omap2/usb-tusb6010.c |1 -
drivers/usb/musb/musb_core.c | 37 +++
drivers/usb/musb/musb_core.h | 14 +---
drivers/usb/musb/tusb6010.h | 169
include/asm-arm/arch-omap/hdrc_cnf.h | 177 --
include/linux/usb/musb.h | 38 +++-
8 files changed, 144 insertions(+), 389 deletions(-)
delete mode 100644 include/asm-arm/arch-omap/hdrc_cnf.h
diff --git a/arch/arm/mach-omap2/board-n800-usb.c
b/arch/arm/mach-omap2/board-n800-usb.c
index 7599f64..16ea8fc 100644
--- a/arch/arm/mach-omap2/board-n800-usb.c
+++ b/arch/arm/mach-omap2/board-n800-usb.c
@@ -35,14 +35,58 @@ static int tusb_set_clock(struct clk *osc_ck, int state);
# define BOARD_MODE MUSB_HOST
#endif
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { ep1_tx, 5,},
+ { ep1_rx, 5,},
+ { ep2_tx, 5,},
+ { ep2_rx, 5,},
+ { ep3_tx, 3,},
+ { ep3_rx, 3,},
+ { ep4_tx, 3,},
+ { ep4_rx, 3,},
+ { ep5_tx, 2,},
+ { ep5_rx, 2,},
+ { ep6_tx, 2,},
+ { ep6_rx, 2,},
+ { ep7_tx, 2,},
+ { ep7_rx, 2,},
+ { ep8_tx, 2,},
+ { ep8_rx, 2,},
+ { ep9_tx, 2,},
+ { ep9_rx, 2,},
+ { ep10_tx, 2, },
+ { ep10_rx, 2, },
+ { ep11_tx, 2, },
+ { ep11_rx, 2, },
+ { ep12_tx, 2, },
+ { ep12_rx, 2, },
+ { ep13_tx, 2, },
+ { ep13_rx, 2, },
+ { ep14_tx, 2, },
+ { ep14_rx, 2, },
+ { ep15_tx, 2, },
+ { ep15_rx, 2, },
+};
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .soft_con = 1,
+ .dma= 1,
+ .num_eps= 32,
+ .dma_channels = 7,
+ .ram_bits = 12,
+ .eps_bits = musb_eps,
+};
+
static struct musb_hdrc_platform_data tusb_data = {
.mode = BOARD_MODE,
- .multipoint = 1,
.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,
};
/*
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index cbd59f8..842edb3 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -37,7 +37,7 @@ static struct resource musb_resources[] = {
: OMAP243X_HS_BASE,
.end= cpu_is_omap34xx()
? OMAP34XX_HSUSB_OTG_BASE + SZ_8K - 1
- : OMAP243X_HS_BASE + SZ_8K -1,
+ : OMAP243X_HS_BASE + SZ_8K - 1,
.flags = IORESOURCE_MEM,
},
[1] = { /* general IRQ */
@@ -73,6 +73,51 @@ static int musb_set_clock(struct clk *clk, int state)
return 0;
}
+static struct musb_hdrc_eps_bits musb_eps[] = {
+ { ep1_tx, 10, },
+ { ep1_rx, 10, },
+ { ep2_tx, 9,},
+ { ep2_rx, 9,},
+ { ep3_tx, 3,},
+ { ep3_rx, 3,},
+ { ep4_tx, 3,},
+ { ep4_rx, 3,},
+ { ep5_tx, 3,},
+ { ep5_rx, 3,},
+ { ep6_tx, 3,},
+ { ep6_rx, 3,},
+ { ep7_tx, 3,},
+ { ep7_rx, 3,},
+ { ep8_tx, 2,},
+ { ep8_rx, 2,},
+ { ep9_tx, 2,},
+ { ep9_rx, 2,},
+ { ep10_tx, 2, },
+ { ep10_rx, 2, },
+ { ep11_tx, 2, },
+ { ep11_rx, 2, },
+ { ep12_tx, 2, },
+ { ep12_rx, 2, },
+ { ep13_tx, 2, },
+ { ep13_rx, 2, },
+ { ep14_tx, 2, },
+ { ep14_rx, 2, },
+ { ep15_tx, 2, },
+ { ep15_rx, 2, },
+};
+
+static struct musb_hdrc_config musb_config = {
+ .multipoint = 1,
+ .dyn_fifo = 1,
+ .soft_con = 1,
+ .dma= 1,
+ .num_eps= 32,
+ .dma_channels = 7,
+ .dma_req_chan = (1 0) | (1 1) | (1 2) | (1 3),
+ .ram_bits = 12,
+ .eps_bits = musb_eps
[PATCH 3/3] input: add more error checks to lm8323 driver
If we can't reach the driver, we stop trying to probe
it. Useful when building kernel for n800 and n810.
n800 doesn't have lm8323, so that driver shouldn't probe
there.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
drivers/input/keyboard/lm8323.c | 42 +-
1 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 72bb587..3d10a0f 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -348,10 +348,10 @@ static void lm8323_process_error(struct lm8323_chip *lm)
}
}
-static void lm8323_reset(struct lm8323_chip *lm)
+static int lm8323_reset(struct lm8323_chip *lm)
{
/* The docs say we must pass 0xAA as the data byte. */
- lm8323_write(lm, 2, LM8323_CMD_RESET, 0xAA);
+ return lm8323_write(lm, 2, LM8323_CMD_RESET, 0xAA);
}
static int lm8323_configure(struct lm8323_chip *lm)
@@ -360,6 +360,7 @@ static int lm8323_configure(struct lm8323_chip *lm)
int clock = (CLK_SLOWCLKEN | CLK_RCPWM_EXTERNAL);
int debounce = lm-debounce_time 2;
int active = lm-active_time 2;
+ int ret;
/*
* Active time must be greater than the debounce time: if it's
@@ -368,13 +369,25 @@ static int lm8323_configure(struct lm8323_chip *lm)
if (debounce = active)
active = debounce + 3;
- lm8323_write(lm, 2, LM8323_CMD_WRITE_CFG, 0);
- lm8323_write(lm, 2, LM8323_CMD_WRITE_CLOCK, clock);
- lm8323_write(lm, 2, LM8323_CMD_SET_KEY_SIZE, keysize);
+ ret = lm8323_write(lm, 2, LM8323_CMD_WRITE_CFG, 0);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 2, LM8323_CMD_WRITE_CLOCK, clock);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 2, LM8323_CMD_SET_KEY_SIZE, keysize);
+ if (ret)
+ goto err;
lm8323_set_active_time(lm, lm-active_time);
- lm8323_write(lm, 2, LM8323_CMD_SET_DEBOUNCE, debounce);
- lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_STATE, 0xff, 0xff);
- lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_SEL, 0, 0);
+ ret = lm8323_write(lm, 2, LM8323_CMD_SET_DEBOUNCE, debounce);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_STATE, 0xff, 0xff);
+ if (ret)
+ goto err;
+ ret = lm8323_write(lm, 3, LM8323_CMD_WRITE_PORT_SEL, 0, 0);
+ if (ret)
+ goto err;
/*
* Not much we can do about errors at this point, so just hope
@@ -382,6 +395,11 @@ static int lm8323_configure(struct lm8323_chip *lm)
*/
return 0;
+
+err:
+ dev_err(lm-client-dev, failed to configure lm8323\n);
+
+ return ret;
}
/*
@@ -721,7 +739,9 @@ static int lm8323_probe(struct i2c_client *client,
else if (lm-active_time == -1) /* Disable sleep. */
lm-active_time = 0;
- lm8323_reset(lm);
+ err = lm8323_reset(lm);
+ if (err)
+ goto fail2;
/* Nothing's set up to service the IRQ yet, so just spin for max.
* 100ms until we can configure. */
@@ -738,7 +758,9 @@ static int lm8323_probe(struct i2c_client *client,
msleep(1);
}
- lm8323_configure(lm);
+ err = lm8323_configure(lm);
+ if (err)
+ goto fail2;
/* If a true probe check the device */
if (lm8323_read_id(lm, data) != 0) {
--
1.6.0.rc1.71.gfba5
--
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: Git tree updated to v2.6.26-rc3, all header files moved
On Thu, Aug 14, 2008 at 04:35:41PM +0300, Tony Lindgren wrote:
Thanks, pushing to l-o. Your twl patch also needs to be updated
for the include path.
Here it is
thanks
--
balbi
From bc91d54477fef30befd382a538526b8a963aee8d Mon Sep 17 00:00:00 2001
From: Felipe Balbi [EMAIL PROTECTED]
Date: Thu, 14 Aug 2008 17:06:00 +0300
Subject: [PATCH] input: keypad: General fixes to omap-twl4030keypad.c
The following patch fixes some problems in T2 keypad
driver.
Basically we're passing irq number via platform_data,
moving globals to a structure and fixing a problem
while iterating over the keymap.
It might be that we still have a few locking issues
that might be solved on a later version of this same
patch.
Signed-off-by: Felipe Balbi [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-2430sdp.c |5 +-
arch/arm/mach-omap2/board-3430sdp.c |5 +-
arch/arm/plat-omap/include/mach/keypad.h|1 +
drivers/input/keyboard/omap-twl4030keypad.c | 204 ---
4 files changed, 129 insertions(+), 86 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c
index cb38fc2..64e76e8 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -176,9 +176,10 @@ static int sdp2430_keymap[] = {
static struct omap_kp_platform_data sdp2430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp2430_keymap,
- .keymapsize = ARRAY_SIZE(sdp2430_keymap),
+ .keymap = sdp2430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp2430_keymap),
.rep = 1,
+ .irq = TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp2430_kp_device = {
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 637f1c8..d27158e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -113,9 +113,10 @@ static int sdp3430_keymap[] = {
static struct omap_kp_platform_data sdp3430_kp_data = {
.rows = 5,
.cols = 6,
- .keymap = sdp3430_keymap,
- .keymapsize = ARRAY_SIZE(sdp3430_keymap),
+ .keymap = sdp3430_keymap,
+ .keymapsize = ARRAY_SIZE(sdp3430_keymap),
.rep = 1,
+ .irq = TWL4030_MODIRQ_KEYPAD,
};
static struct platform_device sdp3430_kp_device = {
diff --git a/arch/arm/plat-omap/include/mach/keypad.h b/arch/arm/plat-omap/include/mach/keypad.h
index 232923a..ba1c95c 100644
--- a/arch/arm/plat-omap/include/mach/keypad.h
+++ b/arch/arm/plat-omap/include/mach/keypad.h
@@ -14,6 +14,7 @@ struct omap_kp_platform_data {
int rows;
int cols;
int *keymap;
+ int irq;
unsigned int keymapsize;
unsigned int rep:1;
unsigned long delay;
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c b/drivers/input/keyboard/omap-twl4030keypad.c
index 5dbb80f..3893d63 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -31,6 +31,7 @@
#include linux/types.h
#include linux/input.h
#include linux/kernel.h
+#include linux/mutex.h
#include linux/delay.h
#include linux/bitops.h
#include linux/platform_device.h
@@ -47,52 +48,65 @@
#define KEYNUM_MASK 0x00FF
/* Global variables */
-static int *keymap;
-static u16 kp_state[MAX_ROWS];
-static int n_rows, n_cols;
-static struct device *dbg_dev;
-static struct input_dev *omap_twl4030kp;
+struct omap_keypad {
+ int *keymap;
+ unsigned int keymapsize;
+ u16 kp_state[MAX_ROWS];
+ int n_rows;
+ int n_cols;
+ int irq;
-static int twl4030_kpread(u32 module, u8 *data, u32 reg, u8 num_bytes)
+ struct device *dbg_dev;
+ struct input_dev *omap_twl4030kp;
+
+ /* sync read/write */
+ struct mutex mutex;
+};
+
+static int twl4030_kpread(struct omap_keypad *kp,
+ u32 module, u8 *data, u32 reg, u8 num_bytes)
{
int ret;
ret = twl4030_i2c_read(module, data, reg, num_bytes);
if (ret 0) {
- dev_warn(dbg_dev, Couldn't read TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Couldn't read TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int twl4030_kpwrite_u8(u32 module, u8 data, u32 reg)
+static int twl4030_kpwrite_u8(struct omap_keypad *kp,
+ u32 module, u8 data, u32 reg)
{
int ret;
ret = twl4030_i2c_write_u8(module, data, reg);
if (ret 0) {
- dev_warn(dbg_dev, Could not write TWL4030: %X - ret %d[%x]\n,
+ dev_warn(kp-dbg_dev,
+ Could not write TWL4030: %X - ret %d[%x]\n,
reg, ret, ret);
return ret;
}
return ret;
}
-static int omap_kp_find_key(int col, int row)
+static int omap_kp_find_key(struct omap_keypad *kp, int col, int row)
{
int i, rc;
rc = KEY(col, row, 0);
- for (i = 0; keymap[i] != 0; i++)
- if ((keymap[i] ROWCOL_MASK) == rc)
- return keymap[i] KEYNUM_MASK;
+ for (i = 0; i kp-keymapsize; i++)
+ if ((kp-keymap[i] ROWCOL_MASK) == rc)
+ return kp-keymap[i] KEYNUM_MASK;
return -EINVAL;
}
-static inline u16 omap_kp_col_xlate(u8 col)
+static inline u16 omap_kp_col_xlate(struct omap_keypad *kp, u8 col)
{
/* If all bits in a row are active
