From: Jani Nikula <jani.nikula@intel.com>
To: Melissa Wen <mwen@igalia.com>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
Ville Syrjala <ville.syrjala@linux.intel.com>,
Harry Wentland <harry.wentland@amd.com>,
Mario Limonciello <mario.limonciello@amd.com>,
Alex Hung <alex.hung@amd.com>
Subject: Re: [PATCH 0/4] drm/edid & drm/i915: vendor and product id logging improvements
Date: Mon, 08 Apr 2024 16:37:49 +0300 [thread overview]
Message-ID: <87h6gc9dqq.fsf@intel.com> (raw)
In-Reply-To: <y53wbwylvn4ybx3gdxb3r3w5harbkyavtqepdevnhygn5e63xs@z2iexp765n7o>
On Mon, 08 Apr 2024, Melissa Wen <mwen@igalia.com> wrote:
> On 04/08, Jani Nikula wrote:
>> On Mon, 08 Apr 2024, Melissa Wen <mwen@igalia.com> wrote:
>> > On 04/02, Jani Nikula wrote:
>> >> On Thu, 21 Mar 2024, Jani Nikula <jani.nikula@intel.com> wrote:
>> >> > Jani Nikula (4):
>> >> > drm/edid: add drm_edid_get_product_id()
>> >> > drm/edid: add drm_edid_print_product_id()
>> >> > drm/i915/bios: switch to struct drm_edid and struct
>> >> > drm_edid_product_id
>> >> > drm/i915/bios: return drm_edid_product_id from get_lvds_pnp_id()
>> >>
>> >> Ping for reviews please? This should be helpful in eradicating one class
>> >> of drm_edid_raw() uses.
>> >
>> > Hi Jani,
>> >
>> > I took a look at the series. AFAIU your solution with
>> > `drm_edid_product_id` mostly fits AMD display driver needs, except that
>> > it needs the `product_code` split into two parts (like manufacturer
>> > name) because the driver handles prod_code parts to configure a register
>> > for audio, as in the path below:
>> >
>> > 1. https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c#L113
>> > 2. https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/dc/core/dc_stream.c#L90
>> > 3. https://gitlab.freedesktop.org/drm/kernel/-/blob/drm-next/drivers/gpu/drm/amd/display/dc/dce/dce_audio.c#L873
>> >
>> > What do you think on keeping `prod_code` split into two part in
>> > `drm_edid_product_id`?
>>
>> I think having it as "__le16 product_code" is better and
>> self-documenting. This is what the spec says it is, so why split it to
>> two parts where you always need to wonder about the byte order?
>
> I have no strong opinion, I was only thinking that two parts would make
> this `edid_buf->prod_code[0] | edid_buf->prod_code[1] << 8` operation
> more intuitive.
>
> As you mentioned the currrent product_code format fits specs better, I
> understand we can get the same result on amd with:
> le16_to_cpu() --> split --> second part shift.
Wait, what? No. le16_to_cpu() directly gives you what you want. That's
the whole point. No splits, no shifts, no OR-ing. One macro that forces
the right byte order for you, as the member is defined __le16.
> Anyway, it's certainly not a blocker. The series LGTM.
>
> Acked-by: Melissa Wen <mwen@igalia.com>
>
>>
>> This is how you'd use it:
>>
>> edid_caps->product_id = le16_to_cpu(id->product_code);
This is intended to be an example how to deal with your URL 1 above.
BR,
Jani.
>>
>> BR,
>> Jani.
>>
>> >
>> > (cc'ing some AMD devs that might have a better understanding of this use case)
>> >
>> > Thanks a lot for addressing this pending issue!
>> >
>> > Melissa
>> >
>> >>
>> >> BR,
>> >> Jani.
>> >>
>> >>
>> >> >
>> >> > drivers/gpu/drm/drm_edid.c | 50 +++++++++++++++++++++++
>> >> > drivers/gpu/drm/i915/display/intel_bios.c | 49 ++++++++++------------
>> >> > include/drm/drm_edid.h | 28 ++++++++++---
>> >> > 3 files changed, 94 insertions(+), 33 deletions(-)
>> >>
>> >> --
>> >> Jani Nikula, Intel
>>
>> --
>> Jani Nikula, Intel
--
Jani Nikula, Intel
prev parent reply other threads:[~2024-04-08 13:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-21 10:05 [PATCH 0/4] drm/edid & drm/i915: vendor and product id logging improvements Jani Nikula
2024-03-21 10:05 ` [PATCH 1/4] drm/edid: add drm_edid_get_product_id() Jani Nikula
2024-04-08 18:10 ` Ville Syrjälä
2024-04-09 7:42 ` Jani Nikula
2024-03-21 10:05 ` [PATCH 2/4] drm/edid: add drm_edid_print_product_id() Jani Nikula
2024-04-08 18:05 ` Ville Syrjälä
2024-04-09 9:41 ` Jani Nikula
2024-03-21 10:05 ` [PATCH 3/4] drm/i915/bios: switch to struct drm_edid and struct drm_edid_product_id Jani Nikula
2024-03-21 10:05 ` [PATCH 4/4] drm/i915/bios: return drm_edid_product_id from get_lvds_pnp_id() Jani Nikula
2024-04-02 8:49 ` [PATCH 0/4] drm/edid & drm/i915: vendor and product id logging improvements Jani Nikula
2024-04-08 12:34 ` Melissa Wen
2024-04-08 13:05 ` Jani Nikula
2024-04-08 13:30 ` Melissa Wen
2024-04-08 13:37 ` Jani Nikula [this message]
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=87h6gc9dqq.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=alex.hung@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mario.limonciello@amd.com \
--cc=mwen@igalia.com \
--cc=ville.syrjala@linux.intel.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;
as well as URLs for NNTP newsgroup(s).