Re: [PATCH] net: davinci_emac: fix oops caused by uninitialized ndev-dev
Sekhar Nori nsek...@ti.com writes: Commit e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net: davinci_cpdma: Convert kzalloc() to devm_kzalloc()) triggered a bug in emac_probe() wherein dev member of net_device is used for devres allocations even before it is initialized. This patch fixes that by using the struct device in platform_device instead. While at it, use pdev-dev consistently for console messages instead of using ndev-dev for just one case and remove an unnecessary line continuation. Reported-by: Kevin Hilman khil...@linaro.org Helped-by: George Cherian george.cher...@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com Tested-by: Kevin Hilman khil...@linaro.org I verified this patch fixes the boot on dm365-evm (legacy boot) and da850-evm (DT boot). Thanks, Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
davinci boot failures in next-20140519
As found by my automated boot tester[1], dm365 EVM and da850 EVM started
failing boot tests in today's linux-next.
I haven't had the time to bisect, but it appears to be related to some
devres failures in the EMAC driver. Full boot log below for the
da850evm (the dm365 fault looks the same.)
Kevin
[1]
http://lists.linaro.org/pipermail/kernel-build-reports/2014-May/003561.html
Connected to da850evm console [channel connected] (~$quit to exit)
(user:khilman) is already connected
~$hardreset
Command(da850evm console) hardreset
(user:khilman) Reboot da850evm
`Reboot: da850evm ; phidget 4 2 : off, sleep, on
OMAP-L138 initialization passed!
Booting TI User Boot Loader
UBL Version: 1.65
UBL Flashtype: SPI
Starting SPI Memory Copy...
Valid magicnum, 0x55424CBB, found at offset 0x0001.
DONE
Jumping to entry point at 0xC108.
MMC: davinci: 0
SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB
Net: DaVinci-EMAC
Hit any key to stop autoboot:
3 0
U-Boot
U-Boot version
version
U-Boot 2014.01-dirty (Feb 27 2014 - 15:12:48)
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
GNU ld (GNU Binutils for Ubuntu) 2.23.52.20130913
U-Boot setenv bootargs console=ttyS2,115200n8 debug earlyprintk
setenv bootargs console=ttyS2,115200n8 debug earlyprintk
U-Boot if test -n ${initenv}; then run initenv; fi
if test -n ${initenv}; then run initenv; fi
U-Boot if test -n ${preboot}; then run preboot; fi
if test -n ${preboot}; then run preboot; fi
U-Boot setenv autoload no; setenv autoboot no
setenv autoload no; setenv autoboot no
U-Boot dhcp
dhcp
BOOTP broadcast 1
DHCP client bound to address 192.168.1.194
U-Boot setenv serverip 192.168.1.2
setenv serverip 192.168.1.2
U-Boot if test -n ${netargs}; then run netargs; fi
if test -n ${netargs}; then run netargs; fi
U-Boot tftp 0xc080 192.168.1.2:tmp/da850evm-ySSgF4/zImage-dtb-Ua2SNu
tftp 0xc080 192.168.1.2:tmp/da850evm-ySSgF4/zImage-dtb-Ua2SNu
Using DaVinci-EMAC device
TFTP from server 192.168.1.2; our IP address is 192.168.1.194
Filename 'tmp/da850evm-ySSgF4/zImage-dtb-Ua2SNu'.
Load address: 0xc080
Loading: *#
#
#
1.7 MiB/s
done
Bytes transferred = 2261167 (2280af hex)
U-Boot tftp 0xc0c0 192.168.1.2:buildroot.cpio.gz.uboot
tftp 0xc0c0 192.168.1.2:buildroot.cpio.gz.uboot
Using DaVinci-EMAC device
TFTP from server 192.168.1.2; our IP address is 192.168.1.194
Filename 'buildroot.cpio.gz.uboot'.
Load address: 0xc0c0
Loading: *
1.7 MiB/s
done
Bytes transferred = 642602 (9ce2a hex)
U-Boot printenv bootargs
printenv bootargs
bootargs=console=ttyS2,115200n8 debug earlyprintk
U-Boot bootz 0xc080 0xc0c0
bootz 0xc080 0xc0c0
Kernel image @ 0xc080 [ 0x00 - 0x226598 ]
## Loading init Ramdisk from Legacy Image at c0c0 ...
Image Name:
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size:642538 Bytes = 627.5 KiB
Load Address:
Entry Point:
Verifying Checksum ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.15.0-rc5-next-20140519 (buildslave@kbuilderdedi01) (gcc version
4.7.1 (Ubuntu/Linaro 4.7.1-5ubuntu1~ppa1) ) #1 PREEMPT Mon May 19 11:11:13 CEST
2014
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine model: DA850/AM1808/OMAP-L138 EVM
Memory policy: Data cache writethrough
DaVinci da850/omap-l138 variant 0x0
On node 0 totalpages: 32768
free_area_init_node: node 0, pgdat c045e6b0, node_mem_map c7efa000
DMA zone: 256 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 32768 pages, LIFO batch:7
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: console=ttyS2,115200n8 debug earlyprintk
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 124592K/131072K available (3046K kernel code, 260K rwdata, 972K rodata,
159K init, 174K bss, 6480K reserved)
Virtual kernel memory layout:
vector : 0x - 0x1000 ( 4 kB)
fixmap : 0xffc0 - 0xffe0 (2048 kB)
vmalloc : 0xc880 - 0xff00 ( 872 MB)
lowmem : 0xc000 - 0xc800 ( 128 MB)
modules : 0xbf00 - 0xc000 ( 16 MB)
.text : 0xc0008000 - 0xc03f4e64 (4020 kB)
.init : 0xc03f5000 - 0xc041ce44 ( 160 kB)
Re: [PATCH] ARM: davinci: fix DT booting with default defconfig
On Sun, Mar 16, 2014 at 10:00 PM, Sekhar Nori nsek...@ti.com wrote: On Friday 14 March 2014 11:00 PM, Kevin Hilman wrote: Davinci boards tend to have older booloaders without DTB support. Enable appended DTB support by default to allow DT booting on older platforms. While there, also enable /proc/device-tree support for easy verification of DT boot. Signed-off-by: Kevin Hilman khil...@linaro.org --- Sekhar, this applies on top of your latest defconfig cleanup queued for v3.15 and validated with DT and legacy boot on DA850 EVM. Thanks Kevin. If you will take this directly through ARM-SoC: Acked-by: Sekhar Nori nsek...@ti.com I'd prefer if you just take it along with your changes. Maybe as a fix for v3.15-rc since it fixes some booting issues with legacy booting on top of your defconfig cleanup. 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: [GIT PULL] DaVinci DT updates for v3.14
Sekhar Nori nsek...@ti.com writes: The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e: Linux 3.13-rc3 (2013-12-06 09:34:04 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.14/dt for you to fetch changes up to 3a9574f2aa4ffd9b867321a1f298893410bd3718: ARM: davinci: da850 evm: add GPIO pinumux entries DT node (2013-12-15 18:40:49 +0530) DaVinci device tree file updates to add GPIO support. Pulled into next/dt. Thanks, 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: [GIT PULL] A DaVinci SoC update for v3.14
Sekhar Nori nsek...@ti.com writes: The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.14/soc for you to fetch changes up to 4408c26bc37fa8ada493ad41a6c7659b76fff483: ARM: davinci: clock: return 0 upon error from clk_round_rate() (2013-11-27 14:48:33 +0530) A patch to fix the return value of clk_round_rate() Pulled into next/soc, Thanks, 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: [GIT PULL] DaVinci watchdog change for v3.14
Sekhar Nori nsek...@ti.com writes: Hi Arnd, Olof, Kevin, Can you please pull the following patch. It has been acked by Wim. There are some other davinci_wdt.c patches Wim has queued in his tree, but a test merge of this patch with latest linux-next does not throw any conflicts. Thanks, Sekhar The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.14/watchdog for you to fetch changes up to 843748123d95ae77a489b41f2f193e8502fc7ea8: watchdog: davinci: rename platform driver to davinci-wdt (2014-01-09 16:48:31 +0530) This patch updates the davinci watchdog platform device name from generic watchdog to something more specific. Pulled into next/drivers, Thanks, 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: [GIT PULL] DaVinci: an SoC update for v3.13
Sekhar Nori nsek...@ti.com writes: The following changes since commit 61e6cfa80de5760bbe406f4e815b7739205754d2: Linux 3.12-rc5 (2013-10-13 15:41:28 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.13/soc-2 for you to fetch changes up to 859236d017978bb95f3e2794aece57da3a40fe5c: ARM: davinci: convert to clockevents_config_and_register (2013-10-16 06:14:55 +0530) This pull request includes a patch to use clockevents_config_and_register() for registering the clockevent. Pulled into next/soc. In the future, please base these off of older -rc releases unless there's a dependency. That helps us from having to pull in the latest -rc into several of our sub branches. In this case, since it looks like your branch isn't already in -next, I've just rebased it onto -rc3 since that's where next/soc was currently based. Thanks, 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: [GIT PULL 1/2] DaVinci SoC updates for v3.12
Sekhar Nori nsek...@ti.com writes: Hi Arnd, Olof, Kevin, Please pull the following DaVinci SoC changes for v3.12 Thanks, Sekhar The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b: Linux 3.11-rc2 (2013-07-21 12:05:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.12/soc for you to fetch changes up to 46c1833467c5e555f31cd6f14b342a7383f26885: ARM: davinci: fix clock lookup for mdio device (2013-08-22 00:39:01 +0530) DaVinci SoC updates for v3.12 - This set of SoC updates contains changes to the way UART clock is handled to enabled DT-boot to obtain UART clock frequency instead of relying on DT-binding being supplied. Similarly handling of MDIO clock is fixed to make it easier to support MDIO in DT-boot. Finally there is patch to remove now unnecessary setting of wake-up capable flag for RTC. Thanks for the detailed description. Pulled into next/soc 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: [GIT PULL 2/2] DaVinci DT updates for v3.12
Sekhar Nori nsek...@ti.com writes: Hi Arnd, Olof, Kevin, Please pull the following DaVinci DT updates for v3.12. It depends on the SoC updates in 1/2 Thanks, Sekhar The following changes since commit 46c1833467c5e555f31cd6f14b342a7383f26885: ARM: davinci: fix clock lookup for mdio device (2013-08-22 00:39:01 +0530) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.12/dt for you to fetch changes up to 29864962f79e3dab645a5b00ccc7d4da96e9db33: ARM: davinci: da850: do not specify clock_frequency for UART DT node (2013-08-22 00:44:58 +0530) DaVinci DT updates for v3.12 This set of patches add ethernet DT nodes for DA850 and also remove now unneeded specification of UART clock frequency so kernel can now boot irrespective of what the bootloader setting of UART frequency is. Pulled into next/soc (due to dependency on soc changes in GIT PULL 1/1) 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: [GIT PULL] DaVinci fixes for v3.11
Hi Sekhar, Sekhar Nori nsek...@ti.com writes: The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v3.11 for you to fetch changes up to de30e316d38b0837fe4c09b43f1b52c8e230c44e: ARM: davinci: nand: specify ecc strength (2013-08-16 15:12:20 +0530) This pull request includes a patch for making NAND flash work on multiple DaVinci boards. The NAND probe was failing because ecc strength was not specified while using hardware ecc algorithm. Note that our current fixes branch is based on -rc4, and since it doesn't look like this fix is in -next, I've rebased it onto our fixes branch. IOW, rebased to -rc4, and applied to fixes. In general, we prefer fixes based on older -rcs (at least not newer than the current fixes branch) unless there is a dependency on a newer -rc. Thanks, 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 2/2] rtc: omap: add rtc wakeup support to alarm events
Hebbar, Gururaja gururaja.heb...@ti.com writes: Hi Kevin, On Mon, Jun 10, 2013 at 16:55:17, Hebbar, Gururaja wrote: On Fri, May 31, 2013 at 23:11:22, Kevin Hilman wrote: Hebbar Gururaja gururaja.heb...@ti.com writes: On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN) is available to enable Wakeup feature for Alarm Events. Since new platforms/Boards are now added through DT only, this feature is supported via DT property only. Platforms using such IP should add the property ti,has_irq_wake_enb in rtc DT node. This is a property of the IP, not the board. Can't you detect this based on the revision of the IP? Here is what I found out till now. 1. rtc-omap driver is used by Davinci, OMAP-1/2 AM33xx SoC. 2. Only AM33xx soc rtc ip has revision register ( populated). Older OMAP Or davinci doesn't have this register. 3. AFAIK, this was the reason why Afzal used platform_device_id of_device_id-data method to detect new versions (commit 9e0344dcc225fe1a0e8b8af9ff7df44ec4613580) So now either a. I can follow the same method and add new member to omap_rtc_devtype add a new compatible in omap_rtc_of_match in rtc-omap.c or b. use dt property to indicate existence of above property. Kindly let me know your opinion about the same. Any update on this. I have patch ready for both the choices. Waiting for your ok to send I think (a) is better. The driver should always do a device_init_wakeup(dev, true), *except* for devtypes that don't have this feature. 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: [RFC 09/42] drivers/i2c/busses: don't check resource with devm_ioremap_resource
Wolfram Sang w...@the-dreams.de writes: devm_ioremap_resource does sanity checks on the given resource. No need to duplicate this in the driver. Signed-off-by: Wolfram Sang w...@the-dreams.de Acked-by: Kevin Hilman khil...@linaro.org # for i2c-omap.c ___ 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] rtc: omap: add rtc wakeup support to alarm events
Hebbar Gururaja gururaja.heb...@ti.com writes: On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN) is available to enable Wakeup feature for Alarm Events. Since new platforms/Boards are now added through DT only, this feature is supported via DT property only. Platforms using such IP should add the property ti,has_irq_wake_enb in rtc DT node. This is a property of the IP, not the board. Can't you detect this based on the revision of the IP? 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 1/2] rtc: omap: add option to indicate wakeup support through DT
Hebbar Gururaja gururaja.heb...@ti.com writes: Even though RTC-IP is wakeup capable, Not all Boards support it. For example The rtc alarm wakeup is available in rtc-ip since omap1 days but alarm was not wired properly in previous ompa1 boards. commit fa5b07820fe3a0fc06ac368516e71f10a59b9539 Author: Sekhar Nori nsek...@ti.com Date: Wed Oct 27 15:33:05 2010 -0700 rtc: omap: let device wakeup capability be configured from chip init logic The rtc-omap driver currently hardcodes the RTC wakeup capability to be not capable. While this seems to be true for existing OMAP1 boards which are not wired for this, the DA850/OMAP-L138 SoC, the RTC can always be wake up source from its deep sleep mode. Current rtc-omap driver expects the rtc module wake-up capabilities to be set up by board specific code. However, in case of DT, this is not possible. So, add a DT property ti,wakeup_capable to indicate that the module is wake-up capable. Why is this a TI-specific property? Also, I think we can do this without a new DT property.Did you see this patch from Tony which is already queued for v3.11: http://marc.info/?l=linux-omapm=136917244530612w=2 I think this is the right way to go. Platforms that don't want/need wakeup support can disable it from userspace via: echo disabled /sys/devices/.../power/wakeup 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 00/11] drivers: Add Pinctrl PM support
+ Linus W. (pinctrl maintainer) Dmitry Torokhov dmitry.torok...@gmail.com writes: Hi Hebbar, On Fri, May 31, 2013 at 03:43:00PM +0530, Hebbar Gururaja wrote: By optionally putting the pins into sleep state in the suspend [or in runtime_suspend] callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. These states can be specified in the DT blob and corresponding driver can pick these states during probe set the related values during idle/suspend. Not all drivers support/has idle state. Drivers like i2c, spi, mmc has idle states and hence these drivers are updated to support all the three states - default : during regular operation - idle : when the module is in idle state - sleep : when the module is in suspend state For those drivers which doesn't support/have idle state (at least at the moment), only default sleep state is added. As with the original introduction of pinctrl states my question is: Can all of this be handled in the driver/bus core instead of adding a lot of boilerplate code to the individual drivers. Yes, I had the same thought. What's being handled here are either events related to runtime PM (runtime suspend, runtime resume) or system PM (suspend/resume) so seems appropriat to handle them in the PM core. 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 V2] davinci: da850: move input frequency to board specific files
Nori, Sekhar nsek...@ti.com writes: On Wed, Jun 08, 2011 at 17:38:25, Nori, Sekhar wrote: On Tue, Jun 07, 2011 at 21:53:59, Hilman, Kevin wrote: I don't expect this to be a big boot-time impact. You are right. Using PRINTK_TIME on DM365 I saw no noticeable boot-time change. When I profiled the code using do_gettimeofday(), I saw it was taking ~95 usecs to complete the propagation. I was mainly worried about all the recursion and reading of PLL and sysclk registers. Seems its not so bad. However, some of the clock.c assumptions might need to be updated as it currently is written from the perspective that the PLL clocks are the root clocks. Hmm, just calling clk_set_rate() on refclk propagated the rate nicely across the tree. It seems DaVinci clock code is not in such a bad shape :) Or did I miss the concern? Setting (and propagating) clock rates is what the clock framework is for, so adding a new interface to set a custom clock rate just doesn't seem right. I understand that the reference oscillator might be considered a special case, but if this can be done with the clock framework, it is much preferred. Okay. Will modify the DM6467/T EVM code to use this method instead. So, here is the patch. I suspect reference clock information should come from devicetree data when available. I hope it is OK to take this approach till that time? Thanks, Sekhar -8 From: Sekhar Nori nsek...@ti.com Date: Thu, 2 Jun 2011 14:10:50 +0530 Subject: [PATCH 1/1] davinci: dm6467/T EVM: fix setting up of reference clock rate The DM6467 and DM6467T EVMs use different reference clock frequencies. This difference is currently supported by having the SoC code call a public board routine which sets up the reference clock frequency. This does not scale as more boards are added. Instead, use the clk_set_rate() API to setup the reference clock frequency to a different value from the board file. Suggested-by: Kevin Hilman khil...@ti.com Signed-off-by: Sekhar Nori nsek...@ti.com Acked-by: Kevin Hilman khil...@ti.com ___ 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: move input frequency to board specific files
Nori, Sekhar nsek...@ti.com writes: Hi Kevin, On Tue, Jun 07, 2011 at 04:14:59, Hilman, Kevin wrote: Christian Riesch christian.rie...@omicron.at writes: From: Bob Dunlop bob.dun...@xyzzy.org.uk Currently the input frequency of the SoC is hardcoded in the SoC specific da850.c file to 24 MHz. Since the SoC accepts input frequencies in a wide range from 12 to 50 MHz, boards with different oscillator/crystal frequencies may be built. This patch allows setting a different input frequency in the board specific files to support boards with oscillator/crystal frequencies other than 24 MHz. Signed-off-by: Bob Dunlop bob.dun...@xyzzy.org.uk Signed-off-by: Christian Riesch christian.rie...@omicron.at Why not allow board code to just do a clk_set_rate()? Currently the ref_clk struct clk does not have a .set_rate method implemented, but that should be easy enough to add. Then the default ref_clk.rate would stay the 24MHz, but any boards that want to override that simply use clk_get(), clk_set_rate(), clk_put() That's certainly much more elegant, but this would mean the whole clock tree is traversed again on each boot. I am doing some measurements to see if there is any big difference in boot-time if this is done. Will get back with results. I don't expect this to be a big boot-time impact. However, some of the clock.c assumptions might need to be updated as it currently is written from the perspective that the PLL clocks are the root clocks. Setting (and propagating) clock rates is what the clock framework is for, so adding a new interface to set a custom clock rate just doesn't seem right. I understand that the reference oscillator might be considered a special case, but if this can be done with the clock framework, it is much preferred. 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 V2] davinci: da850: move input frequency to board specific files
Christian Riesch christian.rie...@omicron.at writes:
From: Bob Dunlop bob.dun...@xyzzy.org.uk
Currently the input frequency of the SoC is hardcoded in the SoC specific
da850.c file to 24 MHz. Since the SoC accepts input frequencies in a wide
range from 12 to 50 MHz, boards with different oscillator/crystal
frequencies may be built.
This patch allows setting a different input frequency in the board
specific files to support boards with oscillator/crystal frequencies other
than 24 MHz.
Signed-off-by: Bob Dunlop bob.dun...@xyzzy.org.uk
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Why not allow board code to just do a clk_set_rate()?
Currently the ref_clk struct clk does not have a .set_rate method
implemented, but that should be easy enough to add.
Then the default ref_clk.rate would stay the 24MHz, but any boards that
want to override that simply use clk_get(), clk_set_rate(), clk_put()
Kevin
---
Hi,
in private email Bob Dunlop suggested to pass a pointer to a small
structure instead of the frequency value to allow future expansions,
e.g., for the OPP list. Therefore I submit his patch as V2.
Christian
arch/arm/mach-davinci/board-da850-evm.c |2 +-
arch/arm/mach-davinci/board-mityomapl138.c |2 +-
arch/arm/mach-davinci/board-omapl138-hawk.c |2 +-
arch/arm/mach-davinci/da850.c |5 -
arch/arm/mach-davinci/include/mach/da8xx.h |6 +-
5 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index a7b41bf..231ff87 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1252,7 +1252,7 @@ console_initcall(da850_evm_console_init);
static void __init da850_evm_map_io(void)
{
- da850_init();
+ da850_init(NULL);
}
MACHINE_START(DAVINCI_DA850_EVM, DaVinci DA850/OMAP-L138/AM18x EVM)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c
b/arch/arm/mach-davinci/board-mityomapl138.c
index 606a6f2..362770c 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -561,7 +561,7 @@ console_initcall(mityomapl138_console_init);
static void __init mityomapl138_map_io(void)
{
- da850_init();
+ da850_init(NULL);
}
MACHINE_START(MITYOMAPL138, MityDSP-L138/MityARM-1808)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index 67c38d0..c43a6c3 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -334,7 +334,7 @@ console_initcall(omapl138_hawk_console_init);
static void __init omapl138_hawk_map_io(void)
{
- da850_init();
+ da850_init(NULL);
}
MACHINE_START(OMAPL138_HAWKBOARD, AM18x/OMAP-L138 Hawkboard)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 133aac4..ebd0603 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1104,10 +1104,13 @@ static struct davinci_soc_info davinci_soc_info_da850
= {
.reset_device = da8xx_wdt_device,
};
-void __init da850_init(void)
+void __init da850_init(struct da850_init_board_info *board)
{
unsigned int v;
+ if (board board-ref_clk_rate)
+ ref_clk.rate = board-ref_clk_rate;
+
davinci_common_init(davinci_soc_info_da850);
da8xx_syscfg0_base = ioremap(DA8XX_SYSCFG0_BASE, SZ_4K);
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h
b/arch/arm/mach-davinci/include/mach/da8xx.h
index ad64da7..66efc5d 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -69,8 +69,12 @@ extern unsigned int da850_max_speed;
#define DA8XX_AEMIF_CTL_BASE 0x6800
#define DA8XX_ARM_RAM_BASE 0x
+struct da850_init_board_info {
+ unsigned long ref_clk_rate;
+};
+
void __init da830_init(void);
-void __init da850_init(void);
+void __init da850_init(struct da850_init_board_info *board);
int da830_register_edma(struct edma_rsv_info *rsv);
int da850_register_edma(struct edma_rsv_info *rsv[2]);
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [GIT PULL] Pull request for 2.6.40
Hi Sekhar, Nori, Sekhar nsek...@ti.com writes: Hi Russell, I have been tracking these four patches for inclusion in 2.6.40 can you please pull them? These are clean-up rather than consolidation patches and all of them have zero or negative net diffstat. The commits in this branch aren't quite right. All except the last one are missing your signoff. As you're on the delivery path, be sure to include your signoff on all the patches. Thanks, Kevin The following changes since commit 0ee5623f9a6e52df90a78bd21179f8ab370e102e: Linus Torvalds (1): Linux 2.6.39-rc6 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git davinci-next Manjunath Hadli (1): davinci: move DM64XX_VDD3P3V_PWDN to devices.c Sergei Shtylyov (3): DA8xx: kill duplicate #define DA8XX_GPIO_BASE DA8xx: kill duplicate #define DA8XX_PLL1_BASE DA8xx: move base address #define's to their proper place arch/arm/mach-davinci/da850.c |2 +- arch/arm/mach-davinci/devices-da8xx.c | 16 +--- arch/arm/mach-davinci/devices.c |3 +++ arch/arm/mach-davinci/include/mach/da8xx.h|4 arch/arm/mach-davinci/include/mach/hardware.h |3 --- 5 files changed, 13 insertions(+), 15 deletions(-) ___ 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] Fix generic irq chip
Russell King - ARM Linux li...@arm.linux.org.uk writes: As a result of c42321c (genirq: Make generic irq chip depend on CONFIG_GENERIC_IRQ_CHIP), we now need those platforms using this in my tree to select this symbol. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk -- Please send acks ASAP. Thanks to Mark for pointing this out with a patch for Samsung. Acked-by: Kevin Hilman khil...@ti.com ___ 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-pm] [RFC PATCH V3 4/4] cpuidle: Single/Global registration of idle states
Hi Trinabh, Trinabh Gupta trin...@linux.vnet.ibm.com writes: [...] I just wanted to get comments on the design and understand how it affects various architectures in question. It looks to me as if the design should be okay and infact better for architectures like ARM since they do not have different idle states for different cpus and thus do not require per-cpu registration. Global registration would work and be simpler; please correct me if I am wrong. Yes, I agree that the new design is better, I especially like that it's more clear (and expected) that final state decision making is to be done directly in the driver without the back-and-forth in the current setup. Thanks, 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: [linux-pm] [RFC PATCH V3 1/4] cpuidle: Move dev-last_residency update to driver enter routine; remove dev-last_state
Trinabh Gupta trin...@linux.vnet.ibm.com writes: Cpuidle subsystem only suggests the state to enter and does not guarantee if the suggested state is entered. The actual entered state may be different because of software or hardware demotion. Software demotion is done by the back-end cpuidle driver and can be accounted correctly. Current cpuidle code uses last_state field to capture the actual state entered and based on that updates the statistics for the state entered. Ideally the driver enter routine should update the counters, and it should return the state actually entered rather than the time spent there. OK, the return type was changed to return the state index instead of the time, but since the governors are still relying on dev-last_residency, drivers are required to update it. Because of that, why not keep the update of the time/usage counters in common code rather than duplicating it (9 times in this patch) into all the drivers? Something like the patch below should suffice. Kevin diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c index 845d3ef..875d241 100644 --- a/drivers/cpuidle/cpuidle.c +++ b/drivers/cpuidle/cpuidle.c @@ -91,6 +91,11 @@ static void cpuidle_idle_call(void) entered_state = target_state-enter(dev, drv, next_state); + /* Update cpuidle counters */ + dev-states_usage[entered_state].time += + (unsigned long long)dev-last_residency; + dev-states_usage[entered_state].usage++; + trace_power_end(dev-cpu); trace_cpu_idle(PWR_EVENT_EXIT, dev-cpu); ___ 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: fix DEBUG_LL code for p2v changes
Fixup davinci UART low-level debug code for new ARM generic p2v changes. Based on OMAP changes by Tony Lindgren Cc: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/mach-davinci/include/mach/debug-macro.S | 13 - arch/arm/mach-davinci/include/mach/serial.h |2 +- 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/debug-macro.S b/arch/arm/mach-davinci/include/mach/debug-macro.S index 9f1befc..f8b7ea4 100644 --- a/arch/arm/mach-davinci/include/mach/debug-macro.S +++ b/arch/arm/mach-davinci/include/mach/debug-macro.S @@ -24,6 +24,9 @@ #define UART_SHIFT 2 +#define davinci_uart_v2p(x)((x) - PAGE_OFFSET + PLAT_PHYS_OFFSET) +#define davinci_uart_p2v(x)((x) - PLAT_PHYS_OFFSET + PAGE_OFFSET) + .pushsection .data davinci_uart_phys: .word 0 davinci_uart_virt: .word 0 @@ -34,7 +37,7 @@ davinci_uart_virt:.word 0 /* Use davinci_uart_phys/virt if already configured */ 10:mrc p15, 0, \rp, c1, c0 tst \rp, #1 @ MMU enabled? - ldreq \rp, =__virt_to_phys(davinci_uart_phys) + ldreq \rp, =davinci_uart_v2p(davinci_uart_phys) ldrne \rp, =davinci_uart_phys add \rv, \rp, #4@ davinci_uart_virt ldr \rp, [\rp, #0] @@ -48,18 +51,18 @@ davinci_uart_virt: .word 0 tst \rp, #1 @ MMU enabled? /* Copy uart phys address from decompressor uart info */ - ldreq \rv, =__virt_to_phys(davinci_uart_phys) + ldreq \rv, =davinci_uart_v2p(davinci_uart_phys) ldrne \rv, =davinci_uart_phys ldreq \rp, =DAVINCI_UART_INFO - ldrne \rp, =__phys_to_virt(DAVINCI_UART_INFO) + ldrne \rp, =davinci_uart_p2v(DAVINCI_UART_INFO) ldr \rp, [\rp, #0] str \rp, [\rv] /* Copy uart virt address from decompressor uart info */ - ldreq \rv, =__virt_to_phys(davinci_uart_virt) + ldreq \rv, =davinci_uart_v2p(davinci_uart_virt) ldrne \rv, =davinci_uart_virt ldreq \rp, =DAVINCI_UART_INFO - ldrne \rp, =__phys_to_virt(DAVINCI_UART_INFO) + ldrne \rp, =davinci_uart_p2v(DAVINCI_UART_INFO) ldr \rp, [\rp, #4] str \rp, [\rv] diff --git a/arch/arm/mach-davinci/include/mach/serial.h b/arch/arm/mach-davinci/include/mach/serial.h index 8051110..c9e6ce1 100644 --- a/arch/arm/mach-davinci/include/mach/serial.h +++ b/arch/arm/mach-davinci/include/mach/serial.h @@ -22,7 +22,7 @@ * * This area sits just below the page tables (see arch/arm/kernel/head.S). */ -#define DAVINCI_UART_INFO (PHYS_OFFSET + 0x3ff8) +#define DAVINCI_UART_INFO (PLAT_PHYS_OFFSET + 0x3ff8) #define DAVINCI_UART0_BASE (IO_PHYS + 0x2) #define DAVINCI_UART1_BASE (IO_PHYS + 0x20400) -- 1.7.4 ___ 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: More NR_IRQS?
Michael Williamson michael.william...@criticallink.com writes: I'm working with a couple of gpio expanders (for example, the PCA953X) that have the capability to plug into the gpiolib kernel infrastructure and include support for interrupt notification. For the interrupts, they appear to function similarly to the davinci gpio.c driver. I.E., they provide for soft IRQs in order to provide one-to-one mapping to support gpio_to_irq(). The problem is that the NR_IRQS in mach/irqs.h is fixed to only accommodate the SOC interrupt handler and it's local GPIOs. There are no extra entries to support expanders. I was going to propose an integer Kconfig option (e.g., CONFIG_DAVINCI_EXTRA_IRQS, default 0) that would be added to NR_IRQS to support this. Is there a better way? Or an alternate solutione? Just increase NR_IRQS. Check arch/arm/plat-omap/include/plat/irqs.h for an example. Also, we now have sparse IRQ support in ARM, which means we don't actully have to allocate and irq_desc for NR_IRQS interrupts. Only those that are requested get an irq_desc. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] final davinci updates for 2.6.39
Russell, A final pull request for davinci for 2.6.39 (based on the previous one.) This is a series that Sekhar Nori (davinci co-maintaier) has been tracking and that I had mistakenly not added to my previous pull request. Thanks, Kevin The following changes since commit 9a9fb12a4832bdf22751e21df298ef3559643b43: davinci: macro rename DA8XX_LPSC0_DMAX to DA8XX_LPSC0_PRUSS. (2011-03-11 10:48:29 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-next-2 Cyril Chemparathy (5): mfd: add driver for sequencer serial port spi: add ti-ssp spi master driver davinci: add tnetv107x ssp platform device davinci: add ssp config for tnetv107x evm board davinci: add spi devices on tnetv107x evm Sergei Shtylyov (1): davinci: DM644x EVM: register MUSB device earlier arch/arm/mach-davinci/board-dm644x-evm.c |8 +- arch/arm/mach-davinci/board-tnetv107x-evm.c| 57 +++ arch/arm/mach-davinci/devices-tnetv107x.c | 25 ++ arch/arm/mach-davinci/include/mach/tnetv107x.h |2 + arch/arm/mach-davinci/tnetv107x.c |2 +- drivers/mfd/Kconfig| 11 + drivers/mfd/Makefile |1 + drivers/mfd/ti-ssp.c | 476 drivers/spi/Kconfig| 10 + drivers/spi/Makefile |1 + drivers/spi/ti-ssp-spi.c | 402 include/linux/mfd/ti_ssp.h | 93 + 12 files changed, 1082 insertions(+), 6 deletions(-) create mode 100644 drivers/mfd/ti-ssp.c create mode 100644 drivers/spi/ti-ssp-spi.c create mode 100644 include/linux/mfd/ti_ssp.h ___ 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] DM644x EVM: register MUSB device earlier
Felipe Balbi ba...@ti.com writes: [...] Kevin feel free to take this into your tree: Acked-by: Felipe Balbi ba...@ti.com OK, will queue for 2.6.39. Thanks, Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] davinci platform updates for 2.6.39
Russell, Please pull the following davinci updates for the upcoming 2.6.39 merge window. This davinci-next branch has already been included in linux-next, so should not have merge problems with your devel branch. Kevin The following changes since commit f5412be599602124d2bdd49947b231dd77c0bf99: Linux 2.6.38-rc6 (2011-02-21 17:25:52 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-next Kevin Hilman (1): MAINTAINERS: update TI DaVinci machine support entry Michael Williamson (13): davinci: Support various speedgrades for MityDSP-L138 and MityARM-1808 SoMs davinci: da850: remove unused pinmux array davinci: da850: remove unused emif pinmux array davinci: da850: move da850_evm specific mcasp pins to board file. davinci: da850: move da850_evm specific mmcsd pinmux array to board file. davinci: da850: remove unused uart pinmux arrays. davinci: spi: move event queue parameter to platform data davinci: remove unused DA830_edma_ch enum davinci: da8xx: clean up magic numbers in devices-da8xx.c davinci: da830: fix driver name for spi clocks davinci: da850: add spi device clock definitions davinci: da8xx: add spi resources and registration routine davinci: add spi devices support for MityDSP-L138/MityARM-1808 platform Sekhar Nori (2): davinci: add spi devices support for da850/omap-l138/am18x evm davinci: add spi devices support for da830/omap-l137/am17x evm Sergei Shtylyov (1): davinci: DA850 EVM: kill useless variable Subhasish Ghosh (1): davinci: macro rename DA8XX_LPSC0_DMAX to DA8XX_LPSC0_PRUSS. Sudhakar Rajashekhara (1): davinci: Add additional JTAG code for AM-1808 and OMAP-L138 Rev 2.0 SoCs Victor Rodriguez (6): davinci: EMAC support for Omapl138-Hawkboard davinci: EDMA support for Omapl138-Hawkboard davinci: MMC/SD and USB-OHCI configuration for Omapl138-Hawkboard davinci: MMC/SD support for Omapl138-Hawkboard davinci: USB clocks for Omapl138-Hawkboard davinci: USB1.1 support for Omapl138-Hawkboard MAINTAINERS |3 +- arch/arm/mach-davinci/board-da830-evm.c | 67 +++ arch/arm/mach-davinci/board-da850-evm.c | 96 +- arch/arm/mach-davinci/board-mityomapl138.c | 167 +++- arch/arm/mach-davinci/board-omapl138-hawk.c | 284 +++ arch/arm/mach-davinci/da830.c |6 +- arch/arm/mach-davinci/da850.c | 99 -- arch/arm/mach-davinci/devices-da8xx.c | 125 +++- arch/arm/mach-davinci/dm355.c |5 +- arch/arm/mach-davinci/dm365.c |5 +- arch/arm/mach-davinci/include/mach/da8xx.h | 11 +- arch/arm/mach-davinci/include/mach/edma.h | 36 arch/arm/mach-davinci/include/mach/mux.h|4 + arch/arm/mach-davinci/include/mach/psc.h|2 +- arch/arm/mach-davinci/include/mach/spi.h| 15 +- drivers/spi/davinci_spi.c | 11 +- 16 files changed, 789 insertions(+), 147 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] davinci fixes for 2.6.38-rc7
Hi Russell, Please pull the following small series of davinci fixes for 2.6.38-rc7. Thanks, Kevin The following changes since commit f5412be599602124d2bdd49947b231dd77c0bf99: Linux 2.6.38-rc6 (2011-02-21 17:25:52 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-fixes Axel Lin (1): davinci: cpufreq: fix section mismatch warning Hirosh Dabui (1): davinci: tnetv107x: fix register indexing for GPIOs numbers 31 Rajashekhara, Sudhakar (1): davinci: da8xx/omap-l1x: add platform device for davinci-pcm-audio Sergei Shtylyov (1): DaVinci: fix compilation warnings in mach/clkdev.h arch/arm/mach-davinci/cpufreq.c |2 +- arch/arm/mach-davinci/devices-da8xx.c |7 +++ arch/arm/mach-davinci/gpio-tnetv107x.c | 18 +- arch/arm/mach-davinci/include/mach/clkdev.h |2 ++ 4 files changed, 19 insertions(+), 10 deletions(-) ___ 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: tnetv107x: fix register indexing for GPIOs numbers 31
Cyril Chemparathy cy...@ti.com writes: On 01/28/2011 04:47 PM, Hilman, Kevin wrote: Hirosh Dabui hirosh.da...@snom.com writes: This patch fix a bug in the register indexing for GPIOs numbers 31 to get the relevant hardware registers of tnetv107x to control the GPIOs. [...] Thanks, applied and queuing for 2.6.39. Does this bug fix need to wait for .39? Hmm, no. It should go for .38-rc. Will queue in davinci-fixes. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
TI DaVinci support under new maintainer: Sekhar Nori
Hello, I will be stepping aside as maintainer of the TI DaVinci family of SoCs and Sekhar Nori from TI will be taking over these responsibilities. Sekhar has long been an active developer, primary contributor and reviewer so taking over the maintainer role is a logical next step for him. I will aid in the transition for a couple merge windows to help make a smooth transition, but will be fading away from an active role in davinci. 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 v2] davinci: spi: move event queue parameter to platform data
Michael Williamson michael.william...@criticallink.com writes:
For DMA operation, the davinci spi driver needs an event queue number.
Currently, this number is passed as a IORESOURCE_DMA. This is not
correct, as the event queue is not a DMA channel. Pass the event queue
via the platform data structure instead.
On dm355 and dm365, move the eventq assignment for spi0 out of resources
array and into platform data.
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Acked-by: Sekhar Nori nsek...@ti.com
With Grant's ack, will merge this through davinci tree.
Kevin
---
Changes since v1:
- Add Sekhar's Ack.
- Really fix the typo. This time for sure (blew the format patch
on last go around).
arch/arm/mach-davinci/dm355.c|5 +
arch/arm/mach-davinci/dm365.c|5 +
arch/arm/mach-davinci/include/mach/spi.h | 15 ++-
drivers/spi/davinci_spi.c| 11 +++
4 files changed, 15 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a5f8a80..76364d1 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -403,16 +403,13 @@ static struct resource dm355_spi0_resources[] = {
.start = 16,
.flags = IORESOURCE_DMA,
},
- {
- .start = EVENTQ_1,
- .flags = IORESOURCE_DMA,
- },
};
static struct davinci_spi_platform_data dm355_spi0_pdata = {
.version= SPI_VERSION_1,
.num_chipselect = 2,
.cshold_bug = true,
+ .dma_event_q= EVENTQ_1,
};
static struct platform_device dm355_spi0_device = {
.name = spi_davinci,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 02d2cc3..4604e72 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -625,6 +625,7 @@ static u64 dm365_spi0_dma_mask = DMA_BIT_MASK(32);
static struct davinci_spi_platform_data dm365_spi0_pdata = {
.version= SPI_VERSION_1,
.num_chipselect = 2,
+ .dma_event_q= EVENTQ_3,
};
static struct resource dm365_spi0_resources[] = {
@@ -645,10 +646,6 @@ static struct resource dm365_spi0_resources[] = {
.start = 16,
.flags = IORESOURCE_DMA,
},
- {
- .start = EVENTQ_3,
- .flags = IORESOURCE_DMA,
- },
};
static struct platform_device dm365_spi0_device = {
diff --git a/arch/arm/mach-davinci/include/mach/spi.h
b/arch/arm/mach-davinci/include/mach/spi.h
index 38f4da5..7af305b 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -19,6 +19,8 @@
#ifndef __ARCH_ARM_DAVINCI_SPI_H
#define __ARCH_ARM_DAVINCI_SPI_H
+#include mach/edma.h
+
#define SPI_INTERN_CS0xFF
enum {
@@ -39,13 +41,16 @@ enum {
* to populate if all chip-selects are internal.
* @cshold_bug: set this to true if the SPI controller on your chip
requires
* a write to CSHOLD bit in between transfers (like in DM355).
+ * @dma_event_q: DMA event queue to use if SPI_IO_TYPE_DMA is used for any
+ * device on the bus.
*/
struct davinci_spi_platform_data {
- u8 version;
- u8 num_chipselect;
- u8 intr_line;
- u8 *chip_sel;
- boolcshold_bug;
+ u8 version;
+ u8 num_chipselect;
+ u8 intr_line;
+ u8 *chip_sel;
+ boolcshold_bug;
+ enum dma_event_qdma_event_q;
};
/**
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 6beab99..166a879 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -790,7 +790,6 @@ static int davinci_spi_probe(struct platform_device *pdev)
struct resource *r, *mem;
resource_size_t dma_rx_chan = SPI_NO_RESOURCE;
resource_size_t dma_tx_chan = SPI_NO_RESOURCE;
- resource_size_t dma_eventq = SPI_NO_RESOURCE;
int i = 0, ret = 0;
u32 spipc0;
@@ -878,17 +877,13 @@ static int davinci_spi_probe(struct platform_device
*pdev)
r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
if (r)
dma_tx_chan = r-start;
- r = platform_get_resource(pdev, IORESOURCE_DMA, 2);
- if (r)
- dma_eventq = r-start;
dspi-bitbang.txrx_bufs = davinci_spi_bufs;
if (dma_rx_chan != SPI_NO_RESOURCE
- dma_tx_chan != SPI_NO_RESOURCE
- dma_eventq != SPI_NO_RESOURCE) {
+ dma_tx_chan != SPI_NO_RESOURCE) {
dspi-dma.rx_channel = dma_rx_chan;
dspi-dma.tx_channel = dma_tx_chan;
- dspi-dma.eventq = dma_eventq;
+ dspi-dma.eventq = pdata-dma_event_q;
ret =
Re: [PATCH 1/2 v1] davinci: support disabling modem status interrupts on SOC UARTS
Michael Williamson michael.william...@criticallink.com writes: Hi Kevin... On 01/05/2011 07:26 AM, Michael Williamson wrote: On the da850/omap-l138/am18x family of SoCs, up to three on chip UARTS may be configured. These peripherals support the standard Tx/Rx signals as well as CTS/RTS hardware flow control signals. The pins on these SOC's associated with these signals are multiplexed; e.g., the pin providing UART0_TXD capability also provides SPI0 chip select line 5 output capability. The configuration of the pin multiplexing occurs during platform initialization (or by earlier bootloader operations). There is a problem with the multiplexing implementation on these SOCs. Only the output and output enable portions of the I/O section of the pin are multiplexed. All peripheral input functions remain connected to a given pin regardless of configuration. In many configurations of these parts, providing a UART with Tx/Rx capability is needed, but the HW flow control capability is not. Furthermore, the pins associated with the CTS inputs on these UARTS are often configured to support a different peripheral, and they may be active/toggling during runtime. This can result in false modem status (CTS) interrupts being asserted to the 8250 driver controlling the associated Tx/Rx pins, and will impact system performance. The 8250 serial driver platform data does not provide a direct mechanism to tell the driver to disable modem status (i.e., CTS) interrupts for a given port. As a work-around, intercept register writes to the IER and disable modem status interrupts. This patch was tested using a MityDSP-L138 SOM having UART1 enabled with the associated CTS pin connected to a clock (configured for the AHCLKX function). Background / problem reports related to this issue are captured in the links below: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/36701.aspx http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg19524.html Signed-off-by: Michael Williamson michael.william...@criticallink.com Tested-by: Michael Williamson michael.william...@criticallink.com --- This is against the linux-davinci tree. Changes from original proposed patch: - instead of overriding set_termios, now override serial_out driver hook and intercept writes to the MSR. An alternate patch was proposed that modified the serial core driver and added a UPF_NO_MSR flag. There was resistance to this patch. The reasoning is that the core 8250 driver code should not continue to get muddied by platform hacks. I'd like to withdraw this patch. It works, but it's inefficient and ugly, and I also get the feeling it isn't going to make it in it's current form anyway. I have another patch that is limited to just the mityomapl138 platform that I would like to submit in place of this. No other board appears to have this problem, so it makes sense to constrain the fix to platform file that does. OK 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] davinci: tnetv107x: fix register indexing for GPIOs numbers 31
Hirosh Dabui hirosh.da...@snom.com writes:
This patch fix a bug in the register indexing for GPIOs numbers 31
to get the relevant hardware registers of tnetv107x to control the GPIOs.
In the structure tnetv107x_gpio_regs:
struct tnetv107x_gpio_regs {
u32 idver;
u32 data_in[3];
u32 data_out[3];
u32 direction[3];
u32 enable[3];
};
The GPIO hardware register addresses of tnetv107x are stored.
The chip implements 3 registers of each entity to serve 96 GPIOs,
each register provides a subset of 32 GPIOs.
The driver provides these macros: gpio_reg_set_bit, gpio_reg_get_bit
and gpio_reg_clear_bit.
The bug implied the use of macros to access the relevant hardware
register e.g. the driver code used the macro like this:
'gpio_reg_clear_bit(reg-data_out, gpio)'
But it has to be used like this:
'gpio_reg_clear_bit(reg-data_out, gpio)'.
The different results are shown here:
- reg-data_out + 1 (it will add the full array size of data_out i.e. 12
bytes)
- reg-data_out + 1 (it will increment only the size of data_out i.e. only 4
bytes)
Acked-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Hirosh Dabui hirosh.da...@snom.com
Thanks, applied and queuing for 2.6.39.
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] This patch fix a bug in the register indexing for GPIOs numbers 31
Hi Hirosh,
Hirosh Dabui hirosh.da...@snom.com writes:
to get the relevant hardware registers of tnetv107x to control the GPIOs.
Your patch/changelog is still messed up. You're missing a good
subject/shortlog and the first line of the changelog has become the
subject/shortlog.
Kevin
In the structure tnetv107x_gpio_regs:
struct tnetv107x_gpio_regs {
u32 idver;
u32 data_in[3];
u32 data_out[3];
u32 direction[3];
u32 enable[3];
};
The GPIO hardware register addresses of tnetv107x are stored.
The chip implements 3 registers of each entity to serve 96 GPIOs,
each register provides a subset of 32 GPIOs.
The driver provides these macros: gpio_reg_set_bit, gpio_reg_get_bit
and gpio_reg_clear_bit.
The bug implied the use of macros to access the relevant hardware
register e.g. the driver code used the macro like this:
'gpio_reg_clear_bit(reg-data_out, gpio)'
But it has to be used like this:
'gpio_reg_clear_bit(reg-data_out, gpio)'.
The different results are shown here:
- reg-data_out + 1 (it will add the full array size of data_out i.e. 12
bytes)
- reg-data_out + 1 (it will increment only the size of data_out i.e. only 4
bytes)
Acked-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Hirosh Dabui hirosh.da...@snom.com
---
arch/arm/mach-davinci/gpio-tnetv107x.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-davinci/gpio-tnetv107x.c
b/arch/arm/mach-davinci/gpio-tnetv107x.c
index d102986..3fa3e28 100644
--- a/arch/arm/mach-davinci/gpio-tnetv107x.c
+++ b/arch/arm/mach-davinci/gpio-tnetv107x.c
@@ -58,7 +58,7 @@ static int tnetv107x_gpio_request(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
- gpio_reg_set_bit(regs-enable, gpio);
+ gpio_reg_set_bit(regs-enable, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -74,7 +74,7 @@ static void tnetv107x_gpio_free(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
- gpio_reg_clear_bit(regs-enable, gpio);
+ gpio_reg_clear_bit(regs-enable, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
}
@@ -88,7 +88,7 @@ static int tnetv107x_gpio_dir_in(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
- gpio_reg_set_bit(regs-direction, gpio);
+ gpio_reg_set_bit(regs-direction, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -106,11 +106,11 @@ static int tnetv107x_gpio_dir_out(struct gpio_chip
*chip,
spin_lock_irqsave(ctlr-lock, flags);
if (value)
- gpio_reg_set_bit(regs-data_out, gpio);
+ gpio_reg_set_bit(regs-data_out, gpio);
else
- gpio_reg_clear_bit(regs-data_out, gpio);
+ gpio_reg_clear_bit(regs-data_out, gpio);
- gpio_reg_clear_bit(regs-direction, gpio);
+ gpio_reg_clear_bit(regs-direction, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -124,7 +124,7 @@ static int tnetv107x_gpio_get(struct gpio_chip *chip,
unsigned offset)
unsigned gpio = chip-base + offset;
int ret;
- ret = gpio_reg_get_bit(regs-data_in, gpio);
+ ret = gpio_reg_get_bit(regs-data_in, gpio);
return ret ? 1 : 0;
}
@@ -140,9 +140,9 @@ static void tnetv107x_gpio_set(struct gpio_chip *chip,
spin_lock_irqsave(ctlr-lock, flags);
if (value)
- gpio_reg_set_bit(regs-data_out, gpio);
+ gpio_reg_set_bit(regs-data_out, gpio);
else
- gpio_reg_clear_bit(regs-data_out, gpio);
+ gpio_reg_clear_bit(regs-data_out, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
}
___
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-devel] [PATCH] davinci: da8xx/omap-l1xx: match codec_name with i2c ids
Mark Brown broo...@opensource.wolfsonmicro.com writes: On Tue, Jan 25, 2011 at 10:59:05AM +, Liam Girdwood wrote: On Mon, 2011-01-24 at 15:09 -0800, Kevin Hilman wrote: On second thought, these should probably merge for .38-rc3. If you're OK with it, I can merge this and the platform fix together for .38-rc3. Yes please :) I applied it and sent it off towards Linux a few days ago. OK, missed that. I'll queue up the platform one then. Thanks, 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] This patch fix a bug in the register indexing for GPIOs numbers 31 to get the relevant hardware registers of tnetv107x to control the GPIOs.
Hi Hirosh,
Hirosh Dabui hirosh.da...@snom.com writes:
In the structure tnetv107x_gpio_regs:
struct tnetv107x_gpio_regs {
u32 idver;
u32 data_in[3];
u32 data_out[3];
u32 direction[3];
u32 enable[3];
};
The GPIO hardware register addresses of tnetv107x are stored.
The chip implements 3 registers of each entity to serve 96 GPIOs,
each register provides a subset of 32 GPIOs.
The driver provides these macros: gpio_reg_set_bit, gpio_reg_get_bit
and gpio_reg_clear_bit.
The first sentence of the changelog has become the subject (and thus the
git shortlog) of this patch. Please update and make the subject
something like it was before:
davinci: tnetv107x: fix register indexing for GPIOs numbers 31
Thanks,
Kevin
The bug implied the use of macros to access the relevant hardware
register e.g. the driver code used the macro like this:
'gpio_reg_clear_bit(reg-data_out, gpio)'
But it has to be used like this:
'gpio_reg_clear_bit(reg-data_out, gpio)'.
The different results are shown here:
- reg-data_out + 1 (it will add the full array size of data_out i.e. 12
bytes)
- reg-data_out + 1 (it will increment only the size of data_out i.e. only 4
bytes)
Acked-by: Cyril Chemparathy cy...@ti.com
Signed-off-by: Hirosh Dabui hirosh.da...@snom.com
---
arch/arm/mach-davinci/gpio-tnetv107x.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-davinci/gpio-tnetv107x.c
b/arch/arm/mach-davinci/gpio-tnetv107x.c
index d102986..3fa3e28 100644
--- a/arch/arm/mach-davinci/gpio-tnetv107x.c
+++ b/arch/arm/mach-davinci/gpio-tnetv107x.c
@@ -58,7 +58,7 @@ static int tnetv107x_gpio_request(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
- gpio_reg_set_bit(regs-enable, gpio);
+ gpio_reg_set_bit(regs-enable, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -74,7 +74,7 @@ static void tnetv107x_gpio_free(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
- gpio_reg_clear_bit(regs-enable, gpio);
+ gpio_reg_clear_bit(regs-enable, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
}
@@ -88,7 +88,7 @@ static int tnetv107x_gpio_dir_in(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
- gpio_reg_set_bit(regs-direction, gpio);
+ gpio_reg_set_bit(regs-direction, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -106,11 +106,11 @@ static int tnetv107x_gpio_dir_out(struct gpio_chip
*chip,
spin_lock_irqsave(ctlr-lock, flags);
if (value)
- gpio_reg_set_bit(regs-data_out, gpio);
+ gpio_reg_set_bit(regs-data_out, gpio);
else
- gpio_reg_clear_bit(regs-data_out, gpio);
+ gpio_reg_clear_bit(regs-data_out, gpio);
- gpio_reg_clear_bit(regs-direction, gpio);
+ gpio_reg_clear_bit(regs-direction, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -124,7 +124,7 @@ static int tnetv107x_gpio_get(struct gpio_chip *chip,
unsigned offset)
unsigned gpio = chip-base + offset;
int ret;
- ret = gpio_reg_get_bit(regs-data_in, gpio);
+ ret = gpio_reg_get_bit(regs-data_in, gpio);
return ret ? 1 : 0;
}
@@ -140,9 +140,9 @@ static void tnetv107x_gpio_set(struct gpio_chip *chip,
spin_lock_irqsave(ctlr-lock, flags);
if (value)
- gpio_reg_set_bit(regs-data_out, gpio);
+ gpio_reg_set_bit(regs-data_out, gpio);
else
- gpio_reg_clear_bit(regs-data_out, gpio);
+ gpio_reg_clear_bit(regs-data_out, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
}
___
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-l1xx: match codec_name with i2c ids
Liam Girdwood l...@slimlogic.co.uk writes:
On Fri, 2011-01-21 at 19:54 +0530, Rajashekhara, Sudhakar wrote:
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,
Acked-by: Liam Girdwood l...@slimlogic.co.uk
Liam,
I'm assuming you'll merge this one via the ASoC tree?
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] davinci: da8xx/omap-l1xx: match codec_name with i2c ids
Kevin Hilman khil...@ti.com writes:
Liam Girdwood l...@slimlogic.co.uk writes:
On Fri, 2011-01-21 at 19:54 +0530, Rajashekhara, Sudhakar wrote:
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,
Acked-by: Liam Girdwood l...@slimlogic.co.uk
Liam,
I'm assuming you'll merge this one via the ASoC tree?
On second thought, these should probably merge for .38-rc3.
If you're OK with it, I can merge this and the platform fix together for
.38-rc3.
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 v2] davinci: da8xx/omap-l1x: add platform device for davinci-pcm-audio
Rajashekhara, Sudhakar sudhakar@ti.com writes:
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().
Thanks, queuing as a fix for 2.6.38-rc cycle.
Kevin
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;
___
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 v8 04/11] backlight: add support for tps6116x controller
Richard,
Cyril Chemparathy cy...@ti.com writes:
TPS6116x is an EasyScale backlight controller device. This driver supports
TPS6116x devices connected on a single GPIO.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Any comments on this driver?
With your Ack, I'll be happy to merge it via the davinci tree with the
rest of the series.
Thanks,
Kevin
---
drivers/video/backlight/Kconfig|7 +
drivers/video/backlight/Makefile |2 +-
drivers/video/backlight/tps6116x.c | 299
3 files changed, 307 insertions(+), 1 deletions(-)
create mode 100644 drivers/video/backlight/tps6116x.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index e54a337..06e868e 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -307,6 +307,13 @@ config BACKLIGHT_PCF50633
If you have a backlight driven by a NXP PCF50633 MFD, say Y here to
enable its driver.
+config BACKLIGHT_TPS6116X
+ tristate TPS6116X LCD Backlight
+ depends on GENERIC_GPIO
+ help
+ This driver controls the LCD backlight level for EasyScale capable
+ SSP connected backlight controllers.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile
b/drivers/video/backlight/Makefile
index 44c0f81..5d407c8 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -35,4 +35,4 @@ obj-$(CONFIG_BACKLIGHT_ADP5520) += adp5520_bl.o
obj-$(CONFIG_BACKLIGHT_ADP8860) += adp8860_bl.o
obj-$(CONFIG_BACKLIGHT_88PM860X) += 88pm860x_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
-
+obj-$(CONFIG_BACKLIGHT_TPS6116X)+= tps6116x.o
diff --git a/drivers/video/backlight/tps6116x.c
b/drivers/video/backlight/tps6116x.c
new file mode 100644
index 000..7f846ab
--- /dev/null
+++ b/drivers/video/backlight/tps6116x.c
@@ -0,0 +1,299 @@
+/*
+ * TPS6116X LCD Backlight Controller Driver
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/fb.h
+#include linux/err.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/backlight.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+
+#define TPS6116X_MAX_INTENSITY 31
+#define TPS6116X_DEFAULT_INTENSITY 10
+
+/* Easyscale timing w/ margin (usecs) */
+#define T_POWER_SETTLE 2000
+#define T_ES_DELAY 120
+#define T_ES_DETECT 280
+#define T_ES_WINDOW (1000 - T_ES_DELAY - T_ES_DETECT)
+#define T_START 3
+#define T_EOS3
+#define T_INACTIVE 3
+#define T_ACTIVE (3 * T_INACTIVE)
+
+#define CMD_SET 0x72
+
+struct tps6116x {
+ struct ti_ssp_device*handle;
+ struct device *dev;
+ int gpio;
+ struct mutexlock;
+ int intensity;
+ struct backlight_properties props;
+ struct backlight_device *bl;
+ struct regulator*regulator;
+ boolpower;
+ boolsuspended;
+};
+
+static int __set_power(struct tps6116x *hw, bool power)
+{
+ unsigned long flags;
+ int error;
+
+ if (power == hw-power)
+ return 0; /* nothing to do */
+
+ /* disabling is simple... choke power */
+ if (!power) {
+ error = regulator_disable(hw-regulator);
+ goto done;
+ }
+
+ /* set ctrl pin init state for easyscale detection */
+ gpio_set_value(hw-gpio, 0);
+
+ error = regulator_enable(hw-regulator);
+ if (error 0)
+ goto done;
+
+ udelay(T_POWER_SETTLE);
+
+ /*
+ * Now that the controller is powered up, we need to put it into 1-wire
+ * mode. This is a timing sensitive operation, hence the irq disable.
+ * Ideally, this should happen rarely, and mostly at init, so disabling
+ * interrupts for the duration should not be a problem.
+ */
+ local_irq_save(flags);
+
+ gpio_set_value(hw-gpio, 1);
+ udelay(T_ES_DELAY);
+ gpio_set_value(hw-gpio, 0);
+ udelay(T_ES_DETECT);
+ gpio_set_value(hw-gpio, 1);
+
+
Re: [PATCH v8 01/11] mfd: add driver for sequencer serial port
Samuel,
Cyril Chemparathy cy...@ti.com writes:
TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial
port
device. It has a built-in programmable execution engine that can be
programmed
to operate as almost any serial bus (I2C, SPI, EasyScale, and others).
This patch adds a driver for this controller device. The driver does not
expose a user-land interface. Protocol drivers built on top of this layer are
expected to remain in-kernel.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Any comments on this driver?
With your ack, I'll be happy to merge this via the davinci tree with the
rest of the series.
Thanks,
Kevin
---
drivers/mfd/Kconfig| 11 +
drivers/mfd/Makefile |1 +
drivers/mfd/ti-ssp.c | 476
include/linux/mfd/ti_ssp.h | 87
4 files changed, 575 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/ti-ssp.c
create mode 100644 include/linux/mfd/ti_ssp.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3a1493b..a4b4b70 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -81,6 +81,17 @@ config MFD_DM355EVM_MSP
boards. MSP430 firmware manages resets and power sequencing,
inputs from buttons and the IR remote, LEDs, an RTC, and more.
+config MFD_TI_SSP
+ tristate TI Sequencer Serial Port support
+ depends on ARCH_DAVINCI_TNETV107X
+ select MFD_CORE
+ ---help---
+ Say Y here if you want support for the Sequencer Serial Port
+ in a Texas Instruments TNETV107X SoC.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ti-ssp.
+
config HTC_EGPIO
bool HTC EGPIO support
depends on GENERIC_HARDIRQS GPIOLIB ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f54b365..f64cf13 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_HTC_I2CPLD)+= htc-i2cpld.o
obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o
obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
+obj-$(CONFIG_MFD_TI_SSP) += ti-ssp.o
obj-$(CONFIG_MFD_STMPE) += stmpe.o
obj-$(CONFIG_MFD_TC35892)+= tc35892.o
diff --git a/drivers/mfd/ti-ssp.c b/drivers/mfd/ti-ssp.c
new file mode 100644
index 000..af9ab0e
--- /dev/null
+++ b/drivers/mfd/ti-ssp.c
@@ -0,0 +1,476 @@
+/*
+ * Sequencer Serial Port (SSP) driver for Texas Instruments' SoCs
+ *
+ * Copyright (C) 2010 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/errno.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/init.h
+#include linux/wait.h
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/spinlock.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/mfd/core.h
+#include linux/mfd/ti_ssp.h
+
+/* Register Offsets */
+#define REG_REV 0x00
+#define REG_IOSEL_1 0x04
+#define REG_IOSEL_2 0x08
+#define REG_PREDIV 0x0c
+#define REG_INTR_ST 0x10
+#define REG_INTR_EN 0x14
+#define REG_TEST_CTRL0x18
+
+/* Per port registers */
+#define PORT_CFG_2 0x00
+#define PORT_ADDR0x04
+#define PORT_DATA0x08
+#define PORT_CFG_1 0x0c
+#define PORT_STATE 0x10
+
+#define SSP_PORT_CONFIG_MASK (SSP_EARLY_DIN | SSP_DELAY_DOUT)
+#define SSP_PORT_CLKRATE_MASK0x0f
+
+#define SSP_SEQRAM_WR_EN BIT(4)
+#define SSP_SEQRAM_RD_EN BIT(5)
+#define SSP_STARTBIT(15)
+#define SSP_BUSY BIT(10)
+#define SSP_PORT_ASL BIT(7)
+#define SSP_PORT_CFO1BIT(6)
+
+#define SSP_PORT_SEQRAM_SIZE 32
+
+static const int ssp_port_base[] = {0x040, 0x080};
+static const int ssp_port_seqram[] = {0x100, 0x180};
+
+struct ti_ssp {
+ struct resource *res;
+ struct device *dev;
+ void __iomem*regs;
+ spinlock_t lock;
+ struct clk *clk;
+ int irq;
+ wait_queue_head_t wqh;
+
+ /*
+ * Some of the iosel2 register
Re: ALSA issue on DA850/OMAP-L138/AM18x
Rajashekhara, Sudhakar sudhakar@ti.com writes:
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.
As suggested by Sergei...
This part should be one patch, and merged by Liam via ASoC tree for
2.6.38-rc cycle.
Also, this patch registers the platform device for davinci-pcm-audio.
This should be a separate patch as well, and I will merge it via davinci
tree for the .38-rc cycle.
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.
When you send final version, care to include a patch for da8xx_omapl_defconfig?
Kevin
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
___
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 Michael, Michael Williamson michael.william...@criticallink.com writes: The following patch series is an attempt to clean up unused and platform specific pinmux arrays in the da850 CPU files. This series was developed as a result of the following email thread: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg19921.html Thanks for taking this on. I noticed you only move changes to the EVM's board file. Won't this break the other da850-based boards (your board and the hawk board?) Kevin This patch is against commit b411b51a71cd9c926712b33ab21d001ed7e57838 of linux-davinci. This series should not be applied until someone with a da850 EVM can please test and confirm the mcasp and mmc interfaces continue to work properly with these patches. I noticed that none of the boards initialize the pinmux settings for the UARTs. Apparently, they are all relying on the bootloader to do this. Michael Williamson (5): davinci: da850: remove unused cpgmac pinmux array davinci: da850: remove unused emif pinmux array davinci: da850: move da850_evm specific mcasp pins to board file. davinci: da850: move da850_evm specific mmcsd pinmux array to board file. davinci: da850: remove unused uart pinmux arrays. arch/arm/mach-davinci/board-da850-evm.c| 18 - arch/arm/mach-davinci/da850.c | 56 arch/arm/mach-davinci/include/mach/da8xx.h |7 --- 3 files changed, 16 insertions(+), 65 deletions(-) ___ 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 v8 00/11] tnetv107x ssp drivers
Cyril Chemparathy cy...@ti.com writes: TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial port device. It has a built-in programmable execution engine that can be programmed to operate as almost any serial bus (I2C, SPI, EasyScale, and others). Hi Cyril, Can you include Grant's ack and repost this a bit broader. Add LKML and linux-arm-kernel please. Thanks, Kevin This patch series implements a driver stack that looks like the following: ++ | eeprom | . . . ++ +---+ +--+ +-+ | regulator | . . . | i2c-gpio | | 1-wire | . . . +---+ +--+ +-+ +--+ ++ | ssp-spi| | ssp-gpio | +--+ ++ +--+ |ssp | +--+ Changes between v8 and v7 of this series: - Reorder commits, removed regulator driver patch (already upstreamed) - Renamed static function definitions to keep namespace clean (mfd, gpio) - Removed instance pdata in mfd driver Changes between v7 and v6 of this series: - Workaround for iosel2 register not reading back set bits. - Update backlight status once probe succeeds. Changes between v6 and v5 of this series: - Changed initcalls to module_init() across all drivers. This series now uses a late_initcall() in the board to delay initialization of gpio and regulator dependent devices. Changes between v5 and v4 of this series: - Moved drivers from misc/gpio/spi to mfd - Removed implicit init-time iosel setup - Minor cleanups in backlight driver Changes between v3 and v4 of this series: - Replaced polled wait for sequence termination with interrupt - Improved locking within SSP driver - Other minor cleanups Changes between v2 and v3 of this series: - Minor cleanups in Kconfig and Makefile ordering Changes between v1 and v2 of this series: - Replaced open()/close() semantics with dynamic platform_device registration on SSP probe. - Removed user-land interface to regulator registers - More sensible regulator constraints - Other minor cleanups Cyril Chemparathy (11): mfd: add driver for sequencer serial port spi: add ti-ssp spi master driver gpio: add ti-ssp gpio driver backlight: add support for tps6116x controller davinci: add tnetv107x ssp platform device davinci: add ssp config for tnetv107x evm board davinci: add spi devices on tnetv107x evm davinci: add tnetv107x evm regulators davinci: add tnetv107x evm ti-ssp gpio device davinci: add tnetv107x evm backlight device davinci: add tnetv107x evm i2c eeprom device arch/arm/mach-davinci/board-tnetv107x-evm.c| 197 ++ arch/arm/mach-davinci/devices-tnetv107x.c | 25 ++ arch/arm/mach-davinci/include/mach/tnetv107x.h |2 + arch/arm/mach-davinci/tnetv107x.c |2 +- drivers/gpio/Kconfig | 10 + drivers/gpio/Makefile |1 + drivers/gpio/ti-ssp-gpio.c | 207 ++ drivers/mfd/Kconfig| 11 + drivers/mfd/Makefile |1 + drivers/mfd/ti-ssp.c | 476 drivers/spi/Kconfig| 10 + drivers/spi/Makefile |1 + drivers/spi/ti-ssp-spi.c | 402 drivers/video/backlight/Kconfig|7 + drivers/video/backlight/Makefile |2 +- drivers/video/backlight/tps6116x.c | 299 +++ include/linux/mfd/ti_ssp.h | 97 + 17 files changed, 1748 insertions(+), 2 deletions(-) create mode 100644 drivers/gpio/ti-ssp-gpio.c create mode 100644 drivers/mfd/ti-ssp.c create mode 100644 drivers/spi/ti-ssp-spi.c create mode 100644 drivers/video/backlight/tps6116x.c create mode 100644 include/linux/mfd/ti_ssp.h ___ 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: AM1808 EVM with davinci git sleep wake up
Hi Steve, Steve Chen sc...@mvista.com writes: [...] The problem was caused by root filesystem mounted on MMC/SD. When the processor goes to the standby mode, the MMC/SD device was removed as part of the suspend process. This, unfortunately, hangs the kernel. Try enabling CONFIG_MMC_UNSAFE_RESUME: config MMC_UNSAFE_RESUME bool Assume MMC/SD cards are non-removable (DANGEROUS) help If you say Y here, the MMC layer will assume that all cards stayed in their respective slots during the suspend. The normal behaviour is to remove them at suspend and redetecting them at resume. Breaking this assumption will in most cases result in data corruption. This option is usually just for embedded systems which use a MMC/SD card for rootfs. Most people should say N here. This option sets a default which can be overridden by the module parameter removable=0 or removable=1. 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] davinci: tnetv107x: fix register indexing for GPIOs numbers 31
Hirosh Dabui hirosh.da...@snom.com writes:
Changelog:
This isn't needed.
Please repost one more time without this and include Cyril's ack please.
Thanks,
Kevin
This patch fix a bug in the register indexing for GPIOs numbers 31
to get the relevant hardware registers of tnetv107x to control the GPIOs.
In the structure tnetv107x_gpio_regs:
struct tnetv107x_gpio_regs {
u32 idver;
u32 data_in[3];
u32 data_out[3];
u32 direction[3];
u32 enable[3];
};
The GPIO hardware register addresses of tnetv107x are stored.
The chip implements 3 registers of each entity to serve 96 GPIOs,
each register provides a subset of 32 GPIOs.
The driver provides these macros: gpio_reg_set_bit, gpio_reg_get_bit
and gpio_reg_clear_bit.
The bug implied the use of macros to access the relevant hardware
register e.g. the driver code used the macro like this:
'gpio_reg_clear_bit(reg-data_out, gpio)'
But it has to be used like this:
'gpio_reg_clear_bit(reg-data_out, gpio)'.
The different results are shown here:
- reg-data_out + 1 (it will add the full array size of data_out i.e. 12
bytes)
- reg-data_out + 1 (it will increment only the size of data_out i.e. only 4
bytes)
Signed-off-by: Hirosh Dabui hirosh.da...@snom.com
---
arch/arm/mach-davinci/gpio-tnetv107x.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-davinci/gpio-tnetv107x.c
b/arch/arm/mach-davinci/gpio-tnetv107x.c
index d102986..3fa3e28 100644
--- a/arch/arm/mach-davinci/gpio-tnetv107x.c
+++ b/arch/arm/mach-davinci/gpio-tnetv107x.c
@@ -58,7 +58,7 @@ static int tnetv107x_gpio_request(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
- gpio_reg_set_bit(regs-enable, gpio);
+ gpio_reg_set_bit(regs-enable, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -74,7 +74,7 @@ static void tnetv107x_gpio_free(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
- gpio_reg_clear_bit(regs-enable, gpio);
+ gpio_reg_clear_bit(regs-enable, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
}
@@ -88,7 +88,7 @@ static int tnetv107x_gpio_dir_in(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
- gpio_reg_set_bit(regs-direction, gpio);
+ gpio_reg_set_bit(regs-direction, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -106,11 +106,11 @@ static int tnetv107x_gpio_dir_out(struct gpio_chip
*chip,
spin_lock_irqsave(ctlr-lock, flags);
if (value)
- gpio_reg_set_bit(regs-data_out, gpio);
+ gpio_reg_set_bit(regs-data_out, gpio);
else
- gpio_reg_clear_bit(regs-data_out, gpio);
+ gpio_reg_clear_bit(regs-data_out, gpio);
- gpio_reg_clear_bit(regs-direction, gpio);
+ gpio_reg_clear_bit(regs-direction, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -124,7 +124,7 @@ static int tnetv107x_gpio_get(struct gpio_chip *chip,
unsigned offset)
unsigned gpio = chip-base + offset;
int ret;
- ret = gpio_reg_get_bit(regs-data_in, gpio);
+ ret = gpio_reg_get_bit(regs-data_in, gpio);
return ret ? 1 : 0;
}
@@ -140,9 +140,9 @@ static void tnetv107x_gpio_set(struct gpio_chip *chip,
spin_lock_irqsave(ctlr-lock, flags);
if (value)
- gpio_reg_set_bit(regs-data_out, gpio);
+ gpio_reg_set_bit(regs-data_out, gpio);
else
- gpio_reg_clear_bit(regs-data_out, gpio);
+ gpio_reg_clear_bit(regs-data_out, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
}
___
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 v16 1/3] davinci vpbe: changes to common files
Manjunath Hadli manjunath.ha...@ti.com writes:
Implemented a common and single mapping for DAVINCI_SYSTEM_MODULE_BASE
to be used by all davinci platforms.
Please use a more descriptive subject. This patch hs nothing to do with
VPBE, so please send it as a standalone patch.
Thanks,
Kevin
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/common.c|4 +++-
arch/arm/mach-davinci/devices.c | 10 --
arch/arm/mach-davinci/include/mach/hardware.h |5 +
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index 1d25573..949e615 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -111,7 +111,9 @@ void __init davinci_common_init(struct davinci_soc_info
*soc_info)
if (ret != 0)
goto err;
}
-
+ davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
+ if (!davinci_sysmodbase)
+ goto err;
return;
err:
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 22ebc64..2bff2d6 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -33,6 +33,8 @@
#define DM365_MMCSD0_BASE 0x01D11000
#define DM365_MMCSD1_BASE 0x01D0
+void __iomem *davinci_sysmodbase;
+
static struct resource i2c_resources[] = {
{
.start = DAVINCI_I2C_BASE,
@@ -209,9 +211,7 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
davinci_cfg_reg(DM355_SD1_DATA2);
davinci_cfg_reg(DM355_SD1_DATA3);
} else if (cpu_is_davinci_dm365()) {
- void __iomem *pupdctl1 =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c);
-
+ void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c);
/* Configure pull down control */
__raw_writel((__raw_readl(pupdctl1) ~0xfc0),
pupdctl1);
@@ -243,9 +243,7 @@ void __init davinci_setup_mmc(int module, struct
davinci_mmc_config *config)
mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
} else if (cpu_is_davinci_dm644x()) {
/* REVISIT: should this be in board-init code? */
- void __iomem *base =
- IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
-
+ void __iomem *base = DAVINCI_SYSMODULE_VIRT(0);
/* Power-on 3.3V IO cells */
__raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
/*Set up the pull regiter for MMC */
diff --git a/arch/arm/mach-davinci/include/mach/hardware.h
b/arch/arm/mach-davinci/include/mach/hardware.h
index c45ba1f..5a105c4 100644
--- a/arch/arm/mach-davinci/include/mach/hardware.h
+++ b/arch/arm/mach-davinci/include/mach/hardware.h
@@ -24,6 +24,11 @@
/* System control register offsets */
#define DM64XX_VDD3P3V_PWDN 0x48
+#ifndef __ASSEMBLER__
+ extern void __iomem *davinci_sysmodbase;
+ #define DAVINCI_SYSMODULE_VIRT(x) (davinci_sysmodbase+(x))
+#endif
+
/*
* I/O mapping
*/
___
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 v16 2/3] davinci vpbe: platform specific additions
Manjunath Hadli manjunath.ha...@ti.com writes:
This patch implements the overall device creation for the Video
display driver, initializes the platform variables and implements
platform functions including setting video clocks.
This is dm644x specific. Please use 'davinci: dm644x: VPBE' as subject
prefix.
Kevin
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/dm644x.c | 169
+--
arch/arm/mach-davinci/include/mach/dm644x.h |5 +
2 files changed, 163 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..45a89a8 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -586,12 +586,14 @@ static struct platform_device dm644x_asp_device = {
.resource = dm644x_asp_resources,
};
+#define DM644X_VPSS_REG_BASE 0x01c73400
+
static struct resource dm644x_vpss_resources[] = {
{
/* VPSS Base address */
.name = vpss,
- .start = 0x01c73400,
- .end= 0x01c73400 + 0xff,
+ .start = DM644X_VPSS_REG_BASE,
+ .end= DM644X_VPSS_REG_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
};
@@ -618,6 +620,7 @@ static struct resource vpfe_resources[] = {
};
static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+
static struct resource dm644x_ccdc_resource[] = {
/* CCDC Base address */
{
@@ -654,6 +657,137 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+#define DM644X_OSD_REG_BASE 0x01C72600
+
+static struct resource dm644x_osd_resources[] = {
+ {
+ .start = DM644X_OSD_REG_BASE,
+ .end= DM644X_OSD_REG_BASE + 0x1ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct osd_platform_data osd_data = {
+ .vpbe_type = DM644X_VPBE,
+};
+
+static struct platform_device dm644x_osd_dev = {
+ .name = VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_osd_resources),
+ .resource = dm644x_osd_resources,
+ .dev = {
+ .dma_mask = dm644x_osd_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = osd_data,
+ },
+};
+
+#define DM644X_VENC_REG_BASE 0x01C72400
+
+static struct resource dm644x_venc_resources[] = {
+ /* venc registers io space */
+ {
+ .start = DM644X_VENC_REG_BASE,
+ .end= DM644X_VENC_REG_BASE + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
+
+static void __iomem *vpss_clkctl_reg;
+
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64
mode)
+{
+ int ret = 0;
+
+ switch (type) {
+ case VPBE_ENC_STD:
+ writel(0x18, vpss_clkctl_reg);
+ break;
+ case VPBE_ENC_DV_PRESET:
+ switch ((unsigned int)mode) {
+ case V4L2_DV_480P59_94:
+ case V4L2_DV_576P50:
+ writel(0x19, vpss_clkctl_reg);
+ break;
+ case V4L2_DV_720P60:
+ case V4L2_DV_1080I60:
+ case V4L2_DV_1080P30:
+ /*
+ * For HD, use external clock source since
+ * HD requires higher clock rate
+ */
+ writel(0xa, vpss_clkctl_reg);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end= IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device vpbe_v4l2_display = {
+ .name = vpbe-v4l2,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+ .resource = dm644x_v4l2_disp_resources,
+ .dev = {
+ .dma_mask = vpbe_display_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+struct venc_platform_data dm644x_venc_pdata = {
+ .venc_type = DM644X_VPBE,
+ .setup_clock= dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+ .name
Re: [PATCH 0/5] davinci: da850: clean up pinmux arrays in da850.c
Michael Williamson michael.william...@criticallink.com writes: Hi Kevin, On 1/18/2011 1:07 PM, Kevin Hilman wrote: Hi Michael, Michael Williamson michael.william...@criticallink.com writes: The following patch series is an attempt to clean up unused and platform specific pinmux arrays in the da850 CPU files. This series was developed as a result of the following email thread: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg19921.html Thanks for taking this on. I noticed you only move changes to the EVM's board file. Won't this break the other da850-based boards (your board and the hawk board?) I don't think it breaks the other boards. I am building all three with the da8xx_omapl_defconfig. I can only test with mine, though... Neither my board nor the hawkboard use the arrays that are moved (or deleted) in this patch series. The hawkboard defines it's own MMC and McASP pin set in the most recent patch series that is queued. I haven't submitted MMC and McASP patches yet for the MityDSP SoMs. OK, thanks for the clarification. I didn't look closely at those boards. [FYI, there is a v1 of this series posted now, Sekhar pointed out a problem with the original series] OK. 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: DaVinci EMAC driver uses random MAC addresses
Michael Williamson michael.william...@criticallink.com writes:
On 1/7/2011 11:03 AM, Steve Chen wrote:
On Fri, Jan 7, 2011 at 9:50 AM, Cyril Chemparathy cy...@ti.com wrote:
On 01/07/2011 09:14 AM, Sergei Shtylyov wrote:
Hello.
Haven't anybody noticed that the EMAC driver in the current
DaVinci/DA8xx
kernels now uses random MAC addresses instead of the fixed ones. I suspect
the recent changes to the driver made by Cyril Chemparathy... :-)
The emac driver uses the mac_addr stuffed into the pdata, and defaults
to a random mac only if the pdata mac is invalid. It seems to be doing
the right thing at probe:
...
memcpy(priv-mac_addr, pdata-mac_addr, 6);
...
if (!is_valid_ether_addr(priv-mac_addr)) {
/* Use random MAC if none passed */
random_ether_addr(priv-mac_addr);
printk(KERN_WARNING %s: using random MAC addr: %pM\n,
__func__, priv-mac_addr);
}
...
Could you verify that the pdata mac is correctly populated (from eeprom)
before emac probe happens?
Cyril,
I just saw the same problem on a shiny new AM1808 EVM.
pdata-mac_addr are all 0's, so there appears to be a failure reading
the MAC address from EEPROM. However, the uImage from PSP 3.20.00.14
seems to work. By the way, I used da8xx_omapl_defconfig to build the
kernel.
It fails because it doesn't attempt to read it at all...
It doesn't appear that the mainline (davinci-linux) has any provisions
for reading the EMAC address out of the SPI FLASH at initialization for
the da850 evm. However, the arago/PSP platform file for the da850-evm does.
So
it would seem that you have to pass the EMAC addr in via the linux boot args
from u-Boot (ethaddr=...) if you want to set the MAC address and you're
using the davinci-linux / mainline tree.
Correct.
At least for da850/EVM, this has never worked with mainline.
Kevin
I don't see any problems with the MityDSP-L138 / MityARM-1808 platform, but
that platform initializes the MAC address differently than the evm...
-Mike
___
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 1/2] da850: Support for TI's PRU SoftUART Emulation
Nori, Sekhar nsek...@ti.com writes: [...] [SG] -- This McASP clock is bound with the McASP driver by the device ID. This device ID (davinci-mcasp.0) is not available to the SUART driver. You can also look up the clock using con_id if not dev_id. Duplicating clock structure is definitely wrong. or alternatively, use clk_add_alias() 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 v5] davinci: Support various speedgrades for MityDSP-L138 and MityARM-1808 SoMs
Michael Williamson michael.william...@criticallink.com writes:
For the MityDSP-L138/MityARM-1808 SoMs, the speed grade can be determined
from the part number string read from the factory configuration block on
the on-board I2C PROM. Configure the maximum CPU speed based on this
information.
This patch was tested using a MityDSP-L138 and MityARM-1808 at various
speedgrades. Also, for code coverage, a bogus configuration was tested
as well as a configuration having an unknown part number.
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Michael Williamson michael.william...@criticallink.com
Reviewed-by: Sekhar Nori nsek...@ti.com
---
Changes since v4.
- Fixup indenting on if block per comments.
Thanks, queuing this for 2.6.39.
Kevin
arch/arm/mach-davinci/board-mityomapl138.c | 83
+---
1 files changed, 75 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c
b/arch/arm/mach-davinci/board-mityomapl138.c
index 0bb5f0c..0ea5932 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -44,38 +44,109 @@ struct factory_config {
static struct factory_config factory_config;
+struct part_no_info {
+ const char *part_no; /* part number string of interest */
+ int max_freq; /* khz */
+};
+
+static struct part_no_info mityomapl138_pn_info[] = {
+ {
+ .part_no= L138-C,
+ .max_freq = 30,
+ },
+ {
+ .part_no= L138-D,
+ .max_freq = 375000,
+ },
+ {
+ .part_no= L138-F,
+ .max_freq = 456000,
+ },
+ {
+ .part_no= 1808-C,
+ .max_freq = 30,
+ },
+ {
+ .part_no= 1808-D,
+ .max_freq = 375000,
+ },
+ {
+ .part_no= 1808-F,
+ .max_freq = 456000,
+ },
+ {
+ .part_no= 1810-D,
+ .max_freq = 375000,
+ },
+};
+
+#ifdef CONFIG_CPU_FREQ
+static void mityomapl138_cpufreq_init(const char *partnum)
+{
+ int i, ret;
+
+ for (i = 0; partnum i ARRAY_SIZE(mityomapl138_pn_info); i++) {
+ /*
+ * the part number has additional characters beyond what is
+ * stored in the table. This information is not needed for
+ * determining the speed grade, and would require several
+ * more table entries. Only check the first N characters
+ * for a match.
+ */
+ if (!strncmp(partnum, mityomapl138_pn_info[i].part_no,
+ strlen(mityomapl138_pn_info[i].part_no))) {
+ da850_max_speed = mityomapl138_pn_info[i].max_freq;
+ break;
+ }
+ }
+
+ ret = da850_register_cpufreq(pll0_sysclk3);
+ if (ret)
+ pr_warning(cpufreq registration failed: %d\n, ret);
+}
+#else
+static void mityomapl138_cpufreq_init(const char *partnum) { }
+#endif
+
static void read_factory_config(struct memory_accessor *a, void *context)
{
int ret;
+ const char *partnum = NULL;
struct davinci_soc_info *soc_info = davinci_soc_info;
ret = a-read(a, (char *)factory_config, 0, sizeof(factory_config));
if (ret != sizeof(struct factory_config)) {
pr_warning(MityOMAPL138: Read Factory Config Failed: %d\n,
ret);
- return;
+ goto bad_config;
}
if (factory_config.magic != FACTORY_CONFIG_MAGIC) {
pr_warning(MityOMAPL138: Factory Config Magic Wrong (%X)\n,
factory_config.magic);
- return;
+ goto bad_config;
}
if (factory_config.version != FACTORY_CONFIG_VERSION) {
pr_warning(MityOMAPL138: Factory Config Version Wrong (%X)\n,
factory_config.version);
- return;
+ goto bad_config;
}
pr_info(MityOMAPL138: Found MAC = %pM\n, factory_config.mac);
- pr_info(MityOMAPL138: Part Number = %s\n, factory_config.partnum);
if (is_valid_ether_addr(factory_config.mac))
memcpy(soc_info-emac_pdata-mac_addr,
factory_config.mac, ETH_ALEN);
else
pr_warning(MityOMAPL138: Invalid MAC found
in factory config block\n);
+
+ partnum = factory_config.partnum;
+ pr_info(MityOMAPL138: Part Number = %s\n, partnum);
+
+bad_config:
+ /* default maximum speed is valid for all platforms */
+ mityomapl138_cpufreq_init(partnum);
}
static struct at24_platform_data mityomapl138_fd_chip = {
@@ -383,10
Re: [PATCH v5] davinci: Add additional JTAG code for AM-1808 and OMAP-L138 Rev 2.0 SoCs From: Sudhakar Rajashekhara sudhakar....@ti.com
Michael Williamson michael.william...@criticallink.com writes:
On 01/03/2011 05:33 PM, Kevin Hilman wrote:
Michael Williamson michael.william...@criticallink.com writes:
I'm assuming the 'From:' line currently in the subject was supposed to
go here?
Kevin
Arg. Yes. Sorry about that; not sure how I lost the newline. Do you need me
to resend?
No biggie, I can take care of it. Just wanted to let you know something
got messed up on the sending side.
Kevin
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.
This patch is originally from a patch on the arago project, here:
http://arago-project.org/git/projects/?p=linux-omapl1.git;a=commit;h=6157618435e313a444cdf059702bd34036a6e2b7
Further information related to the need for this patch can be located at
http://e2e.ti.com/support/embedded/f/354/p/67290/248486.aspx
http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-November/021224.html
This patch was tested using an AM-1808 SoC on a MityARM-1808 SoM card. It
was also tested using a Rev 1.0 silicon OMAP-L138 on a MityDSP-L138F card.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Michael Williamson michael.william...@criticallink.com
Reported-by: Nicolas Luna luna...@gmail.com
---
Built against linux-davinci tree.
Changes since v4.
- removed am18x code from 0 variant per Sekhar's request.
arch/arm/mach-davinci/da850.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 78b5ae2..1550ac3 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -764,6 +764,13 @@ static struct davinci_id da850_ids[] = {
.cpu_id = DAVINCI_CPU_ID_DA850,
.name = da850/omap-l138,
},
+ {
+ .variant= 0x1,
+ .part_no= 0xb7d1,
+ .manufacturer = 0x017,/* 0x02f 1 */
+ .cpu_id = DAVINCI_CPU_ID_DA850,
+ .name = da850/omap-l138/am18x,
+ },
};
static struct davinci_timer_instance da850_timer_instance[4] = {
___
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] davinci: Add additional JTAG code for AM-1808 and OMAP-L138 Rev 2.0 SoCs From: Sudhakar Rajashekhara sudhakar....@ti.com
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.
This patch is originally from a patch on the arago project, here:
http://arago-project.org/git/projects/?p=linux-omapl1.git;a=commit;h=6157618435e313a444cdf059702bd34036a6e2b7
Further information related to the need for this patch can be located at
http://e2e.ti.com/support/embedded/f/354/p/67290/248486.aspx
http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-November/021224.html
This patch was tested using an AM-1808 SoC on a MityARM-1808 SoM card. It
was also tested using a Rev 1.0 silicon OMAP-L138 on a MityDSP-L138F card.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Michael Williamson michael.william...@criticallink.com
Tested-by: Michael Williamson michael.william...@criticallink.com
Reported-by: Nicolas Luna luna...@gmail.com
Thanks, queueing this for 2.6.39.
Also added a reviewed-by tag for Sekhar.
Kevin
---
Built against linux-davinci tree.
Changes since v4.
- removed am18x code from 0 variant per Sekhar's request.
arch/arm/mach-davinci/da850.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 78b5ae2..1550ac3 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -764,6 +764,13 @@ static struct davinci_id da850_ids[] = {
.cpu_id = DAVINCI_CPU_ID_DA850,
.name = da850/omap-l138,
},
+ {
+ .variant= 0x1,
+ .part_no= 0xb7d1,
+ .manufacturer = 0x017,/* 0x02f 1 */
+ .cpu_id = DAVINCI_CPU_ID_DA850,
+ .name = da850/omap-l138/am18x,
+ },
};
static struct davinci_timer_instance da850_timer_instance[4] = {
___
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 to disable MSR interrupts in 8250 driver. Request for guidance...
Michael Williamson michael.william...@criticallink.com writes: I am working on platform from the davinci architecture that uses the 8520 UART driver. However, there are some configurations that do not have a valid CTS input pin (it is a multi-purpose pin on a SoC part, and it may be configured for other functions). These configurations can cause a pile of false MSR interrupts. If, in 8250.c, I set the UART_BUG_NOMSR flag as part of the up-bugs information, the problem clears up. [...] Should I create a new port type, add a new UPF_ flag in the flags field, figure out how to pass bugs information via platform data, or continue along the work-around path? I added Greg KH to Cc as he's maintaining the 8250 core now. IMO, adding UPF_ flag(s) to indicate this bug seems like the right way to go to me. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] davinci updates for 2.6.38
Russell,
Please pull the following changes for the TI DaVinci family of SoCs for
the 2.6.38 merge window.
Thanks,
Kevin
The following changes since commit cf7d7e5a1980d1116ee152d25dac382b112b9c17:
Linux 2.6.37-rc5 (2010-12-06 20:09:04 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
davinci-next
Andreas Gaeer (1):
davinci: Implement sched_clock()
Ben Gardiner (7):
davinci: da850-evm: UI expander gpio_set_value can sleep, use _cansleep
da850-evm: allow pca953x module build
da850-evm, trivial: use da850_evm prefix for consistency
da850-evm: add UI Expander pushbuttons
da850-evm: extract defines for SEL{A,B,C} pins in UI expander
da850-evm: add baseboard GPIO expander buttons, switches and LEDs
da850-evm: KEYBOARD_GPIO_POLLED Kconfig conditional
Cyril Chemparathy (2):
davinci: use divide ratio limits from pll_data
davinci: minor tnetv107x clock tree fixes
Kevin Hilman (1):
davinci: kconfig: select at24 eeprom for selected boards
Nicolas Kaiser (2):
davinci: psc: simplify if-statement
davinci: aemif: signedness bug in davinci_aemif_setup_timing()
Sekhar Nori (2):
davinci: am18x/da850/omap-l138: add support for higher speed grades
davinci: am18x/da850/omap-l138 evm: add support for higher speed grades
arch/arm/mach-davinci/Kconfig | 19 ++-
arch/arm/mach-davinci/aemif.c |2 +-
arch/arm/mach-davinci/board-da850-evm.c| 339 ++--
arch/arm/mach-davinci/clock.c |4 +-
arch/arm/mach-davinci/da850.c | 75 +--
arch/arm/mach-davinci/devices-tnetv107x.c | 15 ++-
arch/arm/mach-davinci/include/mach/da8xx.h |7 +
arch/arm/mach-davinci/psc.c| 13 +-
arch/arm/mach-davinci/time.c | 24 ++-
arch/arm/mach-davinci/tnetv107x.c | 23 +-
10 files changed, 462 insertions(+), 59 deletions(-)
___
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: tnetv107x: fix register indexing for gpio 31
Hirosh Dabui hirosh.da...@snom.com writes:
Hello Kevin,
here is the Changelog, i hope that will be enough.
This is a better changelog, but it needs to accompany the patch please.
Kevin
Changelog: There was a bug in the register indexing for GPIOs numbers 31 to
get the relevant hardware registers of tnetv107x to control the GPIOs.
In the structure tnetv107x_gpio_regs:
struct tnetv107x_gpio_regs {
u32 idver;
u32 data_in[3];
u32 data_out[3];
u32 direction[3];
u32 enable[3];
};
The GPIO hardware register addresses of tnetv107x are stored.
The chip implements 3 registers of each entity to serve 96 GPIOs, each
register provides a subset of 32 GPIOs.
The driver provides these macros: gpio_reg_set_bit, gpio_reg_get_bit and
gpio_reg_clear_bit.
The bug implied the use of macros to access the relevant hardware register
e.g. the driver code used the macro like this:
'gpio_reg_clear_bit(reg-data_out, gpio)'
But it has to be used like this:
'gpio_reg_clear_bit(reg-data_out, gpio)'.
The different results are shown here:
-p-data_out + 1 (it will add the full array size of data_out i.e. 12 bytes)
-p-data_out + 1 (it will increment only the size of data_out i.e. only 4
bytes)
br,
Hirosh Dabui
On 12/21/2010 05:50 PM, Kevin Hilman wrote:
Hirosh Dabuihirosh.da...@snom.com writes:
Please add a descriptive changelog here describing the problem being
fixed.
Also, I'll need an Acked-by from Cyril before merging any tnetv107x
patches.
Kevin
Signed-off-by: Hirosh Dabuihirosh.da...@snom.com
---
arch/arm/mach-davinci/gpio-tnetv107x.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-davinci/gpio-tnetv107x.c
b/arch/arm/mach-davinci/gpio-tnetv107x.c
index d102986..3fa3e28 100644
--- a/arch/arm/mach-davinci/gpio-tnetv107x.c
+++ b/arch/arm/mach-davinci/gpio-tnetv107x.c
@@ -58,7 +58,7 @@ static int tnetv107x_gpio_request(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
-gpio_reg_set_bit(regs-enable, gpio);
+gpio_reg_set_bit(regs-enable, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -74,7 +74,7 @@ static void tnetv107x_gpio_free(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
-gpio_reg_clear_bit(regs-enable, gpio);
+gpio_reg_clear_bit(regs-enable, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
}
@@ -88,7 +88,7 @@ static int tnetv107x_gpio_dir_in(struct gpio_chip *chip,
unsigned offset)
spin_lock_irqsave(ctlr-lock, flags);
-gpio_reg_set_bit(regs-direction, gpio);
+gpio_reg_set_bit(regs-direction, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -106,11 +106,11 @@ static int tnetv107x_gpio_dir_out(struct gpio_chip
*chip,
spin_lock_irqsave(ctlr-lock, flags);
if (value)
-gpio_reg_set_bit(regs-data_out, gpio);
+gpio_reg_set_bit(regs-data_out, gpio);
else
-gpio_reg_clear_bit(regs-data_out, gpio);
+gpio_reg_clear_bit(regs-data_out, gpio);
-gpio_reg_clear_bit(regs-direction, gpio);
+gpio_reg_clear_bit(regs-direction, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
@@ -124,7 +124,7 @@ static int tnetv107x_gpio_get(struct gpio_chip *chip,
unsigned offset)
unsigned gpio = chip-base + offset;
int ret;
-ret = gpio_reg_get_bit(regs-data_in, gpio);
+ret = gpio_reg_get_bit(regs-data_in, gpio);
return ret ? 1 : 0;
}
@@ -140,9 +140,9 @@ static void tnetv107x_gpio_set(struct gpio_chip *chip,
spin_lock_irqsave(ctlr-lock, flags);
if (value)
-gpio_reg_set_bit(regs-data_out, gpio);
+gpio_reg_set_bit(regs-data_out, gpio);
else
-gpio_reg_clear_bit(regs-data_out, gpio);
+gpio_reg_clear_bit(regs-data_out, gpio);
spin_unlock_irqrestore(ctlr-lock, flags);
}
Buon natale! God Jul! Frohe Festtage! Merry Christmas! Feliz Navidad! Chuc
Mung Giang Sinh! Boas Fesats! Mutlu Noel èr!
* The snom Advent Calendar: Win a prize every Day:
www.snom.com/christmashttp://www.snom.com/christmas
* Did you know how versatile snom phones are?
www.snom.com/en/why-snom/did-you-know/http://www.snom.com/en/why-snom/did-you-know/
* introducing snom ONE:
http://www.snom.com/products/ip-pbx/snom-onehttp://www.snom.com/products/ip-pbx/snom-one/
* Join our Partner program: http://www.snom.com/partner
* Subscribe to our snom support RSS
Feedhttp://wiki.snom.com/wiki/index.php?title=RSSaction=feedfeed=rss and
get first-hand technical news about snom products, e.g. Firmware updates, FAQ
updates, troubleshooting hints, etc.
Follow us on Facebookhttp://www.facebook.com/snom.VoIP.phones,
Twitterhttp://twitter.com/snom,
YouTubehttp://www.youtube.com
Re: [PATCH v5 1/2] davinci: am18x/da850/omap-l138: add support for higher speed grades
Sekhar Nori nsek...@ti.com writes: AM18x/DA850/OMAP-L138 SoCs have variants that can operate at a maximum of 456 MHz at 1.3V operating point. Also the 1.2V operating point has a variant that can support a maximum of 375 MHz. This patch adds three new OPPs (456 MHz, 408 MHz and 372 MHz) to the list of DA850 OPPs. Not all silicon is qualified to run at higher speeds and unfortunately the maximum speed the chip can support can only be determined from the label on the package (not software readable). Because of this, we depend on the maximum speed grade information to be provided to us in some board specific way. The board informs the maximum speed grade information by setting the da850_max_speed variable. Signed-off-by: Sekhar Nori nsek...@ti.com --- Since v4, the patch decription has been updated to match the code. No code change has been made. Thanks, I updated davinci-next branch with these versions. Queuing for 2.6.38. 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 v9 5/8] davinci vpbe: platform specific additions
Manjunath Hadli manjunath.ha...@ti.com writes:
This patch implements the overall device creation for the Video
display driver
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
This one still conflicts with other changes in davinci-next queued for
2.6.38.
Please separate this out from the rest of the series, and ensure it
applies on davinci-next branch.
Also, minor comment below...
---
arch/arm/mach-davinci/dm644x.c | 170
++-
arch/arm/mach-davinci/include/mach/dm644x.h |4 +
2 files changed, 168 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 5e5b0a7..9940032 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -640,6 +640,146 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+static struct resource dm644x_osd_resources[] = {
+ {
+ .start = 0x01C72600,
+ .end= 0x01C72600 + 0x1ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm644x_osd_dev = {
+ .name = VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_osd_resources),
+ .resource = dm644x_osd_resources,
+ .dev = {
+ .dma_mask = dm644x_osd_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = (void *)DM644X_VPBE,
+ },
+};
+
+static struct resource dm644x_venc_resources[] = {
+ /* venc registers io space */
+ {
+ .start = 0x01C72400,
+ .end= 0x01C72400 + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
+
+#define VPSS_CLKCTL 0x01C40044
+
+static void __iomem *vpss_clkctl_reg;
+
+/* TBD. Check what VENC_CLOCK_SEL settings for HDTV and EDTV */
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64
mode)
+{
+ int ret = 0;
+
+ if (NULL == vpss_clkctl_reg)
+ return -EINVAL;
+ switch (type) {
+ case VPBE_ENC_STD:
+ __raw_writel(0x18, vpss_clkctl_reg);
+ break;
+ case VPBE_ENC_DV_PRESET:
+ switch ((unsigned int)mode) {
+ case V4L2_DV_480P59_94:
+ case V4L2_DV_576P50:
+ __raw_writel(0x19, vpss_clkctl_reg);
+ break;
+ case V4L2_DV_720P60:
+ case V4L2_DV_1080I60:
+ case V4L2_DV_1080P30:
+ /*
+ * For HD, use external clock source since HD requires higher
+ * clock rate
+ */
+ __raw_writel(0xa, vpss_clkctl_reg);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static inline u32 dm644x_reg_modify(void *reg, u32 val, u32 mask)
+{
+ u32 new_val = (__raw_readl(reg) ~mask) | (val mask);
+ __raw_writel(new_val, reg);
+ return new_val;
+}
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end= IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = 0x01C724B8,
+ .end= 0x01C724B8 + 0x4,
+ .flags = IORESOURCE_MEM,
+ },
+
+};
+
+static struct platform_device vpbe_v4l2_display = {
+ .name = vpbe-v4l2,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+ .resource = dm644x_v4l2_disp_resources,
+ .dev = {
+ .dma_mask = vpbe_display_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+struct venc_platform_data dm644x_venc_pdata = {
+ .venc_type = DM644X_VPBE,
+ .setup_clock = dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+ .name = VPBE_VENC_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_venc_resources),
+ .resource = dm644x_venc_resources,
+ .dev = {
+ .dma_mask = dm644x_venc_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = (void *)dm644x_venc_pdata,
+ },
+};
+
+static u64 dm644x_vpbe_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm644x_vpbe_dev = {
+ .name =
Re: [PATCH v1] davinci: Add additional JTAG code for AM-1808 and OMAP-L138 Rev 2.0 SoCs
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?
Kevin
Signed-off-by: Michael Williamson michael.william...@criticallink.com
---
This is against davinci-linux tree.
Changes since v0, removed whitespace fixups not related to patch.
arch/arm/mach-davinci/da850.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 78b5ae2..2d0bba5 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -764,6 +764,13 @@ static struct davinci_id da850_ids[] = {
.cpu_id = DAVINCI_CPU_ID_DA850,
.name = da850/omap-l138,
},
+ {
+ .variant= 0x1,
+ .part_no= 0xb7d1,
+ .manufacturer = 0x017,/* 0x02f 1 */
+ .cpu_id = DAVINCI_CPU_ID_DA850,
+ .name = da850/omap-l138/am18xx,
+ },
};
static struct davinci_timer_instance da850_timer_instance[4] = {
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
davinci git: update to .37-rc7, no more patches for 2.6.38
Hello, Davinci git is now updated to 2.6.37-rc7, and also includes the davinci-next branch which has all the davinci patches queued for the upcoming 2.6.38 merge window. Since the merge window will be opening rather shortly, I will not be accepting any more patches for the 2.6.38 merge window. This will give some time for davinci-next to be tested with all the other changes coming for 2.6.38 in the linux-next tree from the other subsystems. 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 v1] davinci: Add additional JTAG code for AM-1808 and OMAP-L138 Rev 2.0 SoCs
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.
Thanks,
Kevin
unless someone at TI
is prepping the same patch? I sent it because the AM-1808 fails to boot
without
it. Thanks.
Y
-Mike
davinci thread:
http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-November/021224.html
e2e thread:
http://e2e.ti.com/support/embedded/f/354/p/67290/248486.aspx
arago kernel patch:
http://arago-project.org/git/projects/?p=linux-omapl1.git;a=commit;h=6157618435e313a444cdf059702bd34036a6e2b7
Kevin
Signed-off-by: Michael Williamson michael.william...@criticallink.com
---
This is against davinci-linux tree.
Changes since v0, removed whitespace fixups not related to patch.
arch/arm/mach-davinci/da850.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 78b5ae2..2d0bba5 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -764,6 +764,13 @@ static struct davinci_id da850_ids[] = {
.cpu_id = DAVINCI_CPU_ID_DA850,
.name = da850/omap-l138,
},
+ {
+ .variant= 0x1,
+ .part_no= 0xb7d1,
+ .manufacturer = 0x017,/* 0x02f 1 */
+ .cpu_id = DAVINCI_CPU_ID_DA850,
+ .name = da850/omap-l138/am18xx,
+ },
};
static struct davinci_timer_instance da850_timer_instance[4] = {
___
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: tnetv107x: fix register indexing for gpio 31
Hirosh Dabui hirosh.da...@snom.com writes: Please add a descriptive changelog here describing the problem being fixed. Also, I'll need an Acked-by from Cyril before merging any tnetv107x patches. Kevin Signed-off-by: Hirosh Dabui hirosh.da...@snom.com --- arch/arm/mach-davinci/gpio-tnetv107x.c | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-davinci/gpio-tnetv107x.c b/arch/arm/mach-davinci/gpio-tnetv107x.c index d102986..3fa3e28 100644 --- a/arch/arm/mach-davinci/gpio-tnetv107x.c +++ b/arch/arm/mach-davinci/gpio-tnetv107x.c @@ -58,7 +58,7 @@ static int tnetv107x_gpio_request(struct gpio_chip *chip, unsigned offset) spin_lock_irqsave(ctlr-lock, flags); - gpio_reg_set_bit(regs-enable, gpio); + gpio_reg_set_bit(regs-enable, gpio); spin_unlock_irqrestore(ctlr-lock, flags); @@ -74,7 +74,7 @@ static void tnetv107x_gpio_free(struct gpio_chip *chip, unsigned offset) spin_lock_irqsave(ctlr-lock, flags); - gpio_reg_clear_bit(regs-enable, gpio); + gpio_reg_clear_bit(regs-enable, gpio); spin_unlock_irqrestore(ctlr-lock, flags); } @@ -88,7 +88,7 @@ static int tnetv107x_gpio_dir_in(struct gpio_chip *chip, unsigned offset) spin_lock_irqsave(ctlr-lock, flags); - gpio_reg_set_bit(regs-direction, gpio); + gpio_reg_set_bit(regs-direction, gpio); spin_unlock_irqrestore(ctlr-lock, flags); @@ -106,11 +106,11 @@ static int tnetv107x_gpio_dir_out(struct gpio_chip *chip, spin_lock_irqsave(ctlr-lock, flags); if (value) - gpio_reg_set_bit(regs-data_out, gpio); + gpio_reg_set_bit(regs-data_out, gpio); else - gpio_reg_clear_bit(regs-data_out, gpio); + gpio_reg_clear_bit(regs-data_out, gpio); - gpio_reg_clear_bit(regs-direction, gpio); + gpio_reg_clear_bit(regs-direction, gpio); spin_unlock_irqrestore(ctlr-lock, flags); @@ -124,7 +124,7 @@ static int tnetv107x_gpio_get(struct gpio_chip *chip, unsigned offset) unsigned gpio = chip-base + offset; int ret; - ret = gpio_reg_get_bit(regs-data_in, gpio); + ret = gpio_reg_get_bit(regs-data_in, gpio); return ret ? 1 : 0; } @@ -140,9 +140,9 @@ static void tnetv107x_gpio_set(struct gpio_chip *chip, spin_lock_irqsave(ctlr-lock, flags); if (value) - gpio_reg_set_bit(regs-data_out, gpio); + gpio_reg_set_bit(regs-data_out, gpio); else - gpio_reg_clear_bit(regs-data_out, gpio); + gpio_reg_clear_bit(regs-data_out, gpio); spin_unlock_irqrestore(ctlr-lock, flags); } ___ 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/2] da850: Support for TI's PRU SoftUART Emulation
Nori, Sekhar nsek...@ti.com writes: Hi Kevin, On Sat, Dec 11, 2010 at 06:01:19, Kevin Hilman wrote: Subhasish Ghosh ghosh.subhas...@gmail.com writes: The patch adds support for emulated UART controllers on the programmable realtime unit (PRU) available on OMAPL138. This defines the system resource requirements such as pin mux, clock, iomem, interrupt etc and registers the platform device as per the Linux driver model. Signed-off-by: Subhasish Ghosh subhas...@mistralsolutions.com You might consider setting your git user to use your Mistral address, so according to git, the author and the sign-off are the same person. Otherwise, git stats will report your personal address as the author and your company address as the signoff. Also, please Cc linux-arm-ker...@lists.infradead.org on all davinci kernel patches. Otherwise, this patch is looking ok (after addressing alignment issue reported by Sergei.) Is it OK to merge the platform data before the driver is merged? Hmm, good point. It's probably not worth merging until we can also see the driver, since more than likely, the data between device code and driver will have to change before the driver merges. Let's wait on this to see the driver too. 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 v6 0/5] da850-evm: add gpio-{keys, leds} for UI and BB expanders
Ben Gardiner bengardi...@nanometrics.ca writes: On Mon, Dec 13, 2010 at 4:53 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Ben Gardiner bengardi...@nanometrics.ca writes: [...] Everything seems to be in order there; I tested the resulting kernel with evtest and the expected output was observed. Note that davinci-next still contains the cherry-pick of the upstream commit of the polled gpio keys driver: oops... I've now removed that, since it is part of v2.6.36-rc5 already. Thanks for checking. Oops on my part... [...] It appears that dropping the cherry-pick caused the build failure. The commit that introduces the polled gpio keys driver (which was included in the series as a cherry pick) is commit 0e7d0c860a0dee49dacb7bbb248d1eba637075ad which is in git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#master _after_ the tag v2.6.37-rc5. That's my fault. I incorrectly thought that commit 0e7d0c860a0dee49dacb7bbb248d1eba637075ad was _in_ 2.6.37-rc5 and stated this is previous emails. I'm sorry for the confusion; I think I jumped the gun there due to my excitement at getting this prerequisite driver committed. OK, while waiting for it to arrive upstream, I've added it to my 'davinci-backports' branch, which is also merged into the master branch of davinci git (but not in davinci-next, since it will go upstream via another subsystem.) Just pushed an updated version, and this time, I actually build tested for davinci_all_defconfig and da8xx_omapl_defconfig. :) Sorry for the churn, 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 v6 0/5] da850-evm: add gpio-{keys, leds} for UI and BB expanders
Ben Gardiner bengardi...@nanometrics.ca writes: Hi Kevin, On Fri, Dec 10, 2010 at 11:33 AM, Ben Gardiner bengardi...@nanometrics.ca wrote: On Fri, Dec 10, 2010 at 11:16 AM, Kevin Hilman [...] This series looks good to me, so I'll be queuing it in davinci-next for 2.6.38. It should show up in davinci git shortly. [...] Thank you very much, Kevin. I will check linux-davinci/master on monday. I looked at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git#davinci-next ; HEAD at the time was commit 3004ce0d3a44525de63e18b01f7734bc8d64f2c5 Author: Ben Gardiner bengardi...@nanometrics.ca Date: Thu Dec 9 16:51:07 2010 -0500 da850-evm: KEYBOARD_GPIO_POLLED Kconfig conditional Use the mach-davinci/Kconfig to enable gpio-keys-polled as default when da850-evm machine is enabled. Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca CC: Kevin Hilman khil...@deeprootsystems.com CC: Nori, Sekhar nsek...@ti.com CC: Gabor Juhos juh...@openwrt.org Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Everything seems to be in order there; I tested the resulting kernel with evtest and the expected output was observed. Note that davinci-next still contains the cherry-pick of the upstream commit of the polled gpio keys driver: oops... I've now removed that, since it is part of v2.6.36-rc5 already. Thanks for checking. [...] I also looked at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git#master ; HEAD at the time was commit 4bfbdddc0655a284a98304bc343c6bcaf81b8e4d Merge: 771215c 7507fd3 Author: Kevin Hilman khil...@deeprootsystems.com Date: Fri Dec 10 16:25:27 2010 -0800 rebuild linux-davinci from branches There appears to be some double commits of the patch series. I tested it with evtest anyways and also observed the expected output. The following command and its output hopefully demonstrate what I am seeing as double commits. Yes, there will be double commits in master, because of the way I manage master using 'git merge -ours'. But there shouldn't be double commits between my rebuild from braches merges. It can be confusing, but if you look at the history with a graphical tool like 'gitk', it might shed some light on what is going on. I know it's confusing, but the davinci-next branch is the only important branch in this tree for upstream purposes. [...] Note that the cherry pick of the upstream commit of the polled gpio keys driver is here in 'master' also. Yeah, that came from davinc-next. Now that it's removed from there, it should be ok. I just pushed an updated davinci-next and master branch. It sometimes takes a bit to propagate to all the kernel.org mirrors, but the update should be there shortly. Thanks, 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 v6 1/5] Input: add input driver for polled GPIO buttons
Ben Gardiner bengardi...@nanometrics.ca writes: From: Gabor Juhos juh...@openwrt.org The existing gpio-keys driver can be usable only for GPIO lines with interrupt support. Several devices have buttons connected to a GPIO line which is not capable to generate interrupts. This patch adds a new input driver using the generic GPIO layer and the input-polldev to support such buttons. [Ben Gardiner bengardi...@nanometrics.ca: fold code to use more of the original gpio_keys infrastructure; cleanups and other improvements.] Signed-off-by: Gabor Juhos juh...@openwrt.org Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca Tested-by: Ben Gardiner bengardi...@nanometrics.ca Signed-off-by: Dmitry Torokhov d...@mail.ru (cherry picked from commit 0e7d0c860a0dee49dacb7bbb248d1eba637075ad) --- This a copy of the commit -- I included in the patch series since linux-davinci/master does not currently have it; but 2.6.37-rc5 does. I'll be updating davinci master to .37-rc5 today, so will drop this patch. 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 v6 0/5] da850-evm: add gpio-{keys, leds} for UI and BB expanders
Hi Ben, Ben Gardiner bengardi...@nanometrics.ca writes: The da850-evm baseboard (BB) and its UI board both have tca6416 IO expanders. They are bootstrapped to different I2C addresses so they can be used concurrently. The expander on the UI board is currently used to enable/disable the peripherals that are available on the UI board. In addition to this functionality the expander is also connected to 8 pushbuttons. The expander on the baseboard is not currently used; it is connected to deep sleep enable, sw reset, a push button, some switches and LEDs. This proposed patch series enables the push buttons and switches on the UI and BB expanders using the gpio-keys polling mode patch by Gabor Juhos. Some work was performed to test irq-based gpio-keys support on the expanders (a WIP patch can be posted on request) but I believe that it is not possible to use irq-based gpio-keys on IO expanders for arm systems at this time. Thanks for your patience and persistence on this series, and thanks for working closely with the input folks to get the issues worked through. This series looks good to me, so I'll be queuing it in davinci-next for 2.6.38. It should show up in davinci git shortly. Please validate things are working as expected there. Were there any changes needed to the defaults in da8xx_omapl_defconfig to enable these features by default? or does the Kconfig change in PATCH 5/5 cover it? Also, I really appreciate the thorough patch descriptions and history information. This greatly eases the work of maintainers. Thanks! One minor question: the series has a couple of Signed-off-by tags from Sekhar Nori. The s-o-b tag is for folks on the delivery path, and based on what I saw, these should probably be Acked-by tags from Sekhar, since he certainly helped on the review/test/validate side, but AFAICT, was not an author or on the delivery path. If I'm wrong on this (e.g., if Sekhar actually did author some of those patches) let me know, otherwise I'll change the s-o-b to Acked-by for Sekhar. Thanks, 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] regulator: add driver for tps6524x regulator
Mark Brown broo...@opensource.wolfsonmicro.com writes: On Tue, Dec 07, 2010 at 12:20:14PM -0500, Cyril Chemparathy wrote: On 12/07/2010 12:15 PM, Mark Brown wrote: Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Is this to be merged via the davinci tree? Liam would need to merge it, or it'd need to wait until the regulator tree change to the signature of set_voltage() gets merged into the DaVinci tree. I suggest Liam merge this, as there shouldn't be any dependencies in the davinci tree. 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 v7 11/12] davinci: add tnetv107x evm backlight device
Nori, Sekhar nsek...@ti.com writes: On Thu, Dec 09, 2010 at 20:28:41, Chemparathy, Cyril wrote: On 12/09/2010 06:00 AM, Nori, Sekhar wrote: On Thu, Dec 09, 2010 at 14:25:49, Nori, Sekhar wrote: This call should simply return if machine is not tnetv107x EVM. I didn't follow the entire series but wondering why platform device registration should be a late init call. Typically the driver probe can be made a late init call in case of init sequence dependencies. I meant driver init, not probe. This was done to handle driver dependencies, and is meant to be temporary (until a real driver dependency framework comes in). Please see [1] for a bit more of background on changing drivers to use module_init(). Hmm, okay. Please include a check for machine in that case. Sekhar is right. Today, we don't (can't) build this machine with others for a couple reasons, but we're moving towards removing those restrictions, so when this machine is included in a binary with others, it needs to check. Thanks, 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 v4 0/6] davinci vpbe: dm6446 v4l2 driver
Hans Verkuil hverk...@xs4all.nl writes: version4 : addressed Hans's comments on: 1. replaced mutex_lock_interruptible() with mutex_lock() 2. replaced ntsc and pal macros with new equivalent macros 3. simplifying the code in the if-else condition 4. minor code corrections For the whole patch series: Acked-by: Hans Verkuil hverk...@xs4all.nl Hans, can you take patches 1-4 and 6 through the linux-media tree? I will queue the patch 5 (the only mach-davinci change) in davinci git for 2.6.38. Manjunath, can rebase patch 5 on top of current davinci-next (or davinci master) as this patch doesn't currently apply there. Thanks, Kevin Manjunath Hadli (6): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: platform specific additions davinci vpbe: Build infrastructure for VPBE driver arch/arm/mach-davinci/board-dm644x-evm.c | 79 +- arch/arm/mach-davinci/dm644x.c | 164 ++- arch/arm/mach-davinci/include/mach/dm644x.h|4 + drivers/media/video/davinci/Kconfig| 22 + drivers/media/video/davinci/Makefile |2 + .../media/video/davinci/davinci_vpbe_readme.txt| 100 + drivers/media/video/davinci/vpbe.c | 837 drivers/media/video/davinci/vpbe_display.c | 2099 drivers/media/video/davinci/vpbe_osd.c | 1211 +++ drivers/media/video/davinci/vpbe_osd_regs.h| 389 drivers/media/video/davinci/vpbe_venc.c| 574 ++ drivers/media/video/davinci/vpbe_venc_regs.h | 189 ++ include/media/davinci/vpbe.h | 186 ++ include/media/davinci/vpbe_display.h | 146 ++ include/media/davinci/vpbe_osd.h | 397 include/media/davinci/vpbe_types.h | 93 + include/media/davinci/vpbe_venc.h | 38 + 17 files changed, 6511 insertions(+), 19 deletions(-) create mode 100644 drivers/media/video/davinci/davinci_vpbe_readme.txt create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h ___ 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] davinci: am18x/da850/omap-l138: add support for higher speed grades
Sekhar Nori nsek...@ti.com writes:
AM18x/DA850/OMAP-L138 SoCs have variants that can operate
at a maximum of 456 MHz at 1.3V operating point. Also the
1.2V operating point has a variant that can support a maximum
of 375 MHz.
This patch adds three new OPPs (456 MHz, 408 MHz and 372 MHz)
to the list of DA850 OPPs.
Not all silicon is qualified to run at higher speeds and
unfortunately the maximum speed the chip can support can only
be determined from the label on the package (not software
readable).
Because of this, we depend on the maximum speed grade information
to be provided to us in some board specific way. The board informs
the maximum speed grade information to the SoC by calling the
da850_set_max_speed() function.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Since v3:
Fixed pre-div and post-div for 372MHz OPP based on PLLOUT range
limitations documented in OMAP-L138 datasheet. AM1808 datasheet
will be updated to match this.
This series looks good, but can you (re)post one more time and Cc
the linux-arm-kernel list please?
Thanks,
Kevin
arch/arm/mach-davinci/da850.c | 75
++--
arch/arm/mach-davinci/include/mach/da8xx.h |7 +++
2 files changed, 67 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 63916b9..78b5ae2 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -830,8 +830,7 @@ static void da850_set_async3_src(int pllnum)
* According to the TRM, minimum PLLM results in maximum power savings.
* The OPP definitions below should keep the PLLM as low as possible.
*
- * The output of the PLLM must be between 400 to 600 MHz.
- * This rules out prediv of anything but divide-by-one for 24Mhz OSC input.
+ * The output of the PLLM must be between 300 to 600 MHz.
*/
struct da850_opp {
unsigned intfreq; /* in KHz */
@@ -842,6 +841,33 @@ struct da850_opp {
unsigned intcvdd_max; /* in uV */
};
+static const struct da850_opp da850_opp_456 = {
+ .freq = 456000,
+ .prediv = 1,
+ .mult = 19,
+ .postdiv= 1,
+ .cvdd_min = 130,
+ .cvdd_max = 135,
+};
+
+static const struct da850_opp da850_opp_408 = {
+ .freq = 408000,
+ .prediv = 1,
+ .mult = 17,
+ .postdiv= 1,
+ .cvdd_min = 130,
+ .cvdd_max = 135,
+};
+
+static const struct da850_opp da850_opp_372 = {
+ .freq = 372000,
+ .prediv = 2,
+ .mult = 31,
+ .postdiv= 1,
+ .cvdd_min = 120,
+ .cvdd_max = 132,
+};
+
static const struct da850_opp da850_opp_300 = {
.freq = 30,
.prediv = 1,
@@ -876,6 +902,9 @@ static const struct da850_opp da850_opp_96 = {
}
static struct cpufreq_frequency_table da850_freq_table[] = {
+ OPP(456),
+ OPP(408),
+ OPP(372),
OPP(300),
OPP(200),
OPP(96),
@@ -886,6 +915,19 @@ static struct cpufreq_frequency_table da850_freq_table[]
= {
};
#ifdef CONFIG_REGULATOR
+static int da850_set_voltage(unsigned int index);
+static int da850_regulator_init(void);
+#endif
+
+static struct davinci_cpufreq_config cpufreq_info = {
+ .freq_table = da850_freq_table,
+#ifdef CONFIG_REGULATOR
+ .init = da850_regulator_init,
+ .set_voltage = da850_set_voltage,
+#endif
+};
+
+#ifdef CONFIG_REGULATOR
static struct regulator *cvdd;
static int da850_set_voltage(unsigned int index)
@@ -895,7 +937,7 @@ static int da850_set_voltage(unsigned int index)
if (!cvdd)
return -ENODEV;
- opp = (struct da850_opp *) da850_freq_table[index].index;
+ opp = (struct da850_opp *) cpufreq_info.freq_table[index].index;
return regulator_set_voltage(cvdd, opp-cvdd_min, opp-cvdd_max);
}
@@ -912,14 +954,6 @@ static int da850_regulator_init(void)
}
#endif
-static struct davinci_cpufreq_config cpufreq_info = {
- .freq_table = da850_freq_table[0],
-#ifdef CONFIG_REGULATOR
- .init = da850_regulator_init,
- .set_voltage = da850_set_voltage,
-#endif
-};
-
static struct platform_device da850_cpufreq_device = {
.name = cpufreq-davinci,
.dev = {
@@ -928,12 +962,22 @@ static struct platform_device da850_cpufreq_device = {
.id = -1,
};
+unsigned int da850_max_speed = 30;
+
int __init da850_register_cpufreq(char *async_clk)
{
+ int i;
+
/* cpufreq driver can help keep an async clock constant */
if (async_clk)
clk_add_alias(async, da850_cpufreq_device.name,
async_clk, NULL);
+ for (i = 0; i ARRAY_SIZE(da850_freq_table); i++) {
+ if (da850_freq_table[i].frequency =
Re: [PATCH v6 0/5] da850-evm: add gpio-{keys, leds} for UI and BB expanders
Hi Ben, Ben Gardiner bengardi...@nanometrics.ca writes: [...] One minor question: the series has a couple of Signed-off-by tags from Sekhar Nori. The s-o-b tag is for folks on the delivery path, and based on what I saw, these should probably be Acked-by tags from Sekhar, since he certainly helped on the review/test/validate side, but AFAICT, was not an author or on the delivery path. If I'm wrong on this (e.g., if Sekhar actually did author some of those patches) let me know, otherwise I'll change the s-o-b to Acked-by for Sekhar. The s-o-b 's for Sehkar are because I folded-in suggested changes submitted in review by Sehkar in the form of a patch. I 'think' this qualifies as authorship. I'll leave it to your good judgement. OK, thanks for clarification. I'll leave the s-o-b tags as is. 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 v7 01/12] misc: add driver for sequencer serial port
Cyril Chemparathy cy...@ti.com writes:
TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial
port
device. It has a built-in programmable execution engine that can be
programmed
to operate as almost any serial bus (I2C, SPI, EasyScale, and others).
This patch adds a driver for this controller device. The driver does not
expose a user-land interface. Protocol drivers built on top of this layer are
expected to remain in-kernel.
Signed-off-by: Cyril Chemparathy cy...@ti.com
Minor nit: subject still says 'misc', but this has now been moved to
mfd.
Kevin
---
drivers/mfd/Kconfig| 11 +
drivers/mfd/Makefile |1 +
drivers/mfd/ti-ssp.c | 476
include/linux/mfd/ti_ssp.h | 87
4 files changed, 575 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/ti-ssp.c
create mode 100644 include/linux/mfd/ti_ssp.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3a1493b..a4b4b70 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -81,6 +81,17 @@ config MFD_DM355EVM_MSP
boards. MSP430 firmware manages resets and power sequencing,
inputs from buttons and the IR remote, LEDs, an RTC, and more.
+config MFD_TI_SSP
+ tristate TI Sequencer Serial Port support
+ depends on ARCH_DAVINCI_TNETV107X
+ select MFD_CORE
+ ---help---
+ Say Y here if you want support for the Sequencer Serial Port
+ in a Texas Instruments TNETV107X SoC.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ti-ssp.
+
config HTC_EGPIO
bool HTC EGPIO support
depends on GENERIC_HARDIRQS GPIOLIB ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f54b365..f64cf13 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_HTC_I2CPLD)+= htc-i2cpld.o
obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o
obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
+obj-$(CONFIG_MFD_TI_SSP) += ti-ssp.o
obj-$(CONFIG_MFD_STMPE) += stmpe.o
obj-$(CONFIG_MFD_TC35892)+= tc35892.o
diff --git a/drivers/mfd/ti-ssp.c b/drivers/mfd/ti-ssp.c
new file mode 100644
index 000..af9ab0e
--- /dev/null
+++ b/drivers/mfd/ti-ssp.c
@@ -0,0 +1,476 @@
+/*
+ * Sequencer Serial Port (SSP) driver for Texas Instruments' SoCs
+ *
+ * Copyright (C) 2010 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/errno.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/init.h
+#include linux/wait.h
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/spinlock.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/mfd/core.h
+#include linux/mfd/ti_ssp.h
+
+/* Register Offsets */
+#define REG_REV 0x00
+#define REG_IOSEL_1 0x04
+#define REG_IOSEL_2 0x08
+#define REG_PREDIV 0x0c
+#define REG_INTR_ST 0x10
+#define REG_INTR_EN 0x14
+#define REG_TEST_CTRL0x18
+
+/* Per port registers */
+#define PORT_CFG_2 0x00
+#define PORT_ADDR0x04
+#define PORT_DATA0x08
+#define PORT_CFG_1 0x0c
+#define PORT_STATE 0x10
+
+#define SSP_PORT_CONFIG_MASK (SSP_EARLY_DIN | SSP_DELAY_DOUT)
+#define SSP_PORT_CLKRATE_MASK0x0f
+
+#define SSP_SEQRAM_WR_EN BIT(4)
+#define SSP_SEQRAM_RD_EN BIT(5)
+#define SSP_STARTBIT(15)
+#define SSP_BUSY BIT(10)
+#define SSP_PORT_ASL BIT(7)
+#define SSP_PORT_CFO1BIT(6)
+
+#define SSP_PORT_SEQRAM_SIZE 32
+
+static const int ssp_port_base[] = {0x040, 0x080};
+static const int ssp_port_seqram[] = {0x100, 0x180};
+
+struct ti_ssp {
+ struct resource *res;
+ struct device *dev;
+ void __iomem*regs;
+ spinlock_t lock;
+ struct clk *clk;
+ int irq;
+ wait_queue_head_t wqh;
+
+ /*
+ * Some of the iosel2 register bits always read-back as 0, we need to
+ * remember these
Re: [PATCH v7 00/12] tnetv107x ssp drivers
Cyril Chemparathy cy...@ti.com writes: TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial port device. It has a built-in programmable execution engine that can be programmed to operate as almost any serial bus (I2C, SPI, EasyScale, and others). OK, this series seems to be stabilizing. The question now is how to merge it. I'm happy to merge it as a single series via the davinci tree as long as I get some acks on the drivers. For me to merge this, I'm missing some acks for the following: [PATCH v7 04/12] spi: add ti-ssp spi master driver Grant Likely, although I thought he gave an ack earlier) [PATCH v7 10/12] backlight: add support for tps6116x controller Richard Purdie [PATCH v7 08/12] gpio: add ti-ssp gpio driver David Brownell? (MAINTAINERS isn't clear here) If I get acks soon, we can get this in for 2.6.38. Thanks, 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 1/2] da850: Support for TI's PRU SoftUART Emulation
Subhasish Ghosh ghosh.subhas...@gmail.com writes: The patch adds support for emulated UART controllers on the programmable realtime unit (PRU) available on OMAPL138. This defines the system resource requirements such as pin mux, clock, iomem, interrupt etc and registers the platform device as per the Linux driver model. Signed-off-by: Subhasish Ghosh subhas...@mistralsolutions.com You might consider setting your git user to use your Mistral address, so according to git, the author and the sign-off are the same person. Otherwise, git stats will report your personal address as the author and your company address as the signoff. Also, please Cc linux-arm-ker...@lists.infradead.org on all davinci kernel patches. Otherwise, this patch is looking ok (after addressing alignment issue reported by Sergei.) [...] diff --git a/arch/arm/mach-davinci/include/mach/memory.h b/arch/arm/mach-davinci/include/mach/memory.h index 22eb97c..d3e48d9 100644 --- a/arch/arm/mach-davinci/include/mach/memory.h +++ b/arch/arm/mach-davinci/include/mach/memory.h @@ -22,6 +22,7 @@ **/ #define DAVINCI_DDR_BASE 0x8000 #define DA8XX_DDR_BASE 0xc000 +#define DA8XX_SHARED_RAM_BASE0x8000 please align with previous defines #if defined(CONFIG_ARCH_DAVINCI_DA8XX) defined(CONFIG_ARCH_DAVINCI_DMx) #error Cannot enable DaVinci and DA8XX platforms concurrently diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index 212eb4c..407624e 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -199,6 +199,9 @@ /* TI OMAP-UART */ #define PORT_OMAP96 +/* omapl pru uart emulation */ +#define PORT_OMAPL_PRU_SUART 97 + This define is not used in this series. Please add it when you add the driver which uses it. 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 2/2] da850: board file modifications for PRU SUART.
Subhasish Ghosh ghosh.subhas...@gmail.com writes:
Missing descriptive changelog.
Kevin
Signed-off-by: Subhasish Ghosh subhas...@mistralsolutions.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 f89b0b7..86a89b1 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -736,6 +736,34 @@ static struct edma_rsv_info *da850_edma_rsv[2] = {
da850_edma_cc1_rsv,
};
+const short da850_evm_pru_suart_pins[] = {
+ DA850_AHCLKX, DA850_ACLKX, DA850_AFSX,
+ DA850_AHCLKR, DA850_ACLKR, DA850_AFSR,
+ DA850_AXR_13, DA850_AXR_9, DA850_AXR_7,
+ DA850_AXR_14, DA850_AXR_10, DA850_AXR_8,
+ -1
+};
+
+static int __init da850_evm_setup_pru_suart(void)
+{
+ int ret;
+
+ if (!machine_is_davinci_da850_evm())
+ return 0;
+
+ ret = davinci_cfg_reg_list(da850_evm_pru_suart_pins);
+ if (ret)
+ pr_warning(%s: da850_evm_pru_suart_pins
+ mux setup failed: %d\n, __func__, ret);
+ ret = da8xx_register_pru_suart();
+ if (ret)
+ pr_warning(%s: pru suart registration
+ failed: %d\n, __func__, ret);
+ return ret;
+}
+
+device_initcall(da850_evm_setup_pru_suart);
+
static __init void da850_evm_init(void)
{
int ret;
___
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] da850-evm, trivial: use da850_evm prefix for consistency
Nori, Sekhar nsek...@ti.com writes: On Sat, Nov 20, 2010 at 03:13:04, Ben Gardiner wrote: There was a single case of 'da850evm' prefix in the board-da850-evm.c file where the reset of the prefixes were 'da850_evm'; change it to 'da850_evm' for consistency. Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca --- @Sekhar, you asked me to prefix all the static symbols I added to board-da850-evm.c with 'da850evm' -- but I noticed that the current convention is a prefix of 'da850_evm' so I decided to stick with the convention and replace the only outlier with this patch. Thanks. I personally prefer da850evm, but consistency is more important so that a search-replace is possible later on. So I am okay with this too. I'll take that as an Ack. Applying, queuing for 2.6.38. 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 v2 2/4] da850-evm: add UI Expander pushbuttons
Nori, Sekhar nsek...@ti.com writes: Hi Ben, On Mon, Nov 22, 2010 at 19:20:48, Ben Gardiner wrote: On Mon, Nov 22, 2010 at 6:49 AM, Nori, Sekhar nsek...@ti.com wrote: On Fri, Nov 19, 2010 at 21:08:10, Ben Gardiner wrote: [...] By setting INPUT_POLLDEV default for the da850-evm users will get functioning pushbuttons and switches with the default config but they will be able to disable INPUT_POLLDEV or gpio-keys drivers in their defconfig at their convenience. I guess we could also just modify the defconfig to switch on INPUT_POLLDEV? Since only gpio-keys functionality is affected by not enabling the correct options in kernel, it should be OK. Yes -- only gpio-keys is affected but enabling the option does introduce an additional .o file: drivers/input/Makefile:obj-$(CONFIG_INPUT_POLLDEV) += input-polldev.o I agree that in its current state a user couls inadvertently disable the gpio-keys support on da850-evm simply by disabling INPUT_POLLDEV -- which is less than Ideal. How about I replace the current changes to arch/arm/mach-davinci/Kconfig with: config KEYBOARD_GPIO default MACH_DAVINCI_DA850_EVM select INPUT_POLLDEV So 1) gpio-keys functionality is default for the da850evm and 2) whenever gpio-keys is enabled so is INPUT_POLLDEV. This looks better than what was posted earlier, but I am not sure if platforms should influence driver configuration this way. Agreed. In general, we should not have machine/platform specific conditionals in generic Kconfigs. Generally, this should be handled in machine/platform specific Kconfigs. Kevin I guess I am just afraid that this makes a precedent for many driver config symbols to get replicated in the platform Kconfig files. Lets see if others have an opinion on this. Thanks, Sekhar ___ 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] da850-evm: allow pca953x module build
Ben Gardiner bengardi...@nanometrics.ca writes: Change the mach-davinci Kconfig file so that GPIO_PCA953X is default when MACH_DAVINCI_DA850_EVM is set instead of always selecting. This allows users to compile pca953x as a module. Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca CC: Sergei Shtylyov sshtyl...@mvista.com CC: Nori, Sekhar nsek...@ti.com Reviewed-by: Kevin Hilman khil...@deeprootsystems.com Applied, queuing for 2.6.38. Thanks, Kevin --- Changes since V3: * use default default MACH_DAVINCI_DA850_EVM without 'if' (Kevin Hilman) * rebased to df2e3886aeb6a93c602616d77c9a303ec202e69c of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git Changes since V2: * keep all Kconfig changes local to arch/arm/mach-davinci by exploting the fact that attribute assigment to config entries can span multiple files. * removing David Brownell since we don't need the wider scope in the changes Changes since V1: * make PCA953x default when MACH_DAVINCI_DA850_EVM in drivers/gpio/Kconfig instead of selecting GPIO_PCA953X when MACH_DAVINCI_DA850_EVM in arc/arm/mach-davinci/Kconfig * adding David Brownell because I think he is the pca953x goto guy Note that since NAND/NOR setup is performed in the pcs953x setup() function of board-da850-evm.c, when building pca953x as a module it will need to be insmod'ed from early userspace (i.e. initrd) to use a NAND or NOR rootfs for the system. The following commands and their output illustrate the the changes do allow the build of pca953x.c as a module. $cat arch/arm/configs/da8xx_omapl_defconfig|grep -i GPIO_PCA953X;\ make mrproper; make da8xx_omapl_defconfig ;\ cat .config |grep -i GPIO_PCA953X ; sed -ie 's/GPIO_PCA953X=y//g' .config;\ cat .config |grep -i GPIO_PCA953X; make oldconfig CLEAN scripts/basic CLEAN scripts/kconfig CLEAN include/config CLEAN .config HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc scripts/basic/docproc.c: In function ‘docsect’: scripts/basic/docproc.c:336: warning: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result HOSTCC scripts/basic/hash HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf CONFIG_GPIO_PCA953X=y scripts/kconfig/conf --oldconfig arch/arm/Kconfig * * Restart config... * * * GPIO Support * GPIO Support (GPIOLIB) [Y/?] y Debug GPIO calls (DEBUG_GPIO) [N/y/?] n /sys/class/gpio/... (sysfs interface) (GPIO_SYSFS) [N/y/?] n * * Memory mapped GPIO expanders: * IT8761E GPIO support (GPIO_IT8761E) [N/m/y/?] n * * I2C GPIO expanders: * Maxim MAX7300 GPIO expander (GPIO_MAX7300) [N/m/y/?] n MAX7319, MAX7320-7327 I2C Port Expanders (GPIO_MAX732X) [N/m/y/?] n PCA953x, PCA955x, TCA64xx, and MAX7310 I/O ports (GPIO_PCA953X) [Y/n/m/?] (NEW) fixup pca953x module build --- arch/arm/mach-davinci/Kconfig |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig index b77b860..84066e8 100644 --- a/arch/arm/mach-davinci/Kconfig +++ b/arch/arm/mach-davinci/Kconfig @@ -148,7 +148,6 @@ config MACH_DAVINCI_DA850_EVM bool TI DA850/OMAP-L138/AM18x Reference Platform default ARCH_DAVINCI_DA850 depends on ARCH_DAVINCI_DA850 - select GPIO_PCA953X help Say Y here to select the TI DA850/OMAP-L138/AM18x Evaluation Module. @@ -178,6 +177,9 @@ config DA850_UI_RMII endchoice +config GPIO_PCA953X + default MACH_DAVINCI_DA850_EVM + config MACH_TNETV107X bool TI TNETV107X Reference Platform default ARCH_DAVINCI_TNETV107X ___ 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: kconfig: select at24 eeprom for selected boards
Ensure that the at24 eeprom driver is selected for certain boards that need boot data (e.g. MAC address) from EEPROM. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-davinci/Kconfig | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig index 84066e8..77671b7 100644 --- a/arch/arm/mach-davinci/Kconfig +++ b/arch/arm/mach-davinci/Kconfig @@ -61,6 +61,8 @@ config MACH_DAVINCI_EVM bool TI DM644x EVM default ARCH_DAVINCI_DM644x depends on ARCH_DAVINCI_DM644x + select MISC_DEVICES + select EEPROM_AT24 help Configure this option to specify the whether the board used for development is a DM644x EVM @@ -68,6 +70,8 @@ config MACH_DAVINCI_EVM config MACH_SFFSDR bool Lyrtech SFFSDR depends on ARCH_DAVINCI_DM644x + select MISC_DEVICES + select EEPROM_AT24 help Say Y here to select the Lyrtech Small Form Factor Software Defined Radio (SFFSDR) board. @@ -99,6 +103,8 @@ config MACH_DAVINCI_DM6467_EVM default ARCH_DAVINCI_DM646x depends on ARCH_DAVINCI_DM646x select MACH_DAVINCI_DM6467TEVM + select MISC_DEVICES + select EEPROM_AT24 help Configure this option to specify the whether the board used for development is a DM6467 EVM @@ -110,6 +116,8 @@ config MACH_DAVINCI_DM365_EVM bool TI DM365 EVM default ARCH_DAVINCI_DM365 depends on ARCH_DAVINCI_DM365 + select MISC_DEVICES + select EEPROM_AT24 help Configure this option to specify whether the board used for development is a DM365 EVM @@ -119,6 +127,8 @@ config MACH_DAVINCI_DA830_EVM default ARCH_DAVINCI_DA830 depends on ARCH_DAVINCI_DA830 select GPIO_PCF857X + select MISC_DEVICES + select EEPROM_AT24 help Say Y here to select the TI DA830/OMAP-L137/AM17x Evaluation Module. @@ -190,6 +200,8 @@ config MACH_TNETV107X config MACH_MITYOMAPL138 bool Critical Link MityDSP-L138/MityARM-1808 SoM depends on ARCH_DAVINCI_DA850 + select MISC_DEVICES + select EEPROM_AT24 help Say Y here to select the Critical Link MityDSP-L138/MityARM-1808 System on Module. Information on this SoM may be found at -- 1.7.2.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 v8 4/9] davinci: McASP configuration for Omapl138-Hawkboard
Nori, Sekhar nsek...@ti.com writes: Hi Michael, On Wed, Nov 17, 2010 at 02:12:53, Michael Williamson wrote: Help me out. Why do we need generic pin lists? They might help in cases where all boards will use the same set of pins. For example, every one who uses I2C will most likely both the clock and data pins from the IP. For more complex peripherals with different pins options they serve a documentation purpose at best. It seems to me that the generic pin list for da850.c isn't practical for most (if not all) of the peripherals. They should be done using __initdata in each board file. Yes, agreed. Just a cursory glance at what's in da850.c highlights several items being set up for the EVM and not generically. For example: - da850_uart1_pins and da850_uart2_pins: I believe both have RTS/CTS pins which for a generic definition should be included as for UART0, but would then be unused as the EVM doesn't use these pins in this function. Yes, the generic pin list should have RTS and CTS pins defined for UART1 and UART2. This needs fixing. - da850_mcasp_pins: if generic, must include all 16 AXR pins. I think you'd be hard pressed to find a board configuration that would use all 16 AXR pins for the McASP. I'm fairly sure the EVM uses the pins called out, and uses other pins for other functions. So it's likely this structure wouldn't get used. Yes, the generic pin list should either be completed or removed altogether and the existing pin list da850_mcasp_pins should be copied into the board file and called da850_evm_mcasp_pins. - da850_mmcsd0_pins : includes 2 GPIO pins (specific to the EVM, though possible for other boards) for the card detect and write protect signals. These pins are completely arbitrary for that particular board design. I also believe that the complete mmcsd0 port has 4 more data lines as part of it's peripheral, although the driver doesn't support using them. This is incorrect again. The generic pin list should be completed (or removed) and the existing list should be copied into the EVM board file as da850_evm_mmcsd0_pins. - da850_emif25_pins interface doesn't include the generic pins for some of the SDRAM functions. Yes, this should be completed (or removed). This list is unused anyway. - da850_cpgmac_pins defines both RMII and MII pins. I don't think any board would want to configure both sets at the same time. Seems like this should never get used... Agreed. It's also incomplete. What about the uPP pin list? Or the VPIF? Etc. These should be added as the drivers for these devices are supported. I think a board file author should be familiar enough with the SoC to understand what peripheral pins he should be configuring for his/her particular hardware setup and explicitly specify them in the board file. Agree. If you remove the common pin-mux lists and move them to a board file, then once you configure your specific platform, is there any more memory used than with the common scheme? Of course, there would be replication of pin-mux code in the board There is no memory wastage. All the pin lists are init data. I too prefer all generic pin lists which are most likely not going to be used at all to be removed. Unused stuff like this will only make code difficult to read. FWIW, I agree. Now, who wants to tackle it? 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 v2] da850-evm: UI expander gpio_set_value can sleep, use _cansleep
Ben Gardiner bengardi...@nanometrics.ca writes:
When the RMII PHY on the UI board is enabled with CONFIG_DA850_UI_RMII then
then
following will be printed to the console when warnings are also enabled:
WARNING: at drivers/gpio/gpiolib.c:1567 __gpio_set_value+0x4c/0x5c()
Modules linked in:
[c002c6ac] (unwind_backtrace+0x0/0xf8) from [c003b48c]
(warn_slowpath_common+0x4c/0x64)
[c003b48c] (warn_slowpath_common+0x4c/0x64) from [c003b4c0]
(warn_slowpath_null+0x1c/0x24)
[c003b4c0] (warn_slowpath_null+0x1c/0x24) from [c01aed60]
(__gpio_set_value+0x4c/0x5c)
[c01aed60] (__gpio_set_value+0x4c/0x5c) from [c0033bd4]
(da850_evm_ui_expander_setup+0x1e4/0x2
44)
[c0033bd4] (da850_evm_ui_expander_setup+0x1e4/0x244) from [c02e2e1c]
(pca953x_probe+0x1f8/0x29
0)
snip
Traced the WARN_ON to the gpio_set_value(rmii_sel,0) call in
da850_evm_setup_emac_rmii. Replacing the call with the _cansleep variant
results in no more warning. Also replacing the gpio_set_value calls in the
teardown function.
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
Reviewed-by: Chris Cordahi christophercord...@nanometrics.ca
Reviewed-by: Kevin Killman khil...@deeprootsystems.com
s/Killman/Hilman/ with only one 'L'
Other than that, looks good. And thanks for the detailed description on
how this was tested.
Applying and queuing for 2.6.38.
Kevin
--
Tested by modifying the config to allow pca953x as a module and modifying the
board setup to forcibly run the NAND/NOR setup because I am using a UBIFS
rootfs in NAND w/o initrd (yet) then inspecting the kernel output after
'insmod pca953x.ko' and 'rmmod -f pca953x.ko'; with this patch there are no
WARNINGs printed.
Changes since V1:
* added _cansleep variant calls to the teardown() function, suggested by
Kevin Hillman.
* changed patch subject line as per Kevin Hillman's suggestion.
---
arch/arm/mach-davinci/board-da850-evm.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index c6e11c6..f89b0b7 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -266,7 +266,7 @@ static inline void da850_evm_setup_emac_rmii(int rmii_sel)
struct davinci_soc_info *soc_info = davinci_soc_info;
soc_info-emac_pdata-rmii_en = 1;
- gpio_set_value(rmii_sel, 0);
+ gpio_set_value_cansleep(rmii_sel, 0);
}
#else
static inline void da850_evm_setup_emac_rmii(int rmii_sel) { }
@@ -325,9 +325,9 @@ static int da850_evm_ui_expander_teardown(struct
i2c_client *client,
unsigned gpio, unsigned ngpio, void *c)
{
/* deselect all functionalities */
- gpio_set_value(gpio + 5, 1);
- gpio_set_value(gpio + 6, 1);
- gpio_set_value(gpio + 7, 1);
+ gpio_set_value_cansleep(gpio + 5, 1);
+ gpio_set_value_cansleep(gpio + 6, 1);
+ gpio_set_value_cansleep(gpio + 7, 1);
gpio_free(gpio + 5);
gpio_free(gpio + 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 v3] da850-evm: allow pca953x module build
Ben Gardiner bengardi...@nanometrics.ca writes: Change the mach-davinci Kconfig file so that GPIO_PCA953X is default when MACH_DAVINCI_DA850_EVM is set instead of always selecting. This allows users to compile pca953x as a module. Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca CC: Sergei Shtylyov sshtyl...@mvista.com CC: Nori, Sekhar nsek...@ti.com --- Changes since V2: * keep all Kconfig changes local to arch/arm/mach-davinci by exploting the fact that attribute assigment to config entries can span multiple files. This is a neat trick, I wasn't aware of this either. [...] +config GPIO_PCA953X + default y if MACH_DAVINCI_DA850_EVM + the 'y' part is redundant. You can just do: default MACH_DAVINCI_DA850_EVM 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] mach-davinci: signedness bug
Nori, Sekhar nsek...@ti.com writes: Hi Nicolas, On Tue, Nov 16, 2010 at 00:10:28, Nicolas Kaiser wrote: aemif_calc_rate() can return a negative error value, so all the variables that get tested for this value need to be signed. The maximum bit width of WSETUP(WSETUP_MAX) appears to be 30 bits (0xf 26). Using a signed instead of an unsigned integer shouldn't make a difference here. Signed-off-by: Nicolas Kaiser ni...@nikai.net Thanks for the fix. You could use the subject: davinci: signedness bug in davinci_aemif_setup_timing() Other than that: Acked-by: Sekhar Nori nsek...@ti.com Thanks, I fixed up the subject as Sekhar suggested. Applied, queuing for 2.6.38. 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] davinci: simplify if-statement
Nicolas Kaiser ni...@nikai.net writes:
A common do-while loop can be factored out from the end of
the branches.
Signed-off-by: Nicolas Kaiser ni...@nikai.net
Applied, queueing for 2.6.38.
Kevin
---
arch/arm/mach-davinci/psc.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-davinci/psc.c b/arch/arm/mach-davinci/psc.c
index 1b15dbd..a415804 100644
--- a/arch/arm/mach-davinci/psc.c
+++ b/arch/arm/mach-davinci/psc.c
@@ -83,21 +83,16 @@ void davinci_psc_config(unsigned int domain, unsigned int
ctlr,
pdctl1 = __raw_readl(psc_base + PDCTL1);
pdctl1 |= 0x100;
__raw_writel(pdctl1, psc_base + PDCTL1);
-
- do {
- ptstat = __raw_readl(psc_base +
-PTSTAT);
- } while (!(((ptstat domain) 1) == 0));
} else {
ptcmd = 1 domain;
__raw_writel(ptcmd, psc_base + PTCMD);
-
- do {
- ptstat = __raw_readl(psc_base + PTSTAT);
- } while (!(((ptstat domain) 1) == 0));
}
do {
+ ptstat = __raw_readl(psc_base + PTSTAT);
+ } while (!(((ptstat domain) 1) == 0));
+
+ do {
mdstat = __raw_readl(psc_base + MDSTAT + 4 * id);
} while (!((mdstat MDSTAT_STATE_MASK) == next_state));
___
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 v7 3/9] davinci: ASoC support for Omapl138-Hawkboard
vm.ro...@gmail.com writes:
From: Victor Rodriguez victor.rodrig...@sasken.com
This patch adds ASoC support for the Hawkboard-L138 system
Signed-off-by: Victor Rodriguez victor.rodrig...@sasken.com
I believe Mark Brown ack'd and earlier version of this patch.
When you repost the series, you should collect any acks, sign-offs,
tested-by etc. tags that others have reported.
Mark, I assume you're OK with me merging this ASoC change via the
davinci tree?
Kevin
---
sound/soc/davinci/Kconfig |5 +++--
sound/soc/davinci/davinci-evm.c |6 --
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index 6bbf001..72c6752 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -76,8 +76,9 @@ config SND_DA830_SOC_EVM
DA830/OMAP-L137 EVM
config SND_DA850_SOC_EVM
- tristate SoC Audio support for DA850/OMAP-L138 EVM
- depends on SND_DAVINCI_SOC MACH_DAVINCI_DA850_EVM
+ tristate SoC Audio support for DA850/OMAP-L138 EVM/Hawkboard
+ depends on SND_DAVINCI_SOC (MACH_DAVINCI_DA850_EVM || \
+ MACH_OMAPL138_HAWKBOARD)
select SND_DAVINCI_SOC_MCASP
select SND_SOC_TLV320AIC3X
help
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 97f74d6..73093eb 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -59,7 +59,8 @@ static int evm_hw_params(struct snd_pcm_substream
*substream,
sysclk = 12288000;
else if (machine_is_davinci_da830_evm() ||
- machine_is_davinci_da850_evm())
+ machine_is_davinci_da850_evm() ||
+ machine_is_omapl138_hawkboard())
sysclk = 24576000;
else
@@ -311,7 +312,8 @@ static int __init evm_init(void)
} else if (machine_is_davinci_da830_evm()) {
evm_snd_dev_data = da830_evm_snd_devdata;
index = 1;
- } else if (machine_is_davinci_da850_evm()) {
+ } else if (machine_is_davinci_da850_evm() ||
+ machine_is_omapl138_hawkboard()) {
evm_snd_dev_data = da850_evm_snd_devdata;
index = 0;
} else
___
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 v7 3/9] davinci: ASoC support for Omapl138-Hawkboard
Victor Rodriguez vm.ro...@gmail.com writes: On Fri, Nov 12, 2010 at 10:23 AM, Kevin Hilman khil...@deeprootsystems.com wrote: vm.ro...@gmail.com writes: From: Victor Rodriguez victor.rodrig...@sasken.com This patch adds ASoC support for the Hawkboard-L138 system Signed-off-by: Victor Rodriguez victor.rodrig...@sasken.com I believe Mark Brown ack'd and earlier version of this patch. When you repost the series, you should collect any acks, sign-offs, tested-by etc. tags that others have reported. Mark, I assume you're OK with me merging this ASoC change via the davinci tree? Kevin Sorry for that Would you like that I resend the patches again with all the acks , sign offs and tested by tags ? Yes please. Thanks, 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 v3 00/12] tnetv107x ssp driver stack
Cyril Chemparathy cy...@ti.com writes: TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial port device. It has a built-in programmable execution engine that can be programmed to operate as almost any serial bus (I2C, SPI, EasyScale, and others). Andrew, looking for some advice here... This is a piece of davinci hardware, but introduces drivers in various subsystems. I'm willing to merge this series via the davinci tree after getting acks from the various subsystem maintainers. Is this an OK approach? It seems best to me to merge this all together. We already have acks for the regulator and gpio driver parts, and the backlight driver has a clear owner in MAINTAINERS. However, who should be doing the final review/ack of the drivers/misc and drivers/gpio changes is less clear to me. Any advice appreciated, Thanks, Kevin arch/arm/mach-davinci/board-tnetv107x-evm.c| 199 +++ arch/arm/mach-davinci/devices-tnetv107x.c | 25 + arch/arm/mach-davinci/include/mach/ti_ssp.h| 98 arch/arm/mach-davinci/include/mach/tnetv107x.h |2 + arch/arm/mach-davinci/tnetv107x.c |2 +- drivers/gpio/Kconfig | 10 + drivers/gpio/Makefile |1 + drivers/gpio/ti-ssp-gpio.c | 200 +++ drivers/misc/Kconfig | 11 + drivers/misc/Makefile |1 + drivers/misc/ti_ssp.c | 436 +++ drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile |1 + drivers/regulator/tps6524x-regulator.c | 692 drivers/spi/Kconfig|7 + drivers/spi/Makefile |1 + drivers/spi/spi_ti_ssp.c | 397 ++ drivers/video/backlight/Kconfig|7 + drivers/video/backlight/Makefile |2 +- drivers/video/backlight/tps6116x.c | 340 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] davinci updates for 2.6.37
Linus, Please pull davinci platform updates for 2.6.37: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-for-linus Note that I also merged Russell King's devel branch (which you already merged) in order to fixup some final conflicts. diffstat/shortlog follows for just the davinci specific parts. Thanks, Kevin MAINTAINERS |4 +- arch/arm/configs/da8xx_omapl_defconfig |3 + arch/arm/mach-davinci/Kconfig | 76 +- arch/arm/mach-davinci/Makefile |4 +- arch/arm/mach-davinci/aemif.c | 133 +++ arch/arm/mach-davinci/board-da830-evm.c | 24 +- arch/arm/mach-davinci/board-da850-evm.c | 92 ++- arch/arm/mach-davinci/board-dm365-evm.c | 11 +- arch/arm/mach-davinci/board-dm644x-evm.c| 20 +- arch/arm/mach-davinci/board-dm646x-evm.c| 21 +- arch/arm/mach-davinci/board-mityomapl138.c | 424 +++ arch/arm/mach-davinci/board-neuros-osd2.c |7 +- arch/arm/mach-davinci/board-omapl138-hawk.c | 64 ++ arch/arm/mach-davinci/board-sffsdr.c|7 +- arch/arm/mach-davinci/board-tnetv107x-evm.c | 56 + arch/arm/mach-davinci/clock.c | 75 ++- arch/arm/mach-davinci/clock.h |5 + arch/arm/mach-davinci/cpufreq.c | 28 +- arch/arm/mach-davinci/da850.c | 76 +- arch/arm/mach-davinci/devices-da8xx.c | 70 ++- arch/arm/mach-davinci/devices-tnetv107x.c | 50 + arch/arm/mach-davinci/devices.c |2 +- arch/arm/mach-davinci/dm365.c | 23 +- arch/arm/mach-davinci/dm644x.c | 23 +- arch/arm/mach-davinci/dm646x.c | 22 +- arch/arm/mach-davinci/dma.c |8 +- arch/arm/mach-davinci/include/mach/aemif.h | 36 + arch/arm/mach-davinci/include/mach/da8xx.h |7 +- arch/arm/mach-davinci/include/mach/dm365.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- arch/arm/mach-davinci/include/mach/dm646x.h |2 +- arch/arm/mach-davinci/include/mach/nand.h |6 +- arch/arm/mach-davinci/include/mach/psc.h|1 + arch/arm/mach-davinci/include/mach/tnetv107x.h |3 + arch/arm/mach-davinci/include/mach/uncompress.h |2 + arch/arm/mach-davinci/tnetv107x.c | 11 +- arch/arm/mach-omap2/board-am3517evm.c | 31 +- drivers/input/keyboard/Kconfig |9 + drivers/input/keyboard/Makefile |1 + drivers/input/keyboard/tnetv107x-keypad.c | 340 ++ drivers/input/touchscreen/Kconfig |9 + drivers/input/touchscreen/Makefile |1 + drivers/input/touchscreen/tnetv107x-ts.c| 396 +++ drivers/mtd/nand/davinci_nand.c | 61 +- drivers/net/Kconfig | 21 + drivers/net/Makefile|2 + drivers/net/davinci_cpdma.c | 965 drivers/net/davinci_cpdma.h | 108 ++ drivers/net/davinci_emac.c | 1338 +++ drivers/net/davinci_mdio.c | 475 include/linux/davinci_emac.h| 16 +- 51 files changed, 3814 insertions(+), 1359 deletions(-) Cyril Chemparathy (17): Davinci: tnetv107x: retain psc reg base after init davinci: add idcode for tnetv107x rev 1.1/1.2 net: davinci_emac: separate out davinci mdio davinci: add mdio platform devices omap: add mdio platform devices net: davinci_emac: switch to new mdio davinci: cleanup mdio arch code and switch to phy_id omap: cleanup unused davinci mdio arch code net: davinci_emac: cleanup unused mdio emac code net: davinci_emac: separate out cpdma code net: davinci_emac: switch to new cpdma layer net: davinci_emac: cleanup unused cpdma code input: add driver for tnetv107x on-chip keypad controller davinci: add tnetv107x keypad platform device davinci: add keypad config for tnetv107x evm board input: add driver for tnetv107x touchscreen controller davinci: add tnetv107x touchscreen platform device Juha Kuikka (3): DA850: Add LPSC id for MMCSD1 peripheral DA850: Split MMCSD clock into two to support both MMCSD peripherals DA850: Add MMCSD1 resources, platform device and convenience registration function Kevin Hilman (1): davinci: clock: make 'disable unused clocks' printk debug only Kulikov Vasiliy (1): arm: mach-davinci: check irq2ctlr() result Michael Williamson (5): davinci: Add machine checks to DA8XX serial console init routines davinci: Add CONFIG_REGULATOR_DUMMY to DA8XX defconfig file. davinci: Initial support for MityDSP-L138/MityARM-1808
Re: [PATCH v2 00/12] tnetv107x ssp driver stack
Cyril Chemparathy cy...@ti.com writes: TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial port device. It has a built-in programmable execution engine that can be programmed to operate as almost any serial bus (I2C, SPI, EasyScale, and others). Hi Cyril, Can you do one more posting, including the acks from the subsystem maintainers so far, and posting also to LKML and linux-arm-ker...@lists.infradead.org. Also the backlight driver needs a review/ack from Richard Purdie (search for drivers/video/backlight in MAINTAINERS). With acks from all the subsystem maintainers, I think it makes sense to merge all of these together via the davinci tree. At the moment, I'm not sure who the final authority on the drivers/misc stuff is, but I will ask in response to your updated posting. Thanks, Kevin This patch series implements a driver stack that looks like the following: ++ | eeprom | . . . ++ +---+ +--+ +-+ | regulator | . . . | i2c-gpio | | 1-wire | . . . +---+ +--+ +-+ +--+ ++ | ssp-spi| | ssp-gpio | +--+ ++ +--+ |ssp | +--+ Changes between v1 and v2 of this series: - Replaced open()/close() semantics with dynamic platform_device registration on SSP probe. - Removed user-land interface to regulator registers - More sensible regulator constraints - Other minor cleanups Cyril Chemparathy (12): misc: add driver for sequencer serial port davinci: add tnetv107x ssp platform device davinci: add ssp config for tnetv107x evm board spi: add ti-ssp spi master driver davinci: add spi devices on tnetv107x evm regulator: add driver for tps6524x regulator davinci: add tnetv107x evm regulators gpio: add ti-ssp virtual gpio driver davinci: add tnetv107x evm ti-ssp gpio device backlight: add support for tps6116x controller davinci: add tnetv107x evm backlight device davinci: add tnetv107x evm i2c eeprom device arch/arm/mach-davinci/board-tnetv107x-evm.c| 199 +++ arch/arm/mach-davinci/devices-tnetv107x.c | 25 + arch/arm/mach-davinci/include/mach/ti_ssp.h| 99 arch/arm/mach-davinci/include/mach/tnetv107x.h |2 + arch/arm/mach-davinci/tnetv107x.c |2 +- drivers/gpio/Kconfig | 10 + drivers/gpio/Makefile |1 + drivers/gpio/ti-ssp-gpio.c | 200 +++ drivers/misc/Kconfig | 11 + drivers/misc/Makefile |1 + drivers/misc/ti_ssp.c | 436 +++ drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile |1 + drivers/regulator/tps6524x-regulator.c | 692 drivers/spi/Kconfig|6 + drivers/spi/Makefile |1 + drivers/spi/spi_ti_ssp.c | 397 ++ drivers/video/backlight/Kconfig|7 + drivers/video/backlight/Makefile |2 +- drivers/video/backlight/tps6116x.c | 340 20 files changed, 2440 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-davinci/include/mach/ti_ssp.h create mode 100644 drivers/gpio/ti-ssp-gpio.c create mode 100644 drivers/misc/ti_ssp.c create mode 100644 drivers/regulator/tps6524x-regulator.c create mode 100644 drivers/spi/spi_ti_ssp.c create mode 100644 drivers/video/backlight/tps6116x.c ___ 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: How to reply a tested by for a patch
Rene Gonzalez renegs.2...@gmail.com writes: Hi all, I'm very new in kernel stuffs so; I have applied a set of patches for a hawkboard-L138 and I wonder if there is specific format for reply a tested by. Should I add comments about the way I tested or just I reply it by adding a tested by headline? First, thanks for doing the testing and reporting your results. It is much appreciated. In the future, when testing whole series, you can just reply to the 'PATCH 0/x' introduction with your Tested-by: and some brief details on how/what you tested. Thanks, 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 0/2] davinci: clock control fixes
Cyril Chemparathy cy...@ti.com writes: This series applies a few fixes necessary to get tnetv107x hardware functioning properly. A summary of these fixes follow: - davinci: fix sysclk rate setting code to allow for larger divider values - tnetv107x: reparent tnetv107x usb clocks to usbss - tnetv107x: mark timer1 as always enabled - tnetv107x: enable set_rate on pll divider output clocks - tnetv107x: fix invalid reset defaults on tsc sysclk divider Applied, and queuing for 2.6.38. Thanks, Kevin Cyril Chemparathy (2): davinci: use divide ratio limits from pll_data davinci: minor tnetv107x clock tree fixes arch/arm/mach-davinci/clock.c |4 ++-- arch/arm/mach-davinci/devices-tnetv107x.c | 15 ++- arch/arm/mach-davinci/tnetv107x.c | 23 --- 3 files changed, 28 insertions(+), 14 deletions(-) ___ 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] i2c: davinci: Fix TX setup for more SoCs
Ben,
Jon Povey jon.po...@racelogic.co.uk writes:
This patch is an improvement to 4bba0fd8d1c6d405df666e2573e1a1f917098be0
which got to mainline a little early.
Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode
settings before DXR for correct behaviour, so load MDR first with
STT cleared and later load again with STT set.
Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985
Signed-off-by: Jon Povey jon.po...@racelogic.co.uk
Acked-by: Troy Kisky troy.ki...@boundarydevices.com
Tested-by: Sudhakar Rajashekhara sudhakar@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
This patches to what was v4 of the original patch.
The original patch which made it to 2.6.36-rc7 will as I understand it have
introduced a regression for OMAP-L138 so this patch is a regression fix and
wants to get into 2.6.36.
can you get this one into 2.6.36 please?
Thanks,
Kevin
drivers/i2c/busses/i2c-davinci.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index b8feac5..5795c83 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -331,21 +331,16 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
INIT_COMPLETION(dev-cmd_complete);
dev-cmd_err = 0;
- /* Take I2C out of reset, configure it as master and set the
- * start bit */
- flag = DAVINCI_I2C_MDR_IRS | DAVINCI_I2C_MDR_MST | DAVINCI_I2C_MDR_STT;
+ /* Take I2C out of reset and configure it as master */
+ flag = DAVINCI_I2C_MDR_IRS | DAVINCI_I2C_MDR_MST;
/* if the slave address is ten bit address, enable XA bit */
if (msg-flags I2C_M_TEN)
flag |= DAVINCI_I2C_MDR_XA;
if (!(msg-flags I2C_M_RD))
flag |= DAVINCI_I2C_MDR_TRX;
- if (stop)
- flag |= DAVINCI_I2C_MDR_STP;
- if (msg-len == 0) {
+ if (msg-len == 0)
flag |= DAVINCI_I2C_MDR_RM;
- flag = ~DAVINCI_I2C_MDR_STP;
- }
/* Enable receive or transmit interrupts */
w = davinci_i2c_read_reg(dev, DAVINCI_I2C_IMR_REG);
@@ -358,17 +353,28 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
dev-terminate = 0;
/*
+ * Write mode register first as needed for correct behaviour
+ * on OMAP-L138, but don't set STT yet to avoid a race with XRDY
+ * occuring before we have loaded DXR
+ */
+ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
+
+ /*
* First byte should be set here, not after interrupt,
* because transmit-data-ready interrupt can come before
* NACK-interrupt during sending of previous message and
* ICDXR may have wrong data
+ * It also saves us one interrupt, slightly faster
*/
if ((!(msg-flags I2C_M_RD)) dev-buf_len) {
davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev-buf++);
dev-buf_len--;
}
- /* write the data into mode register; start transmitting */
+ /* Set STT to begin transmit now DXR is loaded */
+ flag |= DAVINCI_I2C_MDR_STT;
+ if (stop msg-len != 0)
+ flag |= DAVINCI_I2C_MDR_STP;
davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag);
r = wait_for_completion_interruptible_timeout(dev-cmd_complete,
___
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: mityomapl138: make file local data static
Sekhar Nori nsek...@ti.com writes:
Most of the regulator data structures are local to the
board file, but not made static. Fix this.
Also make the nand partition table static.
This gets rid of all the sparse warnings for this file.
Signed-off-by: Sekhar Nori nsek...@ti.com
Thanks, applied.
Kevin
---
arch/arm/mach-davinci/board-mityomapl138.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c
b/arch/arm/mach-davinci/board-mityomapl138.c
index 65f7501..194a15f 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -93,14 +93,14 @@ static struct davinci_i2c_platform_data
mityomap_i2c_0_pdata = {
/* TPS65023 voltage regulator support */
/* 1.2V Core */
-struct regulator_consumer_supply tps65023_dcdc1_consumers[] = {
+static struct regulator_consumer_supply tps65023_dcdc1_consumers[] = {
{
.supply = cvdd,
},
};
/* 1.8V */
-struct regulator_consumer_supply tps65023_dcdc2_consumers[] = {
+static struct regulator_consumer_supply tps65023_dcdc2_consumers[] = {
{
.supply = usb0_vdda18,
},
@@ -116,7 +116,7 @@ struct regulator_consumer_supply
tps65023_dcdc2_consumers[] = {
};
/* 1.2V */
-struct regulator_consumer_supply tps65023_dcdc3_consumers[] = {
+static struct regulator_consumer_supply tps65023_dcdc3_consumers[] = {
{
.supply = sata_vdd,
},
@@ -132,20 +132,20 @@ struct regulator_consumer_supply
tps65023_dcdc3_consumers[] = {
};
/* 1.8V Aux LDO, not used */
-struct regulator_consumer_supply tps65023_ldo1_consumers[] = {
+static struct regulator_consumer_supply tps65023_ldo1_consumers[] = {
{
.supply = 1.8v_aux,
},
};
/* FPGA VCC Aux (2.5 or 3.3) LDO */
-struct regulator_consumer_supply tps65023_ldo2_consumers[] = {
+static struct regulator_consumer_supply tps65023_ldo2_consumers[] = {
{
.supply = vccaux,
},
};
-struct regulator_init_data tps65023_regulator_data[] = {
+static struct regulator_init_data tps65023_regulator_data[] = {
/* dcdc1 */
{
.constraints = {
@@ -226,7 +226,7 @@ static int __init pmic_tps65023_init(void)
* MityDSP-L138 includes a 256 MByte large-page NAND flash
* (128K blocks).
*/
-struct mtd_partition mityomapl138_nandflash_partition[] = {
+static struct mtd_partition mityomapl138_nandflash_partition[] = {
{
.name = rootfs,
.offset = 0,
___
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 0/6] Add Omapl138-Hawkboard support
vm.ro...@gmail.com writes: From: Victor Rodriguez victor.rodrig...@sasken.com This patch adds EMAC, EDMA, ASoC, SOUND, MMC/SD and USB OHCI support for the Hawkboard-L138 system It is under the machine name omapl138_hawkboard. This system is based on the da850 davinci CPU architecture. Please remove these 2 sentences from all the changelogs. In addition to Sergei's comments, which I completely agree with, I have some general comments: When you cut and paste from other board files, please also update the comments. I see at least a couple places where comments in this code refers to the EVM. Also, since I don't have a hawkboard, before merging, it would be nice to see some more folks that have these boards test the various features in this series and reply with their 'Tested-by' Kevin Victor Rodriguez (6): davinci: EMAC support for Omapl138-Hawkboard davinci: EDMA support for Omapl138-Hawkboard ASoC: davinci: ASoC support for Omapl138-Hawkboard davinci: SOUND support for Omapl138-Hawkboard davinci: MMC/SD support for Omapl138-Hawkboard davinci: USB-OHCI support for Omapl138-Hawkboard arch/arm/mach-davinci/board-omapl138-hawk.c | 294 +++ arch/arm/mach-davinci/da850.c | 21 ++- arch/arm/mach-davinci/include/mach/mux.h|2 + sound/soc/davinci/Kconfig |5 +- sound/soc/davinci/davinci-evm.c |6 +- 5 files changed, 323 insertions(+), 5 deletions(-) ___ 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] davinci: Implement sched_clock()
Sergei Shtylyov sshtyl...@mvista.com writes: Hello. On 07-10-2010 21:12, Kevin Hilman wrote: Overwrite the default implementation of sched_clock that is based on jiffies by something more precise. This improves timestamps in ftrace. Implementation is copied from OMAP platform code. Signed-off-by: Andreas Gaeerandreas.g...@baslerweb.com Thanks, applying to davinci git. Will queue for 2.6.38 (it's a bit too late for 2.6.37 as Linus only wants real regression fixes after -rc6.) Did you mean 2.6.37 and 2.6.36 respecitvely? Nope. IOW, for the upcoming merge window (2.6.37), Linus does not want to see new features done after 2.6.36-rc6. He wants to sure that by the time the merge window opens, that things have received some testing and validation, particularily in linux-next. This means, that most maintainers (myself included) will not be taking patches/features for 2.6.N merge window after 2.6.(N-1)-rc6 is released, unless they are regression fixes. 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 v4] i2c: davinci: Fix race when setting up for TX
Jon Povey jon.po...@racelogic.co.uk writes: Hi Ben, I am not on the i2c list but noticed this pull request: http://www.spinics.net/linux/lists/linux-i2c/msg04022.html I think you have the wrong (old) version of this patch in that branch, http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0 The correct v4 one from the start of this thread has more lines of patch and this commit message: It is also available in my davinci-i2c branch: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-i2c Thanks Jon for catching this, Kevin When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits 1 byte long. The hardware starts sending immediately that MDR.STT is set. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Sudhakar Rajashekhara explains that at least OMAP-L138 requires MDR mode settings before DXR for correct behaviour, so load MDR first with STT cleared and later load again with STT set. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey jon.po...@racelogic.co.uk CC: Sudhakar Rajashekhara sudhakar@ti.com CC: Troy Kisky troy.ki...@boundarydevices.com It also has some more acks and a tested, via Kevin: Acked-by: Troy Kisky troy.ki...@boundarydevices.com Tested-by: Sudhakar Rajashekhara sudhakar@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] davinci: Implement sched_clock()
andreas.g...@baslerweb.com writes:
From: Andreas Gaeer andreas.g...@baslerweb.com
Overwrite the default implementation of sched_clock that is based on
jiffies by something more precise. This improves timestamps in ftrace.
Implementation is copied from OMAP platform code.
Signed-off-by: Andreas Gaeer andreas.g...@baslerweb.com
Thanks, applying to davinci git.
Will queue for 2.6.38 (it's a bit too late for 2.6.37 as Linus only
wants real regression fixes after -rc6.)
Kevin
---
arch/arm/mach-davinci/time.c | 24 +++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 0f21c36..5d1eea0 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -272,15 +272,36 @@ static cycle_t read_cycles(struct clocksource *cs)
return (cycles_t)timer32_read(t);
}
+/*
+ * Kernel assumes that sched_clock can be called early but may not have
+ * things ready yet.
+ */
+static cycle_t read_dummy(struct clocksource *cs)
+{
+ return 0;
+}
+
+
static struct clocksource clocksource_davinci = {
.rating = 300,
- .read = read_cycles,
+ .read = read_dummy,
.mask = CLOCKSOURCE_MASK(32),
.shift = 24,
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
/*
+ * Overwrite weak default sched_clock with something more precise
+ */
+unsigned long long notrace sched_clock(void)
+{
+ const cycle_t cyc = clocksource_davinci.read(clocksource_davinci);
+
+ return clocksource_cyc2ns(cyc, clocksource_davinci.mult,
+ clocksource_davinci.shift);
+}
+
+/*
* clockevent
*/
static int davinci_set_next_event(unsigned long cycles,
@@ -377,6 +398,7 @@ static void __init davinci_timer_init(void)
davinci_clock_tick_rate = clk_get_rate(timer_clk);
/* setup clocksource */
+ clocksource_davinci.read = read_cycles;
clocksource_davinci.name = id_to_name[clocksource_id];
clocksource_davinci.mult =
clocksource_khz2mult(davinci_clock_tick_rate/1000,
___
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] i2c: davinci: Fix race when setting up for TX
Kevin Hilman khil...@deeprootsystems.com writes: Jon Povey jon.po...@racelogic.co.uk writes: Hi Ben, I am not on the i2c list but noticed this pull request: http://www.spinics.net/linux/lists/linux-i2c/msg04022.html I think you have the wrong (old) version of this patch in that branch, http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=commitdiff;h=4bba0fd8d1c6d405df666e2573e1a1f917098be0 The correct v4 one from the start of this thread has more lines of patch and this commit message: It is also available in my davinci-i2c branch: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git davinci-i2c Thanks Jon for catching this, I just noticed that it has already been pulled and is part of -rc7. Jon, care to submit a new patch with v4 diff and including the acks and tested-bys? Thanks, Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
