OMAPFB problem on 3430SDP
Hi, When running linux-omap kernel on 3430SDP board (version VG5.0.0), the picture on the LCD is very green. It seems to show only green color component, or something like that. TI's own kernel works ok. I've been going through all the DSS registers with Trace32, comparing them between working and non-working kernels, but I haven't been able to find differences. Does linux-omap kernel work ok on earlier SDP versions? This one has 750-2081-102(B) as a display board, (I think the earlier ones have 101). Any ideas what could be missing? Tomi -- 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
Re: Hello Tomi Valkeinen. I wonder about future work plan for new Display Subsystem Driver.
On Fri, 2009-02-27 at 07:04 +0100, ext InKi Dae wrote: > Your patch works fine on my system. > This is good patch. > > Do you have plans that you will apply your patch to mainline and updating ? Yes, the work is ongoing. But it will take time, there is still lots to do. Tomi -- 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: Hello Tomi Valkeinen, I have some questions about dss2 driver.
Hi, On Wed, 2009-03-11 at 05:57 +0100, ext InKi Dae wrote: > I am using your dss2 driver downloaded from your git server and tried > to rotate an image(RGB24U and YUV2 format) using OMAPFB_ROT_DMA > command. > but I can't see rotated image on screen. I added variables for > rotating like below. as the result, LCD Panel is stoped. > > omapfb.rotate=2 > omapfb.vrfb=n > > > and then I tried again using OMAPFB_ROT_VRFB command like below. > > omapfb.rotate=2 > omapfb.vrfb=y > > In this case, I can see rotated image(only RGB24U format) on screen. > You asid "Rotation and mirroring currently only supports RGB565 and > RGB modes. VRFB does not support mirroring" through > /Documentation/arm/OMAP/DSS file. > > Doesn't your dss2 driver support DMA rotation? It does. However, you should use DMA rotation only with OMAP2 when the framebuffer is in SRAM. It seems to work somewhat on OMAP3 and SDRAM, but I've noticed it doesn't always work. I don't know if lowering pixel clock, increasing dss fck or fiddling with fifo sizes could affect it. > I am trying to add rotation feature for YUV2 image using VRFB to your > dss2 driver. > > for this, I think that it have to change rot and mirror become 0 if > rotation_type is OMAPFB_ROT_VRFB to be rot=ofbi->rotation and mirror = > ofbi->mirror (in omapfb-main.c file) and > add codes for calculating offset0, offset1, pixel increment and row > increment value for YUV2 format also pixel size becomes 4 in YUV2 case > (in dispc.c fild). > omap_vrfb_setup function must be modifed also (in vrfb.c file)? > > Do you have any idea? No, I haven't really looked at YUV rotations. Tomi > I need your help and advice. > > Thank you. > - InKi- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend/Resume support with Omap2fb
Hi, On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote: > Hi, > > I am using New Frame-Buffer driver which is based on DSS2 library submitted > by Tomi, and I am trying to add full power management support. But things are > not working out as expected, every time when I am issuing command "echo mem > > /sys/power/state" the system doesn't go into off state. It always points to > dss_prwdm, below are the steps I am following - OFF mode should work. I have verified it with DSI, DPI and SDI. However, it needs passing the get_last_off_on_transaction_id pointer in omap_dss_platform_data. Also, see below. > - Build the kernel with CPU_IDLE > - Enable all the PM flags > > # echo 1 > /sys/power/sleep_while_idle > # echo 1 > /sys/power/clocks_off_while_idle > # echo 1 > /sys/power/enable_off_mode > > - From Linux prompt issue command > > # echo mem > /sys/power/state > > The log is - > > > r...@arago:~# echo mem > /sys/power/state > <6>PM: Syncing filesystems ... PM: Syncing filesystems ... done. > done. > Freezing user space processes ... Freezing user space processes ... (elapsed > 0.00 seconds) (elapsed 0.00 seconds) done. > done. > Freezing remaining freezable tasks ... Freezing remaining freezable tasks ... > (elapsed 0.06 seconds) (elapsed 0.06 seconds) done.done. > Suspending console(s) (use no_console_suspend to debug) > Suspending console(s) (use no_console_suspend to debug) > <6>omap-backlight: suspending... > omapfb_suspend > > omapfb_resume > <6>omap-backlight: resuming... > omap-backlight: suspending... > omapfb_suspend > Powerdomain (core_pwrdm) didn't enter target state 0 > Powerdomain (dss_pwrdm) didn't enter target state 0 > Powerdomain (per_pwrdm) didn't enter target state 0 > Could not enter target state in pm_suspend > eth0: link down > omapfb_resume > omap-backlight: resuming... > Restarting tasks ... Restarting tasks ... done. > done. > > r...@arago:~# > > > Some analysis which I observed during debugging this issue - > > - The root-cause is, DSS PowerDomain always shows it is in ON state > (PWRDM_POWER_ON), and if I understand correctly this is only dependent on > clocks. But I am making sure that DSS clocks are disabled. And with CPU_IDLE > enabled I am going to complete OFF state. > (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is incrementing). > > - If I compile out framebuffer driver and include DSS2 and V4L2 driver, > everything works fine. I am not sure how "omapfb" is being tied with > PowerDomain. Again I have seen references in > arch/arm/mach-omap2/omapdev3xxx.h to the pdev_name = "omapfb", not sure how > this is being used. You have to change it to omapdss (or omap-dss in earlier DSS2 versions). Tomi > > I believe if system is hitting OFF state, then my enable/disable paths are > proper, but really not sure about why "mem" is causing problem here. > > Thanks, > Vaibhav Hiremath > Platform Support Products > Texas Instruments Inc > Ph: +91-80-25099927 > > > Thanks, > Vaibhav Hiremath > Platform Support Products > Texas Instruments Inc > Ph: +91-80-25099927 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
On Wed, 2009-03-11 at 09:46 +0100, ext Hiremath, Vaibhav wrote: > > Thanks, > Vaibhav Hiremath > > > -Original Message----- > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > Sent: Wednesday, March 11, 2009 1:23 PM > > To: Hiremath, Vaibhav > > Cc: linux-omap@vger.kernel.org > > Subject: Re: Suspend/Resume support with Omap2fb > > > > Hi, > > > > On Wed, 2009-03-11 at 07:55 +0100, ext Hiremath, Vaibhav wrote: > > > Hi, > > > > > > I am using New Frame-Buffer driver which is based on DSS2 library > > submitted by Tomi, and I am trying to add full power management > > support. But things are not working out as expected, every time when > > I am issuing command "echo mem > /sys/power/state" the system > > doesn't go into off state. It always points to dss_prwdm, below are > > the steps I am following - > > > > OFF mode should work. I have verified it with DSI, DPI and SDI. > > However, > > it needs passing the get_last_off_on_transaction_id pointer in > > omap_dss_platform_data. > > > > Also, see below. > > > [Hiremath, Vaibhav] I believe this is only required when you do save and > restore context right? Well, yes. But you need to save and restore context if you want OFF mode. > Actually I have modified that part of code where it doesn't expect this > pointer and save/restore happens perfectly fine, which I am very will sure > about, since I am hitting state5 of CPU_IDLE (Full OFF state) and it resumes > back with the same state. > > Again one more data point which I missed in last mail is, I am following > clk->usecount which shows me 0. That means clocks are already disabled. > > r...@arago:~# cat /sys/devices/platform/omap-dss/clk > - dss - > internal clk count 0 > dss_ick 83000 > dss1_alwon_fck 96000 > dss2_alwon_fck 13000 > dss_tv_fck 54000 > dss_96m_fck 96000 > - dispc - > dispc fclk source = dss1_alwon_fclk > pixel clk = 9600 / 1 / 5 = 1920 > r...@arago:~# > > > > > - Build the kernel with CPU_IDLE > > > - Enable all the PM flags > > > > > > # echo 1 > /sys/power/sleep_while_idle > > > # echo 1 > /sys/power/clocks_off_while_idle > > > # echo 1 > /sys/power/enable_off_mode > > > > > > - From Linux prompt issue command > > > > > > # echo mem > /sys/power/state > > > > > > The log is - > > > > > > > > > r...@arago:~# echo mem > /sys/power/state > > > <6>PM: Syncing filesystems ... PM: Syncing filesystems ... done. > > > done. > > > Freezing user space processes ... Freezing user space processes > > ... (elapsed 0.00 seconds) (elapsed 0.00 seconds) done. > > > done. > > > Freezing remaining freezable tasks ... Freezing remaining > > freezable tasks ... (elapsed 0.06 seconds) (elapsed 0.06 seconds) > > done.done. > > > Suspending console(s) (use no_console_suspend to debug) > > > Suspending console(s) (use no_console_suspend to debug) > > > <6>omap-backlight: suspending... > > > omapfb_suspend > > > > > > omapfb_resume > > > <6>omap-backlight: resuming... > > > omap-backlight: suspending... > > > omapfb_suspend > > > Powerdomain (core_pwrdm) didn't enter target state 0 > > > Powerdomain (dss_pwrdm) didn't enter target state 0 > > > Powerdomain (per_pwrdm) didn't enter target state 0 > > > Could not enter target state in pm_suspend > > > eth0: link down > > > omapfb_resume > > > omap-backlight: resuming... > > > Restarting tasks ... Restarting tasks ... done. > > > done. > > > > > > r...@arago:~# > > > > > > > > > Some analysis which I observed during debugging this issue - > > > > > > - The root-cause is, DSS PowerDomain always shows it is in ON > > state (PWRDM_POWER_ON), and if I understand correctly this is only > > dependent on clocks. But I am making sure that DSS clocks are > > disabled. And with CPU_IDLE enabled I am going to complete OFF > > state. (/sys/devices/system/cpu/cpu0/cpuidle/state5/usage is > > incrementing). > > > > > > - If I compile out framebuffer driver and include DSS2 and > > V4L2 driver, everything works fine. I am not sure how "omapfb" is > > being tied with PowerDomain. Again I have seen r
RE: Suspend/Resume support with Omap2fb
On Wed, 2009-03-11 at 11:47 +0100, ext Hiremath, Vaibhav wrote: > > > > > > How have you tested this? > > > Have you also tested with "echo mem > /sys/power/state"? > > > Are you using Kevin's power management tree? What is default > > configuration of your kernel during this test? > > > > It's been some time since I tested it, but it did work on OMAP3 SDP > > with > > the pm-branch. Only changed needed were the > > get_last_off_on_transaction_id and omapfb -> omapdss. I also tested > > echo > > mem > > > > > I'll try to find time to test it again with latest trees. > > > [Hiremath, Vaibhav] That would be great, I am also trying few things here at > my end. Hopefully I will get something. Yeah, it works ok for me. I rebased my DSS2 tree to latest l-o, then merged pm-branch, and made the changes mentioned above. I get some warnings from getnstimeofday when resuming the kernel, but they seem to be unrelated to DSS, and the image is fine after resume. I used my dss_omap_3430sdp_defconfig and made the following commands to enable PM: echo 1 > /sys/power/clocks_off_while_idle echo 1 > /sys/power/enable_off_mode echo 1 > /sys/power/voltage_off_while_idle echo 1 > /sys/power/sleep_while_idle Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
Hi,
On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote:
> Hi,
>
> Finally I could able to find the root-cause, actually some of the previous
> observations miss-led me to dig into power management, suspend/resume path
> and clock structure. But after bit debugging and with the help of Sanjeev, we
> got the rid of it.
>
> The issue is with DSS2 library, inside function "dpi_display_suspend". It
> calls dispc_enable_lcd_out(0), but doesn't wait till the frame-done
> interrupt. And due to this I was getting some abrupt behavior in
> suspend/resume path.
> Actually in the beginning I overlooked legacy frame-buffer driver, which
> handles this scenario perfectly.
dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the latest DSS2
version from my git repository =).
Tomi
>
> For Display sub-system we have 2 interface clocks coming, L3_ICLK and
> L4_ICLK. Out of these, L4_ICLK goes to Display register access and L3_ICLK
> goes to DMA register. In our suspend call we are disabling clocks for L3_ICLK
> (we don't control L4_ICLK), and due to this L4_ICLK stays attached with GFX.
> You will only be able to find out this by looking to
> CM_CLKSTST_DSS.CLKACTIVITY_DSS, which is set 1 and indicates some interface
> clock is still active in DSS domain.
>
> Below is the patch which will explain the change
>
>
> +#include
> +#include
>
> +static void dpi_display_isr(void *arg, unsigned int irqstatus)
> +{
> + struct omap_display *display = (struct omap_display *)arg;
> +
> + complete(&display->frame_done);
> +}
>
> static int dpi_display_suspend(struct omap_display *display)
> {
> + void *handle = NULL;
> +
> if (display->state != OMAP_DSS_DISPLAY_ACTIVE)
> return -EINVAL;
>
> if (display->panel->suspend)
> display->panel->suspend(display);
>
> + /*
> +* Wait for frame done interrupt
> +*/
> + handle = omap_dispc_register_isr(dpi_display_isr, display,
> + DISPC_IRQ_FRAMEDONE);
> + if (!handle)
> + return -EINVAL;
> +
> + init_completion(&display->frame_done);
> +
> dispc_enable_lcd_out(0);
> + if (!wait_for_completion_timeout(&display->frame_done,
> + msecs_to_jiffies(500))) {
> + printk("timeout waiting for FRAME DONE\n");
> + }
>
> Still I need to test this thoroughly, I may hit some another issue (Already I
> am seeing some crashes also when off state is enabled). I will create
> consolidated patch for this and will submit to list.
>
> Thanks,
> Vaibhav Hiremath
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
On Fri, 2009-03-13 at 10:10 +0100, ext Hiremath, Vaibhav wrote: > > Thanks, > Vaibhav Hiremath > > > -Original Message----- > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > Sent: Friday, March 13, 2009 2:01 PM > > To: Hiremath, Vaibhav > > Cc: linux-omap@vger.kernel.org > > Subject: RE: Suspend/Resume support with Omap2fb > > > > Hi, > > > > On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote: > > > Hi, > > > > > > Finally I could able to find the root-cause, actually some of the > > previous observations miss-led me to dig into power management, > > suspend/resume path and clock structure. But after bit debugging and > > with the help of Sanjeev, we got the rid of it. > > > > > > The issue is with DSS2 library, inside function > > "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but doesn't > > wait till the frame-done interrupt. And due to this I was getting > > some abrupt behavior in suspend/resume path. > > > Actually in the beginning I overlooked legacy frame-buffer driver, > > which handles this scenario perfectly. > > > > dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the latest > > DSS2 > > version from my git repository =). > > > [Hiremath, Vaibhav] Ohhh great, but I think yesterday only I pulled changes > from your repository, and it was not there. > > Ok, but it's great that you merged the change. No, it's been there for quite a while... (weeks, months, I don't remember). Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suspend/Resume support with Omap2fb
On Fri, 2009-03-13 at 10:17 +0100, ext Hiremath, Vaibhav wrote: > > > > Hi, > > > > > > > > On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote: > > > > > Hi, > > > > > > > > > > Finally I could able to find the root-cause, actually some of > > the > > > > previous observations miss-led me to dig into power management, > > > > suspend/resume path and clock structure. But after bit debugging > > and > > > > with the help of Sanjeev, we got the rid of it. > > > > > > > > > > The issue is with DSS2 library, inside function > > > > "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but > > doesn't > > > > wait till the frame-done interrupt. And due to this I was > > getting > > > > some abrupt behavior in suspend/resume path. > > > > > Actually in the beginning I overlooked legacy frame-buffer > > driver, > > > > which handles this scenario perfectly. > > > > > > > > dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the > > latest > > > > DSS2 > > > > version from my git repository =). > > > > > > > [Hiremath, Vaibhav] Ohhh great, but I think yesterday only I > > pulled changes from your repository, and it was not there. > > > > > > Ok, but it's great that you merged the change. > > > > No, it's been there for quite a while... (weeks, months, I don't > > remember). > > > [Hiremath, Vaibhav] May be I looked into wrong branch, can you please provide > in which branch of yours the change is? So that I can validate my changes and > make it more close to yours, it will be easy for me to migrate in the future. All the latest DSS2 stuff is in the master branch. Tomi -- 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
Latest l-o and usb gadget + NFS root problems
Hi, There seems to be something wrong with latest l-o, usb gadget ethernet and nfsroot. I'm not sure when it broke, but 2.6.29-rc3 worked fine. This happens to me with beagleboard and a non-public omap3 board: g_ether gadget: high speed config #1: CDC Ethernet (ECM) IP-Config: Guessing netmask 255.255.255.0 IP-Config: Complete: device=usb0, addr=192.168.2.15, mask=255.255.255.0, gw=255.255.255.255, host=192.168.2.15, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=192.168.2.14, rootpath= Looking up port of RPC 13/2 on 192.168.2.14 Looking up port of RPC 15/1 on 192.168.2.14 VFS: Mounted root (nfs filesystem) on device 0:12. Freeing init memory: 140K nfs: server 192.168.2.14 not responding, still trying nfs: server 192.168.2.14 not responding, still trying ... With the nonpublic board I was able to boot up occasionally, but it failed after doing something heavier on the nfs filesystem. Tomi -- 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: Latest l-o and usb gadget + NFS root problems
Hi, On Fri, 2009-03-27 at 11:38 +0100, ext Koen Kooi wrote: > Op 27 mrt 2009, om 10:40 heeft Tomi Valkeinen het volgende geschreven: > > > Hi, > > > > There seems to be something wrong with latest l-o, usb gadget ethernet > > and nfsroot. I'm not sure when it broke, but 2.6.29-rc3 worked fine. > > This happens to me with beagleboard and a non-public omap3 board: > > > > g_ether gadget: high speed config #1: CDC Ethernet (ECM) > > IP-Config: Guessing netmask 255.255.255.0 > > IP-Config: Complete: > >device=usb0, addr=192.168.2.15, mask=255.255.255.0, > > gw=255.255.255.255, > >host=192.168.2.15, domain=, nis-domain=(none), > >bootserver=255.255.255.255, rootserver=192.168.2.14, rootpath= > > Looking up port of RPC 13/2 on 192.168.2.14 > > Looking up port of RPC 15/1 on 192.168.2.14 > > VFS: Mounted root (nfs filesystem) on device 0:12. > > Freeing init memory: 140K > > nfs: server 192.168.2.14 not responding, still trying > > nfs: server 192.168.2.14 not responding, still trying > > ... > > > > With the nonpublic board I was able to boot up occasionally, but it > > failed after doing something heavier on the nfs filesystem. > > Are you running with lockdep enabled or disabled? I was using default beagle defconfig, plus gadget eth compiled into kernel. DEBUG_LOCKDEP seems to be off. Tomi -- 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: Fwd: dss2 with dsi
Hi, Please send DSS2 issues directly to me (cc l-o if you want to). I may miss them otherwise. On Thu, 2009-04-16 at 04:17 +0200, ext Rebecca Schultz Zavin wrote: > I'm using dss2 on a dsi panel and I've run into a few limitations in > the present implementation. I'd like to post the fixes, but I'd > appreciate some guidance, especially since I'm working without the > mipi spec so it isn't always clear to me what's a function of the > implementation vs. the spec. The DSI implementation is generally quite limited currently. I have only one DSI display configuration to test it with, so I opted to leave out the complexity of full VC control for now. There has been enough problems just to get it working properly with one DSI peripheral =). > 1- I think the destination vc set in dsi.vc[n].dest_per should be > specifiable from either the dsi controller or the board file? Any > preference on which? Could be added to omap_ctrl or to > omap_dss_display_type. I believe it should be in the board file. As I said I have only one DSI display with hardcoded vc-id, but I imagine it would be possible to have DSI peripherals that can respond to a configurable vc-id. Thus board file would be the only place where they can be spesified. > > 2- The code hard codes vc0 for L4 and v1 for dispc. My controller > exepects the reverse. Again I think this should come from some struct > in either the controller or the board file. Preferences? The OMAP DSI virtual channel implementation is a bit confusing at first. The VC register sets do not say where the packets go. So if you send data with VC0, it doesn't mean that the packets go to the peripheral with vc-id 0. So even if L4 and DISPC code use different VC register sets, they both go to the same peripheral with id 0. This id is defined in the dest_per field mentioned above. I used two separate VCs just to make debugging simpler, as I only need to configure the VC once and thats it. Otherwise I would need to change the VC0 back and forth between L4 mode to DISPC mode. I don't see why this wouldn't work, and my plan is to use just one VC register set for one peripheral at some point. > > 3- The code hard codes the complexio timing values used for setting > DSIPHY_CFG0, 1 and 2. I think these values should be specified in the > omap_ctrl the way rfbi_timings are. I don't remember what settings there is but aren't they specified in MIPI DSI spec? If so, they should be the same for all peripherals. At least in theory =). Tomi -- 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: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi Valkeinen, I have some questions about dss2 driver.]
Hi Hardik and Tim, Thanks for the patches. They look fine to me, and are applied to my tree. Tomi On Wed, 2009-04-15 at 11:35 +0200, ext Shah, Hardik wrote: > Hi Tomi, > Can you please merge the YUV rotation patches with your latest? > > Thanks and Regards, > Haardik > > > -Original Message- > > From: plasma...@gmail.com [mailto:plasma...@gmail.com] On Behalf Of Tim > > Yamin > > Sent: Tuesday, April 14, 2009 2:30 AM > > To: Shah, Hardik > > Cc: grego...@gentil.com; tomi.valkei...@nokia.com; > > linux-omap@vger.kernel.org; > > beaglebo...@googlegroups.com > > Subject: Re: YUV rotation support for DSS2 - 2.6.29 [WAS Re: Hello Tomi > > Valkeinen, I have some questions about dss2 driver.] > > > > Hi Hardik, > > > > Thanks for fixing up the patch. I can confirm that YUV rotation is > > fine and patches are ready to be merged -- although the attached fix > > is needed as well for the userspace layer to know the correct row > > strides when writing YUV to the framebuffer. > > > > I'm still having VID1_FIFO_UNDERFLOW errors when I try to play rotated > > video on plane 1 and plane 0 is rotated as well. Do you have any ideas > > how to debug this further? > > > > Thanks, > > > > Tim > > > > > Hi Tomi, > > > If YUV rotation with frame buffer passes can you please review the patch > > > and > > merge it to your latest. > > > > > > Regards, > > > Hardik -- 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: Fwd: dss2 with dsi
On Thu, 2009-04-16 at 20:21 +0200, ext Rebecca Schultz Zavin wrote: > That clarifies things a lot. I don't have the MIPI dsi spec so I'm > working from reference code from TI and the limited documentation in > the omap TRM. I'll see if I can't get things working without that > change. My advice is: get the spec ;). Seriously, you'll save a lot of time if you don't have to guess and reverse engineer things. > >> > >> 3- The code hard codes the complexio timing values used for setting > >> DSIPHY_CFG0, 1 and 2. I think these values should be specified in the > >> omap_ctrl the way rfbi_timings are. > > > > I don't remember what settings there is but aren't they specified in > > MIPI DSI spec? If so, they should be the same for all peripherals. At > > least in theory =). > > I don't know about this, again I don't have the spec. I'll see if I > can use your values. Were they specified as a range possibly? Yes, they have minimum and maximum values. I have some comments in dsi_complexio_timings() about mins and maxes, but they are quite old. I guess I should verify that they are what the spec says. > > Speaking of which, one of the other things I ran into was the > controller expecting some packets with different data_type fields. > The reference code I'm working from called these "generic" but I have > no idea if they are part of the spec or just vendor specific. I added > a couple of functions that let you pass the data_type, but if they are > common to the spec it'd be easier to just treat them the same way you > did with the dcs types. Do you remember whether the spec specified > any additional types? I have these: > > #define GENERIC_WRITE_LONG_CMD 0x29 > #define GENERIC_WRITE_SHORT_1 0x23 > #define GENERIC_WRITE_SHORT_0 0x13 > #define GENERIC_READ_CMD 0x14 > #define GENERIC_SHORT_READ10x11 > #define GENERIC_SHORT_READ20x12 > #define GENERIC_LONG_READ0x1a Yes, these are defined in the DSI spec. I have not implemented them as my display doesn't support those. If I remember right, generic commands are used to convey vendor spesific data. So there could be an API for generic datatypes in dsi.c, but the actual code using them needs to be in the display driver. Tomi -- 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] OMAP2/3: DMA: implement trans copy and const fill
Implement transparent copy and constant fill features for OMAP2/3.
Signed-off-by: Tomi Valkeinen
---
arch/arm/plat-omap/dma.c | 81 +
arch/arm/plat-omap/include/mach/dma.h |1 +
2 files changed, 52 insertions(+), 30 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 3fd0e77..060ac71 100755
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -310,41 +310,62 @@ EXPORT_SYMBOL(omap_set_dma_transfer_params);
void omap_set_dma_color_mode(int lch, enum omap_dma_color_mode mode, u32 color)
{
- u16 w;
-
BUG_ON(omap_dma_in_1510_mode());
- if (cpu_class_is_omap2()) {
- REVISIT_24XX();
- return;
- }
+ if (cpu_class_is_omap1()) {
+ u16 w;
- w = dma_read(CCR2(lch));
- w &= ~0x03;
+ w = dma_read(CCR2(lch));
+ w &= ~0x03;
- switch (mode) {
- case OMAP_DMA_CONSTANT_FILL:
- w |= 0x01;
- break;
- case OMAP_DMA_TRANSPARENT_COPY:
- w |= 0x02;
- break;
- case OMAP_DMA_COLOR_DIS:
- break;
- default:
- BUG();
+ switch (mode) {
+ case OMAP_DMA_CONSTANT_FILL:
+ w |= 0x01;
+ break;
+ case OMAP_DMA_TRANSPARENT_COPY:
+ w |= 0x02;
+ break;
+ case OMAP_DMA_COLOR_DIS:
+ break;
+ default:
+ BUG();
+ }
+ dma_write(w, CCR2(lch));
+
+ w = dma_read(LCH_CTRL(lch));
+ w &= ~0x0f;
+ /* Default is channel type 2D */
+ if (mode) {
+ dma_write((u16)color, COLOR_L(lch));
+ dma_write((u16)(color >> 16), COLOR_U(lch));
+ w |= 1; /* Channel type G */
+ }
+ dma_write(w, LCH_CTRL(lch));
}
- dma_write(w, CCR2(lch));
- w = dma_read(LCH_CTRL(lch));
- w &= ~0x0f;
- /* Default is channel type 2D */
- if (mode) {
- dma_write((u16)color, COLOR_L(lch));
- dma_write((u16)(color >> 16), COLOR_U(lch));
- w |= 1; /* Channel type G */
+ if (cpu_class_is_omap2()) {
+ u32 val;
+
+ val = dma_read(CCR(lch));
+ val &= ~((1 << 17) | (1 << 16));
+
+ switch (mode) {
+ case OMAP_DMA_CONSTANT_FILL:
+ val |= 1 << 16;
+ break;
+ case OMAP_DMA_TRANSPARENT_COPY:
+ val |= 1 << 17;
+ break;
+ case OMAP_DMA_COLOR_DIS:
+ break;
+ default:
+ BUG();
+ }
+ dma_write(val, CCR(lch));
+
+ color &= 0xff;
+ dma_write(color, COLOR(lch));
}
- dma_write(w, LCH_CTRL(lch));
}
EXPORT_SYMBOL(omap_set_dma_color_mode);
diff --git a/arch/arm/plat-omap/include/mach/dma.h
b/arch/arm/plat-omap/include/mach/dma.h
index 224b077..4e34f47 100644
--- a/arch/arm/plat-omap/include/mach/dma.h
+++ b/arch/arm/plat-omap/include/mach/dma.h
@@ -144,6 +144,7 @@
#define OMAP_DMA4_CSSA_U(n)0
#define OMAP_DMA4_CDSA_L(n)0
#define OMAP_DMA4_CDSA_U(n)0
+#define OMAP1_DMA_COLOR(n) 0
/**/
--
1.6.1.2
--
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/3] OMAP2/3 V4L2 Display Driver
Hi, On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote: > This is the version 5th of the Driver. > > Following are the features supported. > 1. Provides V4L2 user interface for the video pipelines of DSS > 2. Basic streaming working on LCD and TV. > 3. Support for various pixel formats like YUV, UYVY, RGB32, RGB24, RGB565 > 4. Supports Alpha blending. > 5. Supports Color keying both source and destination. > 6. Supports rotation with RGB565 and RGB32 pixels formats. > 7. Supports cropping. > 8. Supports Background color setting. > 9. Works on latest DSS2 library from Tomi > http://www.bat.org/~tomba/git/linux-omap-dss.git/ > 10. 1/4x scaling added. Detail testing left > > TODOS > 1. Ioctls needs to be added for color space conversion matrix > coefficient programming. > 2. To be tested on DVI resolutions. > > Comments fixed from community. > 1. V4L2 Driver for OMAP3/3 DSS. > 2. Conversion of the custom ioctls to standard V4L2 ioctls like alpha > blending, > color keying, rotation and back ground color setting > 3. Re-organised the code as per community comments. > 4. Added proper copyright year. > 5. Added module name in printk > 6. Kconfig option copy/paste error > 7. Module param desc addded. > 8. Query control implemented using standard query_fill > 9. Re-arranged if-else constructs. > 10. Changed to use mutex instead of semaphore. > 11. Removed dual usage of rotation angles. > 12. Implemented function to convert the V4L2 angle to DSS angle. > 13. Y-position was set half by video driver for TV output > Now its done by DSS so removed that. > 14. Minor cleanup > 15. Added support to pass the page offset to application. > 14. Minor cleanup > 15. Added support to pass the page offset to application. > 16. Renamed V4L2_CID_ROTATION to V4L2_CID_ROTATE > 17. Major comment from Hans fixed. > 18. Copy right year changed. > 19. Added module name for each error/warning print message. > > Changes from Previous Version. > 1. Supported YUV rotation. > 2. Supported Flipping. > 3. Rebased line with Tomi's latest DSS2 master branch with commit id > f575a02edf2218a18d6f2ced308b4f3e26b44ce2. > 4. Kconfig option removed to select between the TV and LCD. > Now supported dynamically by DSS2 library. > 5. Kconfig option for the NTSC_M and PAL_BDGHI mode but not > supported by DSS2. so it will not work now. There is basic support for this. See the DSS doc: /sys/devices/platform/omapdss/display? directory: ... timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw) When writing, two special timings are accepted for tv-out: "pal" and "ntsc" Tomi -- 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: OpenGL flicker issue in Android
On Wed, 2009-05-20 at 14:16 +0200, ext Elvis Dowson wrote: > Hi Tomi, > Would you be able to shed some light on the OpenGL flicker > issue when using Android with TI OMAP 3503 or 3530 hardware? > > > > I can see transient background image artifacts when working with the > widgets, and some say that this maybe a bug in the framebuffer > driver? > > > OpenGL composition artefacts - android-porting | Google Groups > Are you using DSS2 driver? But sounds like a double buffering issue in the application to me. How do you do double buffering? Tomi -- 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
"Dummy" regulator possible?
Hi, Let's say I have a device that requires power from a regulator, like OMAP3430 SDP Sharp LCD's "Vcc". Then I have two boards with the same device. One board gives power to the device from an always-on regulator, like SDP does with VBAT going to the LCD. The other board gives power to the device from a controllable regulator, say, VAUXy. Is it possible to create a dummy regulator, so that the device driver could always ask for Vcc supply, and get it, even when it's connected to a always-on regulator? Or what would be the correct approach to this? Tomi -- 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: DSS2: SYNC Lost error on mirroring enabled
On Fri, 2009-05-29 at 03:32 +0200, ext Venkatesh, Subbu wrote: > Hi, > I am getting SYNC LOSTerror on OMAP development board ( LDP ), this happens > when I enable mirroring by a command > > #echo 1 > /sys/class/graphics/fb0/mirror > > In brief, recently I ported board related funtions to support both LCD and TV > displays on Omap LDP, mirroring works on TV but not LCD. Attached log gives > more details. > Any inputs are appreciated. You need to use VRFB rotation, DMA rotation is only meant for SRAM framebuffers. Tomi -- 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: DSS2: SYNC Lost error on mirroring enabled
Hi, On Fri, 2009-05-29 at 14:06 +0200, ext Venkatesh, Subbu wrote: > Hello Tomi, > I have no problem with the Roatation using VRFB. > Curretnly the issue is with the Mirroring. Using VRFB for mirroring has no > effect as I see in the omapfb-main.c, if Rotation type is VRFB, then > mirror=0. So I cannot use mirroring at all. I meant that VRFB is used also for mirroring, and so you need VRFB. But true, VRFB mirroring is currently disabled, and doesn't seem to work. Tomi > > Regards, > Subbu > ____ > From: Tomi Valkeinen [tomi.valkei...@nokia.com] > Sent: Friday, May 29, 2009 1:51 AM > To: Venkatesh, Subbu > Cc: linux-omap@vger.kernel.org; Shah, Hardik; Castaneda Gonzalez, Axel; > Mande, Nikhil > Subject: Re: DSS2: SYNC Lost error on mirroring enabled > > On Fri, 2009-05-29 at 03:32 +0200, ext Venkatesh, Subbu wrote: > > Hi, > > I am getting SYNC LOSTerror on OMAP development board ( LDP ), this happens > > when I enable mirroring by a command > > > > #echo 1 > /sys/class/graphics/fb0/mirror > > > > In brief, recently I ported board related funtions to support both LCD and > > TV displays on Omap LDP, mirroring works on TV but not LCD. Attached log > > gives more details. > > Any inputs are appreciated. > > You need to use VRFB rotation, DMA rotation is only meant for SRAM > framebuffers. > > Tomi > > > -- 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: DSS2: How to test TV and LCD output simulatenously
Hi, On Tue, 2009-06-02 at 06:22 +0200, ext halli manjunatha wrote: > Hi subbu, > first boot the board including omapfb.vram="1:2M"in boootargs > and follow the below steps it will enable both just try it it should work You don't need to use the module parameters for that. You can allocate memory for the framebuffer by echoing echo mem-amount > /sys/class/graphics/fb?/size Note that the overlays connected to that framebuffer need to be disabled. Also, in your example below, you don't even use fb1, so I don't see much point in allocating 2M for it. Tomi > > > *** > echo "0" > /sys/devices/platform/omapdss/overlay0/enabled > echo "0" > /sys/devices/platform/omapdss/overlay1/enabled > > echo "" > /sys/class/graphics/fb1/overlays > echo "0,1" > /sys/class/graphics/fb0/overlays > > echo "720,564" > /sys/devices/platform/omapdss/overlay1/output_size > echo "tv" > /sys/devices/platform/omapdss/overlay1/manager > > echo "1" > /sys/devices/platform/omapdss/overlay0/enabled > echo "1" > /sys/devices/platform/omapdss/overlay1/enabled > > > echo "1" > /sys/devices/platform/omapdss/display2/enabled > > > > ** > > > On Tue, Jun 2, 2009 at 7:54 AM, Venkatesh, Subbu wrote: > > Hi, > > I have DSS2 ported on LDP board, I could manage to get output display on TV > > and LCD interface individually, also tested some of the features like > > Rotation and Mirroring, they worked with out any problem. > > Now I am trying to get output both on TV and LCD simultaneously, > > > > I was not successful with my approach that I tried, like > > > > 1. Boot the kernel with the default LCD display > > 2. Then I enabled ntsc timings for TV, as PAL do not work on it. > >#echo ntsc > /sys/devices/platform/omapdss/display1/timings > > 3. Enabled TV > > # echo 1 > /sys/devices/platform/omapdss/display1/enable > > and did the common fb test > > But it did not seem to work. > > Its nice if someone has different working approach or can suggest me where > > I am going wrong in the above steps. > > > > Regards, > > Subbu > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSS2: How to test TV and LCD output simulatenously
Hi, On Tue, 2009-06-02 at 13:52 +0200, ext Gary Thomas wrote: > Venkatesh, Subbu wrote: > > Hi, > > I have DSS2 ported on LDP board, I could manage to get output display on TV > > and LCD interface individually, also tested some of the features like > > Rotation and Mirroring, they worked with out any problem. > > What does "DSS2 ported on LDP board" mean? What source tree/branch did you > use? He was using my DSS2 tree from http://www.bat.org/~tomba/git/linux-omap-dss.git (or some older version of it). > > > Now I am trying to get output both on TV and LCD simultaneously, > > > > I was not successful with my approach that I tried, like > > > > 1. Boot the kernel with the default LCD display > > 2. Then I enabled ntsc timings for TV, as PAL do not work on it. > > #echo ntsc > /sys/devices/platform/omapdss/display1/timings > > 3. Enabled TV > > # echo 1 > /sys/devices/platform/omapdss/display1/enable > > and did the common fb test > > But it did not seem to work. > > Its nice if someone has different working approach or can suggest me where > > I am going wrong in the above steps. > > Is this stuff documented somewhere? Like the difference > between DSS1 and DSS2? How the various layers and overlays > are supposed to work? What about the camera interface? It's documented in DSS2 documentation, Documentation/arm/OMAP/DSS. Of course knowledge of OMAP's display subsystem is required, and that information can be found from the OMAP TRM. I have no idea about the camera, it has nothing to do with DSS. Tomi -- 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: DSS2: Compilation Error on Git tree http://www.bat.org/~tomba/git/linux-omap-dss.git
On Wed, 2009-06-03 at 16:07 +0200, ext Venkatesh, Subbu wrote: > Hi Tomi, > I did git pull to update my tree, later compiling code for LDP, I am getting > compilation error as show below. I see that I am missing declaration of > struct omap_dss_display_config in display.h file, could you please comment > on it... You need to port your LDP changes to newer DSS2 device model. Check how it's done with OMAP SDP or Beagleboard. Tomi -- 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: DSS porting problems
On Thu, 2009-06-04 at 23:22 +0200, ext Gary Thomas wrote: > I'm porting my platform (3530, very similar to LDP) to your tree. > http://www.bat.org/~tomba/git/linux-omap-dss.git > Since you have complete support for the 3430SDP, I started with > that board file. I've added my own display (larger Hitachi > screen that is 800x600). I've run into a few problems: > > * All output to the main frame buffer (/dev/fb0) seems to go to > the very last line of the display. Difficult to say anything about this. The problem could be in the board file configuration, or in the panel driver. > > * The documentation (Documentation/arm/OMAP/DSS) does not seem > to match what's in sysfs. In particular, there are no "horizontal" > or "vertical" fields in the displayN tree. This makes the examples > of how to clone, etc, not work. Thanks, I pushed a fix for the documentation. Tomi -- 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
Setting dss1_alwon_fck
Hi, Mans Rullgard has the patches mentioned below in his kernel tree at http://git.mansr.com/?p=linux-omap;a=summary . I currently have those patches and use the following sequence to set the dss1_alwon_fck clock: /* get the rate of the parent of dpll4_m4_ck, which is dpll4_ck */ prate = clk_get_rate(clk_get_parent(dispc.dpll4_m4_ck)); /* calculate divisor so that wanted dss1_alwon_fck is prate / div * 2. * x2 because dss1_alwon_fck comes from dpll4_m4x2_ck */ div = ...; /* set the rate */ clk_set_rate(dispc.dpll4_m4_ck, prate / div); Is this the correct way to set dss1_alwon_fck? Are the patches below needed, or can dss1_alwon_fck be set some other way? Tomi commit e2de5e5578fbaa9b4b75074796da0608fc93e6ae Author: Mans Rullgard <[EMAIL PROTECTED]> Date: Tue Jul 22 01:58:18 2008 +0100 ARM: OMAP: add clk_get_parent() for OMAP2/3 Signed-off-by: Mans Rullgard <[EMAIL PROTECTED]> :100644 100644 577be44... 28aec36... M arch/arm/mach-omap2/clock.c :100644 100644 49245f7... 4aa69d5... M arch/arm/mach-omap2/clock.h :100644 100644 54cc6e1... ed7af21... M arch/arm/mach-omap2/clock24xx.c :100644 100644 04dedec... 08c8c46... M arch/arm/mach-omap2/clock34xx.c commit 2b7b958dc79e51127d7a4ecf88ce12dbc6c31426 Author: Mans Rullgard <[EMAIL PROTECTED]> Date: Tue Jul 22 01:31:11 2008 +0100 ARM: OMAP: make dpll4_m4_ck programmable with clk_set_rate() Filling the set_rate and round_rate fields of dpll4_m4_ck makes this clock programmable through clk_set_rate(). This is needed to give omapfb control over the dss1_alwon_fck rate. :100644 100644 161da12... 876eb13... M arch/arm/mach-omap2/clock34xx.h -- 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
Re: [PATCH] OMAPFB: fix printing of reserved memory
On Fri, 2008-10-17 at 14:45 -0700, ext Tony Lindgren wrote:
> * Tomi Valkeinen <[EMAIL PROTECTED]> [080912 03:27]:
> > Print reserved memory only if it was actually reserved.
>
> Can you reply with your Signed-off-by?
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
>
> Thanks,
>
> Tony
>
> > ---
> >
> > arch/arm/plat-omap/fb.c |5 +++--
> > 1 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
> > index f9927a7..63c82ef 100644
> > --- a/arch/arm/plat-omap/fb.c
> > +++ b/arch/arm/plat-omap/fb.c
> > @@ -207,9 +207,10 @@ void __init omapfb_reserve_sdram(void)
> > config_invalid = 1;
> > return;
> > }
> > - if (rg.paddr)
> > + if (rg.paddr) {
> > reserve_bootmem(rg.paddr, rg.size, BOOTMEM_DEFAULT);
> > - reserved += rg.size;
> > + reserved += rg.size;
> > + }
> > omapfb_config.mem_desc.region[i] = rg;
> > configured_regions++;
> > }
> >
> > --
> > 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
--
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
[REVIEW PATCH 0/9] DSS: Series description
New Display Subsystem for OMAP2/3 - This patch set implements new Display Subsystem (DSS) for OMAP2/3 processors. The DSS is still under work and these patches are for review. Note that there is also another new DSS implementation from TI. The DSS has been tested on OMAP3 SDP board, Beagle Board and on two unreleased boards with DSI and SDI displays. The DSS used to work on OMAP2 board also, but it's been a while since I was able to test with OMAP2 board. The first patch is a doc file that tries to explain a bit how the drivers work. The patch set is based on the current linux-omap tree. You can find the patches also from a git tree at http://www.bat.org/~tomba/git/linux-omap-dss.git/ Note that you also need two patches from Mans Rullgard to make things work. These are needed to be able to reconfigure DSS functional clock. http://git.mansr.com/?p=linux-omap;a=commit;h=e2de5e5578fbaa9b4b75074796da0608fc93e6ae http://git.mansr.com/?p=linux-omap;a=commit;h=2b7b958dc79e51127d7a4ecf88ce12dbc6c31426 Questions/problems -- Perhaps the biggest problems I have is the interface to user space. OMAP hardware doesn't quite fit in to the framebuffer framework. The problem is that a framebuffer can go to multiple overlays, and also the target display, to which a framebuffer goes, can change. In addition, the framebuffer size is used as overlay size, not display resolution. So a framebuffer != display. I believe DRM modesetting could be of help here, at least partially, but I haven't tried that approach yet. But DRM modesetting wouldn't solve all the problems. For example, we still need to configure overlays and overlay managers, and they don't quite belong to either the framebuffer side or the display side. Currently you configure them via a hackish sysfs interface, but I've been wondering if a /dev/omap-dss device with ioctls would be a better choice. There's currently no V4L2 support, but I have been thinking about that. I don't want to make any hardcoded configuration for those, because sometimes you want to use framebuffer devices for video overlays. So what I'd like to have is a way, compile time or run time, to configure which overlays go to framebuffer devices and which go to V4L2 devices. --- Tomi Valkeinen (9): DSS: support for OMAP3 SDP board DSS: support for Beagle Board DSS: Add generic DVI panel DSS: OMAPFB: fb driver for new display subsystem DSS: DSI support for OMAP2/3 DSS DSS: TV-out support for OMAP2/3 DSS DSS: RFBI support for OMAP2/3 DSS DSS: New display subsystem driver for OMAP2/3 DSS: Documentation for OMAP2/3 display subsystem Documentation/arm/OMAP/DSS| 240 ++ arch/arm/mach-omap2/board-3430sdp.c | 234 ++ arch/arm/mach-omap2/board-omap3beagle.c | 121 + arch/arm/plat-omap/Kconfig|2 arch/arm/plat-omap/Makefile |2 arch/arm/plat-omap/dss/Kconfig| 66 + arch/arm/plat-omap/dss/Makefile |6 arch/arm/plat-omap/dss/dispc.c| 1667 arch/arm/plat-omap/dss/display.c | 781 +++ arch/arm/plat-omap/dss/dpi.c | 303 +++ arch/arm/plat-omap/dss/dsi.c | 3027 + arch/arm/plat-omap/dss/dss.c | 547 + arch/arm/plat-omap/dss/dss.h | 240 ++ arch/arm/plat-omap/dss/rfbi.c | 1234 arch/arm/plat-omap/dss/sdi.c | 154 + arch/arm/plat-omap/dss/venc.c | 499 + arch/arm/plat-omap/fb.c |9 arch/arm/plat-omap/include/mach/display.h | 458 arch/arm/plat-omap/include/mach/omapfb.h |7 drivers/video/Kconfig |1 drivers/video/Makefile|1 drivers/video/omap/Kconfig|5 drivers/video/omap2/Kconfig | 54 + drivers/video/omap2/Makefile |5 drivers/video/omap2/omapfb-ioctl.c| 428 drivers/video/omap2/omapfb-main.c | 1247 drivers/video/omap2/omapfb-sysfs.c| 833 drivers/video/omap2/omapfb.h | 104 + drivers/video/omap2/panel-dvi.c | 121 + drivers/video/omap2/panel-sdp3430.c | 110 + 30 files changed, 12479 insertions(+), 27 deletions(-) create mode 100644 Documentation/arm/OMAP/DSS create mode 100644 arch/arm/plat-omap/dss/Kconfig create mode 100644 arch/arm/plat-omap/dss/Makefile create mode 100644 arch/arm/plat-omap/dss/dispc.c create mode 100644 arch/arm/plat-omap/dss/display.c create mode 100644 arch/arm/plat-omap/dss/dpi.c create mode 100644 arch/arm/plat-omap/dss/dsi.c create mode 100644 arch/arm/plat-omap/dss/dss.c create mode 100644 arch/arm/plat-omap/dss/dss.h create mode 100644 arch/arm/plat-omap/dss/rfbi.c create mode 100644 arch/arm/plat-omap/dss/sdi
[REVIEW PATCH 1/9] DSS: Documentation for OMAP2/3 display subsystem
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]> --- Documentation/arm/OMAP/DSS | 240 1 files changed, 240 insertions(+), 0 deletions(-) create mode 100644 Documentation/arm/OMAP/DSS diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS new file mode 100644 index 000..992ee76 --- /dev/null +++ b/Documentation/arm/OMAP/DSS @@ -0,0 +1,240 @@ +OMAP2/3 Display Subsystem +- + +This is an almost total rewrite of the OMAP FB driver in drivers/video/omap +(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI, +TV-out and multiple display support. + +The DSS2 driver (omap-dss module) is in arch/arm/plat-omap/dss/, and the FB, +panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live +currently side by side, you can choose which one to use. + +Features + + +Working and tested features include: + +- MIPI DPI (parallel) output +- MIPI DSI output in command mode +- MIPI DBI (RFBI) output (not tested for a while, might've gotten broken) +- SDI output +- TV output +- All pieces can be compiled as a module or inside kernel +- Use DISPC to update any of the outputs +- Use CPU to update RFBI or DSI output +- OMAP DISPC planes +- RGB16, RGB24 packed, RGB24 unpacked +- YUV2, UYVY +- Scaling +- Adjusting DSS FCK to find a good pixel clock +- Use DSI DPLL to create DSS FCK + +omap-dss driver + + +The DSS driver does not itself have any support for Linux framebuffer, V4L or +such like the current ones, but it has an internal kernel API that upper level +drivers can use. + +The DSS driver models OMAP's overlays, overlay managers and displays in a +flexible way to enable non-common multi-display configuration. In addition to +modelling the hardware overlays, omap-dss supports virtual overlays and overlay +managers. These can be used when updating a display with CPU or system DMA, +instead of DISPC. + +Panel and controller drivers + + +The drivers implement panel or controller specific functionality and are not +visible to users except through omapfb driver. They register themselves to the +DSS driver. + +omapfb driver +- + +The omapfb driver implements arbitrary number of standard linux framebuffers. +These framebuffers can be routed flexibly to any overlays, thus allowing very +dynamic display architecture. + +The driver exports some omapfb specific ioctls, which are compatible with the +ioctls in the old driver. + +The rest of the non standard features are exported via sysfs. Whether the final +implementation will use sysfs, or ioctls, is still open. + +V4L2 drivers + + +Currently there are no V4L2 display drivers planned, but it is possible to +implement such either to omapfb driver, or as a separate one. From omap-dss +point of view the V4L2 drivers should be similar to framebuffer driver. + +Architecture + + +Some clarification what the different components do: + +- Framebuffer is a memory area inside OMAP's SDRAM that contains the pixel + data for the image. Framebuffer has width and height and color depth. +- Overlay defines where the pixels are read from and where they go on the + screen. The overlay may be smaller than framebuffer, thus displaying only + part of the framebuffer. The position of the overlay may be changed if + the overlay is smaller than the display. +- Overlay manager combines the overlays in to one image and feeds them to + display. +- Display is the actual physical display device. + +A framebuffer can be connected to multiple overlays to show the same pixel data +on all of the overlays. Note that in this case the overlay input sizes are the +same, but, in case of scalable video overlays, the output size can be +different. Any framebuffer can be connected to any overlay. + +An overlay can be connected to one overlay manager. Also DISPC overlays can be +connected only to DISPC overlay managers, and virtual overlays can be only +connected to virtual overlays. + +An overlay manager can be connected to one display. There are certain +restrictions which kinds of displays an overlay manager can be connected: + +- DISPC TV overlay manager can be only connected to TV display. +- Virtual overlay managers can only be connected to DBI or DSI displays. +- DISPC LCD overlay manager can be connected to all displays, except TV + display. + +Sysfs +- +The sysfs interface is a hack, but works for testing. I don't think sysfs +interface is the best for this in the final version, but I don't quite know +what would be the best interfaces for these things. + +In /sys/devices/platform/omapfb we have four files: framebuffers, +overlays, managers and displays. You can read them so see the current +setup, and change them by writing to it in the form of +" : :..." + +"framebuffers" l
[REVIEW PATCH 3/9] DSS: RFBI support for OMAP2/3 DSS
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/dss/rfbi.c | 1234 +
1 files changed, 1234 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/dss/rfbi.c
diff --git a/arch/arm/plat-omap/dss/rfbi.c b/arch/arm/plat-omap/dss/rfbi.c
new file mode 100644
index 000..31ddd24
--- /dev/null
+++ b/arch/arm/plat-omap/dss/rfbi.c
@@ -0,0 +1,1234 @@
+/*
+ * linux/arch/arm/plat-omap/dss/rfbi.c
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen <[EMAIL PROTECTED]>
+ *
+ * Some code and ideas taken from drivers/video/omap/ driver
+ * by Imre Deak.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define DSS_SUBSYS_NAME "RFBI"
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include "dss.h"
+
+/*#define MEASURE_PERF*/
+
+#define RFBI_BASE 0x48050800
+
+struct rfbi_reg { u16 idx; };
+
+#define RFBI_REG(idx) ((const struct rfbi_reg) { idx })
+
+#define RFBI_REVISION RFBI_REG(0x)
+#define RFBI_SYSCONFIG RFBI_REG(0x0010)
+#define RFBI_SYSSTATUS RFBI_REG(0x0014)
+#define RFBI_CONTROL RFBI_REG(0x0040)
+#define RFBI_PIXEL_CNT RFBI_REG(0x0044)
+#define RFBI_LINE_NUMBER RFBI_REG(0x0048)
+#define RFBI_CMD RFBI_REG(0x004c)
+#define RFBI_PARAM RFBI_REG(0x0050)
+#define RFBI_DATA RFBI_REG(0x0054)
+#define RFBI_READ RFBI_REG(0x0058)
+#define RFBI_STATUSRFBI_REG(0x005c)
+
+#define RFBI_CONFIG(n) RFBI_REG(0x0060 + (n)*0x18)
+#define RFBI_ONOFF_TIME(n) RFBI_REG(0x0064 + (n)*0x18)
+#define RFBI_CYCLE_TIME(n) RFBI_REG(0x0068 + (n)*0x18)
+#define RFBI_DATA_CYCLE1(n)RFBI_REG(0x006c + (n)*0x18)
+#define RFBI_DATA_CYCLE2(n)RFBI_REG(0x0070 + (n)*0x18)
+#define RFBI_DATA_CYCLE3(n)RFBI_REG(0x0074 + (n)*0x18)
+
+#define RFBI_VSYNC_WIDTH RFBI_REG(0x0090)
+#define RFBI_HSYNC_WIDTH RFBI_REG(0x0094)
+
+#define RFBI_CMD_FIFO_LEN_BYTES (16 * sizeof(struct update_param))
+
+#define REG_FLD_MOD(idx, val, start, end) \
+ rfbi_write_reg(idx, FLD_MOD(rfbi_read_reg(idx), val, start, end))
+
+/* To work around an RFBI transfer rate limitation */
+#define OMAP_RFBI_RATE_LIMIT1
+
+enum omap_rfbi_cycleformat {
+ OMAP_DSS_RFBI_CYCLEFORMAT_1_1 = 0,
+ OMAP_DSS_RFBI_CYCLEFORMAT_2_1 = 1,
+ OMAP_DSS_RFBI_CYCLEFORMAT_3_1 = 2,
+ OMAP_DSS_RFBI_CYCLEFORMAT_3_2 = 3,
+};
+
+enum omap_rfbi_datatype {
+ OMAP_DSS_RFBI_DATATYPE_12 = 0,
+ OMAP_DSS_RFBI_DATATYPE_16 = 1,
+ OMAP_DSS_RFBI_DATATYPE_18 = 2,
+ OMAP_DSS_RFBI_DATATYPE_24 = 3,
+};
+
+enum omap_rfbi_parallelmode {
+ OMAP_DSS_RFBI_PARALLELMODE_8 = 0,
+ OMAP_DSS_RFBI_PARALLELMODE_9 = 1,
+ OMAP_DSS_RFBI_PARALLELMODE_12 = 2,
+ OMAP_DSS_RFBI_PARALLELMODE_16 = 3,
+};
+
+enum update_cmd {
+ RFBI_CMD_UPDATE = 0,
+ RFBI_CMD_SYNC = 1,
+};
+
+static int rfbi_convert_timings(struct rfbi_timings *t);
+static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
+static void process_cmd_fifo(void);
+
+static struct {
+ void __iomem*base;
+
+ struct clk *dss_ick;
+ struct clk *dss1_fck;
+
+ unsigned long l4_khz;
+
+ enum omap_rfbi_datatype datatype;
+ enum omap_rfbi_parallelmode parallelmode;
+
+ enum omap_rfbi_te_mode te_mode;
+ int te_enabled;
+
+ void (*framedone_callback)(void *data);
+ void *framedone_callback_data;
+
+ struct omap_display *display[2];
+
+ struct kfifo *cmd_fifo;
+ spinlock_tcmd_lock;
+ struct completion cmd_done;
+ atomic_t cmd_fifo_full;
+ atomic_t cmd_pending;
+#ifdef MEASURE_PERF
+ ktime_t perf_time;
+#endif
+} rfbi;
+
+struct update_region {
+ u16 x;
+ u16 y;
+ u16 w;
+ u16 h;
+};
+
+struct update_param {
+ u8 rfbi_module;
+ u8 cmd;
+
+ union {
+ struct update_region r;
+ struct completion *sync;
+ } par;
+};
+
+static inline void rfbi_write_reg(const struct rfbi_reg idx, u32 val)
+{
+ __raw_writel(val, rfbi.base + idx.idx);
+}
+
+static inline u32 rfbi_read_reg(const struct rfbi_reg idx)
+{
+ return __raw_readl(rfbi.base + idx.idx)
[REVIEW PATCH 4/9] DSS: TV-out support for OMAP2/3 DSS
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/dss/venc.c | 499 +
1 files changed, 499 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/dss/venc.c
diff --git a/arch/arm/plat-omap/dss/venc.c b/arch/arm/plat-omap/dss/venc.c
new file mode 100644
index 000..a9739ad
--- /dev/null
+++ b/arch/arm/plat-omap/dss/venc.c
@@ -0,0 +1,499 @@
+/*
+ * linux/arch/arm/plat-omap/dss/venc.c
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen <[EMAIL PROTECTED]>
+ *
+ * VENC settings from TI's DSS driver
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define DSS_SUBSYS_NAME "VENC"
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "dss.h"
+
+#define VENC_BASE 0x48050C00
+
+/* Venc registers */
+#define VENC_REV_ID0x00
+#define VENC_STATUS0x04
+#define VENC_F_CONTROL 0x08
+#define VENC_VIDOUT_CTRL 0x10
+#define VENC_SYNC_CTRL 0x14
+#define VENC_LLEN 0x1C
+#define VENC_FLENS 0x20
+#define VENC_HFLTR_CTRL0x24
+#define VENC_CC_CARR_WSS_CARR 0x28
+#define VENC_C_PHASE 0x2C
+#define VENC_GAIN_U0x30
+#define VENC_GAIN_V0x34
+#define VENC_GAIN_Y0x38
+#define VENC_BLACK_LEVEL 0x3C
+#define VENC_BLANK_LEVEL 0x40
+#define VENC_X_COLOR 0x44
+#define VENC_M_CONTROL 0x48
+#define VENC_BSTAMP_WSS_DATA 0x4C
+#define VENC_S_CARR0x50
+#define VENC_LINE210x54
+#define VENC_LN_SEL0x58
+#define VENC_L21__WC_CTL 0x5C
+#define VENC_HTRIGGER_VTRIGGER 0x60
+#define VENC_SAVID__EAVID 0x64
+#define VENC_FLEN__FAL 0x68
+#define VENC_LAL__PHASE_RESET 0x6C
+#define VENC_HS_INT_START_STOP_X 0x70
+#define VENC_HS_EXT_START_STOP_X 0x74
+#define VENC_VS_INT_START_X0x78
+#define VENC_VS_INT_STOP_X__VS_INT_START_Y 0x7C
+#define VENC_VS_INT_STOP_Y__VS_EXT_START_X 0x80
+#define VENC_VS_EXT_STOP_X__VS_EXT_START_Y 0x84
+#define VENC_VS_EXT_STOP_Y 0x88
+#define VENC_AVID_START_STOP_X 0x90
+#define VENC_AVID_START_STOP_Y 0x94
+#define VENC_FID_INT_START_X__FID_INT_START_Y 0xA0
+#define VENC_FID_INT_OFFSET_Y__FID_EXT_START_X 0xA4
+#define VENC_FID_EXT_START_Y__FID_EXT_OFFSET_Y 0xA8
+#define VENC_TVDETGP_INT_START_STOP_X 0xB0
+#define VENC_TVDETGP_INT_START_STOP_Y 0xB4
+#define VENC_GEN_CTRL 0xB8
+#define VENC_OUTPUT_CONTROL0xC4
+#define VENC_DAC_B__DAC_C 0xC8
+
+static DECLARE_MUTEX(venc_lock);
+
+struct venc_config {
+ u32 f_control;
+ u32 vidout_ctrl;
+ u32 sync_ctrl;
+ u32 llen;
+ u32 flens;
+ u32 hfltr_ctrl;
+ u32 cc_carr_wss_carr;
+ u32 c_phase;
+ u32 gain_u;
+ u32 gain_v;
+ u32 gain_y;
+ u32 black_level;
+ u32 blank_level;
+ u32 x_color;
+ u32 m_control;
+ u32 bstamp_wss_data;
+ u32 s_carr;
+ u32 line21;
+ u32 ln_sel;
+ u32 l21__wc_ctl;
+ u32 htrigger_vtrigger;
+ u32 savid__eavid;
+ u32 flen__fal;
+ u32 lal__phase_reset;
+ u32 hs_int_start_stop_x;
+ u32 hs_ext_start_stop_x;
+ u32 vs_int_start_x;
+ u32 vs_int_stop_x__vs_int_start_y;
+ u32 vs_int_stop_y__vs_ext_start_x;
+ u32 vs_ext_stop_x__vs_ext_start_y;
+ u32 vs_ext_stop_y;
+ u32 avid_start_stop_x;
+ u32 avid_start_stop_y;
+ u32 fid_int_start_x__fid_int_start_y;
+ u32 fid_int_offset_y__fid_ext_start_x;
+ u32 fid_ext_start_y__fid_ext_offset_y;
+ u32 tvdetgp_int_start_stop_x;
+ u32 tvdetgp_int_start_stop_y;
+ u32 gen_ctrl;
+
+ int width;
+ int height;
+};
+
+/* from TRM */
+static c
[REVIEW PATCH 7/9] DSS: Add generic DVI panel
For some reason we can't allocate enough mem for 1280x1024x24bpp, even if
there should be enough continuous mem. So 1280x1024 mode defaults to
16bpp for now.
You also need DSI PLL to generate pix clock for 1280x1024.
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
drivers/video/omap2/Kconfig | 20 ++
drivers/video/omap2/Makefile|2 +
drivers/video/omap2/panel-dvi.c | 121 +++
3 files changed, 143 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/panel-dvi.c
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index 4b72479..4584e1b 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -24,6 +24,26 @@ config FB_OMAP2_FORCE_AUTO_UPDATE
menu "OMAP2/3 Display Device Drivers"
depends on OMAP2_DSS
+config PANEL_DVI
+tristate "DVI Panel"
+help
+ DVI output, for Beagle and OMAP3 SDP
+
+choice
+ prompt "Default DVI Mode"
+ depends on PANEL_DVI
+ default PANEL_DVI_HIGHRES
+
+config PANEL_DVI_LOWRES
+ bool "800 x 600 @ 60"
+
+config PANEL_DVI_HIGHRES
+ bool "1024 x 768 @ 60"
+
+config PANEL_DVI_VERYHIGHRES
+ bool "1280 x 1024 @ 57"
+
+endchoice
endmenu
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 51c2e00..7c75340 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_FB_OMAP2) += omapfb.o
omapfb-y := omapfb-main.o omapfb-sysfs.o omapfb-ioctl.o
+
+obj-$(CONFIG_PANEL_DVI) += panel-dvi.o
diff --git a/drivers/video/omap2/panel-dvi.c b/drivers/video/omap2/panel-dvi.c
new file mode 100644
index 000..2d053df
--- /dev/null
+++ b/drivers/video/omap2/panel-dvi.c
@@ -0,0 +1,121 @@
+/*
+ * DVI panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen <[EMAIL PROTECTED]>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include
+#include
+
+#include
+
+static int dvi_panel_init(struct omap_display *display)
+{
+ return 0;
+}
+
+static int dvi_panel_enable(struct omap_display *display)
+{
+ int r = 0;
+
+ if (display->hw_config.panel_enable)
+ r = display->hw_config.panel_enable(display);
+
+ return r;
+}
+
+static void dvi_panel_disable(struct omap_display *display)
+{
+ if (display->hw_config.panel_disable)
+ display->hw_config.panel_disable(display);
+}
+
+static struct omap_panel dvi_panel = {
+ .owner = THIS_MODULE,
+ .name = "panel-dvi",
+ .init = dvi_panel_init,
+ /*.remove = dvi_cleanup, */
+ .enable = dvi_panel_enable,
+ .disable= dvi_panel_disable,
+ /*.set_mode = dvi_set_mode, */
+
+#if defined(CONFIG_PANEL_DVI_LOWRES)
+ .timings = {
+ /* 800 x 600 @ 60 Hz Reduced blanking VESA CVT 0.48M3-R */
+ .pixel_clock= 35500,
+ .hfp= 48,
+ .hsw= 32,
+ .hbp= 80,
+ .vfp= 3,
+ .vsw= 4,
+ .vbp= 11,
+ },
+
+ .x_res = 800,
+ .y_res = 600,
+ .bpp= 24,
+#elif defined(CONFIG_PANEL_DVI_HIGHRES)
+ .timings = {
+ /* 1024 x 768 @ 60 Hz Reduced blanking */
+ .pixel_clock= 56000,
+ .hfp= 48,
+ .hsw= 32,
+ .hbp= 80,
+ .vfp= 3,
+ .vsw= 4,
+ .vbp= 15,
+ },
+
+ .x_res = 1024,
+ .y_res = 768,
+ .bpp= 24,
+#elif defined(CONFIG_PANEL_DVI_VERYHIGHRES)
+ .timings = {
+ /* 1280 x 1024 @ 57 Hz Reduced blanking */
+ .pixel_clock= 86500,
+ .hfp= 48,
+ .hsw= 32,
+ .hbp= 80,
+ .vfp= 3,
+ .vsw= 4,
+ .vbp= 15,
+ },
+
+ .x_res = 1280,
+ .y_res = 1024,
+ .bpp= 16,
+#else
+#error Undefined default mode
[REVIEW PATCH 9/9] DSS: support for OMAP3 SDP board
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-3430sdp.c | 234 +--
drivers/video/omap2/Kconfig |7 +
drivers/video/omap2/Makefile|1
drivers/video/omap2/panel-sdp3430.c | 110
4 files changed, 340 insertions(+), 12 deletions(-)
create mode 100644 drivers/video/omap2/panel-sdp3430.c
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 8773698..b910bc6 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -40,6 +40,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -239,14 +241,224 @@ static struct spi_board_info sdp3430_spi_board_info[]
__initdata = {
},
};
-static struct platform_device sdp3430_lcd_device = {
- .name = "sdp2430_lcd",
- .id = -1,
+static struct omap_fbmem_config sdp3430_fbmem0_config = {
+ .size = 1024*768*4,
+ .start = OMAPFB_MEMTYPE_SDRAM,
+};
+
+static struct omap_fbmem_config sdp3430_fbmem1_config = {
+ .size = 640*480*4,
+ .start = OMAPFB_MEMTYPE_SDRAM,
};
+static struct omap_fbmem_config sdp3430_fbmem2_config = {
+ .size = 640*480*4,
+ .start = OMAPFB_MEMTYPE_SDRAM,
+};
+
+
+#define SDP2430_LCD_PANEL_BACKLIGHT_GPIO 91
+#define SDP2430_LCD_PANEL_ENABLE_GPIO 154
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 24
+#define SDP3430_LCD_PANEL_ENABLE_GPIO 28
+
+#define PM_RECEIVER TWL4030_MODULE_PM_RECEIVER
+#define ENABLE_VAUX2_DEDICATED 0x09
+#define ENABLE_VAUX2_DEV_GRP0x20
+#define ENABLE_VAUX3_DEDICATED 0x03
+#define ENABLE_VAUX3_DEV_GRP 0x20
+
+#define ENABLE_VPLL2_DEDICATED 0x05
+#define ENABLE_VPLL2_DEV_GRP 0xE0
+#define TWL4030_VPLL2_DEV_GRP 0x33
+#define TWL4030_VPLL2_DEDICATED0x36
+
+#define t2_out(c, r, v) twl4030_i2c_write_u8(c, r, v)
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+static int lcd_enabled;
+static int dvi_enabled;
+
+static void __init display_init(void)
+{
+ int r;
+
+ enable_gpio= SDP3430_LCD_PANEL_ENABLE_GPIO;
+ backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
+
+ r = gpio_request(enable_gpio, "OMAP SDP LCD Reset GPIO");
+ if (r) {
+ printk(KERN_ERR "failed to get LCD reset GPIO\n");
+ goto err0;
+ }
+
+ r = gpio_request(backlight_gpio, "OMAP SDP LCD Backlight GPIO");
+ if (r) {
+ printk(KERN_ERR "failed to get LCD backlight GPIO\n");
+ goto err1;
+ }
+
+ gpio_direction_output(enable_gpio, 0);
+ gpio_direction_output(backlight_gpio, 0);
+
+ return;
+err1:
+ gpio_free(enable_gpio);
+err0:
+ return;
+}
+
+
+static int panel_enable_lcd(struct omap_display *display)
+{
+ u8 ded_val, ded_reg;
+ u8 grp_val, grp_reg;
+
+ if (dvi_enabled) {
+ printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
+ return -EINVAL;
+ }
+
+ if (system_rev > OMAP3430_REV_ES1_0) {
+ t2_out(PM_RECEIVER, ENABLE_VPLL2_DEDICATED,
+ TWL4030_VPLL2_DEDICATED);
+ t2_out(PM_RECEIVER, ENABLE_VPLL2_DEV_GRP,
+ TWL4030_VPLL2_DEV_GRP);
+ }
+
+ ded_reg = TWL4030_VAUX3_DEDICATED;
+ ded_val = ENABLE_VAUX3_DEDICATED;
+ grp_reg = TWL4030_VAUX3_DEV_GRP;
+ grp_val = ENABLE_VAUX3_DEV_GRP;
+
+ gpio_direction_output(enable_gpio, 1);
+ gpio_direction_output(backlight_gpio, 1);
+
+ if (0 != t2_out(PM_RECEIVER, ded_val, ded_reg))
+ return -EIO;
+ if (0 != t2_out(PM_RECEIVER, grp_val, grp_reg))
+ return -EIO;
+
+ lcd_enabled = 1;
+
+ return 0;
+}
+
+static void panel_disable_lcd(struct omap_display *display)
+{
+ lcd_enabled = 0;
+
+ gpio_direction_output(enable_gpio, 0);
+ gpio_direction_output(backlight_gpio, 0);
+
+ if (system_rev > OMAP3430_REV_ES1_0) {
+ t2_out(PM_RECEIVER, 0x0, TWL4030_VPLL2_DEDICATED);
+ t2_out(PM_RECEIVER, 0x0, TWL4030_VPLL2_DEV_GRP);
+ mdelay(4);
+ }
+}
+
+static struct omap_display_data sdp_display_data = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "lcd",
+ .panel_name = "panel-sdp3430",
+ .u.dpi.data_lines = 16,
+ .panel_enable = panel_enable_lcd,
+ .panel_disable = panel_disable_lcd,
+};
+
+static int panel_enable_dvi(struct omap_display *display)
+{
+ if (lcd_enabled) {
+ printk(KERN_ERR "cannot enable DVI, LCD is enabled\n");
+ return -EINVAL;
+ }
+
+ if (system_rev > OMAP3430_REV_ES1_0) {
+ t2_out(PM_RECEIVER, ENABLE_VPLL2_DEDICATED,
+
[REVIEW PATCH 8/9] DSS: support for Beagle Board
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-omap3beagle.c | 121 ---
1 files changed, 108 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index ce6c7b4..a6fe63d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -42,6 +42,8 @@
#include
#include
#include
+#include
+#include
#include "twl4030-generic-scripts.h"
@@ -186,15 +188,6 @@ static void __init omap3_beagle_init_irq(void)
omap_gpio_init();
}
-static struct platform_device omap3_beagle_lcd_device = {
- .name = "omap3beagle_lcd",
- .id = -1,
-};
-
-static struct omap_lcd_config omap3_beagle_lcd_config __initdata = {
- .ctrl_name = "internal",
-};
-
static struct gpio_led gpio_leds[] = {
{
.name = "beagleboard::usr0",
@@ -248,13 +241,114 @@ static struct platform_device keys_gpio = {
},
};
+/* DSS */
+
+static int beagle_enable_dvi(struct omap_display *display)
+{
+ if (display->hw_config.panel_reset_gpio != -1)
+ gpio_direction_output(display->hw_config.panel_reset_gpio, 1);
+
+ return 0;
+}
+
+static void beagle_disable_dvi(struct omap_display *display)
+{
+ if (display->hw_config.panel_reset_gpio != -1)
+ gpio_direction_output(display->hw_config.panel_reset_gpio, 0);
+}
+
+static struct omap_display_data beagle_display_data_dvi = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "dvi",
+ .panel_name = "panel-dvi",
+ .u.dpi.data_lines = 24,
+ .panel_reset_gpio = 170,
+ .panel_enable = beagle_enable_dvi,
+ .panel_disable = beagle_disable_dvi,
+};
+
+
+static int panel_enable_tv(struct omap_display *display)
+{
+#define ENABLE_VDAC_DEDICATED 0x03
+#define ENABLE_VDAC_DEV_GRP 0x20
+
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ ENABLE_VDAC_DEDICATED,
+ TWL4030_VDAC_DEDICATED);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ ENABLE_VDAC_DEV_GRP, TWL4030_VDAC_DEV_GRP);
+
+ return 0;
+}
+
+static void panel_disable_tv(struct omap_display *display)
+{
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x00,
+ TWL4030_VDAC_DEDICATED);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x00,
+ TWL4030_VDAC_DEV_GRP);
+}
+
+static struct omap_display_data beagle_display_data_tv = {
+ .type = OMAP_DISPLAY_TYPE_VENC,
+ .name = "tv",
+ .u.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
+ .panel_enable = panel_enable_tv,
+ .panel_disable = panel_disable_tv,
+};
+
+static struct omap_dss_platform_data beagle_dss_data = {
+ .num_displays = 2,
+ .displays = {
+ &beagle_display_data_dvi,
+ &beagle_display_data_tv,
+ }
+};
+
+static struct platform_device beagle_dss_device = {
+ .name = "omap-dss",
+ .id= -1,
+ .dev= {
+ .platform_data = &beagle_dss_data,
+ },
+};
+
+static void __init beagle_display_init(void)
+{
+ int r;
+
+ r = gpio_request(beagle_display_data_dvi.panel_reset_gpio, "DVI reset
GPIO");
+ if(r < 0) {
+ printk(KERN_ERR "Unable to get DVI reset GPIO\n");
+ }
+}
+
+static struct omap_fbmem_config beagle_fbmem0_config = {
+ .size = 1024*768*4,
+ .start = OMAPFB_MEMTYPE_SDRAM,
+};
+
+static struct omap_fbmem_config beagle_fbmem1_config = {
+ .size = 1024*768*4,
+ .start = OMAPFB_MEMTYPE_SDRAM,
+};
+
+static struct omap_fbmem_config beagle_fbmem2_config = {
+ .size = 1024*768*4,
+ .start = OMAPFB_MEMTYPE_SDRAM,
+};
+
+
static struct omap_board_config_kernel omap3_beagle_config[] __initdata = {
{ OMAP_TAG_UART,&omap3_beagle_uart_config },
- { OMAP_TAG_LCD, &omap3_beagle_lcd_config },
+ { OMAP_TAG_FBMEM, &beagle_fbmem0_config },
+ { OMAP_TAG_FBMEM, &beagle_fbmem1_config },
+ { OMAP_TAG_FBMEM, &beagle_fbmem2_config },
};
static struct platform_device *omap3_beagle_devices[] __initdata = {
- &omap3_beagle_lcd_device,
+ &beagle_dss_device,
&leds_gpio,
&keys_gpio,
};
@@ -302,8 +396,6 @@ static void __init omap3_beagle_init(void)
omap3_beagle_i2c_init();
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
- omap_board_config = omap3_beagle_config;
- omap_board_config_size = ARRAY_SIZE(omap3_beagle_config);
omap_serial_init();
omap_cf
Re: [REVIEW PATCH 8/9] DSS: support for Beagle Board
On Tue, 2008-11-04 at 18:28 +0100, ext Koen Kooi wrote:
> Op 4 nov 2008, om 17:10 heeft Tomi Valkeinen het volgende geschreven:
>
> > Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
> > ---
> >
> > arch/arm/mach-omap2/board-omap3beagle.c | 121 ++
> > ++---
> > 1 files changed, 108 insertions(+), 13 deletions(-)
> >
> > +static struct omap_display_data beagle_display_data_dvi = {
> > + .type = OMAP_DISPLAY_TYPE_DPI,
> > + .name = "dvi",
> > + .panel_name = "panel-dvi",
> > + .u.dpi.data_lines = 24,
> > + .panel_reset_gpio = 170,
> > + .panel_enable = beagle_enable_dvi,
> > + .panel_disable = beagle_disable_dvi,
>
> gpio 170 is the enable (or disable, I forget which) for the DVI framer
> (TFP410), not a reset gpio. It would be nice to have a way to enable/
> disable the framer from userspace since it burns 60-100mA.
Well, is there a big difference between reset and enable? Anyway, you
can do
echo "dvi e:0" > /sys/devices/platform/omapfb/displays
and it will turn off the power.
Or, alternatively, use the framebuffer blanking, although that has not
been implemented to the panel-dvi.c (it's in panel-sdp3430.c).
> regards,
>
> Koen
Tom
--
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
Re: [Linux-fbdev-devel] [REVIEW PATCH 1/9] DSS: Documentation for OMAP2/3 display subsystem
On Wed, 2008-11-05 at 08:56 +0100, ext Geert Uytterhoeven wrote:
> On Tue, 4 Nov 2008, Tomi Valkeinen wrote:
> > +Sysfs
> > +-
> > +The sysfs interface is a hack, but works for testing. I don't think sysfs
> > +interface is the best for this in the final version, but I don't quite know
> > +what would be the best interfaces for these things.
> > +
> > +In /sys/devices/platform/omapfb we have four files: framebuffers,
> > +overlays, managers and displays. You can read them so see the current
> > +setup, and change them by writing to it in the form of
> > +" : :..."
> > +
> > +"framebuffers" lists all framebuffers. Its format is:
> > +
> > + t:
> > +
> > +"overlays" lists all overlays. Its format is:
> > +
> > + t:
> > + x:
> > + y:
> > + iw:
> > + ih:
> > + w:
> > + h:
> > + e:
> > +
> > +"managers" lists all overlay managers. Its format is:
> > +
> > + t:
> > +
> > +"displays" lists all displays. Its format is:
> > +
> > + w:
> > + h:
> > + e:
> > + u:
> > + t:
>
> As all of these contain lists of sections (one for each
> fb/overlay/manager/display), what about making them directories, with each
> section an individual file?
I've thought that also. The reason for the current form is that it was
simpler to implement, and is not meant to be in the final version. If
the sysfs interface stays there, then I agree that they files have to be
divided.
>
> Gr{oetje,eeting}s,
>
> Geert
Tomi
--
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
Re: [Linux-fbdev-devel] [REVIEW PATCH 8/9] DSS: support for Beagle Board
On Tue, 2008-11-04 at 10:24 -0800, ext Tony Lindgren wrote:
> Hi,
>
> One comment below.
>
> * Tomi Valkeinen <[EMAIL PROTECTED]> [081104 08:32]:
> > Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
> > ---
> >
> > arch/arm/mach-omap2/board-omap3beagle.c | 121
> > ---
> > 1 files changed, 108 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
> > b/arch/arm/mach-omap2/board-omap3beagle.c
> > index ce6c7b4..a6fe63d 100644
> > --- a/arch/arm/mach-omap2/board-omap3beagle.c
> > +++ b/arch/arm/mach-omap2/board-omap3beagle.c
>
>
>
> > +static struct omap_fbmem_config beagle_fbmem0_config = {
> > + .size = 1024*768*4,
> > + .start = OMAPFB_MEMTYPE_SDRAM,
> > +};
> > +
> > +static struct omap_fbmem_config beagle_fbmem1_config = {
> > + .size = 1024*768*4,
> > + .start = OMAPFB_MEMTYPE_SDRAM,
> > +};
> > +
> > +static struct omap_fbmem_config beagle_fbmem2_config = {
> > + .size = 1024*768*4,
> > + .start = OMAPFB_MEMTYPE_SDRAM,
> > +};
> > +
> > +
> > static struct omap_board_config_kernel omap3_beagle_config[] __initdata = {
> > { OMAP_TAG_UART,&omap3_beagle_uart_config },
> > - { OMAP_TAG_LCD, &omap3_beagle_lcd_config },
> > + { OMAP_TAG_FBMEM, &beagle_fbmem0_config },
> > + { OMAP_TAG_FBMEM, &beagle_fbmem1_config },
> > + { OMAP_TAG_FBMEM, &beagle_fbmem2_config },
> > };
> >
>
> NAK for adding new OMAP_TAGs. We are in process of removing those.
> You should be able to use just board specific platform_data.
>
> If there are ATAGs that are needed, they must be ARM generic. They
> also need to be acked by Russell King on the linux-arm-kernel mailing
> list. I doubt that you'll need those though.
Okay. But in this case, I think, it's not enough to have the board
specific data in board.c's platform_data. It would be good that the
bootloader can setup the display, and tell the relevant information to
the kernel, so that there are no glitches on the display (although not
currently implemented in my driver).
But there may be an ATAG that can be used for that, I'll have to check.
> Regards,
>
> Tony
Tomi
--
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
Re: [REVIEW PATCH 8/9] DSS: support for Beagle Board
On Thu, 2008-11-06 at 01:21 +0200, ext David Brownell wrote:
> On Wednesday 05 November 2008, Jarkko Nikula wrote:
> > > + r = gpio_request(beagle_display_data_dvi.panel_reset_gpio,
> "DVI reset GPIO");
> > > + if(r < 0) {
> >
> > GPIO label "DVI reset" is enough.
>
> Surely this ** doesn't work ** at least against the OMAP git tree
> which already has:
Well, it surely does! =)
But good catch, I'll fix it. There's probably a warning on kernel log
about "can't get a gpio".
>
> omap_cfg_reg(J25_34XX_GPIO170);
> gpio_request(170, "DVI_nPD");
> /* REVISIT leave DVI powered down until it's needed ... */
> gpio_direction_output(170, true);
>
> Label matches the DVI chip, not board schematics. Agreed,
> it's not a reset.
>
> I'd like to see any FB/DSS/... updates have the property that
> the TFP410 chip is powered down *unless* both (a) the frame
> buffer/DSS/... driver is active, and (b) the DVI channel is
> in use.
>
> So for example a kernel without FB/DSS/... configured, that
> DVI chip is never powered up. And when only the S-Video channel
> is used, DVI isn't powered up either.
>
Well, my drivers do not enable the DVI chip unless DVI is in use. It is
in use by default, but you can turn it off. And if the whole DSS is not
compiled in, then no body will turn the DVI chip on.
However, the bootloader turns the DVI chip on (at least the default
beagle board u-boot). If the kernel by default turns the DVI chip off,
and then later on when the DSS starts, we'll have a glitch on the
display. Not that there currently is support for glitchless transition
from bootloader display to kernel display, but still...
> - Dave
>
Tomi
--
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
Re: Fix for dispc's error "omapfb omapfb: irq error status 4020"
Hi,
On Fri, 2008-11-07 at 12:55 -0800, ext Rick Bronson wrote:
> Folks,
>
> Please take a look at this change to drivers/video/omap/dispc.c. It
> addresses a problem seen on some boots of OMAP's. On about 1 in 30
> boots one gets an endless stream of interrupts from the
> DISPC_IRQ_SYNC_LOST bit in the DISPC_IRQSTATUS register. The
> following messages are printed.
>
> omapfb omapfb: irq error status 4020
>
> The correct solution to this problem is to perform a "soft reset"
> but that requires a bit of re-architecturing of the code as the init
> routine would have to be split up, etc. See the OMAP pdf, search for
> "To clear a synchronization lost interrupt".
>
> This patch allows the above error message to get printed once and
> then disables further DISPC_IRQ_SYNC_LOST interrups.
>
> Comments?
I think the correct solution would be to find out why we get sync lost
errors and fix that. Your patch just hides the problem.
However, I agree that it's not good to just keep spamming the error,
possibly making the board freeze. The new DSS turns the display off
after 100 error messages. But I don't think just hiding the interrupt is
a good change.
>
> Thanks,
>
> Rick
Tomi
>
> --- linux-omap-2.6/drivers/video/omap/dispc.c.~1~ 2008-11-04
> 14:23:38.0 -0800
> +++ linux-omap-2.6/drivers/video/omap/dispc.c 2008-11-07 12:34:54.0
> -0800
> @@ -157,7 +157,7 @@ struct resmap {
>
> #define MAX_IRQ_HANDLERS4
>
> -static struct {
> +static struct omapfb_dispc {
> void __iomem*base;
>
> struct omapfb_mem_desc mem_desc;
> @@ -169,6 +169,7 @@ static struct {
>
> int ext_mode;
>
> + u32 irq_error_mask; /* mask used for errors */
> struct {
> u32 irq_mask;
> void(*callback)(void *);
> @@ -812,16 +813,16 @@ static void set_lcd_timings(void)
> panel->pixel_clock = fck / lck_div / pck_div / 1000;
> }
>
> -static void recalc_irq_mask(void)
> +static void recalc_irq_mask(struct omapfb_dispc *p_dispc)
> {
> int i;
> - unsigned long irq_mask = DISPC_IRQ_MASK_ERROR;
> + unsigned long irq_mask = p_dispc->irq_error_mask;
>
> for (i = 0; i < MAX_IRQ_HANDLERS; i++) {
> - if (!dispc.irq_handlers[i].callback)
> + if (!p_dispc->irq_handlers[i].callback)
> continue;
>
> - irq_mask |= dispc.irq_handlers[i].irq_mask;
> + irq_mask |= p_dispc->irq_handlers[i].irq_mask;
> }
>
> enable_lcd_clocks(1);
> @@ -843,7 +844,7 @@ int omap_dispc_request_irq(unsigned long
> dispc.irq_handlers[i].irq_mask = irq_mask;
> dispc.irq_handlers[i].callback = callback;
> dispc.irq_handlers[i].data = data;
> - recalc_irq_mask();
> + recalc_irq_mask(&dispc);
>
> return 0;
> }
> @@ -863,7 +864,7 @@ void omap_dispc_free_irq(unsigned long i
> dispc.irq_handlers[i].irq_mask = 0;
> dispc.irq_handlers[i].callback = NULL;
> dispc.irq_handlers[i].data = NULL;
> - recalc_irq_mask();
> + recalc_irq_mask(&dispc);
> return;
> }
> }
> @@ -884,6 +885,10 @@ static irqreturn_t omap_dispc_irq_handle
> complete(&dispc.frame_done);
>
> if (stat & DISPC_IRQ_MASK_ERROR) {
> + if (stat & DISPC_IRQ_SYNC_LOST) { /* only allow sync lost once
> or we end up... */
> + dispc.irq_error_mask &= ~DISPC_IRQ_SYNC_LOST; /* with
> a barrage of interrupts */
> + recalc_irq_mask(&dispc);
> + }
> if (printk_ratelimit()) {
> dev_err(dispc.fbdev->dev, "irq error status %04x\n",
> stat & 0x7fff);
> @@ -897,6 +902,7 @@ static irqreturn_t omap_dispc_irq_handle
> }
>
> dispc_write_reg(DISPC_IRQSTATUS, stat);
> + stat = dispc_read_reg(DISPC_IRQSTATUS);
>
> enable_lcd_clocks(0);
>
> @@ -1432,7 +1438,8 @@ static int omap_dispc_init(struct omapfb
> l = dispc_read_reg(DISPC_IRQSTATUS);
> dispc_write_reg(DISPC_IRQSTATUS, l);
>
> - recalc_irq_mask();
> + dispc.irq_error_mask = DISPC_IRQ_MASK_ERROR; /* init error mask */
> + recalc_irq_mask(&dispc);
>
> if ((r = request_irq(INT_24XX_DSS_IRQ, omap_dispc_irq_handler,
> 0, MODULE_NAME, fbdev)) < 0) {
>
> --
> 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
--
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
RE: [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description
Hi, On Mon, 10 Nov 2008, ext Shah, Hardik wrote: [Shah, Hardik] We have reviewed the patches in detail and even made modifications to make it work on the OMAP3EVM. Here are our observations: 1) The overall implementation is very much in line with our earlier proposal to provide generic API that supports both V4L2 and FBDEV. 2) The implementation supports multiple output interfaces e.g. RFBI, SDI, DSI, ... that we did not have in our plans 3) You have also validated it on lot many platforms that we do not have access. We believe patches are a good step in right direction. We plan to use this patchset as base for supporting these additional use cases: a) Adding the V4L2 user interface to the video pipelines (I believe video pipelines are natural fit for the V4L2 frame work. If use case is there for FBDEV interface we can have compile time option to expose the video pipelines as the either FBDEV or v4L2 interface). b) Modification of the DSS/DISPC library for supporting V4L2 user interface. c) Supporting the functionality like alpha blending, global alpha blending, setting of various TV standards etc. d) Supporting the mirroring and rotation in both FBDEV and V4L2 driver. Do let us know if you aren't already working on any of these. This sounds very good. I am not currently working on any of those items you mentioned. A couple of comments/thoughts about them: a) Yes, V4L2 interface would be nice. But there are use cases for FB devices also, and sometimes you don't want V4L2 devices at all. So as you suggested, a compile time option to select this is necessary. Or, better yet, a runtime option. One way to implement simultaneous FB and V4L2 devices is to have to separate drivers. But then this needs more locking support to DSS, and pobably some kind of event mechanism. For example, if both FB and V4L2 have overlays on the same display, and one of them changes the screen resolution, the other one needs to know about this also. So what I have been thinking is to have both FB and V4L2 in the same driver. This would make things easier. But then again, I don't know how much code V4L2 needs, and if the combined driver would get too complex. b) Do you already have ideas what features V4L2 needs that are not present in DSS currently? c) Yes, these would be nice. d) These would be nice also. About rotation, I think there are three kinds of rotation that are handled by different entities: - DMA rotation, for framebuffers in SRAM. Handled by DSS. - External framebuffer rotation, handled by the external framebuffer controller. - VRFB rotation. This is basically a memory handling configuration, and is transparent to the end user (in this case, DSS) of the memory. Should be handled by the entity that allocates the memory, ie. omapfb. Tomi -- 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
Re: Fix for dispc's error "omapfb omapfb: irq error status 4020"
Hi, On Fri, 2008-11-07 at 12:55 -0800, ext Rick Bronson wrote: > Folks, > > Please take a look at this change to drivers/video/omap/dispc.c. It > addresses a problem seen on some boots of OMAP's. On about 1 in 30 > boots one gets an endless stream of interrupts from the > DISPC_IRQ_SYNC_LOST bit in the DISPC_IRQSTATUS register. The > following messages are printed. > > omapfb omapfb: irq error status 4020 Can you try the patch below if it fixes this problem for you? On my new display subsystem adding a sleep between enabling clocks and doing the soft reset removed the problem. I tried a bit with different sleep times. With 1ms sleep I still got sync losts. With 10ms I didn't, but I went safe and put 40ms. Tomi diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c index c140c21..bdfda0c 100644 --- a/drivers/video/omap/dispc.c +++ b/drivers/video/omap/dispc.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include @@ -1402,6 +1403,10 @@ static int omap_dispc_init(struct omapfb_device *fbdev, int ext_mode, /* Reset monitoring works only w/ the 54M clk */ enable_digit_clocks(1); + /* We need to wait here a bit, otherwise we sometimes start to get +* synclost errors. */ + msleep(40); + /* Soft reset */ MOD_REG_FLD(DISPC_SYSCONFIG, 1 << 1, 1 << 1); -- 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
Re: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches
Hi,
On Fri, 2008-11-14 at 12:02 +0530, ext [EMAIL PROTECTED] wrote:
> From: Vaibhav Hiremath <[EMAIL PROTECTED]>
>
> Tested LCD, TV, DVI (480P) out on OMAP3EVM board.
>
> Please make sure that you change the option
> CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=7 and apply the
> Mans Rullgard clock patches to support set_rate and round_rate API.
>
> Signed-off-by: Vaibhav Hiremath <[EMAIL PROTECTED]>
I think the LCD panel on SDP and EVM boards are the same, so we should
only have one driver. Do you have specifications about the LCD? The
manufacturer, model etc?. I didn't find any proper information about the
LCD.
The #ifdef mode selection in DVI panel is quit hack, I agree. The mode
selection should be possible to be done runtime (or with kernel boot
option at minimum), but I'm not yet sure how to implement it. But I
guess I could at least name the mode config options a bit better.
You also set the LCD's bpp to 18, why is that? The bpp in panel driver
is currently only used as a default bpp for omapfb, but there's no 18bpp
mode in OMAP. For some reason omapfb let's the 18bpp through, but it
acts like it is 16bpp. I can't remember why it does that, I think I'll
remove it from omapfb.
Tomi
> ---
> arch/arm/mach-omap2/board-omap3evm.c | 224
> --
> drivers/video/omap2/Kconfig |5 +
> drivers/video/omap2/Makefile |1 +
> drivers/video/omap2/panel-dvi.c | 54 ++---
> drivers/video/omap2/panel-omap3evm.c | 110 +
> 5 files changed, 341 insertions(+), 53 deletions(-)
> create mode 100644 drivers/video/omap2/panel-omap3evm.c
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index 42ab826..e244fa7 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -37,6 +37,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "sdram-micron-mt46h32m32lf-6.h"
> #include "twl4030-generic-scripts.h"
> @@ -161,14 +163,215 @@ static int __init omap3_evm_i2c_init(void)
> omap_register_i2c_bus(3, 400, NULL, 0);
> return 0;
> }
> +static struct omap_fbmem_config evm_fbmem0_config = {
> + .size = 480*720*4,
> + .start = OMAPFB_MEMTYPE_SDRAM,
> +};
>
> -static struct platform_device omap3_evm_lcd_device = {
> - .name = "omap3evm_lcd",
> - .id = -1,
> +static struct omap_fbmem_config evm_fbmem1_config = {
> + .size = 480*720*4,
> + .start = OMAPFB_MEMTYPE_SDRAM,
> };
>
> -static struct omap_lcd_config omap3_evm_lcd_config __initdata = {
> - .ctrl_name = "internal",
> +static struct omap_fbmem_config evm_fbmem2_config = {
> + .size = 480*720*4,
> + .start = OMAPFB_MEMTYPE_SDRAM,
> +};
> +#define LCD_PANEL_LR 2
> +#define LCD_PANEL_UD 3
> +#define LCD_PANEL_INI152
> +#define LCD_PANEL_ENABLE_GPIO153
> +#define LCD_PANEL_QVGA 154
> +#define LCD_PANEL_RESB 155
> +
> +#define ENABLE_VDAC_DEDICATED0x03
> +#define ENABLE_VDAC_DEV_GRP 0x20
> +#define ENABLE_VPLL2_DEDICATED 0x05
> +#define ENABLE_VPLL2_DEV_GRP 0xE0
> +
> +#define TWL4030_GPIODATA_IN3 0x03
> +#define TWL4030_GPIODATA_DIR30x06
> +#define TWL4030_VPLL2_DEV_GRP0x33
> +#define TWL4030_VPLL2_DEDICATED 0x36
> +
> +static int lcd_enabled;
> +static int dvi_enabled;
> +
> +static void __init evm_display_init(void)
> +{
> + int r;
> + r = gpio_request(LCD_PANEL_LR, "lcd_panel_lr");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_PANEL_LR\n");
> + return;
> + }
> + r = gpio_request(LCD_PANEL_UD, "lcd_panel_ud");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_PANEL_UD\n");
> + goto err_1;
> + }
> +
> + r = gpio_request(LCD_PANEL_INI, "lcd_panel_ini");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_PANEL_INI\n");
> + goto err_2;
> + }
> + r = gpio_request(LCD_PANEL_RESB, "lcd_panel_resb");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_PANEL_RESB\n");
> + goto err_3;
> + }
> + r = gpio_request(LCD_PANEL_QVGA, "lcd_panel_qvga");
> + if (r) {
> + printk(KERN_ERR "failed to get LCD_PANEL_QVGA\n");
> + goto err_4;
> + }
> +
> + gpio_direction_output(LCD_PANEL_LR, 0);
> + gpio_direction_output(LCD_PANEL_UD, 0);
> + gpio_direction_output(LCD_PANEL_INI, 0);
> + gpio_direction_output(LCD_PANEL_RESB, 0);
> + gpio_direction_output(LCD_PANEL_QVGA, 0);
> +
> +#define TWL_LED_LEDEN 0x00
> +#define TWL_PWMA_PWMAON 0x00
> +#define TWL_PWMA_PWMAOFF0x01
> +
> + twl4030_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_LEDEN);
> + twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, 0x01, TWL_PWMA_PWMAON);
> + twl4030_i2c_write
RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches
Hi,
On Fri, 2008-11-14 at 18:05 +0530, ext Hiremath, Vaibhav wrote:
> >
> > I think the LCD panel on SDP and EVM boards are the same, so we
> > should
> > only have one driver. Do you have specifications about the LCD? The
> > manufacturer, model etc?. I didn't find any proper information about
> > the
> > LCD.
> >
> [Hiremath, Vaibhav] The LCD on OMAP3EVM is Sharp LCD (Model No. -
> LS037V7DW01).
> Koen has already conformed that panel3430sdp.c is working with OMAP3EVM, let
> me try at my end. If it works properly then we can have same file to build
> for both SDP and EVM. But in that case it make sense to rename file to
> panel-lcd.c.
>
I took the liberty to add you EVM changes to my tree, with a comment
about the origin. I also changed the SDP panel name to sharp panel, and
made both EVM and SDP use that. But I can't test the EVM, as I don't
have one.
> > The #ifdef mode selection in DVI panel is quit hack, I agree. The
> > mode
> > selection should be possible to be done runtime (or with kernel boot
> > option at minimum), but I'm not yet sure how to implement it. But I
> > guess I could at least name the mode config options a bit better.
> >
> [Hiremath, Vaibhav] We will also work on this and let you know.
>
> > You also set the LCD's bpp to 18, why is that? The bpp in panel
> > driver
> > is currently only used as a default bpp for omapfb, but there's no
> > 18bpp
> > mode in OMAP. For some reason omapfb let's the 18bpp through, but it
> > acts like it is 16bpp. I can't remember why it does that, I think
> > I'll
> > remove it from omapfb.
> >
> [Hiremath, Vaibhav] LCD panel connected to OMAP3EVM is 18 bit LCD, the
> interface is also 18 bit in schematics. I am not sure about SDP board though.
Then you should change the dpi.data_lines from 16 to 18. On SDP it seems
that a dip-switch controls if there are 16 or 18 lines going to the LCD.
Although I'm not quite sure what 18bit LCD helps. If you use 16 bit
color mode, it doesn't help anything. With 24bit color mode I guess it
helps a bit, but is that enough reason use more memory for the
framebuffer...
Tomi
> > Tomi
> >
> >
> > > ---
> > > arch/arm/mach-omap2/board-omap3evm.c | 224
> > --
> > > drivers/video/omap2/Kconfig |5 +
> > > drivers/video/omap2/Makefile |1 +
> > > drivers/video/omap2/panel-dvi.c | 54 ++---
> > > drivers/video/omap2/panel-omap3evm.c | 110 +
> > > 5 files changed, 341 insertions(+), 53 deletions(-)
> > > create mode 100644 drivers/video/omap2/panel-omap3evm.c
> > >
> > > diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
> > omap2/board-omap3evm.c
> > > index 42ab826..e244fa7 100644
> > > --- a/arch/arm/mach-omap2/board-omap3evm.c
> > > +++ b/arch/arm/mach-omap2/board-omap3evm.c
> > > @@ -37,6 +37,8 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > >
> > > #include "sdram-micron-mt46h32m32lf-6.h"
> > > #include "twl4030-generic-scripts.h"
> > > @@ -161,14 +163,215 @@ static int __init omap3_evm_i2c_init(void)
> > > omap_register_i2c_bus(3, 400, NULL, 0);
> > > return 0;
> > > }
> > > +static struct omap_fbmem_config evm_fbmem0_config = {
> > > + .size = 480*720*4,
> > > + .start = OMAPFB_MEMTYPE_SDRAM,
> > > +};
> > >
> > > -static struct platform_device omap3_evm_lcd_device = {
> > > - .name = "omap3evm_lcd",
> > > - .id = -1,
> > > +static struct omap_fbmem_config evm_fbmem1_config = {
> > > + .size = 480*720*4,
> > > + .start = OMAPFB_MEMTYPE_SDRAM,
> > > };
> > >
> > > -static struct omap_lcd_config omap3_evm_lcd_config __initdata = {
> > > - .ctrl_name = "internal",
> > > +static struct omap_fbmem_config evm_fbmem2_config = {
> > > + .size = 480*720*4,
> > > + .start = OMAPFB_MEMTYPE_SDRAM,
> > > +};
> > > +#define LCD_PANEL_LR 2
> > > +#define LCD_PANEL_UD 3
> > > +#define LCD_PANEL_INI 152
> > > +#define LCD_PANEL_ENABLE_GPIO 153
> > > +#define LCD_PANEL_QVGA 154
> > > +#define LCD_PANEL_RESB 155
> > > +
> > > +#define ENABLE_VDAC_DEDICATED 0x03
> > > +#define ENABLE_VDAC_DEV_GRP0x20
> > > +#define ENABLE_VPLL2_DEDICATED 0x05
> > > +#define ENABLE_VPLL2_DEV_GRP 0xE0
> > > +
> > > +#define TWL4030_GPIODATA_IN3 0x03
> > > +#define TWL4030_GPIODATA_DIR3 0x06
> > > +#define TWL4030_VPLL2_DEV_GRP 0x33
> > > +#define TWL4030_VPLL2_DEDICATED0x36
> > > +
> > > +static int lcd_enabled;
> > > +static int dvi_enabled;
> > > +
> > > +static void __init evm_display_init(void)
> > > +{
> > > + int r;
> > > + r = gpio_request(LCD_PANEL_LR, "lcd_panel_lr");
> > > + if (r) {
> > > + printk(KERN_ERR "failed to get LCD_PANEL_LR\n");
> > > + return;
> > > + }
> > > + r = gpio_request(LCD_PANEL_UD, "lcd_panel_ud");
> > > + if (r) {
>
RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis FBDEV/DSS Patches
On Sat, 2008-11-15 at 14:12 +0530, ext Hiremath, Vaibhav wrote: > > Thanks, > Vaibhav Hiremath > > > -Original Message----- > > From: Tomi Valkeinen [mailto:[EMAIL PROTECTED] > > Sent: Friday, November 14, 2008 9:24 PM > > To: Hiremath, Vaibhav > > Cc: [EMAIL PROTECTED]; linux- > > [EMAIL PROTECTED] > > Subject: RE: [REVIEW PATCH] Added OMAP3EVM support on Tomis > > FBDEV/DSS Patches > > > > Hi, > > On Fri, 2008-11-14 at 18:05 +0530, ext Hiremath, Vaibhav wrote: > > > > > > > > > > I think the LCD panel on SDP and EVM boards are the same, so we > > > > should > > > > only have one driver. Do you have specifications about the LCD? > > The > > > > manufacturer, model etc?. I didn't find any proper information > > about > > > > the > > > > LCD. > > > > > > > [Hiremath, Vaibhav] The LCD on OMAP3EVM is Sharp LCD (Model No. - > > LS037V7DW01). > > > Koen has already conformed that panel3430sdp.c is working with > > OMAP3EVM, let me try at my end. If it works properly then we can > > have same file to build for both SDP and EVM. But in that case it > > make sense to rename file to panel-lcd.c. > > > > > > > I took the liberty to add you EVM changes to my tree, with a comment > > about the origin. I also changed the SDP panel name to sharp panel, > > and > > made both EVM and SDP use that. But I can't test the EVM, as I don't > > have one. > > > [Hiremath, Vaibhav] It's ok; you can incorporate required changes from my > patches, no issues at all. Please share the code base which you merged from > my patch so that I can validate it on EVM, since you don't have EVM to test. > My current version is available in master branch on http://www.bat.org/~tomba/git/linux-omap-dss.git/ I will be keeping the master branch up to date with my changes and linux-omap. And I will be rebasing the branch. pub1 branch has the version that I emailed to mailing lists some time ago. You can diff master and pub1 branches to see what's changed. Tomi -- 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
RE: [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description
Hi, On Tue, 2008-11-18 at 12:10 +0530, ext Shah, Hardik wrote: > > > -Original Message- > > From: Tomi Valkeinen [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 04, 2008 9:40 PM > > To: [EMAIL PROTECTED] > > Cc: linux-omap@vger.kernel.org > > Subject: [Linux-fbdev-devel] [REVIEW PATCH 0/9] DSS: Series description > > > > New Display Subsystem for OMAP2/3 > > - > > [snip] > > > [Shah, Hardik] Hi Tomi, > We are successful to bring up the basic functionality of the V4L2 driver onto > your patches. We will be posting those patches in a day or two. Based on our > V4L2 driver development we have few questions/suggestions on DSS patches you > submitted. > 1.Display enable function is returning false if the display is already > enabled. Instead it should just return without error if display is > already enabled as V4L2 and fbdev both may be enabling it without each > other's knowledge. > > 2.Second display enable/disable should maintain the reference count as > disabling of the display by one driver will leave other driver without > display. > > 3.I think the row increment value should not be calculate inside the > dispc.c file instead high level driver will pass the value it requires > based on his buffer requirement and dispc.c should program it dumbly. > This is mainly due to the odd row_inc_value requirement for the VRFB space. > > 4.There is API in dispc.c file to change pixel increment value. > > 5.We need separate API to enable the plane and enable the clocks. > Oncethe clock is enabled driver can directly go and program registers > through low level dispc APIs instead of dispc APIs enabling the clock for > each register programming and then disabling it. > > This will avoid the enabling and disabling of the clocks for each > frame displayed. As for V4L2 interface driver will enable planes and > clocks during VIDIOC_STREAMON ioctls and during the streaming it will > just change the buffer address for displaying frames. This way delay > between the enabling/disabling of the clocks can also be saved. It would > be driver's responsibility to enable the clocks before programmingany > registers. Same may be true for setting the GO bit of the respective > overlay managers. > > 6.We also need a public API to program the color conversion values. Some > application may need to program it differently than standard values. > These all sound valid changes to me, I will see to them. For the time being, just make whatever hacks you need to get the V4L2 running. And preferably mark these hacks with a comment, so it's easy to find them. As for the 5. issue, I've been thinking the same thing. However, usually the clocks are always on when the LCD is on. So even if there are clk_enable() calls, all they do is increment the ref count. > > > Thanks and Regards, > Hardik Shah > Vaibhav Hiremath Tomi -- 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
OMAP Framebuffer memory allocation and mapping
Hi, I have a couple of questions regarding the memory management for the new display subsystem. The new DSS allocates memory with dma_alloc_writecombine() and mmaps it to user space with dma_mmap_writecombine(). Allocation is done when omapfb starts up. Normally memory gets very quickly too fragmented for dma_alloc_writecombine() to work, but setting CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE helps this. However, even when CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE is set to 14, I am, for some reason, not able to allocate 1280x1024x4 (~5.2M) framebuffer. Could the consistent DMA area be already too fragmented, or is there some size limit there? There's also support to allocate fb memory in very early phase with reserve_bootmem(), which needs a predefined physical address and size that can come from the bootloader. I've been looking at the old DSS to see how this memory should be mapped, but I haven't been able to get it to work. It looks like the DSS DMA and the user space have a bit different view of the memory, so my assumption is that there's some caching or similar being done. So how to setup the memory gotten from reserve_bootmem() (or alloc_bootmem()) so that it would work the same way as dma_alloc_writecombine()'s memory? And generally: any other ideas how to improve the memory management of the DSS? Tomi -- 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
[PATCH] ARM: Parse ATAG_VIDEOLFB to screen_info
Parse ATAG_VIDEOLFB received from bootloader to screen_info struct, so that
video
drivers can use the information.
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
arch/arm/kernel/setup.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 1f1eecc..11dafe5 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -576,6 +576,31 @@ static int __init parse_tag_videotext(const struct tag
*tag)
}
__tagtable(ATAG_VIDEOTEXT, parse_tag_videotext);
+
+static int __init parse_tag_videolfb(const struct tag *tag)
+{
+ screen_info.lfb_width = tag->u.videolfb.lfb_width;
+ screen_info.lfb_height = tag->u.videolfb.lfb_height;
+ screen_info.lfb_depth = tag->u.videolfb.lfb_depth;
+ screen_info.lfb_linelength = tag->u.videolfb.lfb_linelength;
+ screen_info.lfb_base = tag->u.videolfb.lfb_base;
+ screen_info.lfb_size = tag->u.videolfb.lfb_size;
+
+ screen_info.red_size = tag->u.videolfb.red_size;
+ screen_info.red_pos = tag->u.videolfb.red_pos;
+ screen_info.green_size = tag->u.videolfb.green_size;
+ screen_info.green_pos = tag->u.videolfb.green_pos;
+ screen_info.blue_size = tag->u.videolfb.blue_size;
+ screen_info.blue_pos = tag->u.videolfb.blue_pos;
+ screen_info.rsvd_size = tag->u.videolfb.rsvd_size;
+ screen_info.rsvd_pos = tag->u.videolfb.rsvd_pos;
+
+ screen_info.orig_video_isVGA = VIDEO_TYPE_VLFB;
+
+ return 0;
+}
+
+__tagtable(ATAG_VIDEOLFB, parse_tag_videolfb);
#endif
static int __init parse_tag_ramdisk(const struct tag *tag)
--
1.6.0.3
--
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
Re: [PATCH] ARM: Parse ATAG_VIDEOLFB to screen_info
Hi, On Mon, 2008-11-24 at 12:12 +, ext Russell King - ARM Linux wrote: > On Fri, Nov 21, 2008 at 12:25:36PM +0200, Tomi Valkeinen wrote: > > Parse ATAG_VIDEOLFB received from bootloader to screen_info struct, > > so that video drivers can use the information. > > Boot loaders tend to be absolutely diabolical about passing correct > information to the kernel, so I really don't want to see such platform > specific stuff being passed. Please put it in the board specific file > instead, just like everyone else does. I though a general file would be better, because: a) the tag contains only generic stuff and it is parsed directly to screen_info, which is also generic b) ATAG_VIDEOTEXT, which is very similar to ATAG_VIDEOLFB, is parsed in setup.c also. c) it is not used anywhere currently So I don't see anything platform or board specific there. Or do you mean that there are broken bootloaders out there and this would mess up screen_info? Tomi -- 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
OMAP VRAM patch set intro
Hi, This patch set is a prototype video ram allocator for OMAP for review. The reasons I made this are: - The DMA_CONSISTENT memory area is only 14M, and that may not be enough. 1280*1024*4 framebuffer takes more than 5M. Three of those, and perhaps double buffering, and we are easily over the 14M limit. - dma_alloc doesn't let you allocate big areas (I think the limit is ~4M). - You can't specify the physical memory address where you want to alloc the memory. This is needed if the bootloader sets up the display and the kernel continues using that same memory area. - dma_alloc doesn't support SRAM At boot time memory areas (SDRAM or SRAM) defined in board file are reserved with reserve_bootmem() or alloc_bootmem(). These areas are added to the VRAM memory pool. Later on the OMAPFB or V4L2 devices can allocate needed memory from the VRAM manager. If there's no VRAM left, the VRAM manager will fall back to dma_alloc. The VRAM manager automatically mmaps the memory areas with ioremap_wc() when the driver allocates VRAM. The OMAPFB patch removes the old memory manager from dispc.c, which did mostly the same thing as this one, and replaces it with this one. Now some questions as I'm not too familiar with memory management: Is it ok to use ioremap() to map SRAM/SDRAM? If not, how should the mapping be done? What actually are the types that should be used with physical and virtual addresses here? dma_alloc() returns dma_addr_t and void * for physical and virtual addresses. ioremap() takes unsigned long as physical address and returns void __iomem *. What does __iomem mean? "This is pointer to memory that is not RAM"? How do other platforms implement video ram that is in the main memory? Is it better to ioremap the whole VRAM area at boot time, or is it better to ioremap the smaller pieces when the driver allocates memory? Is it possible to not ioremap at all (in SDRAM case), but use the direct SDRAM mapping that already exists? This would need modification of that mapping so that the memory is not cached. Tomi Valkeinen -- arch/arm/mach-omap2/board-3430sdp.c | 10 + arch/arm/plat-omap/Makefile |2 +- arch/arm/plat-omap/fb-vram.c | 439 ++ arch/arm/plat-omap/fb.c | 22 ++- arch/arm/plat-omap/include/mach/omapfb.h |8 + drivers/video/omap/dispc.c | 281 ++- drivers/video/omap/omapfb_main.c | 11 +- 7 files changed, 504 insertions(+), 269 deletions(-) -- 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
[PATCH] OMAP3 SDP: example use of OMAP VRAM
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/board-3430sdp.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index e2eed49..f3bb647 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include "sdram-qimonda-hyb18m512160af-6.h"
#include "mmc-twl4030.h"
@@ -484,9 +485,18 @@ static void __init omap_3430sdp_init(void)
hsmmc_init(mmc);
}
+static struct omap_fbmem_config omap_3430sdp_fbmem_config[] = {
+ {
+ .size = 640 * 480 * 2 * 3,
+ .start = OMAPFB_MEMTYPE_SDRAM,
+ },
+};
+
static void __init omap_3430sdp_map_io(void)
{
omap2_set_globals_343x();
+ omapfb_set_vram_config(omap_3430sdp_fbmem_config,
+ ARRAY_SIZE(omap_3430sdp_fbmem_config));
omap2_map_common_io();
}
--
1.6.0.3
--
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
[PATCH] OMAP: Add a Video RAM manager
The manager can be used to allocate large chucks of memory at boot time
for VRAM use. Drivers can then later allocate pieces of memory from the
manager.
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/fb-vram.c | 439 ++
arch/arm/plat-omap/include/mach/omapfb.h |6 +
3 files changed, 446 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/plat-omap/fb-vram.c
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 1259846..4ff192b 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := common.o sram.o clock.o devices.o dma.o mux.o gpio.o \
-usb.o fb.o io.o
+usb.o fb.o fb-vram.o io.o
obj-m :=
obj-n :=
obj- :=
diff --git a/arch/arm/plat-omap/fb-vram.c b/arch/arm/plat-omap/fb-vram.c
new file mode 100644
index 000..8ae39df
--- /dev/null
+++ b/arch/arm/plat-omap/fb-vram.c
@@ -0,0 +1,439 @@
+/*
+ * linux/arch/arm/plat-omap/fb-vram.c
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen <[EMAIL PROTECTED]>
+ *
+ * Some code and ideas taken from drivers/video/omap/ driver
+ * by Imre Deak.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#ifdef DEBUG
+#define DBG(format, ...) printk(KERN_DEBUG "VRAM: " format, ## __VA_ARGS__)
+#else
+#define DBG(format, ...)
+#endif
+
+#define OMAP2_SRAM_START 0x4020
+/* Maximum size, in reality this is smaller if SRAM is partially locked. */
+#define OMAP2_SRAM_SIZE0xa /* 640k */
+
+#define REG_MAP_SIZE(_page_cnt)
\
+ ((_page_cnt + (sizeof(unsigned long) * 8) - 1) / 8)
+#define REG_MAP_PTR(_rg, _page_nr) \
+ (((_rg)->map) + (_page_nr) / (sizeof(unsigned long) * 8))
+#define REG_MAP_MASK(_page_nr) \
+ (1 << ((_page_nr) & (sizeof(unsigned long) * 8 - 1)))
+
+#if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE) \
+ || defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+/* postponed regions are used to temporarily store region information at boot
+ * time when we cannot yet allocate the region list */
+#define MAX_POSTPONED_REGIONS 10
+
+static int postponed_cnt __initdata;
+static struct {
+ unsigned long paddr;
+ size_t size;
+} postponed_regions[MAX_POSTPONED_REGIONS] __initdata;
+
+struct region {
+ struct list_head list;
+ unsigned long paddr;
+ void*vaddr;
+ unsignedpage_cnt;
+ unsigneddma_alloced:1;
+ unsigned long *map;
+};
+
+static LIST_HEAD(region_list);
+
+static inline int region_mem_type(unsigned long paddr)
+{
+ if (paddr >= OMAP2_SRAM_START &&
+ paddr < OMAP2_SRAM_START + OMAP2_SRAM_SIZE)
+ return OMAPFB_MEMTYPE_SRAM;
+ else
+ return OMAPFB_MEMTYPE_SDRAM;
+}
+
+static inline int region_page_reserved(struct region *rm, unsigned page_nr)
+{
+ return *REG_MAP_PTR(rm, page_nr) & REG_MAP_MASK(page_nr) ? 1 : 0;
+}
+
+static inline void region_reserve_page(struct region *rm, unsigned page_nr)
+{
+ BUG_ON(region_page_reserved(rm, page_nr));
+ *REG_MAP_PTR(rm, page_nr) |= REG_MAP_MASK(page_nr);
+}
+
+static inline void region_free_page(struct region *rm, unsigned page_nr)
+{
+ BUG_ON(!region_page_reserved(rm, page_nr));
+ *REG_MAP_PTR(rm, page_nr) &= ~REG_MAP_MASK(page_nr);
+}
+
+static struct region *region_find_region(unsigned long paddr, size_t size)
+{
+ struct region *rm;
+ unsigned long end;
+
+ end = paddr + PAGE_ALIGN(size);
+
+ list_for_each_entry(rm, ®ion_list, list) {
+ unsigned long s, e;
+
+ s = rm->paddr;
+ e = rm->paddr + (rm->page_cnt << PAGE_SHIFT);
+
+ if (paddr >= s && end <= e)
+ return rm;
+ }
+
+ return NULL;
+}
+
+static struct region *omap_vram_create_region(unsigned long paddr,
+ void *vaddr, size_t size)
+{
+ unsigned page_cnt;
+ struct region *rm;
+
[PATCH] OMAP: Change OMAPFB to use the VRAM manager
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/fb.c | 22 ++-
arch/arm/plat-omap/include/mach/omapfb.h |2 +
drivers/video/omap/dispc.c | 281 +++---
drivers/video/omap/omapfb_main.c | 11 +-
4 files changed, 48 insertions(+), 268 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index 3746222..8c23c9b 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -38,6 +38,9 @@
#if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE)
+static int omapfb_vram_count;
+static struct omap_fbmem_config *omapfb_vram_config;
+
static struct omapfb_platform_data omapfb_config;
static int config_invalid;
static int configured_regions;
@@ -95,11 +98,11 @@ static int get_fbmem_region(int region_idx, struct
omapfb_mem_region *rg)
const struct omap_fbmem_config *conf;
u32 paddr;
- conf = omap_get_nr_config(OMAP_TAG_FBMEM,
- struct omap_fbmem_config, region_idx);
- if (conf == NULL)
+ if (region_idx >= omapfb_vram_count)
return -ENOENT;
+ conf = &omapfb_vram_config[region_idx];
+
paddr = conf->start;
/*
* Low bits encode the page allocation mode, if high bits
@@ -209,6 +212,13 @@ void __init omapfb_reserve_sdram(void)
if (rg.paddr) {
reserve_bootmem(rg.paddr, rg.size, BOOTMEM_DEFAULT);
reserved += rg.size;
+ omap_vram_add_region_postponed(rg.paddr, rg.size);
+ } else {
+ void *vaddr;
+ vaddr = alloc_bootmem(rg.size);
+ rg.paddr = virt_to_phys(vaddr);
+ reserved += rg.size;
+ omap_vram_add_region_postponed(rg.paddr, rg.size);
}
omapfb_config.mem_desc.region[i] = rg;
configured_regions++;
@@ -298,6 +308,12 @@ unsigned long omapfb_reserve_sram(unsigned long
sram_pstart,
return reserved;
}
+void __init omapfb_set_vram_config(struct omap_fbmem_config *config, int count)
+{
+ omapfb_vram_count = count;
+ omapfb_vram_config = config;
+}
+
void omapfb_set_ctrl_platform_data(void *data)
{
omapfb_config.ctrl_platform_data = data;
diff --git a/arch/arm/plat-omap/include/mach/omapfb.h
b/arch/arm/plat-omap/include/mach/omapfb.h
index f1cfd06..09da87f 100644
--- a/arch/arm/plat-omap/include/mach/omapfb.h
+++ b/arch/arm/plat-omap/include/mach/omapfb.h
@@ -392,6 +392,8 @@ extern int omapfb_update_window_async(struct fb_info *fbi,
/* in arch/arm/plat-omap/fb.c */
extern void omapfb_set_ctrl_platform_data(void *pdata);
+extern void omapfb_set_vram_config(struct omap_fbmem_config *config,
+ int count);
/* in arch/arm/plat-omap/fb-vram */
__init int omap_vram_add_region_postponed(unsigned long paddr, size_t size);
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index c140c21..9ae9b5d 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -18,6 +18,7 @@
* with this program; if not, write to the Free Software Foundation, Inc.,
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
+
#include
#include
#include
@@ -139,29 +140,12 @@
/* Maximum size, in reality this is smaller if SRAM is partially locked. */
#define OMAP2_SRAM_SIZE0xa /* 640k */
-/* We support the SDRAM / SRAM types. See OMAPFB_PLANE_MEMTYPE_* in omapfb.h */
-#define DISPC_MEMTYPE_NUM 2
-
-#define RESMAP_SIZE(_page_cnt) \
- ((_page_cnt + (sizeof(unsigned long) * 8) - 1) / 8)
-#define RESMAP_PTR(_res_map, _page_nr) \
- (((_res_map)->map) + (_page_nr) / (sizeof(unsigned long) * 8))
-#define RESMAP_MASK(_page_nr) \
- (1 << ((_page_nr) & (sizeof(unsigned long) * 8 - 1)))
-
-struct resmap {
- unsigned long start;
- unsignedpage_cnt;
- unsigned long *map;
-};
-
#define MAX_IRQ_HANDLERS4
static struct {
void __iomem*base;
struct omapfb_mem_desc mem_desc;
- struct resmap *res_map[DISPC_MEMTYPE_NUM];
atomic_tmap_count[OMAPFB_PLANE_NUM];
dma_addr_t palette_paddr;
@@ -992,35 +976,6 @@ static int omap_dispc_update_window(struct fb_info *fbi,
return dispc.update_mode == OMAPFB_UPDATE_DISABLED ? -ENODEV : 0;
}
-static int mmap_kern(struct omapfb_mem_region *region)
-{
- struct vm_struct*kvma;
- struct vm_area_struct vma;
- pgprot_tpgprot;
- unsigned long vaddr;
-
- kvma = get_vm_area(region->size, VM_IO
Re: Bug in linux omap clock framework?
On Fri, 2008-12-05 at 10:23 -0800, ext Kevin Hilman wrote:
> <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I have had strange clk_enable() crashes with DSS2, and now I managed to
> > isolate it. With the included patch, on OMAP3 SDP board, with default
> > kernel config, I always get the crash below. In this example case it
> > happens at specific time on boot, but with DSS2 it happens randomly at
> > runtime, when I enable the DSS clocks.
> >
> > diff --git a/drivers/video/omap/omapfb_main.c
> > b/drivers/video/omap/omapfb_main.c
> > index 3bb4247..2d5ef0d 100644
> > --- a/drivers/video/omap/omapfb_main.c
> > +++ b/drivers/video/omap/omapfb_main.c
> > @@ -27,6 +27,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -1806,6 +1807,18 @@ static int omapfb_probe(struct platform_device
> > *pdev)
> > {
> > BUG_ON(fbdev_pdev != NULL);
> >
> > + {
> > + struct clk *c1, *c2;
> > + c1 = clk_get(&pdev->dev, "dss_ick");
> > + c2 = clk_get(&pdev->dev, "dss1_fck");
> > + while(1) {
> > + clk_enable(c1);
> > + clk_enable(c2);
> > + clk_disable(c1);
> > + clk_disable(c2);
> > + }
> > + }
> > +
> > /* Delay actual initialization until the LCD is registered */
> > fbdev_pdev = pdev;
> > if (fbdev_panel != NULL)
> > @@ -1958,7 +1971,7 @@ module_param_named(rotate, def_rotate, uint,
> > 0664);
> > module_param_named(mirror, def_mirror, uint, 0664);
> > module_param_named(manual_update, manual_update, bool, 0664);
> >
> > -module_init(omapfb_init);
> > +late_initcall(omapfb_init);
> > module_exit(omapfb_cleanup);
> >
> > MODULE_DESCRIPTION("TI OMAP framebuffer driver");
> >
> >
> > And the crash:
> >
> >
> >
> > <1>Unhandled fault: external abort on non-linefetch (0x1028) at
> > 0xd8200098
> > Unhandled fault: external abort on non-linefetch (0x1028) at 0xd8200098
> > Internal error: : 1028 [#1]
> > Internal error: : 1028 [#1]
> > Modules linked in:Modules linked in:
> >
> > CPU: 0Not tainted (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
> > CPU: 0Not tainted (2.6.28-rc6-omap1-05264-g1705711-dirty #6)
> > PC is at __irq_svc+0x34/0x80
> > PC is at __irq_svc+0x34/0x80
> > LR is at _omap2_clk_enable+0xa0/0xe0
> > LR is at _omap2_clk_enable+0xa0/0xe0
>
> What looks to be happening is an interrupt is firing in the middle of
> your clk_enable() call, and accesses to the Interrupt controller
> registers are triggering a fault.
>
> As a temporary workaround, could you try wrapping your clk_enable()
> with an IRQ save/restore? Something like:
>
> local_irq_save(flags);
> clk_enable(c);
> local_irq_restore(flags);
>
> If this works, then we need to investigate in more detail which
> interrupt is firing, and why the INTC registers are not accessible.
No, I get the same error with irq_saves also. However, if I wrap the
whole while loop inside local_irq_save, then it doesn't crash.
So this does crash:
while(1) {
local_irq_save(flags);
clk_enable(c1);
local_irq_restore(flags);
local_irq_save(flags);
clk_disable(c1);
local_irq_restore(flags);
}
And this doesn't:
local_irq_save(flags);
while(1) {
clk_enable(c1);
clk_disable(c1);
}
Tomi
--
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
Re: Bug in linux omap clock framework?
On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> Hi Tomi,
>
> nice test case.
>
> On Fri, 5 Dec 2008, [EMAIL PROTECTED] wrote:
>
> > I have had strange clk_enable() crashes with DSS2, and now I managed to
> > isolate it. With the included patch, on OMAP3 SDP board, with default
> > kernel config, I always get the crash below. In this example case it
> > happens at specific time on boot, but with DSS2 it happens randomly at
> > runtime, when I enable the DSS clocks.
>
> Looks like there's some problem with the DSS driver's usage of
> dss_tv_fclk. Enabling dss_tv_fclk before entering your test code's
> while-loop makes the problem go away here. Patch below.
Yes, enabling dss_tv_fclk "fixes" it. Also enabling dss1_alwon_fck fixes
it. (Note that I had a bug in the test code: it's dss1_alwon_fck in
omap3, not dss1_fck =). Funny that I didn't get any error.).
So it's the ick that is causing the crashing.
>
> As an aside, your test patch does not actually disable dss1_fclk, since it
> is already enabled by the time the while-loop starts. So you might also
> want to add a clk_disable(c2) before your while-loop starts, when you
> test.
What makes you say that? Who would enable it? And clk_get_count returns
0 for dss_ick, dss1_alwon_fck and dss_tv_fclk.
>
> Based on the traceback that you sent, I'd conjecture that probably some
> part of the DSS subsystem is generating an interrupt via DSS_IRQ; but then
> dss_iclk ends up disabled, and the MPU INTC is not able to communicate
> with the DSS, and the INTC wedges. (The aborting access is to 0xd8200098,
> the INTCPS_PENDING_IRQ0 register, rather than a DSS register.) Probably
> some IRQs need to be masked before disabling the dss_iclk.
Okay. So, is this a DSS problem or clock framework problem? I made the
following test module to make testing easier, and to turn off any
interrupts. Crashes with DSS interrupts turned off also (although they
should be off by default).
Disable omapfb from kconfig if you try this.
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e39e33e..2da9eab 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -138,3 +138,6 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+
+obj-m += test.o
+
diff --git a/drivers/video/test.c b/drivers/video/test.c
new file mode 100644
index 000..285658f
--- /dev/null
+++ b/drivers/video/test.c
@@ -0,0 +1,60 @@
+#include
+#include
+#include
+
+#include
+
+#define DISPC_BASE 0x48050400
+#define DISPC_IRQSTATUS0x0018
+#define DISPC_IRQENABLE0x001C
+
+static void __iomem *base;
+
+static void inline dispc_write_reg(int idx, u32 val)
+{
+ __raw_writel(val, base + idx);
+}
+
+static u32 inline dispc_read_reg(int idx)
+{
+ return __raw_readl(base + idx);
+}
+
+static int __init omapfb_init(void)
+{
+ struct clk *c1, *c2, *c3;
+
+ c1 = clk_get(NULL, "dss_ick");
+ c2 = clk_get(NULL, "dss1_alwon_fck");
+ c3 = clk_get(NULL, "dss_tv_fck");
+
+ base = ioremap(DISPC_BASE, SZ_1K);
+ printk("mapped to %p\n", base);
+
+ clk_enable(c1);
+ clk_enable(c2);
+
+ dispc_write_reg(DISPC_IRQENABLE, 0);
+ dispc_write_reg(DISPC_IRQSTATUS, 0);
+
+ clk_disable(c1);
+ clk_disable(c2);
+
+ printk("usecounts %d, %d, %d\n", clk_get_usecount(c1),
+ clk_get_usecount(c2),
+ clk_get_usecount(c3));
+
+ /*clk_enable(c2);*/
+ /*clk_enable(c3);*/
+
+ while(1) {
+ clk_enable(c1);
+ clk_disable(c1);
+ }
+
+ return 0;
+}
+
+module_init(omapfb_init);
+MODULE_LICENSE("GPL");
+
mapped to d8050400
usecounts 0, 0, 0
Unhandled fault: external abort on non-linefetch (0x1028) at 0xd8200098
Internal error: : 1028 [#1]
Modules linked in: test(+)
CPU: 0Not tainted (2.6.28-rc6-omap1-05264-g1705711-dirty #27)
PC is at __irq_svc+0x34/0x80
LR is at _omap2_clk_enable+0xa0/0xe0
pc : []lr : []psr: 6193
sp : c7a01de0 ip : c7a01df0 fp : c7a01e3c
r10: bf003000 r9 : r8 : c0029f68
r7 : c0364c4c r6 : c0364aec r5 : d820 r4 :
r3 : 6013 r2 : c0037f78 r1 : c0033404 r0 : c7a01e28
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387f Table: 87930018 DAC: 0015
Process insmod (pid: 434, stack limit = 0xc7a002e0)
Stack: (0xc7a01de0 to 0xc7a02000)
1de0: 0010 0001 8013 c0364aec c0364c4c
1e00: c0029f68 bf003000 c7a01e3c c7a01df0 c7a01e28 c0033404 c0037f78
1e20: 6013 c7a01e5c c7a01e40 bf0030d0 c0037f40
1e40: c038a3a0 bf000440 000de220 c7a01f7c c7a01e60 c0029310 bf00300c
1e60: c79deaa0 0001 c8863d68 c885f000 c7a01e8c c7a01e80 c007b6b4 c007b454
1e80: 0007 c885f000 c79deaa0 0001 c7a01ebc
Re: Bug in linux omap clock framework?
On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote: > Hi Tomi, > > On Mon, 8 Dec 2008, Tomi Valkeinen wrote: > > > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote: > > > > Based on the traceback that you sent, I'd conjecture that probably some > > > part of the DSS subsystem is generating an interrupt via DSS_IRQ; but > > > then > > > dss_iclk ends up disabled, and the MPU INTC is not able to communicate > > > with the DSS, and the INTC wedges. (The aborting access is to > > > 0xd8200098, > > > the INTCPS_PENDING_IRQ0 register, rather than a DSS register.) Probably > > > some IRQs need to be masked before disabling the dss_iclk. > > > > Okay. So, is this a DSS problem or clock framework problem? > > At this point my guess would be that it is a DSS driver problem, but I > don't think it is clear yet. Also, after disabling CONFIG_PM the code doesn't crash anymore... Something is turning powers/clocks off too eagerly? Tomi -- 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
[PATCH] OMAP: Fix dpll4_m4_ck clk_set_rate()
This fixes commit e42218d45afbc3e654e289e021e6b80c657b16c2. The commit
was based on old kernel tree, and with bad luck applied ok but to wrong
position, modifying dpll4_m6_ck instead of dpll4_m4_ck.
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock34xx.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 1c2b49f..5357507 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -825,6 +825,8 @@ static struct clk dpll4_m4_ck = {
PARENT_CONTROLS_CLOCK,
.clkdm = { .name = "dpll4_clkdm" },
.recalc = &omap2_clksel_recalc,
+ .set_rate = &omap2_clksel_set_rate,
+ .round_rate = &omap2_clksel_round_rate,
};
/* The PWRDN bit is apparently only available on 3430ES2 and above */
@@ -879,8 +881,6 @@ static struct clk dpll4_m6_ck = {
PARENT_CONTROLS_CLOCK,
.clkdm = { .name = "dpll4_clkdm" },
.recalc = &omap2_clksel_recalc,
- .set_rate = &omap2_clksel_set_rate,
- .round_rate = &omap2_clksel_round_rate,
};
/* The PWRDN bit is apparently only available on 3430ES2 and above */
--
1.6.0.3
--
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
Re: Branch for fbdriver (Re: [PATCH 1/2] OMAP: Make dpll4_m4_ck programmable with clk_set_rate())
Hi, On Fri, 2008-12-05 at 18:12 -0800, ext Tony Lindgren wrote: > * Måns Rullgård <[EMAIL PROTECTED]> [081205 17:40]: > > Tony Lindgren <[EMAIL PROTECTED]> writes: > > > > > Måns, I heard you have some display patches? How about queuing up > > > those on the fbdev list? > > > > It looks like Tomi's driver is shaping up nicely, so it's probably not > > worthwhile spending any significant time on the current driver. If > > anyone is interested, everything I have is in my git tree. > > OK, good to know. Tomi, do you have a git branch against the > mainline kernel for your driver? > > We could start mirroring it on linux-omap and then start automerging > it on daily basis to linux-omap for testing (Assuming it does not cause > problems with other stuff :) I have a git tree against current linux-omap tree at http://www.bat.org/~tomba/git/linux-omap-dss.git It is possible to have a branch based on Linus' tree also, but it's more maintenance work as I need a bunch of omap patches that are not in Linus' tree. (Actually, I have never tested DSS2 with Linus' tree, so I'm not sure how much stuff there's missing). I'd like to get the DSS2 working on OMAP2 also, but I'm (still) waiting for my N810. Half a year ago the DSS2 did work on OMAP2, but I'm sure it's since been broken, and needs some healing. But after that I'm all for it. However, there is a small breakage because of the VRAM manager and OMAP_TAG removal. That code is common for the old and new DSS. I have a patch to fix the old DSS to use the VRAM manager, but I don't think it's a good idea to break the old working code with new experimental code =). So I think I'll see if I can easily separate the old and new boot time memory allocation. But what does it mean in practice? Mirroring means you (script?) will fetch a branch from my tree to dss2 branch on linux-omap tree? What does automerging mean? Does it mean I can still continue rebasing my tree to keep it clean? Tomi -- 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
Re: Bug in linux omap clock framework?
On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote: > Hi Tomi, > > nice test case. > > On Fri, 5 Dec 2008, [EMAIL PROTECTED] wrote: > > > I have had strange clk_enable() crashes with DSS2, and now I managed to > > isolate it. With the included patch, on OMAP3 SDP board, with default > > kernel config, I always get the crash below. In this example case it > > happens at specific time on boot, but with DSS2 it happens randomly at > > runtime, when I enable the DSS clocks. > > Looks like there's some problem with the DSS driver's usage of > dss_tv_fclk. Enabling dss_tv_fclk before entering your test code's > while-loop makes the problem go away here. Patch below. > > As an aside, your test patch does not actually disable dss1_fclk, since it > is already enabled by the time the while-loop starts. So you might also > want to add a clk_disable(c2) before your while-loop starts, when you > test. > > Based on the traceback that you sent, I'd conjecture that probably some > part of the DSS subsystem is generating an interrupt via DSS_IRQ; but then > dss_iclk ends up disabled, and the MPU INTC is not able to communicate > with the DSS, and the INTC wedges. (The aborting access is to 0xd8200098, > the INTCPS_PENDING_IRQ0 register, rather than a DSS register.) Probably > some IRQs need to be masked before disabling the dss_iclk. It doesn't seem to be DSS related, the same crash happens also with cam_ick and sgx_ick. Tomi -- 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
Re: Bug in linux omap clock framework?
Hi, On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote: > Hi Tomi, > > On Mon, 8 Dec 2008, Tomi Valkeinen wrote: > > > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote: > > > Hi Tomi, > > > > > > nice test case. > > > > > > On Fri, 5 Dec 2008, [EMAIL PROTECTED] wrote: > > > > > > > I have had strange clk_enable() crashes with DSS2, and now I managed to > > > > isolate it. With the included patch, on OMAP3 SDP board, with default > > > > kernel config, I always get the crash below. In this example case it > > > > happens at specific time on boot, but with DSS2 it happens randomly at > > > > runtime, when I enable the DSS clocks. > > > > > At this point my guess would be that it is a DSS driver problem, but I > don't think it is clear yet. > I don't know much about power and clock domains, but I believe I found the reason and fix for this. At least this should point to the right direction. It looks to me that when I do clk_enable() to a clock which is inside a turned off powerdomain, clk_enable() function will return before the powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the powerdomain is still in transition state. The following change waits until the powerdomain has finished the transition. At least it fixed the problem for me, and other things seem to be still working =). diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c index fa62f14..f713d0b 100644 --- a/arch/arm/mach-omap2/clockdomain.c +++ b/arch/arm/mach-omap2/clockdomain.c @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk) else omap2_clkdm_wakeup(clkdm); + pwrdm_wait_transition(clkdm->pwrdm.ptr); + return 0; } -- 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
Re: Bug in linux omap clock framework?
On Wed, 2008-12-10 at 09:37 +0200, Högander Jouni wrote: > "ext Tomi Valkeinen" <[EMAIL PROTECTED]> writes: > > > Hi, > > > > On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote: > >> Hi Tomi, > >> > >> On Mon, 8 Dec 2008, Tomi Valkeinen wrote: > >> > >> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote: > >> > > Hi Tomi, > >> > > > >> > > nice test case. > >> > > > >> > > On Fri, 5 Dec 2008, [EMAIL PROTECTED] wrote: > >> > > > >> > > > I have had strange clk_enable() crashes with DSS2, and now I managed > >> > > > to > >> > > > isolate it. With the included patch, on OMAP3 SDP board, with default > >> > > > kernel config, I always get the crash below. In this example case it > >> > > > happens at specific time on boot, but with DSS2 it happens randomly > >> > > > at > >> > > > runtime, when I enable the DSS clocks. > >> > > > >> > >> At this point my guess would be that it is a DSS driver problem, but I > >> don't think it is clear yet. > >> > > > > I don't know much about power and clock domains, but I believe I found > > the reason and fix for this. At least this should point to the right > > direction. > > > > It looks to me that when I do clk_enable() to a clock which is inside a > > turned off powerdomain, clk_enable() function will return before the > > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the > > powerdomain is still in transition state. > > > > The following change waits until the powerdomain has finished the > > transition. At least it fixed the problem for me, and other things seem > > to be still working =). > > > > > > diff --git a/arch/arm/mach-omap2/clockdomain.c > > b/arch/arm/mach-omap2/clockdomain.c > > index fa62f14..f713d0b 100644 > > --- a/arch/arm/mach-omap2/clockdomain.c > > +++ b/arch/arm/mach-omap2/clockdomain.c > > @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, > > struct clk *clk) > > else > > omap2_clkdm_wakeup(clkdm); > > > > + pwrdm_wait_transition(clkdm->pwrdm.ptr); > > + > > Altough this patch is fixing the problem, I'll guess it's because of > delay it causes rather than waiting for > PM_PWSTST_DSS. omap2_clkdm_clk_enable alone doesn't switch pwrdm to > on. This is because clockdomain/powerdomains are controlled by HW (hw > supervised). > > I think the right answer is to use ST_*_IDLE & ST_*_STDBY bits in > omap2_clk_wait_ready. But ST_DSS_IDLE says active only after both interface and functional clock are on, so it doesn't help here. Why is it wrong to wait for PM_PWSTST_DSS? Do you mean that this crash is not caused by the DSS being not powered on, but by something else, and so the small delay just accidentally fixes the problem? Tomi -- 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
Re: Bug in linux omap clock framework?
On Wed, 2008-12-10 at 10:44 +0200, Högander Jouni wrote:
> Tomi Valkeinen <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2008-12-10 at 09:37 +0200, Högander Jouni wrote:
> >> "ext Tomi Valkeinen" <[EMAIL PROTECTED]> writes:
> >>
> >> > Hi,
> >> >
> >> > On Mon, 2008-12-08 at 02:24 -0700, ext Paul Walmsley wrote:
> >> >> Hi Tomi,
> >> >>
> >> >> On Mon, 8 Dec 2008, Tomi Valkeinen wrote:
> >> >>
> >> >> > On Sat, 2008-12-06 at 16:51 -0700, ext Paul Walmsley wrote:
> >> >> > > Hi Tomi,
> >> >> > >
> >> >> > > nice test case.
> >> >> > >
> >> >> > > On Fri, 5 Dec 2008, [EMAIL PROTECTED] wrote:
> >> >> > >
> >> >> > > > I have had strange clk_enable() crashes with DSS2, and now I
> >> >> > > > managed to
> >> >> > > > isolate it. With the included patch, on OMAP3 SDP board, with
> >> >> > > > default
> >> >> > > > kernel config, I always get the crash below. In this example case
> >> >> > > > it
> >> >> > > > happens at specific time on boot, but with DSS2 it happens
> >> >> > > > randomly at
> >> >> > > > runtime, when I enable the DSS clocks.
> >> >> > >
> >> >>
> >> >> At this point my guess would be that it is a DSS driver problem, but I
> >> >> don't think it is clear yet.
> >> >>
> >> >
> >> > I don't know much about power and clock domains, but I believe I found
> >> > the reason and fix for this. At least this should point to the right
> >> > direction.
> >> >
> >> > It looks to me that when I do clk_enable() to a clock which is inside a
> >> > turned off powerdomain, clk_enable() function will return before the
> >> > powerdomain is fully turned on. Reading PM_PWSTST_DSS shows that the
> >> > powerdomain is still in transition state.
> >> >
> >> > The following change waits until the powerdomain has finished the
> >> > transition. At least it fixed the problem for me, and other things seem
> >> > to be still working =).
> >> >
> >> >
> >> > diff --git a/arch/arm/mach-omap2/clockdomain.c
> >> > b/arch/arm/mach-omap2/clockdomain.c
> >> > index fa62f14..f713d0b 100644
> >> > --- a/arch/arm/mach-omap2/clockdomain.c
> >> > +++ b/arch/arm/mach-omap2/clockdomain.c
> >> > @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain
> >> > *clkdm, struct clk *clk)
> >> > else
> >> > omap2_clkdm_wakeup(clkdm);
> >> >
> >> > + pwrdm_wait_transition(clkdm->pwrdm.ptr);
> >> > +
> >>
> >> Altough this patch is fixing the problem, I'll guess it's because of
> >> delay it causes rather than waiting for
> >> PM_PWSTST_DSS. omap2_clkdm_clk_enable alone doesn't switch pwrdm to
> >> on. This is because clockdomain/powerdomains are controlled by HW (hw
> >> supervised).
> >>
> >> I think the right answer is to use ST_*_IDLE & ST_*_STDBY bits in
> >> omap2_clk_wait_ready.
> >
> > But ST_DSS_IDLE says active only after both interface and functional
> > clock are on, so it doesn't help here.
>
> Yes and in ST_DSS_IDLE description it is saying that if it's "0x1
> Display sub-system is in idle mode and cannot be accessed". So it only
> way to get it out of idle is to enable both clocks it needs to be done.
>
> If you look at arch/arm/mach-omap2/clock.c:omap2_clk_wait_ready it is
> actually checking that both clocks are enabled.
But the ST_DSS_IDLE doesn't help here. The kernel crashes after enabling
dss_ick, before your code can even enable dss_fck. The same happens if
you do it other way around, first dss_fck and then dss_ick.
> > Why is it wrong to wait for PM_PWSTST_DSS? Do you mean that this crash
> > is not caused by the DSS being not powered on, but by something else,
> > and so the small delay just accidentally fixes the problem?
>
> Something like that.
>
> If you look at your code:
>
> +static int __init omapfb_init(void)
> +{
> + struct clk *c1, *c2, *c3;
> +
> + c1 = clk_get(NULL, "dss_ick");
> + c
Re: Bug in linux omap clock framework?
On Wed, 2008-12-10 at 12:44 +0200, Högander Jouni wrote:
> Tomi Valkeinen <[EMAIL PROTECTED]> writes:
[snip]
> >
> > And again, the problem is not accessing DSS registers. The problem is
> > that clk_enable(dss_ick) crashes. so the following code crashes also:
> >
> > static int __init test_init(void)
> > {
> > struct clk *c1 = clk_get(NULL, "dss_ick");
> >
> > while(1) {
> > clk_enable(c1);
> > clk_disable(c1);
> > }
> >
> > return 0;
> > }
> >
>
> Are you still using SDP and default config + latest linux-omap? I'm
> not able to reproduce this using your example code.
Yes. But you have to disable omapfb, so that it doesn't enable the
clocks.
Just in case, here's attached my .config, and below is a patch I've
used. It compiles in to kernel, and crashes almost immediately at boot
time.
>From ba19fccb3ac04f9f8c22b42a55ac932f6dc5a99a Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <[EMAIL PROTECTED]>
Date: Mon, 8 Dec 2008 11:15:12 +0200
Subject: [PATCH] DSS clk bug testing
---
drivers/video/Makefile |3 +++
drivers/video/test.c | 20
2 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/test.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index e39e33e..17611d9 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -138,3 +138,6 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+
+obj-y += test.o
+
diff --git a/drivers/video/test.c b/drivers/video/test.c
new file mode 100644
index 000..8c9241b
--- /dev/null
+++ b/drivers/video/test.c
@@ -0,0 +1,20 @@
+#include
+#include
+
+#include
+
+static int __init test_init(void)
+{
+ struct clk *c1 = clk_get(NULL, "dss_ick");
+
+ while(1) {
+ clk_enable(c1);
+ clk_disable(c1);
+ }
+
+ return 0;
+}
+
+late_initcall(test_init);
+MODULE_LICENSE("GPL");
+
--
1.6.0.3
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.28-rc7-omap1
# Wed Dec 10 13:44:45 2008
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_MMU=y
# CONFIG_NO_IOPORT is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_VECTORS_BASE=0x
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEAD
[PATCH] OMAP: wait for pwrdm transition after clk_enable/disable()
Enabling clock in a disabled power domain causes the power domain to be turned on. However, the power transition is not always finished when clk_enable() returns and this randomly crashes the kernel when an interrupt happens right after the clk_enable, and the kernel tries to read the irq status register for that domain. Why the irq status register is inaccessible, I don't know. Also it doesn't seem to be related to the module being not powered up, but to the transition itself. The same could perhaps happen after clk_disable also, even if I have not witnessed that. The problem affects at least dss, cam and sgx clocks. This change waits for the transition to be finished before returning from omap2_clkdm_clk_enable/disable(). Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]> --- arch/arm/mach-omap2/clockdomain.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c index fa62f14..3ae9beb 100644 --- a/arch/arm/mach-omap2/clockdomain.c +++ b/arch/arm/mach-omap2/clockdomain.c @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk) else omap2_clkdm_wakeup(clkdm); + pwrdm_wait_transition(clkdm->pwrdm.ptr); + return 0; } @@ -618,6 +620,8 @@ int omap2_clkdm_clk_disable(struct clockdomain *clkdm, struct clk *clk) else omap2_clkdm_sleep(clkdm); + pwrdm_wait_transition(clkdm->pwrdm.ptr); + return 0; } -- 1.6.0.3 -- 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
Re: Bug in linux omap clock framework?
On Thu, 2008-12-11 at 09:17 -0700, ext Paul Walmsley wrote: > Hi Jouni, Tomi, > > On Thu, 11 Dec 2008, Högander Jouni wrote: > > > So it seems that cm_* register should not be written while there is > > powerstate transition ongoing in * domain. Patch by Tomi is fixing > > this. As it seems to be transition related rather than pwrdm state, > > same line should be added into omap2_clkdm_clk_disable also. > > Shouldn't this have also crashed the system if it needed to be done > in omap2_clkdm_clk_disable() ? Perhaps we should avoid adding it there > until we can reproduce a crash there? > Yep, I haven't seen a crash related to disabling the clock. So perhaps it's better to just wait in enable for now. I'll resend the patch I sent earlier. Tomi -- 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] OMAP: wait for pwrdm transition after clk_enable()
Enabling clock in a disabled power domain causes the power domain to be turned on. However, the power transition is not always finished when clk_enable() returns and this randomly crashes the kernel when an interrupt happens right after the clk_enable, and the kernel tries to read the irq status register for that domain. Why the irq status register is inaccessible, I don't know. Also it doesn't seem to be related to the module being not powered up, but to the transition itself. The same could perhaps happen after clk_disable also, but I have not witnessed that. The problem affects at least dss, cam and sgx clocks. This change waits for the transition to be finished before returning from omap2_clkdm_clk_enable(). Signed-off-by: Tomi Valkeinen --- arch/arm/mach-omap2/clockdomain.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c index fa62f14..f713d0b 100644 --- a/arch/arm/mach-omap2/clockdomain.c +++ b/arch/arm/mach-omap2/clockdomain.c @@ -567,6 +567,8 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk) else omap2_clkdm_wakeup(clkdm); + pwrdm_wait_transition(clkdm->pwrdm.ptr); + return 0; } -- 1.6.0.3 -- 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: [REVIEW PATCH 1/1] OMAP3EVM support-Refreshed against latest Tomis code-base
Hi,
Thanks, applied.
Tomi
On Mon, 2008-12-15 at 10:01 +0200, hvaib...@ti.com wrote:
> From: Vaibhav Hiremath
>
> Refreshed and Cleaned up as per the latest Tomi's DSS2
> code-base -
>
> http://www.bat.org/~tomba/git/linux-omap-dss.git
>
> Tomi,
>
> Can you please merge this patch to your repository, so
> that it will be available as part of your HEAD?
>
> Signed-off-by: Brijesh Jadav
> Signed-off-by: Hardik Shah
> Signed-off-by: Manjunath Hadli
> Signed-off-by: R Sivaraj
> Signed-off-by: Vaibhav Hiremath
> ---
> arch/arm/mach-omap2/board-omap3evm.c | 69
> +-
> 1 files changed, 26 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index 0a722d7..cf0a6b3 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -36,7 +36,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #include "sdram-micron-mt46h32m32lf-6.h"
> @@ -161,20 +160,7 @@ static int __init omap3_evm_i2c_init(void)
> omap_register_i2c_bus(3, 400, NULL, 0);
> return 0;
> }
> -static struct omap_fbmem_config evm_fbmem0_config = {
> - .size = 480*720*4,
> - .start = OMAPFB_MEMTYPE_SDRAM,
> -};
> -
> -static struct omap_fbmem_config evm_fbmem1_config = {
> - .size = 480*720*4,
> - .start = OMAPFB_MEMTYPE_SDRAM,
> -};
>
> -static struct omap_fbmem_config evm_fbmem2_config = {
> - .size = 480*720*4,
> - .start = OMAPFB_MEMTYPE_SDRAM,
> -};
> #define LCD_PANEL_LR 2
> #define LCD_PANEL_UD 3
> #define LCD_PANEL_INI 152
> @@ -195,7 +181,7 @@ static struct omap_fbmem_config evm_fbmem2_config
> = {
> static int lcd_enabled;
> static int dvi_enabled;
>
> -static void __init evm_display_init(void)
> +static void __init omap3_evm_display_init(void)
> {
> int r;
> r = gpio_request(LCD_PANEL_LR, "lcd_panel_lr");
> @@ -258,7 +244,7 @@ err_1:
>
> }
>
> -static int evm_panel_enable_lcd(struct omap_display *display)
> +static int omap3_evm_panel_enable_lcd(struct omap_display *display)
> {
> if (dvi_enabled) {
> printk(KERN_ERR "cannot enable LCD, DVI is enabled
> \n");
> @@ -275,7 +261,7 @@ static int evm_panel_enable_lcd(struct
> omap_display *display)
> return 0;
> }
>
> -static void evm_panel_disable_lcd(struct omap_display *display)
> +static void omap3_evm_panel_disable_lcd(struct omap_display *display)
> {
> if (omap_rev() > OMAP3430_REV_ES1_0) {
> twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x0,
> @@ -287,16 +273,16 @@ static void evm_panel_disable_lcd(struct
> omap_display *display)
> lcd_enabled = 0;
> }
>
> -static struct omap_display_data evm_display_data = {
> +static struct omap_display_data omap3_evm_display_data = {
> .type = OMAP_DISPLAY_TYPE_DPI,
> .name = "lcd",
> .panel_name = "sharp-ls037v7dw01",
> .u.dpi.data_lines = 18,
> - .panel_enable = evm_panel_enable_lcd,
> - .panel_disable = evm_panel_disable_lcd,
> + .panel_enable = omap3_evm_panel_enable_lcd,
> + .panel_disable = omap3_evm_panel_disable_lcd,
> };
>
> -static int evm_panel_enable_tv(struct omap_display *display)
> +static int omap3_evm_panel_enable_tv(struct omap_display *display)
> {
> twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
> ENABLE_VDAC_DEDICATED,
> TWL4030_VDAC_DEDICATED);
> @@ -305,7 +291,7 @@ static int evm_panel_enable_tv(struct omap_display
> *display)
> return 0;
> }
>
> -static void evm_panel_disable_tv(struct omap_display *display)
> +static void omap3_evm_panel_disable_tv(struct omap_display *display)
> {
> twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x00,
> TWL4030_VDAC_DEDICATED);
> @@ -313,16 +299,16 @@ static void evm_panel_disable_tv(struct
> omap_display *display)
> TWL4030_VDAC_DEV_GRP);
> }
>
> -static struct omap_display_data evm_display_data_tv = {
> +static struct omap_display_data omap3_evm_display_data_tv = {
> .type = OMAP_DISPLAY_TYPE_VENC,
> .name = "tv",
> .u.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
> - .panel_enable = evm_panel_enable_tv,
> - .panel_disable = evm_panel_disable_tv,
> + .panel_enable = omap3_evm_panel_enable_tv,
> + .panel_disable = omap3_evm_panel_disable_tv,
> };
>
>
> -static int evm_panel_enable_dvi(struct omap_display *display)
> +static int omap3_evm_panel_enable_dvi(struct omap_display *display)
> {
> if (lcd_enabled) {
> printk(KERN_ERR "cannot enable DVI, LCD is enabled
> \n");
> @@ -337,7 +323,7 @@ static int evm_panel_enable_dvi(struct
> omap_display *display)
> return 0;
> }
>
> -static void evm_panel_disable_dvi(struct omap_display *display)
> +static void
USB slightly broken
Hi, Yesterday's "Merge branch 'musb'" broke the USB slightly on our board. I use NFS root via USB gadget ethernet and if I have the usb cable connected when the device boots up, the network does not go up correctly. If I disconnect and connect the cable the USB starts working. I can't currently test this on other boards, but I will test it on beagle later. g_ether gadget: high speed config #1: CDC Ethernet (ECM) IP-Config: Guessing netmask 255.255.255.0 IP-Config: Complete: device=usb0, addr=192.168.2.15, mask=255.255.255.0, gw=255.255.255.255, host=192.168.2.15, domain=, nis-domain=(none), bootserver=255.255.255.255, rootserver=192.168.2.14, rootpath= Looking up port of RPC 13/2 on 192.168.2.14 (at this point the interface is up on PC side, but pings don't go through) Tomi -- 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: USB slightly broken
On Fri, 2008-12-19 at 13:58 +0200, Felipe Balbi wrote: > On Fri, Dec 19, 2008 at 12:25:16PM +0200, ext Tomi Valkeinen wrote: > > Yesterday's "Merge branch 'musb'" broke the USB slightly on our board. I > > use NFS root via USB gadget ethernet and if I have the usb cable > > connected when the device boots up, the network does not go up > > correctly. If I disconnect and connect the cable the USB starts working. > > > > I can't currently test this on other boards, but I will test it on > > beagle later. > > > > g_ether gadget: high speed config #1: CDC Ethernet (ECM) > > IP-Config: Guessing netmask 255.255.255.0 > > IP-Config: Complete: > > device=usb0, addr=192.168.2.15, mask=255.255.255.0, gw=255.255.255.255, > > host=192.168.2.15, domain=, nis-domain=(none), > > bootserver=255.255.255.255, rootserver=192.168.2.14, rootpath= > > Looking up port of RPC 13/2 on 192.168.2.14 > > > > (at this point the interface is up on PC side, but pings don't go through) > > Could you try this patch: (untested) This patch randomly fixes the problem and randomly crashes (usually crashes): g_ether gadget: high speed config #1: CDC Ethernet (ECM) kernel BUG at drivers/usb/musb/musbhsdma.c:168! Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 805 [#1] Modules linked in: CPU: 0Not tainted (2.6.28-rc9-omap1 #19) PC is at __bug+0x20/0x2c LR is at release_console_sem+0x190/0x1a8 pc : []lr : []psr: 6193 sp : cf81fb20 ip : cf81fa50 fp : cf81fb2c r10: c039fa8c r9 : 3ffe r8 : 8f949002 r7 : 0200 r6 : cf951068 r5 : cf951068 r4 : 2003 r3 : r2 : c0354a8c r1 : 29af r0 : 0033 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004018 DAC: 0017 Process swapper (pid: 1, stack limit = 0xcf81e2e0) Stack: (0xcf81fb20 to 0xcf82) fb20: cf81fb7c cf81fb30 c01d691c c002fb5c cf96a160 0600 cf81b338 0020 fb40: cf81fb74 cf81fb50 c01d767c 0001 cf948ba0 2003 cf96a160 cf81b338 fb60: 3ffe 2003 d80ab110 3ffe cf81fbbc cf81fb80 c01d20a8 c01d6898 fb80: 3ffe cf96a160 cf81fbbc cf81fb98 c01d1c4c 2003 cf81b338 cf951068 fba0: cf96a160 0003 cf81b0f0 d80ab110 cf81fc04 cf81fbc0 c01d3510 c01d1ff4 fbc0: 0001 d80ab116 cf956720 fbe0: cf951068 005a 8f948002 8f94805c 0193 d80ab000 cf81fc14 cf81fc08 fc00: c01cf130 c01d3220 cf81fc6c cf81fc18 c01d6bd8 c01cf0d0 fc20: cf951000 cf81b0f0 0004 0002 fc40: c01714ec cf956720 005d cf81b338 00d0 fc60: cf81fc8c cf81fc70 c0072828 c01d6a98 c035809c 005d cf96a160 fc80: cf81fca4 cf81fc90 c0074320 c00727f8 005d cf81fcbc cf81fca8 fca0: c002c068 c0074258 d820 cf81fd2c cf81fcc0 c0285f70 c002c00c fcc0: 022c 061d cf843bc0 cf948ba0 cf96a160 fce0: cf81b338 00d0 cf81fd2c 0224 cf81fd08 c01d20a8 c01d769c fd00: 0013 cf948ba0 00d0 1003 1002 c002b194 c0024364 fd20: cf81fd44 cf81fd30 c01d7748 c01d75b0 cf948ba0 00d0 cf81fd5c cf81fd48 fd40: c01d7824 c01d770c cf948ba0 cf948800 cf81fd74 cf81fd60 c01da2c0 c01d7800 fd60: cf948800 cf948830 cf81fd8c cf81fd78 c02052dc c01da28c cf948800 0001 fd80: cf81fdac cf81fd90 c02043ac c020524c c03a04c0 cf948800 0003 1002 fda0: cf81fe5c cf81fdb0 c00244c8 c0204320 c0368638 cf81fdec cf81fdc8 fdc0: c0055644 c0054bbc cf81fdee a013 c039c36c c0368628 c0368638 fde0: cf81fe14 cf81fdf0 c005c8d0 c00555b0 c039bca0 c039c340 fe00: c001ac14 cf81fe24 cf81fe18 cf81fe34 cf81fe20 c0238f80 c015f118 fe20: c0327255 c00270bc cf81fe4c cf81fe38 c0238fcc c0375b00 c00270bc fe40: c0024364 cf81ffdc cf81fe60 c002c314 c0024370 fe60: cf812cc0 00d0 cf81fedc cf81fe80 c007b594 c007b0d4 fe80: 0044 c007b594 cf81fedc 0010 fea0: cf81feec cf8035a0 cf83d6e0 fec0: cf8035a0 cf8035a4 024e cf81ff34 cf81fee0 c015b05c c0096714 fee0: cf81ff0c cf81ff54 c0096d4c cf811e30 c038cb20 00d0 c038b66c ff00: cf81ff2c cf81ff10 c015b270 cf83c0a0 c035bd14 cf83d6e0 c038b66c ff20: cf81ff44 cf81ff38 c015b090 c015aec8 cf81ff74 cf81ff48 ff40: c00d82d0 c015b084 cf83d6e0 c0305643 cf81ff9e 024e cf83c0a0 c035bd14 ff60: 015f c038b66c cf81ff94 cf81ff78 c00d8500 c00d82a4 cf81ff94 cf83d6e0 ff80: c00d8634 cf81ff9e cf81ffc4 cf81ff98 c0074824 c00d84c4 cf81ffb4 3533d9e8 ffa0: 0031 0192 c035c908 c0027434 c0
[PATCH 00/12] DSS: Series description
New Display Subsystem for OMAP2/3 - This patch set implements new Display Subsystem (DSS) for OMAP2/3 processors. The DSS is still under work and these patches are for review. This is an updated version of the patch set I sent back in november: http://marc.info/?l=linux-fbdev-devel&m=122581504222406&w=2 The first patch is a doc file that tries to explain a bit how the drivers work. The patch set is based on the current linux-omap tree. You can find the patches also from a git tree at http://www.bat.org/~tomba/git/linux-omap-dss.git/ --- Tomi Valkeinen (12): DSS: Hacked N810 support DSS: Support for OMAP3 EVM board DSS: Support for OMAP3 SDP board DSS: Sharp LS037V7DW01 LCD Panel driver DSS: support for Beagle Board DSS: Add generic DVI panel DSS: OMAPFB: fb driver for new display subsystem DSS: DSI support DSS: VENC support DSS: RFBI support DSS: Display subsystem for OMAP2/3 DSS: Documentation for DSS2 Documentation/arm/OMAP/DSS| 270 ++ arch/arm/configs/dss_omap3_beagle_defconfig | 1437 +++ arch/arm/configs/dss_omap_3430sdp_defconfig | 1603 + arch/arm/mach-omap2/board-3430sdp.c | 215 ++ arch/arm/mach-omap2/board-n800.c | 214 +- arch/arm/mach-omap2/board-omap3beagle.c | 101 + arch/arm/mach-omap2/board-omap3evm.c | 203 ++ arch/arm/plat-omap/Kconfig|2 arch/arm/plat-omap/Makefile |4 arch/arm/plat-omap/dss/Kconfig| 71 + arch/arm/plat-omap/dss/Makefile |6 arch/arm/plat-omap/dss/dispc.c| 2113 + arch/arm/plat-omap/dss/display.c | 787 ++ arch/arm/plat-omap/dss/dpi.c | 344 +++ arch/arm/plat-omap/dss/dsi.c | 3187 + arch/arm/plat-omap/dss/dss.c | 774 ++ arch/arm/plat-omap/dss/dss.h | 274 ++ arch/arm/plat-omap/dss/rfbi.c | 1262 ++ arch/arm/plat-omap/dss/sdi.c | 174 + arch/arm/plat-omap/dss/venc.c | 506 arch/arm/plat-omap/fb-vram.c | 646 + arch/arm/plat-omap/fb.c | 22 arch/arm/plat-omap/include/mach/display.h | 462 arch/arm/plat-omap/include/mach/omapfb.h | 14 drivers/video/Kconfig |1 drivers/video/Makefile|1 drivers/video/omap/Kconfig|5 drivers/video/omap2/Kconfig | 62 drivers/video/omap2/Makefile |8 drivers/video/omap2/ctrl-blizzard.c | 279 ++ drivers/video/omap2/omapfb-ioctl.c| 460 drivers/video/omap2/omapfb-main.c | 1442 +++ drivers/video/omap2/omapfb-sysfs.c| 901 +++ drivers/video/omap2/omapfb.h | 115 + drivers/video/omap2/panel-generic.c | 97 + drivers/video/omap2/panel-n800.c | 437 +++ drivers/video/omap2/panel-sharp-ls037v7dw01.c | 109 + 37 files changed, 18537 insertions(+), 71 deletions(-) create mode 100644 Documentation/arm/OMAP/DSS create mode 100644 arch/arm/configs/dss_omap3_beagle_defconfig create mode 100644 arch/arm/configs/dss_omap_3430sdp_defconfig create mode 100644 arch/arm/plat-omap/dss/Kconfig create mode 100644 arch/arm/plat-omap/dss/Makefile create mode 100644 arch/arm/plat-omap/dss/dispc.c create mode 100644 arch/arm/plat-omap/dss/display.c create mode 100644 arch/arm/plat-omap/dss/dpi.c create mode 100644 arch/arm/plat-omap/dss/dsi.c create mode 100644 arch/arm/plat-omap/dss/dss.c create mode 100644 arch/arm/plat-omap/dss/dss.h create mode 100644 arch/arm/plat-omap/dss/rfbi.c create mode 100644 arch/arm/plat-omap/dss/sdi.c create mode 100644 arch/arm/plat-omap/dss/venc.c create mode 100644 arch/arm/plat-omap/fb-vram.c create mode 100644 arch/arm/plat-omap/include/mach/display.h create mode 100644 drivers/video/omap2/Kconfig create mode 100644 drivers/video/omap2/Makefile create mode 100644 drivers/video/omap2/ctrl-blizzard.c create mode 100644 drivers/video/omap2/omapfb-ioctl.c create mode 100644 drivers/video/omap2/omapfb-main.c create mode 100644 drivers/video/omap2/omapfb-sysfs.c create mode 100644 drivers/video/omap2/omapfb.h create mode 100644 drivers/video/omap2/panel-generic.c create mode 100644 drivers/video/omap2/panel-n800.c create mode 100644 drivers/video/omap2/panel-sharp-ls037v7dw01.c -- Tomi Valkeinen -- 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 01/12] DSS: Documentation for DSS2
Signed-off-by: Tomi Valkeinen --- Documentation/arm/OMAP/DSS | 270 1 files changed, 270 insertions(+), 0 deletions(-) create mode 100644 Documentation/arm/OMAP/DSS diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS new file mode 100644 index 000..011fee1 --- /dev/null +++ b/Documentation/arm/OMAP/DSS @@ -0,0 +1,270 @@ +OMAP2/3 Display Subsystem +- + +This is an almost total rewrite of the OMAP FB driver in drivers/video/omap +(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI, +TV-out and multiple display support, but there are lots of small improvements +also. + +The DSS2 driver (omap-dss module) is in arch/arm/plat-omap/dss/, and the FB, +panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live +currently side by side, you can choose which one to use. + +Features + + +Working and tested features include: + +- MIPI DPI (parallel) output +- MIPI DSI output in command mode +- MIPI DBI (RFBI) output +- SDI output +- TV output +- All pieces can be compiled as a module or inside kernel +- Use DISPC to update any of the outputs +- Use CPU to update RFBI or DSI output +- OMAP DISPC planes +- RGB16, RGB24 packed, RGB24 unpacked +- YUV2, UYVY +- Scaling +- Adjusting DSS FCK to find a good pixel clock +- Use DSI DPLL to create DSS FCK + +Tested boards include: +- OMAP3 SDP board +- Beagle board +- N810 + +omap-dss driver + + +The DSS driver does not itself have any support for Linux framebuffer, V4L or +such like the current ones, but it has an internal kernel API that upper level +drivers can use. + +The DSS driver models OMAP's overlays, overlay managers and displays in a +flexible way to enable non-common multi-display configuration. In addition to +modelling the hardware overlays, omap-dss supports virtual overlays and overlay +managers. These can be used when updating a display with CPU or system DMA. + +Panel and controller drivers + + +The drivers implement panel or controller specific functionality and are not +usually visible to users except through omapfb driver. They register +themselves to the DSS driver. + +omapfb driver +- + +The omapfb driver implements arbitrary number of standard linux framebuffers. +These framebuffers can be routed flexibly to any overlays, thus allowing very +dynamic display architecture. + +The driver exports some omapfb specific ioctls, which are compatible with the +ioctls in the old driver. + +The rest of the non standard features are exported via sysfs. Whether the final +implementation will use sysfs, or ioctls, is still open. + +V4L2 drivers + + +V4L2 is being implemented in TI. + +From omap-dss point of view the V4L2 drivers should be similar to framebuffer +driver. + +Architecture + + +Some clarification what the different components do: + +- Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the + pixel data for the image. Framebuffer has width and height and color + depth. +- Overlay defines where the pixels are read from and where they go on the + screen. The overlay may be smaller than framebuffer, thus displaying only + part of the framebuffer. The position of the overlay may be changed if + the overlay is smaller than the display. +- Overlay manager combines the overlays in to one image and feeds them to + display. +- Display is the actual physical display device. + +A framebuffer can be connected to multiple overlays to show the same pixel data +on all of the overlays. Note that in this case the overlay input sizes must be +the same, but, in case of video overlays, the output size can be different. Any +framebuffer can be connected to any overlay. + +An overlay can be connected to one overlay manager. Also DISPC overlays can be +connected only to DISPC overlay managers, and virtual overlays can be only +connected to virtual overlays. + +An overlay manager can be connected to one display. There are certain +restrictions which kinds of displays an overlay manager can be connected: + +- DISPC TV overlay manager can be only connected to TV display. +- Virtual overlay managers can only be connected to DBI or DSI displays. +- DISPC LCD overlay manager can be connected to all displays, except TV + display. + +Sysfs +- +The sysfs interface is a hack, but works for testing. I don't think sysfs +interface is the best for this in the final version, but I don't quite know +what would be the best interfaces for these things. + +In /sys/devices/platform/omapfb we have four files: framebuffers, +overlays, managers and displays. You can read them so see the current +setup, and change them by writing to it in the form of +" : :..." + +"framebuffers" lists all framebuffers. Its format is: + + p: + v:
[PATCH 04/12] DSS: VENC support
Signed-off-by: Tomi Valkeinen
---
arch/arm/plat-omap/dss/venc.c | 506 +
1 files changed, 506 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/dss/venc.c
diff --git a/arch/arm/plat-omap/dss/venc.c b/arch/arm/plat-omap/dss/venc.c
new file mode 100644
index 000..81319e4
--- /dev/null
+++ b/arch/arm/plat-omap/dss/venc.c
@@ -0,0 +1,506 @@
+/*
+ * linux/arch/arm/plat-omap/dss/venc.c
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * VENC settings from TI's DSS driver
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define DSS_SUBSYS_NAME "VENC"
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "dss.h"
+
+#define VENC_BASE 0x48050C00
+
+/* Venc registers */
+#define VENC_REV_ID0x00
+#define VENC_STATUS0x04
+#define VENC_F_CONTROL 0x08
+#define VENC_VIDOUT_CTRL 0x10
+#define VENC_SYNC_CTRL 0x14
+#define VENC_LLEN 0x1C
+#define VENC_FLENS 0x20
+#define VENC_HFLTR_CTRL0x24
+#define VENC_CC_CARR_WSS_CARR 0x28
+#define VENC_C_PHASE 0x2C
+#define VENC_GAIN_U0x30
+#define VENC_GAIN_V0x34
+#define VENC_GAIN_Y0x38
+#define VENC_BLACK_LEVEL 0x3C
+#define VENC_BLANK_LEVEL 0x40
+#define VENC_X_COLOR 0x44
+#define VENC_M_CONTROL 0x48
+#define VENC_BSTAMP_WSS_DATA 0x4C
+#define VENC_S_CARR0x50
+#define VENC_LINE210x54
+#define VENC_LN_SEL0x58
+#define VENC_L21__WC_CTL 0x5C
+#define VENC_HTRIGGER_VTRIGGER 0x60
+#define VENC_SAVID__EAVID 0x64
+#define VENC_FLEN__FAL 0x68
+#define VENC_LAL__PHASE_RESET 0x6C
+#define VENC_HS_INT_START_STOP_X 0x70
+#define VENC_HS_EXT_START_STOP_X 0x74
+#define VENC_VS_INT_START_X0x78
+#define VENC_VS_INT_STOP_X__VS_INT_START_Y 0x7C
+#define VENC_VS_INT_STOP_Y__VS_EXT_START_X 0x80
+#define VENC_VS_EXT_STOP_X__VS_EXT_START_Y 0x84
+#define VENC_VS_EXT_STOP_Y 0x88
+#define VENC_AVID_START_STOP_X 0x90
+#define VENC_AVID_START_STOP_Y 0x94
+#define VENC_FID_INT_START_X__FID_INT_START_Y 0xA0
+#define VENC_FID_INT_OFFSET_Y__FID_EXT_START_X 0xA4
+#define VENC_FID_EXT_START_Y__FID_EXT_OFFSET_Y 0xA8
+#define VENC_TVDETGP_INT_START_STOP_X 0xB0
+#define VENC_TVDETGP_INT_START_STOP_Y 0xB4
+#define VENC_GEN_CTRL 0xB8
+#define VENC_OUTPUT_CONTROL0xC4
+#define VENC_DAC_B__DAC_C 0xC8
+
+struct venc_config {
+ u32 f_control;
+ u32 vidout_ctrl;
+ u32 sync_ctrl;
+ u32 llen;
+ u32 flens;
+ u32 hfltr_ctrl;
+ u32 cc_carr_wss_carr;
+ u32 c_phase;
+ u32 gain_u;
+ u32 gain_v;
+ u32 gain_y;
+ u32 black_level;
+ u32 blank_level;
+ u32 x_color;
+ u32 m_control;
+ u32 bstamp_wss_data;
+ u32 s_carr;
+ u32 line21;
+ u32 ln_sel;
+ u32 l21__wc_ctl;
+ u32 htrigger_vtrigger;
+ u32 savid__eavid;
+ u32 flen__fal;
+ u32 lal__phase_reset;
+ u32 hs_int_start_stop_x;
+ u32 hs_ext_start_stop_x;
+ u32 vs_int_start_x;
+ u32 vs_int_stop_x__vs_int_start_y;
+ u32 vs_int_stop_y__vs_ext_start_x;
+ u32 vs_ext_stop_x__vs_ext_start_y;
+ u32 vs_ext_stop_y;
+ u32 avid_start_stop_x;
+ u32 avid_start_stop_y;
+ u32 fid_int_start_x__fid_int_start_y;
+ u32 fid_int_offset_y__fid_ext_start_x;
+ u32 fid_ext_start_y__fid_ext_offset_y;
+ u32 tvdetgp_int_start_stop_x;
+ u32 tvdetgp_int_start_stop_y;
+ u32 gen_ctrl;
+
+ int width;
+ int height;
+};
+
+/* from TRM */
+static const struct venc_config venc_config_pal_trm = {
+ .f_control
[PATCH 07/12] DSS: Add generic DVI panel
You also need DSI PLL to generate pix clock for 1280x1024.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/Kconfig |5 ++
drivers/video/omap2/Makefile|2 +
drivers/video/omap2/panel-generic.c | 97 +++
3 files changed, 104 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/panel-generic.c
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index 8be51a3..be00882 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -37,6 +37,11 @@ config FB_OMAP2_NUM_FBS
menu "OMAP2/3 Display Device Drivers"
depends on OMAP2_DSS
+config PANEL_GENERIC
+tristate "Generic Panel"
+help
+ Generic panel driver.
+ Used for DVI output for Beagle and OMAP3 SDP.
endmenu
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index 51c2e00..f471a2b 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_FB_OMAP2) += omapfb.o
omapfb-y := omapfb-main.o omapfb-sysfs.o omapfb-ioctl.o
+
+obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
diff --git a/drivers/video/omap2/panel-generic.c
b/drivers/video/omap2/panel-generic.c
new file mode 100644
index 000..5c8fecd
--- /dev/null
+++ b/drivers/video/omap2/panel-generic.c
@@ -0,0 +1,97 @@
+/*
+ * Generic panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include
+#include
+
+#include
+
+static int generic_panel_init(struct omap_display *display)
+{
+ return 0;
+}
+
+static int generic_panel_enable(struct omap_display *display)
+{
+ int r = 0;
+
+ if (display->hw_config.panel_enable)
+ r = display->hw_config.panel_enable(display);
+
+ return r;
+}
+
+static void generic_panel_disable(struct omap_display *display)
+{
+ if (display->hw_config.panel_disable)
+ display->hw_config.panel_disable(display);
+}
+
+static int generic_panel_suspend(struct omap_display *display)
+{
+ generic_panel_disable(display);
+ return 0;
+}
+
+static int generic_panel_resume(struct omap_display *display)
+{
+ return generic_panel_enable(display);
+}
+
+static struct omap_panel generic_panel = {
+ .owner = THIS_MODULE,
+ .name = "panel-generic",
+ .init = generic_panel_init,
+ .enable = generic_panel_enable,
+ .disable= generic_panel_disable,
+ .suspend= generic_panel_suspend,
+ .resume = generic_panel_resume,
+
+ .timings = {
+ /* 640 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = 640,
+ .y_res = 480,
+ .pixel_clock= 23500,
+ .hfp= 48,
+ .hsw= 32,
+ .hbp= 80,
+ .vfp= 3,
+ .vsw= 4,
+ .vbp= 7,
+ },
+
+ .bpp= 24,
+ .config = OMAP_DSS_LCD_TFT,
+};
+
+
+static int __init generic_panel_drv_init(void)
+{
+ omap_dss_register_panel(&generic_panel);
+ return 0;
+}
+
+static void __exit generic_panel_drv_exit(void)
+{
+ omap_dss_unregister_panel(&generic_panel);
+}
+
+module_init(generic_panel_drv_init);
+module_exit(generic_panel_drv_exit);
+MODULE_LICENSE("GPL");
--
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 03/12] DSS: RFBI support
Signed-off-by: Tomi Valkeinen
---
arch/arm/plat-omap/dss/rfbi.c | 1262 +
1 files changed, 1262 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/dss/rfbi.c
diff --git a/arch/arm/plat-omap/dss/rfbi.c b/arch/arm/plat-omap/dss/rfbi.c
new file mode 100644
index 000..b4b65e6
--- /dev/null
+++ b/arch/arm/plat-omap/dss/rfbi.c
@@ -0,0 +1,1262 @@
+/*
+ * linux/arch/arm/plat-omap/dss/rfbi.c
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * Some code and ideas taken from drivers/video/omap/ driver
+ * by Imre Deak.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define DSS_SUBSYS_NAME "RFBI"
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include "dss.h"
+
+/*#define MEASURE_PERF*/
+
+#define RFBI_BASE 0x48050800
+
+struct rfbi_reg { u16 idx; };
+
+#define RFBI_REG(idx) ((const struct rfbi_reg) { idx })
+
+#define RFBI_REVISION RFBI_REG(0x)
+#define RFBI_SYSCONFIG RFBI_REG(0x0010)
+#define RFBI_SYSSTATUS RFBI_REG(0x0014)
+#define RFBI_CONTROL RFBI_REG(0x0040)
+#define RFBI_PIXEL_CNT RFBI_REG(0x0044)
+#define RFBI_LINE_NUMBER RFBI_REG(0x0048)
+#define RFBI_CMD RFBI_REG(0x004c)
+#define RFBI_PARAM RFBI_REG(0x0050)
+#define RFBI_DATA RFBI_REG(0x0054)
+#define RFBI_READ RFBI_REG(0x0058)
+#define RFBI_STATUSRFBI_REG(0x005c)
+
+#define RFBI_CONFIG(n) RFBI_REG(0x0060 + (n)*0x18)
+#define RFBI_ONOFF_TIME(n) RFBI_REG(0x0064 + (n)*0x18)
+#define RFBI_CYCLE_TIME(n) RFBI_REG(0x0068 + (n)*0x18)
+#define RFBI_DATA_CYCLE1(n)RFBI_REG(0x006c + (n)*0x18)
+#define RFBI_DATA_CYCLE2(n)RFBI_REG(0x0070 + (n)*0x18)
+#define RFBI_DATA_CYCLE3(n)RFBI_REG(0x0074 + (n)*0x18)
+
+#define RFBI_VSYNC_WIDTH RFBI_REG(0x0090)
+#define RFBI_HSYNC_WIDTH RFBI_REG(0x0094)
+
+#define RFBI_CMD_FIFO_LEN_BYTES (16 * sizeof(struct update_param))
+
+#define REG_FLD_MOD(idx, val, start, end) \
+ rfbi_write_reg(idx, FLD_MOD(rfbi_read_reg(idx), val, start, end))
+
+/* To work around an RFBI transfer rate limitation */
+#define OMAP_RFBI_RATE_LIMIT1
+
+enum omap_rfbi_cycleformat {
+ OMAP_DSS_RFBI_CYCLEFORMAT_1_1 = 0,
+ OMAP_DSS_RFBI_CYCLEFORMAT_2_1 = 1,
+ OMAP_DSS_RFBI_CYCLEFORMAT_3_1 = 2,
+ OMAP_DSS_RFBI_CYCLEFORMAT_3_2 = 3,
+};
+
+enum omap_rfbi_datatype {
+ OMAP_DSS_RFBI_DATATYPE_12 = 0,
+ OMAP_DSS_RFBI_DATATYPE_16 = 1,
+ OMAP_DSS_RFBI_DATATYPE_18 = 2,
+ OMAP_DSS_RFBI_DATATYPE_24 = 3,
+};
+
+enum omap_rfbi_parallelmode {
+ OMAP_DSS_RFBI_PARALLELMODE_8 = 0,
+ OMAP_DSS_RFBI_PARALLELMODE_9 = 1,
+ OMAP_DSS_RFBI_PARALLELMODE_12 = 2,
+ OMAP_DSS_RFBI_PARALLELMODE_16 = 3,
+};
+
+enum update_cmd {
+ RFBI_CMD_UPDATE = 0,
+ RFBI_CMD_SYNC = 1,
+};
+
+static int rfbi_convert_timings(struct rfbi_timings *t);
+static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
+static void process_cmd_fifo(void);
+
+static struct {
+ void __iomem*base;
+
+ unsigned long l4_khz;
+
+ enum omap_rfbi_datatype datatype;
+ enum omap_rfbi_parallelmode parallelmode;
+
+ enum omap_rfbi_te_mode te_mode;
+ int te_enabled;
+
+ void (*framedone_callback)(void *data);
+ void *framedone_callback_data;
+
+ struct omap_display *display[2];
+
+ struct kfifo *cmd_fifo;
+ spinlock_tcmd_lock;
+ struct completion cmd_done;
+ atomic_t cmd_fifo_full;
+ atomic_t cmd_pending;
+#ifdef MEASURE_PERF
+ unsigned perf_bytes;
+ ktime_t perf_setup_time;
+ ktime_t perf_start_time;
+#endif
+} rfbi;
+
+struct update_region {
+ u16 x;
+ u16 y;
+ u16 w;
+ u16 h;
+};
+
+struct update_param {
+ u8 rfbi_module;
+ u8 cmd;
+
+ union {
+ struct update_region r;
+ struct completion *sync;
+ } par;
+};
+
+static inline void rfbi_write_reg(const struct rfbi_reg idx, u32 val)
+{
+ __raw_writel(val, rfbi.base + idx.idx);
+}
+
+static inline u32 rfbi_read_reg(const struct rfbi_reg idx)
+{
+ return __raw_readl(rfbi.base + idx.idx);
+}
+
+static void rfbi_enable_clocks
[PATCH 10/12] DSS: Support for OMAP3 SDP board
Signed-off-by: Tomi Valkeinen --- arch/arm/configs/dss_omap_3430sdp_defconfig | 1603 +++ arch/arm/mach-omap2/board-3430sdp.c | 215 +++- 2 files changed, 1809 insertions(+), 9 deletions(-) create mode 100644 arch/arm/configs/dss_omap_3430sdp_defconfig diff --git a/arch/arm/configs/dss_omap_3430sdp_defconfig b/arch/arm/configs/dss_omap_3430sdp_defconfig new file mode 100644 index 000..42d7f5e --- /dev/null +++ b/arch/arm/configs/dss_omap_3430sdp_defconfig @@ -0,0 +1,1603 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.28-omap1 +# Wed Jan 7 15:22:34 2009 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_MMU=y +# CONFIG_NO_IOPORT is not set +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_COMPAT_BRK=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_KMOD=y +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" +CONFIG_CLASSIC_RCU=y +CONFIG_FREEZER=y + +# +# System Type +# +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS7500 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_IMX is not set +# CONFIG_ARCH_IOP13XX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP4XX is not set +# CONFIG_ARCH_L7200 is not set +# CONFIG_ARCH_KIRKWOOD is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_LOKI is not set +# CONFIG_ARCH_MV78XX0 is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_PNX4008 is not set +# CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_RPC is not set +# CONFIG_ARCH_SA1100 is not set +# CONFIG_ARCH_S3C2410 is not set +# CONFIG_ARCH_SHARK is not set +# CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_DAVINCI is not set +CONFIG_ARCH_OMAP=y +# CONFIG_ARCH_MSM is not set + +# +# TI OMAP Implementations +# +CONFIG_ARCH_OMAP_OTG=y +# CONF
[PATCH 09/12] DSS: Sharp LS037V7DW01 LCD Panel driver
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/Kconfig |7 +-
drivers/video/omap2/Makefile |1
drivers/video/omap2/panel-sharp-ls037v7dw01.c | 109 +
3 files changed, 116 insertions(+), 1 deletions(-)
create mode 100644 drivers/video/omap2/panel-sharp-ls037v7dw01.c
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index be00882..b54c955 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -43,5 +43,10 @@ config PANEL_GENERIC
Generic panel driver.
Used for DVI output for Beagle and OMAP3 SDP.
-endmenu
+config PANEL_SHARP_LS037V7DW01
+tristate "Sharp LS037V7DW01 LCD Panel"
+depends on OMAP2_DSS
+help
+ LCD Panel used in TI's SDP3430 and EVM boards
+endmenu
diff --git a/drivers/video/omap2/Makefile b/drivers/video/omap2/Makefile
index f471a2b..fe6858e 100644
--- a/drivers/video/omap2/Makefile
+++ b/drivers/video/omap2/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_FB_OMAP2) += omapfb.o
omapfb-y := omapfb-main.o omapfb-sysfs.o omapfb-ioctl.o
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
+obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
diff --git a/drivers/video/omap2/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/panel-sharp-ls037v7dw01.c
new file mode 100644
index 000..7d67b6d
--- /dev/null
+++ b/drivers/video/omap2/panel-sharp-ls037v7dw01.c
@@ -0,0 +1,109 @@
+/*
+ * LCD panel driver for Sharp LS037V7DW01
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include
+#include
+
+#include
+
+static int sharp_ls_panel_init(struct omap_display *display)
+{
+ return 0;
+}
+
+static void sharp_ls_panel_cleanup(struct omap_display *display)
+{
+}
+
+static int sharp_ls_panel_enable(struct omap_display *display)
+{
+ int r = 0;
+
+ if (display->hw_config.panel_enable)
+ r = display->hw_config.panel_enable(display);
+
+ return r;
+}
+
+static void sharp_ls_panel_disable(struct omap_display *display)
+{
+ if (display->hw_config.panel_disable)
+ display->hw_config.panel_disable(display);
+}
+
+static int sharp_ls_panel_suspend(struct omap_display *display)
+{
+ sharp_ls_panel_disable(display);
+ return 0;
+}
+
+static int sharp_ls_panel_resume(struct omap_display *display)
+{
+ return sharp_ls_panel_enable(display);
+}
+
+static struct omap_panel sharp_ls_panel = {
+ .owner = THIS_MODULE,
+ .name = "sharp-ls037v7dw01",
+ .init = sharp_ls_panel_init,
+ .cleanup= sharp_ls_panel_cleanup,
+ .enable = sharp_ls_panel_enable,
+ .disable= sharp_ls_panel_disable,
+ .suspend= sharp_ls_panel_suspend,
+ .resume = sharp_ls_panel_resume,
+ /*.set_mode = sharp_ls_set_mode, */
+
+ .timings = {
+ .x_res = 480,
+ .y_res = 640,
+
+ .pixel_clock= 19200,
+
+ .hsw= 2,
+ .hfp= 1,
+ .hbp= 28,
+
+ .vsw= 1,
+ .vfp= 1,
+ .vbp= 1,
+ },
+
+ .acb= 0x28,
+
+ .config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+ OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IPC,
+
+ .bpp = 16,
+};
+
+
+static int __init sharp_ls_panel_drv_init(void)
+{
+ omap_dss_register_panel(&sharp_ls_panel);
+ return 0;
+}
+
+static void __exit sharp_ls_panel_drv_exit(void)
+{
+ omap_dss_unregister_panel(&sharp_ls_panel);
+}
+
+module_init(sharp_ls_panel_drv_init);
+module_exit(sharp_ls_panel_drv_exit);
+MODULE_LICENSE("GPL");
--
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 11/12] DSS: Support for OMAP3 EVM board
Coded by Vaibhav Hiremath
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/board-omap3evm.c | 203 +-
1 files changed, 196 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index e4e60e2..e7ec9e6 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include "sdram-micron-mt46h32m32lf-6.h"
#include "twl4030-generic-scripts.h"
@@ -160,13 +161,201 @@ static int __init omap3_evm_i2c_init(void)
return 0;
}
-static struct platform_device omap3_evm_lcd_device = {
- .name = "omap3evm_lcd",
- .id = -1,
+#define LCD_PANEL_LR 2
+#define LCD_PANEL_UD 3
+#define LCD_PANEL_INI 152
+#define LCD_PANEL_ENABLE_GPIO 153
+#define LCD_PANEL_QVGA 154
+#define LCD_PANEL_RESB 155
+
+#define ENABLE_VDAC_DEDICATED 0x03
+#define ENABLE_VDAC_DEV_GRP0x20
+#define ENABLE_VPLL2_DEDICATED 0x05
+#define ENABLE_VPLL2_DEV_GRP 0xE0
+
+#define TWL4030_GPIODATA_IN3 0x03
+#define TWL4030_GPIODATA_DIR3 0x06
+#define TWL4030_VPLL2_DEV_GRP 0x33
+#define TWL4030_VPLL2_DEDICATED0x36
+
+static int lcd_enabled;
+static int dvi_enabled;
+
+static void __init omap3_evm_display_init(void)
+{
+ int r;
+ r = gpio_request(LCD_PANEL_LR, "lcd_panel_lr");
+ if (r) {
+ printk(KERN_ERR "failed to get LCD_PANEL_LR\n");
+ return;
+ }
+ r = gpio_request(LCD_PANEL_UD, "lcd_panel_ud");
+ if (r) {
+ printk(KERN_ERR "failed to get LCD_PANEL_UD\n");
+ goto err_1;
+ }
+
+ r = gpio_request(LCD_PANEL_INI, "lcd_panel_ini");
+ if (r) {
+ printk(KERN_ERR "failed to get LCD_PANEL_INI\n");
+ goto err_2;
+ }
+ r = gpio_request(LCD_PANEL_RESB, "lcd_panel_resb");
+ if (r) {
+ printk(KERN_ERR "failed to get LCD_PANEL_RESB\n");
+ goto err_3;
+ }
+ r = gpio_request(LCD_PANEL_QVGA, "lcd_panel_qvga");
+ if (r) {
+ printk(KERN_ERR "failed to get LCD_PANEL_QVGA\n");
+ goto err_4;
+ }
+
+ gpio_direction_output(LCD_PANEL_LR, 0);
+ gpio_direction_output(LCD_PANEL_UD, 0);
+ gpio_direction_output(LCD_PANEL_INI, 0);
+ gpio_direction_output(LCD_PANEL_RESB, 0);
+ gpio_direction_output(LCD_PANEL_QVGA, 0);
+
+#define TWL_LED_LEDEN 0x00
+#define TWL_PWMA_PWMAON 0x00
+#define TWL_PWMA_PWMAOFF0x01
+
+ twl4030_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_LEDEN);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, 0x01, TWL_PWMA_PWMAON);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, 0x02, TWL_PWMA_PWMAOFF);
+
+ gpio_direction_output(LCD_PANEL_RESB, 1);
+ gpio_direction_output(LCD_PANEL_INI, 1);
+ gpio_direction_output(LCD_PANEL_QVGA, 0);
+ gpio_direction_output(LCD_PANEL_LR, 1);
+ gpio_direction_output(LCD_PANEL_UD, 1);
+
+ return;
+
+err_4:
+ gpio_free(LCD_PANEL_RESB);
+err_3:
+ gpio_free(LCD_PANEL_INI);
+err_2:
+ gpio_free(LCD_PANEL_UD);
+err_1:
+ gpio_free(LCD_PANEL_LR);
+
+}
+
+static int omap3_evm_panel_enable_lcd(struct omap_display *display)
+{
+ if (dvi_enabled) {
+ printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
+ return -EINVAL;
+ }
+ if (omap_rev() > OMAP3430_REV_ES1_0) {
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ ENABLE_VPLL2_DEDICATED, TWL4030_VPLL2_DEDICATED);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ ENABLE_VPLL2_DEV_GRP, TWL4030_VPLL2_DEV_GRP);
+ }
+ gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+ lcd_enabled = 1;
+ return 0;
+}
+
+static void omap3_evm_panel_disable_lcd(struct omap_display *display)
+{
+ if (omap_rev() > OMAP3430_REV_ES1_0) {
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x0,
+ TWL4030_VPLL2_DEDICATED);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, 0x0,
+ TWL4030_VPLL2_DEV_GRP);
+ }
+ gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 1);
+ lcd_enabled = 0;
+}
+
+static struct omap_display_data omap3_evm_display_data = {
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .name = "lcd",
+ .panel_name = "sharp-ls037v7dw01",
+ .u.dpi.data_lines = 18,
+ .panel_enable = omap3_evm_panel_enable_lcd,
+ .panel_disable = omap3_evm_panel_disable_lcd,
};
-static struct omap_lcd_config omap3_evm_lcd_config __initdata =
[PATCH 08/12] DSS: support for Beagle Board
Signed-off-by: Tomi Valkeinen --- arch/arm/configs/dss_omap3_beagle_defconfig | 1437 +++ arch/arm/mach-omap2/board-omap3beagle.c | 101 ++ 2 files changed, 1524 insertions(+), 14 deletions(-) create mode 100644 arch/arm/configs/dss_omap3_beagle_defconfig diff --git a/arch/arm/configs/dss_omap3_beagle_defconfig b/arch/arm/configs/dss_omap3_beagle_defconfig new file mode 100644 index 000..f39167f --- /dev/null +++ b/arch/arm/configs/dss_omap3_beagle_defconfig @@ -0,0 +1,1437 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.28-omap1 +# Wed Jan 7 15:22:00 2009 +# +CONFIG_ARM=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_GENERIC_GPIO=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_MMU=y +# CONFIG_NO_IOPORT is not set +CONFIG_GENERIC_HARDIRQS=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_VECTORS_BASE=0x +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_COMPAT_BRK=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_AIO=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_CLK=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_KMOD=y +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" +CONFIG_CLASSIC_RCU=y +# CONFIG_FREEZER is not set + +# +# System Type +# +# CONFIG_ARCH_AAEC2000 is not set +# CONFIG_ARCH_INTEGRATOR is not set +# CONFIG_ARCH_REALVIEW is not set +# CONFIG_ARCH_VERSATILE is not set +# CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_CLPS7500 is not set +# CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_EBSA110 is not set +# CONFIG_ARCH_EP93XX is not set +# CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_NETX is not set +# CONFIG_ARCH_H720X is not set +# CONFIG_ARCH_IMX is not set +# CONFIG_ARCH_IOP13XX is not set +# CONFIG_ARCH_IOP32X is not set +# CONFIG_ARCH_IOP33X is not set +# CONFIG_ARCH_IXP23XX is not set +# CONFIG_ARCH_IXP2000 is not set +# CONFIG_ARCH_IXP4XX is not set +# CONFIG_ARCH_L7200 is not set +# CONFIG_ARCH_KIRKWOOD is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_LOKI is not set +# CONFIG_ARCH_MV78XX0 is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_PNX4008 is not set +# CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_RPC is not set +# CONFIG_ARCH_SA1100 is not set +# CONFIG_ARCH_S3C2410 is not set +# CONFIG_ARCH_SHARK is not set +# CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_DAVINCI is not set +CONFIG_ARCH_OMAP=y +# CONFIG_ARCH_MSM is not set + +# +# TI OMAP Implementations +# +CONFIG_ARCH_OMAP_OTG=y +# CONF
[PATCH 12/12] DSS: Hacked N810 support
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/board-n800.c| 214 ++---
drivers/video/omap2/Kconfig | 10 +
drivers/video/omap2/Makefile|3
drivers/video/omap2/ctrl-blizzard.c | 279 ++
drivers/video/omap2/panel-n800.c| 437 +++
5 files changed, 905 insertions(+), 38 deletions(-)
create mode 100644 drivers/video/omap2/ctrl-blizzard.c
create mode 100644 drivers/video/omap2/panel-n800.c
diff --git a/arch/arm/mach-omap2/board-n800.c b/arch/arm/mach-omap2/board-n800.c
index b38b295..ffa5aad 100644
--- a/arch/arm/mach-omap2/board-n800.c
+++ b/arch/arm/mach-omap2/board-n800.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include <../drivers/cbus/tahvo.h>
#include <../drivers/media/video/tcm825x.h>
@@ -156,23 +157,175 @@ static struct omap_uart_config n800_uart_config
__initdata = {
#include "../../../drivers/cbus/retu.h"
-static struct omap_fbmem_config n800_fbmem0_config __initdata = {
- .size = 752 * 1024,
+static struct omap_tmp105_config n800_tmp105_config __initdata = {
+ .tmp105_irq_pin = 125,
+ .set_power = n800_tmp105_set_power,
};
-static struct omap_fbmem_config n800_fbmem1_config __initdata = {
- .size = 752 * 1024,
-};
-static struct omap_fbmem_config n800_fbmem2_config __initdata = {
- .size = 752 * 1024,
+
+
+/* DISPLAY */
+static struct {
+ struct clk *sys_ck;
+} blizzard;
+
+static int blizzard_get_clocks(void)
+{
+ blizzard.sys_ck = clk_get(0, "osc_ck");
+ if (IS_ERR(blizzard.sys_ck)) {
+ printk(KERN_ERR "can't get Blizzard clock\n");
+ return PTR_ERR(blizzard.sys_ck);
+ }
+ return 0;
+}
+
+static unsigned long blizzard_get_clock_rate(void)
+{
+ return clk_get_rate(blizzard.sys_ck);
+}
+
+static int n800_pn800_enable(struct omap_display *display)
+{
+ if (display->hw_config.panel_reset_gpio != -1) {
+ printk("enabling panel gpio\n");
+ gpio_direction_output(display->hw_config.panel_reset_gpio, 1);
+ }
+
+ return 0;
+}
+
+static void n800_pn800_disable(struct omap_display *display)
+{
+ if (display->hw_config.panel_reset_gpio != -1) {
+ printk("disabling panel gpio\n");
+ gpio_direction_output(display->hw_config.panel_reset_gpio, 0);
+ msleep(120);
+ }
+}
+
+static int n800_blizzard_enable(struct omap_display *display)
+{
+ printk("enabling bliz powers\n");
+
+ /* Vcore to 1.475V */
+ tahvo_set_clear_reg_bits(0x07, 0, 0xf);
+ msleep(10);
+
+ clk_enable(blizzard.sys_ck);
+
+ if (display->hw_config.ctrl_reset_gpio != -1)
+ gpio_direction_output(display->hw_config.ctrl_reset_gpio, 1);
+
+ printk("osc_ck %lu\n", blizzard_get_clock_rate());
+
+ return 0;
+}
+
+static void n800_blizzard_disable(struct omap_display *display)
+{
+ printk("disabling bliz powers\n");
+
+ if (display->hw_config.ctrl_reset_gpio != -1)
+ gpio_direction_output(display->hw_config.ctrl_reset_gpio, 0);
+
+ clk_disable(blizzard.sys_ck);
+
+ /* Vcore to 1.005V */
+ tahvo_set_clear_reg_bits(0x07, 0xf, 0);
+}
+
+static int n800_set_backlight_level(struct omap_display *display, int level)
+{
+ return 0;
+}
+
+static struct omap_display_data n800_dsi_display_data = {
+ .type = OMAP_DISPLAY_TYPE_DBI,
+ .name = "lcd",
+ .ctrl_name = "ctrl-blizzard",
+ .panel_name = "panel-pn800",
+ .panel_reset_gpio = -1,
+ .ctrl_reset_gpio = N800_BLIZZARD_POWERDOWN_GPIO,
+ .panel_enable = n800_pn800_enable,
+ .panel_disable = n800_pn800_disable,
+ .ctrl_enable = n800_blizzard_enable,
+ .ctrl_disable = n800_blizzard_disable,
+ .set_backlight = n800_set_backlight_level,
+ .u.rfbi = {
+ .channel = 0,
+ /* 8 for cmd mode, 16 for pixel data. ctrl-blizzard handles
switching */
+ .data_lines = 8,
+ },
+ .priv = 0, // XXX used for panel datalines
+};
+static struct omap_dss_platform_data n800_dss_data = {
+ .num_displays = 1,
+ .displays = {
+ &n800_dsi_display_data,
+ },
};
-static struct omap_tmp105_config n800_tmp105_config __initdata = {
- .tmp105_irq_pin = 125,
- .set_power = n800_tmp105_set_power,
+static struct platform_device n800_dss_device = {
+ .name = "omap-dss",
+ .id= -1,
+ .dev= {
+ .platform_data = &n800_dss_data,
+ },
};
+static void __init n800_display_init(void)
+{
+ int r;
+ const struct omap_lcd_config *conf;
+
+ conf = omap_get_config(OMAP_TAG_LCD, struct omap_lcd_confi
Re: [PATCH 08/12] DSS: support for Beagle Board
On Tue, 2009-01-13 at 03:14 -0800, ext David Brownell wrote: > On Monday 12 January 2009, Tomi Valkeinen wrote: > > arch/arm/configs/dss_omap3_beagle_defconfig | 1437 > > +++ > > This is a complete replacement. The patch would be a lot > more comprehensible if changed the standard config to just > add support for this board's video options (DVI and S-Video). The dss_* defconfigs were actually just for my own use. I seem to have forgotten them there. Well, they can serve as examples though. > > Also it'd be good to have a brief textual summary of what > each board's default video config is; maybe one of those > little multicolumn charts as in your first patch, with a > one sentence summary. (In the board-*.c file.) Well, perhaps. But on the other hand, there are no descriptions of other hardware components either. But I agree that, at least for the time being, we could have description of the boards display interfaces to make validation and review easier. > Note that after this merges, some work will be needed to > make the regulator framework handle the power switching. > Such logic should move out of board files (except for > setting up "S-Video is supplied using the twl VDAC"). > It's not quite time for that yet; heads-up, that's all. > > - Dave > Tomi -- 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
ioremap()/iounmap() problem
Hi,
Running with latest linux-omap kernel on OMAP3 SDP board, I have problem
with iounmap(). It looks like iounmap() does not properly free large
areas. Below is a test which fails for me in 6-7 loops.
OMAP spesific ioremap code doesn't do much, so I think it's somewhere in
generic ARM code. I looked at the ioremap code and for larger areas the
code uses area sections, and I believe the bug is somewhere there.
Does this work on other processors?
Tomi
#include
#include
static int test_init(void)
{
const unsigned long paddr = 0x7000;
const unsigned long size = 2048 * 2048 * 4;
void *vaddr;
int i;
for (i = 0; i < 200; ++i) {
vaddr = ioremap(paddr, size);
if (!vaddr) {
printk("couldn't ioremap\n");
break;
}
printk("ioremapped to %p\n", vaddr);
iounmap(vaddr);
}
return 0;
}
static void test_exit(void) { }
module_init(test_init);
module_exit(test_exit);
--
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: ioremap()/iounmap() problem
Hi, On Mon, 2009-01-19 at 11:01 +, ext Russell King - ARM Linux wrote: > On Mon, Jan 19, 2009 at 12:23:03PM +0200, Tomi Valkeinen wrote: > > Hi, > > > > Running with latest linux-omap kernel on OMAP3 SDP board, I have problem > > with iounmap(). It looks like iounmap() does not properly free large > > areas. Below is a test which fails for me in 6-7 loops. > > > > OMAP spesific ioremap code doesn't do much, so I think it's somewhere in > > generic ARM code. I looked at the ioremap code and for larger areas the > > code uses area sections, and I believe the bug is somewhere there. > > In unmap_area_sections(), try changing: > > unsigned long addr = virt, end = virt + (size & ~SZ_1M); > > to > > unsigned long addr = virt, end = virt + (size & ~(SZ_1M - 1)); This didn't help. I Added two debug prints, not sure if it means anything but the size on the second unmap is not the same as in the previous ones. remap_area_sections(virt=d200, size=100, end=d300, pfn=7) unmap_area_sections(virt=d200, size=100, end=d300) ioremapped to d200 unmap_area_sections(virt=d200, size=1001000, end=d300) Tomi -- 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: ioremap()/iounmap() problem
On Mon, 2009-01-19 at 12:53 +, ext Russell King - ARM Linux wrote: > On Mon, Jan 19, 2009 at 02:27:34PM +0200, Tomi Valkeinen wrote: > > On Mon, 2009-01-19 at 11:01 +, ext Russell King - ARM Linux wrote: > > > On Mon, Jan 19, 2009 at 12:23:03PM +0200, Tomi Valkeinen wrote: > > > > Hi, > > > > > > > > Running with latest linux-omap kernel on OMAP3 SDP board, I have problem > > > > with iounmap(). It looks like iounmap() does not properly free large > > > > areas. Below is a test which fails for me in 6-7 loops. > > > > > > > > OMAP spesific ioremap code doesn't do much, so I think it's somewhere in > > > > generic ARM code. I looked at the ioremap code and for larger areas the > > > > code uses area sections, and I believe the bug is somewhere there. > > > > > > In unmap_area_sections(), try changing: > > > > > > unsigned long addr = virt, end = virt + (size & ~SZ_1M); > > > > > > to > > > > > > unsigned long addr = virt, end = virt + (size & ~(SZ_1M - 1)); > > > > This didn't help. I Added two debug prints, not sure if it means > > anything but the size on the second unmap is not the same as in the > > previous ones. > > If you read the comments on unmap_area_sections, you'd understand why > this is. > > > remap_area_sections(virt=d200, size=100, end=d300, pfn=7) > > unmap_area_sections(virt=d200, size=100, end=d300) > > ioremapped to d200 > > unmap_area_sections(virt=d200, size=1001000, end=d300) > > Yes, so changing that line results in 'end' being the correct 0x100 > bytes greater than 'virt', as can be seen from the above. Before this > change, end would've been 0xd3001000 which is incorrect. > > Now, if there's something else wrong, please be more expansive about it. > Please given an exact description of the failure you're seeing. (I'm > not going to be able to try your test program for several days.) The original problem remains, it looks to me that iounmap() doesn't free the memory, and thus ioremap will fail after couple of loops. I get the following error on console: vmap allocation for size 16781312 failed: use vmalloc= to increase size. I don't know too much about memory management, but I'll try to dig deeper in to this. What I don't understand is that in __arm_ioremap_pfn() there's get_vm_area(), and later in the function, in case of error, that area is vunmap()ed. But there's no vunmap() done anywhere else in the code for area sections, so who does free it? Tomi -- 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: ioremap()/iounmap() problem
Hi, On Wed, 2009-01-21 at 19:23 +, ext Russell King - ARM Linux wrote: > On Mon, Jan 19, 2009 at 03:49:40PM +0200, Tomi Valkeinen wrote: > > The original problem remains, it looks to me that iounmap() doesn't free > > the memory, and thus ioremap will fail after couple of loops. > > > > I get the following error on console: > > > > vmap allocation for size 16781312 failed: use vmalloc= to increase > > size. > > > > I don't know too much about memory management, but I'll try to dig > > deeper in to this. > > > > What I don't understand is that in __arm_ioremap_pfn() there's > > get_vm_area(), and later in the function, in case of error, that area is > > vunmap()ed. But there's no vunmap() done anywhere else in the code for > > area sections, so who does free it? > > Yes, the error I pointed out is not the only issue with this code. > > You might consider trying my patch which was sent in this thread to Matt > Gerassimoff. And if you see anyone whinging that it won't work for > whatever reason, please ignore them and just test the patch. You will > not be disappointed. Sorry it took so long to test. The patch indeed works fine, thanks! And the test loop works also fine even without any schedulings, contrary of what was speculated. (Not that it matters in real usage). I'll do some more testing and report if I see any oddities. Tomi -- 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] The clockdomain of clkout2_src_ck fixed
The clockdomain of clkout2_src_ck was set to "core_clkdm", which does not
exist.
---
arch/arm/mach-omap2/clock34xx.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index d7d6ffd..3504e48 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1010,7 +1010,7 @@ static struct clk clkout2_src_ck = {
.clksel_mask= OMAP3430_CLKOUT2SOURCE_MASK,
.clksel = clkout2_src_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES,
- .clkdm = { .name = "core_clkdm" },
+ .clkdm = { .name = "core_l4_clkdm" },
.recalc = &omap2_clksel_recalc,
};
--
1.5.4.3
--
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
[PATCH] The clockdomain of clkout2_src_ck fixed
The clockdomain of clkout2_src_ck was set to "core_clkdm", which does not
exist.
Signed-off-by: Tomi Valkeinen <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clock34xx.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index 5d855e9..8da0097 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1010,7 +1010,7 @@ static struct clk clkout2_src_ck = {
.clksel_mask= OMAP3430_CLKOUT2SOURCE_MASK,
.clksel = clkout2_src_clksel,
.flags = CLOCK_IN_OMAP343X | RATE_PROPAGATES,
- .clkdm = { .name = "core_clkdm" },
+ .clkdm = { .name = "core_l4_clkdm" },
.recalc = &omap2_clksel_recalc,
};
--
1.6.0.1
--
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
Re: [PREVIEW] New display subsystem for OMAP2/3
On Mon, 2008-09-15 at 20:27 +0100, ext Måns Rullgård wrote: > Tomi Valkeinen <[EMAIL PROTECTED]> writes: > > > On Sat, 2008-09-13 at 22:47 +0100, ext Måns Rullgård wrote: > >> Koen Kooi <[EMAIL PROTECTED]> writes: > > > >> What I don't like about the patch posted is its size. I'm sure the > >> transition could be done in a sequence of smaller patches. At the > >> very least, it should be possible to move existing functionality to > >> the new architecture, then add the new parts afterwards. I also see > >> little value in keeping the old model around, as is done in the patch. > > > > I don't like the size either. However, I have no idea how the old driver > > could be transformed to include this functionality with a reasonable > > effort. The implementations are quite different. > > > > Any suggestions how I could approach this task? Only thing that comes to > > my mind is that there are very similar low level functions in both DSS1 > > and DSS2 (for dispc and rfbi), that I could remove from the old place > > and move to arch/arm/plat-omap/dss/, but that doesn't take us very far. > > Are the patches you posted your latest version of the code? Do you > have this code in a public git repo? I'd like to take a closer look > at what you've done. They are not the very latest, but they are recent enough. Unfortunately I don't have them on a public git. Nokia is still a bit lacking in that area =). They should apply to linux-omap kernel from last Thursday (I think the commit id is mentioned in the series file). Tomi -- 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
[PREVIEW 2] New display subsystem for OMAP2/3
Hi, I sent a preview of a new display subsystem for OMAP2/3 some time ago: http://marc.info/?l=linux-omap&m=122114505030542&w=2 I now have updated it, the patches are at the same place: http://www.bat.org/~tomba/omap-dss/ What's new -- As was pointed out in the feedback, my version was not enough to fully utilize OMAP's DISPC. I did a bit of a rewrite and I now model the overlays and overlay managers. This conveniently allows multiple display configurations, and it also solved some other problems I had previously. The code is still bit of a mess after this change. The tv-out and DVI are also now working on OMAP3 SDP board, and you can switch between, and combine, LCD, TV-out and DVI outputs. The current interface for this is a couple of hackish sysfs files. The Kconfig is also a bit more versatile, you can leave out the parts of the DSS that you don't need. Overlays Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI and TV-out are not in use. The columns from left to right are: framebuffers, overlays, overlay managers, displays. Framebuffers are handled by omapfb, and the rest by the DSS. FB0 --- GFX -\DVI FB1 --- VID1 --+- LCD LCD FB2 --- VID2 -/ TV - TV In the examples below we use DVI and TV so that the setup changes to the following: FB0 --- GFX -\ -- DVI FB1 --- VID1 --+- LCD -/ LCD FB2 --- VID2 TV - TV It is also possible to setup a virtual overlay & overlay manager, which can be used with displays that can be updated with CPU/sDMA. For example: FB3 --- VOVL VMGR You can also change the overlay to which a framebuffer is connected. With this we can, for example, change fb0 from DISPC overlay to virtual overlay while X is running on the framebuffer. This way X doesn't notice anything, but DISPC is free for other displays. And, although not implemented yet, one framebuffer can be connected to multiple overlays. This will allow cloning of a framebuffer to multiple outputs. Sysfs - The sysfs interface is a hack, but works for testing. And I don't think sysfs interface is the best for this in the final version. In /sys/devices/platform/omapfb we have four files: framebuffers, overlays, managers and displays. You can read them so see the current setup, and change it by writing "arg1:arg2" to it. So changing framebuffer 0 to point to vid1 overlay would require writing "0:vid1" to framebuffers file. Examples In these examples I have symlink omapfb -> /sys/devices/platform/omapfb # VIDEO2 plane to TV out echo "vid2:" > omapfb/overlays # (1) fbset -fb /dev/fb2 -xres 720 -pw 720 -yres 482 -ph 482 -pe 1 # (2) echo "vid2:tv" > omapfb/overlays # (3) echo "tv:1" > omapfb/displays # (4) 1. Detach vid2 overlay. Otherwise the DSS will reject the fbset, as the asked resolution is larger than the LCD's resolution. 2. Set x/y res, and enable plane 3. Attach vid2 to tv overlay manager. 4. Enable tv display # Use DVI instead of LCD echo "lcd:0" > omapfb/displays # (1) echo "lcd:" > omapfb/managers # (2) # switch the dvi/lcd dip-switch# (3) fbset -fb /dev/fb0 -xres 800 -pw 800 -yres 600 -ph 600 -pe 1 # (4) echo "lcd:dvi" > omapfb/managers # (5) echo "dvi:1" > omapfb/displays # (6) 1. Disable LCD display. We have to disable LCD before we can enable DVI 2. Detach LCD overlay manager 3. Here you have to set the DIP switch to DVI position 4. Set the new resolution 5. Attach LCD overlay manager to DVI display 6. Enable DVI display Tomi -- 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
Re: [PREVIEW 2] New display subsystem for OMAP2/3
Hi, On Mon, 2008-09-22 at 18:10 +0300, ext Tony Lindgren wrote: > Hi, > > * Tomi Valkeinen <[EMAIL PROTECTED]> [080922 17:49]: > > Hi, > > > > I sent a preview of a new display subsystem for OMAP2/3 some time ago: > > http://marc.info/?l=linux-omap&m=122114505030542&w=2 > > > > I now have updated it, the patches are at the same place: > > http://www.bat.org/~tomba/omap-dss/ > > This discussion should go to linux-fbdev-devel list. Please keep l-o > list Cc'd though. Also you should post the patches as a proper inline > series, please see git-send-email man page. > Ok, I'll move it to linux-fbdev-devel. I didn't post the patches inline, as they are quite big (250k+). I thought there was a "rule" to put big patches to some public place, not to mail them. What is the proper procedure for this work? Discuss and review the patches on fbdevel, and mail to l-o when finalized? Or go directly to Linus' tree? Tomi -- 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
RE: [PREVIEW] New display subsystem for OMAP2/3
Hi Vaibhav, On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav wrote: > Tomi, > > Have you got a chance to review the DSS library and V4l2 driver which we have > posted? Unfortunately not very much. I've been glancing the DSS side of the driver, but not the v4l side as I don't know much about it. There seems to be awfully lot ifdefs for board/cpu types in the code. Also there are strange things defined, like L4_VIRT My biased and superficial view of the differences between my DSS and yours is that: - My implementation is cleaner, better organized and more generic - My implementation has support for DSI, SDI, RFBI, L4 updates - Your implementation has better support for "extra" things like VRFB, color conversions, alpha etc. - Your implementation most likely has better power management support. - And of course what is most visible to the user, my version uses only framebuffers, and yours uses also v4l2 devices. As for the future, I have no choice but to keep using my DSS as we need the features it has. I feel it would be quite a big job to get those in to your driver. And even if I had a choice, I (unsurprisingly =) think that my version is better and would stick to it. Have you had time to look at my code after I changed the overlay handling? I've put the most recent version to a public git tree at http://www.bat.org/~tomba/git/linux-omap-dss.git/ and I'll try to keep that up to date. Tomi > > Thanks, > Vaibhav Hiremath > Senior Software Engg. > Platform Support Products > Texas Instruments Inc > Ph: +91-80-25099927 > > > -Original Message- > > From: Hiremath, Vaibhav > > Sent: Monday, September 15, 2008 9:51 PM > > To: 'Tomi Valkeinen' > > Cc: Shah, Hardik; linux-omap@vger.kernel.org; [EMAIL PROTECTED] > > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3 > > > > > > > > Thanks, > > Vaibhav Hiremath > > Senior Software Engg. > > Platform Support Products > > Texas Instruments Inc > > Ph: +91-80-25099927 > > TI IP Ph: 509-9927 > > http://dbdwss01.india.ti.com/pspproducts/ > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomi > > > Valkeinen > > > Sent: Monday, September 15, 2008 8:08 PM > > > To: Hiremath, Vaibhav > > > Cc: Shah, Hardik; linux-omap@vger.kernel.org; [EMAIL PROTECTED] > > > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3 > > > > > > On Mon, 2008-09-15 at 19:02 +0530, ext Hiremath, Vaibhav wrote: > > > > > > > We more concentrated on TV and LCD interface, out design doesn't > > > > support DSI as of now. As > > > mentioned earlier it is easily extendible to support DSI. > > > > > > > > If I understand your implementation correctly, right now there is no > > > > way you can switch the > > > outputs, I mean to say from LCD to DVI. The frame buffer driver gets the > > > handle with API > > > omap_dss_get_display, which will return pointer to omap_display for > > > panel-sdp3430. Henceforth all > > > your functions will use omap_display configuring for LCD panel. How are > > > you planning to add support > > > for this? Through some ioctls or sysfs entry? How about switching between > > > multiple overlay > > managers? > > > > > > You can switch the outputs in the DSS driver. You can enable/disable > > > displays individually, and configure the planes and or L4 pixel source > > > for the display. > > > > > > But yes, the fb driver does not support that currently. > > > > > > One idea I had was to present each display with one framebuffer, so > > > let's say we have 3 displays, we would have fb[0-2]. In addition to > > > that, we would have two framebuffers for the video overlays. Only one of > > > the displays can be updated with DISPC, so the overlays would appear > > > there. > > > > > > Then the display that is updated with DISPC could be changed on the fly > > > to another one, but the framebuffer arrangement would stay the same (so > > > fb0 would still be seen on display0, even if it's now updated with L4). > > > > > > There's still the question how to manage the video overlays, in this > > > scenario they would automatically move to other LCD's as the DISPC > > > target is changed. Also the TV-out is problematic. > > > > > > > This issue has been addresses with our design, you can change the > > > > output either to TV, LCD or to &g
RE: [PREVIEW] New display subsystem for OMAP2/3
Hi, > > -Original Message- > > From: Tomi Valkeinen [mailto:[EMAIL PROTECTED] > > Sent: Thursday, October 02, 2008 1:55 PM > > To: Hiremath, Vaibhav > > Cc: Shah, Hardik; linux-omap@vger.kernel.org; [EMAIL PROTECTED] > > Subject: RE: [PREVIEW] New display subsystem for OMAP2/3 > > > > Hi Vaibhav, > > > > On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav wrote: > > > Tomi, > > > > > > Have you got a chance to review the DSS library and V4l2 driver which we > > > have posted? > > > > Unfortunately not very much. I've been glancing the DSS side of the > > driver, but not the v4l side as I don't know much about it. > > > > There seems to be awfully lot ifdefs for board/cpu types in the code. > > As far as ifdefs are concerned, they are added to take care of OMAP2/3 > variants. Especially you will find many instances of CONFIG_ARCH_OMAP3410 and > the reason is obvious, OMAP3410 doesn't have VENC. As I have mentioned > before, DSS library is designed to support both LCD, TV, and many more. They make the code unclear. I have divided the functionality to separate files, that can easily be left out. So for OMAP3410 I would just disable the VENC config option. And then I can test for CONFIG_DSS_VENC, instead of OMAP3410 || OMAP2410 || OMAPwhatnot. Of course you can't do this for all things, but at least VENC is not one of these. And all board specific code should, in my opinion, be in board files. I don't have any board specific definitions in the DSS driver or the LCD/controller drivers. (well, ok, there is something in the DSI driver, it's still quite raw). > > My biased and superficial view of the differences between my DSS and > > yours is that: > > Tomi, here I differ from you. There should not be biased opinion. What we are > looking here is a good design which will fulfill all our requirements/use > case, like LCD, DVI, HDMI and TV for us and DSI, RFBI for you. Agreed. I was just pointing out that I haven't used enough time to study your DSS to really comment on it, and that a coder tends to like his own code =). > > - My implementation is cleaner, better organized and more generic > > Again, here both of us will be having biased comments to support our own > design, so I would prefer not to comment on this. Lets people on the > community decide whose design is better. > > > - My implementation has support for DSI, SDI, RFBI, L4 updates > > DSI, SDI and RFBI are the modes, which we can add anytime to the system > depending as per our requirement. > It is again driven by use case; you have use cases for DSI, SDI and RFBI. We > have for TV, DVI, HDMI and LCD, so we strongly concentrated on these. > > We can very well add these supports to DSS Library with minimal effort. SDI is quite easy, but I wouldn't say adding RFBI and DSI is minimal effort. DSI is quite complex in itself, and the manual update mode changes how the DSS has to handle things. > > - Your implementation has better support for "extra" things like VRFB, > > color conversions, alpha etc. > > - Your implementation most likely has better power management support. > > - And of course what is most visible to the user, my version uses only > > framebuffers, and yours uses also v4l2 devices. > > > > You really can't deny the V4L2 framework advantages over framebuffer, > especially for streaming kind of applications. Looking towards the hardware > features OMAP supports; we would really require to have such > support/capabilities. Community is also in agreement for the V4L2 interface > on OMAP-DSS. Well, I'm not the best one to comment on V4L2 as I don't know much about it. But I remember seeing quite negative comments about V4L2 a while ago in this or related mail thread, so I'm not yet ready to change to V4L2 camp. The best option would be, of course, to have both =). > Tony/Hans, > Your comments would be helpful here. > > > As for the future, I have no choice but to keep using my DSS as we need > > the features it has. I feel it would be quite a big job to get those in > > to your driver. And even if I had a choice, I (unsurprisingly =) think > > that my version is better and would stick to it. > > > > It's your personal choice to stick to whichever code base you want, I don't > want to comment on that. But what I believe is, with your design we are > limiting ourselves from supporting most of the features which hardware > provides. Is the limiting factor here the missing V4L2 interface? Or something in the core DSS driver? To my knowledge you can have all the HW features supported with frame
Re: [PREVIEW] New display subsystem for OMAP2/3
Hi, On Fri, 2008-10-03 at 16:03 +0200, ext Hans Verkuil wrote: > Hi Vaibhav, > > Hmm, this is getting quite confusing for me :-) > > If I understand it correctly, TI posted two patches while I was on > vacation: one for the DSS library and one for the V4L2 driver. I > quickly looked at the DSS library patch, but I cannot really comment on > that one as it is very omap specific, so as far as I am concerned it is > pretty much up to TI to decide how to set this up. If I understand it > correctly the DSS 'library' basically provides v4l2/fb drivers with the > low-level platform functionality those drivers need. So I'm not sure > whether 'library' is really the right term here. 'DSS platform code' is > more appropriate. > > I definitely have questions regarding the V4L2 driver, but I'll reply to > that patch separately. > > I also understand that there is an alternative DSS implementation from > Tomi? But I can't seem to find any link to that code. A link to the > code would be appreciated. I've only sent it to linux-omap list for now. I'm planning to send it to fbdev-devel list sometime in the near future. Here are my mails: http://marc.info/?l=linux-omap&m=122114505030542&w=2 and http://marc.info/?l=linux-omap&m=122209502314197&w=2 The link to the implementation is a bit old, since then I've set up a public repo at http://www.bat.org/~tomba/git/linux-omap-dss.git/ But most of that code is also very omap specific =). > Regarding v4l2 vs fb: the normal way such things are implemented is that > the V4L2 API is used for video streaming while the FB API is used to > interface to displays and/or menu overlays. The FB API is a natural fit > for graphics applications like X and Qt, whereas the V4L2 API is meant > to handle video streaming in an efficient manner and with correct > timings. You can be creative and use a FB device to stream video or a > V4L2 device for graphics/overlay output, but you only make it hard on > yourself and the application writers. That has been my understanding. OMAP has three overlays (gfx, vid1, vid2) but I wouldn't want to dedicate vid1/2 overlays to V4L2 devices, because often you want to use them the same way as the gfx overlay, and framebuffer fits that better (for example, having a UI on the LCD and TV-out at the same time). So if and when I add V4L2 support, I'd like the choice between FB and V4L2 to be configurable per overlay. Perhaps just compile time configuration, but still. > Regards, > > Hans Tomi > On Friday 03 October 2008 14:47:23 Hiremath, Vaibhav wrote: > > Hi Tomi, > > > > Thanks, > > Vaibhav Hiremath > > Senior Software Engg. > > Platform Support Products > > Texas Instruments Inc > > Ph: +91-80-25099927 > > > > > -Original Message- > > > From: Tomi Valkeinen [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, October 02, 2008 1:55 PM > > > To: Hiremath, Vaibhav > > > Cc: Shah, Hardik; linux-omap@vger.kernel.org; > > > [EMAIL PROTECTED] Subject: RE: [PREVIEW] New display > > > subsystem for OMAP2/3 > > > > > > Hi Vaibhav, > > > > > > On Wed, 2008-10-01 at 16:21 +0530, ext Hiremath, Vaibhav wrote: > > > > Tomi, > > > > > > > > Have you got a chance to review the DSS library and V4l2 driver > > > > which we have posted? > > > > > > Unfortunately not very much. I've been glancing the DSS side of the > > > driver, but not the v4l side as I don't know much about it. > > > > > > There seems to be awfully lot ifdefs for board/cpu types in the > > > code. > > > > As far as ifdefs are concerned, they are added to take care of > > OMAP2/3 variants. Especially you will find many instances of > > CONFIG_ARCH_OMAP3410 and the reason is obvious, OMAP3410 doesn't have > > VENC. As I have mentioned before, DSS library is designed to support > > both LCD, TV, and many more. > > > > > Also there are strange things defined, like L4_VIRT > > > > You are right; the code requires little-bit cleaning. There are some > > macros defined which driver or library doesn't use. We are in the > > process of cleaning and soon will be posting patches. > > > > > My biased and superficial view of the differences between my DSS > > > and yours is that: > > > > Tomi, here I differ from you. There should not be biased opinion. > > What we are looking here is a good design which will fulfill all our > > requirements/use case, like LCD, DVI, HDMI and TV for us and DSI, > > RFBI for
dpll4_ck rate broken
Hi, With latest linux-omap kernel, the dpll4_ck rate is a bit funny: ~ # cat /debug/clock/virt_26m_ck/osc_sys_ck/sys_ck/rate 1300 ~ # cat /debug/clock/virt_26m_ck/osc_sys_ck/sys_ck/dpll4_ck/rate 3224773576 ~ # cat /debug/clock/virt_26m_ck/osc_sys_ck/sys_ck/dpll4_ck/dpll4_m4_ck/rate 4800 I've tested this on OMAP3 SDP board and one other board. Tomi -- 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
Re: dpll4_ck rate broken
On Fri, 2008-10-17 at 14:08 +0300, ext Tomi Valkeinen wrote: > Hi, > > With latest linux-omap kernel, the dpll4_ck rate is a bit funny: > > ~ # cat /debug/clock/virt_26m_ck/osc_sys_ck/sys_ck/rate > 1300 > > ~ # cat /debug/clock/virt_26m_ck/osc_sys_ck/sys_ck/dpll4_ck/rate > 3224773576 > The reason seems to be in arch/arm/mach-omap2/clock34xx.c: omap3_noncore_dpll_enable(). It sets the dpll4_ck rate to the value of an unassigned local variable 'rate'. Tomi -- 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
Re: [PATCH] video: omap2: dss: RET on idle, enable/disable dss clocks only when needed.
On Wed, 2009-09-23 at 17:44 +0200, ext Kevin Hilman wrote: > Tomi Valkeinen writes: > > > On Tue, 2009-09-22 at 16:54 +0200, ext Kevin Hilman wrote: > >> Tomi Valkeinen writes: > >> > >> > Hi, > >> > > >> > On Fri, 2009-09-18 at 19:33 +0200, ext Mike Chan wrote: > >> >> On Fri, Sep 18, 2009 at 1:27 AM, Tomi Valkeinen > >> >> wrote: > >> >> > Hi, > >> >> > > >> >> > If you disable the clocks to allow RET, you also allow OFF mode. And > >> >> > resuming from OFF mode hasn't been implemented for DSI, if I recall > >> >> > right. And when I was testing it, it didn't seem to be trivial with > >> >> > the > >> >> > DSI PLL. > >> >> > > >> >> > >> >> You can limiting the pwrdm next state to RET when being called from > >> >> cpuidle. > >> > > >> > No, you _must_ limit it to RET. Otherwise the DSI will break down. So we > >> > can either keep the dsi code as it is now, or explicitely disable OFF > >> > mode and then apply your patch. But your patch alone won't work. > >> > >> Or could add a hack to this patch so that 'enable_off_mode' doesn't > >> affect DSS_MOD until DSS has off-mode support. > > > > Is this something that the driver can do with the current PM API? The > > thing is, most of the DSS has off-mode support, only DSI and RFBI is > > missing the support. So optimally we would allow full PM normally, but > > when DSI display is in use, only allow RET. > > There's not an official API for this, but for testing, you could just > set the next state for the DSS_MOD to be off. This would be overridden > whenever someone changes the enable_off_mode flag. > > In general, we don't want drivers restricting states at that level. > We'd rather the drivers use the OMAP PM layer to define/declare its > constraints. If I want to disable OFF mode for DSS with constraints, doesn't it mean that I need to dig out a magic number, and use it as the max wakeup latency, and that latency will then limit DSS from going to OFF mode? > > >> > >> > In the long run I think we anyway need to somehow dynamically manage the > >> > power state. I haven't measured it but I believe resuming from OFF will > >> > have a bit of a penalty, as (I think) DSI PLL etc. will have to > >> > reinitialized. But it would still be good to allow RET whenever > >> > possible, and OFF only after some period of inactivity. > >> > >> This is the purpose of latency constraints. These can be used when > >> the latency of going OFF will cause a problem. > > > > I think this is a different problem. My understanding of the PM latency > > functionality is that they control how quickly MPU responds to > > interrupts, or how quickly the HW module is awake after clk_enable(). > > That's only part of the story. > > > The problem here is that there's bunch of DSI initialization that needs > > to be done after the DSS module has woken up. The DSI PLL needs to be > > configured and locked, complex IO has to be configured etc. I don't know > > how long those take (should make some measurements at some point), but I > > imagine they are not anywhere near instant. And the latency from those > > things is what I'm concerned about. So it would be beneficial if the DSS > > driver could define easily what DSS PM level is allowed. > > Actually, the OMAP PM layer is meant to handle device wakeup latencies > as well. See Documentation/arm/OMAP/omap_pm, and the > set_max_dev_wakeup_lat() hook in particular. > > For example, if you know that DSS wakeup from OFF takes X usecs and > the driver has set a max device wakeup latency < X, then DSS will > never go to OFF. The same can be done to prevent RET for even faster > wakeup. The doc says "set_max_dev_wakeup_lat() function to constrain the device wakeup latency (from clk_enable() to accessibility)". I understood "accessibility" meaning that the HW registers can be accessed, and also as registers should be accessible after clk_enable(), it would mean that clk_enable will block at most the defined wakeup latency. If it is not like that, and the driver initialization is included, how does the PM layer know how long it takes for the DSS driver to reconfigure the DSS hardware from OFF mode? Tomi -- 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 01/19] OMAP2: Add funcs for writing SMS_ROT_* registers
SMS_ROT_* registers are used by VRFB rotation engine.
Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
Acked-by: Paul Walmsley
---
arch/arm/mach-omap2/sdrc.c | 16
arch/arm/plat-omap/include/mach/sdrc.h |9 -
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index 9e3bd4f..6a5a2c5 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -133,3 +133,19 @@ void __init omap2_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
(1 << SDRC_POWER_PAGEPOLICY_SHIFT);
sdrc_write_reg(l, SDRC_POWER);
}
+
+void omap2_sms_write_rot_control(u32 val, unsigned ctx)
+{
+ sms_write_reg(val, SMS_ROT_CONTROL(ctx));
+}
+
+void omap2_sms_write_rot_size(u32 val, unsigned ctx)
+{
+ sms_write_reg(val, SMS_ROT_SIZE(ctx));
+}
+
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
+{
+ sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx));
+}
+
diff --git a/arch/arm/plat-omap/include/mach/sdrc.h
b/arch/arm/plat-omap/include/mach/sdrc.h
index 1c09c78..3b157ce 100644
--- a/arch/arm/plat-omap/include/mach/sdrc.h
+++ b/arch/arm/plat-omap/include/mach/sdrc.h
@@ -88,7 +88,10 @@
/* SMS register offsets - read/write with sms_{read,write}_reg() */
-#define SMS_SYSCONFIG 0x010
+#define SMS_SYSCONFIG 0x010
+#define SMS_ROT_CONTROL(context) (0x180 + 0x10 * context)
+#define SMS_ROT_SIZE(context) (0x184 + 0x10 * context)
+#define SMS_ROT_PHYSICAL_BA(context) (0x188 + 0x10 * context)
/* REVISIT: fill in other SMS registers here */
@@ -121,6 +124,10 @@ int omap2_sdrc_get_params(unsigned long r,
struct omap_sdrc_params **sdrc_cs0,
struct omap_sdrc_params **sdrc_cs1);
+void omap2_sms_write_rot_control(u32 val, unsigned ctx);
+void omap2_sms_write_rot_size(u32 val, unsigned ctx);
+void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
+
#ifdef CONFIG_ARCH_OMAP2
struct memory_timings {
--
1.6.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 02/19] OMAP: OMAPFB: split omapfb.h
Split arch/arm/plat-omap/include/mach/omapfb.h into two files:
include/linux/omapfb.h - ioctls etc for userspace and some kernel
stuff for board files
drivers/video/omap/omapfb.h - for omapfb internal use
This cleans up omapfb.h and also makes it easier for the upcoming new
DSS driver to co-exist with the old driver.
Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
---
arch/arm/mach-omap1/board-nokia770.c |2 +-
arch/arm/mach-omap2/io.c |2 +-
arch/arm/plat-omap/fb.c |2 +-
arch/arm/plat-omap/include/mach/omapfb.h | 398 --
drivers/video/omap/blizzard.c|2 +-
drivers/video/omap/dispc.c |2 +-
drivers/video/omap/hwa742.c |2 +-
drivers/video/omap/lcd_2430sdp.c |3 +-
drivers/video/omap/lcd_ams_delta.c |3 +-
drivers/video/omap/lcd_apollon.c |3 +-
drivers/video/omap/lcd_h3.c |2 +-
drivers/video/omap/lcd_h4.c |2 +-
drivers/video/omap/lcd_inn1510.c |2 +-
drivers/video/omap/lcd_inn1610.c |2 +-
drivers/video/omap/lcd_ldp.c |3 +-
drivers/video/omap/lcd_mipid.c |3 +-
drivers/video/omap/lcd_omap2evm.c|3 +-
drivers/video/omap/lcd_omap3beagle.c |3 +-
drivers/video/omap/lcd_omap3evm.c|3 +-
drivers/video/omap/lcd_osk.c |2 +-
drivers/video/omap/lcd_overo.c |3 +-
drivers/video/omap/lcd_palmte.c |2 +-
drivers/video/omap/lcd_palmtt.c |2 +-
drivers/video/omap/lcd_palmz71.c |2 +-
drivers/video/omap/lcdc.c|3 +-
drivers/video/omap/omapfb.h | 227 +
drivers/video/omap/omapfb_main.c |2 +-
drivers/video/omap/rfbi.c|3 +-
drivers/video/omap/sossi.c |2 +-
include/linux/omapfb.h | 197 +++
30 files changed, 461 insertions(+), 426 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/mach/omapfb.h
create mode 100644 drivers/video/omap/omapfb.h
create mode 100644 include/linux/omapfb.h
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index ed2a48a..6fbde33 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -32,7 +33,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 7574b6f..4a08ad3 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -22,13 +22,13 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index 3746222..40615a6 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -28,13 +28,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
-#include
#if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE)
diff --git a/arch/arm/plat-omap/include/mach/omapfb.h
b/arch/arm/plat-omap/include/mach/omapfb.h
deleted file mode 100644
index b226bdf..000
--- a/arch/arm/plat-omap/include/mach/omapfb.h
+++ /dev/null
@@ -1,398 +0,0 @@
-/*
- * File: arch/arm/plat-omap/include/mach/omapfb.h
- *
- * Framebuffer driver for TI OMAP boards
- *
- * Copyright (C) 2004 Nokia Corporation
- * Author: Imre Deak
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __OMAPFB_H
-#define __OMAPFB_H
-
-#include
-#include
-
-/* IOCTL commands. */
-
-#define OMAP_IOW(num, dtype) _IOW('O', num, dtype)
-#define OMAP_IOR(num, dtype) _IOR('O', num, dtype)
-#define OMAP_IOWR(num, dtype) _IOWR('O', num, dtype)
-#define OMAP_IO(num) _IO('O', num)
-
-#define OMAPFB_MIRROR OMAP_IOW(31, int)
-#define OMAPFB_SYNC_GFXOMAP_IO(37)
-#define OMAPFB_VSYNC OMAP_IO(38)
-#define OMAPFB_SET_UPDATE_MODE OMAP_IOW(40, int)
-#define OMAPFB_GET_CAPSO
[PATCH 04/19] OMAP: Add VRAM manager
Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:
- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocations
The upcoming DSS2 uses VRAM manager.
VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/io.c |2 +
arch/arm/plat-omap/include/mach/vram.h | 63 +++
arch/arm/plat-omap/sram.c |8 +
drivers/video/Kconfig |1 +
drivers/video/Makefile |1 +
drivers/video/omap2/Kconfig|2 +
drivers/video/omap2/Makefile |1 +
drivers/video/omap2/vram.c | 655
8 files changed, 733 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/mach/vram.h
create mode 100644 drivers/video/omap2/Kconfig
create mode 100644 drivers/video/omap2/Makefile
create mode 100644 drivers/video/omap2/vram.c
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4a08ad3..e5dd736 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once clkdev is ready */
#include "clock.h"
@@ -246,6 +247,7 @@ void __init omap2_map_common_io(void)
omap2_check_revision();
omap_sram_init();
omapfb_reserve_sdram();
+ omap_vram_reserve_sdram();
}
/*
diff --git a/arch/arm/plat-omap/include/mach/vram.h
b/arch/arm/plat-omap/include/mach/vram.h
new file mode 100644
index 000..fe72f81
--- /dev/null
+++ b/arch/arm/plat-omap/include/mach/vram.h
@@ -0,0 +1,63 @@
+/*
+ * VRAM manager for OMAP
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#ifndef __OMAP_VRAM_H__
+#define __OMAP_VRAM_H__
+
+#include
+#include
+
+#define OMAP_VRAM_MEMTYPE_SDRAM0
+#define OMAP_VRAM_MEMTYPE_SRAM 1
+#define OMAP_VRAM_MEMTYPE_MAX 1
+
+extern int omap_vram_add_region(unsigned long paddr, size_t size);
+extern int omap_vram_free(unsigned long paddr, size_t size);
+extern int omap_vram_alloc(int mtype, size_t size, unsigned long *paddr);
+extern int omap_vram_reserve(unsigned long paddr, size_t size);
+extern void omap_vram_get_info(unsigned long *vram, unsigned long *free_vram,
+ unsigned long *largest_free_block);
+
+#ifdef CONFIG_OMAP2_VRAM
+extern void omap_vram_set_sdram_vram(u32 size, u32 start);
+extern void omap_vram_set_sram_vram(u32 size, u32 start);
+
+extern void omap_vram_reserve_sdram(void);
+extern unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned long sram_size,
+ unsigned long pstart_avail,
+ unsigned long size_avail);
+#else
+static inline void omap_vram_set_sdram_vram(u32 size, u32 start) { }
+static inline void omap_vram_set_sram_vram(u32 size, u32 start) { }
+
+static inline void omap_vram_reserve_sdram(void) { }
+static inline unsigned long omap_vram_reserve_sram(unsigned long sram_pstart,
+ unsigned long sram_vstart,
+ unsigned long sram_size,
+ unsigned long pstart_avail,
+ unsigned long size_avail)
+{
+ return 0;
+}
+#endif
+
+#endif
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 925f647..cda311b 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
@@ -185,6 +186,13 @@ void __init omap_detect_sram(void)
omap_sram_start + SRA
[PATCH 10/19] OMAP: DSS2: DPI driver
This implements MIPI DPI interface.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c | 388 +
1 files changed, 388 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/dpi.c
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
new file mode 100644
index 000..b6543c8
--- /dev/null
+++ b/drivers/video/omap2/dss/dpi.c
@@ -0,0 +1,388 @@
+/*
+ * linux/drivers/video/omap2/dss/dpi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * Some code and ideas taken from drivers/video/omap/ driver
+ * by Imre Deak.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define DSS_SUBSYS_NAME "DPI"
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "dss.h"
+
+static struct {
+ int update_enabled;
+} dpi;
+
+#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
+static int dpi_set_dsi_clk(bool is_tft, unsigned long pck_req,
+ unsigned long *fck, int *lck_div, int *pck_div)
+{
+ struct dsi_clock_info cinfo;
+ int r;
+
+ r = dsi_pll_calc_pck(is_tft, pck_req, &cinfo);
+ if (r)
+ return r;
+
+ r = dsi_pll_program(&cinfo);
+ if (r)
+ return r;
+
+ dss_select_clk_source(0, 1);
+
+ dispc_set_lcd_divisor(cinfo.lck_div, cinfo.pck_div);
+
+ *fck = cinfo.dsi1_pll_fclk;
+ *lck_div = cinfo.lck_div;
+ *pck_div = cinfo.pck_div;
+
+ return 0;
+}
+#else
+static int dpi_set_dispc_clk(bool is_tft, unsigned long pck_req,
+ unsigned long *fck, int *lck_div, int *pck_div)
+{
+ struct dispc_clock_info cinfo;
+ int r;
+
+ r = dispc_calc_clock_div(is_tft, pck_req, &cinfo);
+ if (r)
+ return r;
+
+ r = dispc_set_clock_div(&cinfo);
+ if (r)
+ return r;
+
+ *fck = cinfo.fck;
+ *lck_div = cinfo.lck_div;
+ *pck_div = cinfo.pck_div;
+
+ return 0;
+}
+#endif
+
+static int dpi_set_mode(struct omap_dss_device *dssdev)
+{
+ struct omap_video_timings *t = &dssdev->panel.timings;
+ int lck_div, pck_div;
+ unsigned long fck;
+ unsigned long pck;
+ bool is_tft;
+ int r = 0;
+
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+ dispc_set_pol_freq(dssdev->panel.config, dssdev->panel.acbi,
+ dssdev->panel.acb);
+
+ is_tft = (dssdev->panel.config & OMAP_DSS_LCD_TFT) != 0;
+
+#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
+ r = dpi_set_dsi_clk(is_tft, t->pixel_clock * 1000,
+ &fck, &lck_div, &pck_div);
+#else
+ r = dpi_set_dispc_clk(is_tft, t->pixel_clock * 1000,
+ &fck, &lck_div, &pck_div);
+#endif
+ if (r)
+ goto err0;
+
+ pck = fck / lck_div / pck_div / 1000;
+
+ if (pck != t->pixel_clock) {
+ DSSWARN("Could not find exact pixel clock. "
+ "Requested %d kHz, got %lu kHz\n",
+ t->pixel_clock, pck);
+
+ t->pixel_clock = pck;
+ }
+
+ dispc_set_lcd_timings(t);
+
+err0:
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ return r;
+}
+
+static int dpi_basic_init(struct omap_dss_device *dssdev)
+{
+ bool is_tft;
+
+ is_tft = (dssdev->panel.config & OMAP_DSS_LCD_TFT) != 0;
+
+ dispc_set_parallel_interface_mode(OMAP_DSS_PARALLELMODE_BYPASS);
+ dispc_set_lcd_display_type(is_tft ? OMAP_DSS_LCD_DISPLAY_TFT :
+ OMAP_DSS_LCD_DISPLAY_STN);
+ dispc_set_tft_data_lines(dssdev->phy.dpi.data_lines);
+
+ return 0;
+}
+
+static int dpi_display_enable(struct omap_dss_device *dssdev)
+{
+ int r;
+
+ r = omap_dss_start_device(dssdev);
+ if (r) {
+ DSSERR("failed to start device\n");
+ goto err0;
+ }
+
+ if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED) {
+ DSSERR("display already enabled\n");
+ r = -EINVAL;
+ goto err1;
+ }
+
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+ r = dpi_basic_init(dssdev);
+ if (r)
+ goto err2;
+
+#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
+
[PATCH 13/19] OMAP: DSS2: SDI driver
SDI (Serial Display Interface) implements TI Flatlink 3G display
interface.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/sdi.c | 261 +
1 files changed, 261 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/dss/sdi.c
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
new file mode 100644
index 000..a9c727e
--- /dev/null
+++ b/drivers/video/omap2/dss/sdi.c
@@ -0,0 +1,261 @@
+/*
+ * linux/drivers/video/omap2/dss/sdi.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define DSS_SUBSYS_NAME "SDI"
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include "dss.h"
+
+static struct {
+ bool skip_init;
+ bool update_enabled;
+} sdi;
+
+static void sdi_basic_init(void)
+{
+ dispc_set_parallel_interface_mode(OMAP_DSS_PARALLELMODE_BYPASS);
+
+ dispc_set_lcd_display_type(OMAP_DSS_LCD_DISPLAY_TFT);
+ dispc_set_tft_data_lines(24);
+ dispc_lcd_enable_signal_polarity(1);
+}
+
+static int sdi_display_enable(struct omap_dss_device *dssdev)
+{
+ struct omap_video_timings *t = &dssdev->panel.timings;
+ struct dispc_clock_info cinfo;
+ u16 lck_div, pck_div;
+ unsigned long fck;
+ unsigned long pck;
+ int r;
+
+ r = omap_dss_start_device(dssdev);
+ if (r) {
+ DSSERR("failed to start device\n");
+ goto err0;
+ }
+
+ if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED) {
+ DSSERR("dssdev already enabled\n");
+ r = -EINVAL;
+ goto err1;
+ }
+
+ /* In case of skip_init sdi_init has already enabled the clocks */
+ if (!sdi.skip_init)
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+ sdi_basic_init();
+
+ /* 15.5.9.1.2 */
+ dssdev->panel.config |= OMAP_DSS_LCD_RF | OMAP_DSS_LCD_ONOFF;
+
+ dispc_set_pol_freq(dssdev->panel.config, dssdev->panel.acbi,
+ dssdev->panel.acb);
+
+ if (!sdi.skip_init)
+ r = dispc_calc_clock_div(1, t->pixel_clock * 1000,
+ &cinfo);
+ else
+ r = dispc_get_clock_div(&cinfo);
+
+ if (r)
+ goto err2;
+
+ fck = cinfo.fck;
+ lck_div = cinfo.lck_div;
+ pck_div = cinfo.pck_div;
+
+ pck = fck / lck_div / pck_div / 1000;
+
+ if (pck != t->pixel_clock) {
+ DSSWARN("Could not find exact pixel clock. Requested %d kHz, "
+ "got %lu kHz\n",
+ t->pixel_clock, pck);
+
+ t->pixel_clock = pck;
+ }
+
+
+ dispc_set_lcd_timings(t);
+
+ r = dispc_set_clock_div(&cinfo);
+ if (r)
+ goto err2;
+
+ if (!sdi.skip_init) {
+ dss_sdi_init(dssdev->phy.sdi.datapairs);
+ dss_sdi_enable();
+ mdelay(2);
+ }
+
+ dispc_enable_lcd_out(1);
+
+ if (dssdev->driver->enable) {
+ r = dssdev->driver->enable(dssdev);
+ if (r)
+ goto err3;
+ }
+
+ dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ sdi.skip_init = 0;
+
+ return 0;
+err3:
+ dispc_enable_lcd_out(0);
+err2:
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+err1:
+ omap_dss_stop_device(dssdev);
+err0:
+ return r;
+}
+
+static int sdi_display_resume(struct omap_dss_device *dssdev);
+
+static void sdi_display_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev->state == OMAP_DSS_DISPLAY_DISABLED)
+ return;
+
+ if (dssdev->state == OMAP_DSS_DISPLAY_SUSPENDED)
+ sdi_display_resume(dssdev);
+
+ if (dssdev->driver->disable)
+ dssdev->driver->disable(dssdev);
+
+ dispc_enable_lcd_out(0);
+
+ dss_sdi_disable();
+
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+
+ dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
+
+ omap_dss_stop_device(dssdev);
+}
+
+static int sdi_display_suspend(struct omap_dss_device *dssdev)
+{
+ if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
+ return -EI
[PATCH 19/19] MAINTAINERS: Add OMAP2/3 DSS and OMAPFB maintainer
Signed-off-by: Tomi Valkeinen --- MAINTAINERS | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7c1c0b0..7245dae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3778,6 +3778,23 @@ L: linux-omap@vger.kernel.org S: Maintained F: drivers/video/omap/ +OMAP DISPLAY SUBSYSTEM SUPPORT (DSS2) +M: Tomi Valkeinen +L: linux-fbdev-de...@lists.sourceforge.net (moderated for non-subscribers) +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/video/omap2/dss/ +F: drivers/video/omap2/vrfb.c +F: drivers/video/omap2/vram.c +F: Documentation/arm/OMAP/DSS + +OMAP FRAMEBUFFER SUPPORT (FOR DSS2) +M: Tomi Valkeinen +L: linux-fbdev-de...@lists.sourceforge.net (moderated for non-subscribers) +L: linux-omap@vger.kernel.org +S: Maintained +F: drivers/video/omap2/omapfb/ + OMAP MMC SUPPORT M: Jarkko Lavinen L: linux-omap@vger.kernel.org -- 1.6.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 17/19] OMAP: DSS2: Taal DSI command mode panel driver
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/displays/Kconfig |6 +
drivers/video/omap2/displays/Makefile |2 +
drivers/video/omap2/displays/panel-taal.c | 900 +
3 files changed, 908 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-taal.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 396905d..79d2861 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -19,4 +19,10 @@ config PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
+config PANEL_TAAL
+tristate "Taal DSI Panel"
+depends on OMAP2_DSS_DSI
+help
+ Taal DSI command mode panel from TPO.
+
endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index a26bbd2..d44e765 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,3 +1,5 @@
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C) += panel-samsung-lte430wq-f0c.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
+
+obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
new file mode 100644
index 000..84f0d47
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -0,0 +1,900 @@
+/*
+ * Taal DSI command mode panel
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+/*#define DEBUG*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* DSI Virtual channel. Hardcoded for now. */
+#define TCH 0
+
+#define DCS_READ_NUM_ERRORS0x05
+#define DCS_READ_POWER_MODE0x0a
+#define DCS_READ_MADCTL0x0b
+#define DCS_READ_PIXEL_FORMAT 0x0c
+#define DCS_SLEEP_IN 0x10
+#define DCS_SLEEP_OUT 0x11
+#define DCS_DISPLAY_OFF0x28
+#define DCS_DISPLAY_ON 0x29
+#define DCS_COLUMN_ADDR0x2a
+#define DCS_PAGE_ADDR 0x2b
+#define DCS_MEMORY_WRITE 0x2c
+#define DCS_TEAR_OFF 0x34
+#define DCS_TEAR_ON0x35
+#define DCS_MEM_ACC_CTRL 0x36
+#define DCS_PIXEL_FORMAT 0x3a
+#define DCS_BRIGHTNESS 0x51
+#define DCS_CTRL_DISPLAY 0x53
+#define DCS_WRITE_CABC 0x55
+#define DCS_READ_CABC 0x56
+#define DCS_GET_ID10xda
+#define DCS_GET_ID20xdb
+#define DCS_GET_ID30xdc
+
+struct taal_data {
+ struct backlight_device *bldev;
+
+ unsigned long hw_guard_end; /* next value of jiffies when we can
+* issue the next sleep in/out command
+*/
+ unsigned long hw_guard_wait; /* max guard time in jiffies */
+
+ struct omap_dss_device *dssdev;
+
+ bool enabled;
+ u8 rotate;
+ bool mirror;
+
+ bool te_enabled;
+ bool use_ext_te;
+ struct completion te_completion;
+
+ bool use_dsi_bl;
+
+ bool cabc_broken;
+ unsigned cabc_mode;
+
+ bool intro_printed;
+};
+
+static void hw_guard_start(struct taal_data *td, int guard_msec)
+{
+ td->hw_guard_wait = msecs_to_jiffies(guard_msec);
+ td->hw_guard_end = jiffies + td->hw_guard_wait;
+}
+
+static void hw_guard_wait(struct taal_data *td)
+{
+ unsigned long wait = td->hw_guard_end - jiffies;
+
+ if ((long)wait > 0 && wait <= td->hw_guard_wait) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(wait);
+ }
+}
+
+static int taal_dcs_read_1(u8 dcs_cmd, u8 *data)
+{
+ int r;
+ u8 buf[1];
+
+ r = dsi_vc_dcs_read(TCH, dcs_cmd, buf, 1);
+
+ if (r < 0)
+ return r;
+
+ *data = buf[0];
+
+ return 0;
+}
+
+static int taal_dcs_write_0(u8 dcs_cmd)
+{
+ return dsi_vc_dcs_write(TCH, &dcs_cmd, 1);
+}
+
+static int taal_dcs_write_1(u8 dcs_cmd, u8 param)
+{
+ u8 buf[2];
+ buf[0] = dcs_cmd;
+ buf[1] = param;
+ return dsi_vc_dcs_write(TCH, buf, 2);
+}
+
+static int taal_sleep_in
