From patchwork Wed Sep 1 20:19:19 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 505170 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55CDEC25AEF for ; Wed, 1 Sep 2021 20:20:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3E423610A1 for ; Wed, 1 Sep 2021 20:20:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245497AbhIAUVf (ORCPT ); Wed, 1 Sep 2021 16:21:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243898AbhIAUV2 (ORCPT ); Wed, 1 Sep 2021 16:21:28 -0400 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47D34C0617A8 for ; Wed, 1 Sep 2021 13:20:28 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id t1so666631pgv.3 for ; Wed, 01 Sep 2021 13:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=MFz/J7aAijkpNMg5cMsZk7y0NR1FdTOY1jwRJZxc2nE=; b=f5Rs2FjUW6nkR+AHabo7d9WoP1/vWzHJZv9+bW4me5pWqFLdEYjIS+1PUPQ+PFZ2+F uZ4RJoMTRSOrTb4aB9brFgTboAtAPRO4wfnaMb86fjyTkkJcnxUE47msuUGg7A3aj9H4 qevn5ZG395T+ZN4kb2Qr3SSsuEgZRbY290rn8= 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=MFz/J7aAijkpNMg5cMsZk7y0NR1FdTOY1jwRJZxc2nE=; b=hVPYZIw4FYFwrltJ8nEysE4dZxMW4HlOsYm5ZIBxdyy5z7Gvj1TGtuTWRW1qVecJCV MdRVGtiFv07JFMjYQyjdlwZY7pSfa1AnQJW4zqWZiNGpLyaK/j7is2TDEKudlrgDu5fY j3lYeieLehhJaXvjr6cKeKU//ogazwIvSkSqZFWwHMNIRonx2iyZg4ba3/ghVOsxIVun qg6Wyyd7rHX7PsmWjdrdmfE+LmXAKW2ByoxNdcQzE6KNNrYzx2yumj/0s8cTHb6+++mm soG4j+NmleITxHjG0/zmIuRMOyPCnw0LhONN5F7YM6Gyg0Z+8rDD7IWm1xUW/063hlGb ab5w== X-Gm-Message-State: AOAM533K2yq9tpUjrNkJI38n6ja4U7HOcjWWXtqrJr5pWKTKfUrs6tCK /GsECoEPLhyOtLh/Cbk85uCE7z5UlE6XfA== X-Google-Smtp-Source: ABdhPJzG561MW4j1aGa/s8L4HHSGGsl+PzC3APu3L1sVM4dFh/eFb6YO0xt2ZtmTRVxRFQ3ueRbOrg== X-Received: by 2002:a63:4b53:: with SMTP id k19mr783896pgl.3.1630527627758; Wed, 01 Sep 2021 13:20:27 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:958b:b561:a735:e774]) by smtp.gmail.com with ESMTPSA id x15sm321178pfq.31.2021.09.01.13.20.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Sep 2021 13:20:27 -0700 (PDT) From: Douglas Anderson To: Thierry Reding , Rob Herring , Sam Ravnborg Cc: Maarten Lankhorst , linux-arm-msm@vger.kernel.org, Bjorn Andersson , Linus W , Daniel Vetter , devicetree@vger.kernel.org, Steev Klimaszewski , Thomas Zimmermann , Maxime Ripard , David Airlie , dri-devel@lists.freedesktop.org, Douglas Anderson , Rob Herring , linux-kernel@vger.kernel.org Subject: [PATCH v3 01/16] dt-bindings: drm/panel-simple-edp: Introduce generic eDP panels Date: Wed, 1 Sep 2021 13:19:19 -0700 Message-Id: <20210901131531.v3.1.I1116e79d34035338a45c1fc7cdd14a097909c8e0@changeid> X-Mailer: git-send-email 2.33.0.259.gc128427fd7-goog In-Reply-To: <20210901201934.1084250-1-dianders@chromium.org> References: <20210901201934.1084250-1-dianders@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org eDP panels generally contain almost everything needed to control them in their EDID. This comes from their DP heritage were a computer needs to be able to properly control pretty much any DP display that's plugged into it. The one big issue with eDP panels and the reason that we need a panel driver for them is that the power sequencing can be different per panel. While it is true that eDP panel sequencing can be arbitrarily complex, in practice it turns out that many eDP panels are compatible with just some slightly different delays. See the contents of the bindings file introduced in this patch for some details. The fact that eDP panels are 99% probable and that the power sequencing (especially power up) can be compatible between many panels means that there's a constant desire to plug multiple different panels into the same board. This could be for second sourcing purposes or to support multiple SKUs (maybe a 11" and a 13", for instance). As discussed [1], it should be OK to support this by adding two properties to the device tree to specify the delays needed for powering up the panel the first time. We'll create a new "edp-panel" bindings file and define the two delays that might need to be specified. NOTE: in the vast majority of the cases (HPD is hooked up and isn't glitchy or is debounced) even these delays aren't needed. [1] https://lore.kernel.org/r/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrEQ@mail.gmail.com Signed-off-by: Douglas Anderson Reviewed-by: Rob Herring --- (no changes since v2) Changes in v2: - No longer allow fallback to panel-simple. - Add "-ms" suffix to delays. .../bindings/display/panel/panel-edp.yaml | 188 ++++++++++++++++++ 1 file changed, 188 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.yaml diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.yaml b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml new file mode 100644 index 000000000000..6a621376ff86 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml @@ -0,0 +1,188 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-edp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Probable (via DP AUX / EDID) eDP Panels with simple poweron sequences + +maintainers: + - Douglas Anderson + +description: | + This binding file can be used to indicate that an eDP panel is connected + to a Embedded DisplayPort AUX bus (see display/dp-aux-bus.yaml) without + actually specifying exactly what panel is connected. This is useful for + the case that more than one different panel could be connected to the + board, either for second-sourcing purposes or to support multiple SKUs + with different LCDs that hook up to a common board. + + As per above, a requirement for using this binding is that the panel is + represented under the DP AUX bus. This means that we can use any + information provided by the DP AUX bus (including the EDID) to identify + the panel. We can use this to identify display size, resolution, and + timings among other things. + + One piece of information about eDP panels that is typically _not_ + provided anywhere on the DP AUX bus is the power sequencing timings. + This is the reason why, historically, we've always had to explicitly + list eDP panels. We solve that here with two tricks. The "worst case" + power on timings for any panels expected to be connected to a board are + specified in these bindings. Once we've powered on, it's expected that + the operating system will lookup the panel in a table (based on EDID + information) to figure out other power sequencing timings. + + eDP panels in general can have somewhat arbitrary power sequencing + requirements. However, even though it's arbitrary in general, the + vast majority of panel datasheets have a power sequence diagram that + looks the exactly the same as every other panel. Each panel datasheet + cares about different timings in this diagram but the fact that the + diagram is so similar means we can come up with a single driver to + handle it. + + These diagrams all look roughly like this, sometimes labeled with + slightly different numbers / lines but all pretty much the same + sequence. This is because much of this diagram comes straight from + the eDP Standard. + + __________________________________________________ + Vdd ___/: :\____ / + _/ : : \_____/ + ::: :<--T10-->::: + : +-----------------------+---------+---------+ + eDP -----------+ Black video | Src vid | Blk vid + + Display : +-----------------------+---------+---------+ + : _______________________:_________:_________: + HPD :| : : | + ___________| : : |_____________ + : : : : + Sink +-----------------------:---------:---------+ + AUX CH -----------+ AUX Ch operational : : +------------- + +-----------------------:---------:---------+ + : : : : + :: :: : : + Src main +------+------+--------------+---------+ + lnk data----------------+LnkTrn| Idle |Valid vid data| Idle/off+------------- + +------+------+--------------+---------+ + : :<-T6->:<-T8->: : + :__:: + LED_EN | | + _____________________________________| |____________________________ + : : + __________:__:_ + PWM | : : | + __________________________| : : |__________________________ + : : : : + _____________:__________:__:_:______ + Bklight ____/: : : : : :\____ + power _______/ :<---T13---->: : : :: \______________ + (Vbl) ::<---------T14--------->: :<-T15->:: + + The above looks fairly complex but, as per above, each panel only cares + about a subset of those timings. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: edp-panel + + hpd-reliable-delay-ms: + description: + A fixed amount of time that must be waited after powering on the + panel's power-supply before the HPD signal is a reliable way to know + when the AUX channel is ready. This is useful for panels that glitch + the HPD at the start of power-on. This value is not needed if HPD is + always reliable for all panels that might be connected. + + hpd-absent-delay-ms: + description: + The panel specifies that HPD will be asserted this many milliseconds + from power on (timing T3 in the diagram above). If we have no way to + measure HPD then a fixed delay of this many milliseconds can be used. + This can also be used as a timeout when waiting for HPD. Does not + include the hpd-reliable-delay, so if hpd-reliable-delay was 80 ms + and hpd-absent-delay was 200 ms then we'd do a fixed 80 ms delay and + then we know HPD would assert in the next 120 ms. This value is not + needed if HPD hooked up, either through a GPIO in the panel node or + hooked up directly to the eDP controller. + + backlight: true + enable-gpios: true + port: true + power-supply: true + no-hpd: true + hpd-gpios: true + +additionalProperties: false + +required: + - compatible + - power-supply + +examples: + - | + #include + #include + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi86"; + reg = <0x2d>; + + interrupt-parent = <&tlmm>; + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>; + + enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>; + + vpll-supply = <&src_pp1800_s4a>; + vccio-supply = <&src_pp1800_s4a>; + vcca-supply = <&src_pp1200_l2a>; + vcc-supply = <&src_pp1200_l2a>; + + clocks = <&rpmhcc RPMH_LN_BB_CLK2>; + clock-names = "refclk"; + + no-hpd; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + sn65dsi86_out: endpoint { + remote-endpoint = <&panel_in_edp>; + }; + }; + }; + + aux-bus { + panel { + compatible = "edp-panel"; + power-supply = <&pp3300_dx_edp>; + backlight = <&backlight>; + hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>; + hpd-reliable-delay-ms = <15>; + + port { + panel_in_edp: endpoint { + remote-endpoint = <&sn65dsi86_out>; + }; + }; + }; + }; + }; + }; From patchwork Wed Sep 1 20:19:21 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 505167 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 336D9C25AED for ; Wed, 1 Sep 2021 20:21:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1A40460FE6 for ; Wed, 1 Sep 2021 20:21:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245226AbhIAUV4 (ORCPT ); Wed, 1 Sep 2021 16:21:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55294 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245268AbhIAUVd (ORCPT ); Wed, 1 Sep 2021 16:21:33 -0400 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E48F5C061760 for ; Wed, 1 Sep 2021 13:20:31 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id u1so378002plq.5 for ; Wed, 01 Sep 2021 13:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=NFnoIbGurLHygQYzR/1vkknC/vUF1WONmleiQRHkl10=; b=d5lm75+RLct6X/Jl04wCP559lXGWD7QrbiXaXZsBpu0T/HPKljNQr18x6eRHAPB/Uv A6MK+U8iAPjyDVn9LejUQEv7cJDRahTvyejMAVtMF5Rf1AiBO8Rih3QARced7J00qOhd gvUqgtvGrIcE//kMcXNfoL+wYIvMqL3MBTWUw= 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=NFnoIbGurLHygQYzR/1vkknC/vUF1WONmleiQRHkl10=; b=qFLn89IuRqWcfJh9Fe+A9M3lrqD5sfGpNbNqP3KNTnvomLkePJkKQpNsKg9tPZxyCw o1TaIDLquVNdVU1tV+qrK9CsA3S/qqpKM+jqh+NAFCj15P152DOtEOtLvqc9fqVs+wGx hjWjsZjSz+fLt4gd6ToK12bJAyKFQZmY8DwhDeZ+HBwpfN/AMndDxn50g61yCKUkWJDM PZFGqLGNh1qrqYwT49XCzI0JEXyyxoFoXEIWyRAvV88hyrIDt8zFlHJ679fx9x50kk6h J/Hqwx7Hf98O9enWpf36diFlf4ecZIcHgrgekYH6WiruEykqVe67S3tnVsrFKV5q/Hlx k4ew== X-Gm-Message-State: AOAM532B98xL9kO3AvmG/Bv018BaeNvfL+rQCzj9o1P7O9yDxQJdVOWt ZpgQCZemrFqaxj/KN3fzj4Lj0g== X-Google-Smtp-Source: ABdhPJz9dXAu9z9CahmGdhaS7l63HuYWmgsF9bVQKFGNROPgTEDy5l0aF6odYgaVO9CJl819YB0BNQ== X-Received: by 2002:a17:90b:128a:: with SMTP id fw10mr1225651pjb.212.1630527631467; Wed, 01 Sep 2021 13:20:31 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:958b:b561:a735:e774]) by smtp.gmail.com with ESMTPSA id x15sm321178pfq.31.2021.09.01.13.20.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Sep 2021 13:20:31 -0700 (PDT) From: Douglas Anderson To: Thierry Reding , Rob Herring , Sam Ravnborg Cc: Maarten Lankhorst , linux-arm-msm@vger.kernel.org, Bjorn Andersson , Linus W , Daniel Vetter , devicetree@vger.kernel.org, Steev Klimaszewski , Thomas Zimmermann , Maxime Ripard , David Airlie , dri-devel@lists.freedesktop.org, Douglas Anderson , linux-kernel@vger.kernel.org Subject: [PATCH v3 03/16] drm/edid: Allow the querying/working with the panel ID from the EDID Date: Wed, 1 Sep 2021 13:19:21 -0700 Message-Id: <20210901131531.v3.3.I4a672175ba1894294d91d3dbd51da11a8239cf4a@changeid> X-Mailer: git-send-email 2.33.0.259.gc128427fd7-goog In-Reply-To: <20210901201934.1084250-1-dianders@chromium.org> References: <20210901201934.1084250-1-dianders@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org EDIDs have 32-bits worth of data which is intended to be used to uniquely identify the make/model of a panel. This has historically been used only internally in the EDID processing code to identify quirks with panels. We'd like to use this panel ID in panel-simple to identify which panel is hooked up and from that information figure out power sequence timings. Let's expose this information from the EDID code and also allow it to be accessed early, before a connector has been created. To make matching in the panel-simple code easier, we'll return the panel ID as a 32-bit value. We'll provide some functions for converting this value back and forth to something more human readable. Signed-off-by: Douglas Anderson --- Changes in v3: - Decode hex product ID w/ same endianness as everyone else. drivers/gpu/drm/drm_edid.c | 59 ++++++++++++++++++++++++++++++++++++++ include/drm/drm_edid.h | 47 ++++++++++++++++++++++++++++++ 2 files changed, 106 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index a22c38482a90..ac128bc3478a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2086,6 +2086,65 @@ struct edid *drm_get_edid(struct drm_connector *connector, } EXPORT_SYMBOL(drm_get_edid); +/** + * drm_get_panel_id - Get a panel's ID through DDC + * @adapter: I2C adapter to use for DDC + * + * This function reads the first block of the EDID of a panel and (assuming + * that the EDID is valid) extracts the ID out of it. The ID is a 32-bit value + * (16 bits of manufacturer ID and 16 bits of per-manufacturer ID) that's + * supposed to be different for each different modem of panel. + * + * This function is intended to be used during early probing on devices where + * more than one panel might be present. Because of its intended use it must + * assume that the EDID of the panel is correct, at least as far as the ID + * is concerned (in other words, we don't process any overrides here). + * + * NOTE: it's expected that this function and drm_do_get_edid() will both + * be read the EDID, but there is no caching between them. Since we're only + * reading the first block, hopefully this extra overhead won't be too big. + * + * Return: A 32-bit ID that should be different for each make/model of panel. + * See the functions encode_edid_id() and decode_edid_id() for some + * details on the structure of this ID. + */ +u32 drm_get_panel_id(struct i2c_adapter *adapter) +{ + struct edid *edid; + u32 val; + + edid = drm_do_get_edid_blk0(drm_do_probe_ddc_edid, adapter, NULL, NULL); + + /* + * There are no manufacturer IDs of 0, so if there is a problem reading + * the EDID then we'll just return 0. + */ + if (IS_ERR_OR_NULL(edid)) + return 0; + + /* + * In theory we could try to de-obfuscate this like edid_get_quirks() + * does, but it's easier to just deal with a 32-bit number. + * + * NOTE that we deal with endianness differently for the top half + * of this ID than for the bottom half. The bottom half (the product + * id) gets decoded as little endian by the EDID_PRODUCT_ID because + * that's how everyone seems to interpret it. The top half (the mfg_id) + * gets stored as big endian because that makes encode_edid_id() and + * decode_edid_id() easier to write (it's easier to extract the ASCII). + * It doesn't really matter, though, as long as the number here is + * unique. + */ + val = (u32)edid->mfg_id[0] << 24 | + (u32)edid->mfg_id[1] << 16 | + (u32)EDID_PRODUCT_ID(edid); + + kfree(edid); + + return val; +} +EXPORT_SYMBOL(drm_get_panel_id); + /** * drm_get_edid_switcheroo - get EDID data for a vga_switcheroo output * @connector: connector we're probing diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index deccfd39e6db..73da40d0b5d1 100644 --- a/include/drm/drm_edid.h +++ b/include/drm/drm_edid.h @@ -508,6 +508,52 @@ static inline u8 drm_eld_get_conn_type(const uint8_t *eld) return eld[DRM_ELD_SAD_COUNT_CONN_TYPE] & DRM_ELD_CONN_TYPE_MASK; } +/** + * encode_edid_id - Encode an ID for matching against drm_get_panel_id() + * @vend_chr_0: First character of the vendor string. + * @vend_chr_2: Second character of the vendor string. + * @vend_chr_3: Third character of the vendor string. + * @product_id: The 16-bit product ID. + * + * This is a macro so that it can be calculated at compile time and used + * as an initializer. + * + * For instance: + * encode_edid_id('B', 'O', 'E', 0x2d08) => 0x09e52d08 + * + * Return: a 32-bit ID per panel. + */ +#define encode_edid_id(vend_chr_0, vend_chr_1, vend_chr_2, product_id) \ + ((((u32)(vend_chr_0) - '@') & 0x1f) << 26 | \ + (((u32)(vend_chr_1) - '@') & 0x1f) << 21 | \ + (((u32)(vend_chr_2) - '@') & 0x1f) << 16 | \ + ((product_id) & 0xffff)) + +/** + * decode_edid_id - Decode a panel ID from encode_edid_id() + * @panel_id: The panel ID to decode. + * @vend: A 4-byte buffer to store the 3-letter vendor string plus a '\0' + * termination + * @product_id: The product ID will be returned here. + * + * For instance, after: + * decode_edid_id(0x09e52d08, vend, &product_id) + * These will be true: + * vend[0] = 'B' + * vend[1] = 'O' + * vend[2] = 'E' + * vend[3] = '\0' + * product_id = 0x2d08 + */ +static inline void decode_edid_id(u32 panel_id, char vend[4], u16 *product_id) +{ + *product_id = (u16)(panel_id & 0xffff); + vend[0] = '@' + ((panel_id >> 26) & 0x1f); + vend[1] = '@' + ((panel_id >> 21) & 0x1f); + vend[2] = '@' + ((panel_id >> 16) & 0x1f); + vend[3] = '\0'; +} + bool drm_probe_ddc(struct i2c_adapter *adapter); struct edid *drm_do_get_edid(struct drm_connector *connector, int (*get_edid_block)(void *data, u8 *buf, unsigned int block, @@ -515,6 +561,7 @@ struct edid *drm_do_get_edid(struct drm_connector *connector, void *data); struct edid *drm_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter); +u32 drm_get_panel_id(struct i2c_adapter *adapter); struct edid *drm_get_edid_switcheroo(struct drm_connector *connector, struct i2c_adapter *adapter); struct edid *drm_edid_duplicate(const struct edid *edid); From patchwork Wed Sep 1 20:19:23 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 505169 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F342DC19F38 for ; Wed, 1 Sep 2021 20:20:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CC13C6109E for ; Wed, 1 Sep 2021 20:20:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343698AbhIAUVh (ORCPT ); Wed, 1 Sep 2021 16:21:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245311AbhIAUVd (ORCPT ); Wed, 1 Sep 2021 16:21:33 -0400 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85F04C0612A3 for ; Wed, 1 Sep 2021 13:20:35 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id s11so632992pgr.11 for ; Wed, 01 Sep 2021 13:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Mz9HeGJ+K7sval94JDg800KjqgtCuquTPW7QtWQlZWM=; b=jzTj/pD5dkkQYgZIwhNNMzeq/pE4Xb6qyV9tG+wlV200QFulkiGCrLE2/ks/Oin4ki vV2AH4GTsmOhS/K6/mRqlC9T57ARHF/I0GeFIN7CwUdMWbgtxN3MLd45pO1gnwd79dab 11tmOHElLexVfJ2YrHXx/ZLy3hEYckYwe6dQk= 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=Mz9HeGJ+K7sval94JDg800KjqgtCuquTPW7QtWQlZWM=; b=m3l5ojHbCaQ1bvzICWDDhicJHbuYe8DrQ9yfgq6hYwjX2ooI1IAn/WeSzZOaJHJyyI HbuE0/yjuZ4y5N6v7WWAVn6IUGerBg2tdlgraIQ2bGpyBxeIbLJBZhCUYPQrqLK9lyKF P+e26yoWBuypo0eSw5mFt11hiYdZ0sa7OPDlpoWbSySa4O3y5QBgx2GoUqV3sg6XTScT UbCaS+0P2/NcqPZ9sBi6coAN2IFWVN4b6KLRtrN1XHU09857VWl8LeWvCE4rvMMbGVJJ BxxGvZ/+9s4VCMSeZ09Nl2usRPgrLPAMPP/Ni6wc4eWJZ0V+f2HLD3XEes8ZruMkCAV7 IvkQ== X-Gm-Message-State: AOAM532bzDty3la2W3/FdJ+hmjPRZtVf+l114jeKOXYgjo4No7FBPc7Z BX9KOyl1fVPB4hb4nDKwLg2uRw== X-Google-Smtp-Source: ABdhPJxVRZs2jI+b171j3PMFJmKPyxpXLuhuYzjmV3/PejX4NWlFwEV49rY4x+1i8NaXhx7JCu2hjA== X-Received: by 2002:a63:ff51:: with SMTP id s17mr762145pgk.415.1630527634673; Wed, 01 Sep 2021 13:20:34 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:958b:b561:a735:e774]) by smtp.gmail.com with ESMTPSA id x15sm321178pfq.31.2021.09.01.13.20.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Sep 2021 13:20:34 -0700 (PDT) From: Douglas Anderson To: Thierry Reding , Rob Herring , Sam Ravnborg Cc: Maarten Lankhorst , linux-arm-msm@vger.kernel.org, Bjorn Andersson , Linus W , Daniel Vetter , devicetree@vger.kernel.org, Steev Klimaszewski , Thomas Zimmermann , Maxime Ripard , David Airlie , dri-devel@lists.freedesktop.org, Douglas Anderson , linux-kernel@vger.kernel.org Subject: [PATCH v3 05/16] drm/panel-simple-edp: Split eDP panels out of panel-simple Date: Wed, 1 Sep 2021 13:19:23 -0700 Message-Id: <20210901131531.v3.5.I0a2f75bb822d17ce06f5b147734764eeb0c3e3df@changeid> X-Mailer: git-send-email 2.33.0.259.gc128427fd7-goog In-Reply-To: <20210901201934.1084250-1-dianders@chromium.org> References: <20210901201934.1084250-1-dianders@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org The panel-simple driver handles way too much. Let's start trying to get a handle on it by splitting out the eDP panels. This patch does this: 1. Start by copying simple-panel verbatim over to a new driver, simple-panel-edp. 2. Rename "panel_simple" to "panel_edp" in the new driver. 3. Keep only panels marked with `DRM_MODE_CONNECTOR_eDP` in the new driver. Remove those panels from the old driver. 4. Remove all recent "DP AUX bus" stuff from the old driver. The DP AUX bus is only possible on DP panels. 5. Remove all DSI / MIPI related functions from the new driver. 6. Remove bus_format / bus_flags from eDP driver. These things don't seem to make any sense for eDP panels so let's stop filling in made up stuff. In the end we end up with a bunch of duplicated code for now. Future patches will try to address _some_ of this duplicated code though some of it will be unavoidable. NOTE: This may not actually move all eDP panels over to the new driver since not all panels were properly marked with `DRM_MODE_CONNECTOR_eDP`. A future patch will attempt to move wayward panels I could identify but even so there may be some missed. Suggested-by: Sam Ravnborg Signed-off-by: Douglas Anderson --- I believe this is what Sam was looking for when he requested that the eDP panels split out [1]. Please yell if not. [1] https://lore.kernel.org/dri-devel/YRTsFNTn%2FT8fLxyB@ravnborg.org/ Changes in v3: - Split eDP panels patch new for v3. drivers/gpu/drm/panel/Kconfig | 16 +- drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-simple-edp.c | 1298 ++++++++++++++++++++++ drivers/gpu/drm/panel/panel-simple.c | 575 +--------- 4 files changed, 1323 insertions(+), 567 deletions(-) create mode 100644 drivers/gpu/drm/panel/panel-simple-edp.c diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 0b3784941312..4b7ff4ebdc34 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -77,14 +77,26 @@ config DRM_PANEL_LVDS backlight handling if the panel is attached to a backlight controller. config DRM_PANEL_SIMPLE - tristate "support for simple panels" + tristate "support for simple panels (other than eDP ones)" + depends on OF + depends on BACKLIGHT_CLASS_DEVICE + depends on PM + select VIDEOMODE_HELPERS + help + DRM panel driver for dumb non-eDP panels that need at most a regulator + and a GPIO to be powered up. Optionally a backlight can be attached so + that it can be automatically turned off when the panel goes into a + low power state. + +config DRM_PANEL_SIMPLE_EDP + tristate "support for simple Embedded DisplayPort panels" depends on OF depends on BACKLIGHT_CLASS_DEVICE depends on PM select VIDEOMODE_HELPERS select DRM_DP_AUX_BUS help - DRM panel driver for dumb panels that need at most a regulator and + DRM panel driver for dumb eDP panels that need at most a regulator and a GPIO to be powered up. Optionally a backlight can be attached so that it can be automatically turned off when the panel goes into a low power state. diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index 60c0149fc54a..640234d4d693 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -7,6 +7,7 @@ obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o +obj-$(CONFIG_DRM_PANEL_SIMPLE_EDP) += panel-simple-edp.o obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += panel-feiyang-fy07024di26a30d.o diff --git a/drivers/gpu/drm/panel/panel-simple-edp.c b/drivers/gpu/drm/panel/panel-simple-edp.c new file mode 100644 index 000000000000..5b47ee4bc338 --- /dev/null +++ b/drivers/gpu/drm/panel/panel-simple-edp.c @@ -0,0 +1,1298 @@ +/* + * Copyright (C) 2013, NVIDIA Corporation. All rights reserved. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sub license, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the + * next paragraph) shall be included in all copies or substantial portions + * of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include