* New LCD connector type? @ 2016-05-06 19:01 Sergei Shtylyov 2016-05-07 18:11 ` Ville Syrjälä 2016-05-09 18:09 ` Eric Anholt 0 siblings, 2 replies; 7+ messages in thread From: Sergei Shtylyov @ 2016-05-06 19:01 UTC (permalink / raw) To: dri-devel; +Cc: Laurent Pinchart (Resending as I couldn't find this message from January in the list archives.) Hello. We have a board which has Newhaven Display LCD [1] connected via a what seems to be a custom 40-signal LCD connector. That connector includes (6-bit per component) RGB signals, DISP, H/VSYNC, and the pixel clock signals; in addition, there are I2C and IRQ signals. Now we need to add support for this kind of connector to the R-Car DU driver in order to get the LCD panel resolution from the device tree (see drivers/gpu/drm/rcar-du/rcar_du_*con.c for the examples) and so we'd probably need a new DRM_MODE_CONNECTOR_* constant in include/uapi/drm/drm_mode.h in order to do that... Laurent advised me to ask for the opinions on the dri-devel mailing list first, which I'm doing. :-) MBR, Sergei [1] http://www.newhavendisplay.com/nhd70800480efatxv-p-6720.html _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: New LCD connector type? 2016-05-06 19:01 New LCD connector type? Sergei Shtylyov @ 2016-05-07 18:11 ` Ville Syrjälä 2016-05-09 11:43 ` Laurent Pinchart 2016-05-09 18:09 ` Eric Anholt 1 sibling, 1 reply; 7+ messages in thread From: Ville Syrjälä @ 2016-05-07 18:11 UTC (permalink / raw) To: Sergei Shtylyov; +Cc: Laurent Pinchart, dri-devel On Fri, May 06, 2016 at 10:01:29PM +0300, Sergei Shtylyov wrote: > (Resending as I couldn't find this message from January in the list archives.) > > Hello. > > We have a board which has Newhaven Display LCD [1] connected via a what > seems to be a custom 40-signal LCD connector. That connector includes (6-bit > per component) RGB signals, DISP, H/VSYNC, and the pixel clock signals; in > addition, there are I2C and IRQ signals. > Now we need to add support for this kind of connector to the R-Car DU > driver in order to get the LCD panel resolution from the device tree (see > drivers/gpu/drm/rcar-du/rcar_du_*con.c for the examples) and so we'd probably > need a new DRM_MODE_CONNECTOR_* constant in include/uapi/drm/drm_mode.h in > order to do that... Laurent advised me to ask for the opinions on the > dri-devel mailing list first, which I'm doing. :-) I'd just make it LVDS. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: New LCD connector type? 2016-05-07 18:11 ` Ville Syrjälä @ 2016-05-09 11:43 ` Laurent Pinchart 2016-05-09 12:07 ` Ville Syrjälä 0 siblings, 1 reply; 7+ messages in thread From: Laurent Pinchart @ 2016-05-09 11:43 UTC (permalink / raw) To: Ville Syrjälä; +Cc: dri-devel, Sergei Shtylyov Hi Ville, On Saturday 07 May 2016 21:11:23 Ville Syrjälä wrote: > On Fri, May 06, 2016 at 10:01:29PM +0300, Sergei Shtylyov wrote: > > (Resending as I couldn't find this message from January in the list > > archives.) > > > > Hello. > > > > We have a board which has Newhaven Display LCD [1] connected via a > > what seems to be a custom 40-signal LCD connector. That connector includes > > (6-bit per component) RGB signals, DISP, H/VSYNC, and the pixel clock > > signals; in addition, there are I2C and IRQ signals. > > > > Now we need to add support for this kind of connector to the R-Car DU > > driver in order to get the LCD panel resolution from the device tree (see > > drivers/gpu/drm/rcar-du/rcar_du_*con.c for the examples) and so we'd > > probably need a new DRM_MODE_CONNECTOR_* constant in > > include/uapi/drm/drm_mode.h in order to do that... Laurent advised me to > > ask for the opinions on the dri-devel mailing list first, which I'm > > doing. :-) > > I'd just make it LVDS. Even if the connector doesn't carry LVDS signals ? -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: New LCD connector type? 2016-05-09 11:43 ` Laurent Pinchart @ 2016-05-09 12:07 ` Ville Syrjälä 2016-05-09 20:07 ` Laurent Pinchart 0 siblings, 1 reply; 7+ messages in thread From: Ville Syrjälä @ 2016-05-09 12:07 UTC (permalink / raw) To: Laurent Pinchart; +Cc: dri-devel, Sergei Shtylyov On Mon, May 09, 2016 at 02:43:02PM +0300, Laurent Pinchart wrote: > Hi Ville, > > On Saturday 07 May 2016 21:11:23 Ville Syrjälä wrote: > > On Fri, May 06, 2016 at 10:01:29PM +0300, Sergei Shtylyov wrote: > > > (Resending as I couldn't find this message from January in the list > > > archives.) > > > > > > Hello. > > > > > > We have a board which has Newhaven Display LCD [1] connected via a > > > what seems to be a custom 40-signal LCD connector. That connector includes > > > (6-bit per component) RGB signals, DISP, H/VSYNC, and the pixel clock > > > signals; in addition, there are I2C and IRQ signals. > > > > > > Now we need to add support for this kind of connector to the R-Car DU > > > driver in order to get the LCD panel resolution from the device tree (see > > > drivers/gpu/drm/rcar-du/rcar_du_*con.c for the examples) and so we'd > > > probably need a new DRM_MODE_CONNECTOR_* constant in > > > include/uapi/drm/drm_mode.h in order to do that... Laurent advised me to > > > ask for the opinions on the dri-devel mailing list first, which I'm > > > doing. :-) > > > > I'd just make it LVDS. > > Even if the connector doesn't carry LVDS signals ? No one should really have to care about such details for any purely internal connector. IMO the fact that the thing we have is called LVDS could be considered a historical accident. We do have eDP and DSI types too though, which I might not have even bothered to add myself. These days eDP does make some sense as we expose the AUX ch via /dev so eDP vs. other internal connectors does have some user visible difference at least. And I guess you could justify DSI by the fact that it's a widely used standard. If people feel anal about this, I guess you could always add some kind of generic internal connector type to account for everything that isn't LVDS/eDP/DSI. But a new type means that you'll have to modify userspace to deal with the new connector type, at least if you want to name the connector based on its type (which is the norm). -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: New LCD connector type? 2016-05-09 12:07 ` Ville Syrjälä @ 2016-05-09 20:07 ` Laurent Pinchart 2016-05-10 7:03 ` Daniel Vetter 0 siblings, 1 reply; 7+ messages in thread From: Laurent Pinchart @ 2016-05-09 20:07 UTC (permalink / raw) To: Ville Syrjälä; +Cc: dri-devel, Sergei Shtylyov Hi Ville, On Monday 09 May 2016 15:07:21 Ville Syrjälä wrote: > On Mon, May 09, 2016 at 02:43:02PM +0300, Laurent Pinchart wrote: > > On Saturday 07 May 2016 21:11:23 Ville Syrjälä wrote: > >> On Fri, May 06, 2016 at 10:01:29PM +0300, Sergei Shtylyov wrote: > >>> (Resending as I couldn't find this message from January in the list > >>> archives.) > >>> > >>> Hello. > >>> > >>> We have a board which has Newhaven Display LCD [1] connected via a > >>> what seems to be a custom 40-signal LCD connector. That connector > >>> includes (6-bit per component) RGB signals, DISP, H/VSYNC, and the > >>> pixel clock signals; in addition, there are I2C and IRQ signals. > >>> > >>> Now we need to add support for this kind of connector to the R-Car DU > >>> driver in order to get the LCD panel resolution from the device tree > >>> (see drivers/gpu/drm/rcar-du/rcar_du_*con.c for the examples) and so > >>> we'd probably need a new DRM_MODE_CONNECTOR_* constant in > >>> include/uapi/drm/drm_mode.h in order to do that... Laurent advised me > >>> to ask for the opinions on the dri-devel mailing list first, which I'm > >>> doing. :-) > >> > >> I'd just make it LVDS. > > > > Even if the connector doesn't carry LVDS signals ? > > No one should really have to care about such details for any purely > internal connector. IMO the fact that the thing we have is called > LVDS could be considered a historical accident. > > We do have eDP and DSI types too though, which I might not have even > bothered to add myself. These days eDP does make some sense as we expose > the AUX ch via /dev so eDP vs. other internal connectors does have some > user visible difference at least. And I guess you could justify DSI by > the fact that it's a widely used standard. > > If people feel anal about this, I guess you could always add some kind > of generic internal connector type to account for everything that isn't > LVDS/eDP/DSI. But a new type means that you'll have to modify userspace > to deal with the new connector type, at least if you want to name the > connector based on its type (which is the norm). I don't have a too strong opinion on the topic, but given that we've added a few connector types semi-randomly (or at least without giving it too much thoughts, as you described as "historical accident") I think we should at least decide what we want connector types to represent. For instance, on the topic of DSI, what could have been more interesting than the physical protocol is whether the panel supports command mode and partial updates, but the DSI connector type doesn't tell anything about that except hinting that command mode could be supported. If the connector type is solely used to describe the shape of the user- accessible connector then I agree than an "internal connector" type could have covered LVDS, DPI and DSI (as well as DBI and possibly eDP). One of the question is whether it could be useful to convey more information than that to userspace. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: New LCD connector type? 2016-05-09 20:07 ` Laurent Pinchart @ 2016-05-10 7:03 ` Daniel Vetter 0 siblings, 0 replies; 7+ messages in thread From: Daniel Vetter @ 2016-05-10 7:03 UTC (permalink / raw) To: Laurent Pinchart; +Cc: Sergei Shtylyov, dri-devel On Mon, May 09, 2016 at 11:07:53PM +0300, Laurent Pinchart wrote: > Hi Ville, > > On Monday 09 May 2016 15:07:21 Ville Syrjälä wrote: > > On Mon, May 09, 2016 at 02:43:02PM +0300, Laurent Pinchart wrote: > > > On Saturday 07 May 2016 21:11:23 Ville Syrjälä wrote: > > >> On Fri, May 06, 2016 at 10:01:29PM +0300, Sergei Shtylyov wrote: > > >>> (Resending as I couldn't find this message from January in the list > > >>> archives.) > > >>> > > >>> Hello. > > >>> > > >>> We have a board which has Newhaven Display LCD [1] connected via a > > >>> what seems to be a custom 40-signal LCD connector. That connector > > >>> includes (6-bit per component) RGB signals, DISP, H/VSYNC, and the > > >>> pixel clock signals; in addition, there are I2C and IRQ signals. > > >>> > > >>> Now we need to add support for this kind of connector to the R-Car DU > > >>> driver in order to get the LCD panel resolution from the device tree > > >>> (see drivers/gpu/drm/rcar-du/rcar_du_*con.c for the examples) and so > > >>> we'd probably need a new DRM_MODE_CONNECTOR_* constant in > > >>> include/uapi/drm/drm_mode.h in order to do that... Laurent advised me > > >>> to ask for the opinions on the dri-devel mailing list first, which I'm > > >>> doing. :-) > > >> > > >> I'd just make it LVDS. > > > > > > Even if the connector doesn't carry LVDS signals ? > > > > No one should really have to care about such details for any purely > > internal connector. IMO the fact that the thing we have is called > > LVDS could be considered a historical accident. > > > > We do have eDP and DSI types too though, which I might not have even > > bothered to add myself. These days eDP does make some sense as we expose > > the AUX ch via /dev so eDP vs. other internal connectors does have some > > user visible difference at least. And I guess you could justify DSI by > > the fact that it's a widely used standard. > > > > If people feel anal about this, I guess you could always add some kind > > of generic internal connector type to account for everything that isn't > > LVDS/eDP/DSI. But a new type means that you'll have to modify userspace > > to deal with the new connector type, at least if you want to name the > > connector based on its type (which is the norm). > > I don't have a too strong opinion on the topic, but given that we've added a > few connector types semi-randomly (or at least without giving it too much > thoughts, as you described as "historical accident") I think we should at > least decide what we want connector types to represent. > > For instance, on the topic of DSI, what could have been more interesting than > the physical protocol is whether the panel supports command mode and partial > updates, but the DSI connector type doesn't tell anything about that except > hinting that command mode could be supported. I think for command mode we'd want some prop on either the connector or the crtc. There's lots more stuff that does manual upload or similar things, where vrefresh becomes less well defined ... In any case userspace that renders to the frontbuffer _must_ call the DIRTYFB ioctl to flush stuff out, to make sure it all works on command mode DSI, PSR eDP and any of the other cases. > If the connector type is solely used to describe the shape of the user- > accessible connector then I agree than an "internal connector" type could have > covered LVDS, DPI and DSI (as well as DBI and possibly eDP). One of the > question is whether it could be useful to convey more information than that to > userspace. That was the original intention at least - it was meant to help users find the right connector on their machine. There's also encoder types for completeness, but those are already genuinely useless. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: New LCD connector type? 2016-05-06 19:01 New LCD connector type? Sergei Shtylyov 2016-05-07 18:11 ` Ville Syrjälä @ 2016-05-09 18:09 ` Eric Anholt 1 sibling, 0 replies; 7+ messages in thread From: Eric Anholt @ 2016-05-09 18:09 UTC (permalink / raw) To: Sergei Shtylyov, dri-devel; +Cc: Laurent Pinchart [-- Attachment #1.1: Type: text/plain, Size: 1266 bytes --] Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> writes: > (Resending as I couldn't find this message from January in the list archives.) > > Hello. > > We have a board which has Newhaven Display LCD [1] connected via a what > seems to be a custom 40-signal LCD connector. That connector includes (6-bit > per component) RGB signals, DISP, H/VSYNC, and the pixel clock signals; in > addition, there are I2C and IRQ signals. > Now we need to add support for this kind of connector to the R-Car DU > driver in order to get the LCD panel resolution from the device tree (see > drivers/gpu/drm/rcar-du/rcar_du_*con.c for the examples) and so we'd probably > need a new DRM_MODE_CONNECTOR_* constant in include/uapi/drm/drm_mode.h in > order to do that... Laurent advised me to ask for the opinions on the > dri-devel mailing list first, which I'm doing. :-) I just added the DPI connector/encoder type for this type of panel connection (even though the pinouts are different on all of the actual connectors). I think thta would make the most sense. I haven't updated libdrm for it yet, though. See https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=0b27c02a7f1c697694f2ad6d6517e7dbf9ecfa39 for the commit [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-05-10 7:03 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-06 19:01 New LCD connector type? Sergei Shtylyov 2016-05-07 18:11 ` Ville Syrjälä 2016-05-09 11:43 ` Laurent Pinchart 2016-05-09 12:07 ` Ville Syrjälä 2016-05-09 20:07 ` Laurent Pinchart 2016-05-10 7:03 ` Daniel Vetter 2016-05-09 18:09 ` Eric Anholt
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.