dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: "Neil Armstrong" <neil.armstrong@linaro.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Adam Ford" <aford173@gmail.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Abhinav Kumar" <quic_abhinavk@quicinc.com>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Javier Martinez Canillas" <javierm@redhat.com>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Bogdan Togorean" <bogdan.togorean@analog.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Ahmad Fatoum" <a.fatoum@pengutronix.de>
Subject: Re: [PATCH 5/7] drm: adv7511: Add has_dsi feature bit to struct adv7511_chip_info
Date: Wed, 30 Aug 2023 11:22:55 +0300	[thread overview]
Message-ID: <20230830082255.GL6477@pendragon.ideasonboard.com> (raw)
In-Reply-To: <OS0PR01MB5922682A64BA4EAF0B86344B86E7A@OS0PR01MB5922.jpnprd01.prod.outlook.com>

On Tue, Aug 29, 2023 at 03:42:40PM +0000, Biju Das wrote:
> Hi Laurent Pinchart,
> 
> Thanks for the feedback.
> 
> > Subject: Re: [PATCH 5/7] drm: adv7511: Add has_dsi feature bit to struct
> > adv7511_chip_info
> > 
> > Hi Biju,
> > 
> > On Tue, Aug 29, 2023 at 02:19:02PM +0000, Biju Das wrote:
> > > Subject: Re: [PATCH 5/7] drm: adv7511: Add has_dsi feature bit to
> > > struct adv7511_chip_info
> > > > On Sun, Aug 13, 2023 at 07:05:10PM +0100, Biju Das wrote:
> > > > > The ADV7533 and ADV7535 have DSI support. Add a feature bit
> > > > > has_dsi to struct adv7511_chip_info for handling configuration
> > related to DSI.
> > > > >
> > > > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > > > > ---
> > > > >  drivers/gpu/drm/bridge/adv7511/adv7511.h     |  1 +
> > > > >  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 20
> > > > > +++++++++++---------
> > > > >  2 files changed, 12 insertions(+), 9 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > > > b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > > > index b29d11cae932..2a017bb31a14 100644
> > > > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> > > > > @@ -339,6 +339,7 @@ struct adv7511_chip_info {
> > > > >  	unsigned long max_lane_freq;
> > > > >  	const char * const *supply_names;
> > > > >  	unsigned int num_supplies;
> > > > > +	unsigned has_dsi:1;
> > > >
> > > > As you're not short of space here, I'd make this a bool.
> > >
> > > OK, will use bool here.
> > >
> > > > >  };
> > > > >
> > > > >  struct adv7511 {
> > > > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > > index f6f15c1b0882..66b3f8fcf67d 100644
> > > > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > > @@ -373,7 +373,7 @@ static void adv7511_power_on(struct adv7511
> > *adv7511)
> > > > >  	 */
> > > > >  	regcache_sync(adv7511->regmap);
> > > > >
> > > > > -	if (adv7511->info->type == ADV7533 || adv7511->info->type ==
> > ADV7535)
> > > > > +	if (adv7511->info->has_dsi)
> > > > >  		adv7533_dsi_power_on(adv7511);
> > > > >  	adv7511->powered = true;
> > > > >  }
> > > > > @@ -397,7 +397,7 @@ static void __adv7511_power_off(struct adv7511
> > > > > *adv7511)  static void adv7511_power_off(struct adv7511 *adv7511)  {
> > > > >  	__adv7511_power_off(adv7511);
> > > > > -	if (adv7511->info->type == ADV7533 || adv7511->info->type ==
> > ADV7535)
> > > > > +	if (adv7511->info->has_dsi)
> > > > >  		adv7533_dsi_power_off(adv7511);
> > > > >  	adv7511->powered = false;
> > > > >  }
> > > > > @@ -786,7 +786,7 @@ static void adv7511_mode_set(struct adv7511
> > *adv7511,
> > > > >  	else
> > > > >  		low_refresh_rate = ADV7511_LOW_REFRESH_RATE_NONE;
> > > > >
> > > > > -	if (adv7511->info->type == ADV7511)
> > > > > +	if (!adv7511->info->has_dsi)
> > > >
> > > > While this is functionally equivalent, is the register below really
> > > > related to DSI ? If not, I'd rather not check the has_dsi field here
> > > > but keep checking the type.
> > >
> > > What creating a packed value for this hardware difference as driver
> > > data?
> > >
> > >  { 0xfb, 0x6, 0x1} and { 0x4a, 0xc, 2) packed as unsigned int driver
> > > data low_refresh_data and we can get rid of this if statement and
> > > depack it here.
> > 
> > As we're not in a hot path, I think the most important criteria to consider
> > are maintainability and readability. Making it easy to add support for a
> > new chip without creating a mess of spaghetti code falls into those
> > criteria, but as far as I'm aware there's no indication that we will
> > suddenly see several new compatible devices.
> > 
> > When it comes to readability, code such as
> > 
> > 	if (has_dsi)
> > 		init_dsi();
> > 
> > is great, but code such as
> > 
> > 	if (has_dsi)
> > 		init_cec();
> > 
> > because only the DSI-enabled version happens to also support CEC is not
> > good. Similarly, I don't think packing the refresh rate register addresses
> > and value in the info structure would increase readability, or help in any
> > real way. I'm tempted to leave it as-is.
> 
> Agreed. Will keep as it is for low_refresh_rate() change.
> 
> > 
> > What would help readability, if you feel inclined to keep working on this
> > driver, is to replace the register addresses with named macros :-)
> > 
> > > > >  		regmap_update_bits(adv7511->regmap, 0xfb,
> > > > >  				   0x6, low_refresh_rate << 1);
> > > > >  	else
> > > > > @@ -921,7 +921,7 @@ static enum drm_mode_status
> > > > > adv7511_bridge_mode_valid(struct drm_bridge *bridge,  {
> > > > >  	struct adv7511 *adv = bridge_to_adv7511(bridge);
> > > > >
> > > > > -	if (adv->info->type == ADV7533 || adv->info->type == ADV7535)
> > > > > +	if (adv->info->has_dsi)
> > > > >  		return adv7533_mode_valid(adv, mode);
> > > > >  	else
> > > > >  		return adv7511_mode_valid(adv, mode); @@ -1086,7 +1086,7
> > @@
> > > > > static int adv7511_init_cec_regmap(struct adv7511 *adv)
> > > > >  		goto err;
> > > > >  	}
> > > > >
> > > > > -	if (adv->info->type == ADV7533 || adv->info->type == ADV7535)
> > {
> > > > > +	if (adv->info->has_dsi) {
> > > >
> > > > Same comment here, this doesn't seem logically right.
> > >
> > > But this patching is applicable for DSI.
> > 
> > CEC is an HDMI feature. The ADV7511 may not have CEC support, but it's not
> > linked to DSI as such.
> 
> OK, what about using "has_cec" here instead, which avoids 2 run time comparisons against 1??

I'm OK with that.

> > > > >  		ret = adv7533_patch_cec_registers(adv);
> > > > >  		if (ret)
> > > > >  			goto err;
> > > > > @@ -1245,7 +1245,7 @@ static int adv7511_probe(struct i2c_client
> > *i2c)
> > > > >  		goto uninit_regulators;
> > > > >  	dev_dbg(dev, "Rev. %d\n", val);
> > > > >
> > > > > -	if (info->type == ADV7511)
> > > > > +	if (!info->has_dsi)
> > > >
> > > > And here too.
> > >
> > > Will create another bool. info->has_dpi, is it ok??
> > 
> > Can't we leave type comparisons in the handful of cases where they are
> > simpler ? Is there a specific reason why you think the type enum really has
> > to go ?
> 
> Agreed, will use type here as well.
> 
> > > > >  		ret = regmap_register_patch(adv7511->regmap,
> > > > >  					    adv7511_fixed_registers,
> > > > >
> > ARRAY_SIZE(adv7511_fixed_registers));
> > > > > @@ -1316,7 +1316,7 @@ static int adv7511_probe(struct i2c_client
> > > > > *i2c)
> > > > >
> > > > >  	adv7511_audio_init(dev, adv7511);
> > > > >
> > > > > -	if (info->type == ADV7533 || info->type == ADV7535) {
> > > > > +	if (info->has_dsi) {
> > > > >  		ret = adv7533_attach_dsi(adv7511);
> > > > >  		if (ret)
> > > > >  			goto err_unregister_audio;
> > > > > @@ -1370,7 +1370,8 @@ static const struct adv7511_chip_info
> > > > adv7533_chip_info = {
> > > > >  	.max_mode_clock = 80000,
> > > > >  	.max_lane_freq = 800000,
> > > > >  	.supply_names = adv7533_supply_names,
> > > > > -	.num_supplies = ARRAY_SIZE(adv7533_supply_names)
> > > > > +	.num_supplies = ARRAY_SIZE(adv7533_supply_names),
> > > > > +	.has_dsi = 1
> > > > >  };
> > > > >
> > > > >  static const struct adv7511_chip_info adv7535_chip_info = { @@
> > > > > -1378,7 +1379,8 @@ static const struct adv7511_chip_info
> > > > adv7535_chip_info = {
> > > > >  	.max_mode_clock = 148500,
> > > > >  	.max_lane_freq = 891000,
> > > > >  	.supply_names = adv7533_supply_names,
> > > > > -	.num_supplies = ARRAY_SIZE(adv7533_supply_names)
> > > > > +	.num_supplies = ARRAY_SIZE(adv7533_supply_names),
> > > > > +	.has_dsi = 1
> > > > >  };
> > > > >
> > > > >  static const struct i2c_device_id adv7511_i2c_ids[] = {

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2023-08-30  8:22 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-13 18:05 [PATCH 0/7] ADV7511 driver enhancements Biju Das
2023-08-13 18:05 ` [PATCH 1/7] drm: adv7511: Add struct adv7511_chip_info and use i2c_get_match_data() Biju Das
2023-08-18 14:49   ` Adam Ford
2023-08-29  7:22   ` Laurent Pinchart
2023-08-29 14:00     ` Biju Das
2023-08-13 18:05 ` [PATCH 2/7] drm: adv7511: Add max_mode_clock variable to struct adv7511_chip_info Biju Das
2023-08-28 22:36   ` Adam Ford
2023-08-29  7:23   ` Laurent Pinchart
2023-08-29 14:01     ` Biju Das
2023-08-13 18:05 ` [PATCH 3/7] drm: adv7511: Add max_lane_freq " Biju Das
2023-08-29  7:25   ` Laurent Pinchart
2023-08-29 14:05     ` Biju Das
2023-08-13 18:05 ` [PATCH 4/7] drm: adv7511: Add supply_names and num_supplies variables " Biju Das
2023-08-29  7:26   ` Laurent Pinchart
2023-08-29 14:06     ` Biju Das
2023-08-13 18:05 ` [PATCH 5/7] drm: adv7511: Add has_dsi feature bit " Biju Das
2023-08-29  7:30   ` Laurent Pinchart
2023-08-29 14:19     ` Biju Das
2023-08-29 15:35       ` Laurent Pinchart
2023-08-29 15:42         ` Biju Das
2023-08-30  8:22           ` Laurent Pinchart [this message]
2023-08-13 18:05 ` [PATCH 6/7] drm: adv7511: Add link_config " Biju Das
2023-08-29  7:34   ` Laurent Pinchart
2023-08-29 14:20     ` Biju Das
2023-08-13 18:05 ` [PATCH 7/7] drm: adv7511: Add hpd_override_enable " Biju Das
2023-08-18 12:41   ` Adam Ford
2023-08-18 13:34     ` Biju Das
2023-08-18 13:37       ` Adam Ford
2023-08-18 13:44         ` Biju Das
2023-08-29  7:36     ` Laurent Pinchart
2023-08-29 14:22       ` Biju Das
2023-08-18 13:56 ` [PATCH 0/7] ADV7511 driver enhancements Fabio Estevam

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=20230830082255.GL6477@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=aford173@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=bogdan.togorean@analog.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert+renesas@glider.be \
    --cc=javierm@redhat.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=rfoss@kernel.org \
    --cc=u.kleine-koenig@pengutronix.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