| Message ID | 1345023063.3494.20.camel@deskari (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On 15/08/12 05:31 AM, Tomi Valkeinen wrote: > Hi, > > On Tue, 2012-07-17 at 10:01 -0400, Raphael Assenat wrote: >> Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays. >> > > This needed to be converted to work with latest kernel. See patch below. > I've applied the patch to my dev branch, mail me if it's not correct. > > > commit f4e491f283266b53a926eb3c9017505b04786b9b (HEAD, dev) > Author: Raphael Assenat <raph@8d.com> > Date: Tue Jul 17 10:01:40 2012 -0400 > > OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays > > Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays. > > Signed-off-by: Raphael Assenat <raph@8d.com> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > > diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c > index bc5af25..ae862bb 100644 > --- a/drivers/video/omap2/displays/panel-generic-dpi.c > +++ b/drivers/video/omap2/displays/panel-generic-dpi.c > @@ -538,6 +538,82 @@ static struct panel_config generic_dpi_panels[] = { > }, > .name = "primeview_pd104slf", > }, > + > + /* ChiMei G121S1-L01 */ > + { > + { ... > + .vsync_level = OMAPDSS_SIG_ACTIVE_HIGH, > + .hsync_level = OMAPDSS_SIG_ACTIVE_HIGH, > + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE, > + .de_level = OMAPDSS_SIG_ACTIVE_HIGH, > + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES, Actually those 3 panels only use the DE signal. The hsync/vsync signals are not used and on our system we mux them out to make sure they are kept low as recommended in the panel datasheets. Since vsync/hsync are not used, I think the vsync_level, hsync_level and sync_pclk_edge entries could be removed. Otherwise the updated patch works fine as is. Best regards, Raphaël Assénat -- 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
On Wed, 2012-08-15 at 11:26 -0400, Raphaël Assénat wrote: > > + > > + /* ChiMei G121S1-L01 */ > > + { > > + { > > ... > > > + .vsync_level = OMAPDSS_SIG_ACTIVE_HIGH, > > + .hsync_level = OMAPDSS_SIG_ACTIVE_HIGH, > > + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE, > > + .de_level = OMAPDSS_SIG_ACTIVE_HIGH, > > + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES, > > Actually those 3 panels only use the DE signal. The hsync/vsync signals > are not used and on our system we mux them out to make sure they are > kept low as recommended in the panel datasheets. > > Since vsync/hsync are not used, I think the vsync_level, hsync_level and > sync_pclk_edge entries could be removed. Otherwise the updated patch > works fine as is. Okay. How do panels like that work? How can they know where a new frame starts? Actually, I now googled for those panels, and they are all LVDS panels, not DPI panels. So the patch doesn't look correct at all. Do you have a DPI-to-LVDS converter chip on your board? Tomi
On 21/08/12 06:49 AM, Tomi Valkeinen wrote: > On Wed, 2012-08-15 at 11:26 -0400, Raphaël Assénat wrote: > >>> + >>> + /* ChiMei G121S1-L01 */ >>> + { >>> + { >> >> ... >> >>> + .vsync_level = OMAPDSS_SIG_ACTIVE_HIGH, >>> + .hsync_level = OMAPDSS_SIG_ACTIVE_HIGH, >>> + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE, >>> + .de_level = OMAPDSS_SIG_ACTIVE_HIGH, >>> + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES, >> >> Actually those 3 panels only use the DE signal. The hsync/vsync signals >> are not used and on our system we mux them out to make sure they are >> kept low as recommended in the panel datasheets. >> >> Since vsync/hsync are not used, I think the vsync_level, hsync_level and >> sync_pclk_edge entries could be removed. Otherwise the updated patch >> works fine as is. > > Okay. How do panels like that work? How can they know where a new frame > starts? By DE being inactive for a different number of pixel clock cycles during the vertical and horizontal blanking periods. > Actually, I now googled for those panels, and they are all LVDS panels, > not DPI panels. So the patch doesn't look correct at all. > > Do you have a DPI-to-LVDS converter chip on your board? Yes, we do. Depending on the board, we use a SN75LVDS83B or a SN65LVDS84. The reason for using this approach was that the panels covered by this patch seemed not to be compatible with Flatlink 3G, which meant driving them directly from the AM35xx SDI serial interface was not possible. We unfortunately do not get to select which LVDS deserializer is used at the panel side.. Best regards, Raphaël Assénat -- 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
On Tue, 2012-08-21 at 10:29 -0400, Raphaël Assénat wrote: > On 21/08/12 06:49 AM, Tomi Valkeinen wrote: > > On Wed, 2012-08-15 at 11:26 -0400, Raphaël Assénat wrote: > > > >>> + > >>> + /* ChiMei G121S1-L01 */ > >>> + { > >>> + { > >> > >> ... > >> > >>> + .vsync_level = OMAPDSS_SIG_ACTIVE_HIGH, > >>> + .hsync_level = OMAPDSS_SIG_ACTIVE_HIGH, > >>> + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE, > >>> + .de_level = OMAPDSS_SIG_ACTIVE_HIGH, > >>> + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES, > >> > >> Actually those 3 panels only use the DE signal. The hsync/vsync signals > >> are not used and on our system we mux them out to make sure they are > >> kept low as recommended in the panel datasheets. > >> > >> Since vsync/hsync are not used, I think the vsync_level, hsync_level and > >> sync_pclk_edge entries could be removed. Otherwise the updated patch > >> works fine as is. > > > > Okay. How do panels like that work? How can they know where a new frame > > starts? > > By DE being inactive for a different number of pixel clock cycles during > the vertical and horizontal blanking periods. Ok. Interesting architecture. I wonder what's the reason for a design like that... > > Actually, I now googled for those panels, and they are all LVDS panels, > > not DPI panels. So the patch doesn't look correct at all. > > > > Do you have a DPI-to-LVDS converter chip on your board? > > Yes, we do. Depending on the board, we use a SN75LVDS83B or a SN65LVDS84. > > The reason for using this approach was that the panels covered by > this patch seemed not to be compatible with Flatlink 3G, which meant > driving them directly from the AM35xx SDI serial interface was not possible. > We unfortunately do not get to select which LVDS deserializer is > used at the panel side.. Ok. I'm a bit reluctant to add the panels to panel-generic-dpi.c, as they are not DPI panels at all. Also, you should have drivers for the DPI-to-LVDS converters. However, this cannot be done properly with the current DSS driver model, so I'm not sure what to do with your patch. If you had just one panel and DPI-to-LVDS chip, I'd suggest to create a combined driver which handles both the chip and the panel. But you have two chips and three panels... I'm hoping the common panel framework which is being discussed on the mailinglists will help here. For the moment, I think it's best if you keep the panel patches in your kernel tree, and see later how to add them to common panel framework. Tomi
On 24/08/12 04:38 AM, Tomi Valkeinen wrote: > On Tue, 2012-08-21 at 10:29 -0400, Raphaël Assénat wrote: >> On 21/08/12 06:49 AM, Tomi Valkeinen wrote: >>> On Wed, 2012-08-15 at 11:26 -0400, Raphaël Assénat wrote: >>> >>>>> + >>>>> + /* ChiMei G121S1-L01 */ >>>>> + { >>>>> + { >>>> >>>> ... >>>> >>>>> + .vsync_level = OMAPDSS_SIG_ACTIVE_HIGH, >>>>> + .hsync_level = OMAPDSS_SIG_ACTIVE_HIGH, >>>>> + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE, >>>>> + .de_level = OMAPDSS_SIG_ACTIVE_HIGH, >>>>> + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES, >>>> >>>> Actually those 3 panels only use the DE signal. The hsync/vsync signals >>>> are not used and on our system we mux them out to make sure they are >>>> kept low as recommended in the panel datasheets. >>>> >>>> Since vsync/hsync are not used, I think the vsync_level, hsync_level and >>>> sync_pclk_edge entries could be removed. Otherwise the updated patch >>>> works fine as is. >>> >>> Okay. How do panels like that work? How can they know where a new frame >>> starts? >> >> By DE being inactive for a different number of pixel clock cycles during >> the vertical and horizontal blanking periods. > > Ok. Interesting architecture. I wonder what's the reason for a design > like that... > >>> Actually, I now googled for those panels, and they are all LVDS panels, >>> not DPI panels. So the patch doesn't look correct at all. >>> >>> Do you have a DPI-to-LVDS converter chip on your board? >> >> Yes, we do. Depending on the board, we use a SN75LVDS83B or a SN65LVDS84. >> >> The reason for using this approach was that the panels covered by >> this patch seemed not to be compatible with Flatlink 3G, which meant >> driving them directly from the AM35xx SDI serial interface was not possible. >> We unfortunately do not get to select which LVDS deserializer is >> used at the panel side.. > > Ok. I'm a bit reluctant to add the panels to panel-generic-dpi.c, as > they are not DPI panels at all. Also, you should have drivers for the > DPI-to-LVDS converters. However, this cannot be done properly with the > current DSS driver model, so I'm not sure what to do with your patch. But internally, perhaps with the exception of the "DE only" operation, all the same concepts apply. LVDS is just only one extra layer used to transmit the parallel data more effectively (differential, less conductors, etc). Consider the case where an LVDS transmitter is used on the main board in conjunction with a remote LVDS receiver on a board connected to a "true" DPI panel as follows: [OMAPDSS -> LVDS XMIT] -> [long cable] -> [LVDS RXCV -> DPI Panel] | parallel | lvds serial | parallel | Given the above use case, adding a new panel to panel-generic-dpi.c would be obvious since doing without LVDS and driving the panel directly may still happen if a specific design does not benefit from the use of LVDS. There are a few different conventions for LVDS transmission where the total number of bits transmitted by pairs as well as the bit order varies. The hardware designer selects a compatible pair of chips based on the number of color bits the panel supports and other factors. But no matter which are selected and how they are wired, the LVDS layer remains transparent to the graphics controller and the panel. My situation is only different from the above by the fact that our panels have an LVDS receiver built-in, which means the choice of transmitter is limited to what will be compatible and that a specific bit order (i.e. wiring) must be observed. This is why I tend to consider those LVDS panels simply as DPI panels having a built-in LVDS receiver. > If you had just one panel and DPI-to-LVDS chip, I'd suggest to create a > combined driver which handles both the chip and the panel. But you have > two chips and three panels... I'm not sure what the chip driver would do. The LVDS layer is totally transparent to the operation. Why would the kernel need to be aware of which chip is used? One thing that might be useful would be the ability to control the enable pin, but this is not different from the enable pin on a level shifter placed between the OMAP and a real DPI panel. At the moment, our userspace software simply controls this using a GPIO. Best regards, Raphaël Assénat -- 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
On Fri, 2012-08-24 at 09:50 -0400, Raphaël Assénat wrote: > But internally, perhaps with the exception of the "DE only" operation, > all the same concepts apply. LVDS is just only one extra layer used to > transmit the parallel data more effectively (differential, less > conductors, etc). > > Consider the case where an LVDS transmitter is used on the main board > in conjunction with a remote LVDS receiver on a board connected to > a "true" DPI panel as follows: > > [OMAPDSS -> LVDS XMIT] -> [long cable] -> [LVDS RXCV -> DPI Panel] > | parallel | lvds serial | parallel | > > Given the above use case, adding a new panel to panel-generic-dpi.c would > be obvious since doing without LVDS and driving the panel directly may > still happen if a specific design does not benefit from the use of LVDS. > > There are a few different conventions for LVDS transmission where the total > number of bits transmitted by pairs as well as the bit order varies. The > hardware designer selects a compatible pair of chips based on the number of > color bits the panel supports and other factors. But no matter which are > selected and how they are wired, the LVDS layer remains transparent to the > graphics controller and the panel. > > My situation is only different from the above by the fact that our panels > have an LVDS receiver built-in, which means the choice of transmitter is > limited to what will be compatible and that a specific bit order (i.e. > wiring) > must be observed. This is why I tend to consider those LVDS panels simply > as DPI panels having a built-in LVDS receiver. In your case the LVDS panels are "dummy", and require no configuration, and thus look like DPI panels. But consider an LVDS panel which can be controlled via, say, i2c, and you can configure the number of LVDS lanes used. And consider a SoC with LVDS transmitter, which again needs to be configured depending on the LVDS lanes used (and probably some other parameters). In those cases the use doesn't look like DPI anymore. > > If you had just one panel and DPI-to-LVDS chip, I'd suggest to create a > > combined driver which handles both the chip and the panel. But you have > > two chips and three panels... > > I'm not sure what the chip driver would do. The LVDS layer is totally > transparent to the operation. Why would the kernel need to be aware of > which chip is used? The chip must require power to operate, so it needs to enable regulators. For example, SN75LVDS83B requires VCC, IOVCC, PLLVCC, LVDSVCC. In your case the regulators may be always-on regulators, but a driver cannot make such assumptions. > One thing that might be useful would be the ability to control the > enable pin, but this is not different from the enable pin on a level shifter > placed between the OMAP and a real DPI panel. At the moment, our userspace > software simply controls this using a GPIO. Yes, the driver should also handle the enable GPIO (for the DPI case also). Now, as I said, the current omapdss model doesn't really allow "chaining" of display devices, so you can't currently create proper drivers. That's why I'm not sure what to do. It would be nice to support your boards, but on the other hand, I think it's not correct to add these panels. Tomi
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c index bc5af25..ae862bb 100644 --- a/drivers/video/omap2/displays/panel-generic-dpi.c +++ b/drivers/video/omap2/displays/panel-generic-dpi.c @@ -538,6 +538,82 @@ static struct panel_config generic_dpi_panels[] = { }, .name = "primeview_pd104slf", }, + + /* ChiMei G121S1-L01 */ + { + { + .x_res = 800, + .y_res = 600, + + .pixel_clock = 39700, + + .hfp = 128, + .hsw = 1, + .hbp = 128, + + .vfp = 28, + .vsw = 1, + .vbp = 28, + + .vsync_level = OMAPDSS_SIG_ACTIVE_HIGH, + .hsync_level = OMAPDSS_SIG_ACTIVE_HIGH, + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE, + .de_level = OMAPDSS_SIG_ACTIVE_HIGH, + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES, + }, + .name = "chimei_g121s1-l01", + }, + + /* ChiMei G121S1-L02 */ + { + { + .x_res = 800, + .y_res = 600, + + .pixel_clock = 40000, + + .hfp = 1, + .hsw = 256, + .hbp = 1, + + .vfp = 1, + .vsw = 28, + .vbp = 1, + + .vsync_level = OMAPDSS_SIG_ACTIVE_HIGH, + .hsync_level = OMAPDSS_SIG_ACTIVE_HIGH, + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE, + .de_level = OMAPDSS_SIG_ACTIVE_HIGH, + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES, + }, + .name = "chimei_g121s1-l02", + }, + + + /* ChiMei G121X1-L01 */ + { + { + .x_res = 1024, + .y_res = 768, + + .pixel_clock = 64900, + + .hfp = 160, + .hsw = 1, + .hbp = 160, + + .vfp = 38, + .vsw = 1, + .vbp = 38, + + .vsync_level = OMAPDSS_SIG_ACTIVE_HIGH, + .hsync_level = OMAPDSS_SIG_ACTIVE_HIGH, + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE, + .de_level = OMAPDSS_SIG_ACTIVE_HIGH, + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES, + }, + .name = "chimei_g121x1-l01", + }, }; struct panel_drv_data {