Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
(adding linux-media ML to cc) Hi Pantelis On Tue, 8 Jan 2013, Pantelis Antoniou wrote: Hi Arnd, On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote: (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc) On Monday 07 January 2013, Tony Lindgren wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Arnd Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. Can we get some input by the owner of other similar hardware? I know the FPGA people have similar requirements for example. There are other people that are hitting problems getting DT to work with their systems, like the V4L people with the order of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is cleanly solved by the overlay being contained in the V4L device node and applied just before the device is probed. You probably mean these related V4L patches: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646 that base upon of asynchronous V4L2 subdevice probing, referenced above. Yes, V4L DT nodes, as documented in http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648 contain port and endpoint nodes, that describe the configuration of the hardware port and link to devices, connected to it. Not sure how well this would work with DT overlays, because endpoint nodes on both sides of the video data bus contain references to the other side and I don't know whether and how these can be created and / or updated at run-time. Otherwise, yes, the approach that we're currently developing on V4L allows us to build video data pipelines independent of (sub)device driver probing order. Thanks Guennadi In the meantime it would be better to wait until we have some ack from the maintainers of the core subsystems about what they think. Regards -- Pantelis --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] ARM: sh7372: fix cache clean / invalidate order
According to the Cortex A8 TRM the L2 cache should be first cleaned and then disabled. Fix the swapped order on sh7372. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com --- v2: addressed improvement suggestions by Santosh, thanks diff --git a/arch/arm/mach-shmobile/sleep-sh7372.S b/arch/arm/mach-shmobile/sleep-sh7372.S index 1d56467..a9df53b 100644 --- a/arch/arm/mach-shmobile/sleep-sh7372.S +++ b/arch/arm/mach-shmobile/sleep-sh7372.S @@ -59,17 +59,19 @@ sh7372_do_idle_sysc: mcr p15, 0, r0, c1, c0, 0 isb + /* +* Clean and invalidate data cache again. +*/ + ldr r1, kernel_flush + blx r1 + /* disable L2 cache in the aux control register */ mrc p15, 0, r10, c1, c0, 1 bic r10, r10, #2 mcr p15, 0, r10, c1, c0, 1 + isb /* -* Invalidate data cache again. -*/ - ldr r1, kernel_flush - blx r1 - /* * The kernel doesn't interwork: v7_flush_dcache_all in particluar will * always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled. * This sequence switches back to ARM. Note that .align may insert a -- 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: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Wed, 12 Dec 2012, Will Deacon wrote: On Wed, Dec 12, 2012 at 10:33:38AM +, Lorenzo Pieralisi wrote: On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote: On 12/11/12 08:38, Will Deacon wrote: diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? And after doing that I think the suspend finisher will still have to call flush_cache_all() since LoUU == 1 on A8, L2 is not cleaned and that's probably what we want if it can be retained. At some point we probably want to describe the level of flushing required in the device tree as a property of the CPU node (or something similar). That would allow us to have *one* function for flushing, e.g. cpu_suspend_flush_cache which flushes to the appropriate level. Then we could remove the louis flush from the CPU suspend code and instead make it the finisher's responsibility to call our flushing function when it's done, which helps to avoid over/under-flushing the cache. In the meantime, fixing louis as we've suggested should work. Back to the case in hand Lorenzo just pointed out to me that the finished in question (sh7372_do_idle_sysc) calls v7_flush_dcache_all, so the louis stuff should be irrelevant. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? Yes, this works too. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, 13 Dec 2012, Will Deacon wrote: On Thu, Dec 13, 2012 at 08:09:33AM +, Guennadi Liakhovetski wrote: On Wed, 12 Dec 2012, Will Deacon wrote: Back to the case in hand Lorenzo just pointed out to me that the finished in question (sh7372_do_idle_sysc) calls v7_flush_dcache_all, so the louis stuff should be irrelevant. The problem may actually be that the finisher disables the L2 cache prior to cleaning/invalidating it, which is the opposite order to that described by the A8 TRM. Guennadi -- can you try moving the kernel_flush call before the L2 disable in sh7372_do_idle_sysc please? Yes, this works too. That's good to know. Please can you send a patch for that? The sequence currently being used by the finisher *is* buggy, and should be fixed independently of the louis stuff. Well, the fix is yours, so, it should be From: you. I can certainly send it just copying your description above, but I'd also need your Sob. Something like the below (feel free to improve the subject line and the description): From: Will Deacon will.dea...@arm.com Subject: [PATCH] ARM: sh7372: fix cache clean / invalidate order According to the Cortex A8 TRM the L2 cache should be first cleaned and then disabled. Fix the swapped order on sh7372. Signed-off-by: you Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de (or even just) Tested-by: Guennadi Liakhovetski g.liakhovet...@gmx.de diff --git a/arch/arm/mach-shmobile/sleep-sh7372.S b/arch/arm/mach-shmobile/sleep-sh7372.S index 1d56467..df15d8a 100644 --- a/arch/arm/mach-shmobile/sleep-sh7372.S +++ b/arch/arm/mach-shmobile/sleep-sh7372.S @@ -59,16 +59,16 @@ sh7372_do_idle_sysc: mcr p15, 0, r0, c1, c0, 0 isb - /* disable L2 cache in the aux control register */ - mrc p15, 0, r10, c1, c0, 1 - bic r10, r10, #2 - mcr p15, 0, r10, c1, c0, 1 - /* * Invalidate data cache again. */ ldr r1, kernel_flush blx r1 + + /* disable L2 cache in the aux control register */ + mrc p15, 0, r10, c1, c0, 1 + bic r10, r10, #2 + mcr p15, 0, r10, c1, c0, 1 /* * The kernel doesn't interwork: v7_flush_dcache_all in particluar will * always return in Thumb state when CONFIG_THUMB2_KERNEL is enabled. -- 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: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
Hi Lorenzo On Wed, 12 Dec 2012, Lorenzo Pieralisi wrote: On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote: On 12/11/12 08:38, Will Deacon wrote: diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? And after doing that I think the suspend finisher will still have to call flush_cache_all() since LoUU == 1 on A8, L2 is not cleaned and that's probably what we want if it can be retained. What about this (compile tested) ? Works too. Thanks Guennadi Lorenzo ---8 diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..036f80f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,8 +44,9 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr - mov r3, r3, lsr #20 @ r3 = LoUIS * 2 + ALT_SMP(lsr r3, r0, #20)@ r3 = clidr[31:20] + ALT_UP(lsr r3, r0, #26)@ r3 = clidr[31:26] + andsr3, r3, #0xe@ r3 = LoUIS/LoUU * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 b flush_levels@ start flushing cache levels --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
Hi Will On Wed, 12 Dec 2012, Will Deacon wrote: On Tue, Dec 11, 2012 at 11:27:39PM +, Stephen Boyd wrote: On 12/11/12 08:38, Will Deacon wrote: diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 You need to fix this mov as well, right? Ha, nice catch. So the original patch ended up with a ridiculously high level number and would've flushed L2, hence we will need to retest with the fix below... Had to apply manually, but it worked too. Thanks Guennadi Will ---8 diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..7539ec2 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,8 +44,10 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr - mov r3, r3, lsr #20 @ r3 = LoUIS * 2 + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr + ALT_SMP(mov r3, r3, lsr #20)@ r3 = LoUIS * 2 + ALT_UP(mov r3, r3, lsr #26)@ r3 = LoUU * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 b flush_levels@ start flushing cache levels --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
Hi all On Thu, 20 Sep 2012, Dave Martin wrote: On Thu, Sep 20, 2012 at 11:25:14AM +0100, Lorenzo Pieralisi wrote: On Wed, Sep 19, 2012 at 02:46:58PM +0100, Dave Martin wrote: On Tue, Sep 18, 2012 at 05:35:33PM +0100, Lorenzo Pieralisi wrote: In processors like A15/A7 L2 cache is unified and integrated within the processor cache hierarchy, so that it is not considered an outer cache anymore. For processors like A15/A7 flush_cache_all() ends up cleaning all cache levels up to Level of Coherency (LoC) that includes the L2 unified cache. When a single CPU is suspended (CPU idle) a complete L2 clean is not required, so generic cpu_suspend code must clean the data cache using the newly introduced cache LoUIS function. Git bisect identified this patch, in the mainline as commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560 Author: Lorenzo Pieralisi lorenzo.pieral...@arm.com Date: Fri Sep 7 11:06:57 2012 +0530 ARM: kernel: update cpu_suspend code to use cache LoUIS operations as the culprit of the broken wake up from STR on mackerel, based on an sh7372 A8 SoC. .config attached. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/# CONFIG_ARM_PATCH_PHYS_VIRT is not set CONFIG_EXPERIMENTAL=y CONFIG_CROSS_COMPILE=arm-none-linux-gnueabi- CONFIG_LOCALVERSION=-ap4 # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS_ALL=y CONFIG_EMBEDDED=y CONFIG_SLAB=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_LBDAF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_ARCH_SHMOBILE=y CONFIG_ARCH_SH7372=y CONFIG_MACH_AP4EVB=y CONFIG_MACH_MACKEREL=y CONFIG_MEMORY_SIZE=0x2000 # CONFIG_SH_TIMER_CMT is not set # CONFIG_EM_TIMER_STI is not set # CONFIG_ARM_THUMB is not set CONFIG_AEABI=y CONFIG_FORCE_MAX_ZONEORDER=12 CONFIG_USE_OF=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE=console=ttySC0,115200 console=tty1 earlyprintk=sh-sci.0,115200 CONFIG_KEXEC=y CONFIG_VFP=y CONFIG_NEON=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_PM_RUNTIME=y CONFIG_NET=y CONFIG_PACKET=m CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set CONFIG_INET_DIAG=m CONFIG_INET_UDP_DIAG=m # CONFIG_INET6_XFRM_MODE_TRANSPORT is not set # CONFIG_INET6_XFRM_MODE_TUNNEL is not set # CONFIG_INET6_XFRM_MODE_BEET is not set # CONFIG_IPV6_SIT is not set CONFIG_CFG80211=m CONFIG_CFG80211_WEXT=y CONFIG_MAC80211=m CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_PROC_DEVICETREE=y # CONFIG_BLK_DEV is not set CONFIG_NETDEVICES=y CONFIG_NETCONSOLE=y # CONFIG_NET_VENDOR_BROADCOM is not set # CONFIG_NET_VENDOR_CHELSIO is not set # CONFIG_NET_VENDOR_CIRRUS is not set # CONFIG_NET_VENDOR_FARADAY is not set # CONFIG_NET_VENDOR_INTEL is not set # CONFIG_NET_VENDOR_MARVELL is not set # CONFIG_NET_VENDOR_MICREL is not set # CONFIG_NET_VENDOR_NATSEMI is not set # CONFIG_NET_VENDOR_SEEQ is not set CONFIG_SMSC911X=y # CONFIG_NET_VENDOR_STMICRO is not set # CONFIG_NET_VENDOR_WIZNET is not set CONFIG_MDIO_BITBANG=y # CONFIG_WLAN is not set CONFIG_INPUT_MOUSEDEV=m # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_EVDEV=y # CONFIG_KEYBOARD_ATKBD is not set CONFIG_KEYBOARD_TCA6416=y CONFIG_KEYBOARD_SH_KEYSC=y # CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_TSC2007=y CONFIG_TOUCHSCREEN_ST1232=y CONFIG_INPUT_MISC=y CONFIG_INPUT_ADXL34X=m # CONFIG_SERIO is not set # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_SH_SCI=y CONFIG_SERIAL_SH_SCI_NR_UARTS=8 CONFIG_SERIAL_SH_SCI_CONSOLE=y CONFIG_SERIAL_SH_SCI_DMA=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_SH_MOBILE=y CONFIG_SPI=y CONFIG_SPI_GPIO=m CONFIG_GPIO_SYSFS=y CONFIG_POWER_SUPPLY=y # CONFIG_HWMON is not set CONFIG_SSB=m CONFIG_SSB_SDIOHOST=y CONFIG_REGULATOR=y CONFIG_REGULATOR_DUMMY=y CONFIG_MEDIA_SUPPORT=m CONFIG_MEDIA_CAMERA_SUPPORT=y CONFIG_MEDIA_CONTROLLER=y CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_VIDEO_ADV_DEBUG=y CONFIG_VIDEO_OV7670=m CONFIG_VIDEO_VIVI=m CONFIG_V4L_PLATFORM_DRIVERS=y CONFIG_VIDEO_SH_VOU=m CONFIG_SOC_CAMERA=m CONFIG_SOC_CAMERA_IMX074=m CONFIG_SOC_CAMERA_MT9M111=m CONFIG_SOC_CAMERA_MT9T112=m CONFIG_SOC_CAMERA_MT9V022=m CONFIG_SOC_CAMERA_PLATFORM=m CONFIG_SOC_CAMERA_OV5642=m CONFIG_VIDEO_SH_MOBILE_CSI2=m CONFIG_VIDEO_SH_MOBILE_CEU=m CONFIG_V4L_MEM2MEM_DRIVERS=y CONFIG_VIDEO_MEM2MEM_TESTDEV=m CONFIG_FB=y CONFIG_FB_SH_MOBILE_LCDC=y # CONFIG_LCD_CLASS_DEVICE is not set # CONFIG_BACKLIGHT_GENERIC is not set CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
Hi Will On Tue, 11 Dec 2012, Will Deacon wrote: On Tue, Dec 11, 2012 at 04:33:13PM +, Will Deacon wrote: On Tue, Dec 11, 2012 at 04:07:56PM +, Guennadi Liakhovetski wrote: Git bisect identified this patch, in the mainline as commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560 Author: Lorenzo Pieralisi lorenzo.pieral...@arm.com Date: Fri Sep 7 11:06:57 2012 +0530 ARM: kernel: update cpu_suspend code to use cache LoUIS operations as the culprit of the broken wake up from STR on mackerel, based on an sh7372 A8 SoC. .config attached. My guess is that because Cortex-A8 does not implement the MP extensions, the LoUIS field of the CLIDR reads as zero, and the cache isn't flushed at all (I can see an early exit in v7_flush_dcache_louis). Lorenzo -- how is this supposed to work for uniprocessor CPUs? Bah, forgot to ask you if the following patch helps... Yes, it does. Thanks Guennadi Will ---8 diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Tue, 11 Dec 2012, Will Deacon wrote: On Tue, Dec 11, 2012 at 04:33:13PM +, Will Deacon wrote: On Tue, Dec 11, 2012 at 04:07:56PM +, Guennadi Liakhovetski wrote: Git bisect identified this patch, in the mainline as commit dbee0c6fb4c1269b2dfc8b0b7a29907ea7fed560 Author: Lorenzo Pieralisi lorenzo.pieral...@arm.com Date: Fri Sep 7 11:06:57 2012 +0530 ARM: kernel: update cpu_suspend code to use cache LoUIS operations as the culprit of the broken wake up from STR on mackerel, based on an sh7372 A8 SoC. .config attached. My guess is that because Cortex-A8 does not implement the MP extensions, the LoUIS field of the CLIDR reads as zero, and the cache isn't flushed at all (I can see an early exit in v7_flush_dcache_louis). Lorenzo -- how is this supposed to work for uniprocessor CPUs? Bah, forgot to ask you if the following patch helps... Will ---8 diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index cd95664..f58248f 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -44,7 +44,8 @@ ENDPROC(v7_flush_icache_all) ENTRY(v7_flush_dcache_louis) dmb @ ensure ordering with previous memory accesses mrc p15, 1, r0, c0, c0, 1 @ read clidr, r0 = clidr - andsr3, r0, #0xe0 @ extract LoUIS from clidr + ALT_SMP(andsr3, r0, #(7 21)) @ extract LoUIS from clidr + ALT_UP(ands r3, r0, #(7 27)) @ extract LoUU from clidr mov r3, r3, lsr #20 @ r3 = LoUIS * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 [... later] Yes, it does. Cracking, can I add you tested-by please? Sure: Tested-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 237/493] mmc: remove use of __devinit
On Mon, 19 Nov 2012, Bill Pemberton wrote: drivers/mmc/host/sh_mmcif.c| 2 +- drivers/mmc/host/sh_mobile_sdhi.c | 2 +- drivers/mmc/host/tmio_mmc.c| 2 +- drivers/mmc/host/tmio_mmc_pio.c| 2 +- Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 414/493] mmc: remove use of __devexit
On Mon, 19 Nov 2012, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. drivers/mmc/host/sh_mmcif.c| 2 +- drivers/mmc/host/tmio_mmc.c| 2 +- Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 077/493] mmc: remove use of __devexit_p
On Mon, 19 Nov 2012, Bill Pemberton wrote: drivers/mmc/host/sh_mobile_sdhi.c | 2 +- drivers/mmc/host/tmio_mmc.c| 2 +- Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 1/2] of: Add generic device tree DMA helpers
Hi Vinod On Fri, 13 Jul 2012, Vinod Koul wrote: On Wed, 2012-06-27 at 15:20 +, Arnd Bergmann wrote: [snip] Do you mean there must be a global table, or are you ok with putting the information about a channel into the device that uses the channel, as we do for most other subsystems (IRQ, GPIO, pinctrl, ...). If not, what is the problem with that approach? Today, we simple ask, give me dma channel with DMA_SLAVE capability. If we change it to give me dma channel which suits my need and have additional information in dmaengine to handle this request effectively. What that would mean is a) DMA channel either knows which channel to provide, Or b) Additional arguments provided to dmaengine API to help it find out which channel to provide. It would be good to have client ask for a specific channel. But in order to build generic clients, we face a problem that clients may not know how they mapped to dmac by SoC designer. Or the mux maybe entirely flexible on which channel. If we add this as DT property (which I assume should be platform specific), then client will know which channel to request. It can have two levels, dmac and channel. In case mux is flexible enough then client gets a channel and program the mux for this mapping. I think this is the most simplistic solution I have for this, thoughts? How about this my idea: http://thread.gmane.org/gmane.linux.ports.arm.omap/75828/focus=15501 A small correction to it would be, that it shouldn't (necessarily) be a separate driver, because in some cases the mux resides on the DMAC, they share registers, so, it shouldn't really be a separate device and a separate driver, don't think it's worth an MFD set up or anything similar. So, I am trying ATM to implement something along the lines of struct dma_chan *dma_request_slave_channel(struct device *dev, enum dma_transfer_direction direction, const char *name); The connection between clients and the mux is always static, so, the dmaengine core can always just pass to the mux a client-side pad specifier (dev + direction + (optionally) name). The mux call-back will then see, where it can connect that pad and return a suitable channel descriptor - possibly with the help of the DMAC driver proper. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 1/2] of: Add generic device tree DMA helpers
On Mon, 25 Jun 2012, Arnd Bergmann wrote:
[snip]
The channel data in the device tree is still in a format
that is specific to that dmaengine driver and interpreted
by it. Using the regular dma_filter_fn prototype is not
necessary, but it would be convenient because the dmaengine
code already knows how to deal with it. If we don't use this
method, how about adding another callback to struct dma_device
like
bool (*device_match)(struct dma_chan *chan, struct property *req);
I like this idea, but why don't we extend it to also cover the non-DT
case? I.e., why don't we add the above callback (call it match or
filter or anything else) to dmaengine operations and inside (the
extended) dma_request_channel(), instead of calling the filter function,
passed as a parameter, we loop over all registered DMAC devices and call
their filter callbacks, until one of them returns true? In fact, it goes
back to my earlier proposal from
http://thread.gmane.org/gmane.linux.kernel/1246957
which I, possibly, failed to explain properly. So, the transformation
chain from today's API would be (all code is approximate):
(today)
client driver
dma_request_channel(mask, filter, filter_arg);
dmaengine_core
for_each_channel() {
ret = (*filter)(chan, filter_arg);
if (ret) {
ret = chan-device-device_alloc_chan_resources(chan);
if (!ret)
return chan;
else
return NULL;
}
}
(can be transformed to)
client driver
dma_request_channel(mask, filter_arg);
dmaengine_core
for_each_channel() {
ret = chan-device-filter(chan, filter_arg);
if (ret) {
same as above
}
}
(which further could be simplified to)
client driver
dma_request_channel(mask, filter_arg);
dmaengine_core
for_each_channel() {
ret = chan-device-device_alloc_chan_resources(chan,
filter_arg);
if (!ret)
return chan;
else if (ret != -ENODEV)
return ret;
/* -ENODEV - try the next channel */
}
Which is quite similar to my above mentioned proposal. Wouldn't this both
improve the present API and prepare it for DT?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 1/2] of: Add generic device tree DMA helpers
Hi Arnd
On Fri, 6 Jul 2012, Arnd Bergmann wrote:
On Friday 06 July 2012, Guennadi Liakhovetski wrote:
On Mon, 25 Jun 2012, Arnd Bergmann wrote:
[snip]
The channel data in the device tree is still in a format
that is specific to that dmaengine driver and interpreted
by it. Using the regular dma_filter_fn prototype is not
necessary, but it would be convenient because the dmaengine
code already knows how to deal with it. If we don't use this
method, how about adding another callback to struct dma_device
like
bool (*device_match)(struct dma_chan *chan, struct property *req);
I like this idea, but why don't we extend it to also cover the non-DT
case? I.e., why don't we add the above callback (call it match or
filter or anything else) to dmaengine operations and inside (the
extended) dma_request_channel(), instead of calling the filter function,
passed as a parameter, we loop over all registered DMAC devices and call
their filter callbacks, until one of them returns true? In fact, it goes
back to my earlier proposal from
http://thread.gmane.org/gmane.linux.kernel/1246957
which I, possibly, failed to explain properly. So, the transformation
chain from today's API would be (all code is approximate):
...
dmaengine_core
for_each_channel() {
ret = chan-device-device_alloc_chan_resources(chan,
filter_arg);
if (!ret)
return chan;
else if (ret != -ENODEV)
return ret;
/* -ENODEV - try the next channel */
}
Which is quite similar to my above mentioned proposal. Wouldn't this both
improve the present API and prepare it for DT?
How would the individual driver know the size of the filter_arg?
In exactly the same way as most dmaengine drivers do it today: they don't
touch filter_arg until they're sure this is one of their channels. And
this they typically do by comparing the driver pointer, e.g.:
bool sa11x0_dma_filter_fn(struct dma_chan *chan, void *param)
{
if (chan-device-dev-driver == sa11x0_dma_driver.driver) {
Thanks
Guennadi
In the
device tree code, we would know if from #dma-cells of the engine node,
and that gets checked when reading the property, but when you have
a free-form data structure, it's much less clear.
Also, you could easily have an argument that looks valid for more than one
dmaengine, but really isn't.
I think for your proposal to work, we would need something like the
phandle for the dmaengine device that is at the start of the property
in the DT case.
Arnd
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 1/2] of: Add generic device tree DMA helpers
On Fri, 6 Jul 2012, Russell King - ARM Linux wrote:
On Fri, Jul 06, 2012 at 01:36:32PM +0200, Guennadi Liakhovetski wrote:
I like this idea, but why don't we extend it to also cover the non-DT
case? I.e., why don't we add the above callback (call it match or
filter or anything else) to dmaengine operations and inside (the
extended) dma_request_channel(), instead of calling the filter function,
passed as a parameter, we loop over all registered DMAC devices and call
their filter callbacks, until one of them returns true? In fact, it goes
back to my earlier proposal from
http://thread.gmane.org/gmane.linux.kernel/1246957
which I, possibly, failed to explain properly. So, the transformation
chain from today's API would be (all code is approximate):
(today)
client driver
dma_request_channel(mask, filter, filter_arg);
dmaengine_core
for_each_channel() {
ret = (*filter)(chan, filter_arg);
if (ret) {
ret = chan-device-device_alloc_chan_resources(chan);
if (!ret)
return chan;
else
return NULL;
}
}
(can be transformed to)
client driver
dma_request_channel(mask, filter_arg);
dmaengine_core
for_each_channel() {
ret = chan-device-filter(chan, filter_arg);
if (ret) {
same as above
}
}
(which further could be simplified to)
client driver
dma_request_channel(mask, filter_arg);
dmaengine_core
for_each_channel() {
ret = chan-device-device_alloc_chan_resources(chan,
filter_arg);
This looks like you're re-purposing a perfectly good API for something that
it wasn't designed to do, namely providing a channel selection mechanism,
rather than allocating channel resources. The hint is in the bloody
name, please take a look sometime!
If you want to call into the DMA engine driver for channel selection,
then create an _explicit_ API for it. Don't bugger around with existing
APIs.
Sure, it's better to create a new call-back.
Moreover, the *big* problem that your proposal above creates is this.
What _type_ is filter_arg? If it's void *, then your suggestion is
nonsense, even if you associate it with a size argument. You have no
idea what the bytestream that would be passed via that pointer means,
even if the size just happens to look like it's what you expect.
Right, thanks to you and Arnd, who has pointed this out too.
Then it seems to me, that we need to introduce a notion of a mux device.
We could of course try to just use some strings instead, arrays of
acceptable DMA devices and channels, and most likely we would even be able
to find such an approach, that would work for all existing configurations.
But it still wouldn't be really fully generic, right? Whereas creating a
mux driver we really could cover all possible cases. DMA clients in this
case would always be hard wired to only one pin of such a mux, the DMA
device on the other side also only has to care about its physical
channels. The dmaengine core would then query the mux driver, where it can
route specific client request lines?
A separate mux is needed, because several clients can have their DMA
handshake lines routed to several DMAC instances, so, this muxing
functionality can neither reside on the client nor on the CMAC.
Is this a right direction now? Shall I try to prototype such a DMA mux
API?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 1/2] of: Add generic device tree DMA helpers
Hi Arnd
Sorry for a delayed reply, we had to discuss this your idea internally
first before replying.
On Fri, 15 Jun 2012, Arnd Bergmann wrote:
On Friday 15 June 2012, Guennadi Liakhovetski wrote:
In the common case, you could have one device connected to the third
slave ID of the first controller but the fifth slave ID of the
second controller. In this case, you really have to specify each
controller with its slave ID separately, even if that means a lot
of duplicate data for shmobile.
So, you don't think it's worth making a short-cut possible to specify a
DMAC type instead of each instance phandle? It really would mean __a lot__
of duplication - with 3 generic controllers on (some) current chips and
possibly more on those, that I'm not aware about.
It's certainly possible to make that short-cut, but I'm not convinced
if it's worth it. One thing you can do is create a meta-device for
all of the identical DMA controllers, and refer to that one from the
devices, but make it a separate device node from the actual controllers,
of which you can have more than one. This makes the binding for your
dma controller more complex but reduces the amount of data required
in the other device nodes.
In case of sh7372, this could look something like
dma: dmac-mux {
compatible = renesas,sh-dma-mux;
#dma-cells = 4; /* slave-id, addr, chcr, mid-rid */
#address-cells = 1;
#size-cells = 1;
ranges;
dmae@0xfe008020{
compatible = renesas,sh-dma;
reg = 0xfe008020 0xfe00828f
0xfe009000 0xfe00900b
interrupts = 0x20c0 0x2000 0x2020 0x2040 0x2060 0x2080
0x20a0;
};
dmae@0xfe018020{
compatible = renesas,sh-dma;
reg = 0xfe018020 0xfe01828f
0xfe019000 0xfe01900b
interrupts = 0x21c0 0x2100 0x2120 0x2140 0x2160 0x2180
0x21a0;
};
dmae@0xfe028020{
compatible = renesas,sh-dma;
reg = 0xfe028020 0xfe02828f
0xfe029000 0xfe02900b
interrupts = 0x22c0 0x2200 0x2220 0x2240 0x2260 0x2280
0x22a0;
};
};
This way, a slave would refer to the dmac-mux node and while
the device driver binds to the child nodes.
Indeed, this solution should be good enough, thanks! I'm not sure, whether
making this multiplexing available requires any additional code to the
generic DMA DT binding implementation. If it does - please, let's make
this a part of the implementation.
It is also important to provide a flexible multiple channel per device
configuration support to let slave drivers distinguish between different
DMA channels, that they get back from the API. But I think this is a part
of the current proposal and is being taken care of.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 1/2] of: Add generic device tree DMA helpers
On Thu, 14 Jun 2012, Jon Hunter wrote: On 06/14/2012 10:17 AM, Guennadi Liakhovetski wrote: Hi all Sorry for jumping in so late in the game. But I think, the model, to which this discussion is slowly converging, is not very well suitable for the shdma DMACs, present on SH and ARM sh-mobile SoCs. I might be wrong and the model is indeed suitable, in which case I'd be grateful, if someone could explain, how this model could be used for shdma. Below I'll try to describe main properties of shdma served DMACs, I've done this a couple of times before during various dmaengine related discussions. Let's see how we can use this model for these SoCs. On Sat, 9 Jun 2012, Arnd Bergmann wrote: On Friday 08 June 2012, Jon Hunter wrote: [snip] It seems to me we were pretty close on alignment. In fact, I was quite happy with Steven's 2nd to last proposal of ... simple 1 req: dmas = 0 dmac1 xxx; simple 2 req: dmas = 0 dmac1 xxx 1 dmac1 yyy; multiple dmacs: dmas = 0 dmac1 xxx 0 dmac2 zzz 1 dmac1 yyy; A typical sh-mobile SoC contains several DMAC instances of several sub-types, all served by the same driver. Let's take sh7372 to be specific (see arch/arm/mach-shmobile/setup-sh7372.c for details). On sh7372 we've got 3 generic DMAC instances and 2 dedicated USB DMACs. Generic DMACs have 6 physical channels each, USB DMACs 2. For OMAP we also have dedicated DMAC for the USB controllers. However, these DMAC are very much integrated into the USB controller itself. Hence, in the of OMAP we would only be using the binding really to handle the generic DMAC. However, I would not like to think that this is limited to only generic DMAC. Generic DMACs can perform memory-to-memory DMA, USB DMACs cannot. Generic DMACs can serve any slave (peripheral) request line on any their physical channel, USB DMACs only serve fixed USB controller instances. To configure (connect) a certain physical DMA channel to s specific peripheral request line, a certain value has to be written to a configuration register of that physical DMA channel. Do you still need to specify a request line for the USB DMACs or are these fixed? I personally haven't worked with the renesas_usbhs USB driver or with the respective DMA driver part, but from what I can see, no slave-select values are required, i.e., request lines seem to be fixed. In other words, what purpose would the DMA binding serve for the USB DMACs? The USB driver has to tell the dmaengine which DMAC instances are suitable for it, and which are not. To add to complexity, on other SoCs (e.g., SuperH sh7724) some of generic DMACs (DMAC0) have external DMA request pins, others don't. OMAP also has this. To me an request line going to an external pin can be handled in the same way as one going to a internal peripheral. However, what happens to that pin externally is a different story. As has been discussed before, the presence of external DMA request lines makes specifying fixed DMA channel maps in SoC dtsi files impossible. I'm sure there's more to that, but that's about the scope, that's currently supported or wants to be supported by the driver. Currently we do the slave-switching in the following way: platform data for each DMAC instance references a table of supported peripherals with their IDs and configuration register values. Each peripheral, that wishes to use DMA, provides its slave ID to the DMAC driver, by which it checks, whether this peripheral is supported and, if so, finds its configuration, picks up the next free channel and configures it. So, with the above in mind, IIUC, the above DT binding proposal would require us to reference all 3 generic DMAC instances in each slave dmas property? You could if you wanted to have the ability to select 1 out of the 3. However, I would not say it is a hard requirement. You could just provide one. Or you could list all 3, but use some form of match variable to indicate a default DMAC for a given peripheral. Sorry, I don't think artificially limiting the flexibility to just 1 controller is a good option. The option of listing all 3 in each device doesn't seem too good to me either. What if a future SoC version has 5 of them? I really would prefer to have a list of generic DMAC instances somewhere and be able to omit any explicit references to specific DMACs in device DMA bindings. I can also imagine a possibility, that in the future we won't have just one generic DMAC type, but, say, 2 DMAC groups, serving different, but possibly intersecting, sets of devices. In that case I'd just like to be able to specify use group A in the binding. Do I understand correctly, that with the proposed scheme this is impossible? Even if we assume, that for this specific case we don't have to map each physical channel, because so far they are mostly all equal on each DMAC
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
Hi Arnd On Fri, 15 Jun 2012, Arnd Bergmann wrote: On Thursday 14 June 2012, Jon Hunter wrote: Generic DMACs can perform memory-to-memory DMA, USB DMACs cannot. Generic DMACs can serve any slave (peripheral) request line on any their physical channel, USB DMACs only serve fixed USB controller instances. To configure (connect) a certain physical DMA channel to s specific peripheral request line, a certain value has to be written to a configuration register of that physical DMA channel. Do you still need to specify a request line for the USB DMACs or are these fixed? In other words, what purpose would the DMA binding serve for the USB DMACs? If I understood Guennadi right, the DMA engines are the same kind as the other ones, so we really want to use the same bindings for each instance. Exactly, at least they are compatible and are presently handles by the same dma-engine driver. There are some differences in the register layout, I think, which we might need to handle at some point, maybe by specifying different compatible identifiers or by some other means. To add to complexity, on other SoCs (e.g., SuperH sh7724) some of generic DMACs (DMAC0) have external DMA request pins, others don't. OMAP also has this. To me an request line going to an external pin can be handled in the same way as one going to a internal peripheral. However, what happens to that pin externally is a different story. Right, I don't see a problem here with any of the proposed binding. I'm sure there's more to that, but that's about the scope, that's currently supported or wants to be supported by the driver. Currently we do the slave-switching in the following way: platform data for each DMAC instance references a table of supported peripherals with their IDs and configuration register values. Each peripheral, that wishes to use DMA, provides its slave ID to the DMAC driver, by which it checks, whether this peripheral is supported and, if so, finds its configuration, picks up the next free channel and configures it. So, with the above in mind, IIUC, the above DT binding proposal would require us to reference all 3 generic DMAC instances in each slave dmas property? You could if you wanted to have the ability to select 1 out of the 3. However, I would not say it is a hard requirement. You could just provide one. Or you could list all 3, but use some form of match variable to indicate a default DMAC for a given peripheral. Right. From the description above, it seems that shmobile is actually simpler than some of the others because the slave ID is always the same for each of the controllers. Exactly. In the common case, you could have one device connected to the third slave ID of the first controller but the fifth slave ID of the second controller. In this case, you really have to specify each controller with its slave ID separately, even if that means a lot of duplicate data for shmobile. So, you don't think it's worth making a short-cut possible to specify a DMAC type instead of each instance phandle? It really would mean __a lot__ of duplication - with 3 generic controllers on (some) current chips and possibly more on those, that I'm not aware about. I'm not sure I understand what the configuration register values above are. As I explained in an earlier mail, those include transfer size and other parameters, but cannot be completely calculated in device drivers, because they also vary between SoCs. Most likely, those should all be part of the slave ID, which would then span multiple 32-bit values in the dmas property. Yes, we could do that. Conveniently, that also takes care of removing the DMAC platform data. Right, my only concern so far is a huge redundancy, that accepting and using the proposed scheme would incur. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 1/2] of: Add generic device tree DMA helpers
Hi all Sorry for jumping in so late in the game. But I think, the model, to which this discussion is slowly converging, is not very well suitable for the shdma DMACs, present on SH and ARM sh-mobile SoCs. I might be wrong and the model is indeed suitable, in which case I'd be grateful, if someone could explain, how this model could be used for shdma. Below I'll try to describe main properties of shdma served DMACs, I've done this a couple of times before during various dmaengine related discussions. Let's see how we can use this model for these SoCs. On Sat, 9 Jun 2012, Arnd Bergmann wrote: On Friday 08 June 2012, Jon Hunter wrote: [snip] It seems to me we were pretty close on alignment. In fact, I was quite happy with Steven's 2nd to last proposal of ... simple 1 req: dmas = 0 dmac1 xxx; simple 2 req: dmas = 0 dmac1 xxx 1 dmac1 yyy; multiple dmacs: dmas = 0 dmac1 xxx 0 dmac2 zzz 1 dmac1 yyy; A typical sh-mobile SoC contains several DMAC instances of several sub-types, all served by the same driver. Let's take sh7372 to be specific (see arch/arm/mach-shmobile/setup-sh7372.c for details). On sh7372 we've got 3 generic DMAC instances and 2 dedicated USB DMACs. Generic DMACs have 6 physical channels each, USB DMACs 2. Generic DMACs can perform memory-to-memory DMA, USB DMACs cannot. Generic DMACs can serve any slave (peripheral) request line on any their physical channel, USB DMACs only serve fixed USB controller instances. To configure (connect) a certain physical DMA channel to s specific peripheral request line, a certain value has to be written to a configuration register of that physical DMA channel. To add to complexity, on other SoCs (e.g., SuperH sh7724) some of generic DMACs (DMAC0) have external DMA request pins, others don't. I'm sure there's more to that, but that's about the scope, that's currently supported or wants to be supported by the driver. Currently we do the slave-switching in the following way: platform data for each DMAC instance references a table of supported peripherals with their IDs and configuration register values. Each peripheral, that wishes to use DMA, provides its slave ID to the DMAC driver, by which it checks, whether this peripheral is supported and, if so, finds its configuration, picks up the next free channel and configures it. So, with the above in mind, IIUC, the above DT binding proposal would require us to reference all 3 generic DMAC instances in each slave dmas property? Even if we assume, that for this specific case we don't have to map each physical channel, because so far they are mostly all equal on each DMAC instance. Mostly, because external DMA request lines on sh7724 can only be used with channels 0 and 1 out of 6 of DMAC0... What we certainly don't want to do is specify fixed physical DMA channels or even controller instances in slave DMA bindings. To me it looks like the above proposal would only very suboptimally be usable with sh-mobile SoCs... Thanks Guennadi Arnd, I know that you had some concerns. However, in the above case I would expect that the 3rd parameter be optional and it can be some sort of match variable. In other words, we don't care how the 32-bits are encoded or what they represent but they would be used appropriately by the xlate function being used. So the xlate and this match variable would have to speak the same language. I would at least put the dmac part first to be consistent with other bindings that refer to some node. That controller should then be able to specify the number of additional cells used to describe the dma request. We can define that the first cell after the controller phandle is always the same thing, e.g. the direction (in/out/inout) or a client-specific ID or a combination of that with other predefined bits that are not dependent on dma controller specifics. As I said previously, I think just encoding the direction but not the client specific ID (meaning we would have to disambiguate the more complex cases that Stephen mentioned using a dma-names property) would be the best because it keeps the common case simple, but I could live with other things going in there too. I think that I prefer the idea of having a 3rd optional match variable than encoding the DMA request ID and match data together in 1 32-bit variable. However, not a big deal either way. I agree on that part, I would usually prefer to encode different things in separate cells rather than putting them together into a single cell just because they require less than 32 bits combined. Arnd --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v2 2/5] [media] v4l: Add support for mt9t111 sensor driver
Hi Deepthy
(personally, I don't think this long CC list is justified, you might want
to drop most of them on the next round, but it's up to you eventually)
Nice, that you managed to re-use the existing mt9t112 driver and extend it
to work outside of soc-camera and with mt9t111 on omap3. See comments
below.
On Tue, 27 Sep 2011, Deepthy Ravi wrote:
Added support for mt9t111 sensor in the existing
mt9t112 driver. Also added support for media controller
framework. The sensor driver currently supports only
VGA resolution.
I think we should support same resolutions on mt9t111 as what is supported
on mt9t112.
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9t111_reg.h | 1367
+
drivers/media/video/mt9t112.c | 320 -
include/media/mt9t111.h | 45 ++
5 files changed, 1704 insertions(+), 36 deletions(-)
create mode 100644 drivers/media/video/mt9t111_reg.h
create mode 100644 include/media/mt9t111.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 14326d7..b5806e8 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -482,6 +482,13 @@ config VIDEO_MT9V032
This is a Video4Linux2 sensor-level driver for the Micron
MT9V032 752x480 CMOS sensor.
+config VIDEO_MT9T111
+ tristate Aptina MT9T111 VGA CMOS IMAGE SENSOR
+ depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
+ ---help---
+ This is a Video4Linux2 sensor-level driver for the Aptina MT9T111
+ image sensor.
+
This is not needed, just add a note to the MT9T112 entry saying, that
mt9t111 is supported too, and remove dependency on soc-camera, add
VIDEO_V4L2 instead. VIDEO_V4L2_SUBDEV_API shouldn't be required.
config VIDEO_TCM825X
tristate TCM825x camera sensor support
depends on I2C VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c06f515..02a8b70 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
obj-$(CONFIG_VIDEO_SR030PC30)+= sr030pc30.o
+obj-$(CONFIG_VIDEO_MT9T111) += mt9t112.o
unneeded
obj-$(CONFIG_VIDEO_NOON010PC30) += noon010pc30.o
obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
obj-$(CONFIG_VIDEO_ADP1653) += adp1653.o
diff --git a/drivers/media/video/mt9t111_reg.h
b/drivers/media/video/mt9t111_reg.h
new file mode 100644
index 000..2f610d4
--- /dev/null
+++ b/drivers/media/video/mt9t111_reg.h
@@ -0,0 +1,1367 @@
+/*
+ * drivers/media/video/mt9t111_reg.h
+ *
+ * mt9t111 sensor driver header file
+ *
+ * Copyright (C) 2009 Leopard Imaging
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef MT9T111_REG_H
+#define MT9T111_REG_H
+
+/* register addr */
+#define MT9T111_CHIP_ID (0x)
+
+/* register value */
+#define MT9T111_CHIP_ID_VALUE(0x2680)
+
+#define MT9T111_IMAGE_WIDTH (640)
+#define MT9T111_IMAGE_HEIGHT (480)
A general note. We assume, that mt9t112 and mt9t111 are _very_ similar and
can be supported by one driver with maybe some _minor_ chip-specific
differences. What you seem to be doing is combine two drivers in one.
Practically duplicating most functionality. If the chips are indeed that
different, we need two drivers. Otherwise you really only should need some
_small_ additions to mt9t112.
+
+typedef struct {
+ u16 delay_time;
+ u16 addr;
+ u16 data;
+} mt9t111_regs;
+
+mt9t111_regs patch_rev6[] = {
+ {0, 0x0982, 0x0},
mt9t112 doesn't need any such register magic. If they are similar, we
shouldn't have to add them for mt9t111 either.
+ {0, 0x098A, 0xCE7},
+ {0, 0x0990, 0x3C3C},
+ {0, 0x0992, 0x3C3C},
+ {0, 0x0994, 0x3C5F},
+ {0, 0x0996, 0x4F30},
+ {0, 0x0998, 0xED08},
+ {0, 0x099a, 0xBD61},
+ {0, 0x099c, 0xD5CE},
+ {0, 0x099e, 0x4CD},
+ {0, 0x098A, 0xCF7},
+ {0, 0x0990, 0x1F17},
+ {0, 0x0992, 0x211},
+ {0, 0x0994, 0xCC33},
+ {0, 0x0996, 0x2E30},
+ {0, 0x0998, 0xED02},
+ {0, 0x099a, 0xCCFF},
+ {0, 0x099c, 0xFDED},
+ {0, 0x099e, 0xCC},
+ {0, 0x098A, 0xD07},
+ {0, 0x0990, 0x2},
+ {0, 0x0992, 0xBD70},
+ {0, 0x0994, 0x6D18},
+ {0, 0x0996, 0xDE1F},
+ {0, 0x0998, 0x181F},
+ {0, 0x099a, 0x8E01},
+ {0, 0x099c, 0x10CC},
+ {0, 0x099e, 0x3C52},
+ {0, 0x098A, 0xD17},
+ {0, 0x0990, 0x30ED},
+ {0, 0x0992, 0x18},
+ {0, 0x0994, 0xECA0},
+ {0, 0x0996, 0xC4FD},
+ {0, 0x0998, 0xBD70},
+ {0,
Re: [PATCH 37/57] mmc: irq: Remove IRQF_DISABLED
On Wed, 21 Sep 2011, Yong Zhang wrote:
Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn when handler enables interrupts]).
So now this flag is a NOOP and can be removed.
Signed-off-by: Yong Zhang yong.zha...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c |5 ++---
drivers/mmc/host/tmio_mmc.c |4 ++--
For tmio_mmc.c:
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Thanks
Guennadi
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..75c6395 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2015,7 +2015,7 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
}
/* Request IRQ for MMC operations */
- ret = request_irq(host-irq, omap_hsmmc_irq, IRQF_DISABLED,
+ ret = request_irq(host-irq, omap_hsmmc_irq, 0,
mmc_hostname(mmc), host);
if (ret) {
dev_dbg(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n);
@@ -2043,8 +2043,7 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
if ((mmc_slot(host).card_detect_irq)) {
ret = request_irq(mmc_slot(host).card_detect_irq,
omap_hsmmc_cd_handler,
- IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
- | IRQF_DISABLED,
+ IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING,
mmc_hostname(mmc), host);
if (ret) {
dev_dbg(mmc_dev(host-mmc),
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index 44a9668..a4ea102 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -88,8 +88,8 @@ static int __devinit tmio_mmc_probe(struct platform_device
*pdev)
if (ret)
goto cell_disable;
- ret = request_irq(irq, tmio_mmc_irq, IRQF_DISABLED |
- IRQF_TRIGGER_FALLING, dev_name(pdev-dev), host);
+ ret = request_irq(irq, tmio_mmc_irq, IRQF_TRIGGER_FALLING,
+ dev_name(pdev-dev), host);
if (ret)
goto host_remove;
--
1.7.4.1
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/5] [media] v4l: Add mt9t111 sensor driver
On Tue, 20 Sep 2011, Deepthy Ravi wrote: From: Vaibhav Hiremath hvaib...@ti.com The MT9T111 is a 3.1Mp CMOS sensor from Aptina with its latest image signal processing (ISP) and 1.75ÃŽÅ’m pixel technology. The sensor driver currently supports only VGA resolution. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Deepthy Ravi deepthy.r...@ti.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mt9t111.c | 793 + drivers/media/video/mt9t111_reg.h | 1367 + include/media/mt9t111.h | 45 ++ 5 files changed, 2213 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/mt9t111.c create mode 100644 drivers/media/video/mt9t111_reg.h create mode 100644 include/media/mt9t111.h NAK. The mt9t112 driver claims to also support mt9t111. I'm not sure, whether the driver has indeed been tested with mt9t111, but this is definitely something to verify. If the chips are indeed similar, please use the tree at http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/shortlog/refs/heads/rc1-for-3.2 which has converted the mt9t112 driver to be also used outside ot the soc-camera subsystem, and use that driver instead of adding another one. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v2] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi
On Sun, 18 Sep 2011, Laurent Pinchart wrote:
Hi Martin,
On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 183
+++ 2 files changed, 184 insertions(+), 0
deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Changes in V2:
* ported to current mainline
* Style fixes
* Fix error handling
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..8ae3d25 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO)+=
board-omap3logic.o \ obj-$(CONFIG_MACH_OVERO) +=
board-overo.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
+ board-omap3evm-camera.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644
index 000..be987d9
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,183 @@
[snip]
+static int __init camera_init(void)
+{
+ int ret = -EINVAL;
+
+ omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
+ if (gpio_request(nCAM_VD_SEL, nCAM_VD_SEL) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n,
+ nCAM_VD_SEL);
+ goto err;
+ }
+ if (gpio_direction_output(nCAM_VD_SEL, 1) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO nCAM_VD_SEL(%d)
direction\n, +nCAM_VD_SEL);
+ goto err_vdsel;
+ }
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 2, T2_GPIO2) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO T2_GPIO2(%d)\n,
+ EVM_TWL_GPIO_BASE + 2);
+ goto err_vdsel;
+ }
+ if (gpio_direction_output(EVM_TWL_GPIO_BASE + 2, 0) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO T2_GPIO2(%d)
direction\n,
+ EVM_TWL_GPIO_BASE + 2);
+ goto err_2;
+ }
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 8, nCAM_VD_EN) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_EN(%d)\n,
+ EVM_TWL_GPIO_BASE + 8);
+ goto err_2;
+ }
+ if (gpio_direction_output(EVM_TWL_GPIO_BASE + 8, 0) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO nCAM_VD_EN(%d)
direction\n,
+ EVM_TWL_GPIO_BASE + 8);
+ goto err_8;
+ }
+
+ omap3evm_set_mux(MUX_CAMERA_SENSOR);
+
+
+ ret = omap3_init_camera(isp_platform_data);
+ if (ret 0)
+ goto err_8;
+ return 0;
+
+err_8:
+ gpio_free(EVM_TWL_GPIO_BASE + 8);
+err_2:
+ gpio_free(EVM_TWL_GPIO_BASE + 2);
+err_vdsel:
+ gpio_free(nCAM_VD_SEL);
+err:
+ return ret;
+}
+
+device_initcall(camera_init);
Please don't use device_initcall(), but call the function directly from the
OMAP3 EVM init handler. Otherwise camera_init() will be called if OMAP3 EVM
support is compiled in the kernel, regardless of the board the kernel runs on.
Another possibility is to put
if (!machine_is_omap3evm())
return 0;
in the beginning of the function. Probably, best to follow what other
omap3 boards do.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: [RFC PATCH] HDMI:Support for EDID parsing in kernel.
On Thu, 24 Mar 2011, K, Mythri P wrote: Hi Jesse, On Wed, Mar 23, 2011 at 8:48 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 23 Mar 2011 18:58:27 +0530 K, Mythri P mythr...@ti.com wrote: Hi Dave, On Wed, Mar 23, 2011 at 6:16 AM, Dave Airlie airl...@gmail.com wrote: On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K mythr...@ti.com wrote: Adding support for common EDID parsing in kernel. EDID - Extended display identification data is a data structure provided by a digital display to describe its capabilities to a video source, This a standard supported by CEA and VESA. There are several custom implementations for parsing EDID in kernel, some of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally parsing of EDID should be done in a library, which is agnostic of the framework (V4l2, DRM, FB) Â which is using the functionality, just based on the raw EDID pointer with size/segment information. With other RFC's such as the one below, which tries to standardize HDMI API's It would be better to have a common EDID code in one place.It also helps to provide better interoperability with variety of TV/Monitor may be even by listing out quirks which might get missed with several custom implementation of EDID. http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401 This patch tries to add functions to parse some portion EDID (detailed timing, monitor limits, AV delay information, deep color mode support, Audio and VSDB) If we can align on this library approach i can enhance this library to parse other blocks and probably we could also add quirks from other implementation as well. If you want to take this approach, you need to start from the DRM EDID parser, its the most well tested and I can guarantee its been plugged into more monitors than any of the others. There is just no way we would move the DRM parser to a library one that isn't derived from it + enhancements, as we'd throw away the years of testing and the regression count would be way too high. I had a look at the DRM EDID code, but for quirks it looks pretty much the same. yes i could take quirks and other DRM tested code and enhance, but still the code has to do away with struct drm_display_mode which is very much custom to DRM. If that's the only issue you have, we could easily rename that structure or add conversion funcs to a smaller structure if that's what you need. Dave's point is that we can't ditch the existing code without introducing a lot of risk; it would be better to start a library-ized EDID codebase from the most complete one we have already, i.e. the DRM EDID code. Does the DRM EDID-parser also process blocks beyond the first one and also parses SVD entries similar to what I've recently added to fbdev? Yes, we definitely need a common EDID parses, and maybe we'll have to collect various pieces from different implementations. Thanks Guennadi This sounds good. If we can remove the DRM dependent portion to have a library-ized EDID code, That would be perfect. The main Intention to have a library is, Instead of having several different Implementation in kernel, all doing the same EDID parsing , if we could have one single implementation , it would help in better testing and interoperability. Do you really think the differences between your code and the existing DRM code are irreconcilable? On the contrary if there is a library-ized EDID parsing using the drm_edid, and there is any delta / fields( Parsing the video block in CEA extension for Short Video Descriptor, Vendor block for AV delay /Deep color information etc) that are parsed with the RFC i posted i would be happy to add. Thanks and regards, Mythri. -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] SoC Camera: add driver for OMAP1 camera interface
Hi Janusz You might want to retest ams-delta with the camera on the current (next or git://linuxtv.org/media_tree.git staging/for_v2.6.39 ) kernel - I suspect, you'll need something similar to http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/30728 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
beagleboard-xm network with mainline?
Hi I managed to bring a mainline 2.6.36 kinda kernel to run on my bbxm, Debian rootfs in mmcblk0p2, but I'm getting no connection - neither over the SMSC chip, nor over usb-device in gadget mode, nor can I power on the on-board hub to plug in a usb-to-eth dongle. What's the catch? How do I configure the kernel to get any of those to work? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: beagleboard-xm network with mainline?
Hi Felipe On Tue, 7 Dec 2010, Felipe Balbi wrote: Hi, On Tue, Dec 07, 2010 at 10:42:45AM +0100, Guennadi Liakhovetski wrote: I managed to bring a mainline 2.6.36 kinda kernel to run on my bbxm, Debian rootfs in mmcblk0p2, but I'm getting no connection - neither over the SMSC chip, nor over usb-device in gadget mode, nor can I power on the on-board hub to plug in a usb-to-eth dongle. What's the catch? How do I configure the kernel to get any of those to work? how about you try with current linux-omap HEAD ? Or linux-mainline HEAD ? Sure, can try, but do you have a specific change in mind or is it just a general suggestion? Which interface should work then? Lots has changed since 2.6.36. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: beagleboard-xm network with mainline?
On Tue, 7 Dec 2010, Felipe Balbi wrote: Hi, On Tue, Dec 07, 2010 at 10:56:45AM +0100, Guennadi Liakhovetski wrote: On Tue, Dec 07, 2010 at 10:42:45AM +0100, Guennadi Liakhovetski wrote: I managed to bring a mainline 2.6.36 kinda kernel to run on my bbxm, Debian rootfs in mmcblk0p2, but I'm getting no connection - neither over the SMSC chip, nor over usb-device in gadget mode, nor can I power on the on-board hub to plug in a usb-to-eth dongle. What's the catch? How do I configure the kernel to get any of those to work? how about you try with current linux-omap HEAD ? Or linux-mainline HEAD ? Sure, can try, but do you have a specific change in mind or is it just a general suggestion? Which interface should work then? Just a general suggestion. Compile with omap2plus_defconfig. Should boot fine AFAIK. That's the one I used, right. Also, do you have the driver for the external hub + ethernet enabled ? I think it's called sms9x or something similar. Yes for CONFIG_USB_NET_SMSC95XX=y but I don't see any config option for the hub? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: beagleboard-xm network with mainline?
On Tue, 7 Dec 2010, Koen Kooi wrote: Op 7 dec 2010, om 10:42 heeft Guennadi Liakhovetski het volgende geschreven: Hi I managed to bring a mainline 2.6.36 kinda kernel to run on my bbxm, Debian rootfs in mmcblk0p2, but I'm getting no connection - neither over the SMSC chip, nor over usb-device in gadget mode, nor can I power on the on-board hub to plug in a usb-to-eth dongle. What's the catch? How do I configure the kernel to get any of those to work? Give http://gitorious.org/angstrom/angstrom-linux/commit/c908140c053071789dfa72f34bee76223ba9bdb7 a try. Great, that works, thanks! The branch at http://gitorious.org/angstrom/angstrom-linux/commits/koen/beagle-next has a dozen or so patches to get all beagleboards working with 2.6.37rcX from Tony. Regards Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] SoC Camera: add driver for OMAP1 camera interface
Same with this one - let's take it as is and address a couple of clean-ups
later.
On Thu, 30 Sep 2010, Janusz Krzysztofik wrote:
+static void omap1_videobuf_queue(struct videobuf_queue *vq,
+ struct videobuf_buffer *vb)
+{
+ struct soc_camera_device *icd = vq-priv_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct omap1_cam_dev *pcdev = ici-priv;
+ struct omap1_cam_buf *buf;
+ u32 mode;
+
+ list_add_tail(vb-queue, pcdev-capture);
+ vb-state = VIDEOBUF_QUEUED;
+
+ if (pcdev-active) {
+ /*
+ * Capture in progress, so don't touch pcdev-ready even if
+ * empty. Since the transfer of the DMA programming register set
+ * content to the DMA working register set is done automatically
+ * by the DMA hardware, this can pretty well happen while we
+ * are keeping the lock here. Levae fetching it from the queue
Leave
+ * to be done when a next DMA interrupt occures instead.
+ */
+ return;
+ }
superfluous braces
+static void videobuf_done(struct omap1_cam_dev *pcdev,
+ enum videobuf_state result)
+{
+ struct omap1_cam_buf *buf = pcdev-active;
+ struct videobuf_buffer *vb;
+ struct device *dev = pcdev-icd-dev.parent;
+
+ if (WARN_ON(!buf)) {
+ suspend_capture(pcdev);
+ disable_capture(pcdev);
+ return;
+ }
+
+ if (result == VIDEOBUF_ERROR)
+ suspend_capture(pcdev);
+
+ vb = buf-vb;
+ if (waitqueue_active(vb-done)) {
+ if (!pcdev-ready result != VIDEOBUF_ERROR) {
+ /*
+ * No next buffer has been entered into the DMA
+ * programming register set on time (could be done only
+ * while the previous DMA interurpt was processed, not
+ * later), so the last DMA block, be it a whole buffer
+ * if in CONTIG or its last sgbuf if in SG mode, is
+ * about to be reused by the just autoreinitialized DMA
+ * engine, and overwritten with next frame data. Best we
+ * can do is stopping the capture as soon as possible,
+ * hopefully before the next frame start.
+ */
+ suspend_capture(pcdev);
+ }
superfluous braces
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] SoC Camera: add driver for OMAP1 camera interface
On Sat, 2 Oct 2010, Janusz Krzysztofik wrote:
Saturday 02 October 2010 08:07:28 Guennadi Liakhovetski napisał(a):
Same with this one - let's take it as is and address a couple of clean-ups
later.
Guennadi,
Thanks for taking them both.
BTW, what are your intentions about the last patch from my series still left
not commented, SoC Camera: add support for g_parm / s_parm operations,
http://www.spinics.net/lists/linux-media/msg22887.html ?
Yes, taking that one too, thanks. I see it right, that I have to apply 3
of your patches: omap1 camera driver, ov6650 and default .[gs]_fmt for
soc_camera, the rest will go via the OMAP / ARM tree, right?
On Thu, 30 Sep 2010, Janusz Krzysztofik wrote:
+static void omap1_videobuf_queue(struct videobuf_queue *vq,
+ struct videobuf_buffer *vb)
+{
+ struct soc_camera_device *icd = vq-priv_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
+ struct omap1_cam_dev *pcdev = ici-priv;
+ struct omap1_cam_buf *buf;
+ u32 mode;
+
+ list_add_tail(vb-queue, pcdev-capture);
+ vb-state = VIDEOBUF_QUEUED;
+
+ if (pcdev-active) {
+ /*
+ * Capture in progress, so don't touch pcdev-ready even if
+ * empty. Since the transfer of the DMA programming register set
+ * content to the DMA working register set is done automatically
+ * by the DMA hardware, this can pretty well happen while we
+ * are keeping the lock here. Levae fetching it from the queue
Leave
Yes, sorry.
+ * to be done when a next DMA interrupt occures instead.
+ */
+ return;
+ }
superfluous braces
I was instructed once to do a reverse in a patch against ASoC subtree (see
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg14863.html), but
TBH, I can't find a clear enough requirement specified in the
Documentation/CodingStyle, so I probably change my habits, at least for you
subtree ;).
Nah, forget it, doesn't matter.
+static void videobuf_done(struct omap1_cam_dev *pcdev,
+ enum videobuf_state result)
+{
+ struct omap1_cam_buf *buf = pcdev-active;
+ struct videobuf_buffer *vb;
+ struct device *dev = pcdev-icd-dev.parent;
+
+ if (WARN_ON(!buf)) {
+ suspend_capture(pcdev);
+ disable_capture(pcdev);
+ return;
+ }
+
+ if (result == VIDEOBUF_ERROR)
+ suspend_capture(pcdev);
+
+ vb = buf-vb;
+ if (waitqueue_active(vb-done)) {
+ if (!pcdev-ready result != VIDEOBUF_ERROR) {
+ /*
+ * No next buffer has been entered into the DMA
+ * programming register set on time (could be done only
+ * while the previous DMA interurpt was processed, not
+ * later), so the last DMA block, be it a whole buffer
+ * if in CONTIG or its last sgbuf if in SG mode, is
+ * about to be reused by the just autoreinitialized DMA
+ * engine, and overwritten with next frame data. Best we
+ * can do is stopping the capture as soon as possible,
+ * hopefully before the next frame start.
+ */
+ suspend_capture(pcdev);
+ }
superfluous braces
ditto.
I'll address the issues when ready with my forementioned corner case fixes.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: [RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
On Thu, 23 Sep 2010, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [100923 16:37]: Friday 24 September 2010 01:23:10 Tony Lindgren napisał(a): I think you can just move the OMAP1_CAMERA_IOSIZE to the devices.c or someplace like that? Tony, Not exactly. I use the OMAP1_CAMERA_IOSIZE inside the driver when reserving space for register cache. I think that I could just duplicate its definition in the devices.c for now, than clean things up with a folloup patch when both parts already get merged. Would this be acceptable? Yeah, that sounds good to me. ...better yet put a zero-length cache array at the end of your struct omap1_cam_dev and allocate it dynamically, calculated from the resource size. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v2 5/6] OMAP1: Amstrad Delta: add support for camera
On Thu, 23 Sep 2010, Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [100923 16:52]: Friday 24 September 2010 01:26:17 Tony Lindgren napisał(a): * Tony Lindgren t...@atomide.com [100923 16:06]: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [100910 18:20]: 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. Queuing these last two patches of the series (5/6 and 6/6) for the upcoming merge window. BTW, these still depend on updated 2/6 to make compile happy. Not so simple: still depends on struct omap1_cam_platform_data definition from media/omap1_camera.h, included from mach/camera.h. Are you ready to accept another temporary workaround? Heh I guess so. Or do you want to queue everything via linux-media? Yes, we often have to select via which tree to go, then the maintainer of the other tree just acks the patches. Sometimes we push them via different trees and try to enforce a specific merge order... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 v2 1/6] SoC Camera: add driver for OMAP1 camera interface
On Wed, 22 Sep 2010, Janusz Krzysztofik wrote:
Wednesday 22 September 2010 01:23:22 Guennadi Liakhovetski napisał(a):
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
+
+ vb = buf-vb;
+ if (waitqueue_active(vb-done)) {
+ if (!pcdev-ready result != VIDEOBUF_ERROR)
+ /*
+ * No next buffer has been entered into the DMA
+ * programming register set on time, so best we can do
+ * is stopping the capture before last DMA block,
+ * whether our CONTIG mode whole buffer or its last
+ * sgbuf in SG mode, gets overwritten by next frame.
+ */
Hm, why do you think it's a good idea? This specific buffer completed
successfully, but you want to fail it just because the next buffer is
missing? Any specific reason for this?
Maybe my comment is not clear enough, but the below suspend_capture() doesn't
indicate any failure on a frame just captured. It only prevents the frame
from being overwritten by the already autoreinitialized DMA engine, pointing
back to the same buffer once again.
Besides, you seem to also be
considering the possibility of your -ready == NULL, but the queue
non-empty, in which case you just take the next buffer from the queue and
continue with it. Why error out in this case?
pcdev-ready == NULL means no buffer was available when it was time to put it
into the DMA programming register set.
But how? Buffers are added onto the list in omap1_videobuf_queue() under
spin_lock_irqsave(); and there you also check -ready and fill it in. In
your completion you set -ready = NULL, but then also call
prepare_next_vb() to get the next buffer from the list - if there are any,
so, how can it be NULL with a non-empty list?
As a result, a next DMA transfer has
just been autoreinitialized with the same buffer parameters as before. To
protect the buffer from being overwriten unintentionally, we have to stop the
DMA transfer as soon as possible, hopefully before the sensor starts sending
out next frame data.
If a new buffer has been queued meanwhile, best we can do is stopping
everything, programming the DMA with the new buffer, and setting up for a new
transfer hardware auto startup on nearest frame start, be it the next one if
we are lucky enough, or one after the next if we are too slow.
And even if also the queue
is empty - still not sure, why.
I hope the above explanation clarifies why.
I'll try to rework the above comment to be more clear, OK? Any hints?
linux-2.6.36-rc3.orig/include/media/omap1_camera.h2010-09-03
22:34:02.0 +0200 +++
linux-2.6.36-rc3/include/media/omap1_camera.h 2010-09-08
23:41:12.0 +0200 @@ -0,0 +1,35 @@
+/*
+ * Header for V4L2 SoC Camera driver for OMAP1 Camera Interface
+ *
+ * Copyright (C) 2010, Janusz Krzysztofik jkrzy...@tis.icnet.pl
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __MEDIA_OMAP1_CAMERA_H_
+#define __MEDIA_OMAP1_CAMERA_H_
+
+#include linux/bitops.h
+
+#define OMAP1_CAMERA_IOSIZE 0x1c
+
+enum omap1_cam_vb_mode {
+ CONTIG = 0,
+ SG,
+};
See above - are these needed here?
+
+#define OMAP1_CAMERA_MIN_BUF_COUNT(x)((x) == CONTIG ? 3 : 2)
ditto
I moved them both over to the header file because I was using the
OMAP1_CAMERA_MIN_BUF_COUNT(CONTIG) macro once from the platform code in order
to calculate the buffer size when calling the then NAKed
dma_preallocate_coherent_memory(). Now I could put them back into the driver
code, but if we ever get back to the concept of preallocating a contignuos
piece of memory from the platform init code, we might need them back here, so
maybe I should rather keep them, only rename the two enum values using a
distinct name space. What do you think is better for now?
Yeah, up to you, I'd say, but if you decide to keep them in the header,
please, use a namespace.
I'm satisfied with your answers to the rest of my questions / comments:)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v2 1/6] SoC Camera: add driver for OMAP1 camera interface
On Thu, 23 Sep 2010, Janusz Krzysztofik wrote:
Thursday 23 September 2010 15:33:54 Guennadi Liakhovetski napisał(a):
On Wed, 22 Sep 2010, Janusz Krzysztofik wrote:
Wednesday 22 September 2010 01:23:22 Guennadi Liakhovetski napisał(a):
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
+
+ vb = buf-vb;
+ if (waitqueue_active(vb-done)) {
+ if (!pcdev-ready result != VIDEOBUF_ERROR)
+ /*
+ * No next buffer has been entered into the DMA
+ * programming register set on time, so best we
can do
+ * is stopping the capture before last DMA
block,
+ * whether our CONTIG mode whole buffer or its
last
+ * sgbuf in SG mode, gets overwritten by next
frame.
+ */
Hm, why do you think it's a good idea? This specific buffer completed
successfully, but you want to fail it just because the next buffer is
missing? Any specific reason for this?
Maybe my comment is not clear enough, but the below suspend_capture()
doesn't indicate any failure on a frame just captured. It only prevents
the frame from being overwritten by the already autoreinitialized DMA
engine, pointing back to the same buffer once again.
Besides, you seem to also be
considering the possibility of your -ready == NULL, but the queue
non-empty, in which case you just take the next buffer from the queue
and continue with it. Why error out in this case?
pcdev-ready == NULL means no buffer was available when it was time to
put it into the DMA programming register set.
But how? Buffers are added onto the list in omap1_videobuf_queue() under
spin_lock_irqsave(); and there you also check -ready and fill it in.
Guennadi,
Yes, but only if pcdev-active is NULL, ie. both DMA and FIFO are idle, never
if active:
+ list_add_tail(vb-queue, pcdev-capture);
+ vb-state = VIDEOBUF_QUEUED;
+
+ if (pcdev-active)
+ return;
Since the transfer of the DMA programming register set content to the DMA
working register set is done automatically by the DMA hardware, this can
pretty well happen while I keep the lock here, so I can't be sure if it's not
too late for entering new data into the programming register set. Then, I
decided that this operation should be done only just after the DMA interrupt
occured, ie. the current DMA programming register set content has just been
used and can be overwriten.
I'll emphasize the above return; with a comment.
Ok
In
your completion you set -ready = NULL, but then also call
prepare_next_vb() to get the next buffer from the list - if there are any,
so, how can it be NULL with a non-empty list?
It happens after the above mentioned prepare_next_vb() gets nothing from an
empty queue, so nothing is entered into the DMA programming register set,
only the last, just activated, buffer is processed, then
omap1_videobuf_queue() puts a new buffer into the queue while the active
buffer is still filled in, and finally the DMA ISR is called on this last
active buffer completion.
I hope this helps.
Let's assume it does:) You seem to really understand how this is working
and even be willing to document the driver, thus making it possibly the
best documented soc-camera related piece of software;)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v2 1/6] SoC Camera: add driver for OMAP1 camera interface
On Wed, 22 Sep 2010, hermann pitton wrote:
Am Mittwoch, den 22.09.2010, 01:23 +0200 schrieb Guennadi Liakhovetski:
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
This is a V4L2 driver for TI OMAP1 SoC camera interface.
[snip]
+
+ } else {
+ dev_warn(dev, %s: unhandled camera interrupt, status ==
+ 0x%0x\n, __func__, it_status);
Please, don't split strings
sorry for any OT interference.
But, are there any new rules out?
Maybe I missed them.
Either way, the above was forced during the last three years.
Not at all ?
No. Splitting print strings has always been discouraged, because it makes
tracking back kernel logs difficult. The reason for this has been the 80
character line length limit, which has now been effectively lifted. I'm
sure you can find enough links on the internet for any of these topics.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v2 2/6] OMAP1: Add support for SoC camera interface
That's up to the platform maintainer to review / apply this one, but if
you like, a couple of nit-picks from me:
On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
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.c2010-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
You might want to try to group headers according to their location, i.e.,
put mach/... higher - together with mach/gpio.h, also it helps to have
headers alphabetically ordered.
/*-*/
@@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
}
#endif
+
+#define OMAP1_CAMERA_BASE0xfffb6800
+
+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 *);
function declarations don't need an extern - something I've also been
doing needlessly for a few years...
+
+#endif /* __ASM_ARCH_CAMERA_H_ */
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Thu, 19 Aug 2010, Janusz Krzysztofik wrote: Hi Marin, Since I've finaly managed to make use of your method without any previously observerd limitations (see below), I'm interested in it being implemented system-wide. Are you going to submit a patch? I'm about to submit a patch, which you'll be most welcome to test. Just give me a couple more hours. I would suggest creating one common function that allocates and fills the dev-dma_mem structure, and two wrappers that call it: a dma_declare_coherent_memory() replacement, that passes an ioremapped device memory address to the common fuction, and your proposed dma_reserve_coherent_memory(), that passes a pointer returned by the dma_alloc_coherent() instead. [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver attached to camera 0 [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315659 not found [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315559 not found [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 [ 6068.50] Backtrace: [ 6068.52] [c0028950] (dump_backtrace+0x0/0x110) from [c0028ea8] (dump_stack+0x18/0x1c) [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 [ 6068.59] [c0028e90] (dump_stack+0x0/0x1c) from [c0074e24] (__alloc_pages_nodemask+0x504/0x560) [ 6068.62] [c0074920] (__alloc_pages_nodemask+0x0/0x560) from [c002ae14] (__dma_alloc+0x108/0x354) [ 6068.66] [c002ad0c] (__dma_alloc+0x0/0x354) from [c002b0ec] (dma_alloc_coherent+0x58/0x64) [ 6068.70] [c002b094] (dma_alloc_coherent+0x0/0x64) from [bf000a44] (__videobuf_mmap_mapper+0x10c/0x374 [videobuf_dma_contig]) [ 6068.74] r7:c16934c0 r6: r5:c171baec r4: [ 6068.77] [bf000938] (__videobuf_mmap_mapper+0x0/0x374 [videobuf_dma_contig]) from [c01f9a78] (videobuf_mmap_mapper+0xc4/0x108) [ 6068.81] [c01f99b4] (videobuf_mmap_mapper+0x0/0x108) from [c01fc1ac] (soc_camera_mmap+0x80/0x140) [ 6068.84] r5:c1a3b4e0 r4: [ 6068.87] [c01fc12c] (soc_camera_mmap+0x0/0x140) from [c01eeba8] (v4l2_mmap+0x4c/0x5c) [ 6068.90] r7:c145c000 r6:00ff r5:c16934c0 r4: [ 6068.93] [c01eeb5c] (v4l2_mmap+0x0/0x5c) from [c0085de4] (mmap_region+0x238/0x458) [ 6068.97] [c0085bac] (mmap_region+0x0/0x458) from [c00862c0] (do_mmap_pgoff+0x2bc/0x320) [ 6069.00] [c0086004] (do_mmap_pgoff+0x0/0x320) from [c00863c0] (sys_mmap_pgoff+0x9c/0xc8) [ 6069.04] [c0086324] (sys_mmap_pgoff+0x0/0xc8) from [c0024f00] (ret_fast_syscall+0x0/0x2c) [ 6069.20] Mem-info: [ 6069.22] Normal per-cpu: [ 6069.24] CPU0: hi:0, btch: 1 usd: 0 [ 6069.26] active_anon:676 inactive_anon:682 isolated_anon:0 [ 6069.26] active_file:422 inactive_file:2348 isolated_file:0 [ 6069.26] unevictable:177 dirty:0 writeback:0 unstable:0 [ 6069.26] free:1166 slab_reclaimable:0 slab_unreclaimable:0 [ 6069.26] mapped:1120 shmem:0 pagetables:121 bounce:0 [ 6069.35] Normal free:4664kB min:720kB low:900kB high:1080kB active_anon:2704kB inactive_anon:2728kB active_file:1688kB inactive_file:9392kB unevictable:708kB isolated(anon):0kB isolated(file):0kB present:32512kB mlocked:0kB dirty:0kB writeback:0kB mapped:4480kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:552kB pagetables:484kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 6069.46] lowmem_reserve[]: 0 0 [ 6069.47] Normal: 6*4kB 20*8kB 14*16kB 29*32kB 26*64kB 9*128kB 2*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4664kB [ 6069.53] 2960 total pagecache pages [ 6069.55] 8192 pages of RAM [ 6069.56] 1322 free pages [ 6069.58] 1114 reserved pages [ 6069.59] 750 slab pages [ 6069.61] 2476 pages shared [ 6069.63] 0 pages swap cached [ 6069.64] omap1-camera omap1-camera.0: dma_alloc_coherent size 204800 failed [ 6069.68] omap1-camera omap1-camera.0: OMAP1 Camera driver detached from camera 0 Maybe I should preallocate a few more pages than will be actually used by the driver? That was it. I was trying to reserve exact frame size, times number of buffers. Apparently, the frame size should be rounded up to the nearest power of 2 first for it to work as expected. No, I don't think you should go to the next power of 2 - that's too crude. Try rounding your buffer size to the page size, that should suffice. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Friday 13 August 2010 11:11:52 Marin Mitov napisał(a): On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote: On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. For an example look at arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). Yes, this is the solution that suffers from the already discussed limitation of not being able to remap a memory with different attributes, which affects OMAP1 as well. For preallocating dma-coherent memory for device personal use during device probe() time (when the memory is less fragmented compared to open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if it works for arm arch) With this workaround applied, I get much better results, thank you Marin. However, it seems not bullet proof, since mmap still happens to fail for a reason not quite clear to me: What exactly does this mean - happens to fail - you mean starting and stopping mplayer several times? Can you verify, that you're not leaking memory? That you're freeing all allocated DMA memory again? Are you using the same parameters to mplayer, right? As for the work-around - can you not do this in your board late-initcall function? Not sure whether and how one can get this in the mainline. This is in principle the same, as in the above dma_declare_coherent_memory() example, only open-coded without the ioremap. Maybe we can add a suitable function to the dma-alloc API... Thanks Guennadi [ 6067.22] omap1-camera omap1-camera.0: OMAP1 Camera driver attached to camera 0 [ 6067.65] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315659 not found [ 6067.68] omap1-camera omap1-camera.0: omap1_cam_try_fmt: format 32315559 not found [ 6068.48] mplayer: page allocation failure. order:6, mode:0xd0 [ 6068.50] Backtrace: [ 6068.52] [c0028950] (dump_backtrace+0x0/0x110) from [c0028ea8] (dump_stack+0x18/0x1c) [ 6068.56] r6:0006 r5:00d0 r4:c1bcf000 [ 6068.59] [c0028e90] (dump_stack+0x0/0x1c) from [c0074e24] (__alloc_pages_nodemask+0x504/0x560) [ 6068.62] [c0074920] (__alloc_pages_nodemask+0x0/0x560) from [c002ae14] (__dma_alloc+0x108/0x354) [ 6068.66] [c002ad0c] (__dma_alloc+0x0/0x354) from [c002b0ec] (dma_alloc_coherent+0x58/0x64) [ 6068.70] [c002b094] (dma_alloc_coherent+0x0/0x64) from [bf000a44] (__videobuf_mmap_mapper+0x10c/0x374 [videobuf_dma_contig]) [ 6068.74] r7:c16934c0 r6: r5:c171baec r4: [ 6068.77] [bf000938] (__videobuf_mmap_mapper+0x0/0x374 [videobuf_dma_contig]) from [c01f9a78] (videobuf_mmap_mapper+0xc4/0x108) [ 6068.81] [c01f99b4] (videobuf_mmap_mapper+0x0/0x108) from [c01fc1ac] (soc_camera_mmap+0x80/0x140) [ 6068.84] r5:c1a3b4e0 r4: [ 6068.87] [c01fc12c] (soc_camera_mmap+0x0/0x140) from [c01eeba8] (v4l2_mmap+0x4c/0x5c) [ 6068.90] r7:c145c000 r6:00ff r5:c16934c0 r4: [ 6068.93] [c01eeb5c] (v4l2_mmap+0x0/0x5c) from [c0085de4] (mmap_region+0x238/0x458) [ 6068.97] [c0085bac] (mmap_region+0x0/0x458) from [c00862c0] (do_mmap_pgoff+0x2bc/0x320) [ 6069.00] [c0086004] (do_mmap_pgoff+0x0/0x320) from [c00863c0] (sys_mmap_pgoff+0x9c/0xc8) [ 6069.04] [c0086324] (sys_mmap_pgoff+0x0/0xc8) from [c0024f00] (ret_fast_syscall+0x0/0x2c) [ 6069.20] Mem-info: [ 6069.22] Normal per-cpu: [ 6069.24] CPU0: hi:0, btch: 1 usd: 0 [ 6069.26] active_anon:676 inactive_anon:682 isolated_anon:0 [ 6069.26] active_file:422 inactive_file:2348 isolated_file:0 [ 6069.26] unevictable:177 dirty:0 writeback:0 unstable:0 [ 6069.26] free:1166 slab_reclaimable:0 slab_unreclaimable:0 [ 6069.26] mapped:1120 shmem:0 pagetables:121 bounce:0 [ 6069.35] Normal free:4664kB min:720kB low:900kB high:1080kB active_anon:2704kB inactive_anon:2728kB active_file:1688kB inactive_file:9392kB unevictable:708kB isolated(anon):0kB isolated(file):0kB present:32512kB mlocked:0kB
Re: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Fri, 13 Aug 2010, Janusz Krzysztofik wrote: Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a): On Sun, 1 Aug 2010, Janusz Krzysztofik wrote: Friday 30 July 2010 20:49:05 Janusz Krzysztofik napisał(a): I think the right way would be if implemented at the videobuf-core level. Then, drivers should be able to initialize both paths, providing queue callbacks for both sets of methods, contig and sg, for videobuf sole use. Ok, here're my thoughts about this: 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. I already tried before to find out how I could allocate memory at init without reinventing a new videobuf-dma-contig implementation. Since in the Documentation/video4linux/videobuf I've read that videobuf does not currently play well with drivers that play tricks by allocating DMA space at system boot time, I've implemented the alternate sg path. If it's not quite true what the documentation says and you can give me a hint how this could be done, I might try again. For an example look at arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma(). But given problems with this aproach in the current ARM tree [1], this might be a bit difficult. Still, those problems have to be and will be fixed somehow eventually, so, you might prefer to still just go that route. My board uses two drivers that allocate dma memory at boot time: drivers/video/omap/lcdc.c and sounc/soc/omap/omap-pcm.c. Both use alloc_dma_writecombine() for this and work without problems. dma_alloc_writecombine() also allocates contiguous RAM, right? And it doesn't use device local memory. So, it's chances to fail are the same as those of dma_alloc_coherent() in the absence of device own memory. I guess, the sound driver doesn't need much RAM, but if you build your LCDC driver as a module and load it later after startup, it might get problems allocating RAM for the framebuffer. 2. If you do want to do the switching - we also discussed, how forthcoming changes to the videobuf subsystem will affest this work. I do not think it would be possible to implement this switching in the videobuf core. OK, I should have probably said that it looked not possible for me to do it without any additional support implemented at videobuf-core (or soc_camera) level. Remember, with the videobuf API you first call the respective implementation init method, which doesn't fail. Then, in REQBUFS ioctl you call videobuf_reqbufs(), which might already fail but normally doesn't. The biggest problem is the mmap call with the contig videobuf implementation. This one is likely to fail. So, you would have to catch the failing mmap, call videobuf_mmap_free(), then init the SG videobuf, request buffers and mmap them... That's what I've already discovered, but failed to identify a place in my code where I could intercept this failing mmap without replacing parts of the videobuf code. Right, ATM soc-camera just calls videobuf_mmap_mapper() directly in its mmap method. I could add a callback to struct soc_camera_host_ops like int (*mmap)(struct soc_camera_device *, struct vm_area_struct *) and modify soc_camera_mmap() to check, whether the host driver has implemented it. If so - call it, otherwise call videobuf_mmap_mapper() directly just like now. So, other drivers would not have to be modified. And you could implement that .mmap() method, call videobuf_mmap_mapper() yourself, and if it fails for contig, fall back to SG. With my 2 patches from today, there is only one process (file descriptor, to be precise), that manages the videobuf queue. So, this all can only be implemented in your driver. The only way I'm yet able to invent is replacing the videobuf_queue-int_ops-mmap_mapper() callback with my own wrapper that would intercept a failing videobuf-dma-contig version of mmap_mapper(). This could be done in my soc_camera_host-ops-init_videobuf() after the videobuf-dma-contig.c version of the videobuf_queue-int_ops-mmap_mapper() is installed with the videobuf_queue_dma_contig_init(). Is this method close to what you have on mind? See, if the above idea would suit your needs. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
On Sun, 1 Aug 2010, Janusz Krzysztofik wrote: Friday 30 July 2010 20:49:05 Janusz Krzysztofik napisał(a): Friday 30 July 2010 13:07:42 Guennadi Liakhovetski napisał(a): On Sun, 18 Jul 2010, Janusz Krzysztofik wrote: This is a V4L2 driver for TI OMAP1 SoC camera interface. Two versions of the driver are provided, using either videobuf-dma-contig or videobuf-dma-sg. The former uses less processing power, but often fails to allocate contignuous buffer memory. The latter is free of this problem, but generates tens of DMA interrupts per frame. Hm, would it be difficult to first try contig, and if it fails - fall back to sg? Hmm, let me think about it. Hi Gennadi, For me, your idea of frist trying contig and then falling back to sg if it fails, sounds great. However, I'm not sure if implementing it at a specific hardware driver level is a good solution. Nor soc_camera framework seems the right place for it either. I think the right way would be if implemented at the videobuf-core level. Then, drivers should be able to initialize both paths, providing queue callbacks for both sets of methods, contig and sg, for videobuf sole use. Ok, here're my thoughts about this: 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. But given problems with this aproach in the current ARM tree [1], this might be a bit difficult. Still, those problems have to be and will be fixed somehow eventually, so, you might prefer to still just go that route. 2. If you do want to do the switching - we also discussed, how forthcoming changes to the videobuf subsystem will affest this work. I do not think it would be possible to implement this switching in the videobuf core. Remember, with the videobuf API you first call the respective implementation init method, which doesn't fail. Then, in REQBUFS ioctl you call videobuf_reqbufs(), which might already fail but normally doesn't. The biggest problem is the mmap call with the contig videobuf implementation. This one is likely to fail. So, you would have to catch the failing mmap, call videobuf_mmap_free(), then init the SG videobuf, request buffers and mmap them... With my 2 patches from today, there is only one process (file descriptor, to be precise), that manages the videobuf queue. So, this all can only be implemented in your driver. [1] http://thread.gmane.org/gmane.linux.ports.sh.devel/8560 I'm not sure if I have enough skills to implement this idea. However, if there is a consensus on its general usfullness as a videobuf extension, I can have a look at it in my spare time. For now, I'd propose limiting my changes for v2 to splitting both methods into separate sections, not interleaved with #ifdefs like they are now, as you've already suggested. Yep, so, I think, your choice is either to drop sg completely, or to separate the two cleanly and switch between them dynamically in your driver. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
) += mx3_camera.o obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)+= sh_mobile_ceu_camera.o +obj-$(CONFIG_VIDEO_OMAP1)+= omap1_camera.o obj-$(CONFIG_ARCH_DAVINCI) += davinci/ --- linux-2.6.35-rc3.orig/drivers/media/video/omap1_camera.c 1970-01-01 01:00:00.0 +0100 +++ linux-2.6.35-rc3/drivers/media/video/omap1_camera.c 2010-07-18 01:32:48.0 +0200 @@ -0,0 +1,1656 @@ +/* + * V4L2 SoC Camera driver for OMAP1 Camera Interface + * + * Copyright (C) 2010, Janusz Krzysztofik jkrzy...@tis.icnet.pl + * + * Based on V4L2 Driver for i.MXL/i.MXL camera (CSI) host + * Copyright (C) 2008, Paulius Zaleckas paulius.zalec...@teltonika.lt + * Copyright (C) 2009, Darius Augulis augulis.dar...@gmail.com + * + * Based on PXA SoC camera driver + * Copyright (C) 2006, Sascha Hauer, Pengutronix + * Copyright (C) 2008, Guennadi Liakhovetski ker...@pengutronix.de + * + * Hardware specific bits initialy based on former work by Matt Callow + * drivers/media/video/omap/omap1510cam.c + * Copyright (C) 2006 Matt Callow + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + + +#include linux/clk.h +#include linux/dma-mapping.h +#include linux/interrupt.h +#include linux/platform_device.h +#include linux/slab.h +#include linux/version.h + +#include media/omap1_camera.h +#include media/soc_camera.h +#include media/soc_mediabus.h +#ifndef CONFIG_VIDEO_OMAP1_SG +#include media/videobuf-dma-contig.h +#else +#include media/videobuf-dma-sg.h +#endif I think, you can just include both headers. + +#include plat/dma.h + + +#define DRIVER_NAME omap1-camera +#define VERSION_CODE KERNEL_VERSION(0, 0, 1) + + +/* + * --- + * OMAP1 Camera Interface registers + * --- + */ + +#define REG_CTRLCLOCK0x00 +#define REG_IT_STATUS0x04 +#define REG_MODE 0x08 +#define REG_STATUS 0x0C +#define REG_CAMDATA 0x10 +#define REG_GPIO 0x14 +#define REG_PEAK_COUNTER 0x18 + +/* CTRLCLOCK bit shifts */ +#define LCLK_EN BIT(7) +#define DPLL_EN BIT(6) +#define MCLK_EN BIT(5) +#define CAMEXCLK_EN BIT(4) +#define POLCLK BIT(3) +#define FOSCMOD_SHIFT0 +#define FOSCMOD_MASK (0x7 FOSCMOD_SHIFT) +#define FOSCMOD_12MHz0x0 +#define FOSCMOD_6MHz 0x2 +#define FOSCMOD_9_6MHz 0x4 +#define FOSCMOD_24MHz0x5 +#define FOSCMOD_8MHz 0x6 + +/* IT_STATUS bit shifts */ +#define DATA_TRANSFERBIT(5) +#define FIFO_FULLBIT(4) +#define H_DOWN BIT(3) +#define H_UP BIT(2) +#define V_DOWN BIT(1) +#define V_UP BIT(0) + +/* MODE bit shifts */ +#define RAZ_FIFO BIT(18) +#define EN_FIFO_FULL BIT(17) +#define EN_NIRQ BIT(16) +#define THRESHOLD_SHIFT 9 +#define THRESHOLD_MASK (0x7f THRESHOLD_SHIFT) +#define DMA BIT(8) +#define EN_H_DOWNBIT(7) +#define EN_H_UP BIT(6) +#define EN_V_DOWNBIT(5) +#define EN_V_UP BIT(4) +#define ORDERCAMDBIT(3) + +#define IRQ_MASK (EN_V_UP | EN_V_DOWN | EN_H_UP | EN_H_DOWN | \ + EN_NIRQ | EN_FIFO_FULL) + +/* STATUS bit shifts */ +#define HSTATUS BIT(1) +#define VSTATUS BIT(0) + +/* GPIO bit shifts */ +#define CAM_RST BIT(0) + +/* end of OMAP1 Camera Interface registers */ + + +#define SOCAM_BUS_FLAGS (SOCAM_MASTER | \ + SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_HIGH | \ + SOCAM_PCLK_SAMPLE_RISING | SOCAM_PCLK_SAMPLE_FALLING | \ + SOCAM_DATA_ACTIVE_HIGH | SOCAM_DATAWIDTH_8) + + +#define CAM_EXCLK_6MHz600 +#define CAM_EXCLK_8MHz800 +#define CAM_EXCLK_9_6MHz 960 +#define CAM_EXCLK_12MHz 1200 +#define CAM_EXCLK_24MHz 2400 Why do you need this? Your platform specifies the EXCLK frequency directly in kHz, then you multiplly it by 1000 to get pcdev-camexclk in Hz, then you compare it to these macros. Don't think you need them - just use numbers directly. + + +#define FIFO_SIZE((THRESHOLD_MASK THRESHOLD_SHIFT) + 1) +#define FIFO_SHIFT __fls(FIFO_SIZE) + +#define
[PATCH 2/5 v2] ARM: mach-shmobile: add LCDC and MIPI DSI-Tx clock definitions to sh7372
Define clock objects for switching on and off clocks for LCDC0, LCDC1 and MIPI
DSI-Tx.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v1 - v2:
1. reimplemented based on the arm-shmobile clocking scheme v2. Please,
verify, that this is ok now, also that the naming choise is suitable.
2. adjusted the subject line
arch/arm/mach-shmobile/clock-sh7372.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-shmobile/clock-sh7372.c
b/arch/arm/mach-shmobile/clock-sh7372.c
index ac46b4b..d6414ad 100644
--- a/arch/arm/mach-shmobile/clock-sh7372.c
+++ b/arch/arm/mach-shmobile/clock-sh7372.c
@@ -241,7 +241,10 @@ struct clk div6_clks[DIV6_NR] = {
};
enum { MSTP001,
- MSTP131, MSTP130, MSTP129, MSTP128, MSTP116, MSTP106, MSTP101,
+ MSTP131, MSTP130,
+ MSTP129, MSTP128,
+ MSTP118, MSTP117, MSTP116,
+ MSTP106, MSTP101, MSTP100,
MSTP223,
MSTP207, MSTP206, MSTP204, MSTP203, MSTP202, MSTP201, MSTP200,
MSTP329, MSTP323, MSTP322, MSTP314, MSTP313,
@@ -257,9 +260,12 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP130] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 30, 0), /* VEU2 */
[MSTP129] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 29, 0), /* VEU1 */
[MSTP128] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 28, 0), /* VEU0 */
+ [MSTP118] = MSTP(div6_clks[DIV4_B], SMSTPCR1, 18, 0), /* DSITX */
+ [MSTP117] = MSTP(div6_clks[DIV4_B], SMSTPCR1, 17, 0), /* LCDC1 */
[MSTP116] = MSTP(div6_clks[DIV6_SUB], SMSTPCR1, 16, 0), /* IIC0 */
[MSTP106] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 6, 0), /* JPU */
[MSTP101] = MSTP(div4_clks[DIV4_M1], SMSTPCR1, 1, 0), /* VPU */
+ [MSTP100] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 0, 0), /* LCDC0 */
[MSTP223] = MSTP(div6_clks[DIV6_SPU], SMSTPCR2, 23, 0), /* SPU2 */
[MSTP207] = MSTP(div6_clks[DIV6_SUB], SMSTPCR2, 7, 0), /* SCIFA5 */
[MSTP206] = MSTP(div6_clks[DIV6_SUB], SMSTPCR2, 6, 0), /* SCIFB */
@@ -335,9 +341,12 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID(uio_pdrv_genirq.2, mstp_clks[MSTP130]), /* VEU2 */
CLKDEV_DEV_ID(uio_pdrv_genirq.1, mstp_clks[MSTP129]), /* VEU1 */
CLKDEV_DEV_ID(uio_pdrv_genirq.0, mstp_clks[MSTP128]), /* VEU0 */
+ CLKDEV_DEV_ID(sh-mipi-dsi.0, mstp_clks[MSTP118]), /* DSITX */
+ CLKDEV_DEV_ID(sh_mobile_lcdc_fb.1, mstp_clks[MSTP117]), /* LCDC1 */
CLKDEV_DEV_ID(i2c-sh_mobile.0, mstp_clks[MSTP116]), /* IIC0 */
CLKDEV_DEV_ID(uio_pdrv_genirq.5, mstp_clks[MSTP106]), /* JPU */
CLKDEV_DEV_ID(uio_pdrv_genirq.0, mstp_clks[MSTP101]), /* VPU */
+ CLKDEV_DEV_ID(sh_mobile_lcdc_fb.0, mstp_clks[MSTP100]), /* LCDC0 */
CLKDEV_DEV_ID(uio_pdrv_genirq.6, mstp_clks[MSTP223]), /* SPU2DSP0 */
CLKDEV_DEV_ID(uio_pdrv_genirq.7, mstp_clks[MSTP223]), /* SPU2DSP1 */
CLKDEV_DEV_ID(sh-sci.5, mstp_clks[MSTP207]), /* SCIFA5 */
--
1.6.2.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
[PATCH 4/5 v3] sh-mobile: add support for displays, connected over the MIPI bus
Some SH-mobile SoCs have a MIPI DSI controller, that can be used to connect
MIPI displays to LCDC. This patch adds a platform driver for SH-mobile MIPI DSI
unit. It uses existing hooks in the sh_mobile_lcdcfb.c driver for display
activation and deactivation.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Tested-by: Damian Hobson-Garcia dhobs...@igel.co.jp
---
v2 - v3:
1. added the missing linux/slab.h header
2. switched back to PLL clock multiplier = 23: with the current kernel 13
produces flicker on the display.
drivers/video/Kconfig |8 +
drivers/video/Makefile |1 +
drivers/video/sh_mipi_dsi.c | 505 +++
include/video/sh_mipi_dsi.h | 35 +++
4 files changed, 549 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/sh_mipi_dsi.c
create mode 100644 include/video/sh_mipi_dsi.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6e16244..773c4a6 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1879,6 +1879,13 @@ config FB_W100
If unsure, say N.
+config SH_MIPI_DSI
+ tristate
+ depends on (SUPERH || ARCH_SHMOBILE) HAVE_CLK
+
+config SH_LCD_MIPI_DSI
+ bool
+
config FB_SH_MOBILE_LCDC
tristate SuperH Mobile LCDC framebuffer support
depends on FB (SUPERH || ARCH_SHMOBILE) HAVE_CLK
@@ -1887,6 +1894,7 @@ config FB_SH_MOBILE_LCDC
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO
+ select SH_MIPI_DSI if SH_LCD_MIPI_DSI
---help---
Frame buffer driver for the on-chip SH-Mobile LCD controller.
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ddc2af2..3c3bf86 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -123,6 +123,7 @@ obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o
obj-$(CONFIG_FB_PS3) += ps3fb.o
obj-$(CONFIG_FB_SM501)+= sm501fb.o
obj-$(CONFIG_FB_XILINX) += xilinxfb.o
+obj-$(CONFIG_SH_MIPI_DSI)+= sh_mipi_dsi.o
obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o
obj-$(CONFIG_FB_OMAP) += omap/
obj-y += omap2/
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
new file mode 100644
index 000..017ae9f
--- /dev/null
+++ b/drivers/video/sh_mipi_dsi.c
@@ -0,0 +1,505 @@
+/*
+ * Renesas SH-mobile MIPI DSI support
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/init.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/string.h
+#include linux/types.h
+
+#include video/mipi_display.h
+#include video/sh_mipi_dsi.h
+#include video/sh_mobile_lcdc.h
+
+#define CMTSRTCTR 0x80d0
+#define CMTSRTREQ 0x8070
+
+#define DSIINTE0x0060
+
+/* E.g., sh7372 has 2 MIPI-DSIs - one for each LCDC */
+#define MAX_SH_MIPI_DSI 2
+
+struct sh_mipi {
+ void __iomem*base;
+ struct clk *dsit_clk;
+ struct clk *dsip_clk;
+};
+
+static struct sh_mipi *mipi_dsi[MAX_SH_MIPI_DSI];
+
+/* Protect the above array */
+static DEFINE_MUTEX(array_lock);
+
+static struct sh_mipi *sh_mipi_by_handle(int handle)
+{
+ if (handle = ARRAY_SIZE(mipi_dsi) || handle 0)
+ return NULL;
+
+ return mipi_dsi[handle];
+}
+
+static int sh_mipi_send_short(struct sh_mipi *mipi, u8 dsi_cmd,
+ u8 cmd, u8 param)
+{
+ u32 data = (dsi_cmd 24) | (cmd 16) | (param 8);
+ int cnt = 100;
+
+ /* transmit a short packet to LCD panel */
+ iowrite32(1 | data, mipi-base + 0x80d0); /* CMTSRTCTR */
+ iowrite32(1, mipi-base + 0x8070); /* CMTSRTREQ */
+
+ while ((ioread32(mipi-base + 0x8070) 1) --cnt)
+ udelay(1);
+
+ return cnt ? 0 : -ETIMEDOUT;
+}
+
+#define LCD_CHAN2MIPI(c) ((c) LCDC_CHAN_MAINLCD || (c) LCDC_CHAN_SUBLCD ? \
+ -EINVAL : (c) - 1)
+
+static int sh_mipi_dcs(int handle, u8 cmd)
+{
+ struct sh_mipi *mipi = sh_mipi_by_handle(LCD_CHAN2MIPI(handle));
+ if (!mipi)
+ return -ENODEV;
+ return sh_mipi_send_short(mipi, MIPI_DSI_DCS_SHORT_WRITE, cmd, 0);
+}
+
+static int sh_mipi_dcs_param(int handle, u8 cmd, u8 param)
+{
+ struct sh_mipi *mipi = sh_mipi_by_handle(LCD_CHAN2MIPI(handle));
+ if (!mipi)
+ return -ENODEV;
+ return sh_mipi_send_short(mipi, MIPI_DSI_DCS_SHORT_WRITE_PARAM, cmd,
+ param);
+}
+
+static void sh_mipi_dsi_enable(struct sh_mipi *mipi, bool enable)
+{
+ /*
+* enable LCDC data tx, transition to LPS after completion of each HS
+* packet
[PATCH 2/5] ARM: add LCDC and MIPI DSI-Tx clock definitions to sh7372
Define clock objects for switching on and off clocks for LCDC0, LCDC1 and MIPI
DSI-Tx.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Now that the fbdev: add a MIPI DSI header patch has been acked, we can
add the rest of the patches in this series, which can completely be pulled
via the genesis tree. Paul, please apply. This patch is unchanged from its
original version.
arch/arm/mach-shmobile/clock-sh7372.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/clock-sh7372.c
b/arch/arm/mach-shmobile/clock-sh7372.c
index abbc380..66ee47a 100644
--- a/arch/arm/mach-shmobile/clock-sh7372.c
+++ b/arch/arm/mach-shmobile/clock-sh7372.c
@@ -264,8 +264,12 @@ struct clk div6_clks[] = {
#define R_CLK (r_clk)
#define HP_CLK (div4_clks[DIV4_HP])
+#define B_CLK (div4_clks[DIV4_B])
static struct clk mstp_clks[] = {
+ MSTP(lcdc0, B_CLK, SMSTPCR1, 0, 0),
+ MSTP(lcdc1, B_CLK, SMSTPCR1, 17, 0),
+ MSTP(dsitx, B_CLK, SMSTPCR1, 18, 0),
MSTP(sdhi0, HP_CLK, SMSTPCR3, 14, 0),
MSTP(sdhi1, HP_CLK, SMSTPCR3, 13, 0),
MSTP(keysc0, R_CLK, SMSTPCR4, 3, 0),
--
1.6.2.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
[PATCH 4/5 v2] sh-mobile: add support for displays, connected over the MIPI bus
Some SH-mobile SoCs have a MIPI DSI controller, that can be used to connect
MIPI displays to LCDC. This patch adds a platform driver for SH-mobile MIPI DSI
unit. It uses existing hooks in the sh_mobile_lcdcfb.c driver for display
activation and deactivation.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v1 - v2:
1. header renamed to mipi_display
2. commands and transaction types are now u8 instead of enums
3. reduce PLL clock multplier from 23 down to 13
drivers/video/Kconfig |8 +
drivers/video/Makefile |1 +
drivers/video/sh_mipi_dsi.c | 504 +++
include/video/sh_mipi_dsi.h | 35 +++
4 files changed, 548 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/sh_mipi_dsi.c
create mode 100644 include/video/sh_mipi_dsi.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6e16244..773c4a6 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1879,6 +1879,13 @@ config FB_W100
If unsure, say N.
+config SH_MIPI_DSI
+ tristate
+ depends on (SUPERH || ARCH_SHMOBILE) HAVE_CLK
+
+config SH_LCD_MIPI_DSI
+ bool
+
config FB_SH_MOBILE_LCDC
tristate SuperH Mobile LCDC framebuffer support
depends on FB (SUPERH || ARCH_SHMOBILE) HAVE_CLK
@@ -1887,6 +1894,7 @@ config FB_SH_MOBILE_LCDC
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO
+ select SH_MIPI_DSI if SH_LCD_MIPI_DSI
---help---
Frame buffer driver for the on-chip SH-Mobile LCD controller.
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ddc2af2..3c3bf86 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -123,6 +123,7 @@ obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o
obj-$(CONFIG_FB_PS3) += ps3fb.o
obj-$(CONFIG_FB_SM501)+= sm501fb.o
obj-$(CONFIG_FB_XILINX) += xilinxfb.o
+obj-$(CONFIG_SH_MIPI_DSI)+= sh_mipi_dsi.o
obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o
obj-$(CONFIG_FB_OMAP) += omap/
obj-y += omap2/
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
new file mode 100644
index 000..ac4cae5
--- /dev/null
+++ b/drivers/video/sh_mipi_dsi.c
@@ -0,0 +1,504 @@
+/*
+ * Renesas SH-mobile MIPI DSI support
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/init.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/string.h
+#include linux/types.h
+
+#include video/mipi_display.h
+#include video/sh_mipi_dsi.h
+#include video/sh_mobile_lcdc.h
+
+#define CMTSRTCTR 0x80d0
+#define CMTSRTREQ 0x8070
+
+#define DSIINTE0x0060
+
+/* E.g., sh7372 has 2 MIPI-DSIs - one for each LCDC */
+#define MAX_SH_MIPI_DSI 2
+
+struct sh_mipi {
+ void __iomem*base;
+ struct clk *dsit_clk;
+ struct clk *dsip_clk;
+};
+
+static struct sh_mipi *mipi_dsi[MAX_SH_MIPI_DSI];
+
+/* Protect the above array */
+static DEFINE_MUTEX(array_lock);
+
+static struct sh_mipi *sh_mipi_by_handle(int handle)
+{
+ if (handle = ARRAY_SIZE(mipi_dsi) || handle 0)
+ return NULL;
+
+ return mipi_dsi[handle];
+}
+
+static int sh_mipi_send_short(struct sh_mipi *mipi, u8 dsi_cmd,
+ u8 cmd, u8 param)
+{
+ u32 data = (dsi_cmd 24) | (cmd 16) | (param 8);
+ int cnt = 100;
+
+ /* transmit a short packet to LCD panel */
+ iowrite32(1 | data, mipi-base + 0x80d0); /* CMTSRTCTR */
+ iowrite32(1, mipi-base + 0x8070); /* CMTSRTREQ */
+
+ while ((ioread32(mipi-base + 0x8070) 1) --cnt)
+ udelay(1);
+
+ return cnt ? 0 : -ETIMEDOUT;
+}
+
+#define LCD_CHAN2MIPI(c) ((c) LCDC_CHAN_MAINLCD || (c) LCDC_CHAN_SUBLCD ? \
+ -EINVAL : (c) - 1)
+
+static int sh_mipi_dcs(int handle, u8 cmd)
+{
+ struct sh_mipi *mipi = sh_mipi_by_handle(LCD_CHAN2MIPI(handle));
+ if (!mipi)
+ return -ENODEV;
+ return sh_mipi_send_short(mipi, MIPI_DSI_DCS_SHORT_WRITE, cmd, 0);
+}
+
+static int sh_mipi_dcs_param(int handle, u8 cmd, u8 param)
+{
+ struct sh_mipi *mipi = sh_mipi_by_handle(LCD_CHAN2MIPI(handle));
+ if (!mipi)
+ return -ENODEV;
+ return sh_mipi_send_short(mipi, MIPI_DSI_DCS_SHORT_WRITE_PARAM, cmd,
+ param);
+}
+
+static void sh_mipi_dsi_enable(struct sh_mipi *mipi, bool enable)
+{
+ /*
+* enable LCDC data tx, transition to LPS after completion of each HS
+* packet
+*/
+ iowrite32(0x0002 | enable, mipi-base + 0x8000); /* DTCTR
[PATCH 5/5 v2] ARM: add framebuffer support for ap4evb
ap4evb uses an LCD, connected to the SoC over the MIPI bus. This patch adds
platform data to configure this display and a static clock activation.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v1 - v2:
1. right margin reduced from 1080 points down to 600 points. This
configures the blanking time, required for the LCD.
arch/arm/mach-shmobile/Kconfig|1 +
arch/arm/mach-shmobile/board-ap4evb.c | 121 +
2 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 9003ea9..e216132 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -42,6 +42,7 @@ config MACH_AP4EVB
bool AP4EVB board
depends on ARCH_SH7372
select ARCH_REQUIRE_GPIOLIB
+ select SH_LCD_MIPI_DSI
comment SH-Mobile System Configuration
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c
b/arch/arm/mach-shmobile/board-ap4evb.c
index d2bb7b0..e4ca9a9 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -17,6 +17,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include linux/clk.h
#include linux/kernel.h
#include linux/init.h
#include linux/interrupt.h
@@ -32,8 +33,14 @@
#include linux/gpio.h
#include linux/input.h
#include linux/input/sh_keysc.h
+
+#include video/sh_mobile_lcdc.h
+#include video/sh_mipi_dsi.h
+
#include mach/common.h
+#include mach/irqs.h
#include mach/sh7372.h
+
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -237,11 +244,86 @@ static struct platform_device sdhi0_device = {
},
};
+static struct sh_mobile_lcdc_info sh_mobile_lcdc_info = {
+ .clock_source = LCDC_CLK_PERIPHERAL, /* One of interface clocks */
+ .ch[0] = {
+ .chan = LCDC_CHAN_MAINLCD,
+ .bpp = 16,
+ .interface_type = RGB24,
+ .clock_divider = 1,
+ .flags = LCDC_FLAGS_DWPOL,
+ .lcd_cfg = {
+ .name = R63302(QHD),
+ .xres = 544,
+ .yres = 961,
+ .left_margin = 72,
+ .right_margin = 600,
+ .hsync_len = 16,
+ .upper_margin = 8,
+ .lower_margin = 8,
+ .vsync_len = 2,
+ .sync = FB_SYNC_VERT_HIGH_ACT | FB_SYNC_HOR_HIGH_ACT,
+ },
+ .lcd_size_cfg = {
+ .width = 44,
+ .height = 79,
+ },
+ }
+};
+
+static struct resource lcdc_resources[] = {
+ [0] = {
+ .name = LCDC,
+ .start = 0xfe94, /* P4-only space */
+ .end= 0xfe943fff,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = intcs_evt2irq(0x580),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device lcdc_device = {
+ .name = sh_mobile_lcdc_fb,
+ .num_resources = ARRAY_SIZE(lcdc_resources),
+ .resource = lcdc_resources,
+ .dev= {
+ .platform_data = sh_mobile_lcdc_info,
+ .coherent_dma_mask = ~0,
+ },
+};
+
+static struct resource mipidsi0_resources[] = {
+ [0] = {
+ .start = 0xffc6,
+ .end= 0xffc68fff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct sh_mipi_dsi_info mipidsi0_info = {
+ .data_format= MIPI_RGB888,
+ .lcd_chan = sh_mobile_lcdc_info.ch[0],
+};
+
+static struct platform_device mipidsi0_device = {
+ .name = sh-mipi-dsi,
+ .num_resources = ARRAY_SIZE(mipidsi0_resources),
+ .resource = mipidsi0_resources,
+ .id = 0,
+ .dev= {
+ .platform_data = mipidsi0_info,
+ },
+};
+
static struct platform_device *ap4evb_devices[] __initdata = {
nor_flash_device,
smc911x_device,
keysc_device,
sdhi0_device,
+ lcdc_device,
+ mipidsi0_device,
};
static struct map_desc ap4evb_io_desc[] __initdata = {
@@ -265,6 +347,45 @@ static void __init ap4evb_map_io(void)
shmobile_setup_console();
}
+/* This function will disappear when we switch to (runtime) PM */
+static int __init ap4evb_init_display_clk(void)
+{
+ struct clk *lcdc_clk;
+ struct clk *dsitx_clk;
+ int ret;
+
+ lcdc_clk = clk_get(lcdc_device.dev, lcdc0);
+ if (IS_ERR(lcdc_clk))
+ return PTR_ERR(lcdc_clk);
+
+ dsitx_clk = clk_get(mipidsi0_device.dev, dsitx);
+ if (IS_ERR(dsitx_clk)) {
+ ret = PTR_ERR(dsitx_clk);
+ goto eclkdsitxget;
+ }
+
+ ret
[PATCH 3/5] sh: add a YUV422 output data format, that is also supported by LCDC
The LCDC block is allowed to use one of the two output data formats, when used
with MIPI DSI: RGB24 and YUV422. YUV422 is not currently handled by the LCDC
driver, but we have to add a define for it for MIPI.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Unchanged from v1.
include/video/sh_mobile_lcdc.h | 39 +--
1 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/include/video/sh_mobile_lcdc.h b/include/video/sh_mobile_lcdc.h
index 2cc893f..5eaea78 100644
--- a/include/video/sh_mobile_lcdc.h
+++ b/include/video/sh_mobile_lcdc.h
@@ -3,24 +3,27 @@
#include linux/fb.h
-enum { RGB8, /* 24bpp, 8:8:8 */
- RGB9, /* 18bpp, 9:9 */
- RGB12A, /* 24bpp, 12:12 */
- RGB12B, /* 12bpp */
- RGB16, /* 16bpp */
- RGB18, /* 18bpp */
- RGB24, /* 24bpp */
- SYS8A, /* 24bpp, 8:8:8 */
- SYS8B, /* 18bpp, 8:8:2 */
- SYS8C, /* 18bpp, 2:8:8 */
- SYS8D, /* 16bpp, 8:8 */
- SYS9, /* 18bpp, 9:9 */
- SYS12, /* 24bpp, 12:12 */
- SYS16A, /* 16bpp */
- SYS16B, /* 18bpp, 16:2 */
- SYS16C, /* 18bpp, 2:16 */
- SYS18, /* 18bpp */
- SYS24 };/* 24bpp */
+enum {
+ RGB8, /* 24bpp, 8:8:8 */
+ RGB9, /* 18bpp, 9:9 */
+ RGB12A, /* 24bpp, 12:12 */
+ RGB12B, /* 12bpp */
+ RGB16, /* 16bpp */
+ RGB18, /* 18bpp */
+ RGB24, /* 24bpp */
+ YUV422, /* 16bpp */
+ SYS8A, /* 24bpp, 8:8:8 */
+ SYS8B, /* 18bpp, 8:8:2 */
+ SYS8C, /* 18bpp, 2:8:8 */
+ SYS8D, /* 16bpp, 8:8 */
+ SYS9, /* 18bpp, 9:9 */
+ SYS12, /* 24bpp, 12:12 */
+ SYS16A, /* 16bpp */
+ SYS16B, /* 18bpp, 16:2 */
+ SYS16C, /* 18bpp, 2:16 */
+ SYS18, /* 18bpp */
+ SYS24, /* 24bpp */
+};
enum { LCDC_CHAN_DISABLED = 0,
LCDC_CHAN_MAINLCD,
--
1.6.2.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 1/4] fbdev: add a MIPI DSI header
On Wed, 19 May 2010, Tomi Valkeinen wrote:
Hi,
On Wed, 2010-05-19 at 10:08 +0200, ext Guennadi Liakhovetski wrote:
Hi Tomi
On Wed, 19 May 2010, Tomi Valkeinen wrote:
The file name is mipi_dsi.h, the comment talks about MIPI, and the file
contains defines for MIPI DSI and MIPI DCS. If you want the file to
contain defines about all MIPI specs, I think the file name should be
just mipi.h.
No, the header is just intended for DSI, the comment could be made more
specific, yes, but DCS is a part of DSI, isn't it?
No, DCS is a spec of its own. DCS can be used on non-DSI displays also.
For example N800 and N900 use DCS commands, but they are not DSI
displays.
Yes, right, I should have said they are related;) How about calling the
header mipi_display.h? This would then unite DSI, DCS, DBI and DPI?
Creating a separate header for each of these standards seems like an
overkill to me. We could then put MIPI CSI and CPI standards in an
include/media/mipi_camera.h. Not sure where to put various other MIPI
standards, I guess, we'll have to think about it as a need arises.
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef MIPI_DSI_H
+#define MIPI_DSI_H
+
+#include linux/types.h
+
+enum mipi_dsi_cmd {
I think these are DSI datatypes, not commands.
hm, write, shut down, mode off, mode on sound like commands to me,
and I think I saw them called commands in the spec, but yes, some of them
are just packet or data types... I'll double-check, thanks.
Well, true, this is not a clear thing. MIPI DSI spec talks about turn
on peripheral command. But the numbers are DSI data types, according to
the spec, and not all of them are commands.
Ok, how about telegram types then?
+ MIPI_DSI_DCS_SHORT_WRITE= 5,
Please use the same number format for all enums. So this should be 0x05.
Where does this requirement come from? Is it in CodingStyle?;)
I don't know, but mixing different formats looks ugly to me =).
This seems to be subjective;) But I'm not religious about it, and since
Nokia (C) is the first in this file I might as well just accept your
proposal;)
+ MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
+ MIPI_DSI_COLOR_MODE_OFF = 2,
+ MIPI_DSI_COLOR_MODE_ON = 0x12,
+ MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
+ MIPI_DSI_TURN_ON_PERIPHERAL = 0x32,
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM= 3,
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM= 0x13,
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM= 0x23,
+ MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 4,
+ MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14,
+ MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24,
+ MIPI_DSI_DCS_LONG_WRITE = 0x39,
+ MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
+ MIPI_DSI_NULL_PACKET= 9,
+ MIPI_DSI_BLANKING_PACKET= 0x19,
+ MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
+ MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0xc,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0xd,
+ MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12= 0x3d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0xe,
+ MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e,
+ MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e,
+};
+
+enum mipi_dcs_cmd {
While the MIPI specs define a certain set of commands, the real panels
usually implement also their own custom commands. That's why I don't
think enum is a good choice here.
Yes, that's a valid point, I'll have to think about it more.
I think a simple solution would be to just use defines, and have
functions that take the command as u8. That's what the OMAP DSI driver
does. If you have better ideas, please share =).
The same applies for the DSI commands/datatypes, although I haven't seen
a panel that has custom DSI datatypes.
As others voted for unnamed enums, how about using them?
Concerning omap2 display drivers
Re: [PATCH 1/4] fbdev: add a MIPI DSI header
On Thu, 20 May 2010, Felipe Balbi wrote: On Thu, May 20, 2010 at 11:32:49AM +0300, Tomi Valkeinen wrote: On Thu, 2010-05-20 at 10:07 +0200, ext Guennadi Liakhovetski wrote: Yes, right, I should have said they are related;) How about calling the header mipi_display.h? This would then unite DSI, DCS, DBI and DPI? Creating a separate header for each of these standards seems like an overkill to me. We could then put MIPI CSI and CPI standards in an include/media/mipi_camera.h. Not sure where to put various other MIPI standards, I guess, we'll have to think about it as a need arises. mipi_display.h sounds good to me. if there are extra mipi standards which should be taken care of, why not include/linux/mipi/[display.h camera.h other1.h other2.h...] ? I thought about this too, but I prefer to separate them thematically: put display standards under video/, camera under media/ etc. This way including these headers from respective drivers and platform code would look more naturally, IMHO. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 1/4 v2] fbdev: add a MIPI DSI header
This header adds defines for MIPI DSI and DCS commands and data formats. See
http://www.mipi.org/ for details.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Ok, how about this? If this is acceptable I'll repost other patches too,
adjusted accordingly.
v1 - v2:
1. renamed mpi_dsi.h to mipi_display.h
2. improved introductory comment
3. changed 10 enum values to match others as 0x0N
4. changed command to transaction
5. added a couple of missing transaction types
6. enums are now unnamed
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
new file mode 100644
index 000..93a4d61
--- /dev/null
+++ b/include/video/mipi_display.h
@@ -0,0 +1,118 @@
+/*
+ * Defines for Mobile Industry Processor Interface (MIPI(R))
+ * Display Working Group standards: DSI, DCS, DBI, DPI
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef MIPI_DISPLAY_H
+#define MIPI_DISPLAY_H
+
+/* MIPI DSI transaction types */
+enum {
+ MIPI_DSI_V_SYNC_START = 0x01,
+ MIPI_DSI_V_SYNC_END = 0x11,
+ MIPI_DSI_H_SYNC_START = 0x21,
+ MIPI_DSI_H_SYNC_END = 0x31,
+
+ MIPI_DSI_COLOR_MODE_OFF = 0x02,
+ MIPI_DSI_COLOR_MODE_ON = 0x12,
+ MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
+ MIPI_DSI_TURN_ON_PERIPHERAL = 0x32,
+
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM= 0x03,
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM= 0x13,
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM= 0x23,
+
+ MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 0x04,
+ MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14,
+ MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24,
+
+ MIPI_DSI_DCS_SHORT_WRITE= 0x05,
+ MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
+
+ MIPI_DSI_DCS_READ = 0x06,
+
+ MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
+
+ MIPI_DSI_END_OF_TRANSMISSION= 0x08,
+
+ MIPI_DSI_NULL_PACKET= 0x09,
+ MIPI_DSI_BLANKING_PACKET= 0x19,
+ MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
+ MIPI_DSI_DCS_LONG_WRITE = 0x39,
+
+ MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0x0c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0x0d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12= 0x3d,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0x0e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e,
+ MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e,
+};
+
+/* MIPI DCS commands */
+enum {
+ MIPI_DCS_NOP= 0x00,
+ MIPI_DCS_SOFT_RESET = 0x01,
+ MIPI_DCS_GET_DISPLAY_ID = 0x04,
+ MIPI_DCS_GET_RED_CHANNEL= 0x06,
+ MIPI_DCS_GET_GREEN_CHANNEL = 0x07,
+ MIPI_DCS_GET_BLUE_CHANNEL = 0x08,
+ MIPI_DCS_GET_DISPLAY_STATUS = 0x09,
+ MIPI_DCS_GET_POWER_MODE = 0x0A,
+ MIPI_DCS_GET_ADDRESS_MODE = 0x0B,
+ MIPI_DCS_GET_PIXEL_FORMAT = 0x0C,
+ MIPI_DCS_GET_DISPLAY_MODE = 0x0D,
+ MIPI_DCS_GET_SIGNAL_MODE= 0x0E,
+ MIPI_DCS_GET_DIAGNOSTIC_RESULT = 0x0F,
+ MIPI_DCS_ENTER_SLEEP_MODE = 0x10,
+ MIPI_DCS_EXIT_SLEEP_MODE= 0x11,
+ MIPI_DCS_ENTER_PARTIAL_MODE = 0x12,
+ MIPI_DCS_ENTER_NORMAL_MODE = 0x13,
+ MIPI_DCS_EXIT_INVERT_MODE = 0x20,
+ MIPI_DCS_ENTER_INVERT_MODE = 0x21,
+ MIPI_DCS_SET_GAMMA_CURVE= 0x26,
+ MIPI_DCS_SET_DISPLAY_OFF= 0x28,
+ MIPI_DCS_SET_DISPLAY_ON = 0x29,
+ MIPI_DCS_SET_COLUMN_ADDRESS = 0x2A,
+ MIPI_DCS_SET_PAGE_ADDRESS = 0x2B,
+ MIPI_DCS_WRITE_MEMORY_START = 0x2C,
+ MIPI_DCS_WRITE_LUT = 0x2D,
+ MIPI_DCS_READ_MEMORY_START = 0x2E,
+ MIPI_DCS_SET_PARTIAL_AREA = 0x30,
+ MIPI_DCS_SET_SCROLL_AREA= 0x33,
+ MIPI_DCS_SET_TEAR_OFF = 0x34,
+ MIPI_DCS_SET_TEAR_ON= 0x35,
+ MIPI_DCS_SET_ADDRESS_MODE = 0x36
Re: [PATCH 1/4] fbdev: add a MIPI DSI header
On Thu, 20 May 2010, Tomi Valkeinen wrote: On Thu, 2010-05-20 at 10:07 +0200, ext Guennadi Liakhovetski wrote: Yes, right, I should have said they are related;) How about calling the header mipi_display.h? This would then unite DSI, DCS, DBI and DPI? Creating a separate header for each of these standards seems like an overkill to me. We could then put MIPI CSI and CPI standards in an include/media/mipi_camera.h. Not sure where to put various other MIPI standards, I guess, we'll have to think about it as a need arises. mipi_display.h sounds good to me. Well, true, this is not a clear thing. MIPI DSI spec talks about turn on peripheral command. But the numbers are DSI data types, according to the spec, and not all of them are commands. Ok, how about telegram types then? I wouldn't invent a new word for this =). The DSI spec talks about commands, data types and transactions, I think we should pick one of them. Perhaps this is already approaching nitpicking, but: As only some of the commands/datatypes/transactions are commands, I think that's not proper word. All of them have a data type number, and I guess they all are transactions. So Turn On Peripheral Command is a transaction, and its data type is 0x32. Yes, transaction looks good to me. I guess if the enum is named, it should then be mipi_dsi_transaction. But then, which one of these would be more correct: dsi_send(enum mipi_dsi_transaction transaction) dsi_send(u8 datatype) As I said previously, I haven't seen any panel using custom datatypes, but I wouldn't be surprised if some panel does. In that sense I would go for using u8, and then perhaps leaving the enum unnamed. What do you think? Yes, I'd use u8 too, because the specs define transaction types to take 6 bits and DCS commands to be 8-bit ints. But, you know, doesn't our case fall under case (b) of Chapter 5 Typedefs of CodingStyle?:) I mean, wouldn't it make sense to create two typedefs for these to add some type-safety? In fact, transaction types cannot be user-defined / proprietary, right? So, for that an enum would work. It's only DCS commands that allow extensions. But making transaction type an enum and command a typedef would be ugly, and making a typedef for an enum is frowned upon too... As others voted for unnamed enums, how about using them? Sounds good. Concerning omap2 display drivers, AFAICS the only thing we want to change there is to switch them too to using the common header and telegram type Yep, I think that's the only change for now. and command names? So far I don't see a need for a generic MIPI (display) subsystem in the kernel with an own bus type, API etc. We could of course create a simpe bus with callbacks for sending short and long packets and reading data back, but do we really need it ATM? This is something I've been thinking about for some time. I even made some prototypes for it, but I didn't have time to go forward with it. It would of course be nice to use the same panel driver on different boards, so I think this is definitely something to think about in the future. But you only need specific panel drivers if you want to support their proprietary commands? Otherwise you only need a set of parameters - timeing requirements etc. - which you can perfectly just pass in platform data? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 1/4 v3] fbdev: add a MIPI DSI header
This header adds defines for MIPI DSI and DCS commands and data formats. See
http://www.mipi.org/ for details.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v2 - v3:
1. added peripheral-to-processor transaction types
v1 - v2:
1. renamed mpi_dsi.h to mipi_display.h
2. improved introductory comment
3. changed 10 enum values to match others as 0x0N
4. changed command to transaction
5. added a couple of missing transaction types
6. enums are now unnamed
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
new file mode 100644
index 000..ddcc8ca
--- /dev/null
+++ b/include/video/mipi_display.h
@@ -0,0 +1,130 @@
+/*
+ * Defines for Mobile Industry Processor Interface (MIPI(R))
+ * Display Working Group standards: DSI, DCS, DBI, DPI
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef MIPI_DISPLAY_H
+#define MIPI_DISPLAY_H
+
+/* MIPI DSI Processor-to-Peripheral transaction types */
+enum {
+ MIPI_DSI_V_SYNC_START = 0x01,
+ MIPI_DSI_V_SYNC_END = 0x11,
+ MIPI_DSI_H_SYNC_START = 0x21,
+ MIPI_DSI_H_SYNC_END = 0x31,
+
+ MIPI_DSI_COLOR_MODE_OFF = 0x02,
+ MIPI_DSI_COLOR_MODE_ON = 0x12,
+ MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
+ MIPI_DSI_TURN_ON_PERIPHERAL = 0x32,
+
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM= 0x03,
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM= 0x13,
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM= 0x23,
+
+ MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 0x04,
+ MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14,
+ MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24,
+
+ MIPI_DSI_DCS_SHORT_WRITE= 0x05,
+ MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
+
+ MIPI_DSI_DCS_READ = 0x06,
+
+ MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
+
+ MIPI_DSI_END_OF_TRANSMISSION= 0x08,
+
+ MIPI_DSI_NULL_PACKET= 0x09,
+ MIPI_DSI_BLANKING_PACKET= 0x19,
+ MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
+ MIPI_DSI_DCS_LONG_WRITE = 0x39,
+
+ MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0x0c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0x0d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12= 0x3d,
+
+ MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0x0e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e,
+ MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e,
+};
+
+/* MIPI DSI Peripheral-to-Processor transaction types */
+enum {
+ MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT= 0x02,
+ MIPI_DSI_RX_END_OF_TRANSMISSION = 0x08,
+ MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE = 0x11,
+ MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE = 0x12,
+ MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE = 0x1a,
+ MIPI_DSI_RX_DCS_LONG_READ_RESPONSE = 0x1c,
+ MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE = 0x21,
+ MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE = 0x22,
+};
+
+/* MIPI DCS commands */
+enum {
+ MIPI_DCS_NOP= 0x00,
+ MIPI_DCS_SOFT_RESET = 0x01,
+ MIPI_DCS_GET_DISPLAY_ID = 0x04,
+ MIPI_DCS_GET_RED_CHANNEL= 0x06,
+ MIPI_DCS_GET_GREEN_CHANNEL = 0x07,
+ MIPI_DCS_GET_BLUE_CHANNEL = 0x08,
+ MIPI_DCS_GET_DISPLAY_STATUS = 0x09,
+ MIPI_DCS_GET_POWER_MODE = 0x0A,
+ MIPI_DCS_GET_ADDRESS_MODE = 0x0B,
+ MIPI_DCS_GET_PIXEL_FORMAT = 0x0C,
+ MIPI_DCS_GET_DISPLAY_MODE = 0x0D,
+ MIPI_DCS_GET_SIGNAL_MODE= 0x0E,
+ MIPI_DCS_GET_DIAGNOSTIC_RESULT = 0x0F,
+ MIPI_DCS_ENTER_SLEEP_MODE = 0x10,
+ MIPI_DCS_EXIT_SLEEP_MODE= 0x11,
+ MIPI_DCS_ENTER_PARTIAL_MODE = 0x12,
+ MIPI_DCS_ENTER_NORMAL_MODE = 0x13,
+ MIPI_DCS_EXIT_INVERT_MODE = 0x20,
+ MIPI_DCS_ENTER_INVERT_MODE = 0x21,
+ MIPI_DCS_SET_GAMMA_CURVE= 0x26
Re: [PATCH 1/4] fbdev: add a MIPI DSI header
Hi Tomi
On Wed, 19 May 2010, Tomi Valkeinen wrote:
Hi,
On Fri, 2010-05-07 at 11:07 +0200, ext Guennadi Liakhovetski wrote:
This header adds defines for MIPI DSI and DCS commands and data formats. See
http://www.mipi.org/ for details.
Did you notice that I have implemented MIPI DSI command mode support for
OMAP processors? It's located in drivers/video/omap2/dss/dsi.c and one
DSI panel driver is located in drivers/video/omap2/displays/panel-taal.c
No, didn't see those, I grepped for MIPI...
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/video/mipi_dsi.h | 99
++
1 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 include/video/mipi_dsi.h
diff --git a/include/video/mipi_dsi.h b/include/video/mipi_dsi.h
new file mode 100644
index 000..5d3a6d6
--- /dev/null
+++ b/include/video/mipi_dsi.h
@@ -0,0 +1,99 @@
+/*
+ * Mobile Industry Processor Interface (MIPI(R)) defines
The file name is mipi_dsi.h, the comment talks about MIPI, and the file
contains defines for MIPI DSI and MIPI DCS. If you want the file to
contain defines about all MIPI specs, I think the file name should be
just mipi.h.
No, the header is just intended for DSI, the comment could be made more
specific, yes, but DCS is a part of DSI, isn't it?
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef MIPI_DSI_H
+#define MIPI_DSI_H
+
+#include linux/types.h
+
+enum mipi_dsi_cmd {
I think these are DSI datatypes, not commands.
hm, write, shut down, mode off, mode on sound like commands to me,
and I think I saw them called commands in the spec, but yes, some of them
are just packet or data types... I'll double-check, thanks.
+ MIPI_DSI_DCS_SHORT_WRITE= 5,
Please use the same number format for all enums. So this should be 0x05.
Where does this requirement come from? Is it in CodingStyle?;)
+ MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
+ MIPI_DSI_COLOR_MODE_OFF = 2,
+ MIPI_DSI_COLOR_MODE_ON = 0x12,
+ MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
+ MIPI_DSI_TURN_ON_PERIPHERAL = 0x32,
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM= 3,
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM= 0x13,
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM= 0x23,
+ MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 4,
+ MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14,
+ MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24,
+ MIPI_DSI_DCS_LONG_WRITE = 0x39,
+ MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
+ MIPI_DSI_NULL_PACKET= 9,
+ MIPI_DSI_BLANKING_PACKET= 0x19,
+ MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
+ MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0xc,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0xd,
+ MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12= 0x3d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0xe,
+ MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e,
+ MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e,
+};
+
+enum mipi_dcs_cmd {
While the MIPI specs define a certain set of commands, the real panels
usually implement also their own custom commands. That's why I don't
think enum is a good choice here.
Yes, that's a valid point, I'll have to think about it more.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 3/4 v2] ARM: add framebuffer support for ap4evb
Hello Morimoto-san On Mon, 10 May 2010, Kuninori Morimoto wrote: diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index 9003ea9..e216132 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -42,6 +42,7 @@ config MACH_AP4EVB bool AP4EVB board depends on ARCH_SH7372 select ARCH_REQUIRE_GPIOLIB + select SH_LCD_MIPI_DSI Why is this select needed here ? Do you want force select MIPI DSI on AP4 ? Not on all AP4 systems, only on ap4evb board, because I thought, that's the display, that it is using. I asked because AP4 board can select other type LCD. (not only MIPI DSI) ap4evb can also have other LCDs attached to it? Then this will have to become a choice between various display types, where the MIPI DSI one will select SH_LCD_MIPI_DSI. We can either do this now or later when more LCD types are added. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 0/4] MIPI DSI support for SH-mobile, common header, switch OMAP to use it
This patch series adds support for the MIPI DSI unit on sh-mobile SoCs, to eliminate redundancy a common mipi_dsi.h header is added. The SH-mobile part depends on pending clock and INTC patches by Magnus. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 2/4] sh-mobile: add support for displays, connected over the MIPI bus
Some SH-mobile SoCs have a MIPI DSI controller, that can be used to connect
MIPI displays to LCDC. This patch adds a platform driver for SH-mobile MIPI DSI
unit. It uses existing hooks in the sh_mobile_lcdcfb.c driver for display
activation and deactivation.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Nothing OMAP-relevant here, just for completeness.
drivers/video/Kconfig |8 +
drivers/video/Makefile |1 +
drivers/video/sh_mipi_dsi.c | 500 +++
include/video/sh_mipi_dsi.h | 35 +++
4 files changed, 544 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/sh_mipi_dsi.c
create mode 100644 include/video/sh_mipi_dsi.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 6e16244..773c4a6 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1879,6 +1879,13 @@ config FB_W100
If unsure, say N.
+config SH_MIPI_DSI
+ tristate
+ depends on (SUPERH || ARCH_SHMOBILE) HAVE_CLK
+
+config SH_LCD_MIPI_DSI
+ bool
+
config FB_SH_MOBILE_LCDC
tristate SuperH Mobile LCDC framebuffer support
depends on FB (SUPERH || ARCH_SHMOBILE) HAVE_CLK
@@ -1887,6 +1894,7 @@ config FB_SH_MOBILE_LCDC
select FB_SYS_IMAGEBLIT
select FB_SYS_FOPS
select FB_DEFERRED_IO
+ select SH_MIPI_DSI if SH_LCD_MIPI_DSI
---help---
Frame buffer driver for the on-chip SH-Mobile LCD controller.
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ddc2af2..3c3bf86 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -123,6 +123,7 @@ obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o
obj-$(CONFIG_FB_PS3) += ps3fb.o
obj-$(CONFIG_FB_SM501)+= sm501fb.o
obj-$(CONFIG_FB_XILINX) += xilinxfb.o
+obj-$(CONFIG_SH_MIPI_DSI)+= sh_mipi_dsi.o
obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o
obj-$(CONFIG_FB_OMAP) += omap/
obj-y += omap2/
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
new file mode 100644
index 000..af0208f
--- /dev/null
+++ b/drivers/video/sh_mipi_dsi.c
@@ -0,0 +1,500 @@
+/*
+ * Renesas SH-mobile MIPI DSI support
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/init.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/string.h
+
+#include video/mipi_dsi.h
+#include video/sh_mipi_dsi.h
+#include video/sh_mobile_lcdc.h
+
+#define CMTSRTCTR 0x80d0
+#define CMTSRTREQ 0x8070
+
+#define DSIINTE0x0060
+
+/* E.g., sh7372 has 2 MIPI-DSIs - one for each LCDC */
+#define MAX_SH_MIPI_DSI 2
+
+struct sh_mipi {
+ void __iomem*base;
+ struct clk *dsit_clk;
+ struct clk *dsip_clk;
+};
+
+static struct sh_mipi *mipi_dsi[MAX_SH_MIPI_DSI];
+
+/* Protect the above array */
+static DEFINE_MUTEX(array_lock);
+
+static struct sh_mipi *sh_mipi_by_handle(int handle)
+{
+ if (handle = ARRAY_SIZE(mipi_dsi) || handle 0)
+ return NULL;
+
+ return mipi_dsi[handle];
+}
+
+static int sh_mipi_send_short(struct sh_mipi *mipi, enum mipi_dsi_cmd dsi_cmd,
+ enum mipi_dcs_cmd cmd, u8 param)
+{
+ u32 data = (dsi_cmd 24) | (cmd 16) | (param 8);
+ int cnt = 100;
+
+ /* transmit a short packet to LCD panel */
+ iowrite32(1 | data, mipi-base + 0x80d0); /* CMTSRTCTR */
+ iowrite32(1, mipi-base + 0x8070); /* CMTSRTREQ */
+
+ while ((ioread32(mipi-base + 0x8070) 1) --cnt)
+ udelay(1);
+
+ return cnt ? 0 : -ETIMEDOUT;
+}
+
+#define LCD_CHAN2MIPI(c) ((c) LCDC_CHAN_MAINLCD || (c) LCDC_CHAN_SUBLCD ? \
+ -EINVAL : (c) - 1)
+
+static int sh_mipi_dcs(int handle, enum mipi_dcs_cmd cmd)
+{
+ struct sh_mipi *mipi = sh_mipi_by_handle(LCD_CHAN2MIPI(handle));
+ if (!mipi)
+ return -ENODEV;
+ return sh_mipi_send_short(mipi, MIPI_DSI_DCS_SHORT_WRITE, cmd, 0);
+}
+
+static int sh_mipi_dcs_param(int handle, enum mipi_dcs_cmd cmd, u8 param)
+{
+ struct sh_mipi *mipi = sh_mipi_by_handle(LCD_CHAN2MIPI(handle));
+ if (!mipi)
+ return -ENODEV;
+ return sh_mipi_send_short(mipi, MIPI_DSI_DCS_SHORT_WRITE_PARAM, cmd,
+ param);
+}
+
+static void sh_mipi_dsi_enable(struct sh_mipi *mipi, bool enable)
+{
+ /*
+* enable LCDC data tx, transition to LPS after completion of each HS
+* packet
+*/
+ iowrite32(0x0002 | enable, mipi-base + 0x8000); /* DTCTR */
+}
+
+static void sh_mipi_shutdown(struct platform_device *pdev
[PATCH 1/4] fbdev: add a MIPI DSI header
This header adds defines for MIPI DSI and DCS commands and data formats. See
http://www.mipi.org/ for details.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
include/video/mipi_dsi.h | 99 ++
1 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 include/video/mipi_dsi.h
diff --git a/include/video/mipi_dsi.h b/include/video/mipi_dsi.h
new file mode 100644
index 000..5d3a6d6
--- /dev/null
+++ b/include/video/mipi_dsi.h
@@ -0,0 +1,99 @@
+/*
+ * Mobile Industry Processor Interface (MIPI(R)) defines
+ *
+ * Copyright (C) 2010 Guennadi Liakhovetski g.liakhovet...@gmx.de
+ * Copyright (C) 2006 Nokia Corporation
+ * Author: Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef MIPI_DSI_H
+#define MIPI_DSI_H
+
+#include linux/types.h
+
+enum mipi_dsi_cmd {
+ MIPI_DSI_DCS_SHORT_WRITE= 5,
+ MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
+ MIPI_DSI_COLOR_MODE_OFF = 2,
+ MIPI_DSI_COLOR_MODE_ON = 0x12,
+ MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
+ MIPI_DSI_TURN_ON_PERIPHERAL = 0x32,
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM= 3,
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM= 0x13,
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM= 0x23,
+ MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM = 4,
+ MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM = 0x14,
+ MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM = 0x24,
+ MIPI_DSI_DCS_LONG_WRITE = 0x39,
+ MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
+ MIPI_DSI_NULL_PACKET= 9,
+ MIPI_DSI_BLANKING_PACKET= 0x19,
+ MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
+ MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0xc,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
+ MIPI_DSI_PACKED_PIXEL_STREAM_30 = 0xd,
+ MIPI_DSI_PACKED_PIXEL_STREAM_36 = 0x1d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR12= 0x3d,
+ MIPI_DSI_PACKED_PIXEL_STREAM_16 = 0xe,
+ MIPI_DSI_PACKED_PIXEL_STREAM_18 = 0x1e,
+ MIPI_DSI_PIXEL_STREAM_3BYTE_18 = 0x2e,
+ MIPI_DSI_PACKED_PIXEL_STREAM_24 = 0x3e,
+};
+
+enum mipi_dcs_cmd {
+ MIPI_DCS_NOP= 0x00,
+ MIPI_DCS_SOFT_RESET = 0x01,
+ MIPI_DCS_GET_DISPLAY_ID = 0x04,
+ MIPI_DCS_GET_RED_CHANNEL= 0x06,
+ MIPI_DCS_GET_GREEN_CHANNEL = 0x07,
+ MIPI_DCS_GET_BLUE_CHANNEL = 0x08,
+ MIPI_DCS_GET_DISPLAY_STATUS = 0x09,
+ MIPI_DCS_GET_POWER_MODE = 0x0A,
+ MIPI_DCS_GET_ADDRESS_MODE = 0x0B,
+ MIPI_DCS_GET_PIXEL_FORMAT = 0x0C,
+ MIPI_DCS_GET_DISPLAY_MODE = 0x0D,
+ MIPI_DCS_GET_SIGNAL_MODE= 0x0E,
+ MIPI_DCS_GET_DIAGNOSTIC_RESULT = 0x0F,
+ MIPI_DCS_ENTER_SLEEP_MODE = 0x10,
+ MIPI_DCS_EXIT_SLEEP_MODE= 0x11,
+ MIPI_DCS_ENTER_PARTIAL_MODE = 0x12,
+ MIPI_DCS_ENTER_NORMAL_MODE = 0x13,
+ MIPI_DCS_EXIT_INVERT_MODE = 0x20,
+ MIPI_DCS_ENTER_INVERT_MODE = 0x21,
+ MIPI_DCS_SET_GAMMA_CURVE= 0x26,
+ MIPI_DCS_SET_DISPLAY_OFF= 0x28,
+ MIPI_DCS_SET_DISPLAY_ON = 0x29,
+ MIPI_DCS_SET_COLUMN_ADDRESS = 0x2A,
+ MIPI_DCS_SET_PAGE_ADDRESS = 0x2B,
+ MIPI_DCS_WRITE_MEMORY_START = 0x2C,
+ MIPI_DCS_WRITE_LUT = 0x2D,
+ MIPI_DCS_READ_MEMORY_START = 0x2E,
+ MIPI_DCS_SET_PARTIAL_AREA = 0x30,
+ MIPI_DCS_SET_SCROLL_AREA= 0x33,
+ MIPI_DCS_SET_TEAR_OFF = 0x34,
+ MIPI_DCS_SET_TEAR_ON= 0x35,
+ MIPI_DCS_SET_ADDRESS_MODE = 0x36,
+ MIPI_DCS_SET_SCROLL_START = 0x37,
+ MIPI_DCS_EXIT_IDLE_MODE = 0x38,
+ MIPI_DCS_ENTER_IDLE_MODE= 0x39,
+ MIPI_DCS_SET_PIXEL_FORMAT = 0x3A,
+ MIPI_DCS_WRITE_MEMORY_CONTINUE = 0x3C,
+ MIPI_DCS_READ_MEMORY_CONTINUE = 0x3E,
+ MIPI_DCS_SET_TEAR_SCANLINE = 0x44,
+ MIPI_DCS_GET_SCANLINE = 0x45,
+ MIPI_DCS_READ_DDB_START = 0xA1,
+ MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
+};
+
+#define MIPI_DCS_PIXEL_FMT_24BIT 7
+#define MIPI_DCS_PIXEL_FMT_18BIT 6
+#define MIPI_DCS_PIXEL_FMT_16BIT 5
+#define MIPI_DCS_PIXEL_FMT_12BIT 3
+#define MIPI_DCS_PIXEL_FMT_8BIT
[PATCH 3/4] ARM: add framebuffer support for ap4evb
ap4evb uses an LCD, connected to the SoC over the MIPI bus. This patch adds
platform data to configure this display and a static clock activation.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Nothing OMAP-relevant here, just for completeness.
arch/arm/mach-shmobile/Kconfig|1 +
arch/arm/mach-shmobile/board-ap4evb.c | 121 +
2 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 9003ea9..e216132 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -42,6 +42,7 @@ config MACH_AP4EVB
bool AP4EVB board
depends on ARCH_SH7372
select ARCH_REQUIRE_GPIOLIB
+ select SH_LCD_MIPI_DSI
comment SH-Mobile System Configuration
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c
b/arch/arm/mach-shmobile/board-ap4evb.c
index d2bb7b0..e3f5375 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -17,6 +17,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include linux/clk.h
#include linux/kernel.h
#include linux/init.h
#include linux/interrupt.h
@@ -32,8 +33,14 @@
#include linux/gpio.h
#include linux/input.h
#include linux/input/sh_keysc.h
+
+#include video/sh_mobile_lcdc.h
+#include video/sh_mipi_dsi.h
+
#include mach/common.h
+#include mach/irqs.h
#include mach/sh7372.h
+
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -237,11 +244,86 @@ static struct platform_device sdhi0_device = {
},
};
+static struct sh_mobile_lcdc_info sh_mobile_lcdc_info = {
+ .clock_source = LCDC_CLK_PERIPHERAL, /* One of interface clocks */
+ .ch[0] = {
+ .chan = LCDC_CHAN_MAINLCD,
+ .bpp = 16,
+ .interface_type = RGB24,
+ .clock_divider = 1,
+ .flags = LCDC_FLAGS_DWPOL,
+ .lcd_cfg = {
+ .name = R63302(QHD),
+ .xres = 544,
+ .yres = 961,
+ .left_margin = 72,
+ .right_margin = 1080,
+ .hsync_len = 16,
+ .upper_margin = 8,
+ .lower_margin = 8,
+ .vsync_len = 2,
+ .sync = FB_SYNC_VERT_HIGH_ACT | FB_SYNC_HOR_HIGH_ACT,
+ },
+ .lcd_size_cfg = {
+ .width = 44,
+ .height = 79,
+ },
+ }
+};
+
+static struct resource lcdc_resources[] = {
+ [0] = {
+ .name = LCDC,
+ .start = 0xfe94, /* P4-only space */
+ .end= 0xfe943fff,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = evt2irq(0x580),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device lcdc_device = {
+ .name = sh_mobile_lcdc_fb,
+ .num_resources = ARRAY_SIZE(lcdc_resources),
+ .resource = lcdc_resources,
+ .dev= {
+ .platform_data = sh_mobile_lcdc_info,
+ .coherent_dma_mask = ~0,
+ },
+};
+
+static struct resource mipidsi0_resources[] = {
+ [0] = {
+ .start = 0xffc6,
+ .end= 0xffc68fff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct sh_mipi_dsi_info mipidsi0_info = {
+ .data_format= MIPI_RGB888,
+ .lcd_chan = sh_mobile_lcdc_info.ch[0],
+};
+
+static struct platform_device mipidsi0_device = {
+ .name = sh-mipi-dsi,
+ .num_resources = ARRAY_SIZE(mipidsi0_resources),
+ .resource = mipidsi0_resources,
+ .id = 0,
+ .dev= {
+ .platform_data = mipidsi0_info,
+ },
+};
+
static struct platform_device *ap4evb_devices[] __initdata = {
nor_flash_device,
smc911x_device,
keysc_device,
sdhi0_device,
+ lcdc_device,
+ mipidsi0_device,
};
static struct map_desc ap4evb_io_desc[] __initdata = {
@@ -265,6 +347,45 @@ static void __init ap4evb_map_io(void)
shmobile_setup_console();
}
+/* This function will disappear when we switch to (runtime) PM */
+static int __init ap4evb_init_display_clk(void)
+{
+ struct clk *lcdc_clk;
+ struct clk *dsitx_clk;
+ int ret;
+
+ lcdc_clk = clk_get(lcdc_device.dev, lcdc0);
+ if (IS_ERR(lcdc_clk))
+ return PTR_ERR(lcdc_clk);
+
+ dsitx_clk = clk_get(mipidsi0_device.dev, dsitx);
+ if (IS_ERR(dsitx_clk)) {
+ ret = PTR_ERR(dsitx_clk);
+ goto eclkdsitxget;
+ }
+
+ ret = clk_enable(lcdc_clk);
+ if (ret 0)
+ goto eclklcdcon
[PATCH 2.5/4] ARM: add LCDC and MIPI DSI-Tx clock definitions to sh7372
Define clock objects for switching on and off clocks for LCDC0, LCDC1 and MIPI
DSI-Tx.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Sorry, one more patch to add to the patch-series. In fact nothing breaks
if you apply this patch before or after the whole series, so, no
regressions, but to get LCD to actually work you also need this one;) And
best put it between patches 2 and 3 of the series - that's where 2.5 comes
from.
arch/arm/mach-shmobile/clock-sh7372.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/clock-sh7372.c
b/arch/arm/mach-shmobile/clock-sh7372.c
index abbc380..66ee47a 100644
--- a/arch/arm/mach-shmobile/clock-sh7372.c
+++ b/arch/arm/mach-shmobile/clock-sh7372.c
@@ -264,8 +264,12 @@ struct clk div6_clks[] = {
#define R_CLK (r_clk)
#define HP_CLK (div4_clks[DIV4_HP])
+#define B_CLK (div4_clks[DIV4_B])
static struct clk mstp_clks[] = {
+ MSTP(lcdc0, B_CLK, SMSTPCR1, 0, 0),
+ MSTP(lcdc1, B_CLK, SMSTPCR1, 17, 0),
+ MSTP(dsitx, B_CLK, SMSTPCR1, 18, 0),
MSTP(sdhi0, HP_CLK, SMSTPCR3, 14, 0),
MSTP(sdhi1, HP_CLK, SMSTPCR3, 13, 0),
MSTP(keysc0, R_CLK, SMSTPCR4, 3, 0),
--
1.6.2.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
[PATCH 1.5/4] sh: add a YUV422 output data format, that is also supported by LCDC
The LCDC block is allowed to use one of the two output data formats, when used
with MIPI DSI: RGB24 and YUV422. YUV422 is not currently handled by the LCDC
driver, but we have to add a define for it for MIPI. Fix indentation while
at it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Hm, this one is actually worse, it actually has to go in before patch 2/4.
Sorry again.
include/video/sh_mobile_lcdc.h | 39 +--
1 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/include/video/sh_mobile_lcdc.h b/include/video/sh_mobile_lcdc.h
index 2cc893f..5eaea78 100644
--- a/include/video/sh_mobile_lcdc.h
+++ b/include/video/sh_mobile_lcdc.h
@@ -3,24 +3,27 @@
#include linux/fb.h
-enum { RGB8, /* 24bpp, 8:8:8 */
- RGB9, /* 18bpp, 9:9 */
- RGB12A, /* 24bpp, 12:12 */
- RGB12B, /* 12bpp */
- RGB16, /* 16bpp */
- RGB18, /* 18bpp */
- RGB24, /* 24bpp */
- SYS8A, /* 24bpp, 8:8:8 */
- SYS8B, /* 18bpp, 8:8:2 */
- SYS8C, /* 18bpp, 2:8:8 */
- SYS8D, /* 16bpp, 8:8 */
- SYS9, /* 18bpp, 9:9 */
- SYS12, /* 24bpp, 12:12 */
- SYS16A, /* 16bpp */
- SYS16B, /* 18bpp, 16:2 */
- SYS16C, /* 18bpp, 2:16 */
- SYS18, /* 18bpp */
- SYS24 };/* 24bpp */
+enum {
+ RGB8, /* 24bpp, 8:8:8 */
+ RGB9, /* 18bpp, 9:9 */
+ RGB12A, /* 24bpp, 12:12 */
+ RGB12B, /* 12bpp */
+ RGB16, /* 16bpp */
+ RGB18, /* 18bpp */
+ RGB24, /* 24bpp */
+ YUV422, /* 16bpp */
+ SYS8A, /* 24bpp, 8:8:8 */
+ SYS8B, /* 18bpp, 8:8:2 */
+ SYS8C, /* 18bpp, 2:8:8 */
+ SYS8D, /* 16bpp, 8:8 */
+ SYS9, /* 18bpp, 9:9 */
+ SYS12, /* 24bpp, 12:12 */
+ SYS16A, /* 16bpp */
+ SYS16B, /* 18bpp, 16:2 */
+ SYS16C, /* 18bpp, 2:16 */
+ SYS18, /* 18bpp */
+ SYS24, /* 24bpp */
+};
enum { LCDC_CHAN_DISABLED = 0,
LCDC_CHAN_MAINLCD,
--
1.6.2.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
[PATCH 3/4 v2] ARM: add framebuffer support for ap4evb
ap4evb uses an LCD, connected to the SoC over the MIPI bus. This patch adds
platform data to configure this display and a static clock activation.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v1 - v2:
Use the correct interrupt number for LCDC, based on INTCS.
arch/arm/mach-shmobile/Kconfig|1 +
arch/arm/mach-shmobile/board-ap4evb.c | 121 +
2 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 9003ea9..e216132 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -42,6 +42,7 @@ config MACH_AP4EVB
bool AP4EVB board
depends on ARCH_SH7372
select ARCH_REQUIRE_GPIOLIB
+ select SH_LCD_MIPI_DSI
comment SH-Mobile System Configuration
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c
b/arch/arm/mach-shmobile/board-ap4evb.c
index d2bb7b0..e3f5375 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -17,6 +17,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include linux/clk.h
#include linux/kernel.h
#include linux/init.h
#include linux/interrupt.h
@@ -32,8 +33,14 @@
#include linux/gpio.h
#include linux/input.h
#include linux/input/sh_keysc.h
+
+#include video/sh_mobile_lcdc.h
+#include video/sh_mipi_dsi.h
+
#include mach/common.h
+#include mach/irqs.h
#include mach/sh7372.h
+
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -237,11 +244,86 @@ static struct platform_device sdhi0_device = {
},
};
+static struct sh_mobile_lcdc_info sh_mobile_lcdc_info = {
+ .clock_source = LCDC_CLK_PERIPHERAL, /* One of interface clocks */
+ .ch[0] = {
+ .chan = LCDC_CHAN_MAINLCD,
+ .bpp = 16,
+ .interface_type = RGB24,
+ .clock_divider = 1,
+ .flags = LCDC_FLAGS_DWPOL,
+ .lcd_cfg = {
+ .name = R63302(QHD),
+ .xres = 544,
+ .yres = 961,
+ .left_margin = 72,
+ .right_margin = 1080,
+ .hsync_len = 16,
+ .upper_margin = 8,
+ .lower_margin = 8,
+ .vsync_len = 2,
+ .sync = FB_SYNC_VERT_HIGH_ACT | FB_SYNC_HOR_HIGH_ACT,
+ },
+ .lcd_size_cfg = {
+ .width = 44,
+ .height = 79,
+ },
+ }
+};
+
+static struct resource lcdc_resources[] = {
+ [0] = {
+ .name = LCDC,
+ .start = 0xfe94, /* P4-only space */
+ .end= 0xfe943fff,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = intcs_evt2irq(0x580),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device lcdc_device = {
+ .name = sh_mobile_lcdc_fb,
+ .num_resources = ARRAY_SIZE(lcdc_resources),
+ .resource = lcdc_resources,
+ .dev= {
+ .platform_data = sh_mobile_lcdc_info,
+ .coherent_dma_mask = ~0,
+ },
+};
+
+static struct resource mipidsi0_resources[] = {
+ [0] = {
+ .start = 0xffc6,
+ .end= 0xffc68fff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct sh_mipi_dsi_info mipidsi0_info = {
+ .data_format= MIPI_RGB888,
+ .lcd_chan = sh_mobile_lcdc_info.ch[0],
+};
+
+static struct platform_device mipidsi0_device = {
+ .name = sh-mipi-dsi,
+ .num_resources = ARRAY_SIZE(mipidsi0_resources),
+ .resource = mipidsi0_resources,
+ .id = 0,
+ .dev= {
+ .platform_data = mipidsi0_info,
+ },
+};
+
static struct platform_device *ap4evb_devices[] __initdata = {
nor_flash_device,
smc911x_device,
keysc_device,
sdhi0_device,
+ lcdc_device,
+ mipidsi0_device,
};
static struct map_desc ap4evb_io_desc[] __initdata = {
@@ -265,6 +347,45 @@ static void __init ap4evb_map_io(void)
shmobile_setup_console();
}
+/* This function will disappear when we switch to (runtime) PM */
+static int __init ap4evb_init_display_clk(void)
+{
+ struct clk *lcdc_clk;
+ struct clk *dsitx_clk;
+ int ret;
+
+ lcdc_clk = clk_get(lcdc_device.dev, lcdc0);
+ if (IS_ERR(lcdc_clk))
+ return PTR_ERR(lcdc_clk);
+
+ dsitx_clk = clk_get(mipidsi0_device.dev, dsitx);
+ if (IS_ERR(dsitx_clk)) {
+ ret = PTR_ERR(dsitx_clk);
+ goto eclkdsitxget;
+ }
+
+ ret = clk_enable(lcdc_clk);
+ if (ret 0
32-bit transfers broken in OMAP SPI driver?
Ran across drivers/spi/omap_spi_100k.c and its handling of 16-bit transfers seems buggy to me. Firstly, addresses do not get incremented in omap1_spi100k_txrx_pio() (word_len = 32) case, a fix for which seems to be obvious, secondly, spi100k_write_data() and spi100k_read_data() only write / read 16-bit data blocks, for which I'm not adventurous enough to propose a patch without even touching the hardware;) Am I right? Maybe just disable 16-bit transfers altogether, since they are broken, and thus, obviously, unused. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: v4l2_device/v4l2_subdev: please review (PATCH 1/3)
On Sat, 29 Nov 2008, Hans Verkuil wrote: +Introduction + + +The V4L2 drivers tend to be very complex due to the complexity of the +hardware: most devices have multiple ICs, export multiple device nodes in +/dev, and create also non-V4L2 devices such as DVB, ALSA, FB, I2C and input +(IR) devices. + +Especially the fact that V4L2 drivers have to setup supporting ICs to +do audio/video muxing/encoding/decoding makes it more complex than most. +Usually these ICs are connected to the main bridge driver through one or +more I2C busses, but other busses can also be used. Such devices are +called 'sub-devices'. Do you know of other busses being used in (Linux supported) real video hardware, or is it currently theoretical only ? The pxa_camera driver is one example of that. Also devices driven by GPIO pins can be implemented this way. I did that in ivtv for example: most cards use i2c audio muxers, but some have audio muxers that are commanded through GPIO so I created a v4l2_subdev that uses GPIO to drive these chips. Works very well indeed. I think pxa-camera (as well as sh-mobile-ceu and other soc-camera host drivers in the works) is not a very good example here. Sensors connected to embedded controllers like PXA indeed use a dedicated camera bus but only for data exchange. This bus comprises of data and synchronisation lines only. Sensors are still connected over an i2c bus for control and configuration, also been open to other busses, I haven't seen such examples as yet. I might have misunderstood what has been discussed here though. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
