From nsekhar at ti.com Thu Dec 1 04:37:40 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 1 Dec 2011 10:37:40 +0000 Subject: [PATCH v3] da850:ASoC: change audio edma queue eventq to EVENTQ_0 In-Reply-To: <1320905601-9369-1-git-send-email-prakash.pm@ti.com> References: <1320905601-9369-1-git-send-email-prakash.pm@ti.com> Message-ID: Hi Prakash, On Thu, Nov 10, 2011 at 11:43:21, Manjunathappa, Prakash wrote: > Since there was bug in the audio driver, it was not picking the eventq > specified(EVENTQ_1) via platform data and was using EVENTQ_0. And in > system scenario other modules(say video) were using EVENTQ_1. > 48519f0ae03bc7e86b3dc93e56f1334d53803770(ASoC: davinci: let platform > data define edma queue numbers) fixes the bug in driver to pick > specified eventq via platform data. As a result starvation issue is > observed on audio side when audio/video uses same eventq for transfers. > Patch fixes the issue by changing eventq to EVENTQ_0 for audio. > > Signed-off-by: Manjunathappa, Prakash This description was tough for me to parse. After reading through it couple of times, here is what I think the description could have been: " On OMAP-L138 platform, it is desirable to use EDMA event queue 0 for audio transfers so that they are not starved by video data moving on event queue 1. Commit 48519f0ae03bc7e86b3dc93e56f1334d53803770 (ASoC: davinci: let platform data define edma queue numbers) had a side-effect of changing this behavior by making the driver actually honor the platform data passed. Fix this now by passing event queue 0 as the queue to be used for audio transfers. " The headline should have been: ARM: davinci: da850 evm: change audio edma event queue to EVENTQ_0 Notice the use of proper prefixes per current conventions being used in ARM and the dropping of tautological "queue eventq" Also, in future, please do not fail to copy Linux ARM kernel list on kernel patches. I am making an exception this time and not asking you to resubmit since this a fairly trivial change and I got to reviewing this pretty late. Since the bug fix is applicable to previous kernel versions, I will add the stable tag while committing. Thanks, Sekhar From manjunath.hadli at ti.com Fri Dec 2 00:29:49 2011 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Fri, 2 Dec 2011 06:29:49 +0000 Subject: [PATCH v3 0/5] ARM: davinci: re-arrange definitions to have a common davinci header In-Reply-To: References: <1321525138-3928-1-git-send-email-manjunath.hadli@ti.com> Message-ID: Sekhar, On Wed, Nov 30, 2011 at 17:07:21, Nori, Sekhar wrote: > Hi Manju, > > On Thu, Nov 17, 2011 at 15:48:53, Hadli, Manjunath wrote: > > Re-arrange definitions and remove unnecessary code so that we canx > > These are two different things and should be done in separate patches. Sergei has already pointed out couple of instances. Ok, This is only subject for the cover letter and not individual patches. The individual patches have separate modularized implementations. I will change the cover letter subject to "remove private definitions from headers and move to C files". Is that OK? > > > have a common header for all davinci platforms. This will enable > > You mean all DMx platforms? DA8x and TNETVx will still have their own header files after this patch set. Yes, DMx platforms. I will also change the common "davinci.h" to dmx.h ? > > > us to share defines and enable common routines to be used without > > polluting hardware.h. > > This patch set forms the base for a later set of patches for having a > > common system module base address (DAVINCI_SYSTEM_MODULE_BASE). > > > > Changes from previous version(As per Sergei's comments): > > 1. Renamed davinci_common.h to davinci.h. > > 2. Added extra line whereever appropriate. > > 3. removed unnecessary header inclusion. > > > > Manjunath Hadli (5): > > ARM: davinci: dm644x: remove the macros from the header to move to c > > file > > ARM: davinci: dm365: remove the macros from the header to move to c > > file > > ARM: davinci: dm646x: remove the macros from the header to move to c > > file > > These headlines should describe the changes better. You are moving _private_ defines to C file (to reduce header file pollution). That should be clear from the headline. > > > ARM: davinci: create new common platform header for davinci > > ARM: davinci: delete individual platform header files and use a > > common header > > > > arch/arm/mach-davinci/board-dm355-evm.c | 2 +- > > arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- > > arch/arm/mach-davinci/board-dm365-evm.c | 2 +- > > arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- > > arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- > > arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- > > arch/arm/mach-davinci/board-sffsdr.c | 2 +- > > arch/arm/mach-davinci/dm355.c | 2 +- > > arch/arm/mach-davinci/dm365.c | 18 +++++- > > arch/arm/mach-davinci/dm644x.c | 9 +++- > > arch/arm/mach-davinci/dm646x.c | 9 +++- > > arch/arm/mach-davinci/include/mach/davinci.h | 88 ++++++++++++++++++++++++++ > > This file should be placed in arch/arm/mach-davinci itself since the definitions are private to arch/arm/mach-davinci. > Russell has been complaining about placing unnecessary files in include/mach. I will just check if the file is needed from the main driver files. If not, I will move it to mach-davinci. > > Thanks, > Sekhar > > Thanks and Regards, -Manju From hs at denx.de Fri Dec 2 01:35:22 2011 From: hs at denx.de (Heiko Schocher) Date: Fri, 02 Dec 2011 08:35:22 +0100 Subject: arm, am1808: using mmc1 controller and dma Message-ID: <4ED87FBA.40409@denx.de> Hello, trying Linux 3.2.0-rc3 on an am1808 based board using MMCSD1 controller, and facing problems with using DMA. Deactivating use_dma=0 in the davinci_mmc controller and mmc works in pio mode without problems. So there are no hardware problems, pinmux is ok, psc are all on. Tried this on the AM1808 evalboard TMDXEXP1808L, and Linux 3.1 works with DMA without problems. Difference: On the AM1808 Evalboard TMDXEXP1808L MMCSD0 controller is used on my am1808 based board MMCSD1! Debugging in code and found, that on the am1808 evalboard I get on startup (first DMA access): CMD13, arg 0x00000000, R1/R5/R6/R7 response a status back in mmc_davinci_irq(): TRNDNE (0x1000) Transfer done RSPDNE (0x0004) Response succesfully has received DATDNE (0x0001) The data has been fully transmitted On the am1808 based board with using MMCSD1 I get: CMD13, arg 0x00000000, R1/R5/R6/R7 response TRNDNE (0x1000) Transfer done DRRDY (0x0400) MMCDRR is ready New data arrived and can be read by cpu or dma RSPDNE (0x0004) Response succesfully has received after that command, I see no more mmc accesses ... some ideas? Looking in the sprufu5.pdf (AM18x ARM Microprocessor Enhanced Direct Memory Access (EDMA3) Controller" chapter "2.6 Event, Channel, and PaRAM Mapping": "Most of the DMA channels are tied to a specific hardware peripheral event, thus allowing transfers to be triggered by events from device peripherals or external hardware." The mapping is defined in the device specific manual http://www.ti.com/lit/ds/sprs653b/sprs653b.pdf chapter "5.9.1 EDMA3 Channel Synchronization Events" and there I found: EDMA0 Controller Event 16 MMCSD0 Receive EDMA0 Controller Event 17 MMCSD0 Transmit EDMA1 Controller Event 28 MMCSD1 Receive EDMA1 Controller Event 29 MMCSD1 Transmit The Linux 3.1 Code is using EDMA1 Controller Event 28 MMCSD1 Receive EDMA1 Controller Event 29 MMCSD1 Transmit as events for the MMCSD1 controller ... so, this should be ok ... I see no more differences between MMCSD0 and MMCSD1 ... maybe I miss something? Have somebody running an am1808 based board with using MMCSD controller 1? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From sudhakar.raj at ti.com Fri Dec 2 02:34:27 2011 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Fri, 2 Dec 2011 08:34:27 +0000 Subject: arm, am1808: using mmc1 controller and dma In-Reply-To: <4ED87FBA.40409@denx.de> References: <4ED87FBA.40409@denx.de> Message-ID: Hi, On Fri, Dec 02, 2011 at 13:05:22, Heiko Schocher wrote: > Hello, > > trying Linux 3.2.0-rc3 on an am1808 based board using MMCSD1 controller, > and facing problems with using DMA. Deactivating use_dma=0 in the > davinci_mmc controller and mmc works in pio mode without problems. > So there are no hardware problems, pinmux is ok, psc are all on. > Please refer to the discussion at [1] where similar issue was discussed. Go through the entire thread. In the patch posted by Juha in this link, I see that except for the below hunk all others are integrated. @@ -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; Can you check whether the above patch fixes your issue? [1] http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17926.html Thanks, Sudhakar From hs at denx.de Fri Dec 2 02:55:48 2011 From: hs at denx.de (Heiko Schocher) Date: Fri, 02 Dec 2011 09:55:48 +0100 Subject: arm, am1808: using mmc1 controller and dma In-Reply-To: References: <4ED87FBA.40409@denx.de> Message-ID: <4ED89294.6010804@denx.de> Hello Rajashekhara, Sudhakar, Rajashekhara, Sudhakar wrote: > Hi, > > On Fri, Dec 02, 2011 at 13:05:22, Heiko Schocher wrote: >> Hello, >> >> trying Linux 3.2.0-rc3 on an am1808 based board using MMCSD1 controller, >> and facing problems with using DMA. Deactivating use_dma=0 in the >> davinci_mmc controller and mmc works in pio mode without problems. >> So there are no hardware problems, pinmux is ok, psc are all on. >> > > Please refer to the discussion at [1] where similar issue was discussed. Go through the Oh, sorry, missed this! Thanks for the hint! > entire thread. In the patch posted by Juha in this link, I see that except for the below > hunk all others are integrated. > > @@ -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; > > Can you check whether the above patch fixes your issue? Yuhu! that works for me! But I had to fix it a little, because "edma_info" is now named "info". Here my diff: diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index da90103..e10a251 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -1513,7 +1513,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, info[j]->default_queue); queue_tc_mapping = info[j]->queue_tc_mapping; queue_priority_mapping = info[j]->queue_priority_mapping; > [1] http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17926.html Do you prepare a patch, or should I send it? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From sudhakar.raj at ti.com Fri Dec 2 03:00:08 2011 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Fri, 2 Dec 2011 09:00:08 +0000 Subject: arm, am1808: using mmc1 controller and dma In-Reply-To: <4ED89294.6010804@denx.de> References: <4ED87FBA.40409@denx.de> <4ED89294.6010804@denx.de> Message-ID: Hi, On Fri, Dec 02, 2011 at 14:25:48, Heiko Schocher wrote: > Hello Rajashekhara, Sudhakar, > > Rajashekhara, Sudhakar wrote: > > Hi, > > > > On Fri, Dec 02, 2011 at 13:05:22, Heiko Schocher wrote: > >> Hello, > >> > >> trying Linux 3.2.0-rc3 on an am1808 based board using MMCSD1 controller, > >> and facing problems with using DMA. Deactivating use_dma=0 in the > >> davinci_mmc controller and mmc works in pio mode without problems. > >> So there are no hardware problems, pinmux is ok, psc are all on. > >> > > > > Please refer to the discussion at [1] where similar issue was discussed. Go through the [...] > > Yuhu! that works for me! But I had to fix it a little, because "edma_info" > is now named "info". Here my diff: > Yup, this patch was on an older version. > diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c > index da90103..e10a251 100644 > --- a/arch/arm/mach-davinci/dma.c > +++ b/arch/arm/mach-davinci/dma.c > @@ -1513,7 +1513,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, info[j]->default_queue); > > queue_tc_mapping = info[j]->queue_tc_mapping; > queue_priority_mapping = info[j]->queue_priority_mapping; > > > [1] http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17926.html > > Do you prepare a patch, or should I send it? > You can go ahead and submit the patch but Juha was the person who found out this issue. Thanks, Sudhakar From hs at denx.de Fri Dec 2 03:19:57 2011 From: hs at denx.de (Heiko Schocher) Date: Fri, 02 Dec 2011 10:19:57 +0100 Subject: arm, am1808: using mmc1 controller and dma In-Reply-To: References: <4ED87FBA.40409@denx.de> <4ED89294.6010804@denx.de> Message-ID: <4ED8983D.5020400@denx.de> Hello Juha, Rajashekhara, Sudhakar wrote: > Hi, > > On Fri, Dec 02, 2011 at 14:25:48, Heiko Schocher wrote: >> Hello Rajashekhara, Sudhakar, >> >> Rajashekhara, Sudhakar wrote: >>> Hi, >>> >>> On Fri, Dec 02, 2011 at 13:05:22, Heiko Schocher wrote: >>>> Hello, >>>> >>>> trying Linux 3.2.0-rc3 on an am1808 based board using MMCSD1 controller, >>>> and facing problems with using DMA. Deactivating use_dma=0 in the >>>> davinci_mmc controller and mmc works in pio mode without problems. >>>> So there are no hardware problems, pinmux is ok, psc are all on. >>>> >>> Please refer to the discussion at [1] where similar issue was discussed. Go through the > > [...] > >> Yuhu! that works for me! But I had to fix it a little, because "edma_info" >> is now named "info". Here my diff: >> > > Yup, this patch was on an older version. > >> diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c >> index da90103..e10a251 100644 >> --- a/arch/arm/mach-davinci/dma.c >> +++ b/arch/arm/mach-davinci/dma.c >> @@ -1513,7 +1513,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, info[j]->default_queue); >> >> queue_tc_mapping = info[j]->queue_tc_mapping; >> queue_priority_mapping = info[j]->queue_priority_mapping; >> >>> [1] http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg17926.html >> Do you prepare a patch, or should I send it? >> > > You can go ahead and submit the patch but Juha was the person who found out this issue. Juha, can you post this patch, or is it ok for you, if I post it with your "Reported-by" and "Signed-off-by"? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From nsekhar at ti.com Fri Dec 2 06:42:11 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Fri, 2 Dec 2011 12:42:11 +0000 Subject: [PATCH v3 0/5] ARM: davinci: re-arrange definitions to have a common davinci header In-Reply-To: References: <1321525138-3928-1-git-send-email-manjunath.hadli@ti.com> Message-ID: On Fri, Dec 02, 2011 at 11:59:49, Hadli, Manjunath wrote: > Sekhar, > > On Wed, Nov 30, 2011 at 17:07:21, Nori, Sekhar wrote: > > Hi Manju, > > > > On Thu, Nov 17, 2011 at 15:48:53, Hadli, Manjunath wrote: > > > Re-arrange definitions and remove unnecessary code so that we canx > > > > These are two different things and should be done in separate patches. Sergei has already pointed out couple of instances. > Ok, This is only subject for the cover letter and not individual patches. > The individual patches have separate modularized implementations. I will I am referring to the kind of issues Sergei pointed to here: http://linux.omap.com/pipermail/davinci-linux-open-source/2011-November/023524.html > change the cover letter subject to "remove private definitions from headers and move to C files". Is that OK? > Current headline is fine by me. It doesn't become part of commit history anyway. > > > > > > have a common header for all davinci platforms. This will enable > > > > You mean all DMx platforms? DA8x and TNETVx will still have their own header files after this patch set. > > Yes, DMx platforms. I will also change the common "davinci.h" to dmx.h ? No, davinci.h is fine. > > > > > > us to share defines and enable common routines to be used without > > > polluting hardware.h. > > > This patch set forms the base for a later set of patches for having a > > > common system module base address (DAVINCI_SYSTEM_MODULE_BASE). > > > > > > Changes from previous version(As per Sergei's comments): > > > 1. Renamed davinci_common.h to davinci.h. > > > 2. Added extra line whereever appropriate. > > > 3. removed unnecessary header inclusion. > > > > > > Manjunath Hadli (5): > > > ARM: davinci: dm644x: remove the macros from the header to move to c > > > file > > > ARM: davinci: dm365: remove the macros from the header to move to c > > > file > > > ARM: davinci: dm646x: remove the macros from the header to move to c > > > file > > > > These headlines should describe the changes better. You are moving _private_ defines to C file (to reduce header file pollution). That should be clear from the headline. > > > > > ARM: davinci: create new common platform header for davinci > > > ARM: davinci: delete individual platform header files and use a > > > common header > > > > > > arch/arm/mach-davinci/board-dm355-evm.c | 2 +- > > > arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- > > > arch/arm/mach-davinci/board-dm365-evm.c | 2 +- > > > arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- > > > arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- > > > arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- > > > arch/arm/mach-davinci/board-sffsdr.c | 2 +- > > > arch/arm/mach-davinci/dm355.c | 2 +- > > > arch/arm/mach-davinci/dm365.c | 18 +++++- > > > arch/arm/mach-davinci/dm644x.c | 9 +++- > > > arch/arm/mach-davinci/dm646x.c | 9 +++- > > > arch/arm/mach-davinci/include/mach/davinci.h | 88 ++++++++++++++++++++++++++ > > > > This file should be placed in arch/arm/mach-davinci itself since the definitions are private to arch/arm/mach-davinci. > > Russell has been complaining about placing unnecessary files in include/mach. > > I will just check if the file is needed from the main driver files. > If not, I will move it to mach-davinci. Driver files should not need to see machine private stuff. If that's the case, drivers will probably need some clean-up too. Thanks, Sekhar From nsekhar at ti.com Fri Dec 2 09:57:57 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Fri, 2 Dec 2011 15:57:57 +0000 Subject: [PATCH] ARM: mach-davinci: fixed name and parent of pll1 sysclock6 In-Reply-To: <20111104110004.GA15331@altenpts-laptop> References: <20111104110004.GA15331@altenpts-laptop> Message-ID: On Fri, Nov 04, 2011 at 16:30:07, Bas van den Berg wrote: > The name and parent of pll1_sysclk6 should be pll1 and not pll0. > Checked and tested in debugfs on OmapL138. > > Signed-off-by: Bas van den Berg > --- Thanks for spotting this. Looking at the technical reference manual[1], there is a bigger issue here. PLL1 SYSCLK6 doesn't exist in hardware! Only PLL1_SYSCLK[1-3] are valid. The right fix would be simply to remove these erroneous entries. Would be able to respin the patch? Thanks, Sekhar [1] http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf From nsekhar at ti.com Fri Dec 2 11:26:56 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Fri, 2 Dec 2011 17:26:56 +0000 Subject: [PATCH] dm365: nand: Change offset in kernel to in-line with u-boot In-Reply-To: <1320841520-10605-1-git-send-email-akshay.s@ti.com> References: <1320841520-10605-1-git-send-email-akshay.s@ti.com> Message-ID: Hi Akshay, On Wed, Nov 09, 2011 at 17:55:20, Shankarmurthy, Akshay wrote: > Current partition information maintained in kernel does not match with > u-boot, this leads to corruption of u-boot env when we update uImage > from kernel. Patch fixes it to match with u-boot partition information. > > Signed-off-by: Shankarmurthy,Akshay Thanks for the fix. Queuing this for v3.2-rc. While committing, I modified the headline to: ARM: davinci: dm365 evm: align nand partition table to u-boot in order to align to current conventions. Also, in future please copy LAKML on kernel patches without fail. Thanks, Sekhar From member at linkedin.com Sun Dec 4 02:04:31 2011 From: member at linkedin.com (Marcel Katz via LinkedIn) Date: Sun, 4 Dec 2011 08:04:31 +0000 (UTC) Subject: Invitation to connect on LinkedIn Message-ID: <540710501.1874248.1322985871422.JavaMail.app@ela4-bed81.prod> LinkedIn ------------ Marcel Katz requested to add you as a connection on LinkedIn: ------------------------------------------ Markus, I'd like to add you to my professional network on LinkedIn. - Marcel Accept invitation from Marcel Katz http://www.linkedin.com/e/-6res9e-gvrrmnne-5y/vvFWCrP4iVDLPCMMvsUEhA0xEJ-zU4c1qDFPC6sbh2c67ksWv8wEE7JxEJ5LTxxFpNc/blk/I230523861_15/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYRclYNdzwPczkMcP99bS9Cbll6cRZmbPoMej0Ue38UdPcLrCBxbOYWrSlI/EML_comm_afe/?hs=false&tok=2B-iiuQjPAsR01 View invitation from Marcel Katz http://www.linkedin.com/e/-6res9e-gvrrmnne-5y/vvFWCrP4iVDLPCMMvsUEhA0xEJ-zU4c1qDFPC6sbh2c67ksWv8wEE7JxEJ5LTxxFpNc/blk/I230523861_15/3kNnP4Se3cOdj0PcAALqnpPbOYWrSlI/svi/?hs=false&tok=1llEBXxEXAsR01 ------------------------------------------ DID YOU KNOW you can showcase your professional knowledge on LinkedIn to receive job/consulting offers and enhance your professional reputation? Posting replies to questions on LinkedIn Answers puts you in front of the world's professional community. http://www.linkedin.com/e/-6res9e-gvrrmnne-5y/abq/inv-24/?hs=false&tok=0ewetTyL_AsR01 -- (c) 2011, LinkedIn Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From hs at denx.de Sun Dec 4 03:33:30 2011 From: hs at denx.de (Heiko Schocher) Date: Sun, 4 Dec 2011 10:33:30 +0100 Subject: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue Message-ID: <1322991210-20486-1-git-send-email-hs@denx.de> 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. This is tried to fix in commit f23fe857bbea393b4b94fe2218c98d934bd3d4cf from Ido Yariv, but missed a fix for the second MMC controller on da850. Signed-off-by: Heiko Schocher Signed-off-by: juha.kuikka at gmail.com Reported-by: juha.kuikka at gmail.com Cc: linux-mmc at vger.kernel.org Cc: davinci-linux-open-source at linux.davincidsp.com Cc: Rajashekhara, Sudhakar Cc: Ido Yariv Cc: Sekhar Nori Cc: Wolfgang Denk --- arch/arm/mach-davinci/dma.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index da90103..e10a251 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -1513,7 +1513,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, info[j]->default_queue); queue_tc_mapping = info[j]->queue_tc_mapping; queue_priority_mapping = info[j]->queue_priority_mapping; -- 1.7.6.4 From hs at denx.de Sun Dec 4 03:41:19 2011 From: hs at denx.de (Heiko Schocher) Date: Sun, 4 Dec 2011 10:41:19 +0100 Subject: [PATCH] arm,davinci: configure davinci aemif chipselects through OF Message-ID: <1322991679-20947-1-git-send-email-hs@denx.de> Signed-off-by: Heiko Schocher Cc: davinci-linux-open-source at linux.davincidsp.com Cc: devicetree-discuss at lists.ozlabs.org Cc: linux-arm-kernel at lists.infradead.org Cc: grant.likely at secretlab.ca Cc: Sekhar Nori Cc: Kevin Hilman Cc: Wolfgang Denk --- .../devicetree/bindings/arm/davinci/aemif.txt | 85 ++++++++++++++++ arch/arm/mach-davinci/aemif.c | 105 +++++++++++++++++++- arch/arm/mach-davinci/include/mach/aemif.h | 1 + 3 files changed, 190 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt b/Documentation/devicetree/bindings/arm/davinci/aemif.txt new file mode 100644 index 0000000..c9ed551 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt @@ -0,0 +1,85 @@ +* Texas Instruments Davinci AEMIF + +This file provides information, what the device node for the +davinci aemifa interface contain. + +Required properties: +- compatible: "ti,davinci-emifa"; +- #address-cells : Should be either two or three. The first cell is the + chipselect number, and the remaining cells are the + offset into the chipselect. +- #size-cells : Either one or two, depending on how large each chipselect + can be. +- ranges : Each range corresponds to a single chipselect, and cover + the entire access window as configured. + +Optional properties: +- none + +Optional subnodes: +- Chipselect setup: + - Required properties: + - compatible: "ti,davinci-cs"; + - #address-cells = <1>; + - #size-cells = <1>; + + Timing setup, all timings in nanoseconds + - cs: chipselect (value 2,3,4 or 5) + - asize: Asynchronous Data Bus Width. + value: + 0: 8 bit + 1: 16 bit + - ta: Minimum Turn-Around time. + - rhold: Read hold width + - rstrobe: Read strobe width + - rsetup: Read setup width + - whold: Write hold width + - wstrobe: Write strobe width + - wsetup: Write setup width + - ew: Extend Wait bit + value: + 0: Extended wait cycles disabled. + 1: Extended wait cycles enabled. + -ss: Select Strobe bit. + value: + 0: Normal Mode enabled. + 1: Select Strobe Mode enabled. +- CFI driver: + see: Documentation/devicetree/bindings/mtd/mtd-physmap.txt + +Example (enbw_cmc board): + aemif at 60000000 { + compatible = "ti,davinci-emifa"; + #address-cells = <2>; + #size-cells = <1>; + reg = <0x68000000 0x80000>; + ranges = <2 0 0x60000000 0x02000000 + 3 0 0x62000000 0x02000000 + 4 0 0x64000000 0x02000000 + 5 0 0x66000000 0x02000000>; + cs2 at 0x60000000 { + compatible = "ti,davinci-cs"; + #address-cells = <1>; + #size-cells = <1>; + /* all timings in nanoseconds */ + cs = <2>; + asize = <1>; + ta = <0>; + rhold = <7>; + rstrobe = <42>; + rsetup = <14>; + whold = <7>; + wstrobe = <42>; + wsetup = <14>; + ew = <0>; + ss = <0>; + }; + flash at 2,0 { + compatible = "cfi-flash"; + reg = <2 0x0 0x400000>; + #address-cells = <1>; + #size-cells = <1>; + bank-width = <2>; + device-width = <2>; + }; + }; diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c index 1ce70a9..12c559f 100644 --- a/arch/arm/mach-davinci/aemif.c +++ b/arch/arm/mach-davinci/aemif.c @@ -13,12 +13,14 @@ #include #include #include +#include +#include #include #include /* Timing value configuration */ - +#define ASIZE(x) (x) #define TA(x) ((x) << 2) #define RHOLD(x) ((x) << 4) #define RSTROBE(x) ((x) << 7) @@ -26,7 +28,10 @@ #define WHOLD(x) ((x) << 17) #define WSTROBE(x) ((x) << 20) #define WSETUP(x) ((x) << 26) +#define EW(x) ((x) << 30) +#define SS(x) ((x) << 31) +#define ASIZE_MAX 0x1 #define TA_MAX 0x3 #define RHOLD_MAX 0x7 #define RSTROBE_MAX 0x3f @@ -34,6 +39,8 @@ #define WHOLD_MAX 0x7 #define WSTROBE_MAX 0x3f #define WSETUP_MAX 0xf +#define EW_MAX 0x1 +#define SS_MAX 0x1 #define TIMING_MASK (TA(TA_MAX) | \ RHOLD(RHOLD_MAX) | \ @@ -131,3 +138,99 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, return 0; } EXPORT_SYMBOL(davinci_aemif_setup_timing); + +#if defined(CONFIG_OF) +static int dv_get_value(struct device_node *np, const char *name) +{ + const u32 *data; + int len; + + data = of_get_property(np, name, &len); + if (data) + return be32_to_cpu(readl(data)); + + return -EINVAL; +} + +static int davinci_aemif_setup_timing_of_one(struct device_node *np, + void __iomem *base) +{ + unsigned val; + int asize, ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup; + int ew, ss; + int cs; + unsigned offset; + struct clk *aemif_clk; + unsigned long clkrate; + + aemif_clk = clk_get(NULL, "aemif"); + if (IS_ERR(aemif_clk)) + return PTR_ERR(aemif_clk); + + clkrate = clk_get_rate(aemif_clk); + + clkrate /= 1000; /* turn clock into kHz for ease of use */ + + cs = dv_get_value(np, "cs"); + if (cs < 2) + return -EINVAL; + + offset = A1CR_OFFSET + (cs - 2) * 4; + asize = dv_get_value(np, "asize"); + ta = aemif_calc_rate(dv_get_value(np, "ta"), clkrate, TA_MAX); + rhold = aemif_calc_rate(dv_get_value(np, "rhold"), clkrate, + RHOLD_MAX); + rstrobe = aemif_calc_rate(dv_get_value(np, "rstrobe"), clkrate, + RSTROBE_MAX); + rsetup = aemif_calc_rate(dv_get_value(np, "rsetup"), clkrate, + RSETUP_MAX); + whold = aemif_calc_rate(dv_get_value(np, "whold"), clkrate, + WHOLD_MAX); + wstrobe = aemif_calc_rate(dv_get_value(np, "wstrobe"), clkrate, + WSTROBE_MAX); + wsetup = aemif_calc_rate(dv_get_value(np, "wsetup"), clkrate, + WSETUP_MAX); + ew = dv_get_value(np, "ew"); + ss = dv_get_value(np, "ss"); + + if (asize < 0 || ta < 0 || rhold < 0 || rstrobe < 0 || rsetup < 0 || + whold < 0 || wstrobe < 0 || wsetup < 0 || ew < 0 || + ss < 0) { + pr_err("%s: cannot get suitable timings\n", __func__); + return -EINVAL; + } + + val = ASIZE(asize) | TA(ta) | RHOLD(rhold) | RSTROBE(rstrobe) | + RSETUP(rsetup) | WHOLD(whold) | WSTROBE(wstrobe) | + WSETUP(wsetup) | EW(ew) | SS(ss); + + __raw_writel(val, base + offset); + + return 0; +} + +int davinci_aemif_setup_timing_of(void) +{ + struct device_node *np = NULL; + void __iomem *base; + + np = of_find_compatible_node(NULL, NULL, "ti,davinci-emifa"); + if (!np) { + pr_warning("%s: ti,davinci-emifa not found\n", __func__); + return 0; + } + + base = of_iomap(np, 0); + for_each_compatible_node(np, NULL, "ti,davinci-cs") + davinci_aemif_setup_timing_of_one(np, base); + + iounmap(base); + return 0; +} +#else +int davinci_aemif_setup_timing_of(void) +{ + return 0; +} +#endif +EXPORT_SYMBOL(davinci_aemif_setup_timing_of); diff --git a/arch/arm/mach-davinci/include/mach/aemif.h b/arch/arm/mach-davinci/include/mach/aemif.h index 05b2934..1538565 100644 --- a/arch/arm/mach-davinci/include/mach/aemif.h +++ b/arch/arm/mach-davinci/include/mach/aemif.h @@ -33,4 +33,5 @@ struct davinci_aemif_timing { int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, void __iomem *base, unsigned cs); +int davinci_aemif_setup_timing_of(void); #endif -- 1.7.6.4 From sshtylyov at mvista.com Sun Dec 4 06:15:02 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Sun, 04 Dec 2011 16:15:02 +0400 Subject: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue In-Reply-To: <1322991210-20486-1-git-send-email-hs@denx.de> References: <1322991210-20486-1-git-send-email-hs@denx.de> Message-ID: <4EDB6446.2010208@mvista.com> Hello. On 04-12-2011 13:33, Heiko Schocher wrote: > The MMC driver allocates channels with EVENTQ_DEFAULT they Missed comma before "they"? > get put into EVENTQ_1 which the second EDMA controller does > not have and hence transfers stall. This is tried to fix > in commit f23fe857bbea393b4b94fe2218c98d934bd3d4cf Please also specify that commit's summary in parens. > from Ido Yariv, but missed a fix for the second MMC > controller on da850. > Signed-off-by: Heiko Schocher > Signed-off-by: juha.kuikka at gmail.com > Reported-by: juha.kuikka at gmail.com > Cc: linux-mmc at vger.kernel.org > Cc: davinci-linux-open-source at linux.davincidsp.com > Cc: Rajashekhara, Sudhakar > Cc: Ido Yariv > Cc: Sekhar Nori > Cc: Wolfgang Denk WBR, Sergei From sshtylyov at mvista.com Sun Dec 4 06:25:45 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Sun, 04 Dec 2011 16:25:45 +0400 Subject: [PATCH] arm, davinci: configure davinci aemif chipselects through OF In-Reply-To: <1322991679-20947-1-git-send-email-hs@denx.de> References: <1322991679-20947-1-git-send-email-hs@denx.de> Message-ID: <4EDB66C9.9050302@mvista.com> Hello. On 04-12-2011 13:41, Heiko Schocher wrote: > Signed-off-by: Heiko Schocher > Cc: davinci-linux-open-source at linux.davincidsp.com > Cc: devicetree-discuss at lists.ozlabs.org > Cc: linux-arm-kernel at lists.infradead.org > Cc: grant.likely at secretlab.ca > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: Wolfgang Denk > diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c > index 1ce70a9..12c559f 100644 > --- a/arch/arm/mach-davinci/aemif.c > +++ b/arch/arm/mach-davinci/aemif.c [...] > @@ -131,3 +138,99 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, > return 0; > } > EXPORT_SYMBOL(davinci_aemif_setup_timing); > + > +#if defined(CONFIG_OF) > +static int dv_get_value(struct device_node *np, const char *name) > +{ > + const u32 *data; > + int len; > + > + data = of_get_property(np, name,&len); > + if (data) > + return be32_to_cpu(readl(data)); Why readl() here?! Device tree is not a peripheral device... > + > + return -EINVAL; > +} Isn't there already a standard helper for that, of_property_read_u32()? WBR, Sergei From sshtylyov at mvista.com Sun Dec 4 06:33:59 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Sun, 04 Dec 2011 16:33:59 +0400 Subject: [PATCH] arm, davinci: configure davinci aemif chipselects through OF In-Reply-To: <1322991679-20947-1-git-send-email-hs@denx.de> References: <1322991679-20947-1-git-send-email-hs@denx.de> Message-ID: <4EDB68B7.8080609@mvista.com> Hello. On 04-12-2011 13:41, Heiko Schocher wrote: > Signed-off-by: Heiko Schocher > Cc: davinci-linux-open-source at linux.davincidsp.com > Cc: devicetree-discuss at lists.ozlabs.org > Cc: linux-arm-kernel at lists.infradead.org > Cc: grant.likely at secretlab.ca > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: Wolfgang Denk [...] > diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt b/Documentation/devicetree/bindings/arm/davinci/aemif.txt > new file mode 100644 > index 0000000..c9ed551 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt > @@ -0,0 +1,85 @@ > +* Texas Instruments Davinci AEMIF > + > +This file provides information, what the device node for the > +davinci aemifa interface contain. [...] > +Example (enbw_cmc board): > + aemif at 60000000 { > + compatible = "ti,davinci-emifa"; > + #address-cells = <2>; > + #size-cells = <1>; > + reg = <0x68000000 0x80000>; > + ranges = <2 0 0x60000000 0x02000000 > + 3 0 0x62000000 0x02000000 > + 4 0 0x64000000 0x02000000 > + 5 0 0x66000000 0x02000000>; > + cs2 at 0x60000000 { 0x shouldn't be included. > + compatible = "ti,davinci-cs"; > + #address-cells = <1>; > + #size-cells = <1>; > + /* all timings in nanoseconds */ > + cs = <2>; > + asize = <1>; > + ta = <0>; > + rhold = <7>; > + rstrobe = <42>; > + rsetup = <14>; > + whold = <7>; > + wstrobe = <42>; > + wsetup = <14>; > + ew = <0>; > + ss = <0>; > + }; > + flash at 2,0 { Why you have one kind of address for cs2 at 60000000 node and other kind for this node? WBR, Sergei From sudhakar.raj at ti.com Sun Dec 4 07:25:35 2011 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Sun, 4 Dec 2011 13:25:35 +0000 Subject: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue In-Reply-To: <1322991210-20486-1-git-send-email-hs@denx.de> References: <1322991210-20486-1-git-send-email-hs@denx.de> Message-ID: Hi, On Sun, Dec 04, 2011 at 15:03:30, Heiko Schocher wrote: > 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. This is tried to fix > in commit f23fe857bbea393b4b94fe2218c98d934bd3d4cf > from Ido Yariv, but missed a fix for the second MMC > controller on da850. > > Signed-off-by: Heiko Schocher > Signed-off-by: juha.kuikka at gmail.com > Reported-by: juha.kuikka at gmail.com > Cc: linux-mmc at vger.kernel.org > Cc: davinci-linux-open-source at linux.davincidsp.com > Cc: Rajashekhara, Sudhakar > Cc: Ido Yariv > Cc: Sekhar Nori > Cc: Wolfgang Denk > --- > arch/arm/mach-davinci/dma.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c > index da90103..e10a251 100644 > --- a/arch/arm/mach-davinci/dma.c > +++ b/arch/arm/mach-davinci/dma.c > @@ -1513,7 +1513,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, info[j]->default_queue); > > queue_tc_mapping = info[j]->queue_tc_mapping; > queue_priority_mapping = info[j]->queue_priority_mapping; Acked-by: Rajashekhara, Sudhakar Regards, Sudhakar From prakash.pm at ti.com Sun Dec 4 21:15:26 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Mon, 5 Dec 2011 03:15:26 +0000 Subject: [PATCH v3] da850:ASoC: change audio edma queue eventq to EVENTQ_0 In-Reply-To: References: <1320905601-9369-1-git-send-email-prakash.pm@ti.com> Message-ID: Hi Sekhar, On Thu, Dec 01, 2011 at 16:07:40, Nori, Sekhar wrote: > Hi Prakash, > > On Thu, Nov 10, 2011 at 11:43:21, Manjunathappa, Prakash wrote: > > Since there was bug in the audio driver, it was not picking the eventq > > specified(EVENTQ_1) via platform data and was using EVENTQ_0. And in > > system scenario other modules(say video) were using EVENTQ_1. > > 48519f0ae03bc7e86b3dc93e56f1334d53803770(ASoC: davinci: let platform > > data define edma queue numbers) fixes the bug in driver to pick > > specified eventq via platform data. As a result starvation issue is > > observed on audio side when audio/video uses same eventq for transfers. > > Patch fixes the issue by changing eventq to EVENTQ_0 for audio. > > > > Signed-off-by: Manjunathappa, Prakash > > This description was tough for me to parse. After reading through it > couple of times, here is what I think the description could have been: > > " > On OMAP-L138 platform, it is desirable to use EDMA event queue 0 for audio > transfers so that they are not starved by video data moving on event queue 1. > > Commit 48519f0ae03bc7e86b3dc93e56f1334d53803770 (ASoC: davinci: let platform > data define edma queue numbers) had a side-effect of changing this behavior > by making the driver actually honor the platform data passed. > > Fix this now by passing event queue 0 as the queue to be used for audio > transfers. > " > > The headline should have been: > > ARM: davinci: da850 evm: change audio edma event queue to EVENTQ_0 > > Notice the use of proper prefixes per current conventions being used in > ARM and the dropping of tautological "queue eventq" > > Also, in future, please do not fail to copy Linux ARM kernel list on kernel > patches. I am making an exception this time and not asking you to resubmit > since this a fairly trivial change and I got to reviewing this pretty late. > > Since the bug fix is applicable to previous kernel versions, I will add the > stable tag while committing. > > Thanks, > Sekhar > > Thanks for re-writing commit message. Regards, Prakash From nsekhar at ti.com Mon Dec 5 02:51:46 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Mon, 5 Dec 2011 08:51:46 +0000 Subject: [PATCH v2] ARM: restart: davinci: use new restart hook In-Reply-To: <1322513934-23069-1-git-send-email-nsekhar@ti.com> References: <1322513934-23069-1-git-send-email-nsekhar@ti.com> Message-ID: Hi Russell, On Tue, Nov 29, 2011 at 02:28:54, Nori, Sekhar wrote: > Rather than using DaVinci specific davinci_soc_info based > restart hook, use the restart hook available in the machine > descriptor instead. > > Tested on DM365 and AM18x EVMs. > > v2: > Changed to use restart hook in machine descriptor > per Russell's comment. > > Signed-off-by: Sekhar Nori If you are OK with this patch, I will put it into your patch system? Thanks, Sekhar From linux at arm.linux.org.uk Mon Dec 5 02:55:37 2011 From: linux at arm.linux.org.uk (Russell King - ARM Linux) Date: Mon, 5 Dec 2011 08:55:37 +0000 Subject: [PATCH v2] ARM: restart: davinci: use new restart hook In-Reply-To: References: <1322513934-23069-1-git-send-email-nsekhar@ti.com> Message-ID: <20111205085537.GE14542@n2100.arm.linux.org.uk> On Mon, Dec 05, 2011 at 08:51:46AM +0000, Nori, Sekhar wrote: > Hi Russell, > > On Tue, Nov 29, 2011 at 02:28:54, Nori, Sekhar wrote: > > Rather than using DaVinci specific davinci_soc_info based > > restart hook, use the restart hook available in the machine > > descriptor instead. > > > > Tested on DM365 and AM18x EVMs. > > > > v2: > > Changed to use restart hook in machine descriptor > > per Russell's comment. > > > > Signed-off-by: Sekhar Nori > > If you are OK with this patch, I will put it into > your patch system? Yes please. From hs at denx.de Mon Dec 5 04:46:33 2011 From: hs at denx.de (Heiko Schocher) Date: Mon, 05 Dec 2011 11:46:33 +0100 Subject: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue In-Reply-To: References: <1322991210-20486-1-git-send-email-hs@denx.de> Message-ID: <4EDCA109.2090204@denx.de> Hello Rajashekhara, Rajashekhara, Sudhakar wrote: > Hi, > > On Sun, Dec 04, 2011 at 15:03:30, Heiko Schocher wrote: >> 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. This is tried to fix >> in commit f23fe857bbea393b4b94fe2218c98d934bd3d4cf >> from Ido Yariv, but missed a fix for the second MMC >> controller on da850. >> >> Signed-off-by: Heiko Schocher >> Signed-off-by: juha.kuikka at gmail.com >> Reported-by: juha.kuikka at gmail.com >> Cc: linux-mmc at vger.kernel.org >> Cc: davinci-linux-open-source at linux.davincidsp.com >> Cc: Rajashekhara, Sudhakar >> Cc: Ido Yariv >> Cc: Sekhar Nori >> Cc: Wolfgang Denk >> --- >> arch/arm/mach-davinci/dma.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c >> index da90103..e10a251 100644 >> --- a/arch/arm/mach-davinci/dma.c >> +++ b/arch/arm/mach-davinci/dma.c >> @@ -1513,7 +1513,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, info[j]->default_queue); >> >> queue_tc_mapping = info[j]->queue_tc_mapping; >> queue_priority_mapping = info[j]->queue_priority_mapping; > > Acked-by: Rajashekhara, Sudhakar Thanks, but as Ido commented, this patch is no longer necessary, sorry for the noise. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From hs at denx.de Mon Dec 5 04:50:41 2011 From: hs at denx.de (Heiko Schocher) Date: Mon, 05 Dec 2011 11:50:41 +0100 Subject: [PATCH] arm, davinci: configure davinci aemif chipselects through OF In-Reply-To: <4EDB66C9.9050302@mvista.com> References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EDB66C9.9050302@mvista.com> Message-ID: <4EDCA201.4080505@denx.de> Hello Sergei, Sergei Shtylyov wrote: > Hello. > > On 04-12-2011 13:41, Heiko Schocher wrote: > >> Signed-off-by: Heiko Schocher >> Cc: davinci-linux-open-source at linux.davincidsp.com >> Cc: devicetree-discuss at lists.ozlabs.org >> Cc: linux-arm-kernel at lists.infradead.org >> Cc: grant.likely at secretlab.ca >> Cc: Sekhar Nori >> Cc: Kevin Hilman >> Cc: Wolfgang Denk > >> diff --git a/arch/arm/mach-davinci/aemif.c >> b/arch/arm/mach-davinci/aemif.c >> index 1ce70a9..12c559f 100644 >> --- a/arch/arm/mach-davinci/aemif.c >> +++ b/arch/arm/mach-davinci/aemif.c > [...] >> @@ -131,3 +138,99 @@ int davinci_aemif_setup_timing(struct >> davinci_aemif_timing *t, >> return 0; >> } >> EXPORT_SYMBOL(davinci_aemif_setup_timing); >> + >> +#if defined(CONFIG_OF) >> +static int dv_get_value(struct device_node *np, const char *name) >> +{ >> + const u32 *data; >> + int len; >> + >> + data = of_get_property(np, name,&len); >> + if (data) >> + return be32_to_cpu(readl(data)); > > Why readl() here?! Device tree is not a peripheral device... > >> + >> + return -EINVAL; >> +} > > Isn't there already a standard helper for that, of_property_read_u32()? Yep, fixed that. Thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From hs at denx.de Mon Dec 5 05:49:04 2011 From: hs at denx.de (Heiko Schocher) Date: Mon, 05 Dec 2011 12:49:04 +0100 Subject: [PATCH] arm, davinci: configure davinci aemif chipselects through OF In-Reply-To: <4EDB68B7.8080609@mvista.com> References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EDB68B7.8080609@mvista.com> Message-ID: <4EDCAFB0.1080009@denx.de> Hello Sergei, Sergei Shtylyov wrote: > Hello. > > On 04-12-2011 13:41, Heiko Schocher wrote: > >> Signed-off-by: Heiko Schocher >> Cc: davinci-linux-open-source at linux.davincidsp.com >> Cc: devicetree-discuss at lists.ozlabs.org >> Cc: linux-arm-kernel at lists.infradead.org >> Cc: grant.likely at secretlab.ca >> Cc: Sekhar Nori >> Cc: Kevin Hilman >> Cc: Wolfgang Denk > [...] > >> diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt >> b/Documentation/devicetree/bindings/arm/davinci/aemif.txt >> new file mode 100644 >> index 0000000..c9ed551 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt >> @@ -0,0 +1,85 @@ >> +* Texas Instruments Davinci AEMIF >> + >> +This file provides information, what the device node for the >> +davinci aemifa interface contain. > [...] >> +Example (enbw_cmc board): >> + aemif at 60000000 { >> + compatible = "ti,davinci-emifa"; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + reg = <0x68000000 0x80000>; >> + ranges = <2 0 0x60000000 0x02000000 >> + 3 0 0x62000000 0x02000000 >> + 4 0 0x64000000 0x02000000 >> + 5 0 0x66000000 0x02000000>; >> + cs2 at 0x60000000 { > > 0x shouldn't be included. fixed. >> + compatible = "ti,davinci-cs"; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + /* all timings in nanoseconds */ >> + cs = <2>; >> + asize = <1>; >> + ta = <0>; >> + rhold = <7>; >> + rstrobe = <42>; >> + rsetup = <14>; >> + whold = <7>; >> + wstrobe = <42>; >> + wsetup = <14>; >> + ew = <0>; >> + ss = <0>; >> + }; >> + flash at 2,0 { > > Why you have one kind of address for cs2 at 60000000 node and other kind > for this node? Typo it must be cs2 at 68000010 { [...] } As the chipselect registers start @0x68000000 maybe I should add in ranges a "x 0 0x68000000 0x00080000" line? But which value has x, as this range has no chipselect? So I could add subnodes "cs2 at 680000yy" with a reg entry "reg = ;" with yy = offset from 0x68000000 and drop the "cs" property? Or are the "ti,davinci-cs" nodes no subnodes from "ti,davinci-emifa", so I easy can use "reg = <0x68000010 4>;"? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From nsekhar at ti.com Mon Dec 5 06:49:11 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Mon, 5 Dec 2011 12:49:11 +0000 Subject: [GIT PULL] DaVinci fixes for v3.2-rc Message-ID: Hi Arnd, Please pull the following DaVinci fixes for the next v3.2-rc release. None of these are v3.2 regressions, but I have marked only two of these with stable tag since rest are not very critical. Thanks, Sekhar The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416: Linus Torvalds (1): Linux 3.2-rc4 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git fixes Hans Verkuil (1): ARM: davinci: dm646x evm: wrong register used in setup_vpif_input_channel_mode Manjunathappa, Prakash (1): ARM: davinci: da850 evm: change audio edma event queue to EVENTQ_0 Murali Karicheri (2): ARM: davinci: psc: fix incorrect mask ARM: davinci: psc: fix incorrect offsets Sekhar Nori (1): ARM: davinci: dm646x does not have a DSP domain Shankarmurthy,Akshay (1): ARM: davinci: dm365 evm: align nand partition table to u-boot arch/arm/mach-davinci/board-da850-evm.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm646x-evm.c | 6 +++--- arch/arm/mach-davinci/dm646x.c | 1 - arch/arm/mach-davinci/include/mach/psc.h | 5 ++++- arch/arm/mach-davinci/psc.c | 18 +++++++++--------- 6 files changed, 18 insertions(+), 16 deletions(-) From prakash.pm at ti.com Tue Dec 6 04:45:59 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Tue, 6 Dec 2011 16:15:59 +0530 Subject: [PATCH] ARM: davinci: dm368 evm: add support for CPLD version specific cpu_is_* macro Message-ID: <1323168359-17943-1-git-send-email-prakash.pm@ti.com> From: Rajashekhara, Sudhakar DM368 and DM365 EVMs have different CPLD versions. This patch adds function which differentiates DM368 from DM365 EVMs. Signed-off-by: Rajashekhara, Sudhakar --- arch/arm/mach-davinci/include/mach/common.h | 1 + arch/arm/mach-davinci/include/mach/cputype.h | 11 +++++++++++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h index a57cba2..f89cd2a 100644 --- a/arch/arm/mach-davinci/include/mach/common.h +++ b/arch/arm/mach-davinci/include/mach/common.h @@ -52,6 +52,7 @@ struct davinci_soc_info { u32 cpu_id; u32 jtag_id; u32 jtag_id_reg; + u8 cpld_version; struct davinci_id *ids; unsigned long ids_num; struct clk_lookup *cpu_clks; diff --git a/arch/arm/mach-davinci/include/mach/cputype.h b/arch/arm/mach-davinci/include/mach/cputype.h index 957fb87..ef02ab1 100644 --- a/arch/arm/mach-davinci/include/mach/cputype.h +++ b/arch/arm/mach-davinci/include/mach/cputype.h @@ -49,6 +49,15 @@ IS_DAVINCI_CPU(da830, DAVINCI_CPU_ID_DA830) IS_DAVINCI_CPU(da850, DAVINCI_CPU_ID_DA850) IS_DAVINCI_CPU(tnetv107x, DAVINCI_CPU_ID_TNETV107X) +#define IS_DAVINCI_CPU_CPLD_VER(type, id, cpld_ver) \ +static inline int is_davinci_ ##type(void) \ +{ \ + return ((davinci_soc_info.cpu_id == (id)) && \ + (davinci_soc_info.cpld_version == (cpld_ver))); \ +} + +IS_DAVINCI_CPU_CPLD_VER(dm368, DAVINCI_CPU_ID_DM365, 0x21) + #ifdef CONFIG_ARCH_DAVINCI_DM644x #define cpu_is_davinci_dm644x() is_davinci_dm644x() #else @@ -69,8 +78,10 @@ IS_DAVINCI_CPU(tnetv107x, DAVINCI_CPU_ID_TNETV107X) #ifdef CONFIG_ARCH_DAVINCI_DM365 #define cpu_is_davinci_dm365() is_davinci_dm365() +#define cpu_is_davinci_dm368() is_davinci_dm368() #else #define cpu_is_davinci_dm365() 0 +#define cpu_is_davinci_dm368() 0 #endif #ifdef CONFIG_ARCH_DAVINCI_DA830 -- 1.7.1 From sshtylyov at mvista.com Tue Dec 6 05:40:25 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Tue, 06 Dec 2011 15:40:25 +0400 Subject: [PATCH] ARM: davinci: dm368 evm: add support for CPLD version specific cpu_is_* macro In-Reply-To: <1323168359-17943-1-git-send-email-prakash.pm@ti.com> References: <1323168359-17943-1-git-send-email-prakash.pm@ti.com> Message-ID: <4EDDFF29.1020009@mvista.com> Hello. On 06-12-2011 14:45, Manjunathappa, Prakash wrote: > From: Rajashekhara, Sudhakar > DM368 and DM365 EVMs have different CPLD versions. This patch > adds function which differentiates DM368 from DM365 EVMs. > Signed-off-by: Rajashekhara, Sudhakar > --- > arch/arm/mach-davinci/include/mach/common.h | 1 + > arch/arm/mach-davinci/include/mach/cputype.h | 11 +++++++++++ > 2 files changed, 12 insertions(+), 0 deletions(-) > diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h > index a57cba2..f89cd2a 100644 > --- a/arch/arm/mach-davinci/include/mach/common.h > +++ b/arch/arm/mach-davinci/include/mach/common.h > @@ -52,6 +52,7 @@ struct davinci_soc_info { > u32 cpu_id; > u32 jtag_id; > u32 jtag_id_reg; > + u8 cpld_version; Come on, CPLD is not a part of a SoC and the structure is called *davinci_soc_info*. > diff --git a/arch/arm/mach-davinci/include/mach/cputype.h b/arch/arm/mach-davinci/include/mach/cputype.h > index 957fb87..ef02ab1 100644 > --- a/arch/arm/mach-davinci/include/mach/cputype.h > +++ b/arch/arm/mach-davinci/include/mach/cputype.h > @@ -49,6 +49,15 @@ IS_DAVINCI_CPU(da830, DAVINCI_CPU_ID_DA830) > IS_DAVINCI_CPU(da850, DAVINCI_CPU_ID_DA850) > IS_DAVINCI_CPU(tnetv107x, DAVINCI_CPU_ID_TNETV107X) > > +#define IS_DAVINCI_CPU_CPLD_VER(type, id, cpld_ver) \ > +static inline int is_davinci_ ##type(void) \ > +{ \ > + return ((davinci_soc_info.cpu_id == (id))&& \ > + (davinci_soc_info.cpld_version == (cpld_ver))); \ > +} > + > +IS_DAVINCI_CPU_CPLD_VER(dm368, DAVINCI_CPU_ID_DM365, 0x21) > + If DM365 is indistinguishable from DM368 except when being on an EVM board, so be it. WBR, Sergei From arnd at arndb.de Tue Dec 6 08:21:07 2011 From: arnd at arndb.de (Arnd Bergmann) Date: Tue, 6 Dec 2011 14:21:07 +0000 Subject: [GIT PULL] DaVinci fixes for v3.2-rc In-Reply-To: References: Message-ID: <201112061421.07357.arnd@arndb.de> On Monday 05 December 2011, Nori, Sekhar wrote: > Please pull the following DaVinci fixes for > the next v3.2-rc release. None of these are > v3.2 regressions, but I have marked only two > of these with stable tag since rest are not > very critical. Ok, thanks for the info! > The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416: > Linus Torvalds (1): > Linux 3.2-rc4 > > are available in the git repository at: > > git://gitorious.org/linux-davinci/linux-davinci.git fixes Pulled. Arnd From nsekhar at ti.com Tue Dec 6 13:09:31 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 6 Dec 2011 19:09:31 +0000 Subject: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue In-Reply-To: <4EDCA109.2090204@denx.de> References: <1322991210-20486-1-git-send-email-hs@denx.de> <4EDCA109.2090204@denx.de> Message-ID: On Mon, Dec 05, 2011 at 16:16:33, Heiko Schocher wrote: > > Thanks, but as Ido commented, this patch is no longer necessary, sorry > for the noise. > It doesn't look like Ido's comment reached me or the archives. Can you please forward it? Thanks, Sekhar From ajhernandez at ti.com Tue Dec 6 13:15:48 2011 From: ajhernandez at ti.com (Hernandez, Alejandro) Date: Tue, 6 Dec 2011 19:15:48 +0000 Subject: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue In-Reply-To: References: <1322991210-20486-1-git-send-email-hs@denx.de> <4EDCA109.2090204@denx.de> Message-ID: Sekhar, Do you still want me to try the patch? Thanks, Alejandro -----Original Message----- From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci-linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Nori, Sekhar Sent: Tuesday, December 06, 2011 2:10 PM To: hs at denx.de; Rajashekhara, Sudhakar Cc: davinci-linux-open-source at linux.davincidsp.com; Wolfgang Denk; linux-mmc at vger.kernel.org; Ido Yariv; linux-arm-kernel at lists.infradead.org Subject: RE: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue On Mon, Dec 05, 2011 at 16:16:33, Heiko Schocher wrote: > > Thanks, but as Ido commented, this patch is no longer necessary, sorry > for the noise. > It doesn't look like Ido's comment reached me or the archives. Can you please forward it? Thanks, Sekhar _______________________________________________ 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 hs at denx.de Wed Dec 7 00:22:23 2011 From: hs at denx.de (Heiko Schocher) Date: Wed, 07 Dec 2011 07:22:23 +0100 Subject: [Fwd: Re: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue] Message-ID: <4EDF061F.7080302@denx.de> Hello Sekhar, here the forwarded comment from Ido Yariv to my patch. I tried with current kernel MMC Controller 2 on my am1808 based board without my fix, and it works fine, so no need for applying my patch. Thanks bye, Heiko here the message from Ido: Betreff: Re: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue Datum: Mon, 5 Dec 2011 10:35:10 +0200 Von: Ido Yariv An: hs at denx.de CC: juha.kuikka at gmail.com Referenzen: <1322991210-20486-1-git-send-email-hs at denx.de> <20111204102741.GL32400 at WorkStation> <4EDC7C00.30603 at denx.de> Hi Heiko, On Dec 5, 2011 10:08 AM, "Heiko Schocher" wro > Ok ... patch not longer needed, but isn't it better to setup here > immediately the right values? If so, I can sent a v2 with your > suggested comment change. These are just default values which will get overwritten later on, so im not sure if it matters much. I guess it wouldn't hurt to use default_queue instead of queue 1. In any case, if you do chose to submit v2, the commit message should also be changed if it doesnt really fix anything. Thanks, Ido. -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From nsekhar at ti.com Wed Dec 7 04:44:35 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Wed, 7 Dec 2011 10:44:35 +0000 Subject: [PATCH] arm,davinci: configure davinci aemif chipselects through OF In-Reply-To: <1322991679-20947-1-git-send-email-hs@denx.de> References: <1322991679-20947-1-git-send-email-hs@denx.de> Message-ID: Hi Heiko, On Sun, Dec 04, 2011 at 15:11:19, Heiko Schocher wrote: Please provide a patch description. Nice to see device tree support being added for DaVinci devices. > Signed-off-by: Heiko Schocher > Cc: davinci-linux-open-source at linux.davincidsp.com > Cc: devicetree-discuss at lists.ozlabs.org > Cc: linux-arm-kernel at lists.infradead.org > Cc: grant.likely at secretlab.ca > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: Wolfgang Denk > --- > .../devicetree/bindings/arm/davinci/aemif.txt | 85 ++++++++++++++++ > arch/arm/mach-davinci/aemif.c | 105 +++++++++++++++++++- > arch/arm/mach-davinci/include/mach/aemif.h | 1 + > 3 files changed, 190 insertions(+), 1 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt > > diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt b/Documentation/devicetree/bindings/arm/davinci/aemif.txt > new file mode 100644 > index 0000000..c9ed551 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt > @@ -0,0 +1,85 @@ > +* Texas Instruments Davinci AEMIF > + > +This file provides information, what the device node for the > +davinci aemifa interface contain. ^^^^^^ aemif > + > +Required properties: > +- compatible: "ti,davinci-emifa"; > +- #address-cells : Should be either two or three. The first cell is the > + chipselect number, and the remaining cells are the > + offset into the chipselect. > +- #size-cells : Either one or two, depending on how large each chipselect > + can be. > +- ranges : Each range corresponds to a single chipselect, and cover > + the entire access window as configured. > + > +Optional properties: > +- none > + > +Optional subnodes: > +- Chipselect setup: > + - Required properties: > + - compatible: "ti,davinci-cs"; > + - #address-cells = <1>; > + - #size-cells = <1>; > + > + Timing setup, all timings in nanoseconds > + - cs: chipselect (value 2,3,4 or 5) > + - asize: Asynchronous Data Bus Width. > + value: > + 0: 8 bit > + 1: 16 bit > + - ta: Minimum Turn-Around time. > + - rhold: Read hold width > + - rstrobe: Read strobe width > + - rsetup: Read setup width > + - whold: Write hold width > + - wstrobe: Write strobe width > + - wsetup: Write setup width > + - ew: Extend Wait bit > + value: > + 0: Extended wait cycles disabled. > + 1: Extended wait cycles enabled. > + -ss: Select Strobe bit. > + value: > + 0: Normal Mode enabled. > + 1: Select Strobe Mode enabled. > +- CFI driver: > + see: Documentation/devicetree/bindings/mtd/mtd-physmap.txt > + > +Example (enbw_cmc board): > + aemif at 60000000 { > + compatible = "ti,davinci-emifa"; > + #address-cells = <2>; > + #size-cells = <1>; > + reg = <0x68000000 0x80000>; > + ranges = <2 0 0x60000000 0x02000000 > + 3 0 0x62000000 0x02000000 > + 4 0 0x64000000 0x02000000 > + 5 0 0x66000000 0x02000000>; > + cs2 at 0x60000000 { > + compatible = "ti,davinci-cs"; > + #address-cells = <1>; > + #size-cells = <1>; > + /* all timings in nanoseconds */ > + cs = <2>; > + asize = <1>; > + ta = <0>; > + rhold = <7>; > + rstrobe = <42>; > + rsetup = <14>; > + whold = <7>; > + wstrobe = <42>; > + wsetup = <14>; > + ew = <0>; > + ss = <0>; > + }; > + flash at 2,0 { > + compatible = "cfi-flash"; > + reg = <2 0x0 0x400000>; > + #address-cells = <1>; > + #size-cells = <1>; > + bank-width = <2>; > + device-width = <2>; > + }; > + }; > diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c > index 1ce70a9..12c559f 100644 > --- a/arch/arm/mach-davinci/aemif.c > +++ b/arch/arm/mach-davinci/aemif.c > @@ -13,12 +13,14 @@ > #include > #include > #include > +#include > +#include > #include > > #include > > /* Timing value configuration */ > - > +#define ASIZE(x) (x) > #define TA(x) ((x) << 2) > #define RHOLD(x) ((x) << 4) > #define RSTROBE(x) ((x) << 7) > @@ -26,7 +28,10 @@ > #define WHOLD(x) ((x) << 17) > #define WSTROBE(x) ((x) << 20) > #define WSETUP(x) ((x) << 26) > +#define EW(x) ((x) << 30) > +#define SS(x) ((x) << 31) You are adding support for additional configuration parameters which should be done in a separate patch. > > +#define ASIZE_MAX 0x1 > #define TA_MAX 0x3 > #define RHOLD_MAX 0x7 > #define RSTROBE_MAX 0x3f > @@ -34,6 +39,8 @@ > #define WHOLD_MAX 0x7 > #define WSTROBE_MAX 0x3f > #define WSETUP_MAX 0xf > +#define EW_MAX 0x1 > +#define SS_MAX 0x1 > > #define TIMING_MASK (TA(TA_MAX) | \ > RHOLD(RHOLD_MAX) | \ > @@ -131,3 +138,99 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing *t, > return 0; > } > EXPORT_SYMBOL(davinci_aemif_setup_timing); > + > +#if defined(CONFIG_OF) > +static int dv_get_value(struct device_node *np, const char *name) > +{ > + const u32 *data; > + int len; > + > + data = of_get_property(np, name, &len); > + if (data) > + return be32_to_cpu(readl(data)); > + > + return -EINVAL; > +} > + > +static int davinci_aemif_setup_timing_of_one(struct device_node *np, > + void __iomem *base) > +{ > + unsigned val; > + int asize, ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup; > + int ew, ss; > + int cs; > + unsigned offset; > + struct clk *aemif_clk; > + unsigned long clkrate; > + > + aemif_clk = clk_get(NULL, "aemif"); > + if (IS_ERR(aemif_clk)) > + return PTR_ERR(aemif_clk); > + > + clkrate = clk_get_rate(aemif_clk); > + > + clkrate /= 1000; /* turn clock into kHz for ease of use */ > + > + cs = dv_get_value(np, "cs"); > + if (cs < 2) > + return -EINVAL; > + > + offset = A1CR_OFFSET + (cs - 2) * 4; > + asize = dv_get_value(np, "asize"); > + ta = aemif_calc_rate(dv_get_value(np, "ta"), clkrate, TA_MAX); > + rhold = aemif_calc_rate(dv_get_value(np, "rhold"), clkrate, > + RHOLD_MAX); > + rstrobe = aemif_calc_rate(dv_get_value(np, "rstrobe"), clkrate, > + RSTROBE_MAX); > + rsetup = aemif_calc_rate(dv_get_value(np, "rsetup"), clkrate, > + RSETUP_MAX); > + whold = aemif_calc_rate(dv_get_value(np, "whold"), clkrate, > + WHOLD_MAX); > + wstrobe = aemif_calc_rate(dv_get_value(np, "wstrobe"), clkrate, > + WSTROBE_MAX); > + wsetup = aemif_calc_rate(dv_get_value(np, "wsetup"), clkrate, > + WSETUP_MAX); > + ew = dv_get_value(np, "ew"); > + ss = dv_get_value(np, "ss"); > + > + if (asize < 0 || ta < 0 || rhold < 0 || rstrobe < 0 || rsetup < 0 || > + whold < 0 || wstrobe < 0 || wsetup < 0 || ew < 0 || > + ss < 0) { > + pr_err("%s: cannot get suitable timings\n", __func__); > + return -EINVAL; > + } > + > + val = ASIZE(asize) | TA(ta) | RHOLD(rhold) | RSTROBE(rstrobe) | > + RSETUP(rsetup) | WHOLD(whold) | WSTROBE(wstrobe) | > + WSETUP(wsetup) | EW(ew) | SS(ss); > + > + __raw_writel(val, base + offset); > + > + return 0; > +} This shares a large amount of code with davinci_aemif_setup_timing(). Can you try writing this as a OF wrapper to the existing function? Thanks, Sekhar From jc at eclis.ch Wed Dec 7 05:52:52 2011 From: jc at eclis.ch (Jean-Christian de Rivaz) Date: Wed, 07 Dec 2011 12:52:52 +0100 Subject: Cause of non working GPIO IRQ on a OMAP-L138 Message-ID: <4EDF5394.4050701@eclis.ch> On a OMAP-L138 custom board, the GPIO 5,11 is used as an interrupt for the wl12xx driver. It is declared this way in the board file: #define XBRD_WLAN_IRQ GPIO_TO_PIN(5, 11) static struct wl12xx_platform_data xbrd_wlan_data __initdata = { .irq = -1, .board_ref_clock = WL12XX_REFCLOCK_38, .platform_quirks = WL12XX_PLATFORM_QUIRK_EDGE_IRQ, }; In the init() of the board file: ret = gpio_request_one(XBRD_WLAN_IRQ, GPIOF_IN, "wl12xx_irq"); if (ret) { pr_warning("error request wl12xx irq gpio: %d\n", ret); } xbrd_wlan_data.irq = gpio_to_irq(XBRD_WLAN_IRQ); ret = wl12xx_set_platform_data(&xbrd_wlan_data); if (ret) { pr_warning("error setting wl12xx data: %d\n", ret); } The oscilloscope show that the electrical signal work exactly as expected and described in http://www.lsr.com/downloads/tiwi_r1/TiWi_R1_Datasheet.pdf, page 19, "IRQ OPERATION". The /sys/kernel/debug/gpio entry show the correct state of the line: GPIOs 64-95, DaVinci: gpio-91 (wl12xx_irq ) in lo When the signal is low on the oscilloscope, and GPIOs 64-95, DaVinci: gpio-91 (wl12xx_irq ) in hi When the signal is high on the oscilloscope. So far everything seem to be ok. The problem is that when the wl12xx driver is loader, it complain with the message: wl1271: ERROR ELP wakeup timeout! Reading the code drivers/net/wireless/wl12xx/ps.c show that the driver is clearly waiting for a interrupt at this point. But this is not happening according to /proc/interrupts: 192: 0 GPIO wl1271 And stay always 0. I even connected a 10 Hz periodic square signal to the GPIO 5,11 wire, and the /proc/interrupts never increase. But at the same time, /sys/kernel/debug/gpio is always reporting the true signal state, flipping between "lo" and "hi". I suspect that something is missing in order to connect the "wl12xx_irq" from the GPIO to the "wl1271" of the wl12xx driver. But I can't figure what. Jean-Christian From jc at eclis.ch Wed Dec 7 06:55:34 2011 From: jc at eclis.ch (Jean-Christian de Rivaz) Date: Wed, 07 Dec 2011 13:55:34 +0100 Subject: Cause of non working GPIO IRQ on a OMAP-L138 In-Reply-To: <4EDF5394.4050701@eclis.ch> References: <4EDF5394.4050701@eclis.ch> Message-ID: <4EDF6246.8050105@eclis.ch> Le 07. 12. 11 12:52, Jean-Christian de Rivaz a ?crit : > I suspect that something is missing in order to connect the "wl12xx_irq" > from the GPIO to the "wl1271" of the wl12xx driver. But I can't figure > what. Well, forget all this message. I discovered that months before the line "irq_set_chained_handler(bank_irq, gpio_irq_handler);" was commented out in static int __init davinci_gpio_irq_setup(void). This was a hack to test a problem and was not recovered since. Now the interrupt work as expected. Jean-Christian From anibal.pinto at efacec.com Wed Dec 7 08:13:32 2011 From: anibal.pinto at efacec.com (=?ISO-8859-1?Q?An=EDbal_Almeida_Pinto?=) Date: Wed, 07 Dec 2011 14:13:32 +0000 Subject: OMAP L138 usb_submit_urb return -28 Message-ID: <4EDF748C.8000702@efacec.com> Hi, On an OMAP L138 custom board, the USB is used to conect to a SMS95xx (hub usb + ethernet) that have a Freescale Chip (usb uart conversor) and a eXar chip (usb multiple uart conversor) connected. The eXar and Freescale are self powered connected from the start of boot and the usb port is limited to Full Speed. Both device drivers that talk with the chips return the error -28 when using the function usb_submit_urb. If I disconnect and plug again the chip everything work fine. Anyone have an idea what can cause this problem ? Thanks. Regards, An?bal From timothy.bean at gmail.com Wed Dec 7 09:23:26 2011 From: timothy.bean at gmail.com (Timothy Bean) Date: Wed, 7 Dec 2011 09:23:26 -0600 Subject: NFS boot help Message-ID: This is happening to me with MontaVista. I have been stuck at this point for about 2 weeks... really need to get past this. Here is my output: TFTP from server 192.168.0.50; our IP address is 192.168 .0.100 Filename 'uImage'. Load address: 0x80700000 Loading: *\0x08 ############################################################ ##### \0x09 ################################################### ############## \0x09 ########################################## ####################### \0x09 ################################# ################################ \0x09 ######################## ######################################### \0x09 ############### ################################################## \0x09 ###### # done Bytes transferred = 2028544 (1ef400 hex) ## Booting image at 80700000 ... Image Name: Linux-2.6.18_ pro500-davinci_evm- Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2028480 Bytes = 1.9 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux............ ............................................................ ............................................................ .. done, booting the kernel. Linux version 2.6.18_pro500-davinci_evm-arm_v5t_le (root at tim-dev) (gcc version 4.2.0 (Mo ntaVista 4.2.0-16.0.32.0801914 2008-08-30)) #1 PREEMPT Mon Dec 5 00:26:52 CST 2011 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 Machine: DaVinci EVM Memory policy: ECC disabled, Data cache writeback DaVinci DM6443 variant 0x1 CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Built 1 zonelists. Total pages: 30208 Kernel command line: video=davincifb:vid0=0,2500K:vid1=0,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=ntsc console=ttyS0,115200n8 noinitrd rw ip=192.168.0.100:192 .168.0.50:192.168.0.1:255.255.255.0:::off eth=00:0e:99:02:51:54 root=/dev/nfs nfsroot=192.168.0.50:/home/tim/workdir/ruiva-dm6446-dvsdk2-v2/ruiva-dm6446-dvsdk2-rel/workdir/filesys,nolock rootdelay=5 mem=118M TI DaVinci EMAC: Kernel Boot params Eth address: 00:0e:99:02:51:54 PID hash table entries: 512 (order: 9, 2048 bytes) Clock event device timer0_0 configured with caps set: 03 Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 118MB = 118MB total Memory: 115200KB available (3473K code, 694K data, 172K init) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 DaVinci: 71 gpio irqs WARNING: both IDE and NOR flash are enabled, but share pins. \0x09Disable IDE for NOR support. WARNING: both NAND and NOR flash are enabled, but share pins. \0x09Disable NAND for NOR support. : failed to get UART2 clock ch0 default output "COMPOSITE", mode "NTSC" MUX: initialized LOEEN MUX: initialized LFLDEN VPBE Encoder Initialized LogicPD encoder initialized SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 4096 bind 2048) TCP reno registered Initializing DaVinci McBSP system MUX: initialized MCBSP davinci_spi_board_init: NO spi support VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) squashfs: version 3.1 (2006/08/19) Phillip Lougher JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc. yaffs Dec 5 2011 00:33:41 Installing. SGI XFS with no debug enabled Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered (default) LTT : ltt-facilities init LTT : ltt-facility-core init in kernel davincifb davincifb: dm_osd0_fb: Initial window configuration is invalid. davincifb davincifb: dm_osd0_fb: 720x576x16 at 0,0 with framebuffer size 2025KB davincifb davincifb: dm_vid0_fb: 0x0x16 at 0,0 with framebuffer size 2500KB davincifb davincifb: dm_osd1_fb: 720x480x4 at 0,0 with framebuffer size 675KB davincifb davincifb: dm_vid1_fb: 0x0x16 at 0,0 with framebuffer size 2500KB davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window. DAVINCI-WDT: DaVinci Watchdog Timer: heartbeat 60 sec Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO map 0x1c20000 mem 0xfec20000 (irq = 40) is a 16550A serial8250.0: ttyS1 at MMIO map 0x1c20800 mem 0xfec20800 (irq = 42) is a 16550A RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize netconsole: not configured, aborting TI DaVinci EMAC: MAC address is 00:0e:99:02:51:54 TI DaVinci EMAC Linux version updated 4.0 TI DaVinci EMAC: Installed 1 instances. Linux video capture interface: v2.00 vpfe vpfe.1: DaVinci v4l2 capture driver V1.0 loaded Trying to register davinci display video device. layer=c0be2600,layer->video_dev=c0be2760 Trying to register davinci display video device. layer=c0be2400,layer->video_dev=c0be25 60 davinci_init:DaVinci V4L2 Display Driver V1.0 loaded i2c /dev entries driver TLV320AIC23 I2C version 1.8 (10-Feb-2006) Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx ide0: MMIO-DMA , BIOS settings: hda:pio, hdb:pio Palm Chip BK3710 IDE Register Fail nand_davinci nand_davinci.0: Usi ng soft ECC NAND device: Manufacturer ID: 0xad, Chip ID: 0xda (Hynix NAND 256MiB 3,3V 8-bit) Scanning device for bad blocks Creating 4 MTD partitions on "nand_davinci.0": 0x00000000-0x00040000 : "bootloa der" 0x00040000-0x00060000 : "params" 0x00060000-0x00460000 : "kernel" 0x00460000-0x10000000 : "filesystem" nand_davinci nand_davinci.0: hardware revision: 2.1 Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver musb_hdrc: version 6.0, cppi-dma, host, debug=0 musb_hdrc musb_hdrc: No DMA interrupt line musb_hdrc: USB Host mode controller at c7866000 using DMA, IRQ 12 musb_hdrc musb_hdrc: MUSB HDRC host driver musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mice: PS/2 mouse device common for all mice rtc_davinci_evm rtc_davinci_evm: rtc intf: proc rtc_davinci_evm rtc_davinci_evm: rtc intf: dev (254:0) rtc_davinci_evm rtc_davinci_evm: rtc core: registered rtc_davinci_evm as rtc0 rtc0: hours 12-23 are misreported as duplicate hours 00-11 davinci-mmc davinci-mmc.0: Supporting 4-bit mode davinci-mmc davinci-mmc.0: Using DMA mode aic33 mclk=27MHz davinci mcbsp&aic33 initializing... aic33:set left mic volume to: 50 set right mic volume to: 50 set left volume to: 50 set right volume to: 50 aic33: Enabling line in set left igain to:50 Set right igain to: 50 set left ogain to: 100 Set right ogain to: 100 aic33:set left mic volume to: 50 set right mic volume to: 50 set left volume to: 50 set right volume to: 50 aic33: Enabling line in set left igain to:50 Set right igain to: 50 set left ogain to: 100 Set right ogain to: 100 Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC). ASoC version 0.13.1 AIC3X Audio Codec 0.1 ALSA device list: No soundcards found. IPv4 over IPv4 tunneling driver TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 \0x08Time: timer0_1 clocksource has been installed. Clock event device timer0_0 configured with caps set: 08 Switched to high resolution mode on CPU 0 usb 1-1: new high speed USB device using musb_hdrc and address 2 rtc_davinci_evm rtc_davinci_evm: hctosys: invalid date/time usb 1-1: configuration #1 chosen from 1 choice hub 1-1:1.0: USB hub found hub 1-1:1.0: 2 ports detected IP-Config: Complete: device=eth0, addr=192.168.0.100, mask=255.25 5.255.0, gw=192.168.0.1, host=192.168.0.100, domain=, nis-domain=(none), bootserver=192.168.0.50, rootserver=192.168.0.50, rootpath= Waiting 5sec before mounting root device... Looking up port of RPC 100003/2 on 192.168.0.50 Looking up port of RPC 100005/1 on 192.168.0.50 VFS: Mounted root (nfs filesystem). Freeing init memory: 172K INIT: version 2.86 booting Starting the hotplug events dispatcher: udevd . Synthesizing the initial hotplug events... done. Waiting for /dev to be fully populated... done. Activating swap... done. Remounting root filesystem...done. Calculating module dependencies nfs: server 192.168.0.50 not responding, still trying nfs: server 192.168.0.50 not responding, still trying nfs: server 192.168.0.50 not responding, still trying Do you have any other pointers? I hopefully have attached a wireshark catpure. Maybe someone can look at that and determine what I am doing wrong. This is what I put for my interfaces file: # We always want the loopback interface. auto lo iface lo inet loopback # An example ethernet card setup: (broadcast and gateway are optional) # auto eth0 iface eth0 inet static address 192.168.0.100 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 gateway 192.168.0.1 Firewall is stopped NFS is running and can mount the drive locally File system is exported correctly Seems that it mounts 2 times and on the second just stops after "Calculating module dependencies" Wireshark capture does not seem to show any "errors" filesystem has root ownership. root built file system. Data still being send from EVM to Host, but shows IP fragment not NFS. Tried Arago pre-built. root tar to directory, export directory. Same issue. Modified /etc/network/interfaces with auto eth0 iface eth0 inet static and dhcp. Bot no go. DHCP gets and sets IP adderss to 192.168.0.100 (did this last night) Seems like after 2nd boot that the Linux Ethernet driver kicks in and looses the NFS for some reason? Been working on this for 2 weeks. Need some help or a work around to get going. Can I TFTP the filesystem using U-boot to flash and then run from there? How can I do this? Thanks Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From schen at mvista.com Wed Dec 7 09:39:25 2011 From: schen at mvista.com (Steve Chen) Date: Wed, 7 Dec 2011 09:39:25 -0600 Subject: NFS boot help In-Reply-To: References: Message-ID: On Wed, Dec 7, 2011 at 9:23 AM, Timothy Bean wrote: > ... > > IP-Config: Complete: > > device=eth0, addr=192.168.0.100, mask=255.25 > > 5.255.0, gw=192.168.0.1, > > host=192.168.0.100, domain=, nis-domain=(none), > > bootserver=192.168.0.50, rootserver=192.168.0.50, rootpath= > > Waiting 5sec before mounting root device... > > > > Looking up port of RPC 100003/2 on 192.168.0.50 > > > > Looking up port of RPC 100005/1 on 192.168.0.50 > > > > VFS: Mounted root (nfs filesystem). > > Freeing init memory: 172K > > > > > > INIT: version 2.86 booting > > > > > > > > Starting the hotplug events dispatcher: udevd > > . > > Synthesizing the initial hotplug events... > > done. > > > > Waiting for /dev to be fully populated... > > done. > > > > Activating swap... > > done. > > Remounting root filesystem...done. > > > > Calculating module dependencies > > > > nfs: server 192.168.0.50 not responding, still trying > > > > nfs: server 192.168.0.50 not responding, still trying > > > > nfs: server 192.168.0.50 not responding, still trying > > > > Do you have any other pointers? I hopefully have attached a wireshark > catpure. Maybe someone can look at that and determine what I am doing > wrong. This is what I put for my interfaces file: > > Yes, your analysis is correct that NFS was connected and dropped shortly after. I have seen similar issues when the target board shared the same IP address as another device on the network. You may want to try replacing the kernel command line ... ip=192.168.0.100:192.168.0.50:192.168.0.1:255.255.255.0:::off ... with ... ip=dhcp ... to see if that makes a difference. Or just unplug your board and ping 192.168.0.100 to make sure no-one answers. Regards, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuckmeade at mindspring.com Wed Dec 7 09:47:27 2011 From: chuckmeade at mindspring.com (Chuck Meade) Date: Wed, 07 Dec 2011 10:47:27 -0500 Subject: NFS boot help In-Reply-To: References: Message-ID: <4EDF8A8F.5080405@mindspring.com> On 12/07/2011 10:39 AM, Steve Chen wrote: > > > On Wed, Dec 7, 2011 at 9:23 AM, Timothy Bean > wrote: > > ... > > IP-Config: Complete: > > device=eth0, addr=192.168.0.100, mask=255.25 > > 5.255.0, gw=192.168.0.1, > > host=192.168.0.100, domain=, nis-domain=(none), > > bootserver=192.168.0.50, rootserver=192.168.0.50, rootpath= > > Waiting 5sec before mounting root device... > > > > Looking up port of RPC 100003/2 on 192.168.0.50 > > > > Looking up port of RPC 100005/1 on 192.168.0.50 > > > > VFS: Mounted root (nfs filesystem). > > Freeing init memory: 172K > > > > > > INIT: version 2.86 booting > > > > > > > > Starting the hotplug events dispatcher: udevd > > . > > Synthesizing the initial hotplug events... > > done. > > > > Waiting for /dev to be fully populated... > > done. > > > > Activating swap... > > done. > > Remounting root filesystem...done. > > > > Calculating module dependencies > > > > nfs: server 192.168.0.50 not responding, still trying > > > > nfs: server 192.168.0.50 not responding, still trying > > > > nfs: server 192.168.0.50 not responding, still trying > > > > Do you have any other pointers? I hopefully have attached a wireshark catpure. Maybe someone can look at that and determine what I am doing wrong. This is what I put for my interfaces file: > > > > Yes, your analysis is correct that NFS was connected and dropped shortly after. I have seen similar issues when the target board shared the same IP address as another device on the network. You > may want to try replacing the kernel command line > > ... ip=192.168.0.100:192.168.0.50:192.168.0.1:255.255.255.0:::off ... > > with > > ... ip=dhcp ... > > to see if that makes a difference. Or just unplug your board and ping 192.168.0.100 to make sure no-one answers. > > Regards, > > Steve > Your wireshark capture was not attached (at least I did not get it). The Linux Ethernet driver was working, since NFS mounted successfully. Without seeing the wireshark info I can't tell, but you should check to be sure that some other bootup logic has not changed the target's IP address or Eth MAC address. You mention that the wireshark packets go from looking fine to looking like fragments. Do this same boot sequence, but reduce what is being loaded and run at bootup. Especially reduce the list of modules being loaded, one by one. Then reduce what is being done by the sysv init logic. Boot up after each small change you make. If you can find a point at which you stop seeing the problem, then you have likely found what is causing it. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From timothy.bean at gmail.com Wed Dec 7 09:58:55 2011 From: timothy.bean at gmail.com (Timothy Bean) Date: Wed, 7 Dec 2011 09:58:55 -0600 Subject: NFS boot help In-Reply-To: <4EDF8A8F.5080405@mindspring.com> References: <4EDF8A8F.5080405@mindspring.com> Message-ID: I will try to get it attached tonight. Maybe someone can look at it an spot an issue. I really need to move past this point and haven't gotten anything that gets it working from the TI forums. I am not sure exactly how you would go about reducing teh modules 1 by 1. I am new so bear with me. Thanks Tim On Wed, Dec 7, 2011 at 9:47 AM, Chuck Meade wrote: > ** > On 12/07/2011 10:39 AM, Steve Chen wrote: > > > > On Wed, Dec 7, 2011 at 9:23 AM, Timothy Bean wrote: > >> ... >> >> IP-Config: Complete: >> >> device=eth0, addr=192.168.0.100, mask=255.25 >> >> 5.255.0, gw=192.168.0.1, >> >> host=192.168.0.100, domain=, nis-domain=(none), >> >> bootserver=192.168.0.50, rootserver=192.168.0.50, rootpath= >> >> Waiting 5sec before mounting root device... >> >> >> >> Looking up port of RPC 100003/2 on 192.168.0.50 >> >> >> >> Looking up port of RPC 100005/1 on 192.168.0.50 >> >> >> >> VFS: Mounted root (nfs filesystem). >> >> Freeing init memory: 172K >> >> >> >> >> >> INIT: version 2.86 booting >> >> >> >> >> >> >> >> Starting the hotplug events dispatcher: udevd >> >> . >> >> Synthesizing the initial hotplug events... >> >> done. >> >> >> >> Waiting for /dev to be fully populated... >> >> done. >> >> >> >> Activating swap... >> >> done. >> >> Remounting root filesystem...done. >> >> >> >> Calculating module dependencies >> >> >> >> nfs: server 192.168.0.50 not responding, still trying >> >> >> >> nfs: server 192.168.0.50 not responding, still trying >> >> >> >> nfs: server 192.168.0.50 not responding, still trying >> >> >> >> Do you have any other pointers? I hopefully have attached a wireshark >> catpure. Maybe someone can look at that and determine what I am doing >> wrong. This is what I put for my interfaces file: >> >> > Yes, your analysis is correct that NFS was connected and dropped shortly > after. I have seen similar issues when the target board shared the same IP > address as another device on the network. You may want to try replacing > the kernel command line > > ... ip=192.168.0.100:192.168.0.50:192.168.0.1:255.255.255.0:::off ... > > with > > ... ip=dhcp ... > > to see if that makes a difference. Or just unplug your board and ping > 192.168.0.100 to make sure no-one answers. > > Regards, > > Steve > > > Your wireshark capture was not attached (at least I did not get it). The > Linux Ethernet driver was working, since NFS mounted > successfully. Without seeing the wireshark info I can't tell, but you > should check to be sure that some other bootup logic has not changed > the target's IP address or Eth MAC address. > > You mention that the wireshark packets go from looking fine to looking > like fragments. Do this same boot sequence, but reduce > what is being loaded and run at bootup. Especially reduce the list of > modules being loaded, one by one. Then reduce what is being done by the > sysv init logic. Boot up after each small change you make. If you can > find a point at which you stop seeing the problem, then you have likely > found what is causing it. > > Chuck > > > _______________________________________________ > 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 sudhakar.raj at ti.com Wed Dec 7 10:20:35 2011 From: sudhakar.raj at ti.com (Rajashekhara, Sudhakar) Date: Wed, 7 Dec 2011 16:20:35 +0000 Subject: [Fwd: Re: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue] In-Reply-To: <4EDF061F.7080302@denx.de> References: <4EDF061F.7080302@denx.de> Message-ID: Hi Heiko, On Wed, Dec 07, 2011 at 11:52:23, Heiko Schocher wrote: > Hello Sekhar, > > here the forwarded comment from Ido Yariv to my patch. I tried > with current kernel MMC Controller 2 on my am1808 based board > without my fix, and it works fine, so no need for applying my > patch. > > Thanks > bye, > Heiko > > here the message from Ido: > > Betreff: Re: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue > Datum: Mon, 5 Dec 2011 10:35:10 +0200 > Von: Ido Yariv > An: hs at denx.de > CC: juha.kuikka at gmail.com I think Ido replied to only you and Juha, that's why even I am not able to see his reply on the list. > Referenzen: <1322991210-20486-1-git-send-email-hs at denx.de> <20111204102741.GL32400 at WorkStation> <4EDC7C00.30603 at denx.de> > > Hi Heiko, > > On Dec 5, 2011 10:08 AM, "Heiko Schocher" wro > > Ok ... patch not longer needed, but isn't it better to setup here > > immediately the right values? If so, I can sent a v2 with your > > suggested comment change. > > These are just default values which will get overwritten later on, so im > not sure if it matters much. I guess it wouldn't hurt to use default_queue > instead of queue 1. > It would have helped if you posted the complete message here but I figured this out. I assume that Ido's explanation is as below: EDMA channel is allocated in MMC driver through the call to edma_alloc_channel() api and the last argument passed to this api is the event queue number. Currently the event queue number being passed is EVENTQ_DEFAULT. Inside edma_alloc_channel() there is a call to map_dmach_queue() which also takes event queue number as argument. map_dmach_queue() function initializes the event queue number to default_queue (being passed from platform data), if it is EVENTQ_DEFAULT. I wanted to know why MMC/SD was not working initially for you even with this piece of code? > In any case, if you do chose to submit v2, the commit message should also > be changed if it doesnt really fix anything. I would still say, your patch is the clean way of addressing the issue. May be you can modify the commit message as Ido has pointed out. Sekhar, do you have any comments? Thanks, Sudhakar From chuckmeade at mindspring.com Wed Dec 7 20:57:46 2011 From: chuckmeade at mindspring.com (Chuck Meade) Date: Wed, 07 Dec 2011 21:57:46 -0500 Subject: NFS boot help In-Reply-To: References: <4EDF8A8F.5080405@mindspring.com> Message-ID: <4EE027AA.4070102@mindspring.com> On 12/07/2011 08:51 PM, Timothy Bean wrote: > Here is capture. Thanks for anyone that can look at it and maybe point me in the right direction. I exported as text file and compressed. > > Thanks > > Tim > > On Wed, Dec 7, 2011 at 9:47 AM, Chuck Meade > wrote: > > On 12/07/2011 10:39 AM, Steve Chen wrote: >> >> >> On Wed, Dec 7, 2011 at 9:23 AM, Timothy Bean > wrote: >> >> ... >> >> IP-Config: Complete: >> >> device=eth0, addr=192.168.0.100, mask=255.25 >> >> 5.255.0, gw=192.168.0.1, >> >> host=192.168.0.100, domain=, nis-domain=(none), >> >> bootserver=192.168.0.50, rootserver=192.168.0.50, rootpath= >> >> Waiting 5sec before mounting root device... >> >> >> >> Looking up port of RPC 100003/2 on 192.168.0.50 >> >> >> >> Looking up port of RPC 100005/1 on 192.168.0.50 >> >> >> >> VFS: Mounted root (nfs filesystem). >> >> Freeing init memory: 172K >> >> >> >> >> >> INIT: version 2.86 booting >> >> >> >> >> >> >> >> Starting the hotplug events dispatcher: udevd >> >> . >> >> Synthesizing the initial hotplug events... >> >> done. >> >> >> >> Waiting for /dev to be fully populated... >> >> done. >> >> >> >> Activating swap... >> >> done. >> >> Remounting root filesystem...done. >> >> >> >> Calculating module dependencies >> >> >> >> nfs: server 192.168.0.50 not responding, still trying >> >> >> >> nfs: server 192.168.0.50 not responding, still trying >> >> >> >> nfs: server 192.168.0.50 not responding, still trying >> >> >> >> Do you have any other pointers? I hopefully have attached a wireshark catpure. Maybe someone can look at that and determine what I am doing wrong. This is what I put for my interfaces file: >> >> >> >> Yes, your analysis is correct that NFS was connected and dropped shortly after. I have seen similar issues when the target board shared the same IP address as another device on the network. >> You may want to try replacing the kernel command line >> >> ... ip=192.168.0.100:192.168.0.50:192.168.0.1:255.255.255.0:::off ... >> >> with >> >> ... ip=dhcp ... >> >> to see if that makes a difference. Or just unplug your board and ping 192.168.0.100 to make sure no-one answers. >> >> Regards, >> >> Steve >> > > Your wireshark capture was not attached (at least I did not get it). The Linux Ethernet driver was working, since NFS mounted > successfully. Without seeing the wireshark info I can't tell, but you should check to be sure that some other bootup logic has not changed > the target's IP address or Eth MAC address. > > You mention that the wireshark packets go from looking fine to looking like fragments. Do this same boot sequence, but reduce > what is being loaded and run at bootup. Especially reduce the list of modules being loaded, one by one. Then reduce what is being done by the > sysv init logic. Boot up after each small change you make. If you can find a point at which you stop seeing the problem, then you have likely found what is causing it. > > Chuck > > > I don't see NFS necessarily failing there. Something is causing a read of a large file at the end, and that is after a lot of reads of *.ko files. You can "grep LOOKUP nfs_capture.txt" to see what files were read in that capture. I still suggest that you simplify your boot process. If you cut back on the large number of modules being loaded and strip down your startup sequence, then you may be able to find out what in the startup sequence is causing the problem. The fact that NFS works fine and allows you to read in so many files means that it is at least functional. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From hs at denx.de Thu Dec 8 00:55:57 2011 From: hs at denx.de (Heiko Schocher) Date: Thu, 8 Dec 2011 07:55:57 +0100 Subject: [PATCH v2] arm, da8xx, mmc: set second MMC controllers default queue In-Reply-To: <1322991210-20486-1-git-send-email-hs@denx.de> References: <1322991210-20486-1-git-send-email-hs@denx.de> Message-ID: <1323327357-23886-1-git-send-email-hs@denx.de> 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. This is fixed in commit f23fe857bbea393b4b94fe2218c98d934bd3d4cf "ARM: davinci: Explicitly set channel controllers' default queues" from Ido Yariv. This patch sets immediately in edma_probe() the proper default_queue, so this patch does not really fix something, it is more a cosmetic change. Signed-off-by: Heiko Schocher Signed-off-by: juha.kuikka at gmail.com Reported-by: juha.kuikka at gmail.com Acked-by: Rajashekhara, Sudhakar Cc: linux-mmc at vger.kernel.org Cc: davinci-linux-open-source at linux.davincidsp.com Cc: Rajashekhara, Sudhakar Cc: Ido Yariv Cc: Sekhar Nori Cc: Wolfgang Denk Cc: Sergei Shtylyov --- - changes for v2: - add comment from Sergei Shtylyov add in commit message the commit's summary in parens. - add comment from Ido Yariv: changed comment and commit message - added Acked-by from Rajashekhara, Sudhakar arch/arm/mach-davinci/dma.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c index da90103..a0cabc7 100644 --- a/arch/arm/mach-davinci/dma.c +++ b/arch/arm/mach-davinci/dma.c @@ -1508,12 +1508,14 @@ static int __init edma_probe(struct platform_device *pdev) goto fail; } - /* 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. + /* + * Everything lives on transfer controller 1, except on the + * da850 MMC2 controller, so pass info[j]->default_queue. + * This way, long transfers on the low priority queue 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, info[j]->default_queue); queue_tc_mapping = info[j]->queue_tc_mapping; queue_priority_mapping = info[j]->queue_priority_mapping; -- 1.7.6.4 From hs at denx.de Thu Dec 8 00:56:20 2011 From: hs at denx.de (Heiko Schocher) Date: Thu, 08 Dec 2011 07:56:20 +0100 Subject: [Fwd: Re: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue] In-Reply-To: References: <4EDF061F.7080302@denx.de> Message-ID: <4EE05F94.9050209@denx.de> Hello Rajashekhara, Rajashekhara, Sudhakar wrote: > On Wed, Dec 07, 2011 at 11:52:23, Heiko Schocher wrote: >> Hello Sekhar, >> >> here the forwarded comment from Ido Yariv to my patch. I tried >> with current kernel MMC Controller 2 on my am1808 based board >> without my fix, and it works fine, so no need for applying my >> patch. >> >> Thanks >> bye, >> Heiko >> >> here the message from Ido: >> >> Betreff: Re: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue >> Datum: Mon, 5 Dec 2011 10:35:10 +0200 >> Von: Ido Yariv >> An: hs at denx.de >> CC: juha.kuikka at gmail.com > > I think Ido replied to only you and Juha, that's why even I am not able to see his reply on the list. Ah, yes, you are right, sorry missed that ... >> Referenzen: <1322991210-20486-1-git-send-email-hs at denx.de> <20111204102741.GL32400 at WorkStation> <4EDC7C00.30603 at denx.de> >> >> Hi Heiko, >> >> On Dec 5, 2011 10:08 AM, "Heiko Schocher" wro >>> Ok ... patch not longer needed, but isn't it better to setup here >>> immediately the right values? If so, I can sent a v2 with your >>> suggested comment change. >> These are just default values which will get overwritten later on, so im >> not sure if it matters much. I guess it wouldn't hurt to use default_queue >> instead of queue 1. >> > > It would have helped if you posted the complete message here but I figured > this out. I assume that Ido's explanation is as below: Hmm.. that was the complete message ... > EDMA channel is allocated in MMC driver through the call to > edma_alloc_channel() api and the last argument passed to this api is the > event queue number. Currently the event queue number being passed is > EVENTQ_DEFAULT. Inside edma_alloc_channel() there is a call to > map_dmach_queue() which also takes event queue number as argument. > map_dmach_queue() function initializes the event queue number to > default_queue (being passed from platform data), if it is EVENTQ_DEFAULT. Yep, fully correct. > I wanted to know why MMC/SD was not working initially for you even with > this piece of code? Because I tested with Linux-3.1 where this patch wasn't included ... >> In any case, if you do chose to submit v2, the commit message should also >> be changed if it doesnt really fix anything. > > I would still say, your patch is the clean way of addressing the issue. > May be you can modify the commit message as Ido has pointed out. Ok, send a v2, thanks! > Sekhar, do you have any comments? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From hs at denx.de Thu Dec 8 01:47:05 2011 From: hs at denx.de (Heiko Schocher) Date: Thu, 08 Dec 2011 08:47:05 +0100 Subject: [PATCH] arm, davinci: configure davinci aemif chipselects through OF In-Reply-To: References: <1322991679-20947-1-git-send-email-hs@denx.de> Message-ID: <4EE06B79.7070804@denx.de> Hello Nori, Nori, Sekhar wrote: > Hi Heiko, > > On Sun, Dec 04, 2011 at 15:11:19, Heiko Schocher wrote: > > Please provide a patch description. Nice to see device tree > support being added for DaVinci devices. fixed. >> Signed-off-by: Heiko Schocher >> Cc: davinci-linux-open-source at linux.davincidsp.com >> Cc: devicetree-discuss at lists.ozlabs.org >> Cc: linux-arm-kernel at lists.infradead.org >> Cc: grant.likely at secretlab.ca >> Cc: Sekhar Nori >> Cc: Kevin Hilman >> Cc: Wolfgang Denk >> --- >> .../devicetree/bindings/arm/davinci/aemif.txt | 85 ++++++++++++++++ >> arch/arm/mach-davinci/aemif.c | 105 +++++++++++++++++++- >> arch/arm/mach-davinci/include/mach/aemif.h | 1 + >> 3 files changed, 190 insertions(+), 1 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt >> >> diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt b/Documentation/devicetree/bindings/arm/davinci/aemif.txt >> new file mode 100644 >> index 0000000..c9ed551 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt >> @@ -0,0 +1,85 @@ >> +* Texas Instruments Davinci AEMIF >> + >> +This file provides information, what the device node for the >> +davinci aemifa interface contain. > ^^^^^^ > aemif fixed, thanks. >> + >> +Required properties: >> +- compatible: "ti,davinci-emifa"; Shouldn't this also be "ti,davinci-aemif" ? [...] >> diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c >> index 1ce70a9..12c559f 100644 >> --- a/arch/arm/mach-davinci/aemif.c >> +++ b/arch/arm/mach-davinci/aemif.c >> @@ -13,12 +13,14 @@ >> #include >> #include >> #include >> +#include >> +#include >> #include >> >> #include >> >> /* Timing value configuration */ >> - >> +#define ASIZE(x) (x) >> #define TA(x) ((x) << 2) >> #define RHOLD(x) ((x) << 4) >> #define RSTROBE(x) ((x) << 7) >> @@ -26,7 +28,10 @@ >> #define WHOLD(x) ((x) << 17) >> #define WSTROBE(x) ((x) << 20) >> #define WSETUP(x) ((x) << 26) >> +#define EW(x) ((x) << 30) >> +#define SS(x) ((x) << 31) > > You are adding support for additional configuration > parameters which should be done in a separate patch. Hmm.. they are only used in the OF case ... is this split really needed? [...] >> +static int davinci_aemif_setup_timing_of_one(struct device_node *np, >> + void __iomem *base) >> +{ [...] >> + val = ASIZE(asize) | TA(ta) | RHOLD(rhold) | RSTROBE(rstrobe) | >> + RSETUP(rsetup) | WHOLD(whold) | WSTROBE(wstrobe) | >> + WSETUP(wsetup) | EW(ew) | SS(ss); >> + >> + __raw_writel(val, base + offset); >> + >> + return 0; >> +} > > This shares a large amount of code with davinci_aemif_setup_timing(). > Can you try writing this as a OF wrapper to the existing function? Done. Waiting to your response to my 2 questions above, after that sending the v2. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From nsekhar at ti.com Thu Dec 8 02:19:12 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 8 Dec 2011 08:19:12 +0000 Subject: [PATCH] arm,davinci: configure davinci aemif chipselects through OF In-Reply-To: <4EE06B79.7070804@denx.de> References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EE06B79.7070804@denx.de> Message-ID: On Thu, Dec 08, 2011 at 13:17:05, Heiko Schocher wrote: > >> diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt b/Documentation/devicetree/bindings/arm/davinci/aemif.txt > >> new file mode 100644 > >> index 0000000..c9ed551 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt > >> @@ -0,0 +1,85 @@ > >> +* Texas Instruments Davinci AEMIF > >> + > >> +This file provides information, what the device node for the > >> +davinci aemifa interface contain. > > ^^^^^^ > > aemif > > fixed, thanks. > > >> + > >> +Required properties: > >> +- compatible: "ti,davinci-emifa"; > > Shouldn't this also be "ti,davinci-aemif" ? Yes, makes sense. > > [...] > >> diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c > >> index 1ce70a9..12c559f 100644 > >> --- a/arch/arm/mach-davinci/aemif.c > >> +++ b/arch/arm/mach-davinci/aemif.c > >> @@ -13,12 +13,14 @@ > >> #include > >> #include > >> #include > >> +#include > >> +#include > >> #include > >> > >> #include > >> > >> /* Timing value configuration */ > >> - > >> +#define ASIZE(x) (x) > >> #define TA(x) ((x) << 2) > >> #define RHOLD(x) ((x) << 4) > >> #define RSTROBE(x) ((x) << 7) > >> @@ -26,7 +28,10 @@ > >> #define WHOLD(x) ((x) << 17) > >> #define WSTROBE(x) ((x) << 20) > >> #define WSETUP(x) ((x) << 26) > >> +#define EW(x) ((x) << 30) > >> +#define SS(x) ((x) << 31) > > > > You are adding support for additional configuration > > parameters which should be done in a separate patch. > > Hmm.. they are only used in the OF case ... is this split > really needed? But they should also be useful in the non-OF case, no? Why restrict their usage to the OF case? Thanks, Sekhar From hs at denx.de Thu Dec 8 03:06:47 2011 From: hs at denx.de (Heiko Schocher) Date: Thu, 08 Dec 2011 10:06:47 +0100 Subject: [PATCH] arm, davinci: configure davinci aemif chipselects through OF In-Reply-To: References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EE06B79.7070804@denx.de> Message-ID: <4EE07E27.8090602@denx.de> Hello Nori, Nori, Sekhar wrote: > On Thu, Dec 08, 2011 at 13:17:05, Heiko Schocher wrote: > >>>> diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt b/Documentation/devicetree/bindings/arm/davinci/aemif.txt >>>> new file mode 100644 >>>> index 0000000..c9ed551 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt >>>> @@ -0,0 +1,85 @@ >>>> +* Texas Instruments Davinci AEMIF >>>> + >>>> +This file provides information, what the device node for the >>>> +davinci aemifa interface contain. >>> ^^^^^^ >>> aemif >> fixed, thanks. >> >>>> + >>>> +Required properties: >>>> +- compatible: "ti,davinci-emifa"; >> Shouldn't this also be "ti,davinci-aemif" ? > > Yes, makes sense. Ok, change this. >> [...] >>>> diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c >>>> index 1ce70a9..12c559f 100644 >>>> --- a/arch/arm/mach-davinci/aemif.c >>>> +++ b/arch/arm/mach-davinci/aemif.c >>>> @@ -13,12 +13,14 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>> +#include >>>> #include >>>> >>>> #include >>>> >>>> /* Timing value configuration */ >>>> - >>>> +#define ASIZE(x) (x) >>>> #define TA(x) ((x) << 2) >>>> #define RHOLD(x) ((x) << 4) >>>> #define RSTROBE(x) ((x) << 7) >>>> @@ -26,7 +28,10 @@ >>>> #define WHOLD(x) ((x) << 17) >>>> #define WSTROBE(x) ((x) << 20) >>>> #define WSETUP(x) ((x) << 26) >>>> +#define EW(x) ((x) << 30) >>>> +#define SS(x) ((x) << 31) >>> You are adding support for additional configuration >>> parameters which should be done in a separate patch. >> Hmm.. they are only used in the OF case ... is this split >> really needed? > > But they should also be useful in the non-OF case, no? > Why restrict their usage to the OF case? I thought there is no need, because nobody needed this yet ... Ok, I change this too, so I have to fix this files: $ grep -lr davinci_aemif_timing . ./arch/arm/mach-davinci/board-dm644x-evm.c ./arch/arm/mach-davinci/board-dm646x-evm.c ./arch/arm/mach-davinci/board-da850-evm.c ./arch/arm/mach-davinci/include/mach/aemif.h ./arch/arm/mach-davinci/include/mach/nand.h ./arch/arm/mach-davinci/board-da830-evm.c ./drivers/mtd/nand/davinci_nand.c I do not know the values for this boards for the new parameters. How to proceed? Do you know this values? Or is it Ok, if I add in arch/arm/mach-davinci/include/mach/aemif.h a "#define AEMIF_VALUE_NOT USED 0xff" and if the new value is set to this I don't change this setting in the register? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany From akshay.s at ti.com Thu Dec 8 03:05:51 2011 From: akshay.s at ti.com (Shankarmurthy, Akshay) Date: Thu, 8 Dec 2011 14:35:51 +0530 Subject: [PATCH] ARM: davinci: add missing commas on last members of structure and arrays Message-ID: <1323335151-25398-1-git-send-email-akshay.s@ti.com> This patch adds missing commas on last members of structure and arrays. This makes less harder to add additional initializer at the end of the existing initializers and avoids the conflict of more line being modified. This was pointed out by Russell King in his pet peeves mail at http://www.spinics.net/lists/arm-kernel/msg147268.html. Signed-off-by: Shankarmurthy, Akshay --- arch/arm/mach-davinci/board-da830-evm.c | 6 +++--- arch/arm/mach-davinci/board-da850-evm.c | 6 +++--- arch/arm/mach-davinci/board-dm355-evm.c | 6 +++--- arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 6 +++--- arch/arm/mach-davinci/board-dm644x-evm.c | 10 +++++----- arch/arm/mach-davinci/board-dm646x-evm.c | 4 ++-- arch/arm/mach-davinci/board-neuros-osd2.c | 4 ++-- arch/arm/mach-davinci/board-tnetv107x-evm.c | 4 ++-- arch/arm/mach-davinci/da830.c | 4 ++-- arch/arm/mach-davinci/da850.c | 6 +++--- arch/arm/mach-davinci/devices-tnetv107x.c | 24 ++++++++++++------------ arch/arm/mach-davinci/dm355.c | 8 ++++---- arch/arm/mach-davinci/dm365.c | 6 +++--- arch/arm/mach-davinci/dm644x.c | 8 ++++---- arch/arm/mach-davinci/dm646x.c | 6 +++--- arch/arm/mach-davinci/tnetv107x.c | 8 ++++---- 17 files changed, 59 insertions(+), 59 deletions(-) diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index 26d94c0..9a5074e 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -333,7 +333,7 @@ static struct mtd_partition da830_evm_nand_partitions[] = { .offset = MTDPART_OFS_APPEND, .size = MTDPART_SIZ_FULL, .mask_flags = 0, - } + }, }; /* flash bbt decriptors */ @@ -348,7 +348,7 @@ static struct nand_bbt_descr da830_evm_nand_bbt_main_descr = { .len = 4, .veroffs = 16, .maxblocks = 4, - .pattern = da830_evm_nand_bbt_pattern + .pattern = da830_evm_nand_bbt_pattern, }; static struct nand_bbt_descr da830_evm_nand_bbt_mirror_descr = { @@ -359,7 +359,7 @@ static struct nand_bbt_descr da830_evm_nand_bbt_mirror_descr = { .len = 4, .veroffs = 16, .maxblocks = 4, - .pattern = da830_evm_nand_mirror_pattern + .pattern = da830_evm_nand_mirror_pattern, }; static struct davinci_aemif_timing da830_evm_nandflash_timing = { diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index ec21663..9d97a17 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -545,7 +545,7 @@ enum da850_evm_bb_exp_pins { DA850_EVM_BB_EXP_USER_SW5, DA850_EVM_BB_EXP_USER_SW6, DA850_EVM_BB_EXP_USER_SW7, - DA850_EVM_BB_EXP_USER_SW8 + DA850_EVM_BB_EXP_USER_SW8, }; static const char const *da850_evm_bb_exp[] = { @@ -642,8 +642,8 @@ static struct platform_device da850_evm_bb_leds_device = { .name = "leds-gpio", .id = -1, .dev = { - .platform_data = &da850_evm_bb_leds_pdata - } + .platform_data = &da850_evm_bb_leds_pdata, + }, }; static void da850_evm_bb_leds_init(unsigned gpio) diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index 6556628..d1c17ad 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -68,7 +68,7 @@ static struct mtd_partition davinci_nand_partitions[] = { .offset = MTDPART_OFS_APPEND, .size = MTDPART_SIZ_FULL, .mask_flags = 0, - } + }, /* two blocks with bad block table (and mirror) at the end */ }; @@ -177,7 +177,7 @@ static struct platform_device dm355evm_dm9000 = { static struct tvp514x_platform_data tvp5146_pdata = { .clk_polarity = 0, .hs_polarity = 1, - .vs_polarity = 1 + .vs_polarity = 1, }; #define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) @@ -230,7 +230,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = { I2C_BOARD_INFO("tvp5146", 0x5d), .platform_data = &tvp5146_pdata, }, - } + }, }; static struct vpfe_config vpfe_cfg = { diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c index b307470..dc8880f 100644 --- a/arch/arm/mach-davinci/board-dm355-leopard.c +++ b/arch/arm/mach-davinci/board-dm355-leopard.c @@ -65,7 +65,7 @@ static struct mtd_partition davinci_nand_partitions[] = { .offset = MTDPART_OFS_APPEND, .size = MTDPART_SIZ_FULL, .mask_flags = 0, - } + }, /* two blocks with bad block table (and mirror) at the end */ }; diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index 04c43ab..4706f81 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -130,7 +130,7 @@ static struct mtd_partition davinci_nand_partitions[] = { .offset = MTDPART_OFS_APPEND, .size = MTDPART_SIZ_FULL, .mask_flags = 0, - } + }, /* two blocks with bad block table (and mirror) at the end */ }; @@ -214,7 +214,7 @@ static unsigned short dm365evm_keymap[] = { KEY_FASTFORWARD, KEY_KPPLUS, KEY_PLAYPAUSE, - 0 + 0, }; static struct davinci_ks_platform_data dm365evm_ks_data = { @@ -309,7 +309,7 @@ static void dm365evm_mmc_configure(void) static struct tvp514x_platform_data tvp5146_pdata = { .clk_polarity = 0, .hs_polarity = 1, - .vs_polarity = 1 + .vs_polarity = 1, }; #define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 28fafa7..c7c0fb7 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -64,15 +64,15 @@ static struct mtd_partition davinci_evm_norflash_partitions[] = { .name = "kernel", .offset = MTDPART_OFS_APPEND, .size = SZ_2M, - .mask_flags = 0 + .mask_flags = 0, }, /* file system */ { .name = "filesystem", .offset = MTDPART_OFS_APPEND, .size = MTDPART_SIZ_FULL, - .mask_flags = 0 - } + .mask_flags = 0, + }, }; static struct physmap_flash_data davinci_evm_norflash_data = { @@ -192,7 +192,7 @@ static struct platform_device davinci_fb_device = { static struct tvp514x_platform_data tvp5146_pdata = { .clk_polarity = 0, .hs_polarity = 1, - .vs_polarity = 1 + .vs_polarity = 1, }; #define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) @@ -567,7 +567,7 @@ static struct davinci_mmc_config dm6446evm_mmc_config = { .get_cd = dm6444evm_mmc_get_cd, .get_ro = dm6444evm_mmc_get_ro, .wires = 4, - .version = MMC_CTLR_VERSION_1 + .version = MMC_CTLR_VERSION_1, }; static struct i2c_board_info __initdata i2c_info[] = { diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index e574d7f..7cbb2ae 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -70,7 +70,7 @@ static struct mtd_partition davinci_nand_partitions[] = { .offset = MTDPART_OFS_APPEND, .size = MTDPART_SIZ_FULL, .mask_flags = 0, - } + }, }; static struct davinci_aemif_timing dm6467tevm_nandflash_timing = { @@ -593,7 +593,7 @@ static int setup_vpif_input_channel_mode(int mux_mode) static struct tvp514x_platform_data tvp5146_pdata = { .clk_polarity = 0, .hs_polarity = 1, - .vs_polarity = 1 + .vs_polarity = 1, }; #define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c index 38d6f64..717ea1d 100644 --- a/arch/arm/mach-davinci/board-neuros-osd2.c +++ b/arch/arm/mach-davinci/board-neuros-osd2.c @@ -79,7 +79,7 @@ static struct mtd_partition davinci_ntosd2_nandflash_partition[] = { .offset = MTDPART_OFS_APPEND, .size = MTDPART_SIZ_FULL, .mask_flags = 0, - } + }, /* A few blocks at end hold a flash Bad Block Table. */ }; @@ -195,7 +195,7 @@ static int ntosd2_init_i2c(void) static struct davinci_mmc_config davinci_ntosd2_mmc_config = { .wires = 4, - .version = MMC_CTLR_VERSION_1 + .version = MMC_CTLR_VERSION_1, }; diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c b/arch/arm/mach-davinci/board-tnetv107x-evm.c index 90ee7b5..d111a90 100644 --- a/arch/arm/mach-davinci/board-tnetv107x-evm.c +++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c @@ -104,7 +104,7 @@ static const short uart1_pins[] __initdata = { static const short ssp_pins[] __initdata = { TNETV107X_SSP0_0, TNETV107X_SSP0_1, TNETV107X_SSP0_2, TNETV107X_SSP1_0, TNETV107X_SSP1_1, TNETV107X_SSP1_2, - TNETV107X_SSP1_3, -1 + TNETV107X_SSP1_3, -1, }; static struct mtd_partition nand_partitions[] = { @@ -135,7 +135,7 @@ static struct mtd_partition nand_partitions[] = { .offset = MTDPART_OFS_NXTBLK, .size = MTDPART_SIZ_FULL, .mask_flags = 0, - } + }, }; static struct davinci_nand_pdata nand_config = { diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c index a6bf5dc..115d836 100644 --- a/arch/arm/mach-davinci/da830.c +++ b/arch/arm/mach-davinci/da830.c @@ -1113,13 +1113,13 @@ static struct map_desc da830_io_desc[] = { .virtual = IO_VIRT, .pfn = __phys_to_pfn(IO_PHYS), .length = IO_SIZE, - .type = MT_DEVICE + .type = MT_DEVICE, }, { .virtual = DA8XX_CP_INTC_VIRT, .pfn = __phys_to_pfn(DA8XX_CP_INTC_BASE), .length = DA8XX_CP_INTC_SIZE, - .type = MT_DEVICE + .type = MT_DEVICE, }, }; diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index b047f87..bc6f769 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -737,19 +737,19 @@ static struct map_desc da850_io_desc[] = { .virtual = IO_VIRT, .pfn = __phys_to_pfn(IO_PHYS), .length = IO_SIZE, - .type = MT_DEVICE + .type = MT_DEVICE, }, { .virtual = DA8XX_CP_INTC_VIRT, .pfn = __phys_to_pfn(DA8XX_CP_INTC_BASE), .length = DA8XX_CP_INTC_SIZE, - .type = MT_DEVICE + .type = MT_DEVICE, }, { .virtual = SRAM_VIRT, .pfn = __phys_to_pfn(DA8XX_ARM_RAM_BASE), .length = SZ_8K, - .type = MT_DEVICE + .type = MT_DEVICE, }, }; diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c b/arch/arm/mach-davinci/devices-tnetv107x.c index 29b17f7..b3f55c2 100644 --- a/arch/arm/mach-davinci/devices-tnetv107x.c +++ b/arch/arm/mach-davinci/devices-tnetv107x.c @@ -169,23 +169,23 @@ static struct resource mmc0_resources[] = { { /* Memory mapped registers */ .start = TNETV107X_SDIO0_BASE, .end = TNETV107X_SDIO0_BASE + 0x0ff, - .flags = IORESOURCE_MEM + .flags = IORESOURCE_MEM, }, { /* MMC interrupt */ .start = IRQ_TNETV107X_MMC0, - .flags = IORESOURCE_IRQ + .flags = IORESOURCE_IRQ, }, { /* SDIO interrupt */ .start = IRQ_TNETV107X_SDIO0, - .flags = IORESOURCE_IRQ + .flags = IORESOURCE_IRQ, }, { /* DMA RX */ .start = EDMA_CTLR_CHAN(0, TNETV107X_DMACH_SDIO0_RX), - .flags = IORESOURCE_DMA + .flags = IORESOURCE_DMA, }, { /* DMA TX */ .start = EDMA_CTLR_CHAN(0, TNETV107X_DMACH_SDIO0_TX), - .flags = IORESOURCE_DMA + .flags = IORESOURCE_DMA, }, }; @@ -193,23 +193,23 @@ static struct resource mmc1_resources[] = { { /* Memory mapped registers */ .start = TNETV107X_SDIO1_BASE, .end = TNETV107X_SDIO1_BASE + 0x0ff, - .flags = IORESOURCE_MEM + .flags = IORESOURCE_MEM, }, { /* MMC interrupt */ .start = IRQ_TNETV107X_MMC1, - .flags = IORESOURCE_IRQ + .flags = IORESOURCE_IRQ, }, { /* SDIO interrupt */ .start = IRQ_TNETV107X_SDIO1, - .flags = IORESOURCE_IRQ + .flags = IORESOURCE_IRQ, }, { /* DMA RX */ .start = EDMA_CTLR_CHAN(0, TNETV107X_DMACH_SDIO1_RX), - .flags = IORESOURCE_DMA + .flags = IORESOURCE_DMA, }, { /* DMA TX */ .start = EDMA_CTLR_CHAN(0, TNETV107X_DMACH_SDIO1_TX), - .flags = IORESOURCE_DMA + .flags = IORESOURCE_DMA, }, }; @@ -225,7 +225,7 @@ static struct platform_device mmc_devices[2] = { .coherent_dma_mask = DMA_BIT_MASK(32), }, .num_resources = ARRAY_SIZE(mmc0_resources), - .resource = mmc0_resources + .resource = mmc0_resources, }, { .name = "davinci_mmc", @@ -235,7 +235,7 @@ static struct platform_device mmc_devices[2] = { .coherent_dma_mask = DMA_BIT_MASK(32), }, .num_resources = ARRAY_SIZE(mmc1_resources), - .resource = mmc1_resources + .resource = mmc1_resources, }, }; diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index fe520d4..607a96f 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -104,7 +104,7 @@ static struct clk pll1_sysclkbp = { .name = "pll1_sysclkbp", .parent = &pll1_clk, .flags = CLK_PLL | PRE_PLL, - .div_reg = BPDIV + .div_reg = BPDIV, }; static struct clk vpss_dac_clk = { @@ -155,7 +155,7 @@ static struct clk pll2_sysclkbp = { .name = "pll2_sysclkbp", .parent = &pll2_clk, .flags = CLK_PLL | PRE_PLL, - .div_reg = BPDIV + .div_reg = BPDIV, }; static struct clk clkout3_clk = { @@ -756,7 +756,7 @@ static struct map_desc dm355_io_desc[] = { .virtual = IO_VIRT, .pfn = __phys_to_pfn(IO_PHYS), .length = IO_SIZE, - .type = MT_DEVICE + .type = MT_DEVICE, }, { .virtual = SRAM_VIRT, @@ -817,7 +817,7 @@ static struct plat_serial8250_port dm355_serial_platform_data[] = { .regshift = 2, }, { - .flags = 0 + .flags = 0, }, }; diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 679e168..f63e055 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -74,7 +74,7 @@ static struct clk pll1_sysclkbp = { .name = "pll1_sysclkbp", .parent = &pll1_clk, .flags = CLK_PLL | PRE_PLL, - .div_reg = BPDIV + .div_reg = BPDIV, }; static struct clk clkout0_clk = { @@ -967,7 +967,7 @@ static struct map_desc dm365_io_desc[] = { .virtual = IO_VIRT, .pfn = __phys_to_pfn(IO_PHYS), .length = IO_SIZE, - .type = MT_DEVICE + .type = MT_DEVICE, }, { .virtual = SRAM_VIRT, @@ -1045,7 +1045,7 @@ static struct plat_serial8250_port dm365_serial_platform_data[] = { .regshift = 2, }, { - .flags = 0 + .flags = 0, }, }; diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 3470983..b8e016e 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -95,7 +95,7 @@ static struct clk pll1_sysclkbp = { .name = "pll1_sysclkbp", .parent = &pll1_clk, .flags = CLK_PLL | PRE_PLL, - .div_reg = BPDIV + .div_reg = BPDIV, }; static struct clk pll2_clk = { @@ -123,7 +123,7 @@ static struct clk pll2_sysclkbp = { .name = "pll2_sysclkbp", .parent = &pll2_clk, .flags = CLK_PLL | PRE_PLL, - .div_reg = BPDIV + .div_reg = BPDIV, }; static struct clk dsp_clk = { @@ -662,7 +662,7 @@ static struct map_desc dm644x_io_desc[] = { .virtual = IO_VIRT, .pfn = __phys_to_pfn(IO_PHYS), .length = IO_SIZE, - .type = MT_DEVICE + .type = MT_DEVICE, }, { .virtual = SRAM_VIRT, @@ -730,7 +730,7 @@ static struct plat_serial8250_port dm644x_serial_platform_data[] = { .regshift = 2, }, { - .flags = 0 + .flags = 0, }, }; diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 0b68ed5..86fe054 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -681,7 +681,7 @@ static struct resource vpif_resource[] = { .start = DAVINCI_VPIF_BASE, .end = DAVINCI_VPIF_BASE + 0x03ff, .flags = IORESOURCE_MEM, - } + }, }; static struct platform_device vpif_dev = { @@ -750,7 +750,7 @@ static struct map_desc dm646x_io_desc[] = { .virtual = IO_VIRT, .pfn = __phys_to_pfn(IO_PHYS), .length = IO_SIZE, - .type = MT_DEVICE + .type = MT_DEVICE, }, { .virtual = SRAM_VIRT, @@ -818,7 +818,7 @@ static struct plat_serial8250_port dm646x_serial_platform_data[] = { .regshift = 2, }, { - .flags = 0 + .flags = 0, }, }; diff --git a/arch/arm/mach-davinci/tnetv107x.c b/arch/arm/mach-davinci/tnetv107x.c index 409bb86..3a31d2c 100644 --- a/arch/arm/mach-davinci/tnetv107x.c +++ b/arch/arm/mach-davinci/tnetv107x.c @@ -101,11 +101,11 @@ static u32 bypass_mask[N_PLLS] = { BIT(0), BIT(2), BIT(1) }; static u32 pll_ext_freq[] = { OSC_FREQ_OFFCHIP_SYS, OSC_FREQ_OFFCHIP_TDM, - OSC_FREQ_OFFCHIP_ETH + OSC_FREQ_OFFCHIP_ETH, }; /* PSC control registers */ -static u32 psc_regs[] = { TNETV107X_PSC_BASE }; +static u32 psc_regs[] = { TNETV107X_PSC_BASE, }; /* Host map for interrupt controller */ static u32 intc_host_map[] = { 0x01010000, 0x01010101, -1 }; @@ -634,13 +634,13 @@ static struct map_desc io_desc[] = { .virtual = IO_VIRT, .pfn = __phys_to_pfn(TNETV107X_INTC_BASE), .length = SZ_16K, - .type = MT_DEVICE + .type = MT_DEVICE, }, { /* Most of the rest */ .virtual = TNETV107X_IO_VIRT, .pfn = __phys_to_pfn(TNETV107X_IO_BASE), .length = IO_SIZE - SZ_1M, - .type = MT_DEVICE + .type = MT_DEVICE, }, }; -- 1.7.1 From sshtylyov at mvista.com Thu Dec 8 04:18:44 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Thu, 08 Dec 2011 14:18:44 +0400 Subject: OMAP L138 usb_submit_urb return -28 In-Reply-To: <4EDF748C.8000702@efacec.com> References: <4EDF748C.8000702@efacec.com> Message-ID: <4EE08F04.8050400@mvista.com> Hello. On 07-12-2011 18:13, An?bal Almeida Pinto wrote: > On an OMAP L138 custom board, the USB is used to conect to a SMS95xx (hub usb > + ethernet) that have a Freescale Chip (usb uart conversor) and a eXar chip > (usb multiple uart conversor) connected. > The eXar and Freescale are self powered connected from the start of boot and > the usb port is limited to Full Speed. > Both device drivers that talk with the chips return the error -28 when using > the function usb_submit_urb. > If I disconnect and plug again the chip everything work fine. > Anyone have an idea what can cause this problem ? -28 means -ENOSPC, according to Documentation/usb/error-codes.txt: -ENOSPC This request would overcommit the usb bandwidth reserved for periodic transfers (interrupt, isochronous). > Thanks. You really should ask such questions on linux-usb at vger.kernel.org... WBR, Sergei From nsekhar at ti.com Thu Dec 8 04:29:14 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 8 Dec 2011 10:29:14 +0000 Subject: [PATCH] arm,davinci: configure davinci aemif chipselects through OF In-Reply-To: <4EE07E27.8090602@denx.de> References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EE06B79.7070804@denx.de> <4EE07E27.8090602@denx.de> Message-ID: Hi Heiko, On Thu, Dec 08, 2011 at 14:36:47, Heiko Schocher wrote: > >>>> diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c > >>>> index 1ce70a9..12c559f 100644 > >>>> --- a/arch/arm/mach-davinci/aemif.c > >>>> +++ b/arch/arm/mach-davinci/aemif.c > >>>> @@ -13,12 +13,14 @@ > >>>> #include > >>>> #include > >>>> #include > >>>> +#include > >>>> +#include > >>>> #include > >>>> > >>>> #include > >>>> > >>>> /* Timing value configuration */ > >>>> - > >>>> +#define ASIZE(x) (x) > >>>> #define TA(x) ((x) << 2) > >>>> #define RHOLD(x) ((x) << 4) > >>>> #define RSTROBE(x) ((x) << 7) > >>>> @@ -26,7 +28,10 @@ > >>>> #define WHOLD(x) ((x) << 17) > >>>> #define WSTROBE(x) ((x) << 20) > >>>> #define WSETUP(x) ((x) << 26) > >>>> +#define EW(x) ((x) << 30) > >>>> +#define SS(x) ((x) << 31) > >>> You are adding support for additional configuration > >>> parameters which should be done in a separate patch. > >> Hmm.. they are only used in the OF case ... is this split > >> really needed? > > > > But they should also be useful in the non-OF case, no? > > Why restrict their usage to the OF case? > > I thought there is no need, because nobody needed this yet ... > Ok, I change this too, so I have to fix this files: True, no one configured these so far (relied on the defaults). Also, they probably did not get added into the timing API since they are not really timing parameters. Its better to add a separate configuration API for these. It will be better to move the driver outside of arch/arm/ before adding new features. I don't know if there is a place defined yet for "memory interface" drivers, so, drivers/misc/ may be the place. I have added Greg and Arnd for their opinion in this. Greg, Arnd, Brief background: DaVinci AEMIF is an async memory interface peripheral implemented in arch/arm/mach-davinci/aemif.c. It helps interface to NAND, NOR and other asynchronous memories. Currently it just provides an API for timing value configuration. The API is invoked by the MTD NAND driver. Specification here: http://www.ti.com/lit/ug/sprue20c/sprue20c.pdf We are looking at a place for this outside of architecture code. > > $ grep -lr davinci_aemif_timing . > ./arch/arm/mach-davinci/board-dm644x-evm.c > ./arch/arm/mach-davinci/board-dm646x-evm.c > ./arch/arm/mach-davinci/board-da850-evm.c > ./arch/arm/mach-davinci/include/mach/aemif.h > ./arch/arm/mach-davinci/include/mach/nand.h > ./arch/arm/mach-davinci/board-da830-evm.c > ./drivers/mtd/nand/davinci_nand.c > > I do not know the values for this boards for the new parameters. > How to proceed? Do you know this values? Or is it Ok, if I add in If we add a new API, there won't be a need to touch existing board code. > arch/arm/mach-davinci/include/mach/aemif.h > a "#define AEMIF_VALUE_NOT USED 0xff" and if the new value is set to > this I don't change this setting in the register? > > bye, > Heiko Thanks, Sekhar From albertbu at gmail.com Thu Dec 8 05:52:40 2011 From: albertbu at gmail.com (Albert Burbea) Date: Thu, 8 Dec 2011 13:52:40 +0200 Subject: Cause of non working GPIO IRQ on a OMAP-L138 In-Reply-To: <4EDF5394.4050701@eclis.ch> References: <4EDF5394.4050701@eclis.ch> Message-ID: Thanks anyway for sharing - it was instructive On Wed, Dec 7, 2011 at 1:52 PM, Jean-Christian de Rivaz wrote: > On a OMAP-L138 custom board, the GPIO 5,11 is used as an interrupt for the > wl12xx driver. It is declared this way in the board file: > > #define XBRD_WLAN_IRQ GPIO_TO_PIN(5, 11) > > static struct wl12xx_platform_data xbrd_wlan_data __initdata = > { > .irq = -1, > .board_ref_clock = WL12XX_REFCLOCK_38, > .platform_quirks = WL12XX_PLATFORM_QUIRK_EDGE_**IRQ, > }; > > In the init() of the board file: > > ret = gpio_request_one(XBRD_WLAN_**IRQ, GPIOF_IN, "wl12xx_irq"); > if (ret) { > pr_warning("error request wl12xx irq gpio: %d\n", ret); > } > xbrd_wlan_data.irq = gpio_to_irq(XBRD_WLAN_IRQ); > ret = wl12xx_set_platform_data(&**xbrd_wlan_data); > if (ret) { > pr_warning("error setting wl12xx data: %d\n", ret); > } > > The oscilloscope show that the electrical signal work exactly as expected > and described in http://www.lsr.com/downloads/** > tiwi_r1/TiWi_R1_Datasheet.pdf, > page 19, "IRQ OPERATION". The /sys/kernel/debug/gpio entry show the correct > state of the line: > > GPIOs 64-95, DaVinci: > gpio-91 (wl12xx_irq ) in lo > > When the signal is low on the oscilloscope, and > > GPIOs 64-95, DaVinci: > gpio-91 (wl12xx_irq ) in hi > > When the signal is high on the oscilloscope. So far everything seem to be > ok. > > The problem is that when the wl12xx driver is loader, it complain with the > message: > > wl1271: ERROR ELP wakeup timeout! > > Reading the code drivers/net/wireless/wl12xx/**ps.c show that the driver > is clearly waiting for a interrupt at this point. But this is not happening > according to /proc/interrupts: > > 192: 0 GPIO wl1271 > > And stay always 0. I even connected a 10 Hz periodic square signal to the > GPIO 5,11 wire, and the /proc/interrupts never increase. But at the same > time, /sys/kernel/debug/gpio is always reporting the true signal state, > flipping between "lo" and "hi". > > I suspect that something is missing in order to connect the "wl12xx_irq" > from the GPIO to the "wl1271" of the wl12xx driver. But I can't figure what. > > Jean-Christian > ______________________________**_________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@**linux.davincidsp.com > http://linux.davincidsp.com/**mailman/listinfo/davinci-**linux-open-source > -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842 -------------- next part -------------- An HTML attachment was scrubbed... URL: From manjunath.hadli at ti.com Thu Dec 8 07:55:24 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 8 Dec 2011 19:25:24 +0530 Subject: [PATCH v4 1/5] davinci: vpif: remove obsolete header file inclusion In-Reply-To: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> References: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323352528-1207-2-git-send-email-manjunath.hadli@ti.com> remove inclusion of header files from vpif.h and vpif_dispaly.c and add appropriate header file for building. Signed-off-by: Manjunath Hadli --- drivers/media/video/davinci/vpif.h | 2 +- drivers/media/video/davinci/vpif_display.c | 2 -- 2 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/davinci/vpif.h b/drivers/media/video/davinci/vpif.h index 25036cb..c96268a 100644 --- a/drivers/media/video/davinci/vpif.h +++ b/drivers/media/video/davinci/vpif.h @@ -19,7 +19,7 @@ #include #include #include -#include +#include #include /* Maximum channel allowed */ diff --git a/drivers/media/video/davinci/vpif_display.c b/drivers/media/video/davinci/vpif_display.c index 286f029..7fa34b4 100644 --- a/drivers/media/video/davinci/vpif_display.c +++ b/drivers/media/video/davinci/vpif_display.c @@ -39,8 +39,6 @@ #include #include -#include - #include "vpif_display.h" #include "vpif.h" -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 8 07:55:25 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 8 Dec 2011 19:25:25 +0530 Subject: [PATCH v4 2/5] ARM: davinci: dm644x: remove the macros from the header to move to c file In-Reply-To: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> References: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323352528-1207-3-git-send-email-manjunath.hadli@ti.com> move the register base addresses and offsets used only by dm644x platform file from platform header dm644x.h to dm644x.c as they are used only in the c file. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/dm644x.c | 7 +++++++ arch/arm/mach-davinci/include/mach/dm644x.h | 7 ------- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 3470983..27d1371 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -35,6 +35,13 @@ */ #define DM644X_REF_FREQ 27000000 +#define DM644X_EMAC_BASE 0x01c80000 +#define DM644X_EMAC_MDIO_BASE (DM644X_EMAC_BASE + 0x4000) +#define DM644X_EMAC_CNTRL_OFFSET 0x0000 +#define DM644X_EMAC_CNTRL_MOD_OFFSET 0x1000 +#define DM644X_EMAC_CNTRL_RAM_OFFSET 0x2000 +#define DM644X_EMAC_CNTRL_RAM_SIZE 0x2000 + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h index 5a1b26d..724377f 100644 --- a/arch/arm/mach-davinci/include/mach/dm644x.h +++ b/arch/arm/mach-davinci/include/mach/dm644x.h @@ -27,13 +27,6 @@ #include #include -#define DM644X_EMAC_BASE (0x01C80000) -#define DM644X_EMAC_MDIO_BASE (DM644X_EMAC_BASE + 0x4000) -#define DM644X_EMAC_CNTRL_OFFSET (0x0000) -#define DM644X_EMAC_CNTRL_MOD_OFFSET (0x1000) -#define DM644X_EMAC_CNTRL_RAM_OFFSET (0x2000) -#define DM644X_EMAC_CNTRL_RAM_SIZE (0x2000) - #define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01E00000 #define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 #define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 8 07:55:26 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 8 Dec 2011 19:25:26 +0530 Subject: [PATCH v4 3/5] ARM: davinci: dm365: remove the macros from the header to move to c file In-Reply-To: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> References: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323352528-1207-4-git-send-email-manjunath.hadli@ti.com> move the register base addresses and offsets used only by dm365 platform file from platform header dm365.h to dm365.c as they are used only in the c file. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/dm365.c | 16 ++++++++++++++++ arch/arm/mach-davinci/include/mach/dm365.h | 16 ---------------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 679e168..77edee8 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -40,6 +40,22 @@ #define DM365_REF_FREQ 24000000 /* 24 MHz on the DM365 EVM */ +/* Base of key scan register bank */ +#define DM365_KEYSCAN_BASE 0x01c69400 + +#define DM365_RTC_BASE 0x01c69000 + +#define DAVINCI_DM365_VC_BASE 0x01d0c000 +#define DAVINCI_DMA_VC_TX 2 +#define DAVINCI_DMA_VC_RX 3 + +#define DM365_EMAC_BASE 0x01d07000 +#define DM365_EMAC_MDIO_BASE (DM365_EMAC_BASE + 0x4000) +#define DM365_EMAC_CNTRL_OFFSET 0x0000 +#define DM365_EMAC_CNTRL_MOD_OFFSET 0x3000 +#define DM365_EMAC_CNTRL_RAM_OFFSET 0x1000 +#define DM365_EMAC_CNTRL_RAM_SIZE 0x2000 + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h index 2563bf4..51924de 100644 --- a/arch/arm/mach-davinci/include/mach/dm365.h +++ b/arch/arm/mach-davinci/include/mach/dm365.h @@ -20,22 +20,6 @@ #include #include -#define DM365_EMAC_BASE (0x01D07000) -#define DM365_EMAC_MDIO_BASE (DM365_EMAC_BASE + 0x4000) -#define DM365_EMAC_CNTRL_OFFSET (0x0000) -#define DM365_EMAC_CNTRL_MOD_OFFSET (0x3000) -#define DM365_EMAC_CNTRL_RAM_OFFSET (0x1000) -#define DM365_EMAC_CNTRL_RAM_SIZE (0x2000) - -/* Base of key scan register bank */ -#define DM365_KEYSCAN_BASE (0x01C69400) - -#define DM365_RTC_BASE (0x01C69000) - -#define DAVINCI_DM365_VC_BASE (0x01D0C000) -#define DAVINCI_DMA_VC_TX 2 -#define DAVINCI_DMA_VC_RX 3 - #define DM365_ASYNC_EMIF_CONTROL_BASE 0x01D10000 #define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 #define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 8 07:55:28 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 8 Dec 2011 19:25:28 +0530 Subject: [PATCH v4 5/5] ARM: davinci: create new common platform header for davinci In-Reply-To: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> References: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323352528-1207-6-git-send-email-manjunath.hadli@ti.com> remove the code from individual platform header files for dm365, dm355, dm644x and dm646x and consolidate it into a single and common header file davinci.h. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/board-dm355-evm.c | 2 +- arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- arch/arm/mach-davinci/board-sffsdr.c | 2 +- arch/arm/mach-davinci/davinci.h | 88 +++++++++++++++++++++++++++ arch/arm/mach-davinci/dm355.c | 2 +- arch/arm/mach-davinci/dm365.c | 2 +- arch/arm/mach-davinci/dm644x.c | 2 +- arch/arm/mach-davinci/dm646x.c | 2 +- arch/arm/mach-davinci/include/mach/dm355.h | 32 ---------- arch/arm/mach-davinci/include/mach/dm365.h | 36 ----------- arch/arm/mach-davinci/include/mach/dm644x.h | 40 ------------ arch/arm/mach-davinci/include/mach/dm646x.h | 34 ---------- 16 files changed, 99 insertions(+), 153 deletions(-) create mode 100644 arch/arm/mach-davinci/davinci.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index 4e0e707..7ae0d15 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -26,7 +26,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c index ff2d241..56f88de 100644 --- a/arch/arm/mach-davinci/board-dm355-leopard.c +++ b/arch/arm/mach-davinci/board-dm355-leopard.c @@ -23,7 +23,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index 1918ae7..613ed00 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -32,7 +32,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 0cf8abf..00e8599 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -30,7 +30,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index e574d7f..c0f9ea2 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -36,7 +36,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c index e5f231a..edc6ff7 100644 --- a/arch/arm/mach-davinci/board-neuros-osd2.c +++ b/arch/arm/mach-davinci/board-neuros-osd2.c @@ -30,7 +30,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c index 5dd4da9..122c7aa 100644 --- a/arch/arm/mach-davinci/board-sffsdr.c +++ b/arch/arm/mach-davinci/board-sffsdr.c @@ -35,7 +35,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h new file mode 100644 index 0000000..1fafbd7 --- /dev/null +++ b/arch/arm/mach-davinci/davinci.h @@ -0,0 +1,88 @@ +/* + * This file contains the processor specific definitions + * of the TI DM644x, DM355, DM365, and DM646x. + * + * Copyright (C) 2011 Texas Instruments Incorporated + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#ifndef __DAVINCI_H +#define __DAVINCI_H + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* DM355 base addresses */ +#define DM355_ASYNC_EMIF_CONTROL_BASE 0x01e10000 +#define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 + +#define ASP1_TX_EVT_EN 1 +#define ASP1_RX_EVT_EN 2 + +/* DM365 base addresses */ +#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01d10000 +#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 +#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 + +/* DM644x base addresses */ +#define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01e00000 +#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 +#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 +#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000 +#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000 + +/* DM646x base addresses */ +#define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 +#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 + +/* DM355 function declarations */ +struct spi_board_info; + +void __init dm355_init(void); +void dm355_init_spi0(unsigned chipselect_mask, + struct spi_board_info *info, unsigned len); +void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); +void dm355_set_vpfe_config(struct vpfe_config *cfg); + +/* DM365 function declarations */ +void __init dm365_init(void); +void __init dm365_init_asp(struct snd_platform_data *pdata); +void __init dm365_init_vc(struct snd_platform_data *pdata); +void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); +void __init dm365_init_rtc(void); +void dm365_init_spi0(unsigned chipselect_mask, + struct spi_board_info *info, unsigned len); + +void dm365_set_vpfe_config(struct vpfe_config *cfg); + +/* DM644x function declarations */ +void __init dm644x_init(void); +void __init dm644x_init_asp(struct snd_platform_data *pdata); +void dm644x_set_vpfe_config(struct vpfe_config *cfg); + +/* DM646x function declarations */ +void __init dm646x_init(void); +void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); +void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); +void __init dm646x_board_setup_refclk(struct clk *clk); +int __init dm646x_init_edma(struct edma_rsv_info *rsv); + +void dm646x_video_init(void); + +void dm646x_setup_vpif(struct vpif_display_config *, + struct vpif_capture_config *); +#endif /*__DAVINCI_H */ diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index fe520d4..36744ff 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -18,7 +18,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 77edee8..3171cd1 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -21,7 +21,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 27d1371..b84b220 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -15,7 +15,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 0560e82..a6a9cde 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -16,7 +16,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/include/mach/dm355.h b/arch/arm/mach-davinci/include/mach/dm355.h deleted file mode 100644 index 36dff4a..0000000 --- a/arch/arm/mach-davinci/include/mach/dm355.h +++ /dev/null @@ -1,32 +0,0 @@ -/* - * Chip specific defines for DM355 SoC - * - * Author: Kevin Hilman, Deep Root Systems, LLC - * - * 2007 (c) Deep Root Systems, LLC. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. - */ -#ifndef __ASM_ARCH_DM355_H -#define __ASM_ARCH_DM355_H - -#include -#include -#include - -#define DM355_ASYNC_EMIF_CONTROL_BASE 0x01E10000 -#define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 - -#define ASP1_TX_EVT_EN 1 -#define ASP1_RX_EVT_EN 2 - -struct spi_board_info; - -void __init dm355_init(void); -void dm355_init_spi0(unsigned chipselect_mask, - struct spi_board_info *info, unsigned len); -void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); -void dm355_set_vpfe_config(struct vpfe_config *cfg); - -#endif /* __ASM_ARCH_DM355_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h deleted file mode 100644 index 51924de..0000000 --- a/arch/arm/mach-davinci/include/mach/dm365.h +++ /dev/null @@ -1,36 +0,0 @@ -/* - * Copyright (C) 2009 Texas Instruments Incorporated - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation version 2. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether express or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ -#ifndef __ASM_ARCH_DM365_H -#define __ASM_ARCH_DM665_H - -#include -#include -#include -#include -#include -#include - -#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01D10000 -#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 -#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 - -void __init dm365_init(void); -void __init dm365_init_asp(struct snd_platform_data *pdata); -void __init dm365_init_vc(struct snd_platform_data *pdata); -void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); -void __init dm365_init_rtc(void); -void dm365_init_spi0(unsigned chipselect_mask, - struct spi_board_info *info, unsigned len); - -void dm365_set_vpfe_config(struct vpfe_config *cfg); -#endif /* __ASM_ARCH_DM365_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h deleted file mode 100644 index 724377f..0000000 --- a/arch/arm/mach-davinci/include/mach/dm644x.h +++ /dev/null @@ -1,40 +0,0 @@ -/* - * This file contains the processor specific definitions - * of the TI DM644x. - * - * Copyright (C) 2008 Texas Instruments. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - * - */ -#ifndef __ASM_ARCH_DM644X_H -#define __ASM_ARCH_DM644X_H - -#include -#include -#include -#include - -#define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01E00000 -#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 -#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 -#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000 -#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000 - -void __init dm644x_init(void); -void __init dm644x_init_asp(struct snd_platform_data *pdata); -void dm644x_set_vpfe_config(struct vpfe_config *cfg); - -#endif /* __ASM_ARCH_DM644X_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h deleted file mode 100644 index eb95864..0000000 --- a/arch/arm/mach-davinci/include/mach/dm646x.h +++ /dev/null @@ -1,34 +0,0 @@ -/* - * Chip specific defines for DM646x SoC - * - * Author: Kevin Hilman, Deep Root Systems, LLC - * - * 2007 (c) Deep Root Systems, LLC. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. - */ -#ifndef __ASM_ARCH_DM646X_H -#define __ASM_ARCH_DM646X_H - -#include -#include -#include -#include -#include -#include - -#define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 -#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 - -void __init dm646x_init(void); -void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); -void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); -int __init dm646x_init_edma(struct edma_rsv_info *rsv); - -void dm646x_video_init(void); - -void dm646x_setup_vpif(struct vpif_display_config *, - struct vpif_capture_config *); - -#endif /* __ASM_ARCH_DM646X_H */ -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 8 07:55:23 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 8 Dec 2011 19:25:23 +0530 Subject: [PATCH v4 0/5] ARM: davinci: re-arrange definitions to have a common davinci header Message-ID: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> Re-arrange definitions and remove unnecessary code so that we can have a common header for all davinci platforms. This will enable us to share defines and enable common routines to be used without polluting hardware.h. This patch set forms the base for a later set of patches for having a common system module base address (DAVINCI_SYSTEM_MODULE_BASE). Changes from previous version: 1. Addressed Shekhar's comments for non-inclusion of mach headers from core. 2. Move the mach header from include to mach Manjunath Hadli (5): davinci: vpif: remove obsolete header file inclusion ARM: davinci: dm644x: remove the macros from the header to move to c file ARM: davinci: dm365: remove the macros from the header to move to c file ARM: davinci: dm646x: remove the macros from the header to move to c file ARM: davinci: create new common platform header for davinci arch/arm/mach-davinci/board-dm355-evm.c | 2 +- arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- arch/arm/mach-davinci/board-sffsdr.c | 2 +- arch/arm/mach-davinci/davinci.h | 88 +++++++++++++++++++++++++++ arch/arm/mach-davinci/dm355.c | 2 +- arch/arm/mach-davinci/dm365.c | 18 +++++- arch/arm/mach-davinci/dm644x.c | 9 +++- arch/arm/mach-davinci/dm646x.c | 9 +++- arch/arm/mach-davinci/include/mach/dm355.h | 32 ---------- arch/arm/mach-davinci/include/mach/dm365.h | 52 ---------------- arch/arm/mach-davinci/include/mach/dm644x.h | 47 -------------- arch/arm/mach-davinci/include/mach/dm646x.h | 41 ------------ drivers/media/video/davinci/vpif.h | 2 +- drivers/media/video/davinci/vpif_display.c | 2 - 18 files changed, 130 insertions(+), 186 deletions(-) create mode 100644 arch/arm/mach-davinci/davinci.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h From manjunath.hadli at ti.com Thu Dec 8 07:55:27 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 8 Dec 2011 19:25:27 +0530 Subject: [PATCH v4 4/5] ARM: davinci: dm646x: remove the macros from the header to move to c file In-Reply-To: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> References: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323352528-1207-5-git-send-email-manjunath.hadli@ti.com> move the register base addresses and offsets used only by dm646x platform file from platform header dm646x.h to dm646x.c as they are used only in the c file. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/dm646x.c | 7 +++++++ arch/arm/mach-davinci/include/mach/dm646x.h | 7 ------- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 0b68ed5..0560e82 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -46,6 +46,13 @@ #define DM646X_REF_FREQ 27000000 #define DM646X_AUX_FREQ 24000000 +#define DM646X_EMAC_BASE 0x01c80000 +#define DM646X_EMAC_MDIO_BASE (DM646X_EMAC_BASE + 0x4000) +#define DM646X_EMAC_CNTRL_OFFSET 0x0000 +#define DM646X_EMAC_CNTRL_MOD_OFFSET 0x1000 +#define DM646X_EMAC_CNTRL_RAM_OFFSET 0x2000 +#define DM646X_EMAC_CNTRL_RAM_SIZE 0x2000 + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h index a8ee6c9..eb95864 100644 --- a/arch/arm/mach-davinci/include/mach/dm646x.h +++ b/arch/arm/mach-davinci/include/mach/dm646x.h @@ -18,13 +18,6 @@ #include #include -#define DM646X_EMAC_BASE (0x01C80000) -#define DM646X_EMAC_MDIO_BASE (DM646X_EMAC_BASE + 0x4000) -#define DM646X_EMAC_CNTRL_OFFSET (0x0000) -#define DM646X_EMAC_CNTRL_MOD_OFFSET (0x1000) -#define DM646X_EMAC_CNTRL_RAM_OFFSET (0x2000) -#define DM646X_EMAC_CNTRL_RAM_SIZE (0x2000) - #define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 #define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 -- 1.6.2.4 From arnd at arndb.de Thu Dec 8 09:48:08 2011 From: arnd at arndb.de (Arnd Bergmann) Date: Thu, 8 Dec 2011 15:48:08 +0000 Subject: [PATCH] arm, davinci: configure davinci aemif chipselects through OF In-Reply-To: References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EE07E27.8090602@denx.de> Message-ID: <201112081548.08548.arnd@arndb.de> On Thursday 08 December 2011, Nori, Sekhar wrote: > DaVinci AEMIF is an async memory interface peripheral implemented > in arch/arm/mach-davinci/aemif.c. It helps interface to NAND, NOR > and other asynchronous memories. Currently it just provides an API > for timing value configuration. The API is invoked by the MTD NAND > driver. > > Specification here: http://www.ti.com/lit/ug/sprue20c/sprue20c.pdf > > We are looking at a place for this outside of architecture code. I think the best place depends on how you plan to use the sram interface. If all memory behind the aemif is handled by mtd, I would put the entire driver somewhere in the mtd infrastructure. If you want it to provide endpoint devices that are handled by distinct subsystems in Linux, I would make it an mfd multifunction device and make the common code a driver that scans the connected memories in order to register its child devices for each of the subsystems. Arnd From sshtylyov at mvista.com Fri Dec 9 04:50:27 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Fri, 09 Dec 2011 14:50:27 +0400 Subject: [PATCH v4 5/5] ARM: davinci: create new common platform header for davinci In-Reply-To: <1323352528-1207-6-git-send-email-manjunath.hadli@ti.com> References: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> <1323352528-1207-6-git-send-email-manjunath.hadli@ti.com> Message-ID: <4EE1E7F3.3050509@mvista.com> Hello. On 08-12-2011 17:55, Manjunath Hadli wrote: > remove the code from individual platform header files for > dm365, dm355, dm644x and dm646x and consolidate it into a > single and common header file davinci.h. > Signed-off-by: Manjunath Hadli [...] > diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h > new file mode 100644 > index 0000000..1fafbd7 > --- /dev/null > +++ b/arch/arm/mach-davinci/davinci.h > @@ -0,0 +1,88 @@ [...] > +/* DM646x function declarations */ > +void __init dm646x_init(void); > +void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); > +void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); > +void __init dm646x_board_setup_refclk(struct clk *clk); I don't see from where are you moving this prototype -- it wasn't in the original #include file... In fact, I'm not even seeing this function in the current Linus tree... > +int __init dm646x_init_edma(struct edma_rsv_info *rsv); > + > +void dm646x_video_init(void); > + > +void dm646x_setup_vpif(struct vpif_display_config *, > + struct vpif_capture_config *); > +#endif /*__DAVINCI_H */ [...] > diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h > deleted file mode 100644 > index eb95864..0000000 > --- a/arch/arm/mach-davinci/include/mach/dm646x.h > +++ /dev/null > @@ -1,34 +0,0 @@ > -/* > - * Chip specific defines for DM646x SoC > - * > - * Author: Kevin Hilman, Deep Root Systems, LLC > - * > - * 2007 (c) Deep Root Systems, LLC. This file is licensed under > - * the terms of the GNU General Public License version 2. This program > - * is licensed "as is" without any warranty of any kind, whether express > - * or implied. > - */ > -#ifndef __ASM_ARCH_DM646X_H > -#define __ASM_ARCH_DM646X_H > - > -#include > -#include > -#include > -#include > -#include > -#include > - > -#define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 > -#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 > - > -void __init dm646x_init(void); > -void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); > -void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); > -int __init dm646x_init_edma(struct edma_rsv_info *rsv); > - > -void dm646x_video_init(void); > - > -void dm646x_setup_vpif(struct vpif_display_config *, > - struct vpif_capture_config *); > - > -#endif /* __ASM_ARCH_DM646X_H */ WBR, Sergei From nsekhar at ti.com Mon Dec 12 05:25:11 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Mon, 12 Dec 2011 11:25:11 +0000 Subject: [PATCH v4 0/5] ARM: davinci: re-arrange definitions to have a common davinci header In-Reply-To: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> References: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> Message-ID: Hi Manju, On Thu, Dec 08, 2011 at 19:25:23, Hadli, Manjunath wrote: > Re-arrange definitions and remove unnecessary code so that we can > have a common header for all davinci platforms. This will enable > us to share defines and enable common routines to be used without > polluting hardware.h. > This patch set forms the base for a later set of patches for having > a common system module base address (DAVINCI_SYSTEM_MODULE_BASE). Its easy to dismiss this series as causing "needless churn" by moving around definitions from header to C files and consolidating definitions from multiple header files to one. You need to do a better job of "selling" this series. The best way to do that would be to include future patches which benefit from this series into this series itself. This way, its clear to judge the relative benefit of the "churn". You gave some examples, but showing code helps. Also, one of the biggest gains from this series is reducing the pollution in include/mach as asked by Russell in his "pet peaves" mail. That should find reference in the cover letter and in the commit text of patch 5/5. Thanks, Sekhar > > Changes from previous version: > 1. Addressed Shekhar's comments for non-inclusion of mach headers from core. > 2. Move the mach header from include to mach > > Manjunath Hadli (5): > davinci: vpif: remove obsolete header file inclusion > ARM: davinci: dm644x: remove the macros from the header to move to c > file > ARM: davinci: dm365: remove the macros from the header to move to c > file > ARM: davinci: dm646x: remove the macros from the header to move to c > file > ARM: davinci: create new common platform header for davinci > > arch/arm/mach-davinci/board-dm355-evm.c | 2 +- > arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- > arch/arm/mach-davinci/board-dm365-evm.c | 2 +- > arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- > arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- > arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- > arch/arm/mach-davinci/board-sffsdr.c | 2 +- > arch/arm/mach-davinci/davinci.h | 88 +++++++++++++++++++++++++++ > arch/arm/mach-davinci/dm355.c | 2 +- > arch/arm/mach-davinci/dm365.c | 18 +++++- > arch/arm/mach-davinci/dm644x.c | 9 +++- > arch/arm/mach-davinci/dm646x.c | 9 +++- > arch/arm/mach-davinci/include/mach/dm355.h | 32 ---------- > arch/arm/mach-davinci/include/mach/dm365.h | 52 ---------------- > arch/arm/mach-davinci/include/mach/dm644x.h | 47 -------------- > arch/arm/mach-davinci/include/mach/dm646x.h | 41 ------------ > drivers/media/video/davinci/vpif.h | 2 +- > drivers/media/video/davinci/vpif_display.c | 2 - > 18 files changed, 130 insertions(+), 186 deletions(-) > create mode 100644 arch/arm/mach-davinci/davinci.h > delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h > delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h > delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h > delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h > > _______________________________________________ > 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 linux at arm.linux.org.uk Mon Dec 12 09:03:34 2011 From: linux at arm.linux.org.uk (Russell King - ARM Linux) Date: Mon, 12 Dec 2011 15:03:34 +0000 Subject: [PATCH v4 0/5] ARM: davinci: re-arrange definitions to have a common davinci header In-Reply-To: References: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <20111212150334.GA20178@n2100.arm.linux.org.uk> On Mon, Dec 12, 2011 at 11:25:11AM +0000, Nori, Sekhar wrote: > Hi Manju, > > On Thu, Dec 08, 2011 at 19:25:23, Hadli, Manjunath wrote: > > Re-arrange definitions and remove unnecessary code so that we can > > have a common header for all davinci platforms. This will enable > > us to share defines and enable common routines to be used without > > polluting hardware.h. > > This patch set forms the base for a later set of patches for having > > a common system module base address (DAVINCI_SYSTEM_MODULE_BASE). > > Its easy to dismiss this series as causing "needless churn" by > moving around definitions from header to C files and consolidating > definitions from multiple header files to one. > > You need to do a better job of "selling" this series. The best way > to do that would be to include future patches which benefit from > this series into this series itself. This way, its clear to judge > the relative benefit of the "churn". You gave some examples, but > showing code helps. > > Also, one of the biggest gains from this series is reducing the > pollution in include/mach as asked by Russell in his "pet peaves" > mail. That should find reference in the cover letter and in the > commit text of patch 5/5. Indeed, and I hope it takes into account (at some point) the restart changes. From manjunath.hadli at ti.com Tue Dec 13 03:38:01 2011 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Tue, 13 Dec 2011 09:38:01 +0000 Subject: [PATCH v4 0/5] ARM: davinci: re-arrange definitions to have a common davinci header In-Reply-To: References: <1323352528-1207-1-git-send-email-manjunath.hadli@ti.com> Message-ID: Sekhar, On Mon, Dec 12, 2011 at 16:55:11, Nori, Sekhar wrote: > Hi Manju, > > On Thu, Dec 08, 2011 at 19:25:23, Hadli, Manjunath wrote: > > Re-arrange definitions and remove unnecessary code so that we can have > > a common header for all davinci platforms. This will enable us to > > share defines and enable common routines to be used without polluting > > hardware.h. > > This patch set forms the base for a later set of patches for having a > > common system module base address (DAVINCI_SYSTEM_MODULE_BASE). > > Its easy to dismiss this series as causing "needless churn" by moving around definitions from header to C files and consolidating definitions from multiple header files to one. > > You need to do a better job of "selling" this series. The best way to do that would be to include future patches which benefit from this series into this series itself. This way, its clear to judge the relative benefit of the "churn". You gave some examples, but showing code helps. Ok. Will do. I will send the 11 patch set completely so it is better appreciated. > > Also, one of the biggest gains from this series is reducing the pollution in include/mach as asked by Russell in his "pet peaves" > mail. That should find reference in the cover letter and in the commit text of patch 5/5. Ok. > > Thanks, > Sekhar Thx, -Manju > > > > > Changes from previous version: > > 1. Addressed Shekhar's comments for non-inclusion of mach headers from core. > > 2. Move the mach header from include to mach > > > > Manjunath Hadli (5): > > davinci: vpif: remove obsolete header file inclusion > > ARM: davinci: dm644x: remove the macros from the header to move to c > > file > > ARM: davinci: dm365: remove the macros from the header to move to c > > file > > ARM: davinci: dm646x: remove the macros from the header to move to c > > file > > ARM: davinci: create new common platform header for davinci > > > > arch/arm/mach-davinci/board-dm355-evm.c | 2 +- > > arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- > > arch/arm/mach-davinci/board-dm365-evm.c | 2 +- > > arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- > > arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- > > arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- > > arch/arm/mach-davinci/board-sffsdr.c | 2 +- > > arch/arm/mach-davinci/davinci.h | 88 +++++++++++++++++++++++++++ > > arch/arm/mach-davinci/dm355.c | 2 +- > > arch/arm/mach-davinci/dm365.c | 18 +++++- > > arch/arm/mach-davinci/dm644x.c | 9 +++- > > arch/arm/mach-davinci/dm646x.c | 9 +++- > > arch/arm/mach-davinci/include/mach/dm355.h | 32 ---------- > > arch/arm/mach-davinci/include/mach/dm365.h | 52 ---------------- > > arch/arm/mach-davinci/include/mach/dm644x.h | 47 -------------- > > arch/arm/mach-davinci/include/mach/dm646x.h | 41 ------------ > > drivers/media/video/davinci/vpif.h | 2 +- > > drivers/media/video/davinci/vpif_display.c | 2 - > > 18 files changed, 130 insertions(+), 186 deletions(-) create mode > > 100644 arch/arm/mach-davinci/davinci.h delete mode 100644 > > arch/arm/mach-davinci/include/mach/dm355.h > > delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h > > delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h > > delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h > > > > _______________________________________________ > > 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 manjunath.hadli at ti.com Tue Dec 13 05:23:24 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:24 +0530 Subject: [PATCH v5 00/11]ARM: davinci:add support for dm644x vpbe display driver Message-ID: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Re-arrange definitions and remove unnecessary code so that we can have a common header for all davinci platforms. This will enable us to share defines and enable common routines to be used without polluting hardware.h. This is consistent with Russel's pet peaves notes regarding non-pollution of include/mach. Having this as the base, have a common system module base address (DAVINCI_SYSTEM_MODULE_BASE) and removing IO_ADDRESS macro,add support for dm644x VPBE display driver. Manjunath Hadli (11): davinci: vpif: remove obsolete header file inclusion ARM: davinci: dm644x: remove the macros from the header to move to c file ARM: davinci: dm365: remove the macros from the header to move to c file ARM: davinci: dm646x: remove the macros from the header to move to c file ARM: davinci: create new common platform header for davinci davinci: eliminate use of IO_ADDRESS() on sysmod davinci: dm644x: Replace register base value with a defined macro davinci: dm644x: change vpfe capture structure variables for consistency davinci: dm644x: move vpfe init from soc to board specific files davinci: dm644x: add support for v4l2 video display davinci: dm644x EVM: add support for VPBE display arch/arm/mach-davinci/board-dm355-evm.c | 2 +- arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm644x-evm.c | 133 ++++++++++++++++-- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- arch/arm/mach-davinci/board-sffsdr.c | 2 +- arch/arm/mach-davinci/davinci.h | 101 +++++++++++++ arch/arm/mach-davinci/devices.c | 25 ++-- arch/arm/mach-davinci/dm355.c | 3 +- arch/arm/mach-davinci/dm365.c | 19 +++- arch/arm/mach-davinci/dm644x.c | 186 ++++++++++++++++++++++--- arch/arm/mach-davinci/dm646x.c | 10 ++- arch/arm/mach-davinci/include/mach/dm355.h | 32 ----- arch/arm/mach-davinci/include/mach/dm365.h | 52 ------- arch/arm/mach-davinci/include/mach/dm644x.h | 47 ------ arch/arm/mach-davinci/include/mach/dm646x.h | 41 ------ arch/arm/mach-davinci/include/mach/hardware.h | 2 - drivers/media/video/davinci/vpif.h | 2 +- drivers/media/video/davinci/vpif_display.c | 2 - 20 files changed, 438 insertions(+), 229 deletions(-) create mode 100644 arch/arm/mach-davinci/davinci.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h From manjunath.hadli at ti.com Tue Dec 13 05:23:31 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:31 +0530 Subject: [PATCH v5 07/11] davinci: dm644x: Replace register base value with a defined macro In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-8-git-send-email-manjunath.hadli@ti.com> Replace hard coded value of vpss register base to a define macro DM644X_VPSS_REG_BASE for proper readability Signed-off-by: Manjunath Hadli Acked-by: Sekhar Nori --- arch/arm/mach-davinci/dm644x.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 6b1d473..3802b59 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -594,13 +594,15 @@ static struct platform_device dm644x_asp_device = { .resource = dm644x_asp_resources, }; +#define DM644X_VPSS_REG_BASE 0x01c73400 + static struct resource dm644x_vpss_resources[] = { { /* VPSS Base address */ .name = "vpss", - .start = 0x01c73400, - .end = 0x01c73400 + 0xff, - .flags = IORESOURCE_MEM, + .start = DM644X_VPSS_REG_BASE, + .end = DM644X_VPSS_REG_BASE + 0xff, + .flags = IORESOURCE_MEM, }, }; -- 1.6.2.4 From manjunath.hadli at ti.com Tue Dec 13 05:23:27 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:27 +0530 Subject: [PATCH v5 03/11] ARM: davinci: dm365: remove the macros from the header to move to c file In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-4-git-send-email-manjunath.hadli@ti.com> move the register base addresses and offsets used only by dm365 platform file from platform header dm365.h to dm365.c as they are used only in the c file. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/dm365.c | 16 ++++++++++++++++ arch/arm/mach-davinci/include/mach/dm365.h | 16 ---------------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 679e168..77edee8 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -40,6 +40,22 @@ #define DM365_REF_FREQ 24000000 /* 24 MHz on the DM365 EVM */ +/* Base of key scan register bank */ +#define DM365_KEYSCAN_BASE 0x01c69400 + +#define DM365_RTC_BASE 0x01c69000 + +#define DAVINCI_DM365_VC_BASE 0x01d0c000 +#define DAVINCI_DMA_VC_TX 2 +#define DAVINCI_DMA_VC_RX 3 + +#define DM365_EMAC_BASE 0x01d07000 +#define DM365_EMAC_MDIO_BASE (DM365_EMAC_BASE + 0x4000) +#define DM365_EMAC_CNTRL_OFFSET 0x0000 +#define DM365_EMAC_CNTRL_MOD_OFFSET 0x3000 +#define DM365_EMAC_CNTRL_RAM_OFFSET 0x1000 +#define DM365_EMAC_CNTRL_RAM_SIZE 0x2000 + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h index 2563bf4..51924de 100644 --- a/arch/arm/mach-davinci/include/mach/dm365.h +++ b/arch/arm/mach-davinci/include/mach/dm365.h @@ -20,22 +20,6 @@ #include #include -#define DM365_EMAC_BASE (0x01D07000) -#define DM365_EMAC_MDIO_BASE (DM365_EMAC_BASE + 0x4000) -#define DM365_EMAC_CNTRL_OFFSET (0x0000) -#define DM365_EMAC_CNTRL_MOD_OFFSET (0x3000) -#define DM365_EMAC_CNTRL_RAM_OFFSET (0x1000) -#define DM365_EMAC_CNTRL_RAM_SIZE (0x2000) - -/* Base of key scan register bank */ -#define DM365_KEYSCAN_BASE (0x01C69400) - -#define DM365_RTC_BASE (0x01C69000) - -#define DAVINCI_DM365_VC_BASE (0x01D0C000) -#define DAVINCI_DMA_VC_TX 2 -#define DAVINCI_DMA_VC_RX 3 - #define DM365_ASYNC_EMIF_CONTROL_BASE 0x01D10000 #define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 #define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 -- 1.6.2.4 From manjunath.hadli at ti.com Tue Dec 13 05:23:28 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:28 +0530 Subject: [PATCH v5 04/11] ARM: davinci: dm646x: remove the macros from the header to move to c file In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-5-git-send-email-manjunath.hadli@ti.com> move the register base addresses and offsets used only by dm646x platform file from platform header dm646x.h to dm646x.c as they are used only in the c file. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/dm646x.c | 7 +++++++ arch/arm/mach-davinci/include/mach/dm646x.h | 7 ------- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 0b68ed5..0560e82 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -46,6 +46,13 @@ #define DM646X_REF_FREQ 27000000 #define DM646X_AUX_FREQ 24000000 +#define DM646X_EMAC_BASE 0x01c80000 +#define DM646X_EMAC_MDIO_BASE (DM646X_EMAC_BASE + 0x4000) +#define DM646X_EMAC_CNTRL_OFFSET 0x0000 +#define DM646X_EMAC_CNTRL_MOD_OFFSET 0x1000 +#define DM646X_EMAC_CNTRL_RAM_OFFSET 0x2000 +#define DM646X_EMAC_CNTRL_RAM_SIZE 0x2000 + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h index a8ee6c9..eb95864 100644 --- a/arch/arm/mach-davinci/include/mach/dm646x.h +++ b/arch/arm/mach-davinci/include/mach/dm646x.h @@ -18,13 +18,6 @@ #include #include -#define DM646X_EMAC_BASE (0x01C80000) -#define DM646X_EMAC_MDIO_BASE (DM646X_EMAC_BASE + 0x4000) -#define DM646X_EMAC_CNTRL_OFFSET (0x0000) -#define DM646X_EMAC_CNTRL_MOD_OFFSET (0x1000) -#define DM646X_EMAC_CNTRL_RAM_OFFSET (0x2000) -#define DM646X_EMAC_CNTRL_RAM_SIZE (0x2000) - #define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 #define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 -- 1.6.2.4 From manjunath.hadli at ti.com Tue Dec 13 05:23:26 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:26 +0530 Subject: [PATCH v5 02/11] ARM: davinci: dm644x: remove the macros from the header to move to c file In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-3-git-send-email-manjunath.hadli@ti.com> move the register base addresses and offsets used only by dm644x platform file from platform header dm644x.h to dm644x.c as they are used only in the c file. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/dm644x.c | 7 +++++++ arch/arm/mach-davinci/include/mach/dm644x.h | 7 ------- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 3470983..27d1371 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -35,6 +35,13 @@ */ #define DM644X_REF_FREQ 27000000 +#define DM644X_EMAC_BASE 0x01c80000 +#define DM644X_EMAC_MDIO_BASE (DM644X_EMAC_BASE + 0x4000) +#define DM644X_EMAC_CNTRL_OFFSET 0x0000 +#define DM644X_EMAC_CNTRL_MOD_OFFSET 0x1000 +#define DM644X_EMAC_CNTRL_RAM_OFFSET 0x2000 +#define DM644X_EMAC_CNTRL_RAM_SIZE 0x2000 + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h index 5a1b26d..724377f 100644 --- a/arch/arm/mach-davinci/include/mach/dm644x.h +++ b/arch/arm/mach-davinci/include/mach/dm644x.h @@ -27,13 +27,6 @@ #include #include -#define DM644X_EMAC_BASE (0x01C80000) -#define DM644X_EMAC_MDIO_BASE (DM644X_EMAC_BASE + 0x4000) -#define DM644X_EMAC_CNTRL_OFFSET (0x0000) -#define DM644X_EMAC_CNTRL_MOD_OFFSET (0x1000) -#define DM644X_EMAC_CNTRL_RAM_OFFSET (0x2000) -#define DM644X_EMAC_CNTRL_RAM_SIZE (0x2000) - #define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01E00000 #define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 #define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 -- 1.6.2.4 From manjunath.hadli at ti.com Tue Dec 13 05:23:29 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:29 +0530 Subject: [PATCH v5 05/11] ARM: davinci: create new common platform header for davinci In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-6-git-send-email-manjunath.hadli@ti.com> remove the code from individual platform header files for dm365, dm355, dm644x and dm646x and consolidate it into a single and common header file davinci.h. This reduces the pollution in the include/mach and is consistent with Russel's suggestions as part of his "pet peaves" mail. The further patches in the series take advantage of this consolidation for easy implementation of IO_ADDRESS elimination. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/board-dm355-evm.c | 2 +- arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- arch/arm/mach-davinci/board-sffsdr.c | 2 +- arch/arm/mach-davinci/davinci.h | 87 +++++++++++++++++++++++++++ arch/arm/mach-davinci/dm355.c | 2 +- arch/arm/mach-davinci/dm365.c | 2 +- arch/arm/mach-davinci/dm644x.c | 2 +- arch/arm/mach-davinci/dm646x.c | 2 +- arch/arm/mach-davinci/include/mach/dm355.h | 32 ---------- arch/arm/mach-davinci/include/mach/dm365.h | 36 ----------- arch/arm/mach-davinci/include/mach/dm644x.h | 40 ------------ arch/arm/mach-davinci/include/mach/dm646x.h | 34 ---------- 16 files changed, 98 insertions(+), 153 deletions(-) create mode 100644 arch/arm/mach-davinci/davinci.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index 4e0e707..7ae0d15 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -26,7 +26,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c index ff2d241..56f88de 100644 --- a/arch/arm/mach-davinci/board-dm355-leopard.c +++ b/arch/arm/mach-davinci/board-dm355-leopard.c @@ -23,7 +23,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index 1918ae7..613ed00 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -32,7 +32,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 0cf8abf..00e8599 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -30,7 +30,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index e574d7f..c0f9ea2 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -36,7 +36,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c index e5f231a..edc6ff7 100644 --- a/arch/arm/mach-davinci/board-neuros-osd2.c +++ b/arch/arm/mach-davinci/board-neuros-osd2.c @@ -30,7 +30,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c index 5dd4da9..122c7aa 100644 --- a/arch/arm/mach-davinci/board-sffsdr.c +++ b/arch/arm/mach-davinci/board-sffsdr.c @@ -35,7 +35,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h new file mode 100644 index 0000000..3e6def4 --- /dev/null +++ b/arch/arm/mach-davinci/davinci.h @@ -0,0 +1,87 @@ +/* + * This file contains the processor specific definitions + * of the TI DM644x, DM355, DM365, and DM646x. + * + * Copyright (C) 2011 Texas Instruments Incorporated + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#ifndef __DAVINCI_H +#define __DAVINCI_H + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* DM355 base addresses */ +#define DM355_ASYNC_EMIF_CONTROL_BASE 0x01e10000 +#define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 + +#define ASP1_TX_EVT_EN 1 +#define ASP1_RX_EVT_EN 2 + +/* DM365 base addresses */ +#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01d10000 +#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 +#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 + +/* DM644x base addresses */ +#define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01e00000 +#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 +#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 +#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000 +#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000 + +/* DM646x base addresses */ +#define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 +#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 + +/* DM355 function declarations */ +struct spi_board_info; + +void __init dm355_init(void); +void dm355_init_spi0(unsigned chipselect_mask, + struct spi_board_info *info, unsigned len); +void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); +void dm355_set_vpfe_config(struct vpfe_config *cfg); + +/* DM365 function declarations */ +void __init dm365_init(void); +void __init dm365_init_asp(struct snd_platform_data *pdata); +void __init dm365_init_vc(struct snd_platform_data *pdata); +void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); +void __init dm365_init_rtc(void); +void dm365_init_spi0(unsigned chipselect_mask, + struct spi_board_info *info, unsigned len); + +void dm365_set_vpfe_config(struct vpfe_config *cfg); + +/* DM644x function declarations */ +void __init dm644x_init(void); +void __init dm644x_init_asp(struct snd_platform_data *pdata); +void dm644x_set_vpfe_config(struct vpfe_config *cfg); + +/* DM646x function declarations */ +void __init dm646x_init(void); +void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); +void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); +int __init dm646x_init_edma(struct edma_rsv_info *rsv); + +void dm646x_video_init(void); + +void dm646x_setup_vpif(struct vpif_display_config *, + struct vpif_capture_config *); +#endif /*__DAVINCI_H */ diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index fe520d4..36744ff 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -18,7 +18,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 77edee8..3171cd1 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -21,7 +21,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 27d1371..b84b220 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -15,7 +15,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 0560e82..a6a9cde 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -16,7 +16,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/include/mach/dm355.h b/arch/arm/mach-davinci/include/mach/dm355.h deleted file mode 100644 index 36dff4a..0000000 --- a/arch/arm/mach-davinci/include/mach/dm355.h +++ /dev/null @@ -1,32 +0,0 @@ -/* - * Chip specific defines for DM355 SoC - * - * Author: Kevin Hilman, Deep Root Systems, LLC - * - * 2007 (c) Deep Root Systems, LLC. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. - */ -#ifndef __ASM_ARCH_DM355_H -#define __ASM_ARCH_DM355_H - -#include -#include -#include - -#define DM355_ASYNC_EMIF_CONTROL_BASE 0x01E10000 -#define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 - -#define ASP1_TX_EVT_EN 1 -#define ASP1_RX_EVT_EN 2 - -struct spi_board_info; - -void __init dm355_init(void); -void dm355_init_spi0(unsigned chipselect_mask, - struct spi_board_info *info, unsigned len); -void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); -void dm355_set_vpfe_config(struct vpfe_config *cfg); - -#endif /* __ASM_ARCH_DM355_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h deleted file mode 100644 index 51924de..0000000 --- a/arch/arm/mach-davinci/include/mach/dm365.h +++ /dev/null @@ -1,36 +0,0 @@ -/* - * Copyright (C) 2009 Texas Instruments Incorporated - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation version 2. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether express or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ -#ifndef __ASM_ARCH_DM365_H -#define __ASM_ARCH_DM665_H - -#include -#include -#include -#include -#include -#include - -#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01D10000 -#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 -#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 - -void __init dm365_init(void); -void __init dm365_init_asp(struct snd_platform_data *pdata); -void __init dm365_init_vc(struct snd_platform_data *pdata); -void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); -void __init dm365_init_rtc(void); -void dm365_init_spi0(unsigned chipselect_mask, - struct spi_board_info *info, unsigned len); - -void dm365_set_vpfe_config(struct vpfe_config *cfg); -#endif /* __ASM_ARCH_DM365_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h deleted file mode 100644 index 724377f..0000000 --- a/arch/arm/mach-davinci/include/mach/dm644x.h +++ /dev/null @@ -1,40 +0,0 @@ -/* - * This file contains the processor specific definitions - * of the TI DM644x. - * - * Copyright (C) 2008 Texas Instruments. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - * - */ -#ifndef __ASM_ARCH_DM644X_H -#define __ASM_ARCH_DM644X_H - -#include -#include -#include -#include - -#define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01E00000 -#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 -#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 -#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000 -#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000 - -void __init dm644x_init(void); -void __init dm644x_init_asp(struct snd_platform_data *pdata); -void dm644x_set_vpfe_config(struct vpfe_config *cfg); - -#endif /* __ASM_ARCH_DM644X_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h deleted file mode 100644 index eb95864..0000000 --- a/arch/arm/mach-davinci/include/mach/dm646x.h +++ /dev/null @@ -1,34 +0,0 @@ -/* - * Chip specific defines for DM646x SoC - * - * Author: Kevin Hilman, Deep Root Systems, LLC - * - * 2007 (c) Deep Root Systems, LLC. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. - */ -#ifndef __ASM_ARCH_DM646X_H -#define __ASM_ARCH_DM646X_H - -#include -#include -#include -#include -#include -#include - -#define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 -#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 - -void __init dm646x_init(void); -void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); -void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); -int __init dm646x_init_edma(struct edma_rsv_info *rsv); - -void dm646x_video_init(void); - -void dm646x_setup_vpif(struct vpif_display_config *, - struct vpif_capture_config *); - -#endif /* __ASM_ARCH_DM646X_H */ -- 1.6.2.4 From manjunath.hadli at ti.com Tue Dec 13 05:23:32 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:32 +0530 Subject: [PATCH v5 08/11] davinci: dm644x: change vpfe capture structure variables for consistency In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-9-git-send-email-manjunath.hadli@ti.com> Add SoC and board prefixes to variable names so that it is consistent with the rest of the file. Signed-off-by: Manjunath Hadli Acked-by: Sekhar Nori --- arch/arm/mach-davinci/board-dm644x-evm.c | 24 ++++++++++++------------ arch/arm/mach-davinci/dm644x.c | 12 ++++++------ 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 00e8599..fbd3856 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -189,7 +189,7 @@ static struct platform_device davinci_fb_device = { .num_resources = 0, }; -static struct tvp514x_platform_data tvp5146_pdata = { +static struct tvp514x_platform_data dm644xevm_tvp5146_pdata = { .clk_polarity = 0, .hs_polarity = 1, .vs_polarity = 1 @@ -197,7 +197,7 @@ static struct tvp514x_platform_data tvp5146_pdata = { #define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) /* Inputs available at the TVP5146 */ -static struct v4l2_input tvp5146_inputs[] = { +static struct v4l2_input dm644xevm_tvp5146_inputs[] = { { .index = 0, .name = "Composite", @@ -217,7 +217,7 @@ static struct v4l2_input tvp5146_inputs[] = { * ouput that goes to vpfe. There is a one to one correspondence * with tvp5146_inputs */ -static struct vpfe_route tvp5146_routes[] = { +static struct vpfe_route dm644xevm_tvp5146_routes[] = { { .input = INPUT_CVBS_VI2B, .output = OUTPUT_10BIT_422_EMBEDDED_SYNC, @@ -228,13 +228,13 @@ static struct vpfe_route tvp5146_routes[] = { }, }; -static struct vpfe_subdev_info vpfe_sub_devs[] = { +static struct vpfe_subdev_info dm644xevm_vpfe_sub_devs[] = { { .name = "tvp5146", .grp_id = 0, - .num_inputs = ARRAY_SIZE(tvp5146_inputs), - .inputs = tvp5146_inputs, - .routes = tvp5146_routes, + .num_inputs = ARRAY_SIZE(dm644xevm_tvp5146_inputs), + .inputs = dm644xevm_tvp5146_inputs, + .routes = dm644xevm_tvp5146_routes, .can_route = 1, .ccdc_if_params = { .if_type = VPFE_BT656, @@ -243,15 +243,15 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = { }, .board_info = { I2C_BOARD_INFO("tvp5146", 0x5d), - .platform_data = &tvp5146_pdata, + .platform_data = &dm644xevm_tvp5146_pdata, }, }, }; -static struct vpfe_config vpfe_cfg = { - .num_subdevs = ARRAY_SIZE(vpfe_sub_devs), +static struct vpfe_config dm644xevm_capture_cfg = { + .num_subdevs = ARRAY_SIZE(dm644xevm_vpfe_sub_devs), .i2c_adapter_id = 1, - .sub_devs = vpfe_sub_devs, + .sub_devs = dm644xevm_vpfe_sub_devs, .card_name = "DM6446 EVM", .ccdc = "DM6446 CCDC", }; @@ -625,7 +625,7 @@ static void __init davinci_evm_map_io(void) { /* setup input configuration for VPFE input devices */ - dm644x_set_vpfe_config(&vpfe_cfg); + dm644x_set_vpfe_config(&dm644xevm_capture_cfg); dm644x_init(); } diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 3802b59..1d9be87 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -614,7 +614,7 @@ static struct platform_device dm644x_vpss_device = { .resource = dm644x_vpss_resources, }; -static struct resource vpfe_resources[] = { +static struct resource dm644x_vpfe_resources[] = { { .start = IRQ_VDINT0, .end = IRQ_VDINT0, @@ -648,11 +648,11 @@ static struct platform_device dm644x_ccdc_dev = { }, }; -static struct platform_device vpfe_capture_dev = { +static struct platform_device dm644x_vpfe_dev = { .name = CAPTURE_DRV_NAME, .id = -1, - .num_resources = ARRAY_SIZE(vpfe_resources), - .resource = vpfe_resources, + .num_resources = ARRAY_SIZE(dm644x_vpfe_resources), + .resource = dm644x_vpfe_resources, .dev = { .dma_mask = &vpfe_capture_dma_mask, .coherent_dma_mask = DMA_BIT_MASK(32), @@ -661,7 +661,7 @@ static struct platform_device vpfe_capture_dev = { void dm644x_set_vpfe_config(struct vpfe_config *cfg) { - vpfe_capture_dev.dev.platform_data = cfg; + dm644x_vpfe_dev.dev.platform_data = cfg; } /*----------------------------------------------------------------------*/ @@ -809,7 +809,7 @@ static int __init dm644x_init_devices(void) platform_device_register(&dm644x_vpss_device); platform_device_register(&dm644x_ccdc_dev); - platform_device_register(&vpfe_capture_dev); + platform_device_register(&dm644x_vpfe_dev); return 0; } -- 1.6.2.4 From manjunath.hadli at ti.com Tue Dec 13 05:23:35 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:35 +0530 Subject: [PATCH v5 11/11] davinci: dm644x EVM: add support for VPBE display In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-12-git-send-email-manjunath.hadli@ti.com> This patch adds support for V4L2 video display to DM6446 EVM. Support for SD and ED modes is provided, along with Composite and Component outputs.Also added vpbe_config as a parameter for dm644x_init_video to allow for registration of vpbe platform devices. Signed-off-by: Manjunath Hadli Acked-by: Sekhar Nori --- arch/arm/mach-davinci/board-dm644x-evm.c | 108 +++++++++++++++++++++++++++++- 1 files changed, 107 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index eb7daff..af81dbb 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -612,6 +612,112 @@ static void __init evm_init_i2c(void) i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info)); } +#define VENC_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) + +/* venc standard timings */ +static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = { + { + .name = "ntsc", + .timings_type = VPBE_ENC_STD, + .timings = {V4L2_STD_525_60}, + .interlaced = 1, + .xres = 720, + .yres = 480, + .aspect = {11, 10}, + .fps = {30000, 1001}, + .left_margin = 0x79, + .upper_margin = 0x10, + }, + { + .name = "pal", + .timings_type = VPBE_ENC_STD, + .timings = {V4L2_STD_625_50}, + .interlaced = 1, + .xres = 720, + .yres = 576, + .aspect = {54, 59}, + .fps = {25, 1}, + .left_margin = 0x7e, + .upper_margin = 0x16, + }, +}; + +/* venc dv preset timings */ +static struct vpbe_enc_mode_info dm644xevm_enc_preset_timing[] = { + { + .name = "480p59_94", + .timings_type = VPBE_ENC_DV_PRESET, + .timings = {V4L2_DV_480P59_94}, + .interlaced = 0, + .xres = 720, + .yres = 480, + .aspect = {1, 1}, + .fps = {5994, 100}, + .left_margin = 0x80, + .upper_margin = 0x20, + }, + { + .name = "576p50", + .timings_type = VPBE_ENC_DV_PRESET, + .timings = {V4L2_DV_576P50}, + .interlaced = 0, + .xres = 720, + .yres = 576, + .aspect = {1, 1}, + .fps = {50, 1}, + .left_margin = 0x7e, + .upper_margin = 0x30, + }, +}; + +/* + * The outputs available from VPBE + encoders. Keep the order same + * as that of encoders. First those from venc followed by that from + * encoders. Index in the output refers to index on a particular encoder. + * Driver uses this index to pass it to encoder when it supports more than + * one output. Application uses index of the array to set an output. + */ +static struct vpbe_output dm644xevm_vpbe_outputs[] = { + { + .output = { + .index = 0, + .name = "Composite", + .type = V4L2_OUTPUT_TYPE_ANALOG, + .std = VENC_STD_ALL, + .capabilities = V4L2_OUT_CAP_STD, + }, + .subdev_name = VPBE_VENC_SUBDEV_NAME, + .default_mode = "ntsc", + .num_modes = ARRAY_SIZE(dm644xevm_enc_std_timing), + .modes = dm644xevm_enc_std_timing, + }, + { + .output = { + .index = 1, + .name = "Component", + .type = V4L2_OUTPUT_TYPE_ANALOG, + .capabilities = V4L2_OUT_CAP_PRESETS, + }, + .subdev_name = VPBE_VENC_SUBDEV_NAME, + .default_mode = "480p59_94", + .num_modes = ARRAY_SIZE(dm644xevm_enc_preset_timing), + .modes = dm644xevm_enc_preset_timing, + }, +}; + +static struct vpbe_config dm644xevm_display_cfg = { + .module_name = "dm644x-vpbe-display", + .i2c_adapter_id = 1, + .osd = { + .module_name = VPBE_OSD_SUBDEV_NAME, + }, + .venc = { + .module_name = VPBE_VENC_SUBDEV_NAME, + }, + .num_outputs = ARRAY_SIZE(dm644xevm_vpbe_outputs), + .outputs = dm644xevm_vpbe_outputs, +}; + static struct platform_device *davinci_evm_devices[] __initdata = { &davinci_fb_device, &rtc_dev, @@ -695,7 +801,7 @@ static __init void davinci_evm_init(void) evm_init_i2c(); davinci_setup_mmc(0, &dm6446evm_mmc_config); - dm644x_init_video(&dm644xevm_capture_cfg, NULL); + dm644x_init_video(&dm644xevm_capture_cfg, &dm644xevm_display_cfg); davinci_serial_init(&uart_config); dm644x_init_asp(&dm644x_evm_snd_data); -- 1.6.2.4 From manjunath.hadli at ti.com Tue Dec 13 05:23:34 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:34 +0530 Subject: [PATCH v5 10/11] davinci: dm644x: add support for v4l2 video display In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-11-git-send-email-manjunath.hadli@ti.com> Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm644x. Change the dm644x_init_video to make room for display config, and register the vpfe or vpbe devices based on the config pointer validity to make sure boards without vpfe or vpbe can be built with minimal changes. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- arch/arm/mach-davinci/davinci.h | 7 +- arch/arm/mach-davinci/dm644x.c | 163 +++++++++++++++++++++++++++--- 3 files changed, 154 insertions(+), 18 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 8884125..eb7daff 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -695,7 +695,7 @@ static __init void davinci_evm_init(void) evm_init_i2c(); davinci_setup_mmc(0, &dm6446evm_mmc_config); - dm644x_init_video(&dm644xevm_capture_cfg); + dm644x_init_video(&dm644xevm_capture_cfg, NULL); davinci_serial_init(&uart_config); dm644x_init_asp(&dm644x_evm_snd_data); diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h index 13cb029..bdaa586 100644 --- a/arch/arm/mach-davinci/davinci.h +++ b/arch/arm/mach-davinci/davinci.h @@ -26,6 +26,11 @@ #include #include #include +#include +#include +#include +#include +#include #define DAVINCI_SYSTEM_MODULE_BASE 0x01c40000 @@ -81,7 +86,7 @@ void dm365_set_vpfe_config(struct vpfe_config *cfg); /* DM644x function declarations */ void __init dm644x_init(void); void __init dm644x_init_asp(struct snd_platform_data *pdata); -int __init dm644x_init_video(struct vpfe_config *); +int __init dm644x_init_video(struct vpfe_config *, struct vpbe_config *); /* DM646x function declarations */ void __init dm646x_init(void); diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 6c034fd..2e408d8 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -627,7 +627,7 @@ static struct resource dm644x_vpfe_resources[] = { }, }; -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); +static u64 dm644x_video_dma_mask = DMA_BIT_MASK(32); static struct resource dm644x_ccdc_resource[] = { /* CCDC Base address */ { @@ -643,7 +643,7 @@ static struct platform_device dm644x_ccdc_dev = { .num_resources = ARRAY_SIZE(dm644x_ccdc_resource), .resource = dm644x_ccdc_resource, .dev = { - .dma_mask = &vpfe_capture_dma_mask, + .dma_mask = &dm644x_video_dma_mask, .coherent_dma_mask = DMA_BIT_MASK(32), }, }; @@ -654,7 +654,127 @@ static struct platform_device dm644x_vpfe_dev = { .num_resources = ARRAY_SIZE(dm644x_vpfe_resources), .resource = dm644x_vpfe_resources, .dev = { - .dma_mask = &vpfe_capture_dma_mask, + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, +}; + +#define DM644X_OSD_REG_BASE 0x01c72600 + +static struct resource dm644x_osd_resources[] = { + { + .start = DM644X_OSD_REG_BASE, + .end = DM644X_OSD_REG_BASE + 0x1ff, + .flags = IORESOURCE_MEM, + }, +}; + +static struct osd_platform_data dm644x_osd_data = { + .vpbe_type = VPBE_VERSION_1, +}; + +static struct platform_device dm644x_osd_dev = { + .name = VPBE_OSD_SUBDEV_NAME, + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_osd_resources), + .resource = dm644x_osd_resources, + .dev = { + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = &dm644x_osd_data, + }, +}; + +#define DM644X_VENC_REG_BASE 0x01c72400 + +static struct resource dm644x_venc_resources[] = { + { + .start = DM644X_VENC_REG_BASE, + .end = DM644X_VENC_REG_BASE + 0x17f, + .flags = IORESOURCE_MEM, + }, +}; + +static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, + unsigned int mode) +{ + int ret = 0; + void __iomem *vpss_clkctl_reg; + + vpss_clkctl_reg = DAVINCI_SYSMODULE_VIRT(0x44); + + switch (type) { + case VPBE_ENC_STD: + writel(0x18, vpss_clkctl_reg); + break; + case VPBE_ENC_DV_PRESET: + switch ((unsigned int)mode) { + case V4L2_DV_480P59_94: + case V4L2_DV_576P50: + writel(0x19, vpss_clkctl_reg); + break; + case V4L2_DV_720P60: + case V4L2_DV_1080I60: + case V4L2_DV_1080P30: + /* + * For HD, use external clock source since + * HD requires higher clock rate + */ + writel(0xa, vpss_clkctl_reg); + break; + default: + ret = -EINVAL; + break; + } + break; + default: + ret = -EINVAL; + } + + return ret; +} + +static struct resource dm644x_v4l2_disp_resources[] = { + { + .start = IRQ_VENCINT, + .end = IRQ_VENCINT, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct platform_device dm644x_vpbe_display = { + .name = "vpbe-v4l2", + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources), + .resource = dm644x_v4l2_disp_resources, + .dev = { + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, +}; + +static struct venc_platform_data dm644x_venc_pdata = { + .venc_type = VPBE_VERSION_1, + .setup_clock = dm644x_venc_setup_clock, +}; + +static struct platform_device dm644x_venc_dev = { + .name = VPBE_VENC_SUBDEV_NAME, + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_venc_resources), + .resource = dm644x_venc_resources, + .dev = { + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = &dm644x_venc_pdata, + }, +}; + +static struct platform_device dm644x_vpbe_dev = { + .name = "vpbe_controller", + .id = -1, + .dev = { + .dma_mask = &dm644x_video_dma_mask, .coherent_dma_mask = DMA_BIT_MASK(32), }, }; @@ -787,20 +907,31 @@ void __init dm644x_init(void) davinci_map_sysmod(); } -static struct platform_device *dm644x_video_devices[] __initdata = { - &dm644x_vpss_device, - &dm644x_ccdc_dev, - &dm644x_vpfe_dev, -}; - -int __init dm644x_init_video(struct vpfe_config *vpfe_cfg) +int __init dm644x_init_video(struct vpfe_config *vpfe_cfg, + struct vpbe_config *vpbe_cfg) { - dm644x_vpfe_dev.dev.platform_data = vpfe_cfg; - /* Add ccdc clock aliases */ - clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL); - clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL); - platform_add_devices(dm644x_video_devices, - ARRAY_SIZE(dm644x_video_devices)); + if (vpfe_cfg || vpbe_cfg) + platform_device_register(&dm644x_vpss_device); + + if (vpfe_cfg) { + dm644x_vpfe_dev.dev.platform_data = vpfe_cfg; + platform_device_register(&dm644x_ccdc_dev); + platform_device_register(&dm644x_vpfe_dev); + /* Add ccdc clock aliases */ + clk_add_alias("master", dm644x_ccdc_dev.name, + "vpss_master", NULL); + clk_add_alias("slave", dm644x_ccdc_dev.name, + "vpss_slave", NULL); + } + + if (vpbe_cfg) { + dm644x_vpbe_dev.dev.platform_data = vpbe_cfg; + platform_device_register(&dm644x_osd_dev); + platform_device_register(&dm644x_venc_dev); + platform_device_register(&dm644x_vpbe_dev); + platform_device_register(&dm644x_vpbe_display); + } + return 0; } -- 1.6.2.4 From manjunath.hadli at ti.com Tue Dec 13 05:23:33 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:33 +0530 Subject: [PATCH v5 09/11] davinci: dm644x: move vpfe init from soc to board specific files In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-10-git-send-email-manjunath.hadli@ti.com> Move all vpfe platform device registrations to the board specific file like the rest of the devices, and have all of them together. This would remove the restriction of inclusion and registration of vpfe platform devices for non-vpfe boards. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/board-dm644x-evm.c | 3 +-- arch/arm/mach-davinci/davinci.h | 2 +- arch/arm/mach-davinci/dm644x.c | 29 +++++++++++++++++------------ 3 files changed, 19 insertions(+), 15 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index fbd3856..8884125 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -624,8 +624,6 @@ static struct davinci_uart_config uart_config __initdata = { static void __init davinci_evm_map_io(void) { - /* setup input configuration for VPFE input devices */ - dm644x_set_vpfe_config(&dm644xevm_capture_cfg); dm644x_init(); } @@ -697,6 +695,7 @@ static __init void davinci_evm_init(void) evm_init_i2c(); davinci_setup_mmc(0, &dm6446evm_mmc_config); + dm644x_init_video(&dm644xevm_capture_cfg); davinci_serial_init(&uart_config); dm644x_init_asp(&dm644x_evm_snd_data); diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h index 06ed38a..13cb029 100644 --- a/arch/arm/mach-davinci/davinci.h +++ b/arch/arm/mach-davinci/davinci.h @@ -81,7 +81,7 @@ void dm365_set_vpfe_config(struct vpfe_config *cfg); /* DM644x function declarations */ void __init dm644x_init(void); void __init dm644x_init_asp(struct snd_platform_data *pdata); -void dm644x_set_vpfe_config(struct vpfe_config *cfg); +int __init dm644x_init_video(struct vpfe_config *); /* DM646x function declarations */ void __init dm646x_init(void); diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 1d9be87..6c034fd 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -659,11 +659,6 @@ static struct platform_device dm644x_vpfe_dev = { }, }; -void dm644x_set_vpfe_config(struct vpfe_config *cfg) -{ - dm644x_vpfe_dev.dev.platform_data = cfg; -} - /*----------------------------------------------------------------------*/ static struct map_desc dm644x_io_desc[] = { @@ -792,14 +787,28 @@ void __init dm644x_init(void) davinci_map_sysmod(); } +static struct platform_device *dm644x_video_devices[] __initdata = { + &dm644x_vpss_device, + &dm644x_ccdc_dev, + &dm644x_vpfe_dev, +}; + +int __init dm644x_init_video(struct vpfe_config *vpfe_cfg) +{ + dm644x_vpfe_dev.dev.platform_data = vpfe_cfg; + /* Add ccdc clock aliases */ + clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL); + clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL); + platform_add_devices(dm644x_video_devices, + ARRAY_SIZE(dm644x_video_devices)); + return 0; +} + static int __init dm644x_init_devices(void) { if (!cpu_is_davinci_dm644x()) return 0; - /* Add ccdc clock aliases */ - clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL); - clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL); platform_device_register(&dm644x_edma_device); platform_device_register(&dm644x_mdio_device); @@ -807,10 +816,6 @@ static int __init dm644x_init_devices(void) clk_add_alias(NULL, dev_name(&dm644x_mdio_device.dev), NULL, &dm644x_emac_device.dev); - platform_device_register(&dm644x_vpss_device); - platform_device_register(&dm644x_ccdc_dev); - platform_device_register(&dm644x_vpfe_dev); - return 0; } postcore_initcall(dm644x_init_devices); -- 1.6.2.4 From manjunath.hadli at ti.com Tue Dec 13 05:23:30 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:30 +0530 Subject: [PATCH v5 06/11] davinci: eliminate use of IO_ADDRESS() on sysmod In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-7-git-send-email-manjunath.hadli@ti.com> Current devices.c file has a number of instances where IO_ADDRESS() is used for system module register access. Eliminate this in favor of a ioremap() based access. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/davinci.h | 9 +++++++++ arch/arm/mach-davinci/devices.c | 25 ++++++++++++++++--------- arch/arm/mach-davinci/dm355.c | 1 + arch/arm/mach-davinci/dm365.c | 1 + arch/arm/mach-davinci/dm644x.c | 1 + arch/arm/mach-davinci/dm646x.c | 1 + arch/arm/mach-davinci/include/mach/hardware.h | 2 -- 7 files changed, 29 insertions(+), 11 deletions(-) diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h index 3e6def4..06ed38a 100644 --- a/arch/arm/mach-davinci/davinci.h +++ b/arch/arm/mach-davinci/davinci.h @@ -20,12 +20,21 @@ #include #include #include +#include #include #include #include #include #include +#define DAVINCI_SYSTEM_MODULE_BASE 0x01c40000 + +#ifndef __ASSEMBLER__ +extern void __iomem *davinci_sysmodbase; +#define DAVINCI_SYSMODULE_VIRT(x) (davinci_sysmodbase + (x)) +void davinci_map_sysmod(void); +#endif + /* DM355 base addresses */ #define DM355_ASYNC_EMIF_CONTROL_BASE 0x01e10000 #define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c index 806a2f0..580d48a 100644 --- a/arch/arm/mach-davinci/devices.c +++ b/arch/arm/mach-davinci/devices.c @@ -22,6 +22,7 @@ #include #include #include +#include "davinci.h" #include "clock.h" @@ -36,6 +37,14 @@ /* System control register offsets */ #define DM64XX_VDD3P3V_PWDN 0x48 +void __iomem *davinci_sysmodbase; + +void davinci_map_sysmod(void) +{ + davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800); + WARN_ON(!davinci_sysmodbase); +} + static struct resource i2c_resources[] = { { .start = DAVINCI_I2C_BASE, @@ -212,12 +221,12 @@ void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config) davinci_cfg_reg(DM355_SD1_DATA2); davinci_cfg_reg(DM355_SD1_DATA3); } else if (cpu_is_davinci_dm365()) { - void __iomem *pupdctl1 = - IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c); - /* Configure pull down control */ - __raw_writel((__raw_readl(pupdctl1) & ~0xfc0), - pupdctl1); + void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c); + unsigned v; + + v = __raw_readl(pupdctl1); + __raw_writel(v & ~0xfc0, pupdctl1); mmcsd1_resources[0].start = DM365_MMCSD1_BASE; mmcsd1_resources[0].end = DM365_MMCSD1_BASE + @@ -246,11 +255,9 @@ void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config) mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0; } else if (cpu_is_davinci_dm644x()) { /* REVISIT: should this be in board-init code? */ - void __iomem *base = - IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE); - /* Power-on 3.3V IO cells */ - __raw_writel(0, base + DM64XX_VDD3P3V_PWDN); + __raw_writel(0, + DAVINCI_SYSMODULE_VIRT(DM64XX_VDD3P3V_PWDN)); /*Set up the pull regiter for MMC */ davinci_cfg_reg(DM644X_MSTK); } diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index 36744ff..1f90c5a 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -872,6 +872,7 @@ void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata) void __init dm355_init(void) { davinci_common_init(&davinci_soc_info_dm355); + davinci_map_sysmod(); } static int __init dm355_init_devices(void) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 3171cd1..f0801b9 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -1139,6 +1139,7 @@ void __init dm365_init_rtc(void) void __init dm365_init(void) { davinci_common_init(&davinci_soc_info_dm365); + davinci_map_sysmod(); } static struct resource dm365_vpss_resources[] = { diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index b84b220..6b1d473 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -787,6 +787,7 @@ void __init dm644x_init_asp(struct snd_platform_data *pdata) void __init dm644x_init(void) { davinci_common_init(&davinci_soc_info_dm644x); + davinci_map_sysmod(); } static int __init dm644x_init_devices(void) diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index a6a9cde..1da02fe 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -914,6 +914,7 @@ int __init dm646x_init_edma(struct edma_rsv_info *rsv) void __init dm646x_init(void) { davinci_common_init(&davinci_soc_info_dm646x); + davinci_map_sysmod(); } static int __init dm646x_init_devices(void) diff --git a/arch/arm/mach-davinci/include/mach/hardware.h b/arch/arm/mach-davinci/include/mach/hardware.h index 414e0b9..0209b1f 100644 --- a/arch/arm/mach-davinci/include/mach/hardware.h +++ b/arch/arm/mach-davinci/include/mach/hardware.h @@ -19,8 +19,6 @@ * and the chip/board init code should then explicitly include * .h */ -#define DAVINCI_SYSTEM_MODULE_BASE 0x01C40000 - /* * I/O mapping */ -- 1.6.2.4 From manjunath.hadli at ti.com Tue Dec 13 05:23:25 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Tue, 13 Dec 2011 16:53:25 +0530 Subject: [PATCH v5 01/11] davinci: vpif: remove obsolete header file inclusion In-Reply-To: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323775415-24504-2-git-send-email-manjunath.hadli@ti.com> remove inclusion of header files from vpif.h and vpif_dispaly.c and add appropriate header file for building. Signed-off-by: Manjunath Hadli Cc: Mauro Carvalho Chehab Cc: LMML --- drivers/media/video/davinci/vpif.h | 2 +- drivers/media/video/davinci/vpif_display.c | 2 -- 2 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/davinci/vpif.h b/drivers/media/video/davinci/vpif.h index 25036cb..c96268a 100644 --- a/drivers/media/video/davinci/vpif.h +++ b/drivers/media/video/davinci/vpif.h @@ -19,7 +19,7 @@ #include #include #include -#include +#include #include /* Maximum channel allowed */ diff --git a/drivers/media/video/davinci/vpif_display.c b/drivers/media/video/davinci/vpif_display.c index 286f029..7fa34b4 100644 --- a/drivers/media/video/davinci/vpif_display.c +++ b/drivers/media/video/davinci/vpif_display.c @@ -39,8 +39,6 @@ #include #include -#include - #include "vpif_display.h" #include "vpif.h" -- 1.6.2.4 From prakash.pm at ti.com Tue Dec 13 08:45:33 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Tue, 13 Dec 2011 14:45:33 +0000 Subject: [PATCH] video:da8xx-fb: Add 24bpp LCD configuration support In-Reply-To: <4ED00893.2070809@gmx.de> References: <1321358479-20390-1-git-send-email-prakash.pm@ti.com> <4EC84CC8.10102@gmx.de> <4ED00893.2070809@gmx.de> Message-ID: Hi Florian Tobias Schandinat, On Sat, Nov 26, 2011 at 02:58:51, Florian Tobias Schandinat wrote: > On 11/25/2011 07:45 AM, Manjunathappa, Prakash wrote: > > Hi Florian Tobias Schandinat > > > > On Sun, Nov 20, 2011 at 06:11:44, Florian Tobias Schandinat wrote: > >> On 11/15/2011 12:01 PM, Manjunathappa, Prakash wrote: > >>> LCD controller on am335x supports 24bpp raster configuration > >>> in addition to ones on da850. LCDC also supports 24bpp in unpacked > >>> format having ARGB:8888 32bpp format data in DDR, but it doesn't > >>> interpret Alpha component of the data. > >>> > >>> Signed-off-by: Manjunathappa, Prakash > >>> --- > >>> drivers/video/da8xx-fb.c | 57 +++++++++++++++++++++++++++++++++++++++++++++- > >>> 1 files changed, 56 insertions(+), 1 deletions(-) > >>> > >>> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c > >>> index 55f91d9..e111971 100644 > >>> --- a/drivers/video/da8xx-fb.c > >>> +++ b/drivers/video/da8xx-fb.c > >>> @@ -82,6 +82,8 @@ > >>> #define LCD_V2_LIDD_CLK_EN BIT(1) > >>> #define LCD_V2_CORE_CLK_EN BIT(0) > >>> #define LCD_V2_LPP_B10 26 > >>> +#define LCD_V2_TFT_24BPP_MODE BIT(25) > >>> +#define LCD_V2_TFT_24BPP_UNPACK BIT(26) > >>> > >>> /* LCD Raster Timing 2 Register */ > >>> #define LCD_AC_BIAS_TRANSITIONS_PER_INT(x) ((x) << 16) > >>> @@ -151,7 +153,7 @@ struct da8xx_fb_par { > >>> unsigned int dma_end; > >>> struct clk *lcdc_clk; > >>> int irq; > >>> - unsigned short pseudo_palette[16]; > >>> + unsigned short pseudo_palette[32]; > >> > >> This looks wrong, include/linux/fb.h says: > >> "void *pseudo_palette; /* Fake palette of 16 colors */" > >> This will probably also simplify the code below to write to the pseudo palette. > >> But I think you have to increase the data type of the palette, maybe to u32? > >> > >> > > > > Yes, I accept that data type has to be changed to u32. But how does it simplify updating of pseudo palette. > > Your code is even buggier than I saw. Where did you get the information how to > write fb_setcolreg? > First, as I wrote in my last mail, the pseudo_palette has always exactly 16 > colors, regardless of the color depth. > Second, the existing code is some sort of wrong to check for bpp the only thing > that really matters is whether it is Truecolor or not, the code for handling the > Truecolor case will very likely be always the same regardless of the bpp, just > the values in {red,green,blue}{length,offset} differ. > Third your patch is wrong in using 24 in things like > red >>= (24 - info->var.red.length); > skeletonfb.c: "The values supplied have a 16 bit magnitude which needs to be > scaled in this function for the hardware." > So it has to be 16, always. > > Just have a look at drivers/video/skeletonfb.c, it contains much useful information. > > > Best regards, > > Florian Tobias Schandinat > Thanks for pointing out to skeletonfb.c. I will submit next version based on this. Thanks, Prakash [...] From nsekhar at ti.com Tue Dec 13 12:34:27 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 13 Dec 2011 18:34:27 +0000 Subject: [PATCH] arm,davinci: configure davinci aemif chipselects through OF In-Reply-To: <201112081548.08548.arnd@arndb.de> References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EE07E27.8090602@denx.de> <201112081548.08548.arnd@arndb.de> Message-ID: Hi Arnd, On Thu, Dec 08, 2011 at 21:18:08, Arnd Bergmann wrote: > On Thursday 08 December 2011, Nori, Sekhar wrote: > > DaVinci AEMIF is an async memory interface peripheral implemented > > in arch/arm/mach-davinci/aemif.c. It helps interface to NAND, NOR > > and other asynchronous memories. Currently it just provides an API > > for timing value configuration. The API is invoked by the MTD NAND > > driver. > > > > Specification here: http://www.ti.com/lit/ug/sprue20c/sprue20c.pdf > > > > We are looking at a place for this outside of architecture code. > > I think the best place depends on how you plan to use the sram > interface. If all memory behind the aemif is handled by mtd, I would > put the entire driver somewhere in the mtd infrastructure. All the boards and use cases I have come across for AEMIF so far (5-6 years) have either used NAND or NOR memory. > If you want it to provide endpoint devices that are handled by > distinct subsystems in Linux, I would make it an mfd multifunction > device and make the common code a driver that scans the connected > memories in order to register its child devices for each of the > subsystems. Okay. Thanks for the explanation. Since the users of AEMIF at this point are mtd devices, I propose moving it to drivers/mtd/davinci-aemif.c (of course, mtd folks need to approve). Thanks, Sekhar From sshtylyov at mvista.com Wed Dec 14 04:36:41 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Wed, 14 Dec 2011 14:36:41 +0400 Subject: [PATCH v5 07/11] davinci: dm644x: Replace register base value with a defined macro In-Reply-To: <1323775415-24504-8-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> <1323775415-24504-8-git-send-email-manjunath.hadli@ti.com> Message-ID: <4EE87C39.8010601@mvista.com> Hello. On 13-12-2011 15:23, Manjunath Hadli wrote: > Replace hard coded value of vpss register base to a define macro > DM644X_VPSS_REG_BASE for proper readability > Signed-off-by: Manjunath Hadli > Acked-by: Sekhar Nori > --- > arch/arm/mach-davinci/dm644x.c | 8 +++++--- > 1 files changed, 5 insertions(+), 3 deletions(-) > diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c > index 6b1d473..3802b59 100644 > --- a/arch/arm/mach-davinci/dm644x.c > +++ b/arch/arm/mach-davinci/dm644x.c > @@ -594,13 +594,15 @@ static struct platform_device dm644x_asp_device = { > .resource = dm644x_asp_resources, > }; > > +#define DM644X_VPSS_REG_BASE 0x01c73400 > + Why not simply DM644X_VPSS_BASE, like all the other #define's? WBR, Sergei From sshtylyov at mvista.com Wed Dec 14 04:48:40 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Wed, 14 Dec 2011 14:48:40 +0400 Subject: [PATCH v5 10/11] davinci: dm644x: add support for v4l2 video display In-Reply-To: <1323775415-24504-11-git-send-email-manjunath.hadli@ti.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> <1323775415-24504-11-git-send-email-manjunath.hadli@ti.com> Message-ID: <4EE87F08.6080309@mvista.com> Hello. On 13-12-2011 15:23, Manjunath Hadli wrote: > Create platform devices for various video modules like venc,osd, > vpbe and v4l2 driver for dm644x. Change the dm644x_init_video to > make room for display config, and register the vpfe or vpbe devices > based on the config pointer validity to make sure boards without vpfe > or vpbe can be built with minimal changes. > Signed-off-by: Manjunath Hadli [...] > diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c > index 6c034fd..2e408d8 100644 > --- a/arch/arm/mach-davinci/dm644x.c > +++ b/arch/arm/mach-davinci/dm644x.c [...] > @@ -654,7 +654,127 @@ static struct platform_device dm644x_vpfe_dev = { [...] > +#define DM644X_OSD_REG_BASE 0x01c72600 [...] > +#define DM644X_VENC_REG_BASE 0x01c72400 Why not without _REG, like all the other #define's? > +static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, > + unsigned int mode) > +{ > + int ret = 0; > + void __iomem *vpss_clkctl_reg; > + > + vpss_clkctl_reg = DAVINCI_SYSMODULE_VIRT(0x44); Why not in the initializer? > + switch (type) { > + case VPBE_ENC_STD: > + writel(0x18, vpss_clkctl_reg); > + break; > + case VPBE_ENC_DV_PRESET: > + switch ((unsigned int)mode) { 'mode' is already 'unsigned int'. WBR, Sergei From nsekhar at ti.com Wed Dec 14 07:14:14 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Wed, 14 Dec 2011 13:14:14 +0000 Subject: [PATCH] ARM: davinci: add missing commas on last members of structure and arrays In-Reply-To: <1323335151-25398-1-git-send-email-akshay.s@ti.com> References: <1323335151-25398-1-git-send-email-akshay.s@ti.com> Message-ID: Hi Akshay, On Thu, Dec 08, 2011 at 14:35:51, Shankarmurthy, Akshay wrote: > This patch adds missing commas on last members of structure and arrays. > This makes less harder to add additional initializer at the end of the > existing initializers and avoids the conflict of more line being > modified. This was pointed out by Russell King in his pet peeves mail at > http://www.spinics.net/lists/arm-kernel/msg147268.html. Tony has already provided link to his patches fixing this in the message you referenced. Is your patch catching any additional instances? Tony's patch adds comma after some sentinels, which should be dropped. Thanks, Sekhar From bengardiner at nanometrics.ca Wed Dec 14 08:35:25 2011 From: bengardiner at nanometrics.ca (Ben Gardiner) Date: Wed, 14 Dec 2011 09:35:25 -0500 Subject: [PATCH] arm, davinci: configure davinci aemif chipselects through OF In-Reply-To: References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EE07E27.8090602@denx.de> <201112081548.08548.arnd@arndb.de> Message-ID: Hello Arnd and Sekhar, On Tue, Dec 13, 2011 at 1:34 PM, Nori, Sekhar wrote: > [...] > On Thu, Dec 08, 2011 at 21:18:08, Arnd Bergmann wrote: >> [...] >> If you want it to provide endpoint devices that are handled by >> distinct subsystems in Linux, I would make it an mfd multifunction >> device and make the common code a driver that scans the connected >> memories in order to register its child devices for each of the >> subsystems. > > Okay. Thanks for the explanation. Since the users of AEMIF at this > point are mtd devices, I propose moving it to drivers/mtd/davinci-aemif.c > (of course, mtd folks need to approve). We have a vested interest in the davinci AEMIF setup facilities in-kernel; I'm electing to pipe-up now rather than later. Sadly our board is not yet in mainline so my opinions may be redirected to the bit-bucket as you see fit. We are planning to post a patch series for our complete board support -- but we can't do it right now. The AEMIF is useful for interfacing to other asynchronous devices too; our newest board uses it for accessing memory mapped FPGA functional blocks via UIO and for permanent storage to a compact flash using pata_platform. In both cases the timings and mode for the chip-select are manually configured before the devices are registered. In both cases the performance of the endpoints could be better preserved across CPU freq transitions if the hooks for cpufreq transitions recently proposed by Sudhakar [1] were part of an mfd device and hence applicable to devices other than mtd. Again, I apologize for requesting features for boards that are not yet in mainline. Best Regards, Ben Gardiner [1] http://article.gmane.org/gmane.linux.drivers.mtd/36876/ --- Nanometrics Inc. http://www.nanometrics.ca From nsekhar at ti.com Wed Dec 14 12:09:31 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Wed, 14 Dec 2011 18:09:31 +0000 Subject: [GIT PULL] DaVinci cleanup for v3.3 Message-ID: Hi Arnd, I have this lone patch queued for DaVinci clean-up so far. Can you please pull this? Thanks, Sekhar The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139: Linus Torvalds (1): Linux 3.2-rc3 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git v3.3/cleanup Manjunath Hadli (1): ARM: davinci: vpif: move code to driver core header from platform arch/arm/mach-davinci/include/mach/dm646x.h | 53 +------------------- drivers/media/video/davinci/vpif.h | 1 + drivers/media/video/davinci/vpif_capture.h | 2 +- drivers/media/video/davinci/vpif_display.h | 1 + include/media/davinci/vpif_types.h | 71 +++++++++++++++++++++++++++ 5 files changed, 75 insertions(+), 53 deletions(-) create mode 100644 include/media/davinci/vpif_types.h From nsekhar at ti.com Wed Dec 14 12:34:14 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Wed, 14 Dec 2011 18:34:14 +0000 Subject: [GIT PULL] DaVinci features for v3.3 Message-ID: Arnd, Olof, I have this lone feature queued for v3.3 so far. Can you please pull? The patch depends on v3.2-rc5 for build, but I have not rebased to preserve the commit date. Thanks, Sekhar The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139: Linus Torvalds (1): Linux 3.2-rc3 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git v3.3/features Murali Karicheri (1): ARM: davinci: add support for multiple power domains arch/arm/mach-davinci/clock.c | 13 +++---------- arch/arm/mach-davinci/clock.h | 10 +++++----- arch/arm/mach-davinci/dm644x.c | 4 ++-- 3 files changed, 10 insertions(+), 17 deletions(-) From tony at atomide.com Wed Dec 14 16:00:05 2011 From: tony at atomide.com (Tony Lindgren) Date: Wed, 14 Dec 2011 14:00:05 -0800 Subject: [PATCH] ARM: davinci: add missing commas on last members of structure and arrays In-Reply-To: References: <1323335151-25398-1-git-send-email-akshay.s@ti.com> Message-ID: <20111214220005.GQ32251@atomide.com> * Nori, Sekhar [111214 04:42]: > Hi Akshay, > > On Thu, Dec 08, 2011 at 14:35:51, Shankarmurthy, Akshay wrote: > > This patch adds missing commas on last members of structure and arrays. > > This makes less harder to add additional initializer at the end of the > > existing initializers and avoids the conflict of more line being > > modified. This was pointed out by Russell King in his pet peeves mail at > > http://www.spinics.net/lists/arm-kernel/msg147268.html. > > Tony has already provided link to his patches fixing this in the > message you referenced. Is your patch catching any additional instances? > > Tony's patch adds comma after some sentinels, which should be dropped. My patches are intended just as a reference, please feel free to pick from those and apply as needed along with other related clean-up. Regards, Tony From Jon.Povey at racelogic.co.uk Wed Dec 14 20:45:32 2011 From: Jon.Povey at racelogic.co.uk (Jon Povey) Date: Thu, 15 Dec 2011 02:45:32 +0000 Subject: OT: ARM Linux job in Buckingham, UK Message-ID: <70E876B0EA86DD4BAF101844BC814DFE0BF3F7C869@Cloud.RL.local> Hello folks, My company Racelogic is looking for another ARM Linux dev to work in Buckingham, UK with me and the rest of our dev team, job ad here: http://www.racelogic.co.uk/index.php/en/careersjobs Sorry if this is considered off-topic, I don't mean to be spammy. Suggestions for more appropriate ways to find people like this are welcome and appreciated. 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 manjunath.hadli at ti.com Thu Dec 15 05:11:58 2011 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Thu, 15 Dec 2011 11:11:58 +0000 Subject: [PATCH v5 07/11] davinci: dm644x: Replace register base value with a defined macro In-Reply-To: <4EE87C39.8010601@mvista.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> <1323775415-24504-8-git-send-email-manjunath.hadli@ti.com> <4EE87C39.8010601@mvista.com> Message-ID: Sergei, On Wed, Dec 14, 2011 at 16:06:41, Sergei Shtylyov wrote: > Hello. > > On 13-12-2011 15:23, Manjunath Hadli wrote: > > > Replace hard coded value of vpss register base to a define macro > > DM644X_VPSS_REG_BASE for proper readability > > > Signed-off-by: Manjunath Hadli > > Acked-by: Sekhar Nori > > --- > > arch/arm/mach-davinci/dm644x.c | 8 +++++--- > > 1 files changed, 5 insertions(+), 3 deletions(-) > > > diff --git a/arch/arm/mach-davinci/dm644x.c > > b/arch/arm/mach-davinci/dm644x.c index 6b1d473..3802b59 100644 > > --- a/arch/arm/mach-davinci/dm644x.c > > +++ b/arch/arm/mach-davinci/dm644x.c > > @@ -594,13 +594,15 @@ static struct platform_device dm644x_asp_device = { > > .resource = dm644x_asp_resources, > > }; > > > > +#define DM644X_VPSS_REG_BASE 0x01c73400 > > + > > Why not simply DM644X_VPSS_BASE, like all the other #define's? There are #defines with _REG also like DAVINCI_DM646X_MCASP0_REG_BASE. But in the spirit of keeping it same for this file, I will change it. > > WBR, Sergei > Thx, -Manju From manjunath.hadli at ti.com Thu Dec 15 05:13:02 2011 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Thu, 15 Dec 2011 11:13:02 +0000 Subject: [PATCH v5 10/11] davinci: dm644x: add support for v4l2 video display In-Reply-To: <4EE87F08.6080309@mvista.com> References: <1323775415-24504-1-git-send-email-manjunath.hadli@ti.com> <1323775415-24504-11-git-send-email-manjunath.hadli@ti.com> <4EE87F08.6080309@mvista.com> Message-ID: Sergei, On Wed, Dec 14, 2011 at 16:18:40, Sergei Shtylyov wrote: > Hello. > > On 13-12-2011 15:23, Manjunath Hadli wrote: > > > Create platform devices for various video modules like venc,osd, vpbe > > and v4l2 driver for dm644x. Change the dm644x_init_video to make room > > for display config, and register the vpfe or vpbe devices based on the > > config pointer validity to make sure boards without vpfe or vpbe can > > be built with minimal changes. > > > Signed-off-by: Manjunath Hadli > [...] > > > diff --git a/arch/arm/mach-davinci/dm644x.c > > b/arch/arm/mach-davinci/dm644x.c index 6c034fd..2e408d8 100644 > > --- a/arch/arm/mach-davinci/dm644x.c > > +++ b/arch/arm/mach-davinci/dm644x.c > [...] > > @@ -654,7 +654,127 @@ static struct platform_device dm644x_vpfe_dev = > > { > [...] > > +#define DM644X_OSD_REG_BASE 0x01c72600 > [...] > > +#define DM644X_VENC_REG_BASE 0x01c72400 > > Why not without _REG, like all the other #define's? Ok. > > > +static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, > > + unsigned int mode) > > +{ > > + int ret = 0; > > + void __iomem *vpss_clkctl_reg; > > + > > + vpss_clkctl_reg = DAVINCI_SYSMODULE_VIRT(0x44); > > Why not in the initializer? Because it is used only for clock control. I think it is fine here. > > > + switch (type) { > > + case VPBE_ENC_STD: > > + writel(0x18, vpss_clkctl_reg); > > + break; > > + case VPBE_ENC_DV_PRESET: > > + switch ((unsigned int)mode) { > > 'mode' is already 'unsigned int'. Ok. Thx, -Manju > > WBR, Sergei > > From manjunath.hadli at ti.com Thu Dec 15 06:11:49 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:49 +0530 Subject: [PATCH v6 00/11] ARM: davinci:add support for dm644x vpbe display driver Message-ID: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Re-arrange definitions and remove unnecessary code so that we can have a common header for all davinci platforms. This will enable us to share defines and enable common routines to be used without polluting hardware.h. This is consistent with Russel's pet peaves notes regarding non-pollution of include/mach. Having this as the base, have a common system module base address (DAVINCI_SYSTEM_MODULE_BASE) and removing IO_ADDRESS macro,add support for dm644x VPBE display driver. Changes from last version: 1. Sergei's comments for changing form XXX_REG_BASE to XXX_BASE. 2. Removal of unnecassary typecasting. Manjunath Hadli (11): davinci: vpif: remove obsolete header file inclusion ARM: davinci: dm644x: remove the macros from the header to move to c file ARM: davinci: dm365: remove the macros from the header to move to c file ARM: davinci: dm646x: remove the macros from the header to move to c file ARM: davinci: create new common platform header for davinci davinci: eliminate use of IO_ADDRESS() on sysmod davinci: dm644x: Replace register base value with a defined macro davinci: dm644x: change vpfe capture structure variables for consistency davinci: dm644x: move vpfe init from soc to board specific files davinci: dm644x: add support for v4l2 video display davinci: dm644x EVM: add support for VPBE display arch/arm/mach-davinci/board-dm355-evm.c | 2 +- arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm644x-evm.c | 133 ++++++++++++++++-- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- arch/arm/mach-davinci/board-sffsdr.c | 2 +- arch/arm/mach-davinci/davinci.h | 101 +++++++++++++ arch/arm/mach-davinci/devices.c | 25 ++-- arch/arm/mach-davinci/dm355.c | 3 +- arch/arm/mach-davinci/dm365.c | 19 +++- arch/arm/mach-davinci/dm644x.c | 186 ++++++++++++++++++++++--- arch/arm/mach-davinci/dm646x.c | 10 ++- arch/arm/mach-davinci/include/mach/dm355.h | 32 ----- arch/arm/mach-davinci/include/mach/dm365.h | 52 ------- arch/arm/mach-davinci/include/mach/dm644x.h | 47 ------ arch/arm/mach-davinci/include/mach/dm646x.h | 41 ------ arch/arm/mach-davinci/include/mach/hardware.h | 2 - drivers/media/video/davinci/vpif.h | 2 +- drivers/media/video/davinci/vpif_display.c | 2 - 20 files changed, 438 insertions(+), 229 deletions(-) create mode 100644 arch/arm/mach-davinci/davinci.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h From manjunath.hadli at ti.com Thu Dec 15 06:11:53 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:53 +0530 Subject: [PATCH v6 04/11] ARM: davinci: dm646x: remove the macros from the header to move to c file In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-5-git-send-email-manjunath.hadli@ti.com> move the register base addresses and offsets used only by dm646x platform file from platform header dm646x.h to dm646x.c as they are used only in the c file. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/dm646x.c | 7 +++++++ arch/arm/mach-davinci/include/mach/dm646x.h | 7 ------- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 0b68ed5..0560e82 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -46,6 +46,13 @@ #define DM646X_REF_FREQ 27000000 #define DM646X_AUX_FREQ 24000000 +#define DM646X_EMAC_BASE 0x01c80000 +#define DM646X_EMAC_MDIO_BASE (DM646X_EMAC_BASE + 0x4000) +#define DM646X_EMAC_CNTRL_OFFSET 0x0000 +#define DM646X_EMAC_CNTRL_MOD_OFFSET 0x1000 +#define DM646X_EMAC_CNTRL_RAM_OFFSET 0x2000 +#define DM646X_EMAC_CNTRL_RAM_SIZE 0x2000 + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h index a8ee6c9..eb95864 100644 --- a/arch/arm/mach-davinci/include/mach/dm646x.h +++ b/arch/arm/mach-davinci/include/mach/dm646x.h @@ -18,13 +18,6 @@ #include #include -#define DM646X_EMAC_BASE (0x01C80000) -#define DM646X_EMAC_MDIO_BASE (DM646X_EMAC_BASE + 0x4000) -#define DM646X_EMAC_CNTRL_OFFSET (0x0000) -#define DM646X_EMAC_CNTRL_MOD_OFFSET (0x1000) -#define DM646X_EMAC_CNTRL_RAM_OFFSET (0x2000) -#define DM646X_EMAC_CNTRL_RAM_SIZE (0x2000) - #define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 #define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:11:51 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:51 +0530 Subject: [PATCH v6 02/11] ARM: davinci: dm644x: remove the macros from the header to move to c file In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-3-git-send-email-manjunath.hadli@ti.com> move the register base addresses and offsets used only by dm644x platform file from platform header dm644x.h to dm644x.c as they are used only in the c file. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/dm644x.c | 7 +++++++ arch/arm/mach-davinci/include/mach/dm644x.h | 7 ------- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 3470983..27d1371 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -35,6 +35,13 @@ */ #define DM644X_REF_FREQ 27000000 +#define DM644X_EMAC_BASE 0x01c80000 +#define DM644X_EMAC_MDIO_BASE (DM644X_EMAC_BASE + 0x4000) +#define DM644X_EMAC_CNTRL_OFFSET 0x0000 +#define DM644X_EMAC_CNTRL_MOD_OFFSET 0x1000 +#define DM644X_EMAC_CNTRL_RAM_OFFSET 0x2000 +#define DM644X_EMAC_CNTRL_RAM_SIZE 0x2000 + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h index 5a1b26d..724377f 100644 --- a/arch/arm/mach-davinci/include/mach/dm644x.h +++ b/arch/arm/mach-davinci/include/mach/dm644x.h @@ -27,13 +27,6 @@ #include #include -#define DM644X_EMAC_BASE (0x01C80000) -#define DM644X_EMAC_MDIO_BASE (DM644X_EMAC_BASE + 0x4000) -#define DM644X_EMAC_CNTRL_OFFSET (0x0000) -#define DM644X_EMAC_CNTRL_MOD_OFFSET (0x1000) -#define DM644X_EMAC_CNTRL_RAM_OFFSET (0x2000) -#define DM644X_EMAC_CNTRL_RAM_SIZE (0x2000) - #define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01E00000 #define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 #define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:11:52 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:52 +0530 Subject: [PATCH v6 03/11] ARM: davinci: dm365: remove the macros from the header to move to c file In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-4-git-send-email-manjunath.hadli@ti.com> move the register base addresses and offsets used only by dm365 platform file from platform header dm365.h to dm365.c as they are used only in the c file. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/dm365.c | 16 ++++++++++++++++ arch/arm/mach-davinci/include/mach/dm365.h | 16 ---------------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 679e168..77edee8 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -40,6 +40,22 @@ #define DM365_REF_FREQ 24000000 /* 24 MHz on the DM365 EVM */ +/* Base of key scan register bank */ +#define DM365_KEYSCAN_BASE 0x01c69400 + +#define DM365_RTC_BASE 0x01c69000 + +#define DAVINCI_DM365_VC_BASE 0x01d0c000 +#define DAVINCI_DMA_VC_TX 2 +#define DAVINCI_DMA_VC_RX 3 + +#define DM365_EMAC_BASE 0x01d07000 +#define DM365_EMAC_MDIO_BASE (DM365_EMAC_BASE + 0x4000) +#define DM365_EMAC_CNTRL_OFFSET 0x0000 +#define DM365_EMAC_CNTRL_MOD_OFFSET 0x3000 +#define DM365_EMAC_CNTRL_RAM_OFFSET 0x1000 +#define DM365_EMAC_CNTRL_RAM_SIZE 0x2000 + static struct pll_data pll1_data = { .num = 1, .phys_base = DAVINCI_PLL1_BASE, diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h index 2563bf4..51924de 100644 --- a/arch/arm/mach-davinci/include/mach/dm365.h +++ b/arch/arm/mach-davinci/include/mach/dm365.h @@ -20,22 +20,6 @@ #include #include -#define DM365_EMAC_BASE (0x01D07000) -#define DM365_EMAC_MDIO_BASE (DM365_EMAC_BASE + 0x4000) -#define DM365_EMAC_CNTRL_OFFSET (0x0000) -#define DM365_EMAC_CNTRL_MOD_OFFSET (0x3000) -#define DM365_EMAC_CNTRL_RAM_OFFSET (0x1000) -#define DM365_EMAC_CNTRL_RAM_SIZE (0x2000) - -/* Base of key scan register bank */ -#define DM365_KEYSCAN_BASE (0x01C69400) - -#define DM365_RTC_BASE (0x01C69000) - -#define DAVINCI_DM365_VC_BASE (0x01D0C000) -#define DAVINCI_DMA_VC_TX 2 -#define DAVINCI_DMA_VC_RX 3 - #define DM365_ASYNC_EMIF_CONTROL_BASE 0x01D10000 #define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 #define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:11:59 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:59 +0530 Subject: [PATCH v6 10/11] davinci: dm644x: add support for v4l2 video display In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-11-git-send-email-manjunath.hadli@ti.com> Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm644x. Change the dm644x_init_video to make room for display config, and register the vpfe or vpbe devices based on the config pointer validity to make sure boards without vpfe or vpbe can be built with minimal changes. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- arch/arm/mach-davinci/davinci.h | 7 +- arch/arm/mach-davinci/dm644x.c | 163 +++++++++++++++++++++++++++--- 3 files changed, 154 insertions(+), 18 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 8884125..eb7daff 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -695,7 +695,7 @@ static __init void davinci_evm_init(void) evm_init_i2c(); davinci_setup_mmc(0, &dm6446evm_mmc_config); - dm644x_init_video(&dm644xevm_capture_cfg); + dm644x_init_video(&dm644xevm_capture_cfg, NULL); davinci_serial_init(&uart_config); dm644x_init_asp(&dm644x_evm_snd_data); diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h index 13cb029..bdaa586 100644 --- a/arch/arm/mach-davinci/davinci.h +++ b/arch/arm/mach-davinci/davinci.h @@ -26,6 +26,11 @@ #include #include #include +#include +#include +#include +#include +#include #define DAVINCI_SYSTEM_MODULE_BASE 0x01c40000 @@ -81,7 +86,7 @@ void dm365_set_vpfe_config(struct vpfe_config *cfg); /* DM644x function declarations */ void __init dm644x_init(void); void __init dm644x_init_asp(struct snd_platform_data *pdata); -int __init dm644x_init_video(struct vpfe_config *); +int __init dm644x_init_video(struct vpfe_config *, struct vpbe_config *); /* DM646x function declarations */ void __init dm646x_init(void); diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 4606e5c..243876c 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -627,7 +627,7 @@ static struct resource dm644x_vpfe_resources[] = { }, }; -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); +static u64 dm644x_video_dma_mask = DMA_BIT_MASK(32); static struct resource dm644x_ccdc_resource[] = { /* CCDC Base address */ { @@ -643,7 +643,7 @@ static struct platform_device dm644x_ccdc_dev = { .num_resources = ARRAY_SIZE(dm644x_ccdc_resource), .resource = dm644x_ccdc_resource, .dev = { - .dma_mask = &vpfe_capture_dma_mask, + .dma_mask = &dm644x_video_dma_mask, .coherent_dma_mask = DMA_BIT_MASK(32), }, }; @@ -654,7 +654,127 @@ static struct platform_device dm644x_vpfe_dev = { .num_resources = ARRAY_SIZE(dm644x_vpfe_resources), .resource = dm644x_vpfe_resources, .dev = { - .dma_mask = &vpfe_capture_dma_mask, + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, +}; + +#define DM644X_OSD_BASE 0x01c72600 + +static struct resource dm644x_osd_resources[] = { + { + .start = DM644X_OSD_BASE, + .end = DM644X_OSD_BASE + 0x1ff, + .flags = IORESOURCE_MEM, + }, +}; + +static struct osd_platform_data dm644x_osd_data = { + .vpbe_type = VPBE_VERSION_1, +}; + +static struct platform_device dm644x_osd_dev = { + .name = VPBE_OSD_SUBDEV_NAME, + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_osd_resources), + .resource = dm644x_osd_resources, + .dev = { + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = &dm644x_osd_data, + }, +}; + +#define DM644X_VENC_BASE 0x01c72400 + +static struct resource dm644x_venc_resources[] = { + { + .start = DM644X_VENC_BASE, + .end = DM644X_VENC_BASE + 0x17f, + .flags = IORESOURCE_MEM, + }, +}; + +static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, + unsigned int mode) +{ + int ret = 0; + void __iomem *vpss_clkctl_reg; + + vpss_clkctl_reg = DAVINCI_SYSMODULE_VIRT(0x44); + + switch (type) { + case VPBE_ENC_STD: + writel(0x18, vpss_clkctl_reg); + break; + case VPBE_ENC_DV_PRESET: + switch (mode) { + case V4L2_DV_480P59_94: + case V4L2_DV_576P50: + writel(0x19, vpss_clkctl_reg); + break; + case V4L2_DV_720P60: + case V4L2_DV_1080I60: + case V4L2_DV_1080P30: + /* + * For HD, use external clock source since + * HD requires higher clock rate + */ + writel(0xa, vpss_clkctl_reg); + break; + default: + ret = -EINVAL; + break; + } + break; + default: + ret = -EINVAL; + } + + return ret; +} + +static struct resource dm644x_v4l2_disp_resources[] = { + { + .start = IRQ_VENCINT, + .end = IRQ_VENCINT, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct platform_device dm644x_vpbe_display = { + .name = "vpbe-v4l2", + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources), + .resource = dm644x_v4l2_disp_resources, + .dev = { + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, +}; + +static struct venc_platform_data dm644x_venc_pdata = { + .venc_type = VPBE_VERSION_1, + .setup_clock = dm644x_venc_setup_clock, +}; + +static struct platform_device dm644x_venc_dev = { + .name = VPBE_VENC_SUBDEV_NAME, + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_venc_resources), + .resource = dm644x_venc_resources, + .dev = { + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = &dm644x_venc_pdata, + }, +}; + +static struct platform_device dm644x_vpbe_dev = { + .name = "vpbe_controller", + .id = -1, + .dev = { + .dma_mask = &dm644x_video_dma_mask, .coherent_dma_mask = DMA_BIT_MASK(32), }, }; @@ -787,20 +907,31 @@ void __init dm644x_init(void) davinci_map_sysmod(); } -static struct platform_device *dm644x_video_devices[] __initdata = { - &dm644x_vpss_device, - &dm644x_ccdc_dev, - &dm644x_vpfe_dev, -}; - -int __init dm644x_init_video(struct vpfe_config *vpfe_cfg) +int __init dm644x_init_video(struct vpfe_config *vpfe_cfg, + struct vpbe_config *vpbe_cfg) { - dm644x_vpfe_dev.dev.platform_data = vpfe_cfg; - /* Add ccdc clock aliases */ - clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL); - clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL); - platform_add_devices(dm644x_video_devices, - ARRAY_SIZE(dm644x_video_devices)); + if (vpfe_cfg || vpbe_cfg) + platform_device_register(&dm644x_vpss_device); + + if (vpfe_cfg) { + dm644x_vpfe_dev.dev.platform_data = vpfe_cfg; + platform_device_register(&dm644x_ccdc_dev); + platform_device_register(&dm644x_vpfe_dev); + /* Add ccdc clock aliases */ + clk_add_alias("master", dm644x_ccdc_dev.name, + "vpss_master", NULL); + clk_add_alias("slave", dm644x_ccdc_dev.name, + "vpss_slave", NULL); + } + + if (vpbe_cfg) { + dm644x_vpbe_dev.dev.platform_data = vpbe_cfg; + platform_device_register(&dm644x_osd_dev); + platform_device_register(&dm644x_venc_dev); + platform_device_register(&dm644x_vpbe_dev); + platform_device_register(&dm644x_vpbe_display); + } + return 0; } -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:12:00 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:42:00 +0530 Subject: [PATCH v6 11/11] davinci: dm644x EVM: add support for VPBE display In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-12-git-send-email-manjunath.hadli@ti.com> This patch adds support for V4L2 video display to DM6446 EVM. Support for SD and ED modes is provided, along with Composite and Component outputs.Also added vpbe_config as a parameter for dm644x_init_video to allow for registration of vpbe platform devices. Signed-off-by: Manjunath Hadli Acked-by: Sekhar Nori --- arch/arm/mach-davinci/board-dm644x-evm.c | 108 +++++++++++++++++++++++++++++- 1 files changed, 107 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index eb7daff..af81dbb 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -612,6 +612,112 @@ static void __init evm_init_i2c(void) i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info)); } +#define VENC_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) + +/* venc standard timings */ +static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = { + { + .name = "ntsc", + .timings_type = VPBE_ENC_STD, + .timings = {V4L2_STD_525_60}, + .interlaced = 1, + .xres = 720, + .yres = 480, + .aspect = {11, 10}, + .fps = {30000, 1001}, + .left_margin = 0x79, + .upper_margin = 0x10, + }, + { + .name = "pal", + .timings_type = VPBE_ENC_STD, + .timings = {V4L2_STD_625_50}, + .interlaced = 1, + .xres = 720, + .yres = 576, + .aspect = {54, 59}, + .fps = {25, 1}, + .left_margin = 0x7e, + .upper_margin = 0x16, + }, +}; + +/* venc dv preset timings */ +static struct vpbe_enc_mode_info dm644xevm_enc_preset_timing[] = { + { + .name = "480p59_94", + .timings_type = VPBE_ENC_DV_PRESET, + .timings = {V4L2_DV_480P59_94}, + .interlaced = 0, + .xres = 720, + .yres = 480, + .aspect = {1, 1}, + .fps = {5994, 100}, + .left_margin = 0x80, + .upper_margin = 0x20, + }, + { + .name = "576p50", + .timings_type = VPBE_ENC_DV_PRESET, + .timings = {V4L2_DV_576P50}, + .interlaced = 0, + .xres = 720, + .yres = 576, + .aspect = {1, 1}, + .fps = {50, 1}, + .left_margin = 0x7e, + .upper_margin = 0x30, + }, +}; + +/* + * The outputs available from VPBE + encoders. Keep the order same + * as that of encoders. First those from venc followed by that from + * encoders. Index in the output refers to index on a particular encoder. + * Driver uses this index to pass it to encoder when it supports more than + * one output. Application uses index of the array to set an output. + */ +static struct vpbe_output dm644xevm_vpbe_outputs[] = { + { + .output = { + .index = 0, + .name = "Composite", + .type = V4L2_OUTPUT_TYPE_ANALOG, + .std = VENC_STD_ALL, + .capabilities = V4L2_OUT_CAP_STD, + }, + .subdev_name = VPBE_VENC_SUBDEV_NAME, + .default_mode = "ntsc", + .num_modes = ARRAY_SIZE(dm644xevm_enc_std_timing), + .modes = dm644xevm_enc_std_timing, + }, + { + .output = { + .index = 1, + .name = "Component", + .type = V4L2_OUTPUT_TYPE_ANALOG, + .capabilities = V4L2_OUT_CAP_PRESETS, + }, + .subdev_name = VPBE_VENC_SUBDEV_NAME, + .default_mode = "480p59_94", + .num_modes = ARRAY_SIZE(dm644xevm_enc_preset_timing), + .modes = dm644xevm_enc_preset_timing, + }, +}; + +static struct vpbe_config dm644xevm_display_cfg = { + .module_name = "dm644x-vpbe-display", + .i2c_adapter_id = 1, + .osd = { + .module_name = VPBE_OSD_SUBDEV_NAME, + }, + .venc = { + .module_name = VPBE_VENC_SUBDEV_NAME, + }, + .num_outputs = ARRAY_SIZE(dm644xevm_vpbe_outputs), + .outputs = dm644xevm_vpbe_outputs, +}; + static struct platform_device *davinci_evm_devices[] __initdata = { &davinci_fb_device, &rtc_dev, @@ -695,7 +801,7 @@ static __init void davinci_evm_init(void) evm_init_i2c(); davinci_setup_mmc(0, &dm6446evm_mmc_config); - dm644x_init_video(&dm644xevm_capture_cfg, NULL); + dm644x_init_video(&dm644xevm_capture_cfg, &dm644xevm_display_cfg); davinci_serial_init(&uart_config); dm644x_init_asp(&dm644x_evm_snd_data); -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:11:56 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:56 +0530 Subject: [PATCH v6 07/11] davinci: dm644x: Replace register base value with a defined macro In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-8-git-send-email-manjunath.hadli@ti.com> Replace hard coded value of vpss register base to a define macro DM644X_VPSS_BASE for proper readability Signed-off-by: Manjunath Hadli Acked-by: Sekhar Nori --- arch/arm/mach-davinci/dm644x.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 6b1d473..39d1332 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -594,13 +594,15 @@ static struct platform_device dm644x_asp_device = { .resource = dm644x_asp_resources, }; +#define DM644X_VPSS_BASE 0x01c73400 + static struct resource dm644x_vpss_resources[] = { { /* VPSS Base address */ .name = "vpss", - .start = 0x01c73400, - .end = 0x01c73400 + 0xff, - .flags = IORESOURCE_MEM, + .start = DM644X_VPSS_BASE, + .end = DM644X_VPSS_BASE + 0xff, + .flags = IORESOURCE_MEM, }, }; -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:11:54 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:54 +0530 Subject: [PATCH v6 05/11] ARM: davinci: create new common platform header for davinci In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-6-git-send-email-manjunath.hadli@ti.com> remove the code from individual platform header files for dm365, dm355, dm644x and dm646x and consolidate it into a single and common header file davinci.h. This reduces the pollution in the include/mach and is consistent with Russel's suggestions as part of his "pet peaves" mail. The further patches in the series take advantage of this consolidation for easy implementation of IO_ADDRESS elimination. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/board-dm355-evm.c | 2 +- arch/arm/mach-davinci/board-dm355-leopard.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 2 +- arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 2 +- arch/arm/mach-davinci/board-sffsdr.c | 2 +- arch/arm/mach-davinci/davinci.h | 87 +++++++++++++++++++++++++++ arch/arm/mach-davinci/dm355.c | 2 +- arch/arm/mach-davinci/dm365.c | 2 +- arch/arm/mach-davinci/dm644x.c | 2 +- arch/arm/mach-davinci/dm646x.c | 2 +- arch/arm/mach-davinci/include/mach/dm355.h | 32 ---------- arch/arm/mach-davinci/include/mach/dm365.h | 36 ----------- arch/arm/mach-davinci/include/mach/dm644x.h | 40 ------------ arch/arm/mach-davinci/include/mach/dm646x.h | 34 ---------- 16 files changed, 98 insertions(+), 153 deletions(-) create mode 100644 arch/arm/mach-davinci/davinci.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index 4e0e707..7ae0d15 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -26,7 +26,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c index ff2d241..56f88de 100644 --- a/arch/arm/mach-davinci/board-dm355-leopard.c +++ b/arch/arm/mach-davinci/board-dm355-leopard.c @@ -23,7 +23,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index 1918ae7..613ed00 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -32,7 +32,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 0cf8abf..00e8599 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -30,7 +30,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index e574d7f..c0f9ea2 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -36,7 +36,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c index e5f231a..edc6ff7 100644 --- a/arch/arm/mach-davinci/board-neuros-osd2.c +++ b/arch/arm/mach-davinci/board-neuros-osd2.c @@ -30,7 +30,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c index 5dd4da9..122c7aa 100644 --- a/arch/arm/mach-davinci/board-sffsdr.c +++ b/arch/arm/mach-davinci/board-sffsdr.c @@ -35,7 +35,7 @@ #include #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h new file mode 100644 index 0000000..3e6def4 --- /dev/null +++ b/arch/arm/mach-davinci/davinci.h @@ -0,0 +1,87 @@ +/* + * This file contains the processor specific definitions + * of the TI DM644x, DM355, DM365, and DM646x. + * + * Copyright (C) 2011 Texas Instruments Incorporated + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#ifndef __DAVINCI_H +#define __DAVINCI_H + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* DM355 base addresses */ +#define DM355_ASYNC_EMIF_CONTROL_BASE 0x01e10000 +#define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 + +#define ASP1_TX_EVT_EN 1 +#define ASP1_RX_EVT_EN 2 + +/* DM365 base addresses */ +#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01d10000 +#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 +#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 + +/* DM644x base addresses */ +#define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01e00000 +#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 +#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 +#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000 +#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000 + +/* DM646x base addresses */ +#define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 +#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 + +/* DM355 function declarations */ +struct spi_board_info; + +void __init dm355_init(void); +void dm355_init_spi0(unsigned chipselect_mask, + struct spi_board_info *info, unsigned len); +void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); +void dm355_set_vpfe_config(struct vpfe_config *cfg); + +/* DM365 function declarations */ +void __init dm365_init(void); +void __init dm365_init_asp(struct snd_platform_data *pdata); +void __init dm365_init_vc(struct snd_platform_data *pdata); +void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); +void __init dm365_init_rtc(void); +void dm365_init_spi0(unsigned chipselect_mask, + struct spi_board_info *info, unsigned len); + +void dm365_set_vpfe_config(struct vpfe_config *cfg); + +/* DM644x function declarations */ +void __init dm644x_init(void); +void __init dm644x_init_asp(struct snd_platform_data *pdata); +void dm644x_set_vpfe_config(struct vpfe_config *cfg); + +/* DM646x function declarations */ +void __init dm646x_init(void); +void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); +void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); +int __init dm646x_init_edma(struct edma_rsv_info *rsv); + +void dm646x_video_init(void); + +void dm646x_setup_vpif(struct vpif_display_config *, + struct vpif_capture_config *); +#endif /*__DAVINCI_H */ diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index fe520d4..36744ff 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -18,7 +18,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 77edee8..3171cd1 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -21,7 +21,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 27d1371..b84b220 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -15,7 +15,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 0560e82..a6a9cde 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -16,7 +16,7 @@ #include -#include +#include "davinci.h" #include #include #include diff --git a/arch/arm/mach-davinci/include/mach/dm355.h b/arch/arm/mach-davinci/include/mach/dm355.h deleted file mode 100644 index 36dff4a..0000000 --- a/arch/arm/mach-davinci/include/mach/dm355.h +++ /dev/null @@ -1,32 +0,0 @@ -/* - * Chip specific defines for DM355 SoC - * - * Author: Kevin Hilman, Deep Root Systems, LLC - * - * 2007 (c) Deep Root Systems, LLC. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. - */ -#ifndef __ASM_ARCH_DM355_H -#define __ASM_ARCH_DM355_H - -#include -#include -#include - -#define DM355_ASYNC_EMIF_CONTROL_BASE 0x01E10000 -#define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 - -#define ASP1_TX_EVT_EN 1 -#define ASP1_RX_EVT_EN 2 - -struct spi_board_info; - -void __init dm355_init(void); -void dm355_init_spi0(unsigned chipselect_mask, - struct spi_board_info *info, unsigned len); -void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); -void dm355_set_vpfe_config(struct vpfe_config *cfg); - -#endif /* __ASM_ARCH_DM355_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h deleted file mode 100644 index 51924de..0000000 --- a/arch/arm/mach-davinci/include/mach/dm365.h +++ /dev/null @@ -1,36 +0,0 @@ -/* - * Copyright (C) 2009 Texas Instruments Incorporated - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation version 2. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether express or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ -#ifndef __ASM_ARCH_DM365_H -#define __ASM_ARCH_DM665_H - -#include -#include -#include -#include -#include -#include - -#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01D10000 -#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 -#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 - -void __init dm365_init(void); -void __init dm365_init_asp(struct snd_platform_data *pdata); -void __init dm365_init_vc(struct snd_platform_data *pdata); -void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); -void __init dm365_init_rtc(void); -void dm365_init_spi0(unsigned chipselect_mask, - struct spi_board_info *info, unsigned len); - -void dm365_set_vpfe_config(struct vpfe_config *cfg); -#endif /* __ASM_ARCH_DM365_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h deleted file mode 100644 index 724377f..0000000 --- a/arch/arm/mach-davinci/include/mach/dm644x.h +++ /dev/null @@ -1,40 +0,0 @@ -/* - * This file contains the processor specific definitions - * of the TI DM644x. - * - * Copyright (C) 2008 Texas Instruments. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - * - */ -#ifndef __ASM_ARCH_DM644X_H -#define __ASM_ARCH_DM644X_H - -#include -#include -#include -#include - -#define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01E00000 -#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 -#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 -#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000 -#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000 - -void __init dm644x_init(void); -void __init dm644x_init_asp(struct snd_platform_data *pdata); -void dm644x_set_vpfe_config(struct vpfe_config *cfg); - -#endif /* __ASM_ARCH_DM644X_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h deleted file mode 100644 index eb95864..0000000 --- a/arch/arm/mach-davinci/include/mach/dm646x.h +++ /dev/null @@ -1,34 +0,0 @@ -/* - * Chip specific defines for DM646x SoC - * - * Author: Kevin Hilman, Deep Root Systems, LLC - * - * 2007 (c) Deep Root Systems, LLC. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. - */ -#ifndef __ASM_ARCH_DM646X_H -#define __ASM_ARCH_DM646X_H - -#include -#include -#include -#include -#include -#include - -#define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 -#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 - -void __init dm646x_init(void); -void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); -void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); -int __init dm646x_init_edma(struct edma_rsv_info *rsv); - -void dm646x_video_init(void); - -void dm646x_setup_vpif(struct vpif_display_config *, - struct vpif_capture_config *); - -#endif /* __ASM_ARCH_DM646X_H */ -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:11:57 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:57 +0530 Subject: [PATCH v6 08/11] davinci: dm644x: change vpfe capture structure variables for consistency In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-9-git-send-email-manjunath.hadli@ti.com> Add SoC and board prefixes to variable names so that it is consistent with the rest of the file. Signed-off-by: Manjunath Hadli Acked-by: Sekhar Nori --- arch/arm/mach-davinci/board-dm644x-evm.c | 24 ++++++++++++------------ arch/arm/mach-davinci/dm644x.c | 12 ++++++------ 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 00e8599..fbd3856 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -189,7 +189,7 @@ static struct platform_device davinci_fb_device = { .num_resources = 0, }; -static struct tvp514x_platform_data tvp5146_pdata = { +static struct tvp514x_platform_data dm644xevm_tvp5146_pdata = { .clk_polarity = 0, .hs_polarity = 1, .vs_polarity = 1 @@ -197,7 +197,7 @@ static struct tvp514x_platform_data tvp5146_pdata = { #define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) /* Inputs available at the TVP5146 */ -static struct v4l2_input tvp5146_inputs[] = { +static struct v4l2_input dm644xevm_tvp5146_inputs[] = { { .index = 0, .name = "Composite", @@ -217,7 +217,7 @@ static struct v4l2_input tvp5146_inputs[] = { * ouput that goes to vpfe. There is a one to one correspondence * with tvp5146_inputs */ -static struct vpfe_route tvp5146_routes[] = { +static struct vpfe_route dm644xevm_tvp5146_routes[] = { { .input = INPUT_CVBS_VI2B, .output = OUTPUT_10BIT_422_EMBEDDED_SYNC, @@ -228,13 +228,13 @@ static struct vpfe_route tvp5146_routes[] = { }, }; -static struct vpfe_subdev_info vpfe_sub_devs[] = { +static struct vpfe_subdev_info dm644xevm_vpfe_sub_devs[] = { { .name = "tvp5146", .grp_id = 0, - .num_inputs = ARRAY_SIZE(tvp5146_inputs), - .inputs = tvp5146_inputs, - .routes = tvp5146_routes, + .num_inputs = ARRAY_SIZE(dm644xevm_tvp5146_inputs), + .inputs = dm644xevm_tvp5146_inputs, + .routes = dm644xevm_tvp5146_routes, .can_route = 1, .ccdc_if_params = { .if_type = VPFE_BT656, @@ -243,15 +243,15 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = { }, .board_info = { I2C_BOARD_INFO("tvp5146", 0x5d), - .platform_data = &tvp5146_pdata, + .platform_data = &dm644xevm_tvp5146_pdata, }, }, }; -static struct vpfe_config vpfe_cfg = { - .num_subdevs = ARRAY_SIZE(vpfe_sub_devs), +static struct vpfe_config dm644xevm_capture_cfg = { + .num_subdevs = ARRAY_SIZE(dm644xevm_vpfe_sub_devs), .i2c_adapter_id = 1, - .sub_devs = vpfe_sub_devs, + .sub_devs = dm644xevm_vpfe_sub_devs, .card_name = "DM6446 EVM", .ccdc = "DM6446 CCDC", }; @@ -625,7 +625,7 @@ static void __init davinci_evm_map_io(void) { /* setup input configuration for VPFE input devices */ - dm644x_set_vpfe_config(&vpfe_cfg); + dm644x_set_vpfe_config(&dm644xevm_capture_cfg); dm644x_init(); } diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 39d1332..7144277 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -614,7 +614,7 @@ static struct platform_device dm644x_vpss_device = { .resource = dm644x_vpss_resources, }; -static struct resource vpfe_resources[] = { +static struct resource dm644x_vpfe_resources[] = { { .start = IRQ_VDINT0, .end = IRQ_VDINT0, @@ -648,11 +648,11 @@ static struct platform_device dm644x_ccdc_dev = { }, }; -static struct platform_device vpfe_capture_dev = { +static struct platform_device dm644x_vpfe_dev = { .name = CAPTURE_DRV_NAME, .id = -1, - .num_resources = ARRAY_SIZE(vpfe_resources), - .resource = vpfe_resources, + .num_resources = ARRAY_SIZE(dm644x_vpfe_resources), + .resource = dm644x_vpfe_resources, .dev = { .dma_mask = &vpfe_capture_dma_mask, .coherent_dma_mask = DMA_BIT_MASK(32), @@ -661,7 +661,7 @@ static struct platform_device vpfe_capture_dev = { void dm644x_set_vpfe_config(struct vpfe_config *cfg) { - vpfe_capture_dev.dev.platform_data = cfg; + dm644x_vpfe_dev.dev.platform_data = cfg; } /*----------------------------------------------------------------------*/ @@ -809,7 +809,7 @@ static int __init dm644x_init_devices(void) platform_device_register(&dm644x_vpss_device); platform_device_register(&dm644x_ccdc_dev); - platform_device_register(&vpfe_capture_dev); + platform_device_register(&dm644x_vpfe_dev); return 0; } -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:11:58 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:58 +0530 Subject: [PATCH v6 09/11] davinci: dm644x: move vpfe init from soc to board specific files In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-10-git-send-email-manjunath.hadli@ti.com> Move all vpfe platform device registrations to the board specific file like the rest of the devices, and have all of them together. This would remove the restriction of inclusion and registration of vpfe platform devices for non-vpfe boards. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/board-dm644x-evm.c | 3 +-- arch/arm/mach-davinci/davinci.h | 2 +- arch/arm/mach-davinci/dm644x.c | 29 +++++++++++++++++------------ 3 files changed, 19 insertions(+), 15 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index fbd3856..8884125 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -624,8 +624,6 @@ static struct davinci_uart_config uart_config __initdata = { static void __init davinci_evm_map_io(void) { - /* setup input configuration for VPFE input devices */ - dm644x_set_vpfe_config(&dm644xevm_capture_cfg); dm644x_init(); } @@ -697,6 +695,7 @@ static __init void davinci_evm_init(void) evm_init_i2c(); davinci_setup_mmc(0, &dm6446evm_mmc_config); + dm644x_init_video(&dm644xevm_capture_cfg); davinci_serial_init(&uart_config); dm644x_init_asp(&dm644x_evm_snd_data); diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h index 06ed38a..13cb029 100644 --- a/arch/arm/mach-davinci/davinci.h +++ b/arch/arm/mach-davinci/davinci.h @@ -81,7 +81,7 @@ void dm365_set_vpfe_config(struct vpfe_config *cfg); /* DM644x function declarations */ void __init dm644x_init(void); void __init dm644x_init_asp(struct snd_platform_data *pdata); -void dm644x_set_vpfe_config(struct vpfe_config *cfg); +int __init dm644x_init_video(struct vpfe_config *); /* DM646x function declarations */ void __init dm646x_init(void); diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 7144277..4606e5c 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -659,11 +659,6 @@ static struct platform_device dm644x_vpfe_dev = { }, }; -void dm644x_set_vpfe_config(struct vpfe_config *cfg) -{ - dm644x_vpfe_dev.dev.platform_data = cfg; -} - /*----------------------------------------------------------------------*/ static struct map_desc dm644x_io_desc[] = { @@ -792,14 +787,28 @@ void __init dm644x_init(void) davinci_map_sysmod(); } +static struct platform_device *dm644x_video_devices[] __initdata = { + &dm644x_vpss_device, + &dm644x_ccdc_dev, + &dm644x_vpfe_dev, +}; + +int __init dm644x_init_video(struct vpfe_config *vpfe_cfg) +{ + dm644x_vpfe_dev.dev.platform_data = vpfe_cfg; + /* Add ccdc clock aliases */ + clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL); + clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL); + platform_add_devices(dm644x_video_devices, + ARRAY_SIZE(dm644x_video_devices)); + return 0; +} + static int __init dm644x_init_devices(void) { if (!cpu_is_davinci_dm644x()) return 0; - /* Add ccdc clock aliases */ - clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL); - clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL); platform_device_register(&dm644x_edma_device); platform_device_register(&dm644x_mdio_device); @@ -807,10 +816,6 @@ static int __init dm644x_init_devices(void) clk_add_alias(NULL, dev_name(&dm644x_mdio_device.dev), NULL, &dm644x_emac_device.dev); - platform_device_register(&dm644x_vpss_device); - platform_device_register(&dm644x_ccdc_dev); - platform_device_register(&dm644x_vpfe_dev); - return 0; } postcore_initcall(dm644x_init_devices); -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:11:55 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:55 +0530 Subject: [PATCH v6 06/11] davinci: eliminate use of IO_ADDRESS() on sysmod In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-7-git-send-email-manjunath.hadli@ti.com> Current devices.c file has a number of instances where IO_ADDRESS() is used for system module register access. Eliminate this in favor of a ioremap() based access. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/davinci.h | 9 +++++++++ arch/arm/mach-davinci/devices.c | 25 ++++++++++++++++--------- arch/arm/mach-davinci/dm355.c | 1 + arch/arm/mach-davinci/dm365.c | 1 + arch/arm/mach-davinci/dm644x.c | 1 + arch/arm/mach-davinci/dm646x.c | 1 + arch/arm/mach-davinci/include/mach/hardware.h | 2 -- 7 files changed, 29 insertions(+), 11 deletions(-) diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h index 3e6def4..06ed38a 100644 --- a/arch/arm/mach-davinci/davinci.h +++ b/arch/arm/mach-davinci/davinci.h @@ -20,12 +20,21 @@ #include #include #include +#include #include #include #include #include #include +#define DAVINCI_SYSTEM_MODULE_BASE 0x01c40000 + +#ifndef __ASSEMBLER__ +extern void __iomem *davinci_sysmodbase; +#define DAVINCI_SYSMODULE_VIRT(x) (davinci_sysmodbase + (x)) +void davinci_map_sysmod(void); +#endif + /* DM355 base addresses */ #define DM355_ASYNC_EMIF_CONTROL_BASE 0x01e10000 #define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c index 806a2f0..580d48a 100644 --- a/arch/arm/mach-davinci/devices.c +++ b/arch/arm/mach-davinci/devices.c @@ -22,6 +22,7 @@ #include #include #include +#include "davinci.h" #include "clock.h" @@ -36,6 +37,14 @@ /* System control register offsets */ #define DM64XX_VDD3P3V_PWDN 0x48 +void __iomem *davinci_sysmodbase; + +void davinci_map_sysmod(void) +{ + davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800); + WARN_ON(!davinci_sysmodbase); +} + static struct resource i2c_resources[] = { { .start = DAVINCI_I2C_BASE, @@ -212,12 +221,12 @@ void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config) davinci_cfg_reg(DM355_SD1_DATA2); davinci_cfg_reg(DM355_SD1_DATA3); } else if (cpu_is_davinci_dm365()) { - void __iomem *pupdctl1 = - IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c); - /* Configure pull down control */ - __raw_writel((__raw_readl(pupdctl1) & ~0xfc0), - pupdctl1); + void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c); + unsigned v; + + v = __raw_readl(pupdctl1); + __raw_writel(v & ~0xfc0, pupdctl1); mmcsd1_resources[0].start = DM365_MMCSD1_BASE; mmcsd1_resources[0].end = DM365_MMCSD1_BASE + @@ -246,11 +255,9 @@ void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config) mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0; } else if (cpu_is_davinci_dm644x()) { /* REVISIT: should this be in board-init code? */ - void __iomem *base = - IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE); - /* Power-on 3.3V IO cells */ - __raw_writel(0, base + DM64XX_VDD3P3V_PWDN); + __raw_writel(0, + DAVINCI_SYSMODULE_VIRT(DM64XX_VDD3P3V_PWDN)); /*Set up the pull regiter for MMC */ davinci_cfg_reg(DM644X_MSTK); } diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index 36744ff..1f90c5a 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -872,6 +872,7 @@ void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata) void __init dm355_init(void) { davinci_common_init(&davinci_soc_info_dm355); + davinci_map_sysmod(); } static int __init dm355_init_devices(void) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 3171cd1..f0801b9 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -1139,6 +1139,7 @@ void __init dm365_init_rtc(void) void __init dm365_init(void) { davinci_common_init(&davinci_soc_info_dm365); + davinci_map_sysmod(); } static struct resource dm365_vpss_resources[] = { diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index b84b220..6b1d473 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -787,6 +787,7 @@ void __init dm644x_init_asp(struct snd_platform_data *pdata) void __init dm644x_init(void) { davinci_common_init(&davinci_soc_info_dm644x); + davinci_map_sysmod(); } static int __init dm644x_init_devices(void) diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index a6a9cde..1da02fe 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -914,6 +914,7 @@ int __init dm646x_init_edma(struct edma_rsv_info *rsv) void __init dm646x_init(void) { davinci_common_init(&davinci_soc_info_dm646x); + davinci_map_sysmod(); } static int __init dm646x_init_devices(void) diff --git a/arch/arm/mach-davinci/include/mach/hardware.h b/arch/arm/mach-davinci/include/mach/hardware.h index 414e0b9..0209b1f 100644 --- a/arch/arm/mach-davinci/include/mach/hardware.h +++ b/arch/arm/mach-davinci/include/mach/hardware.h @@ -19,8 +19,6 @@ * and the chip/board init code should then explicitly include * .h */ -#define DAVINCI_SYSTEM_MODULE_BASE 0x01C40000 - /* * I/O mapping */ -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:11:50 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:41:50 +0530 Subject: [PATCH v6 01/11] davinci: vpif: remove obsolete header file inclusion In-Reply-To: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951120-15876-2-git-send-email-manjunath.hadli@ti.com> remove inclusion of header files from vpif.h and vpif_dispaly.c and add appropriate header file for building. Signed-off-by: Manjunath Hadli Cc: Mauro Carvalho Chehab Cc: LMML --- drivers/media/video/davinci/vpif.h | 2 +- drivers/media/video/davinci/vpif_display.c | 2 -- 2 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/davinci/vpif.h b/drivers/media/video/davinci/vpif.h index 25036cb..c96268a 100644 --- a/drivers/media/video/davinci/vpif.h +++ b/drivers/media/video/davinci/vpif.h @@ -19,7 +19,7 @@ #include #include #include -#include +#include #include /* Maximum channel allowed */ diff --git a/drivers/media/video/davinci/vpif_display.c b/drivers/media/video/davinci/vpif_display.c index 286f029..7fa34b4 100644 --- a/drivers/media/video/davinci/vpif_display.c +++ b/drivers/media/video/davinci/vpif_display.c @@ -39,8 +39,6 @@ #include #include -#include - #include "vpif_display.h" #include "vpif.h" -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:24:56 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:54:56 +0530 Subject: [PATCH 0/2] add dm365 specific media formats Message-ID: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> add mediabus formats and pixel formats suported as part of dm365 vpfe device. The device supports media formats(transfer and storage) which include - 1. ALAW compressed bayer. 2. UV interleaved without Y( for resizer) 3. NV12 Manjunath Hadli (2): media: add new mediabus format enums for dm365 v4l2: add new pixel formats supported on dm365 include/linux/v4l2-mediabus.h | 10 ++++++++-- include/linux/videodev2.h | 6 ++++++ 2 files changed, 14 insertions(+), 2 deletions(-) From manjunath.hadli at ti.com Thu Dec 15 06:24:58 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:54:58 +0530 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951898-16330-3-git-send-email-manjunath.hadli@ti.com> add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format frames compressed by A-LAW alogorithm. add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only. Signed-off-by: Manjunath Hadli Cc: Laurent Pinchart --- include/linux/videodev2.h | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h index 4b752d5..969112d 100644 --- a/include/linux/videodev2.h +++ b/include/linux/videodev2.h @@ -338,6 +338,9 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv interleaved */ +/* Chrominance formats */ +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV 4:4 */ + /* two planes -- one Y, one Cr + Cb interleaved */ #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') + /* 10bit raw bayer a-law compressed to 8 bits */ +#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') + /* * 10bit raw bayer, expanded to 16 bits * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb... -- 1.6.2.4 From manjunath.hadli at ti.com Thu Dec 15 06:24:57 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Thu, 15 Dec 2011 17:54:57 +0530 Subject: [PATCH 1/2] media: add new mediabus format enums for dm365 In-Reply-To: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1323951898-16330-2-git-send-email-manjunath.hadli@ti.com> add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into mbus_pixel_code to represent A-LAW compressed Bayer format. This corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8. add UV8 and NV12 ( Y and C separate with UV interleaved) which are supported on dm365. Signed-off-by: Manjunath Hadli Cc: Laurent Pinchart --- include/linux/v4l2-mediabus.h | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644 --- a/include/linux/v4l2-mediabus.h +++ b/include/linux/v4l2-mediabus.h @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, - /* YUV (including grey) - next is 0x2014 */ + /* YUV (including grey) - next is 0x2016 */ V4L2_MBUS_FMT_Y8_1X8 = 0x2001, V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012, V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, + V4L2_MBUS_FMT_NV12_1X20 = 0x2014, + V4L2_MBUS_FMT_UV8_1X8 = 0x2015, - /* Bayer - next is 0x3015 */ + /* Bayer - next is 0x3019 */ V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013, V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode { V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010, V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011, V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012, + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015, + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016, + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017, + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018, /* JPEG compressed formats - next is 0x4002 */ V4L2_MBUS_FMT_JPEG_1X8 = 0x4001, -- 1.6.2.4 From laurent.pinchart at ideasonboard.com Thu Dec 15 07:00:47 2011 From: laurent.pinchart at ideasonboard.com (Laurent Pinchart) Date: Thu, 15 Dec 2011 14:00:47 +0100 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: <1323951898-16330-3-git-send-email-manjunath.hadli@ti.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <1323951898-16330-3-git-send-email-manjunath.hadli@ti.com> Message-ID: <201112151400.48321.laurent.pinchart@ideasonboard.com> Hi Manjunath, Thanks for the patch. On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format > frames compressed by A-LAW alogorithm. > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only. > > Signed-off-by: Manjunath Hadli > Cc: Laurent Pinchart > --- > include/linux/videodev2.h | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) Could you please also document these formats in Documentation/DocBook/media/v4l ? > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > index 4b752d5..969112d 100644 > --- a/include/linux/videodev2.h > +++ b/include/linux/videodev2.h > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 v4l2_fourcc('M', > '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv interleaved */ > > +/* Chrominance formats */ > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV > 4:4 */ + > /* two planes -- one Y, one Cr + Cb interleaved */ > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* > 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct v4l2_pix_format { > #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. > GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */ > #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') > + /* 10bit raw bayer a-law compressed to 8 bits */ > +#define V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > + That's not very future-proof, how would you describe SGBRG10ALAW8 for instance ? Maybe it's time to standardize FOURCCs for Bayer new formats. We have 4 characters, we could start with 'B' to denote Bayer, followed by one character for the order, one for the compression, and one for the number of bits. > /* > * 10bit raw bayer, expanded to 16 bits > * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb... -- Regards, Laurent Pinchart From laurent.pinchart at ideasonboard.com Thu Dec 15 07:02:44 2011 From: laurent.pinchart at ideasonboard.com (Laurent Pinchart) Date: Thu, 15 Dec 2011 14:02:44 +0100 Subject: [PATCH 1/2] media: add new mediabus format enums for dm365 In-Reply-To: <1323951898-16330-2-git-send-email-manjunath.hadli@ti.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <1323951898-16330-2-git-send-email-manjunath.hadli@ti.com> Message-ID: <201112151402.45100.laurent.pinchart@ideasonboard.com> Hi Manhunath, Thanks for the patch. On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote: > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into mbus_pixel_code > to represent A-LAW compressed Bayer format. This corresponds to pixel > format - V4L2_PIX_FMT_SGRBG10ALAW8. > add UV8 and NV12 ( Y and C separate with UV interleaved) which are > supported on dm365. > > Signed-off-by: Manjunath Hadli > Cc: Laurent Pinchart > --- > include/linux/v4l2-mediabus.h | 10 ++++++++-- > 1 files changed, 8 insertions(+), 2 deletions(-) Please also update the documentation in Documentation/DocBook/media/v4l. > diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h > index 5ea7f75..d408654 100644 > --- a/include/linux/v4l2-mediabus.h > +++ b/include/linux/v4l2-mediabus.h > @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode { > V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, > V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, > > - /* YUV (including grey) - next is 0x2014 */ > + /* YUV (including grey) - next is 0x2016 */ > V4L2_MBUS_FMT_Y8_1X8 = 0x2001, > V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, > V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode { > V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012, > V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, > V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, > + V4L2_MBUS_FMT_NV12_1X20 = 0x2014, > + V4L2_MBUS_FMT_UV8_1X8 = 0x2015, NV12, on the bus ? How does that work ? (The documentation should answer my question :-)) > - /* Bayer - next is 0x3015 */ > + /* Bayer - next is 0x3019 */ > V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, > V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013, > V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, > @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode { > V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010, > V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011, > V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012, > + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015, > + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016, > + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017, > + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018, Please keep the names sorted as described in the comment at the beginning of the file. > > /* JPEG compressed formats - next is 0x4002 */ > V4L2_MBUS_FMT_JPEG_1X8 = 0x4001, -- Regards, Laurent Pinchart From timothy.bean at gmail.com Thu Dec 15 08:30:07 2011 From: timothy.bean at gmail.com (Timothy Bean) Date: Thu, 15 Dec 2011 08:30:07 -0600 Subject: Help with gstreamer Message-ID: Hi Guys I got Gstreamer installed and am getting the gst-rtsp-server going. Got it compiled finally but when I run: ./test-video ./test-video: symbol lookup error: /usr/lib/libgstreamer-0.10.so.0: undefined symbol: g_once_init_enter_impl I Googled and says maybe something wrong with different version of Glib, but I am not sure how to match them if that is the case. Here is some more debuging: ldd -r test-launch libgstrtspserver-0.10.so.0 => /usr/lib/libgstrtspserver-0.10.so.0 (0x4002f000) libgstrtp-0.10.so.0 => /usr/lib/libgstrtp-0.10.so.0 (0x4004a000) libgstrtsp-0.10.so.0 => /usr/lib/libgstrtsp-0.10.so.0 (0x40065000) libgstsdp-0.10.so.0 => /usr/lib/libgstsdp-0.10.so.0 (0x40081000) libgstapp-0.10.so.0 => /usr/lib/libgstapp-0.10.so.0 (0x4008f000) libgstbase-0.10.so.0 => /usr/lib/libgstbase-0.10.so.0 (0x400a2000) libgstreamer-0.10.so.0 => /usr/lib/libgstreamer-0.10.so.0 (0x400e3000) libm.so.6 => /lib/libm.so.6 (0x401ab000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x40256000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x4029b000) libdl.so.2 => /lib/libdl.so.2 (0x402a6000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x402b1000) libpthread.so.0 => /lib/libpthread.so.0 (0x402bd000) librt.so.1 => /lib/librt.so.1 (0x402dc000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x402eb000) libc.so.6 => /lib/libc.so.6 (0x403ad000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x404d2000) /lib/ld-linux.so.3 (0x40000000) undefined symbol: g_assertion_message_expr (/usr/lib/libgstreamer-0.10.so.0) undefined symbol: g_once_init_enter_impl (/usr/lib/libgstreamer-0.10.so.0) undefined symbol: g_assertion_message (/usr/lib/libgstreamer-0.10.so.0) undefined symbol: g_once_init_leave (/usr/lib/libgstreamer-0.10.so.0) undefined symbol: g_assertion_message_expr (/usr/lib/libgstbase-0.10.so.0) undefined symbol: g_once_init_enter_impl (/usr/lib/libgstbase-0.10.so.0) undefined symbol: g_once_init_leave (/usr/lib/libgstbase-0.10.so.0) undefined symbol: g_once_init_enter_impl (/usr/lib/libgstapp-0.10.so.0) undefined symbol: g_once_init_leave (/usr/lib/libgstapp-0.10.so.0) undefined symbol: g_checksum_update (/usr/lib/libgstrtsp-0.10.so.0) undefined symbol: g_checksum_get_string (/usr/lib/libgstrtsp-0.10.so.0) undefined symbol: g_checksum_new (/usr/lib/libgstrtsp-0.10.so.0) undefined symbol: g_checksum_free (/usr/lib/libgstrtsp-0.10.so.0) undefined symbol: g_once_init_enter_impl (/usr/lib/libgstrtsp-0.10.so.0) undefined symbol: g_checksum_reset (/usr/lib/libgstrtsp-0.10.so.0) undefined symbol: g_once_init_leave (/usr/lib/libgstrtsp-0.10.so.0) undefined symbol: g_once_init_enter_impl (/usr/lib/libgstrtp-0.10.so.0) undefined symbol: g_once_init_leave (/usr/lib/libgstrtp-0.10.so.0) undefined symbol: g_once_init_enter_impl (/usr/lib/libgstrtspserver-0.10.so.0) undefined symbol: g_once_init_leave (/usr/lib/libgstrtspserver-0.10.so.0) I posted this over at the Gstreamer forum but no one has replied yet. Thanks Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsekhar at ti.com Thu Dec 15 11:10:57 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 15 Dec 2011 17:10:57 +0000 Subject: [PATCH] arm,davinci: configure davinci aemif chipselects through OF In-Reply-To: References: <1322991679-20947-1-git-send-email-hs@denx.de> <4EE07E27.8090602@denx.de> <201112081548.08548.arnd@arndb.de> Message-ID: Hi Ben, On Wed, Dec 14, 2011 at 20:05:25, Ben Gardiner wrote: > Hello Arnd and Sekhar, > > On Tue, Dec 13, 2011 at 1:34 PM, Nori, Sekhar wrote: > > [...] > > On Thu, Dec 08, 2011 at 21:18:08, Arnd Bergmann wrote: > >> [...] > >> If you want it to provide endpoint devices that are handled by > >> distinct subsystems in Linux, I would make it an mfd multifunction > >> device and make the common code a driver that scans the connected > >> memories in order to register its child devices for each of the > >> subsystems. > > > > Okay. Thanks for the explanation. Since the users of AEMIF at this > > point are mtd devices, I propose moving it to drivers/mtd/davinci-aemif.c > > (of course, mtd folks need to approve). > > We have a vested interest in the davinci AEMIF setup facilities > in-kernel; I'm electing to pipe-up now rather than later. Sadly our > board is not yet in mainline so my opinions may be redirected to the > bit-bucket as you see fit. We are planning to post a patch series for > our complete board support -- but we can't do it right now. > > The AEMIF is useful for interfacing to other asynchronous devices too; > our newest board uses it for accessing memory mapped FPGA functional > blocks via UIO and for permanent storage to a compact flash using > pata_platform. In both cases the timings and mode for the chip-select > are manually configured before the devices are registered. In both > cases the performance of the endpoints could be better preserved > across CPU freq transitions if the hooks for cpufreq transitions > recently proposed by Sudhakar [1] were part of an mfd device and hence > applicable to devices other than mtd. > > Again, I apologize for requesting features for boards that are not yet > in mainline. No problem. Thanks for showing a use case I didn't know existed. Now we just need to find someone to work on moving aemif to mfd multifunction device :) Thanks, Sekhar From gangadhar.509 at gmail.com Thu Dec 1 03:38:40 2011 From: gangadhar.509 at gmail.com (vassamsetti gangadhar) Date: Thu, 1 Dec 2011 15:08:40 +0530 Subject: uboot in nandflash Message-ID: Hi, i am gangadhar i am using p2020rdb i am done u-boot in nand flash but in minicom ping is not alive error ,tftp is not working but in my host ping is alive how can i make ping alive in nandflash but in nor flash everything working fine. Thanks&Regards V.Ganagadhar -------------- next part -------------- An HTML attachment was scrubbed... URL: From kahle at precor.com Thu Dec 8 01:09:39 2011 From: kahle at precor.com (Kahle, Steve) Date: Wed, 7 Dec 2011 23:09:39 -0800 Subject: NFS boot help In-Reply-To: <4EE027AA.4070102@mindspring.com> Message-ID: Is ethaddr set to a reasonable value in bootargs? From: Chuck Meade [mailto:chuckmeade at mindspring.com] Sent: Wednesday, December 07, 2011 06:57 PM To: Timothy Bean Cc: davinci-linux-open-source at linux.davincidsp.com Subject: Re: NFS boot help On 12/07/2011 08:51 PM, Timothy Bean wrote: Here is capture. Thanks for anyone that can look at it and maybe point me in the right direction. I exported as text file and compressed. Thanks Tim On Wed, Dec 7, 2011 at 9:47 AM, Chuck Meade > wrote: On 12/07/2011 10:39 AM, Steve Chen wrote: On Wed, Dec 7, 2011 at 9:23 AM, Timothy Bean > wrote: ... IP-Config: Complete: device=eth0, addr=192.168.0.100, mask=255.25 5.255.0, gw=192.168.0.1, host=192.168.0.100, domain=, nis-domain=(none), bootserver=192.168.0.50, rootserver=192.168.0.50, rootpath= Waiting 5sec before mounting root device... Looking up port of RPC 100003/2 on 192.168.0.50 Looking up port of RPC 100005/1 on 192.168.0.50 VFS: Mounted root (nfs filesystem). Freeing init memory: 172K INIT: version 2.86 booting Starting the hotplug events dispatcher: udevd . Synthesizing the initial hotplug events... done. Waiting for /dev to be fully populated... done. Activating swap... done. Remounting root filesystem...done. Calculating module dependencies nfs: server 192.168.0.50 not responding, still trying nfs: server 192.168.0.50 not responding, still trying nfs: server 192.168.0.50 not responding, still trying Do you have any other pointers? I hopefully have attached a wireshark catpure. Maybe someone can look at that and determine what I am doing wrong. This is what I put for my interfaces file: Yes, your analysis is correct that NFS was connected and dropped shortly after. I have seen similar issues when the target board shared the same IP address as another device on the network. You may want to try replacing the kernel command line ... ip=192.168.0.100:192.168.0.50:192.168.0.1:255.255.255.0:::off ... with ... ip=dhcp ... to see if that makes a difference. Or just unplug your board and ping 192.168.0.100 to make sure no-one answers. Regards, Steve Your wireshark capture was not attached (at least I did not get it). The Linux Ethernet driver was working, since NFS mounted successfully. Without seeing the wireshark info I can't tell, but you should check to be sure that some other bootup logic has not changed the target's IP address or Eth MAC address. You mention that the wireshark packets go from looking fine to looking like fragments. Do this same boot sequence, but reduce what is being loaded and run at bootup. Especially reduce the list of modules being loaded, one by one. Then reduce what is being done by the sysv init logic. Boot up after each small change you make. If you can find a point at which you stop seeing the problem, then you have likely found what is causing it. Chuck I don't see NFS necessarily failing there. Something is causing a read of a large file at the end, and that is after a lot of reads of *.ko files. You can "grep LOOKUP nfs_capture.txt" to see what files were read in that capture. I still suggest that you simplify your boot process. If you cut back on the large number of modules being loaded and strip down your startup sequence, then you may be able to find out what in the startup sequence is causing the problem. The fact that NFS works fine and allows you to read in so many files means that it is at least functional. Chuck This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsekhar at ti.com Thu Dec 15 12:37:33 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 15 Dec 2011 18:37:33 +0000 Subject: [PATCH] ARM: davinci: add missing commas on last members of structure and arrays In-Reply-To: <20111214220005.GQ32251@atomide.com> References: <1323335151-25398-1-git-send-email-akshay.s@ti.com> <20111214220005.GQ32251@atomide.com> Message-ID: On Thu, Dec 15, 2011 at 03:30:05, Tony Lindgren wrote: > * Nori, Sekhar [111214 04:42]: > > Hi Akshay, > > > > On Thu, Dec 08, 2011 at 14:35:51, Shankarmurthy, Akshay wrote: > > > This patch adds missing commas on last members of structure and arrays. > > > This makes less harder to add additional initializer at the end of the > > > existing initializers and avoids the conflict of more line being > > > modified. This was pointed out by Russell King in his pet peeves mail at > > > http://www.spinics.net/lists/arm-kernel/msg147268.html. > > > > Tony has already provided link to his patches fixing this in the > > message you referenced. Is your patch catching any additional instances? > > > > Tony's patch adds comma after some sentinels, which should be dropped. > > My patches are intended just as a reference, please feel free > to pick from those and apply as needed along with other > related clean-up. Tony, Thanks for clarifying. Regards, Sekhar From m-karicheri2 at ti.com Thu Dec 15 15:20:10 2011 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Thu, 15 Dec 2011 21:20:10 +0000 Subject: Log time stamp wraps around to 25 Message-ID: <3E54258959B69E4282D79E01AB1F32B7248955@DFLE34.ent.ti.com> Sekhar, On our new SoC that is a using davinci architecture in kernel, we are seeing an issue in which the time stamp displayed by printk wraps around at about 25-26 seconds. We are using a timer clock frequency of 163.84MHz and uses timer64 for implementing clock event and clock source. The cat /proc/interrupts shows that the event interrupts are happening at HZ rate. Clock source max of 0xffffffff translates to about 25 secs. So when prink calls the arch specific sched_clock(), the time stamp wraps around at the max. If the weak sched_clock is used instead, then time stamp is working fine (but lower resolution). There seems to be something missing that mess up the time stamp. Have you seen this kind of behavior before and if so, what could be the potential cause for this. We are using v3.1 from upstream kernel repo. You help will be highly appreciated. Thanks. Murali Karicheri Software Design Engineer email: m-karicheri2 at ti.com Phone: (301) 407 9583 From m-karicheri2 at ti.com Thu Dec 15 17:20:54 2011 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Thu, 15 Dec 2011 23:20:54 +0000 Subject: Log time stamp wraps around to 25 Message-ID: <3E54258959B69E4282D79E01AB1F32B72489F0@DFLE34.ent.ti.com> Sekhar, I made some searches on the internet. The schedule_clock() must return a monotonous clock. One way to do this is to use cnt32_to_63() to convert the 32bit clock count value to a 64bit value. I have tried this and it seems to work. I am just curious as to how this is working on other davinci platforms? So any response from you will be helpful. unsigned long long notrace sched_clock(void) { - const cycle_t cyc = clocksource_davinci.read(&clocksource_davinci); + const cycle_t cyc = cnt32_to_63(clocksource_davinci.read(&clocksource_davinci)); Murali Karicheri Software Design Engineer email: m-karicheri2 at ti.com Phone: (301) 407 9583 >> -----Original Message----- >> From: Karicheri, Muralidharan >> Sent: Thursday, December 15, 2011 4:20 PM >> To: Nori, Sekhar >> Cc: 'davinci-linux-open-source at linux.davincidsp.com'; Chemparathy, Cyril >> Subject: Log time stamp wraps around to 25 >> >> Sekhar, >> >> On our new SoC that is a using davinci architecture in kernel, we are seeing >> an issue in which the time stamp displayed by printk wraps around at about 25- >> 26 seconds. We are using a timer clock frequency of 163.84MHz and uses timer64 >> for implementing clock event and clock source. >> The cat /proc/interrupts shows that the event interrupts are happening at HZ >> rate. Clock source max of 0xffffffff translates to about 25 secs. >> So when prink calls the arch specific sched_clock(), the time stamp wraps >> around at the max. If the weak sched_clock is used instead, then time stamp is >> working fine (but lower resolution). There seems to be something missing that >> mess up the time stamp. Have you seen this kind of behavior before and if so, >> what could be the potential cause for this. We are using v3.1 from upstream >> kernel repo. >> >> You help will be highly appreciated. >> >> Thanks. >> >> Murali Karicheri >> Software Design Engineer >> email: m-karicheri2 at ti.com >> Phone: (301) 407 9583 >> From olof at lixom.net Fri Dec 16 01:24:11 2011 From: olof at lixom.net (Olof Johansson) Date: Thu, 15 Dec 2011 23:24:11 -0800 Subject: [GIT PULL] DaVinci features for v3.3 In-Reply-To: References: Message-ID: Hi, On Wed, Dec 14, 2011 at 10:34 AM, Nori, Sekhar wrote: > Arnd, Olof, > > I have this lone feature queued for v3.3 so far. Can you please pull? > The patch depends on v3.2-rc5 for build, but I have not rebased to > preserve the commit date. > > Thanks, > Sekhar > > The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139: > ?Linus Torvalds (1): > ? ? ? ?Linux 3.2-rc3 > > are available in the git repository at: > > ?git://gitorious.org/linux-davinci/linux-davinci.git v3.3/features Thanks, pulled into next/devel. -Olof From manjunath.hadli at ti.com Fri Dec 16 07:42:48 2011 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Fri, 16 Dec 2011 13:42:48 +0000 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: <201112151400.48321.laurent.pinchart@ideasonboard.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <1323951898-16330-3-git-send-email-manjunath.hadli@ti.com> <201112151400.48321.laurent.pinchart@ideasonboard.com> Message-ID: Hello Laurent, Thank you for the comments. On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > Hi Manjunath, > > Thanks for the patch. > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format > > frames compressed by A-LAW alogorithm. > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only. > > > > Signed-off-by: Manjunath Hadli > > Cc: Laurent Pinchart > > --- > > include/linux/videodev2.h | 6 ++++++ > > 1 files changed, 6 insertions(+), 0 deletions(-) > > Could you please also document these formats in Documentation/DocBook/media/v4l ? I will. Sorry to have missed that out. > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > > index 4b752d5..969112d 100644 > > --- a/include/linux/videodev2.h > > +++ b/include/linux/videodev2.h > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 v4l2_fourcc('M', > > '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv interleaved */ > > > > +/* Chrominance formats */ > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 UV > > 4:4 */ + > > /* two planes -- one Y, one Cr + Cb interleaved */ > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') /* > > 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct v4l2_pix_format { > > #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. > > GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */ #define > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > + > > That's not very future-proof, how would you describe SGBRG10ALAW8 for instance ? > > Maybe it's time to standardize FOURCCs for Bayer new formats. We have 4 characters, we could start with 'B' to denote Bayer, followed by one character for the order, one for the compression, and one for the number of bits. I agree. May be ('B', 'G', 'A', '8') is fine for the above? Thanks and Regards, -Manju > > > /* > > * 10bit raw bayer, expanded to 16 bits > > * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb... > > -- > Regards, > > Laurent Pinchart > From manjunath.hadli at ti.com Fri Dec 16 08:20:24 2011 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Fri, 16 Dec 2011 14:20:24 +0000 Subject: [PATCH 1/2] media: add new mediabus format enums for dm365 In-Reply-To: <201112151402.45100.laurent.pinchart@ideasonboard.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <1323951898-16330-2-git-send-email-manjunath.hadli@ti.com> <201112151402.45100.laurent.pinchart@ideasonboard.com> Message-ID: Laurent, Thank you for the comments. On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote: > Hi Manhunath, > > Thanks for the patch. > > On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote: > > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into > > mbus_pixel_code to represent A-LAW compressed Bayer format. This > > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8. > > add UV8 and NV12 ( Y and C separate with UV interleaved) which are > > supported on dm365. > > > > Signed-off-by: Manjunath Hadli > > Cc: Laurent Pinchart > > --- > > include/linux/v4l2-mediabus.h | 10 ++++++++-- > > 1 files changed, 8 insertions(+), 2 deletions(-) > > Please also update the documentation in Documentation/DocBook/media/v4l. > > > diff --git a/include/linux/v4l2-mediabus.h > > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644 > > --- a/include/linux/v4l2-mediabus.h > > +++ b/include/linux/v4l2-mediabus.h > > @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode { > > V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, > > V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, > > > > - /* YUV (including grey) - next is 0x2014 */ > > + /* YUV (including grey) - next is 0x2016 */ > > V4L2_MBUS_FMT_Y8_1X8 = 0x2001, > > V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, > > V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, > > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode { > > V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012, > > V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, > > V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, > > + V4L2_MBUS_FMT_NV12_1X20 = 0x2014, > > + V4L2_MBUS_FMT_UV8_1X8 = 0x2015, > > NV12, on the bus ? How does that work ? (The documentation should answer my question :-)) Well, this is on the internal bus not exposed outside, but nevertheless bus between two subdevs or two independent hardware blocks. For example Resizer supports NV12 on its pad. Is there any other way to treat this? Thx, -Manju > > > - /* Bayer - next is 0x3015 */ > > + /* Bayer - next is 0x3019 */ > > V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, > > V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013, > > V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, > > @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode { > > V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010, > > V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011, > > V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012, > > + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015, > > + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016, > > + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017, > > + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018, > > Please keep the names sorted as described in the comment at the beginning of the file. > > > > > /* JPEG compressed formats - next is 0x4002 */ > > V4L2_MBUS_FMT_JPEG_1X8 = 0x4001, > > -- > Regards, > > Laurent Pinchart > From manjunath.hadli at ti.com Fri Dec 16 08:22:06 2011 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Fri, 16 Dec 2011 14:22:06 +0000 Subject: [PATCH v6 01/11] davinci: vpif: remove obsolete header file inclusion In-Reply-To: <1323951120-15876-2-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> <1323951120-15876-2-git-send-email-manjunath.hadli@ti.com> Message-ID: Mauro, Sekhar needs your ack on this to get a series of mach patches in. Can you please have a look at this? -Manju On Thu, Dec 15, 2011 at 17:41:50, Hadli, Manjunath wrote: > remove inclusion of header files from vpif.h and vpif_dispaly.c and add appropriate header file for building. > > Signed-off-by: Manjunath Hadli > Cc: Mauro Carvalho Chehab > Cc: LMML > --- > drivers/media/video/davinci/vpif.h | 2 +- > drivers/media/video/davinci/vpif_display.c | 2 -- > 2 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/video/davinci/vpif.h b/drivers/media/video/davinci/vpif.h > index 25036cb..c96268a 100644 > --- a/drivers/media/video/davinci/vpif.h > +++ b/drivers/media/video/davinci/vpif.h > @@ -19,7 +19,7 @@ > #include > #include > #include > -#include > +#include > #include > > /* Maximum channel allowed */ > diff --git a/drivers/media/video/davinci/vpif_display.c b/drivers/media/video/davinci/vpif_display.c > index 286f029..7fa34b4 100644 > --- a/drivers/media/video/davinci/vpif_display.c > +++ b/drivers/media/video/davinci/vpif_display.c > @@ -39,8 +39,6 @@ > #include > #include > > -#include > - > #include "vpif_display.h" > #include "vpif.h" > > -- > 1.6.2.4 > > From arnd at arndb.de Fri Dec 16 08:28:03 2011 From: arnd at arndb.de (Arnd Bergmann) Date: Fri, 16 Dec 2011 14:28:03 +0000 Subject: [GIT PULL] DaVinci cleanup for v3.3 In-Reply-To: References: Message-ID: <201112161428.03412.arnd@arndb.de> On Wednesday 14 December 2011, Nori, Sekhar wrote: > I have this lone patch queued for DaVinci clean-up so far. > Can you please pull this? > > The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139: > Linus Torvalds (1): > Linux 3.2-rc3 > > are available in the git repository at: > > git://gitorious.org/linux-davinci/linux-davinci.git v3.3/cleanup > Pulled into next/cleanups, but not happy about the patch. While the patch is a move in the right direction, it is not sufficient for what you intend with it: Author: Manjunath Hadli Date: Sat Nov 12 20:36:02 2011 +0530 ARM: davinci: vpif: move code to driver core header from platform Move vpif related definitions for capture and display drivers from dm646x platform header file to vpif_types.h inside the driver as these definitions are related to driver code rather than the platform or board. This enables reusing this IP across platforms. If you really want to use the same IP on future platforms, the correct approach would be to get rid of the requirement for having platform- specific callbacks and setup data, and replace it all with device tree based probing. I can understand that you consider mach-davinci legacy code and don't want to rework it in significant ways, but if a driver that is used in there is not legacy code, it should be updated to the modern ways of doing this. Arnd From nsekhar at ti.com Mon Dec 19 02:12:08 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Mon, 19 Dec 2011 08:12:08 +0000 Subject: [GIT PULL] DaVinci cleanup for v3.3 In-Reply-To: <201112161428.03412.arnd@arndb.de> References: <201112161428.03412.arnd@arndb.de> Message-ID: Hi Arnd, On Fri, Dec 16, 2011 at 19:58:03, Arnd Bergmann wrote: > On Wednesday 14 December 2011, Nori, Sekhar wrote: > > I have this lone patch queued for DaVinci clean-up so far. > > Can you please pull this? > > > > The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139: > > Linus Torvalds (1): > > Linux 3.2-rc3 > > > > are available in the git repository at: > > > > git://gitorious.org/linux-davinci/linux-davinci.git v3.3/cleanup > > > > Pulled into next/cleanups, but not happy about the patch. > > While the patch is a move in the right direction, it is not sufficient for > what you intend with it: > > Author: Manjunath Hadli > Date: Sat Nov 12 20:36:02 2011 +0530 > > ARM: davinci: vpif: move code to driver core header from platform > > Move vpif related definitions for capture and display drivers > from dm646x platform header file to vpif_types.h inside > the driver as these definitions are related to driver code > rather than the platform or board. > > This enables reusing this IP across platforms. > > If you really want to use the same IP on future platforms, the correct > approach would be to get rid of the requirement for having platform- > specific callbacks and setup data, and replace it all with device tree > based probing. I can understand that you consider mach-davinci legacy > code and don't want to rework it in significant ways, but if a driver > that is used in there is not legacy code, it should be updated to the > modern ways of doing this. Yes, agreed. In this case the other platform is not an OMAP but an existing DaVinci platform - da850. There are no plans of using VPIF on any new OMAP platforms AFAIK. Thanks for pulling the patch. Regards, Sekhar From nsekhar at ti.com Mon Dec 19 13:14:48 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Mon, 19 Dec 2011 19:14:48 +0000 Subject: Log time stamp wraps around to 25 In-Reply-To: <3E54258959B69E4282D79E01AB1F32B72489F0@DFLE34.ent.ti.com> References: <3E54258959B69E4282D79E01AB1F32B72489F0@DFLE34.ent.ti.com> Message-ID: Hi Murali, On Fri, Dec 16, 2011 at 04:50:54, Karicheri, Muralidharan wrote: > Sekhar, > > I made some searches on the internet. The schedule_clock() must return a monotonous clock. One way to do this is to use cnt32_to_63() to convert the 32bit clock count value to a 64bit value. I have tried this and it seems to work. I am just curious as to how this is working on other davinci platforms? So any response from you will be helpful. > I checked this on AM18x and the clock there wraps around in about 180 seconds which is consistent with your observation given that we have a 24 MHz timer clock there. I did a quick implementation of sched_clock using the common sched_clock infrastructure in arch/arm/kernel/sched_clock.c and that seemed to have fixed the issue in some limited testing. Attached is the patch, can you give it a shot? Thanks, Sekhar ----8<----- diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e084b7e..b5b630a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -924,6 +924,7 @@ config ARCH_DAVINCI select ARCH_REQUIRE_GPIOLIB select ZONE_DMA select HAVE_IDE + select HAVE_SCHED_CLOCK select CLKDEV_LOOKUP select GENERIC_ALLOCATOR select GENERIC_IRQ_CHIP diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c index e1969ce..8396ba8 100644 --- a/arch/arm/mach-davinci/time.c +++ b/arch/arm/mach-davinci/time.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include "clock.h" @@ -292,12 +293,18 @@ static struct clocksource clocksource_davinci = { /* * Overwrite weak default sched_clock with something more precise */ +static DEFINE_CLOCK_DATA(cd); + unsigned long long notrace sched_clock(void) { - const cycle_t cyc = clocksource_davinci.read(&clocksource_davinci); + u32 cyc = clocksource_davinci.read(&clocksource_davinci); + return cyc_to_sched_clock(&cd, cyc, (u32)~0); +} - return clocksource_cyc2ns(cyc, clocksource_davinci.mult, - clocksource_davinci.shift); +static void notrace davinci_update_sched_clock(void) +{ + u32 cyc = clocksource_davinci.read(&clocksource_davinci); + update_sched_clock(&cd, cyc, (u32)~0); } /* @@ -399,6 +406,8 @@ static void __init davinci_timer_init(void) /* setup clocksource */ clocksource_davinci.read = read_cycles; clocksource_davinci.name = id_to_name[clocksource_id]; + init_sched_clock(&cd, davinci_update_sched_clock, 32, + davinci_clock_tick_rate); if (clocksource_register_hz(&clocksource_davinci, davinci_clock_tick_rate)) printk(err, clocksource_davinci.name); From nsekhar at ti.com Mon Dec 19 14:02:29 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Mon, 19 Dec 2011 20:02:29 +0000 Subject: [PATCH v6 01/11] davinci: vpif: remove obsolete header file inclusion In-Reply-To: <1323951120-15876-2-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> <1323951120-15876-2-git-send-email-manjunath.hadli@ti.com> Message-ID: Hi Manju, In the subject line, calling mach/dm646x.h obsolete is not right since as of this patch mach/dm646x.h still exists. On Thu, Dec 15, 2011 at 17:41:50, Hadli, Manjunath wrote: > remove inclusion of header files from vpif.h and vpif_dispaly.c > and add appropriate header file for building. The main purpose of the patch is to remove machine specific includes from driver files since that (among other things) comes in the way of platform code consolidation. This needs to come out in the description. Right now the description is just describing the change without answering the question - why? > > Signed-off-by: Manjunath Hadli > Cc: Mauro Carvalho Chehab > Cc: LMML > --- > drivers/media/video/davinci/vpif.h | 2 +- > drivers/media/video/davinci/vpif_display.c | 2 -- > 2 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/video/davinci/vpif.h b/drivers/media/video/davinci/vpif.h > index 25036cb..c96268a 100644 > --- a/drivers/media/video/davinci/vpif.h > +++ b/drivers/media/video/davinci/vpif.h > @@ -19,7 +19,7 @@ > #include > #include > #include It appears mach/hardware.h can be removed as well. Can you please check? > -#include > +#include I2C is actually needed by include/media/davinci/vpif_types.h so it should go there. Thanks, Sekhar From nsekhar at ti.com Tue Dec 20 00:30:28 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 20 Dec 2011 06:30:28 +0000 Subject: [PATCH v6 02/11] ARM: davinci: dm644x: remove the macros from the header to move to c file In-Reply-To: <1323951120-15876-3-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> <1323951120-15876-3-git-send-email-manjunath.hadli@ti.com> Message-ID: Hi Manju, "remove the macros from the header to move to c file" in subject line is too convoluted to read and doesn't convey the real purpose of the patch. It can simply be stated as: "move private definitions to C file" On Thu, Dec 15, 2011 at 17:41:51, Hadli, Manjunath wrote: > move the register base addresses and offsets used only by dm644x > platform file from platform header dm644x.h to dm644x.c as they > are used only in the c file. And add here: This helps reduce code in arch/arm/mach-davinci/include/mach which is not really needed by rest of the kernel. You have already spun 6 versions of the patch so I will just make these changes locally and commit it. No need to send a replacement. Thanks, Sekhar From prakash.pm at ti.com Tue Dec 20 00:36:45 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Tue, 20 Dec 2011 12:06:45 +0530 Subject: [PATCH] davinci: DA850 EVM: OHCI platform code Message-ID: <1324363005-11320-1-git-send-email-prakash.pm@ti.com> From: Ajay Kumar Gupta On this board the OHCI port's power control and over-current signals from TPS2065 power switch are connected via GPIO1[15] and GPIO2[1] respectively, so we can implement the DA8xx OHCI glue layer's hooks for overriding the root hub port's power and over-current status bits. We also have to properly set up the clocking mode in the CFGCHIP2 register, so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and its output is used to clock the USB 1.1 (OHCI) PHY... Signed-off-by: Ajay Kumar Gupta --- arch/arm/mach-davinci/board-da850-evm.c | 126 +++++++++++++++++++++++++++++++ 1 files changed, 126 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 6659a90..df74ba5 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include @@ -42,6 +43,7 @@ #include #include #include +#include #include #define DA850_EVM_PHY_ID "0:00" @@ -734,6 +736,127 @@ static struct davinci_i2c_platform_data da850_evm_i2c_0_pdata = { .bus_delay = 0, /* usec */ }; +/* + * USB1 VBUS is controlled by GPIO2[4], over-current is reported on GPIO6[13]. + */ +#define ON_BD_USB_DRV GPIO_TO_PIN(2, 4) +#define ON_BD_USB_OVC GPIO_TO_PIN(6, 13) + +static const short da850_evm_usb11_pins[] = { + DA850_GPIO2_4, DA850_GPIO6_13, + -1 +}; + +static da8xx_ocic_handler_t da850_evm_usb_ocic_handler; + +static int da850_evm_usb_set_power(unsigned port, int on) +{ + gpio_set_value(ON_BD_USB_DRV, on); + return 0; +} + +static int da850_evm_usb_get_power(unsigned port) +{ + return gpio_get_value(ON_BD_USB_DRV); +} + +static int da850_evm_usb_get_oci(unsigned port) +{ + return !gpio_get_value(ON_BD_USB_OVC); +} + +static irqreturn_t da850_evm_usb_ocic_irq(int, void *); + +static int da850_evm_usb_ocic_notify(da8xx_ocic_handler_t handler) +{ + int irq = gpio_to_irq(ON_BD_USB_OVC); + int error = 0; + + if (handler != NULL) { + da850_evm_usb_ocic_handler = handler; + + error = request_irq(irq, da850_evm_usb_ocic_irq, IRQF_DISABLED | + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, + "OHCI over-current indicator", NULL); + if (error) + printk(KERN_ERR "%s: could not request IRQ to watch " + "over-current indicator changes\n", __func__); + } else + free_irq(irq, NULL); + + return error; +} + +static struct da8xx_ohci_root_hub da850_evm_usb11_pdata = { + .set_power = da850_evm_usb_set_power, + .get_power = da850_evm_usb_get_power, + .get_oci = da850_evm_usb_get_oci, + .ocic_notify = da850_evm_usb_ocic_notify, + + /* TPS2065 switch @ 5V */ + .potpgt = (3 + 1) / 2, /* 3 ms max */ +}; + +static irqreturn_t da850_evm_usb_ocic_irq(int irq, void *dev_id) +{ + da850_evm_usb_ocic_handler(&da850_evm_usb11_pdata, 1); + return IRQ_HANDLED; +} + +static __init void da850_evm_usb_init(void) +{ + u32 cfgchip2; + int ret; + + /* + * Set up USB clock/mode in the CFGCHIP2 register. + * FYI: CFGCHIP2 is 0x0000ef00 initially. + */ + cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)); + + /* USB2.0 PHY reference clock is 24 MHz */ + cfgchip2 &= ~CFGCHIP2_REFFREQ; + cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ; + + /* + * Select internal reference clock for USB 2.0 PHY + * and use it as a clock source for USB 1.1 PHY + * (this is the default setting anyway). + */ + cfgchip2 &= ~CFGCHIP2_USB1PHYCLKMUX; + cfgchip2 |= CFGCHIP2_USB2PHYCLKMUX; + + __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)); + + ret = davinci_cfg_reg_list(da850_evm_usb11_pins); + if (ret) { + pr_warning("%s: USB 1.1 PinMux setup failed: %d\n", + __func__, ret); + return; + } + + ret = gpio_request(ON_BD_USB_DRV, "ON_BD_USB_DRV"); + if (ret) { + printk(KERN_ERR "%s: failed to request GPIO for USB 1.1 port " + "power control: %d\n", __func__, ret); + return; + } + gpio_direction_output(ON_BD_USB_DRV, 0); + + ret = gpio_request(ON_BD_USB_OVC, "ON_BD_USB_OVC"); + if (ret) { + printk(KERN_ERR "%s: failed to request GPIO for USB 1.1 port " + "over-current indicator: %d\n", __func__, ret); + return; + } + gpio_direction_input(ON_BD_USB_OVC); + + ret = da8xx_register_usb11(&da850_evm_usb11_pdata); + if (ret) + pr_warning("%s: USB 1.1 registration failed: %d\n", + __func__, ret); +} + static struct davinci_uart_config da850_evm_uart_config __initdata = { .enabled_uarts = 0x7, }; @@ -1386,6 +1509,9 @@ static __init void da850_evm_init(void) ret); da850_evm_setup_mac_addr(); + + /* initilaize usb module */ + da850_evm_usb_init(); } #ifdef CONFIG_SERIAL_8250_CONSOLE -- 1.7.1 From nsekhar at ti.com Tue Dec 20 03:02:35 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 20 Dec 2011 09:02:35 +0000 Subject: [PATCH v6 03/11] ARM: davinci: dm365: remove the macros from the header to move to c file In-Reply-To: <1323951120-15876-4-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> <1323951120-15876-4-git-send-email-manjunath.hadli@ti.com> Message-ID: On Thu, Dec 15, 2011 at 17:41:52, Hadli, Manjunath wrote: > move the register base addresses and offsets used only by dm365 > platform file from platform header dm365.h to dm365.c as they > are used only in the c file. > > Signed-off-by: Manjunath Hadli Comitting this patch while making changes to the headline and description similar to that I made for patch 2/11 Thanks, Sekhar From sshtylyov at mvista.com Tue Dec 20 05:07:16 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Tue, 20 Dec 2011 15:07:16 +0400 Subject: [PATCH] davinci: DA850 EVM: OHCI platform code In-Reply-To: <1324363005-11320-1-git-send-email-prakash.pm@ti.com> References: <1324363005-11320-1-git-send-email-prakash.pm@ti.com> Message-ID: <4EF06C64.8000708@mvista.com> Hello. On 20.12.2011 10:36, Manjunathappa, Prakash wrote: > From: Ajay Kumar Gupta It's a good practice to CC the original author of the patch -- which I'm doing now... > On this board the OHCI port's power control and over-current signals from > TPS2065 power switch are connected via GPIO1[15] and GPIO2[1] respectively, Ajay, your description seems to be copied unchganged from the analogous DA830 EVM patch, and thus doesn't match your patch: GPIO2[4] and GPIO6[13] are used apparently. Be more attentive to detail next time please. > so we can implement the DA8xx OHCI glue layer's hooks for overriding the > root hub port's power and over-current status bits. > We also have to properly set up the clocking mode in the CFGCHIP2 register, > so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and > its output is used to clock the USB 1.1 (OHCI) PHY... > Signed-off-by: Ajay Kumar Gupta > --- > arch/arm/mach-davinci/board-da850-evm.c | 126 +++++++++++++++++++++++++++++++ > 1 files changed, 126 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c > index 6659a90..df74ba5 100644 > --- a/arch/arm/mach-davinci/board-da850-evm.c > +++ b/arch/arm/mach-davinci/board-da850-evm.c [...] > @@ -734,6 +736,127 @@ static struct davinci_i2c_platform_data da850_evm_i2c_0_pdata = { [...] > +static int da850_evm_usb_ocic_notify(da8xx_ocic_handler_t handler) > +{ > + int irq = gpio_to_irq(ON_BD_USB_OVC); > + int error = 0; > + > + if (handler != NULL) { > + da850_evm_usb_ocic_handler = handler; > + > + error = request_irq(irq, da850_evm_usb_ocic_irq, IRQF_DISABLED | IRQF_DISABLED is a nop now -- just remove it. WBR, Sergei From sshtylyov at mvista.com Tue Dec 20 05:17:22 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Tue, 20 Dec 2011 15:17:22 +0400 Subject: [PATCH] davinci: DA850 EVM: OHCI platform code In-Reply-To: <1324363005-11320-1-git-send-email-prakash.pm@ti.com> References: <1324363005-11320-1-git-send-email-prakash.pm@ti.com> Message-ID: <4EF06EC2.3070907@mvista.com> Hello. On 20-12-2011 10:36, Manjunathappa, Prakash wrote: > From: Ajay Kumar Gupta > On this board the OHCI port's power control and over-current signals from > TPS2065 power switch are connected via GPIO1[15] and GPIO2[1] respectively, > so we can implement the DA8xx OHCI glue layer's hooks for overriding the > root hub port's power and over-current status bits. > We also have to properly set up the clocking mode in the CFGCHIP2 register, > so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and > its output is used to clock the USB 1.1 (OHCI) PHY... > Signed-off-by: Ajay Kumar Gupta BTW, Prakash, as you'r on the patch's disrtibution path, shouldn't you add your signoff as well? > --- > arch/arm/mach-davinci/board-da850-evm.c | 126 +++++++++++++++++++++++++++++++ > 1 files changed, 126 insertions(+), 0 deletions(-) > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c > index 6659a90..df74ba5 100644 > --- a/arch/arm/mach-davinci/board-da850-evm.c > +++ b/arch/arm/mach-davinci/board-da850-evm.c [...] > +static __init void da850_evm_usb_init(void) > +{ [...] > + ret = gpio_request(ON_BD_USB_DRV, "ON_BD_USB_DRV"); > + if (ret) { > + printk(KERN_ERR "%s: failed to request GPIO for USB 1.1 port " > + "power control: %d\n", __func__, ret); > + return; > + } > + gpio_direction_output(ON_BD_USB_DRV, 0); You should also use gpio_request_one() instead gpio_request()/gpio_direction_output() pair. > + > + ret = gpio_request(ON_BD_USB_OVC, "ON_BD_USB_OVC"); > + if (ret) { > + printk(KERN_ERR "%s: failed to request GPIO for USB 1.1 port " > + "over-current indicator: %d\n", __func__, ret); > + return; > + } > + gpio_direction_input(ON_BD_USB_OVC); Same here. WBR, Sergei From nsekhar at ti.com Tue Dec 20 07:19:34 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 20 Dec 2011 13:19:34 +0000 Subject: [PATCH v6 04/11] ARM: davinci: dm646x: remove the macros from the header to move to c file In-Reply-To: <1323951120-15876-5-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> <1323951120-15876-5-git-send-email-manjunath.hadli@ti.com> Message-ID: On Thu, Dec 15, 2011 at 17:41:53, Hadli, Manjunath wrote: > move the register base addresses and offsets used only by dm646x > platform file from platform header dm646x.h to dm646x.c as they > are used only in the c file. Comitting this as well with the changes as described for patch 2/11. Thanks, Sekhar From ajay.gupta at ti.com Tue Dec 20 07:51:10 2011 From: ajay.gupta at ti.com (Gupta, Ajay Kumar) Date: Tue, 20 Dec 2011 13:51:10 +0000 Subject: [PATCH] davinci: DA850 EVM: OHCI platform code In-Reply-To: <4EF06C64.8000708@mvista.com> References: <1324363005-11320-1-git-send-email-prakash.pm@ti.com> <4EF06C64.8000708@mvista.com> Message-ID: <47CEF8C4B26E8C44B22B028A650E0EA90659DC@DBDE01.ent.ti.com> Hi > Hello. > > On 20.12.2011 10:36, Manjunathappa, Prakash wrote: > > > From: Ajay Kumar Gupta > > It's a good practice to CC the original author of the patch -- which > I'm > doing now... > > > On this board the OHCI port's power control and over-current signals > from > > TPS2065 power switch are connected via GPIO1[15] and GPIO2[1] > respectively, > > Ajay, your description seems to be copied unchganged from the > analogous > DA830 EVM patch, and thus doesn't match your patch: GPIO2[4] and > GPIO6[13] are > used apparently. Be more attentive to detail next time please. Well, this patch was created long back for internal release work and couldn't review this before it is sent out. Prakash, Please correct the patch description as suggested. Regards, Ajay > . > > so we can implement the DA8xx OHCI glue layer's hooks for overriding > the > > root hub port's power and over-current status bits. > > > We also have to properly set up the clocking mode in the CFGCHIP2 > register, > > so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) > PHY and > > its output is used to clock the USB 1.1 (OHCI) PHY... > > > Signed-off-by: Ajay Kumar Gupta > > --- > > arch/arm/mach-davinci/board-da850-evm.c | 126 > +++++++++++++++++++++++++++++++ > > 1 files changed, 126 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach- > davinci/board-da850-evm.c > > index 6659a90..df74ba5 100644 > > --- a/arch/arm/mach-davinci/board-da850-evm.c > > +++ b/arch/arm/mach-davinci/board-da850-evm.c > [...] > > @@ -734,6 +736,127 @@ static struct davinci_i2c_platform_data > da850_evm_i2c_0_pdata = { > [...] > > +static int da850_evm_usb_ocic_notify(da8xx_ocic_handler_t handler) > > +{ > > + int irq = gpio_to_irq(ON_BD_USB_OVC); > > + int error = 0; > > + > > + if (handler != NULL) { > > + da850_evm_usb_ocic_handler = handler; > > + > > + error = request_irq(irq, da850_evm_usb_ocic_irq, > IRQF_DISABLED | > > IRQF_DISABLED is a nop now -- just remove it. > > WBR, Sergei From m-karicheri2 at ti.com Tue Dec 20 09:15:14 2011 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Tue, 20 Dec 2011 15:15:14 +0000 Subject: Log time stamp wraps around to 25 In-Reply-To: References: <3E54258959B69E4282D79E01AB1F32B72489F0@DFLE34.ent.ti.com> Message-ID: <3E54258959B69E4282D79E01AB1F32B7249C8B@DFLE34.ent.ti.com> Sekhar, I had implemented the same fix yesterday after discussion with Russell in the ARM mailing list. I got a crash in the sched_init() as given below. I am not sure why this is not happening on your platform. I haven't root caused the reason for this crash, but from Russell's email, it seems timer is to be initialized using early_init() of machine callback so that sched_init() will be able to call sched_clock early. I will debug the root cause of the crash, but what you think on moving timer initialization to early_init() machine callback? Murali [ 0.000000] Memory: 128MB = 128MB total [ 0.000000] Memory: 126552k/126552k available, 4520k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] DMA : 0xff000000 - 0xffe00000 ( 14 MB) [ 0.000000] vmalloc : 0xc8800000 - 0xfe600000 ( 862 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) [ 0.000000] .text : 0xc0008000 - 0xc02edf7c (2968 kB) [ 0.000000] .init : 0xc02ee000 - 0xc030a000 ( 112 kB) [ 0.000000] .data : 0xc030a000 - 0xc032f600 ( 150 kB) [ 0.000000] .bss : 0xc032f624 - 0xc03470d8 ( 95 kB) [ 0.000000] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 0.000000] pgd = c0004000 [ 0.000000] [00000000] *pgd=00000000 [ 0.000000] Internal error: Oops: 5 [#1] PREEMPT [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 Not tainted (3.1.0-00032-g5dc3d4f-dirty #4) [ 0.000000] PC is at sched_clock+0x1c/0x64 [ 0.000000] LR is at 0x0 [ 0.000000] pc : [] lr : [<00000000>] psr: 400001d3 [ 0.000000] sp : c030bf90 ip : 00000000 fp : c030bfac [ 0.000000] r10: c0313030 r9 : c0311bf0 r8 : c032fcc0 [ 0.000000] r7 : 00000000 r6 : 389fd980 r5 : c030dd48 r4 : 400001d3 [ 0.000000] r3 : 00000000 r2 : c032f910 r1 : 00000000 r0 : c030dd48 [ 0.000000] Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [ 0.000000] Control: 10c5287b Table: 80004019 DAC: 00000015 [ 0.000000] Process swapper (pid: 0, stack limit = 0xc030a2e8) [ 0.000000] Stack: (0xc030bf90 to 0xc030c000) [ 0.000000] bf80: 400001d3 c030dd48 389fd980 c030385c [ 0.000000] bfa0: c030a000 00000000 c030bfd4 c02f49fc c030c160 c032f640 c030515c c0305158 [ 0.000000] bfc0: c030ed84 80004059 413fc082 00000000 00000000 c02ee650 c02ee2c0 00000000 [ 0.000000] bfe0: 00000000 c030515c 00000000 10c52c79 c030c040 8000803c 00000000 00000000 [ 0.000000] [] (sched_clock+0x1c/0x64) from [] (init_idle+0x3c/0xa0) [ 0.000000] [] (init_idle+0x3c/0xa0) from [] (sched_init+0x190/0x1ec) [ 0.000000] [] (sched_init+0x190/0x1ec) from [] (start_kernel+0x150/0x2fc) [ 0.000000] [] (start_kernel+0x150/0x2fc) from [<8000803c>] (0x8000803c) [ 0.000000] Code: e5931068 e5933064 e592e014 e592c010 (e7932001) [ 0.000000] ---[ end trace 1b75b31a2719ed1c ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] [] (unwind_backtrace+0x0/0xec) from [] (panic+0x6c/0x1a4) [ 0.000000] [] (panic+0x6c/0x1a4) from [] (do_exit+0x9c/0x6a0) [ 0.000000] [] (do_exit+0x9c/0x6a0) from [] (die+0x1b8/0x1e0) [ 0.000000] [] (die+0x1b8/0x1e0) from [] (__do_kernel_fault+0x64/0x84) [ 0.000000] [] (__do_kernel_fault+0x64/0x84) from [] (do_page_fault+0x2f0/0x314) [ 0.000000] [] (do_page_fault+0x2f0/0x314) from [] (do_DataAbort+0x34/0x94) [ 0.000000] [] (do_DataAbort+0x34/0x94) from [] (__dabt_svc+0x38/0x60) [ 0.000000] Exception stack(0xc030bf48 to 0xc030bf90) [ 0.000000] bf40: c030dd48 00000000 c032f910 00000000 400001d3 c030dd48 [ 0.000000] bf60: 389fd980 00000000 c032fcc0 c0311bf0 c0313030 c030bfac 00000000 c030bf90 [ 0.000000] bf80: 00000000 c001e034 400001d3 ffffffff [ 0.000000] [] (__dabt_svc+0x38/0x60) from [] (sched_clock+0x1c/0x64) [ 0.000000] [] (sched_clock+0x1c/0x64) from [] (init_idle+0x3c/0xa0) [ 0.000000] [] (init_idle+0x3c/0xa0) from [] (sched_init+0x190/0x1ec) [ 0.000000] [] (sched_init+0x190/0x1ec) from [] (start_kernel+0x150/0x2fc) [ 0.000000] [] (start_kernel+0x150/0x2fc) from [<8000803c>] (0x8000803c) Uncompressing Linux... done, booting the kernel. [ 0.000000] Linux version 3.1.0-00032-g5dc3d4f (murali at murali-laptop) (gcc version 4.3.3 (Sourcery G+ + Lite 2009q1-203) ) #6 PREEMPT Mon Dec 19 14:57:22 EST 2011 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c52c7b [ 0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache Murali Karicheri Software Design Engineer email: m-karicheri2 at ti.com Phone: (301) 407 9583 >> -----Original Message----- >> From: Nori, Sekhar >> Sent: Monday, December 19, 2011 2:15 PM >> To: Karicheri, Muralidharan >> Cc: davinci-linux-open-source at linux.davincidsp.com; Chemparathy, Cyril >> Subject: RE: Log time stamp wraps around to 25 >> >> Hi Murali, >> >> On Fri, Dec 16, 2011 at 04:50:54, Karicheri, Muralidharan wrote: >> > Sekhar, >> > >> > I made some searches on the internet. The schedule_clock() must return a >> monotonous clock. One way to do this is to use cnt32_to_63() to convert the >> 32bit clock count value to a 64bit value. I have tried this and it seems to >> work. I am just curious as to how this is working on other davinci platforms? >> So any response from you will be helpful. >> > >> >> I checked this on AM18x and the clock there wraps around in about >> 180 seconds which is consistent with your observation given that >> we have a 24 MHz timer clock there. >> >> I did a quick implementation of sched_clock using the common sched_clock >> infrastructure in arch/arm/kernel/sched_clock.c and that seemed to have >> fixed the issue in some limited testing. Attached is the patch, can you >> give it a shot? >> >> Thanks, >> Sekhar >> >> ----8<----- >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> index e084b7e..b5b630a 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -924,6 +924,7 @@ config ARCH_DAVINCI >> select ARCH_REQUIRE_GPIOLIB >> select ZONE_DMA >> select HAVE_IDE >> + select HAVE_SCHED_CLOCK >> select CLKDEV_LOOKUP >> select GENERIC_ALLOCATOR >> select GENERIC_IRQ_CHIP >> diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c >> index e1969ce..8396ba8 100644 >> --- a/arch/arm/mach-davinci/time.c >> +++ b/arch/arm/mach-davinci/time.c >> @@ -22,6 +22,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include "clock.h" >> @@ -292,12 +293,18 @@ static struct clocksource clocksource_davinci = { >> /* >> * Overwrite weak default sched_clock with something more precise >> */ >> +static DEFINE_CLOCK_DATA(cd); >> + >> unsigned long long notrace sched_clock(void) >> { >> - const cycle_t cyc = clocksource_davinci.read(&clocksource_davinci); >> + u32 cyc = clocksource_davinci.read(&clocksource_davinci); >> + return cyc_to_sched_clock(&cd, cyc, (u32)~0); >> +} >> >> - return clocksource_cyc2ns(cyc, clocksource_davinci.mult, >> - clocksource_davinci.shift); >> +static void notrace davinci_update_sched_clock(void) >> +{ >> + u32 cyc = clocksource_davinci.read(&clocksource_davinci); >> + update_sched_clock(&cd, cyc, (u32)~0); >> } >> >> /* >> @@ -399,6 +406,8 @@ static void __init davinci_timer_init(void) >> /* setup clocksource */ >> clocksource_davinci.read = read_cycles; >> clocksource_davinci.name = id_to_name[clocksource_id]; >> + init_sched_clock(&cd, davinci_update_sched_clock, 32, >> + davinci_clock_tick_rate); >> if (clocksource_register_hz(&clocksource_davinci, >> davinci_clock_tick_rate)) >> printk(err, clocksource_davinci.name); From m-karicheri2 at ti.com Tue Dec 20 13:13:26 2011 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Tue, 20 Dec 2011 19:13:26 +0000 Subject: Log time stamp wraps around to 25 In-Reply-To: <3E54258959B69E4282D79E01AB1F32B7249C8B@DFLE34.ent.ti.com> References: <3E54258959B69E4282D79E01AB1F32B72489F0@DFLE34.ent.ti.com> <3E54258959B69E4282D79E01AB1F32B7249C8B@DFLE34.ent.ti.com> Message-ID: <3E54258959B69E4282D79E01AB1F32B7249FD1@DFLE34.ent.ti.com> Sekhar, My patch also initialized the read in the structure with read function which caused the crash. I think the reason for the dummy is to allow early call of sched_clock(). I have tested your patch and it seems to work fine so far (2 hours of test). Could you push this to upstream? [ 6913.964051] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 6924.057637] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 6934.154051] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 6944.244104] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 6954.334119] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 INIT: Id "1" respawning too fast: disabled for 5 minutes [ 7265.037501] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7275.134251] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7285.224238] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7295.314279] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7305.404428] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7315.494298] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7325.588130] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7335.684288] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7345.774308] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7355.864308] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 INIT: Id "1" respawning too fast: disabled for 5 minutes [ 7667.566695] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7677.664666] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7687.754515] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7697.844583] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7707.934504] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7718.024714] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7728.118240] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7738.214555] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7748.304595] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7758.394574] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 INIT: Id "1" respawning too fast: disabled for 5 minutes Murali Karicheri Software Design Engineer email: m-karicheri2 at ti.com Phone: (301) 407 9583 >> -----Original Message----- >> From: davinci-linux-open-source-bounces at linux.davincidsp.com [mailto:davinci- >> linux-open-source-bounces at linux.davincidsp.com] On Behalf Of Karicheri, >> Muralidharan >> Sent: Tuesday, December 20, 2011 10:15 AM >> To: Nori, Sekhar >> Cc: davinci-linux-open-source at linux.davincidsp.com >> Subject: RE: Log time stamp wraps around to 25 >> >> Sekhar, >> >> I had implemented the same fix yesterday after discussion with Russell in the >> ARM mailing list. I got a crash in the sched_init() as given below. I am not >> sure why this is not happening on your platform. I haven't root caused the >> reason for this crash, but from Russell's email, it seems timer is to be >> initialized using early_init() of machine callback so that sched_init() will >> be able to call sched_clock early. I will debug the root cause of the crash, >> but what you think on moving timer initialization to early_init() machine >> callback? >> >> Murali >> >> [ 0.000000] Memory: 128MB = 128MB total >> [ 0.000000] Memory: 126552k/126552k available, 4520k reserved, 0K highmem >> [ 0.000000] Virtual kernel memory layout: >> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) >> [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) >> [ 0.000000] DMA : 0xff000000 - 0xffe00000 ( 14 MB) >> [ 0.000000] vmalloc : 0xc8800000 - 0xfe600000 ( 862 MB) >> [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) >> [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) >> [ 0.000000] .text : 0xc0008000 - 0xc02edf7c (2968 kB) >> [ 0.000000] .init : 0xc02ee000 - 0xc030a000 ( 112 kB) >> [ 0.000000] .data : 0xc030a000 - 0xc032f600 ( 150 kB) >> [ 0.000000] .bss : 0xc032f624 - 0xc03470d8 ( 95 kB) >> [ 0.000000] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, >> Nodes=1 >> [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual >> address 00000000 >> [ 0.000000] pgd = c0004000 >> [ 0.000000] [00000000] *pgd=00000000 >> [ 0.000000] Internal error: Oops: 5 [#1] PREEMPT >> [ 0.000000] Modules linked in: >> [ 0.000000] CPU: 0 Not tainted (3.1.0-00032-g5dc3d4f-dirty #4) >> [ 0.000000] PC is at sched_clock+0x1c/0x64 >> [ 0.000000] LR is at 0x0 >> [ 0.000000] pc : [] lr : [<00000000>] psr: 400001d3 >> [ 0.000000] sp : c030bf90 ip : 00000000 fp : c030bfac >> [ 0.000000] r10: c0313030 r9 : c0311bf0 r8 : c032fcc0 >> [ 0.000000] r7 : 00000000 r6 : 389fd980 r5 : c030dd48 r4 : 400001d3 >> [ 0.000000] r3 : 00000000 r2 : c032f910 r1 : 00000000 r0 : c030dd48 >> [ 0.000000] Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment >> kernel >> [ 0.000000] Control: 10c5287b Table: 80004019 DAC: 00000015 >> [ 0.000000] Process swapper (pid: 0, stack limit = 0xc030a2e8) >> [ 0.000000] Stack: (0xc030bf90 to 0xc030c000) >> [ 0.000000] bf80: 400001d3 c030dd48 >> 389fd980 c030385c >> [ 0.000000] bfa0: c030a000 00000000 c030bfd4 c02f49fc c030c160 c032f640 >> c030515c c0305158 >> [ 0.000000] bfc0: c030ed84 80004059 413fc082 00000000 00000000 c02ee650 >> c02ee2c0 00000000 >> [ 0.000000] bfe0: 00000000 c030515c 00000000 10c52c79 c030c040 8000803c >> 00000000 00000000 >> [ 0.000000] [] (sched_clock+0x1c/0x64) from [] >> (init_idle+0x3c/0xa0) >> [ 0.000000] [] (init_idle+0x3c/0xa0) from [] >> (sched_init+0x190/0x1ec) >> [ 0.000000] [] (sched_init+0x190/0x1ec) from [] >> (start_kernel+0x150/0x2fc) >> [ 0.000000] [] (start_kernel+0x150/0x2fc) from [<8000803c>] >> (0x8000803c) >> [ 0.000000] Code: e5931068 e5933064 e592e014 e592c010 (e7932001) >> [ 0.000000] ---[ end trace 1b75b31a2719ed1c ]--- >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! >> [ 0.000000] [] (unwind_backtrace+0x0/0xec) from [] >> (panic+0x6c/0x1a4) >> [ 0.000000] [] (panic+0x6c/0x1a4) from [] >> (do_exit+0x9c/0x6a0) >> [ 0.000000] [] (do_exit+0x9c/0x6a0) from [] >> (die+0x1b8/0x1e0) >> [ 0.000000] [] (die+0x1b8/0x1e0) from [] >> (__do_kernel_fault+0x64/0x84) >> [ 0.000000] [] (__do_kernel_fault+0x64/0x84) from [] >> (do_page_fault+0x2f0/0x314) >> [ 0.000000] [] (do_page_fault+0x2f0/0x314) from [] >> (do_DataAbort+0x34/0x94) >> [ 0.000000] [] (do_DataAbort+0x34/0x94) from [] >> (__dabt_svc+0x38/0x60) >> [ 0.000000] Exception stack(0xc030bf48 to 0xc030bf90) >> [ 0.000000] bf40: c030dd48 00000000 c032f910 00000000 >> 400001d3 c030dd48 >> [ 0.000000] bf60: 389fd980 00000000 c032fcc0 c0311bf0 c0313030 c030bfac >> 00000000 c030bf90 >> [ 0.000000] bf80: 00000000 c001e034 400001d3 ffffffff >> [ 0.000000] [] (__dabt_svc+0x38/0x60) from [] >> (sched_clock+0x1c/0x64) >> [ 0.000000] [] (sched_clock+0x1c/0x64) from [] >> (init_idle+0x3c/0xa0) >> [ 0.000000] [] (init_idle+0x3c/0xa0) from [] >> (sched_init+0x190/0x1ec) >> [ 0.000000] [] (sched_init+0x190/0x1ec) from [] >> (start_kernel+0x150/0x2fc) >> [ 0.000000] [] (start_kernel+0x150/0x2fc) from [<8000803c>] >> (0x8000803c) >> Uncompressing Linux... done, booting the kernel. >> [ 0.000000] Linux version 3.1.0-00032-g5dc3d4f (murali at murali-laptop) (gcc >> version 4.3.3 (Sourcery G+ >> + Lite 2009q1-203) ) #6 PREEMPT Mon Dec 19 14:57:22 EST 2011 >> [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c52c7b >> [ 0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction >> cache >> >> >> Murali Karicheri >> Software Design Engineer >> email: m-karicheri2 at ti.com >> Phone: (301) 407 9583 >> >> >> >> -----Original Message----- >> >> From: Nori, Sekhar >> >> Sent: Monday, December 19, 2011 2:15 PM >> >> To: Karicheri, Muralidharan >> >> Cc: davinci-linux-open-source at linux.davincidsp.com; Chemparathy, Cyril >> >> Subject: RE: Log time stamp wraps around to 25 >> >> >> >> Hi Murali, >> >> >> >> On Fri, Dec 16, 2011 at 04:50:54, Karicheri, Muralidharan wrote: >> >> > Sekhar, >> >> > >> >> > I made some searches on the internet. The schedule_clock() must return a >> >> monotonous clock. One way to do this is to use cnt32_to_63() to convert the >> >> 32bit clock count value to a 64bit value. I have tried this and it seems to >> >> work. I am just curious as to how this is working on other davinci >> platforms? >> >> So any response from you will be helpful. >> >> > >> >> >> >> I checked this on AM18x and the clock there wraps around in about >> >> 180 seconds which is consistent with your observation given that >> >> we have a 24 MHz timer clock there. >> >> >> >> I did a quick implementation of sched_clock using the common sched_clock >> >> infrastructure in arch/arm/kernel/sched_clock.c and that seemed to have >> >> fixed the issue in some limited testing. Attached is the patch, can you >> >> give it a shot? >> >> >> >> Thanks, >> >> Sekhar >> >> >> >> ----8<----- >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >> >> index e084b7e..b5b630a 100644 >> >> --- a/arch/arm/Kconfig >> >> +++ b/arch/arm/Kconfig >> >> @@ -924,6 +924,7 @@ config ARCH_DAVINCI >> >> select ARCH_REQUIRE_GPIOLIB >> >> select ZONE_DMA >> >> select HAVE_IDE >> >> + select HAVE_SCHED_CLOCK >> >> select CLKDEV_LOOKUP >> >> select GENERIC_ALLOCATOR >> >> select GENERIC_IRQ_CHIP >> >> diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c >> >> index e1969ce..8396ba8 100644 >> >> --- a/arch/arm/mach-davinci/time.c >> >> +++ b/arch/arm/mach-davinci/time.c >> >> @@ -22,6 +22,7 @@ >> >> #include >> >> #include >> >> #include >> >> +#include >> >> #include >> >> #include >> >> #include "clock.h" >> >> @@ -292,12 +293,18 @@ static struct clocksource clocksource_davinci = { >> >> /* >> >> * Overwrite weak default sched_clock with something more precise >> >> */ >> >> +static DEFINE_CLOCK_DATA(cd); >> >> + >> >> unsigned long long notrace sched_clock(void) >> >> { >> >> - const cycle_t cyc = clocksource_davinci.read(&clocksource_davinci); >> >> + u32 cyc = clocksource_davinci.read(&clocksource_davinci); >> >> + return cyc_to_sched_clock(&cd, cyc, (u32)~0); >> >> +} >> >> >> >> - return clocksource_cyc2ns(cyc, clocksource_davinci.mult, >> >> - clocksource_davinci.shift); >> >> +static void notrace davinci_update_sched_clock(void) >> >> +{ >> >> + u32 cyc = clocksource_davinci.read(&clocksource_davinci); >> >> + update_sched_clock(&cd, cyc, (u32)~0); >> >> } >> >> >> >> /* >> >> @@ -399,6 +406,8 @@ static void __init davinci_timer_init(void) >> >> /* setup clocksource */ >> >> clocksource_davinci.read = read_cycles; >> >> clocksource_davinci.name = id_to_name[clocksource_id]; >> >> + init_sched_clock(&cd, davinci_update_sched_clock, 32, >> >> + davinci_clock_tick_rate); >> >> if (clocksource_register_hz(&clocksource_davinci, >> >> davinci_clock_tick_rate)) >> >> printk(err, clocksource_davinci.name); >> >> _______________________________________________ >> 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 nsekhar at ti.com Tue Dec 20 13:15:47 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 20 Dec 2011 19:15:47 +0000 Subject: [PATCH v6 05/11] ARM: davinci: create new common platform header for davinci In-Reply-To: <1323951120-15876-6-git-send-email-manjunath.hadli@ti.com> References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> <1323951120-15876-6-git-send-email-manjunath.hadli@ti.com> Message-ID: Hi Manju, On Thu, Dec 15, 2011 at 17:41:54, Hadli, Manjunath wrote: > remove the code from individual platform header files for Not just the code, the files themselves are being removed. > dm365, dm355, dm644x and dm646x and consolidate it into a > single and common header file davinci.h. .. placed in arch/arm/mach-davinci/ > > This reduces the pollution in the include/mach and is consistent > with Russel's suggestions as part of his "pet peaves" mail. > > The further patches in the series take advantage of this consolidation > for easy implementation of IO_ADDRESS elimination. > > Signed-off-by: Manjunath Hadli > --- [...] > diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c > index 4e0e707..7ae0d15 100644 > --- a/arch/arm/mach-davinci/board-dm355-evm.c > +++ b/arch/arm/mach-davinci/board-dm355-evm.c > @@ -26,7 +26,7 @@ > #include > #include > > -#include > +#include "davinci.h" > #include Local headers should typically be the last ones included. Can you please revisit the header file inclusion order throughout this patch? The headers in linux/ need to be added first followed by asm/ mach/ and then the private headers. Also, like headers need to be grouped together using empty lines. You can look at arch/arm/mach-davinci/board-dm644x-evm.c as an example of how existing code looks. [...] > diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h > +/* DM355 function declarations */ > +struct spi_board_info; > + > +void __init dm355_init(void); > +void dm355_init_spi0(unsigned chipselect_mask, > + struct spi_board_info *info, unsigned len); > +void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); > +void dm355_set_vpfe_config(struct vpfe_config *cfg); > + > +/* DM365 function declarations */ > +void __init dm365_init(void); > +void __init dm365_init_asp(struct snd_platform_data *pdata); > +void __init dm365_init_vc(struct snd_platform_data *pdata); > +void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); > +void __init dm365_init_rtc(void); > +void dm365_init_spi0(unsigned chipselect_mask, > + struct spi_board_info *info, unsigned len); > + You can drop the empty line here... > +void dm365_set_vpfe_config(struct vpfe_config *cfg); > + > +/* DM644x function declarations */ > +void __init dm644x_init(void); > +void __init dm644x_init_asp(struct snd_platform_data *pdata); > +void dm644x_set_vpfe_config(struct vpfe_config *cfg); > + > +/* DM646x function declarations */ > +void __init dm646x_init(void); > +void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); > +void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); > +int __init dm646x_init_edma(struct edma_rsv_info *rsv); > + > +void dm646x_video_init(void); > + > +void dm646x_setup_vpif(struct vpif_display_config *, > + struct vpif_capture_config *); .. and these two as well. I have merged 2/11, 3/11 and 4/11 of this series into my master branch. Can you please respin 1/11 and 5/11 of this series based on my new master and with my comments fixed? Based on your patch 1/11, I guess you have grepped the driver sources to make sure none of them are including any of the files you are deleting. Want to double check. Thanks, Sekhar From nsekhar at ti.com Tue Dec 20 13:19:19 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Tue, 20 Dec 2011 19:19:19 +0000 Subject: Log time stamp wraps around to 25 In-Reply-To: <3E54258959B69E4282D79E01AB1F32B7249FD1@DFLE34.ent.ti.com> References: <3E54258959B69E4282D79E01AB1F32B72489F0@DFLE34.ent.ti.com> <3E54258959B69E4282D79E01AB1F32B7249C8B@DFLE34.ent.ti.com> <3E54258959B69E4282D79E01AB1F32B7249FD1@DFLE34.ent.ti.com> Message-ID: On Wed, Dec 21, 2011 at 00:43:26, Karicheri, Muralidharan wrote: > Sekhar, > > My patch also initialized the read in the structure with read function which caused the crash. I think the reason for the dummy is to allow early call of sched_clock(). I have tested your patch and it seems to work fine so far (2 hours of test). Could you push this to upstream? > Thanks Murali! I will take this as a "Tested-by:" Will spin a formal patch tomorrow. Regards, Sekhar From laurent.pinchart at ideasonboard.com Tue Dec 20 17:58:31 2011 From: laurent.pinchart at ideasonboard.com (Laurent Pinchart) Date: Wed, 21 Dec 2011 00:58:31 +0100 Subject: [PATCH 1/2] media: add new mediabus format enums for dm365 In-Reply-To: References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112151402.45100.laurent.pinchart@ideasonboard.com> Message-ID: <201112210058.33006.laurent.pinchart@ideasonboard.com> Hi Manju, On Friday 16 December 2011 15:20:24 Hadli, Manjunath wrote: > On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote: > > On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote: > > > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into > > > mbus_pixel_code to represent A-LAW compressed Bayer format. This > > > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8. > > > add UV8 and NV12 ( Y and C separate with UV interleaved) which are > > > supported on dm365. > > > > > > Signed-off-by: Manjunath Hadli > > > Cc: Laurent Pinchart > > > --- > > > > > > include/linux/v4l2-mediabus.h | 10 ++++++++-- > > > 1 files changed, 8 insertions(+), 2 deletions(-) > > > > Please also update the documentation in Documentation/DocBook/media/v4l. > > > > > diff --git a/include/linux/v4l2-mediabus.h > > > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644 > > > --- a/include/linux/v4l2-mediabus.h > > > +++ b/include/linux/v4l2-mediabus.h > > > @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode { > > > > > > V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, > > > V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, > > > > > > - /* YUV (including grey) - next is 0x2014 */ > > > + /* YUV (including grey) - next is 0x2016 */ > > > > > > V4L2_MBUS_FMT_Y8_1X8 = 0x2001, > > > V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, > > > V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, > > > > > > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode { > > > > > > V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012, > > > V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, > > > V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, > > > > > > + V4L2_MBUS_FMT_NV12_1X20 = 0x2014, > > > + V4L2_MBUS_FMT_UV8_1X8 = 0x2015, > > > > NV12, on the bus ? How does that work ? (The documentation should answer > > my question :-)) > > Well, this is on the internal bus not exposed outside, but nevertheless bus > between two subdevs or two independent hardware blocks. For example Resizer > supports NV12 on its pad. Is there any other way to treat this? How is NV12 transferred on the bus in that case ? Are all luma samples transferred first, followed by all chroma samples ? > > > - /* Bayer - next is 0x3015 */ > > > + /* Bayer - next is 0x3019 */ > > > > > > V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, > > > V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013, > > > V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, > > > > > > @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode { > > > > > > V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010, > > > V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011, > > > V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012, > > > > > > + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015, > > > + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016, > > > + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017, > > > + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018, > > > > Please keep the names sorted as described in the comment at the beginning > > of the file. > > > > > /* JPEG compressed formats - next is 0x4002 */ > > > V4L2_MBUS_FMT_JPEG_1X8 = 0x4001, -- Regards, Laurent Pinchart From laurent.pinchart at ideasonboard.com Tue Dec 20 18:02:08 2011 From: laurent.pinchart at ideasonboard.com (Laurent Pinchart) Date: Wed, 21 Dec 2011 01:02:08 +0100 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112151400.48321.laurent.pinchart@ideasonboard.com> Message-ID: <201112210102.09117.laurent.pinchart@ideasonboard.com> Hi Manju, On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote: > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format > > > frames compressed by A-LAW alogorithm. > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only. > > > > > > Signed-off-by: Manjunath Hadli > > > Cc: Laurent Pinchart > > > --- > > > > > > include/linux/videodev2.h | 6 ++++++ > > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > Could you please also document these formats in > > Documentation/DocBook/media/v4l ? > > I will. Sorry to have missed that out. > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > > > index 4b752d5..969112d 100644 > > > --- a/include/linux/videodev2.h > > > +++ b/include/linux/videodev2.h > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > > > > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') /* 8 > > > YUV > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv > > > interleaved */ > > > > > > +/* Chrominance formats */ > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 > > > UV 4:4 */ + > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */ > > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 > > > Y/CbCr > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') > > > /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct v4l2_pix_format { > > > #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 > > > RGRG.. GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */ > > > #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > > + > > > > That's not very future-proof, how would you describe SGBRG10ALAW8 for > > instance ? > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We have 4 > > characters, we could start with 'B' to denote Bayer, followed by one > > character for the order, one for the compression, and one for the number > > of bits. > > I agree. > May be ('B', 'G', 'A', '8') is fine for the above? We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B', 'g', 'G' and 'R' respectively for the second character. The third character would be 'A' for A-law and 'D' for DPCM, and the fourth character could describe the bus width in bits from 0 to 15 with '0' - '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses for raw Bayer at some point, and a 0 width is definitely not useful. We could thus offset the width by some value. This is just a preliminary idea, I'm open to suggestions. > > > /* > > > > > > * 10bit raw bayer, expanded to 16 bits > > > * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb... -- Regards, Laurent Pinchart From prakash.pm at ti.com Tue Dec 20 23:52:13 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Wed, 21 Dec 2011 05:52:13 +0000 Subject: [PATCH] davinci: DA850 EVM: OHCI platform code In-Reply-To: <4EF06C64.8000708@mvista.com> References: <1324363005-11320-1-git-send-email-prakash.pm@ti.com> <4EF06C64.8000708@mvista.com> Message-ID: Hi Sergei, On Tue, Dec 20, 2011 at 16:37:16, Sergei Shtylyov wrote: > Hello. > > On 20.12.2011 10:36, Manjunathappa, Prakash wrote: > > > From: Ajay Kumar Gupta > > It's a good practice to CC the original author of the patch -- which I'm > doing now... > I did put author and maintainers in CC, my git send-email log shows it up as below. But I don't know why it doesnot appear when mails reach my inbox. Can you please let me know if I am missing any configuration?: prakash at linux-psp-server:~/project/linux/linux_torvalds$ git send-email --smtp-server=192.168.247.13 --cc=nsekhar at ti.com --cc=linux-kernel at vger.kernel.org --cc=linux-arm-kernel at lists.infradead.org --cc=linux at arm.linux.org.uk 0001-davinci-DA850-EVM-OHCI-platform-code.patch 0001-davinci-DA850-EVM-OHCI-platform-code.patch Who should the emails appear to be from? [Manjunathappa, Prakash ] Emails will be sent from: Manjunathappa, Prakash Who should the emails be sent to? davinci-linux-open-source at linux.davincidsp.com Message-ID to be used as In-Reply-To for the first email? (mbox) Adding cc: Ajay Kumar Gupta from line 'From: Ajay Kumar Gupta ' (body) Adding cc: Ajay Kumar Gupta from line 'Signed-off-by: Ajay Kumar Gupta ' From: "Manjunathappa, Prakash" To: davinci-linux-open-source at linux.davincidsp.com Cc: nsekhar at ti.com, linux-kernel at vger.kernel.org, linux-arm-kernel at lists.infradead.org, linux at arm.linux.org.uk, Ajay Kumar Gupta Subject: [PATCH] davinci: DA850 EVM: OHCI platform code Date: Wed, 21 Dec 2011 11:05:38 +0530 Message-Id: <1324445738-7203-1-git-send-email-prakash.pm at ti.com> X-Mailer: git-send-email 1.7.1 The Cc list above has been expanded by additional addresses found in the patch commit message. By default send-email prompts before sending whenever this occurs. This behavior is controlled by the sendemail.confirm configuration setting. For additional information, run 'git send-email --help'. To retain the current behavior, but squelch this message, run 'git config --global sendemail.confirm auto'. Send this email? ([y]es|[n]o|[q]uit|[a]ll): > > On this board the OHCI port's power control and over-current signals from > > TPS2065 power switch are connected via GPIO1[15] and GPIO2[1] respectively, > > Ajay, your description seems to be copied unchganged from the analogous > DA830 EVM patch, and thus doesn't match your patch: GPIO2[4] and GPIO6[13] are > used apparently. Be more attentive to detail next time please. > I will fix this. > > so we can implement the DA8xx OHCI glue layer's hooks for overriding the > > root hub port's power and over-current status bits. > > > We also have to properly set up the clocking mode in the CFGCHIP2 register, > > so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and > > its output is used to clock the USB 1.1 (OHCI) PHY... > > > Signed-off-by: Ajay Kumar Gupta > > --- > > arch/arm/mach-davinci/board-da850-evm.c | 126 +++++++++++++++++++++++++++++++ > > 1 files changed, 126 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c > > index 6659a90..df74ba5 100644 > > --- a/arch/arm/mach-davinci/board-da850-evm.c > > +++ b/arch/arm/mach-davinci/board-da850-evm.c > [...] > > @@ -734,6 +736,127 @@ static struct davinci_i2c_platform_data da850_evm_i2c_0_pdata = { > [...] > > +static int da850_evm_usb_ocic_notify(da8xx_ocic_handler_t handler) > > +{ > > + int irq = gpio_to_irq(ON_BD_USB_OVC); > > + int error = 0; > > + > > + if (handler != NULL) { > > + da850_evm_usb_ocic_handler = handler; > > + > > + error = request_irq(irq, da850_evm_usb_ocic_irq, IRQF_DISABLED | > > IRQF_DISABLED is a nop now -- just remove it. > Agreed, I will remove it. Thanks, Prakash > WBR, Sergei > From prakash.pm at ti.com Tue Dec 20 23:56:24 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Wed, 21 Dec 2011 05:56:24 +0000 Subject: [PATCH] davinci: DA850 EVM: OHCI platform code In-Reply-To: <4EF06EC2.3070907@mvista.com> References: <1324363005-11320-1-git-send-email-prakash.pm@ti.com> <4EF06EC2.3070907@mvista.com> Message-ID: Hi Sergei, On Tue, Dec 20, 2011 at 16:47:22, Sergei Shtylyov wrote: > Hello. > > On 20-12-2011 10:36, Manjunathappa, Prakash wrote: > > > From: Ajay Kumar Gupta > > > On this board the OHCI port's power control and over-current signals from > > TPS2065 power switch are connected via GPIO1[15] and GPIO2[1] respectively, > > so we can implement the DA8xx OHCI glue layer's hooks for overriding the > > root hub port's power and over-current status bits. > > > We also have to properly set up the clocking mode in the CFGCHIP2 register, > > so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and > > its output is used to clock the USB 1.1 (OHCI) PHY... > > > Signed-off-by: Ajay Kumar Gupta > > BTW, Prakash, as you'r on the patch's disrtibution path, shouldn't you add > your signoff as well? > Yes, I will make it point to keep my signoff as well while distributing. > > --- > > arch/arm/mach-davinci/board-da850-evm.c | 126 +++++++++++++++++++++++++++++++ > > 1 files changed, 126 insertions(+), 0 deletions(-) > > > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c > > index 6659a90..df74ba5 100644 > > --- a/arch/arm/mach-davinci/board-da850-evm.c > > +++ b/arch/arm/mach-davinci/board-da850-evm.c > [...] > > +static __init void da850_evm_usb_init(void) > > +{ > [...] > > + ret = gpio_request(ON_BD_USB_DRV, "ON_BD_USB_DRV"); > > + if (ret) { > > + printk(KERN_ERR "%s: failed to request GPIO for USB 1.1 port " > > + "power control: %d\n", __func__, ret); > > + return; > > + } > > + gpio_direction_output(ON_BD_USB_DRV, 0); > > You should also use gpio_request_one() instead > gpio_request()/gpio_direction_output() pair. > Agreed, I will use gpio_request_one(). > > + > > + ret = gpio_request(ON_BD_USB_OVC, "ON_BD_USB_OVC"); > > + if (ret) { > > + printk(KERN_ERR "%s: failed to request GPIO for USB 1.1 port " > > + "over-current indicator: %d\n", __func__, ret); > > + return; > > + } > > + gpio_direction_input(ON_BD_USB_OVC); > > Same here. > Agreed. Thanks, Prakash > WBR, Sergei > From prakash.pm at ti.com Wed Dec 21 01:20:02 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Wed, 21 Dec 2011 12:50:02 +0530 Subject: [PATCH v2] davinci: DA850 EVM: OHCI platform code Message-ID: <1324452002-8388-1-git-send-email-prakash.pm@ti.com> From: Ajay Kumar Gupta On this board the OHCI port's power control and over-current signals from TPS2065 power switch are connected via GPIO2[4] and GPIO6[13] respectively, so we can implement the DA8xx OHCI glue layer's hooks for overriding the root hub port's power and over-current status bits. We also have to properly set up the clocking mode in the CFGCHIP2 register, so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and its output is used to clock the USB 1.1 (OHCI) PHY... Signed-off-by: Ajay Kumar Gupta Signed-off-by: Manjunathappa, Prakash --- Since v1: Fixed Sergei's review comments. arch/arm/mach-davinci/board-da850-evm.c | 125 +++++++++++++++++++++++++++++++ 1 files changed, 125 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 6659a90..c505992 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include #include @@ -42,6 +43,7 @@ #include #include #include +#include #include #define DA850_EVM_PHY_ID "0:00" @@ -734,6 +736,126 @@ static struct davinci_i2c_platform_data da850_evm_i2c_0_pdata = { .bus_delay = 0, /* usec */ }; +/* + * USB1 VBUS is controlled by GPIO2[4], over-current is reported on GPIO6[13]. + */ +#define ON_BD_USB_DRV GPIO_TO_PIN(2, 4) +#define ON_BD_USB_OVC GPIO_TO_PIN(6, 13) + +static const short da850_evm_usb11_pins[] = { + DA850_GPIO2_4, DA850_GPIO6_13, + -1 +}; + +static da8xx_ocic_handler_t da850_evm_usb_ocic_handler; + +static int da850_evm_usb_set_power(unsigned port, int on) +{ + gpio_set_value(ON_BD_USB_DRV, on); + return 0; +} + +static int da850_evm_usb_get_power(unsigned port) +{ + return gpio_get_value(ON_BD_USB_DRV); +} + +static int da850_evm_usb_get_oci(unsigned port) +{ + return !gpio_get_value(ON_BD_USB_OVC); +} + +static irqreturn_t da850_evm_usb_ocic_irq(int, void *); + +static int da850_evm_usb_ocic_notify(da8xx_ocic_handler_t handler) +{ + int irq = gpio_to_irq(ON_BD_USB_OVC); + int error = 0; + + if (handler != NULL) { + da850_evm_usb_ocic_handler = handler; + + error = request_irq(irq, da850_evm_usb_ocic_irq, + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, + "OHCI over-current indicator", NULL); + if (error) + printk(KERN_ERR "%s: could not request IRQ to watch " + "over-current indicator changes\n", __func__); + } else + free_irq(irq, NULL); + + return error; +} + +static struct da8xx_ohci_root_hub da850_evm_usb11_pdata = { + .set_power = da850_evm_usb_set_power, + .get_power = da850_evm_usb_get_power, + .get_oci = da850_evm_usb_get_oci, + .ocic_notify = da850_evm_usb_ocic_notify, + + /* TPS2065 switch @ 5V */ + .potpgt = (3 + 1) / 2, /* 3 ms max */ +}; + +static irqreturn_t da850_evm_usb_ocic_irq(int irq, void *dev_id) +{ + da850_evm_usb_ocic_handler(&da850_evm_usb11_pdata, 1); + return IRQ_HANDLED; +} + +static __init void da850_evm_usb_init(void) +{ + u32 cfgchip2; + int ret; + + /* + * Set up USB clock/mode in the CFGCHIP2 register. + * FYI: CFGCHIP2 is 0x0000ef00 initially. + */ + cfgchip2 = __raw_readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)); + + /* USB2.0 PHY reference clock is 24 MHz */ + cfgchip2 &= ~CFGCHIP2_REFFREQ; + cfgchip2 |= CFGCHIP2_REFFREQ_24MHZ; + + /* + * Select internal reference clock for USB 2.0 PHY + * and use it as a clock source for USB 1.1 PHY + * (this is the default setting anyway). + */ + cfgchip2 &= ~CFGCHIP2_USB1PHYCLKMUX; + cfgchip2 |= CFGCHIP2_USB2PHYCLKMUX; + + __raw_writel(cfgchip2, DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)); + + ret = davinci_cfg_reg_list(da850_evm_usb11_pins); + if (ret) { + pr_warning("%s: USB 1.1 PinMux setup failed: %d\n", + __func__, ret); + return; + } + + ret = gpio_request_one(ON_BD_USB_DRV, GPIOF_OUT_INIT_LOW, + "ON_BD_USB_DRV"); + if (ret) { + pr_err("%s: failed to request GPIO for USB 1.1 port " + "power control: %d\n", __func__, ret); + return; + } + + ret = gpio_request_one(ON_BD_USB_OVC, GPIOF_IN, "ON_BD_USB_OVC"); + if (ret) { + pr_err("%s: failed to request GPIO for USB 1.1 port " + "over-current indicator: %d\n", __func__, ret); + return; + } + + ret = da8xx_register_usb11(&da850_evm_usb11_pdata); + if (ret) + pr_warning("%s: USB 1.1 registration failed: %d\n", + __func__, ret); +} + static struct davinci_uart_config da850_evm_uart_config __initdata = { .enabled_uarts = 0x7, }; @@ -1386,6 +1508,9 @@ static __init void da850_evm_init(void) ret); da850_evm_setup_mac_addr(); + + /* initilaize usb module */ + da850_evm_usb_init(); } #ifdef CONFIG_SERIAL_8250_CONSOLE -- 1.7.1 From manjunath.hadli at ti.com Wed Dec 21 01:29:31 2011 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Wed, 21 Dec 2011 07:29:31 +0000 Subject: [PATCH v6 05/11] ARM: davinci: create new common platform header for davinci In-Reply-To: References: <1323951120-15876-1-git-send-email-manjunath.hadli@ti.com> <1323951120-15876-6-git-send-email-manjunath.hadli@ti.com> Message-ID: Sekhar, On Wed, Dec 21, 2011 at 00:45:47, Nori, Sekhar wrote: > Hi Manju, > > On Thu, Dec 15, 2011 at 17:41:54, Hadli, Manjunath wrote: > > remove the code from individual platform header files for > > Not just the code, the files themselves are being removed. > > > dm365, dm355, dm644x and dm646x and consolidate it into a single and > > common header file davinci.h. > > .. placed in arch/arm/mach-davinci/ > > > > > This reduces the pollution in the include/mach and is consistent with > > Russel's suggestions as part of his "pet peaves" mail. > > > > The further patches in the series take advantage of this > > consolidation for easy implementation of IO_ADDRESS elimination. > > > > Signed-off-by: Manjunath Hadli > > --- > > [...] > > > diff --git a/arch/arm/mach-davinci/board-dm355-evm.c > > b/arch/arm/mach-davinci/board-dm355-evm.c > > index 4e0e707..7ae0d15 100644 > > --- a/arch/arm/mach-davinci/board-dm355-evm.c > > +++ b/arch/arm/mach-davinci/board-dm355-evm.c > > @@ -26,7 +26,7 @@ > > #include > > #include > > > > -#include > > +#include "davinci.h" > > #include > > Local headers should typically be the last ones included. Can you please revisit the header file inclusion order throughout this patch? The headers in linux/ need to be added first followed by asm/ mach/ and then the private headers. > > Also, like headers need to be grouped together using empty lines. You can look at arch/arm/mach-davinci/board-dm644x-evm.c > as an example of how existing code looks. > > [...] > > > diff --git a/arch/arm/mach-davinci/davinci.h > > b/arch/arm/mach-davinci/davinci.h > > > +/* DM355 function declarations */ > > +struct spi_board_info; > > + > > +void __init dm355_init(void); > > +void dm355_init_spi0(unsigned chipselect_mask, > > + struct spi_board_info *info, unsigned len); void __init > > +dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); > > +void dm355_set_vpfe_config(struct vpfe_config *cfg); > > + > > +/* DM365 function declarations */ > > +void __init dm365_init(void); > > +void __init dm365_init_asp(struct snd_platform_data *pdata); void > > +__init dm365_init_vc(struct snd_platform_data *pdata); void __init > > +dm365_init_ks(struct davinci_ks_platform_data *pdata); void __init > > +dm365_init_rtc(void); void dm365_init_spi0(unsigned chipselect_mask, > > + struct spi_board_info *info, unsigned len); > > + > > You can drop the empty line here... > > > +void dm365_set_vpfe_config(struct vpfe_config *cfg); > > + > > +/* DM644x function declarations */ > > +void __init dm644x_init(void); > > +void __init dm644x_init_asp(struct snd_platform_data *pdata); void > > +dm644x_set_vpfe_config(struct vpfe_config *cfg); > > + > > +/* DM646x function declarations */ > > +void __init dm646x_init(void); > > +void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); void > > +__init dm646x_init_mcasp1(struct snd_platform_data *pdata); int > > +__init dm646x_init_edma(struct edma_rsv_info *rsv); > > + > > +void dm646x_video_init(void); > > + > > +void dm646x_setup_vpif(struct vpif_display_config *, > > + struct vpif_capture_config *); > > .. and these two as well. > > I have merged 2/11, 3/11 and 4/11 of this series into my master branch. Can you please respin 1/11 and 5/11 of this series based on my new master and with my comments fixed? I will. Can you send me the link for your new master? > > Based on your patch 1/11, I guess you have grepped the driver sources to make sure none of them are including any of the files you are deleting. Want to double check. There was another file-sound codec with the inclusion of the header which was not needed. I have deleted the inclusion from that file. Will send across that patch also. > > Thanks, > Sekhar > > Thx, -Manju From prakash.pm at ti.com Wed Dec 21 01:27:40 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Wed, 21 Dec 2011 12:57:40 +0530 Subject: [PATCH] video: da8xx-fb: reset LCDC only if functional clock changes with DVFS Message-ID: <1324452460-10646-1-git-send-email-prakash.pm@ti.com> LCDC functional clock may or may not be derived from CPU/MPU DPLL, For example, AM335x => Separate independent DPLL for LCDC Davinci => Same DPLL as MPU So, on platforms where LCDC functional clock is not derived from CPU/MPU PLL it is not required to reset LCDC module, if CPU frequency does not change with DVFS. This patch adds check to do reset only if functional clock changes between pre and post notifier callbacks with DVFS. Signed-off-by: Manjunathappa, Prakash --- drivers/video/da8xx-fb.c | 13 ++++++++----- 1 files changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 29577bf..1334a68 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -161,6 +161,7 @@ struct da8xx_fb_par { int vsync_timeout; #ifdef CONFIG_CPU_FREQ struct notifier_block freq_transition; + unsigned int lcd_fck_rate; #endif void (*panel_power_ctrl)(int); }; @@ -840,11 +841,12 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb, struct da8xx_fb_par *par; par = container_of(nb, struct da8xx_fb_par, freq_transition); - if (val == CPUFREQ_PRECHANGE) { - lcd_disable_raster(); - } else if (val == CPUFREQ_POSTCHANGE) { - lcd_calc_clk_divider(par); - lcd_enable_raster(); + if (val == CPUFREQ_POSTCHANGE) { + if (par->lcd_fck_rate != clk_get_rate(par->lcdc_clk)) { + lcd_disable_raster(); + lcd_calc_clk_divider(par); + lcd_enable_raster(); + } } return 0; @@ -1137,6 +1139,7 @@ static int __devinit fb_probe(struct platform_device *device) par = da8xx_fb_info->par; par->lcdc_clk = fb_clk; + par->lcd_fck_rate = clk_get_rate(fb_clk); par->pxl_clk = lcdc_info->pxl_clk; if (fb_pdata->panel_power_ctrl) { par->panel_power_ctrl = fb_pdata->panel_power_ctrl; -- 1.7.1 From nsekhar at ti.com Wed Dec 21 03:56:55 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Wed, 21 Dec 2011 09:56:55 +0000 Subject: [PATCH v2] davinci: DA850 EVM: OHCI platform code In-Reply-To: <1324452002-8388-1-git-send-email-prakash.pm@ti.com> References: <1324452002-8388-1-git-send-email-prakash.pm@ti.com> Message-ID: Hi Prakash, On Wed, Dec 21, 2011 at 12:50:02, Manjunathappa, Prakash wrote: > From: Ajay Kumar Gupta > > On this board the OHCI port's power control and over-current signals from > TPS2065 power switch are connected via GPIO2[4] and GPIO6[13] respectively, > so we can implement the DA8xx OHCI glue layer's hooks for overriding the > root hub port's power and over-current status bits. > > We also have to properly set up the clocking mode in the CFGCHIP2 register, > so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and > its output is used to clock the USB 1.1 (OHCI) PHY... > > Signed-off-by: Ajay Kumar Gupta > Signed-off-by: Manjunathappa, Prakash This is the third copy of OHCI platform setup code which is almost the same except for the GPIO numbers. Can we attempt to consolidate the GPIO case under drivers/usb/host/ohci-da8xx.c glue layer itself? Of course, here should be a provision for non-GPIO based implementation as well. Sergei, any thoughts, comments? Thanks, Sekhar From sriram.madhvapathi at gmail.com Wed Dec 21 04:47:01 2011 From: sriram.madhvapathi at gmail.com (Madhvapathi Sriram) Date: Wed, 21 Dec 2011 16:17:01 +0530 Subject: [PATCH] video: da8xx-fb: reset LCDC only if functional clock changes with DVFS In-Reply-To: <1324452460-10646-1-git-send-email-prakash.pm@ti.com> References: <1324452460-10646-1-git-send-email-prakash.pm@ti.com> Message-ID: Prakash, On Wed, Dec 21, 2011 at 12:57 PM, Manjunathappa, Prakash wrote: > > LCDC functional clock may or may not be derived from CPU/MPU DPLL, > For example, > AM335x => Separate independent DPLL for LCDC > Davinci => Same DPLL as MPU > > So, on platforms where LCDC functional clock is not derived from CPU/MPU > PLL it is not required to reset LCDC module, if CPU frequency does not > change with DVFS. Is it not the case that the CPU frequency always changes during DVFS? This sentence does not strike me straight. Did you mean that if the frequency of the PLL (from which LCDC derives) does not change with DVFS, then LCDC module is not required to be reset? > > This patch adds check to do reset only if functional clock changes > between pre and post notifier callbacks with DVFS. > > Signed-off-by: Manjunathappa, Prakash > --- > ?drivers/video/da8xx-fb.c | ? 13 ++++++++----- > ?1 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c > index 29577bf..1334a68 100644 > --- a/drivers/video/da8xx-fb.c > +++ b/drivers/video/da8xx-fb.c > @@ -161,6 +161,7 @@ struct da8xx_fb_par { > ? ? ? ?int ? ? ? ? ? ? ? ? ? ? vsync_timeout; > ?#ifdef CONFIG_CPU_FREQ > ? ? ? ?struct notifier_block ? freq_transition; > + ? ? ? unsigned int ? ? ? ? ? ?lcd_fck_rate; > ?#endif > ? ? ? ?void (*panel_power_ctrl)(int); > ?}; > @@ -840,11 +841,12 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb, > ? ? ? ?struct da8xx_fb_par *par; > > ? ? ? ?par = container_of(nb, struct da8xx_fb_par, freq_transition); > - ? ? ? if (val == CPUFREQ_PRECHANGE) { > - ? ? ? ? ? ? ? lcd_disable_raster(); > - ? ? ? } else if (val == CPUFREQ_POSTCHANGE) { > - ? ? ? ? ? ? ? lcd_calc_clk_divider(par); > - ? ? ? ? ? ? ? lcd_enable_raster(); > + ? ? ? if (val == CPUFREQ_POSTCHANGE) { > + ? ? ? ? ? ? ? if (par->lcd_fck_rate != clk_get_rate(par->lcdc_clk)) { > + ? ? ? ? ? ? ? ? ? ? ? lcd_disable_raster(); > + ? ? ? ? ? ? ? ? ? ? ? lcd_calc_clk_divider(par); > + ? ? ? ? ? ? ? ? ? ? ? lcd_enable_raster(); > + ? ? ? ? ? ? ? } > ? ? ? ?} > > ? ? ? ?return 0; > @@ -1137,6 +1139,7 @@ static int __devinit fb_probe(struct platform_device *device) > > ? ? ? ?par = da8xx_fb_info->par; > ? ? ? ?par->lcdc_clk = fb_clk; > + ? ? ? par->lcd_fck_rate = clk_get_rate(fb_clk); > ? ? ? ?par->pxl_clk = lcdc_info->pxl_clk; > ? ? ? ?if (fb_pdata->panel_power_ctrl) { > ? ? ? ? ? ? ? ?par->panel_power_ctrl = fb_pdata->panel_power_ctrl; > -- > 1.7.1 > > _______________________________________________ > 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 prakash.pm at ti.com Wed Dec 21 05:11:57 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Wed, 21 Dec 2011 11:11:57 +0000 Subject: [PATCH] video: da8xx-fb: reset LCDC only if functional clock changes with DVFS In-Reply-To: References: <1324452460-10646-1-git-send-email-prakash.pm@ti.com> Message-ID: Hi Sriram, On Wed, Dec 21, 2011 at 16:17:01, Madhvapathi Sriram wrote: > Prakash, > > On Wed, Dec 21, 2011 at 12:57 PM, Manjunathappa, Prakash > wrote: > > > > LCDC functional clock may or may not be derived from CPU/MPU DPLL, > > For example, > > AM335x => Separate independent DPLL for LCDC > > Davinci => Same DPLL as MPU > > > > So, on platforms where LCDC functional clock is not derived from CPU/MPU > > PLL it is not required to reset LCDC module, if CPU frequency does not > > change with DVFS. > Is it not the case that the CPU frequency always changes during DVFS? > This sentence does not strike me straight. > Did you mean that if the frequency of the PLL (from which LCDC > derives) does not change with DVFS, then LCDC module is not required > to be reset? Ok I will re-phrase it as below: So, on platforms where LCDC functional clock is not derived from CPU/MPU PLL it is not required to reset LCDC module as its functional clock does not change with DVFS. > > > > This patch adds check to do reset only if functional clock changes > > between pre and post notifier callbacks with DVFS. > > > > Signed-off-by: Manjunathappa, Prakash > > --- > > ?drivers/video/da8xx-fb.c | ? 13 ++++++++----- > > ?1 files changed, 8 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c > > index 29577bf..1334a68 100644 > > --- a/drivers/video/da8xx-fb.c > > +++ b/drivers/video/da8xx-fb.c > > @@ -161,6 +161,7 @@ struct da8xx_fb_par { > > ? ? ? ?int ? ? ? ? ? ? ? ? ? ? vsync_timeout; > > ?#ifdef CONFIG_CPU_FREQ > > ? ? ? ?struct notifier_block ? freq_transition; > > + ? ? ? unsigned int ? ? ? ? ? ?lcd_fck_rate; > > ?#endif > > ? ? ? ?void (*panel_power_ctrl)(int); > > ?}; > > @@ -840,11 +841,12 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb, > > ? ? ? ?struct da8xx_fb_par *par; > > > > ? ? ? ?par = container_of(nb, struct da8xx_fb_par, freq_transition); > > - ? ? ? if (val == CPUFREQ_PRECHANGE) { > > - ? ? ? ? ? ? ? lcd_disable_raster(); > > - ? ? ? } else if (val == CPUFREQ_POSTCHANGE) { > > - ? ? ? ? ? ? ? lcd_calc_clk_divider(par); > > - ? ? ? ? ? ? ? lcd_enable_raster(); > > + ? ? ? if (val == CPUFREQ_POSTCHANGE) { > > + ? ? ? ? ? ? ? if (par->lcd_fck_rate != clk_get_rate(par->lcdc_clk)) { > > + ? ? ? ? ? ? ? ? ? ? ? lcd_disable_raster(); > > + ? ? ? ? ? ? ? ? ? ? ? lcd_calc_clk_divider(par); > > + ? ? ? ? ? ? ? ? ? ? ? lcd_enable_raster(); > > + ? ? ? ? ? ? ? } > > ? ? ? ?} > > > > ? ? ? ?return 0; > > @@ -1137,6 +1139,7 @@ static int __devinit fb_probe(struct platform_device *device) > > > > ? ? ? ?par = da8xx_fb_info->par; > > ? ? ? ?par->lcdc_clk = fb_clk; > > + ? ? ? par->lcd_fck_rate = clk_get_rate(fb_clk); > > ? ? ? ?par->pxl_clk = lcdc_info->pxl_clk; > > ? ? ? ?if (fb_pdata->panel_power_ctrl) { > > ? ? ? ? ? ? ? ?par->panel_power_ctrl = fb_pdata->panel_power_ctrl; > > -- > > 1.7.1 > > > > _______________________________________________ > > 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 sshtylyov at mvista.com Wed Dec 21 06:05:30 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Wed, 21 Dec 2011 16:05:30 +0400 Subject: [PATCH v2] davinci: DA850 EVM: OHCI platform code In-Reply-To: References: <1324452002-8388-1-git-send-email-prakash.pm@ti.com> Message-ID: <4EF1CB8A.10309@mvista.com> Hello. On 21-12-2011 13:56, Nori, Sekhar wrote: > On Wed, Dec 21, 2011 at 12:50:02, Manjunathappa, Prakash wrote: >> From: Ajay Kumar Gupta >> On this board the OHCI port's power control and over-current signals from >> TPS2065 power switch are connected via GPIO2[4] and GPIO6[13] respectively, >> so we can implement the DA8xx OHCI glue layer's hooks for overriding the >> root hub port's power and over-current status bits. >> We also have to properly set up the clocking mode in the CFGCHIP2 register, >> so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and >> its output is used to clock the USB 1.1 (OHCI) PHY... >> Signed-off-by: Ajay Kumar Gupta >> Signed-off-by: Manjunathappa, Prakash > This is the third copy of OHCI platform setup code which is almost > the same except for the GPIO numbers. Well, in my counting, it's only second, DA830 EVM being the first one. What's the third? > Can we attempt to consolidate > the GPIO case under drivers/usb/host/ohci-da8xx.c glue layer itself? > Of course, here should be a provision for non-GPIO based implementation > as well. > Sergei, any thoughts, comments? I designed the hub interface to be as abstract as I could, and now you're proposing to add GPIO to it? No, I have no clear idea how to keeep it abstract and add GPIO support at the same time. I would have been grateful to TI if I didn't have to invent this at all and they stop saving on OHCI pins. > Thanks, > Sekhar WBR, Sergei From sshtylyov at mvista.com Wed Dec 21 06:24:49 2011 From: sshtylyov at mvista.com (Sergei Shtylyov) Date: Wed, 21 Dec 2011 16:24:49 +0400 Subject: [PATCH v2] davinci: DA850 EVM: OHCI platform code In-Reply-To: <4EF1CB8A.10309@mvista.com> References: <1324452002-8388-1-git-send-email-prakash.pm@ti.com> <4EF1CB8A.10309@mvista.com> Message-ID: <4EF1D011.8060103@mvista.com> Hello. On 21-12-2011 16:05, I wrote: >> On Wed, Dec 21, 2011 at 12:50:02, Manjunathappa, Prakash wrote: >>> From: Ajay Kumar Gupta >>> On this board the OHCI port's power control and over-current signals from >>> TPS2065 power switch are connected via GPIO2[4] and GPIO6[13] respectively, >>> so we can implement the DA8xx OHCI glue layer's hooks for overriding the >>> root hub port's power and over-current status bits. >>> We also have to properly set up the clocking mode in the CFGCHIP2 register, >>> so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and >>> its output is used to clock the USB 1.1 (OHCI) PHY... >>> Signed-off-by: Ajay Kumar Gupta >>> Signed-off-by: Manjunathappa, Prakash >> This is the third copy of OHCI platform setup code which is almost >> the same except for the GPIO numbers. > Well, in my counting, it's only second, DA830 EVM being the first one. > What's the third? Ah, I missed Hawkboard... :-) > I designed the hub interface to be as abstract as I could, and now you're > proposing to add GPIO to it? No, I have no clear idea how to keeep it > abstract and add GPIO support at the same time. I would have been grateful to > TI if I didn't have to invent this at all and they stop saving on OHCI pins. Well, I have one idea. We can create a separate module in arch/arm/mach-davinci/, named say ohci.c, put the shared code there and pass to it the GPIOs actually used via a function call. Or maybe use existing arch/arm/mach-davinci/usb.c. WBR, Sergei From manjunath.hadli at ti.com Wed Dec 21 07:43:33 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 21 Dec 2011 19:13:33 +0530 Subject: [PATCH v7 0/8] ARM: davinci:add support for dm644x vpbe display driver Message-ID: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> Re-arrange definitions and remove unnecessary code so that we can have a common header for all davinci platforms. This will enable us to share defines and enable common routines to be used without polluting hardware.h. This is consistent with Russel's pet peaves notes regarding non-pollution of include/mach. Having this as the base, have a common system module base address (DAVINCI_SYSTEM_MODULE_BASE) and removing IO_ADDRESS macro,add support for dm644x VPBE display driver. Changes from last version: 1. patches 2,3 and 4 from last set pulled by Sekhar 2. Some description changes. 3. Header inclusion sequence changes. 4. Deletion of a platform file which was missed out. Manjunath Hadli (8): davinci: vpif: remove machine specific inclusion from driver ARM: davinci: create new common platform header for davinci davinci: eliminate use of IO_ADDRESS() on sysmod davinci: dm644x: Replace register base value with a defined macro davinci: dm644x: change vpfe capture structure variables for consistency davinci: dm644x: move vpfe init from soc to board specific files davinci: dm644x: add support for v4l2 video display davinci: dm644x EVM: add support for VPBE display arch/arm/mach-davinci/board-dm355-evm.c | 3 +- arch/arm/mach-davinci/board-dm355-leopard.c | 3 +- arch/arm/mach-davinci/board-dm365-evm.c | 3 +- arch/arm/mach-davinci/board-dm644x-evm.c | 134 +++++++++++++++++-- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 3 +- arch/arm/mach-davinci/board-sffsdr.c | 3 +- arch/arm/mach-davinci/davinci.h | 99 ++++++++++++++ arch/arm/mach-davinci/devices.c | 25 +++-- arch/arm/mach-davinci/dm355.c | 3 +- arch/arm/mach-davinci/dm365.c | 3 +- arch/arm/mach-davinci/dm644x.c | 179 ++++++++++++++++++++++--- arch/arm/mach-davinci/dm646x.c | 3 +- arch/arm/mach-davinci/include/mach/dm355.h | 32 ----- arch/arm/mach-davinci/include/mach/dm365.h | 36 ----- arch/arm/mach-davinci/include/mach/dm644x.h | 40 ------ arch/arm/mach-davinci/include/mach/dm646x.h | 34 ----- arch/arm/mach-davinci/include/mach/hardware.h | 2 - drivers/media/video/davinci/vpif.h | 2 - drivers/media/video/davinci/vpif_display.c | 2 - include/media/davinci/vpif_types.h | 2 + sound/soc/codecs/cq93vc.c | 2 - 22 files changed, 413 insertions(+), 202 deletions(-) create mode 100644 arch/arm/mach-davinci/davinci.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h From manjunath.hadli at ti.com Wed Dec 21 07:43:38 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 21 Dec 2011 19:13:38 +0530 Subject: [PATCH v7 5/8] davinci: dm644x: change vpfe capture structure variables for consistency In-Reply-To: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1324475021-32509-6-git-send-email-manjunath.hadli@ti.com> Add SoC and board prefixes to variable names so that it is consistent with the rest of the file. Signed-off-by: Manjunath Hadli Acked-by: Sekhar Nori --- arch/arm/mach-davinci/board-dm644x-evm.c | 24 ++++++++++++------------ arch/arm/mach-davinci/dm644x.c | 12 ++++++------ 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 6d76d7c..7d940f5 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -190,7 +190,7 @@ static struct platform_device davinci_fb_device = { .num_resources = 0, }; -static struct tvp514x_platform_data tvp5146_pdata = { +static struct tvp514x_platform_data dm644xevm_tvp5146_pdata = { .clk_polarity = 0, .hs_polarity = 1, .vs_polarity = 1 @@ -198,7 +198,7 @@ static struct tvp514x_platform_data tvp5146_pdata = { #define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) /* Inputs available at the TVP5146 */ -static struct v4l2_input tvp5146_inputs[] = { +static struct v4l2_input dm644xevm_tvp5146_inputs[] = { { .index = 0, .name = "Composite", @@ -218,7 +218,7 @@ static struct v4l2_input tvp5146_inputs[] = { * ouput that goes to vpfe. There is a one to one correspondence * with tvp5146_inputs */ -static struct vpfe_route tvp5146_routes[] = { +static struct vpfe_route dm644xevm_tvp5146_routes[] = { { .input = INPUT_CVBS_VI2B, .output = OUTPUT_10BIT_422_EMBEDDED_SYNC, @@ -229,13 +229,13 @@ static struct vpfe_route tvp5146_routes[] = { }, }; -static struct vpfe_subdev_info vpfe_sub_devs[] = { +static struct vpfe_subdev_info dm644xevm_vpfe_sub_devs[] = { { .name = "tvp5146", .grp_id = 0, - .num_inputs = ARRAY_SIZE(tvp5146_inputs), - .inputs = tvp5146_inputs, - .routes = tvp5146_routes, + .num_inputs = ARRAY_SIZE(dm644xevm_tvp5146_inputs), + .inputs = dm644xevm_tvp5146_inputs, + .routes = dm644xevm_tvp5146_routes, .can_route = 1, .ccdc_if_params = { .if_type = VPFE_BT656, @@ -244,15 +244,15 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = { }, .board_info = { I2C_BOARD_INFO("tvp5146", 0x5d), - .platform_data = &tvp5146_pdata, + .platform_data = &dm644xevm_tvp5146_pdata, }, }, }; -static struct vpfe_config vpfe_cfg = { - .num_subdevs = ARRAY_SIZE(vpfe_sub_devs), +static struct vpfe_config dm644xevm_capture_cfg = { + .num_subdevs = ARRAY_SIZE(dm644xevm_vpfe_sub_devs), .i2c_adapter_id = 1, - .sub_devs = vpfe_sub_devs, + .sub_devs = dm644xevm_vpfe_sub_devs, .card_name = "DM6446 EVM", .ccdc = "DM6446 CCDC", }; @@ -626,7 +626,7 @@ static void __init davinci_evm_map_io(void) { /* setup input configuration for VPFE input devices */ - dm644x_set_vpfe_config(&vpfe_cfg); + dm644x_set_vpfe_config(&dm644xevm_capture_cfg); dm644x_init(); } diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 97aecf2..acd9ee2 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -614,7 +614,7 @@ static struct platform_device dm644x_vpss_device = { .resource = dm644x_vpss_resources, }; -static struct resource vpfe_resources[] = { +static struct resource dm644x_vpfe_resources[] = { { .start = IRQ_VDINT0, .end = IRQ_VDINT0, @@ -648,11 +648,11 @@ static struct platform_device dm644x_ccdc_dev = { }, }; -static struct platform_device vpfe_capture_dev = { +static struct platform_device dm644x_vpfe_dev = { .name = CAPTURE_DRV_NAME, .id = -1, - .num_resources = ARRAY_SIZE(vpfe_resources), - .resource = vpfe_resources, + .num_resources = ARRAY_SIZE(dm644x_vpfe_resources), + .resource = dm644x_vpfe_resources, .dev = { .dma_mask = &vpfe_capture_dma_mask, .coherent_dma_mask = DMA_BIT_MASK(32), @@ -661,7 +661,7 @@ static struct platform_device vpfe_capture_dev = { void dm644x_set_vpfe_config(struct vpfe_config *cfg) { - vpfe_capture_dev.dev.platform_data = cfg; + dm644x_vpfe_dev.dev.platform_data = cfg; } /*----------------------------------------------------------------------*/ @@ -809,7 +809,7 @@ static int __init dm644x_init_devices(void) platform_device_register(&dm644x_vpss_device); platform_device_register(&dm644x_ccdc_dev); - platform_device_register(&vpfe_capture_dev); + platform_device_register(&dm644x_vpfe_dev); return 0; } -- 1.6.2.4 From manjunath.hadli at ti.com Wed Dec 21 07:43:40 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 21 Dec 2011 19:13:40 +0530 Subject: [PATCH v7 7/8] davinci: dm644x: add support for v4l2 video display In-Reply-To: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1324475021-32509-8-git-send-email-manjunath.hadli@ti.com> Create platform devices for various video modules like venc,osd, vpbe and v4l2 driver for dm644x. Change the dm644x_init_video to make room for display config, and register the vpfe or vpbe devices based on the config pointer validity to make sure boards without vpfe or vpbe can be built with minimal changes. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/board-dm644x-evm.c | 2 +- arch/arm/mach-davinci/davinci.h | 7 +- arch/arm/mach-davinci/dm644x.c | 163 +++++++++++++++++++++++++++--- 3 files changed, 154 insertions(+), 18 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 71aae93..8d6e4f6 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -696,7 +696,7 @@ static __init void davinci_evm_init(void) evm_init_i2c(); davinci_setup_mmc(0, &dm6446evm_mmc_config); - dm644x_init_video(&dm644xevm_capture_cfg); + dm644x_init_video(&dm644xevm_capture_cfg, NULL); davinci_serial_init(&uart_config); dm644x_init_asp(&dm644x_evm_snd_data); diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h index 680446f..fcfe2f8 100644 --- a/arch/arm/mach-davinci/davinci.h +++ b/arch/arm/mach-davinci/davinci.h @@ -27,6 +27,11 @@ #include #include +#include +#include +#include +#include +#include #define DAVINCI_SYSTEM_MODULE_BASE 0x01c40000 @@ -81,7 +86,7 @@ void dm365_set_vpfe_config(struct vpfe_config *cfg); /* DM644x function declarations */ void __init dm644x_init(void); void __init dm644x_init_asp(struct snd_platform_data *pdata); -int __init dm644x_init_video(struct vpfe_config *); +int __init dm644x_init_video(struct vpfe_config *, struct vpbe_config *); /* DM646x function declarations */ void __init dm646x_init(void); diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 27bf9ca..6809bea 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -627,7 +627,7 @@ static struct resource dm644x_vpfe_resources[] = { }, }; -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32); +static u64 dm644x_video_dma_mask = DMA_BIT_MASK(32); static struct resource dm644x_ccdc_resource[] = { /* CCDC Base address */ { @@ -643,7 +643,7 @@ static struct platform_device dm644x_ccdc_dev = { .num_resources = ARRAY_SIZE(dm644x_ccdc_resource), .resource = dm644x_ccdc_resource, .dev = { - .dma_mask = &vpfe_capture_dma_mask, + .dma_mask = &dm644x_video_dma_mask, .coherent_dma_mask = DMA_BIT_MASK(32), }, }; @@ -654,7 +654,127 @@ static struct platform_device dm644x_vpfe_dev = { .num_resources = ARRAY_SIZE(dm644x_vpfe_resources), .resource = dm644x_vpfe_resources, .dev = { - .dma_mask = &vpfe_capture_dma_mask, + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, +}; + +#define DM644X_OSD_BASE 0x01c72600 + +static struct resource dm644x_osd_resources[] = { + { + .start = DM644X_OSD_BASE, + .end = DM644X_OSD_BASE + 0x1ff, + .flags = IORESOURCE_MEM, + }, +}; + +static struct osd_platform_data dm644x_osd_data = { + .vpbe_type = VPBE_VERSION_1, +}; + +static struct platform_device dm644x_osd_dev = { + .name = VPBE_OSD_SUBDEV_NAME, + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_osd_resources), + .resource = dm644x_osd_resources, + .dev = { + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = &dm644x_osd_data, + }, +}; + +#define DM644X_VENC_BASE 0x01c72400 + +static struct resource dm644x_venc_resources[] = { + { + .start = DM644X_VENC_BASE, + .end = DM644X_VENC_BASE + 0x17f, + .flags = IORESOURCE_MEM, + }, +}; + +static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, + unsigned int mode) +{ + int ret = 0; + void __iomem *vpss_clkctl_reg; + + vpss_clkctl_reg = DAVINCI_SYSMODULE_VIRT(0x44); + + switch (type) { + case VPBE_ENC_STD: + writel(0x18, vpss_clkctl_reg); + break; + case VPBE_ENC_DV_PRESET: + switch (mode) { + case V4L2_DV_480P59_94: + case V4L2_DV_576P50: + writel(0x19, vpss_clkctl_reg); + break; + case V4L2_DV_720P60: + case V4L2_DV_1080I60: + case V4L2_DV_1080P30: + /* + * For HD, use external clock source since + * HD requires higher clock rate + */ + writel(0xa, vpss_clkctl_reg); + break; + default: + ret = -EINVAL; + break; + } + break; + default: + ret = -EINVAL; + } + + return ret; +} + +static struct resource dm644x_v4l2_disp_resources[] = { + { + .start = IRQ_VENCINT, + .end = IRQ_VENCINT, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct platform_device dm644x_vpbe_display = { + .name = "vpbe-v4l2", + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources), + .resource = dm644x_v4l2_disp_resources, + .dev = { + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, +}; + +static struct venc_platform_data dm644x_venc_pdata = { + .venc_type = VPBE_VERSION_1, + .setup_clock = dm644x_venc_setup_clock, +}; + +static struct platform_device dm644x_venc_dev = { + .name = VPBE_VENC_SUBDEV_NAME, + .id = -1, + .num_resources = ARRAY_SIZE(dm644x_venc_resources), + .resource = dm644x_venc_resources, + .dev = { + .dma_mask = &dm644x_video_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = &dm644x_venc_pdata, + }, +}; + +static struct platform_device dm644x_vpbe_dev = { + .name = "vpbe_controller", + .id = -1, + .dev = { + .dma_mask = &dm644x_video_dma_mask, .coherent_dma_mask = DMA_BIT_MASK(32), }, }; @@ -787,20 +907,31 @@ void __init dm644x_init(void) davinci_map_sysmod(); } -static struct platform_device *dm644x_video_devices[] __initdata = { - &dm644x_vpss_device, - &dm644x_ccdc_dev, - &dm644x_vpfe_dev, -}; - -int __init dm644x_init_video(struct vpfe_config *vpfe_cfg) +int __init dm644x_init_video(struct vpfe_config *vpfe_cfg, + struct vpbe_config *vpbe_cfg) { - dm644x_vpfe_dev.dev.platform_data = vpfe_cfg; - /* Add ccdc clock aliases */ - clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL); - clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL); - platform_add_devices(dm644x_video_devices, - ARRAY_SIZE(dm644x_video_devices)); + if (vpfe_cfg || vpbe_cfg) + platform_device_register(&dm644x_vpss_device); + + if (vpfe_cfg) { + dm644x_vpfe_dev.dev.platform_data = vpfe_cfg; + platform_device_register(&dm644x_ccdc_dev); + platform_device_register(&dm644x_vpfe_dev); + /* Add ccdc clock aliases */ + clk_add_alias("master", dm644x_ccdc_dev.name, + "vpss_master", NULL); + clk_add_alias("slave", dm644x_ccdc_dev.name, + "vpss_slave", NULL); + } + + if (vpbe_cfg) { + dm644x_vpbe_dev.dev.platform_data = vpbe_cfg; + platform_device_register(&dm644x_osd_dev); + platform_device_register(&dm644x_venc_dev); + platform_device_register(&dm644x_vpbe_dev); + platform_device_register(&dm644x_vpbe_display); + } + return 0; } -- 1.6.2.4 From manjunath.hadli at ti.com Wed Dec 21 07:43:36 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 21 Dec 2011 19:13:36 +0530 Subject: [PATCH v7 3/8] davinci: eliminate use of IO_ADDRESS() on sysmod In-Reply-To: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1324475021-32509-4-git-send-email-manjunath.hadli@ti.com> Current devices.c file has a number of instances where IO_ADDRESS() is used for system module register access. Eliminate this in favor of a ioremap() based access. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/davinci.h | 9 +++++++++ arch/arm/mach-davinci/devices.c | 25 ++++++++++++++++--------- arch/arm/mach-davinci/dm355.c | 1 + arch/arm/mach-davinci/dm365.c | 1 + arch/arm/mach-davinci/dm644x.c | 1 + arch/arm/mach-davinci/dm646x.c | 1 + arch/arm/mach-davinci/include/mach/hardware.h | 2 -- 7 files changed, 29 insertions(+), 11 deletions(-) diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h index 238c282..065b3a0 100644 --- a/arch/arm/mach-davinci/davinci.h +++ b/arch/arm/mach-davinci/davinci.h @@ -23,10 +23,19 @@ #include #include +#include #include #include +#define DAVINCI_SYSTEM_MODULE_BASE 0x01c40000 + +#ifndef __ASSEMBLER__ +extern void __iomem *davinci_sysmodbase; +#define DAVINCI_SYSMODULE_VIRT(x) (davinci_sysmodbase + (x)) +void davinci_map_sysmod(void); +#endif + /* DM355 base addresses */ #define DM355_ASYNC_EMIF_CONTROL_BASE 0x01e10000 #define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c index 806a2f0..faff29a 100644 --- a/arch/arm/mach-davinci/devices.c +++ b/arch/arm/mach-davinci/devices.c @@ -23,6 +23,7 @@ #include #include +#include "davinci.h" #include "clock.h" #define DAVINCI_I2C_BASE 0x01C21000 @@ -36,6 +37,14 @@ /* System control register offsets */ #define DM64XX_VDD3P3V_PWDN 0x48 +void __iomem *davinci_sysmodbase; + +void davinci_map_sysmod(void) +{ + davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800); + WARN_ON(!davinci_sysmodbase); +} + static struct resource i2c_resources[] = { { .start = DAVINCI_I2C_BASE, @@ -212,12 +221,12 @@ void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config) davinci_cfg_reg(DM355_SD1_DATA2); davinci_cfg_reg(DM355_SD1_DATA3); } else if (cpu_is_davinci_dm365()) { - void __iomem *pupdctl1 = - IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c); - /* Configure pull down control */ - __raw_writel((__raw_readl(pupdctl1) & ~0xfc0), - pupdctl1); + void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c); + unsigned v; + + v = __raw_readl(pupdctl1); + __raw_writel(v & ~0xfc0, pupdctl1); mmcsd1_resources[0].start = DM365_MMCSD1_BASE; mmcsd1_resources[0].end = DM365_MMCSD1_BASE + @@ -246,11 +255,9 @@ void __init davinci_setup_mmc(int module, struct davinci_mmc_config *config) mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0; } else if (cpu_is_davinci_dm644x()) { /* REVISIT: should this be in board-init code? */ - void __iomem *base = - IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE); - /* Power-on 3.3V IO cells */ - __raw_writel(0, base + DM64XX_VDD3P3V_PWDN); + __raw_writel(0, + DAVINCI_SYSMODULE_VIRT(DM64XX_VDD3P3V_PWDN)); /*Set up the pull regiter for MMC */ davinci_cfg_reg(DM644X_MSTK); } diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index 68423d2..43b4dc3 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -872,6 +872,7 @@ void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata) void __init dm355_init(void) { davinci_common_init(&davinci_soc_info_dm355); + davinci_map_sysmod(); } static int __init dm355_init_devices(void) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index d3f5642..3758762 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -1139,6 +1139,7 @@ void __init dm365_init_rtc(void) void __init dm365_init(void) { davinci_common_init(&davinci_soc_info_dm365); + davinci_map_sysmod(); } static struct resource dm365_vpss_resources[] = { diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index b1a3567..6b95b4b 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -787,6 +787,7 @@ void __init dm644x_init_asp(struct snd_platform_data *pdata) void __init dm644x_init(void) { davinci_common_init(&davinci_soc_info_dm644x); + davinci_map_sysmod(); } static int __init dm644x_init_devices(void) diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index ef4e753..2f28a49 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -913,6 +913,7 @@ int __init dm646x_init_edma(struct edma_rsv_info *rsv) void __init dm646x_init(void) { davinci_common_init(&davinci_soc_info_dm646x); + davinci_map_sysmod(); } static int __init dm646x_init_devices(void) diff --git a/arch/arm/mach-davinci/include/mach/hardware.h b/arch/arm/mach-davinci/include/mach/hardware.h index 414e0b9..0209b1f 100644 --- a/arch/arm/mach-davinci/include/mach/hardware.h +++ b/arch/arm/mach-davinci/include/mach/hardware.h @@ -19,8 +19,6 @@ * and the chip/board init code should then explicitly include * .h */ -#define DAVINCI_SYSTEM_MODULE_BASE 0x01C40000 - /* * I/O mapping */ -- 1.6.2.4 From manjunath.hadli at ti.com Wed Dec 21 07:43:41 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 21 Dec 2011 19:13:41 +0530 Subject: [PATCH v7 8/8] davinci: dm644x EVM: add support for VPBE display In-Reply-To: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1324475021-32509-9-git-send-email-manjunath.hadli@ti.com> This patch adds support for V4L2 video display to DM6446 EVM. Support for SD and ED modes is provided, along with Composite and Component outputs.Also added vpbe_config as a parameter for dm644x_init_video to allow for registration of vpbe platform devices. Signed-off-by: Manjunath Hadli Acked-by: Sekhar Nori --- arch/arm/mach-davinci/board-dm644x-evm.c | 108 +++++++++++++++++++++++++++++- 1 files changed, 107 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 8d6e4f6..142154b 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -613,6 +613,112 @@ static void __init evm_init_i2c(void) i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info)); } +#define VENC_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) + +/* venc standard timings */ +static struct vpbe_enc_mode_info dm644xevm_enc_std_timing[] = { + { + .name = "ntsc", + .timings_type = VPBE_ENC_STD, + .timings = {V4L2_STD_525_60}, + .interlaced = 1, + .xres = 720, + .yres = 480, + .aspect = {11, 10}, + .fps = {30000, 1001}, + .left_margin = 0x79, + .upper_margin = 0x10, + }, + { + .name = "pal", + .timings_type = VPBE_ENC_STD, + .timings = {V4L2_STD_625_50}, + .interlaced = 1, + .xres = 720, + .yres = 576, + .aspect = {54, 59}, + .fps = {25, 1}, + .left_margin = 0x7e, + .upper_margin = 0x16, + }, +}; + +/* venc dv preset timings */ +static struct vpbe_enc_mode_info dm644xevm_enc_preset_timing[] = { + { + .name = "480p59_94", + .timings_type = VPBE_ENC_DV_PRESET, + .timings = {V4L2_DV_480P59_94}, + .interlaced = 0, + .xres = 720, + .yres = 480, + .aspect = {1, 1}, + .fps = {5994, 100}, + .left_margin = 0x80, + .upper_margin = 0x20, + }, + { + .name = "576p50", + .timings_type = VPBE_ENC_DV_PRESET, + .timings = {V4L2_DV_576P50}, + .interlaced = 0, + .xres = 720, + .yres = 576, + .aspect = {1, 1}, + .fps = {50, 1}, + .left_margin = 0x7e, + .upper_margin = 0x30, + }, +}; + +/* + * The outputs available from VPBE + encoders. Keep the order same + * as that of encoders. First those from venc followed by that from + * encoders. Index in the output refers to index on a particular encoder. + * Driver uses this index to pass it to encoder when it supports more than + * one output. Application uses index of the array to set an output. + */ +static struct vpbe_output dm644xevm_vpbe_outputs[] = { + { + .output = { + .index = 0, + .name = "Composite", + .type = V4L2_OUTPUT_TYPE_ANALOG, + .std = VENC_STD_ALL, + .capabilities = V4L2_OUT_CAP_STD, + }, + .subdev_name = VPBE_VENC_SUBDEV_NAME, + .default_mode = "ntsc", + .num_modes = ARRAY_SIZE(dm644xevm_enc_std_timing), + .modes = dm644xevm_enc_std_timing, + }, + { + .output = { + .index = 1, + .name = "Component", + .type = V4L2_OUTPUT_TYPE_ANALOG, + .capabilities = V4L2_OUT_CAP_PRESETS, + }, + .subdev_name = VPBE_VENC_SUBDEV_NAME, + .default_mode = "480p59_94", + .num_modes = ARRAY_SIZE(dm644xevm_enc_preset_timing), + .modes = dm644xevm_enc_preset_timing, + }, +}; + +static struct vpbe_config dm644xevm_display_cfg = { + .module_name = "dm644x-vpbe-display", + .i2c_adapter_id = 1, + .osd = { + .module_name = VPBE_OSD_SUBDEV_NAME, + }, + .venc = { + .module_name = VPBE_VENC_SUBDEV_NAME, + }, + .num_outputs = ARRAY_SIZE(dm644xevm_vpbe_outputs), + .outputs = dm644xevm_vpbe_outputs, +}; + static struct platform_device *davinci_evm_devices[] __initdata = { &davinci_fb_device, &rtc_dev, @@ -696,7 +802,7 @@ static __init void davinci_evm_init(void) evm_init_i2c(); davinci_setup_mmc(0, &dm6446evm_mmc_config); - dm644x_init_video(&dm644xevm_capture_cfg, NULL); + dm644x_init_video(&dm644xevm_capture_cfg, &dm644xevm_display_cfg); davinci_serial_init(&uart_config); dm644x_init_asp(&dm644x_evm_snd_data); -- 1.6.2.4 From manjunath.hadli at ti.com Wed Dec 21 07:43:39 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 21 Dec 2011 19:13:39 +0530 Subject: [PATCH v7 6/8] davinci: dm644x: move vpfe init from soc to board specific files In-Reply-To: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1324475021-32509-7-git-send-email-manjunath.hadli@ti.com> Move all vpfe platform device registrations to the board specific file like the rest of the devices, and have all of them together. This would remove the restriction of inclusion and registration of vpfe platform devices for non-vpfe boards. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/board-dm644x-evm.c | 3 +-- arch/arm/mach-davinci/davinci.h | 2 +- arch/arm/mach-davinci/dm644x.c | 29 +++++++++++++++++------------ 3 files changed, 19 insertions(+), 15 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 7d940f5..71aae93 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -625,8 +625,6 @@ static struct davinci_uart_config uart_config __initdata = { static void __init davinci_evm_map_io(void) { - /* setup input configuration for VPFE input devices */ - dm644x_set_vpfe_config(&dm644xevm_capture_cfg); dm644x_init(); } @@ -698,6 +696,7 @@ static __init void davinci_evm_init(void) evm_init_i2c(); davinci_setup_mmc(0, &dm6446evm_mmc_config); + dm644x_init_video(&dm644xevm_capture_cfg); davinci_serial_init(&uart_config); dm644x_init_asp(&dm644x_evm_snd_data); diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h index 065b3a0..680446f 100644 --- a/arch/arm/mach-davinci/davinci.h +++ b/arch/arm/mach-davinci/davinci.h @@ -81,7 +81,7 @@ void dm365_set_vpfe_config(struct vpfe_config *cfg); /* DM644x function declarations */ void __init dm644x_init(void); void __init dm644x_init_asp(struct snd_platform_data *pdata); -void dm644x_set_vpfe_config(struct vpfe_config *cfg); +int __init dm644x_init_video(struct vpfe_config *); /* DM646x function declarations */ void __init dm646x_init(void); diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index acd9ee2..27bf9ca 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -659,11 +659,6 @@ static struct platform_device dm644x_vpfe_dev = { }, }; -void dm644x_set_vpfe_config(struct vpfe_config *cfg) -{ - dm644x_vpfe_dev.dev.platform_data = cfg; -} - /*----------------------------------------------------------------------*/ static struct map_desc dm644x_io_desc[] = { @@ -792,14 +787,28 @@ void __init dm644x_init(void) davinci_map_sysmod(); } +static struct platform_device *dm644x_video_devices[] __initdata = { + &dm644x_vpss_device, + &dm644x_ccdc_dev, + &dm644x_vpfe_dev, +}; + +int __init dm644x_init_video(struct vpfe_config *vpfe_cfg) +{ + dm644x_vpfe_dev.dev.platform_data = vpfe_cfg; + /* Add ccdc clock aliases */ + clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL); + clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL); + platform_add_devices(dm644x_video_devices, + ARRAY_SIZE(dm644x_video_devices)); + return 0; +} + static int __init dm644x_init_devices(void) { if (!cpu_is_davinci_dm644x()) return 0; - /* Add ccdc clock aliases */ - clk_add_alias("master", dm644x_ccdc_dev.name, "vpss_master", NULL); - clk_add_alias("slave", dm644x_ccdc_dev.name, "vpss_slave", NULL); platform_device_register(&dm644x_edma_device); platform_device_register(&dm644x_mdio_device); @@ -807,10 +816,6 @@ static int __init dm644x_init_devices(void) clk_add_alias(NULL, dev_name(&dm644x_mdio_device.dev), NULL, &dm644x_emac_device.dev); - platform_device_register(&dm644x_vpss_device); - platform_device_register(&dm644x_ccdc_dev); - platform_device_register(&dm644x_vpfe_dev); - return 0; } postcore_initcall(dm644x_init_devices); -- 1.6.2.4 From manjunath.hadli at ti.com Wed Dec 21 07:43:37 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 21 Dec 2011 19:13:37 +0530 Subject: [PATCH v7 4/8] davinci: dm644x: Replace register base value with a defined macro In-Reply-To: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1324475021-32509-5-git-send-email-manjunath.hadli@ti.com> Replace hard coded value of vpss register base to a define macro DM644X_VPSS_BASE for proper readability Signed-off-by: Manjunath Hadli Acked-by: Sekhar Nori --- arch/arm/mach-davinci/dm644x.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index 6b95b4b..97aecf2 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -594,13 +594,15 @@ static struct platform_device dm644x_asp_device = { .resource = dm644x_asp_resources, }; +#define DM644X_VPSS_BASE 0x01c73400 + static struct resource dm644x_vpss_resources[] = { { /* VPSS Base address */ .name = "vpss", - .start = 0x01c73400, - .end = 0x01c73400 + 0xff, - .flags = IORESOURCE_MEM, + .start = DM644X_VPSS_BASE, + .end = DM644X_VPSS_BASE + 0xff, + .flags = IORESOURCE_MEM, }, }; -- 1.6.2.4 From manjunath.hadli at ti.com Wed Dec 21 07:43:35 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 21 Dec 2011 19:13:35 +0530 Subject: [PATCH v7 2/8] ARM: davinci: create new common platform header for davinci In-Reply-To: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1324475021-32509-3-git-send-email-manjunath.hadli@ti.com> remove individual platform header files for dm365, dm355, dm644x and dm646x and consolidate it into a single and common header file davinci.h placed in arch/arm/mach-davinci. This reduces the pollution in the include/mach and is consistent with Russel's suggestions as part of his "pet peaves" mail. The further patches in the series take advantage of this consolidation for easy implementation of IO_ADDRESS elimination. Signed-off-by: Manjunath Hadli --- arch/arm/mach-davinci/board-dm355-evm.c | 3 +- arch/arm/mach-davinci/board-dm355-leopard.c | 3 +- arch/arm/mach-davinci/board-dm365-evm.c | 3 +- arch/arm/mach-davinci/board-dm644x-evm.c | 3 +- arch/arm/mach-davinci/board-dm646x-evm.c | 2 +- arch/arm/mach-davinci/board-neuros-osd2.c | 3 +- arch/arm/mach-davinci/board-sffsdr.c | 3 +- arch/arm/mach-davinci/davinci.h | 85 +++++++++++++++++++++++++++ arch/arm/mach-davinci/dm355.c | 2 +- arch/arm/mach-davinci/dm365.c | 2 +- arch/arm/mach-davinci/dm644x.c | 2 +- arch/arm/mach-davinci/dm646x.c | 2 +- arch/arm/mach-davinci/include/mach/dm355.h | 32 ---------- arch/arm/mach-davinci/include/mach/dm365.h | 36 ----------- arch/arm/mach-davinci/include/mach/dm644x.h | 40 ------------- arch/arm/mach-davinci/include/mach/dm646x.h | 34 ----------- 16 files changed, 102 insertions(+), 153 deletions(-) create mode 100644 arch/arm/mach-davinci/davinci.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index 4e0e707..f700018 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -26,13 +26,14 @@ #include #include -#include #include #include #include #include #include +#include "davinci.h" + /* NOTE: this is geared for the standard config, with a socketed * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you * swap chips, maybe with a different block size, partitioning may diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c index ff2d241..103c65a 100644 --- a/arch/arm/mach-davinci/board-dm355-leopard.c +++ b/arch/arm/mach-davinci/board-dm355-leopard.c @@ -23,13 +23,14 @@ #include #include -#include #include #include #include #include #include +#include "davinci.h" + /* NOTE: this is geared for the standard config, with a socketed * 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you * swap chips, maybe with a different block size, partitioning may diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index 10447c0..7124224 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -32,7 +32,6 @@ #include #include -#include #include #include #include @@ -42,6 +41,8 @@ #include +#include "davinci.h" + static inline int have_imager(void) { /* REVISIT when it's supported, trigger via Kconfig */ diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 0cf8abf..6d76d7c 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -30,7 +30,6 @@ #include #include -#include #include #include #include @@ -40,6 +39,8 @@ #include #include +#include "davinci.h" + #define DM644X_EVM_PHY_ID "0:01" #define LXT971_PHY_ID (0x001378e2) #define LXT971_PHY_MASK (0xfffffff0) diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 635bf77..123bea8 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -36,7 +36,6 @@ #include #include -#include #include #include #include @@ -46,6 +45,7 @@ #include #include "clock.h" +#include "davinci.h" #define NAND_BLOCK_SIZE SZ_128K diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c index e5f231a..4a8bacc 100644 --- a/arch/arm/mach-davinci/board-neuros-osd2.c +++ b/arch/arm/mach-davinci/board-neuros-osd2.c @@ -30,7 +30,6 @@ #include #include -#include #include #include #include @@ -39,6 +38,8 @@ #include #include +#include "davinci.h" + #define NEUROS_OSD2_PHY_ID "0:01" #define LXT971_PHY_ID 0x001378e2 #define LXT971_PHY_MASK 0xfffffff0 diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c index 5dd4da9..abd09bf 100644 --- a/arch/arm/mach-davinci/board-sffsdr.c +++ b/arch/arm/mach-davinci/board-sffsdr.c @@ -35,13 +35,14 @@ #include #include -#include #include #include #include #include #include +#include "davinci.h" + #define SFFSDR_PHY_ID "0:01" static struct mtd_partition davinci_sffsdr_nandflash_partition[] = { /* U-Boot Environment: Block 0 diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h new file mode 100644 index 0000000..238c282 --- /dev/null +++ b/arch/arm/mach-davinci/davinci.h @@ -0,0 +1,85 @@ +/* + * This file contains the processor specific definitions + * of the TI DM644x, DM355, DM365, and DM646x. + * + * Copyright (C) 2011 Texas Instruments Incorporated + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#ifndef __DAVINCI_H +#define __DAVINCI_H + +#include +#include +#include +#include + +#include +#include + +#include +#include + +/* DM355 base addresses */ +#define DM355_ASYNC_EMIF_CONTROL_BASE 0x01e10000 +#define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 + +#define ASP1_TX_EVT_EN 1 +#define ASP1_RX_EVT_EN 2 + +/* DM365 base addresses */ +#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01d10000 +#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 +#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 + +/* DM644x base addresses */ +#define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01e00000 +#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 +#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 +#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000 +#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000 + +/* DM646x base addresses */ +#define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 +#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 + +/* DM355 function declarations */ +struct spi_board_info; + +void __init dm355_init(void); +void dm355_init_spi0(unsigned chipselect_mask, + struct spi_board_info *info, unsigned len); +void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); +void dm355_set_vpfe_config(struct vpfe_config *cfg); + +/* DM365 function declarations */ +void __init dm365_init(void); +void __init dm365_init_asp(struct snd_platform_data *pdata); +void __init dm365_init_vc(struct snd_platform_data *pdata); +void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); +void __init dm365_init_rtc(void); +void dm365_init_spi0(unsigned chipselect_mask, + struct spi_board_info *info, unsigned len); +void dm365_set_vpfe_config(struct vpfe_config *cfg); + +/* DM644x function declarations */ +void __init dm644x_init(void); +void __init dm644x_init_asp(struct snd_platform_data *pdata); +void dm644x_set_vpfe_config(struct vpfe_config *cfg); + +/* DM646x function declarations */ +void __init dm646x_init(void); +void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); +void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); +int __init dm646x_init_edma(struct edma_rsv_info *rsv); +void dm646x_video_init(void); +void dm646x_setup_vpif(struct vpif_display_config *, + struct vpif_capture_config *); +#endif /*__DAVINCI_H */ diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c index fe520d4..68423d2 100644 --- a/arch/arm/mach-davinci/dm355.c +++ b/arch/arm/mach-davinci/dm355.c @@ -18,7 +18,6 @@ #include -#include #include #include #include @@ -33,6 +32,7 @@ #include "clock.h" #include "mux.h" +#include "davinci.h" #define DM355_UART2_BASE (IO_PHYS + 0x206000) diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c index 77edee8..d3f5642 100644 --- a/arch/arm/mach-davinci/dm365.c +++ b/arch/arm/mach-davinci/dm365.c @@ -21,7 +21,6 @@ #include -#include #include #include #include @@ -37,6 +36,7 @@ #include "clock.h" #include "mux.h" +#include "davinci.h" #define DM365_REF_FREQ 24000000 /* 24 MHz on the DM365 EVM */ diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c index b274b21..b1a3567 100644 --- a/arch/arm/mach-davinci/dm644x.c +++ b/arch/arm/mach-davinci/dm644x.c @@ -15,7 +15,6 @@ #include -#include #include #include #include @@ -29,6 +28,7 @@ #include "clock.h" #include "mux.h" +#include "davinci.h" /* * Device specific clocks diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c index 4cf8b68..ef4e753 100644 --- a/arch/arm/mach-davinci/dm646x.c +++ b/arch/arm/mach-davinci/dm646x.c @@ -16,7 +16,6 @@ #include -#include #include #include #include @@ -30,6 +29,7 @@ #include "clock.h" #include "mux.h" +#include "davinci.h" #define DAVINCI_VPIF_BASE (0x01C12000) #define VDD3P3V_PWDN_OFFSET (0x48) diff --git a/arch/arm/mach-davinci/include/mach/dm355.h b/arch/arm/mach-davinci/include/mach/dm355.h deleted file mode 100644 index 36dff4a..0000000 --- a/arch/arm/mach-davinci/include/mach/dm355.h +++ /dev/null @@ -1,32 +0,0 @@ -/* - * Chip specific defines for DM355 SoC - * - * Author: Kevin Hilman, Deep Root Systems, LLC - * - * 2007 (c) Deep Root Systems, LLC. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. - */ -#ifndef __ASM_ARCH_DM355_H -#define __ASM_ARCH_DM355_H - -#include -#include -#include - -#define DM355_ASYNC_EMIF_CONTROL_BASE 0x01E10000 -#define DM355_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 - -#define ASP1_TX_EVT_EN 1 -#define ASP1_RX_EVT_EN 2 - -struct spi_board_info; - -void __init dm355_init(void); -void dm355_init_spi0(unsigned chipselect_mask, - struct spi_board_info *info, unsigned len); -void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); -void dm355_set_vpfe_config(struct vpfe_config *cfg); - -#endif /* __ASM_ARCH_DM355_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h deleted file mode 100644 index 51924de..0000000 --- a/arch/arm/mach-davinci/include/mach/dm365.h +++ /dev/null @@ -1,36 +0,0 @@ -/* - * Copyright (C) 2009 Texas Instruments Incorporated - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation version 2. - * - * This program is distributed "as is" WITHOUT ANY WARRANTY of any - * kind, whether express or implied; without even the implied warranty - * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ -#ifndef __ASM_ARCH_DM365_H -#define __ASM_ARCH_DM665_H - -#include -#include -#include -#include -#include -#include - -#define DM365_ASYNC_EMIF_CONTROL_BASE 0x01D10000 -#define DM365_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 -#define DM365_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 - -void __init dm365_init(void); -void __init dm365_init_asp(struct snd_platform_data *pdata); -void __init dm365_init_vc(struct snd_platform_data *pdata); -void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); -void __init dm365_init_rtc(void); -void dm365_init_spi0(unsigned chipselect_mask, - struct spi_board_info *info, unsigned len); - -void dm365_set_vpfe_config(struct vpfe_config *cfg); -#endif /* __ASM_ARCH_DM365_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h deleted file mode 100644 index 724377f..0000000 --- a/arch/arm/mach-davinci/include/mach/dm644x.h +++ /dev/null @@ -1,40 +0,0 @@ -/* - * This file contains the processor specific definitions - * of the TI DM644x. - * - * Copyright (C) 2008 Texas Instruments. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - * - */ -#ifndef __ASM_ARCH_DM644X_H -#define __ASM_ARCH_DM644X_H - -#include -#include -#include -#include - -#define DM644X_ASYNC_EMIF_CONTROL_BASE 0x01E00000 -#define DM644X_ASYNC_EMIF_DATA_CE0_BASE 0x02000000 -#define DM644X_ASYNC_EMIF_DATA_CE1_BASE 0x04000000 -#define DM644X_ASYNC_EMIF_DATA_CE2_BASE 0x06000000 -#define DM644X_ASYNC_EMIF_DATA_CE3_BASE 0x08000000 - -void __init dm644x_init(void); -void __init dm644x_init_asp(struct snd_platform_data *pdata); -void dm644x_set_vpfe_config(struct vpfe_config *cfg); - -#endif /* __ASM_ARCH_DM644X_H */ diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h deleted file mode 100644 index eb95864..0000000 --- a/arch/arm/mach-davinci/include/mach/dm646x.h +++ /dev/null @@ -1,34 +0,0 @@ -/* - * Chip specific defines for DM646x SoC - * - * Author: Kevin Hilman, Deep Root Systems, LLC - * - * 2007 (c) Deep Root Systems, LLC. This file is licensed under - * the terms of the GNU General Public License version 2. This program - * is licensed "as is" without any warranty of any kind, whether express - * or implied. - */ -#ifndef __ASM_ARCH_DM646X_H -#define __ASM_ARCH_DM646X_H - -#include -#include -#include -#include -#include -#include - -#define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000 -#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x42000000 - -void __init dm646x_init(void); -void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); -void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); -int __init dm646x_init_edma(struct edma_rsv_info *rsv); - -void dm646x_video_init(void); - -void dm646x_setup_vpif(struct vpif_display_config *, - struct vpif_capture_config *); - -#endif /* __ASM_ARCH_DM646X_H */ -- 1.6.2.4 From manjunath.hadli at ti.com Wed Dec 21 07:43:34 2011 From: manjunath.hadli at ti.com (Manjunath Hadli) Date: Wed, 21 Dec 2011 19:13:34 +0530 Subject: [PATCH v7 1/8] davinci: vpif: remove machine specific inclusion from driver In-Reply-To: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> Message-ID: <1324475021-32509-2-git-send-email-manjunath.hadli@ti.com> remove machine specific inclusion from the driver which comes in the way of platform code consolidation. currently was seen that these header inclusions were not necessary. Signed-off-by: Manjunath Hadli Cc: Mauro Carvalho Chehab Cc: LMML --- drivers/media/video/davinci/vpif.h | 2 -- drivers/media/video/davinci/vpif_display.c | 2 -- include/media/davinci/vpif_types.h | 2 ++ sound/soc/codecs/cq93vc.c | 2 -- 4 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/media/video/davinci/vpif.h b/drivers/media/video/davinci/vpif.h index 25036cb..8bcac65 100644 --- a/drivers/media/video/davinci/vpif.h +++ b/drivers/media/video/davinci/vpif.h @@ -18,8 +18,6 @@ #include #include -#include -#include #include /* Maximum channel allowed */ diff --git a/drivers/media/video/davinci/vpif_display.c b/drivers/media/video/davinci/vpif_display.c index 286f029..7fa34b4 100644 --- a/drivers/media/video/davinci/vpif_display.c +++ b/drivers/media/video/davinci/vpif_display.c @@ -39,8 +39,6 @@ #include #include -#include - #include "vpif_display.h" #include "vpif.h" diff --git a/include/media/davinci/vpif_types.h b/include/media/davinci/vpif_types.h index 9929b05..bd8217c 100644 --- a/include/media/davinci/vpif_types.h +++ b/include/media/davinci/vpif_types.h @@ -17,6 +17,8 @@ #ifndef _VPIF_TYPES_H #define _VPIF_TYPES_H +#include + #define VPIF_CAPTURE_MAX_CHANNELS 2 enum vpif_if_type { diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c index 46dbfd0..ff4eb7a 100644 --- a/sound/soc/codecs/cq93vc.c +++ b/sound/soc/codecs/cq93vc.c @@ -38,8 +38,6 @@ #include #include -#include - static inline unsigned int cq93vc_read(struct snd_soc_codec *codec, unsigned int reg) { -- 1.6.2.4 From manjunath.hadli at ti.com Wed Dec 21 07:54:18 2011 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Wed, 21 Dec 2011 13:54:18 +0000 Subject: [PATCH 1/2] media: add new mediabus format enums for dm365 In-Reply-To: <201112210058.33006.laurent.pinchart@ideasonboard.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112151402.45100.laurent.pinchart@ideasonboard.com> <201112210058.33006.laurent.pinchart@ideasonboard.com> Message-ID: Laurent, On Wed, Dec 21, 2011 at 05:28:31, Laurent Pinchart wrote: > Hi Manju, > > On Friday 16 December 2011 15:20:24 Hadli, Manjunath wrote: > > On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote: > > > On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote: > > > > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into > > > > mbus_pixel_code to represent A-LAW compressed Bayer format. This > > > > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8. > > > > add UV8 and NV12 ( Y and C separate with UV interleaved) which are > > > > supported on dm365. > > > > > > > > Signed-off-by: Manjunath Hadli > > > > Cc: Laurent Pinchart > > > > --- > > > > > > > > include/linux/v4l2-mediabus.h | 10 ++++++++-- > > > > 1 files changed, 8 insertions(+), 2 deletions(-) > > > > > > Please also update the documentation in Documentation/DocBook/media/v4l. > > > > > > > diff --git a/include/linux/v4l2-mediabus.h > > > > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644 > > > > --- a/include/linux/v4l2-mediabus.h > > > > +++ b/include/linux/v4l2-mediabus.h > > > > @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode { > > > > > > > > V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, > > > > V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, > > > > > > > > - /* YUV (including grey) - next is 0x2014 */ > > > > + /* YUV (including grey) - next is 0x2016 */ > > > > > > > > V4L2_MBUS_FMT_Y8_1X8 = 0x2001, > > > > V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, > > > > V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, > > > > > > > > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode { > > > > > > > > V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012, > > > > V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, > > > > V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, > > > > > > > > + V4L2_MBUS_FMT_NV12_1X20 = 0x2014, > > > > + V4L2_MBUS_FMT_UV8_1X8 = 0x2015, > > > > > > NV12, on the bus ? How does that work ? (The documentation should > > > answer my question :-)) > > > > Well, this is on the internal bus not exposed outside, but > > nevertheless bus between two subdevs or two independent hardware > > blocks. For example Resizer supports NV12 on its pad. Is there any other way to treat this? > > How is NV12 transferred on the bus in that case ? Are all luma samples transferred first, followed by all chroma samples ? It uses parallel bus of 16 bits, where Y and C are transmitted simultaneously on 8 bits each. NV12 uses a dummy C byte for every valid one. So I guess we call it V4L2_MBUS_FMT_YDYC_1X16 or V4L2_MBUS_FMT_YCYD_1X16? That way we will be able to document the format in the documentation also. Thx, -Manju > > > > > - /* Bayer - next is 0x3015 */ > > > > + /* Bayer - next is 0x3019 */ > > > > > > > > V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001, > > > > V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013, > > > > V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002, > > > > > > > > @@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode { > > > > > > > > V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010, > > > > V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011, > > > > V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012, > > > > > > > > + V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015, > > > > + V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016, > > > > + V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017, > > > > + V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018, > > > > > > Please keep the names sorted as described in the comment at the > > > beginning of the file. > > > > > > > /* JPEG compressed formats - next is 0x4002 */ > > > > V4L2_MBUS_FMT_JPEG_1X8 = 0x4001, > > -- > Regards, > > Laurent Pinchart > From manjunath.hadli at ti.com Wed Dec 21 07:56:36 2011 From: manjunath.hadli at ti.com (Hadli, Manjunath) Date: Wed, 21 Dec 2011 13:56:36 +0000 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: <201112210102.09117.laurent.pinchart@ideasonboard.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112151400.48321.laurent.pinchart@ideasonboard.com> <201112210102.09117.laurent.pinchart@ideasonboard.com> Message-ID: Laurent, On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote: > Hi Manju, > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote: > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format > > > > frames compressed by A-LAW alogorithm. > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only. > > > > > > > > Signed-off-by: Manjunath Hadli > > > > Cc: Laurent Pinchart > > > > --- > > > > > > > > include/linux/videodev2.h | 6 ++++++ > > > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > > > Could you please also document these formats in > > > Documentation/DocBook/media/v4l ? > > > > I will. Sorry to have missed that out. > > > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > > > > index 4b752d5..969112d 100644 > > > > --- a/include/linux/videodev2.h > > > > +++ b/include/linux/videodev2.h > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > > > > > > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') /* 8 > > > > YUV > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line > > > > uv interleaved */ > > > > > > > > +/* Chrominance formats */ > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8 > > > > UV 4:4 */ + > > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */ > > > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 > > > > Y/CbCr > > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', '1') > > > > /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct v4l2_pix_format > > > > { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* > > > > 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits > > > > */ #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', > > > > '0') > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > > > + > > > > > > That's not very future-proof, how would you describe SGBRG10ALAW8 > > > for instance ? > > > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We > > > have 4 characters, we could start with 'B' to denote Bayer, followed > > > by one character for the order, one for the compression, and one for > > > the number of bits. > > > > I agree. > > May be ('B', 'G', 'A', '8') is fine for the above? > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B', 'g', 'G' and 'R' respectively for the second character. The third character would be 'A' for A-law and 'D' for DPCM, and the fourth character could describe the bus width in bits from 0 to 15 with '0' - '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses for raw Bayer at some point, and a 0 width is definitely not useful. We could thus offset the width by some value. > > This is just a preliminary idea, I'm open to suggestions. I think it is a very good suggestion that we can go with. B : BGGR g : GBRG G : GRBG R : RGGB and 0-F can signify 1-16. Thx, -Manju > > > > > /* > > > > > > > > * 10bit raw bayer, expanded to 16 bits > > > > * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb... > > -- > Regards, > > Laurent Pinchart > From m-karicheri2 at ti.com Wed Dec 21 08:48:47 2011 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Wed, 21 Dec 2011 14:48:47 +0000 Subject: Log time stamp wraps around to 25 In-Reply-To: References: <3E54258959B69E4282D79E01AB1F32B72489F0@DFLE34.ent.ti.com> <3E54258959B69E4282D79E01AB1F32B7249C8B@DFLE34.ent.ti.com> <3E54258959B69E4282D79E01AB1F32B7249FD1@DFLE34.ent.ti.com> Message-ID: <3E54258959B69E4282D79E01AB1F32B724A8EA@DFLE34.ent.ti.com> Sekhar, Thanks. You can add me to the "Tested-by" and submit the patch. Murali Karicheri Software Design Engineer email: m-karicheri2 at ti.com Phone: (301) 407 9583 >> -----Original Message----- >> From: Nori, Sekhar >> Sent: Tuesday, December 20, 2011 2:19 PM >> To: Karicheri, Muralidharan >> Cc: davinci-linux-open-source at linux.davincidsp.com; Chemparathy, Cyril >> Subject: RE: Log time stamp wraps around to 25 >> >> On Wed, Dec 21, 2011 at 00:43:26, Karicheri, Muralidharan wrote: >> > Sekhar, >> > >> > My patch also initialized the read in the structure with read function which >> caused the crash. I think the reason for the dummy is to allow early call of >> sched_clock(). I have tested your patch and it seems to work fine so far (2 >> hours of test). Could you push this to upstream? >> > >> >> Thanks Murali! I will take this as a "Tested-by:" >> Will spin a formal patch tomorrow. >> >> Regards, >> Sekhar From m-karicheri2 at ti.com Wed Dec 21 08:55:23 2011 From: m-karicheri2 at ti.com (Karicheri, Muralidharan) Date: Wed, 21 Dec 2011 14:55:23 +0000 Subject: [PATCH v7 5/8] davinci: dm644x: change vpfe capture structure variables for consistency In-Reply-To: <1324475021-32509-6-git-send-email-manjunath.hadli@ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> <1324475021-32509-6-git-send-email-manjunath.hadli@ti.com> Message-ID: <3E54258959B69E4282D79E01AB1F32B724A949@DFLE34.ent.ti.com> original Message----- >> From: davinci-linux-open-source-bounces+m- >> karicheri2=ti.com at linux.davincidsp.com [mailto:davinci-linux-open-source- >> bounces+m-karicheri2=ti.com at linux.davincidsp.com] On Behalf Of Hadli, >> Manjunath >> Sent: Wednesday, December 21, 2011 8:44 AM >> To: dlos; LAK >> Subject: [PATCH v7 5/8] davinci: dm644x: change vpfe capture structure >> variables for consistency >> >> Add SoC and board prefixes to variable names so that it is >> consistent with the rest of the file. >> >> Signed-off-by: Manjunath Hadli >> Acked-by: Sekhar Nori >> --- >> arch/arm/mach-davinci/board-dm644x-evm.c | 24 ++++++++++++------------ >> arch/arm/mach-davinci/dm644x.c | 12 ++++++------ >> 2 files changed, 18 insertions(+), 18 deletions(-) >> >> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach- >> davinci/board-dm644x-evm.c >> index 6d76d7c..7d940f5 100644 >> --- a/arch/arm/mach-davinci/board-dm644x-evm.c >> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c >> @@ -190,7 +190,7 @@ static struct platform_device davinci_fb_device = { >> .num_resources = 0, >> }; >> >> -static struct tvp514x_platform_data tvp5146_pdata = { >> +static struct tvp514x_platform_data dm644xevm_tvp5146_pdata = { >> .clk_polarity = 0, >> .hs_polarity = 1, >> .vs_polarity = 1 >> @@ -198,7 +198,7 @@ static struct tvp514x_platform_data tvp5146_pdata = { >> >> #define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL) >> /* Inputs available at the TVP5146 */ >> -static struct v4l2_input tvp5146_inputs[] = { >> +static struct v4l2_input dm644xevm_tvp5146_inputs[] = { >> { >> .index = 0, >> .name = "Composite", >> @@ -218,7 +218,7 @@ static struct v4l2_input tvp5146_inputs[] = { >> * ouput that goes to vpfe. There is a one to one correspondence >> * with tvp5146_inputs >> */ >> -static struct vpfe_route tvp5146_routes[] = { >> +static struct vpfe_route dm644xevm_tvp5146_routes[] = { >> { >> .input = INPUT_CVBS_VI2B, >> .output = OUTPUT_10BIT_422_EMBEDDED_SYNC, >> @@ -229,13 +229,13 @@ static struct vpfe_route tvp5146_routes[] = { >> }, >> }; >> >> -static struct vpfe_subdev_info vpfe_sub_devs[] = { >> +static struct vpfe_subdev_info dm644xevm_vpfe_sub_devs[] = { >> { >> .name = "tvp5146", >> .grp_id = 0, >> - .num_inputs = ARRAY_SIZE(tvp5146_inputs), >> - .inputs = tvp5146_inputs, >> - .routes = tvp5146_routes, >> + .num_inputs = ARRAY_SIZE(dm644xevm_tvp5146_inputs), >> + .inputs = dm644xevm_tvp5146_inputs, >> + .routes = dm644xevm_tvp5146_routes, >> .can_route = 1, >> .ccdc_if_params = { >> .if_type = VPFE_BT656, >> @@ -244,15 +244,15 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = { >> }, >> .board_info = { >> I2C_BOARD_INFO("tvp5146", 0x5d), >> - .platform_data = &tvp5146_pdata, >> + .platform_data = &dm644xevm_tvp5146_pdata, >> }, >> }, >> }; >> >> -static struct vpfe_config vpfe_cfg = { >> - .num_subdevs = ARRAY_SIZE(vpfe_sub_devs), >> +static struct vpfe_config dm644xevm_capture_cfg = { >> + .num_subdevs = ARRAY_SIZE(dm644xevm_vpfe_sub_devs), >> .i2c_adapter_id = 1, >> - .sub_devs = vpfe_sub_devs, >> + .sub_devs = dm644xevm_vpfe_sub_devs, >> .card_name = "DM6446 EVM", >> .ccdc = "DM6446 CCDC", >> }; >> @@ -626,7 +626,7 @@ static void __init >> davinci_evm_map_io(void) >> { >> /* setup input configuration for VPFE input devices */ >> - dm644x_set_vpfe_config(&vpfe_cfg); >> + dm644x_set_vpfe_config(&dm644xevm_capture_cfg); >> dm644x_init(); >> } >> >> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c >> index 97aecf2..acd9ee2 100644 >> --- a/arch/arm/mach-davinci/dm644x.c >> +++ b/arch/arm/mach-davinci/dm644x.c >> @@ -614,7 +614,7 @@ static struct platform_device dm644x_vpss_device = { >> .resource = dm644x_vpss_resources, >> }; >> >> -static struct resource vpfe_resources[] = { >> +static struct resource dm644x_vpfe_resources[] = { >> { >> .start = IRQ_VDINT0, >> .end = IRQ_VDINT0, >> @@ -648,11 +648,11 @@ static struct platform_device dm644x_ccdc_dev = { >> }, >> }; >> >> -static struct platform_device vpfe_capture_dev = { >> +static struct platform_device dm644x_vpfe_dev = { >> .name = CAPTURE_DRV_NAME, >> .id = -1, >> - .num_resources = ARRAY_SIZE(vpfe_resources), >> - .resource = vpfe_resources, >> + .num_resources = ARRAY_SIZE(dm644x_vpfe_resources), >> + .resource = dm644x_vpfe_resources, >> .dev = { >> .dma_mask = &vpfe_capture_dma_mask, >> .coherent_dma_mask = DMA_BIT_MASK(32), >> @@ -661,7 +661,7 @@ static struct platform_device vpfe_capture_dev = { >> >> void dm644x_set_vpfe_config(struct vpfe_config *cfg) >> { >> - vpfe_capture_dev.dev.platform_data = cfg; >> + dm644x_vpfe_dev.dev.platform_data = cfg; >> } >> >> /*----------------------------------------------------------------------*/ >> @@ -809,7 +809,7 @@ static int __init dm644x_init_devices(void) >> >> platform_device_register(&dm644x_vpss_device); >> platform_device_register(&dm644x_ccdc_dev); >> - platform_device_register(&vpfe_capture_dev); >> + platform_device_register(&dm644x_vpfe_dev); >> Just a suggestion. Why don't we change these with platform_add_devices() API call and register all of the video devices in once call instead of separate calls to platform_device_register? >> return 0; >> } >> -- >> 1.6.2.4 >> >> _______________________________________________ >> 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 laurent.pinchart at ideasonboard.com Wed Dec 21 16:18:54 2011 From: laurent.pinchart at ideasonboard.com (Laurent Pinchart) Date: Wed, 21 Dec 2011 23:18:54 +0100 Subject: [PATCH 1/2] media: add new mediabus format enums for dm365 In-Reply-To: References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112210058.33006.laurent.pinchart@ideasonboard.com> Message-ID: <201112212318.55517.laurent.pinchart@ideasonboard.com> Hi Manju, On Wednesday 21 December 2011 14:54:18 Hadli, Manjunath wrote: > On Wed, Dec 21, 2011 at 05:28:31, Laurent Pinchart wrote: > > On Friday 16 December 2011 15:20:24 Hadli, Manjunath wrote: > > > On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote: > > > > On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote: > > > > > add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into > > > > > mbus_pixel_code to represent A-LAW compressed Bayer format. This > > > > > corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8. > > > > > add UV8 and NV12 ( Y and C separate with UV interleaved) which are > > > > > supported on dm365. > > > > > > > > > > Signed-off-by: Manjunath Hadli > > > > > Cc: Laurent Pinchart > > > > > --- > > > > > > > > > > include/linux/v4l2-mediabus.h | 10 ++++++++-- > > > > > 1 files changed, 8 insertions(+), 2 deletions(-) > > > > > > > > Please also update the documentation in > > > > Documentation/DocBook/media/v4l. > > > > > > > > > diff --git a/include/linux/v4l2-mediabus.h > > > > > b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644 > > > > > --- a/include/linux/v4l2-mediabus.h > > > > > +++ b/include/linux/v4l2-mediabus.h > > > > > @@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode { > > > > > > > > > > V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007, > > > > > V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008, > > > > > > > > > > - /* YUV (including grey) - next is 0x2014 */ > > > > > + /* YUV (including grey) - next is 0x2016 */ > > > > > > > > > > V4L2_MBUS_FMT_Y8_1X8 = 0x2001, > > > > > V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002, > > > > > V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003, > > > > > > > > > > @@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode { > > > > > > > > > > V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012, > > > > > V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d, > > > > > V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e, > > > > > > > > > > + V4L2_MBUS_FMT_NV12_1X20 = 0x2014, > > > > > + V4L2_MBUS_FMT_UV8_1X8 = 0x2015, > > > > > > > > NV12, on the bus ? How does that work ? (The documentation should > > > > answer my question :-)) > > > > > > Well, this is on the internal bus not exposed outside, but > > > nevertheless bus between two subdevs or two independent hardware > > > blocks. For example Resizer supports NV12 on its pad. Is there any > > > other way to treat this? > > > > How is NV12 transferred on the bus in that case ? Are all luma samples > > transferred first, followed by all chroma samples ? > > It uses parallel bus of 16 bits, where Y and C are transmitted > simultaneously on 8 bits each. NV12 uses a dummy C byte for every valid > one. > So I guess we call it V4L2_MBUS_FMT_YDYC_1X16 or V4L2_MBUS_FMT_YCYD_1X16? > That way we will be able to document the format in the documentation also. That sounds good (YDYC8_1X16 to be precise). Hans, Guennadi, Sakari, any opinion ? -- Regards, Laurent Pinchart From laurent.pinchart at ideasonboard.com Wed Dec 21 16:23:26 2011 From: laurent.pinchart at ideasonboard.com (Laurent Pinchart) Date: Wed, 21 Dec 2011 23:23:26 +0100 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112210102.09117.laurent.pinchart@ideasonboard.com> Message-ID: <201112212323.26971.laurent.pinchart@ideasonboard.com> Hi Manju, On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote: > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote: > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote: > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format > > > > > frames compressed by A-LAW alogorithm. > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) > > > > > only. > > > > > > > > > > Signed-off-by: Manjunath Hadli > > > > > Cc: Laurent Pinchart > > > > > --- > > > > > > > > > > include/linux/videodev2.h | 6 ++++++ > > > > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > > > > > Could you please also document these formats in > > > > Documentation/DocBook/media/v4l ? > > > > > > I will. Sorry to have missed that out. > > > > > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > > > > > index 4b752d5..969112d 100644 > > > > > --- a/include/linux/videodev2.h > > > > > +++ b/include/linux/videodev2.h > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > > > > > > > > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') /* 8 > > > > > YUV > > > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line > > > > > uv interleaved */ > > > > > > > > > > +/* Chrominance formats */ > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* > > > > > 8 UV 4:4 */ + > > > > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */ > > > > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 > > > > > Y/CbCr > > > > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', > > > > > '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct > > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', > > > > > 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM > > > > > compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8 > > > > > v4l2_fourcc('B', 'D', '1', '0') > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > > > > + > > > > > > > > That's not very future-proof, how would you describe SGBRG10ALAW8 > > > > for instance ? > > > > > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We > > > > have 4 characters, we could start with 'B' to denote Bayer, followed > > > > by one character for the order, one for the compression, and one for > > > > the number of bits. > > > > > > I agree. > > > May be ('B', 'G', 'A', '8') is fine for the above? > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B', > > 'g', 'G' and 'R' respectively for the second character. The third > > character would be 'A' for A-law and 'D' for DPCM, and the fourth > > character could describe the bus width in bits from 0 to 15 with '0' - > > '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses > > for raw Bayer at some point, and a 0 width is definitely not useful. We > > could thus offset the width by some value. > > > > This is just a preliminary idea, I'm open to suggestions. > > I think it is a very good suggestion that we can go with. > B : BGGR > g : GBRG > G : GRBG > R : RGGB > > and 0-F can signify 1-16. Hans, Guennadi, Sakari, any opinion on that as well ? -- Regards, Laurent Pinchart From g.liakhovetski at gmx.de Wed Dec 21 16:46:24 2011 From: g.liakhovetski at gmx.de (Guennadi Liakhovetski) Date: Wed, 21 Dec 2011 23:46:24 +0100 (CET) Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: <201112212323.26971.laurent.pinchart@ideasonboard.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112210102.09117.laurent.pinchart@ideasonboard.com> <201112212323.26971.laurent.pinchart@ideasonboard.com> Message-ID: On Wed, 21 Dec 2011, Laurent Pinchart wrote: > Hi Manju, > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote: > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote: > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote: > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format > > > > > > frames compressed by A-LAW alogorithm. > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) > > > > > > only. > > > > > > > > > > > > Signed-off-by: Manjunath Hadli > > > > > > Cc: Laurent Pinchart > > > > > > --- > > > > > > > > > > > > include/linux/videodev2.h | 6 ++++++ > > > > > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > > > > > > > Could you please also document these formats in > > > > > Documentation/DocBook/media/v4l ? > > > > > > > > I will. Sorry to have missed that out. > > > > > > > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > > > > > > index 4b752d5..969112d 100644 > > > > > > --- a/include/linux/videodev2.h > > > > > > +++ b/include/linux/videodev2.h > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > > > > > > > > > > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') /* 8 > > > > > > YUV > > > > > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line > > > > > > uv interleaved */ > > > > > > > > > > > > +/* Chrominance formats */ > > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* > > > > > > 8 UV 4:4 */ + > > > > > > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */ > > > > > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 > > > > > > Y/CbCr > > > > > > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', > > > > > > '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct > > > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', > > > > > > 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM > > > > > > compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8 > > > > > > v4l2_fourcc('B', 'D', '1', '0') > > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > > > > > + > > > > > > > > > > That's not very future-proof, how would you describe SGBRG10ALAW8 > > > > > for instance ? > > > > > > > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We > > > > > have 4 characters, we could start with 'B' to denote Bayer, followed > > > > > by one character for the order, one for the compression, and one for > > > > > the number of bits. > > > > > > > > I agree. > > > > May be ('B', 'G', 'A', '8') is fine for the above? > > > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B', > > > 'g', 'G' and 'R' respectively for the second character. The third > > > character would be 'A' for A-law and 'D' for DPCM, and the fourth > > > character could describe the bus width in bits from 0 to 15 with '0' - > > > '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses > > > for raw Bayer at some point, and a 0 width is definitely not useful. We > > > could thus offset the width by some value. > > > > > > This is just a preliminary idea, I'm open to suggestions. > > > > I think it is a very good suggestion that we can go with. > > B : BGGR > > g : GBRG > > G : GRBG > > R : RGGB > > > > and 0-F can signify 1-16. > > Hans, Guennadi, Sakari, any opinion on that as well ? Is there any risk of confusion, if we don't reserve the first character for 'B'? I'm just trying to avoid mixed cases, I'm not a great fan of those;-) What if we use the first two characters for the order like "GR", "GB",... AFAICS, 'G' so far only also occurs in GREY and various RGB* / BGR* / ... formats, which we wouldn't be confusing with. We could further reduce confusion, if we use some other character for A-law ('L' or 'W'?) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ From prakash.pm at ti.com Thu Dec 22 03:19:14 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Thu, 22 Dec 2011 14:49:14 +0530 Subject: [PATCH v2] video: da8xx-fb: reset LCDC only if functional clock changes with DVFS Message-ID: <1324545554-20543-1-git-send-email-prakash.pm@ti.com> LCDC functional clock may or may not be derived from CPU/MPU DPLL, For example, AM335x => Separate independent DPLL for LCDC Davinci => Same DPLL as MPU So, on platforms where LCDC functional clock is not derived from CPU/MPU PLL it is not required to reset LCDC module as its functional clock does not change with DVFS. This patch adds check to do reset only if functional clock changes between pre and post notifier callbacks with DVFS. Signed-off-by: Manjunathappa, Prakash --- drivers/video/da8xx-fb.c | 15 ++++++++++----- 1 files changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 6b27751..6146186 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -163,6 +163,7 @@ struct da8xx_fb_par { int vsync_timeout; #ifdef CONFIG_CPU_FREQ struct notifier_block freq_transition; + unsigned int lcd_fck_rate; #endif void (*panel_power_ctrl)(int); }; @@ -895,11 +896,12 @@ static int lcd_da8xx_cpufreq_transition(struct notifier_block *nb, struct da8xx_fb_par *par; par = container_of(nb, struct da8xx_fb_par, freq_transition); - if (val == CPUFREQ_PRECHANGE) { - lcd_disable_raster(); - } else if (val == CPUFREQ_POSTCHANGE) { - lcd_calc_clk_divider(par); - lcd_enable_raster(); + if (val == CPUFREQ_POSTCHANGE) { + if (par->lcd_fck_rate != clk_get_rate(par->lcdc_clk)) { + lcd_disable_raster(); + lcd_calc_clk_divider(par); + lcd_enable_raster(); + } } return 0; @@ -1192,6 +1194,9 @@ static int __devinit fb_probe(struct platform_device *device) par = da8xx_fb_info->par; par->lcdc_clk = fb_clk; +#ifdef CONFIG_CPU_FREQ + par->lcd_fck_rate = clk_get_rate(fb_clk); +#endif par->pxl_clk = lcdc_info->pxl_clk; if (fb_pdata->panel_power_ctrl) { par->panel_power_ctrl = fb_pdata->panel_power_ctrl; -- 1.7.1 From laurent.pinchart at ideasonboard.com Thu Dec 22 04:23:32 2011 From: laurent.pinchart at ideasonboard.com (Laurent Pinchart) Date: Thu, 22 Dec 2011 11:23:32 +0100 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112212323.26971.laurent.pinchart@ideasonboard.com> Message-ID: <201112221123.33315.laurent.pinchart@ideasonboard.com> Hi Guennadi, On Wednesday 21 December 2011 23:46:24 Guennadi Liakhovetski wrote: > On Wed, 21 Dec 2011, Laurent Pinchart wrote: > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote: > > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote: > > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote: > > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer > > > > > > > format frames compressed by A-LAW alogorithm. > > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) > > > > > > > only. > > > > > > > > > > > > > > Signed-off-by: Manjunath Hadli > > > > > > > Cc: Laurent Pinchart > > > > > > > --- > > > > > > > > > > > > > > include/linux/videodev2.h | 6 ++++++ > > > > > > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > > > > > > > > > Could you please also document these formats in > > > > > > Documentation/DocBook/media/v4l ? > > > > > > > > > > I will. Sorry to have missed that out. > > > > > > > > > > > > diff --git a/include/linux/videodev2.h > > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644 > > > > > > > --- a/include/linux/videodev2.h > > > > > > > +++ b/include/linux/videodev2.h > > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > > > > > > > > > > > > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') > > > > > > > /* 8 YUV > > > > > > > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 > > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 > > > > > > > line uv interleaved */ > > > > > > > > > > > > > > +/* Chrominance formats */ > > > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') > > > > > > > /* 8 UV 4:4 */ + > > > > > > > > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */ > > > > > > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') > > > > > > > /* 12 Y/CbCr > > > > > > > > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', > > > > > > > '2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct > > > > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 > > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* > > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define > > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') > > > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > > > > > > + > > > > > > > > > > > > That's not very future-proof, how would you describe SGBRG10ALAW8 > > > > > > for instance ? > > > > > > > > > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We > > > > > > have 4 characters, we could start with 'B' to denote Bayer, > > > > > > followed by one character for the order, one for the > > > > > > compression, and one for the number of bits. > > > > > > > > > > I agree. > > > > > May be ('B', 'G', 'A', '8') is fine for the above? > > > > > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use > > > > 'B', 'g', 'G' and 'R' respectively for the second character. The > > > > third character would be 'A' for A-law and 'D' for DPCM, and the > > > > fourth character could describe the bus width in bits from 0 to 15 > > > > with '0' - '9', 'A' - 'F'. However, I suspect that we will need > > > > 16-bit wide busses for raw Bayer at some point, and a 0 width is > > > > definitely not useful. We could thus offset the width by some value. > > > > > > > > This is just a preliminary idea, I'm open to suggestions. > > > > > > I think it is a very good suggestion that we can go with. > > > B : BGGR > > > g : GBRG > > > G : GRBG > > > R : RGGB > > > > > > and 0-F can signify 1-16. > > > > Hans, Guennadi, Sakari, any opinion on that as well ? > > Is there any risk of confusion, if we don't reserve the first character > for 'B'? I'm just trying to avoid mixed cases, I'm not a great fan of > those;-) FOURCCs are not really supposed to be displayed anyway :-) > What if we use the first two characters for the order like "GR", "GB",... > AFAICS, 'G' so far only also occurs in GREY and various RGB* / BGR* / ... > formats, which we wouldn't be confusing with. Or we could use random FOURCC values as well :-) There could also be other non-Bayer raw formats, such as panchromatic cells or Foveon patterns. I don't know if we need to plan for them already. > We could further reduce confusion, if we use some other character for A-law > ('L' or 'W'?) We could also have ?-law compression, L and W would be ambiguous. -- Regards, Laurent Pinchart From nsekhar at ti.com Thu Dec 22 06:27:16 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 22 Dec 2011 12:27:16 +0000 Subject: [PATCH v2] davinci: DA850 EVM: OHCI platform code In-Reply-To: <4EF1D011.8060103@mvista.com> References: <1324452002-8388-1-git-send-email-prakash.pm@ti.com> <4EF1CB8A.10309@mvista.com> <4EF1D011.8060103@mvista.com> Message-ID: On Wed, Dec 21, 2011 at 17:54:49, Sergei Shtylyov wrote: > Hello. > > On 21-12-2011 16:05, I wrote: > > >> On Wed, Dec 21, 2011 at 12:50:02, Manjunathappa, Prakash wrote: > >>> From: Ajay Kumar Gupta > > >>> On this board the OHCI port's power control and over-current signals from > >>> TPS2065 power switch are connected via GPIO2[4] and GPIO6[13] respectively, > >>> so we can implement the DA8xx OHCI glue layer's hooks for overriding the > >>> root hub port's power and over-current status bits. > > >>> We also have to properly set up the clocking mode in the CFGCHIP2 register, > >>> so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and > >>> its output is used to clock the USB 1.1 (OHCI) PHY... > > >>> Signed-off-by: Ajay Kumar Gupta > >>> Signed-off-by: Manjunathappa, Prakash > > >> This is the third copy of OHCI platform setup code which is almost > >> the same except for the GPIO numbers. > > > Well, in my counting, it's only second, DA830 EVM being the first one. > > What's the third? > > Ah, I missed Hawkboard... :-) > > > I designed the hub interface to be as abstract as I could, and now you're > > proposing to add GPIO to it? No, I have no clear idea how to keeep it > > abstract and add GPIO support at the same time. I would have been grateful to > > TI if I didn't have to invent this at all and they stop saving on OHCI pins. > > Well, I have one idea. We can create a separate module in > arch/arm/mach-davinci/, named say ohci.c, put the shared code there and pass > to it the GPIOs actually used via a function call. Or maybe use existing > arch/arm/mach-davinci/usb.c. Thanks Sergei. I think using the existing usb.c would be a better idea. Prakash, Can you please go ahead with this approach and post updated patches. Thanks, Sekhar From nsekhar at ti.com Thu Dec 22 07:10:01 2011 From: nsekhar at ti.com (Nori, Sekhar) Date: Thu, 22 Dec 2011 13:10:01 +0000 Subject: [PATCH v7 1/8] davinci: vpif: remove machine specific inclusion from driver In-Reply-To: <1324475021-32509-2-git-send-email-manjunath.hadli@ti.com> References: <1324475021-32509-1-git-send-email-manjunath.hadli@ti.com> <1324475021-32509-2-git-send-email-manjunath.hadli@ti.com> Message-ID: Hi Manju, On Wed, Dec 21, 2011 at 19:13:34, Hadli, Manjunath wrote: > remove machine specific inclusion from the driver which > comes in the way of platform code consolidation. I think it would be more readable to use the term "header file" here and in the headline. Just "machine specific inclusion" begs the question - "inclusion of what?" > currently was seen that these header inclusions were > not necessary. Sorry about nit-picking, but it is not good to talk in past tense in commit text. Past tense is natural for you to use since you write the text after making the changes, but for the reviewer it is not natural since he is seeing the commit text and the patch both at once. Also, usage of "currently" in above line is not necessary. It is assumed that commit text talks about current state of affairs. I would have made these changes myself after Mauro's ack, but.. > > Signed-off-by: Manjunath Hadli > Cc: Mauro Carvalho Chehab > Cc: LMML > --- > drivers/media/video/davinci/vpif.h | 2 -- > drivers/media/video/davinci/vpif_display.c | 2 -- > include/media/davinci/vpif_types.h | 2 ++ > sound/soc/codecs/cq93vc.c | 2 -- .. you clubbed this unrelated sound/soc/ change in this patch. First, the change is not related to VPIF in any way so it has no business being in this patch. Second, there is no way the sound/soc folks will have a look at this patch, so basically the change will end up bypassing the right maintainers if other reviewers fail to catch it. Please separate the change into another patch. You can just post the two patches alone copying the right maintainers in each instead of posting the entire series again. Thanks, Sekhar From prakash.pm at ti.com Fri Dec 23 07:15:28 2011 From: prakash.pm at ti.com (Manjunathappa, Prakash) Date: Fri, 23 Dec 2011 13:15:28 +0000 Subject: [PATCH v2] davinci: DA850 EVM: OHCI platform code In-Reply-To: References: <1324452002-8388-1-git-send-email-prakash.pm@ti.com> <4EF1CB8A.10309@mvista.com> <4EF1D011.8060103@mvista.com> Message-ID: On Thu, Dec 22, 2011 at 17:57:16, Nori, Sekhar wrote: [...] > > > > Well, I have one idea. We can create a separate module in > > arch/arm/mach-davinci/, named say ohci.c, put the shared code there and pass > > to it the GPIOs actually used via a function call. Or maybe use existing > > arch/arm/mach-davinci/usb.c. > > Thanks Sergei. I think using the existing usb.c would be a better idea. > > Prakash, > > Can you please go ahead with this approach and post updated patches. > > Thanks, > Sekhar > Ok I will create abstract function and post the new set of patches. Thanks, Prakash From nsekhar at ti.com Fri Dec 23 11:57:19 2011 From: nsekhar at ti.com (Sekhar Nori) Date: Fri, 23 Dec 2011 23:27:19 +0530 Subject: [PATCH 1/2] ARM: davinci: time.c: group related header files together Message-ID: <1324663040-2859-1-git-send-email-nsekhar@ti.com> Rearrange header files to keep related header files together. Signed-off-by: Sekhar Nori --- arch/arm/mach-davinci/time.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c index e1969ce..f2afb2d 100644 --- a/arch/arm/mach-davinci/time.c +++ b/arch/arm/mach-davinci/time.c @@ -19,11 +19,13 @@ #include #include -#include #include #include + #include +#include #include + #include "clock.h" static struct clock_event_device clockevent_davinci; -- 1.6.2.4 From nsekhar at ti.com Fri Dec 23 11:57:20 2011 From: nsekhar at ti.com (Sekhar Nori) Date: Fri, 23 Dec 2011 23:27:20 +0530 Subject: [PATCH 2/2] ARM: davinci: convert sched_clock() to use common infrastructure In-Reply-To: <1324663040-2859-1-git-send-email-nsekhar@ti.com> References: <1324663040-2859-1-git-send-email-nsekhar@ti.com> Message-ID: <1324663040-2859-2-git-send-email-nsekhar@ti.com> Convert davinci to use the common sched_clock() infrastructure for extending 32bit counters to full 64-bit nanoseconds. Eventually clocksource timer should be initialized from init_early so there would be no need to use a dummy clocksource read at start. Tested-by: Murali Karicheri Signed-off-by: Sekhar Nori --- arch/arm/Kconfig | 1 + arch/arm/mach-davinci/time.c | 15 ++++++++++++--- 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 776d76b..3304316 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -925,6 +925,7 @@ config ARCH_DAVINCI select ARCH_REQUIRE_GPIOLIB select ZONE_DMA select HAVE_IDE + select HAVE_SCHED_CLOCK select CLKDEV_LOOKUP select GENERIC_ALLOCATOR select GENERIC_IRQ_CHIP diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c index f2afb2d..e7d8b52 100644 --- a/arch/arm/mach-davinci/time.c +++ b/arch/arm/mach-davinci/time.c @@ -19,6 +19,7 @@ #include #include +#include #include #include @@ -291,15 +292,21 @@ static struct clocksource clocksource_davinci = { .flags = CLOCK_SOURCE_IS_CONTINUOUS, }; +static DEFINE_CLOCK_DATA(cd); + /* * Overwrite weak default sched_clock with something more precise */ unsigned long long notrace sched_clock(void) { - const cycle_t cyc = clocksource_davinci.read(&clocksource_davinci); + u32 cyc = clocksource_davinci.read(&clocksource_davinci); + return cyc_to_sched_clock(&cd, cyc, (u32)~0); +} - return clocksource_cyc2ns(cyc, clocksource_davinci.mult, - clocksource_davinci.shift); +static void notrace davinci_update_sched_clock(void) +{ + u32 cyc = timer32_read(&timers[TID_CLOCKSOURCE]); + update_sched_clock(&cd, cyc, (u32)~0); } /* @@ -401,6 +408,8 @@ static void __init davinci_timer_init(void) /* setup clocksource */ clocksource_davinci.read = read_cycles; clocksource_davinci.name = id_to_name[clocksource_id]; + init_sched_clock(&cd, davinci_update_sched_clock, 32, + davinci_clock_tick_rate); if (clocksource_register_hz(&clocksource_davinci, davinci_clock_tick_rate)) printk(err, clocksource_davinci.name); -- 1.6.2.4 From sujeshlx at gmail.com Tue Dec 27 07:59:20 2011 From: sujeshlx at gmail.com (sujesh.k.p kp) Date: Tue, 27 Dec 2011 19:29:20 +0530 Subject: how to configure gpio as interrupt Message-ID: hai all, please tell how to configure gpio as interrupt with regards sujesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From sreecha01 at gmail.com Tue Dec 27 14:04:17 2011 From: sreecha01 at gmail.com (Appalayagari Sreedhar) Date: Wed, 28 Dec 2011 01:34:17 +0530 Subject: how to configure gpio as interrupt In-Reply-To: References: Message-ID: Hi Sujesh, I suggest you can refer to any WiFi or Touch controller driver software in kernel. You can learn how to configure the gpio as interrupt. It is very simple dude you can easily do it with little effort. All the Best, Sreedhar. On 12/27/11, sujesh.k.p kp wrote: > hai all, > please tell how to configure gpio as interrupt > > with regards sujesh > From nsekhar at ti.com Wed Dec 28 00:32:57 2011 From: nsekhar at ti.com (Sekhar Nori) Date: Wed, 28 Dec 2011 12:02:57 +0530 Subject: [PATCH 1/1] usb: musb: davinci: fix build breakage Message-ID: <8a79643d234d8357b39b513bce73d7b00851f921.1325053572.git.nsekhar@ti.com> Commit 0020afb369859472a461ef4af6410732e929d402 (ARM: mach-davinci: remove mach/memory.h) removed mach/memory.h for DaVinci which broke DaVinci MUSB build. mach/memory.h is not actually needed in davinci.c, so remove it. While at it, also remove some more machine specific inclulde files which are not needed for build. Tested on DM644x EVM using USB card reader. Signed-off-by: Sekhar Nori --- Hopefully this is not too late for v3.2. If it is late, please apply stable tag for v3.2.x while comitting. drivers/usb/musb/davinci.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c index f9a3f62..7c569f5 100644 --- a/drivers/usb/musb/davinci.c +++ b/drivers/usb/musb/davinci.c @@ -33,9 +33,6 @@ #include #include -#include -#include -#include #include #include -- 1.7.0.4 From sakari.ailus at iki.fi Wed Dec 28 05:16:27 2011 From: sakari.ailus at iki.fi (Sakari Ailus) Date: Wed, 28 Dec 2011 13:16:27 +0200 Subject: [PATCH 2/2] v4l2: add new pixel formats supported on dm365 In-Reply-To: <201112212323.26971.laurent.pinchart@ideasonboard.com> References: <1323951898-16330-1-git-send-email-manjunath.hadli@ti.com> <201112210102.09117.laurent.pinchart@ideasonboard.com> <201112212323.26971.laurent.pinchart@ideasonboard.com> Message-ID: <20111228111627.GT3677@valkosipuli.localdomain> Hi Laurent, On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote: > Hi Manju, > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote: > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote: > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote: > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote: > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote: > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format > > > > > > frames compressed by A-LAW alogorithm. > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) > > > > > > only. > > > > > > > > > > > > Signed-off-by: Manjunath Hadli > > > > > > Cc: Laurent Pinchart > > > > > > --- > > > > > > > > > > > > include/linux/videodev2.h | 6 ++++++ > > > > > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > > > > > > > Could you please also document these formats in > > > > > Documentation/DocBook/media/v4l ? > > > > > > > > I will. Sorry to have missed that out. > > > > > > > > > > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h > > > > > > index 4b752d5..969112d 100644 > > > > > > --- a/include/linux/videodev2.h > > > > > > +++ b/include/linux/videodev2.h > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format { > > > > > > > > > > > > #define V4L2_PIX_FMT_HM12 v4l2_fourcc('H', 'M', '1', '2') /* 8 > > > > > > YUV > > > > > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420 > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line > > > > > > uv interleaved */ > > > > > > > > > > > > +/* Chrominance formats */ > > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* > > > > > > 8 UV 4:4 */ + > > > > > > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */ > > > > > > #define V4L2_PIX_FMT_NV12 v4l2_fourcc('N', 'V', '1', '2') /* 12 > > > > > > Y/CbCr > > > > > > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21 v4l2_fourcc('N', 'V', '2', > > > > > > '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct > > > > > > v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', > > > > > > 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM > > > > > > compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8 > > > > > > v4l2_fourcc('B', 'D', '1', '0') > > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8') > > > > > > + > > > > > > > > > > That's not very future-proof, how would you describe SGBRG10ALAW8 > > > > > for instance ? > > > > > > > > > > Maybe it's time to standardize FOURCCs for Bayer new formats. We > > > > > have 4 characters, we could start with 'B' to denote Bayer, followed > > > > > by one character for the order, one for the compression, and one for > > > > > the number of bits. > > > > > > > > I agree. > > > > May be ('B', 'G', 'A', '8') is fine for the above? > > > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B', > > > 'g', 'G' and 'R' respectively for the second character. The third > > > character would be 'A' for A-law and 'D' for DPCM, and the fourth > > > character could describe the bus width in bits from 0 to 15 with '0' - > > > '9', 'A' - 'F'. However, I suspect that we will need 16-bit wide busses > > > for raw Bayer at some point, and a 0 width is definitely not useful. We > > > could thus offset the width by some value. > > > > > > This is just a preliminary idea, I'm open to suggestions. > > > > I think it is a very good suggestion that we can go with. > > B : BGGR > > g : GBRG > > G : GRBG > > R : RGGB > > > > and 0-F can signify 1-16. > > Hans, Guennadi, Sakari, any opinion on that as well ? I think four letters simply aren't enough to universally describe a media bus format in a human-readable way. We can aim to that, but we will have to make compromises. For example, DPCM compressed format has two important parameters beyond pixel order and the colour space, the uncompressed depth and the compressed depth. Typically one doesn't compress the data too much, but things like 10-to-6 bits are well possible. Could we use a single letter to tell that a format is both bayer and DPCM compressed? I'd go for 'b'. Raw bayer alaw could be denoted by 'a'. Then raw bayer, GBRG pixel order 10-to-7 bits would be called "bgA7". The same in Alaw would be "agA7". What do you think? -- Sakari Ailus e-mail: sakari.ailus at iki.fi jabber/XMPP/Gmail: sailus at retiisi.org.uk From nsekhar at ti.com Thu Dec 29 06:50:26 2011 From: nsekhar at ti.com (Sekhar Nori) Date: Thu, 29 Dec 2011 18:20:26 +0530 Subject: [PATCH 0/3] ARM: davinci: initialize timer early Message-ID: This patch series initializes the DaVinci timer early so sched_clock() doesnt have to use a dummy clock before switch to real clock. Also, switch to using the driver available in kernel for simple MMIO clocksources. The patch series depends on the patch "ARM: davinci: convert sched_clock() to use common infrastructure" submitted earlier. The patch series has been tested on DM644x, DM646x, DM365, DM355, AM17x and AM18x EVMs. Sekhar Nori (3): ARM: davinci: fix indentation using spaces ARM: davinci: initialize timer early ARM: davinci: use mmio clocksource implementation arch/arm/Kconfig | 1 + arch/arm/mach-davinci/board-da830-evm.c | 1 + arch/arm/mach-davinci/board-da850-evm.c | 1 + arch/arm/mach-davinci/board-dm355-evm.c | 11 ++- arch/arm/mach-davinci/board-dm355-leopard.c | 11 ++- arch/arm/mach-davinci/board-dm365-evm.c | 1 + arch/arm/mach-davinci/board-dm644x-evm.c | 11 ++- arch/arm/mach-davinci/board-dm646x-evm.c | 22 +++--- arch/arm/mach-davinci/board-mityomapl138.c | 1 + arch/arm/mach-davinci/board-neuros-osd2.c | 5 +- arch/arm/mach-davinci/board-omapl138-hawk.c | 1 + arch/arm/mach-davinci/board-sffsdr.c | 11 ++- arch/arm/mach-davinci/board-tnetv107x-evm.c | 1 + arch/arm/mach-davinci/include/mach/common.h | 2 + arch/arm/mach-davinci/time.c | 115 ++++++++++++--------------- 15 files changed, 99 insertions(+), 96 deletions(-) From nsekhar at ti.com Thu Dec 29 06:50:29 2011 From: nsekhar at ti.com (Sekhar Nori) Date: Thu, 29 Dec 2011 18:20:29 +0530 Subject: [PATCH 3/3] ARM: davinci: use mmio clocksource implementation In-Reply-To: References: Message-ID: Switch to using the simple MMIO clocksource driver provided by kernel. Signed-off-by: Sekhar Nori --- arch/arm/Kconfig | 1 + arch/arm/mach-davinci/time.c | 30 ++++++++---------------------- 2 files changed, 9 insertions(+), 22 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3304316..69e97e8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -927,6 +927,7 @@ config ARCH_DAVINCI select HAVE_IDE select HAVE_SCHED_CLOCK select CLKDEV_LOOKUP + select CLKSRC_MMIO select GENERIC_ALLOCATOR select GENERIC_IRQ_CHIP select ARCH_HAS_HOLES_MEMORYMODEL diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c index f307b7d..876e5d7 100644 --- a/arch/arm/mach-davinci/time.c +++ b/arch/arm/mach-davinci/time.c @@ -264,20 +264,6 @@ static void __init timer_hw_init(void) /* * clocksource */ -static cycle_t read_cycles(struct clocksource *cs) -{ - struct timer_s *t = &timers[TID_CLOCKSOURCE]; - - return (cycles_t)timer32_read(t); -} - -static struct clocksource clocksource_davinci = { - .rating = 300, - .read = read_cycles, - .mask = CLOCKSOURCE_MASK(32), - .flags = CLOCK_SOURCE_IS_CONTINUOUS, -}; - static DEFINE_CLOCK_DATA(cd); /* @@ -347,8 +333,6 @@ void __init davinci_timer_early_init(void) struct davinci_soc_info *soc_info = &davinci_soc_info; unsigned int clockevent_id; unsigned int clocksource_id; - static char err[] __initdata = KERN_ERR - "%s: can't register clocksource!\n"; clockevent_id = soc_info->timer_info->clockevent_id; clocksource_id = soc_info->timer_info->clocksource_id; @@ -382,20 +366,16 @@ void __init davinci_timer_early_init(void) timer_hw_init(); - /* setup clocksource */ - clocksource_davinci.read = read_cycles; - clocksource_davinci.name = id_to_name[clocksource_id]; init_sched_clock(&cd, davinci_update_sched_clock, 32, davinci_clock_tick_rate); - if (clocksource_register_hz(&clocksource_davinci, - davinci_clock_tick_rate)) - printk(err, clocksource_davinci.name); } static void __init davinci_timer_late_init(void) { struct davinci_soc_info *soc_info = &davinci_soc_info; struct davinci_timer_instance *dtip = soc_info->timer_info->timers; + void __iomem *clocksource_reg = timers[TID_CLOCKSOURCE].base + + timers[TID_CLOCKSOURCE].tim_off; int i; for (i = 0; i < ARRAY_SIZE(timers); i++) { @@ -418,6 +398,12 @@ static void __init davinci_timer_late_init(void) } } + /* setup clocksource */ + clocksource_mmio_init(clocksource_reg, + id_to_name[timers[TID_CLOCKSOURCE].id], + davinci_clock_tick_rate, 300, 32, + clocksource_mmio_readl_up); + /* setup clockevent */ clockevent_davinci.name = id_to_name[timers[TID_CLOCKEVENT].id]; clockevent_davinci.mult = div_sc(davinci_clock_tick_rate, NSEC_PER_SEC, -- 1.7.0.4 From nsekhar at ti.com Thu Dec 29 06:50:27 2011 From: nsekhar at ti.com (Sekhar Nori) Date: Thu, 29 Dec 2011 18:20:27 +0530 Subject: [PATCH 1/3] ARM: davinci: fix indentation using spaces In-Reply-To: References: Message-ID: Several board files use spaces for indentation in machine descriptor structure. Fix it to use tabs instead. Signed-off-by: Sekhar Nori --- arch/arm/mach-davinci/board-dm355-evm.c | 10 +++++----- arch/arm/mach-davinci/board-dm355-leopard.c | 10 +++++----- arch/arm/mach-davinci/board-dm644x-evm.c | 10 +++++----- arch/arm/mach-davinci/board-dm646x-evm.c | 20 ++++++++++---------- arch/arm/mach-davinci/board-neuros-osd2.c | 4 ++-- arch/arm/mach-davinci/board-sffsdr.c | 10 +++++----- 6 files changed, 32 insertions(+), 32 deletions(-) diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index 4e0e707..10107f6 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -351,10 +351,10 @@ static __init void dm355_evm_init(void) } MACHINE_START(DAVINCI_DM355_EVM, "DaVinci DM355 EVM") - .atag_offset = 0x100, - .map_io = dm355_evm_map_io, - .init_irq = davinci_irq_init, - .timer = &davinci_timer, - .init_machine = dm355_evm_init, + .atag_offset = 0x100, + .map_io = dm355_evm_map_io, + .init_irq = davinci_irq_init, + .timer = &davinci_timer, + .init_machine = dm355_evm_init, .dma_zone_size = SZ_128M, MACHINE_END diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c index ff2d241..286243b 100644 --- a/arch/arm/mach-davinci/board-dm355-leopard.c +++ b/arch/arm/mach-davinci/board-dm355-leopard.c @@ -270,10 +270,10 @@ static __init void dm355_leopard_init(void) } MACHINE_START(DM355_LEOPARD, "DaVinci DM355 leopard") - .atag_offset = 0x100, - .map_io = dm355_leopard_map_io, - .init_irq = davinci_irq_init, - .timer = &davinci_timer, - .init_machine = dm355_leopard_init, + .atag_offset = 0x100, + .map_io = dm355_leopard_map_io, + .init_irq = davinci_irq_init, + .timer = &davinci_timer, + .init_machine = dm355_leopard_init, .dma_zone_size = SZ_128M, MACHINE_END diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 0cf8abf..40f6437 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -713,10 +713,10 @@ static __init void davinci_evm_init(void) MACHINE_START(DAVINCI_EVM, "DaVinci DM644x EVM") /* Maintainer: MontaVista Software */ - .atag_offset = 0x100, - .map_io = davinci_evm_map_io, - .init_irq = davinci_irq_init, - .timer = &davinci_timer, - .init_machine = davinci_evm_init, + .atag_offset = 0x100, + .map_io = davinci_evm_map_io, + .init_irq = davinci_irq_init, + .timer = &davinci_timer, + .init_machine = davinci_evm_init, .dma_zone_size = SZ_128M, MACHINE_END diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 635bf77..309040a 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -793,20 +793,20 @@ static __init void evm_init(void) } MACHINE_START(DAVINCI_DM6467_EVM, "DaVinci DM646x EVM") - .atag_offset = 0x100, - .map_io = davinci_map_io, - .init_irq = davinci_irq_init, - .timer = &davinci_timer, - .init_machine = evm_init, + .atag_offset = 0x100, + .map_io = davinci_map_io, + .init_irq = davinci_irq_init, + .timer = &davinci_timer, + .init_machine = evm_init, .dma_zone_size = SZ_128M, MACHINE_END MACHINE_START(DAVINCI_DM6467TEVM, "DaVinci DM6467T EVM") - .atag_offset = 0x100, - .map_io = davinci_map_io, - .init_irq = davinci_irq_init, - .timer = &davinci_timer, - .init_machine = evm_init, + .atag_offset = 0x100, + .map_io = davinci_map_io, + .init_irq = davinci_irq_init, + .timer = &davinci_timer, + .init_machine = evm_init, .dma_zone_size = SZ_128M, MACHINE_END diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c index e5f231a..b5e9aca 100644 --- a/arch/arm/mach-davinci/board-neuros-osd2.c +++ b/arch/arm/mach-davinci/board-neuros-osd2.c @@ -273,9 +273,9 @@ static __init void davinci_ntosd2_init(void) MACHINE_START(NEUROS_OSD2, "Neuros OSD2") /* Maintainer: Neuros Technologies */ .atag_offset = 0x100, - .map_io = davinci_ntosd2_map_io, + .map_io = davinci_ntosd2_map_io, .init_irq = davinci_irq_init, .timer = &davinci_timer, - .init_machine = davinci_ntosd2_init, + .init_machine = davinci_ntosd2_init, .dma_zone_size = SZ_128M, MACHINE_END diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c index 5dd4da9..d15d161 100644 --- a/arch/arm/mach-davinci/board-sffsdr.c +++ b/arch/arm/mach-davinci/board-sffsdr.c @@ -151,10 +151,10 @@ static __init void davinci_sffsdr_init(void) MACHINE_START(SFFSDR, "Lyrtech SFFSDR") /* Maintainer: Hugo Villeneuve hugo.villeneuve at lyrtech.com */ - .atag_offset = 0x100, - .map_io = davinci_sffsdr_map_io, - .init_irq = davinci_irq_init, - .timer = &davinci_timer, - .init_machine = davinci_sffsdr_init, + .atag_offset = 0x100, + .map_io = davinci_sffsdr_map_io, + .init_irq = davinci_irq_init, + .timer = &davinci_timer, + .init_machine = davinci_sffsdr_init, .dma_zone_size = SZ_128M, MACHINE_END -- 1.7.0.4 From nsekhar at ti.com Thu Dec 29 06:50:28 2011 From: nsekhar at ti.com (Sekhar Nori) Date: Thu, 29 Dec 2011 18:20:28 +0530 Subject: [PATCH 2/3] ARM: davinci: initialize timer early In-Reply-To: References: Message-ID: <0c6d18b50582307a85cc911131ada30eb5bf4d03.1325162372.git.nsekhar@ti.com> Initialize timer early so it can be used in sched_clock straightaway instead of starting with a dummy timer. To do this, timer hardware initialization is seperated out from clocksource, clockevent and irq setup which come in as part of a "late" init. Signed-off-by: Sekhar Nori --- arch/arm/mach-davinci/board-da830-evm.c | 1 + arch/arm/mach-davinci/board-da850-evm.c | 1 + arch/arm/mach-davinci/board-dm355-evm.c | 1 + arch/arm/mach-davinci/board-dm355-leopard.c | 1 + arch/arm/mach-davinci/board-dm365-evm.c | 1 + arch/arm/mach-davinci/board-dm644x-evm.c | 1 + arch/arm/mach-davinci/board-dm646x-evm.c | 2 + arch/arm/mach-davinci/board-mityomapl138.c | 1 + arch/arm/mach-davinci/board-neuros-osd2.c | 1 + arch/arm/mach-davinci/board-omapl138-hawk.c | 1 + arch/arm/mach-davinci/board-sffsdr.c | 1 + arch/arm/mach-davinci/board-tnetv107x-evm.c | 1 + arch/arm/mach-davinci/include/mach/common.h | 2 + arch/arm/mach-davinci/time.c | 89 ++++++++++++++------------- 14 files changed, 60 insertions(+), 44 deletions(-) diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index 11c3db9..83e194b 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -678,6 +678,7 @@ static void __init da830_evm_map_io(void) MACHINE_START(DAVINCI_DA830_EVM, "DaVinci DA830/OMAP-L137/AM17x EVM") .atag_offset = 0x100, .map_io = da830_evm_map_io, + .init_early = davinci_timer_early_init, .init_irq = cp_intc_init, .timer = &davinci_timer, .init_machine = da830_evm_init, diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 6659a90..97c23b4 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -1407,6 +1407,7 @@ static void __init da850_evm_map_io(void) MACHINE_START(DAVINCI_DA850_EVM, "DaVinci DA850/OMAP-L138/AM18x EVM") .atag_offset = 0x100, .map_io = da850_evm_map_io, + .init_early = davinci_timer_early_init, .init_irq = cp_intc_init, .timer = &davinci_timer, .init_machine = da850_evm_init, diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c index 10107f6..8138cb9 100644 --- a/arch/arm/mach-davinci/board-dm355-evm.c +++ b/arch/arm/mach-davinci/board-dm355-evm.c @@ -353,6 +353,7 @@ static __init void dm355_evm_init(void) MACHINE_START(DAVINCI_DM355_EVM, "DaVinci DM355 EVM") .atag_offset = 0x100, .map_io = dm355_evm_map_io, + .init_early = davinci_timer_early_init, .init_irq = davinci_irq_init, .timer = &davinci_timer, .init_machine = dm355_evm_init, diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-davinci/board-dm355-leopard.c index 286243b..5e312e2 100644 --- a/arch/arm/mach-davinci/board-dm355-leopard.c +++ b/arch/arm/mach-davinci/board-dm355-leopard.c @@ -272,6 +272,7 @@ static __init void dm355_leopard_init(void) MACHINE_START(DM355_LEOPARD, "DaVinci DM355 leopard") .atag_offset = 0x100, .map_io = dm355_leopard_map_io, + .init_early = davinci_timer_early_init, .init_irq = davinci_irq_init, .timer = &davinci_timer, .init_machine = dm355_leopard_init, diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-davinci/board-dm365-evm.c index 46e1f41..e74f4e9 100644 --- a/arch/arm/mach-davinci/board-dm365-evm.c +++ b/arch/arm/mach-davinci/board-dm365-evm.c @@ -614,6 +614,7 @@ static __init void dm365_evm_init(void) MACHINE_START(DAVINCI_DM365_EVM, "DaVinci DM365 EVM") .atag_offset = 0x100, .map_io = dm365_evm_map_io, + .init_early = davinci_timer_early_init, .init_irq = davinci_irq_init, .timer = &davinci_timer, .init_machine = dm365_evm_init, diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c index 40f6437..8e9caef 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c @@ -715,6 +715,7 @@ MACHINE_START(DAVINCI_EVM, "DaVinci DM644x EVM") /* Maintainer: MontaVista Software */ .atag_offset = 0x100, .map_io = davinci_evm_map_io, + .init_early = davinci_timer_early_init, .init_irq = davinci_irq_init, .timer = &davinci_timer, .init_machine = davinci_evm_init, diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c index 309040a..500c092 100644 --- a/arch/arm/mach-davinci/board-dm646x-evm.c +++ b/arch/arm/mach-davinci/board-dm646x-evm.c @@ -795,6 +795,7 @@ static __init void evm_init(void) MACHINE_START(DAVINCI_DM6467_EVM, "DaVinci DM646x EVM") .atag_offset = 0x100, .map_io = davinci_map_io, + .init_early = davinci_timer_early_init, .init_irq = davinci_irq_init, .timer = &davinci_timer, .init_machine = evm_init, @@ -804,6 +805,7 @@ MACHINE_END MACHINE_START(DAVINCI_DM6467TEVM, "DaVinci DM6467T EVM") .atag_offset = 0x100, .map_io = davinci_map_io, + .init_early = davinci_timer_early_init, .init_irq = davinci_irq_init, .timer = &davinci_timer, .init_machine = evm_init, diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c index 3cfff55..2f48d85 100644 --- a/arch/arm/mach-davinci/board-mityomapl138.c +++ b/arch/arm/mach-davinci/board-mityomapl138.c @@ -569,6 +569,7 @@ static void __init mityomapl138_map_io(void) MACHINE_START(MITYOMAPL138, "MityDSP-L138/MityARM-1808") .atag_offset = 0x100, .map_io = mityomapl138_map_io, + .init_early = davinci_timer_early_init, .init_irq = cp_intc_init, .timer = &davinci_timer, .init_machine = mityomapl138_init, diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c index b5e9aca..118ff8e 100644 --- a/arch/arm/mach-davinci/board-neuros-osd2.c +++ b/arch/arm/mach-davinci/board-neuros-osd2.c @@ -274,6 +274,7 @@ MACHINE_START(NEUROS_OSD2, "Neuros OSD2") /* Maintainer: Neuros Technologies */ .atag_offset = 0x100, .map_io = davinci_ntosd2_map_io, + .init_early = davinci_timer_early_init, .init_irq = davinci_irq_init, .timer = &davinci_timer, .init_machine = davinci_ntosd2_init, diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c index c6701e4..11b3f29 100644 --- a/arch/arm/mach-davinci/board-omapl138-hawk.c +++ b/arch/arm/mach-davinci/board-omapl138-hawk.c @@ -340,6 +340,7 @@ static void __init omapl138_hawk_map_io(void) MACHINE_START(OMAPL138_HAWKBOARD, "AM18x/OMAP-L138 Hawkboard") .atag_offset = 0x100, .map_io = omapl138_hawk_map_io, + .init_early = davinci_timer_early_init, .init_irq = cp_intc_init, .timer = &davinci_timer, .init_machine = omapl138_hawk_init, diff --git a/arch/arm/mach-davinci/board-sffsdr.c b/arch/arm/mach-davinci/board-sffsdr.c index d15d161..53c648b 100644 --- a/arch/arm/mach-davinci/board-sffsdr.c +++ b/arch/arm/mach-davinci/board-sffsdr.c @@ -153,6 +153,7 @@ MACHINE_START(SFFSDR, "Lyrtech SFFSDR") /* Maintainer: Hugo Villeneuve hugo.villeneuve at lyrtech.com */ .atag_offset = 0x100, .map_io = davinci_sffsdr_map_io, + .init_early = davinci_timer_early_init, .init_irq = davinci_irq_init, .timer = &davinci_timer, .init_machine = davinci_sffsdr_init, diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c b/arch/arm/mach-davinci/board-tnetv107x-evm.c index f69e40a..df92f24 100644 --- a/arch/arm/mach-davinci/board-tnetv107x-evm.c +++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c @@ -279,6 +279,7 @@ console_initcall(tnetv107x_evm_console_init); MACHINE_START(TNETV107X, "TNETV107X EVM") .atag_offset = 0x100, .map_io = tnetv107x_init, + .init_early = davinci_timer_early_init, .init_irq = cp_intc_init, .timer = &davinci_timer, .init_machine = tnetv107x_evm_board_init, diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h index a57cba2..9f73358 100644 --- a/arch/arm/mach-davinci/include/mach/common.h +++ b/arch/arm/mach-davinci/include/mach/common.h @@ -37,6 +37,8 @@ struct davinci_timer_info { unsigned int clocksource_id; }; +void __init davinci_timer_early_init(void); + struct davinci_gpio_controller; /* diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c index e7d8b52..f307b7d 100644 --- a/arch/arm/mach-davinci/time.c +++ b/arch/arm/mach-davinci/time.c @@ -196,13 +196,20 @@ static struct timer_s timers[] = { }, }; -static void __init timer_init(void) +static void __init timer_hw_init(void) { struct davinci_soc_info *soc_info = &davinci_soc_info; struct davinci_timer_instance *dtip = soc_info->timer_info->timers; + struct clk *timer_clk; void __iomem *base[2]; int i; + timer_clk = clk_get(NULL, "timer0"); + BUG_ON(IS_ERR(timer_clk)); + clk_enable(timer_clk); + + davinci_clock_tick_rate = clk_get_rate(timer_clk); + /* Global init of each 64-bit timer as a whole */ for(i=0; i<2; i++) { u32 tgcr; @@ -236,7 +243,6 @@ static void __init timer_init(void) for (i=0; i< ARRAY_SIZE(timers); i++) { struct timer_s *t = &timers[i]; int timer = ID_TO_TIMER(t->id); - u32 irq; t->base = base[timer]; if (!t->base) @@ -246,22 +252,12 @@ static void __init timer_init(void) t->enamode_shift = 6; t->tim_off = TIM12; t->prd_off = PRD12; - irq = dtip[timer].bottom_irq; } else { t->enamode_shift = 22; t->tim_off = TIM34; t->prd_off = PRD34; - irq = dtip[timer].top_irq; - } - - /* Register interrupt */ - t->irqaction.name = t->name; - t->irqaction.dev_id = (void *)t; - - if (t->irqaction.handler != NULL) { - irq = USING_COMPARE(t) ? dtip[i].cmp_irq : irq; - setup_irq(irq, &t->irqaction); } + timer32_config(t); } } @@ -275,19 +271,9 @@ static cycle_t read_cycles(struct clocksource *cs) return (cycles_t)timer32_read(t); } -/* - * Kernel assumes that sched_clock can be called early but may not have - * things ready yet. - */ -static cycle_t read_dummy(struct clocksource *cs) -{ - return 0; -} - - static struct clocksource clocksource_davinci = { .rating = 300, - .read = read_dummy, + .read = read_cycles, .mask = CLOCKSOURCE_MASK(32), .flags = CLOCK_SOURCE_IS_CONTINUOUS, }; @@ -299,7 +285,7 @@ static DEFINE_CLOCK_DATA(cd); */ unsigned long long notrace sched_clock(void) { - u32 cyc = clocksource_davinci.read(&clocksource_davinci); + u32 cyc = timer32_read(&timers[TID_CLOCKSOURCE]); return cyc_to_sched_clock(&cd, cyc, (u32)~0); } @@ -356,15 +342,13 @@ static struct clock_event_device clockevent_davinci = { }; -static void __init davinci_timer_init(void) +void __init davinci_timer_early_init(void) { - struct clk *timer_clk; struct davinci_soc_info *soc_info = &davinci_soc_info; unsigned int clockevent_id; unsigned int clocksource_id; static char err[] __initdata = KERN_ERR "%s: can't register clocksource!\n"; - int i; clockevent_id = soc_info->timer_info->clockevent_id; clocksource_id = soc_info->timer_info->clocksource_id; @@ -384,26 +368,19 @@ static void __init davinci_timer_init(void) /* Only bottom timers can use compare regs */ if (IS_TIMER_TOP(clockevent_id)) - pr_warning("davinci_timer_init: Invalid use" - " of system timers. Results unpredictable.\n"); + pr_warning("%s: Invalid use of system timers." + " Results unpredictable.\n", __func__); else if ((dtip[event_timer].cmp_off == 0) || (dtip[event_timer].cmp_irq == 0)) - pr_warning("davinci_timer_init: Invalid timer instance" - " setup. Results unpredictable.\n"); + pr_warning("%s: Invalid timer instance setup." + " Results unpredictable.\n", __func__); else { timers[TID_CLOCKEVENT].opts |= TIMER_OPTS_USE_COMPARE; clockevent_davinci.features = CLOCK_EVT_FEAT_ONESHOT; } } - timer_clk = clk_get(NULL, "timer0"); - BUG_ON(IS_ERR(timer_clk)); - clk_enable(timer_clk); - - /* init timer hw */ - timer_init(); - - davinci_clock_tick_rate = clk_get_rate(timer_clk); + timer_hw_init(); /* setup clocksource */ clocksource_davinci.read = read_cycles; @@ -413,6 +390,33 @@ static void __init davinci_timer_init(void) if (clocksource_register_hz(&clocksource_davinci, davinci_clock_tick_rate)) printk(err, clocksource_davinci.name); +} + +static void __init davinci_timer_late_init(void) +{ + struct davinci_soc_info *soc_info = &davinci_soc_info; + struct davinci_timer_instance *dtip = soc_info->timer_info->timers; + int i; + + for (i = 0; i < ARRAY_SIZE(timers); i++) { + struct timer_s *t = &timers[i]; + int timer = ID_TO_TIMER(t->id); + u32 irq; + + if (IS_TIMER_BOT(t->id)) + irq = dtip[timer].bottom_irq; + else + irq = dtip[timer].top_irq; + + /* Register interrupt */ + t->irqaction.name = t->name; + t->irqaction.dev_id = (void *)t; + + if (t->irqaction.handler != NULL) { + irq = USING_COMPARE(t) ? dtip[i].cmp_irq : irq; + setup_irq(irq, &t->irqaction); + } + } /* setup clockevent */ clockevent_davinci.name = id_to_name[timers[TID_CLOCKEVENT].id]; @@ -424,13 +428,10 @@ static void __init davinci_timer_init(void) clockevent_davinci.cpumask = cpumask_of(0); clockevents_register_device(&clockevent_davinci); - - for (i=0; i< ARRAY_SIZE(timers); i++) - timer32_config(&timers[i]); } struct sys_timer davinci_timer = { - .init = davinci_timer_init, + .init = davinci_timer_late_init, }; -- 1.7.0.4 From Wee-chang.Liew at leica-microsystems.com Thu Dec 29 14:03:06 2011 From: Wee-chang.Liew at leica-microsystems.com (Wee-chang.Liew at leica-microsystems.com) Date: Fri, 30 Dec 2011 04:03:06 +0800 Subject: AUTO: Wee-chang Liew is out of the office. Message-ID: I am out of the office until 01/03/2012. I will respond to your message when I return. Note: This is an automated response to your message "Davinci-linux-open-source Digest, Vol 72, Issue 40" sent on 12/28/2011 2:00:00 AM. This is the only notification you will receive while this person is away. _____________________________________________________________________ This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services - powered by MessageLabs. For further information visit http://www.verizonbusiness.com/uk