date:20151203

Re: [RFC PATCH 0/4] Command Queueing Support in eMMC

2015-12-03 Thread Dong Aisheng

On Fri, Dec 4, 2015 at 12:40 PM, Das, Asutosh (asd)
 wrote:
> + Kostya
> Hi Aisheng,
> Yes, a colleague of mine is working on upstreaming it. It should be done
> within a week or so.
>

Great! Thanks!
Looking forward to it.

Regards
Dong Aisheng

>
> On 12/3/2015 9:12 AM, Dong Aisheng wrote:
>>
>> Hi Asutosh,
>>
>> On Tue, Dec 2, 2014 at 7:53 PM, Asutosh Das 
>> wrote:
>>>
>>> In this patch series, we propose a method to add support for
>>> Command Queueing(CQ) feature added to eMMC-5.1 specification.
>>> This feature includes new commands for issuing tasks to the
>>> device and orders the execution of tasks to the device. It
>>> also has task management functions.
>>>
>>> The initialization of CQ is decided based on the underlying
>>> driver capability and the capability advertised by the card
>>> through ext_csd.
>>>
>>> We have selectively adopted the scsi design of pulling in
>>> requests from kernel block layer.
>>>
>>> In order to support queueing of multiple requests, we have
>>> added a new issue function to mmc-queue. This selectively
>>> pulls the requests and prepares and issues it to the underlying
>>> driver. We have used the inherent tagging mechanism of kernel
>>> block layer to keep track and map tags to the slots of underlying
>>> driver. The current design doesn't block for the request to
>>> complete. We have separated the issuing and completion path
>>> of the request and tracking is done using the tag assigned to
>>> the request.
>>>
>>> We have introduced a number of APIs to mmc block layer to
>>> facilitate servicing of requests.
>>>
>>> The completion of requests is handled in a softirq registered
>>> with the kernel block layer during initialization. The error
>>> handling however would be done using a workqueue and is under
>>> development.
>>>
>>> We have separated the legacy eMMC code from CQ code, so as to
>>> make it more manageable.
>>>
>>> A new layer has been introduced to serve the CQ compliant drivers.
>>> This layer (cq_hci) has all the standard functionality implemented.
>>> It also has necessary hooks for convenience of platform drivers.
>>>
>>> Asutosh Das (4):
>>>mmc: queue: initialization of command-queue support
>>>mmc: card: Add eMMC command queuing support in mmc block layer
>>>mmc: cmdq: support for command queue enabled host
>>>mmc: sdhci: add command queue support to sdhci
>>>
>>> Sujit Reddy Thumma (1):
>>>mmc: core: Add support to read command queue parameters
>>>
>>>   drivers/mmc/card/block.c   | 378
>>> -
>>>   drivers/mmc/card/queue.c   | 160 ++-
>>>   drivers/mmc/card/queue.h   |   9 +-
>>>   drivers/mmc/core/core.c|  87 +++
>>>   drivers/mmc/core/mmc.c |  19 +++
>>>   drivers/mmc/core/mmc_ops.c |  45 --
>>>   drivers/mmc/host/Kconfig   |  12 ++
>>>   drivers/mmc/host/Makefile  |   1 +
>>>   drivers/mmc/host/sdhci.c   |  89 +++
>>>   drivers/mmc/host/sdhci.h   |   2 +
>>>   include/linux/mmc/card.h   |  10 +-
>>>   include/linux/mmc/core.h   |  14 ++
>>>   include/linux/mmc/host.h   |  72 +
>>>   include/linux/mmc/mmc.h|   9 ++
>>>   include/linux/mmc/sdhci.h  |   1 +
>>>   15 files changed, 887 insertions(+), 21 deletions(-)
>>>
>> Are you still working on this?
>> Is there a updated version and any upstream plan?
>> I'm going to verify it.
>>
>> Regards
>> Dong Aisheng
>>
>>> --
>>> 1.8.2.1
>>>
>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> a Linux Foundation Collaborative Project
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/4] Command Queueing Support in eMMC

2015-12-03 Thread Das, Asutosh (asd)


