* Fwd: dss2 with dsi [not found] <aed62de90904151916h5a218e9bgf3419ea96c3ed262@mail.gmail.com> @ 2009-04-16 2:17 ` Rebecca Schultz Zavin 2009-04-16 9:58 ` Tomi Valkeinen 0 siblings, 1 reply; 4+ messages in thread From: Rebecca Schultz Zavin @ 2009-04-16 2:17 UTC (permalink / raw) To: linux-omap@vger.kernel.org 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. 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. 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? 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. If no one has any thoughts on this I'll just pick something and throw some patches for Tomi's tree up, but I thought it was worth pinging on it. Rebecca -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Fwd: dss2 with dsi 2009-04-16 2:17 ` Fwd: dss2 with dsi Rebecca Schultz Zavin @ 2009-04-16 9:58 ` Tomi Valkeinen 2009-04-16 18:21 ` Rebecca Schultz Zavin 0 siblings, 1 reply; 4+ messages in thread From: Tomi Valkeinen @ 2009-04-16 9:58 UTC (permalink / raw) To: ext Rebecca Schultz Zavin; +Cc: linux-omap@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Fwd: dss2 with dsi 2009-04-16 9:58 ` Tomi Valkeinen @ 2009-04-16 18:21 ` Rebecca Schultz Zavin 2009-04-17 6:44 ` Tomi Valkeinen 0 siblings, 1 reply; 4+ messages in thread From: Rebecca Schultz Zavin @ 2009-04-16 18:21 UTC (permalink / raw) To: tomi.valkeinen; +Cc: linux-omap@vger.kernel.org On Thu, Apr 16, 2009 at 2:58 AM, Tomi Valkeinen <tomi.valkeinen@nokia.com> wrote: > 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 =). I know! I've never met a serial display interface that wasn't a total pain to get going. > >> 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. I'll make this change and send you a patch. > >> >> 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. 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. > >> >> 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? 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_READ1 0x11 #define GENERIC_SHORT_READ2 0x12 #define GENERIC_LONG_READ 0x1a > > Tomi > > > Thanks, Rebecca -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Fwd: dss2 with dsi 2009-04-16 18:21 ` Rebecca Schultz Zavin @ 2009-04-17 6:44 ` Tomi Valkeinen 0 siblings, 0 replies; 4+ messages in thread From: Tomi Valkeinen @ 2009-04-17 6:44 UTC (permalink / raw) To: ext Rebecca Schultz Zavin; +Cc: linux-omap@vger.kernel.org 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_READ1 0x11 > #define GENERIC_SHORT_READ2 0x12 > #define GENERIC_LONG_READ 0x1a 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-04-17 6:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <aed62de90904151916h5a218e9bgf3419ea96c3ed262@mail.gmail.com>
2009-04-16 2:17 ` Fwd: dss2 with dsi Rebecca Schultz Zavin
2009-04-16 9:58 ` Tomi Valkeinen
2009-04-16 18:21 ` Rebecca Schultz Zavin
2009-04-17 6:44 ` Tomi Valkeinen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox