From patchwork Fri Sep 1 09:40:58 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Linus Walleij X-Patchwork-Id: 9933819 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4322E6016C for ; Fri, 1 Sep 2017 09:41:06 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4378B28614 for ; Fri, 1 Sep 2017 09:41:06 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 385A928619; Fri, 1 Sep 2017 09:41:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 9CC3328614 for ; Fri, 1 Sep 2017 09:41:05 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B93A86E804; Fri, 1 Sep 2017 09:41:04 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7E0726E804 for ; Fri, 1 Sep 2017 09:41:03 +0000 (UTC) Received: by mail-lf0-x22d.google.com with SMTP id g18so7349428lfl.2 for ; Fri, 01 Sep 2017 02:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=o/ej2FjQu2npDRBXrAGv29FkV2oWHLvp7UzxTwPe2eI=; b=Tuz8T2FBD30m1YpkxtclVU1yyMJoOW8NxygVRJj+NleBcjIsmeya6sWNDXWy6ImdDW OleCvGvBv8PPZ8Lrh9Un8BgcSRS8Iiuljunf/gRYNlLgjxZucPx5DaBy7Lr4HH8PaHMy jYuSRMB04McU+J7rBzeSf4+BqL7D7CYMX5IcQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=o/ej2FjQu2npDRBXrAGv29FkV2oWHLvp7UzxTwPe2eI=; b=T+8UThEuSdx5IaFbS+82W3qGQ8w/WPSsOyE2ZgRib96zwy+mOj15lyjhbguWuTBEX/ mJlE5VZU7MDdsyxQCWkMZEFM6AvS1I4N27dLQRb9QisDotL2PIh8uV/gxUxW+j0/n0OQ 6NW594WW0aINhokkd8n4E2K1KeX0n7U/BUTpqut/0LKXz4tdeaQxCLlJEvmnADFRA4e8 mCsXhx2VuRUiTH+tf0fYm/cMRRjY9qgtffaTn5SOYxpt0chmu7ld+FHZpY5f6LMwzmam Km7+Vujbme236BIinH5yS84SQntuSUYCT93Z29y/4eykUe/ZxTc32JphforXbewxnmeb bflw== X-Gm-Message-State: AHPjjUijVIcFtWQRZ/cgmV3EWx/kvfLeM4kYtpK3Vfb1MSZzFPH89gUB oVnqf5JIW/jdrVPy X-Google-Smtp-Source: ADKCNb7NGyAI7wOD7eTecG+SvF9icQM/mvrLnkcG6Lv24pbXkS+cTWVM9LtL+u/5fncMHQQa5zch1w== X-Received: by 10.25.228.199 with SMTP id x68mr541199lfi.24.1504258861722; Fri, 01 Sep 2017 02:41:01 -0700 (PDT) Received: from genomnajs.ideon.se ([85.235.10.227]) by smtp.gmail.com with ESMTPSA id h89sm341629lji.56.2017.09.01.02.41.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Sep 2017 02:41:01 -0700 (PDT) From: Linus Walleij To: Archit Taneja , Andrzej Hajda , Laurent Pinchart Subject: [PATCH 2/2] drm: bridge: Add THS8134A/B support to dumb VGA DAC Date: Fri, 1 Sep 2017 11:40:58 +0200 Message-Id: <20170901094058.4387-1-linus.walleij@linaro.org> X-Mailer: git-send-email 2.13.5 Cc: Laurent Pinchart , dri-devel@lists.freedesktop.org, Bartosz Golaszewski , Maxime Ripard , linux-arm-kernel@lists.infradead.org X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP This extends the dumb VGA DAC bridge to handle the THS8134A and THS8134B VGA DACs in addition to those already handled. The THS8134A, THS8134B and as it turns out also THS8135 need to have data clocked out at the negative edge of the clock pulse, since they clock it into the DAC at the positive edge (so by then it needs to be stable) so we need some extra logic to flag this on the connector to the driver. The semantics of the flag DRM_BUS_FLAG_PIXDATA_NEGEDGE in clearly indicates that this flag tells when to *drive* the data, not when the receiver *reads* it, so the TI variants needs to be handled like this. Introduce a variant struct and contain the information there, and add a bit of helpful comments about how this works so people will get it right when adding new DACs or connectiong new display drivers to DACs. The fact that THS8135 might be working on some systems today is probably due to the fact that the display driver cannot configure when the data is clocked out and the electronics have simply been designed around it so it works anyways. The phenomenon is very real on the ARM reference designs using PL111 where the hardware can control which edge to push out the data. Cc: Laurent Pinchart Cc: Bartosz Golaszewski Cc: Maxime Ripard Signed-off-by: Linus Walleij --- drivers/gpu/drm/bridge/dumb-vga-dac.c | 62 +++++++++++++++++++++++++++++++++-- 1 file changed, 59 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c index 831a606c4706..6c2fdcb4fde1 100644 --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c @@ -12,6 +12,7 @@ #include #include +#include #include #include @@ -19,9 +20,20 @@ #include #include +/** + * struct vga_dac_variant - characteristics of the DAC + * @posedge_clk: this DAC latches data into the DAC on the positive + * edge of the clock pulse, which means that display controllers + * need to clock it out on the negative edge + */ +struct vga_dac_variant { + bool posedge_clk; +}; + struct dumb_vga { struct drm_bridge bridge; struct drm_connector connector; + struct vga_dac_variant const *variant; struct i2c_adapter *ddc; struct regulator *vdd; @@ -67,6 +79,18 @@ static int dumb_vga_get_modes(struct drm_connector *connector) /* And prefer a mode pretty much anyone can handle */ drm_set_preferred_mode(connector, 1024, 768); + if (vga->variant->posedge_clk) + /* + * If the DAC latches the data into its registers on the + * positive edge of the clock, the display driver needs to + * drive the data out on the negative edge so it is + * stable at the positive edge, so as to avoid flicker. + * + * Tell the driver that we want data on the negative edge + */ + connector->display_info.bus_flags |= + DRM_BUS_FLAG_PIXDATA_NEGEDGE; + return ret; } @@ -183,6 +207,7 @@ static int dumb_vga_probe(struct platform_device *pdev) if (!vga) return -ENOMEM; platform_set_drvdata(pdev, vga); + vga->variant = of_device_get_match_data(&pdev->dev); vga->vdd = devm_regulator_get_optional(&pdev->dev, "vdd"); if (IS_ERR(vga->vdd)) { @@ -226,10 +251,41 @@ static int dumb_vga_remove(struct platform_device *pdev) return 0; } +static const struct vga_dac_variant default_dac_variant = { + /* + * These DACs read data on the negative edge. For example in the + * ADV7123 datasheet (revision D, page 8) there is a timing diagram + * making this clear. + */ + .posedge_clk = false, +}; + +static const struct vga_dac_variant ti_ths_dac_variant = { + /* The TI DACs read the data on the positive edge of the CLK */ + .posedge_clk = true, +}; + static const struct of_device_id dumb_vga_match[] = { - { .compatible = "dumb-vga-dac" }, - { .compatible = "adi,adv7123" }, - { .compatible = "ti,ths8135" }, + { + .compatible = "dumb-vga-dac", + .data = &default_dac_variant, + }, + { + .compatible = "adi,adv7123", + .data = &default_dac_variant, + }, + { + .compatible = "ti,ths8134a", + .data = &ti_ths_dac_variant, + }, + { + .compatible = "ti,ths8134b", + .data = &ti_ths_dac_variant, + }, + { + .compatible = "ti,ths8135", + .data = &ti_ths_dac_variant, + }, {}, }; MODULE_DEVICE_TABLE(of, dumb_vga_match);