RE: davinci_emac/mdio: SOFT_RESET of EMAC module resets MDIO on AM1808
Hi Christian, On Fri, Feb 24, 2012 at 19:45:23, Christian Riesch wrote: Hello Sudhakar, On Fri, Feb 24, 2012 at 2:02 PM, Rajashekhara, Sudhakar sudhakar@ti.com wrote: On Thu, Feb 23, 2012 at 14:39:49, Christian Riesch wrote: Hi, I observed this behavior on a Texas Instruments AM1808 SoC (AM1808 experimenter's kit) running the current mainline kernel: [snip] According to the AM1808 Technical Reference Manual (sections 18.2.14.1 and 18.3.3.34 in [1]), writing a 1 to the EMAC_SOFTRESET register resets the EMAC module, but not the MDIO module. However, when I comment out the code above, the MDIO control register is not affected and the warning 'resetting idled controller' disappears. But this was not the case for me. Even after commenting out the above lines, I could still see that MDIO was getting reset. Uh, I am sorry. I forgot to mention that there is a second emac_write(EMAC_SOFTRESET,1); in emac_dev_stop() in davinci_emac.c. This one must also be commented out to make the resetting idled controller message go away. The patch below shows that changes that I did. May I please ask you to try again with these changes? I was able to reproduce the issue. I'll debug this further and get back to you. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: davinci_emac/mdio: SOFT_RESET of EMAC module resets MDIO on AM1808
Hi Christian, On Mon, Feb 27, 2012 at 15:44:54, Rajashekhara, Sudhakar wrote: Hi Christian, On Fri, Feb 24, 2012 at 19:45:23, Christian Riesch wrote: Hello Sudhakar, On Fri, Feb 24, 2012 at 2:02 PM, Rajashekhara, Sudhakar sudhakar@ti.com wrote: On Thu, Feb 23, 2012 at 14:39:49, Christian Riesch wrote: Hi, I observed this behavior on a Texas Instruments AM1808 SoC (AM1808 experimenter's kit) running the current mainline kernel: [snip] According to the AM1808 Technical Reference Manual (sections 18.2.14.1 and 18.3.3.34 in [1]), writing a 1 to the EMAC_SOFTRESET register resets the EMAC module, but not the MDIO module. However, when I comment out the code above, the MDIO control register is not affected and the warning 'resetting idled controller' disappears. But this was not the case for me. Even after commenting out the above lines, I could still see that MDIO was getting reset. Uh, I am sorry. I forgot to mention that there is a second emac_write(EMAC_SOFTRESET,1); in emac_dev_stop() in davinci_emac.c. This one must also be commented out to make the resetting idled controller message go away. The patch below shows that changes that I did. May I please ask you to try again with these changes? I was able to reproduce the issue. I'll debug this further and get back to you. I was going through the mailing list discussions where a work around for emac soft-reset tie-up to mdio controller has been proposed. I think this was a known issue on TI's da8xx family of devices. Please refer to the thread at http://www.spinics.net/lists/netdev/msg140465.html. Cyril, As you have mentioned in your patch, did you get any confirmation from TI designer regarding emac soft reset behavior? I see that nothing has been mentioned in the EMAC user guide. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: davinci_emac/mdio: SOFT_RESET of EMAC module resets MDIO on AM1808
Hi Christian, On Thu, Feb 23, 2012 at 14:39:49, Christian Riesch wrote: Hi, I observed this behavior on a Texas Instruments AM1808 SoC (AM1808 experimenter's kit) running the current mainline kernel: # ifconfig eth0 down # ifconfig eth0 up davinci_mdio davinci_mdio.0: resetting idled controller net eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=davinci_mdio-0:00) # PHY: davinci_mdio-0:00 - Link is Up - 100/Full I also observed this issue with the kernel from linux-davinci tree from gitorious. After each ifconfig eth0 up I get this 'resetting idled controller' warning. I added a few debug messages to the davinci_mdio driver and noticed that the MDIO control register was set to its reset value (clock divider 0xff and MDIO turned off) after an ifconfig eth0 up. Therefore, this warning is issued and a reconfiguration of the MDIO controller is done by the driver. Now the question was: Who is turning off the MDIO controller? After a bit of debugging I found out that the reset of the MDIO controller seems to be caused by these lines in the davinci_emac driver in emac_hw_enable() in drivers/net/ethernet/ti/davinci_emac.c: emac_write(EMAC_SOFTRESET, 1); while (emac_read(EMAC_SOFTRESET)) cpu_relax(); According to the AM1808 Technical Reference Manual (sections 18.2.14.1 and 18.3.3.34 in [1]), writing a 1 to the EMAC_SOFTRESET register resets the EMAC module, but not the MDIO module. However, when I comment out the code above, the MDIO control register is not affected and the warning 'resetting idled controller' disappears. But this was not the case for me. Even after commenting out the above lines, I could still see that MDIO was getting reset. During eth0 up, the smsc_phy_config_init() function calls the mdiobus_read() function. During this sequence if the MDIO state machine is in IDLE state, then MDIO is reset causing the above warning message to appear. In summary, EMAC reset is not causing the MDIO reset to happen. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] davinci_emac: Do not free all rx dma descriptors during init
Hi, On Thu, Feb 23, 2012 at 16:44:17, Christian Riesch wrote: This patch fixes a regression that was introduced by commit 0a5f38467765ee15478db90d81e40c269c8dda20 davinci_emac: Add Carrier Link OK check in Davinci RX Handler Said commit adds a check whether the carrier link is ok. If the link is not ok, the skb is freed and no new dma descriptor added to the rx dma channel. This causes trouble during initialization when the carrier status has not yet been updated. If a lot of packets are received while netif_carrier_ok returns false, all dma descriptors are freed and the rx dma transfer is stopped. The bug occurs when the board is connected to a network with lots of traffic and the ifconfig down/up is done, e.g., when reconfiguring the interface with DHCP. The bug can be reproduced by flood pinging the davinci board while doing ifconfig eth0 down ifconfig eth0 up on the board. After that, the rx path stops working and the overrun value reported by ifconfig is counting up. This patch reverts commit 0a5f38467765ee15478db90d81e40c269c8dda20 and instead issues warnings only if cpdma_chan_submit returns -ENOMEM. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: sta...@vger.kernel.org Cc: Hegde, Vinay vinay.he...@ti.com Cc: Cyril Chemparathy cy...@ti.com Cc: Sascha Hauer s.ha...@pengutronix.de --- Hi, Since my first submission of this patch yesterday I did additional tests with suspend/rtcwake. My tests confirmed that the solution in this patch solves the problem that was addressed by commit 0a5f38467765ee15478db90d81e40c269c8dda20 while not destroying the rx communication channel. Tested on DA850 and confirmed that there is no regression. Tested-by: Rajashekhara, Sudhakar sudhakar@ti.com Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBIFS with davinci NAND driver - ECC error
Hi Murali, On Fri, Feb 03, 2012 at 05:09:27, Karicheri, Muralidharan wrote: Sudhakar, The good news is that I am able to get UBIFS working as per your procedure. But I have to make following changes as well:- 1) Disable sub-page write in Linux kernel nand driver and u-boot nand driver. Have you done this at your end? 2) Use a sub page size of 2048 in mkfs and ubinize commands. Your procdure still shows -s 512 though the procedure mention about disabling sub page writes. With these I can ubiformat a partition for rootfs from Linux and boot Linux using the rootfs volume. But following steps still doesn't work when you try the same from u-boot 1) nand erase.part rootfs partition 2) nand write 0x8800 rootfs partition size 3) Boot using rootfs volume. We see ECC error when Linux boots up. Have you made any changes To u-boot code? Is there a step missing between 1) and 2) similar to ubiformat? I have not tried it from u-boot. But we were able to boot the AM335x EVM when UBIFS was flashed from u-boot. The only thing to be taken care of is that both u-boot and Linux kernel should be following same ECC layout. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [RFC 1/2] mmc: davinci: Eliminate spurious interrupts
Hi, On Tue, Jan 24, 2012 at 16:46:05, Ido Yariv wrote: The davinci mmc interrupt handler fills the fifo, as long as the DXRDY or DRRDY bits are set in the status register. If interrupts fire during this loop, they will be handled by the handler, but the interrupt controller will still buffer these. As a result, the handler will be called again to serve these needlessly. In order to avoid these spurious interrupts, keep interrupts masked while filling the fifo. Signed-off-by: Ido Yariv i...@wizery.com --- Tested this series on OMAP-L138 EVM using SD card. Observed that number of interrupts during IO transaction were less compared to earlier and there was no drop in performance numbers. Tested-by: Rajashekhara, Sudhakar sudhakar@ti.com Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBIFS with davinci NAND driver - ECC error
Hi Murali, On Wed, Feb 01, 2012 at 02:51:03, Karicheri, Muralidharan wrote: Hi, I am trying to use UBIFS in my project and we are using the davinci nand driver with a flash part that has page size of 2048, block size of 128KiB and size of 128MiB. I have done following to boot the kernel with a UBIFS rootfs. Please refer to http://processors.wiki.ti.com/index.php/UBIFS_Support which has steps to get UBIFS working on AM335x. But I followed these steps and was able to get UBIFS working on OMAP-L138. The bootargs I used from U-Boot are as below: setenv bootargs mem=32M console=ttyS2,115200n8 root=ubi0:rootfs rw rootfstype=ubifs ubi.mtd=4,2048 ip=dhcp Note that I also faced similar booting issues when I was using mkfs.ubifs version 1.3 on the host system to generate the UBIFS file system. The issue went away when I used v 1.4.8. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] Fix 4 bit ECC on OMAP-L13x
Hi Gary, On Sat, Jan 28, 2012 at 21:38:34, Gary Thomas wrote: On 2012-01-28 07:53, Sergei Shtylyov wrote: On 28.01.2012 15:16, Gary Thomas wrote: The use of pdev-id as a channel select is problematic, at least on the OMAP-L13x when using 4 bit hardware assisted ECC. On this hardware, only EMiF channels (chip select) 2 through 5 are available. Specifying platform device id 1 when using chip select 3 is obscure at best. If the core_chipsel value used by the driver is incorrect, then the ECC hardware is not set up properly and ends up always reading ECC values of zero. This is totally broken as no ECC errors will be detected on reads and incorrect ECC values will be stored on writes. The best way to fix this is to pass the actual chip select in the platform data, rather than have it be inferred from the platform device id. The attached patch provides for this. Also, this patch is a no-op for target platforms that do not specify the core_chipsel value in the platform data. This patch was generated against the mainline 3.0 kernel, but applies to 3.2 as well. Note: there does not seem to be an identified maintainer of this code, so this list was my first guess at where to post. Pelase send your patches inline, not as attachments. As Sergei suggested, please modify your patch to convert spaces to tabs and remove trailing white-spaces. You can run your patch through the scripts/checkpatch.pl script which will detect such errors. Once done, please resubmit your patch inline. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [RFC 1/2] mmc: davinci: Eliminate spurious interrupts
Hello Ido, On Tue, Jan 24, 2012 at 16:46:05, Ido Yariv wrote: The davinci mmc interrupt handler fills the fifo, as long as the DXRDY or DRRDY bits are set in the status register. If interrupts fire during this loop, they will be handled by the handler, but the interrupt controller will still buffer these. As a result, the handler will be called again to serve these needlessly. In order to avoid these spurious interrupts, keep interrupts masked while filling the fifo. I tested both these patches and they work fine on the OMAP-L138 EVM. I observed that with these patches the number of interrupts during a transfer are less compared to earlier. For a 100 MB transfer, I could see around 700-800 interrupts less. Did you see any performance improvement with these patches? Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] usb: musb: make modules behave better
Hello, On Thu, Jan 26, 2012 at 16:15:49, Balbi, Felipe wrote: There's really no point in doing all that initcall trickery when we can safely let udev handle module probing for us. Remove all of that trickery, by moving everybody to module_init() and making proper use of platform_device_register() rather than platform_device_probe(). Signed-off-by: Felipe Balbi ba...@ti.com --- Tested on DM644x EVM. Tested-by: Rajashekhara, Sudhakar sudhakar@ti.com Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues.
Hi Mike, On Fri, Jan 20, 2012 at 15:18:07, Rajashekhara, Sudhakar wrote: Hi Mike, On Tue, Jan 17, 2012 at 18:13:23, Michael Williamson wrote: Hello Sudhakar, On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote: Hi Mike, On Mon, Jan 16, 2012 at 20:25:44, Michael Williamson wrote: Hi, [...] We were actually interested in having the option to run that bus (in async mode) faster than 100 MHz for the higher speed OPP's, but it sounds like the specification is a little misleading in the capabilities of the part. As I mentioned above, I'll get this clarified from our design team and update you. I got the confirmation from our design team that EMIFA can be run at a frequency more than 100 MHz at 1.3v and 1.2v. So information in Table 5.5 of OMAP-L138 data sheet (http://www.ti.com/lit/ds/symlink/omap-l138.pdf) is correct. We will correct the software to adjust the EMIFA frequency when the OPP changes instead of fixing the clock divider value. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues.
Hi Mike, On Tue, Jan 17, 2012 at 18:13:23, Michael Williamson wrote: Hello Sudhakar, On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote: Hi Mike, On Mon, Jan 16, 2012 at 20:25:44, Michael Williamson wrote: Hi, I am working with the OMAP-L138 and I think there may be a problem with the 456 MHz OPP point and using the EMIFA. The EMIFA max clock rate is specified at 148 MHz. By default, the EMIFA is driven by PLL0_SYSCLK3 (or 1/3 the CPU rate). Though EMIFA is configured at 1/3 of CPU rate, maximum frequency supported by it 100 MHz which is mentioned in the OMAP-L138 TRM at [1] (Refer to the Note below Table 7-6). We'll be correcting this in our next release scheduled for March end. Correcting the spec? The revision D OMAP-L138 specification[1] in Table 5-5 indicates a max async rate of 148 MHz and a max SDRAM rate of 100 MHz. It also indicates a max 148 MHz rate in table 5-23 (Tc(CLK) is minimum 6.75 ns) for async operation. I was talking about correcting the software here. As of now there is some confusion on the maximum allowable EMIFA frequency. I'll get this clarified from our design team and then either correct the software or the documentation. At 456 MHz, this is 152 MHz. In addition to being out of spec, it looks like the aemif code that sets up wait state divisor settings is getting called by the MTD/NAND probe() code at startup, but doesn't register and recompute the timings if someone starts messing with the OPP (e.g., cranks it up from 300 MHz to 456 MHz) and the affected clock. We had two options to keep the pll0_sysclk3 frequency under allowable limits: a. Whenever cpu frequency changes, check whether the current value of PLL0_SYSCLK3 is greater than the allowed value and adjust accordingly. b. Fix the PLL0_SYSCLK3 divider value at some constant such that at all operating points, the frequency is within the allowed value. We did some experiments on the NAND performance with the above two options. We found out that except for the case when CPU is operating at 100 MHz, there was a minor variation in the performance figures (of the order of 2-4%). Note that we had implemented CPU freq support for NAND during this experiment. Based on the findings we'll be implementing option 'b' in our next release. EMIFA frequency will be fixed at 1/5 of CPU rate. Well, that's all fine and swell, except we have OMAP-L138 platforms (built using the MityDSP-L138 SOM) that use the EMIFA for other devices than NAND, such as an FPGA (and no SDRAM). Dropping the default 300 MHz OPP EMIFA speed from 100 MHz down to 60 MHz will directly translate to a 40% reduction in potential bus bandwidth. If you are making this device wide, it would really be nice to have an option that is more consistent with option A and let the platform designer decide what rate the EMIFA clock should run at based on his hardware requirements. You are right. We'll implement option A in our software. Right now we are working on supporting USB on Linux 3.2 on AM18x. Once we finish that, we'll look into this. Is your release regarding this matter going to be brought into the mainline as well or just the TI Arago tree? We'll be pushing this patch upstream but till the point it gets accepted, we'll be maintaining it on Arago. We were actually interested in having the option to run that bus (in async mode) faster than 100 MHz for the higher speed OPP's, but it sounds like the specification is a little misleading in the capabilities of the part. As I mentioned above, I'll get this clarified from our design team and update you. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues.
Hi Christian, On Tue, Jan 17, 2012 at 18:23:52, Christian Riesch wrote: Hi Sudhakar, hi Mike, On Tue, Jan 17, 2012 at 1:43 PM, Michael Williamson michael.william...@criticallink.com wrote: On 1/17/2012 12:39 AM, Rajashekhara, Sudhakar wrote: [...] Well, that's all fine and swell, except we have OMAP-L138 platforms (built using the MityDSP-L138 SOM) that use the EMIFA for other devices than NAND, such as an FPGA (and no SDRAM). Dropping the default 300 MHz OPP EMIFA speed from 100 MHz down to 60 MHz will directly translate to a 40% reduction in potential bus bandwidth. If you are making this device wide, it would really be nice to have an option that is more consistent with option A and let the platform designer decide what rate the EMIFA clock should run at based on his hardware requirements. In my opinion hardcoding OPPs in a SoC specific file (arch/arm/mach-davinci/da850.c) was a bad idea. Setting EMIFA clock to 1/5 of CPU rate may be fine for some boards, but for others it may be a bad decision. How about boards with input clock frequencies other than 24 MHz? Currently the OPP settings are only correct if a 24 MHz quartz or oscillator is used. So I think the OPPs should move out of the SoC specific file. Using a different oscillator is a perfectly valid use case but I was wondering why anyone would do that? The OPP settings are defined and are valid when using a 24 MHz quartz. Have you come across a board where a different quartz is being used with OMAP-L138? Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DA850 / OMAP-L138 / AM-1808 EMIFA Clk issues.
Hi, On Tue, Jan 17, 2012 at 11:09:31, Rajashekhara, Sudhakar wrote: Hi Mike, On Mon, Jan 16, 2012 at 20:25:44, Michael Williamson wrote: Hi, I am working with the OMAP-L138 and I think there may be a problem with the 456 MHz OPP point and using the EMIFA. The EMIFA max clock rate is specified at 148 MHz. By default, the EMIFA is driven by PLL0_SYSCLK3 (or 1/3 the CPU rate). Though EMIFA is configured at 1/3 of CPU rate, maximum frequency supported by it 100 MHz which is mentioned in the OMAP-L138 TRM at [1] (Refer to the Note below Table 7-6). We'll be correcting this in our next release scheduled for March end. Forgot to mention the link. [1] http://www.ti.com/litv/pdf/spruh77a At 456 MHz, this is 152 MHz. In addition to being out of spec, it looks like the aemif code that sets up wait state divisor settings is getting called by the MTD/NAND probe() code at startup, but doesn't register and recompute the timings if someone starts messing with the OPP (e.g., cranks it up from 300 MHz to 456 MHz) and the affected clock. [...] Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [Fwd: Re: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue]
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 i...@wizery.com An: h...@denx.de CC: juha.kui...@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...@denx.de 20111204102741.GL32400@WorkStation4edc7c00.30...@denx.de Hi Heiko, On Dec 5, 2011 10:08 AM, Heiko Schocher h...@denx.de 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 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue
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 h...@denx.de Signed-off-by: juha.kui...@gmail.com Reported-by: juha.kui...@gmail.com Cc: linux-...@vger.kernel.org Cc: davinci-linux-open-source@linux.davincidsp.com Cc: Rajashekhara, Sudhakar sudhakar@ti.com Cc: Ido Yariv i...@wizery.com Cc: Sekhar Nori nsek...@ti.com Cc: Wolfgang Denk w...@denx.de --- 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 sudhakar@ti.com Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: arm, am1808: using mmc1 controller and dma
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@linux.davincidsp.com/msg17926.html Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: arm, am1808: using mmc1 controller and dma
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@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 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: OMAP L138 evm halts when removing module davinci_spi
Hi, On Wed, Sep 21, 2011 at 15:33:08, Rajashekhara, Sudhakar wrote: Hi, On Wed, Sep 21, 2011 at 15:06:29, Aníbal Almeida Pinto wrote: Em 21-09-2011 09:38, Rajashekhara, Sudhakar escreveu: Hi, On Wed, Aug 31, 2011 at 17:47:43, Aníbal Almeida Pinto wrote: Hi, [...] If I apply the patch attached I can make rmmod of the spi davinci driver. The procedure that I have tested : # insmod davinci_spi.ko spi_davinci spi_davinci.1: DMA: supported spi_davinci spi_davinci.1: DMA: RX channel: 18, TX channel: 19, event queue: 0 spi_davinci spi_davinci.1: Controller at 0xfef0e000 # rmmod davinci_spi.ko But can't insmod it again : # insmod davinci_spi.ko Unable to request DMA channel for SPI RX Trying to free nonexistent resource 01f0e000-01f0e000 spi_davinci: probe of spi_davinci.1 failed with error -11 insmod: can't insert 'davinci_spi.ko': No such device I see that during module removal, the driver is not doing the following: edma_free_channel(dspi-dma.tx_channel); edma_free_channel(dspi-dma.rx_channel); edma_free_slot(dspi-dma.dummy_param_slot); Even after adding the above lines, I was not able to do the insmod again because for me, the m25p80 device was already registered. I am not sure whether you are using the same interface. If yes, you need to figure out how to handle that. Any luck with the above fix? Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: kernel bootlog timestamp all zeros - 3.0rcx based davinci tree
Hi Murali, On Mon, Aug 29, 2011 at 21:23:45, Karicheri, Muralidharan wrote: Hi All, I have a port of the davinci tree for a new platform that I am working on. The time stamp of the boot log shows all zeros. I am using the master branch of davinci tree at http://gitorious.org/linux-davinci/linux-davinci My original port based on 2.6.37 has proper time stamps displayed. Anything changes related to this in recent kernel that I need to be aware causing this issue? Thanks in advance for your help. I tried it from the same repository which had the below commit at the top and it worked absolutely fine. commit acc2ec87c22da0655bc75ef1d8eba89010bab00e Merge: 06baeca 6e22c04 Author: Sekhar Nori nsek...@ti.com Date: Sat Sep 17 16:17:23 2011 +0530 rebuild linux-davinci from branches 5.241 0.011: Bytes transferred = 1815848 (1bb528 hex) 5.331 0.091: ## Booting kernel from Legacy Image at c070 ... 5.331 0.000:Image Name: Linux-3.1.0-rc6-07781-gacc2ec8 5.340 0.009:Image Type: ARM Linux Kernel Image (uncompressed) 5.340 0.000:Data Size:1815784 Bytes = 1.7 MB 5.340 0.000:Load Address: c0008000 5.340 0.000:Entry Point: c0008000 5.900 0.560:Verifying Checksum ... OK 6.500 0.600:Loading Kernel Image ... OK 6.500 0.000: OK 6.500 0.000: 6.500 0.000: Starting kernel ... 6.500 0.000: 7.880 1.380: Uncompressing Linux... done, booting the kernel. 9.830 1.950: Linux version 3.1.0-rc6-07781-gacc2ec8 (sudha...@linux-psp-server.india.ext.ti.com) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #1 PREEMPT Mon Sep 26 09:04:58 IST 2011 9.843 0.013: CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 9.843 0.000: CPU: VIVT data cache, VIVT instruction cache 9.843 0.000: Machine: DaVinci DA850/OMAP-L138/AM18x EVM 9.857 0.015: Memory policy: ECC disabled, Data cache writethrough 9.857 0.000: DaVinci da850/omap-l138 variant 0x0 Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: OMAP L138 evm halts when removing module davinci_spi
Hi, On Wed, Aug 31, 2011 at 17:47:43, Aníbal Almeida Pinto wrote: Hi, I am using the OMAP L138 logic evaluation board with 3.0.0 linux-davinci kernel. To the default configuration I have added spi support and build the spi_davinci as a module. After the boards boot I was able to insmod davinci_spi.ko but when tried to make rmmod davinci_spi.ko the board halted. Anyone have reported this ? Inserting printk on davinci_spi remove function it appears to be on clk_disable. I also noticed this issue. When I debugged this I found out that, the SPI driver enables the local low-power mode. This is achieved by setting the POWERDOWN bit (9th bit) in SPIGCR1 register. In local low-power mode, clock to SPI internal logic is stopped. At this point of time, doing a clk_disable() is not behaving properly. When SPI is not in low-power mode, clk_disable() works fine. So for rmmod to work, you need to remove all references to SPIGCR1_POWERDOWN_MASK in the code. Please test this at your end and let me know the outcome. If it is working, then I can submit a patch to the list which takes care of this. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: OMAP L138 evm halts when removing module davinci_spi
Hi, On Wed, Sep 21, 2011 at 15:06:29, Aníbal Almeida Pinto wrote: Em 21-09-2011 09:38, Rajashekhara, Sudhakar escreveu: Hi, On Wed, Aug 31, 2011 at 17:47:43, Aníbal Almeida Pinto wrote: Hi, I am using the OMAP L138 logic evaluation board with 3.0.0 linux-davinci kernel. To the default configuration I have added spi support and build the spi_davinci as a module. After the boards boot I was able to insmod davinci_spi.ko but when tried to make rmmod davinci_spi.ko the board halted. Anyone have reported this ? Inserting printk on davinci_spi remove function it appears to be on clk_disable. I also noticed this issue. When I debugged this I found out that, the SPI driver enables the local low-power mode. This is achieved by setting the POWERDOWN bit (9th bit) in SPIGCR1 register. In local low-power mode, clock to SPI internal logic is stopped. At this point of time, doing a clk_disable() is not behaving properly. When SPI is not in low-power mode, clk_disable() works fine. So for rmmod to work, you need to remove all references to SPIGCR1_POWERDOWN_MASK in the code. Please test this at your end and let me know the outcome. If it is working, then I can submit a patch to the list which takes care of this. If I apply the patch attached I can make rmmod of the spi davinci driver. The procedure that I have tested : # insmod davinci_spi.ko spi_davinci spi_davinci.1: DMA: supported spi_davinci spi_davinci.1: DMA: RX channel: 18, TX channel: 19, event queue: 0 spi_davinci spi_davinci.1: Controller at 0xfef0e000 # rmmod davinci_spi.ko But can't insmod it again : # insmod davinci_spi.ko Unable to request DMA channel for SPI RX Trying to free nonexistent resource 01f0e000-01f0e000 spi_davinci: probe of spi_davinci.1 failed with error -11 insmod: can't insert 'davinci_spi.ko': No such device I see that during module removal, the driver is not doing the following: edma_free_channel(dspi-dma.tx_channel); edma_free_channel(dspi-dma.rx_channel); edma_free_slot(dspi-dma.dummy_param_slot); Even after adding the above lines, I was not able to do the insmod again because for me, the m25p80 device was already registered. I am not sure whether you are using the same interface. If yes, you need to figure out how to handle that. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] mtd: nand: davinci: Add cpufreq support
Hi, On Mon, Aug 15, 2011 at 20:50:07, Artem Bityutskiy wrote: On Tue, 2011-08-02 at 12:03 +0530, Rajashekhara, Sudhakar wrote: Hi David, On Thu, Jul 21, 2011 at 15:09:23, Rajashekhara, Sudhakar wrote: This patch adds cpufreq support for NAND driver. During cpufreq transition, 'davinci_aemif_setup_timing()' function will be called to reconfigure that AEMIF timings for the new frequency. Tested on TI DA850/OMAP-L138 EVM. Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com I have not seen any comments on this patch. Can you pull it in into your tree? Would be nice to get a Tested-by or Acked-by from someone. There were few comments on this patch series from Ben Gardiner. I am working on them. Will post an updated patch set to the list. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] mtd: nand: davinci: Add cpufreq support
Hi David, On Thu, Jul 21, 2011 at 15:09:23, Rajashekhara, Sudhakar wrote: This patch adds cpufreq support for NAND driver. During cpufreq transition, 'davinci_aemif_setup_timing()' function will be called to reconfigure that AEMIF timings for the new frequency. Tested on TI DA850/OMAP-L138 EVM. Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com I have not seen any comments on this patch. Can you pull it in into your tree? Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] mtd: nand: davinci: Add cpufreq support
This patch adds cpufreq support for NAND driver. During cpufreq
transition, 'davinci_aemif_setup_timing()' function will be called
to reconfigure that AEMIF timings for the new frequency.
Tested on TI DA850/OMAP-L138 EVM.
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
---
drivers/mtd/nand/davinci_nand.c | 54 +++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 1f34951..7e764af 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -33,6 +33,7 @@
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
#include linux/slab.h
+#include linux/cpufreq.h
#include mach/nand.h
#include mach/aemif.h
@@ -74,6 +75,9 @@ struct davinci_nand_info {
uint32_tcore_chipsel;
struct davinci_aemif_timing *timing;
+#ifdef CONFIG_CPU_FREQ
+ struct notifier_block freq_transition;
+#endif
};
static DEFINE_SPINLOCK(davinci_nand_lock);
@@ -519,6 +523,47 @@ static struct nand_ecclayout hwecc4_2048 __initconst = {
},
};
+#ifdef CONFIG_CPU_FREQ
+static int nand_davinci_cpufreq_transition(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ struct davinci_nand_info *info;
+
+ info = container_of(nb, struct davinci_nand_info, freq_transition);
+
+ if (val == CPUFREQ_POSTCHANGE)
+ davinci_aemif_setup_timing(info-timing, info-base,
+ info-core_chipsel);
+
+ return 0;
+}
+
+static inline int nand_davinci_cpufreq_register(struct davinci_nand_info *info)
+{
+ info-freq_transition.notifier_call = nand_davinci_cpufreq_transition;
+
+ return cpufreq_register_notifier(info-freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+
+static inline void nand_davinci_cpufreq_deregister(struct davinci_nand_info
+ *info)
+{
+ cpufreq_unregister_notifier(info-freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+#else
+static inline int nand_davinci_cpufreq_register(struct davinci_nand_info *info)
+{
+ return 0;
+}
+
+static inline void nand_davinci_cpufreq_deregister(struct davinci_nand_info
+ *info)
+{
+}
+#endif
+
static int __init nand_davinci_probe(struct platform_device *pdev)
{
struct davinci_nand_pdata *pdata = pdev-dev.platform_data;
@@ -782,12 +827,19 @@ syndrome_done:
if (ret 0)
goto err_scan;
+ ret = nand_davinci_cpufreq_register(info);
+ if (ret) {
+ dev_err(pdev-dev, failed to register cpufreq\n);
+ goto err_cpu_freq_fail;
+ }
+
val = davinci_nand_readl(info, NRCSR_OFFSET);
dev_info(pdev-dev, controller rev. %d.%d\n,
(val 8) 0xff, val 0xff);
return 0;
+err_cpu_freq_fail:
err_scan:
err_timing:
clk_disable(info-clk);
@@ -818,6 +870,8 @@ static int __exit nand_davinci_remove(struct
platform_device *pdev)
struct davinci_nand_info *info = platform_get_drvdata(pdev);
int status;
+ nand_davinci_cpufreq_deregister(info);
+
status = mtd_device_unregister(info-mtd);
spin_lock_irq(davinci_nand_lock);
--
1.7.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] ASoC: davinci: bug fixes for DM365 voice codec driver
This patch fixes the following bugs found in DaVinci voice codec driver. a. According to DM365 voice codec data sheet at [1], before starting recording or playback, ADC/DAC modules should follow a reset and enable cycle. Writing a 1 to the ADC/DAC bit in the register resets the module and clearing the bit to 0 will enable the module. But the driver seems to be doing the reverse of it. b. In davinci_vcif_trigger() function, a break() statement was missing causing the davinci_vcif_stop() function to be called as a fallback after calling davinci_vcif_start(). [1] http://focus.ti.com/lit/ug/sprufi9b/sprufi9b.pdf Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com --- sound/soc/davinci/davinci-vcif.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/soc/davinci/davinci-vcif.c b/sound/soc/davinci/davinci-vcif.c index 9259f1f..1f11525 100644 --- a/sound/soc/davinci/davinci-vcif.c +++ b/sound/soc/davinci/davinci-vcif.c @@ -62,9 +62,9 @@ static void davinci_vcif_start(struct snd_pcm_substream *substream) w = readl(davinci_vc-base + DAVINCI_VC_CTRL); if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) - MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTDAC, 1); + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTDAC, 0); else - MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTADC, 1); + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTADC, 0); writel(w, davinci_vc-base + DAVINCI_VC_CTRL); } @@ -80,9 +80,9 @@ static void davinci_vcif_stop(struct snd_pcm_substream *substream) /* Reset transmitter/receiver and sample rate/frame sync generators */ w = readl(davinci_vc-base + DAVINCI_VC_CTRL); if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) - MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTDAC, 0); + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTDAC, 1); else - MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTADC, 0); + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTADC, 1); writel(w, davinci_vc-base + DAVINCI_VC_CTRL); } @@ -159,6 +159,7 @@ static int davinci_vcif_trigger(struct snd_pcm_substream *substream, int cmd, case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: davinci_vcif_start(substream); + break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: -- 1.7.1 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ASoC: davinci: bug fixes for DM365 voice codec driver
Hi Sekhar, On Wed, Jul 20, 2011 at 17:04:55, Nori, Sekhar wrote: Hi Sudhakar, On Wed, Jul 20, 2011 at 16:15:30, Rajashekhara, Sudhakar wrote: This patch fixes the following bugs found in DaVinci voice codec driver. a. According to DM365 voice codec data sheet at [1], before starting recording or playback, ADC/DAC modules should follow a reset and enable cycle. Writing a 1 to the ADC/DAC bit in the register resets the module and clearing the bit to 0 will enable the module. But the driver seems to be doing the reverse of it. b. In davinci_vcif_trigger() function, a break() statement was missing causing the davinci_vcif_stop() function to be called as a fallback after calling davinci_vcif_start(). These should be two different patches. Also, please CC the ALSA maintainers. I'll split the patches and resend them. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 1/2] ASoC: davinci: fix codec start and stop functions
According to DM365 voice codec data sheet at [1], before starting recording or playback, ADC/DAC modules should follow a reset and enable cycle. Writing a 1 to the ADC/DAC bit in the register resets the module and clearing the bit to 0 will enable the module. But the driver seems to be doing the reverse of it. [1] http://focus.ti.com/lit/ug/sprufi9b/sprufi9b.pdf Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com --- sound/soc/davinci/davinci-vcif.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/davinci/davinci-vcif.c b/sound/soc/davinci/davinci-vcif.c index 9259f1f..c957e9e 100644 --- a/sound/soc/davinci/davinci-vcif.c +++ b/sound/soc/davinci/davinci-vcif.c @@ -62,9 +62,9 @@ static void davinci_vcif_start(struct snd_pcm_substream *substream) w = readl(davinci_vc-base + DAVINCI_VC_CTRL); if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) - MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTDAC, 1); + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTDAC, 0); else - MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTADC, 1); + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTADC, 0); writel(w, davinci_vc-base + DAVINCI_VC_CTRL); } @@ -80,9 +80,9 @@ static void davinci_vcif_stop(struct snd_pcm_substream *substream) /* Reset transmitter/receiver and sample rate/frame sync generators */ w = readl(davinci_vc-base + DAVINCI_VC_CTRL); if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) - MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTDAC, 0); + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTDAC, 1); else - MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTADC, 0); + MOD_REG_BIT(w, DAVINCI_VC_CTRL_RSTADC, 1); writel(w, davinci_vc-base + DAVINCI_VC_CTRL); } -- 1.7.1 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 2/2] ASoC: davinci: add missing break statement
In davinci_vcif_trigger() function, a break() statement was missing causing the davinci_vcif_stop() function to be called as a fallback after calling davinci_vcif_start(). Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com --- sound/soc/davinci/davinci-vcif.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/soc/davinci/davinci-vcif.c b/sound/soc/davinci/davinci-vcif.c index c957e9e..1f11525 100644 --- a/sound/soc/davinci/davinci-vcif.c +++ b/sound/soc/davinci/davinci-vcif.c @@ -159,6 +159,7 @@ static int davinci_vcif_trigger(struct snd_pcm_substream *substream, int cmd, case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: davinci_vcif_start(substream); + break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: -- 1.7.1 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3] davinci: da850 EVM: read mac address from SPI flash
Hi,
On Mon, Jul 11, 2011 at 18:02:55, Nori, Sekhar wrote:
Hi Sudhakar,
On Mon, Jul 11, 2011 at 14:58:21, Rajashekhara, Sudhakar wrote:
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index a7b41bf..5bb6556 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -115,6 +115,25 @@ static struct spi_board_info da850evm_spi_info[] = {
},
};
+#ifdef CONFIG_MTD
+static void da850_evm_m25p80_notify_add(struct mtd_info *mtd)
+{
+ char *mac_addr = davinci_soc_info.emac_pdata-mac_addr;
+ size_t retlen;
+
+ if (!strcmp(mtd-name, MAC-Address)) {
+ mtd-read(mtd, 0, ETH_ALEN, retlen, mac_addr);
+ if (retlen == ETH_ALEN)
+ pr_info(Read MAC addr from SPI Flash: %pM\n,
+ mac_addr);
+ }
+}
+
+static struct mtd_notifier da850evm_spi_notifier = {
+ .add= da850_evm_m25p80_notify_add,
+};
+#endif
+
static struct mtd_partition da850_evm_norflash_partition[] = {
{
.name = bootloaders + env,
@@ -1117,6 +1136,15 @@ static __init int da850_evm_init_cpufreq(void)
static __init int da850_evm_init_cpufreq(void) { return 0; }
#endif
+#ifdef CONFIG_MTD
+static void da850_evm_setup_mac_addr(void)
+{
+ register_mtd_user(da850evm_spi_notifier);
+}
+#else
+static void da850_evm_setup_mac_addr(void) { }
+#endif
Why not combine this ifdef construct with
earlier one?
Ok. Updated patch will follow.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4] davinci: da850 EVM: read mac address from SPI flash
DA850/OMAP-L138 EMAC driver uses random mac address instead of
a fixed one because the mac address is not stuffed into EMAC
platform data.
This patch provides a function which reads the mac address
stored in SPI flash (registered as MTD device) and populates the
EMAC platform data. The function which reads the mac address is
registered as a callback which gets called upon addition of MTD
device.
NOTE: In case the MAC address stored in SPI flash is erased, follow
the instructions at [1] to restore it.
[1]
http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash
Modifications in v2:
Guarded registering the mtd_notifier only when MTD is enabled.
Earlier this was handled using mtd_has_partitions() call, but
this has been removed in Linux v3.0.
Modifications in v3:
a. Guarded da850_evm_m25p80_notify_add() function and
da850evm_spi_notifier structure with CONFIG_MTD macros.
b. Renamed da850_evm_register_mtd_user() function to
da850_evm_setup_mac_addr() and removed the struct mtd_notifier
argument to this function.
c. Passed the da850evm_spi_notifier structure to register_mtd_user()
function.
Modifications in v4:
Moved the da850_evm_setup_mac_addr() function within the first
CONFIG_MTD ifdef construct.
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index a7b41bf..e83cc86 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -115,6 +115,32 @@ static struct spi_board_info da850evm_spi_info[] = {
},
};
+#ifdef CONFIG_MTD
+static void da850_evm_m25p80_notify_add(struct mtd_info *mtd)
+{
+ char *mac_addr = davinci_soc_info.emac_pdata-mac_addr;
+ size_t retlen;
+
+ if (!strcmp(mtd-name, MAC-Address)) {
+ mtd-read(mtd, 0, ETH_ALEN, retlen, mac_addr);
+ if (retlen == ETH_ALEN)
+ pr_info(Read MAC addr from SPI Flash: %pM\n,
+ mac_addr);
+ }
+}
+
+static struct mtd_notifier da850evm_spi_notifier = {
+ .add= da850_evm_m25p80_notify_add,
+};
+
+static void da850_evm_setup_mac_addr(void)
+{
+ register_mtd_user(da850evm_spi_notifier);
+}
+#else
+static void da850_evm_setup_mac_addr(void) { }
+#endif
+
static struct mtd_partition da850_evm_norflash_partition[] = {
{
.name = bootloaders + env,
@@ -1237,6 +1263,8 @@ static __init void da850_evm_init(void)
if (ret)
pr_warning(da850_evm_init: spi 1 registration failed: %d\n,
ret);
+
+ da850_evm_setup_mac_addr();
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
1.7.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] davinci: da850 EVM: read mac address from SPI flash
Hi Sekhar,
On Wed, Jul 06, 2011 at 21:22:52, Nori, Sekhar wrote:
Hi Sudhakar,
On Mon, Jul 04, 2011 at 18:37:18, Rajashekhara, Sudhakar wrote:
DA850/OMAP-L138 EMAC driver uses random mac address instead of
a fixed one because the mac address is not stuffed into EMAC
platform data.
This patch provides a function which reads the mac address
stored in SPI flash (registered as MTD device) and populates the
EMAC platform data. The function which reads the mac address is
registered as a callback which gets called upon addition of MTD
device.
NOTE: In case the MAC address stored in SPI flash is erased, follow
the instructions at [1] to restore it.
[1]
http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
---
Since v1:
Guarded registering the mtd_notifier only when MTD is enabled.
Earlier this was handled using mtd_has_partitions() call, but
this has been removed in Linux v3.0.
Current trend is to include the change log into the
commit message itself. It might be useful to examine
at a later time what transformation the patch went
through. It also simplifies things for you since you
don't have to maintain this separately.
You are right, this is very helpful. I'll move the change log into the commit
message.
+static void da850_evm_m25p80_notify_add(struct mtd_info *mtd)
+{
+ char *mac_addr = davinci_soc_info.emac_pdata-mac_addr;
+ size_t retlen;
+
+ if (!strcmp(mtd-name, MAC-Address)) {
+ mtd-read(mtd, 0, ETH_ALEN, retlen, mac_addr);
+ if (retlen == ETH_ALEN)
+ pr_info(Read MAC addr from SPI Flash: %pM\n,
+ mac_addr);
+ }
+}
+
+static struct mtd_notifier da850evm_spi_notifier = {
+ .add= da850_evm_m25p80_notify_add,
+};
The function and data structure above are not required
when CONFIG_MTD is not defined so these should be
under #ifdef CONFIG_MTD too. Towards this..
Ok.
+#ifdef CONFIG_MTD
+static void da850_evm_register_mtd_user(struct mtd_notifier *notify)
+{
+ register_mtd_user(notify);
+}
.. rename this function as something like da850_evm_setup_mac_addr() and
make it take void as argument and use:
register_mtd_user(da850evm_spi_notifier);
Agreed. I'll include these modifications and send the updated version.
Thanks,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] davinci: da850 EVM: read mac address from SPI flash
DA850/OMAP-L138 EMAC driver uses random mac address instead of
a fixed one because the mac address is not stuffed into EMAC
platform data.
This patch provides a function which reads the mac address
stored in SPI flash (registered as MTD device) and populates the
EMAC platform data. The function which reads the mac address is
registered as a callback which gets called upon addition of MTD
device.
NOTE: In case the MAC address stored in SPI flash is erased, follow
the instructions at [1] to restore it.
[1]
http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
---
Since v1:
Guarded registering the mtd_notifier only when MTD is enabled.
Earlier this was handled using mtd_has_partitions() call, but
this has been removed in Linux v3.0.
arch/arm/mach-davinci/board-da850-evm.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index a7b41bf..f994a1f 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -115,6 +115,23 @@ static struct spi_board_info da850evm_spi_info[] = {
},
};
+static void da850_evm_m25p80_notify_add(struct mtd_info *mtd)
+{
+ char *mac_addr = davinci_soc_info.emac_pdata-mac_addr;
+ size_t retlen;
+
+ if (!strcmp(mtd-name, MAC-Address)) {
+ mtd-read(mtd, 0, ETH_ALEN, retlen, mac_addr);
+ if (retlen == ETH_ALEN)
+ pr_info(Read MAC addr from SPI Flash: %pM\n,
+ mac_addr);
+ }
+}
+
+static struct mtd_notifier da850evm_spi_notifier = {
+ .add= da850_evm_m25p80_notify_add,
+};
+
static struct mtd_partition da850_evm_norflash_partition[] = {
{
.name = bootloaders + env,
@@ -1117,6 +1134,15 @@ static __init int da850_evm_init_cpufreq(void)
static __init int da850_evm_init_cpufreq(void) { return 0; }
#endif
+#ifdef CONFIG_MTD
+static void da850_evm_register_mtd_user(struct mtd_notifier *notify)
+{
+ register_mtd_user(notify);
+}
+#else
+static void da850_evm_register_mtd_user(struct mtd_notifier *notify) { }
+#endif
+
static __init void da850_evm_init(void)
{
int ret;
@@ -1237,6 +1263,8 @@ static __init void da850_evm_init(void)
if (ret)
pr_warning(da850_evm_init: spi 1 registration failed: %d\n,
ret);
+
+ da850_evm_register_mtd_user(da850evm_spi_notifier);
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
1.7.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] davinci: da850 EVM: read mac address from SPI flash
Hi, On Mon, Jun 20, 2011 at 23:16:56, Nori, Sekhar wrote: Hi Sudhakar, On Wed, Jun 08, 2011 at 18:32:35, Rajashekhara, Sudhakar wrote: DA850/OMAP-L138 EMAC driver uses random mac address instead of a fixed one because the mac address is not stuffed into EMAC platform data. This patch provides a function which reads the mac address stored in SPI flash (registered as MTD device) and populates the EMAC platform data. The function which reads the mac address is registered as a callback which gets called upon addition of MTD device. NOTE: In case the MAC address stored in SPI flash is erased, follow the instructions at [1] to restore it. [1] http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additiona l_Procedures#Restoring_MAC_address_on_SPI_Flash Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com --- [...] + + if (mtd_has_partitions()) + register_mtd_user(da850evm_spi_notifier); The v3.0 merge removes mtd_has_partitions() so this fails to build. Can you please fix and re-submit? I'll rework on this patch and submit it again. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: da850 EVM: read mac address from SPI flash
DA850/OMAP-L138 EMAC driver uses random mac address instead of
a fixed one because the mac address is not stuffed into EMAC
platform data.
This patch provides a function which reads the mac address
stored in SPI flash (registered as MTD device) and populates the
EMAC platform data. The function which reads the mac address is
registered as a callback which gets called upon addition of MTD
device.
NOTE: In case the MAC address stored in SPI flash is erased, follow
the instructions at [1] to restore it.
[1]
http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index a7b41bf..3ff64b8 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -115,6 +115,23 @@ static struct spi_board_info da850evm_spi_info[] = {
},
};
+static void da850_evm_m25p80_notify_add(struct mtd_info *mtd)
+{
+ char *mac_addr = davinci_soc_info.emac_pdata-mac_addr;
+ size_t retlen;
+
+ if (!strcmp(mtd-name, MAC-Address)) {
+ mtd-read(mtd, 0, ETH_ALEN, retlen, mac_addr);
+ if (retlen == ETH_ALEN)
+ pr_info(Read MAC addr from SPI Flash: %pM\n,
+ mac_addr);
+ }
+}
+
+static struct mtd_notifier da850evm_spi_notifier = {
+ .add= da850_evm_m25p80_notify_add,
+};
+
static struct mtd_partition da850_evm_norflash_partition[] = {
{
.name = bootloaders + env,
@@ -1237,6 +1254,9 @@ static __init void da850_evm_init(void)
if (ret)
pr_warning(da850_evm_init: spi 1 registration failed: %d\n,
ret);
+
+ if (mtd_has_partitions())
+ register_mtd_user(da850evm_spi_notifier);
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
--
1.7.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: ALSA issue on DA850/OMAP-L138/AM18x
Hi Christophe, On Mon, Mar 07, 2011 at 14:10:41, Christophe Aeschlimann wrote: Hi Sudhakar, On 17.02.2011 05:23, Rajashekhara, Sudhakar wrote: Reverting the commit 140176159597ea1f23dcccb47b5c38fdf7c7faa8 (ASoC: Configure symmetric rates for tlv320aic3x) resolves the issue. We are still working on the proper fix. Thanks, Sudhakar Did you find a proper solution to that issue ? Did the workaround work for you? Because of other engagements we have not spent time on finding the proper fix. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4 1/2] mtd: NOR flash driver for OMAP-L137/AM17x
Hi, On Thu, Dec 02, 2010 at 09:20:15, Artem Bityutskiy wrote: On Tue, 2010-11-30 at 15:32 +0530, Savinay Dharmappa wrote: From: David Griego dgri...@mvista.com OMAP-L137/AM17x has limited number of dedicated EMIFA address pins, enough to interface directly to an SDRAM. If a device such as an asynchronous flash needs to be attached to the EMIFA, then either GPIO pins or a chip select may be used to control the flash device's upper address lines. This patch adds support for the NOR flash on the OMAP-L137/ AM17x user interface daughter board using the latch-addr-flash MTD mapping driver which allows flashes to be partially physically addressed. The upper address lines are set by a board specific code which is a separate patch. Signed-off-by: David Griego dgri...@mvista.com Signed-off-by: Aleksey Makarov amaka...@ru.mvista.com Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com Signed-off-by: Savinay Dharmappa savinay.dharma...@ti.com Pushed these to l2-mtd-2.6.git, thanks. I do not see these patches in Linus's tree [1] or at l2-mtd-2.6.git tree [2]. Is there any tree where these patches are available? [1] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git [2] git://git.infradead.org/users/dedekind/l2-mtd-2.6.git Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: ALSA issue on DA850/OMAP-L138/AM18x
Hi Christophe, On Wed, Feb 16, 2011 at 19:37:57, Christophe Aeschlimann wrote: Hi Sudhakar, On 18.01.2011 05:43, Rajashekhara, Sudhakar wrote: [...] With the above fixes, arecord and aplay does not work for the first time. Couple of times I get the below error: root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat arecord: main:608: audio open error: Invalid argument aplay: playback:2297: read error root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat aplay: main:608: audio open error: Invalid argument Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Third time arecord and aplay work normally. Has anyone seen such issues on DA850 or any other platform? I am currently debugging this issue. I'll submit the above patch to community once the issue of fixed. I'm facing the same issue here. Did you make any progress on that one ? Reverting the commit 140176159597ea1f23dcccb47b5c38fdf7c7faa8 (ASoC: Configure symmetric rates for tlv320aic3x) resolves the issue. We are still working on the proper fix. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: PREEMPT_RT patches and GPIO (interrupts) problem
Hi, On Fri, Feb 11, 2011 at 14:58:13, Christophe Aeschlimann wrote: On 08.02.2011 12:19, Rajashekhara, Sudhakar wrote: Hi Christophe, On Tue, Feb 08, 2011 at 15:43:30, Christophe Aeschlimann wrote: Hi Sudhakar, [...] Thanks for doing some testing on your side. Any specific reason why you used the gpio-keys-polled driver ? I'm using the standard gpio-keys driver which is based on a interrupt instead of polling. As I said I think it's a problem with the interruption mechanism. I am not able boot my board when I use the gpio-keys driver? Have you done any modifications to the kernel to use gpio-keys driver? Regards, Sudhakar Hi Sudhakar, Did you sort it out ? Tell me if you need any additional information. When I enable the gpio-keys driver I am getting the below error message when kernel is booting: gpio-keys gpio-keys.0: Unable to get irq number for GPIO 152, error -6 I am yet to debug this. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: PREEMPT_RT patches and GPIO (interrupts) problem
Hi Ben, On Fri, Feb 11, 2011 at 20:04:07, Ben Gardiner wrote: Hi Sudhakar, On Fri, Feb 11, 2011 at 6:03 AM, Rajashekhara, Sudhakar sudhakar@ti.com wrote: When I enable the gpio-keys driver I am getting the below error message when kernel is booting: gpio-keys gpio-keys.0: Unable to get irq number for GPIO 152, error -6 This error looks familiar to me; please excuse me if I presume too much. It looks like you may be trying to use the gpio-keys driver on an i2c expander. You are right. This driver requires interrupt-capable GPIOs and i2c expander GPIOs are not interrupt capable -- yet. The support needed for chained interrupts is being developed by Lennert Buytenhek as part of the ARM device tree support [1]. Thanks for the information. To reproduce Chritophe's problem, try using the L138's GPIOs directly in a gpio-keys driver instance. I'll look into this. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: PREEMPT_RT patches and GPIO (interrupts) problem
Hi, On Thu, Feb 03, 2011 at 15:08:39, Christophe Aeschlimann wrote: Hi, I'm working with the arago omapl1 kernel on a custom OMAP-L138 board. http://arago-project.org/git/projects/?p=linux-omapl1.git Recently I made some testing with the PREEMPT_RT patches (that were also applied in a branch in the arago kernel). The Kernel seems to behave correctly but I have issues with the GPIO interface. E.G. I'm using the gpio-keys and matrix-keypad drivers and they don't behave correctly. The symptoms are : Just after boot, I can press a button attached to a GPIO and get an event through the input subsystem, but after a few presses (few being random) the button doesn't generate an event any-more. (the interrupt is also not reported in /proc/interrupts). By browsing the mailing list archives I saw these old patches for the davinci tree and the omap tree : http://linux.omap.com/pipermail/davinci-linux-open-source/2007-October/004283.html http://marc.info/?l=linux-omapm=119634477133936w=2 (both are also listed here https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch) Of course quite a lot of things changed since 2.6.23 so it's difficult to just adapt the patches (I don't even know if they are still required or if I'm facing another issue). Anyway just wanted to know if someone is having the same issues or if there is a new version of the patches for the latest davinci kernel that I may have missed. I downloaded the Linux Kernel from arago which had these patches applied. I added support for gpio-keys-polled driver and tested it on AM1810 EVM from spectrum digital. I did not observe the issue you have reported. I pressed the push buttons on the daughter card for about 800 times and I used evtest to test. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: PREEMPT_RT patches and GPIO (interrupts) problem
Hi Christophe, On Tue, Feb 08, 2011 at 15:43:30, Christophe Aeschlimann wrote: Hi Sudhakar, [...] Thanks for doing some testing on your side. Any specific reason why you used the gpio-keys-polled driver ? I'm using the standard gpio-keys driver which is based on a interrupt instead of polling. As I said I think it's a problem with the interruption mechanism. I am not able boot my board when I use the gpio-keys driver? Have you done any modifications to the kernel to use gpio-keys driver? Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci EMAC driver uses random MAC addresses
Hi Steve, On Tue, Jan 11, 2011 at 23:48:43, Steve Chen wrote: On Tue, Jan 11, 2011 at 10:38 AM, Nori, Sekhar nsek...@ti.com wrote: Hi Steve, On Mon, Jan 10, 2011 at 20:40:56, Steve Chen wrote: Yes, this seems to be NFS specific. Ethernet works fine when mounting on EXT3 on SD. I'm not sure if this is related to the lengthy NFS discussion happening on ARM mailing list either, but is seems unlikely since it would affect all DaVinci variants. I can retest when a patch becomes available. Not sure if you noticed but Trond already posted a patch and it has already received some acks. Even without the patch, I was able to boot my OMAP-L138 board fine except some occasional errors and freezes. I have applied Trond's patch to my tree and will be testing it during my regular development. Sekhar, I'm still getting ... root: mount: mounting rootfs on / failed: No such file or directory root: mount: mounting usbfs on /proc/bus/usb failed: No such file or directory Setting up IP spoofing protection: rp_filter. Configuring network interfaces... udhcpc (v1.13.2) started Sending discover... Sending select for 192.168.40.109... Lease of 192.168.40.109 obtained, lease time 604800 nfs: server 192.168.40.101 not responding, still trying The init went passed udev, so NFS must be working earlier in the boot process. The failure is likely caused by some incompatibilities between the kernel and filesystem. Thanks for looking. I also faced this issue when used ip=dhcp in bootargs and this turned out to be a file system specific issue. Arago file system starts a dhcp client on eth0 interface. Disabling this DHCP client resolves the above issue. You need to edit the /etc/network/interfaces file of file system and comment out the line auto eth0. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: AM1808 EVM with davinci git sleep wake up
Hi Steve, On Thu, Jan 13, 2011 at 19:53:26, Steve Chen wrote: Hello, Running latest Davinci git kernel. I issued # echo mem /sys/power/state to put DA850 EVM in sleep mode. I'm unable to wake up the processor (tried UART, USB, or Ethernet). Anyone knows how to bring the processor back? I am facing an issue while doing suspend/resume on latest DaVinci git kernel. I followed: * Compiled using da8xx_omapl_defconfig. * Enabled CONFIG_PM and CONFIG_SUSPEND * booted the EVM using NFS * issued echo mem /sys/power/state At this stage I did not see any messages on the console. So I added no_console_suspend to bootargs and got the below error messages after issuing echo mem /sys/power/state: [ cut here ] WARNING: at drivers/net/davinci_emac.c:1040 emac_rx_handler+0xf0/0x110() Modules linked in: [c002d81c] (unwind_backtrace+0x0/0xec) from [c003d0b4] (warn_slowpath_common+0x4c/0x64) [c003d0b4] (warn_slowpath_common+0x4c/0x64) from [c003d0e4] (warn_slowpath_null+0x18/0x1c) [c003d0e4] (warn_slowpath_null+0x18/0x1c) from [c01a7c08] (emac_rx_handler+0xf0/0x110) [c01a7c08] (emac_rx_handler+0xf0/0x110) from [c01a87a4] (__cpdma_chan_free+0xb0/0xb4) [c01a87a4] (__cpdma_chan_free+0xb0/0xb4) from [c01a8ab8] (cpdma_chan_stop+0x174/0x1d4) [c01a8ab8] (cpdma_chan_stop+0x174/0x1d4) from [c01a8b98] (cpdma_ctlr_stop+0x80/0xe4) [c01a8b98] (cpdma_ctlr_stop+0x80/0xe4) from [c01a72a8] (emac_dev_stop+0xb0/0x168) [c01a72a8] (emac_dev_stop+0xb0/0x168) from [c01a7378] (davinci_emac_suspend+0x18/0x30) [c01a7378] (davinci_emac_suspend+0x18/0x30) from [c019d5ec] (platform_pm_suspend+0x30/0x5c) [c019d5ec] (platform_pm_suspend+0x30/0x5c) from [c019fdd4] (pm_op+0x4c/0xac) [c019fdd4] (pm_op+0x4c/0xac) from [c01a0674] (__device_suspend+0xec/0x140) [c01a0674] (__device_suspend+0xec/0x140) from [c01a0934] (dpm_suspend_start+0x26c/0x36c) [c01a0934] (dpm_suspend_start+0x26c/0x36c) from [c006cca0] (suspend_devices_and_enter+0x40/0x1ac) [c006cca0] (suspend_devices_and_enter+0x40/0x1ac) from [c006ceb0] (enter_state+0xa4/0xe0) [c006ceb0] (enter_state+0xa4/0xe0) from [c006c5d8] (state_store+0x90/0xb8) [c006c5d8] (state_store+0x90/0xb8) from [c0159dc8] (kobj_attr_store+0x18/0x1c) [c0159dc8] (kobj_attr_store+0x18/0x1c) from [c00e5dbc] (sysfs_write_file+0x108/0x140) [c00e5dbc] (sysfs_write_file+0x108/0x140) from [c009cc30] (vfs_write+0xac/0x134) [c009cc30] (vfs_write+0xac/0x134) from [c009cd64] (sys_write+0x3c/0x68) [c009cd64] (sys_write+0x3c/0x68) from [c0028f80] (ret_fast_syscall+0x0/0x2c) ---[ end trace febdd54cdf7fde9e ]--- I saw that you have mentioned that suspend/resume worked fine for you. Have you tried suspend/resume when using NFS root file system? I have not enabled any drivers in menuconfig except for I2C, Watchdog, RTC and Ethernet. emac_rx_handler() function was introduced by commit id 3ef0fdb2342cf58f617ce2bdcd133978629c2403. I have also cc'ed the author of this commit, just in case he can help. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] davinci: da8xx/omap-l1xx: match codec_name with i2c ids
The codec_name entry for da8xx evm in sound/soc/davinci/davinci-evm.c
is not matching with the i2c ids in the board file. Without this fix the
soundcard does not get detected on da850/omap-l138/am18x evm.
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
Tested-by: Dan Sharon dansha...@nanometrics.ca
---
This patch applies to Linus's kernel tree.
sound/soc/davinci/davinci-evm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 0c2d6ba..b36f0b3 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -223,7 +223,7 @@ static struct snd_soc_dai_link da8xx_evm_dai = {
.stream_name = AIC3X,
.cpu_dai_name= davinci-mcasp.0,
.codec_dai_name = tlv320aic3x-hifi,
- .codec_name = tlv320aic3x-codec.0-001a,
+ .codec_name = tlv320aic3x-codec.1-0018,
.platform_name = davinci-pcm-audio,
.init = evm_aic3x_init,
.ops = evm_ops,
--
1.7.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] davinci: da8xx/omap-l1x: add platform device for davinci-pcm-audio
Hi Sergei,
On Fri, Jan 21, 2011 at 20:53:32, Sergei Shtylyov wrote:
Hello.
Rajashekhara, Sudhakar wrote:
After the multi-component commit f0fba2ad
Please also specify the commit summary in parens, as asked by Linus.
Sure, will do it.
for ASoC, we need to
register the platform device for davinci-pcm-audio.
This patch and patch at [1] are required for audio to work on
DA850/OMAP-L138.
[1] https://patchwork.kernel.org/patch/495211/
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
Tested-by: Dan Sharon dansha...@nanometrics.ca
---
arch/arm/mach-davinci/devices-da8xx.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 9eec630..062190b 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -480,8 +480,20 @@ static struct platform_device da850_mcasp_device = {
.resource = da850_mcasp_resources,
};
+struct platform_device davinci_pcm_device = {
+ .name = davinci-pcm-audio,
+ .id = -1,
+};
+
+static void davinci_init_pcm(void)
+{
+ platform_device_register(davinci_pcm_device);
+}
+
void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
{
+ davinci_init_pcm();
Why not call platform_device_register() directly?
This is a good suggestion. Anyhow I am calling only platform_device_register()
functions inside da8xx_register_mcasp(), so I can add this one as well.
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] davinci: da8xx/omap-l1x: add platform device for davinci-pcm-audio
After the multi-component commit f0fba2ad (ASoC: multi-component - ASoC
Multi-Component Support) for ASoC, we need to register the platform
device for davinci-pcm-audio.
This patch and patch at [1] are required for audio to work on
DA850/OMAP-L138.
[1] https://patchwork.kernel.org/patch/495211/
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
---
Since v1, removed davinci_init_pcm() function and called
platform_device_register() from within da8xx_register_mcasp().
arch/arm/mach-davinci/devices-da8xx.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 9eec630..beda8a4 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -480,8 +480,15 @@ static struct platform_device da850_mcasp_device = {
.resource = da850_mcasp_resources,
};
+struct platform_device davinci_pcm_device = {
+ .name = davinci-pcm-audio,
+ .id = -1,
+};
+
void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
{
+ platform_device_register(davinci_pcm_device);
+
/* DA830/OMAP-L137 has 3 instances of McASP */
if (cpu_is_davinci_da830() id == 1) {
da830_mcasp1_device.dev.platform_data = pdata;
--
1.7.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: ALSA issue on DA850/OMAP-L138/AM18x
Hi Dan, Thanks for testing this patch. I'll add your Tested-by tag when I submit this patch. On Wed, Jan 19, 2011 at 00:32:21, Dan Sharon wrote: These patches apply cleanly to 'v2.6.37' 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5 of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git. The kernel was built with the 'da8xx_omapl_defconfig' from the omap-l1tree, and 'make menuconfig' to enable ASoC (the defconfig already has CONFIG_REGULATOR=y, CONFIG_REGULATOR_DUMMY=y, and CONFIG_REGULATOR_TPS6507X=y). Testing was done on a da850evm by tftp'ing the kernel into ram, and using the SPI-flash-based rootfs from the PSP that shipped with the board. Using 'arecord -r 48000 -c 2 -f S32_BE -t raw -v -d 1 /tmp/arecord.cap' produced a file of 384000 bytes (48000 x 2 x 4 bytes/sample). 'arecord -r 48000 -c 2 -f S32_BE -t raw -v /dev/null' ran flawlessly for several hours. I was not able to reproduce Sudhakar's problems with 'arecord -f dat | aplay -f dat'. Did you try the above, immediately after the da850evm boots? I am not facing the issue if I run arecod and aplay together after executing arecord or aplay individually. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 0/5] davinci: da850: clean up pinmux arrays in da850.c
Hi Sergei, On Tue, Jan 18, 2011 at 17:11:13, Sergei Shtylyov wrote: Hello. On 18-01-2011 7:40, Rajashekhara, Sudhakar wrote: I was testing Audio with 2.6.37 on DA850 from Kevin Hilman Linux tree at [1] and found that audio is broken. Below patch fixes the issue. --- From: Rajashekhara, Sudhakarsudhakar@ti.com davinci: fixes for audio on da850/omap-l138/am18x On DA850/OMAP-L138/AM18x, AIC3x codec is at 0x18 slave address. But in sound/soc/davinci/davinci-evm.c file, struct snd_soc_dai_link has the wrong AIC3x codec slave address. This patch fixes this issue. Also, this patch registers the platform device for davinci-pcm-audio. Shouldn't this be 2 patches? I don't see a connection between the changes. Yes, definitely this should be 2 patches. I just posted the fix as-is to unblock any folks who are facing the issue. As you can see from my e-mail there are still some issues which I am debugging currently. I'll post the proper patch later. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 0/5] davinci: da850: clean up pinmux arrays in da850.c
Hi,
I was testing Audio with 2.6.37 on DA850 from Kevin Hilman Linux tree
at [1] and found that audio is broken. Below patch fixes the issue.
---
From: Rajashekhara, Sudhakar sudhakar@ti.com
davinci: fixes for audio on da850/omap-l138/am18x
On DA850/OMAP-L138/AM18x, AIC3x codec is at 0x18 slave address.
But in sound/soc/davinci/davinci-evm.c file, struct snd_soc_dai_link
has the wrong AIC3x codec slave address. This patch fixes this issue.
Also, this patch registers the platform device for davinci-pcm-audio.
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 12
sound/soc/davinci/davinci-evm.c |2 +-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 9eec630..17c0dbc 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -473,6 +473,11 @@ static struct resource da850_mcasp_resources[] = {
},
};
+struct platform_device davinci_pcm_device = {
+ .name = davinci-pcm-audio,
+ .id = -1,
+};
+
static struct platform_device da850_mcasp_device = {
.name = davinci-mcasp,
.id = 0,
@@ -480,8 +485,15 @@ static struct platform_device da850_mcasp_device = {
.resource = da850_mcasp_resources,
};
+static void davinci_init_pcm(void)
+{
+ platform_device_register(davinci_pcm_device);
+}
+
void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
{
+ davinci_init_pcm();
+
/* DA830/OMAP-L137 has 3 instances of McASP */
if (cpu_is_davinci_da830() id == 1) {
da830_mcasp1_device.dev.platform_data = pdata;
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index bc9e6b0..07db881 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -224,7 +224,7 @@ static struct snd_soc_dai_link da8xx_evm_dai = {
.stream_name = AIC3X,
.cpu_dai_name= davinci-mcasp.0,
.codec_dai_name = tlv320aic3x-hifi,
- .codec_name = tlv320aic3x-codec.0-001a,
+ .codec_name = tlv320aic3x-codec.1-0018,
.platform_name = davinci-pcm-audio,
.init = evm_aic3x_init,
.ops = evm_ops,
---
Also, I found that either CONFIG_REGULATOR should not be defined or if
CONFIG_REGULATOR is defined then CONFIG_REGULATOR_DUMMY should also be
defined. Without this menuconfig fix, Soundcard does not get detected.
With the above fixes, arecord and aplay does not work for the first time.
Couple of times I get the below error:
root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat
arecord: main:608: audio open error: Invalid argument
aplay: playback:2297: read error
root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat
aplay: main:608: audio open error: Invalid argument
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Third time arecord and aplay work normally.
Has anyone seen such issues on DA850 or any other platform?
I am currently debugging this issue. I'll submit the above patch to community
once the issue of fixed.
[1]
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
ALSA issue on DA850/OMAP-L138/AM18x
Resending with proper $SUBJECT...
Hi,
I was testing Audio with 2.6.37 on DA850 from Kevin Hilman Linux tree
at [1] and found that audio is broken. Below patch fixes the issue.
---
From: Rajashekhara, Sudhakar sudhakar@ti.com
davinci: fixes for audio on da850/omap-l138/am18x
On DA850/OMAP-L138/AM18x, AIC3x codec is at 0x18 slave address.
But in sound/soc/davinci/davinci-evm.c file, struct snd_soc_dai_link
has the wrong AIC3x codec slave address. This patch fixes this issue.
Also, this patch registers the platform device for davinci-pcm-audio.
Signed-off-by: Rajashekhara, Sudhakar sudhakar@ti.com
---
arch/arm/mach-davinci/devices-da8xx.c | 12
sound/soc/davinci/davinci-evm.c |2 +-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 9eec630..17c0dbc 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -473,6 +473,11 @@ static struct resource da850_mcasp_resources[] = {
},
};
+struct platform_device davinci_pcm_device = {
+ .name = davinci-pcm-audio,
+ .id = -1,
+};
+
static struct platform_device da850_mcasp_device = {
.name = davinci-mcasp,
.id = 0,
@@ -480,8 +485,15 @@ static struct platform_device da850_mcasp_device = {
.resource = da850_mcasp_resources,
};
+static void davinci_init_pcm(void)
+{
+ platform_device_register(davinci_pcm_device);
+}
+
void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
{
+ davinci_init_pcm();
+
/* DA830/OMAP-L137 has 3 instances of McASP */
if (cpu_is_davinci_da830() id == 1) {
da830_mcasp1_device.dev.platform_data = pdata;
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index bc9e6b0..07db881 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -224,7 +224,7 @@ static struct snd_soc_dai_link da8xx_evm_dai = {
.stream_name = AIC3X,
.cpu_dai_name= davinci-mcasp.0,
.codec_dai_name = tlv320aic3x-hifi,
- .codec_name = tlv320aic3x-codec.0-001a,
+ .codec_name = tlv320aic3x-codec.1-0018,
.platform_name = davinci-pcm-audio,
.init = evm_aic3x_init,
.ops = evm_ops,
---
Also, I found that either CONFIG_REGULATOR should not be defined or if
CONFIG_REGULATOR is defined then CONFIG_REGULATOR_DUMMY should also be
defined. Without this menuconfig fix, Soundcard does not get detected.
With the above fixes, arecord and aplay does not work for the first time.
Couple of times I get the below error:
root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat
arecord: main:608: audio open error: Invalid argument
aplay: playback:2297: read error
root@da850-omapl138-evm:~# arecord -f dat | aplay -f dat
aplay: main:608: audio open error: Invalid argument
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Third time arecord and aplay work normally.
Has anyone seen such issues on DA850 or any other platform?
I am currently debugging this issue. I'll submit the above patch to community
once the issue of fixed.
[1]
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary
Regards,
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v1] davinci: Add additional JTAG code for AM-1808 and OMAP-L138 Rev 2.0 SoCs
Hi Mike, On Thu, Dec 23, 2010 at 05:41:54, Kevin Hilman wrote: Michael Williamson michael.william...@criticallink.com writes: On 12/22/2010 05:06 PM, Kevin Hilman wrote: Michael Williamson michael.william...@criticallink.com writes: The JTAG variant code for Rev-2.0 silicon of the OMAP-L138 has changed. In addition, the variant code for the AM-1808 SoC appears to match the Rev-2.0 code for the OMAP-L138. Add an additional entry to support these chips. Tested on? I'm assuming on the Mity platforms, right? I tested this using an AM-1808 (456 MHz speedgrade) on a MityARM-1808 configured SoM. I don't have a rev-2.0 silicon OMAP-L138 to try, but according to the Rev B datasheet the variant will change as described. It doesn't break the Rev 1 OMAP-L138 silicon MityDSP-L138F SoM. There was a thread about this in this list (link below) and I also have some background on an e2e link at TI (link below). I had forgotten that I pulled this patch from Sudhakar Rajashekhara on the arago omapl PSP kernel (link to patch below). It's really his work. I can resubmit (with tested-by and correct authorship) Yes please. Also add the links to the threads mentioned above. Also, please add Reported-by: Nicolas Luna luna...@gmail.com Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v5] Frame Buffer driver for TI DA8xx/OMAP-L1xx
On Wed, Jul 08, 2009 at 01:39:43, Krzysztof Helt wrote: On Mon, 6 Jul 2009 01:29:11 -0400 Rajashekhara, Sudhakar sudhakar@ti.com wrote: Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture. LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a. LCDC on DA8xx consists of two independent controllers, the Raster Controller and the LCD Interface Display Driver (LIDD) controller. LIDD further supports character and graphic displays. This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on the DA830 based EVM. The EVM details can be found at: http://support.spectrumdigital.com/boards/dskda830/revc/. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com Signed-off-by: Steve Chen sc...@mvista.com --- This patch applies to Linus's Kernel tree. Acked-by: Krzysztof Helt krzysztof...@wp.pl Thanks. What I should do to get this patch to Linus's tree? Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 2/2] davinci: DA850/OMAP-L138: add cpufreq support
On Mon, Jul 06, 2009 at 21:23:47, Sergei Shtylyov wrote: Hello. Sekhar Nori wrote: add basic cpufreq support for DA850/OMAP-L138 Currently, frequency scaling only on PLL0 is supported. No scaling of PLL1 or voltage levels as yet. This patch also moves Async3 clock source to PLL1 so that frequency scaling on PLL0 does not affect those peripherals. Without this the console on UART2 goes for a toss the moment CPUFreq kicks in. The OPP defintions assume clock input of 24MHz to the SoC. This is inline with hardcoding of input frequency in the soc.c files. At some point this will need to move into board dependent code as boards appear with different input clock. Tested with ondemand governer and a shell script to vary processor load. Signed-off-by: Sekhar Nori nsek...@ti.com diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c index 274f004..7a3a376 100644 --- a/arch/arm/mach-davinci/da850.c +++ b/arch/arm/mach-davinci/da850.c @@ -15,6 +15,7 @@ #include linux/init.h #include linux/clk.h #include linux/platform_device.h +#include linux/cpufreq.h #include asm/mach/map.h @@ -32,14 +33,20 @@ #define DA850_PSC0_BASE0x01c1 #define DA850_PLL0_BASE0x01c11000 -#define DA850_JTAG_ID_REG 0x01c14018 #define DA850_TIMER64P0_BASE 0x01c2 #define DA850_TIMER64P1_BASE 0x01c21000 #define DA850_GPIO_BASE0x01e26000 #define DA850_PSC1_BASE0x01e27000 #define DA850_PLL1_BASE0x01e1a000 Please don't duplicate these #define's which are not specific to DA850 and are the same for DA830. Could you move them into soime header file instead -- probably mach/hardware.h? Sergei, The above lines were added by my DA850/OMAP-L138 SoC and EVM patches. I'll move them to mach/da8xx.h file when I submit my next version of the patches. Kevin, Do you have any objections to moving these #defines to mach/da8xx.h file as they'll be common across DA830/OMAP-L137 and DA850/OMAP-L138? Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 2/2] davinci: Add support for DA850/OMAP-L138 EVM board
On Tue, Jul 07, 2009 at 21:32:44, Kevin Hilman wrote: Steve Chen sc...@mvista.com writes: On Tue, 2009-07-07 at 07:36 -0700, Kevin Hilman wrote: Steve can you rename the board name in RMK's machine registry from davinci_da8xx_evm to davinci_da830_evm. Done, Hmm, the names changed, but the Kconfig macro didn't change: http://www.arm.linux.org.uk/developer/machines/list.php?id=1781 I see that Steve has changed this. Shall I submit the updated patch once you pull in this change to DaVinci git? Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v5] Frame Buffer driver for TI DA8xx/OMAP-L1xx
Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture. LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a. LCDC on DA8xx consists of two independent controllers, the Raster Controller and the LCD Interface Display Driver (LIDD) controller. LIDD further supports character and graphic displays. This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on the DA830 based EVM. The EVM details can be found at: http://support.spectrumdigital.com/boards/dskda830/revc/. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com Signed-off-by: Steve Chen sc...@mvista.com --- This patch applies to Linus's Kernel tree. Since the previous version, fb_setcolreg function has been modified for 8 bit mode. drivers/video/Kconfig| 11 + drivers/video/Makefile |1 + drivers/video/da8xx-fb.c | 900 ++ include/video/da8xx-fb.h | 106 ++ 4 files changed, 1018 insertions(+), 0 deletions(-) create mode 100644 drivers/video/da8xx-fb.c create mode 100644 include/video/da8xx-fb.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 8afcf08..d048b7e 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2038,6 +2038,17 @@ config FB_SH7760 and 8, 15 or 16 bpp color; 90 degrees clockwise display rotation for panels = 320 pixel horizontal resolution. +config FB_DA8XX +tristate DA8xx/OMAP-L1xx Framebuffer support +depends on FB ARCH_DAVINCI_DA830 + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + ---help--- + This is the frame buffer device driver for the TI LCD controller + found on DA8xx/OMAP-L1xx SoCs. + If unsure, say N. + config FB_VIRTUAL tristate Virtual Frame Buffer support (ONLY FOR TESTING!) depends on FB diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 01a819f..288d9b0 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -136,6 +136,7 @@ obj-$(CONFIG_FB_OF) += offb.o obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o obj-$(CONFIG_FB_MX3) += mx3fb.o +obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o # the test framebuffer is last obj-$(CONFIG_FB_VIRTUAL) += vfb.o diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c new file mode 100644 index 000..4b9d80b --- /dev/null +++ b/drivers/video/da8xx-fb.c @@ -0,0 +1,900 @@ +/* + * Copyright (C) 2008-2009 MontaVista Software Inc. + * Copyright (C) 2008-2009 Texas Instruments Inc + * + * Based on the LCD driver for TI Avalanche processors written by + * Ajay Singh and Shalom Hai. + * + * 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 + */ +#include linux/module.h +#include linux/kernel.h +#include linux/fb.h +#include linux/dma-mapping.h +#include linux/device.h +#include linux/platform_device.h +#include linux/uaccess.h +#include linux/device.h +#include linux/interrupt.h +#include linux/clk.h +#include video/da8xx-fb.h + +#define DRIVER_NAME da8xx_lcdc + +/* LCD Status Register */ +#define LCD_END_OF_FRAME0 BIT(8) +#define LCD_FIFO_UNDERFLOW BIT(5) +#define LCD_SYNC_LOST BIT(2) + +/* LCD DMA Control Register */ +#define LCD_DMA_BURST_SIZE(x) ((x) 4) +#define LCD_DMA_BURST_10x0 +#define LCD_DMA_BURST_20x1 +#define LCD_DMA_BURST_40x2 +#define LCD_DMA_BURST_80x3 +#define LCD_DMA_BURST_16 0x4 +#define LCD_END_OF_FRAME_INT_ENA BIT(2) +#define LCD_DUAL_FRAME_BUFFER_ENABLE BIT(0) + +/* LCD Control Register */ +#define LCD_CLK_DIVISOR(x) ((x) 8) +#define LCD_RASTER_MODE0x01 + +/* LCD Raster Control Register */ +#define LCD_PALETTE_LOAD_MODE(x) ((x) 20) +#define PALETTE_AND_DATA 0x00 +#define PALETTE_ONLY 0x01 + +#define LCD_MONO_8BIT_MODE BIT(9) +#define LCD_RASTER_ORDER BIT(8) +#define LCD_TFT_MODE BIT(7) +#define LCD_UNDERFLOW_INT_ENA BIT(6) +#define
RE: [PATCH 2/2] davinci: Add support for DA850/OMAP-L138 EVM board
On Tue, Jul 07, 2009 at 00:02:00, Kevin Hilman wrote:
Rajashekhara, Sudhakar sudhakar@ti.com writes:
On Wed, Jul 01, 2009 at 23:24:21, Kevin Hilman wrote:
Rajashekhara, Sudhakar sudhakar@ti.com writes:
This patch also fixes broken CONFIG_DEBUG_LL support on
DA830/OMAP-L137 EVM caused by my previous patch.
hmm...
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h
b/arch/arm/mach-davinci/include/mach/uncompress.h
index 0f1f12b..28ea1f5 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -21,7 +21,8 @@ static u32 *uart;
static u32 *get_uart_base(void)
{
-if (__machine_arch_type == MACH_TYPE_DAVINCI_DA8XX_EVM)
+if (__machine_arch_type == MACH_TYPE_DAVINCI_DA8XX_EVM ||
+__machine_arch_type == MACH_TYPE_DAVINCI_DA850_EVM)
return (u32 *)DA8XX_UART2_BASE;
else
return (u32 *)DAVINCI_UART0_BASE;
this looks still broken for da830 since ..._DA8XX_EVM machine doesn't
exist.
No, it's not broken. DA830 EVM has been registered as DAVINCI_DA8XX_EVM.
Please refer to arch/arm/tools/mach-types.
Then the machine type was registered incorrectly as that is clearly a
wrong (and confusing) name for that board.
Please fix the machine-name registration and send a mach-types patch
along with an updated version of this patch.
FYI, I did not register DA830 board. Now if I register the DA830 again,
u-boot will break because.
Can I submit a patch against mach-types file to Russell King, which
changes the the EVM name to ..._DA830_EVM from ..._DA8XX_EVM?
Regards, Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 2/2] davinci: Add support for DA850/OMAP-L138 EVM board
On Wed, Jul 01, 2009 at 23:24:21, Kevin Hilman wrote:
Rajashekhara, Sudhakar sudhakar@ti.com writes:
This patch also fixes broken CONFIG_DEBUG_LL support on
DA830/OMAP-L137 EVM caused by my previous patch.
hmm...
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h
b/arch/arm/mach-davinci/include/mach/uncompress.h
index 0f1f12b..28ea1f5 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -21,7 +21,8 @@ static u32 *uart;
static u32 *get_uart_base(void)
{
- if (__machine_arch_type == MACH_TYPE_DAVINCI_DA8XX_EVM)
+ if (__machine_arch_type == MACH_TYPE_DAVINCI_DA8XX_EVM ||
+ __machine_arch_type == MACH_TYPE_DAVINCI_DA850_EVM)
return (u32 *)DA8XX_UART2_BASE;
else
return (u32 *)DAVINCI_UART0_BASE;
this looks still broken for da830 since ..._DA8XX_EVM machine doesn't exist.
No, it's not broken. DA830 EVM has been registered as DAVINCI_DA8XX_EVM.
Please refer to arch/arm/tools/mach-types.
Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [Linux-fbdev-devel] [PATCH v3] Frame Buffer driver for TI DA8xx/OMAP-L1xx
Hi, On Fri, Jun 26, 2009 at 10:48:55, Krzysztof Helt wrote: On Wed, 24 Jun 2009 06:58:21 -0400 Rajashekhara, Sudhakar sudhakar@ti.com wrote: Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture. LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a. LCDC on DA8xx consists of two independent controllers, the Raster Controller and the LCD Interface Display Driver (LIDD) controller. LIDD further supports character and graphic displays. This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on the DA830 based EVM. The EVM details can be found at: http://support.spectrumdigital.com/boards/dskda830/revc/. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com Signed-off-by: Steve Chen sc...@mvista.com --- [...] The true color modes do not use the palette entry. I assume that the value below forces controller to use true color mode. + palette[0] = 0x4000; + } + You are right. The above line enables the true color mode. I tested the driver with the changes suggested by you. I'll be submitting the v4 version of the patch soon. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/2] davinci: Add support for DA850/OMAP-L138 EVM board
Add support for the DA850/OMAP-L138 Evaluation Module (EVM) from TI. The EVM has User Interface (UI) card which contains various devices. This UI card can be connected to the base board. Support for all the devices on the UI card and ones on the EVM will be added in subsequent patches. The EVM schematics are not available publicly yet; but should be available soon. A new defconfig for this board has been added mainly because the DA830/OMAP-L137 defconfig forces writethrough cache mode which is not required on DA850/OMAP-L138. This patch has been boot tested on DA850/OMAP-L138 EVM using ramdisk as filesystem. This patch also fixes broken CONFIG_DEBUG_LL support on DA830/OMAP-L137 EVM caused by my previous patch. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- arch/arm/configs/da850_omapl138_defconfig| 1229 ++ arch/arm/mach-davinci/Kconfig|7 + arch/arm/mach-davinci/Makefile |1 + arch/arm/mach-davinci/board-da850-evm.c | 102 ++ arch/arm/mach-davinci/include/mach/debug-macro.S |3 +- arch/arm/mach-davinci/include/mach/uncompress.h |3 +- 6 files changed, 1343 insertions(+), 2 deletions(-) create mode 100644 arch/arm/configs/da850_omapl138_defconfig create mode 100644 arch/arm/mach-davinci/board-da850-evm.c diff --git a/arch/arm/configs/da850_omapl138_defconfig b/arch/arm/configs/da850_omapl138_defconfig new file mode 100644 index 000..842a70b --- /dev/null +++ b/arch/arm/configs/da850_omapl138_defconfig @@ -0,0 +1,1229 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.30-davinci1 +# Mon Jun 29 07:54:15 2009 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_MMU=y +# CONFIG_NO_IOPORT is not set +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_ZONE_DMA=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_LOCALVERSION_AUTO=y +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_CLASSIC_RCU=y +# CONFIG_TREE_RCU is not set +# CONFIG_PREEMPT_RCU is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_PREEMPT_RCU_TRACE is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +# CONFIG_CGROUPS is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +# CONFIG_STRIP_ASM_SYMS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLUB_DEBUG=y +CONFIG_COMPAT_BRK=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y +# CONFIG_SLOW_WORK is not set +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_MODVERSIONS=y +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +# CONFIG_IOSCHED_DEADLINE is not set +# CONFIG_IOSCHED_CFQ is not set +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory +# CONFIG_FREEZER is not set + +# +# System
RE: [Linux-fbdev-devel] [PATCH v3] Frame Buffer driver for TI DA8xx/OMAP-L1xx
Krzysztof,
-Original Message-
From: Krzysztof Helt [mailto:krzysztof...@poczta.fm]
Sent: Friday, June 26, 2009 10:49 AM
To: Rajashekhara, Sudhakar
Cc: linux-fbdev-de...@lists.sourceforge.net; davinci-linux-open-
sou...@linux.davincidsp.com; Steve Chen; Pavel Kiryukhin
Subject: Re: [Linux-fbdev-devel] [PATCH v3] Frame Buffer driver for TI
DA8xx/OMAP-L1xx
On Wed, 24 Jun 2009 06:58:21 -0400
Rajashekhara, Sudhakar sudhakar@ti.com wrote:
Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture.
LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a.
LCDC on DA8xx consists of two independent controllers, the Raster Controller
and the LCD Interface Display Driver (LIDD) controller. LIDD further
supports
character and graphic displays.
This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on
the DA830 based EVM. The EVM details can be found at:
http://support.spectrumdigital.com/boards/dskda830/revc/.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com
Signed-off-by: Steve Chen sc...@mvista.com
---
Since the previous version, error paths in probing function has been
corected, removed set_par() function and added code in fb_setcolreg()
function for TRUECOLOR mode.
drivers/video/Kconfig| 11 +
drivers/video/Makefile |1 +
drivers/video/da8xx-fb.c | 887
++
include/video/da8xx-fb.h | 106 ++
4 files changed, 1005 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/da8xx-fb.c
create mode 100644 include/video/da8xx-fb.h
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
new file mode 100644
index 000..a41ae62
--- /dev/null
+++ b/drivers/video/da8xx-fb.c
@@ -0,0 +1,887 @@
(fast forward)
+
+static int fb_setcolreg(unsigned regno, unsigned red, unsigned green,
+ unsigned blue, unsigned transp,
+ struct fb_info *info)
+{
+ struct da8xx_fb_par *par = info-par;
+ unsigned short *palette = (unsigned short *)par-v_palette_base;
+ u_short pal;
+
+ if (regno 255)
+ return 1;
+
+ if (info-fix.visual == FB_VISUAL_DIRECTCOLOR)
+ return 1;
+
+ if (info-var.bits_per_pixel == 8) {
+ red = 8;
+ green = 8;
+ blue = 8;
This function is still incorrect. Each color component value passed to the
function is 16 bit.
I assume you have 16-bit word for each palette entry and you want
to pack 4-bit colors like this 0RGB. The shift should be
red = 12;
so you reduced the component length to 4 bits then
red = 8;
so it is put on correct position in the palette entry.
You fold these two shifts so it is
red = 4;
The same logic should be used for all color components.
+
+ pal = (red 0x0f00);
+ pal |= (green 0x00f0);
+ pal |= (blue 0x000f);
+
+ palette[regno] = pal;
+
+ } else if ((info-var.bits_per_pixel == 16) regno 16) {
+ memset(palette, 0, 16);
I do not understand what is achieved by zeroing the palette area.
This is what you should use:
red = (16 - info-var.red.len)
red = info-var.red.offset;
The same logic should be used for all color components.
Then pack them into palette register:
par-pseudo_palette[ regno ] = red | green | blue;
The true color modes do not use the palette entry. I assume
that the value below forces controller to use true color mode.
+ palette[0] = 0x4000;
+ }
+
+ return 0;
+}
+
Regards,
Krzysztof
I'll test the driver with the modifications suggested by you
and will submit the updated version of the patch tomorrow.
Thanks, Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/2] davinci: Add base DA850/OMAP-L138 SoC support
The DA850/OMAP-L138 is a new SoC from TI in the same family as
DA830/OMAP-L137.
Major changes include better support for power management,
support for SATA devices and McBSP (same IP as DM644x).
The Techinical Reference Manual is not available publicly
as yet, but should be available soon.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/Kconfig|5 +
arch/arm/mach-davinci/Makefile |1 +
arch/arm/mach-davinci/da850.c| 630 ++
arch/arm/mach-davinci/include/mach/cputype.h |8 +
arch/arm/mach-davinci/include/mach/da8xx.h |8 +
arch/arm/mach-davinci/include/mach/irqs.h| 63 +++-
arch/arm/mach-davinci/include/mach/mux.h | 28 ++
arch/arm/mach-davinci/include/mach/psc.h |4 +
8 files changed, 744 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-davinci/da850.c
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index a8ce2dd..ca331e9 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -33,6 +33,11 @@ config ARCH_DAVINCI_DA830
select CP_INTC
select ARCH_DAVINCI_DA8XX
+config ARCH_DAVINCI_DA850
+ bool DA850/OMAP-L138 based system
+ select CP_INTC
+ select ARCH_DAVINCI_DA8XX
+
config ARCH_DAVINCI_DA8XX
bool
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index d183b11..5f8a661 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_ARCH_DAVINCI_DM355)+= dm355.o devices.o
obj-$(CONFIG_ARCH_DAVINCI_DM646x) += dm646x.o devices.o
obj-$(CONFIG_ARCH_DAVINCI_DM365) += dm365.o devices.o
obj-$(CONFIG_ARCH_DAVINCI_DA830)+= da830.o devices-da8xx.o
+obj-$(CONFIG_ARCH_DAVINCI_DA850)+= da850.o devices-da8xx.o
obj-$(CONFIG_AINTC)+= irq.o
obj-$(CONFIG_CP_INTC) += cp_intc.o
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
new file mode 100644
index 000..274f004
--- /dev/null
+++ b/arch/arm/mach-davinci/da850.c
@@ -0,0 +1,630 @@
+/*
+ * TI DA850/OMAP L138 chip specific setup
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Derived from: arch/arm/mach-davinci/da830.c
+ * Original Copyrights follow:
+ *
+ * 2009 (c) MontaVista Software, Inc. 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.
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/clk.h
+#include linux/platform_device.h
+
+#include asm/mach/map.h
+
+#include mach/clock.h
+#include mach/psc.h
+#include mach/mux.h
+#include mach/irqs.h
+#include mach/cputype.h
+#include mach/common.h
+#include mach/time.h
+#include mach/da8xx.h
+
+#include clock.h
+#include mux.h
+
+#define DA850_PSC0_BASE0x01c1
+#define DA850_PLL0_BASE0x01c11000
+#define DA850_JTAG_ID_REG 0x01c14018
+#define DA850_TIMER64P0_BASE 0x01c2
+#define DA850_TIMER64P1_BASE 0x01c21000
+#define DA850_GPIO_BASE0x01e26000
+#define DA850_PSC1_BASE0x01e27000
+#define DA850_PLL1_BASE0x01e1a000
+
+#define DA850_REF_FREQ 2400
+
+static struct pll_data pll0_data = {
+ .num= 1,
+ .phys_base = DA850_PLL0_BASE,
+ .flags = PLL_HAS_PREDIV | PLL_HAS_POSTDIV,
+};
+
+static struct clk ref_clk = {
+ .name = ref_clk,
+ .rate = DA850_REF_FREQ,
+};
+
+static struct clk pll0_clk = {
+ .name = pll0,
+ .parent = ref_clk,
+ .pll_data = pll0_data,
+ .flags = CLK_PLL,
+};
+
+static struct clk pll0_aux_clk = {
+ .name = pll0_aux_clk,
+ .parent = pll0_clk,
+ .flags = CLK_PLL | PRE_PLL,
+};
+
+static struct clk pll0_sysclk2 = {
+ .name = pll0_sysclk2,
+ .parent = pll0_clk,
+ .flags = CLK_PLL,
+ .div_reg= PLLDIV2,
+};
+
+static struct clk pll0_sysclk3 = {
+ .name = pll0_sysclk3,
+ .parent = pll0_clk,
+ .flags = CLK_PLL,
+ .div_reg= PLLDIV3,
+};
+
+static struct clk pll0_sysclk4 = {
+ .name = pll0_sysclk4,
+ .parent = pll0_clk,
+ .flags = CLK_PLL,
+ .div_reg= PLLDIV4,
+};
+
+static struct clk pll0_sysclk5 = {
+ .name = pll0_sysclk5,
+ .parent = pll0_clk,
+ .flags = CLK_PLL,
+ .div_reg= PLLDIV5,
+};
+
+static struct clk pll0_sysclk6 = {
+ .name = pll0_sysclk6,
+ .parent = pll0_clk,
+ .flags = CLK_PLL,
+ .div_reg= PLLDIV6,
+};
+
+static
RE: [PATCH 1/2] davinci: Add base DA850/OMAP-L138 SoC support
On Mon, Jun 29, 2009 at 18:59:02, Rajashekhara, Sudhakar wrote: The DA850/OMAP-L138 is a new SoC from TI in the same family as DA830/OMAP-L137. Major changes include better support for power management, support for SATA devices and McBSP (same IP as DM644x). The Technical Reference Manual is not available publicly as yet, but should be available soon. DA850/OMAP-L138 has been announced yesterday night. The documents are available at http://focus.ti.com/docs/prod/folders/print/omap-l138.html. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] davinci: Fix MMCSD compilation issue
Hi, On Wed, Jun 24, 2009 at 22:26:43, Kevin Hilman wrote: Rajashekhara, Sudhakar sudhakar@ti.com writes: Passes channel controller number as the first argument to edma_alloc_slot() API. Without this patch, kernel compilation fails with too few arguments to function 'edma_alloc_slot' error. This patch has been tested on DM6446 EVM. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- This patch applies to davinci git on top of the following patch. http://linux.omap.com/pipermail/davinci-linux-open-source/2009-June/01 4236.html Thanks, I reverted the old driver in davinci git, applied your v5 driver and added this patch to davinci git. Will push today. Re: $SUBJECT, this patch applies to drivers/mmc, so the subject should have been more descriptive and have a prefix like [PATCH] MMC: davinci: updates for EDMA API changes I changed this manually before applying. I got confused a bit regarding the subject line but now it's clear. Thanks for correcting $(SUBJECT) on my behalf. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v3] Frame Buffer driver for TI DA8xx/OMAP-L1xx
Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture. LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a. LCDC on DA8xx consists of two independent controllers, the Raster Controller and the LCD Interface Display Driver (LIDD) controller. LIDD further supports character and graphic displays. This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on the DA830 based EVM. The EVM details can be found at: http://support.spectrumdigital.com/boards/dskda830/revc/. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com Signed-off-by: Steve Chen sc...@mvista.com --- Since the previous version, error paths in probing function has been corected, removed set_par() function and added code in fb_setcolreg() function for TRUECOLOR mode. drivers/video/Kconfig| 11 + drivers/video/Makefile |1 + drivers/video/da8xx-fb.c | 887 ++ include/video/da8xx-fb.h | 106 ++ 4 files changed, 1005 insertions(+), 0 deletions(-) create mode 100644 drivers/video/da8xx-fb.c create mode 100644 include/video/da8xx-fb.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 693fb4e..fc0c191 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -1984,6 +1984,17 @@ config FB_DAVINCI hardware found on the TI DaVinci EVM. If unsure, say N. +config FB_DA8XX +tristate DA8xx/OMAP-L1xx Framebuffer support +depends on FB ARCH_DAVINCI_DA830 + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + ---help--- + This is the frame buffer device driver for the TI LCD controller + found on DA8xx/OMAP-L1xx SoCs. + If unsure, say N. + config FB_VIRTUAL tristate Virtual Frame Buffer support (ONLY FOR TESTING!) depends on FB diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 902d199..e7a3e7d 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -136,6 +136,7 @@ obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o obj-$(CONFIG_FB_MX3) += mx3fb.o obj-$(CONFIG_FB_DAVINCI) += davincifb.o +obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o # the test framebuffer is last obj-$(CONFIG_FB_VIRTUAL) += vfb.o diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c new file mode 100644 index 000..a41ae62 --- /dev/null +++ b/drivers/video/da8xx-fb.c @@ -0,0 +1,887 @@ +/* + * Copyright (C) 2008-2009 MontaVista Software Inc. + * Copyright (C) 2008-2009 Texas Instruments Inc + * + * 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 + */ +#include linux/module.h +#include linux/kernel.h +#include linux/fb.h +#include linux/dma-mapping.h +#include linux/device.h +#include linux/platform_device.h +#include linux/uaccess.h +#include linux/device.h +#include linux/interrupt.h +#include linux/clk.h +#include video/da8xx-fb.h + +#define DRIVER_NAME da8xx_lcdc + +/* LCD Status Register */ +#define LCD_END_OF_FRAME0 BIT(8) +#define LCD_FIFO_UNDERFLOW BIT(5) +#define LCD_SYNC_LOST BIT(2) + +/* LCD DMA Control Register */ +#define LCD_DMA_BURST_SIZE(x) ((x) 4) +#define LCD_DMA_BURST_10x0 +#define LCD_DMA_BURST_20x1 +#define LCD_DMA_BURST_40x2 +#define LCD_DMA_BURST_80x3 +#define LCD_DMA_BURST_16 0x4 +#define LCD_END_OF_FRAME_INT_ENA BIT(2) +#define LCD_DUAL_FRAME_BUFFER_ENABLE BIT(0) + +/* LCD Control Register */ +#define LCD_CLK_DIVISOR(x) ((x) 8) +#define LCD_RASTER_MODE0x01 + +/* LCD Raster Control Register */ +#define LCD_PALETTE_LOAD_MODE(x) ((x) 20) +#define PALETTE_AND_DATA 0x00 +#define PALETTE_ONLY 0x01 + +#define LCD_MONO_8BIT_MODE BIT(9) +#define LCD_RASTER_ORDER BIT(8) +#define LCD_TFT_MODE BIT(7) +#define LCD_UNDERFLOW_INT_ENA BIT(6) +#define LCD_MONOCHROME_MODEBIT(1) +#define LCD_RASTER_ENABLE BIT(0) +#define LCD_TFT_ALT_ENABLE
[PATCH] davinci: Fix MMCSD compilation issue
Passes channel controller number as the first argument to
edma_alloc_slot() API. Without this patch, kernel compilation
fails with too few arguments to function 'edma_alloc_slot'
error.
This patch has been tested on DM6446 EVM.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
This patch applies to davinci git on top of the following patch.
http://linux.omap.com/pipermail/davinci-linux-open-source/2009-June/014236.html
drivers/mmc/host/davinci_mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 170a0a0..e1095f3 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -589,7 +589,7 @@ static int __init davinci_acquire_dma_channels(struct
mmc_davinci_host *host)
* channel as needed to handle a scatterlist.
*/
for (i = 0; i ARRAY_SIZE(host-links); i++) {
- r = edma_alloc_slot(EDMA_SLOT_ANY);
+ r = edma_alloc_slot(EDMA_CTLR(host-txdma), EDMA_SLOT_ANY);
if (r 0) {
dev_dbg(mmc_dev(host-mmc), dma PaRAM alloc -- %d\n,
r);
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 2/2] ARM: DaVinci: Preparing for da850/omapl138 EVM support
Rename common macros and functions that have da830 string in
them to da8xx.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/board-da830-evm.c | 14 +++---
arch/arm/mach-davinci/include/mach/debug-macro.S |6 +++---
arch/arm/mach-davinci/include/mach/uncompress.h |2 +-
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 09d01f4..0409eb6 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -22,7 +22,7 @@
#include mach/common.h
#include mach/irqs.h
#include mach/cp_intc.h
-#include mach/da830.h
+#include mach/da8xx.h
#define DA830_EVM_PHY_MASK 0x0
#define DA830_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
@@ -56,7 +56,7 @@ static __init void da830_evm_init(void)
struct davinci_soc_info *soc_info = davinci_soc_info;
int ret;
- ret = da830_register_edma();
+ ret = da8xx_register_edma();
if (ret)
pr_warning(da830_evm_init: edma registration failed: %d\n,
ret);
@@ -66,7 +66,7 @@ static __init void da830_evm_init(void)
pr_warning(da830_evm_init: i2c0 mux setup failed: %d\n,
ret);
- ret = da830_register_i2c(0, da830_evm_i2c_0_pdata);
+ ret = da8xx_register_i2c(0, da830_evm_i2c_0_pdata);
if (ret)
pr_warning(da830_evm_init: i2c0 registration failed: %d\n,
ret);
@@ -80,12 +80,12 @@ static __init void da830_evm_init(void)
pr_warning(da830_evm_init: cpgmac mux setup failed: %d\n,
ret);
- ret = da830_register_emac();
+ ret = da8xx_register_emac();
if (ret)
pr_warning(da830_evm_init: emac registration failed: %d\n,
ret);
- ret = da830_register_watchdog();
+ ret = da8xx_register_watchdog();
if (ret)
pr_warning(da830_evm_init: watchdog registration failed: %d\n,
ret);
@@ -107,7 +107,7 @@ static __init void da830_evm_irq_init(void)
{
struct davinci_soc_info *soc_info = davinci_soc_info;
- cp_intc_init((void __iomem *)DA830_CP_INTC_VIRT, DA830_N_CP_INTC_IRQ,
+ cp_intc_init((void __iomem *)DA8XX_CP_INTC_VIRT, DA830_N_CP_INTC_IRQ,
soc_info-intc_irq_prios);
}
@@ -119,7 +119,7 @@ static void __init da830_evm_map_io(void)
MACHINE_START(DAVINCI_DA8XX_EVM, DaVinci DA830/OMAP L137 EVM)
.phys_io= IO_PHYS,
.io_pg_offst= (__IO_ADDRESS(IO_PHYS) 18) 0xfffc,
- .boot_params= (DA830_DDR_BASE + 0x100),
+ .boot_params= (DA8XX_DDR_BASE + 0x100),
.map_io = da830_evm_map_io,
.init_irq = da830_evm_irq_init,
.timer = davinci_timer,
diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S
b/arch/arm/mach-davinci/include/mach/debug-macro.S
index 6cb21e0..69837a6 100644
--- a/arch/arm/mach-davinci/include/mach/debug-macro.S
+++ b/arch/arm/mach-davinci/include/mach/debug-macro.S
@@ -24,9 +24,9 @@
tst \rx, #1 @ MMU enabled?
moveq \rx, #0x0100@ physical base address
movne \rx, #0xfe00@ virtual base
-#if defined(CONFIG_ARCH_DAVINCI_DA830) defined(CONFIG_ARCH_DAVINCI_DMx)
-#error Cannot enable DaVinci and DA830 platforms concurrently
-#elif defined(CONFIG_MACH_DAVINCI_DA830_EVM)
+#if defined(CONFIG_ARCH_DAVINCI_DA8XX) defined(CONFIG_ARCH_DAVINCI_DMx)
+#error Cannot enable DaVinci and DA8XX platforms concurrently
+#elif defined(CONFIG_MACH_DAVINCI_DA8XX_EVM)
orr \rx, \rx, #0x00d0 @ physical base address
orr \rx, \rx, #0xd000 @ of UART 2
#else
diff --git a/arch/arm/mach-davinci/include/mach/uncompress.h
b/arch/arm/mach-davinci/include/mach/uncompress.h
index 860ed7a..0f1f12b 100644
--- a/arch/arm/mach-davinci/include/mach/uncompress.h
+++ b/arch/arm/mach-davinci/include/mach/uncompress.h
@@ -22,7 +22,7 @@ static u32 *uart;
static u32 *get_uart_base(void)
{
if (__machine_arch_type == MACH_TYPE_DAVINCI_DA8XX_EVM)
- return (u32 *)DA830_UART2_BASE;
+ return (u32 *)DA8XX_UART2_BASE;
else
return (u32 *)DAVINCI_UART0_BASE;
}
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 0/2] ARM: DaVinci: Preparing for da850/omapl138 support
This series prepares the DaVinci git tree for TI da850/omapl138 support. This series is dependent on the following patch which I have submitted earlier. [PATCH] ARM: DaVinci: Pass proper EDMA platform data information - Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2 1/2] ARM: DaVinci: Preparing for da850/omapl138 SoC support
DA850/OMAP-L138 is the next generation DA830/OMAP-L137 processor
from TI.
DA830 and DA850 have many things in common. Instead of adding
new files for DA850 reuse the existing DA830 files by renaming
da830-xxx files to da8xx-xxx. Also rename common macros and
functions that have da830 string in them to da8xx.
A new config variable CONFIG_ARCH_DAVINCI_DA8XX, is added
to group DA830 and DA850 architectures.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/Kconfig |4 +
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/Makefile.boot |4 +-
arch/arm/mach-davinci/da830.c | 236 +++---
arch/arm/mach-davinci/devices-da830.c | 283 ---
arch/arm/mach-davinci/devices-da8xx.c | 283 +++
arch/arm/mach-davinci/include/mach/da830.h | 69 ---
arch/arm/mach-davinci/include/mach/da8xx.h | 69 +++
arch/arm/mach-davinci/include/mach/irqs.h | 148 +++---
arch/arm/mach-davinci/include/mach/memory.h | 10 +-
arch/arm/mach-davinci/include/mach/psc.h| 70
arch/arm/mach-davinci/include/mach/serial.h |6 +-
12 files changed, 596 insertions(+), 588 deletions(-)
delete mode 100644 arch/arm/mach-davinci/devices-da830.c
create mode 100644 arch/arm/mach-davinci/devices-da8xx.c
delete mode 100644 arch/arm/mach-davinci/include/mach/da830.h
create mode 100644 arch/arm/mach-davinci/include/mach/da8xx.h
diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 0817adf..0a586ca 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -31,6 +31,10 @@ config ARCH_DAVINCI_DM646x
config ARCH_DAVINCI_DA830
bool DA830/OMAP-L137 based system
select CP_INTC
+ select ARCH_DAVINCI_DA8XX
+
+config ARCH_DAVINCI_DA8XX
+ bool
config ARCH_DAVINCI_DM365
bool DaVinci 365 based system
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 59b77a3..d183b11 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_ARCH_DAVINCI_DM644x) += dm644x.o devices.o
obj-$(CONFIG_ARCH_DAVINCI_DM355)+= dm355.o devices.o
obj-$(CONFIG_ARCH_DAVINCI_DM646x) += dm646x.o devices.o
obj-$(CONFIG_ARCH_DAVINCI_DM365) += dm365.o devices.o
-obj-$(CONFIG_ARCH_DAVINCI_DA830)+= da830.o devices-da830.o
+obj-$(CONFIG_ARCH_DAVINCI_DA830)+= da830.o devices-da8xx.o
obj-$(CONFIG_AINTC)+= irq.o
obj-$(CONFIG_CP_INTC) += cp_intc.o
diff --git a/arch/arm/mach-davinci/Makefile.boot
b/arch/arm/mach-davinci/Makefile.boot
index 64e7824..db97ef2 100644
--- a/arch/arm/mach-davinci/Makefile.boot
+++ b/arch/arm/mach-davinci/Makefile.boot
@@ -1,6 +1,6 @@
-ifeq ($(CONFIG_ARCH_DAVINCI_DA830),y)
+ifeq ($(CONFIG_ARCH_DAVINCI_DA8XX),y)
ifeq ($(CONFIG_ARCH_DAVINCI_DMx),y)
-$(error Cannot enable DaVinci and DA830 platforms concurrently)
+$(error Cannot enable DaVinci and DA8XX platforms concurrently)
else
zreladdr-y := 0xc0008000
params_phys-y := 0xc100
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index ce8249a..ab42428 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -22,7 +22,7 @@
#include mach/cputype.h
#include mach/common.h
#include mach/time.h
-#include mach/da830.h
+#include mach/da8xx.h
#include clock.h
#include mux.h
@@ -131,137 +131,137 @@ static struct clk timerp64_1_clk = {
static struct clk arm_rom_clk = {
.name = arm_rom,
.parent = pll0_sysclk2,
- .lpsc = DA830_LPSC0_ARM_RAM_ROM,
+ .lpsc = DA8XX_LPSC0_ARM_RAM_ROM,
.flags = ALWAYS_ENABLED,
};
static struct clk scr0_ss_clk = {
.name = scr0_ss,
.parent = pll0_sysclk2,
- .lpsc = DA830_LPSC0_SCR0_SS,
+ .lpsc = DA8XX_LPSC0_SCR0_SS,
.flags = ALWAYS_ENABLED,
};
static struct clk scr1_ss_clk = {
.name = scr1_ss,
.parent = pll0_sysclk2,
- .lpsc = DA830_LPSC0_SCR1_SS,
+ .lpsc = DA8XX_LPSC0_SCR1_SS,
.flags = ALWAYS_ENABLED,
};
static struct clk scr2_ss_clk = {
.name = scr2_ss,
.parent = pll0_sysclk2,
- .lpsc = DA830_LPSC0_SCR2_SS,
+ .lpsc = DA8XX_LPSC0_SCR2_SS,
.flags = ALWAYS_ENABLED,
};
static struct clk dmax_clk = {
.name = dmax,
.parent = pll0_sysclk2,
- .lpsc = DA830_LPSC0_DMAX,
+ .lpsc = DA8XX_LPSC0_DMAX,
.flags = ALWAYS_ENABLED,
};
static struct clk tpcc_clk = {
.name = tpcc,
.parent
RE: [Linux-fbdev-devel] [PATCH] Frame Buffer driver for TI DA8xx/OMAP-L1xx
Hi,
On Fri, Jun 19, 2009 at 15:05:52, Krzysztof Helt wrote:
HI,
This version of the driver is much cleaner however major issues still
remains.
1. The driver seems not able to change graphics mode (depth or resolution)
but check_var() and set_par() are defined. The set_par() function does not
modify any register. You should move this few settings done there to
lcd initialization functions and just remove the check_var() and
set_par().
Forgot to remove this in my last version. I'll do it this time.
2. The driver does not set pseudo palette entries but uses true color mode
(16-bit). See other driver show to do this (I advice tdfxfb.c).
Sorry, but I didn't understand this comment. By default this driver uses
PSEUDOCOLOR mode and this controller does not need palette data for
TRUECOLOR
mode.
3. The request_mem_region() should be accompanied by the
release_mem_region()
(I have not noticed it in my previous review).
4. Check error paths in the probing functions. Not all already
requested/allocated
resources are released correctly (e.g. the in one path there is no
clk_put() called).
Will take care of both the above comments.
Minor issues are in comments below.
If any of above issues is false let me know. I am not specialist in all
types of
embedded lcd controllers.
Kind regards,
Krzysztof
On Thu, 18 Jun 2009 10:42:34 -0400
Rajashekhara, Sudhakar sudhakar@ti.com wrote:
Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture.
LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a.
LCDC on DA8xx consists of two independent controllers, the Raster
Controller
and the LCD Interface Display Driver (LIDD) controller. LIDD further
supports
character and graphic displays.
This patch adds support for the graphic display (Sharp LQ035Q3DG01)
found on
the DA830 based EVM. The EVM details can be found at:
http://support.spectrumdigital.com/boards/dskda830/revc/.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com
Signed-off-by: Steve Chen sc...@mvista.com
---
[. . . ]
+
+/* Palette Initialization */
+static int init_palette(struct fb_info *info)
+{
+ struct da8xx_fb_par *par = info-par;
+ unsigned short *palette = (unsigned short *)par-p_palette_base;
+ unsigned short i, size;
+
+ /* Palette Size */
+ size = (info-cmap.len / sizeof(*palette));
+
+ /* Clear the Palette */
+ memset(palette, 0, info-cmap.len);
+
+ /* Initialization of Palette for Default values */
+ for (i = 0; i size; i++)
+ *(unsigned short *)(palette + i) = i;
+
+ /* Setup the BPP */
+ switch (info-var.bits_per_pixel) {
+ case 1:
+ palette[0] |= BIT(11);
+ break;
+ case 2:
+ palette[0] |= BIT(12);
+ break;
+ case 4:
+ palette[0] |= (2 12);
+ break;
+ case 8:
+ palette[0] |= (3 12);
+ break;
+ case 16:
+ palette[0] |= (4 12);
+ break;
+ default:
+ dev_dbg(info-dev, GLCD: Unsupported Video BPP %d!\n,
+ info-var.bits_per_pixel);
+ return -EINVAL;
+ }
+
+ for (i = 0; i size; i++)
+ par-pseudo_palette[i] = i;
+
The pseudo palette entries do not need to be initialized. Just handle them
correctly in the fb_setcolreg.
Do you mean to say this whole function is not needed or just the above line?
+ return 0;
+}
[. . .]
+
+
+static int __init fb_probe(struct platform_device *device)
+{
+ struct da8xx_lcdc_platform_data *fb_pdata =
+ device-dev.platform_data;
+ struct lcd_ctrl_config *lcd_cfg;
+ struct da8xx_panel *lcdc_info;
+ struct fb_info *da8xx_fb_info;
+ struct resource *lcdc_regs;
+ struct clk *fb_clk = NULL;
+ struct da8xx_fb_par *par;
+ resource_size_t len;
+ int ret, i;
+
+ if (fb_pdata == NULL) {
+ dev_err(device-dev, Can not get platform data\n);
+ return -ENOENT;
+ }
+
+ lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
+ if (!lcdc_regs) {
+ dev_err(device-dev,
+ Can not get memory resource for LCD controller\n);
+ return -ENOENT;
+ }
+
+ len = lcdc_regs-end - lcdc_regs-start + 1;
+
+ lcdc_regs = request_mem_region(lcdc_regs-start, len,
lcdc_regs-name);
+ if (!lcdc_regs)
+ return -EBUSY;
+
+ da8xx_fb_reg_base = (resource_size_t)ioremap(lcdc_regs-start, len);
+
+ fb_clk = clk_get(device-dev, NULL);
+ if (IS_ERR(fb_clk)) {
+ dev_err(device-dev, Can not get device clock\n);
+ return -ENODEV;
+ }
+ ret = clk_enable(fb_clk);
+ if (ret)
+ goto err_clk_put;
+
+ for (i = 0, lcdc_info = known_lcd_panels
RE: [PATCH] ARM: DaVinci: Preparing for da850/omapl138 support
Hi, On Sat, Jun 20, 2009 at 03:49:18, Kevin Hilman wrote: Rajashekhara, Sudhakar sudhakar@ti.com writes: DA850/OMAP-L138 is the next generation DA830/OMAP-L137 processor from TI. DA830 and DA850 have many things in common. Instead of adding new files for DA850 reuse the existing DA830 files by renaming da830-xxx files to da8xx-xxx. Also rename common macros and functions that have da830 string in them to da8xx. A new config variable CONFIG_ARCH_DAVINCI_DA8XX, is added to group DA830 and DA850 architectures. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com Content-wise, this looks fine, some requests below... --- arch/arm/mach-davinci/Kconfig|4 + arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/Makefile.boot |4 +- arch/arm/mach-davinci/board-da830-evm.c | 14 +- arch/arm/mach-davinci/da830.c| 236 +- arch/arm/mach-davinci/devices-da830.c| 266 arch/arm/mach-davinci/devices-da8xx.c| 280 ++ Please use 'git mv' when renaming files. OK. arch/arm/mach-davinci/include/mach/da830.h | 69 -- arch/arm/mach-davinci/include/mach/da8xx.h | 69 ++ arch/arm/mach-davinci/include/mach/debug-macro.S |6 +- arch/arm/mach-davinci/include/mach/irqs.h| 148 ++-- arch/arm/mach-davinci/include/mach/memory.h |6 +- arch/arm/mach-davinci/include/mach/psc.h | 70 +++--- arch/arm/mach-davinci/include/mach/serial.h |6 +- arch/arm/mach-davinci/include/mach/uncompress.h |2 +- 15 files changed, 602 insertions(+), 580 deletions(-) delete mode 100644 arch/arm/mach-davinci/devices-da830.c create mode 100644 arch/arm/mach-davinci/devices-da8xx.c delete mode 100644 arch/arm/mach-davinci/include/mach/da830.h create mode 100644 arch/arm/mach-davinci/include/mach/da8xx.h Also, I'd like to merge this together with Mark's original series before submitting upstream. Therefore, to make that easier, could you break this up into two patches. One that touches the files in Mark's SoC support (commit 40e1b943581b2d92ab2f5b4750a554ff00b51323) and a 2nd that touches the files in Mark's EVM support (commit 32b9fa0df29d31e01b28c3296c3b0ed744a775da) Thanks, Kevin I'll rework on the patch as per your suggestion and will submit the updated version. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] ARM: DaVinci: Pass proper EDMA platform data information
Currently on da830/omapl137 EDMA fails to get initialized because
EDMA channel controller name is being passed wrongly. This is
preventing a kernel crash which could happen as the queue_tc_mapping
and queue_priority_mapping are not initialized for da830/omapl137.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/devices-da830.c | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da830.c
b/arch/arm/mach-davinci/devices-da830.c
index 95110ca..15cdff9 100644
--- a/arch/arm/mach-davinci/devices-da830.c
+++ b/arch/arm/mach-davinci/devices-da830.c
@@ -85,17 +85,34 @@ static const s8 da830_dma_chan_no_event[] = {
-1
};
+static const s8 da830_queue_tc_mapping[][2] = {
+ /* {event queue no, TC no} */
+ {0, 0},
+ {1, 1},
+ {-1, -1}
+};
+
+static const s8 da830_queue_priority_mapping[][2] = {
+ /* {event queue no, Priority} */
+ {0, 3},
+ {1, 7},
+ {-1, -1}
+};
+
static struct edma_soc_info da830_edma_info = {
- .n_channel = 32,
- .n_region = 4,
- .n_slot = 128,
- .n_tc = 2,
- .noevent= da830_dma_chan_no_event,
+ .n_channel = 32,
+ .n_region = 4,
+ .n_slot = 128,
+ .n_tc = 2,
+ .n_cc = 1,
+ .noevent= da830_dma_chan_no_event,
+ .queue_tc_mapping = da830_queue_tc_mapping,
+ .queue_priority_mapping = da830_queue_priority_mapping,
};
static struct resource da830_edma_resources[] = {
{
- .name = edma_cc,
+ .name = edma_cc0,
.start = DA830_TPCC_BASE,
.end= DA830_TPCC_BASE + SZ_32K - 1,
.flags = IORESOURCE_MEM,
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] ARM: DaVinci: Preparing for da850/omapl138 support
DA850/OMAP-L138 is the next generation DA830/OMAP-L137 processor from TI. DA830 and DA850 have many things in common. Instead of adding new files for DA850 reuse the existing DA830 files by renaming da830-xxx files to da8xx-xxx. Also rename common macros and functions that have da830 string in them to da8xx. A new config variable CONFIG_ARCH_DAVINCI_DA8XX, is added to group DA830 and DA850 architectures. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com --- arch/arm/mach-davinci/Kconfig|4 + arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/Makefile.boot |4 +- arch/arm/mach-davinci/board-da830-evm.c | 14 +- arch/arm/mach-davinci/da830.c| 236 +- arch/arm/mach-davinci/devices-da830.c| 266 arch/arm/mach-davinci/devices-da8xx.c| 280 ++ arch/arm/mach-davinci/include/mach/da830.h | 69 -- arch/arm/mach-davinci/include/mach/da8xx.h | 69 ++ arch/arm/mach-davinci/include/mach/debug-macro.S |6 +- arch/arm/mach-davinci/include/mach/irqs.h| 148 ++-- arch/arm/mach-davinci/include/mach/memory.h |6 +- arch/arm/mach-davinci/include/mach/psc.h | 70 +++--- arch/arm/mach-davinci/include/mach/serial.h |6 +- arch/arm/mach-davinci/include/mach/uncompress.h |2 +- 15 files changed, 602 insertions(+), 580 deletions(-) delete mode 100644 arch/arm/mach-davinci/devices-da830.c create mode 100644 arch/arm/mach-davinci/devices-da8xx.c delete mode 100644 arch/arm/mach-davinci/include/mach/da830.h create mode 100644 arch/arm/mach-davinci/include/mach/da8xx.h diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig index 0817adf..0a586ca 100644 --- a/arch/arm/mach-davinci/Kconfig +++ b/arch/arm/mach-davinci/Kconfig @@ -31,6 +31,10 @@ config ARCH_DAVINCI_DM646x config ARCH_DAVINCI_DA830 bool DA830/OMAP-L137 based system select CP_INTC + select ARCH_DAVINCI_DA8XX + +config ARCH_DAVINCI_DA8XX + bool config ARCH_DAVINCI_DM365 bool DaVinci 365 based system diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile index 59b77a3..d183b11 100644 --- a/arch/arm/mach-davinci/Makefile +++ b/arch/arm/mach-davinci/Makefile @@ -14,7 +14,7 @@ obj-$(CONFIG_ARCH_DAVINCI_DM644x) += dm644x.o devices.o obj-$(CONFIG_ARCH_DAVINCI_DM355)+= dm355.o devices.o obj-$(CONFIG_ARCH_DAVINCI_DM646x) += dm646x.o devices.o obj-$(CONFIG_ARCH_DAVINCI_DM365) += dm365.o devices.o -obj-$(CONFIG_ARCH_DAVINCI_DA830)+= da830.o devices-da830.o +obj-$(CONFIG_ARCH_DAVINCI_DA830)+= da830.o devices-da8xx.o obj-$(CONFIG_AINTC)+= irq.o obj-$(CONFIG_CP_INTC) += cp_intc.o diff --git a/arch/arm/mach-davinci/Makefile.boot b/arch/arm/mach-davinci/Makefile.boot index 64e7824..db97ef2 100644 --- a/arch/arm/mach-davinci/Makefile.boot +++ b/arch/arm/mach-davinci/Makefile.boot @@ -1,6 +1,6 @@ -ifeq ($(CONFIG_ARCH_DAVINCI_DA830),y) +ifeq ($(CONFIG_ARCH_DAVINCI_DA8XX),y) ifeq ($(CONFIG_ARCH_DAVINCI_DMx),y) -$(error Cannot enable DaVinci and DA830 platforms concurrently) +$(error Cannot enable DaVinci and DA8XX platforms concurrently) else zreladdr-y := 0xc0008000 params_phys-y := 0xc100 diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c index 09d01f4..0409eb6 100644 --- a/arch/arm/mach-davinci/board-da830-evm.c +++ b/arch/arm/mach-davinci/board-da830-evm.c @@ -22,7 +22,7 @@ #include mach/common.h #include mach/irqs.h #include mach/cp_intc.h -#include mach/da830.h +#include mach/da8xx.h #define DA830_EVM_PHY_MASK 0x0 #define DA830_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */ @@ -56,7 +56,7 @@ static __init void da830_evm_init(void) struct davinci_soc_info *soc_info = davinci_soc_info; int ret; - ret = da830_register_edma(); + ret = da8xx_register_edma(); if (ret) pr_warning(da830_evm_init: edma registration failed: %d\n, ret); @@ -66,7 +66,7 @@ static __init void da830_evm_init(void) pr_warning(da830_evm_init: i2c0 mux setup failed: %d\n, ret); - ret = da830_register_i2c(0, da830_evm_i2c_0_pdata); + ret = da8xx_register_i2c(0, da830_evm_i2c_0_pdata); if (ret) pr_warning(da830_evm_init: i2c0 registration failed: %d\n, ret); @@ -80,12 +80,12 @@ static __init void da830_evm_init(void) pr_warning(da830_evm_init: cpgmac mux setup failed: %d\n, ret); - ret = da830_register_emac(); + ret = da8xx_register_emac(); if (ret) pr_warning
RE: [Linux-fbdev-devel] [Resend] [PATCH] Frame Buffer driver for DA8XX
On Thu, Jun 18, 2009 at 03:08:54, Krzysztof Helt wrote: On Wed, 17 Jun 2009 10:01:10 -0400 Rajashekhara, Sudhakar sudhakar@ti.com wrote: Resending the same patch with additional Signed-off information. Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture. LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a. LCDC on DA8xx consists of two independent controllers, the Raster Controller and the LCD Interface Display Driver (LIDD) controller. LIDD further supports character and graphic displays. This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on the DA830 based EVM. The EVM details can be found at: http://support.spectrumdigital.com/boards/dskda830/revc/. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com Signed-off-by: Steve Chen sc...@mvista.com --- drivers/video/Kconfig| 11 + drivers/video/Makefile |1 + drivers/video/da8xx-fb.c | 964 ++ include/linux/da8xx-fb.h | 106 + 4 files changed, 1082 insertions(+), 0 deletions(-) create mode 100644 drivers/video/da8xx-fb.c create mode 100644 include/linux/da8xx-fb.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 693fb4e..fc0c191 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -1984,6 +1984,17 @@ config FB_DAVINCI hardware found on the TI DaVinci EVM. If unsure, say N. +config FB_DA8XX +tristate DA8xx/OMAP-L1xx Framebuffer support +depends on FB ARCH_DAVINCI_DA830 + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + ---help--- + This is the frame buffer device driver for the TI LCD controller + found on DA8xx/OMAP-L1xx SoCs. + If unsure, say N. + config FB_VIRTUAL tristate Virtual Frame Buffer support (ONLY FOR TESTING!) depends on FB diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 902d199..e7a3e7d 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -136,6 +136,7 @@ obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o obj-$(CONFIG_FB_MX3) += mx3fb.o obj-$(CONFIG_FB_DAVINCI) += davincifb.o +obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o # the test framebuffer is last obj-$(CONFIG_FB_VIRTUAL) += vfb.o diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c new file mode 100644 index 000..5e3b861 --- /dev/null +++ b/drivers/video/da8xx-fb.c @@ -0,0 +1,964 @@ +/* + * Copyright (C) 2008-2009 MontaVista Software Inc. + * Copyright (C) 2008-2009 Texas Instruments Inc + * + * 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 + */ +#include linux/module.h +#include linux/kernel.h +#include linux/fb.h +#include linux/dma-mapping.h +#include linux/device.h +#include linux/platform_device.h +#include mach/cputype.h +#include mach/io.h +#include mach/hardware.h +#include linux/uaccess.h +#include linux/device.h +#include linux/interrupt.h +#include linux/clk.h +#include linux/da8xx-fb.h + +#define DRIVER_NAME da8xx_lcdc + +/* LCD Status Register */ +#define LCD_END_OF_FRAME0 BIT(8) +#define LCD_FIFO_UNDERFLOW BIT(5) +#define LCD_SYNC_LOST BIT(2) + +/* LCD DMA Control Register */ +#define LCD_DMA_BURST_SIZE(x) ((x) 4) +#define LCD_DMA_BURST_10x0 +#define LCD_DMA_BURST_20x1 +#define LCD_DMA_BURST_40x2 +#define LCD_DMA_BURST_80x3 +#define LCD_DMA_BURST_16 0x4 +#define LCD_END_OF_FRAME_INT_ENA BIT(2) +#define LCD_DUAL_FRAME_BUFFER_ENABLE BIT(0) + +/* LCD Control Register */ +#define LCD_CLK_DIVISOR(x) ((x) 8) +#define LCD_RASTER_MODE0x01 + +/* LCD Raster Control Register */ +#define LCD_PALETTE_LOAD_MODE(x) ((x) 20) +#define PALETTE_AND_DATA 0x00 +#define PALETTE_ONLY 0x01 + +#define
[PATCH] Frame Buffer driver for TI DA8xx/OMAP-L1xx
Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture. LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a. LCDC on DA8xx consists of two independent controllers, the Raster Controller and the LCD Interface Display Driver (LIDD) controller. LIDD further supports character and graphic displays. This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on the DA830 based EVM. The EVM details can be found at: http://support.spectrumdigital.com/boards/dskda830/revc/. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com Signed-off-by: Steve Chen sc...@mvista.com --- drivers/video/Kconfig| 11 + drivers/video/Makefile |1 + drivers/video/da8xx-fb.c | 960 ++ include/video/da8xx-fb.h | 106 + 4 files changed, 1078 insertions(+), 0 deletions(-) create mode 100644 drivers/video/da8xx-fb.c create mode 100644 include/video/da8xx-fb.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 693fb4e..fc0c191 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -1984,6 +1984,17 @@ config FB_DAVINCI hardware found on the TI DaVinci EVM. If unsure, say N. +config FB_DA8XX +tristate DA8xx/OMAP-L1xx Framebuffer support +depends on FB ARCH_DAVINCI_DA830 + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + ---help--- + This is the frame buffer device driver for the TI LCD controller + found on DA8xx/OMAP-L1xx SoCs. + If unsure, say N. + config FB_VIRTUAL tristate Virtual Frame Buffer support (ONLY FOR TESTING!) depends on FB diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 902d199..e7a3e7d 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -136,6 +136,7 @@ obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o obj-$(CONFIG_FB_MX3) += mx3fb.o obj-$(CONFIG_FB_DAVINCI) += davincifb.o +obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o # the test framebuffer is last obj-$(CONFIG_FB_VIRTUAL) += vfb.o diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c new file mode 100644 index 000..3af5ca9 --- /dev/null +++ b/drivers/video/da8xx-fb.c @@ -0,0 +1,960 @@ +/* + * Copyright (C) 2008-2009 MontaVista Software Inc. + * Copyright (C) 2008-2009 Texas Instruments Inc + * + * 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 + */ +#include linux/module.h +#include linux/kernel.h +#include linux/fb.h +#include linux/dma-mapping.h +#include linux/device.h +#include linux/platform_device.h +#include mach/cputype.h +#include mach/io.h +#include mach/hardware.h +#include linux/uaccess.h +#include linux/device.h +#include linux/interrupt.h +#include linux/clk.h +#include video/da8xx-fb.h + +#define DRIVER_NAME da8xx_lcdc + +/* LCD Status Register */ +#define LCD_END_OF_FRAME0 BIT(8) +#define LCD_FIFO_UNDERFLOW BIT(5) +#define LCD_SYNC_LOST BIT(2) + +/* LCD DMA Control Register */ +#define LCD_DMA_BURST_SIZE(x) ((x) 4) +#define LCD_DMA_BURST_10x0 +#define LCD_DMA_BURST_20x1 +#define LCD_DMA_BURST_40x2 +#define LCD_DMA_BURST_80x3 +#define LCD_DMA_BURST_16 0x4 +#define LCD_END_OF_FRAME_INT_ENA BIT(2) +#define LCD_DUAL_FRAME_BUFFER_ENABLE BIT(0) + +/* LCD Control Register */ +#define LCD_CLK_DIVISOR(x) ((x) 8) +#define LCD_RASTER_MODE0x01 + +/* LCD Raster Control Register */ +#define LCD_PALETTE_LOAD_MODE(x) ((x) 20) +#define PALETTE_AND_DATA 0x00 +#define PALETTE_ONLY 0x01 + +#define LCD_MONO_8BIT_MODE BIT(9) +#define LCD_RASTER_ORDER BIT(8) +#define LCD_TFT_MODE BIT(7) +#define LCD_UNDERFLOW_INT_ENA BIT(6) +#define LCD_MONOCHROME_MODEBIT(1) +#define LCD_RASTER_ENABLE BIT(0) +#define LCD_TFT_ALT_ENABLE BIT(23) +#define LCD_STN_565_ENABLE BIT(24) + +/* LCD Raster Timing 2 Register
[PATCH] Frame Buffer driver for DA8XX
Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture. LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a. LCDC on DA8xx consists of two independent controllers, the Raster Controller and the LCD Interface Display Driver (LIDD) controller. LIDD further supports character and graphic displays. This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on the DA830 based EVM. The EVM details can be found at: http://support.spectrumdigital.com/boards/dskda830/revc/. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- drivers/video/Kconfig| 11 + drivers/video/Makefile |1 + drivers/video/da8xx-fb.c | 964 ++ include/linux/da8xx-fb.h | 106 + 4 files changed, 1082 insertions(+), 0 deletions(-) create mode 100644 drivers/video/da8xx-fb.c create mode 100644 include/linux/da8xx-fb.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 693fb4e..fc0c191 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -1984,6 +1984,17 @@ config FB_DAVINCI hardware found on the TI DaVinci EVM. If unsure, say N. +config FB_DA8XX +tristate DA8xx/OMAP-L1xx Framebuffer support +depends on FB ARCH_DAVINCI_DA830 + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + ---help--- + This is the frame buffer device driver for the TI LCD controller + found on DA8xx/OMAP-L1xx SoCs. + If unsure, say N. + config FB_VIRTUAL tristate Virtual Frame Buffer support (ONLY FOR TESTING!) depends on FB diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 902d199..e7a3e7d 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -136,6 +136,7 @@ obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o obj-$(CONFIG_FB_MX3) += mx3fb.o obj-$(CONFIG_FB_DAVINCI) += davincifb.o +obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o # the test framebuffer is last obj-$(CONFIG_FB_VIRTUAL) += vfb.o diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c new file mode 100644 index 000..5e3b861 --- /dev/null +++ b/drivers/video/da8xx-fb.c @@ -0,0 +1,964 @@ +/* + * Copyright (C) 2008-2009 MontaVista Software Inc. + * Copyright (C) 2008-2009 Texas Instruments Inc + * + * 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 + */ +#include linux/module.h +#include linux/kernel.h +#include linux/fb.h +#include linux/dma-mapping.h +#include linux/device.h +#include linux/platform_device.h +#include mach/cputype.h +#include mach/io.h +#include mach/hardware.h +#include linux/uaccess.h +#include linux/device.h +#include linux/interrupt.h +#include linux/clk.h +#include linux/da8xx-fb.h + +#define DRIVER_NAME da8xx_lcdc + +/* LCD Status Register */ +#define LCD_END_OF_FRAME0 BIT(8) +#define LCD_FIFO_UNDERFLOW BIT(5) +#define LCD_SYNC_LOST BIT(2) + +/* LCD DMA Control Register */ +#define LCD_DMA_BURST_SIZE(x) ((x) 4) +#define LCD_DMA_BURST_10x0 +#define LCD_DMA_BURST_20x1 +#define LCD_DMA_BURST_40x2 +#define LCD_DMA_BURST_80x3 +#define LCD_DMA_BURST_16 0x4 +#define LCD_END_OF_FRAME_INT_ENA BIT(2) +#define LCD_DUAL_FRAME_BUFFER_ENABLE BIT(0) + +/* LCD Control Register */ +#define LCD_CLK_DIVISOR(x) ((x) 8) +#define LCD_RASTER_MODE0x01 + +/* LCD Raster Control Register */ +#define LCD_PALETTE_LOAD_MODE(x) ((x) 20) +#define PALETTE_AND_DATA 0x00 +#define PALETTE_ONLY 0x01 + +#define LCD_MONO_8BIT_MODE BIT(9) +#define LCD_RASTER_ORDER BIT(8) +#define LCD_TFT_MODE BIT(7) +#define LCD_UNDERFLOW_INT_ENA BIT(6) +#define LCD_MONOCHROME_MODEBIT(1) +#define LCD_RASTER_ENABLE BIT(0) +#define LCD_TFT_ALT_ENABLE BIT(23) +#define LCD_STN_565_ENABLE BIT(24) + +/* LCD Raster Timing 2 Register */ +#define LCD_AC_BIAS_TRANSITIONS_PER_INT(x) ((x) 16) +#define LCD_AC_BIAS_FREQUENCY(x
[Resend] [PATCH] Frame Buffer driver for DA8XX
Reseding the same patch with additional Signed-off information. Adds LCD controller (LCDC) driver for TI's DA8xx/OMAP-L1xx architecture. LCDC specifications can be found at http://www.ti.com/litv/pdf/sprufm0a. LCDC on DA8xx consists of two independent controllers, the Raster Controller and the LCD Interface Display Driver (LIDD) controller. LIDD further supports character and graphic displays. This patch adds support for the graphic display (Sharp LQ035Q3DG01) found on the DA830 based EVM. The EVM details can be found at: http://support.spectrumdigital.com/boards/dskda830/revc/. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Signed-off-by: Pavel Kiryukhin pkiryuk...@ru.mvista.com Signed-off-by: Steve Chen sc...@mvista.com --- drivers/video/Kconfig| 11 + drivers/video/Makefile |1 + drivers/video/da8xx-fb.c | 964 ++ include/linux/da8xx-fb.h | 106 + 4 files changed, 1082 insertions(+), 0 deletions(-) create mode 100644 drivers/video/da8xx-fb.c create mode 100644 include/linux/da8xx-fb.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 693fb4e..fc0c191 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -1984,6 +1984,17 @@ config FB_DAVINCI hardware found on the TI DaVinci EVM. If unsure, say N. +config FB_DA8XX +tristate DA8xx/OMAP-L1xx Framebuffer support +depends on FB ARCH_DAVINCI_DA830 + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + ---help--- + This is the frame buffer device driver for the TI LCD controller + found on DA8xx/OMAP-L1xx SoCs. + If unsure, say N. + config FB_VIRTUAL tristate Virtual Frame Buffer support (ONLY FOR TESTING!) depends on FB diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 902d199..e7a3e7d 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -136,6 +136,7 @@ obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043fb.o obj-$(CONFIG_FB_BFIN_T350MCQB) += bfin-t350mcqb-fb.o obj-$(CONFIG_FB_MX3) += mx3fb.o obj-$(CONFIG_FB_DAVINCI) += davincifb.o +obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o # the test framebuffer is last obj-$(CONFIG_FB_VIRTUAL) += vfb.o diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c new file mode 100644 index 000..5e3b861 --- /dev/null +++ b/drivers/video/da8xx-fb.c @@ -0,0 +1,964 @@ +/* + * Copyright (C) 2008-2009 MontaVista Software Inc. + * Copyright (C) 2008-2009 Texas Instruments Inc + * + * 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 + */ +#include linux/module.h +#include linux/kernel.h +#include linux/fb.h +#include linux/dma-mapping.h +#include linux/device.h +#include linux/platform_device.h +#include mach/cputype.h +#include mach/io.h +#include mach/hardware.h +#include linux/uaccess.h +#include linux/device.h +#include linux/interrupt.h +#include linux/clk.h +#include linux/da8xx-fb.h + +#define DRIVER_NAME da8xx_lcdc + +/* LCD Status Register */ +#define LCD_END_OF_FRAME0 BIT(8) +#define LCD_FIFO_UNDERFLOW BIT(5) +#define LCD_SYNC_LOST BIT(2) + +/* LCD DMA Control Register */ +#define LCD_DMA_BURST_SIZE(x) ((x) 4) +#define LCD_DMA_BURST_10x0 +#define LCD_DMA_BURST_20x1 +#define LCD_DMA_BURST_40x2 +#define LCD_DMA_BURST_80x3 +#define LCD_DMA_BURST_16 0x4 +#define LCD_END_OF_FRAME_INT_ENA BIT(2) +#define LCD_DUAL_FRAME_BUFFER_ENABLE BIT(0) + +/* LCD Control Register */ +#define LCD_CLK_DIVISOR(x) ((x) 8) +#define LCD_RASTER_MODE0x01 + +/* LCD Raster Control Register */ +#define LCD_PALETTE_LOAD_MODE(x) ((x) 20) +#define PALETTE_AND_DATA 0x00 +#define PALETTE_ONLY 0x01 + +#define LCD_MONO_8BIT_MODE BIT(9) +#define LCD_RASTER_ORDER BIT(8) +#define LCD_TFT_MODE BIT(7) +#define LCD_UNDERFLOW_INT_ENA BIT(6) +#define LCD_MONOCHROME_MODEBIT(1) +#define LCD_RASTER_ENABLE BIT(0) +#define LCD_TFT_ALT_ENABLE BIT(23) +#define
RE: DaVinci git update: v2.6.30 + dm365 + da830
On Fri, Jun 12, 2009 at 01:56:38, Kevin Hilman wrote: Hello, DaVinci git has been update to v2.6.30 as well as the merging of basic support for dm365 and da830. I tried booting this kernel on DA830 using da830_omapl137_defconfig but booting hangs at: ... Load Address: c0008000 Entry Point: c0008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... The http://linux.omap.com/pipermail/davinci-linux-open-source/2009-April/012557. html patch from Mark Greer solves this issue. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4 2/2] ARM: DaVinci: Enable EDMA support for dm646x
From: Sudhakar Rajashekhara sudhakar@ti.com
Enables module clock for DM646x EDMA channel controller and transfer controller.
Channel mapping logic is introduced in dm646x EDMA. This implies that there is
no fixed association for a channel number to a parameter entry number. In other
words, using the DMA channel mapping registers (DCHMAPn), a PaRAM entry can be
mapped to any channel. While in the case of dm644x and dm355 there is a fixed
mapping between the EDMA channel and Param entry number.
Signed-off-by: Naresh Medisetty nar...@ti.com
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/dm646x.c | 40
arch/arm/mach-davinci/dma.c| 25 +
2 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 18a81ad..e4d7d0f 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -162,6 +162,41 @@ static struct clk arm_clk = {
.flags = ALWAYS_ENABLED,
};
+static struct clk edma_cc_clk = {
+ .name = edma_cc,
+ .parent = pll1_sysclk2,
+ .lpsc = DM646X_LPSC_TPCC,
+ .flags = ALWAYS_ENABLED,
+};
+
+static struct clk edma_tc0_clk = {
+ .name = edma_tc0,
+ .parent = pll1_sysclk2,
+ .lpsc = DM646X_LPSC_TPTC0,
+ .flags = ALWAYS_ENABLED,
+};
+
+static struct clk edma_tc1_clk = {
+ .name = edma_tc1,
+ .parent = pll1_sysclk2,
+ .lpsc = DM646X_LPSC_TPTC1,
+ .flags = ALWAYS_ENABLED,
+};
+
+static struct clk edma_tc2_clk = {
+ .name = edma_tc2,
+ .parent = pll1_sysclk2,
+ .lpsc = DM646X_LPSC_TPTC2,
+ .flags = ALWAYS_ENABLED,
+};
+
+static struct clk edma_tc3_clk = {
+ .name = edma_tc3,
+ .parent = pll1_sysclk2,
+ .lpsc = DM646X_LPSC_TPTC3,
+ .flags = ALWAYS_ENABLED,
+};
+
static struct clk uart0_clk = {
.name = uart0,
.parent = aux_clkin,
@@ -281,6 +316,11 @@ struct davinci_clk dm646x_clks[] = {
CLK(NULL, pll2_sysclk1, pll2_sysclk1),
CLK(NULL, dsp, dsp_clk),
CLK(NULL, arm, arm_clk),
+ CLK(NULL, edma_cc, edma_cc_clk),
+ CLK(NULL, edma_tc0, edma_tc0_clk),
+ CLK(NULL, edma_tc1, edma_tc1_clk),
+ CLK(NULL, edma_tc2, edma_tc2_clk),
+ CLK(NULL, edma_tc3, edma_tc3_clk),
CLK(NULL, uart0, uart0_clk),
CLK(NULL, uart1, uart1_clk),
CLK(NULL, uart2, uart2_clk),
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 50ac74f..1c60de6 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -104,6 +104,9 @@
#define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) 5))
+#define EDMA_DCHMAP0x0100 /* 64 registers */
+#define CHMAP_EXISTBIT(24)
+
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
#define EDMA_MAX_CC 2
@@ -287,6 +290,24 @@ static void __init assign_priority_to_queue(unsigned ctlr,
int queue_no,
((priority 0x7) bit));
}
+/**
+ * map_dmach_param - Maps channel number to param entry number
+ *
+ * This maps the dma channel number to param entry numberter. In
+ * other words using the DMA channel mapping registers a param entry
+ * can be mapped to any channel
+ *
+ * Callers are responsible for ensuring the channel mapping logic is
+ * included in that particular EDMA variant (Eg : dm646x)
+ *
+ */
+static void __init map_dmach_param(unsigned ctlr)
+{
+ int i;
+ for (i = 0; i EDMA_MAX_DMACH; i++)
+ edma_write_array(ctlr, EDMA_DCHMAP , i , (i 5));
+}
+
static inline void
setup_dma_interrupt(unsigned lch,
void (*callback)(unsigned channel, u16 ch_status, void *data),
@@ -1287,6 +1308,10 @@ static int __init edma_probe(struct platform_device
*pdev)
assign_priority_to_queue(pdev-id, queue_priority_mapping[i][0],
queue_priority_mapping[i][1]);
+ /* Map the channel to param entry if channel mapping logic exist */
+ if (edma_read(pdev-id, EDMA_CCCFG) CHMAP_EXIST)
+ map_dmach_param(pdev-id);
+
for (i = 0; i info-n_region; i++) {
edma_write_array2(pdev-id, EDMA_DRAE, i, 0, 0x0);
edma_write_array2(pdev-id, EDMA_DRAE, i, 1, 0x0);
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4 0/2] ARM: DaVinci: Add EDMA support for dm646x
From: Sudhakar Rajashekhara sudhakar@ti.com This series adds EDMA support for dm646x. These patches are based on the work done by Naresh Medisetty (nar...@ti.com). patch1: Move queue to tc mapping and queue priority mappings to dmsoc.c since the number of transfer controllers in dm646x is four and number of transfer controllers in dm644x/dm355 is two. patch2: Enables the module clock for EDMA channel controller and transfer controller. Maps channels to param sets which is specific to dm646x. -Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: about audio issue for kernel 2.6.30 on DM355 EVM.
Jeff, The latest kernel (2.6.30-rc7) does not show this warning message and even playback at 32KHz is fine on DM355. Regards, Sudhakar From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Jeff Sent: Tuesday, June 02, 2009 4:00 PM To: Davinci-Linux-Source Subject: about audio issue for kernel 2.6.30 on DM355 EVM. All, When I booted DM355 EVM using kernel 2.6.30 (with sram allocator), I got warning messages in the following. Advanced Linux Sound Architecture Driver Version 1.0.19. No device for DAI tlv320aic3x No device for DAI davinci-i2s soc-audio.1: use which platform_data? AIC3X Audio Codec 0.2 asoc: tlv320aic3x - davinci-i2s mapping ok ALSA device list: #0: DaVinci EVM (tlv320aic3x) It is correct? When I played a mp3 file with sample rate 32000HZ, the audio output was distortion. Any much help is appreciated. Thanks very much. BR, Jeff ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] ARM: DaVinci: Support for dm644x silicon revision 2.1
JTAG ID for DM644x silicon revision 2.1 has changed. An entry for the new
silicon revision needs to be added to the davinci_id structure. Without
this addition, EVMs with new silicon revision fail to boot the kernel.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/dm644x.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index a2f83af..1b3aec8 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -576,6 +576,13 @@ static struct davinci_id dm644x_ids[] = {
.cpu_id = DAVINCI_CPU_ID_DM6446,
.name = dm6446,
},
+ {
+ .variant= 0x1,
+ .part_no= 0xb700,
+ .manufacturer = 0x017,
+ .cpu_id = DAVINCI_CPU_ID_DM6446,
+ .name = dm6446a,
+ },
};
static void __iomem *dm644x_psc_bases[] = {
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 0/2] ARM: DaVinci: EDMA: Add EDMA support for dm646x
Kevin, nar...@ti.com writes: From: Naresh Medisetty nar...@ti.com Add EDMA support for dm646x Hi Naresh, After fixing review comments, please rebase against current DaVinci git. Your series had some conflicts with the 'multiple EDMA CC instances' series which is now merged. I'll re-submit these patches after fixing the review comments. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH V2] RFC: ARM: DaVinci: ASoc use iram to buffer sound
On Tue, May 26, 2009 at 08:04:02, Troy Kisky wrote: Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com --- I fixed 2 bugs in this version. 1. I ensure that buffer size is a multiple of period size. 2. Disable asp rx on shutdown. If it is not disabled on shutdown, you cannot initialize it to different settings. With this version of the patch, the set of underrun messages which were coming on DM644x EVM initially when loopback is started, are not coming. I observed one strange problem on DM644x. Noise is observed when loopback is run at 44100 KHz sample rate. When loopback is restarted, the noise goes away. On DM355 EVM though, I see one or two underrun messages when loopback is started. Recording and playback are working fine without any issues both on DM644x and DM355 EVMs. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Troy,
I tried this patch on DM644x EVM and following are my observations:
1. Playback works fine.
2. Record has some issues. Recorded stream has Loud volume on
the right side, and on the left, volume is very low.
3. Loopback (arecord -f cd | aplay -f cd) has some issues.
Audio is bit noisy here. I think if arecord issues are fixed,
this may go away.
On DM355, though arecord and aplay work fine independently. But
once loopback is run, arecord records data only on one side.
Loopback is noisy with intermittent overrun/underrun messages both
on DM355 and DM644x EVMs.
Regards, Sudhakar
-Original Message-
From: davinci-linux-open-source-
bounces+sudhakar.raj=ti@linux.davincidsp.com [mailto:davinci-linux-
open-source-bounces+sudhakar.raj=ti@linux.davincidsp.com] On Behalf
Of Troy Kisky
Sent: Wednesday, May 20, 2009 5:18 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Use the sram(iram) to avoid underrun on audio.
I will clean this up after someone says it
works for them.
Signed-off-by: Troy Kisky troy.ki...@boundarydevices.com
---
include/sound/soc-dai.h |2 +
sound/soc/davinci/davinci-i2s.c | 336 -
sound/soc/davinci/davinci-pcm.c | 516 ++-
sound/soc/davinci/davinci-pcm.h |3 +-
4 files changed, 618 insertions(+), 239 deletions(-)
diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 1367647..fe9bfa3 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -137,6 +137,7 @@ int snd_soc_dai_digital_mute(struct snd_soc_dai
*dai, int mute);
* This structure covers the clocking, formating and ALSA operations
for each
* interface a
*/
+/* ASoC DAI ops */
struct snd_soc_dai_ops {
/*
* DAI clocking configuration, all optional.
@@ -162,6 +163,7 @@ struct snd_soc_dai_ops {
* Called by soc-core to minimise any pops.
*/
int (*digital_mute)(struct snd_soc_dai *dai, int mute);
+ int (*inform_channel_order)(struct snd_soc_dai *dai, int
right_first);
/*
* ALSA PCM audio operations - all optional.
diff --git a/sound/soc/davinci/davinci-i2s.c
b/sound/soc/davinci/davinci-i2s.c
index b1ea52f..725a019 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -63,6 +63,7 @@
#define DAVINCI_MCBSP_RCR_RWDLEN1(v) ((v) 5)
#define DAVINCI_MCBSP_RCR_RFRLEN1(v) ((v) 8)
#define DAVINCI_MCBSP_RCR_RDATDLY(v) ((v) 16)
+#define DAVINCI_MCBSP_RCR_RFIG (1 18)
#define DAVINCI_MCBSP_RCR_RWDLEN2(v) ((v) 21)
#define DAVINCI_MCBSP_XCR_XWDLEN1(v) ((v) 5)
@@ -85,14 +86,6 @@
#define DAVINCI_MCBSP_PCR_FSRM (1 10)
#define DAVINCI_MCBSP_PCR_FSXM (1 11)
-#define MOD_REG_BIT(val, mask, set) do { \
- if (set) { \
- val |= mask; \
- } else { \
- val = ~mask; \
- } \
-} while (0)
-
enum {
DAVINCI_MCBSP_WORD_8 = 0,
DAVINCI_MCBSP_WORD_12,
@@ -112,8 +105,13 @@ static struct davinci_pcm_dma_params
davinci_i2s_pcm_in = {
struct davinci_mcbsp_dev {
void __iomem*base;
+#define MOD_DSP_A0
+#define MOD_DSP_B1
+ int mode;
+ u32 pcr;
struct clk *clk;
struct davinci_pcm_dma_params *dma_params[2];
+ struct snd_soc_dai *codec_dai;
};
static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev
*dev,
@@ -127,96 +125,100 @@ static inline u32 davinci_mcbsp_read_reg(struct
davinci_mcbsp_dev *dev, int reg)
return __raw_readl(dev-base + reg);
}
-static void davinci_mcbsp_start(struct snd_pcm_substream *substream)
+static void toggle_clock(struct davinci_mcbsp_dev *dev, int playback)
+{
+ u32 m = playback ? DAVINCI_MCBSP_PCR_CLKXP :
DAVINCI_MCBSP_PCR_CLKRP;
+ /* The clock needs to toggle to complete reset.
+ * So, fake it by toggling the clk polarity.
+ */
+ davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_PCR_REG, dev-pcr ^ m);
+ davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_PCR_REG, dev-pcr);
+}
+
+static void davinci_mcbsp_start(struct davinci_mcbsp_dev *dev,
+ struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
- struct davinci_mcbsp_dev *dev = rtd-dai-cpu_dai-private_data;
struct snd_soc_device *socdev = rtd-socdev;
struct snd_soc_platform *platform = socdev-card-platform;
- u32 w;
- int ret;
-
- /* Start the sample generator and enable transmitter/receiver */
- w = davinci_mcbsp_read_reg(dev, DAVINCI_MCBSP_SPCR_REG);
- MOD_REG_BIT(w, DAVINCI_MCBSP_SPCR_GRST, 1);
- davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, w);
+ int playback = (substream-stream == SNDRV_PCM_STREAM_PLAYBACK);
+
RE: [PATCH] RFC: ARM: DaVinci: ASoc use iram to buffer sound
Rajashekhara, Sudhakar wrote: Troy, I tried this patch on DM644x EVM and following are my observations: 1. Playback works fine. 2. Record has some issues. Recorded stream has Loud volume on the right side, and on the left, volume is very low. 3. Loopback (arecord -f cd | aplay -f cd) has some issues. Audio is bit noisy here. I think if arecord issues are fixed, this may go away. On DM355, though arecord and aplay work fine independently. But once loopback is run, arecord records data only on one side. Loopback is noisy with intermittent overrun/underrun messages both on DM355 and DM644x EVMs. Thanks for testing... Can you post the overrun/underrun messages. # arecord -f cd | aplay -f cd Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo underrun!!! (at least 0.372 ms long) underrun!!! (at least 0.146 ms long) underrun!!! (at least 0.147 ms long) underrun!!! (at least 0.153 ms long) underrun!!! (at least 0.153 ms long) underrun!!! (at least 0.159 ms long) underrun!!! (at least 0.149 ms long) underrun!!! (at least 0.153 ms long) underrun!!! (at least 0.153 ms long) underrun!!! (at least 0.236 ms long) underrun!!! (at least 0.147 ms long) underrun!!! (at least 0.180 ms long) underrun!!! (at least 0.159 ms long) underrun!!! (at least 0.154 ms long) underrun!!! (at least 0.154 ms long) underrun!!! (at least 0.149 ms long) underrun!!! (at least 0.145 ms long) underrun!!! (at least 0.149 ms long) underrun!!! (at least 0.176 ms long) Aborted by signal Interrupt... Aborted by signal Interrupt... # After I stop it, if I re-run the same command as above, I am not getting these messages. Which codec does the DM355 use. Is it AIC33 like DM6446 EVM? Yes, DM355 is using AIC33. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3 0/3] ARM: DaVinci: Add support for multiple EDMA CC instances
Anyone has any comments on these set of patches? Regards, Sudhakar Existing EDMA driver does not take care of multiple EDMA channel controller instances. An upcoming architecture from TI has 2 EDMA channel controller instances. This series adds support for multiple EDMA CC instances. With this patch, user needs to pass the EDMA channel number as EDMA_CTLR_CHAN(ctlr, chan), through IORESOURCE_DMA resources. The edma_alloc_channel api returns the channel number in LSB and controller number in MSB. This return value is accepted by the other EDMA apis. Drivers using EDMA have to pass controller number as an argument along with slot number required. The macros EDMA_CHAN_SLOT and EDMA_CTLR will extract the channel/slot number and the controller number from the value returned by edma_alloc_channel. This series has been tested on DM644x. -Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 1/3] ARM: DaVinci: Add support for multiple EDMA CC instances
Dave,
[...]
Plus, both your alloc_channel() and alloc_slot() are discarding the
controller they may have been told to use ... alloc_slot() should
if (slot = 0) {
ctlr = EDMA_CTLR(slot);
slot = EDMA_CHAN(slot);
}
I agree that I was discarding the controller information in
edma_alloc_channel function, but I am taking the controller
as an argument in edma_alloc_slot function.
Regards, Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 1/3] ARM: DaVinci: Add support for multiple EDMA CC instances
Dave,
/* PaRAM slots are laid out like this */
struct edmacc_param {
unsigned int opt;
@@ -171,6 +176,10 @@ enum sync_dimension {
ABSYNC = 1
};
+#define EDMA_CTLR_CHAN(ctlr, chan) (((ctlr) 16) | (chan))
+#define EDMA_CTLR(i) ((i) 16)
+#define EDMA_CHAN(i) ((i) 0x)
+
I can't quite think of a word that can mean channel or slot
and is already used in the DMA context. So all I'll do right
now is note that CHAN will be misleading when these are
used with slot identifiers, so a better tag would be nice.
As EDMA_CTLR_CHAN is used only to pass channel numbers, we can
leave it as it is and I am proposing to use EDMA_CHAN_SLOT
instead of EDMA_CHAN to get channel/slot numbers.
Regards, Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/3] ARM: DaVinci: Add support for multiple EDMA CC instances
Dave, This patch is needlessly intrusive and complex. [...] I agree with you. - Define one new channel macros, along the lines of #define EDMA_CHANNEL(ctlr,chn) (((ctlr)10)|(chan)) Those values would be passed in IORESOURCE_DMA resources, returned by edma_alloc_channel(), and accepted by all the current interfaces accepting an EDMA channel. Of course EDMA_CHANNEL_ANY would still work, but it could look at more controllers than just the first one. I started off with something similar initially and I came till the point where I had to add an extra argument to edma_alloc_slot(). At this point, I thought of adding the EDMA CC instance as an argument to all the interfaces to maintain uniformity in the code. [...] - Slot allocation would need some change, because it would need to be coupled to a controller (and thus its channels). This should be the only driver-visible change. Meaning, this should be the only change that is visible to the drivers using EDMA. Right? [...] Those three calls for logical EDMA channel IDs should work for slot IDs too: one to build IDs from a controller and slot number, and two extracting those numbers from the ID. Difference being that raw channel numbers are max 63, while raw' slot numbers can be bigger (I've seen 511). - Rather than converting static state to arrays, first collect all that state into a struct edma or somesuch, and have an array of those. Use platform_device.id to say which instance is being configured, and configure each instance normally in probe(). I'll work on these comments and post the patches again. During this, in case of any doubts, I'll get back to you. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/5] Initial support for Neuros Technologies OSD2 board
Please post the patches inline. Regards, Sudhakar From: davinci-linux-open-source-boun...@linux.davincidsp.com [davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Jorge Luis Zapata Muga [jorgeluis.zap...@gmail.com] Sent: Friday, April 03, 2009 5:00 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: [PATCH 1/5] Initial support for Neuros Technologies OSD2 board___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/5] Initial support for Neuros Technologies OSD2 board
Yes, you should submit the patches again. I assume you'll be using the git-send-email to send the patches. Regards, Sudhakar From: Jorge Luis Zapata Muga [jorgeluis.zap...@gmail.com] Sent: Friday, April 03, 2009 5:09 PM To: Rajashekhara, Sudhakar Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH 1/5] Initial support for Neuros Technologies OSD2 board On Fri, Apr 3, 2009 at 1:33 PM, Rajashekhara, Sudhakar sudhakar@ti.com wrote: Please post the patches inline. True, my fault. Didnt know the list rules. Should i send the patches again? Regards Regards, Sudhakar From: davinci-linux-open-source-boun...@linux.davincidsp.com [davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Jorge Luis Zapata Muga [jorgeluis.zap...@gmail.com] Sent: Friday, April 03, 2009 5:00 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: [PATCH 1/5] Initial support for Neuros Technologies OSD2 board___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/5] Initial support for Neuros Technologies OSD2 board
The patch has come properly but there are some things which you need to follow. Refer to the patches which have been submitted to the list. The $SUBJECT should have ARM: DaVinci: patch description. Also the patch body should have a description about the patch and signed-off by line. Regards, Sudhakar From: Jorge Luis Zapata Muga [jorgeluis.zap...@gmail.com] Sent: Friday, April 03, 2009 6:00 PM To: Rajashekhara, Sudhakar Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH 1/5] Initial support for Neuros Technologies OSD2 board On Fri, Apr 3, 2009 at 1:47 PM, Rajashekhara, Sudhakar sudhakar@ti.com wrote: Yes, you should submit the patches again. I assume you'll be using the git-send-email to send the patches. Yes, i had issues with gmail and SSL but is solved now. I have sent the first patch again, if the format is good enough please confirm so i can send the other patches as well. Regards Regards, Sudhakar From: Jorge Luis Zapata Muga [jorgeluis.zap...@gmail.com] Sent: Friday, April 03, 2009 5:09 PM To: Rajashekhara, Sudhakar Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH 1/5] Initial support for Neuros Technologies OSD2 board On Fri, Apr 3, 2009 at 1:33 PM, Rajashekhara, Sudhakar sudhakar@ti.com wrote: Please post the patches inline. True, my fault. Didnt know the list rules. Should i send the patches again? Regards Regards, Sudhakar From: davinci-linux-open-source-boun...@linux.davincidsp.com [davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Jorge Luis Zapata Muga [jorgeluis.zap...@gmail.com] Sent: Friday, April 03, 2009 5:00 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: [PATCH 1/5] Initial support for Neuros Technologies OSD2 board___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3] ARM: DaVinci: Fix for MMC/SD PIO mode on DA830/OMAP-L137
Kevin, Sudhakar Rajashekhara sudhakar@ti.com writes: Fixes the PIO mode for MMC/SD on TI's DA830/OMAP-L137 architecture. On TI's DA830/OMAP-L137, the DMATRIG bit should be set for PIO transfers. If MMC is being used for both PIO and EDMA based transfers, then it is likely that, an extra MMC EVENT is latched in the EDMA Event register even when just the CPU and MMC are in play. To properly switch from PIO to EDMA, clear any extra or unexpected event latched in the Event register, by doing a write to the corresponding bits in the ECR register. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com Thanks, pushed. Have you incorporated this update into the version you're submitting upstream? I'll incorporate these changes once Purushotam's patch gets accepted in mainline. Thanks, Sudhakar Kevin___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: Clear an EDMA event
Adds edma_clear_event API support to EDMA. There has been a change to the MMC interface on TI's DA830 architecture that requires setting the DMATRIG bit to trigger the first read data transfer when doing a read operation using the CPU, but it has the unintended consequence causing a DMA event. Because of this, the next DMA read from the MMC/SD will fail with an Event Miss. This API will be used to clear the ER. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com I forgot to add the sign-offs from David Griego and Sergei Shtylyov who are original authors of this patch. I'll re-submit this patch with the original sign-offs added. Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: Clear an EDMA event
Hello, I'll be re-submitting this patch as per David Brownell's suggestion. Regards, Sudhakar -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sergei Shtylyov Sent: Tuesday, March 24, 2009 3:43 PM To: David Brownell Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH] ARM: DaVinci: Clear an EDMA event David Brownell wrote: I forgot to add the sign-offs from David Griego and Sergei Shtylyov who are original authors of this patch. I'll re-submit this patch with the original sign-offs added. You should re-resubmit with the right From: line at the top of the patch, showing one of those two as the author of that patch. :) That would be David, though I'm not sure he'd insist on that. :-) WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: MMC/SD support for DA830
Sergei, Thanks for your comments. Hello. Sudhakar Rajashekhara wrote: Adds support for MMC/SD on TI's DA830 architecture. On TI's DA830, the DMATRIG bit should be set for CPU transfers. Could you call them PIO transfers for clarity? I agree with this. Will change it to PIO. @@ -317,6 +320,10 @@ static void mmc_davinci_start_command(struct mmc_davinci_host *host, if (host-do_dma) cmd_reg |= MMCCMD_DMATRIG; + if ((host-version == MMC_CTLR_VERSION_2) (host-data != NULL) + (host-data_dir == DAVINCI_MMC_DATADIR_READ)) Unneeded parens around == and !=. I'll remove them. @@ -1114,6 +1127,9 @@ static int __init davinci_mmcsd_probe(struct platform_device *pdev) if (!pdata || pdata-wires == 4 || pdata-wires == 0) mmc-caps |= MMC_CAP_4_BIT_DATA; + if (pdata-version) Unneeded check... I'll remove this check. Regards, Sudhakar + host-version = pdata-version; + WBR, Sergei___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: MMC/SD support for DA830
Dave, On Monday 23 March 2009, David Brownell wrote: This looks like *partial* support for at least the OMAP-L137. It omits the HSMMC/eMMC support for 8-bit parallel I/O. So $SUBJECT might usefully reference EDMA too ... :) Make that: reference PIO. Isn't EDMA support going to have to cope with the fact that the rw_threshold values associated with that bit are twice the size the driver currently expects? On da830/omap-l137, the FIFOLEV bit should be 0 for rw_threshold value of 32 and 1 for rw_threshold value of 64. EDMA support need not be changed as long as rw_threshold value remains 32. Regards, Sudhakar___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] ARM: DaVinci: MMC/SD support for DA830
Dave,
On Monday 23 March 2009, Sudhakar Rajashekhara wrote:
Adds support for MMC/SD on TI's DA830 architecture.
Also known as OMAP-L137? Regardless, if that chip
has the same issue, please update comments accordingly.
Likewise on the EDMA patch.
This behavior is seen both on DA830 and OMAP-L137. I'll update the description
of both the patches.
This looks like *partial* support for at least the
OMAP-L137. It omits the HSMMC/eMMC support for 8-bit
parallel I/O. So $SUBJECT might usefully reference
EDMA too ... :)
I'll update the $SUBJECT.
A procedural nit: now that the DaVinci MMC driver
has been sent for mainline inclusion -- although not
yet merged -- I'd send the next iteration of this
patch to LKML, referencing the patches on which it
relies: (a) that MMC driver, (b) platform support
for EDMA.
Once this patch gets accepted in the DaVinci tree, I'll post it to LKML also.
On TI's DA830, the DMATRIG bit should be set for CPU transfers.
As Sergei noted, PIO transfers.
Agreed.
+enum {
+ MMC_CTLR_VERSION_1, /* DM644x and DM355 */
+ MMC_CTLR_VERSION_2, /* DA830 */
+};
+
Make that explicit: MMC_CTR_VERSION_1 = 0 will avoid
some confusion.
Agreed.
Regards, Sudhakar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: need help for sdio stack
Are you building sdio as module? SDIO stack in DaVinciLSP_01_30_00_082 does not work if it's statically built. Regards, Sudhakar From: davinci-linux-open-source-boun...@linux.davincidsp.com [davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of 黄守旺 [huan...@temobi.com] Sent: Friday, March 13, 2009 1:51 PM To: Bin Qiu; Liu Yebo Cc: davinci-linux-open-sou...@linux. Subject: need help for sdio stack Bin Qiu,您好！ I have import DaVinciLSP_01_30_00_082 to Davinci DM6446，now i want to support SDHC . so i download and patch the patches below ti_davinci_mv_1_30_update_release_version_number_001 ti_davinci_mv_1_30_mmcsd_writeprotect_fix_002 ti_davinci_mv_1_30_usb_interrupt_scheduling_support_003 ti_davinci_mv_1_30_sdiostack_davinci_prepatch_004 ti_davinci_mv_1_30_sdiostack_atheros_005 ti_davinci_mv_1_30_sdiostack_atheros_sample_fd_006 ti_davinci_mv_1_30_sdiostack_atheros_benchmark_007 ti_davinci_mv_1_30_sdiostack_atheros_ar6000_wlan_008 ti_davinci_mv_1_30_sdiostack_davinci_hcd_009 ti_davinci_mv_1_30_sdiostack_davinci_sdhc_enhance_010 ti_davinci_mv_1_30_sdiostack_ar6000_fix_011 ti_davinci_mv_1_30_sdiostack_writeprotect_fix_012 ti_davinci_mv_1_30_nand_change_partition_information_013 In my config file,the CONFIG_MMC is disabled and SDIO ie enabled, but when i insert a Transcend SDHC card ,the board does not detetc it. Can you give me some advice,thanks a lot 致 礼！ 黄守旺 huan...@temobi.com 2009-03-13___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
