All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vignesh R <vigneshr@ti.com>
To: Marek Vasut <marek.vasut@gmail.com>,
	Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Rob Herring <robh+dt@kernel.org>, <linux-mtd@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 2/5] mtd: spi-nor: cadence-quadspi: add a delay in write sequence
Date: Mon, 2 Oct 2017 18:16:40 +0530	[thread overview]
Message-ID: <07137a92-244b-e009-54ae-71f733860f28@ti.com> (raw)
In-Reply-To: <d35d0891-71b9-12df-9689-dc77f56453ab@gmail.com>



On 9/24/2017 6:43 PM, Marek Vasut wrote:
> On 09/24/2017 02:33 PM, Vignesh R wrote:
>>
>>
>> On 9/24/2017 5:29 PM, Marek Vasut wrote:
>>> On 09/24/2017 12:59 PM, Vignesh R wrote:
>>>> As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access
>>>> Controller programming sequence, a delay equal to couple of QSPI master
>>>> clock(~5ns) is required after setting CQSPI_REG_INDIRECTWR_START bit and
>>>> writing data to the flash. Introduce a quirk flag CQSPI_NEEDS_WR_DELAY
>>>> to handle this and set this flag for TI 66AK2G SoC.
>>>>
>>>> [1]http://www.ti.com/lit/ug/spruhy8f/spruhy8f.pdf
>>>>
>>>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>>>
>>> Is this TI specific or is this controller property ? I wouldn't be
>>> surprised of the later ...
>>
>> I am not sure, there is no generic public documentation by cadence for
>> this IP. TI TRM clearly states this delay is required and I have
>> verified it practically that this delay is indeed needed.
>> But current user of this IP, socfpga does not seem to mention anything
>> about it. So, I guess its TI specific quirk.
> 
> OK, let's go with that then. I didn't observe any stability issues with
> SoCFPGA, but I didn't run the flash at 100s of MHz either. At what kind
> of frequencies does the quirk become relevant ?
> 

Actually, delay is tied to QSPI master clk rate(not SPI bus clk rate).
It runs at 384MHz. Changing SPI bus rate has no effect.

Regards
Vignesh

>>>
>>>> ---
>>>>
>>>> v3:
>>>> Fix build warnings reported by kbuild test bot.
>>>>
>>>>  drivers/mtd/spi-nor/cadence-quadspi.c | 27 ++++++++++++++++++++++++++-
>>>>  1 file changed, 26 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> index 53c7d8e0327a..5cd5d6f7303f 100644
>>>> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> @@ -38,6 +38,9 @@
>>>>  #define CQSPI_NAME			"cadence-qspi"
>>>>  #define CQSPI_MAX_CHIPSELECT		16
>>>>  
>>>> +/* Quirks */
>>>> +#define CQSPI_NEEDS_WR_DELAY		BIT(0)
>>>> +
>>>>  struct cqspi_st;
>>>>  
>>>>  struct cqspi_flash_pdata {
>>>> @@ -76,6 +79,7 @@ struct cqspi_st {
>>>>  	u32			fifo_depth;
>>>>  	u32			fifo_width;
>>>>  	u32			trigger_address;
>>>> +	u32			wr_delay;
>>>>  	struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
>>>>  };
>>>>  
>>>> @@ -608,6 +612,15 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor,
>>>>  	reinit_completion(&cqspi->transfer_complete);
>>>>  	writel(CQSPI_REG_INDIRECTWR_START_MASK,
>>>>  	       reg_base + CQSPI_REG_INDIRECTWR);
>>>> +	/*
>>>> +	 * As per 66AK2G02 TRM SPRUHY8F section 11.15.5.3 Indirect Access
>>>> +	 * Controller programming sequence, couple of cycles of
>>>> +	 * QSPI_REF_CLK delay is required for the above bit to
>>>> +	 * be internally synchronized by the QSPI module. Provide 5
>>>> +	 * cycles of delay.
>>>> +	 */
>>>> +	if (cqspi->wr_delay)
>>>> +		ndelay(cqspi->wr_delay);
>>>>  
>>>>  	while (remaining > 0) {
>>>>  		write_bytes = remaining > page_size ? page_size : remaining;
>>>> @@ -1156,6 +1169,7 @@ static int cqspi_probe(struct platform_device *pdev)
>>>>  	struct cqspi_st *cqspi;
>>>>  	struct resource *res;
>>>>  	struct resource *res_ahb;
>>>> +	unsigned long data;
>>>>  	int ret;
>>>>  	int irq;
>>>>  
>>>> @@ -1213,6 +1227,10 @@ static int cqspi_probe(struct platform_device *pdev)
>>>>  	}
>>>>  
>>>>  	cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
>>>> +	data  = (unsigned long)of_device_get_match_data(dev);
>>>> +	if (data & CQSPI_NEEDS_WR_DELAY)
>>>> +		cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
>>>> +						   cqspi->master_ref_clk_hz);
>>>>  
>>>>  	ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0,
>>>>  			       pdev->name, cqspi);
>>>> @@ -1284,7 +1302,14 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
>>>>  #endif
>>>>  
>>>>  static const struct of_device_id cqspi_dt_ids[] = {
>>>> -	{.compatible = "cdns,qspi-nor",},
>>>> +	{
>>>> +		.compatible = "cdns,qspi-nor",
>>>> +		.data = (void *)0,
>>>> +	},
>>>> +	{
>>>> +		.compatible = "ti,k2g-qspi",
>>>> +		.data = (void *)CQSPI_NEEDS_WR_DELAY,
>>>> +	},
>>>>  	{ /* end of table */ }
>>>>  };
>>>>  
>>>>
>>>
>>>
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
To: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Cyrille Pitchen
	<cyrille.pitchen-yU5RGvR974pGWvitb5QawA@public.gmane.org>
Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Brian Norris
	<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Boris Brezillon
	<boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v3 2/5] mtd: spi-nor: cadence-quadspi: add a delay in write sequence
