dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: "Corey Minyard" <cminyard@mvista.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Antonio Borneo" <antonio.borneo@foss.st.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Marek Behún" <kabel@kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Kieran Bingham" <kieran.bingham@ideasonboard.com>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"Alessandro Zummo" <a.zummo@towertech.it>,
	"Jiasheng Jiang" <jiasheng@iscas.ac.cn>,
	"Abhinav Kumar" <quic_abhinavk@quicinc.com>,
	"Fabrizio Castro" <fabrizio.castro.jz@renesas.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Ahmad Fatoum" <a.fatoum@pengutronix.de>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Wolfram Sang" <wsa@kernel.org>,
	"Hans Verkuil" <hverkuil-cisco@xs4all.nl>
Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
Date: Wed, 31 May 2023 16:35:28 +0300	[thread overview]
Message-ID: <20230531133528.GH27043@pendragon.ideasonboard.com> (raw)
In-Reply-To: <OS0PR01MB592217BBDCD7C0072F24493D86489@OS0PR01MB5922.jpnprd01.prod.outlook.com>

On Wed, May 31, 2023 at 12:53:18PM +0000, Biju Das wrote:
> > Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API
> > On Wed, May 31, 2023 at 09:34:06AM +0000, Biju Das wrote:
> > > > Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device
> > > > API On Mon, May 29, 2023 at 09:00:43AM +0000, Biju Das wrote:
> > > > > > Subject: Re: [PATCH v5 01/11] i2c: Enhance
> > > > > > i2c_new_ancillary_device API On Mon, May 22, 2023 at 11:18:39AM +0100, Biju Das wrote:
> > > > > > > Renesas PMIC RAA215300 exposes two separate i2c devices, one
> > > > > > > for the main device and another for rtc device.
> > > > > > >
> > > > > > > Enhance i2c_new_ancillary_device() to instantiate a real device.
> > > > > >
> > > > > > Doesn't it already instantiate a real device ?
> > > > >
> > > > And that function calls i2c_new_client_device(), which allocates a
> > > > struct i2c_client that embeds a struct device, and registers that
> > > > device with the kernel device core. How is that different, in terms
> > > > of instantiating a "real device", from what this patch does ?
> > >
> > > There is a difference, right? it instantiates new "i2c dummy client"
> > > driver and a "real i2c client device" driver like rtc device
> > client(rtc-isl2108)??
> > 
> > I don't see how there's a difference in behaviour in the code you have
> > implemented, sorry.
> 
> Will reword,
> 
> Enhance i2c_new_ancillary_device() to instantiate a "I2C client device"
> apart from the already supported "I2C dummy client device".
> 
> > > > > > > (eg: Instantiate rtc device from PMIC driver)
> > > > > > >
> > > > > > > Added helper function __i2c_new_dummy_device to share the code
> > > > > > > between i2c_new_dummy_device and i2c_new_ancillary_device().
> > > > > > >
> > > > > > > Also added helper function __i2c_new_client_device() to pass
> > > > > > > parent dev parameter, so that the ancillary device can assign
> > > > > > > its parent during creation.
> > > > > > >
> > > > > > > Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > > > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > > > > > > ---
> > > > > > > v4->v5:
> > > > > > >  * Replaced parameter dev->parent in __i2c_new_client_device() and
> > > > > > >    __i2c_new_dummy_device().
> > > > > > >  * Improved error message in __i2c_new_dummy_device() by printing device name.
> > > > > > >  * Updated comment for ancillary's device parent
> > > > > > >  * Dropped aux_device_name check in i2c_new_ancillary_device().
> > > > > > > v3->v4:
> > > > > > >  * Dropped Rb tag from Geert as there are new changes.
> > > > > > >  * Introduced __i2c_new_dummy_device() to share the code between
> > > > > > >    i2c_new_dummy_device and i2c_new_ancillary_device().
> > > > > > >  * Introduced __i2c_new_client_device() to pass parent dev
> > > > > > >    parameter, so that the ancillary device can assign its parent during
> > > > > > >    creation.
> > > > > > > v3:
> > > > > > >  * New patch
> > > > > > >
> > > > > > > Ref:
> > > > > > >
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c |  6 +-
> > > > > > >  drivers/i2c/i2c-core-base.c                  | 92 +++++++++++++-------
> > > > > > >  drivers/media/i2c/adv748x/adv748x-core.c     |  2 +-
> > > > > > >  drivers/media/i2c/adv7604.c                  |  3 +-
> > > > > > >  include/linux/i2c.h                          |  3 +-
> > > > > > >  5 files changed, 69 insertions(+), 37 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > > > > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > > > > index ddceafa7b637..86306b010a0a 100644
> > > > > > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > > > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > > > > > > @@ -1072,7 +1072,7 @@ static int
> > > > > > > adv7511_init_cec_regmap(struct adv7511 *adv)
> > > > > > >  	int ret;
> > > > > > >
> > > > > > >  	adv->i2c_cec = i2c_new_ancillary_device(adv->i2c_main, "cec",
> > > > > > > -						ADV7511_CEC_I2C_ADDR_DEFAULT);
> > > > > > > +				    ADV7511_CEC_I2C_ADDR_DEFAULT, NULL);
> > > > > > >  	if (IS_ERR(adv->i2c_cec))
> > > > > > >  		return PTR_ERR(adv->i2c_cec);
> > > > > > >
> > > > > > > @@ -1261,7 +1261,7 @@ static int adv7511_probe(struct i2c_client *i2c)
> > > > > > >  	adv7511_packet_disable(adv7511, 0xffff);
> > > > > > >
> > > > > > >  	adv7511->i2c_edid = i2c_new_ancillary_device(i2c, "edid",
> > > > > > > -					ADV7511_EDID_I2C_ADDR_DEFAULT);
> > > > > > > +					ADV7511_EDID_I2C_ADDR_DEFAULT, NULL);
> > > > > > >  	if (IS_ERR(adv7511->i2c_edid)) {
> > > > > > >  		ret = PTR_ERR(adv7511->i2c_edid);
> > > > > > >  		goto uninit_regulators;
> > > > > > > @@ -1271,7 +1271,7 @@ static int adv7511_probe(struct i2c_client *i2c)
> > > > > > >  		     adv7511->i2c_edid->addr << 1);
> > > > > > >
> > > > > > >  	adv7511->i2c_packet = i2c_new_ancillary_device(i2c, "packet",
> > > > > > > -					ADV7511_PACKET_I2C_ADDR_DEFAULT);
> > > > > > > +					ADV7511_PACKET_I2C_ADDR_DEFAULT, NULL);
> > > > > > >  	if (IS_ERR(adv7511->i2c_packet)) {
> > > > > > >  		ret = PTR_ERR(adv7511->i2c_packet);
> > > > > > >  		goto err_i2c_unregister_edid; diff --git
> > > > > > > a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> > > > > > > index ae3af738b03f..3442aa80290f
> > > > > > > 100644
> > > > > > > --- a/drivers/i2c/i2c-core-base.cvvccc
> > > > > > > +++ b/drivers/i2c/i2c-core-base.cckvlrgnulkj
> > > > > > > @@ -893,24 +893,10 @@ int i2c_dev_irq_from_resources(const struct resource *resources,
> > > > > > >  	return 0;
> > > > > > >  }
> > > > > > >
> > > > > > > -/**
> > > > > > > - * i2c_new_client_device - instantiate an i2c device
> > > > > > > - * @adap: the adapter managing the device
> > > > > > > - * @info: describes one I2C device; bus_num is ignored
> > > > > > > - * Context: can sleep
> > > > > > > - *
> > > > > > > - * Create an i2c device. Binding is handled through driver model
> > > > > > > - * probe()/remove() methods.  A driver may be bound to this device when we
> > > > > > > - * return from this function, or any later moment (e.g. maybe hotplugging will
> > > > > > > - * load the driver module).  This call is not appropriate for use by mainboard
> > > > > > > - * initialization logic, which usually runs during an arch_initcall() long
> > > > > > > - * before any i2c_adapter could exist.
> > > > > > > - *
> > > > > > > - * This returns the new i2c client, which may be saved for later use with
> > > > > > > - * i2c_unregister_device(); or an ERR_PTR to describe the error.
> > > > > > > - */
> > > > > > > -struct i2c_client *
> > > > > > > -i2c_new_client_device(struct i2c_adapter *adap, struct
> > > > > > > i2c_board_info const *info)
> > > > > > > +static struct i2c_client *
> > > > > > > +__i2c_new_client_device(struct i2c_adapter *adap,
> > > > > > > +			struct i2c_board_info const *info,
> > > > > > > +			struct device *parent)
> > > > > > >  {
> > > > > > >  	struct i2c_client	*client;
> > > > > > >  	int			status;
> > > > > > > @@ -944,7 +930,7 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf
> > > > > > >  	if (status)
> > > > > > >  		goto out_err;
> > > > > > >
> > > > > > > -	client->dev.parent = &client->adapter->dev;
> > > > > > > +	client->dev.parent = parent ? parent : &client->adapter->dev;
> > > > > > >  	client->dev.bus = &i2c_bus_type;
> > > > > > >  	client->dev.type = &i2c_client_type;
> > > > > > >  	client->dev.of_node = of_node_get(info->of_node); @@ -984,6
> > > > > > > +970,28 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf
> > > > > > >  	kfree(client);
> > > > > > >  	return ERR_PTR(status);
> > > > > > >  }
> > > > > > > +
> > > > > > > +/**
> > > > > > > + * i2c_new_client_device - instantiate an i2c device
> > > > > > > + * @adap: the adapter managing the device
> > > > > > > + * @info: describes one I2C device; bus_num is ignored
> > > > > > > + * Context: can sleep
> > > > > > > + *
> > > > > > > + * Create an i2c device. Binding is handled through driver model
> > > > > > > + * probe()/remove() methods.  A driver may be bound to this device when we
> > > > > > > + * return from this function, or any later moment (e.g. maybe hotplugging will
> > > > > > > + * load the driver module).  This call is not appropriate for use by mainboard
> > > > > > > + * initialization logic, which usually runs during an arch_initcall() long
> > > > > > > + * before any i2c_adapter could exist.
> > > > > > > + *
> > > > > > > + * This returns the new i2c client, which may be saved for later use with
> > > > > > > + * i2c_unregister_device(); or an ERR_PTR to describe the error.
> > > > > > > + */
> > > > > > > +struct i2c_client *
> > > > > > > +i2c_new_client_device(struct i2c_adapter *adap, struct
> > > > > > > +i2c_board_info const *info) {
> > > > > > > +	return __i2c_new_client_device(adap, info, NULL); }
> > > > > > >  EXPORT_SYMBOL_GPL(i2c_new_client_device);
> > > > > > >
> > > > > > >  /**
> > > > > > > @@ -1054,6 +1062,26 @@ static struct i2c_driver dummy_driver = {
> > > > > > >  	.id_table	= dummy_id,
> > > > > > >  };
> > > > > > >
> > > > > > > +static struct i2c_client *__i2c_new_dummy_device(struct i2c_adapter *adapter,
> > > > > > > +						 u16 address, const char *name,
> > > > > > > +						 struct device *parent) {
> > > > > > > +	struct i2c_board_info info = {
> > > > > > > +		I2C_BOARD_INFO("dummy", address),
> > > > > > > +	};
> > > > > > > +
> > > > > > > +	if (name) {
> > > > > > > +		ssize_t ret = strscpy(info.type, name, sizeof(info.type));
> > > > > > > +
> > > > > > > +		if (ret < 0)
> > > > > > > +			return ERR_PTR(dev_err_probe(&adapter->dev, ret,
> > > > > > > +						     "Invalid device name: %s\n",
> > > > > > > +						     name));
> > > > > > > +	}
> > > > > > > +
> > > > > > > +	return __i2c_new_client_device(adapter, &info, parent); }
> > > > > > > +
> > > > > > >  /**
> > > > > > >   * i2c_new_dummy_device - return a new i2c device bound to a dummy driver
> > > > > > >   * @adapter: the adapter managing the device
> > > > > > > @@ -1074,11 +1102,7 @@ static struct i2c_driver dummy_driver = {
> > > > > > >   */
> > > > > > >  struct i2c_client *i2c_new_dummy_device(struct i2c_adapter *adapter, u16 address)  {
> > > > > > > -	struct i2c_board_info info = {
> > > > > > > -		I2C_BOARD_INFO("dummy", address),
> > > > > > > -	};
> > > > > > > -
> > > > > > > -	return i2c_new_client_device(adapter, &info);
> > > > > > > +	return __i2c_new_dummy_device(adapter, address, NULL, NULL);
> > > > > > >  }
> > > > > > >  EXPORT_SYMBOL_GPL(i2c_new_dummy_device);
> > > > > > >
> > > > > > > @@ -1122,15 +1146,19 @@ EXPORT_SYMBOL_GPL(devm_i2c_new_dummy_device);
> > > > > > >   * @client: Handle to the primary client
> > > > > > >   * @name: Handle to specify which secondary address to get
> > > > > > >   * @default_addr: Used as a fallback if no secondary address was specified
> > > > > > > + * @aux_device_name: Ancillary device name
> > > > > > >   * Context: can sleep
> > > > > > >   *
> > > > > > >   * I2C clients can be composed of multiple I2C slaves bound together in a single
> > > > > > >   * component. The I2C client driver then binds to the master I2C slave and needs
> > > > > > > - * to create I2C dummy clients to communicate with all the other slaves.
> > > > > > > + * to create I2C ancillary clients to communicate with all the other slaves.
> > > > > > >   *
> > > > > > > - * This function creates and returns an I2C dummy client whose I2C address is
> > > > > > > - * retrieved from the platform firmware based on the given slave name. If no
> > > > > > > - * address is specified by the firmware default_addr is used.
> > > > > > > + * This function creates and returns an I2C ancillary client whose I2C address
> > > > > > > + * is retrieved from the platform firmware based on the given slave name. if
> > > > > > > + * aux_device_name is specified by the firmware,
> > > > > >
> > > > > > Unless I'm missing something, aux_device_name isn't specified by
> > > > > > the firmware, it's a function parameter.
> > > > >
> > > > > It is specified in the platform firmware(device tree firmware).
> > > >
> > > > What I meant, in the context of the documentation here, is that the
> > > > address is retrieved from the platform firmware by the
> > > > i2c_new_ancillary_device() function, not passed as a parameter,
> > > > while the name is passed as a parameter. It's not relevant, for the
> > > > documentation of this function, where the caller gets the name from.
> > >
> > > Are you ok with these wordings?
> > >
> > > * This function creates and returns an I2C ancillary client whose I2C address
> > > * is retrieved from the platform firmware based on the given slave name. If
> > > * aux_device_name is not NULL, the ancillary's device parent
> > > * will be set to the primary device otherwise it will be set to I2C adapter.
> > 
> > The wording is better, but this is not what you have implemented in the
> > code. The name doesn't select which parent is used.
> 
> It is the same implemented in the code.
> 
> For the existing users, aux_device_name is NULL --> The parent is set
> as "I2C adapter".
> 
> For instantiating a "i2c client device", aux_device_name is not NULL
> --> The parent is set as primary device.
> 
> The primary device is the one instantiated the "i2c client device" using
> i2c_new_ancillary_device().
> 
> Please correct me if anything wrong here.

Before your patch:

struct i2c_client *i2c_new_ancillary_device(struct i2c_client *client,
						const char *name,
						u16 default_addr)
{
[...]
	return i2c_new_dummy_device(client->adapter, addr);
}

struct i2c_client *i2c_new_dummy_device(struct i2c_adapter *adapter, u16 address)
{
	struct i2c_board_info info = {
		I2C_BOARD_INFO("dummy", address),
	};

	return i2c_new_client_device(adapter, &info);
}

struct i2c_client *
i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
{
	struct i2c_client	*client;
	int			status;

	client = kzalloc(sizeof *client, GFP_KERNEL);
	if (!client)
		return ERR_PTR(-ENOMEM);

	client->adapter = adap;
[...]
	client->dev.parent = &client->adapter->dev;
[...]
	return client;
[...]
}

i2c_new_ancillary_device() returns an i2c_client with client->dev.parent
set to the I2C adapter device.

After your patch:

struct i2c_client *i2c_new_ancillary_device(struct i2c_client *client,
					    const char *name,
					    u16 default_addr,
					    const char *aux_device_name)
{
[...]
	return __i2c_new_dummy_device(client->adapter, addr, aux_device_name,
				      &client->dev);
}

static struct i2c_client *__i2c_new_dummy_device(struct i2c_adapter *adapter,
						 u16 address, const char *name,
						 struct device *parent)
{
	struct i2c_board_info info = {
		I2C_BOARD_INFO("dummy", address),
	};

[...]

	return __i2c_new_client_device(adapter, &info, parent);
}

static struct i2c_client *
__i2c_new_client_device(struct i2c_adapter *adap,
			struct i2c_board_info const *info,
			struct device *parent)
{
	struct i2c_client	*client;
	int			status;

	client = kzalloc(sizeof *client, GFP_KERNEL);
	if (!client)
		return ERR_PTR(-ENOMEM);

	client->adapter = adap;
[...]
	client->dev.parent = parent ? parent : &client->adapter->dev;
[...]
	return client;
[...]
}

i2c_new_ancillary_device() returns an i2c_client with client->dev.parent
set to the main i2c_client device, *regardless* of the value of the
aux_device_name parameter.

The behaviour of i2c_new_ancillary_device() has changed for existing
users.

> > > * If no address is specified by the firmware default_addr is used.
> > >
> > > > > > > the ancillary's device parent
> > > > > > > + * will be set to the primary device.
> > > > > >
> > > > > > This doesn't seem to match the implementation. With this patch
> > > > > > the ancillary device's parent is always the primary device. Are
> > > > > > you sure this won't cause any regression ?
> > > > >
> > > > > There is no regression as existing users only instantiate dummy device.
> > > >
> > > > Sorry, I don't follow you here. Existing callers of
> > > > i2c_new_ancillary_device() today get an i2c_client device whose
> > > > parent is the I2C adapter. With this patch they will get an
> > > > i2c_client device whose parent is the main i2c_client. That's a
> > > > change in behaviour, which could cause all sorts of issues.
> > >
> > > Please see the patch snippet below, there is no regression.
> > >
> > > client->dev.parent = parent ? parent : &client->adapter->dev;
> > 
> > When called from i2c_new_ancillary_device(), __i2c_new_dummy_device() as
> > a non-NULL parent argument. There is no change of behaviour *for
> > i2c_new_dummy_device()*, but thre is a change of behaviour *for
> > i2c_new_ancillary_device()*.
> 
> I don't think I understand what you mean.
> 
> For existing users, i2c_new_ancillary_device(...,
> aux_device_name=NULL) the behaviour is not changed.
> 
> Could you please elaborate further?
> 
> > > > > > And why do you need this ?
> > > > >
> > > > > As per Krzysztof [2],
> > > > >
> > > > > The DT schema allows multiple addresses for children. But we lack
> > > > > implementation of parent child relationship, As parent owns the resources.
> > > > > Child device needs to parse parent node to get some resource like
> > > > > clocks.
> > > > >
> > > > > [2]
> > > >
> > > > The I2C ancillary clients are not meant to be handled by separate
> > > > drivers.
> > >
> > > Is it a Linux rule??
> > 
> > It's an I2C subsystem rule as far as I can tell. This is how it has been
> > designed.
> 
> Wolfram/Geert:
> 
> Do you agree with Laurent's statement?

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2023-05-31 13:35 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230522101849.297499-1-biju.das.jz@bp.renesas.com>
2023-05-22 10:18 ` [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API Biju Das
2023-05-23  9:50   ` Hans Verkuil
2023-05-25 16:49   ` Geert Uytterhoeven
2023-05-29  8:05   ` Laurent Pinchart
2023-05-29  9:00     ` Biju Das
2023-05-31  8:59       ` Laurent Pinchart
2023-05-31  9:34         ` Biju Das
2023-05-31 11:41           ` Laurent Pinchart
2023-05-31 12:53             ` Biju Das
2023-05-31 13:35               ` Laurent Pinchart [this message]
2023-05-31 13:44                 ` Biju Das
2023-06-02  7:40                   ` Biju Das
2023-05-31 13:37               ` Geert Uytterhoeven
2023-05-31 13:47                 ` Biju Das
2023-05-31 12:51         ` Geert Uytterhoeven
2023-05-31 13:37           ` Laurent Pinchart
2023-05-31 13:39             ` Geert Uytterhoeven
2023-06-05  9:30           ` Wolfram Sang
2023-06-07  8:53           ` Wolfram Sang
2023-06-07 10:58             ` Biju Das
2023-06-08  6:41               ` Biju Das
2023-06-08 10:39                 ` Laurent Pinchart
2023-06-08 11:00                   ` Biju Das
2023-06-08 12:50                     ` Laurent Pinchart
2023-06-08 12:57                       ` Biju Das
2023-06-12  9:53                         ` Biju Das
2023-06-12 12:23                           ` Laurent Pinchart
2023-06-12 12:42                             ` Biju Das
2023-06-12 12:54                               ` Laurent Pinchart
2023-06-12 13:08                                 ` Geert Uytterhoeven
2023-06-12 13:19                                   ` Laurent Pinchart
2023-06-12 12:44                             ` Geert Uytterhoeven
2023-06-12 13:02                               ` Laurent Pinchart
2023-06-12 12:35                           ` Wolfram Sang
2023-06-12 12:42                             ` Geert Uytterhoeven
2023-06-12 12:48                               ` Wolfram Sang
2023-06-12 13:00                                 ` Geert Uytterhoeven
2023-06-12 20:43                                   ` Wolfram Sang
2023-06-13  7:24                                     ` Biju Das
2023-06-13 17:57                                       ` Biju Das
2023-06-13 19:31                                         ` Biju Das
2023-06-14  8:13                                           ` Laurent Pinchart
2023-06-14  8:21                                             ` Biju Das
2023-06-14  9:18                                               ` Geert Uytterhoeven
2023-06-14 11:04                                                 ` Biju Das
2023-06-15  9:00                                                   ` Geert Uytterhoeven
2023-06-14  9:54                                               ` Laurent Pinchart
2023-06-14 11:30                                                 ` Biju Das
2023-06-15  9:26                                                   ` Laurent Pinchart
2023-06-20  8:06                                                     ` Biju Das
2023-06-13  7:25                                     ` Geert Uytterhoeven
2023-06-13 10:45                                       ` Biju Das
2023-06-13 14:51                                         ` Geert Uytterhoeven
2023-06-13 16:11                                           ` Biju Das
2023-06-14  7:53                                             ` Geert Uytterhoeven
2023-06-14  8:02                                               ` Biju Das
2023-06-15  8:07                                               ` Geert Uytterhoeven
2023-06-15  9:23                                                 ` Laurent Pinchart
2023-06-16  6:32                                                   ` Wolfram Sang
2023-06-19  8:17                                                     ` Biju Das
2023-06-12 13:00                             ` Biju Das

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=20230531133528.GH27043@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrzej.hajda@intel.com \
    --cc=antonio.borneo@foss.st.com \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=cminyard@mvista.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fabrizio.castro.jz@renesas.com \
    --cc=geert+renesas@glider.be \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jernej.skrabec@gmail.com \
    --cc=jiasheng@iscas.ac.cn \
    --cc=jonas@kwiboo.se \
    --cc=kabel@kernel.org \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=rfoss@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@kernel.org \
    /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).