All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Kishon Vijay Abraham I <kishon@ti.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 11/16] mmc: sdhci: Program a relatively accurate SW timeout value
Date: Mon, 19 Feb 2018 15:13:23 +0200	[thread overview]
Message-ID: <89a159dc-1601-5c19-1468-c0efeb1bb2a2@intel.com> (raw)
In-Reply-To: <a65e45a0-8032-b2b8-c590-c28a5e12a5c6@intel.com>

On 19/02/18 11:24, Adrian Hunter wrote:
> On 05/02/18 14:50, Kishon Vijay Abraham I wrote:
>> sdhci has a 10 second timeout to catch devices that stop responding.
>> Instead of programming 10 second arbitrary value, calculate the total time
>> it would take for the entire transfer to happen and program the timeout
>> value accordingly.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>>  drivers/mmc/host/sdhci.c | 46 +++++++++++++++++++++++++++++++++++++++-------
>>  drivers/mmc/host/sdhci.h | 10 ++++++++++
>>  2 files changed, 49 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 0489572d1892..d52f9e7eabe2 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -673,6 +673,37 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
>>  	}
>>  }
>>  
>> +static void sdhci_calc_sw_timeout(struct sdhci_host *host,
>> +				  struct mmc_command *cmd,
>> +				  unsigned int target_timeout)
>> +{
>> +	struct mmc_data *data = cmd->data;
>> +	struct mmc_host *mmc = host->mmc;
>> +	unsigned long long transfer_time;
>> +	struct mmc_ios *ios = &mmc->ios;
>> +	unsigned char bus_width = ios->bus_width;
>> +	unsigned int blksz;
>> +	unsigned int freq;
>> +
>> +	if (data) {
>> +		blksz = data->blksz;
>> +		freq = host->mmc->actual_clock ? host->mmc->actual_clock :
>> +						host->clock;
> 
> I think this can be:
> 
> 		freq = host->mmc->actual_clock ? : host->clock;
> 
>> +		transfer_time = (unsigned long long)(blksz * NSEC_PER_SEC *
>> +						     (8 / bus_width)) / freq;
> 
> You have got a 32-bit overflow here and a 64-bit division that can't always
> be done with '/'
> 
>> +		/* multiply by '2' to account for any unknowns */
>> +		transfer_time = transfer_time * 2;
> 
> 		transfer_time *= 2;
> 
>> +		/* calculate timeout for the entire data */
>> +		host->data_timeout = (data->blocks * ((target_timeout *
>> +						       NSEC_PER_USEC) +
>> +						       transfer_time));
>> +	} else {
>> +		host->data_timeout = target_timeout * NSEC_PER_USEC;
> 
> And another 32-bit overflow here
> 
>> +	}
>> +
>> +	host->data_timeout += MMC_CMD_TRANSFER_TIME;
>> +}
>> +
>>  static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
>>  {
>>  	u8 count;
>> @@ -742,6 +773,7 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
>>  			host->hw_timeout_disabled = true;
>>  		}
>>  	}
>> +	sdhci_calc_sw_timeout(host, cmd, target_timeout);
>>  
>>  	return count;
>>  }
>> @@ -1130,13 +1162,6 @@ void sdhci_send_command(struct sdhci_host *host, struct mmc_command *cmd)
>>  		mdelay(1);
>>  	}
>>  
>> -	timeout = jiffies;
>> -	if (!cmd->data && cmd->busy_timeout > 9000)
>> -		timeout += DIV_ROUND_UP(cmd->busy_timeout, 1000) * HZ + HZ;
>> -	else
>> -		timeout += 10 * HZ;
>> -	sdhci_mod_timer(host, cmd, timeout);
>> -
>>  	host->cmd = cmd;
>>  	if (sdhci_data_line_cmd(cmd)) {
>>  		WARN_ON(host->data_cmd);
>> @@ -1176,6 +1201,13 @@ void sdhci_send_command(struct sdhci_host *host, struct mmc_command *cmd)
>>  	    cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200)
>>  		flags |= SDHCI_CMD_DATA;
>>  
>> +	timeout = jiffies;
>> +	if (sdhci_data_line_cmd(cmd))
>> +		timeout += nsecs_to_jiffies(host->data_timeout);
>> +	else
>> +		timeout += 10 * HZ;
>> +	sdhci_mod_timer(host, cmd, timeout);
> 
> Here you probably want to avoid updating the timer if the mrq has already
> started using host->data_timeout.
> 
>> +
>>  	sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND);
>>  }
>>  EXPORT_SYMBOL_GPL(sdhci_send_command);
>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
>> index 3a967a56fcc3..b73577d77856 100644
>> --- a/drivers/mmc/host/sdhci.h
>> +++ b/drivers/mmc/host/sdhci.h
>> @@ -332,6 +332,14 @@ struct sdhci_adma2_64_desc {
>>  /* Allow for a a command request and a data request at the same time */
>>  #define SDHCI_MAX_MRQS		2
>>  
>> +/*
>> + * 48bit command and 136 bit response in 400KHz clock should take 0.46ms.
> 
> I am not sure the math is correct here.  I would add the 64 clocks before
> the response also, and allow for 100 kHz clock.
> 
> 	(48 + 64 + 136) * 100 us = 24.8 ms

No I am off by x10, sorry!  I would still go for 10 ms.

> 
> Given that you are looking at data block timeouts in excess of 700 ms, and
> anything up to 10% of that is relatively negligible, anything less that 70
> ms seems fine, so I would set 30 ms here as a round number.
> 
>> + * However since the start time of the command, the time between
>> + * command and response, and the time between response and start of data is
>> + * not known, set the command transfer time to 2ms.
>> + */
>> +#define MMC_CMD_TRANSFER_TIME	(2 * NSEC_PER_MSEC) /* max 2 ms */
>> +
>>  enum sdhci_cookie {
>>  	COOKIE_UNMAPPED,
>>  	COOKIE_PRE_MAPPED,	/* mapped by sdhci_pre_req() */
>> @@ -554,6 +562,8 @@ struct sdhci_host {
>>  	/* Host SDMA buffer boundary. */
>>  	u32			sdma_boundary;
>>  
>> +	unsigned long long	data_timeout;
> 
> nsecs_to_jiffies() uses u64 which is nicer I think
> 
>> +
>>  	unsigned long private[0] ____cacheline_aligned;
>>  };
>>  
>>
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Adrian Hunter <adrian.hunter@intel.com>
To: Kishon Vijay Abraham I <kishon@ti.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Tony Lindgren <tony@atomide.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
	Russell King <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 11/16] mmc: sdhci: Program a relatively accurate SW timeout value
Date: Mon, 19 Feb 2018 15:13:23 +0200	[thread overview]
Message-ID: <89a159dc-1601-5c19-1468-c0efeb1bb2a2@intel.com> (raw)
In-Reply-To: <a65e45a0-8032-b2b8-c590-c28a5e12a5c6@intel.com>

On 19/02/18 11:24, Adrian Hunter wrote:
> On 05/02/18 14:50, Kishon Vijay Abraham I wrote:
>> sdhci has a 10 second timeout to catch devices that stop responding.
>> Instead of programming 10 second arbitrary value, calculate the total time
>> it would take for the entire transfer to happen and program the timeout
>> value accordingly.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>>  drivers/mmc/host/sdhci.c | 46 +++++++++++++++++++++++++++++++++++++++-------
>>  drivers/mmc/host/sdhci.h | 10 ++++++++++
>>  2 files changed, 49 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 0489572d1892..d52f9e7eabe2 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -673,6 +673,37 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
>>  	}
>>  }
>>  
>> +static void sdhci_calc_sw_timeout(struct sdhci_host *host,
>> +				  struct mmc_command *cmd,
>> +				  unsigned int target_timeout)
>> +{
>> +	struct mmc_data *data = cmd->data;
>> +	struct mmc_host *mmc = host->mmc;
>> +	unsigned long long transfer_time;
>> +	struct mmc_ios *ios = &mmc->ios;
>> +	unsigned char bus_width = ios->bus_width;
>> +	unsigned int blksz;
>> +	unsigned int freq;
>> +
>> +	if (data) {
>> +		blksz = data->blksz;
>> +		freq = host->mmc->actual_clock ? host->mmc->actual_clock :
>> +						host->clock;
> 
> I think this can be:
> 
> 		freq = host->mmc->actual_clock ? : host->clock;
> 
>> +		transfer_time = (unsigned long long)(blksz * NSEC_PER_SEC *
>> +						     (8 / bus_width)) / freq;
> 
> You have got a 32-bit overflow here and a 64-bit division that can't always
> be done with '/'
> 
>> +		/* multiply by '2' to account for any unknowns */
>> +		transfer_time = transfer_time * 2;
> 
> 		transfer_time *= 2;
> 
>> +		/* calculate timeout for the entire data */
>> +		host->data_timeout = (data->blocks * ((target_timeout *
>> +						       NSEC_PER_USEC) +
>> +						       transfer_time));
>> +	} else {
>> +		host->data_timeout = target_timeout * NSEC_PER_USEC;
> 
> And another 32-bit overflow here
> 
>> +	}
>> +
>> +	host->data_timeout += MMC_CMD_TRANSFER_TIME;
>> +}
>> +
>>  static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
>>  {
>>  	u8 count;
>> @@ -742,6 +773,7 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
>>  			host->hw_timeout_disabled = true;
>>  		}
>>  	}
>> +	sdhci_calc_sw_timeout(host, cmd, target_timeout);
>>  
>>  	return count;
>>  }
>> @@ -1130,13 +1162,6 @@ void sdhci_send_command(struct sdhci_host *host, struct mmc_command *cmd)
>>  		mdelay(1);
>>  	}
>>  
>> -	timeout = jiffies;
>> -	if (!cmd->data && cmd->busy_timeout > 9000)
>> -		timeout += DIV_ROUND_UP(cmd->busy_timeout, 1000) * HZ + HZ;
>> -	else
>> -		timeout += 10 * HZ;
>> -	sdhci_mod_timer(host, cmd, timeout);
>> -
>>  	host->cmd = cmd;
>>  	if (sdhci_data_line_cmd(cmd)) {
>>  		WARN_ON(host->data_cmd);
>> @@ -1176,6 +1201,13 @@ void sdhci_send_command(struct sdhci_host *host, struct mmc_command *cmd)
>>  	    cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200)
>>  		flags |= SDHCI_CMD_DATA;
>>  
>> +	timeout = jiffies;
>> +	if (sdhci_data_line_cmd(cmd))
>> +		timeout += nsecs_to_jiffies(host->data_timeout);
>> +	else
>> +		timeout += 10 * HZ;
>> +	sdhci_mod_timer(host, cmd, timeout);
> 
> Here you probably want to avoid updating the timer if the mrq has already
> started using host->data_timeout.
> 
>> +
>>  	sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND);
>>  }
>>  EXPORT_SYMBOL_GPL(sdhci_send_command);
>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
>> index 3a967a56fcc3..b73577d77856 100644
>> --- a/drivers/mmc/host/sdhci.h
>> +++ b/drivers/mmc/host/sdhci.h
>> @@ -332,6 +332,14 @@ struct sdhci_adma2_64_desc {
>>  /* Allow for a a command request and a data request at the same time */
>>  #define SDHCI_MAX_MRQS		2
>>  
>> +/*
>> + * 48bit command and 136 bit response in 400KHz clock should take 0.46ms.
> 
> I am not sure the math is correct here.  I would add the 64 clocks before
> the response also, and allow for 100 kHz clock.
> 
> 	(48 + 64 + 136) * 100 us = 24.8 ms

No I am off by x10, sorry!  I would still go for 10 ms.

> 
> Given that you are looking at data block timeouts in excess of 700 ms, and
> anything up to 10% of that is relatively negligible, anything less that 70
> ms seems fine, so I would set 30 ms here as a round number.
> 
>> + * However since the start time of the command, the time between
>> + * command and response, and the time between response and start of data is
>> + * not known, set the command transfer time to 2ms.
>> + */
>> +#define MMC_CMD_TRANSFER_TIME	(2 * NSEC_PER_MSEC) /* max 2 ms */
>> +
>>  enum sdhci_cookie {
>>  	COOKIE_UNMAPPED,
>>  	COOKIE_PRE_MAPPED,	/* mapped by sdhci_pre_req() */
>> @@ -554,6 +562,8 @@ struct sdhci_host {
>>  	/* Host SDMA buffer boundary. */
>>  	u32			sdma_boundary;
>>  
>> +	unsigned long long	data_timeout;
> 
> nsecs_to_jiffies() uses u64 which is nicer I think
> 
>> +
>>  	unsigned long private[0] ____cacheline_aligned;
>>  };
>>  
>>
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: adrian.hunter@intel.com (Adrian Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 11/16] mmc: sdhci: Program a relatively accurate SW timeout value
Date: Mon, 19 Feb 2018 15:13:23 +0200	[thread overview]
Message-ID: <89a159dc-1601-5c19-1468-c0efeb1bb2a2@intel.com> (raw)
In-Reply-To: <a65e45a0-8032-b2b8-c590-c28a5e12a5c6@intel.com>

On 19/02/18 11:24, Adrian Hunter wrote:
> On 05/02/18 14:50, Kishon Vijay Abraham I wrote:
>> sdhci has a 10 second timeout to catch devices that stop responding.
>> Instead of programming 10 second arbitrary value, calculate the total time
>> it would take for the entire transfer to happen and program the timeout
>> value accordingly.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>>  drivers/mmc/host/sdhci.c | 46 +++++++++++++++++++++++++++++++++++++++-------
>>  drivers/mmc/host/sdhci.h | 10 ++++++++++
>>  2 files changed, 49 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 0489572d1892..d52f9e7eabe2 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -673,6 +673,37 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
>>  	}
>>  }
>>  
>> +static void sdhci_calc_sw_timeout(struct sdhci_host *host,
>> +				  struct mmc_command *cmd,
>> +				  unsigned int target_timeout)
>> +{
>> +	struct mmc_data *data = cmd->data;
>> +	struct mmc_host *mmc = host->mmc;
>> +	unsigned long long transfer_time;
>> +	struct mmc_ios *ios = &mmc->ios;
>> +	unsigned char bus_width = ios->bus_width;
>> +	unsigned int blksz;
>> +	unsigned int freq;
>> +
>> +	if (data) {
>> +		blksz = data->blksz;
>> +		freq = host->mmc->actual_clock ? host->mmc->actual_clock :
>> +						host->clock;
> 
> I think this can be:
> 
> 		freq = host->mmc->actual_clock ? : host->clock;
> 
>> +		transfer_time = (unsigned long long)(blksz * NSEC_PER_SEC *
>> +						     (8 / bus_width)) / freq;
> 
> You have got a 32-bit overflow here and a 64-bit division that can't always
> be done with '/'
> 
>> +		/* multiply by '2' to account for any unknowns */
>> +		transfer_time = transfer_time * 2;
> 
> 		transfer_time *= 2;
> 
>> +		/* calculate timeout for the entire data */
>> +		host->data_timeout = (data->blocks * ((target_timeout *
>> +						       NSEC_PER_USEC) +
>> +						       transfer_time));
>> +	} else {
>> +		host->data_timeout = target_timeout * NSEC_PER_USEC;
> 
> And another 32-bit overflow here
> 
>> +	}
>> +
>> +	host->data_timeout += MMC_CMD_TRANSFER_TIME;
>> +}
>> +
>>  static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
>>  {
>>  	u8 count;
>> @@ -742,6 +773,7 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
>>  			host->hw_timeout_disabled = true;
>>  		}
>>  	}
>> +	sdhci_calc_sw_timeout(host, cmd, target_timeout);
>>  
>>  	return count;
>>  }
>> @@ -1130,13 +1162,6 @@ void sdhci_send_command(struct sdhci_host *host, struct mmc_command *cmd)
>>  		mdelay(1);
>>  	}
>>  
>> -	timeout = jiffies;
>> -	if (!cmd->data && cmd->busy_timeout > 9000)
>> -		timeout += DIV_ROUND_UP(cmd->busy_timeout, 1000) * HZ + HZ;
>> -	else
>> -		timeout += 10 * HZ;
>> -	sdhci_mod_timer(host, cmd, timeout);
>> -
>>  	host->cmd = cmd;
>>  	if (sdhci_data_line_cmd(cmd)) {
>>  		WARN_ON(host->data_cmd);
>> @@ -1176,6 +1201,13 @@ void sdhci_send_command(struct sdhci_host *host, struct mmc_command *cmd)
>>  	    cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200)
>>  		flags |= SDHCI_CMD_DATA;
>>  
>> +	timeout = jiffies;
>> +	if (sdhci_data_line_cmd(cmd))
>> +		timeout += nsecs_to_jiffies(host->data_timeout);
>> +	else
>> +		timeout += 10 * HZ;
>> +	sdhci_mod_timer(host, cmd, timeout);
> 
> Here you probably want to avoid updating the timer if the mrq has already
> started using host->data_timeout.
> 
>> +
>>  	sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND);
>>  }
>>  EXPORT_SYMBOL_GPL(sdhci_send_command);
>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
>> index 3a967a56fcc3..b73577d77856 100644
>> --- a/drivers/mmc/host/sdhci.h
>> +++ b/drivers/mmc/host/sdhci.h
>> @@ -332,6 +332,14 @@ struct sdhci_adma2_64_desc {
>>  /* Allow for a a command request and a data request at the same time */
>>  #define SDHCI_MAX_MRQS		2
>>  
>> +/*
>> + * 48bit command and 136 bit response in 400KHz clock should take 0.46ms.
> 
> I am not sure the math is correct here.  I would add the 64 clocks before
> the response also, and allow for 100 kHz clock.
> 
> 	(48 + 64 + 136) * 100 us = 24.8 ms

No I am off by x10, sorry!  I would still go for 10 ms.

> 
> Given that you are looking at data block timeouts in excess of 700 ms, and
> anything up to 10% of that is relatively negligible, anything less that 70
> ms seems fine, so I would set 30 ms here as a round number.
> 
>> + * However since the start time of the command, the time between
>> + * command and response, and the time between response and start of data is
>> + * not known, set the command transfer time to 2ms.
>> + */
>> +#define MMC_CMD_TRANSFER_TIME	(2 * NSEC_PER_MSEC) /* max 2 ms */
>> +
>>  enum sdhci_cookie {
>>  	COOKIE_UNMAPPED,
>>  	COOKIE_PRE_MAPPED,	/* mapped by sdhci_pre_req() */
>> @@ -554,6 +562,8 @@ struct sdhci_host {
>>  	/* Host SDMA buffer boundary. */
>>  	u32			sdma_boundary;
>>  
>> +	unsigned long long	data_timeout;
> 
> nsecs_to_jiffies() uses u64 which is nicer I think
> 
>> +
>>  	unsigned long private[0] ____cacheline_aligned;
>>  };
>>  
>>
> 
> 

  reply	other threads:[~2018-02-19 13:14 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-05 12:50 [PATCH v2 00/16] mmc: sdhci-omap: Add UHS/HS200 mode support Kishon Vijay Abraham I
2018-02-05 12:50 ` Kishon Vijay Abraham I
2018-02-05 12:50 ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 01/16] mmc: sdhci-omap: Update 'power_mode' outside sdhci_omap_init_74_clocks Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 02/16] mmc: sdhci-omap: Add card_busy host ops Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 03/16] mmc: sdhci-omap: Add custom set_uhs_signaling sdhci_host ops Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 04/16] mmc: sdhci-omap: Add tuning support Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 05/16] mmc: sdhci-omap: Workaround for Errata i802 Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 06/16] mmc: sdhci_omap: Add support to set IODELAY values Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 07/16] mmc: sdhci_omap: Fix sdhci-omap quirks Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 08/16] mmc: sdhci-omap: Add support to override f_max and iodelay from pdata Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-14  9:53   ` Ulf Hansson
2018-02-14  9:53     ` Ulf Hansson
2018-02-14 17:24     ` Tony Lindgren
2018-02-14 17:24       ` Tony Lindgren
2018-02-16  8:08       ` Kishon Vijay Abraham I
2018-02-16  8:08         ` Kishon Vijay Abraham I
2018-02-16  8:08         ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 09/16] mmc: sdhci: Add quirk to disable HW timeout Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-19  8:51   ` Adrian Hunter
2018-02-19  8:51     ` Adrian Hunter
2018-02-19  8:51     ` Adrian Hunter
2018-03-05  9:30     ` Kishon Vijay Abraham I
2018-03-05  9:30       ` Kishon Vijay Abraham I
2018-03-05  9:30       ` Kishon Vijay Abraham I
2018-03-05  9:38       ` Adrian Hunter
2018-03-05  9:38         ` Adrian Hunter
2018-03-14 13:25         ` Kishon Vijay Abraham I
2018-03-14 13:25           ` Kishon Vijay Abraham I
2018-03-14 13:25           ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 10/16] mmc: sdhci: Fix to use data_timer only for data line commands Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-19  8:03   ` Adrian Hunter
2018-02-19  8:03     ` Adrian Hunter
2018-02-19  8:03     ` Adrian Hunter
2018-02-19 12:55     ` Kishon Vijay Abraham I
2018-02-19 12:55       ` Kishon Vijay Abraham I
2018-02-19 12:55       ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 11/16] mmc: sdhci: Program a relatively accurate SW timeout value Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-16  7:17   ` Kishon Vijay Abraham I
2018-02-16  7:17     ` Kishon Vijay Abraham I
2018-02-16  7:17     ` Kishon Vijay Abraham I
2018-02-19  9:24   ` Adrian Hunter
2018-02-19  9:24     ` Adrian Hunter
2018-02-19  9:24     ` Adrian Hunter
2018-02-19 13:13     ` Adrian Hunter [this message]
2018-02-19 13:13       ` Adrian Hunter
2018-02-19 13:13       ` Adrian Hunter
2018-02-05 12:50 ` [PATCH v2 12/16] mmc: sdhci-omap: Workaround for Errata i834 Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 13/16] dt-bindings: sdhci-omap: Add K2G specific binding Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 14/16] mmc: sdhci-omap: Add support for MMC/SD controller in k2g SoC Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50 ` [PATCH v2 15/16] mmc: sdhci-omap: Add SPDX identifier Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 21:50   ` Joe Perches
2018-02-05 21:50     ` Joe Perches
2018-02-05 21:50     ` Joe Perches
2018-02-19  9:33   ` Adrian Hunter
2018-02-19  9:33     ` Adrian Hunter
2018-02-19  9:33     ` Adrian Hunter
2018-02-05 12:50 ` [PATCH v2 16/16] ARM: OMAP2+: Use sdhci-omap specific pdata-quirks for MMC/SD on DRA74x EVM Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-05 12:50   ` Kishon Vijay Abraham I
2018-02-14 10:38 ` [PATCH v2 00/16] mmc: sdhci-omap: Add UHS/HS200 mode support Ulf Hansson
2018-02-14 10:38   ` Ulf Hansson
2018-02-14 10:38   ` Ulf Hansson

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=89a159dc-1601-5c19-1468-c0efeb1bb2a2@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=tony@atomide.com \
    --cc=ulf.hansson@linaro.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.