From nsekhar at ti.com Tue Jun 1 00:38:37 2010 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 1 Jun 2010 11:08:37 +0530 Subject: [PATCH 3/4] davinci: Allow the OSD framebuffers to be disabled on the kernel command line. In-Reply-To: <1274187385-10969-3-git-send-email-gilles.chanteperdrix@nexvision.fr> References: <4BF28E20.3070701@nexvision.fr> <1274187385-10969-1-git-send-email-gilles.chanteperdrix@nexvision.fr> <1274187385-10969-2-git-send-email-gilles.chanteperdrix@nexvision.fr> <1274187385-10969-3-git-send-email-gilles.chanteperdrix@nexvision.fr> Message-ID: Hi Gilles, On Tue, May 18, 2010 at 18:26:24, Gilles Chanteperdrix wrote: > Signed-off-by: Gilles Chanteperdrix You can always disable osd windows by passing osd0=0:osd1=0 in the commandline. I guess this patch tries to prevent the framebuffers from even getting registered. I wonder why you hit a need for that? Thanks, Sekhar From thomas.koeller at baslerweb.com Tue Jun 1 04:05:12 2010 From: thomas.koeller at baslerweb.com (thomas.koeller at baslerweb.com) Date: Tue, 1 Jun 2010 11:05:12 +0200 Subject: [PATCH] DM365: fixed second serial port In-Reply-To: References: Message-ID: <1275383112-6258-1-git-send-email-thomas.koeller@baslerweb.com> From: Thomas Koeller The register base address for the second serial port (UART1) was wrong. Patch is against 'arago' tree. Signed-off-by: Thomas Koeller --- arch/arm/mach-davinci/dm365.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 5645b4a..ffcf0c8 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -44,6 +44,9 @@ #define DM365_REF_FREQ 24000000 /* 24 MHz on the DM365 EVM */ +#undef DAVINCI_UART1_BASE /* Value in serial.h is wrong for DM365 */ +#define DAVINCI_UART1_BASE (IO_PHYS + 0x106000) + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, -- 1.7.1 From thomas.koeller at baslerweb.com Tue Jun 1 04:06:43 2010 From: thomas.koeller at baslerweb.com (thomas.koeller at baslerweb.com) Date: Tue, 1 Jun 2010 11:06:43 +0200 Subject: [PATCH] DM365: fixed second serial port In-Reply-To: References: Message-ID: <1275383203-6381-1-git-send-email-thomas.koeller@baslerweb.com> From: Thomas Koeller The register base address for the second serial port (UART1) was wrong. Patch is against Kevin's tree. Signed-off-by: Thomas Koeller --- arch/arm/mach-davinci/dm365.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index a146849..5b66441 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -41,6 +41,9 @@ #define DM365_REF_FREQ 24000000 /* 24 MHz on the DM365 EVM */ +#undef DAVINCI_UART1_BASE /* Value in serial.h is wrong for DM365 */ +#define DAVINCI_UART1_BASE (IO_PHYS + 0x106000) + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, -- 1.7.1 From gilles.chanteperdrix at nexvision.fr Tue Jun 1 04:11:29 2010 From: gilles.chanteperdrix at nexvision.fr (Gilles Chanteperdrix) Date: Tue, 01 Jun 2010 11:11:29 +0200 Subject: [PATCH 3/4] davinci: Allow the OSD framebuffers to be disabled on the kernel command line. In-Reply-To: References: <4BF28E20.3070701@nexvision.fr> <1274187385-10969-1-git-send-email-gilles.chanteperdrix@nexvision.fr> <1274187385-10969-2-git-send-email-gilles.chanteperdrix@nexvision.fr> <1274187385-10969-3-git-send-email-gilles.chanteperdrix@nexvision.fr> Message-ID: <4C04CEC1.2000204@nexvision.fr> Nori, Sekhar wrote: > Hi Gilles, > > On Tue, May 18, 2010 at 18:26:24, Gilles Chanteperdrix wrote: >> Signed-off-by: Gilles Chanteperdrix > > You can always disable osd windows by passing osd0=0:osd1=0 in the > commandline. I guess this patch tries to prevent the framebuffers from > even getting registered. I wonder why you hit a need for that? In the documentation I read, I did not notice that I could disable the osds this way. But anyway, I find it more orthogonal to use osdx=off to disable osd, since the way to disable video windows is to use vidx=off. -- Gilles. From raghu_ramaraj at mindtree.com Tue Jun 1 06:12:25 2010 From: raghu_ramaraj at mindtree.com (Raghu Ramaraj) Date: Tue, 1 Jun 2010 16:42:25 +0530 Subject: ARM9-PCI-WLAN Card In-Reply-To: References: Message-ID: Hi Swami, Could you please give me the details? Which WLAN-USB tested with Dm6467T? We are having already " WUSB54G V4 ". But I am unable to cross compile the source code which is downloaded from net. Thanks & Regards, Raghu Ramaraj ________________________________ From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] Sent: Thursday, May 27, 2010 10:51 AM To: Raghu Ramaraj; davinci-linux-open-source at linux.davincidsp.com Subject: RE: ARM9-PCI-WLAN Card Raghu, Any commercially available usbwifi card that has Linux drivers would work just fine on DM6467T. Regards swami ________________________________ From: Raghu Ramaraj [mailto:raghu_ramaraj at mindtree.com] Sent: Thursday, May 27, 2010 9:49 AM To: Subbrathnam, Swaminathan; davinci-linux-open-source at linux.davincidsp.com Subject: RE: ARM9-PCI-WLAN Card Hi Swami, Have you tested any USB-WLAN Card with DM6467T? Could please give us the details of the Card & data rate of the card? Thanks & Regards, Raghu Ramaraj ________________________________ From: Subbrathnam, Swaminathan [mailto:swami.iyer at ti.com] Sent: Tuesday, May 25, 2010 6:02 PM To: Raghu Ramaraj; davinci-linux-open-source at linux.davincidsp.com Subject: RE: ARM9-PCI-WLAN Card Raghu, Can you not consider over USB? It is much simpler as compared to PCI. Regards swami ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Raghu Ramaraj Sent: Tuesday, May 25, 2010 5:57 PM To: davinci-linux-open-source at linux.davincidsp.com Subject: ARM9-PCI-WLAN Card Hi, We are trying to bring out Athoers WLAN card with DM6467T and we are facing some communication issue between host & device. Has anybody tested any TI Platform (ARM9) with any PCI based WLAN card? Thanks & Regards, Raghu Ramaraj ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jon.Povey at racelogic.co.uk Tue Jun 1 07:07:49 2010 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Tue, 1 Jun 2010 13:07:49 +0100 Subject: The state of MUSB OTG + CPPI DMA..? In-Reply-To: <4BFFC9D6.5040803@mvista.com> Message-ID: <70E876B0EA86DD4BAF101844BC814DFE08E055CB52@Cloud.RL.local> Hi Sergei, I am reading up on the OTG state machine, also on my board I have USB ID wired to a GPIO so may be able to hack in an interrupt to help me out if I have to. Meanwhile though here is what I have found; thanks for any clues: Sergei Shtylyov wrote: > Jon Povey wrote: >> but having some problems with it not finding memory sticks in host >> mode after connecting as a gadget, > > IIRC, that should be cured by adding musb_platfrom_try_idle() to > drivers/usb/musb/davinci.c. I'm not sure why it lacks this function, > while it's been proven that DA830 needs it. You can try copying the > code from omap2430.c (you'll also have to modify the #ifdef'ery > around the declaration in musb_core.h). My memory may be wrong > though... I had a go at hacking that in, triggering otg_timer() with some extra case statements. I can see it printing things during module shutdown at debug level 4. It hasn't made any difference to my main issues which are: After use in host mode (memory stick detected), swapping cables for use in gadget (serial) mode, does not react to cable connect/disconnect. Gadget mode does work if tried first after module load, and can disconnect/reconnect multiple times (until cables are swapped and a memory stick is used) I have two USB memory sticks here which I will call "good" and "bad". Different models, both work fine on PC, I have no reason to think there is anything wrong with the "bad" stick, but the "bad" stick will only be detected after the "good" stick has successfully been detected, or immediately after driver module load iff the correct cable was connected at module load time. Note the stick doesn't have to be plugged into the cable at module load time, the cable just has to be plugged into the board. After use in gadget mode and swapping cables, the "bad" stick will not be detected until the "good" stick has been. I will paste a couple of console logs at the end of this email. >> and a few weird error messages. > > Like? When I have a memory stick connected and detected, if I remove the cable from the board I get dma warnings: usb 1-1: USB disconnect, address 11 drivers/usb/musb/davinci.c musb_platform_enable: dma not reactivated This doesn't happen if I remove the stick from the cable but leave the cable connected to the board, then remove the cable a few seconds later. The cable connector has the ID pin grounded.. I assume it's something to do with that. I looked at the code generating the dma warnings; it seems to be a flag that's not actually associated with any DMA (dma_off in davinci.c) - seems to be pointless. Also, a possible red herring: I have times when I will get a console screen full of messages like serial8250: too much work for irq14 serial8250: too much work for irq14 ttyS2: 5 input overrun(s) serial8250: too much work for irq14 which seems to be associated with loading and doing things with the musb driver, but only very loosely and intermittently. May be something else entirely. We do have something hooked up to ttyS2 sending lots of data that's probably not configured right yet, so ignore this if it doesn't mean anything to you. Log for gadget -> memory stick ------------------------------ root at H:/# # disconnect gadget root at H:/# davinci_interrupt 362: IRQ 00010000 musb_interrupt 1505: ** IRQ peripheral usb0001 tx0000 rx0000 musb_stage0_irq 380: <== Power=f0, DevCtl=99, int_usb=0x1 musb_stage0_irq 564: SUSPEND (b_peripheral) devctl 99 power f0 musb_g_suspend 1921: devctl 99 root at H:/# # plug in host cable root at H:/# # plug in black stick (no reaction) root at H:/# # swap for blue stick root at H:/# davinci_interrupt 362: IRQ 00200000 musb_interrupt 1505: ** IRQ peripheral usb0020 tx0000 rx0000 musb_stage0_irq 380: <== Power=e0, DevCtl=88, int_usb=0x20 musb_stage0_irq 696: DISCONNECT (b_peripheral) as Peripheral, devctl 88 musb_g_disconnect 1957: devctl 88 nuke 189: ep1out: abort DMA --> 0 musb_gadget_disable 1038: ep1out nuke 189: ep1in: abort DMA --> 0 musb_gadget_disable 1038: ep1in nuke 189: ep2in: abort DMA --> 0 musb_gadget_disable 1038: ep2in otg_timer 216: poll devctl 88 (b_idle) davinci_interrupt 362: IRQ 01000000 davinci_interrupt 423: VBUS on (a_wait_vrise), devctl 19 davinci_interrupt 362: IRQ 00100000 musb_interrupt 1505: ** IRQ host usb0010 tx0000 rx0000 musb_stage0_irq 380: <== Power=e0, DevCtl=5d, int_usb=0x10 musb_stage0_irq 689: CONNECT (a_host) devctl 5d Log for stick -> gadget ----------------------- root at H:/# # remove memory stick root at H:/# davinci_interrupt 362: IRQ 00200000 musb_interrupt 1505: ** IRQ peripheral usb0020 tx0000 rx0000 musb_stage0_irq 380: <== Power=e0, DevCtl=19, int_usb=0x20 musb_stage0_irq 696: DISCONNECT (a_host) as Host, devctl 19 musb_platform_try_idle 328: a_wait_bcon inactive, for idle timer for 1100 ms musb_hub_control 356: port status 00010100 musb_hub_control 290: clear feature 16 usb 1-1: USB disconnect, address 2 musb_hub_control 356: port status 00000100 musb_hub_control 356: port status 00000100 musb_hub_control 356: port status 00000100 musb_hub_control 356: port status 00000100 musb_hub_control 356: port status 00000100 otg_timer 216: poll devctl 19 (a_wait_bcon) davinci_interrupt 362: IRQ 01000000 davinci_interrupt 423: VBUS off (b_idle), devctl 98 otg_timer 216: poll devctl 98 (b_idle) otg_timer 216: poll devctl 99 (b_idle) otg_timer 216: poll devctl 99 (b_idle) # remove host cable otg_timer 216: poll devctl 99 (b_idle) otg_timer 216: poll devctl 91 (b_idle) otg_timer 216: poll devctl 91 (b_idle) otg_timer 216: poll devctl 91 (b_idle) otg_timer 216: poll devctl 91 (b_idle) otg_timer 216: poll devctl 91 (b_idle) # connect gadget cable (to PC) otg_timer 216: poll devctl 91 (b_idle) otg_timer 216: poll devctl 99 (b_idle) otg_timer 216: poll devctl 99 (b_idle) otg_timer 216: poll devctl 99 (b_idle) -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From armstrong0916 at gmail.com Tue Jun 1 21:16:32 2010 From: armstrong0916 at gmail.com (armstrong james) Date: Wed, 2 Jun 2010 10:16:32 +0800 Subject: How to control the contrast saturation of tvp7002 Message-ID: Hello all, I'm using dm6467 and lsp1.3 . In tvp7002.c, I only found the relation code that was used to initialize the brightness of tvp7002. In the encode application, I added some ioctl code and wanted to control the contrast brightness saturation of tvp7002. The code is as below: struct v4l2_control ctrl; if(type == 1) ctrl.id = V4L2_CID_CONTRAST; else if(type == 2) ctrl.id = V4L2_CID_SATURATION; ctrl.value = value; ioctl(hCapture->fd, VIDIOC_S_CTRL, &ctrl); but the return value of ioctl was -1,so the handling was fail. Could you tell me how to control the contrast brightness saturation of tvp7002? thank you. best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsekhar at ti.com Wed Jun 2 01:22:46 2010 From: nsekhar at ti.com (Nori, Sekhar) Date: Wed, 2 Jun 2010 11:52:46 +0530 Subject: [PATCH] DM365: fixed second serial port In-Reply-To: <1275383203-6381-1-git-send-email-thomas.koeller@baslerweb.com> References: <1275383203-6381-1-git-send-email-thomas.koeller@baslerweb.com> Message-ID: Hi Thomas, On Tue, Jun 01, 2010 at 14:36:43, thomas.koeller at baslerweb.com wrote: > From: Thomas Koeller > > The register base address for the second serial port (UART1) was > wrong. > > Patch is against Kevin's tree. Such information (which is not relevant to the fix as such) should go below the --- in the patch. That way, it does not get included in the git logs once the patch is committed. > > Signed-off-by: Thomas Koeller > --- > arch/arm/mach-davinci/dm365.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c > index a146849..5b66441 100644 > --- a/arch/arm/mach-davinci/dm365.c > +++ b/arch/arm/mach-davinci/dm365.c > @@ -41,6 +41,9 @@ > > #define DM365_REF_FREQ 24000000 /* 24 MHz on the DM365 EVM */ > > +#undef DAVINCI_UART1_BASE /* Value in serial.h is wrong for DM365 */ > +#define DAVINCI_UART1_BASE (IO_PHYS + 0x106000) > + May be it is personal taste, but I like this way of fixing it better: diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index a146849..5dded5e 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -1020,6 +1020,8 @@ static struct davinci_timer_info dm365_timer_info = { .clocksource_id = T0_TOP, }; +#define DAVINCI_DM365_UART1_BASE 0x01D06000 + static struct plat_serial8250_port dm365_serial_platform_data[] = { { .mapbase = DAVINCI_UART0_BASE, @@ -1030,7 +1032,7 @@ static struct plat_serial8250_port dm365_serial_platform_data[] = { .regshift = 2, }, { - .mapbase = DAVINCI_UART1_BASE, + .mapbase = DAVINCI_DM365_UART1_BASE, .irq = IRQ_UARTINT1, .flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_IOREMAP, -- Thanks, Sekhar From nsekhar at ti.com Wed Jun 2 01:33:14 2010 From: nsekhar at ti.com (Nori, Sekhar) Date: Wed, 2 Jun 2010 12:03:14 +0530 Subject: [PATCH] DM365: fixed second serial port In-Reply-To: <1275383112-6258-1-git-send-email-thomas.koeller@baslerweb.com> References: <1275383112-6258-1-git-send-email-thomas.koeller@baslerweb.com> Message-ID: Hi Thomas, On Tue, Jun 01, 2010 at 14:35:12, thomas.koeller at baslerweb.com wrote: > From: Thomas Koeller > > The register base address for the second serial port (UART1) was > wrong. > > Patch is against 'arago' tree. No need of submitting patches against arago tree if they are relevant to upstream (Kevin's or other subsystem) trees. Please submit the fixes only against upstream trees in such cases - no need to take the pain of generating patches against two different trees. The arago tree is a TI development tree and it is the responsibility of TI developers to pick up fixes relevant to a particular release from the community and make it a part of the TI release. Once a fix is accepted upstream, it will automatically become part of the arago tree once the next kernel rebase is done. Thanks, Sekhar From brijesh.j at ti.com Wed Jun 2 03:33:50 2010 From: brijesh.j at ti.com (Jadav, Brijesh R) Date: Wed, 2 Jun 2010 14:03:50 +0530 Subject: How to control the contrast saturation of tvp7002 In-Reply-To: References: Message-ID: <19F8576C6E063C45BE387C64729E7394044E6D2D67@dbde02.ent.ti.com> Hi, As far as I remember, TVP7002 does not support any other controls, so driver returns error for contrast/saturation. Thx, Brijesh ________________________________ From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of armstrong james Sent: Wednesday, June 02, 2010 7:47 AM To: davinci-linux-open-source at linux.davincidsp.com Subject: How to control the contrast saturation of tvp7002 Hello all, I'm using dm6467 and lsp1.3 . In tvp7002.c, I only found the relation code that was used to initialize the brightness of tvp7002. In the encode application, I added some ioctl code and wanted to control the contrast brightness saturation of tvp7002. The code is as below: struct v4l2_control ctrl; if(type == 1) ctrl.id = V4L2_CID_CONTRAST; else if(type == 2) ctrl.id = V4L2_CID_SATURATION; ctrl.value = value; ioctl(hCapture->fd, VIDIOC_S_CTRL, &ctrl); but the return value of ioctl was -1,so the handling was fail. Could you tell me how to control the contrast brightness saturation of tvp7002? thank you. best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liuyue18301 at 163.com Wed Jun 2 05:15:36 2010 From: liuyue18301 at 163.com (liuyue18301) Date: Wed, 2 Jun 2010 18:15:36 +0800 (CST) Subject: can i add other type uart Message-ID: hi all: in dm6446 the uart driver is supported by 8250.c now i want to expand five uart serial port by fpga,and the register is different to the exsited,i want to write a new uart driver for the five expand serial port,but i have a question,can i compile the new uart driver to the kernel?the uart device which expanded is different to the exsited,can the kernel support different uart driver at the same time? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pan at nt.tu-darmstadt.de Wed Jun 2 05:22:17 2010 From: pan at nt.tu-darmstadt.de (Vladimir Pantelic) Date: Wed, 02 Jun 2010 12:22:17 +0200 Subject: can i add other type uart In-Reply-To: References: Message-ID: <4C0630D9.3070206@nt.tu-darmstadt.de> liuyue18301 wrote: > > hi all: > in dm6446 the uart driver is supported by 8250.c now i want to expand > five uart serial port by fpga,and the register is different to the > exsited,i want to write a new uart driver for the five expand serial > port,but i have a question,can i compile the new uart driver to the > kernel?the uart device which expanded is different to the exsited,can > the kernel support different uart driver at the same time? yes From sshtylyov at mvista.com Wed Jun 2 05:23:44 2010 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Wed, 02 Jun 2010 14:23:44 +0400 Subject: Kernel oops when unloading musb module in OTG mode In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE08E055CA19@Cloud.RL.local> References: <70E876B0EA86DD4BAF101844BC814DFE08E055CA19@Cloud.RL.local> Message-ID: <4C063130.1010804@mvista.com> Hello. Jon Povey wrote: > In the process of looking into problems with MUSB OTG behaviour here, I tried a rebase to the current master, which has broken module unload of musb_hdrc - it now OOPSes while trying to rmmod (OOPS pasted below). Saw that, though it was really a WARNING in my case. > I reverted two commits in /musb, after reverting the second I could unload musb_hdrc without crash: > #1 34e2beb2c883e0ea1b6135ad6f7713f7574a01aa > #2 461972d8a4c94bc44f11a13046041c78a7cf18dd Yeah, the second one seems to be a culprit. I haven't tested it in OTG mode. [...] > The OOPS: > Unable to handle kernel NULL pointer dereference at virtual address 0000002c > pgd = c7df0000 Strange, I got a WARNING there... > [0000002c] *pgd=87e1b031, *pte=00000000, *ppte=00000000 > Internal error: Oops: 17 [#1] PREEMPT > last sysfs file: /sys/devices/platform/musb_hdrc/usb1/product > Modules linked in: musb_hdrc(-) [last unloaded: g_serial] > CPU: 0 Not tainted (2.6.34-07363-g879b87a #78) > PC is at kobject_put+0x18/0x60 > LR is at put_device+0x1c/0x20 > pc : [] lr : [] psr: 20000013 > sp : c7e0be28 ip : c7e0be48 fp : c7e0be44 > r10: 00000000 r9 : c7e0a000 r8 : c00260a4 > r7 : fec64000 r6 : c030f038 r5 : c7dfd100 r4 : 0000000c > r3 : c7d84360 r2 : c7e0bdf8 r1 : c7db6440 r0 : 0000000c > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 0005317f Table: 87df0000 DAC: 00000015 > Process rmmod (pid: 1019, stack limit = 0xc7e0a270) > Stack: (0xc7e0be28 to 0xc7e0c000) > be20: c7e0be54 c7e0be38 c006a3c0 c7dfd100 c7e0be54 c7e0be48 > be40: c016c91c c012f0ac c7e0be6c c7e0be58 bf000920 c016c910 00000000 c7dfd100 > be60: c7e0be8c c7e0be70 bf0081fc bf0008d0 c030f040 bf00a530 c030f074 bf00a530 > be80: c7e0be9c c7e0be90 c0170f90 bf0081a8 c7e0beb4 c7e0bea0 c016fbe0 c0170f80 > bea0: c030f040 c7e0a000 c7e0bed4 c7e0beb8 c016fce8 c016fb60 bf00a530 bf00a530 > bec0: c0320588 c7e0bf3c c7e0bef4 c7e0bed8 c016ee78 c016fc3c 00000000 bf00a530 > bee0: 00000000 c7e0bf3c c7e0bf14 c7e0bef8 c01702b4 c016edf0 00000000 bf00a5b8 > bf00: 00000880 c7e0bf3c c7e0bf24 c7e0bf18 c01711f4 c017025c c7e0bf34 c7e0bf28 > bf20: bf008190 c01711f0 c7e0bfa4 c7e0bf38 c0066310 bf00818c c0089088 6273756d > bf40: 7264685f c7e00063 c0132cc0 c0032fec 00000000 c7dd7934 00001000 40020000 > bf60: c00260a4 00000000 c7e0bf84 c7e0bf78 c0055934 00132b80 bf00a5b8 00000880 > bf80: c7e0bf84 00000000 00090008 00000000 00098028 00000081 00000000 c7e0bfa8 > bfa0: c0025f20 c006612c 00090008 00000000 00098028 00000880 00098278 00098278 > bfc0: 00090008 00000000 00098028 00000081 00000001 beba8e68 00000000 00000000 > bfe0: 00098278 beba8ac8 00014140 400e96dc 20000010 00098028 e9045000 22540000 > Backtrace: > [] (kobject_put+0x0/0x60) from [] (put_device+0x1c/0x20) > r4:c7dfd100 > [] (put_device+0x0/0x20) from [] (musb_free+0x60/0x70 [musb_hdrc]) I've looked into this and was puzzled by that imbalanced put_device() call in musb_free(), surrounded by OTG #ifdef. Why it is here, and why only for OTG case? What I think should be done instead are the otg_put_transceiver() calls, symmetrical to otg_get_transcaiver() calls in the glue layers. Felipe? > [] (musb_free+0x0/0x70 [musb_hdrc]) from [] (musb_remove+0x64/0x8c [musb_hdrc]) > r5:c7dfd100 r4:00000000 > [] (musb_remove+0x0/0x8c [musb_hdrc]) from [] (platform_drv_remove+0x20/0x24) > r7:bf00a530 r6:c030f074 r5:bf00a530 r4:c030f040 > [] (platform_drv_remove+0x0/0x24) from [] (__device_release_driver+0x90/0xdc) > [] (__device_release_driver+0x0/0xdc) from [] (driver_detach+0xbc/0xe4) > r5:c7e0a000 r4:c030f040 > [] (driver_detach+0x0/0xe4) from [] (bus_remove_driver+0x98/0xc0) > r7:c7e0bf3c r6:c0320588 r5:bf00a530 r4:bf00a530 > [] (bus_remove_driver+0x0/0xc0) from [] (driver_unregister+0x68/0x78) > r7:c7e0bf3c r6:00000000 r5:bf00a530 r4:00000000 > [] (driver_unregister+0x0/0x78) from [] (platform_driver_unregister+0x14/0x18) > r7:c7e0bf3c r6:00000880 r5:bf00a5b8 r4:00000000 > [] (platform_driver_unregister+0x0/0x18) from [] (musb_cleanup+0x14/0x1c [musb_hdrc]) > [] (musb_cleanup+0x0/0x1c [musb_hdrc]) from [] (sys_delete_module+0x1f4/0x268) > [] (sys_delete_module+0x0/0x268) from [] (ret_fast_syscall+0x0/0x2c) > r7:00000081 r6:00098028 r5:00000000 r4:00090008 > Code: e24cb004 e24dd00c e2504000 0a00000b (e5d43020) WBR, Sergei From juha.kuikka at gmail.com Wed Jun 2 19:18:51 2010 From: juha.kuikka at gmail.com (Juha Kuikka) Date: Wed, 2 Jun 2010 17:18:51 -0700 Subject: DA850 and MMCSD1 EDMA In-Reply-To: References: Message-ID: Hi, Sorry about replying to my own email but I only get the digests. On Wed, May 19, 2010 at 5:38 PM, Juha Kuikka wrote: > > I am working with a HW that has an SDIO device on the second > MMC/SD/SDIO controller (mmcsd1). > > I suspect the DMA channel numbers are wrong or for some reason the > second EDMA controller has issues. > Turns out the issue is the EDMA configuration. DA850 has two EDMA controllers. Unfortunately they are not identical, the first instance has two transfer controllers and two event queues but the second instance only has one of each. The static int __init edma_probe(struct platform_device *pdev) -function in dma.c has this code in it: edma_info[j]->default_queue = info[j].default_queue; if (!edma_info[j]->default_queue) edma_info[j]->default_queue = EVENTQ_1; /* Everything lives on transfer controller 1 until otherwise * specified. This way, long transfers on the low priority queue * started by the codec engine will not cause audio defects. */ for (i = 0; i < edma_info[j]->num_channels; i++) map_dmach_queue(j, i, EVENTQ_1); And because the MMC driver allocates channels with EVENTQ_DEFAULT they get put into EVENTQ_1 which the second EDMA controller does not have and hence transfers stall. My proposal for a fix would be something like this: --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -186,6 +186,7 @@ static struct edma_soc_info da850_edma_info[] = { .n_cc = 1, .queue_tc_mapping = da8xx_queue_tc_mapping, .queue_priority_mapping = da8xx_queue_priority_mapping, + .default_queue = EVENTQ_1, }, { .n_channel = 32, @@ -195,6 +196,7 @@ static struct edma_soc_info da850_edma_info[] = { .n_cc = 1, .queue_tc_mapping = da850_queue_tc_mapping, .queue_priority_mapping = da850_queue_priority_mapping, + .default_queue = EVENTQ_0, }, }; --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -1447,8 +1447,6 @@ static int __init edma_probe(struct platform_device *pdev) EDMA_MAX_CC); edma_info[j]->default_queue = info[j].default_queue; - if (!edma_info[j]->default_queue) - edma_info[j]->default_queue = EVENTQ_1; dev_dbg(&pdev->dev, "DMA REG BASE ADDR=%p\n", edmacc_regs_base[j]); @@ -1508,7 +1506,7 @@ static int __init edma_probe(struct platform_device *pdev) * started by the codec engine will not cause audio defects. */ for (i = 0; i < edma_info[j]->num_channels; i++) - map_dmach_queue(j, i, EVENTQ_1); + map_dmach_queue(j, i, edma_info[j]->default_queue); queue_tc_mapping = info[j].queue_tc_mapping; queue_priority_mapping = info[j].queue_priority_mapping; Comments? / Juha From Jon.Povey at racelogic.co.uk Wed Jun 2 19:52:03 2010 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Thu, 3 Jun 2010 01:52:03 +0100 Subject: MUSB: Idea: board-specific OTG ID pin interrupt support Message-ID: <70E876B0EA86DD4BAF101844BC814DFE08E055CE48@Cloud.RL.local> Playing around with MUSB OTG on TI DM355 I am having some trouble getting A-B role switching working. On my board by happy design foresight, USB ID is also wired to a GPIO. I am currently having a go at hacking an ID interrupt into the MUSB driver to prod the state machine. This email is to see if anyone has any comments or suggestions on this approach, and to see if it might be worth cleaning up and abstracting the support through platform data or whatever, and sending some patches so other boards could use this (and you fine people can spot my glaring bugs). Thanks, -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From sudhakar.raj at ti.com Wed Jun 2 23:48:02 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Thu, 3 Jun 2010 10:18:02 +0530 Subject: DA850 and MMCSD1 EDMA In-Reply-To: References: Message-ID: <024301cb02d7$f2cb6030$d8622090$@raj@ti.com> Hi Juha, On Thu, Jun 03, 2010 at 05:48:51, Juha Kuikka wrote: > Hi, > > Sorry about replying to my own email but I only get the digests. > > On Wed, May 19, 2010 at 5:38 PM, Juha Kuikka wrote: > > > > I am working with a HW that has an SDIO device on the second > > MMC/SD/SDIO controller (mmcsd1). > > > > I suspect the DMA channel numbers are wrong or for some reason the > > second EDMA controller has issues. > > > > Turns out the issue is the EDMA configuration. > > DA850 has two EDMA controllers. Unfortunately they are not identical, > the first instance has two transfer controllers and two event queues > but the second instance only has one of each. > > The static int __init edma_probe(struct platform_device *pdev) > -function in dma.c has this code in it: > > edma_info[j]->default_queue = info[j].default_queue; > if (!edma_info[j]->default_queue) > edma_info[j]->default_queue = EVENTQ_1; > > /* Everything lives on transfer controller 1 until otherwise > * specified. This way, long transfers on the low priority queue > * started by the codec engine will not cause audio defects. > */ > for (i = 0; i < edma_info[j]->num_channels; i++) > map_dmach_queue(j, i, EVENTQ_1); > > And because the MMC driver allocates channels with EVENTQ_DEFAULT they > get put into EVENTQ_1 which the second EDMA controller does not have > and hence transfers stall. > You are absolutely correct here. Your patch to fix this issue looks fine to me. Please go ahead and submit it as a patch to the same list. Regards, Sudhakar From raghu_ramaraj at mindtree.com Thu Jun 3 00:22:03 2010 From: raghu_ramaraj at mindtree.com (Raghu Ramaraj) Date: Thu, 3 Jun 2010 10:52:03 +0530 Subject: how to decode h264 video encode by TI\'s H264 Baseline Profile Encoder (dm6446) Message-ID: Hi, I also wanted to know , how to play H264 encoded file in player(like ffmeg, vlc) ? I just tried to play in ffmeg. But I am unable to play it. Is it require any header ? Thanks & Regards, Raghu Ramaraj ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From amraldo at hotmail.com Thu Jun 3 01:35:01 2010 From: amraldo at hotmail.com (amr ali) Date: Thu, 3 Jun 2010 09:35:01 +0300 Subject: Running a Web Browser on DM6446 Message-ID: Hi, I want to run a Web Browser on DM6446. Any head starts? Did anyone manage to run Ubuntu Desktop on any Davinci Boards? -- Amr Ali Abdel-Naby Embedded Systems Developer www.embedded-tips.blogspot.com _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsekhar at ti.com Thu Jun 3 01:40:08 2010 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 3 Jun 2010 12:10:08 +0530 Subject: Running a Web Browser on DM6446 In-Reply-To: References: Message-ID: Hi Amr, On Thu, Jun 03, 2010 at 12:05:01, amr ali wrote: > Hi, > I want to run a Web Browser on DM6446. Any head starts? Filesystem that comes with Arago project usually has thttpd bundled. You can try: http://arago-project.org/files/releases/2009.11/images/dm6446-evm/ > > Did anyone manage to run Ubuntu Desktop on any Davinci Boards? > None that I am aware of. Thanks, Sekhar From huangsw at temobi.com Thu Jun 3 01:46:47 2010 From: huangsw at temobi.com (=?utf-8?B?aHVhbmdzdw==?=) Date: Thu, 3 Jun 2010 14:46:47 +0800 Subject: =?utf-8?B?UmU6IFJ1bm5pbmcgYSBXZWIgQnJvd3NlciBvbiBETTY0NDY=?= References: Message-ID: <201006031446461710644@temobi.com> Why not Andriod, i failed to find the packages for davinci 2010-06-03 huangsw ???? amr ali ????? 2010-06-03 14:37:23 ???? davinci forum ??? ??? Running a Web Browser on DM6446 Hi, I want to run a Web Browser on DM6446. Any head starts? Did anyone manage to run Ubuntu Desktop on any Davinci Boards? -- Amr Ali Abdel-Naby Embedded Systems Developer www.embedded-tips.blogspot.com Hotmail: Free, trusted and rich email service. Get it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amraldo at hotmail.com Thu Jun 3 01:49:09 2010 From: amraldo at hotmail.com (amr ali) Date: Thu, 3 Jun 2010 09:49:09 +0300 Subject: Running a Web Browser on DM6446 In-Reply-To: References: , Message-ID: Thanks for the thttpd hint, but this is a server not a browser :) thttpd -- Amr Ali Abdel-Naby Embedded Systems Developer www.embedded-tips.blogspot.com > From: nsekhar at ti.com > To: amraldo at hotmail.com > CC: davinci-linux-open-source at linux.davincidsp.com > Date: Thu, 3 Jun 2010 12:10:08 +0530 > Subject: RE: Running a Web Browser on DM6446 > > Hi Amr, > > On Thu, Jun 03, 2010 at 12:05:01, amr ali wrote: > > Hi, > > I want to run a Web Browser on DM6446. Any head starts? > > Filesystem that comes with Arago project usually has > thttpd bundled. You can try: > > http://arago-project.org/files/releases/2009.11/images/dm6446-evm/ > > > > > Did anyone manage to run Ubuntu Desktop on any Davinci Boards? > > > > None that I am aware of. > > Thanks, > Sekhar _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969 -------------- next part -------------- An HTML attachment was scrubbed... URL: From amraldo at hotmail.com Thu Jun 3 01:54:17 2010 From: amraldo at hotmail.com (amr ali) Date: Thu, 3 Jun 2010 09:54:17 +0300 Subject: Running a Web Browser on DM6446 In-Reply-To: <201006031446461710644@temobi.com> References: , <201006031446461710644@temobi.com> Message-ID: Can you point me any android files working on DM6446? -- Amr Ali Abdel-Naby Embedded Systems Developer www.embedded-tips.blogspot.com Date: Thu, 3 Jun 2010 14:46:47 +0800 From: huangsw at temobi.com To: amraldo at hotmail.com; davinci-linux-open-source at linux.davincidsp.com Subject: Re: Running a Web Browser on DM6446 Why not Andriod, i failed to find the packages for davinci 2010-06-03 huangsw ???? amr ali ????? 2010-06-03 14:37:23 ???? davinci forum ??? ??? Running a Web Browser on DM6446 Hi, I want to run a Web Browser on DM6446. Any head starts? Did anyone manage to run Ubuntu Desktop on any Davinci Boards? -- Amr Ali Abdel-Naby Embedded Systems Developer www.embedded-tips.blogspot.com Hotmail: Free, trusted and rich email service. Get it now. _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jon.Povey at racelogic.co.uk Thu Jun 3 03:04:48 2010 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Thu, 3 Jun 2010 09:04:48 +0100 Subject: MUSB: Idea: board-specific OTG ID pin interrupt support In-Reply-To: Message-ID: <70E876B0EA86DD4BAF101844BC814DFE08E055CE6F@Cloud.RL.local> jean-philippe francois wrote: > 2010/6/3 Jon Povey : >> jean-philippe francois wrote: >>> I achieved this by monitoring '/sys/devices/platform/musb_hdrc/mode' >>> in user space. >> >> We did similar using hotplug events on 2.6.10 for both mmc and usb >> storage. >> > But there is no hotplug event in gadget mode . No. We worked around that ;) >> It's a portable video recorder which you can plug a USB stick into >> to record. You can also (swap cables and) plug into a PC, when it >> goes into gadget serial mode to communicate with our setup software. >> >> We did this on 2.6.10 by having two sets of USB modules build in >> Host and Peripheral mode, and our own driver monitor the ID pin and >> unload/reload modules. It worked, but OTG would be cleaner, faster >> to switch and not needing of nasty build time hacks. > > So all the ID pin sensing is in addition to the DM OTG machinery, or > is it a replacement for a malfunctionning > OTG mode, where you kind of "manually" switch from one role to > another ? It was the latter. I am planning / working on integrating it into the OTG machinery. -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From nsekhar at ti.com Thu Jun 3 03:23:39 2010 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 3 Jun 2010 13:53:39 +0530 Subject: Running a Web Browser on DM6446 In-Reply-To: References: , Message-ID: Hi Amr, On Thu, Jun 03, 2010 at 12:19:09, amr ali wrote: > Thanks for the thttpd hint, but this is a server not a browser :) > Right! Didn?t read the question correctly. No idea about browser :( Thanks, Sekhar From amraldo at hotmail.com Thu Jun 3 03:28:01 2010 From: amraldo at hotmail.com (amr ali) Date: Thu, 3 Jun 2010 11:28:01 +0300 Subject: Running a Web Browser on DM6446 In-Reply-To: References: , , , Message-ID: I am trying with this right now: http://www.webkitgtk.org/?page=download. I already have a GTK in my file system and most webkit's dependencies. Will feedback if I succeed in doing that. -- Amr Ali Abdel-Naby Embedded Systems Developer www.embedded-tips.blogspot.com > From: nsekhar at ti.com > To: amraldo at hotmail.com > CC: davinci-linux-open-source at linux.davincidsp.com > Date: Thu, 3 Jun 2010 13:53:39 +0530 > Subject: RE: Running a Web Browser on DM6446 > > Hi Amr, > > On Thu, Jun 03, 2010 at 12:19:09, amr ali wrote: > > Thanks for the thttpd hint, but this is a server not a browser :) > > > > Right! Didn?t read the question correctly. No idea about browser :( > > Thanks, > Sekhar _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969 -------------- next part -------------- An HTML attachment was scrubbed... URL: From krunal.patil at einfochips.com Thu Jun 3 03:37:17 2010 From: krunal.patil at einfochips.com (Krunal Patil) Date: Thu, 03 Jun 2010 14:07:17 +0530 Subject: DM365 UBL binary size differs. Message-ID: <4C0769BD.8020007@einfochips.com> Hi, I am in process or board bring up of DM365 based customize hardware. I am using PSP_02_10_00_14.tgz which comes with DVSDK_2.10. I compiled the *original *UBL source code provided in PSP package (PSP_02_10_00_14/board_utilities/flash_utils/DM36x/GNU/ubl/). After compilation the binary size for "ubl_DM36x_nand.bin" is 13208 bytes whereas the binary provided by TI (PSP_02_10_00_14/bin/dm365/UBL_DM36x_NAND.bin) has size 20480 bytes. Can anyone tell me why is this difference? Am I missing something in this source code or having wrong source code? -- Regards, *Krunal Patil* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ottavio.campana at dei.unipd.it Thu Jun 3 03:51:53 2010 From: ottavio.campana at dei.unipd.it (Ottavio Campana) Date: Thu, 3 Jun 2010 10:51:53 +0200 Subject: Running a Web Browser on DM6446 In-Reply-To: References: Message-ID: <20100603085153.GA6177@dei.unipd.it> On Thu, Jun 03, 2010 at 09:35:01AM +0300, amr ali wrote: > > Hi, > I want to run a Web Browser on DM6446. Any head starts? > > Did anyone manage to run Ubuntu Desktop on any Davinci Boards? basically you need X working on the framebuffer or something like directfb + gtk + browser. I think having X running is the easiest solution and should be available in the evaluation version of montavista. Once you have X, you can do what you want. From ipcevm at gmail.com Thu Jun 3 04:06:37 2010 From: ipcevm at gmail.com (shaofeng zhang) Date: Thu, 3 Jun 2010 17:06:37 +0800 Subject: How to change the file Davinci_vpfe.c for capturing the Raw Data in my DM6446 platform? Message-ID: Hi, all My platform have the FPGA modules as the video source, and I could get the video stream as the BT 656 format, and It works very well. Now I want to capturing the video stream as the Raw Data format from the FPGA modules, but I do not know how to change the davinci_vpfe.c to set the ccdc registers and the ipipe registers. could anyone tell how to do that for get the raw data from video source? Thank you ~~ -- Best Regards! zhangshaofeng @Xi'an JiaoTong University -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jon.Povey at racelogic.co.uk Thu Jun 3 06:30:28 2010 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Thu, 3 Jun 2010 12:30:28 +0100 Subject: Davinci GPIO -> IRQ confusion Message-ID: <70E876B0EA86DD4BAF101844BC814DFE08E055CF04@Cloud.RL.local> I have spent today convinced something was wrong with gpio_to_irq() on DM355, and am slowly getting round to thinking that things are as intended, with confusing side effects. Namely, gpio_to_irq(1) returns 65, which eth0 reports on boot: eth0: dm9000a at c8814000,c8818002 IRQ 65 MAC: 06:06:0b:0b:06:06 (eeprom) And everything works. DM355 highest IRQ is 63. eth0 is actually using IRQ 54 (GPIOBNK0) and this "IRQ" seems to be not really an IRQ but an abstracted index number. This makes me confused and sad :( Under 2.6.10 it used to be a real, honest-to-hardware IRQ: eth0: dm9000 at c7810000,c7812002 IRQ 45 MAC: 00:50:c2:68:00:10 I think I see why this has been done, but it makes me wonder how we might report real IRQs instead.. Mailing so someone might say "that's as intended, you did indeed waste your day" or (unlikely) "well spotted, that's not right." -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From spoulsen at css-design.com Thu Jun 3 07:32:55 2010 From: spoulsen at css-design.com (Steve Poulsen) Date: Thu, 3 Jun 2010 07:32:55 -0500 Subject: Davinci GPIO -> IRQ confusion In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE08E055CF04@Cloud.RL.local> References: <70E876B0EA86DD4BAF101844BC814DFE08E055CF04@Cloud.RL.local> Message-ID: Jon Because there isn't an actual IRQ for each pin, they need to be virtual. The alternative is to have multiple drivers all wanting the same IRQ Steve On Jun 3, 2010, at 6:30 AM, Jon Povey wrote: > I have spent today convinced something was wrong with gpio_to_irq() > on DM355, and am slowly getting round to thinking that things are as > intended, with confusing side effects. > > Namely, gpio_to_irq(1) returns 65, which eth0 reports on boot: > > eth0: dm9000a at c8814000,c8818002 IRQ 65 MAC: 06:06:0b:0b:06:06 > (eeprom) > > And everything works. DM355 highest IRQ is 63. eth0 is actually > using IRQ 54 (GPIOBNK0) and this "IRQ" seems to be not really an IRQ > but an abstracted index number. This makes me confused and sad :( > > Under 2.6.10 it used to be a real, honest-to-hardware IRQ: > > eth0: dm9000 at c7810000,c7812002 IRQ 45 MAC: 00:50:c2:68:00:10 > > I think I see why this has been done, but it makes me wonder how we > might report real IRQs instead.. > > Mailing so someone might say "that's as intended, you did indeed > waste your day" or (unlikely) "well spotted, that's not right." > > -- > Jon Povey > jon.povey at racelogic.co.uk > > Racelogic is a limited company registered in England. Registered > number 2743719 . > Registered Office Unit 10, Swan Business Centre, Osier Way, > Buckingham, Bucks, MK18 1TB . > > The information contained in this electronic mail transmission is > intended by Racelogic Ltd for the use of the named individual or > entity to which it is directed and may contain information that is > confidential or privileged. If you have received this electronic > mail transmission in error, please delete it from your system > without copying or forwarding it, and notify the sender of the error > by reply email so that the sender's address records can be > corrected. The views expressed by the sender of this communication > do not necessarily represent those of Racelogic Ltd. Please note > that Racelogic reserves the right to monitor e-mail communications > passing through its network > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > From david-b at pacbell.net Thu Jun 3 08:59:37 2010 From: david-b at pacbell.net (David Brownell) Date: Thu, 3 Jun 2010 06:59:37 -0700 (PDT) Subject: Davinci GPIO -> IRQ confusion In-Reply-To: Message-ID: <106718.85714.qm@web180312.mail.gq1.yahoo.com> > Because there isn't an actual IRQ for each pin, > they need to be virtual. Actually, some of them could be "real" IRQs instead of being dispatched through the GPIO bank IRQ (which is a "real" IRQ, of course). But that gets messy. At one point it didn't work at all in Linux. It should work now, but as a rule you should expect IRQs associated with DaVinci GPIOs to be dispatched through some top-level bank IRQ ... most Linux platforms do the same thing (so doing anything else is what should be a surprise). > t things are as intended, with confusing side > effects. > > > > Namely, gpio_to_irq(1) returns 65, which eth0 reports on boot: Why would that be confusing? Most embedded Linux platforms don't map GPIO IRQs to numbers recognized by the top level IRQ controller ... GPIO IRQs get fed to some bank IRQ, and the handler for that IRQ dispatches to the right handler. From Juha.Kuikka at elektrobit.com Thu Jun 3 12:27:34 2010 From: Juha.Kuikka at elektrobit.com (Juha.Kuikka at elektrobit.com) Date: Thu, 3 Jun 2010 10:27:34 -0700 Subject: [PATCH 0/2] Davinci: Fix EDMA controller default queue number handling Message-ID: On DA850 the second EDMA controller only has one transfer controller and event queue. These changes fix the default event queue configuration from EVENTQ_1 to what is configured in platform data. As the EDMA driver is shared this may cause unwanted event queue ids on other davinci devices. These devices should set default_queue in edma_soc_info. - Juha Kuikka ---------------------------------------------------------------- Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. From Juha.Kuikka at elektrobit.com Thu Jun 3 12:27:38 2010 From: Juha.Kuikka at elektrobit.com (Juha.Kuikka at elektrobit.com) Date: Thu, 3 Jun 2010 10:27:38 -0700 Subject: [PATCH 1/2] DA850: Add default event queue numbers to EDMA controllers' platform data. Message-ID: Signed-off-by: Juha Kuikka diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c old mode 100644 new mode 100755 index 8cda729..9578642 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -132,6 +132,7 @@ static struct edma_soc_info da850_edma_info[] = { .n_cc = 1, .queue_tc_mapping = da8xx_queue_tc_mapping, .queue_priority_mapping = da8xx_queue_priority_mapping, + .default_queue = EVENTQ_1, }, { .n_channel = 32, @@ -141,6 +142,7 @@ static struct edma_soc_info da850_edma_info[] = { .n_cc = 1, .queue_tc_mapping = da850_queue_tc_mapping, .queue_priority_mapping = da850_queue_priority_mapping, + .default_queue = EVENTQ_0, }, }; -- 1.6.0.1 ---------------------------------------------------------------- Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. From Juha.Kuikka at elektrobit.com Thu Jun 3 12:27:42 2010 From: Juha.Kuikka at elektrobit.com (Juha.Kuikka at elektrobit.com) Date: Thu, 3 Jun 2010 10:27:42 -0700 Subject: [PATCH 2/2] Davinci-EDMA: Use default event queue numbers from platform data to initialize channels. Message-ID: Without this change the edma_probe defaults all channels into EVENTQ_1. This is an issue on devices where not all EDMA controllers have multiple queues. Signed-off-by: Juha Kuikka diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index d33827a..24bf27c 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -1433,8 +1433,6 @@ static int __init edma_probe(struct platform_device *pdev) edma_cc[j]->num_cc = min_t(unsigned, info[j].n_cc, EDMA_MAX_CC); edma_cc[j]->default_queue = info[j].default_queue; - if (!edma_cc[j]->default_queue) - edma_cc[j]->default_queue = EVENTQ_1; dev_dbg(&pdev->dev, "DMA REG BASE ADDR=%p\n", edmacc_regs_base[j]); @@ -1474,7 +1472,7 @@ static int __init edma_probe(struct platform_device *pdev) * started by the codec engine will not cause audio defects. */ for (i = 0; i < edma_cc[j]->num_channels; i++) - map_dmach_queue(j, i, EVENTQ_1); + map_dmach_queue(j, i, edma_cc[j]->default_queue); queue_tc_mapping = info[j].queue_tc_mapping; queue_priority_mapping = info[j].queue_priority_mapping; -- 1.6.0.1 ---------------------------------------------------------------- Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. From jphilippe.francois at gmail.com Thu Jun 3 03:00:26 2010 From: jphilippe.francois at gmail.com (jean-philippe francois) Date: Thu, 3 Jun 2010 10:00:26 +0200 Subject: MUSB: Idea: board-specific OTG ID pin interrupt support In-Reply-To: <70E876B0EA86DD4BAF101844BC814DFE08E055CE52@Cloud.RL.local> References: <70E876B0EA86DD4BAF101844BC814DFE08E055CE52@Cloud.RL.local> Message-ID: 2010/6/3 Jon Povey : > Hi, > > Did you mean to email privately or forgot list CC's? > My mistake. > jean-philippe francois wrote: >> What is your use case ? >> I am having a similar problem, but without happy design foresight ;). >> >> I am only using the gadget role, but still I need to detect external >> connection. In my case it may be easier than yours. The use case is >> the following : >> >> When no USB host is connected, the mmc/sd card is mounted in /mmc. >> On USB host connection, I want to unmount /mmc, and give the >> correspondig block device to the file_storage_ gadget. >> >> I achieved this by monitoring '/sys/devices/platform/musb_hdrc/mode' >> in user space. > > We did similar using hotplug events on 2.6.10 for both mmc and usb storage. > But there is no hotplug event in gadget mode . >> What is your example case ? I am not familiar with OTG USB, and while >> I understand what A-B role switching >> means, I need a more practical example of what you are trying to >> achieve. > > It's a portable video recorder which you can plug a USB stick into to record. You can also (swap cables and) plug into a PC, when it goes into gadget serial mode to communicate with our setup software. > > We did this on 2.6.10 by having two sets of USB modules build in Host and Peripheral mode, and our own driver monitor the ID pin and unload/reload modules. It worked, but OTG would be cleaner, faster to switch and not needing of nasty build time hacks. > So all the ID pin sensing is in addition to the DM OTG machinery, or is it a replacement for a malfunctionning OTG mode, where you kind of "manually" switch from one role to another ? > It's this, by the way: http://www.videovbox.co.uk/ > > -- > Jon Povey > jon.povey at racelogic.co.uk > > Racelogic is a limited company registered in England. Registered number 2743719 . > Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . > > The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network > > > From spoulsen at css-design.com Thu Jun 3 16:10:40 2010 From: spoulsen at css-design.com (Steve Poulsen) Date: Thu, 3 Jun 2010 16:10:40 -0500 Subject: how to decode h264 video encode by TI\'s H264 Baseline Profile Encoder (dm6446) In-Reply-To: References: Message-ID: <1ED2B7B0-C78D-4FB5-AF78-2E39F35BADAB@css-design.com> VLC should work well on the raw H.264. Make sure you start with the first frame. You may need to modify the bitstream if you want to start at any arbitrary position. Steve On Jun 3, 2010, at 12:22 AM, Raghu Ramaraj wrote: > Hi, > > I also wanted to know , how to play H264 encoded file in player > (like ffmeg, vlc) ? > > I just tried to play in ffmeg. But I am unable to play it. Is it > require any header ? > > > > > > Thanks & Regards, > > Raghu Ramaraj > > > > > http://www.mindtree.com/email/disclaimer.html > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jon.Povey at racelogic.co.uk Thu Jun 3 20:49:15 2010 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Fri, 4 Jun 2010 02:49:15 +0100 Subject: Davinci GPIO -> IRQ confusion In-Reply-To: <106718.85714.qm@web180312.mail.gq1.yahoo.com> Message-ID: <70E876B0EA86DD4BAF101844BC814DFE08E055CFCA@Cloud.RL.local> David Brownell wrote: >> Because there isn't an actual IRQ for each pin, >> they need to be virtual. > > Actually, some of them could be "real" IRQs > instead of being dispatched through the GPIO > bank IRQ (which is a "real" IRQ, of course). > > But that gets messy. At one point it didn't > work at all in Linux. It should work now, but as > a rule you should expect IRQs associated with > DaVinci GPIOs to be dispatched through some > top-level bank IRQ ... most Linux platforms do > the same thing (so doing anything else is what > should be a surprise). I suppose that's just my inexperience showing, then. It does seem confusing that there are two sets of values called "irq" used in the kernel code, one agreeing with the datasheet and one made-up token. I'm sure it's all straightforward when you're used to it, and really who is to say what's a "real" IRQ anyway, as the AINTC is a Davinci-specific thing as much as banked GPIO interrupts, the ARM only having two really hard interrupts. It made more sense as the dust settled. A shame it violates the principle of least surprise (to my eyes) but I see why and can't think of a good clean fix without another layer of abstraction. Shutting up. -- Jon Povey jon.povey at racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network From raghu_ramaraj at mindtree.com Thu Jun 3 22:37:56 2010 From: raghu_ramaraj at mindtree.com (Raghu Ramaraj) Date: Fri, 4 Jun 2010 09:07:56 +0530 Subject: how to decode h264 video encode by TI\'s H264 Baseline Profile Encoder (dm6446) In-Reply-To: <1ED2B7B0-C78D-4FB5-AF78-2E39F35BADAB@css-design.com> References: <1ED2B7B0-C78D-4FB5-AF78-2E39F35BADAB@css-design.com> Message-ID: We are facing some issue in which the image colors go bad (Means not getting proper image) after 4-5 hours .... At this stage, we wanted to record the video image into file. So that time we will not be having the header of H264. Is it possible to run the H264 raw file? If not then how to add headers in the file ? Thanks & Regards, Raghu Ramaraj ________________________________ From: Steve Poulsen [mailto:spoulsen at css-design.com] Sent: Friday, June 04, 2010 2:41 AM To: Raghu Ramaraj Cc: zuber.saiyed at einfochips.com; davinci-linux-open-source at linux.davincidsp.com Subject: Re: how to decode h264 video encode by TI\'s H264 Baseline Profile Encoder (dm6446) VLC should work well on the raw H.264. Make sure you start with the first frame. You may need to modify the bitstream if you want to start at any arbitrary position. Steve On Jun 3, 2010, at 12:22 AM, Raghu Ramaraj > wrote: Hi, I also wanted to know , how to play H264 encoded file in player(like ffmeg, vlc) ? I just tried to play in ffmeg. But I am unable to play it. Is it require any header ? Thanks & Regards, Raghu Ramaraj ________________________________ http://www.mindtree.com/email/disclaimer.html -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source at linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.koeller at baslerweb.com Fri Jun 4 04:31:00 2010 From: thomas.koeller at baslerweb.com (Thomas Koeller) Date: Fri, 4 Jun 2010 11:31:00 +0200 Subject: [PATCH] DM365: fixed second serial port In-Reply-To: References: <1275383203-6381-1-git-send-email-thomas.koeller@baslerweb.com> Message-ID: <201006041131.01010.thomas.koeller@baslerweb.com> On Wednesday 02 June 2010 08:22:46 Nori, Sekhar wrote: > > Patch is against Kevin's tree. > > Such information (which is not relevant to the fix as such) > should go below the --- in the patch. That way, it does not > get included in the git logs once the patch is committed. O.K., I will address that > May be it is personal taste, but I like this way of fixing > it better: > > diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c > index a146849..5dded5e 100644 > --- a/arch/arm/mach-davinci/dm365.c > +++ b/arch/arm/mach-davinci/dm365.c > @@ -1020,6 +1020,8 @@ static struct davinci_timer_info dm365_timer_info = { > .clocksource_id = T0_TOP, > }; > > +#define DAVINCI_DM365_UART1_BASE 0x01D06000 > + > static struct plat_serial8250_port dm365_serial_platform_data[] = { > { > .mapbase = DAVINCI_UART0_BASE, > @@ -1030,7 +1032,7 @@ static struct plat_serial8250_port > dm365_serial_platform_data[] = { .regshift = 2, > }, > { > - .mapbase = DAVINCI_UART1_BASE, > + .mapbase = DAVINCI_DM365_UART1_BASE, > .irq = IRQ_UARTINT1, > .flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | > UPF_IOREMAP, Unless you insist, I would prefer to leave the define at its current place. First of all, many people (including me) expect to find defines somewhere near the beginning of a source file. More importantly, if a definition is valid throughout the entire file, it is easier to later add code that also depends on that definition, without having to move it again. Thomas From jp.francois at cynove.com Fri Jun 4 06:16:28 2010 From: jp.francois at cynove.com (jean-philippe francois) Date: Fri, 4 Jun 2010 13:16:28 +0200 Subject: [PATCH] DM365: fixed second serial port In-Reply-To: <201006041131.01010.thomas.koeller@baslerweb.com> References: <1275383203-6381-1-git-send-email-thomas.koeller@baslerweb.com> <201006041131.01010.thomas.koeller@baslerweb.com> Message-ID: > Unless you insist, I would prefer to leave the define at its current place. > First of all, many people (including me) expect to find defines somewhere > near the beginning of a source file. More importantly, if a definition is > valid throughout the entire file, it is easier to later add code that also > depends on that definition, without having to move it again. > As far as I am concerned, when a define is used in a single place, I find it easier to have it near the place where it is used. And I don't think we will need to add further reference to this define, since the precise purpose of this platform data is to stop caring about the hardware base address. > Thomas > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > From sudhakar.raj at ti.com Fri Jun 4 06:16:02 2010 From: sudhakar.raj at ti.com (Sudhakar Rajashekhara) Date: Fri, 4 Jun 2010 16:46:02 +0530 Subject: [PATCH 2/2] Davinci-EDMA: Use default event queue numbers from platform data to initialize channels. In-Reply-To: References: Message-ID: <006201cb03d7$515b48e0$f411daa0$@raj@ti.com> Hi Juha, On Thu, Jun 03, 2010 at 22:57:42, Juha.Kuikka at elektrobit.com wrote: > > Without this change the edma_probe defaults all channels into > EVENTQ_1. This is an issue on devices where not all EDMA controllers > have multiple queues. > > Signed-off-by: Juha Kuikka > > diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c > index d33827a..24bf27c 100644 > --- a/arch/arm/mach-davinci/dma.c > +++ b/arch/arm/mach-davinci/dma.c > @@ -1433,8 +1433,6 @@ static int __init edma_probe(struct > platform_device *pdev) > edma_cc[j]->num_cc = min_t(unsigned, info[j].n_cc, > EDMA_MAX_CC); > > edma_cc[j]->default_queue = info[j].default_queue; > - if (!edma_cc[j]->default_queue) > - edma_cc[j]->default_queue = EVENTQ_1; On platforms which do not specify the default_queue from platform data, this patch maps them to EVENTQ_0. So this is a change from the existing behavior. You can do any of the following: a. Retain the default behavior by not removing the 2 lines above. Anyway, patch 1/2 specifies the default_queue for OMAP-L138, so we should be OK. b. Remove the 2 lines above and check the EDMA behavior on all affected platforms. c. Remove the 2 lines above and add default_queue as EVENTQ_1 for other platforms as well. > > dev_dbg(&pdev->dev, "DMA REG BASE ADDR=%p\n", > edmacc_regs_base[j]); > @@ -1474,7 +1472,7 @@ static int __init edma_probe(struct > platform_device *pdev) > * started by the codec engine will not cause audio > defects. > */ > for (i = 0; i < edma_cc[j]->num_channels; i++) > - map_dmach_queue(j, i, EVENTQ_1); > + map_dmach_queue(j, i, > edma_cc[j]->default_queue); Please correct indenting here. Regards, Sudhakar From juha.kuikka at gmail.com Fri Jun 4 14:28:05 2010 From: juha.kuikka at gmail.com (Juha Kuikka) Date: Fri, 4 Jun 2010 12:28:05 -0700 Subject: [PATCH 2/2] Davinci-EDMA: Use default event queue numbers from platform data to initialize channels. In-Reply-To: <-1551304331868021255@unknownmsgid> References: <-1551304331868021255@unknownmsgid> Message-ID: Sudhakar, I apologize for the confusing email-address-dance but seems my corp email ate your message. On Fri, Jun 4, 2010 at 4:16 AM, Sudhakar Rajashekhara wrote: > Hi Juha, > > On Thu, Jun 03, 2010 at 22:57:42, Juha.Kuikka at elektrobit.com wrote: >> >> Without this change the edma_probe defaults all channels into >> EVENTQ_1. This is an issue on devices where not all EDMA controllers >> have multiple queues. >> >> Signed-off-by: Juha Kuikka >> >> diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c >> index d33827a..24bf27c 100644 >> --- a/arch/arm/mach-davinci/dma.c >> +++ b/arch/arm/mach-davinci/dma.c >> @@ -1433,8 +1433,6 @@ static int __init edma_probe(struct >> platform_device *pdev) >> ? ? ? ? ? ? ? ? edma_cc[j]->num_cc = min_t(unsigned, info[j].n_cc, >> EDMA_MAX_CC); >> >> ? ? ? ? ? ? ? ? edma_cc[j]->default_queue = info[j].default_queue; >> - ? ? ? ? ? ? ? if (!edma_cc[j]->default_queue) >> - ? ? ? ? ? ? ? ? ? ? ? edma_cc[j]->default_queue = EVENTQ_1; > > On platforms which do not specify the default_queue from platform data, this > patch maps them to EVENTQ_0. So this is a change from the existing behavior. > You can do any of the following: > > a. Retain the default behavior by not removing the 2 lines above. Anyway, patch > ? 1/2 specifies the default_queue for OMAP-L138, so we should be OK. Problem with these two lines is that EVENTQ_0 is defined as zero (same as when you leave default_queue undefined), so with these two lines in place it is impossible to set the default to EVENTQ_0 at all. So this is not a durable solution. > b. Remove the 2 lines above and check the EDMA behavior on all affected platforms. I only have access to DA850 platform so this is not possible. > c. Remove the 2 lines above and add default_queue as EVENTQ_1 for other platforms as well. So it seems this is the only feasible answer. Other than re-defining EVENTQ -enums as one higher. But this breaks lot of the code in the driver that depends on then being zero-based and is very ugly anyways. > >> >> ? ? ? ? ? ? ? ? dev_dbg(&pdev->dev, "DMA REG BASE ADDR=%p\n", >> ? ? ? ? ? ? ? ? ? ? ? ? edmacc_regs_base[j]); >> @@ -1474,7 +1472,7 @@ static int __init edma_probe(struct >> platform_device *pdev) >> ? ? ? ? ? ? ? ? ?* started by the codec engine will not cause audio >> defects. >> ? ? ? ? ? ? ? ? ?*/ >> ? ? ? ? ? ? ? ? for (i = 0; i < edma_cc[j]->num_channels; i++) >> - ? ? ? ? ? ? ? ? ? ? ? map_dmach_queue(j, i, EVENTQ_1); >> + ? ? ? ? ? ? ? ? ? ? ? map_dmach_queue(j, i, >> edma_cc[j]->default_queue); > > Please correct indenting here. Now where did that come from... I blame the mailer. :) - Juha From luna.id at gmail.com Fri Jun 4 15:15:02 2010 From: luna.id at gmail.com (Nicolas Luna) Date: Fri, 4 Jun 2010 16:15:02 -0400 Subject: Touchscreen - MFD driver for TPS6507x family Message-ID: Hi, I downloaded and tried the kernel v2.6.34 from * linux/kernel/git/khilman/linux-davinci.git**/ *to get the touchscreen patch. It is working well, but I wonder if it is normal that the touchscreen constantly use the I2C bus, even if I don't touch to the touchscreen. Because of that, it is not possible to have an other device on the bus. Is there any specific reason why the driver do not use the INT pin from the TPS6507x to free a little bit the I2C bus. Thanks Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From akumar at Cernium.com Fri Jun 4 15:16:04 2010 From: akumar at Cernium.com (Alok Kumar) Date: Fri, 4 Jun 2010 16:16:04 -0400 Subject: usb 1-1: device descriptor read/64, error -11 Message-ID: <03A2FA9E0D3DC841992E682BF528771801E95484@lipwig.Cernium.local> Hi, I am using Davinci 6446 with git tree kernel 2.6.30. We use USB drive (pen drive) to collect the data periodically. Sometimes (once in 3-4 months) , after reboot an earlier working USB drive is not recognized (no /dev/sda1 etc) and I see following errors and USB is was not detected. kernel: usb 1-1: new high speed USB device using musb_hdrc and address 2 kernel: Initializing USB Mass Storage driver... kernel: usbcore: registered new interface driver usb-storage kernel: USB Mass Storage support registered. kernel: musb_h_ep0_irq 1067: no URB for end 0 kernel: usb 1-1: device descriptor read/64, error -11 I see some comments in musb/musb_host.c for 'no URB for end 0', saying this should never happen. My question is how to fix this error. What kind of recovery mechanism , I can put to auto detect it and fix it. Any help will be greatly appreciated. Thanks Alok -------------- next part -------------- An HTML attachment was scrubbed... URL: From akumar at Cernium.com Fri Jun 4 15:16:50 2010 From: akumar at Cernium.com (Alok Kumar) Date: Fri, 4 Jun 2010 16:16:50 -0400 Subject: usb 1-1: device descriptor read/64, error -110 Message-ID: <03A2FA9E0D3DC841992E682BF528771801E95487@lipwig.Cernium.local> Correction Error number is -110 (timeout) From: Alok Kumar Sent: Friday, June 04, 2010 4:25 PM To: 'davinci-linux-open-source at linux.davincidsp.com' Subject: usb 1-1: device descriptor read/64, error -11 Hi, I am using Davinci 6446 with git tree kernel 2.6.30. We use USB drive (pen drive) to collect the data periodically. Sometimes (once in 3-4 months) , after reboot an earlier working USB drive is not recognized (no /dev/sda1 etc) and I see following errors and USB is was not detected. kernel: usb 1-1: new high speed USB device using musb_hdrc and address 2 kernel: Initializing USB Mass Storage driver... kernel: usbcore: registered new interface driver usb-storage kernel: USB Mass Storage support registered. kernel: musb_h_ep0_irq 1067: no URB for end 0 kernel: usb 1-1: device descriptor read/64, error -110 I see some comments in musb/musb_host.c for 'no URB for end 0', saying this should never happen. My question is how to fix this error. What kind of recovery mechanism , I can put to auto detect it and fix it. Any help will be greatly appreciated. Thanks Alok -------------- next part -------------- An HTML attachment was scrubbed... URL: From todd.fischer at ridgerun.com Fri Jun 4 15:33:01 2010 From: todd.fischer at ridgerun.com (Todd Fischer) Date: Fri, 04 Jun 2010 14:33:01 -0600 Subject: Touchscreen - MFD driver for TPS6507x family In-Reply-To: References: Message-ID: <1275683581.21486.374.camel@sax-lx> Hi Nicolas, On Fri, 2010-06-04 at 16:15 -0400, Nicolas Luna wrote: > Hi, > > > > I downloaded and tried the kernel v2.6.34 from > linux/kernel/git/khilman/linux-davinci.git/ to get the touchscreen > patch. It is working well, but I wonder if it is normal that the > touchscreen constantly use the I2C bus, even if I don't touch to the > touchscreen. No, that is not normal. The hardware I was using doesn't have the TPS6507x interrupt pin connected, so I couldn't test that code path (and thus didn't attempt to include it). What hardware are you using? > Because of that, it is not possible to have an other device on the > bus. Is there any specific reason why the driver do not use the INT > pin from the TPS6507x to free a little bit the I2C bus. Also, I didn't think the driver was locking out all other access to the I2C bus. I will enhance my test suite to check for that case. Todd > Thanks > > > Nicolas > > > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -------------- next part -------------- An HTML attachment was scrubbed... URL: From BNiebuhr at efjohnson.com Fri Jun 4 15:35:50 2010 From: BNiebuhr at efjohnson.com (Brian Niebuhr) Date: Fri, 4 Jun 2010 15:35:50 -0500 Subject: [PATCH 3/6] davinci: edma: clear events in edma_start() References: <1268841163-5868-1-git-send-email-khilman@deeprootsystems.com><1268841163-5868-4-git-send-email-khilman@deeprootsystems.com><4BFA6A22.1000006@windriver.com> <871vd16wic.fsf@deeprootsystems.com><4BFBA100.4020805@windriver.com><00f701cafc0e$23dedbf0$6b9c93d0$@raj@ti.com> <87d3wkov63.fsf@deeprootsystems.com> Message-ID: > >> >> This patch causes that the sound can not work normally > on OMAP_L138. > >> > >> After revert it, the audio works fine. > >> > > > > This patch works fine on DM644x which has McBSP but breaks > audio on OMAP L138 > > (as you had mentioned) which has McASP. Ideally McBSP/McASP > should start after > > EDMA is started. If not then this patch clears the EDMA > event which is actually > > set by McBSP/McASP. As this patch is working fine on > DM644x, I think there is > > some issue in the audio driver which needs to be debugged. > > In the mean time, I think it makes sense to revert $SUBJECT patch in > davinci git until the audio driver is debugged. Kevin - What is the process or timeline for getting this patch reapplied? I am working right now on resubmitting my patch for the Davinci SPI driver, however that driver won't work as is without this patch. I could probably hack something into the SPI driver to compensate, however if all are agreed that drivers shouldn't rely on DMA events that occur before the DMA is started, then it seems better to handle the issue in the DMA driver as I did in the reverted patch. Thanks! Brian From swb at i-d-2.com Fri Jun 4 21:07:29 2010 From: swb at i-d-2.com (Stephen Berry) Date: Fri, 04 Jun 2010 22:07:29 -0400 Subject: usb 1-1: device descriptor read/64, error -110 In-Reply-To: <03A2FA9E0D3DC841992E682BF528771801E95487@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771801E95487@lipwig.Cernium.local> Message-ID: <4C09B161.8020508@i-d-2.com> It looks like the device descriptor wasn't read correctly. Without that the kernel can't attach the device. Did you try removing it and hot-plugging to see if it works? If a USB device doesn't respond to configuration requests appropriately, then it is usually because it is : a - damaged b - the hardware (pen drive) has a power issue c - firmware is too slow on the device to respond. Try a new pen drive. You can certainly detect that a device you expect isn't mounted, not sure how to tell udev to try to reconfigure it again after it failed the first time around... Steve On 6/4/2010 4:16 PM, Alok Kumar wrote: > > Correction Error number is -110 (timeout) > > > > *From:* Alok Kumar > *Sent:* Friday, June 04, 2010 4:25 PM > *To:* 'davinci-linux-open-source at linux.davincidsp.com' > *Subject:* usb 1-1: device descriptor read/64, error -11 > > > > Hi, > > > > I am using Davinci 6446 with git tree kernel 2.6.30. We use USB drive > (pen drive) to collect the data periodically. > > Sometimes (once in 3-4 months) , after reboot an earlier working USB > drive is not recognized (no /dev/sda1 etc) and I see following errors > and USB is was not detected. > > > > *kernel: usb 1-1: new high speed USB device using musb_hdrc and address 2* > > *kernel: Initializing USB Mass Storage driver...* > > *kernel: usbcore: registered new interface driver usb-storage* > > *kernel: USB Mass Storage support registered.* > > *kernel: musb_h_ep0_irq 1067: no URB for end 0* > > *kernel: usb 1-1: device descriptor read/64, error -110* > > * * > > I see some comments in musb/musb_host.c for 'no URB for end 0', saying > this should never happen. > > > > My question is how to fix this error. What kind of recovery mechanism > , I can put to auto detect it and fix it. > > Any help will be greatly appreciated. > > > > Thanks > > Alok > > NOTICE: The information contained in this email and any document > attached hereto is intended only for the named recipient(s). It is the > property of Cernium Corporation and shall not be used, disclosed or > reproduced without the express written consent of Cernium Corporation. > If you are not the intended recipient (or the employee or agent > responsible for delivering this message in confidence to the intended > recipient(s)), you are hereby notified that you have received this > transmittal in error, and any review, dissemination, distribution or > copying of this transmittal or its attachments is strictly prohibited. > If you have received this transmittal and/or attachments in error, > please notify me immediately by reply email or telephone and > immediately delete this message and all its attachments. Thank you. > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spoulsen at css-design.com Sat Jun 5 08:34:27 2010 From: spoulsen at css-design.com (Steve Poulsen) Date: Sat, 05 Jun 2010 08:34:27 -0500 Subject: usb 1-1: device descriptor read/64, error -110 In-Reply-To: <03A2FA9E0D3DC841992E682BF528771801E95487@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771801E95487@lipwig.Cernium.local> Message-ID: <4C0A5263.9060605@css-design.com> I have not spent much time in this part of the code, but I believe you are on the right track. You probably already know some of these things, but I suggest the following. 1) Create a test that can simulate the 3-4 month issue more quickly. Many board, many reboots? 2) Test code that has all debug enabled, with some added debug around the area of the URB error. 3) Walk through the code and try to determine what possible reasons could cause this URB error. Is it a dynamic allocation? If so, try to determine what your memory situation is at that point. 4) Try reducing the kernel memory to see if it is more frequent. Try increasing to see if it goes away. Steve On 06/04/2010 03:16 PM, Alok Kumar wrote: > > Correction Error number is -110 (timeout) > > *From:* Alok Kumar > *Sent:* Friday, June 04, 2010 4:25 PM > *To:* 'davinci-linux-open-source at linux.davincidsp.com' > *Subject:* usb 1-1: device descriptor read/64, error -11 > > Hi, > > I am using Davinci 6446 with git tree kernel 2.6.30. We use USB drive > (pen drive) to collect the data periodically. > > Sometimes (once in 3-4 months) , after reboot an earlier working USB > drive is not recognized (no /dev/sda1 etc) and I see following errors > and USB is was not detected. > > *kernel: usb 1-1: new high speed USB device using musb_hdrc and address 2* > > *kernel: Initializing USB Mass Storage driver...* > > *kernel: usbcore: registered new interface driver usb-storage* > > *kernel: USB Mass Storage support registered.* > > *kernel: musb_h_ep0_irq 1067: no URB for end 0* > > *kernel: usb 1-1: device descriptor read/64, error -110* > > * * > > I see some comments in musb/musb_host.c for 'no URB for end 0', saying > this should never happen. > > My question is how to fix this error. What kind of recovery mechanism > , I can put to auto detect it and fix it. > > Any help will be greatly appreciated. > > Thanks > > Alok > > NOTICE: The information contained in this email and any document > attached hereto is intended only for the named recipient(s). It is the > property of Cernium Corporation and shall not be used, disclosed or > reproduced without the express written consent of Cernium Corporation. > If you are not the intended recipient (or the employee or agent > responsible for delivering this message in confidence to the intended > recipient(s)), you are hereby notified that you have received this > transmittal in error, and any review, dissemination, distribution or > copying of this transmittal or its attachments is strictly prohibited. > If you have received this transmittal and/or attachments in error, > please notify me immediately by reply email or telephone and > immediately delete this message and all its attachments. Thank you. > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* , and is > believed to be clean. > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source at linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david-b at pacbell.net Sat Jun 5 11:48:15 2010 From: david-b at pacbell.net (David Brownell) Date: Sat, 5 Jun 2010 09:48:15 -0700 (PDT) Subject: usb 1-1: device descriptor read/64, error -110 In-Reply-To: <4C0A5263.9060605@css-design.com> Message-ID: <943666.59133.qm@web180312.mail.gq1.yahoo.com> > kernel: musb_h_ep0_irq 1067: no URB for end 0 > kernel: usb 1-1: device descriptor read/64, error -110 Some devices are flakey about device descriptor reads. Note "-110" is "-ETIMEDOUT".? The code in usbcore to read descriptors has all sorts of logic to handle flakey descriptor reporting from USB peripherals, and the first place such things show up is usually device descriptors. Root causes are normally peripheral bugs, but it's also possible the MUSB code might need tweaking. ? > I see some comments in musb/musb_host.c for ?no URB for > end 0?, saying this should never happen. where "should" is the operative word ... not "can".? Butit's clearly happening to you ... ? My question is how to fix this error. No suggestions, sorry; but you have TWO errors, soI'd debug them one at a time. - Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From ng at max01.eu Mon Jun 7 02:26:40 2010 From: ng at max01.eu (ng at max01.eu) Date: Mon, 7 Jun 2010 09:26:40 +0200 (CEST) Subject: TPS6507x-ts driver failed with -121 on kernel v2.6.34-davinci1 Message-ID: <241396971.3491.1275895600821.JavaMail.open-xchange@oxltgw05.schlund.de> Hello, i try to get running the tps6507x-ts touchscreen driver on the Kevin Hilman Davinci kernel tree (git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git). I enabled the following parts in the kernelconfig: Device Drivers - Multifunction Device Drivers - TPS6507x Power Management / Touch Screen chips Device Drivers - Input device support - Event Interface Device Drivers - Input device support - Touchscreens - TPS6507x based touchscreens That gives a compile error : "can`t find" kzalloc and kfree! After applying following patch the driver compiles. diff --git a/drivers/mfd/tps6507x.c b/drivers/mfd/tps6507x.c index dcddef0..dbaab1a 100644 --- a/drivers/mfd/tps6507x.c +++ b/drivers/mfd/tps6507x.c @@ -20,6 +20,7 @@ ?#include ?#include ?#include +#include ? ?static struct mfd_cell tps6507x_devs[] = { ??????? { On runtime the kernel gives the following error: tps6507x-ts: probe of tps6507x-ts failed with error -121 Any idea whats to do now? Thank you very much, ? regards ? Bastian. ? P.S. Hardware: OMAP-L138 Evm-Board with ui-board -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Jun 7 05:15:20 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 7 Jun 2010 12:15:20 +0200 Subject: [PATCH 02/12] spi: davinci: Added support for chip select using gpio Message-ID: From: Raffaele Recalcati Date: Fri, 4 Jun 2010 16:16:37 +0200 Subject: [PATCH 02/12] spi: davinci: Added support for chip select using gpio Signed-off-by: Davide Bonfanti --- arch/arm/mach-davinci/dm365.c | 10 ++++++---- drivers/spi/davinci_spi.c | 26 +++++++++++++++++--------- 2 files changed, 23 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index a146849..42fd4a4 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -677,10 +677,12 @@ void __init dm365_init_spi0(unsigned chipselect_mask, davinci_cfg_reg(DM365_SPI0_SDO); /* not all slaves will be wired up */ - if (chipselect_mask & BIT(0)) - davinci_cfg_reg(DM365_SPI0_SDENA0); - if (chipselect_mask & BIT(1)) - davinci_cfg_reg(DM365_SPI0_SDENA1); + if (!((unsigned long) info->controller_data)) { + if (chipselect_mask & BIT(0)) + davinci_cfg_reg(DM365_SPI0_SDENA0); + if (chipselect_mask & BIT(1)) + davinci_cfg_reg(DM365_SPI0_SDENA1); + } spi_register_board_info(info, len); diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c index 95afb6b..6a305ca 100644 --- a/drivers/spi/davinci_spi.c +++ b/drivers/spi/davinci_spi.c @@ -29,6 +29,7 @@ #include #include +#include #include #include @@ -270,18 +271,25 @@ static void davinci_spi_chipselect(struct spi_device *spi, int value) pdata = davinci_spi->pdata; /* - * Board specific chip select logic decides the polarity and cs - * line for the controller - */ + * Board specific chip select logic decides the polarity and cs + * line for the controller + */ if (value == BITBANG_CS_INACTIVE) { - set_io_bits(davinci_spi->base + SPIDEF, CS_DEFAULT); - - data1_reg_val |= CS_DEFAULT << SPIDAT1_CSNR_SHIFT; - iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1); + if ((unsigned long) spi->controller_data) { + gpio_set_value(spi->controller_data, !(spi->mode & SPI_CS_HIGH)); + } else { + set_io_bits(davinci_spi->base + SPIDEF, CS_DEFAULT); + data1_reg_val |= CS_DEFAULT << SPIDAT1_CSNR_SHIFT; + iowrite32(data1_reg_val, davinci_spi->base + SPIDAT1); + } while ((ioread32(davinci_spi->base + SPIBUF) - & SPIBUF_RXEMPTY_MASK) == 0) + & SPIBUF_RXEMPTY_MASK) == 0) cpu_relax(); + } else { + if ((unsigned long) spi->controller_data) { + gpio_set_value(spi->controller_data, (spi->mode & SPI_CS_HIGH)); + } } } -- 1.6.3.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Jun 7 05:15:28 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 7 Jun 2010 12:15:28 +0200 Subject: [PATCH 03/12] davinci: dm365: Added swap between y and c data in isif port. Message-ID: From: Raffaele Recalcati Date: Fri, 4 Jun 2010 14:23:30 +0200 Subject: [PATCH 03/12] davinci: dm365: Added swap between y and c data in isif port. --- drivers/media/video/davinci/isif.c | 6 +++++- include/media/davinci/isif.h | 2 ++ include/media/davinci/vpfe_types.h | 8 ++++++++ 3 files changed, 15 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/davinci/isif.c b/drivers/media/video/davinci/isif.c index 29c29c6..120fcf0 100644 --- a/drivers/media/video/davinci/isif.c +++ b/drivers/media/video/davinci/isif.c @@ -105,6 +105,7 @@ static struct isif_oper_config { .hd_pol = VPFE_PINPOL_POSITIVE, .pix_order = CCDC_PIXORDER_CBYCRY, .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED, + .ycswap = YCIN_NOT_SWP, }, .bayer = { .pix_fmt = CCDC_PIXFMT_RAW, @@ -864,6 +865,7 @@ static void isif_setfbaddr(unsigned long addr) static int isif_set_hw_if_params(struct vpfe_hw_if_param *params) { isif_cfg.if_type = params->if_type; + isif_cfg.ycbcr.ycswap = params->ycswap; switch (params->if_type) { case VPFE_BT656: @@ -914,7 +916,9 @@ static int isif_config_ycbcr(void) } modeset |= (VPFE_PINPOL_NEGATIVE << ISIF_VD_POL_SHIFT); regw(3, REC656IF); - ccdcfg = ccdcfg | ISIF_DATA_PACK8 | ISIF_YCINSWP_YCBCR; + ccdcfg = ccdcfg | ISIF_DATA_PACK8; + if(params->ycswap == YCIN_SWP) + ccdcfg |= ISIF_YCINSWP_YCBCR; break; case VPFE_BT656_10BIT: if (params->pix_fmt != CCDC_PIXFMT_YCBCR_8BIT) { diff --git a/include/media/davinci/isif.h b/include/media/davinci/isif.h index b0b74ad..b123f2c 100644 --- a/include/media/davinci/isif.h +++ b/include/media/davinci/isif.h @@ -466,6 +466,8 @@ struct isif_ycbcr_config { enum vpfe_pin_pol hd_pol; /* isif pix order. Only used for ycbcr capture */ enum ccdc_pixorder pix_order; + /* ccdc data connection. 8 bit ycbcr data bus connection */ + enum vpfe_data_swap ycswap; /* isif buffer type. Only used for ycbcr capture */ enum ccdc_buftype buf_type; }; diff --git a/include/media/davinci/vpfe_types.h b/include/media/davinci/vpfe_types.h index 76fb74b..337c917 100644 --- a/include/media/davinci/vpfe_types.h +++ b/include/media/davinci/vpfe_types.h @@ -40,12 +40,20 @@ enum vpfe_hw_if_type { VPFE_BT656_10BIT }; +/* 8 bit interface can be swapped */ +enum vpfe_data_swap { + YCIN_NOT_SWP, + YCIN_SWP, +}; + /* interface description */ struct vpfe_hw_if_param { enum vpfe_hw_if_type if_type; enum vpfe_pin_pol hdpol; enum vpfe_pin_pol vdpol; + enum vpfe_data_swap ycswap; }; + #endif #endif -- 1.6.3.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Jun 7 05:15:33 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 7 Jun 2010 12:15:33 +0200 Subject: [PATCH 04/12] ads7846: setting pen_down direction in input Message-ID: From: Raffaele Recalcati Date: Fri, 4 Jun 2010 14:55:16 +0200 Subject: [PATCH 04/12] ads7846: setting pen_down direction in input --- drivers/input/touchscreen/ads7846.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c index 532279c..226dbdc 100644 --- a/drivers/input/touchscreen/ads7846.c +++ b/drivers/input/touchscreen/ads7846.c @@ -872,6 +872,8 @@ static int __devinit setup_pendown(struct spi_device *spi, struct ads7846 *ts) return err; } + gpio_direction_input(pdata->gpio_pendown); + ts->gpio_pendown = pdata->gpio_pendown; return 0; } -- 1.6.3.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Jun 7 05:15:40 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 7 Jun 2010 12:15:40 +0200 Subject: [PATCH 05/12] mtd-nand: davinci: Added 16 bit wide bus for DaVinci bmx board Message-ID: From: Davide Bonfanti Date: Fri, 4 Jun 2010 13:56:35 +0200 Subject: [PATCH 05/12] mtd-nand: davinci: Added 16 bit wide bus for DaVinci bmx board Signed-off-by: "Raffaele Recalcati " --- drivers/mtd/nand/davinci_nand.c | 40 +++++++++++++++++++++++++++++++++++++++ 1 files changed, 40 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c index 103235e..d29685d 100644 --- a/drivers/mtd/nand/davinci_nand.c +++ b/drivers/mtd/nand/davinci_nand.c @@ -508,6 +508,38 @@ static void __init nand_dm6446evm_flash_init(struct davinci_nand_info *info) } } +static void __init nand_bmx_flash_init(struct davinci_nand_info *info) +{ + uint32_t regval, a1cr; + + /* + * NAND FLASH timings @ PLL1 == 459 MHz + * - AEMIF.CLK freq = PLL1/6 = 459/6 = 76.5 MHz + * - AEMIF.CLK period = 1/76.5 MHz = 13.1 ns + */ + regval = 0 + | (0 << 31) /* selectStrobe */ + | (1 << 30) /* extWait (never with NAND) */ + | (0 << 26) /* writeSetup 10 ns */ + | (4 << 20) /* writeStrobe 40 ns */ + | (0 << 17) /* writeHold 10 ns */ + | (0 << 13) /* readSetup 10 ns */ + | (4 << 7) /* readStrobe 60 ns */ + | (0 << 4) /* readHold 10 ns */ + | (1 << 2) /* turnAround ?? ns */ + | (1 << 0) /* asyncSize 16-bit bus */ + ; + a1cr = davinci_nand_readl(info, A1CR_OFFSET); + if (a1cr != regval) { + dev_err(info->dev, "Warning: NAND config: Set A1CR " \ + "reg to 0x%08x, was 0x%08x, should be done by " \ + "bootloader.\n", regval, a1cr); + davinci_nand_writel(info, A1CR_OFFSET, regval); + } + +} + + /*----------------------------------------------------------------------*/ /* An ECC layout for using 4-bit ECC with small-page flash, storing @@ -697,6 +729,14 @@ static int __init nand_davinci_probe(struct platform_device *pdev) */ if (machine_is_davinci_evm()) nand_dm6446evm_flash_init(info); + else if (machine_is_bmx()) + nand_bmx_flash_init(info); /* no reason to do this, + * because the boot loader + * is booting the kernel + * that is in the nand flash + * and so EMIF must already + * configured + */ spin_lock_irq(&davinci_nand_lock); -- 1.6.3.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Jun 7 05:15:46 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 7 Jun 2010 12:15:46 +0200 Subject: [PATCH 06/12] fb: Added composite sync high active mode Message-ID: From: Davide Bonfanti Date: Fri, 4 Jun 2010 14:30:12 +0200 Subject: [PATCH 06/12] fb: Added composite sync high active mode --- include/linux/fb.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/fb.h b/include/linux/fb.h index c10163b..578a8de 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -212,6 +212,7 @@ struct fb_bitfield { /* vtotal = 144d/288n/576i => PAL */ /* vtotal = 121d/242n/484i => NTSC */ #define FB_SYNC_ON_GREEN 32 /* sync on green */ +#define FB_SYNC_PIXCLOCK_HIGH_ACT 64 /* composite sync high active */ #define FB_VMODE_NONINTERLACED 0 /* non interlaced */ #define FB_VMODE_INTERLACED 1 /* interlaced */ -- 1.6.3.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Jun 7 05:15:14 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 7 Jun 2010 12:15:14 +0200 Subject: [PATCH 01/12] ASoC: DaVinci: Added support for stereo I2S Message-ID: From: Raffaele Recalcati Date: Thu, 3 Jun 2010 14:40:05 +0200 Subject: [PATCH 01/12] ASoC: DaVinci: Added support for stereo I2S - Frame Sync master and Clock master (internally generated) - Frame Sync master and Clock slave Signed-off-by: Davide Bonfanti --- sound/soc/davinci/davinci-i2s.c | 137 ++++++++++++++++++++++++++++++++++----- 1 files changed, 121 insertions(+), 16 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index adadcd3..c1281c5 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -9,6 +9,8 @@ * published by the Free Software Foundation. */ +#define DEBUG 3 + #include #include #include @@ -68,16 +70,23 @@ #define DAVINCI_MCBSP_RCR_RDATDLY(v) ((v) << 16) #define DAVINCI_MCBSP_RCR_RFIG (1 << 18) #define DAVINCI_MCBSP_RCR_RWDLEN2(v) ((v) << 21) +#define DAVINCI_MCBSP_RCR_RFRLEN2(v) ((v) << 24) +#define DAVINCI_MCBSP_RCR_RPHASE (1 << 31) #define DAVINCI_MCBSP_XCR_XWDLEN1(v) ((v) << 5) #define DAVINCI_MCBSP_XCR_XFRLEN1(v) ((v) << 8) #define DAVINCI_MCBSP_XCR_XDATDLY(v) ((v) << 16) #define DAVINCI_MCBSP_XCR_XFIG (1 << 18) #define DAVINCI_MCBSP_XCR_XWDLEN2(v) ((v) << 21) +#define DAVINCI_MCBSP_XCR_XFRLEN2(v) ((v) << 24) +#define DAVINCI_MCBSP_XCR_XPHASE (1 << 31) + +#define CLKGDV(v) (v) /* Bits 0:7 */ #define DAVINCI_MCBSP_SRGR_FWID(v) ((v) << 8) #define DAVINCI_MCBSP_SRGR_FPER(v) ((v) << 16) #define DAVINCI_MCBSP_SRGR_FSGM (1 << 28) +#define DAVINCI_MCBSP_SRGR_CLKSM (1 << 29) #define DAVINCI_MCBSP_PCR_CLKRP (1 << 0) #define DAVINCI_MCBSP_PCR_CLKXP (1 << 1) @@ -89,6 +98,11 @@ #define DAVINCI_MCBSP_PCR_FSRM (1 << 10) #define DAVINCI_MCBSP_PCR_FSXM (1 << 11) +/* this define works when both clock and FS are output for the cpu + and makes clock very fast (FS is not simmetrical, but sampling + frequency is better approximated */ +#define I2S_FAST_CLOCK + enum { DAVINCI_MCBSP_WORD_8 = 0, DAVINCI_MCBSP_WORD_12, @@ -146,6 +160,14 @@ struct davinci_mcbsp_dev { unsigned enable_channel_combine:1; }; +struct davinci_mcbsp_data { + unsigned int fmt; + int clk_div; +}; + +static struct davinci_mcbsp_data mcbsp_data; + + static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev *dev, int reg, u32 val) { @@ -197,7 +219,7 @@ static void davinci_mcbsp_start(struct davinci_mcbsp_dev *dev, int ret = platform->pcm_ops->trigger(substream, SNDRV_PCM_TRIGGER_STOP); if (ret < 0) - printk(KERN_DEBUG "Playback DMA stop failed\n"); + pr_debug("Playback DMA stop failed\n"); } /* Enable the transmitter */ @@ -219,7 +241,7 @@ static void davinci_mcbsp_start(struct davinci_mcbsp_dev *dev, int ret = platform->pcm_ops->trigger(substream, SNDRV_PCM_TRIGGER_START); if (ret < 0) - printk(KERN_DEBUG "Playback DMA start failed\n"); + pr_debug("Playback DMA start failed\n"); } } @@ -254,12 +276,15 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai *cpu_dai, struct davinci_mcbsp_dev *dev = cpu_dai->private_data; unsigned int pcr; unsigned int srgr; - srgr = DAVINCI_MCBSP_SRGR_FSGM | + srgr = DAVINCI_MCBSP_SRGR_FSGM | DAVINCI_MCBSP_SRGR_FPER(DEFAULT_BITPERSAMPLE * 2 - 1) | DAVINCI_MCBSP_SRGR_FWID(DEFAULT_BITPERSAMPLE - 1); + /* Attention srgr is updated by hw_params! */ + mcbsp_data.fmt = fmt; /* set master/slave audio interface */ switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) { + case SND_SOC_DAIFMT_CBS_CFM: case SND_SOC_DAIFMT_CBS_CFS: /* cpu is master */ pcr = DAVINCI_MCBSP_PCR_FSXM | @@ -279,7 +304,7 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai *cpu_dai, pcr = 0; break; default: - printk(KERN_ERR "%s:bad master\n", __func__); + dev_err(dev, "%s:bad master\n", __func__); return -EINVAL; } @@ -310,7 +335,7 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai *cpu_dai, dev->mode = MOD_DSP_B; break; default: - printk(KERN_ERR "%s:bad format\n", __func__); + dev_err(dev, "%s:bad format\n", __func__); return -EINVAL; } @@ -372,6 +397,25 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai *cpu_dai, return 0; } +static int davinci_i2s_dai_set_clkdiv (struct snd_soc_dai *cpu_dai, + int div_id, int div) +{ + struct davinci_mcbsp_dev *dev = cpu_dai->private_data; + int srgr; + + mcbsp_data.clk_div = div; +/* register set in hw_params: not needed here + srgr = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SRGR_REG); + srgr |= CLKGDV(div - 1); + davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SRGR_REG, srgr); + pr_debug("%s - %d DIV set re-read srgr = %X \n", + __func__,__LINE__, davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SRGR_REG)); +*/ + + return 0; +} + + static int davinci_i2s_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params, struct snd_soc_dai *dai) @@ -380,11 +424,12 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream *substream, struct davinci_pcm_dma_params *dma_params = &dev->dma_params[substream->stream]; struct snd_interval *i = NULL; - int mcbsp_word_length; - unsigned int rcr, xcr, srgr; + int mcbsp_word_length, master; + unsigned int rcr, xcr, srgr, clk_div, freq, framesize; u32 spcr; snd_pcm_format_t fmt; unsigned element_cnt = 1; + struct clk *clk; /* general line settings */ spcr = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG); @@ -396,12 +441,51 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream *substream, davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, spcr); } - i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_SAMPLE_BITS); - srgr = DAVINCI_MCBSP_SRGR_FSGM; - srgr |= DAVINCI_MCBSP_SRGR_FWID(snd_interval_value(i) - 1); + master = mcbsp_data.fmt & SND_SOC_DAIFMT_MASTER_MASK; + fmt = params_format(params); + mcbsp_word_length = asp_word_length[fmt]; - i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_FRAME_BITS); - srgr |= DAVINCI_MCBSP_SRGR_FPER(snd_interval_value(i) - 1); + if (master == SND_SOC_DAIFMT_CBS_CFS) { + clk = clk_get(NULL, "pll1_sysclk6");//"pll1"); + if (clk) + freq = clk_get_rate(clk); + freq = 122000000; /* FIXME ask to Texas */ +#ifdef I2S_FAST_CLOCK + clk_div=256; + do { + framesize = (freq / (--clk_div)) / params->rate_num * params->rate_den; + } while ( ((framesize < 33) || (framesize > 4095)) && (clk_div) ); + clk_div--; + srgr = DAVINCI_MCBSP_SRGR_FSGM | DAVINCI_MCBSP_SRGR_CLKSM; + srgr |= DAVINCI_MCBSP_SRGR_FWID(mcbsp_word_length*8-1); + srgr |= DAVINCI_MCBSP_SRGR_FPER(framesize - 1); +#else + /* simmetric waveforms */ + srgr = DAVINCI_MCBSP_SRGR_FSGM | DAVINCI_MCBSP_SRGR_CLKSM; + srgr |= DAVINCI_MCBSP_SRGR_FWID(mcbsp_word_length * 8 - 1); + srgr |= DAVINCI_MCBSP_SRGR_FPER(mcbsp_word_length * 16 - 1); + clk_div = freq / (mcbsp_word_length * 16) / params->rate_num * params->rate_den; +#endif + clk_div &= 0xFF; + srgr |= clk_div; + } else if (master == SND_SOC_DAIFMT_CBS_CFM) { + /* Clock given on CLKS */ + srgr = DAVINCI_MCBSP_SRGR_FSGM; + clk_div = mcbsp_data.clk_div - 1; + srgr |= DAVINCI_MCBSP_SRGR_FWID(mcbsp_word_length * 8 - 1); + srgr |= DAVINCI_MCBSP_SRGR_FPER(mcbsp_word_length * 16 - 1); + clk_div &= 0xFF; + srgr |= clk_div; + } else { + i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_SAMPLE_BITS); + srgr = DAVINCI_MCBSP_SRGR_FSGM; + srgr |= DAVINCI_MCBSP_SRGR_FWID(snd_interval_value(i) - 1); + pr_debug("%s - %d FWID set: re-read srgr = %X \n", + __func__,__LINE__, snd_interval_value(i) - 1 ); + + i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_FRAME_BITS); + srgr |= DAVINCI_MCBSP_SRGR_FPER(snd_interval_value(i) - 1); + } davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SRGR_REG, srgr); rcr = DAVINCI_MCBSP_RCR_RFIG; @@ -416,7 +500,7 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream *substream, /* Determine xfer data type */ fmt = params_format(params); if ((fmt > SNDRV_PCM_FORMAT_S32_LE) || !data_type[fmt]) { - printk(KERN_WARNING "davinci-i2s: unsupported PCM format\n"); + dev_warn(dev, "davinci-i2s: unsupported PCM format\n"); return -EINVAL; } @@ -426,12 +510,29 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream *substream, element_cnt = 1; fmt = double_fmt[fmt]; } + if (master == SND_SOC_DAIFMT_CBS_CFS || master == SND_SOC_DAIFMT_CBS_CFM) { + rcr |= DAVINCI_MCBSP_RCR_RFRLEN2(0); + xcr |= DAVINCI_MCBSP_XCR_XFRLEN2(0); + rcr |= DAVINCI_MCBSP_RCR_RPHASE; + xcr |= DAVINCI_MCBSP_XCR_XPHASE; + } else { + /* FIXME ask to Texas */ + rcr |= DAVINCI_MCBSP_RCR_RFRLEN2(element_cnt - 1); + xcr |= DAVINCI_MCBSP_XCR_XFRLEN2(element_cnt - 1); + } } dma_params->acnt = dma_params->data_type = data_type[fmt]; dma_params->fifo_level = 0; mcbsp_word_length = asp_word_length[fmt]; - rcr |= DAVINCI_MCBSP_RCR_RFRLEN1(element_cnt - 1); - xcr |= DAVINCI_MCBSP_XCR_XFRLEN1(element_cnt - 1); + + if (master == SND_SOC_DAIFMT_CBS_CFS || master == SND_SOC_DAIFMT_CBS_CFM) { + rcr |= DAVINCI_MCBSP_RCR_RFRLEN1(0); + xcr |= DAVINCI_MCBSP_XCR_XFRLEN1(0); + } else { + /* FIXME ask to Texas */ + rcr |= DAVINCI_MCBSP_RCR_RFRLEN1(element_cnt - 1); + xcr |= DAVINCI_MCBSP_XCR_XFRLEN1(element_cnt - 1); + } rcr |= DAVINCI_MCBSP_RCR_RWDLEN1(mcbsp_word_length) | DAVINCI_MCBSP_RCR_RWDLEN2(mcbsp_word_length); @@ -442,6 +543,10 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream *substream, davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_XCR_REG, xcr); else davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_RCR_REG, rcr); + + pr_debug("%s - %d srgr=%X \n",__func__,__LINE__, srgr ); + pr_debug("%s - %d xcr=%X \n",__func__,__LINE__, xcr ); + pr_debug("%s - %d rcr=%X \n",__func__,__LINE__, rcr ); return 0; } @@ -500,7 +605,7 @@ static struct snd_soc_dai_ops davinci_i2s_dai_ops = { .trigger = davinci_i2s_trigger, .hw_params = davinci_i2s_hw_params, .set_fmt = davinci_i2s_set_dai_fmt, - + .set_clkdiv = davinci_i2s_dai_set_clkdiv, }; struct snd_soc_dai davinci_i2s_dai = { -- 1.6.3.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Jun 7 05:15:53 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 7 Jun 2010 12:15:53 +0200 Subject: [PATCH 07/12] davinci: dm365: Fix UART0,1 register addresses Message-ID: From: Davide Bonfanti Date: Fri, 4 Jun 2010 14:05:35 +0200 Subject: [PATCH 07/12] davinci: dm365: Fix UART0,1 register addresses Signed-off-by: Raffaele Recalcati --- arch/arm/mach-davinci/dm365.c | 4 ++-- arch/arm/mach-davinci/include/mach/serial.h | 3 +++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 42fd4a4..e4ead0a 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -1024,7 +1024,7 @@ static struct davinci_timer_info dm365_timer_info = { static struct plat_serial8250_port dm365_serial_platform_data[] = { { - .mapbase = DAVINCI_UART0_BASE, + .mapbase = DM365_UART0_BASE, .irq = IRQ_UARTINT0, .flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_IOREMAP, @@ -1032,7 +1032,7 @@ static struct plat_serial8250_port dm365_serial_platform_data[] = { .regshift = 2, }, { - .mapbase = DAVINCI_UART1_BASE, + .mapbase = DM365_UART1_BASE, .irq = IRQ_UARTINT1, .flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST | UPF_IOREMAP, diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h index f6c4f34..ba8f230 100644 --- a/arch/arm/mach-davinci/include/mach/serial.h +++ b/arch/arm/mach-davinci/include/mach/serial.h @@ -17,6 +17,9 @@ #define DAVINCI_UART1_BASE (IO_PHYS + 0x20400) #define DAVINCI_UART2_BASE (IO_PHYS + 0x20800) +#define DM365_UART0_BASE 0x01C20000 +#define DM365_UART1_BASE 0x01D06000 + #define DA8XX_UART0_BASE (IO_PHYS + 0x042000) #define DA8XX_UART1_BASE (IO_PHYS + 0x10c000) #define DA8XX_UART2_BASE (IO_PHYS + 0x10d000) -- 1.6.3.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Jun 7 05:16:01 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 7 Jun 2010 12:16:01 +0200 Subject: [PATCH 08/12] drivers: mfd: Kconfig Adding comment to MFD_DAVINCI_VOICECODEC Message-ID: From: Raffaele Recalcati Date: Tue, 20 Apr 2010 08:23:56 +0200 Subject: [PATCH 08/12] drivers: mfd: Kconfig Adding comment to MFD_DAVINCI_VOICECODEC It makes more clear the selection. --- drivers/mfd/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index dfbd03f..bf584f0 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -54,7 +54,7 @@ config MFD_SH_MOBILE_SDHI SuperH Mobile SoCs. config MFD_DAVINCI_VOICECODEC - tristate + tristate "DaVinci VoiceCodec" select MFD_CORE config MFD_DM355EVM_MSP -- 1.6.3.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Jun 7 05:16:05 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 7 Jun 2010 12:16:05 +0200 Subject: [PATCH 09/12] mfd: update gfp/slab.h includes Message-ID: From: Tejun Heo Date: Tue, 30 Mar 2010 02:52:40 +0900 Subject: [PATCH 09/12] mfd: update gfp/slab.h includes Implicit slab.h inclusion via percpu.h is about to go away. Make sure gfp.h or slab.h is included as necessary. Signed-off-by: Tejun Heo Acked-by: Samuel Ortiz Signed-off-by: Mark Brown --- drivers/mfd/davinci_voicecodec.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mfd/davinci_voicecodec.c b/drivers/mfd/davinci_voicecodec.c index 9886aa8..3e75f02 100644 --- a/drivers/mfd/davinci_voicecodec.c +++ b/drivers/mfd/davinci_voicecodec.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include #include -- 1.6.3.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamiaposta71 at gmail.com Mon Jun 7 05:16:19 2010 From: lamiaposta71 at gmail.com (Raffaele Recalcati) Date: Mon, 7 Jun 2010 12:16:19 +0200 Subject: [PATCH 11/12] davinci: dm365: fb: support for parallel RGB LCD Message-ID: From: Davide Bonfanti Date: Fri, 4 Jun 2010 14:48:37 +0200 Subject: [PATCH 11/12] davinci: dm365: fb: support for parallel RGB LCD Signed-off-by: Raffaele Recalcati --- arch/arm/mach-davinci/dm365.c | 1 + drivers/video/davincifb.c | 342 +++++++++++++++++++++++++++++++--------- include/video/davincifb.h | 237 ++++++++++++++++++++--------- 3 files changed, 430 insertions(+), 150 deletions(-) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 9968c37..75e4623 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -139,6 +139,7 @@ static struct clk pll1_sysclk6 = { .parent = &pll1_clk, .flags = CLK_PLL, .div_reg = PLLDIV6, + .set_rate = dm365_set_pll1_rate, }; static struct clk pll1_sysclk7 = { diff --git a/drivers/video/davincifb.c b/drivers/video/davincifb.c index 1344be7..ab31fd4 100644 --- a/drivers/video/davincifb.c +++ b/drivers/video/davincifb.c @@ -29,12 +29,16 @@ #include #include +#include #include #include #include