Date: Mon, 2 Oct 2017 18:16:40 +0530	[thread overview]
Message-ID: <07137a92-244b-e009-54ae-71f733860f28@ti.com> (raw)
In-Reply-To: <d35d0891-71b9-12df-9689-dc77f56453ab-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>



On 9/24/2017 6:43 PM, Marek Vasut wrote:
> On 09/24/2017 02:33 PM, Vignesh R wrote:
>>
>>
>> On 9/24/2017 5:29 PM, Marek Vasut wrote:
>>> On 09/24/2017 12:59 PM, Vignesh R wrote:
>>>> As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access
>>>> Controller programming sequence, a delay equal to couple of QSPI master
>>>> clock(~5ns) is required after setting CQSPI_REG_INDIRECTWR_START bit and
>>>> writing data to the flash. Introduce a quirk flag CQSPI_NEEDS_WR_DELAY
>>>> to handle this and set this flag for TI 66AK2G SoC.
>>>>
>>>> [1]http://www.ti.com/lit/ug/spruhy8f/spruhy8f.pdf
>>>>
>>>> Signed-off-by: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
>>>
>>> Is this TI specific or is this controller property ? I wouldn't be
>>> surprised of the later ...
>>
>> I am not sure, there is no generic public documentation by cadence for
>> this IP. TI TRM clearly states this delay is required and I have
>> verified it practically that this delay is indeed needed.
>> But current user of this IP, socfpga does not seem to mention anything
>> about it. So, I guess its TI specific quirk.
> 
> OK, let's go with that then. I didn't observe any stability issues with
> SoCFPGA, but I didn't run the flash at 100s of MHz either. At what kind
> of frequencies does the quirk become relevant ?
> 

Actually, delay is tied to QSPI master clk rate(not SPI bus clk rate).
It runs at 384MHz. Changing SPI bus rate has no effect.

Regards
Vignesh