+ Kostya
Hi Aisheng,
Yes, a colleague of mine is working on upstreaming it. It should be done 
within a week or so.


On 12/3/2015 9:12 AM, Dong Aisheng wrote:

Hi Asutosh,

On Tue, Dec 2, 2014 at 7:53 PM, Asutosh Das  wrote:

In this patch series, we propose a method to add support for
Command Queueing(CQ) feature added to eMMC-5.1 specification.
This feature includes new commands for issuing tasks to the
device and orders the execution of tasks to the device. It
also has task management functions.

The initialization of CQ is decided based on the underlying
driver capability and the capability advertised by the card
through ext_csd.

We have selectively adopted the scsi design of pulling in
requests from kernel block layer.

In order to support queueing of multiple requests, we have
added a new issue function to mmc-queue. This selectively
pulls the requests and prepares and issues it to the underlying
driver. We have used the inherent tagging mechanism of kernel
block layer to keep track and map tags to the slots of underlying
driver. The current design doesn't block for the request to
complete. We have separated the issuing and completion path
of the request and tracking is done using the tag assigned to
the request.

We have introduced a number of APIs to mmc block layer to
facilitate servicing of requests.

The completion of requests is handled in a softirq registered
with the kernel block layer during initialization. The error
handling however would be done using a workqueue and is under
development.

We have separated the legacy eMMC code from CQ code, so as to
make it more manageable.

A new layer has been introduced to serve the CQ compliant drivers.
This layer (cq_hci) has all the standard functionality implemented.
It also has necessary hooks for convenience of platform drivers.

Asutosh Das (4):
   mmc: queue: initialization of command-queue support
   mmc: card: Add eMMC command queuing support in mmc block layer
   mmc: cmdq: support for command queue enabled host
   mmc: sdhci: add command queue support to sdhci

Sujit Reddy Thumma (1):
   mmc: core: Add support to read command queue parameters

  drivers/mmc/card/block.c   | 378 -
  drivers/mmc/card/queue.c   | 160 ++-
  drivers/mmc/card/queue.h   |   9 +-
  drivers/mmc/core/core.c|  87 +++
  drivers/mmc/core/mmc.c |  19 +++
  drivers/mmc/core/mmc_ops.c |  45 --
  drivers/mmc/host/Kconfig   |  12 ++
  drivers/mmc/host/Makefile  |   1 +
  drivers/mmc/host/sdhci.c   |  89 +++
  drivers/mmc/host/sdhci.h   |   2 +
  include/linux/mmc/card.h   |  10 +-
  include/linux/mmc/core.h   |  14 ++
  include/linux/mmc/host.h   |  72 +
  include/linux/mmc/mmc.h|   9 ++
  include/linux/mmc/sdhci.h  |   1 +
  15 files changed, 887 insertions(+), 21 deletions(-)


Are you still working on this?
Is there a updated version and any upstream plan?
I'm going to verify it.

Regards
Dong Aisheng


--
1.8.2.1

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v03 03/15] dmaengine: core: Introduce new, universal API to request a channel

2015-12-03 Thread Peter Ujfalusi

