[1/2] drm_edid: Add a function to get EDID base block

  It's found that some panels have variants that they share the same panel id
although their EDID and names are different. Besides panel id, now we need
the hash of entire EDID base block to distinguish these panel variants.

Add drm_edid_get_base_block to returns the EDID base block, so caller can
further use it to get panel id and/or the hash.

Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
---
 drivers/gpu/drm/drm_edid.c        | 55 +++++++++++++++++--------------
 drivers/gpu/drm/panel/panel-edp.c |  8 +++--
 include/drm/drm_edid.h            |  3 +-
 3 files changed, 38 insertions(+), 28 deletions(-)
  

Hi,

On Fri, Feb 23, 2024 at 2:40 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> @@ -2770,58 +2770,63 @@ static u32 edid_extract_panel_id(const struct edid *edid)
>  }
>
>  /**
> - * drm_edid_get_panel_id - Get a panel's ID through DDC
> - * @adapter: I2C adapter to use for DDC
> + * drm_edid_get_panel_id - Get a panel's ID from EDID base block
> + * @base_bock: EDID base block that contains panel ID.

s/base_bock/base_block, as identified by:

scripts/kernel-doc -v drivers/gpu/drm/drm_edid.c | less 2>&1

drivers/gpu/drm/drm_edid.c:2787: warning: Function parameter or struct
member 'base_block' not described in 'drm_edid_get_panel_id'
drivers/gpu/drm/drm_edid.c:2787: warning: Excess function parameter
'base_bock' description in 'drm_edid_get_panel_id'


>   *
> - * This function reads the first block of the EDID of a panel and (assuming
> + * This function uses 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.
>   *
> + * Return: A 32-bit ID that should be different for each make/model of panel.
> + *         See the functions drm_edid_encode_panel_id() and
> + *         drm_edid_decode_panel_id() for some details on the structure of this
> + *         ID.
> + */
> +u32 drm_edid_get_panel_id(void *base_block)
> +{
> +       return edid_extract_panel_id(base_block);
> +}
> +EXPORT_SYMBOL(drm_edid_get_panel_id);
> +
> +/**
> + * drm_edid_get_base_block - Get a panel's EDID base block
> + * @adapter: I2C adapter to use for DDC
> + *
> + * This function returns the first block of the EDID of a 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).
> + * assume that the EDID of the panel is correct, at least as far as the base
> + * block 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 drm_edid_encode_panel_id() and
> - *         drm_edid_decode_panel_id() for some details on the structure of this
> - *         ID.
> + * Caller should free the base block after use.

Don't you need a "Return:" clause here to document what you're returning?


Other than the kernel-doc nits, this looks fine to me.

Reviewed-by: Douglas Anderson <dianders@chromium.org>

It'll probably need at least an Ack from someone else in the DRM
community before it can land, though, since this is touching a core
file.


-Doug
  

On Fri, 23 Feb 2024, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> It's found that some panels have variants that they share the same panel id
> although their EDID and names are different. Besides panel id, now we need
> the hash of entire EDID base block to distinguish these panel variants.
>
> Add drm_edid_get_base_block to returns the EDID base block, so caller can
> further use it to get panel id and/or the hash.

Please reconsider the whole approach here.

Please let's not add single-use special case functions to read an EDID
base block.

Please consider reading the whole EDID, using the regular EDID reading
functions, and use that instead.

Most likely you'll only have 1-2 blocks anyway. And you might consider
caching the EDID in struct panel_edp if reading the entire EDID is too
slow. (And if it is, this is probably sensible even if the EDID only
consists of one block.)

Anyway, please do *not* merge this as-is.

BR,
Jani.

>
> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> ---
>  drivers/gpu/drm/drm_edid.c        | 55 +++++++++++++++++--------------
>  drivers/gpu/drm/panel/panel-edp.c |  8 +++--
>  include/drm/drm_edid.h            |  3 +-
>  3 files changed, 38 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 923c4423151c..55598ca4a5d1 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2770,58 +2770,63 @@ static u32 edid_extract_panel_id(const struct edid *edid)
>  }
>  
>  /**
> - * drm_edid_get_panel_id - Get a panel's ID through DDC
> - * @adapter: I2C adapter to use for DDC
> + * drm_edid_get_panel_id - Get a panel's ID from EDID base block
> + * @base_bock: EDID base block that contains panel ID.
>   *
> - * This function reads the first block of the EDID of a panel and (assuming
> + * This function uses 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.
>   *
> + * Return: A 32-bit ID that should be different for each make/model of panel.
> + *         See the functions drm_edid_encode_panel_id() and
> + *         drm_edid_decode_panel_id() for some details on the structure of this
> + *         ID.
> + */
> +u32 drm_edid_get_panel_id(void *base_block)
> +{
> +	return edid_extract_panel_id(base_block);
> +}
> +EXPORT_SYMBOL(drm_edid_get_panel_id);
> +
> +/**
> + * drm_edid_get_base_block - Get a panel's EDID base block
> + * @adapter: I2C adapter to use for DDC
> + *
> + * This function returns the first block of the EDID of a 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).
> + * assume that the EDID of the panel is correct, at least as far as the base
> + * block 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 drm_edid_encode_panel_id() and
> - *         drm_edid_decode_panel_id() for some details on the structure of this
> - *         ID.
> + * Caller should free the base block after use.
>   */
> -
> -u32 drm_edid_get_panel_id(struct i2c_adapter *adapter)
> +void *drm_edid_get_base_block(struct i2c_adapter *adapter)
>  {
>  	enum edid_block_status status;
>  	void *base_block;
> -	u32 panel_id = 0;
> -
> -	/*
> -	 * There are no manufacturer IDs of 0, so if there is a problem reading
> -	 * the EDID then we'll just return 0.
> -	 */
>  
>  	base_block = kzalloc(EDID_LENGTH, GFP_KERNEL);
>  	if (!base_block)
> -		return 0;
> +		return NULL;
>  
>  	status = edid_block_read(base_block, 0, drm_do_probe_ddc_edid, adapter);
>  
>  	edid_block_status_print(status, base_block, 0);
>  
> -	if (edid_block_status_valid(status, edid_block_tag(base_block)))
> -		panel_id = edid_extract_panel_id(base_block);
> -	else
> +	if (!edid_block_status_valid(status, edid_block_tag(base_block))) {
>  		edid_block_dump(KERN_NOTICE, base_block, 0);
> +		return NULL;
> +	}
>  
> -	kfree(base_block);
> -
> -	return panel_id;
> +	return base_block;
>  }
> -EXPORT_SYMBOL(drm_edid_get_panel_id);
> +EXPORT_SYMBOL(drm_edid_get_base_block);
>  
>  /**
>   * drm_get_edid_switcheroo - get EDID data for a vga_switcheroo output
> diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
> index bd71d239272a..f6ddbaa103b5 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -763,6 +763,7 @@ static const struct edp_panel_entry *find_edp_panel(u32 panel_id);
>  static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
>  {
>  	struct panel_desc *desc;
> +	void *base_block;
>  	u32 panel_id;
>  	char vend[4];
>  	u16 product_id;
> @@ -792,8 +793,11 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
>  		goto exit;
>  	}
>  
> -	panel_id = drm_edid_get_panel_id(panel->ddc);
> -	if (!panel_id) {
> +	base_block = drm_edid_get_base_block(panel->ddc);
> +	if (base_block) {
> +		panel_id = drm_edid_get_panel_id(base_block);
> +		kfree(base_block);
> +	} else {
>  		dev_err(dev, "Couldn't identify panel via EDID\n");
>  		ret = -EIO;
>  		goto exit;
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 7923bc00dc7a..56b60f9204d3 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -410,7 +410,8 @@ 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_edid_get_panel_id(struct i2c_adapter *adapter);
> +void *drm_edid_get_base_block(struct i2c_adapter *adapter);
> +u32 drm_edid_get_panel_id(void *base_block);
>  struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
>  				     struct i2c_adapter *adapter);
>  struct edid *drm_edid_duplicate(const struct edid *edid);
  

Hi,

On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Fri, 23 Feb 2024, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > It's found that some panels have variants that they share the same panel id
> > although their EDID and names are different. Besides panel id, now we need
> > the hash of entire EDID base block to distinguish these panel variants.
> >
> > Add drm_edid_get_base_block to returns the EDID base block, so caller can
> > further use it to get panel id and/or the hash.
>
> Please reconsider the whole approach here.
>
> Please let's not add single-use special case functions to read an EDID
> base block.
>
> Please consider reading the whole EDID, using the regular EDID reading
> functions, and use that instead.
>
> Most likely you'll only have 1-2 blocks anyway. And you might consider
> caching the EDID in struct panel_edp if reading the entire EDID is too
> slow. (And if it is, this is probably sensible even if the EDID only
> consists of one block.)

That makes a lot of sense! Not quite sure why I didn't just read the
whole EDID in the first place when trying to get the panel ID.

-Doug
  

On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Fri, 23 Feb 2024, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > It's found that some panels have variants that they share the same panel id
> > although their EDID and names are different. Besides panel id, now we need
> > the hash of entire EDID base block to distinguish these panel variants.
> >
> > Add drm_edid_get_base_block to returns the EDID base block, so caller can
> > further use it to get panel id and/or the hash.
>
> Please reconsider the whole approach here.
>
> Please let's not add single-use special case functions to read an EDID
> base block.
>
> Please consider reading the whole EDID, using the regular EDID reading
> functions, and use that instead.
>
> Most likely you'll only have 1-2 blocks anyway. And you might consider
> caching the EDID in struct panel_edp if reading the entire EDID is too
> slow. (And if it is, this is probably sensible even if the EDID only
> consists of one block.)
>
> Anyway, please do *not* merge this as-is.
>

hi Jani,

I sent a v2 here implementing this method:
https://lore.kernel.org/lkml/20240228011133.1238439-2-hsinyi@chromium.org/

We still have to read edid twice due to:
1. The first caller is in panel probe, at that time, connector is
still unknown, so we can't update connector status (eg. update
edid_corrupt).
2. It's possible that the connector can have some override
(drm_edid_override_get) to EDID, that is still unknown during the
first read.

> BR,
> Jani.
>
> >
> > Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
> > ---
> >  drivers/gpu/drm/drm_edid.c        | 55 +++++++++++++++++--------------
> >  drivers/gpu/drm/panel/panel-edp.c |  8 +++--
> >  include/drm/drm_edid.h            |  3 +-
> >  3 files changed, 38 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 923c4423151c..55598ca4a5d1 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -2770,58 +2770,63 @@ static u32 edid_extract_panel_id(const struct edid *edid)
> >  }
> >
> >  /**
> > - * drm_edid_get_panel_id - Get a panel's ID through DDC
> > - * @adapter: I2C adapter to use for DDC
> > + * drm_edid_get_panel_id - Get a panel's ID from EDID base block
> > + * @base_bock: EDID base block that contains panel ID.
> >   *
> > - * This function reads the first block of the EDID of a panel and (assuming
> > + * This function uses 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.
> >   *
> > + * Return: A 32-bit ID that should be different for each make/model of panel.
> > + *         See the functions drm_edid_encode_panel_id() and
> > + *         drm_edid_decode_panel_id() for some details on the structure of this
> > + *         ID.
> > + */
> > +u32 drm_edid_get_panel_id(void *base_block)
> > +{
> > +     return edid_extract_panel_id(base_block);
> > +}
> > +EXPORT_SYMBOL(drm_edid_get_panel_id);
> > +
> > +/**
> > + * drm_edid_get_base_block - Get a panel's EDID base block
> > + * @adapter: I2C adapter to use for DDC
> > + *
> > + * This function returns the first block of the EDID of a 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).
> > + * assume that the EDID of the panel is correct, at least as far as the base
> > + * block 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 drm_edid_encode_panel_id() and
> > - *         drm_edid_decode_panel_id() for some details on the structure of this
> > - *         ID.
> > + * Caller should free the base block after use.
> >   */
> > -
> > -u32 drm_edid_get_panel_id(struct i2c_adapter *adapter)
> > +void *drm_edid_get_base_block(struct i2c_adapter *adapter)
> >  {
> >       enum edid_block_status status;
> >       void *base_block;
> > -     u32 panel_id = 0;
> > -
> > -     /*
> > -      * There are no manufacturer IDs of 0, so if there is a problem reading
> > -      * the EDID then we'll just return 0.
> > -      */
> >
> >       base_block = kzalloc(EDID_LENGTH, GFP_KERNEL);
> >       if (!base_block)
> > -             return 0;
> > +             return NULL;
> >
> >       status = edid_block_read(base_block, 0, drm_do_probe_ddc_edid, adapter);
> >
> >       edid_block_status_print(status, base_block, 0);
> >
> > -     if (edid_block_status_valid(status, edid_block_tag(base_block)))
> > -             panel_id = edid_extract_panel_id(base_block);
> > -     else
> > +     if (!edid_block_status_valid(status, edid_block_tag(base_block))) {
> >               edid_block_dump(KERN_NOTICE, base_block, 0);
> > +             return NULL;
> > +     }
> >
> > -     kfree(base_block);
> > -
> > -     return panel_id;
> > +     return base_block;
> >  }
> > -EXPORT_SYMBOL(drm_edid_get_panel_id);
> > +EXPORT_SYMBOL(drm_edid_get_base_block);
> >
> >  /**
> >   * drm_get_edid_switcheroo - get EDID data for a vga_switcheroo output
> > diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
> > index bd71d239272a..f6ddbaa103b5 100644
> > --- a/drivers/gpu/drm/panel/panel-edp.c
> > +++ b/drivers/gpu/drm/panel/panel-edp.c
> > @@ -763,6 +763,7 @@ static const struct edp_panel_entry *find_edp_panel(u32 panel_id);
> >  static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
> >  {
> >       struct panel_desc *desc;
> > +     void *base_block;
> >       u32 panel_id;
> >       char vend[4];
> >       u16 product_id;
> > @@ -792,8 +793,11 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
> >               goto exit;
> >       }
> >
> > -     panel_id = drm_edid_get_panel_id(panel->ddc);
> > -     if (!panel_id) {
> > +     base_block = drm_edid_get_base_block(panel->ddc);
> > +     if (base_block) {
> > +             panel_id = drm_edid_get_panel_id(base_block);
> > +             kfree(base_block);
> > +     } else {
> >               dev_err(dev, "Couldn't identify panel via EDID\n");
> >               ret = -EIO;
> >               goto exit;
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 7923bc00dc7a..56b60f9204d3 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -410,7 +410,8 @@ 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_edid_get_panel_id(struct i2c_adapter *adapter);
> > +void *drm_edid_get_base_block(struct i2c_adapter *adapter);
> > +u32 drm_edid_get_panel_id(void *base_block);
> >  struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
> >                                    struct i2c_adapter *adapter);
> >  struct edid *drm_edid_duplicate(const struct edid *edid);
>
> --
> Jani Nikula, Intel
  

Hi,

On Tue, Feb 27, 2024 at 5:27 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>
> On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> >
> > On Fri, 23 Feb 2024, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > > It's found that some panels have variants that they share the same panel id
> > > although their EDID and names are different. Besides panel id, now we need
> > > the hash of entire EDID base block to distinguish these panel variants.
> > >
> > > Add drm_edid_get_base_block to returns the EDID base block, so caller can
> > > further use it to get panel id and/or the hash.
> >
> > Please reconsider the whole approach here.
> >
> > Please let's not add single-use special case functions to read an EDID
> > base block.
> >
> > Please consider reading the whole EDID, using the regular EDID reading
> > functions, and use that instead.
> >
> > Most likely you'll only have 1-2 blocks anyway. And you might consider
> > caching the EDID in struct panel_edp if reading the entire EDID is too
> > slow. (And if it is, this is probably sensible even if the EDID only
> > consists of one block.)
> >
> > Anyway, please do *not* merge this as-is.
> >
>
> hi Jani,
>
> I sent a v2 here implementing this method:
> https://lore.kernel.org/lkml/20240228011133.1238439-2-hsinyi@chromium.org/
>
> We still have to read edid twice due to:
> 1. The first caller is in panel probe, at that time, connector is
> still unknown, so we can't update connector status (eg. update
> edid_corrupt).
> 2. It's possible that the connector can have some override
> (drm_edid_override_get) to EDID, that is still unknown during the
> first read.

I'll also comment in Hsin-Yi's v2, but given Hsin-Yi's digging and the
fact that we can't cache the EDID (because we don't yet have a
"drm_connector"), I'd much prefer Hsin-Yi's solution here from v1 that
allows reading just the first block. If we try to boot a device with a
multi-block EDID we're now wastefully reading all the blocks of the
EDID twice at bootup which will slow boot time.

If you can see a good solution to avoid reading the EDID twice then
that would be amazing, but if not it seems like we should go back to
what's here in v1. What do you think? Anyone else have any opinions?



-Doug
  

On Wed, 28 Feb 2024, Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Tue, Feb 27, 2024 at 5:27 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>>
>> On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>> >
>> > On Fri, 23 Feb 2024, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
>> > > It's found that some panels have variants that they share the same panel id
>> > > although their EDID and names are different. Besides panel id, now we need
>> > > the hash of entire EDID base block to distinguish these panel variants.
>> > >
>> > > Add drm_edid_get_base_block to returns the EDID base block, so caller can
>> > > further use it to get panel id and/or the hash.
>> >
>> > Please reconsider the whole approach here.
>> >
>> > Please let's not add single-use special case functions to read an EDID
>> > base block.
>> >
>> > Please consider reading the whole EDID, using the regular EDID reading
>> > functions, and use that instead.
>> >
>> > Most likely you'll only have 1-2 blocks anyway. And you might consider
>> > caching the EDID in struct panel_edp if reading the entire EDID is too
>> > slow. (And if it is, this is probably sensible even if the EDID only
>> > consists of one block.)
>> >
>> > Anyway, please do *not* merge this as-is.
>> >
>>
>> hi Jani,
>>
>> I sent a v2 here implementing this method:
>> https://lore.kernel.org/lkml/20240228011133.1238439-2-hsinyi@chromium.org/
>>
>> We still have to read edid twice due to:
>> 1. The first caller is in panel probe, at that time, connector is
>> still unknown, so we can't update connector status (eg. update
>> edid_corrupt).
>> 2. It's possible that the connector can have some override
>> (drm_edid_override_get) to EDID, that is still unknown during the
>> first read.
>
> I'll also comment in Hsin-Yi's v2, but given Hsin-Yi's digging and the
> fact that we can't cache the EDID (because we don't yet have a
> "drm_connector"), I'd much prefer Hsin-Yi's solution here from v1 that
> allows reading just the first block. If we try to boot a device with a
> multi-block EDID we're now wastefully reading all the blocks of the
> EDID twice at bootup which will slow boot time.
>
> If you can see a good solution to avoid reading the EDID twice then
> that would be amazing, but if not it seems like we should go back to
> what's here in v1. What do you think? Anyone else have any opinions?

I haven't replied so far, because I've been going back and forth with
this. I'm afraid I don't really like either approach now. Handling the
no connector case in v2 is a bit ugly too. :(

Seems like you only need this to extend the panel ID with a hash. And
panel-edp.c is the only user of drm_edid_get_panel_id(). And EDID quirks
in drm_edid.c could theoretically hit the same problem you're solving.

So maybe something like:

	u32 drm_edid_get_panel_id(struct i2c_adapter *adapter, u32 *hash);

or if you want to be fancy add a struct capturing both id and hash:

	bool drm_edid_get_panel_id(struct i2c_adapter *adapter, struct drm_edid_panel_id *id);

And put the hash (or whatever mechanism you have) computation in
drm_edid.c. Just hide it all in drm_edid.c, and keep the EDID interfaces
neat.

How would that work for you?


BR,
Jani.
  

Hi,

On Thu, Feb 29, 2024 at 8:43 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Wed, 28 Feb 2024, Doug Anderson <dianders@chromium.org> wrote:
> > Hi,
> >
> > On Tue, Feb 27, 2024 at 5:27 PM Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >>
> >> On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula <jani.nikula@linuxintel.com> wrote:
> >> >
> >> > On Fri, 23 Feb 2024, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> >> > > It's found that some panels have variants that they share the same panel id
> >> > > although their EDID and names are different. Besides panel id, now we need
> >> > > the hash of entire EDID base block to distinguish these panel variants.
> >> > >
> >> > > Add drm_edid_get_base_block to returns the EDID base block, so caller can
> >> > > further use it to get panel id and/or the hash.
> >> >
> >> > Please reconsider the whole approach here.
> >> >
> >> > Please let's not add single-use special case functions to read an EDID
> >> > base block.
> >> >
> >> > Please consider reading the whole EDID, using the regular EDID reading
> >> > functions, and use that instead.
> >> >
> >> > Most likely you'll only have 1-2 blocks anyway. And you might consider
> >> > caching the EDID in struct panel_edp if reading the entire EDID is too
> >> > slow. (And if it is, this is probably sensible even if the EDID only
> >> > consists of one block.)
> >> >
> >> > Anyway, please do *not* merge this as-is.
> >> >
> >>
> >> hi Jani,
> >>
> >> I sent a v2 here implementing this method:
> >> https://lore.kernel.org/lkml/20240228011133.1238439-2-hsinyi@chromium.org/
> >>
> >> We still have to read edid twice due to:
> >> 1. The first caller is in panel probe, at that time, connector is
> >> still unknown, so we can't update connector status (eg. update
> >> edid_corrupt).
> >> 2. It's possible that the connector can have some override
> >> (drm_edid_override_get) to EDID, that is still unknown during the
> >> first read.
> >
> > I'll also comment in Hsin-Yi's v2, but given Hsin-Yi's digging and the
> > fact that we can't cache the EDID (because we don't yet have a
> > "drm_connector"), I'd much prefer Hsin-Yi's solution here from v1 that
> > allows reading just the first block. If we try to boot a device with a
> > multi-block EDID we're now wastefully reading all the blocks of the
> > EDID twice at bootup which will slow boot time.
> >
> > If you can see a good solution to avoid reading the EDID twice then
> > that would be amazing, but if not it seems like we should go back to
> > what's here in v1. What do you think? Anyone else have any opinions?
>
> I haven't replied so far, because I've been going back and forth with
> this. I'm afraid I don't really like either approach now. Handling the
> no connector case in v2 is a bit ugly too. :(
>
> Seems like you only need this to extend the panel ID with a hash. And
> panel-edp.c is the only user of drm_edid_get_panel_id(). And EDID quirks
> in drm_edid.c could theoretically hit the same problem you're solving.

Good point. That would imply that more of the logic could go into
"drm_edid.c" in case the EDID quirks code eventually needs it.


> So maybe something like:
>
>         u32 drm_edid_get_panel_id(struct i2c_adapter *adapter, u32 *hash);
>
> or if you want to be fancy add a struct capturing both id and hash:
>
>         bool drm_edid_get_panel_id(struct i2c_adapter *adapter, struct drm_edid_panel_id *id);
>
> And put the hash (or whatever mechanism you have) computation in
> drm_edid.c. Just hide it all in drm_edid.c, and keep the EDID interfaces
> neat.
>
> How would that work for you?

The problem is that Dmitry didn't like the idea of using a hash and in
v2 Hsin-Yi has moved to using the name of the display. ...except of
course that eDP panels don't always properly specify
"EDID_DETAIL_MONITOR_NAME". See the discussion [1]. If you want to see
some of the EDIDs involved, you can see Hsin-Yi's post [2]. The panels
included stuff like this:

    Alphanumeric Data String: 'AUO'
    Alphanumeric Data String: 'B116XAN04.0 '

The fact that there is more than one string in there makes it hard to
just "return" the display name in a generic way. The way Hsin-Yi's
code was doing it was that it would consider it a match if the panel
name was in any of the strings...

How about this as a solution: we change drm_edid_get_panel_id() to
return an opaque type (struct drm_edid_panel_id_blob) that's really
just the first block of the EDID but we can all pretend that it isn't.
Then we can add a function in drm_edid.c that takes this opaque blob,
a 32-bit integer (as per drm_edid_encode_panel_id()), and a string
name and it can tell us if the blob matches?


[1] https://lore.kernel.org/r/CAD=FV=VMVr+eJ7eyuLGa671fMgH6ZX9zPOkbKzYJ0H79MZ2k9A@mail.gmail.com
[2] https://lore.kernel.org/r/CAJMQK-gfKbdPhYJeCJ5UX0dNrx3y-EmLsTiv9nj+U3Rmej38pw@mail.gmail.com
  

On Thu, 29 Feb 2024 at 19:11, Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Thu, Feb 29, 2024 at 8:43 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> >
> > On Wed, 28 Feb 2024, Doug Anderson <dianders@chromium.org> wrote:
> > > Hi,
> > >
> > > On Tue, Feb 27, 2024 at 5:27 PM Hsin-Yi Wang <hsinyi@chromiumorg> wrote:
> > >>
> > >> On Tue, Feb 27, 2024 at 1:09 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > >> >
> > >> > On Fri, 23 Feb 2024, Hsin-Yi Wang <hsinyi@chromium.org> wrote:
> > >> > > It's found that some panels have variants that they share the same panel id
> > >> > > although their EDID and names are different. Besides panel id, now we need
> > >> > > the hash of entire EDID base block to distinguish these panel variants.
> > >> > >
> > >> > > Add drm_edid_get_base_block to returns the EDID base block, so caller can
> > >> > > further use it to get panel id and/or the hash.
> > >> >
> > >> > Please reconsider the whole approach here.
> > >> >
> > >> > Please let's not add single-use special case functions to read an EDID
> > >> > base block.
> > >> >
> > >> > Please consider reading the whole EDID, using the regular EDID reading
> > >> > functions, and use that instead.
> > >> >
> > >> > Most likely you'll only have 1-2 blocks anyway. And you might consider
> > >> > caching the EDID in struct panel_edp if reading the entire EDID is too
> > >> > slow. (And if it is, this is probably sensible even if the EDID only
> > >> > consists of one block.)
> > >> >
> > >> > Anyway, please do *not* merge this as-is.
> > >> >
> > >>
> > >> hi Jani,
> > >>
> > >> I sent a v2 here implementing this method:
> > >> https://lore.kernel.org/lkml/20240228011133.1238439-2-hsinyi@chromium.org/
> > >>
> > >> We still have to read edid twice due to:
> > >> 1. The first caller is in panel probe, at that time, connector is
> > >> still unknown, so we can't update connector status (eg. update
> > >> edid_corrupt).
> > >> 2. It's possible that the connector can have some override
> > >> (drm_edid_override_get) to EDID, that is still unknown during the
> > >> first read.
> > >
> > > I'll also comment in Hsin-Yi's v2, but given Hsin-Yi's digging and the
> > > fact that we can't cache the EDID (because we don't yet have a
> > > "drm_connector"), I'd much prefer Hsin-Yi's solution here from v1 that
> > > allows reading just the first block. If we try to boot a device with a
> > > multi-block EDID we're now wastefully reading all the blocks of the
> > > EDID twice at bootup which will slow boot time.
> > >
> > > If you can see a good solution to avoid reading the EDID twice then
> > > that would be amazing, but if not it seems like we should go back to
> > > what's here in v1. What do you think? Anyone else have any opinions?
> >
> > I haven't replied so far, because I've been going back and forth with
> > this. I'm afraid I don't really like either approach now. Handling the
> > no connector case in v2 is a bit ugly too. :(
> >
> > Seems like you only need this to extend the panel ID with a hash. And
> > panel-edp.c is the only user of drm_edid_get_panel_id(). And EDID quirks
> > in drm_edid.c could theoretically hit the same problem you're solving.
>
> Good point. That would imply that more of the logic could go into
> "drm_edid.c" in case the EDID quirks code eventually needs it.
>
>
> > So maybe something like:
> >
> >         u32 drm_edid_get_panel_id(struct i2c_adapter *adapter, u32 *hash);
> >
> > or if you want to be fancy add a struct capturing both id and hash:
> >
> >         bool drm_edid_get_panel_id(struct i2c_adapter *adapter, struct drm_edid_panel_id *id);
> >
> > And put the hash (or whatever mechanism you have) computation in
> > drm_edid.c. Just hide it all in drm_edid.c, and keep the EDID interfaces
> > neat.
> >
> > How would that work for you?
>
> The problem is that Dmitry didn't like the idea of using a hash and in
> v2 Hsin-Yi has moved to using the name of the display. ...except of
> course that eDP panels don't always properly specify
> "EDID_DETAIL_MONITOR_NAME". See the discussion [1]. If you want to see
> some of the EDIDs involved, you can see Hsin-Yi's post [2]. The panels
> included stuff like this:
>
>     Alphanumeric Data String: 'AUO'
>     Alphanumeric Data String: 'B116XAN04.0 '
>
> The fact that there is more than one string in there makes it hard to
> just "return" the display name in a generic way. The way Hsin-Yi's
> code was doing it was that it would consider it a match if the panel
> name was in any of the strings...
>
> How about this as a solution: we change drm_edid_get_panel_id() to
> return an opaque type (struct drm_edid_panel_id_blob) that's really
> just the first block of the EDID but we can all pretend that it isn't.
> Then we can add a function in drm_edid.c that takes this opaque blob,
> a 32-bit integer (as per drm_edid_encode_panel_id()), and a string
> name and it can tell us if the blob matches?

Would it be easier to push drm_edid_match to drm_edid.c? It looks way
more simpler than the opaque blob.

> [1] https://lore.kernel.org/r/CAD=FV=VMVr+eJ7eyuLGa671fMgH6ZX9zPOkbKzYJ0H79MZ2k9A@mail.gmail.com
> [2] https://lore.kernel.org/r/CAJMQK-gfKbdPhYJeCJ5UX0dNrx3y-EmLsTiv9nj+U3Rmej38pw@mail.gmail.com
  

Hi,

On Sun, Mar 3, 2024 at 1:30 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> > The problem is that Dmitry didn't like the idea of using a hash and in
> > v2 Hsin-Yi has moved to using the name of the display. ...except of
> > course that eDP panels don't always properly specify
> > "EDID_DETAIL_MONITOR_NAME". See the discussion [1]. If you want to see
> > some of the EDIDs involved, you can see Hsin-Yi's post [2]. The panels
> > included stuff like this:
> >
> >     Alphanumeric Data String: 'AUO'
> >     Alphanumeric Data String: 'B116XAN04.0 '
> >
> > The fact that there is more than one string in there makes it hard to
> > just "return" the display name in a generic way. The way Hsin-Yi's
> > code was doing it was that it would consider it a match if the panel
> > name was in any of the strings...
> >
> > How about this as a solution: we change drm_edid_get_panel_id() to
> > return an opaque type (struct drm_edid_panel_id_blob) that's really
> > just the first block of the EDID but we can all pretend that it isn't.
> > Then we can add a function in drm_edid.c that takes this opaque blob,
> > a 32-bit integer (as per drm_edid_encode_panel_id()), and a string
> > name and it can tell us if the blob matches?
>
> Would it be easier to push drm_edid_match to drm_edid.c? It looks way
> more simpler than the opaque blob.

Yeah, that sounds reasonable / cleaner to me. Good idea! Maybe Hsin-Yi
will be able to try this out and see if there's a reason it wouldn't
work.

-Doug