RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Thursday, September 09, 2010 4:53 PM To: linux-omap@vger.kernel.org Cc: t...@atomide.com; khil...@deeprootsystems.com; Shilimkar, Santosh Subject: [PATCH 0/7] omap4: Fixes, hacks for es2.0 This series has few fixes, hacks to get omap4 es2.0 working on mainline. The patches are generated against the mainline 2.6.36-rc3. The series is boot tested tested on 4430 SDP, Blaze with omap_4430sdp_defconfig with file over NFS and MMC. Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 SDPs. Same observation with Panda With omap3_defconfig, MMC while mounting the rootfs over MMC, the boot hangs. Same observation with Panda [Ghorai] Santosh, It's booing in another Panda. I think that's a board issue. [5.794616] regulator_init_complete: incomplete constraints, leaving VUSIM on [5.802764] regulator_init_complete: incomplete constraints, leaving VPP on [5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:53:12 UTC (9 ) [5.849304] mmc0: new high speed MMC card at address 0001 [5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB [5.862091] mmcblk0: unknown partition table [6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate latency 0: 6 [ 18.424407] VFS: Cannot open root device mmcblk0p2 or unknown- block(179,2) [ 18.431823] Please append a correct root= boot option; here are the available ons: [ 18.440643] b300 7757824 mmcblk0 driver: mmcblk [ 18.446166] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown All these patches are also available at: http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=summary head: omap4-for-tony David Anders (1): omap4: Panda: Add DEBUG_LL support Eric Dumazet (1): KS8851: Correct RX packet allocation Madhusudhan Chikkature (1): omap4: Workaround for CMD line reset. Santosh Shilimkar (4): omap4: Update id.c and cpu.h for es2.0 omap4: Temporary fix silicon version detection omap4: l2x0: Fix init parameter for ES2.0 omap4: Fix bootup crash observed with higher CPU clocks arch/arm/mach-omap2/id.c | 39 + arch/arm/mach-omap2/omap4-common.c |5 ++- arch/arm/plat-omap/dmtimer.c |2 +- arch/arm/plat-omap/include/plat/cpu.h|5 ++- arch/arm/plat-omap/include/plat/uncompress.h |1 + drivers/mmc/host/omap_hsmmc.c|8 + drivers/net/ks8851.c | 39 ++--- - 7 files changed, 71 insertions(+), 28 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0
-Original Message- [..snip..] The series is boot tested tested on 4430 SDP, Blaze with omap_4430sdp_defconfig with file over NFS and MMC. Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 SDPs. Same observation with Panda With omap3_defconfig, MMC while mounting the rootfs over MMC, the boot hangs. Same observation with Panda On my ES2.0 Panda, rootfs on MMC is now working with this series. I observed the same with MMC. Ramdisk boot worked for me on PANDA. Note that I said now working. I think you read my message as not working. Yes I read it otherway ... Second time today :) IOW, rootfs on MMC *is* working for me on my es2.0 Panda. I applied your series to current l-o master, and it works. Cool!! [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. However, rootfs over NFS is not yet working, presumably because the OMAP4 EHCI support is needed for the USB-attached smsc95xx to work properly. This is correct. We need to get the MMC fixed o.w panda is unusable in it's current form. [5.794616] regulator_init_complete: incomplete constraints, leaving VUSIM on [5.802764] regulator_init_complete: incomplete constraints, leaving VPP on [5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:53:12 UTC (9 ) [5.849304] mmc0: new high speed MMC card at address 0001 [5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB [5.862091] mmcblk0: unknown partition table [6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate latency 0: 6 Based on this message, this is not a mainline kernel, but one where the omap_device conversion for MMC has been applied. This is mainline 2.6.36-rc3 http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=shortlog;h=refs/heads/omap4-for-tony [..snip ..] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0
-Original Message- From: Ghorai, Sukumar Sent: Friday, September 10, 2010 4:00 PM To: Shilimkar, Santosh; Kevin Hilman Cc: linux-omap@vger.kernel.org; t...@atomide.com Subject: RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0 -Original Message- [..snip..] The series is boot tested tested on 4430 SDP, Blaze with omap_4430sdp_defconfig with file over NFS and MMC. Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 SDPs. Same observation with Panda With omap3_defconfig, MMC while mounting the rootfs over MMC, the boot hangs. Same observation with Panda On my ES2.0 Panda, rootfs on MMC is now working with this series. I observed the same with MMC. Ramdisk boot worked for me on PANDA. Note that I said now working. I think you read my message as not working. Yes I read it otherway ... Second time today :) IOW, rootfs on MMC *is* working for me on my es2.0 Panda. I applied your series to current l-o master, and it works. Cool!! [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Thanks Sukumar!! So with this testing data, the series works fine on all boards now with rootfs over MMC. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: otg: twl4030: fix phy initialization(v1)
Hi, On Thu, Sep 09, 2010 at 12:28:27PM -0500, venki kaps wrote: one thing i have not understood, why it requires to power down when the device is booted without a USB cable? why would the phy be powered up for no use ? After booting, just attach/detach the usb cable, then i have not seen any issue with power numbers in off mode, RETENTION and active states. that's because if you boot without cable the phy is left alive, consuming power for nothing. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] omap4: Temporary fix silicon version detection
Hi, On Thu, Sep 09, 2010 at 08:24:12AM -0500, Shilimkar, Santosh wrote: Updated version attached. attaching is generally not a good idea, but if you do so, at least use .diff as extension (or .patch or .txt) so that most mutt users will see it dumped onto the messaged. I think that if you attach, you're also breaking Tony's 'fwiendly wobot'. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/7] omap4: Temporary fix silicon version detection
-Original Message- From: Balbi, Felipe Sent: Friday, September 10, 2010 6:04 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; Cousson, Benoit; t...@atomide.com; khil...@deeprootsystems.com; Balbi, Felipe Subject: Re: [PATCH 2/7] omap4: Temporary fix silicon version detection Hi, On Thu, Sep 09, 2010 at 08:24:12AM -0500, Shilimkar, Santosh wrote: Updated version attached. attaching is generally not a good idea, but if you do so, at least use .diff as extension (or .patch or .txt) so that most mutt users will see it dumped onto the messaged. The attachment is with .patch extension. I think that if you attach, you're also breaking Tony's 'fwiendly wobot'. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
On Fri, Sep 10, 2010 at 7:30 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- [..snip..] The series is boot tested tested on 4430 SDP, Blaze with omap_4430sdp_defconfig with file over NFS and MMC. Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 SDPs. Same observation with Panda With omap3_defconfig, MMC while mounting the rootfs over MMC, the boot hangs. Same observation with Panda On my ES2.0 Panda, rootfs on MMC is now working with this series. I observed the same with MMC. Ramdisk boot worked for me on PANDA. Note that I said now working. I think you read my message as not working. Yes I read it otherway ... Second time today :) IOW, rootfs on MMC *is* working for me on my es2.0 Panda. I applied your series to current l-o master, and it works. Cool!! [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Which Panda version are you using during your tests? I tried omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm unable to detect the MMC. Do I need any other patch to make the MMC work with Panda? Thanks, -- Ricardo Salveti de Araujo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0
-Original Message- From: Ricardo Salveti [mailto:rsalv...@rsalveti.net] Sent: Friday, September 10, 2010 8:34 PM To: Ghorai, Sukumar Cc: Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org; t...@atomide.com Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0 On Fri, Sep 10, 2010 at 7:30 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- [..snip..] The series is boot tested tested on 4430 SDP, Blaze with omap_4430sdp_defconfig with file over NFS and MMC. Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 SDPs. Same observation with Panda With omap3_defconfig, MMC while mounting the rootfs over MMC, the boot hangs. Same observation with Panda On my ES2.0 Panda, rootfs on MMC is now working with this series. I observed the same with MMC. Ramdisk boot worked for me on PANDA. Note that I said now working. I think you read my message as not working. Yes I read it otherway ... Second time today :) IOW, rootfs on MMC *is* working for me on my es2.0 Panda. I applied your series to current l-o master, and it works. Cool!! [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Which Panda version are you using during your tests? I tried omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm unable to detect the MMC. Do I need any other patch to make the MMC work with Panda? [Ghorai] I have tested based on following tree/branch and using ES2.0 PANDA only. Can you share bootlog enabling mmc/sd debug message? http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap4-for-tony Thanks, -- Ricardo Salveti de Araujo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/7] omap4: Fixes, hacks for es2.0
-Original Message- From: Ricardo Salveti [mailto:rsalv...@rsalveti.net] Sent: Friday, September 10, 2010 8:34 PM To: Ghorai, Sukumar Cc: Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org; t...@atomide.com Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0 On Fri, Sep 10, 2010 at 7:30 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- [..snip..] The series is boot tested tested on 4430 SDP, Blaze with omap_4430sdp_defconfig with file over NFS and MMC. Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 SDPs. Same observation with Panda With omap3_defconfig, MMC while mounting the rootfs over MMC, the boot hangs. Same observation with Panda On my ES2.0 Panda, rootfs on MMC is now working with this series. I observed the same with MMC. Ramdisk boot worked for me on PANDA. Note that I said now working. I think you read my message as not working. Yes I read it otherway ... Second time today :) IOW, rootfs on MMC *is* working for me on my es2.0 Panda. I applied your series to current l-o master, and it works. Cool!! [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Which Panda version are you using during your tests? I tried omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm unable to detect the MMC. Do I need any other patch to make the MMC work with Panda? You don't need any more patches for kernel. Just use latest Panda boot-loaders and it should work. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] i2c: twl: add register defines for pm master module
Hi Felipe, On Wed, Aug 18, 2010 at 10:19:16AM +0300, Felipe Balbi wrote: hi, On Wed, Aug 18, 2010 at 08:19:34AM +0200, Balbi Felipe (Nokia-MS/Helsinki) wrote: From: Felipe Balbi felipe.ba...@nokia.com Some modules already need to talk to at least PROTECT_KEY register, while at that, add defines to the entire register space. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com --- here's updated patch with correct register space All 4 patches applied, many thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse
On Friday 10 September 2010 12:25:40 am Michael Williamson wrote:
Hi Cyril,
On 09/09/2010 03:51 PM, Cyril Chemparathy wrote:
Hi Mike,
[...]
The hang is in wait_for_user_access() in the davinci_mdio_read() call.
Looks like the state machine got put back into IDLE somewhere between
the MDIO probe and the EMAC probe. Seems like there should be some sort
of time-out and error message in the wait_for_user_access() method
(maybe even a check for IDLE??)
If I add a patch to check the state machine for IDLE and then re-enable
it in the davinci_mdio_read() call, it is able to press on and come up.
I don't see any calls to the davinci_mdio_suspend() call, so I am
wondering if the EMAC probe routine, particularly the application of the
SOFTRESET, is causing the MDIO to drop back to IDLE / disabled.
I can post the patch if you like, but it is a bit of a hack...
An EMAC soft-reset clobbering the MDIO controller state is a
possibility. I will poll TI designers to see if this could be the case.
In any case, a couple of unanswered questions remain:
1. Why don't other davinci devices display similar behavior?
2. If the answer to #1 above is that the timing window is pretty slim
(i.e., only if an MDIO read/write is in progress during EMAC
soft-reset), why do we hit this situation consistently on
mityomap?
Has it been confirmed that this only happens on mityomap? Has anyone had
success using a da850 evm or other da850 platform? The configuration for
Same problem exists on another DA850 board, Hawkboard.(Sorry no support in
mainline yet)
the mityomap, wrt to the EMAC/MII/MDIO, is pretty much identical to the
da850 evm using the MII interface. The only difference I am aware of is
the assigned address to the PHY chip. The reference clocks and rates are
identical, AFAIK, to the evm.
I have put together a quick patch (tested dm365). See attached.
Your patch doesn't work with my board. It does attempt to reset the bus on
This patch fixes the problem here. I'm using kernel IP auto configuration and
mounting fs over NFS. My system boots and I can login to my board.
Regards,
Caglar
the read call, but following wait_for_user_access() calls are timing out
and the _read() and _write() calls punt. I bumped up the MDIO_TIMEOUT to
100 ms, and it works. I'm wondering if the scanning logic has to complete
an entire cycle (all 32 phys) before issuing a request, and if it's a lot
slower than expected.
I also found that the initial scanning logic would not reliably find the
PHY until I bumped up the delay time following the reset operation.
Sometimes it would, sometimes no.
Also, your while(1) loops with the continue conditions on the second
wait_for_user_access() in the read and writes might need some
consideration, i.e.:
while (1) {
ret = wait_for_user_access(data);
if (ret == -EAGAIN)
continue;
if (ret 0)
break;
__raw_writel(reg, data-regs-user[0].access);
ret = wait_for_user_access(data);
if (ret == -EAGAIN)
continue;
^ --- this will re-issue the request
what you want? if (ret 0)
break;
reg = __raw_readl(data-regs-user[0].access);
ret = (reg USERACCESS_ACK) ? (reg USERACCESS_DATA) :
-EIO; break;
}
Also, on the shutdown, I get a major kernel trace. Here is the dump, as
much as I could catch of it (I need a better terminal program)
Deconfiguring network interfaces... [ cut here ]
WARNING: at kernel/softirq.c:143 local_bh_enable+0x40/0xb4()
Modules linked in:
[c002e684] (unwind_backtrace+0x0/0xec) from [c003e284]
(warn_slowpath_common+0x4c/0x64) [c003e284]
(warn_slowpath_common+0x4c/0x64) from [c003e2b8]
(warn_slowpath_null+0x1c/0x24) [c003e2b8] (warn_slowpath_null+0x1c/0x24)
from [c0043e80] (local_bh_enable+0x40/0xb4) [c0043e80]
(local_bh_enable+0x40/0xb4) from [c01f3760]
(__netif_receive_skb+0xf8/0x3d0) [c01f3760]
(__netif_receive_skb+0xf8/0x3d0) from [c01d344c]
(emac_rx_handler+0x40/0xcc) [c01d344c] (emac_rx_handler+0x40/0xcc) from
[c01d3fe8] (__cpdma_chan_free+0xac/0xb0) [c01d3fe8]
(__cpdma_chan_free+0xac/0xb0) from [c01d40d0]
(__cpdma_chan_process+0xe4/0x114) [c01d40d0]
(__cpdma_chan_process+0xe4/0x114) from [c01d4238]
(cpdma_chan_stop+0xf0/0x1c8) [c01d4238] (cpdma_chan_stop+0xf0/0x1c8)
from [c01d4390] (cpdma_ctlr_stop+0x80/0xe4) [c01d4390]
(cpdma_ctlr_stop+0x80/0xe4) from [c01d2c00] (emac_dev_stop+0xb0/0x13c)
[c01d2c00] (emac_dev_stop+0xb0/0x13c) from [c01f5b40]
(__dev_close+0x74/0x98) [c01f5b40] (__dev_close+0x74/0x98) from
[c01f3168] (__dev_change_flags+0xac/0x13c) [c01f3168]
(__dev_change_flags+0xac/0x13c) from
Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0
On Fri, Sep 10, 2010 at 12:09 PM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- On Fri, Sep 10, 2010 at 7:30 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- [..snip..] The series is boot tested tested on 4430 SDP, Blaze with omap_4430sdp_defconfig with file over NFS and MMC. Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 SDPs. Same observation with Panda With omap3_defconfig, MMC while mounting the rootfs over MMC, the boot hangs. Same observation with Panda On my ES2.0 Panda, rootfs on MMC is now working with this series. I observed the same with MMC. Ramdisk boot worked for me on PANDA. Note that I said now working. I think you read my message as not working. Yes I read it otherway ... Second time today :) IOW, rootfs on MMC *is* working for me on my es2.0 Panda. I applied your series to current l-o master, and it works. Cool!! [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Which Panda version are you using during your tests? I tried omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm unable to detect the MMC. Do I need any other patch to make the MMC work with Panda? [Ghorai] I have tested based on following tree/branch and using ES2.0 PANDA only. Can you share bootlog enabling mmc/sd debug message? http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap4-for-tony My boot log: http://paste.ubuntu.com/491645/ Using x-loader from http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and upstream u-boot. Cheers, -- Ricardo Salveti de Araujo -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Suspend to RAM broken on BeagleBoard ?
Hello, I've tested the current linux-omap Git tree and Kevin's pm-core branch on a BeagleBoard using the omap3_defconfig, and when trying a suspend to RAM, I get a Class driver suspend failed for cpu0 : # echo mem /sys/power/state [ 93.395050] PM: Syncing filesystems ... done. [ 93.410827] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 93.434570] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 93.458557] Suspending console(s) (use no_console_suspend to debug) [ 93.590728] PM: suspend of devices complete after 119.629 msecs [ 93.593902] PM: late suspend of devices complete after 3.112 msecs [ 93.594421] Class driver suspend failed for cpu0 [ 93.595153] PM: early resume of devices complete after 0.518 msecs [ 93.887603] PM: resume of devices complete after 292.052 msecs [ 93.922851] Restarting tasks ... done. Is this a known issue ? I also have a problem with USB support, both on linux-omap and Kevin's pm-core branch. My USB Ethernet adapter, supported by the asix driver, isn't detected anymore. With a pm git tree of a couple of weeks ago, it was working. This is again with just a plain omap3_defconfig. Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend to RAM broken on BeagleBoard ?
Hi, On Fri, Sep 10, 2010 at 10:48:14AM -0500, Thomas Petazzoni wrote: I also have a problem with USB support, both on linux-omap and Kevin's pm-core branch. My USB Ethernet adapter, supported by the asix driver, isn't detected anymore. With a pm git tree of a couple of weeks ago, it was working. This is again with just a plain omap3_defconfig. is it attached to EHCI/OHCI or musb port ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Example OMAP board configuration file for LCD brightness control
Hi, I'm trying to implement LCD brightness control for the Gumstix Overo (TI OMAP 3503) + Palo43 module. GPIO 144 which can also support PWM signal generation is, connected to the LCD's display on/off signal. Could someone point me to an example board-configuration file that I can use, to similarly configure the board-overo.c file, to configure GPIO144 to PWM mode, to enable brightness control for the LCD display? Best regards, Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Example OMAP board configuration file for LCD brightness control
Hi, you should break your lines at 80-chars On Fri, Sep 10, 2010 at 12:43:48PM -0500, Elvis Dowson wrote: Could someone point me to an example board-configuration file that I can use, to similarly configure the board-overo.c file, to configure GPIO144 to PWM mode, to enable brightness control for the LCD display? probably arch/arm/mach-omap2/board-3430sdp.c could help. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend to RAM broken on BeagleBoard ?
On Fri, 10 Sep 2010 20:00:53 +0300 Felipe Balbi ba...@ti.com wrote: On Fri, Sep 10, 2010 at 10:48:14AM -0500, Thomas Petazzoni wrote: I also have a problem with USB support, both on linux-omap and Kevin's pm-core branch. My USB Ethernet adapter, supported by the asix driver, isn't detected anymore. With a pm git tree of a couple of weeks ago, it was working. This is again with just a plain omap3_defconfig. is it attached to EHCI/OHCI or musb port ? It's a normal USB Ethernet adapter that is attached to the EHCI/OCHI port of the BeagleBoard. I have a revision C3. With older Git versions from the PM tree, it used to work, even if it wasn't 100% stable. But at least it was detected, and I was able to nfs mount the root filesystem. I don't know if I can easily bisect this, as I think the PM branches are constantly rebased. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
NAND erase failures on overo
With the current, linux-omap:master branch (8475b9e5077d9e9b4ba7a92afd4c5c7d65564c09), I get the following errors on a overo system when erasing flash: r...@ts3:~# flash_eraseall -j /dev/mtd4 Erasing 128 Kibyte @ 8c4 -- 56 % complete. Cleanmarker written at 8c2. flash_eraseall: /dev/mtd4: MTD Erase failure: Input/output error Erasing 128 Kibyte @ 944 -- 59 % complete. Cleanmarker written at 942. flash_eraseall: /dev/mtd4: MTD Erase failure: Input/output error Erasing 128 Kibyte @ f98 -- 100 % complete.Cleanmarker written at f96. On the omap3530 TI EVM, with the same kernel, I don't see any of these errors. I'm not sure if its related to something like this: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031563.html Thanks, Cliff -- = http://bec-systems.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend to RAM broken on BeagleBoard ?
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: Hello, I've tested the current linux-omap Git tree and Kevin's pm-core branch on a BeagleBoard using the omap3_defconfig, and when trying a suspend to RAM, I get a Class driver suspend failed for cpu0 : # echo mem /sys/power/state [ 93.395050] PM: Syncing filesystems ... done. [ 93.410827] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 93.434570] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 93.458557] Suspending console(s) (use no_console_suspend to debug) [ 93.590728] PM: suspend of devices complete after 119.629 msecs [ 93.593902] PM: late suspend of devices complete after 3.112 msecs [ 93.594421] Class driver suspend failed for cpu0 It's the CPUfreq driver that's failing to suspend. [ 93.595153] PM: early resume of devices complete after 0.518 msecs [ 93.887603] PM: resume of devices complete after 292.052 msecs [ 93.922851] Restarting tasks ... done. Is this a known issue ? Yes, CPUfreq is not supported in l-o master or pm-core (only in the full pm branch.) If you Kconfig out CPUfreq, this failure will go away. [...] Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] nand/omap2: fix compile error with DMA Config
With CONFIG_MTD_NAND_OMAP_PREFETCH_DMA, there is a compile error that this patch fixes. Signed-off-by: Cliff Brake cbr...@bec-systems.com --- drivers/mtd/nand/omap2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 133d515..513e0a7 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -413,7 +413,7 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr, prefetch_status = gpmc_read_status(GPMC_PREFETCH_COUNT); } while (prefetch_status); /* disable and stop the PFPW engine */ - gpmc_prefetch_reset(); + gpmc_prefetch_reset(info-gpmc_cs); dma_unmap_single(info-pdev-dev, dma_addr, len, dir); return 0; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP: McSPI: Implement McSPI in HWMOD way
Grant Likely grant.lik...@secretlab.ca writes: On Thu, Aug 19, 2010 at 05:56:43PM -0700, Kevin Hilman wrote: Grant Likely grant.lik...@secretlab.ca writes: On Fri, Aug 13, 2010 at 8:05 AM, Charulatha V ch...@ti.com wrote: This patch series implements McSPI Module in HWMOD FW way and use the runtime PM layer. Hi Charulatha, I'll go through and review the patches, but I'm unfamiliar with HWMOD. Is there a description of HWMOD that you can point me at? Hi Grant, If you want to skip my rambling, the source for omap_hwmod is in mainline: arch/arm/mach-omap2/omap_hwmod.c arch/arm/plat-omap/include/plat/omap_hwmod.h omap_hwmod is short for OMAP hardware module. It is essentially a central way of describing each IP block in an OMAP SoC, and the way they are connected together to make an SoC. An omap_hwmod for a given IP block contains base address, IRQs, DMA channels etc. (as would a device tree node) but also includes information on any master/slave interfaces to model how IP blocks are connected on the SoC and many other details. Hi Kevin, This seems to be a common issue for more than just OMAP SoCs, and I've seen a number of approaches to solving it; both internal to the kernel (AMBA bus, HWMOD, ad-hoc pdata, etc) and via external data (FDT, SFI). It doesn't seem like there is a lot of cross-pollination going on either. I'm thinking about scheduling a discussion in the embedded microconference at Plumbers to talk about the encoding and handling of SoC and machine interconnection data. There should be enough examples now that we can agree on some common infrastructure for handling these kinds of things without inventing new infrastructure from scratch for each SoC family. What do you think? The discussion is certainly worthwhile, and I would love to participate. As with everything, the devil is in the details. And I'm afraid that while at a high-level, describing one SoC or another might look similar, when it gets down to the details, there will be *tons* of things that are unique to each SoC. For example, if you look into the omap_hwmod code and data structures, you will see that most of the stuff described in there is extremly OMAP specific (mostly clock/power related), and only ever visible to OMAP specific code. The question to me is what is the end goal of having a common infrastructure to model SoC-unique features that are only touched by SoC-specific code? And who would maintain such an infrastructure? Personally, I would rather keep focus on infrastructure efforts that would actually be common across SoCs (common kernel binaries, etc.) and visible to drivers (PM frameworks like CPUidle, runtime PM, etc.) All the gory SoC specifics should be hidden by the SoC-specific implementations of these frameworks, and maintained by folks who really understand the SoC. So, all that that I question the need for a common framework to define SoC internals. That being said, I'm totally in favor of the direction that the FDT is going in, and very much support the ways it will unify much of the hardware description. However, I think it has limits. And at least for OMAP, I envision using the device tree to describe connections at the board level, but continuing to use omap_hwmod to describe the SoC itself. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] split out emac cpdma and mdio for reuse
Hi Mike,
I have merged your latest two emails and responded to both here.
[...]
Your patch doesn't work with my board. It does attempt to reset the bus on
the read call,
but following wait_for_user_access() calls are timing out and the _read() and
_write() calls punt.
I bumped up the MDIO_TIMEOUT to 100 ms, and it works. I'm wondering if the
scanning logic
has to complete an entire cycle (all 32 phys) before issuing a request, and
if it's a lot
slower than expected.
Based on the mdio module's state machine code, the scan does not need to
complete before a user-request is issued. However, when the module is
first enabled, it _must_ poll at least one phy (phy id 0) before it
handles the user-access request. Consequently, the first access after
coming out of reset may be slower than subsequent accesses.
One of the patches posted on my repo [1] replaces the dumb mdelay() with
a bit more logic that calculates the worst-case access time. This
mechanism may work a lot better for you. Would you mind trying it out?
Since the MDIO_TIMEOUT is simply a defensive measure, I have no
objections to raising this timeout (included in the updated stack).
I also found that the initial scanning logic would not reliably find the PHY
until I bumped
up the delay time following the reset operation. Sometimes it would,
sometimes no.
Also, your while(1) loops with the continue conditions on the second
wait_for_user_access()
in the read and writes might need some consideration, i.e.:
while (1) {
ret = wait_for_user_access(data);
if (ret == -EAGAIN)
continue;
if (ret 0)
break;
__raw_writel(reg, data-regs-user[0].access);
ret = wait_for_user_access(data);
if (ret == -EAGAIN)
continue;
^ --- this will re-issue the request
what you want?
Yes, the wait_for_user_access() would have reset the controller,
throwing the current transaction out. The intent here is to restart the
current transaction with a newly initialized controller.
if (ret 0)
break;
reg = __raw_readl(data-regs-user[0].access);
ret = (reg USERACCESS_ACK) ? (reg USERACCESS_DATA) : -EIO;
break;
}
Also, on the shutdown, I get a major kernel trace. Here is the dump, as much
as I could catch of it (I need a better terminal program)
[...]
WARNING: at drivers/net/davinci_emac.c:1025 __cpdma_chan_free+0xac/0xb0()
The current code spits out a huge volume of stuff as a result of a
WARN_ON in the rx handler. The gitweb on [1] has a patch that fixes this.
[...]
The MDIO module upgrade (rev 1.4 - 1.5) could have something to do with
this behavior. Even so, I can't explain why this issue wasn't seen on
da8xx prior to this series. The original code should (at least in
theory) have sporadically locked up on emac open.
I think, if I understand it correctly, that in the previous version of
this code, the emac was reset *prior* to enabling, scanning, and assigning
the associated phy on the MDIO bus. The new implementation sets up and scans
the MDIO bus first, then comes back around to the EMAC second... hits a reset,
and doesn't re-ENABLE the MDIO.
AFAICS, that isn't entirely accurate. In the previous version, the mdio
bus was being brought up at probe time in davinci_emac_probe(). The
soft-reset was happening later on when the device is opened, in
emac_hw_enable().
The difference, however, is that the original code forced an
emac_mii_reset() immediately after the emac_hw_enable(). This is not
being done with the separated mdio, and that is the problem. In terms
of behavior, with the current work around, the new and old versions
should be close to identical. More below...
Also, maybe hitting the EMAC reset while the MDIO state machine is up is
*bad*, I
seem to recall some text in the user's guide about waiting for the state
machine to stop before disabling it. I wonder if that also applies to reset?
You are correct. EMAC soft-reset stops the MDIO mid-transaction, quite
unlike disabling the module via the control register. Therefore, there
is a risk that a badly designed phy could be left hanging in an
arbitrary state. However, all earlier versions of the emac code have
been exposed to this very same vulnerability (i.e. arbitrary emac
soft-reset regardless of mdio state) all along.
Regards
Cyril.
[1]
http://arago-project.org/git/people/?p=cyril/linux-tnetv107x.git;a=shortlog;h=refs/heads/emac-cpdma-mdio-fixes
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/6] Add camera support to the OMAP1 Amstrad Delta videophone
This set consists of the following patches: 1/6 SoC Camera: add driver for OMAP1 camera interface 2/6 OMAP1: Add support for SoC camera interface 3/6 SoC Camera: add driver for OV6650 sensor 4/6 SoC Camera: add support for g_parm / s_parm operations 5/6 OMAP1: Amstrad Delta: add support for on-board camera 6/6 OMAP1: Amstrad Delta: add camera controlled LEDS trigger arch/arm/mach-omap1/board-ams-delta.c | 69 + arch/arm/mach-omap1/devices.c | 43 arch/arm/mach-omap1/include/mach/camera.h |8 drivers/media/video/Kconfig | 14 drivers/media/video/Makefile |2 drivers/media/video/omap1_camera.c| 1781 ++ drivers/media/video/ov6650.c | 1242 drivers/media/video/soc_camera.c | 18 include/media/omap1_camera.h | 35 include/media/v4l2-chip-ident.h |1 10 files changed, 3213 insertions(+) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/6] OMAP1: Add support for SoC camera interface
This patch adds support for SoC camera interface to OMAP1 devices.
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
For successfull compilation, requires a header file provided by PATCH 1/6 from
this series, SoC Camera: add driver for OMAP1 camera interface.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/devices.c | 43
++
arch/arm/mach-omap1/include/mach/camera.h |8 +
2 files changed, 51 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c
linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c 2010-09-09
18:42:30.0 +0200
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/spi/spi.h
+#include linux/dma-mapping.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -25,6 +26,7 @@
#include mach/gpio.h
#include plat/mmc.h
#include plat/omap7xx.h
+#include mach/camera.h
/*-*/
@@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
}
#endif
+
+#define OMAP1_CAMERA_BASE 0xfffb6800
+
+static struct resource omap1_camera_resources[] = {
+ [0] = {
+ .start = OMAP1_CAMERA_BASE,
+ .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = INT_CAMERA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device omap1_camera_device = {
+ .name = omap1-camera,
+ .id = 0, /* This is used to put cameras on this interface */
+ .dev= {
+ .dma_mask = omap1_camera_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(omap1_camera_resources),
+ .resource = omap1_camera_resources,
+};
+
+void __init omap1_set_camera_info(struct omap1_cam_platform_data *info)
+{
+ struct platform_device *dev = omap1_camera_device;
+ int ret;
+
+ dev-dev.platform_data = info;
+
+ ret = platform_device_register(dev);
+ if (ret)
+ dev_err(dev-dev, unable to register device: %d\n, ret);
+}
+
+
/*-*/
static inline void omap_init_sti(void) {}
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
2010-09-03
22:34:03.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h 2010-09-09
18:42:30.0 +0200
@@ -0,0 +1,8 @@
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+#include media/omap1_camera.h
+
+extern void omap1_set_camera_info(struct omap1_cam_platform_data *);
+
+#endif /* __ASM_ARCH_CAMERA_H_ */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/6] OMAP1: Amstrad Delta: add support for camera
This patch adds configuration data and initialization code required for camera
support to the Amstrad Delta board.
Three devices are declared: SoC camera, OMAP1 camera interface and OV6650
sensor.
Default 12MHz clock has been selected for driving the sensor. Pixel clock has
been limited to get reasonable frame rates, not exceeding the board
capabilities. Since both devices (interface and sensor) support both pixel
clock polarities, decision on polarity selection has been left to drivers.
Interface GPIO line has been found not functional, thus not configured.
Created and tested against linux-2.6.36-rc3.
Works on top of previous patches from the series, at least 1/6, 2/6 and 3/6.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/board-ams-delta.c | 45 ++
1 file changed, 45 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c
linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:01:24.0 +0200
@@ -19,6 +19,8 @@
#include linux/platform_device.h
#include linux/serial_8250.h
+#include media/soc_camera.h
+
#include asm/serial.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -32,6 +34,7 @@
#include plat/usb.h
#include plat/board.h
#include plat/common.h
+#include mach/camera.h
#include mach/ams-delta-fiq.h
@@ -213,10 +216,37 @@ static struct platform_device ams_delta_
.id = -1
};
+static struct i2c_board_info ams_delta_camera_board_info[] = {
+ {
+ I2C_BOARD_INFO(ov6650, 0x60),
+ },
+};
+
+static struct soc_camera_link __initdata ams_delta_iclink = {
+ .bus_id = 0,/* OMAP1 SoC camera bus */
+ .i2c_adapter_id = 1,
+ .board_info = ams_delta_camera_board_info[0],
+ .module_name= ov6650,
+};
+
+static struct platform_device ams_delta_camera_device = {
+ .name = soc-camera-pdrv,
+ .id = 0,
+ .dev= {
+ .platform_data = ams_delta_iclink,
+ },
+};
+
+static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
+ .camexclk_khz = 12000,/* default 12MHz clock, no extra DPLL */
+ .lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
+};
+
static struct platform_device *ams_delta_devices[] __initdata = {
ams_delta_kp_device,
ams_delta_lcd_device,
ams_delta_led_device,
+ ams_delta_camera_device,
};
static void __init ams_delta_init(void)
@@ -225,6 +255,20 @@ static void __init ams_delta_init(void)
omap_cfg_reg(UART1_TX);
omap_cfg_reg(UART1_RTS);
+ /* parallel camera interface */
+ omap_cfg_reg(H19_1610_CAM_EXCLK);
+ omap_cfg_reg(J15_1610_CAM_LCLK);
+ omap_cfg_reg(L18_1610_CAM_VS);
+ omap_cfg_reg(L15_1610_CAM_HS);
+ omap_cfg_reg(L19_1610_CAM_D0);
+ omap_cfg_reg(K14_1610_CAM_D1);
+ omap_cfg_reg(K15_1610_CAM_D2);
+ omap_cfg_reg(K19_1610_CAM_D3);
+ omap_cfg_reg(K18_1610_CAM_D4);
+ omap_cfg_reg(J14_1610_CAM_D5);
+ omap_cfg_reg(J19_1610_CAM_D6);
+ omap_cfg_reg(J18_1610_CAM_D7);
+
iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc));
omap_board_config = ams_delta_config;
@@ -236,6 +280,7 @@ static void __init ams_delta_init(void)
ams_delta_latch2_write(~0, 0);
omap1_usb_init(ams_delta_usb_config);
+ omap1_set_camera_info(ams_delta_camera_platform_data);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
#ifdef CONFIG_AMS_DELTA_FIQ
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/6] OMAP1: Amstrad Delta: add camera controlled LEDS trigger
This patch extends the Amstrad Delta camera support with LEDS trigger that can
be used for automatic control of the on-board camera LED. The led turns on
automatically on camera device open and turns off on camera device close.
Created and tested against linux-2.6.36-rc3.
Works on top of patch 5/6, OMAP1: Amstrad Delta: add support for on-board
camera
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Having no comments received on v1 of this patch, I assume nobody could see any
benefit if I implemented this idea at the SoC camera or OMAP1 camera level,
so I'm leaveing it as an Amstrad Delta only feature, as it originally was for
v1.
Thanks,
Janusz
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3.
arch/arm/mach-omap1/board-ams-delta.c | 24
1 file changed, 24 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c
linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:01:24.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:08:29.0 +0200
@@ -16,6 +16,7 @@
#include linux/init.h
#include linux/input.h
#include linux/interrupt.h
+#include linux/leds.h
#include linux/platform_device.h
#include linux/serial_8250.h
@@ -222,11 +223,30 @@ static struct i2c_board_info ams_delta_c
},
};
+#ifdef CONFIG_LEDS_TRIGGERS
+DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);
+
+static int ams_delta_camera_power(struct device *dev, int power)
+{
+ /*
+* turn on camera LED
+*/
+ if (power)
+ led_trigger_event(ams_delta_camera_led_trigger, LED_FULL);
+ else
+ led_trigger_event(ams_delta_camera_led_trigger, LED_OFF);
+ return 0;
+}
+#else
+#define ams_delta_camera_power NULL
+#endif
+
static struct soc_camera_link __initdata ams_delta_iclink = {
.bus_id = 0,/* OMAP1 SoC camera bus */
.i2c_adapter_id = 1,
.board_info = ams_delta_camera_board_info[0],
.module_name= ov6650,
+ .power = ams_delta_camera_power,
};
static struct platform_device ams_delta_camera_device = {
@@ -281,6 +301,10 @@ static void __init ams_delta_init(void)
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
+#ifdef CONFIG_LEDS_TRIGGERS
+ led_trigger_register_simple(ams_delta_camera,
+ ams_delta_camera_led_trigger);
+#endif
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
#ifdef CONFIG_AMS_DELTA_FIQ
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
This patch adds support for SoC camera interface to OMAP1 devices.
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
For successfull compilation, requires a header file provided by PATCH 1/6 from
this series, SoC Camera: add driver for OMAP1 camera interface.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Resend because of wrapped lines, sorry.
Janusz
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/devices.c | 43 ++
arch/arm/mach-omap1/include/mach/camera.h |8 +
2 files changed, 51 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c
linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c 2010-09-09
18:42:30.0 +0200
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/spi/spi.h
+#include linux/dma-mapping.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -25,6 +26,7 @@
#include mach/gpio.h
#include plat/mmc.h
#include plat/omap7xx.h
+#include mach/camera.h
/*-*/
@@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
}
#endif
+
+#define OMAP1_CAMERA_BASE 0xfffb6800
+
+static struct resource omap1_camera_resources[] = {
+ [0] = {
+ .start = OMAP1_CAMERA_BASE,
+ .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = INT_CAMERA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device omap1_camera_device = {
+ .name = omap1-camera,
+ .id = 0, /* This is used to put cameras on this interface */
+ .dev= {
+ .dma_mask = omap1_camera_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(omap1_camera_resources),
+ .resource = omap1_camera_resources,
+};
+
+void __init omap1_set_camera_info(struct omap1_cam_platform_data *info)
+{
+ struct platform_device *dev = omap1_camera_device;
+ int ret;
+
+ dev-dev.platform_data = info;
+
+ ret = platform_device_register(dev);
+ if (ret)
+ dev_err(dev-dev, unable to register device: %d\n, ret);
+}
+
+
/*-*/
static inline void omap_init_sti(void) {}
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
2010-09-03 22:34:03.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h 2010-09-09
18:42:30.0 +0200
@@ -0,0 +1,8 @@
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+#include media/omap1_camera.h
+
+extern void omap1_set_camera_info(struct omap1_cam_platform_data *);
+
+#endif /* __ASM_ARCH_CAMERA_H_ */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