On 12/02/2015 04:35 PM, Andy Shevchenko wrote:
>> +const static struct dma_filter_map *dma_filter_match(struct dma_device 
>> *device,
>> +  const char *name,
>> +  struct device *dev)
>> +{
>> +   const struct dma_filter_map *map_found = NULL;
>> +   int i;
>> +
>> +   if (!device->filter_map.mapcnt)
>> +   return NULL;
>> +
>> +   for (i = 0; i < device->filter_map.mapcnt; i++) {
>> +   const struct dma_filter_map *map = 
>> >filter_map.map[i];
>> +
>> +   if (!strcmp(map->devname, dev_name(dev)) &&
>> +   !strcmp(map->slave, name)) {
>> +   map_found = map;
>> +   break;
> 
> return map?
> 
>> +   }
>> +   }
>> +
> 
> return NULL;

OK.

> 
>> +   return map_found;
>> +}
>> +
>> +/**
>> + * dma_request_chan - try to allocate an exclusive slave channel
>> + * @dev:   pointer to client device structure
>> + * @name:  slave channel name
>> + *
>> + * Returns pointer to appropriate DMA channel on success or an error 
>> pointer.
>> + */
>> +struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>> +{
>> +   struct dma_device *device, *_d;
> 
> If you name *d, *_d; it would…
> 
>> +   struct dma_chan *chan = NULL;
>> +
> 
>> +   /* If device-tree is present get slave info from here */
>> +   if (dev->of_node)
>> +   chan = of_dma_request_slave_channel(dev->of_node, name);
>> +
>> +   /* If device was enumerated by ACPI get slave info from here */
>> +   if (has_acpi_companion(dev) && !chan)
>> +   chan = acpi_dma_request_slave_chan_by_name(dev, name);
> 
> This part might be a good candidate to be moved to
> drivers/base/property.c as
> struct dma_chan *device_property_dma_request_chan(…) or alike.

Not sure if it is a good idea. We want users to use the dmaengine API for
requesting DMA channels, but if we just add renamed
dma_request_slave_channel_reason() - essentially the
device_property_dma_request_chan() would be the same - what users will stop to
use some random API to request the channel?
I'm not really sure if something which is returning 'struct dma_chan *' can be
considered as property to anything. The DMA request number can be seen as a
property for a given device, but a dmaengine related pointer?

Actually I was thinking to move the declaration for these from
include/linux/of_dma.h/acpi_dma.h to a header under drivers/dma/

Also move as much local to dmaengine as it is possible to have cleaner
interface towards the client drivers.

> 
>> +
>> +   if (chan) {
>> +   /* Valid channel found */
>> +   if (!IS_ERR(chan))
>> +   return chan;
>> +
> 
> They might return EPROBE_DEFER. Is any specific handling needed here?

-EPROBE_DEFER means that the DMA driver is not yet loaded and in this case the
lookup for the filter function would also fail, but we have additional and
needless warning printed out. It is better to return with the deferred code 
also.

> 
>> +   pr_warn("%s: %s DMA request failed, falling back to 
>> legacy\n",
>> +   __func__, dev->of_node ? "OF" : "ACPI");
>> +   }
>> +
>> +   /* Try to find the channel via the DMA filter map(s) */
>> +   mutex_lock(_list_mutex);
>> +   list_for_each_entry_safe(device, _d, _device_list, global_node) {
>> +   dma_cap_mask_t mask;
>> +   const struct dma_filter_map *map = dma_filter_match(device,
>> +   name, 
>> dev);
>> +
>> +   if (!map)
>> +   continue;
>> +
>> +   dma_cap_zero(mask);
>> +   dma_cap_set(DMA_SLAVE, mask);
>> +
>> +   chan = find_candidate(device, ,
>> + device->filter_map.filter_fn, 
>> map->param);
> 
> …allow to put this on single line I believe.

if not in one line, but will look much better.

> 
>> +   if (!IS_ERR(chan))
>> +   break;
>> +   }
>> +   mutex_unlock(_list_mutex);
>> +
>> +   return chan ? chan : ERR_PTR(-EPROBE_DEFER);
>> +}
>> +EXPORT_SYMBOL_GPL(dma_request_chan);
>> +
>> +/**
>> + * dma_request_chan_by_mask - allocate a channel satisfying certain 
>> capabilities
>> + * @mask: capabilities that the channel must satisfy
>> + *
>> + * Returns pointer to appropriate DMA channel on success or an error 
>> pointer.
>> + */
>> +struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask)
>> +{
>> +   struct dma_chan *chan;
>> +
>> +   if (!mask)
>> +   return ERR_PTR(-ENODEV);
>> +
>> +   chan = __dma_request_channel(mask, NULL, NULL);
>> +   if (!chan)
>> +   chan = ERR_PTR(-ENODEV);
>> +
>> +   return chan;
>> +}
>>

[PATCH] mmc: sdhci-acpi: set non-removable in ACPI table

2015-12-03 Thread Philip Elcan

This allows setting an SDHC controller as non-removable
by using the _RMV method in the ACPI table. It doesn't
mark it as non-removable if GPIO card detection is
already setup.