>>>
>>>> ---
>>>>
>>>> v3:
>>>> Fix build warnings reported by kbuild test bot.
>>>>
>>>>  drivers/mtd/spi-nor/cadence-quadspi.c | 27 ++++++++++++++++++++++++++-
>>>>  1 file changed, 26 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> index 53c7d8e0327a..5cd5d6f7303f 100644
>>>> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> @@ -38,6 +38,9 @@
>>>>  #define CQSPI_NAME			"cadence-qspi"
>>>>  #define CQSPI_MAX_CHIPSELECT		16
>>>>  
>>>> +/* Quirks */
>>>> +#define CQSPI_NEEDS_WR_DELAY		BIT(0)
>>>> +
>>>>  struct cqspi_st;
>>>>  
>>>>  struct cqspi_flash_pdata {
>>>> @@ -76,6 +79,7 @@ struct cqspi_st {
>>>>  	u32			fifo_depth;
>>>>  	u32			fifo_width;
>>>>  	u32			trigger_address;
>>>> +	u32			wr_delay;
>>>>  	struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
>>>>  };
>>>>  
>>>> @@ -608,6 +612,15 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor,
>>>>  	reinit_completion(&cqspi->transfer_complete);
>>>>  	writel(CQSPI_REG_INDIRECTWR_START_MASK,
>>>>  	       reg_base + CQSPI_REG_INDIRECTWR);
>>>> +	/*
>>>> +	 * As per 66AK2G02 TRM SPRUHY8F section 11.15.5.3 Indirect Access
>>>> +	 * Controller programming sequence, couple of cycles of
>>>> +	 * QSPI_REF_CLK delay is required for the above bit to
>>>> +	 * be internally synchronized by the QSPI module. Provide 5
>>>> +	 * cycles of delay.
>>>> +	 */
>>>> +	if (cqspi->wr_delay)
>>>> +		ndelay(cqspi->wr_delay);
>>>>  
>>>>  	while (remaining > 0) {
>>>>  		write_bytes = remaining > page_size ? page_size : remaining;
>>>> @@ -1156,6 +1169,7 @@ static int cqspi_probe(struct platform_device *pdev)
>>>>  	struct cqspi_st *cqspi;
>>>>  	struct resource *res;
>>>>  	struct resource *res_ahb;
>>>> +	unsigned long data;
>>>>  	int ret;
>>>>  	int irq;
>>>>  
>>>> @@ -1213,6 +1227,10 @@ static int cqspi_probe(struct platform_device *pdev)
>>>>  	}
>>>>  
>>>>  	cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
>>>> +	data  = (unsigned long)of_device_get_match_data(dev);
>>>> +	if (data & CQSPI_NEEDS_WR_DELAY)
>>>> +		cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
>>>> +						   cqspi->master_ref_clk_hz);
>>>>  
>>>>  	ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0,
>>>>  			       pdev->name, cqspi);
>>>> @@ -1284,7 +1302,14 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
>>>>  #endif
>>>>  
>>>>  static const struct of_device_id cqspi_dt_ids[] = {
>>>> -	{.compatible = "cdns,qspi-nor",},
>>>> +	{
>>>> +		.compatible = "cdns,qspi-nor",
>>>> +		.data = (void *)0,
>>>> +	},
>>>> +	{
>>>> +		.compatible = "ti,k2g-qspi",
>>>> +		.data = (void *)CQSPI_NEEDS_WR_DELAY,
>>>> +	},
>>>>  	{ /* end of table */ }
>>>>  };
>>>>  
>>>>
>>>
>>>
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: vigneshr@ti.com (Vignesh R)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/5] mtd: spi-nor: cadence-quadspi: add a delay in write sequence
Date: Mon, 2 Oct 2017 18:16:40 +0530	[thread overview]
Message-ID: <07137a92-244b-e009-54ae-71f733860f28@ti.com> (raw)
In-Reply-To: <d35d0891-71b9-12df-9689-dc77f56453ab@gmail.com>



