From: Jani Nikula <jani.nikula@linux.intel.com>
To: syyang <syyang@lontium.com>,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
andrzej.hajda@intel.com, neil.armstrong@linaro.org,
rfoss@kernel.org
Cc: Laurent.pinchart@ideasonboard.com, jonas@kwiboo.se,
jernej.skrabec@gmail.com, devicetree@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
yangsunyun1993@gmail.com, syyang <syyang@lontium.com>
Subject: Re: [PATCH v1 2/2] This patch adds a new DRM bridge driver for the Lontium LT9611C chip.
Date: Mon, 08 Sep 2025 14:03:45 +0300 [thread overview]
Message-ID: <52330c2afbf6bab7c06fbdd2b5cb9b2a4e24319b@intel.com> (raw)
In-Reply-To: <20250903123825.1721443-3-syyang@lontium.com>
On Wed, 03 Sep 2025, syyang <syyang@lontium.com> wrote:
> +static int lt9611c_read_edid(struct lt9611c *lt9611c)
> +{
> + struct device *dev = lt9611c->dev;
> + int ret, i, bytes_to_copy, offset = 0;
> + u8 packets_num;
> + u8 read_edid_data_cmd[5] = {0x52, 0x48, 0x33, 0x3A, 0x00};
> + u8 return_edid_data[37];
> + u8 read_edid_byte_num_cmd[5] = {0x52, 0x48, 0x32, 0x3A, 0x00};
> + u8 return_edid_byte_num[6];
> +
> + ret = i2c_read_write_flow(lt9611c, read_edid_byte_num_cmd, 5, return_edid_byte_num, 6);
> + if (ret) {
> + dev_err(dev, "Failed to read EDID byte number\n");
> + lt9611c->edid_valid = false;
> + return ret;
> + }
> +
> + lt9611c->edid_len = (return_edid_byte_num[4] << 8) | return_edid_byte_num[5];
> +
> + if (!lt9611c->edid_buf || lt9611c->edid_len > (lt9611c->edid_valid ?
> + lt9611c->edid_len : 0)) {
> + kfree(lt9611c->edid_buf);
> + lt9611c->edid_buf = kzalloc(lt9611c->edid_len, GFP_KERNEL);
> + if (!lt9611c->edid_buf) {
> + dev_err(dev, "Failed to allocate EDID buffer\n");
> + lt9611c->edid_len = 0;
> + lt9611c->edid_valid = false;
> + return -ENOMEM;
> + }
> + }
If you want to do caching, store a struct drm_edid pointer at a higher
level, not dumb buffers at the low level. Might be easier to start off
without any caching.
> +
> + packets_num = (lt9611c->edid_len % 32) ? (lt9611c->edid_len / 32 + 1) :
> + (lt9611c->edid_len / 32);
> + for (i = 0; i < packets_num; i++) {
> + read_edid_data_cmd[4] = (u8)i;
> + ret = i2c_read_write_flow(lt9611c, read_edid_data_cmd, 5, return_edid_data, 37);
> + if (ret) {
> + dev_err(dev, "Failed to read EDID packet %d\n", i);
> + lt9611c->edid_valid = false;
> + return -EIO;
> + }
> + offset = i * 32;
> + bytes_to_copy = min(32, lt9611c->edid_len - offset);
> + memcpy(lt9611c->edid_buf + offset, &return_edid_data[5], bytes_to_copy);
> + }
And really, you wouldn't have to implement the custom get edid block at
all, if you added a proper i2c adapter implementation and passed that to
drm_edid_read_ddc().
> +
> + lt9611c->edid_valid = true;
> +
> + return ret;
> +}
> +
> +static int lt9611c_get_edid_block(void *data, u8 *buf, unsigned int block, size_t len)
> +{
> + struct lt9611c *lt9611c = data;
> + struct device *dev = lt9611c->dev;
> + unsigned int total_blocks;
> + int ret;
> +
> + if (len > 128)
> + return -EINVAL;
> +
> + guard(mutex)(<9611c->ocm_lock);
> + if (block == 0 || !lt9611c->edid_valid) {
> + ret = lt9611c_read_edid(lt9611c);
> + if (ret) {
> + dev_err(dev, "EDID read failed\n");
> + return ret;
> + }
> + }
> +
> + total_blocks = lt9611c->edid_len / 128;
> + if (!total_blocks) {
> + dev_err(dev, "No valid EDID blocks\n");
> + return -EIO;
> + }
> +
> + if (block >= total_blocks) {
> + dev_err(dev, "Requested block %u exceeds total blocks %u\n",
> + block, total_blocks);
> + return -EINVAL;
> + }
> +
> + memcpy(buf, lt9611c->edid_buf + block * 128, len);
The get edid block hook is supposed to read *one* block. Can't you
implement reading one block? This now reads the entire edid for every
block.
Again, better yet, i2c adapter implementation.
> +
> + return 0;
> +}
> +
> +static const struct drm_edid *lt9611c_bridge_edid_read(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> +{
> + struct lt9611c *lt9611c = bridge_to_lt9611c(bridge);
> +
> + usleep_range(10000, 20000);
> + return drm_edid_read_custom(connector, lt9611c_get_edid_block, lt9611c);
> +}
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-09-08 11:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-03 12:38 [PATCH v1 0/2] Add LT9611C DRM bridge driver and device tree binding syyang
2025-09-03 12:38 ` [PATCH v1 1/2] This patch adds a new device tree binding documentation syyang
2025-09-03 16:33 ` Rob Herring (Arm)
2025-09-04 2:25 ` [PATCH v2 " syyang
2025-09-04 2:53 ` Dmitry Baryshkov
2025-09-04 5:49 ` Krzysztof Kozlowski
2025-09-04 8:08 ` 杨孙运
2025-09-04 8:26 ` Krzysztof Kozlowski
2025-09-04 11:27 ` 杨孙运
2025-09-04 2:21 ` [PATCH v1 " Dmitry Baryshkov
[not found] ` <CAFQXuNYKcGHyWLD5hjj24CrbaXzkaKsLU4R2vmhYaryQArA_yQ@mail.gmail.com>
2025-09-04 2:56 ` Dmitry Baryshkov
2025-09-03 12:38 ` [PATCH v1 2/2] This patch adds a new DRM bridge driver for the Lontium LT9611C chip syyang
2025-09-04 2:52 ` Dmitry Baryshkov
2025-09-04 10:48 ` 杨孙运
2025-09-04 11:04 ` Krzysztof Kozlowski
2025-09-04 11:17 ` 杨孙运
2025-09-04 14:39 ` Dmitry Baryshkov
2025-09-05 2:55 ` 杨孙运
2025-09-05 8:10 ` neil.armstrong
2025-09-05 8:58 ` 杨孙运
2025-09-05 14:24 ` Dmitry Baryshkov
2025-09-08 1:14 ` 杨孙运
2025-09-08 10:17 ` Dmitry Baryshkov
2025-09-05 14:10 ` Dmitry Baryshkov
2025-09-08 11:03 ` Jani Nikula [this message]
2025-09-08 11:07 ` Jani Nikula
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52330c2afbf6bab7c06fbdd2b5cb9b2a4e24319b@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=andrzej.hajda@intel.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=syyang@lontium.com \
--cc=yangsunyun1993@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®