Signed-off-by: Philip Elcan 
---
 drivers/mmc/host/sdhci-acpi.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index f6047fc..8c06ba6 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -288,6 +288,20 @@ static const struct sdhci_acpi_slot 
*sdhci_acpi_get_slot(const char *hid,
return NULL;
 }
 
+static bool sdhci_acpi_is_removable(acpi_handle handle)
+{
+   acpi_status status;
+   unsigned long long removable = 1; /* default to removable */
+
+   if (acpi_has_method(handle, "_EJ0"))
+   return true;
+   status = acpi_evaluate_integer(handle, "_RMV", NULL, );
+   if (ACPI_SUCCESS(status) && !removable)
+   return false;
+
+   return true;
+}
+
 static int sdhci_acpi_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -300,6 +314,7 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
const char *hid;
const char *uid;
int err;
+   bool gpio_cd = false;
 
if (acpi_bus_get_device(handle, ))
return -ENODEV;
@@ -373,9 +388,14 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
if (mmc_gpiod_request_cd(host->mmc, NULL, 0, v, 0, NULL)) {
dev_warn(dev, "failed to setup card detect gpio\n");
c->use_runtime_pm = false;
+   } else {
+   gpio_cd = true;
}
}
 
+   if (!gpio_cd && !sdhci_acpi_is_removable(handle))
+   host->mmc->caps |= MMC_CAP_NONREMOVABLE;
+
err = sdhci_add_host(host);
if (err)
goto err_free;
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: sdhci-acpi: set non-removable in ACPI table

2015-12-03 Thread Adrian Hunter

On 03/12/15 15:48, Philip Elcan wrote:
> This allows setting an SDHC controller as non-removable
> by using the _RMV method in the ACPI table. It doesn't

Is that _RMV on the host controller?  Shouldn't it be on the card i.e. child
device node?

> mark it as non-removable if GPIO card detection is
> already setup.
> 
> Signed-off-by: Philip Elcan 
> ---
>  drivers/mmc/host/sdhci-acpi.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
> index f6047fc..8c06ba6 100644
> --- a/drivers/mmc/host/sdhci-acpi.c
> +++ b/drivers/mmc/host/sdhci-acpi.c
> @@ -288,6 +288,20 @@ static const struct sdhci_acpi_slot 
> *sdhci_acpi_get_slot(const char *hid,
>   return NULL;
>  }
>  
> +static bool sdhci_acpi_is_removable(acpi_handle handle)
> +{
> + acpi_status status;
> + unsigned long long removable = 1; /* default to removable */
> +
> + if (acpi_has_method(handle, "_EJ0"))
> + return true;
> + status = acpi_evaluate_integer(handle, "_RMV", NULL, );
> + if (ACPI_SUCCESS(status) && !removable)
> + return false;
> +
> + return true;
> +}
> +
>  static int sdhci_acpi_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> @@ -300,6 +314,7 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
>   const char *hid;
>   const char *uid;
>   int err;
> + bool gpio_cd = false;
>  
>   if (acpi_bus_get_device(handle, ))
>   return -ENODEV;
> @@ -373,9 +388,14 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
>   if (mmc_gpiod_request_cd(host->mmc, NULL, 0, v, 0, NULL)) {
>   dev_warn(dev, "failed to setup card detect gpio\n");
>   c->use_runtime_pm = false;
> + } else {
> + gpio_cd = true;
>   }
>   }
>  
> + if (!gpio_cd && !sdhci_acpi_is_removable(handle))
> + host->mmc->caps |= MMC_CAP_NONREMOVABLE;
> +
>   err = sdhci_add_host(host);
>   if (err)
>   goto err_free;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/4] Command Queueing Support in eMMC

Re: [RFC PATCH 0/4] Command Queueing Support in eMMC

Re: [RFC v03 03/15] dmaengine: core: Introduce new, universal API to request a channel

[PATCH] mmc: sdhci-acpi: set non-removable in ACPI table

Re: [PATCH] mmc: sdhci-acpi: set non-removable in ACPI table

5 matches

Site Navigation

Mail list logo

Footer information