On 9/24/2017 6:43 PM, Marek Vasut wrote:
> On 09/24/2017 02:33 PM, Vignesh R wrote:
>>
>>
>> On 9/24/2017 5:29 PM, Marek Vasut wrote:
>>> On 09/24/2017 12:59 PM, Vignesh R wrote:
>>>> As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access
>>>> Controller programming sequence, a delay equal to couple of QSPI master
>>>> clock(~5ns) is required after setting CQSPI_REG_INDIRECTWR_START bit and
>>>> writing data to the flash. Introduce a quirk flag CQSPI_NEEDS_WR_DELAY
>>>> to handle this and set this flag for TI 66AK2G SoC.
>>>>
>>>> [1]http://www.ti.com/lit/ug/spruhy8f/spruhy8f.pdf
>>>>
>>>> Signed-off-by: Vignesh R <vigneshr@ti.com>
>>>
>>> Is this TI specific or is this controller property ? I wouldn't be
>>> surprised of the later ...
>>
>> I am not sure, there is no generic public documentation by cadence for
>> this IP. TI TRM clearly states this delay is required and I have
>> verified it practically that this delay is indeed needed.
>> But current user of this IP, socfpga does not seem to mention anything
>> about it. So, I guess its TI specific quirk.
> 
> OK, let's go with that then. I didn't observe any stability issues with
> SoCFPGA, but I didn't run the flash at 100s of MHz either. At what kind
> of frequencies does the quirk become relevant ?
> 

Actually, delay is tied to QSPI master clk rate(not SPI bus clk rate).
It runs at 384MHz. Changing SPI bus rate has no effect.

Regards
Vignesh

