All of 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: "Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Abhinav Kumar" <quic_abhinavk@quicinc.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Javier Martinez Canillas" <javierm@redhat.com>,
	"Ahmad Fatoum" <a.fatoum@pengutronix.de>,
	"Rob Herring" <robh@kernel.org>,
	"Bogdan Togorean" <bogdan.togorean@analog.com>,
	"Adam Ford" <aford173@gmail.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>
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

WARNING: multiple messages have this Message-ID (diff)
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 18:47 UTC|newest]

Thread overview: 64+ 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 ` 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-13 18:05   ` Biju Das
2023-08-18 14:49   ` Adam Ford
2023-08-18 14:49     ` Adam Ford
2023-08-29  7:22   ` Laurent Pinchart
2023-08-29  7:22     ` Laurent Pinchart
2023-08-29 14:00     ` Biju Das
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-13 18:05   ` Biju Das
2023-08-28 22:36   ` Adam Ford
2023-08-28 22:36     ` Adam Ford
2023-08-29  7:23   ` Laurent Pinchart
2023-08-29  7:23     ` Laurent Pinchart
2023-08-29 14:01     ` Biju Das
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-13 18:05   ` Biju Das
2023-08-29  7:25   ` Laurent Pinchart
2023-08-29  7:25     ` Laurent Pinchart
2023-08-29 14:05     ` Biju Das
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-13 18:05   ` Biju Das
2023-08-29  7:26   ` Laurent Pinchart
2023-08-29  7:26     ` Laurent Pinchart
2023-08-29 14:06     ` Biju Das
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-13 18:05   ` Biju Das
2023-08-29  7:30   ` Laurent Pinchart
2023-08-29  7:30     ` Laurent Pinchart
2023-08-29 14:19     ` Biju Das
2023-08-29 14:19       ` Biju Das
2023-08-29 15:35       ` Laurent Pinchart
2023-08-29 15:35         ` Laurent Pinchart
2023-08-29 15:42         ` Biju Das
2023-08-29 15:42           ` Biju Das
2023-08-30  8:22           ` Laurent Pinchart [this message]
2023-08-30  8:22             ` Laurent Pinchart
2023-08-13 18:05 ` [PATCH 6/7] drm: adv7511: Add link_config " Biju Das
2023-08-13 18:05   ` Biju Das
2023-08-29  7:34   ` Laurent Pinchart
2023-08-29  7:34     ` Laurent Pinchart
2023-08-29 14:20     ` Biju Das
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-13 18:05   ` Biju Das
2023-08-18 12:41   ` Adam Ford
2023-08-18 12:41     ` Adam Ford
2023-08-18 13:34     ` Biju Das
2023-08-18 13:34       ` Biju Das
2023-08-18 13:37       ` Adam Ford
2023-08-18 13:37         ` Adam Ford
2023-08-18 13:44         ` Biju Das
2023-08-18 13:44           ` Biju Das
2023-08-29  7:36     ` Laurent Pinchart
2023-08-29  7:36       ` Laurent Pinchart
2023-08-29 14:22       ` Biju Das
2023-08-29 14:22         ` Biju Das
2023-08-18 13:56 ` [PATCH 0/7] ADV7511 driver enhancements Fabio Estevam
2023-08-18 13:56   ` 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=airlied@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=daniel@ffwll.ch \
    --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=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.