<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Hi Maxime & Miquel, <div class="moz-cite-prefix">在 2019/12/16 下午7:14, Maxime Ripard 写道: </div> <blockquote type="cite" cite="mid:20191216111436.wzoq33gvt42w6gqj@gilmour.lan"> <pre class="moz-quote-pre" wrap="">On Mon, Dec 16, 2019 at 12:03:12PM +0100, Miquel Raynal wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Maxime Ripard <a class="moz-txt-link-rfc2396E" href="mailto:maxime@cerno.tech"><maxime@cerno.tech></a> wrote on Mon, 16 Dec 2019 11:58:27 +0100: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Hi, On Fri, Dec 13, 2019 at 07:10:48PM +0100, Miquel Raynal wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">+static int px30_lvds_grf_config(struct drm_encoder *encoder, + struct drm_display_mode *mode) +{ + struct rockchip_lvds *lvds = encoder_to_lvds(encoder); + u8 nhsync = !(mode->flags & DRM_MODE_FLAG_PHSYNC); + u8 nvsync = !(mode->flags & DRM_MODE_FLAG_PVSYNC); + u8 ndclk = !(mode->flags & DRM_MODE_FLAG_PCSYNC); + int ret; + + if (lvds->output != DISPLAY_OUTPUT_LVDS) { + DRM_DEV_ERROR(lvds->dev, "Unsupported display output %d\n", + lvds->output); + return -EINVAL; + } + + if (nhsync ^ nvsync) { + DRM_DEV_ERROR(lvds->dev, "Unsupported Hsync/Vsync polarity\n"); + return -EINVAL; + } + + /* Set format */ + ret = regmap_update_bits(lvds->grf, PX30_LVDS_GRF_PD_VO_CON1, + PX30_LVDS_FORMAT(lvds->format), + PX30_LVDS_FORMAT(lvds->format)); + if (ret) + return ret; + + /* Control Hsync/Vsync polarity */ + ret = regmap_update_bits(lvds->grf, PX30_LVDS_GRF_PD_VO_CON0, + PX30_LVDS_TIE_CLKS(1), + PX30_LVDS_TIE_CLKS(1)); + if (ret) + return ret; + + /* Set Hsync/Vsync polarity */ + ret = regmap_update_bits(lvds->grf, PX30_LVDS_GRF_PD_VO_CON0, + PX30_LVDS_INVERT_CLKS(1), + PX30_LVDS_INVERT_CLKS(nhsync)); + if (ret) + return ret; </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> I don't know the hardware but it seems pretty weird to me. hsync and vsync in LVDS are not clocks (or even signals), they're a bit in the payload. Is there any explanation in the datasheet (or even a datasheet in the first place)? </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> There is no explanation about this in the PX30 TRM part 1 (public). But you are right the naming is weird. Could the "tie clocks" thing above mean something to you/people knowing the LVDS world? </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> I have no idea what that could mean :)</pre> </blockquote> This two bit(GRF_CON0[9,8]) is not for hsync/vsync polarity config, the polarity is done at <a class="moz-txt-link-abbreviated" href="mailto:vop_crtc_atomic_enable@rockchip_drm_vop.c">vop_crtc_atomic_enable@rockchip_drm_vop.c</a>. Before px30, all rockchip platform lvds output payload is include hsync,vsync and den clock signal. About years ago, we meet a lvds panel can't work normally at rk3288, from the panel spec we know the panel need lvds work den mode only, the hsync/vsync need to set 0 at blank time, so we add this two bit(GRF_CON0[9,8]) for this mode. but now we can't get in touch with the customer and get the panel to test this function, so we can't verify the panel work unnormally is because of the den mode only and the hsync vsync signal level at blank time. I recommend not including this part of configuration before we test this funcion at den mode only lvds panel,thanks. <blockquote type="cite" cite="mid:20191216111436.wzoq33gvt42w6gqj@gilmour.lan"> <pre class="moz-quote-pre" wrap=""> Maxime </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre class="moz-quote-pre" wrap="">_______________________________________________ Linux-rockchip mailing list <a class="moz-txt-link-abbreviated" href="mailto:Linux-rockchip@lists.infradead.org">Linux-rockchip@lists.infradead.org</a> <a class="moz-txt-link-freetext" href="http://lists.infradead.org/mailman/listinfo/linux-rockchip">http://lists.infradead.org/mailman/listinfo/linux-rockchip</a> </pre> </blockquote> </body> </html>