>>>
>>>> ---
>>>>
>>>> v3:
>>>> Fix build warnings reported by kbuild test bot.
>>>>
>>>>  drivers/mtd/spi-nor/cadence-quadspi.c | 27 ++++++++++++++++++++++++++-
>>>>  1 file changed, 26 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> index 53c7d8e0327a..5cd5d6f7303f 100644
>>>> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
>>>> @@ -38,6 +38,9 @@
>>>>  #define CQSPI_NAME			"cadence-qspi"
>>>>  #define CQSPI_MAX_CHIPSELECT		16
>>>>  
>>>> +/* Quirks */
>>>> +#define CQSPI_NEEDS_WR_DELAY		BIT(0)
>>>> +
>>>>  struct cqspi_st;
>>>>  
>>>>  struct cqspi_flash_pdata {
>>>> @@ -76,6 +79,7 @@ struct cqspi_st {
>>>>  	u32			fifo_depth;
>>>>  	u32			fifo_width;
>>>>  	u32			trigger_address;
>>>> +	u32			wr_delay;
>>>>  	struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
>>>>  };
>>>>  
>>>> @@ -608,6 +612,15 @@ static int cqspi_indirect_write_execute(struct spi_nor *nor,
>>>>  	reinit_completion(&cqspi->transfer_complete);
>>>>  	writel(CQSPI_REG_INDIRECTWR_START_MASK,
>>>>  	       reg_base + CQSPI_REG_INDIRECTWR);
>>>> +	/*
>>>> +	 * As per 66AK2G02 TRM SPRUHY8F section 11.15.5.3 Indirect Access
>>>> +	 * Controller programming sequence, couple of cycles of
>>>> +	 * QSPI_REF_CLK delay is required for the above bit to
>>>> +	 * be internally synchronized by the QSPI module. Provide 5
>>>> +	 * cycles of delay.
>>>> +	 */
>>>> +	if (cqspi->wr_delay)
>>>> +		ndelay(cqspi->wr_delay);
>>>>  
>>>>  	while (remaining > 0) {
>>>>  		write_bytes = remaining > page_size ? page_size : remaining;
>>>> @@ -1156,6 +1169,7 @@ static int cqspi_probe(struct platform_device *pdev)
>>>>  	struct cqspi_st *cqspi;
>>>>  	struct resource *res;
>>>>  	struct resource *res_ahb;
>>>> +	unsigned long data;
>>>>  	int ret;
>>>>  	int irq;
>>>>  
>>>> @@ -1213,6 +1227,10 @@ static int cqspi_probe(struct platform_device *pdev)
>>>>  	}
>>>>  
>>>>  	cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
>>>> +	data  = (unsigned long)of_device_get_match_data(dev);
>>>> +	if (data & CQSPI_NEEDS_WR_DELAY)
>>>> +		cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
>>>> +						   cqspi->master_ref_clk_hz);
>>>>  
>>>>  	ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0,
>>>>  			       pdev->name, cqspi);
>>>> @@ -1284,7 +1302,14 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
>>>>  #endif
>>>>  
>>>>  static const struct of_device_id cqspi_dt_ids[] = {
>>>> -	{.compatible = "cdns,qspi-nor",},
>>>> +	{
>>>> +		.compatible = "cdns,qspi-nor",
>>>> +		.data = (void *)0,
>>>> +	},
>>>> +	{
>>>> +		.compatible = "ti,k2g-qspi",
>>>> +		.data = (void *)CQSPI_NEEDS_WR_DELAY,
>>>> +	},
>>>>  	{ /* end of table */ }
>>>>  };
>>>>  
>>>>
>>>
>>>
> 
> 

  reply	other threads:[~2017-10-02 12:47 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-24 10:59 [PATCH v3 0/5] K2G: Add QSPI support Vignesh R
2017-09-24 10:59 ` Vignesh R
2017-09-24 10:59 ` Vignesh R
2017-09-24 10:59 ` [PATCH v3 1/5] mtd: spi-nor: cadence-quadspi: Add TI 66AK2G SoC specific compatible Vignesh R
2017-09-24 10:59   ` Vignesh R
2017-09-24 10:59   ` Vignesh R
2017-09-24 10:59 ` [PATCH v3 2/5] mtd: spi-nor: cadence-quadspi: add a delay in write sequence Vignesh R
2017-09-24 10:59   ` Vignesh R
2017-09-24 10:59   ` Vignesh R
2017-09-24 11:59   ` Marek Vasut
2017-09-24 11:59     ` Marek Vasut
2017-09-24 12:33     ` Vignesh R
2017-09-24 12:33       ` Vignesh R
2017-09-24 12:33       ` Vignesh R
2017-09-24 13:13       ` Marek Vasut
2017-09-24 13:13         ` Marek Vasut
2017-09-24 13:13         ` Marek Vasut
2017-10-02 12:46         ` Vignesh R [this message]
2017-10-02 12:46           ` Vignesh R
2017-10-02 12:46           ` Vignesh R
2017-09-24 10:59 ` [PATCH v3 3/5] mtd: spi-nor: cadence-quadspi: Add new binding to enable loop-back circuit Vignesh R
2017-09-24 10:59   ` Vignesh R
2017-09-24 10:59   ` Vignesh R
2017-09-24 10:59 ` [PATCH v3 4/5] mtd: spi-nor: cadence-quadspi: Add support to enable loop-back clock circuit Vignesh R
2017-09-24 10:59   ` Vignesh R
2017-09-24 10:59   ` Vignesh R
2017-09-24 10:59 ` [PATCH v3 5/5] mtd: spi-nor: cadence-quadspi: Add runtime PM support Vignesh R
2017-09-24 10:59   ` Vignesh R
2017-09-24 10:59   ` Vignesh R
2017-09-24 12:01   ` Marek Vasut
2017-09-24 12:01     ` Marek Vasut
2017-09-24 13:08     ` Vignesh R
2017-09-24 13:08       ` Vignesh R
2017-09-24 13:08       ` Vignesh R
2017-09-24 13:12       ` Marek Vasut
2017-09-24 13:12         ` Marek Vasut
2017-09-24 13:12         ` Marek Vasut
2017-09-24 13:27         ` Vignesh R
2017-09-24 13:27           ` Vignesh R
2017-09-24 13:27           ` Vignesh R
2017-09-24 13:51           ` Marek Vasut
2017-09-24 13:51             ` Marek Vasut
2017-09-25 22:41             ` matthew.gerlach
2017-09-25 22:41               ` matthew.gerlach at linux.intel.com
2017-09-25 22:41               ` matthew.gerlach-VuQAYsv1563Yd54FQh9/CA
2017-09-25 23:49               ` Marek Vasut
2017-09-25 23:49                 ` Marek Vasut
2017-09-25 23:49                 ` Marek Vasut
2017-09-27 10:48                 ` Vignesh R
2017-09-27 10:48                   ` Vignesh R
2017-09-27 10:48                   ` Vignesh R
2017-09-28 15:01                   ` matthew.gerlach
2017-09-28 15:01                     ` matthew.gerlach at linux.intel.com
2017-10-02 12:28                     ` Vignesh R
2017-10-02 12:28                       ` Vignesh R
2017-10-02 12:28                       ` Vignesh R

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=07137a92-244b-e009-54ae-71f733860f28@ti.com \
    --to=vigneshr@ti.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=robh+dt@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 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.