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:05:45 +0300 [thread overview]
Message-ID: <87o7ak9f86.fsf@intel.com> (raw)
In-Reply-To: <2qptajfrvnotxjyymphzrqyjxcrof46rlnjto62j6wtkanzk5g@e6oek426opcj>
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?
This is how you'd use it:
edid_caps->product_id = le16_to_cpu(id->product_code);
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
next prev parent reply other threads:[~2024-04-08 13:05 UTC|newest]
Thread overview: 17+ 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-03-21 11:03 ` ✗ Fi.CI.SPARSE: warning for drm/edid & drm/i915: vendor and product id logging improvements Patchwork
2024-03-21 11:16 ` ✓ Fi.CI.BAT: success " Patchwork
2024-03-22 2:27 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-04-02 8:49 ` [PATCH 0/4] " Jani Nikula
2024-04-08 12:34 ` Melissa Wen
2024-04-08 13:05 ` Jani Nikula [this message]
2024-04-08 13:30 ` Melissa Wen
2024-04-08 13:37 ` 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=87o7ak9f86.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).