All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Quadros <rogerq@ti.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: <tony@atomide.com>, <dwmw2@infradead.org>,
	<ezequiel@vanguardiasur.com.ar>, <javier@dowhile0.org>,
	<fcooper@ti.com>, <nsekhar@ti.com>,
	<linux-mtd@lists.infradead.org>, <linux-omap@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Alex Smith <alex.smith@imgtec.com>,
	Harvey Hunt <harvey.hunt@imgtec.com>
Subject: Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib
Date: Tue, 27 Oct 2015 10:03:02 +0200	[thread overview]
Message-ID: <562F2FB6.7050806@ti.com> (raw)
In-Reply-To: <20151026204900.GI13239@google.com>

On 26/10/15 22:49, Brian Norris wrote:
> + others
> 
> A few comments below.
> 
> On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
>> The GPMC WAIT pin status are now available over gpiolib.
>> Update the omap_dev_ready() function to use gpio instead of
>> directly accessing GPMC register space.
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> ---
>>  drivers/mtd/nand/omap2.c                     | 29 +++++++++++++++++-----------
>>  include/linux/platform_data/mtd-nand-omap2.h |  2 +-
>>  2 files changed, 19 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 228f498..d0f2620 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -12,6 +12,7 @@
>>  #include <linux/dmaengine.h>
>>  #include <linux/dma-mapping.h>
>>  #include <linux/delay.h>
>> +#include <linux/gpio/consumer.h>
>>  #include <linux/module.h>
>>  #include <linux/interrupt.h>
>>  #include <linux/jiffies.h>
>> @@ -184,6 +185,8 @@ struct omap_nand_info {
>>  	/* fields specific for BCHx_HW ECC scheme */
>>  	struct device			*elm_dev;
>>  	struct device_node		*of_node;
>> +	/* NAND ready gpio */
>> +	struct gpio_desc		*ready_gpiod;
>>  };
>>  
>>  /**
>> @@ -1047,22 +1050,17 @@ static int omap_wait(struct mtd_info *mtd, struct nand_chip *chip)
>>  }
>>  
>>  /**
>> - * omap_dev_ready - calls the platform specific dev_ready function
>> + * omap_dev_ready - checks the NAND Ready GPIO line
>>   * @mtd: MTD device structure
>> + *
>> + * Returns true if ready and false if busy.
>>   */
>>  static int omap_dev_ready(struct mtd_info *mtd)
>>  {
>> -	unsigned int val = 0;
>>  	struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
>>  							mtd);
>>  
>> -	val = readl(info->reg.gpmc_status);
>> -
>> -	if ((val & 0x100) == 0x100) {
>> -		return 1;
>> -	} else {
>> -		return 0;
>> -	}
>> +	return gpiod_get_value(info->ready_gpiod);
>>  }
>>  
>>  /**
>> @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>  		info->reg = pdata->reg;
>>  		info->of_node = pdata->of_node;
>>  		info->ecc_opt = pdata->ecc_opt;
>> -		info->dev_ready	= pdata->dev_ready;
>> +		if (pdata->dev_ready)
>> +			dev_info(&pdev->dev, "pdata->dev_ready is deprecated\n");
>> +
>>  		info->xfer_type = pdata->xfer_type;
>>  		info->devsize = pdata->devsize;
>>  		info->elm_of_node = pdata->elm_of_node;
>> @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device *pdev)
>>  	nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
>>  	nand_chip->cmd_ctrl  = omap_hwcontrol;
>>  
>> +	info->ready_gpiod = devm_gpiod_get_optional(&pdev->dev, "ready",
>> +						    GPIOD_IN);
> 
> Others have been looking at using GPIOs for the ready/busy pin too. At a
> minimum, we need an updated DT binding doc for this, since I see you're
> adding this via device tree in a later patch (I don't see any DT binding
> patch for this; but I could just be overlooking it). It'd also be great
> if this support was moved to nand_dt_init() so other platforms can
> benefit, but I won't require that.
> 
> Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
> (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
> really care, but the name should be going into a doc, so we can choose
> the same one everywhere.
> 
> EDIT: looks like the discussion was partly here [1] and it seems we're
> landing on "rb-gpios" in the latest version [2]. Can we stick with that?

Why should it be "rb-gpios" and not "rb-gpio"?
I don't think there are multiple gpios for r/b# function.

cheers,
-roger

> 
> Regards,
> Brian
> 
> [0] "Previous" may be subject to debate, as both series have been going
>     for several revisions.
> [1] http://patchwork.ozlabs.org/patch/515327/
> [2] http://patchwork.ozlabs.org/patch/526819/
> 
>> +	if (IS_ERR(info->ready_gpiod)) {
>> +		dev_err(dev, "failed to get ready gpio\n");
>> +		return PTR_ERR(info->ready_gpiod);
>> +	}
>> +
>>  	/*
>>  	 * If RDY/BSY line is connected to OMAP then use the omap ready
>>  	 * function and the generic nand_wait function which reads the status
>> @@ -1822,7 +1829,7 @@ static int omap_nand_probe(struct platform_device *pdev)
>>  	 * chip delay which is slightly more than tR (AC Timing) of the NAND
>>  	 * device and read status register until you get a failure or success
>>  	 */
>> -	if (info->dev_ready) {
>> +	if (info->ready_gpiod) {
>>  		nand_chip->dev_ready = omap_dev_ready;
>>  		nand_chip->chip_delay = 0;
>>  	} else {
>> diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
>> index ff27e5a..19e509d 100644
>> --- a/include/linux/platform_data/mtd-nand-omap2.h
>> +++ b/include/linux/platform_data/mtd-nand-omap2.h
>> @@ -70,7 +70,6 @@ struct omap_nand_platform_data {
>>  	int			cs;
>>  	struct mtd_partition	*parts;
>>  	int			nr_parts;
>> -	bool			dev_ready;
>>  	bool			flash_bbt;
>>  	enum nand_io		xfer_type;
>>  	int			devsize;
>> @@ -81,5 +80,6 @@ struct omap_nand_platform_data {
>>  	/* deprecated */
>>  	struct gpmc_nand_regs	reg;
>>  	struct device_node	*of_node;
>> +	bool			dev_ready;
>>  };
>>  #endif
>> -- 
>> 2.1.4
>>

WARNING: multiple messages have this Message-ID (diff)
From: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
To: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org,
	dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ@public.gmane.org,
	javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org,
	fcooper-l0cyMroinI0@public.gmane.org,
	nsekhar-l0cyMroinI0@public.gmane.org,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Boris Brezillon
	<boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	Alex Smith <alex.smith-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>,
	Harvey Hunt <harvey.hunt-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib
Date: Tue, 27 Oct 2015 10:03:02 +0200	[thread overview]
Message-ID: <562F2FB6.7050806@ti.com> (raw)
In-Reply-To: <20151026204900.GI13239-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

On 26/10/15 22:49, Brian Norris wrote:
> + others
> 
> A few comments below.
> 
> On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
>> The GPMC WAIT pin status are now available over gpiolib.
>> Update the omap_dev_ready() function to use gpio instead of
>> directly accessing GPMC register space.
>>
>> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
>> ---
>>  drivers/mtd/nand/omap2.c                     | 29 +++++++++++++++++-----------
>>  include/linux/platform_data/mtd-nand-omap2.h |  2 +-
>>  2 files changed, 19 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 228f498..d0f2620 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -12,6 +12,7 @@
>>  #include <linux/dmaengine.h>
>>  #include <linux/dma-mapping.h>
>>  #include <linux/delay.h>
>> +#include <linux/gpio/consumer.h>
>>  #include <linux/module.h>
>>  #include <linux/interrupt.h>
>>  #include <linux/jiffies.h>
>> @@ -184,6 +185,8 @@ struct omap_nand_info {
>>  	/* fields specific for BCHx_HW ECC scheme */
>>  	struct device			*elm_dev;
>>  	struct device_node		*of_node;
>> +	/* NAND ready gpio */
>> +	struct gpio_desc		*ready_gpiod;
>>  };
>>  
>>  /**
>> @@ -1047,22 +1050,17 @@ static int omap_wait(struct mtd_info *mtd, struct nand_chip *chip)
>>  }
>>  
>>  /**
>> - * omap_dev_ready - calls the platform specific dev_ready function
>> + * omap_dev_ready - checks the NAND Ready GPIO line
>>   * @mtd: MTD device structure
>> + *
>> + * Returns true if ready and false if busy.
>>   */
>>  static int omap_dev_ready(struct mtd_info *mtd)
>>  {
>> -	unsigned int val = 0;
>>  	struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
>>  							mtd);
>>  
>> -	val = readl(info->reg.gpmc_status);
>> -
>> -	if ((val & 0x100) == 0x100) {
>> -		return 1;
>> -	} else {
>> -		return 0;
>> -	}
>> +	return gpiod_get_value(info->ready_gpiod);
>>  }
>>  
>>  /**
>> @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>>  		info->reg = pdata->reg;
>>  		info->of_node = pdata->of_node;
>>  		info->ecc_opt = pdata->ecc_opt;
>> -		info->dev_ready	= pdata->dev_ready;
>> +		if (pdata->dev_ready)
>> +			dev_info(&pdev->dev, "pdata->dev_ready is deprecated\n");
>> +
>>  		info->xfer_type = pdata->xfer_type;
>>  		info->devsize = pdata->devsize;
>>  		info->elm_of_node = pdata->elm_of_node;
>> @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device *pdev)
>>  	nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
>>  	nand_chip->cmd_ctrl  = omap_hwcontrol;
>>  
>> +	info->ready_gpiod = devm_gpiod_get_optional(&pdev->dev, "ready",
>> +						    GPIOD_IN);
> 
> Others have been looking at using GPIOs for the ready/busy pin too. At a
> minimum, we need an updated DT binding doc for this, since I see you're
> adding this via device tree in a later patch (I don't see any DT binding
> patch for this; but I could just be overlooking it). It'd also be great
> if this support was moved to nand_dt_init() so other platforms can
> benefit, but I won't require that.
> 
> Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
> (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
> really care, but the name should be going into a doc, so we can choose
> the same one everywhere.
> 
> EDIT: looks like the discussion was partly here [1] and it seems we're
> landing on "rb-gpios" in the latest version [2]. Can we stick with that?

Why should it be "rb-gpios" and not "rb-gpio"?
I don't think there are multiple gpios for r/b# function.

cheers,
-roger

> 
> Regards,
> Brian
> 
> [0] "Previous" may be subject to debate, as both series have been going
>     for several revisions.
> [1] http://patchwork.ozlabs.org/patch/515327/
> [2] http://patchwork.ozlabs.org/patch/526819/
> 
>> +	if (IS_ERR(info->ready_gpiod)) {
>> +		dev_err(dev, "failed to get ready gpio\n");
>> +		return PTR_ERR(info->ready_gpiod);
>> +	}
>> +
>>  	/*
>>  	 * If RDY/BSY line is connected to OMAP then use the omap ready
>>  	 * function and the generic nand_wait function which reads the status
>> @@ -1822,7 +1829,7 @@ static int omap_nand_probe(struct platform_device *pdev)
>>  	 * chip delay which is slightly more than tR (AC Timing) of the NAND
>>  	 * device and read status register until you get a failure or success
>>  	 */
>> -	if (info->dev_ready) {
>> +	if (info->ready_gpiod) {
>>  		nand_chip->dev_ready = omap_dev_ready;
>>  		nand_chip->chip_delay = 0;
>>  	} else {
>> diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
>> index ff27e5a..19e509d 100644
>> --- a/include/linux/platform_data/mtd-nand-omap2.h
>> +++ b/include/linux/platform_data/mtd-nand-omap2.h
>> @@ -70,7 +70,6 @@ struct omap_nand_platform_data {
>>  	int			cs;
>>  	struct mtd_partition	*parts;
>>  	int			nr_parts;
>> -	bool			dev_ready;
>>  	bool			flash_bbt;
>>  	enum nand_io		xfer_type;
>>  	int			devsize;
>> @@ -81,5 +80,6 @@ struct omap_nand_platform_data {
>>  	/* deprecated */
>>  	struct gpmc_nand_regs	reg;
>>  	struct device_node	*of_node;
>> +	bool			dev_ready;
>>  };
>>  #endif
>> -- 
>> 2.1.4
>>
--
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

  reply	other threads:[~2015-10-27  8:04 UTC|newest]

Thread overview: 144+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-18 14:53 [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Roger Quadros
2015-09-18 14:53 ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 01/27] ARM: OMAP2+: gpmc: Add platform data Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 02/27] ARM: OMAP2+: gpmc: Add gpmc timings and settings to " Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 03/27] memory: omap-gpmc: Introduce GPMC to NAND interface Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 04/27] mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-12-03  5:00   ` Brian Norris
2015-09-18 14:53 ` [PATCH v3 05/27] memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 06/27] mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty check Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 07/27] memory: omap-gpmc: Remove NAND IRQ code Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 08/27] memory: omap-gpmc: Add IRQ ops for GPMC-NAND interface Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 09/27] mtd: nand: omap2: manage NAND interrupts Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 10/27] mtd: nand: omap: Copy platform data parameters to omap_nand_info data Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 11/27] mtd: nand: omap: Clean up device tree support Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-10-06 10:35   ` [PATCH v4 " Roger Quadros
2015-10-06 10:35     ` Roger Quadros
2015-12-03  4:29     ` Brian Norris
2015-12-03  4:29       ` Brian Norris
2015-12-03  5:57       ` Roger Quadros
2015-12-03  5:57         ` Roger Quadros
2015-12-03  6:09         ` Brian Norris
2015-09-18 14:53 ` [PATCH v3 12/27] mtd: nand: omap: Update DT binding documentation Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 13/27] memory: omap-gpmc: Prevent mapping into 1st 16MB Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 14/27] memory: omap-gpmc: Move device tree binding to correct location Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 15/27] memory: omap-gpmc: Support general purpose input for WAITPINs Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 16/27] memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 17/27] memory: omap-gpmc: Add irqchip support to the gpiochip Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-10-26 20:49   ` Brian Norris
2015-10-26 20:49     ` Brian Norris
2015-10-27  8:03     ` Roger Quadros [this message]
2015-10-27  8:03       ` Roger Quadros
2015-10-27  8:12       ` Boris Brezillon
2015-10-27  8:12         ` Boris Brezillon
2015-10-27  8:43         ` Roger Quadros
2015-10-27  8:43           ` Roger Quadros
2015-10-27  8:28     ` Boris Brezillon
2015-12-03  4:45       ` Brian Norris
2015-12-03  8:41         ` Boris Brezillon
2015-09-18 14:53 ` [PATCH v3 19/27] memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via gpmc_regs Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 20/27] ARM: dts: dra7: Fix NAND device nodes Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-10-14 13:34   ` Franklin S Cooper Jr.
2015-10-14 13:34     ` Franklin S Cooper Jr.
2015-10-14 14:17     ` Roger Quadros
2015-10-14 14:17       ` Roger Quadros
2015-10-14 14:37       ` Franklin S Cooper Jr.
2015-10-14 14:37         ` Franklin S Cooper Jr.
2015-09-18 14:53 ` [PATCH v3 21/27] ARM: dts: dra7x-evm: Provide NAND ready pin Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 22/27] ARM: dts: am437x: Fix NAND device nodes Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 23/27] ARM: dts: am437x-gp-evm: Provide NAND ready pin Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 24/27] ARM: dts: am335x: Fix NAND device nodes Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 25/27] ARM: dts: am335x: Provide NAND ready pin Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 26/27] ARM: dts: dm816x: Fix gpmc and NAND node Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-09-18 14:53 ` [PATCH v3 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes Roger Quadros
2015-09-18 14:53   ` Roger Quadros
2015-10-13  0:43   ` Tony Lindgren
2015-10-13  0:43     ` Tony Lindgren
2015-10-13  6:29     ` Roger Quadros
2015-10-13  6:29       ` Roger Quadros
2015-10-13 15:18       ` Tony Lindgren
2015-10-13 15:18         ` Tony Lindgren
2015-10-14  7:39         ` Roger Quadros
2015-10-14  7:39           ` Roger Quadros
2015-10-14  8:55   ` [PATCH v4 " Roger Quadros
2015-10-14  8:55     ` Roger Quadros
2015-09-30  7:39 ` [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Roger Quadros
2015-09-30  7:39   ` Roger Quadros
2015-09-30 11:00 ` Roger Quadros
2015-09-30 11:00   ` Roger Quadros
2015-10-06  8:33   ` Tony Lindgren
2015-10-06  9:54     ` Roger Quadros
2015-10-06  9:54       ` Roger Quadros
2015-10-06 10:00       ` Tony Lindgren
2015-10-06 10:00         ` Tony Lindgren
2015-10-06 10:05         ` Roger Quadros
2015-10-06 10:05           ` Roger Quadros
2015-10-06 10:28           ` Roger Quadros
2015-10-06 10:28             ` Roger Quadros
2015-10-06 11:01             ` Tony Lindgren
2015-10-06 11:01               ` Tony Lindgren
2015-10-06 11:09               ` Roger Quadros
2015-10-06 11:09                 ` Roger Quadros
2015-10-16 21:25                 ` Tony Lindgren
2015-10-19  7:08                   ` Roger Quadros
2015-10-19  7:08                     ` Roger Quadros
2015-10-21  8:31                     ` Roger Quadros
2015-10-21  8:31                       ` Roger Quadros
2015-10-21 15:20                       ` Tony Lindgren
2015-10-21 15:20                         ` Tony Lindgren
2015-10-23  7:09                         ` Roger Quadros
2015-10-23  7:09                           ` Roger Quadros
2015-11-30 17:26                           ` Tony Lindgren
2015-10-26 21:23 ` Brian Norris
2015-10-26 21:23   ` Brian Norris
2015-10-27  9:37   ` Roger Quadros
2015-10-27  9:37     ` Roger Quadros
2015-11-25 10:42     ` Roger Quadros
2015-11-25 10:42       ` Roger Quadros
2015-11-30 19:54     ` Brian Norris
2015-12-01 14:41       ` Roger Quadros
2015-12-01 14:41         ` Roger Quadros
2015-12-02  3:26         ` Brian Norris
2015-12-02  3:26           ` Brian Norris
2015-12-02  5:12           ` Roger Quadros
2015-12-02  5:12             ` Roger Quadros
2015-12-02 15:03             ` Tony Lindgren
2015-12-02 15:03               ` Tony Lindgren
2015-12-02 18:13               ` Brian Norris
2015-12-02 20:05                 ` Tony Lindgren
2015-12-02 18:43             ` Brian Norris
2015-12-03  5:09 ` Brian Norris
2015-12-03  5:09   ` Brian Norris
2015-12-03  6:08   ` Roger Quadros
2015-12-03  6:08     ` Roger Quadros
2015-12-03  6:22     ` Brian Norris
2015-12-03  9:01       ` Roger Quadros
2015-12-03  9:01         ` Roger Quadros
2015-12-03 15:17         ` Tony Lindgren

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=562F2FB6.7050806@ti.com \
    --to=rogerq@ti.com \
    --cc=alex.smith@imgtec.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=fcooper@ti.com \
    --cc=harvey.hunt@imgtec.com \
    --cc=javier@dowhile0.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --cc=tony@atomide.com \
    /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.