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
signature.asc
Description: This is a digitally signed message part
