public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sui Jingfeng <sui.jingfeng@linux.dev>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Phong LE <ple@baylibre.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Maxime Ripard <mripard@kernel.org>,
	Sui Jingfeng <suijingfeng@loongson.cn>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH 5/8] drm/bridge: it66121: Add a helper function to read chip id
Date: Fri, 17 Nov 2023 02:29:25 +0800	[thread overview]
Message-ID: <cc1bee15-f69f-4467-873d-c85cc09d60a0@linux.dev> (raw)
In-Reply-To: <CAA8EJprFjdrQtegJd5HyzGYQaMawwQOhvkE=SNqsdsBCrtfDTA@mail.gmail.com>

Hi,


On 2023/11/16 21:00, Dmitry Baryshkov wrote:
> On Thu, 16 Nov 2023 at 14:18, Sui Jingfeng <sui.jingfeng@linux.dev> wrote:
>> Hi,
>>
>>
>> On 2023/11/15 00:06, Dmitry Baryshkov wrote:
>>> On Tue, 14 Nov 2023 at 17:09, Sui Jingfeng <sui.jingfeng@linux.dev> wrote:
>>>> From: Sui Jingfeng <suijingfeng@loongson.cn>
>>>>
>>>> Read the required chip id data back by calling regmap_bulk_read() once,
>>>> reduce the number of local variables needed in it66121_probe() function.
>>>> And store its values into struct it66121_ctx, as it will be used latter.
>>>>
>>>> Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn>
>>>> ---
>>>>    drivers/gpu/drm/bridge/ite-it66121.c | 47 ++++++++++++++++++++--------
>>>>    1 file changed, 34 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c
>>>> index 7e473beefc79..f36d05331f25 100644
>>>> --- a/drivers/gpu/drm/bridge/ite-it66121.c
>>>> +++ b/drivers/gpu/drm/bridge/ite-it66121.c
>>>> @@ -313,6 +313,9 @@ struct it66121_ctx {
>>>>                   bool auto_cts;
>>>>           } audio;
>>>>           const struct it66121_chip_info *info;
>>>> +       u16 vender_id;
>>>> +       u16 device_id;
>>>> +       u8 revision;
>>> There is no need to store them, they are not used by the driver anywhere.
>>>
>>>>    };
>>>>
>>>>    static inline struct it66121_ctx *bridge_to_it66121(struct drm_bridge *bridge)
>>>> @@ -399,6 +402,30 @@ static void it66121_hw_reset(struct it66121_ctx *ctx)
>>>>           gpiod_set_value(ctx->gpio_reset, 0);
>>>>    }
>>>>
>>>> +static int it66121_read_chip_id(struct it66121_ctx *ctx, bool verbose)
>>>> +{
>>>> +       u8 id[4];
>>>> +       int ret;
>>>> +
>>>> +       ret = regmap_bulk_read(ctx->regmap, IT66121_VENDOR_ID0_REG, id, 4);
>>>> +       if (ret < 0) {
>>>> +               dev_err(ctx->dev, "Failed to read chip ID: %d\n", ret);
>>>> +               return ret;
>>>> +       }
>>>> +
>>>> +       ctx->vender_id = (u16)id[1] << 8 | id[0];
>>>> +       ctx->device_id = ((u16)(id[3] & IT66121_DEVICE_ID1_MASK) << 8 | id[2]);
>>>> +       /* Revision is shared with DEVICE_ID1 */
>>>> +       ctx->revision = FIELD_GET(IT66121_REVISION_MASK, id[3]);
>>>> +
>>>> +       if (verbose) {
>>>> +               dev_info(ctx->dev, "Found ITE66121: 0x%x%x, revision: %u\n",
>>>> +                        ctx->vender_id, ctx->device_id, ctx->revision);
>>>> +       }
>>>> +
>>>> +       return 0;
>>>> +}
>>>> +
>>>>    static inline int it66121_preamble_ddc(struct it66121_ctx *ctx)
>>>>    {
>>>>           return regmap_write(ctx->regmap, IT66121_MASTER_SEL_REG, IT66121_MASTER_SEL_HOST);
>>>> @@ -1561,7 +1588,6 @@ static const char * const it66121_supplies[] = {
>>>>
>>>>    static int it66121_probe(struct i2c_client *client)
>>>>    {
>>>> -       u32 revision_id, vendor_ids[2] = { 0 }, device_ids[2] = { 0 };
>>>>           int ret;
>>>>           struct it66121_ctx *ctx;
>>>>           struct device *dev = &client->dev;
>>>> @@ -1603,19 +1629,13 @@ static int it66121_probe(struct i2c_client *client)
>>>>           if (IS_ERR(ctx->regmap))
>>>>                   return PTR_ERR(ctx->regmap);
>>>>
>>>> -       regmap_read(ctx->regmap, IT66121_VENDOR_ID0_REG, &vendor_ids[0]);
>>>> -       regmap_read(ctx->regmap, IT66121_VENDOR_ID1_REG, &vendor_ids[1]);
>>>> -       regmap_read(ctx->regmap, IT66121_DEVICE_ID0_REG, &device_ids[0]);
>>>> -       regmap_read(ctx->regmap, IT66121_DEVICE_ID1_REG, &device_ids[1]);
>>>> -
>>>> -       /* Revision is shared with DEVICE_ID1 */
>>>> -       revision_id = FIELD_GET(IT66121_REVISION_MASK, device_ids[1]);
>>>> -       device_ids[1] &= IT66121_DEVICE_ID1_MASK;
>>>> +       ret = it66121_read_chip_id(ctx, false);
>>>> +       if (ret)
>>>> +               return ret;
>>>>
>>>> -       if ((vendor_ids[1] << 8 | vendor_ids[0]) != ctx->info->vid ||
>>>> -           (device_ids[1] << 8 | device_ids[0]) != ctx->info->pid) {
>>>> +       if (ctx->vender_id != ctx->info->vid ||
>>>> +           ctx->device_id != ctx->info->pid)
>> Q: There is no need to store them, they are not used by the driver anywhere.
>>
>> A: Here it is used, it is also used by the 0007-patch to get the entity(instance)-specific data.
> And the patch 7 will be changed once you have proper i2c client struct
> registered.
>
We will create a "wrong"i2c client intentionally by calling i2c_new_client_device, the "wrong" 
here means that 'board_info.type'  is not equal to "it66121" or "it6610".

I probably know what you means, but please note that we are not object you at here.
The reason why we prefer theit66121_get_match_data() over the i2c_get_match_data() is that our 
it66121_get_match_data()  works with *the least dependency*. Ourversion
don't rely on the DT to provide compatible strings. Because the it66121 itself already
provided constant hard-coded vender id and device id on-chip register. This is a bit
similar with the PCIe devices. This chip id speak everything about chip identify.
By re-arranging the variants into array, searching and matching against became
straight-forward. We can also utilize the vender id and device id information to
dynamic bind the instance specific functions *at the setup(probe) time*. Which helps
to untangle the it66121 and it6610 cases with function object. Currently they are
tangled. This is not a problem simply because the model supported is too small(less).


>>
>> Since it6610 was introduced, this is used for chip identifying.
>> It can also be used with in debugfs context, to show who I am.
> I'd say, there is little point in whoami debugfs files. Debugfs is for
> the useful information.
>
>>
>>>>                   return -ENODEV;
>>>> -       }
>>>>
>>>>           ctx->bridge.funcs = &it66121_bridge_funcs;
>>>>           ctx->bridge.of_node = dev->of_node;
>>>> @@ -1633,7 +1653,8 @@ static int it66121_probe(struct i2c_client *client)
>>>>
>>>>           drm_bridge_add(&ctx->bridge);
>>>>
>>>> -       dev_info(dev, "IT66121 revision %d probed\n", revision_id);
>>>> +       dev_info(dev, "IT66121 probed, chip id: 0x%x:0x%x, revision: %u\n",
>>>> +                ctx->vender_id, ctx->device_id, ctx->revision);
>>>>
>>>>           return 0;
>>>>    }
>>>> --
>>>> 2.34.1
>>>>
>
>

  reply	other threads:[~2023-11-16 18:29 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14 15:01 [PATCH 0/8] Allow link the it66121 display bridge driver as a lib Sui Jingfeng
2023-11-14 15:01 ` [PATCH 1/8] drm/bridge: it66121: Use dev replace ctx->dev in the it66121_probe() Sui Jingfeng
2023-11-14 16:01   ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 2/8] drm/bridge: it66121: Add bridge_to_it66121() helper and use it Sui Jingfeng
2023-11-14 16:01   ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 3/8] drm/bridge: it66121: Add a helper function to read bus width Sui Jingfeng
2023-11-14 16:03   ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 4/8] drm/bridge: it66121: Add a helper function to get the next bridge Sui Jingfeng
2023-11-14 16:05   ` Dmitry Baryshkov
2023-11-23  5:25     ` Sui Jingfeng
2023-11-23  7:54       ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 5/8] drm/bridge: it66121: Add a helper function to read chip id Sui Jingfeng
2023-11-14 16:06   ` Dmitry Baryshkov
2023-11-16 12:18     ` Sui Jingfeng
2023-11-16 13:00       ` Dmitry Baryshkov
2023-11-16 18:29         ` Sui Jingfeng [this message]
2023-11-16 22:00           ` Dmitry Baryshkov
2023-11-23  5:37         ` Sui Jingfeng
2023-11-23  7:48           ` Dmitry Baryshkov
2023-11-23 13:03             ` Sui Jingfeng
2023-11-14 15:01 ` [PATCH 6/8] drm/bridge: it66121: Add a helper to initialize the DRM bridge structure Sui Jingfeng
2023-11-14 16:10   ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 7/8] drm/bridge: it66121: Add another implementation for getting match data Sui Jingfeng
2023-11-14 16:00   ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib Sui Jingfeng
2023-11-14 16:30   ` Dmitry Baryshkov
2023-11-16  9:14     ` Sui Jingfeng
2023-11-16  9:30       ` Dmitry Baryshkov
2023-11-16 10:12         ` Sui Jingfeng
2023-11-16 11:19           ` Dmitry Baryshkov
2023-11-23  5:05             ` Sui Jingfeng
2023-11-23  8:08               ` Dmitry Baryshkov
2023-11-23 13:39                 ` Neil Armstrong
2023-11-23 16:20                   ` Sui Jingfeng
2023-11-23 15:41                 ` Sui Jingfeng
2023-11-23 16:06                   ` Dmitry Baryshkov
2023-11-23 16:29                     ` Sui Jingfeng
2023-11-23 17:04                 ` Sui Jingfeng
2023-11-23 17:39                   ` Dmitry Baryshkov
2023-11-23 17:52                 ` Sui Jingfeng
2023-11-24  7:38                   ` Maxime Ripard
2023-11-24  7:51                     ` Sui Jingfeng
2023-11-24  8:13                       ` Maxime Ripard
2023-11-24  8:48                         ` Sui Jingfeng
2023-11-25  2:30                         ` Sui Jingfeng
2023-11-16 10:29     ` Sui Jingfeng
2023-11-16 11:11       ` Dmitry Baryshkov
2023-11-16 11:15         ` Jani Nikula
2023-11-16 11:18     ` Sui Jingfeng
2023-11-16 11:29       ` Dmitry Baryshkov
2023-11-16 11:53         ` Sui Jingfeng
2023-11-16 12:07           ` Sui Jingfeng
2023-11-16 15:23             ` Dmitry Baryshkov
2023-11-16 17:18               ` Sui Jingfeng
2023-11-17  9:52                 ` Maxime Ripard
2023-11-17  4:24               ` Sui Jingfeng
2023-11-17  9:03                 ` Dmitry Baryshkov
2023-11-17 17:14                   ` Sui Jingfeng
2023-11-20  8:23                     ` Neil Armstrong
2023-11-17 17:35                   ` Sui Jingfeng
2023-11-20 10:06                     ` Dmitry Baryshkov
2023-11-17 12:13                 ` Maxime Ripard
2023-11-15 13:02   ` kernel test robot
2023-11-20  9:08   ` kernel test robot

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=cc1bee15-f69f-4467-873d-c85cc09d60a0@linux.dev \
    --to=sui.jingfeng@linux.dev \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=ple@baylibre.com \
    --cc=suijingfeng@loongson.cn \
    --cc=tzimmermann@suse.de \
    /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