Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*

2015-12-14 Thread Arnd Bergmann 
On Monday 14 December 2015 10:19:40 Thierry Reding wrote:
> > PCIe host driver that use fixup (DECLARE_PCI_FIXUP_*) can't use tristate.
> > Fixup region is in kernel region and this region if not updated when
> > loading a module.
> 
> Interesting, I hadn't thought about that. I suppose this means that the
> module will end up containing an unused section with the fixup code. It
> might be useful to add a way for that to trigger a warning at build
> time.
> 
> Perhaps to fix this a mechanism could be introduced to add a table of
> fixups to a host controller driver and that will get applied to all
> children of the bridge. It could be problematic to cover all of the
> different fixup stages, though.
> 


I think a lot of the fixups shouldn't really be there in the first place,
they are about stuff that we can fix up in the probe function, or that should
be fixed up in the probe function with some appropriate core support added.

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

[PATCH V02 0/5] dmaengine: New 'universal' API for requesting channel

2015-12-14 Thread Peter Ujfalusi 
Hi,

Changes since v1:
- Added Reviewed-by from Andy for patch 1-2, I decided to not add the 
reviewed-by
  to patch 3 due to the changes since v1
- patch for omap-dma to support passing the filter setup to the core
- dma_request_slave_channel_reason() remeved and it is now defines as
  dma_request_chan()
- Print of warning removed when DT or ACPI lookup fails and we are going to
  Fallback to legacy lookup
- members of struct dma_filter has been revised for simplicity.

Changes since RFC v03:
- No longer RFC
- Dropped the arch/arm/mcah-davinci and daVinci MMC and SPI patches so we don't
  have inter subsystem issues.
- Comments from Andy to patch no 3 has been addressed with the exception of
  moving code over to device_property
- 'struct dma_filter_map' renamed as 'struct dma_slave_map'
- Code documentation added

Changes since RFC v02:
- Using has_acpi_companion() instead ACPI_HANDLE()
- mask matching change within private_candidate()
- Fallback in dma_request_chan() when DT/ACPI lookup fails.
- Rename dma_get_channel() -> find_candidate()
- Arch code changes as suggested by Arnd
- Some documentation updated, more need to be done.

Changes since RFC v01:
- dma_request_chan(); lost the mask parameter
- The new API does not rely on RESOURCE_DMA, instead the dma_slave_map table
  will be used to provide the needed information to the filter function in
  legacy mode
- Extended the example patches to convert most of daVinci to use the new API to
  request the DMA channels.

As it has been discussed in the following thread:
http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487

With this series I have taken a path which would result two new API, which can
be used to convert most of the current users already and with some work all
users might be able to move to this set.
With this set the filter_fn used for legacy (non DT/ACPI) channel request is no
longer needed to be exported to client drivers since the selection of the
correct filter_fn will be done in the core.

So, the first proposal is to have:

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

The dma_request_chan_by_mask() is to request any channel matching with the
requested capabilities, can be used to request channel for memcpy, memset, xor,
etc where no hardware synchronization is needed.

The dma_request_chan() is to request a slave channel. The dma_request_chan()
will try to find the channel via DT, ACPI or in case if the kernel booted in non
DT/ACPI mode it will use a filter lookup table and retrieves the needed
information from the dma_slave_map provided by the DMA drivers.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static const struct dma_slave_map da830_edma_map[] = {
{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
};

This information is going to be used by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.slave_map = da830_edma_map;
da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to configure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

ecc->dma_slave.filter_map.map = info->slave_map;
ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
ecc->dma_slave.filter_map.fn = edma_filter_fn;

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_slave_map to get the channel with the dma_get_channel() internal
function.

Tested on OMAP-L138 (dm850) EVM, with updtaed patches from RFC v03 [1].
Both legacy and DT boot works fine.

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122016.html

Regards,
Peter
---
Peter Ujfalusi (5):
  dmaengine: core: Skip mask matching when it is not provided to
private_candidate
  dmaengine: core: Move and merge the code paths using private_candidate
  dmaengine: core: Introduce

[PATCH V02 2/5] dmaengine: core: Move and merge the code paths using private_candidate

2015-12-14 Thread Peter Ujfalusi 
Channel matching with private_candidate() is used in two paths, the error
checking is slightly different in them and they are duplicating code also.
Move the code under find_candidate() to provide consistent execution and
going to allow us to reuse this mode of channel lookup later.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Andy Shevchenko 
---
 drivers/dma/dmaengine.c | 81 +
 1 file changed, 42 insertions(+), 39 deletions(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 6311e1fc80be..ea9d66982d40 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -546,6 +546,42 @@ static struct dma_chan *private_candidate(const 
dma_cap_mask_t *mask,
return NULL;
 }
 
+static struct dma_chan *find_candidate(struct dma_device *device,
+  const dma_cap_mask_t *mask,
+  dma_filter_fn fn, void *fn_param)
+{
+   struct dma_chan *chan = private_candidate(mask, device, fn, fn_param);
+   int err;
+
+   if (chan) {
+   /* Found a suitable channel, try to grab, prep, and return it.
+* We first set DMA_PRIVATE to disable balance_ref_count as this
+* channel will not be published in the general-purpose
+* allocator
+*/
+   dma_cap_set(DMA_PRIVATE, device->cap_mask);
+   device->privatecnt++;
+   err = dma_chan_get(chan);
+
+   if (err) {
+   if (err == -ENODEV) {
+   pr_debug("%s: %s module removed\n", __func__,
+dma_chan_name(chan));
+   list_del_rcu(>global_node);
+   } else
+   pr_debug("%s: failed to get %s: (%d)\n",
+__func__, dma_chan_name(chan), err);
+
+   if (--device->privatecnt == 0)
+   dma_cap_clear(DMA_PRIVATE, device->cap_mask);
+
+   chan = ERR_PTR(err);
+   }
+   }
+
+   return chan ? chan : ERR_PTR(-EPROBE_DEFER);
+}
+
 /**
  * dma_get_slave_channel - try to get specific channel exclusively
  * @chan: target channel
@@ -584,7 +620,6 @@ struct dma_chan *dma_get_any_slave_channel(struct 
dma_device *device)
 {
dma_cap_mask_t mask;
struct dma_chan *chan;
-   int err;
 
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -592,23 +627,11 @@ struct dma_chan *dma_get_any_slave_channel(struct 
dma_device *device)
/* lock against __dma_request_channel */
mutex_lock(_list_mutex);
 
-   chan = private_candidate(, device, NULL, NULL);
-   if (chan) {
-   dma_cap_set(DMA_PRIVATE, device->cap_mask);
-   device->privatecnt++;
-   err = dma_chan_get(chan);
-   if (err) {
-   pr_debug("%s: failed to get %s: (%d)\n",
-   __func__, dma_chan_name(chan), err);
-   chan = NULL;
-   if (--device->privatecnt == 0)
-   dma_cap_clear(DMA_PRIVATE, device->cap_mask);
-   }
-   }
+   chan = find_candidate(device, , NULL, NULL);
 
mutex_unlock(_list_mutex);
 
-   return chan;
+   return IS_ERR(chan) ? NULL : chan;
 }
 EXPORT_SYMBOL_GPL(dma_get_any_slave_channel);
 
@@ -625,35 +648,15 @@ struct dma_chan *__dma_request_channel(const 
dma_cap_mask_t *mask,
 {
struct dma_device *device, *_d;
struct dma_chan *chan = NULL;
-   int err;
 
/* Find a channel */
mutex_lock(_list_mutex);
list_for_each_entry_safe(device, _d, _device_list, global_node) {
-   chan = private_candidate(mask, device, fn, fn_param);
-   if (chan) {
-   /* Found a suitable channel, try to grab, prep, and
-* return it.  We first set DMA_PRIVATE to disable
-* balance_ref_count as this channel will not be
-* published in the general-purpose allocator
-*/
-   dma_cap_set(DMA_PRIVATE, device->cap_mask);
-   device->privatecnt++;
-   err = dma_chan_get(chan);
+   chan = find_candidate(device, mask, fn, fn_param);
+   if (!IS_ERR(chan))
+   break;
 
-   if (err == -ENODEV) {
-   pr_debug("%s: %s module removed\n",
-__func__, dma_chan_name(chan));
-   list_del_rcu(>global_node);
-   } else if (err)
-   pr_debug("%s: failed to get %s: (%d)\n",
-

[PATCH V02 5/5] dmaengine: omap-dma: Add support for DMA filter mapping to slave devices

2015-12-14 Thread Peter Ujfalusi 
Add support for providing device to filter_fn mapping so client drivers
can switch to use the dma_request_chan() API.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/omap-dma.c   | 4 
 include/linux/omap-dma.h | 6 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index f86827ac0c8a..9794b073d7d7 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1153,6 +1153,10 @@ static int omap_dma_probe(struct platform_device *pdev)
return rc;
}
 
+   od->ddev.filter.map = od->plat->slave_map;
+   od->ddev.filter.mapcnt = od->plat->slavecnt;
+   od->ddev.filter.fn = omap_dma_filter_fn;
+
rc = dma_async_device_register(>ddev);
if (rc) {
pr_warn("OMAP-DMA: failed to register slave DMA engine device: 
%d\n",
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 88fa8af2b937..1d99b61adc65 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -267,6 +267,9 @@ struct omap_dma_reg {
u8  type;
 };
 
+#define SDMA_FILTER_PARAM(hw_req)  ((int[]) { (hw_req) })
+struct dma_slave_map;
+
 /* System DMA platform data structure */
 struct omap_system_dma_plat_info {
const struct omap_dma_reg *reg_map;
@@ -278,6 +281,9 @@ struct omap_system_dma_plat_info {
void (*clear_dma)(int lch);
void (*dma_write)(u32 val, int reg, int lch);
u32 (*dma_read)(int reg, int lch);
+
+   const struct dma_slave_map *slave_map;
+   int slavecnt;
 };
 
 #ifdef CONFIG_ARCH_OMAP2PLUS
-- 
2.6.4

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

[PATCH V02 4/5] dmaengine: edma: Add support for DMA filter mapping to slave devices

2015-12-14 Thread Peter Ujfalusi 
Add support for providing device to filter_fn mapping so client drivers
can switch to use the dma_request_chan() API.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/edma.c | 4 
 include/linux/platform_data/edma.h | 7 +++
 2 files changed, 11 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 16fe773fb846..2e8acde6b134 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2314,6 +2314,10 @@ static int edma_probe(struct platform_device *pdev)
edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
}
 
+   ecc->dma_slave.filter.map = info->slave_map;
+   ecc->dma_slave.filter.mapcnt = info->slavecnt;
+   ecc->dma_slave.filter.fn = edma_filter_fn;
+
ret = dma_async_device_register(>dma_slave);
if (ret) {
dev_err(dev, "slave ddev registration failed (%d)\n", ret);
diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index 4299f4ba03bd..0a533f94438f 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -53,12 +53,16 @@ enum dma_event_q {
 #define EDMA_CTLR(i)   ((i) >> 16)
 #define EDMA_CHAN_SLOT(i)  ((i) & 0x)
 
+#define EDMA_FILTER_PARAM(ctlr, chan)  ((int[]) { EDMA_CTLR_CHAN(ctlr, chan) })
+
 struct edma_rsv_info {
 
const s16   (*rsv_chans)[2];
const s16   (*rsv_slots)[2];
 };
 
+struct dma_slave_map;
+
 /* platform_data for EDMA driver */
 struct edma_soc_info {
/*
@@ -76,6 +80,9 @@ struct edma_soc_info {
 
s8  (*queue_priority_mapping)[2];
const s16   (*xbar_chans)[2];
+
+   const struct dma_slave_map *slave_map;
+   int slavecnt;
 };
 
 #endif
-- 
2.6.4

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

Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*

2015-12-14 Thread Thierry Reding 
On Mon, Dec 14, 2015 at 04:33:51PM +0800, Ley Foon Tan wrote:
> On Mon, Dec 14, 2015 at 4:24 PM, Thierry Reding
>  wrote:
> > On Mon, Dec 14, 2015 at 09:19:30AM +0100, Geert Uytterhoeven wrote:
> >> Hi Paul,
> >>
> >> On Sun, Dec 13, 2015 at 2:41 AM, Paul Gortmaker
> >>  wrote:
> >> > This series of commits is a slice of a larger project to ensure
> >> > people don't have dead code for module removal in non-modular
> >> > drivers.  Overall there was roughly 5k lines of dead code in the
> >> > kernel due to this.  So far we've fixed several areas, like tty,
> >> > x86, net, etc. and we continue to work on other areas.
> >> >
> >> > There are several reasons to not use module_init for code that can
> >> > never be built as a module, but the big ones are:
> >> >
> >> >  (1) it is easy to accidentally code up unused module_exit and remove 
> >> > code
> >> >  (2) it can be misleading when reading the source, thinking it can be
> >> >   modular when the Makefile and/or Kconfig prohibit it
> >> >  (3) it requires the include of the module.h header file which in turn
> >> >  includes nearly everything else.
> >> >
> >> > Here we convert some module_init() calls into device_initcall() and 
> >> > delete
> >> > any module_exit and remove code that gets orphaned in the process, for
> >> > an overall net code reduction, which is always welcome.
> >> >
> >> > The use of device_initcall ensures that the init function ordering
> >> > remains unchanged, but one could argue that PCI host code might be more
> >> > appropriate to be handled under subsys_initcall.  Fortunately we can
> >> > revisit making this extra change at a later date if desired; it does
> >> > not need to happen now, and we reduce the risk of introducing
> >> > regressions at this point in time by separating the two changes.
> >> >
> >> > Over half of the drivers changed here already explicitly disallowed any
> >> > unbind operations.  For the rest we make them the same, since there is
> >> > not really any sensible use case to unbind any built-in bus support that
> >> > I can think of.
> >>
> >> Personally, I think all of these should become tristate, so distro kernels
> >> don't have to build in PCI(e) support for all SoCs. multi_v7_defconfig 
> >> kernels
> >> are becoming too big.
> >>
> >> That does not preclude making these modules un-unloadable, though.
> >
> > Most of these can't be made tristate as-is, because they use symbols
> > that aren't exported. Many of those symbols can easily be exported, so
> > its just a matter of getting the respective patches merged. I disagree
> > with making the modules non-unloadable, though. I have a local branch
> > with changes necessary to unload the host controller driver and it
> > works just fine.
> >
> PCIe host driver that use fixup (DECLARE_PCI_FIXUP_*) can't use tristate.
> Fixup region is in kernel region and this region if not updated when
> loading a module.

Interesting, I hadn't thought about that. I suppose this means that the
module will end up containing an unused section with the fixup code. It
might be useful to add a way for that to trigger a warning at build
time.

Perhaps to fix this a mechanism could be introduced to add a table of
fixups to a host controller driver and that will get applied to all
children of the bridge. It could be problematic to cover all of the
different fixup stages, though.

Thierry


signature.asc
Description: PGP signature

[PATCH V02 3/5] dmaengine: core: Introduce new, universal API to request a channel

2015-12-14 Thread Peter Ujfalusi 
The two API function can cover most, if not all current APIs used to
request a channel. With minimal effort dmaengine drivers, platforms and
dmaengine user drivers can be converted to use the two function.

struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

To request any channel matching with the requested capabilities, can be
used to request channel for memcpy, memset, xor, etc where no hardware
synchronization is needed.

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
To request a slave channel. The dma_request_chan() will try to find the
channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
it will use a filter lookup table and retrieves the needed information from
the dma_slave_map provided by the DMA drivers.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static const struct dma_slave_map da830_edma_map[] = {
{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
};

This information is going to be needed by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.slave_map = da830_edma_map;
da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to configure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

ecc->dma_slave.filter_map.map = info->slave_map;
ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
ecc->dma_slave.filter_map.fn = edma_filter_fn;

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_slave_map to get the channel with the dma_get_channel() internal
function.

Signed-off-by: Peter Ujfalusi 
---
 Documentation/dmaengine/client.txt | 23 +++---
 drivers/dma/dmaengine.c| 89 +-
 include/linux/dmaengine.h  | 51 +++---
 3 files changed, 127 insertions(+), 36 deletions(-)

diff --git a/Documentation/dmaengine/client.txt 
b/Documentation/dmaengine/client.txt
index d9f9f461102a..9e33189745f0 100644
--- a/Documentation/dmaengine/client.txt
+++ b/Documentation/dmaengine/client.txt
@@ -22,25 +22,14 @@ The slave DMA usage consists of following steps:
Channel allocation is slightly different in the slave DMA context,
client drivers typically need a channel from a particular DMA
controller only and even in some cases a specific channel is desired.
-   To request a channel dma_request_channel() API is used.
+   To request a channel dma_request_chan() API is used.
 
Interface:
-   struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
-   dma_filter_fn filter_fn,
-   void *filter_param);
-   where dma_filter_fn is defined as:
-   typedef bool (*dma_filter_fn)(struct dma_chan *chan, void 
*filter_param);
-
-   The 'filter_fn' parameter is optional, but highly recommended for
-   slave and cyclic channels as they typically need to obtain a specific
-   DMA channel.
-
-   When the optional 'filter_fn' parameter is NULL, dma_request_channel()
-   simply returns the first channel that satisfies the capability mask.
-
-   Otherwise, the 'filter_fn' routine will be called once for each free
-   channel which has a capability in 'mask'.  'filter_fn' is expected to
-   return 'true' when the desired DMA channel is found.
+   struct dma_chan *dma_request_chan(struct device *dev, const char *name);
+
+   Which will find and return the 'name' DMA channel associated with the 'dev'
+   device. The association is done via DT, ACPI or board file based
+   dma_slave_map matching table.
 
A channel allocated via this interface is exclusive to the caller,
until dma_release_channel() is called.
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ea9d66982d40..1e7fdabbc9bb 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -43,6 +43,7 @@
 
 #define

[PATCH V02 1/5] dmaengine: core: Skip mask matching when it is not provided to private_candidate

2015-12-14 Thread Peter Ujfalusi 
If mask is NULL skip the mask matching against the DMA device capabilities.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Andy Shevchenko 
---
 drivers/dma/dmaengine.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index daf54a39bcc7..6311e1fc80be 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -515,7 +515,7 @@ static struct dma_chan *private_candidate(const 
dma_cap_mask_t *mask,
 {
struct dma_chan *chan;
 
-   if (!__dma_device_satisfies_mask(dev, mask)) {
+   if (mask && !__dma_device_satisfies_mask(dev, mask)) {
pr_debug("%s: wrong capabilities\n", __func__);
return NULL;
}
-- 
2.6.4

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

Re: [PATCH V02 0/5] dmaengine: New 'universal' API for requesting channel

2015-12-14 Thread Arnd Bergmann 
On Monday 14 December 2015 13:22:15 Peter Ujfalusi wrote:
> 
> Changes since v1:
> - Added Reviewed-by from Andy for patch 1-2, I decided to not add the 
> reviewed-by
>   to patch 3 due to the changes since v1
> - patch for omap-dma to support passing the filter setup to the core
> - dma_request_slave_channel_reason() remeved and it is now defines as
>   dma_request_chan()
> - Print of warning removed when DT or ACPI lookup fails and we are going to
>   Fallback to legacy lookup
> - members of struct dma_filter has been revised for simplicity.

Whole series

Reviewed-by: Arnd Bergmann 

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

Re: [PATCH v2] clk: ti: Add support for dm814x ADPLL

2015-12-14 Thread Matthijs van Duin 
On Thu, Dec 10, 2015 at 06:26:32PM -0800, Tony Lindgren wrote:
> +- compatible : shall be one of "ti,dm814-adpll-s-clock" or
> +  "ti,dm814-adpll-j-clock" depending on the type of the ADPLL

There's still a j -> lj you missed.

Also, since the device series almost always referred to as dm814x, any 
reason the x is omitted here?  Based on a quick google, dm814 mostly seems 
to be a moose hunting area in alaska ;-)

> +- clocks : link phandles of parent clocks (clk-ref and clk-bypass)

The documentation and your later example calls these clkinp and clkinpulow. 
In theory adpll-s has a third input (clkinphif).

Calling the input clock "clk-ref" is potentially misleading since the 
documentation uses the name "refclk" for clkinp/(N+1). Also, while I'll 
admit "clkinpulow" is an awful name, "clk-bypass" is also misleading since 
it is merely an optional alternative bypass clock, the default being 
clkinp/(N2+1).

Are you aware of any dm814x-sibling that actually uses clkinpulow, or are 
you just including it for completeness or consistency with DPLL instances 
in other devices like the omap4 or am335x?


> + clock-output-names = "481c5040.adpll.dcoclkldo",
> ...
> + clock-output-names = "481c5080.adpll.clkdcoldo",

I know this inconsistency comes straight out of the TRM, but may I vote for 
picking one of them and sticking to it? :-)


> +#define ADPLL_CLKINPHIFSEL_ADPLL_S   19  /* REVISIT: which bit? */

Impossible to say unless a dm814x sibling shows up that actually uses it; 
pll_mpu lacks the HIF clocks entirely.  Note that it's quite possible bit 19 
is indeed officially assigned to it, CLKINPHIFSEL and CLKOUTLDOEN do not 
conflict since they apply to different PLL types.


> +static void ti_adpll_set_bypass(struct ti_adpll_data *d)
> +static void ti_adpll_clear_bypass(struct ti_adpll_data *d)

These functions relate to a specific "Idle Bypass" mode of the PLL,
which gates the refclk and sort of freezes the PLL state.  Various other
control/status bits become unresponsive in this mode as a result.

I would suggest reflecting this in the name, or at least a comment,
since "bypass" refers to a much more general state.  Clearing the IDLE
bit is necessary to take the PLL out of bypass, but other conditions
need to be satisfied as well.  Hence, "clear_bypass" does not not
literally do what its name would seem to suggest.

> +static int ti_adpll_wait_lock(struct ti_adpll_data *d)
> ...
> + while (ti_adpll_clock_is_bypass(d)) {

Locked and bypass are not actually mutually exclusive:  if you only care
about the DCO clock and not CLKOUT you can clear M2PWDNZ before enabling
the PLL, resulting in status (FREQLOCK | PHASELOCK | BYPASS) after lock.

I don't know if there's any reason to take this obscure configuration
into consideration, but I just wanted to make you aware of it.


> +static int ti_adpll_is_prepared(struct clk_hw *hw)
> ...
> + return (v & ADPLL_STATUS_PREPARED_MASK) == ADPLL_STATUS_PREPARED_MASK;

Yet here you do actually test whether the PLL is locked... why the use a
different condition here than in ti_adpll_wait_lock?


> +static unsigned long ti_adpll_recalc_rate(struct clk_hw *hw,
> ...
> + if (ti_adpll_clock_is_bypass(d))
> + return clk_get_rate(d->clocks[TI_ADPLL_N2].clk);

Bypass refers to clkout. This function calculates the DCO clock, which
is never subject to bypass: if the PLL is off, dcoclk is low.


Although I understand the reasoning behind using abstractions like
readl_relaxed() for I/O access to allow portability to platforms where
I/O is not simply memory-mapped, this concern does not exist for
platform-specific devices like this.  There's really no reason in my
humble opinion this code could not simply do

/* read predivider and multiplier, shifted left 18 bits to
 * accomodate the fractional multiplier */
spin_lock_irqsave(>lock, flags);
divider = (pll->n + 1) << 18;
rate = (pll->m << 18) + pll->frac_m;
spin_unlock_irqrestore(>lock, flags);

do_div(rate, divider);

instead of spending a whole paragraph of code on reading each individual
field, which I think just hurts readability.


Note btw that PLLSS is entirely memory-like and is perfectly okay with
16-bit reads/writes.  Grouping the  u16 n, m2, m, n2;  into two 32-bit
registers in the documentation is just TI being silly.


> + frac_m += 1;

que?


> + /* Internal mux, sources from divider N2 or clkinpulow */
> + err = ti_adpll_init_mux(d, TI_ADPLL_ULOW, "ulow",

Shouldn't this just be called "bypass", since it is the bypass clock
after all.  I would associate the name "ulow" only with clkinpulow.


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

[PATCH] mtd: onenand: omap2: Convert to use dmaengine for memcpy

2015-12-14 Thread Peter Ujfalusi 
Do not use the legacy and deprecated omap-dma interface for setting up the
memcpy.

Signed-off-by: Peter Ujfalusi 
---

Hi,

this patch depends on the dma setup simplification patch:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122375.html

We could try to enable the DMA memcpy without condition I believe, but I have
decided to not do it since the code had comments regarding to PM (?) when using
DMA.

Regards,
Peter


 drivers/mtd/onenand/omap2.c | 84 ++---
 1 file changed, 41 insertions(+), 43 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 58576c9babb0..b747217d5e73 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -40,8 +41,6 @@
 #include 
 #include 
 
-#include 
-
 #define DRIVER_NAME "omap2-onenand"
 
 #define ONENAND_BUFRAM_SIZE(1024 * 5)
@@ -56,18 +55,16 @@ struct omap2_onenand {
struct onenand_chip onenand;
struct completion irq_done;
struct completion dma_done;
-   int dma_channel;
+   struct dma_chan *dma_chan;
int freq;
int (*setup)(void __iomem *base, int *freq_ptr);
struct regulator *regulator;
u8 flags;
 };
 
-static void omap2_onenand_dma_cb(int lch, u16 ch_status, void *data)
+static void omap2_onenand_dma_complete_func(void *completion)
 {
-   struct omap2_onenand *c = data;
-
-   complete(>dma_done);
+   complete(completion);
 }
 
 static irqreturn_t omap2_onenand_interrupt(int irq, void *dev_id)
@@ -295,23 +292,33 @@ static inline int omap2_onenand_dma_transfer(struct 
omap2_onenand *c,
 dma_addr_t src, dma_addr_t dst,
 size_t count)
 {
-   int data_type = __ffs((src | dst | count));
+   struct dma_device *dma_dev = c->dma_chan->device;
+   struct dma_async_tx_descriptor *tx = NULL;
+   dma_cookie_t cookie;
 
-   if (data_type > OMAP_DMA_DATA_TYPE_S32)
-   data_type = OMAP_DMA_DATA_TYPE_S32;
-
-   omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
-count / BIT(data_type), 1, 0, 0, 0);
-   omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-   src, 0, 0);
-   omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-dst, 0, 0);
+   tx = dma_dev->device_prep_dma_memcpy(c->dma_chan, dst, src, count, 0);
+   if (!tx) {
+   dev_err(>pdev->dev, "Failed to prepare DMA memcpy\n");
+   return -EIO;
+   }
 
reinit_completion(>dma_done);
-   omap_start_dma(c->dma_channel);
+   tx->callback = omap2_onenand_dma_complete_func;
+   tx->callback_param = >dma_done;
+
+   cookie = tx->tx_submit(tx);
+   if (dma_submit_error(cookie)) {
+   dev_err(>pdev->dev, "Failed to do DMA tx_submit\n");
+   return -EIO;
+   }
+
+   dma_async_issue_pending(c->dma_chan);
+
if (wait_for_completion_timeout(>dma_done, msecs_to_jiffies(20)))
return -ETIMEDOUT;
 
+   dmaengine_terminate_all(c->dma_chan);
+
return 0;
 }
 
@@ -465,7 +472,7 @@ static int omap2_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
/* DMA is not used.  Revisit PM requirements before enabling it. */
-   if (1 || (c->dma_channel < 0) ||
+   if (1 || !c->dma_chan ||
((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
(((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
memcpy(buffer, (__force void *)(this->base + bram_offset),
@@ -503,7 +510,7 @@ static int omap2_onenand_write_bufferram(struct mtd_info 
*mtd, int area,
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
/* DMA is not used.  Revisit PM requirements before enabling it. */
-   if (1 || (c->dma_channel < 0) ||
+   if (1 || !c->dma_chan ||
((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
(((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
memcpy((__force void *)(this->base + bram_offset), buffer,
@@ -608,8 +615,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
c->flags = pdata->flags;
c->gpmc_cs = pdata->cs;
c->gpio_irq = pdata->gpio_irq;
-   c->dma_channel = pdata->dma_channel;
-   if (c->dma_channel < 0) {
+   if (pdata->dma_channel < 0) {
/* if -1, don't use DMA */
c->gpio_irq = 0;
}
@@ -661,25 +667,17 @@ static int omap2_onenand_probe(struct platform_device 
*pdev)
goto

Re: [PATCH V02 3/5] dmaengine: core: Introduce new, universal API to request a channel

2015-12-14 Thread kbuild test robot 
Hi Peter,

[auto build test WARNING on slave-dma/next]
[also build test WARNING on v4.4-rc5 next-20151214]

url:
https://github.com/0day-ci/linux/commits/Peter-Ujfalusi/dmaengine-core-Skip-mask-matching-when-it-is-not-provided-to-private_candidate/20151214-192521
base:   https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/dma/dmaengine.c:715:23-30: ERROR: PTR_ERR applied after 
>> initialization to constant on line 703

vim +715 drivers/dma/dmaengine.c

   697   *
   698   * Returns pointer to appropriate DMA channel on success or an error 
pointer.
   699   */
   700  struct dma_chan *dma_request_chan(struct device *dev, const char *name)
   701  {
   702  struct dma_device *d, *_d;
 > 703  struct dma_chan *chan = NULL;
   704  
   705  /* If device-tree is present get slave info from here */
   706  if (dev->of_node)
   707  chan = of_dma_request_slave_channel(dev->of_node, name);
   708  
   709  /* If device was enumerated by ACPI get slave info from here */
   710  if (has_acpi_companion(dev) && !chan)
   711  chan = acpi_dma_request_slave_chan_by_name(dev, name);
   712  
   713  if (chan) {
   714  /* Valid channel found or requester need to be deferred 
*/
 > 715  if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
   716  return chan;
   717  }
   718  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl:Convert the composition of devm_request_mem_region and devm_ioremap to a single call

2015-12-14 Thread Linus Walleij 
On Thu, Dec 10, 2015 at 11:31 PM, Tony Lindgren  wrote:

>> >
>> > I think we need to add ourselves to MAINTAINERS for this driver,
>> > otherwise we'll keep on missing emails.
>>
>> Good idea! Patches accepted.
>
> How about this one below?

Patch applied for fixes!

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

Re: [PATCH] ARM: OMAP2+: LogicPD Torpedo + Wireless: add Bluetooth support Add WL1283 support through pdata-quirks since the driver lacks DT support

2015-12-14 Thread Tony Lindgren 
* Adam Ford  [151212 19:08]:

Please add a description here like "The binding for wl12xx bluetooth
got removed by commit xyz and until we have a better binding we need
to use the platform data to initialize bluetooth".

Regards,

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

4.4-rc5 : INFO: rcu_sched detected stalls on CPUs/tasks in twl4030_bci_usb_ncb

2015-12-14 Thread Belisko Marek 
Hi,

randomly hit this issue from 4.4-rc1:

[   35.926605] INFO: rcu_sched detected stalls on CPUs/tasks:
[   35.932373]  (detected by 0, t=2602 jiffies, g=519, c=518, q=38)
[   35.938659] All QSes seen, last rcu_sched kthread activity 2602
(-26407--29009), jiffies_till_next_fqs=1, root ->qsmask 0x0
[   35.950317] kworker/0:2 R running  0   964  2 0x0002
[   35.957031] Workqueue: events omap_musb_mailbox_work
[   35.962249] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[   35.970367] [] (show_stack) from []
(rcu_check_callbacks+0x548/0x774)
[   35.978942] [] (rcu_check_callbacks) from []
(update_process_times+0x30/0x5c)
[   35.988250] [] (update_process_times) from []
(tick_sched_handle+0x48/0x54)
[   35.997375] [] (tick_sched_handle) from []
(tick_sched_timer+0x58/0x9c)
[   36.006103] [] (tick_sched_timer) from []
(__hrtimer_run_queues+0x198/0x2b0)
[   36.015319] [] (__hrtimer_run_queues) from []
(hrtimer_interrupt+0xac/0x1f4)
[   36.024536] [] (hrtimer_interrupt) from []
(omap2_gp_timer_interrupt+0x20/0x30)
[   36.034027] [] (omap2_gp_timer_interrupt) from
[] (handle_irq_event_percpu+0x78/0x1d4)
[   36.044128] [] (handle_irq_event_percpu) from
[] (handle_irq_event+0x38/0x5c)
[   36.053436] [] (handle_irq_event) from []
(handle_level_irq+0xf0/0x130)
[   36.062194] [] (handle_level_irq) from []
(generic_handle_irq+0x18/0x28)
[   36.071014] [] (generic_handle_irq) from []
(__handle_domain_irq+0x98/0xd8)
[   36.080139] [] (__handle_domain_irq) from []
(__irq_svc+0x58/0x78)
[   36.088470] [] (__irq_svc) from []
(twl4030_bci_usb_ncb+0x10/0x4c [twl4030_charger])
[   36.098449] [] (twl4030_bci_usb_ncb [twl4030_charger])
from [] (notifier_call_chain+0x48/0x70)
[   36.109283] [] (notifier_call_chain) from []
(__atomic_notifier_call_chain+0x94/0x118)
[   36.119415] [] (__atomic_notifier_call_chain) from
[] (atomic_notifier_call_chain+0x14/0x1c)
[   36.130065] [] (atomic_notifier_call_chain) from
[] (omap_musb_mailbox_work+0x28/0x48)
[   36.140197] [] (omap_musb_mailbox_work) from []
(process_one_work+0x284/0x484)
[   36.149597] [] (process_one_work) from []
(worker_thread+0x2a4/0x3d8)
[   36.158142] [] (worker_thread) from []
(kthread+0xd8/0xec)
[   36.165740] [] (kthread) from []
(ret_from_fork+0x14/0x24)
[   36.173309] rcu_sched kthread starved for 2602 jiffies! g519 c518
f0x2 s3 ->state=0x0


is it known problem? Is there fix for this issue? Thanks.

BR,

marek


-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mtd: onenand: omap2: Simplify the DMA setup for various paths

2015-12-14 Thread Peter Ujfalusi 
We have 4 functions containing almost identical DMA setup code. Create one
function which can set up the DMA for both read and write and use this in
place for the setup code in the driver.
The new function will use wait_for_completion_timeout() and it will figure
out the best data_type to be used for the transfer instead of hardwiring
32 or 16 bit data.

Signed-off-by: Peter Ujfalusi 
---
 drivers/mtd/onenand/omap2.c | 106 ++--
 1 file changed, 42 insertions(+), 64 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 0aacf125938b..58576c9babb0 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -291,6 +291,30 @@ static inline int omap2_onenand_bufferram_offset(struct 
mtd_info *mtd, int area)
return 0;
 }
 
+static inline int omap2_onenand_dma_transfer(struct omap2_onenand *c,
+dma_addr_t src, dma_addr_t dst,
+size_t count)
+{
+   int data_type = __ffs((src | dst | count));
+
+   if (data_type > OMAP_DMA_DATA_TYPE_S32)
+   data_type = OMAP_DMA_DATA_TYPE_S32;
+
+   omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
+count / BIT(data_type), 1, 0, 0, 0);
+   omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
+   src, 0, 0);
+   omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
+dst, 0, 0);
+
+   reinit_completion(>dma_done);
+   omap_start_dma(c->dma_channel);
+   if (wait_for_completion_timeout(>dma_done, msecs_to_jiffies(20)))
+   return -ETIMEDOUT;
+
+   return 0;
+}
+
 #if defined(CONFIG_ARCH_OMAP3) || defined(MULTI_OMAP2)
 
 static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
@@ -301,10 +325,9 @@ static int omap3_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
struct onenand_chip *this = mtd->priv;
dma_addr_t dma_src, dma_dst;
int bram_offset;
-   unsigned long timeout;
void *buf = (void *)buffer;
size_t xtra;
-   volatile unsigned *done;
+   int ret;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
@@ -341,25 +364,10 @@ static int omap3_onenand_read_bufferram(struct mtd_info 
*mtd, int area,
goto out_copy;
}
 
-   omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
-count >> 2, 1, 0, 0, 0);
-   omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-   dma_src, 0, 0);
-   omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-dma_dst, 0, 0);
-
-   reinit_completion(>dma_done);
-   omap_start_dma(c->dma_channel);
-
-   timeout = jiffies + msecs_to_jiffies(20);
-   done = >dma_done.done;
-   while (time_before(jiffies, timeout))
-   if (*done)
-   break;
-
+   ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
dma_unmap_single(>pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
 
-   if (!*done) {
+   if (ret) {
dev_err(>pdev->dev, "timeout waiting for DMA\n");
goto out_copy;
}
@@ -379,9 +387,8 @@ static int omap3_onenand_write_bufferram(struct mtd_info 
*mtd, int area,
struct onenand_chip *this = mtd->priv;
dma_addr_t dma_src, dma_dst;
int bram_offset;
-   unsigned long timeout;
void *buf = (void *)buffer;
-   volatile unsigned *done;
+   int ret;
 
bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
@@ -412,25 +419,10 @@ static int omap3_onenand_write_bufferram(struct mtd_info 
*mtd, int area,
return -1;
}
 
-   omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
-count >> 2, 1, 0, 0, 0);
-   omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-   dma_src, 0, 0);
-   omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-dma_dst, 0, 0);
-
-   reinit_completion(>dma_done);
-   omap_start_dma(c->dma_channel);
-
-   timeout = jiffies + msecs_to_jiffies(20);
-   done = >dma_done.done;
-   while (time_before(jiffies, timeout))
-   if (*done)
-   break;
-
+   ret = omap2_onenand_dma_transfer(c, dma_src, dma_dst, count);
dma_unmap_single(>pdev->dev, dma_src, count, DMA_TO_DEVICE);
 
-   if (!*done) {
+   if (ret) {

[PATCH 0/2] arm: omap2: AM43xx: enable ARM TWD timer

2015-12-14 Thread Grygorii Strashko 
Now ARM TWD timer can be enabled for AM437x devices since all prerequisite
patches have been merged already [1] [2].

But before finally enable ARM TWD timer for UP AM437x devices - 
the Broadcast event source and infrustructure need to be enabled properly.
Otherwise CPUIdle will be broken.

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363989.html
[2] http://www.spinics.net/lists/linux-omap/msg123940.html
Felipe Balbi (1):
  arm: omap2: AM43xx: select ARM TWD timer

Grygorii Strashko (1):
  ARM: OMAP: am43xx: enable GENERIC_CLOCKEVENTS_BROADCAST

 arch/arm/mach-omap2/Kconfig | 2 ++
 arch/arm/mach-omap2/timer.c | 6 ++
 2 files changed, 8 insertions(+)

-- 
2.6.4

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

[PATCH 1/2] ARM: OMAP: am43xx: enable GENERIC_CLOCKEVENTS_BROADCAST

2015-12-14 Thread Grygorii Strashko 
System will misbehave in the following case:
- AM43XX only build (UP);
- CONFIG_CPU_IDLE=y
- ARM TWD timer enabled and selected as clockevent device.

In the above case, It's expected that broadcast timer will be used as
backup timer when CPUIdle will put MPU in low power states where ARM
TWD will stop and lose its context. But, the CONFIG_SMP might not be
selected when kernel is built for AM43XX SoC only and, as result,
GENERIC_CLOCKEVENTS_BROADCAST option will not be selected also. This
will break CPUIdle and System will stuck in low power states.

Hence, fix it by selecting GENERIC_CLOCKEVENTS_BROADCAST option for
AM43XX SoCs always and add empty tick_broadcast() function
implementation - no need to send any IPI on UP. After this change
timer1 will be selected as broadcast timer the same way as for SMP,
and CPUIdle will work properly.

Signed-off-by: Grygorii Strashko 
---
 arch/arm/mach-omap2/Kconfig | 1 +
 arch/arm/mach-omap2/timer.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4b4371d..32a0086 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -65,6 +65,7 @@ config SOC_AM43XX
select MACH_OMAP_GENERIC
select MIGHT_HAVE_CACHE_L2X0
select HAVE_ARM_SCU
+   select GENERIC_CLOCKEVENTS_BROADCAST
 
 config SOC_DRA7XX
bool "TI DRA7XX"
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 3bfde44..f34a809 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -320,6 +320,12 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
return r;
 }
 
+#if !defined(CONFIG_SMP) && defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST)
+void tick_broadcast(const struct cpumask *mask)
+{
+}
+#endif
+
 static void __init omap2_gp_clockevent_init(int gptimer_id,
const char *fck_source,
const char *property)
-- 
2.6.4

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

[PATCH v2 2/2] arm: omap2: AM43xx: select ARM TWD timer

2015-12-14 Thread Grygorii Strashko 
From: Felipe Balbi 

Make sure to tell the kernel that AM437x devices have ARM TWD timer.

Signed-off-by: Felipe Balbi 
[grygorii.stras...@ti.com: drop ARM Global timer selection, because
 it's incompatible with PM (cpuidle/cpufreq). So, it's unsafe to enable
 it unconditionally]
Signed-off-by: Grygorii Strashko 
---
v1: http://www.spinics.net/lists/arm-kernel/msg459649.html

 arch/arm/mach-omap2/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 32a0086..0517f0c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -66,6 +66,7 @@ config SOC_AM43XX
select MIGHT_HAVE_CACHE_L2X0
select HAVE_ARM_SCU
select GENERIC_CLOCKEVENTS_BROADCAST
+   select HAVE_ARM_TWD
 
 config SOC_DRA7XX
bool "TI DRA7XX"
-- 
2.6.4

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

Re: [PATCH v2] clk: ti: Add support for dm814x ADPLL

2015-12-14 Thread Tony Lindgren 
* Matthijs van Duin  [151214 01:16]:
> On Thu, Dec 10, 2015 at 06:26:32PM -0800, Tony Lindgren wrote:
> > +- compatible : shall be one of "ti,dm814-adpll-s-clock" or
> > +  "ti,dm814-adpll-j-clock" depending on the type of the ADPLL
> 
> There's still a j -> lj you missed.

Oops thanks will fix.

> Also, since the device series almost always referred to as dm814x, any 
> reason the x is omitted here?  Based on a quick google, dm814 mostly seems 
> to be a moose hunting area in alaska ;-)

Well we don't want any any wild cards in the dts compatible names.
Typically the first piece of hardware is selected, but that causes
confusion too. So we're using comaptible names like dra7 and dm814.

> > +- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
> 
> The documentation and your later example calls these clkinp and clkinpulow. 
> In theory adpll-s has a third input (clkinphif).
> 
> Calling the input clock "clk-ref" is potentially misleading since the 
> documentation uses the name "refclk" for clkinp/(N+1). Also, while I'll 
> admit "clkinpulow" is an awful name, "clk-bypass" is also misleading since 
> it is merely an optional alternative bypass clock, the default being 
> clkinp/(N2+1).
> 
> Are you aware of any dm814x-sibling that actually uses clkinpulow, or are 
> you just including it for completeness or consistency with DPLL instances 
> in other devices like the omap4 or am335x?

I don't know of any instances using it.. I'll take a look but seems like we
could just leave it out.

> > +   clock-output-names = "481c5040.adpll.dcoclkldo",
> > ...
> > +   clock-output-names = "481c5080.adpll.clkdcoldo",
> 
> I know this inconsistency comes straight out of the TRM, but may I vote for 
> picking one of them and sticking to it? :-)

I vote for dcoclkldo then :) The "cold" name embedded in the other one just
causes me confusion reading it every time..

> > +#define ADPLL_CLKINPHIFSEL_ADPLL_S 19  /* REVISIT: which bit? */
> 
> Impossible to say unless a dm814x sibling shows up that actually uses it; 
> pll_mpu lacks the HIF clocks entirely.  Note that it's quite possible bit 19 
> is indeed officially assigned to it, CLKINPHIFSEL and CLKOUTLDOEN do not 
> conflict since they apply to different PLL types.

Yup.

> > +static void ti_adpll_set_bypass(struct ti_adpll_data *d)
> > +static void ti_adpll_clear_bypass(struct ti_adpll_data *d)
> 
> These functions relate to a specific "Idle Bypass" mode of the PLL,
> which gates the refclk and sort of freezes the PLL state.  Various other
> control/status bits become unresponsive in this mode as a result.
> 
> I would suggest reflecting this in the name, or at least a comment,
> since "bypass" refers to a much more general state.  Clearing the IDLE
> bit is necessary to take the PLL out of bypass, but other conditions
> need to be satisfied as well.  Hence, "clear_bypass" does not not
> literally do what its name would seem to suggest.
> 
> > +static int ti_adpll_wait_lock(struct ti_adpll_data *d)
> > ...
> > +   while (ti_adpll_clock_is_bypass(d)) {

Yeah I have to take a closer look at this whole bypass thing..

> Locked and bypass are not actually mutually exclusive:  if you only care
> about the DCO clock and not CLKOUT you can clear M2PWDNZ before enabling
> the PLL, resulting in status (FREQLOCK | PHASELOCK | BYPASS) after lock.
> 
> I don't know if there's any reason to take this obscure configuration
> into consideration, but I just wanted to make you aware of it.

OK good to know thanks.

> > +static int ti_adpll_is_prepared(struct clk_hw *hw)
> > ...
> > +   return (v & ADPLL_STATUS_PREPARED_MASK) == ADPLL_STATUS_PREPARED_MASK;
> 
> Yet here you do actually test whether the PLL is locked... why the use a
> different condition here than in ti_adpll_wait_lock?
> 
> 
> > +static unsigned long ti_adpll_recalc_rate(struct clk_hw *hw,
> > ...
> > +   if (ti_adpll_clock_is_bypass(d))
> > +   return clk_get_rate(d->clocks[TI_ADPLL_N2].clk);
> 
> Bypass refers to clkout. This function calculates the DCO clock, which
> is never subject to bypass: if the PLL is off, dcoclk is low.

Thanks will check.

> 
> Although I understand the reasoning behind using abstractions like
> readl_relaxed() for I/O access to allow portability to platforms where
> I/O is not simply memory-mapped, this concern does not exist for
> platform-specific devices like this.  There's really no reason in my
> humble opinion this code could not simply do
> 
>   /* read predivider and multiplier, shifted left 18 bits to
>* accomodate the fractional multiplier */
>   spin_lock_irqsave(>lock, flags);
>   divider = (pll->n + 1) << 18;
>   rate = (pll->m << 18) + pll->frac_m;
>   spin_unlock_irqrestore(>lock, flags);
> 
>   do_div(rate, divider);
> 
> instead of spending a whole paragraph of code on reading each individual
> field, which I think just hurts readability.
> 
>
> Note btw that PLLSS is

Re: [PATCH] drivers: net: cpsw: fix RMII/RGMII mode when used with fixed-link PHY

2015-12-14 Thread David Rivshin (Allworx) 
On Sat, 12 Dec 2015 16:44:19 +0100
Markus Brunner  wrote:

> On Wednesday 09 December 2015 22:31:15 David Rivshin wrote:
> ...
> > This patch was originally developed in parallel with 1f71e8c96fc6 to
> > accomplish the same goal. When I replaced this patch with
> > 1f71e8c96fc6, I found that it did not work on my hardware (which
> > uses RGMII), so I am submitting this patch now as a bugfix. 
> 
> Your patch works fine on my board, which uses MII and dual_emac with
> a fixed_phy and a real one. 

Thanks for checking. The only dual_emac board I have available is the 
EVMSK, which has two real PHYs. I'm not sure of the usual etiquette 
(and Google was  unhelpful), should I add a Tested-by on the next 
version?

> > Besides fixing the bug mentioned in the commit log, there are a few
> > other differences to note:
> >  * If both "phy_id" and a "fixed-link" subnode are present this
> > patch will use the "phy_id" property. This should preserve current
> > behavior with existing devicetrees that might incorrectly have
> > both. This motivates the biggest difference in code organization
> > from 1f71e8c96fc6.
> >  * Some error messages have been tweaked to reflect the slightly
> > changed meanings of the checks.
> 
> I wanted to keep changes small and didn't spend too much thinking
> about already broken devicetrees. Since my patch is quite new, I

I'm honestly not sure it's an important consideration myself. Most
patches I've seen in this area for this or other drivers do not take 
such behavior into account (e.g. the phy-handle parsing that went in 
to cpsw in 4.3).
I would generally feel more comfortable with such a behavior tweak
(minor as it is) before 4.4 is released, to avoid ping-ponging the
behavior. But given how far along the cycle is, I'm not sure about 
the chances of that.

> don't see any problems with subtle changes like that. However you
> should update the documentation as well. 

Your patch already updated .../bindings/net/cpsw.txt, which this
patch left alone. Are you referring to some other documentation, 
or do you think I should update the binding documentation to state
that phy_id takes precedence over fixed-link? I figured that such
devicetrees were still officially malformed, so I thought the 
existing text was appropriate.

> >  * of_node_get() is called on slave_node before passing the result
> > to of_phy_find_device(). This increments the reference count, which
> > I believe is correct for this situation, but I'm not certain of
> > that.
> I think you are right. At least most other drivers calling
> of_phy_register_fixed_link(), call of_node_get afterwards. I can't
> remember where I got my "inspiration" for the patch. I made it almost
> a year ago and now 3 other guys tinker with the same feature? What a
> coincidence ;-)

Perhaps not a complete coincidence. I first wrote this patch a few 
months ago against 4.1. While I had always intended on submitting when 
time allowed, testing your patch gave me an extra push.

[...]

> > --- a/drivers/net/ethernet/ti/cpsw.c
> > +++ b/drivers/net/ethernet/ti/cpsw.c
> > @@ -26,6 +26,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> 
> The prototypes for of_*_fixed_link are in linux/of_mdio.h, which is
> already included.

You are correct; I forget why I had originally included that. I will 
remove it for v2.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mtd: omap_elm: print interrupt resource using %pr

2015-12-14 Thread Brian Norris 
On Sat, Dec 12, 2015 at 03:41:31PM +0100, Arnd Bergmann wrote:
> On Friday 11 December 2015 17:10:56 Brian Norris wrote:
> > drivers/mtd/nand/omap_elm.c:417 elm_probe() error: '%pr' expects argument 
> > of type struct resource *, but argument 3 has type 'struct resource**' 
> > [smatch]
> 
> Ah, good catch. Do you want to fix it up yourself, or should I send a new 
> version?

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

Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*

2015-12-14 Thread Geert Uytterhoeven 
Hi Paul,

On Sun, Dec 13, 2015 at 2:41 AM, Paul Gortmaker
 wrote:
> This series of commits is a slice of a larger project to ensure
> people don't have dead code for module removal in non-modular
> drivers.  Overall there was roughly 5k lines of dead code in the
> kernel due to this.  So far we've fixed several areas, like tty,
> x86, net, etc. and we continue to work on other areas.
>
> There are several reasons to not use module_init for code that can
> never be built as a module, but the big ones are:
>
>  (1) it is easy to accidentally code up unused module_exit and remove code
>  (2) it can be misleading when reading the source, thinking it can be
>   modular when the Makefile and/or Kconfig prohibit it
>  (3) it requires the include of the module.h header file which in turn
>  includes nearly everything else.
>
> Here we convert some module_init() calls into device_initcall() and delete
> any module_exit and remove code that gets orphaned in the process, for
> an overall net code reduction, which is always welcome.
>
> The use of device_initcall ensures that the init function ordering
> remains unchanged, but one could argue that PCI host code might be more
> appropriate to be handled under subsys_initcall.  Fortunately we can
> revisit making this extra change at a later date if desired; it does
> not need to happen now, and we reduce the risk of introducing
> regressions at this point in time by separating the two changes.
>
> Over half of the drivers changed here already explicitly disallowed any
> unbind operations.  For the rest we make them the same, since there is
> not really any sensible use case to unbind any built-in bus support that
> I can think of.

Personally, I think all of these should become tristate, so distro kernels
don't have to build in PCI(e) support for all SoCs. multi_v7_defconfig kernels
are becoming too big.

That does not preclude making these modules un-unloadable, though.

> Paul Gortmaker (10):
>   drivers/pci: make host/pci-imx6.c driver explicitly non-modular
>   drivers/pci: make host/pcie-spear13xx.c driver explicitly non-modular
>   drivers/pci: make host/pci-mvebu.c explicitly non-modular
>   drivers/pci: make host/pci-dra7xx.c explicitly non-modular
>   drivers/pci: make host/pci-rcar-gen2.c explicitly non-modular
>   drivers/pci: make host/pci-tegra.c explicitly non-modular
>   drivers/pci: make host/pcie-rcar.c explicitly non-modular
>   drivers/pci: make host/pcie-xilinx.c explicitly non-modular
>   drivers/pci: make host/pci-keystone.c explicitly non-modular
>   drivers/pci: make host/pcie-altera.c explicitly non-modular

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*

2015-12-14 Thread Thierry Reding 
On Mon, Dec 14, 2015 at 09:19:30AM +0100, Geert Uytterhoeven wrote:
> Hi Paul,
> 
> On Sun, Dec 13, 2015 at 2:41 AM, Paul Gortmaker
>  wrote:
> > This series of commits is a slice of a larger project to ensure
> > people don't have dead code for module removal in non-modular
> > drivers.  Overall there was roughly 5k lines of dead code in the
> > kernel due to this.  So far we've fixed several areas, like tty,
> > x86, net, etc. and we continue to work on other areas.
> >
> > There are several reasons to not use module_init for code that can
> > never be built as a module, but the big ones are:
> >
> >  (1) it is easy to accidentally code up unused module_exit and remove code
> >  (2) it can be misleading when reading the source, thinking it can be
> >   modular when the Makefile and/or Kconfig prohibit it
> >  (3) it requires the include of the module.h header file which in turn
> >  includes nearly everything else.
> >
> > Here we convert some module_init() calls into device_initcall() and delete
> > any module_exit and remove code that gets orphaned in the process, for
> > an overall net code reduction, which is always welcome.
> >
> > The use of device_initcall ensures that the init function ordering
> > remains unchanged, but one could argue that PCI host code might be more
> > appropriate to be handled under subsys_initcall.  Fortunately we can
> > revisit making this extra change at a later date if desired; it does
> > not need to happen now, and we reduce the risk of introducing
> > regressions at this point in time by separating the two changes.
> >
> > Over half of the drivers changed here already explicitly disallowed any
> > unbind operations.  For the rest we make them the same, since there is
> > not really any sensible use case to unbind any built-in bus support that
> > I can think of.
> 
> Personally, I think all of these should become tristate, so distro kernels
> don't have to build in PCI(e) support for all SoCs. multi_v7_defconfig kernels
> are becoming too big.
> 
> That does not preclude making these modules un-unloadable, though.

Most of these can't be made tristate as-is, because they use symbols
that aren't exported. Many of those symbols can easily be exported, so
its just a matter of getting the respective patches merged. I disagree
with making the modules non-unloadable, though. I have a local branch
with changes necessary to unload the host controller driver and it
works just fine.

Thierry


signature.asc
Description: PGP signature

[PATCH V03 3/5] dmaengine: core: Introduce new, universal API to request a channel

2015-12-14 Thread Peter Ujfalusi 
The two API function can cover most, if not all current APIs used to
request a channel. With minimal effort dmaengine drivers, platforms and
dmaengine user drivers can be converted to use the two function.

struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

To request any channel matching with the requested capabilities, can be
used to request channel for memcpy, memset, xor, etc where no hardware
synchronization is needed.

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
To request a slave channel. The dma_request_chan() will try to find the
channel via DT, ACPI or in case if the kernel booted in non DT/ACPI mode
it will use a filter lookup table and retrieves the needed information from
the dma_slave_map provided by the DMA drivers.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static const struct dma_slave_map da830_edma_map[] = {
{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
};

This information is going to be needed by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.slave_map = da830_edma_map;
da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to configure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

ecc->dma_slave.filter_map.map = info->slave_map;
ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
ecc->dma_slave.filter_map.fn = edma_filter_fn;

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_slave_map to get the channel with the dma_get_channel() internal
function.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Arnd Bergmann 
---
 Documentation/dmaengine/client.txt | 23 +++---
 drivers/dma/dmaengine.c| 89 +-
 include/linux/dmaengine.h  | 51 +++---
 3 files changed, 127 insertions(+), 36 deletions(-)

diff --git a/Documentation/dmaengine/client.txt 
b/Documentation/dmaengine/client.txt
index d9f9f461102a..9e33189745f0 100644
--- a/Documentation/dmaengine/client.txt
+++ b/Documentation/dmaengine/client.txt
@@ -22,25 +22,14 @@ The slave DMA usage consists of following steps:
Channel allocation is slightly different in the slave DMA context,
client drivers typically need a channel from a particular DMA
controller only and even in some cases a specific channel is desired.
-   To request a channel dma_request_channel() API is used.
+   To request a channel dma_request_chan() API is used.
 
Interface:
-   struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
-   dma_filter_fn filter_fn,
-   void *filter_param);
-   where dma_filter_fn is defined as:
-   typedef bool (*dma_filter_fn)(struct dma_chan *chan, void 
*filter_param);
-
-   The 'filter_fn' parameter is optional, but highly recommended for
-   slave and cyclic channels as they typically need to obtain a specific
-   DMA channel.
-
-   When the optional 'filter_fn' parameter is NULL, dma_request_channel()
-   simply returns the first channel that satisfies the capability mask.
-
-   Otherwise, the 'filter_fn' routine will be called once for each free
-   channel which has a capability in 'mask'.  'filter_fn' is expected to
-   return 'true' when the desired DMA channel is found.
+   struct dma_chan *dma_request_chan(struct device *dev, const char *name);
+
+   Which will find and return the 'name' DMA channel associated with the 'dev'
+   device. The association is done via DT, ACPI or board file based
+   dma_slave_map matching table.
 
A channel allocated via this interface is exclusive to the caller,
until dma_release_channel() is called.
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ea9d66982d40..c50a247be2e0 100644
--- a/drivers/dma/dmaengine.c
+++

[PATCH V03 4/5] dmaengine: edma: Add support for DMA filter mapping to slave devices

2015-12-14 Thread Peter Ujfalusi 
Add support for providing device to filter_fn mapping so client drivers
can switch to use the dma_request_chan() API.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Arnd Bergmann 
---
 drivers/dma/edma.c | 4 
 include/linux/platform_data/edma.h | 7 +++
 2 files changed, 11 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 16fe773fb846..2e8acde6b134 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2314,6 +2314,10 @@ static int edma_probe(struct platform_device *pdev)
edma_set_chmap(>slave_chans[i], ecc->dummy_slot);
}
 
+   ecc->dma_slave.filter.map = info->slave_map;
+   ecc->dma_slave.filter.mapcnt = info->slavecnt;
+   ecc->dma_slave.filter.fn = edma_filter_fn;
+
ret = dma_async_device_register(>dma_slave);
if (ret) {
dev_err(dev, "slave ddev registration failed (%d)\n", ret);
diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index 4299f4ba03bd..0a533f94438f 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -53,12 +53,16 @@ enum dma_event_q {
 #define EDMA_CTLR(i)   ((i) >> 16)
 #define EDMA_CHAN_SLOT(i)  ((i) & 0x)
 
+#define EDMA_FILTER_PARAM(ctlr, chan)  ((int[]) { EDMA_CTLR_CHAN(ctlr, chan) })
+
 struct edma_rsv_info {
 
const s16   (*rsv_chans)[2];
const s16   (*rsv_slots)[2];
 };
 
+struct dma_slave_map;
+
 /* platform_data for EDMA driver */
 struct edma_soc_info {
/*
@@ -76,6 +80,9 @@ struct edma_soc_info {
 
s8  (*queue_priority_mapping)[2];
const s16   (*xbar_chans)[2];
+
+   const struct dma_slave_map *slave_map;
+   int slavecnt;
 };
 
 #endif
-- 
2.6.4

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

Re: [PATCH V02 3/5] dmaengine: core: Introduce new, universal API to request a channel

2015-12-14 Thread Peter Ujfalusi 
On 12/14/2015 01:22 PM, Peter Ujfalusi wrote:

>  /**
> + * struct dma_slave_map - associates slave device and it's slave channel with
> + * parameter to be used by a filter function
> + * @devname: name of the device
> + * @slave: slave channel name
> + * @param: opaque parameter to pass to struct dma_filter.fn
> + */
> +struct dma_slave_map {
> +const char *devname;
> +const char *slave;
> +void *param;

??? Tabs got replaced by spaces ???

> +};
> +
> +/**
> + * struct dma_filter - information for slave device/channel to 
> filter_fn/param
> + * mapping
> + * @fn: filter function callback
> + * @mapcnt: number of slave device/channel in the map
> + * @map: array of channel to filter mapping data
> + */
> +struct dma_filter {
> +dma_filter_fn fn;
> +int mapcnt;
> +const struct dma_slave_map *map;

Here also.

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

[PATCH V03 0/5] dmaengine: New 'universal' API for requesting channel

2015-12-14 Thread Peter Ujfalusi 
Hi,

Changes since v2:
- in patch 3 some tabs got replaced by spaces, now they are fixed
- added Reviewed-by from Arnd

Changes since v1:
- Added Reviewed-by from Andy for patch 1-2, I decided to not add the 
reviewed-by
  to patch 3 due to the changes since v1
- patch for omap-dma to support passing the filter setup to the core
- dma_request_slave_channel_reason() remeved and it is now defines as
  dma_request_chan()
- Print of warning removed when DT or ACPI lookup fails and we are going to
  Fallback to legacy lookup
- members of struct dma_filter has been revised for simplicity.

Changes since RFC v03:
- No longer RFC
- Dropped the arch/arm/mcah-davinci and daVinci MMC and SPI patches so we don't
  have inter subsystem issues.
- Comments from Andy to patch no 3 has been addressed with the exception of
  moving code over to device_property
- 'struct dma_filter_map' renamed as 'struct dma_slave_map'
- Code documentation added

Changes since RFC v02:
- Using has_acpi_companion() instead ACPI_HANDLE()
- mask matching change within private_candidate()
- Fallback in dma_request_chan() when DT/ACPI lookup fails.
- Rename dma_get_channel() -> find_candidate()
- Arch code changes as suggested by Arnd
- Some documentation updated, more need to be done.

Changes since RFC v01:
- dma_request_chan(); lost the mask parameter
- The new API does not rely on RESOURCE_DMA, instead the dma_slave_map table
  will be used to provide the needed information to the filter function in
  legacy mode
- Extended the example patches to convert most of daVinci to use the new API to
  request the DMA channels.

As it has been discussed in the following thread:
http://www.gossamer-threads.com/lists/linux/kernel/2181487#2181487

With this series I have taken a path which would result two new API, which can
be used to convert most of the current users already and with some work all
users might be able to move to this set.
With this set the filter_fn used for legacy (non DT/ACPI) channel request is no
longer needed to be exported to client drivers since the selection of the
correct filter_fn will be done in the core.

So, the first proposal is to have:

struct dma_chan *dma_request_chan(struct device *dev, const char *name);
struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);

The dma_request_chan_by_mask() is to request any channel matching with the
requested capabilities, can be used to request channel for memcpy, memset, xor,
etc where no hardware synchronization is needed.

The dma_request_chan() is to request a slave channel. The dma_request_chan()
will try to find the channel via DT, ACPI or in case if the kernel booted in non
DT/ACPI mode it will use a filter lookup table and retrieves the needed
information from the dma_slave_map provided by the DMA drivers.
This legacy mode needs changes in platform code, in dmaengine drivers and
finally the dmaengine user drivers can be converted:

For each dmaengine driver an array of DMA device, slave and the parameter
for the filter function needs to be added:

static const struct dma_slave_map da830_edma_map[] = {
{ "davinci-mcasp.0", "rx", EDMA_FILTER_PARAM(0, 0) },
{ "davinci-mcasp.0", "tx", EDMA_FILTER_PARAM(0, 1) },
{ "davinci-mcasp.1", "rx", EDMA_FILTER_PARAM(0, 2) },
{ "davinci-mcasp.1", "tx", EDMA_FILTER_PARAM(0, 3) },
{ "davinci-mcasp.2", "rx", EDMA_FILTER_PARAM(0, 4) },
{ "davinci-mcasp.2", "tx", EDMA_FILTER_PARAM(0, 5) },
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 14) },
{ "spi_davinci.0", "tx", EDMA_FILTER_PARAM(0, 15) },
{ "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 16) },
{ "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.1", "rx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.1", "tx", EDMA_FILTER_PARAM(0, 19) },
};

This information is going to be used by the dmaengine driver, so
modification to the platform_data is needed, and the driver map should be
added to the pdata of the DMA driver:

da8xx_edma0_pdata.slave_map = da830_edma_map;
da8xx_edma0_pdata.slavecnt = ARRAY_SIZE(da830_edma_map);

The DMA driver then needs to configure the needed device -> filter_fn
mapping before it registers with dma_async_device_register() :

ecc->dma_slave.filter_map.map = info->slave_map;
ecc->dma_slave.filter_map.mapcnt = info->slavecnt;
ecc->dma_slave.filter_map.fn = edma_filter_fn;

When neither DT or ACPI lookup is available the dma_request_chan() will
try to match the requester's device name with the filter_map's list of
device names, when a match found it will use the information from the
dma_slave_map to get the channel with the dma_get_channel() internal
function.

Tested on OMAP-L138 (dm850) EVM, with updtaed patches from RFC v03 [1].
Both legacy and DT boot works fine.

[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122016.html

Regards,
Peter
---
Peter Ujfalusi (5):
  dmaengine: core: Skip mask matching when it is not provided to

[PATCH V03 1/5] dmaengine: core: Skip mask matching when it is not provided to private_candidate

2015-12-14 Thread Peter Ujfalusi 
If mask is NULL skip the mask matching against the DMA device capabilities.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Arnd Bergmann 
---
 drivers/dma/dmaengine.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index daf54a39bcc7..6311e1fc80be 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -515,7 +515,7 @@ static struct dma_chan *private_candidate(const 
dma_cap_mask_t *mask,
 {
struct dma_chan *chan;
 
-   if (!__dma_device_satisfies_mask(dev, mask)) {
+   if (mask && !__dma_device_satisfies_mask(dev, mask)) {
pr_debug("%s: wrong capabilities\n", __func__);
return NULL;
}
-- 
2.6.4

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

[PATCH V03 5/5] dmaengine: omap-dma: Add support for DMA filter mapping to slave devices

2015-12-14 Thread Peter Ujfalusi 
Add support for providing device to filter_fn mapping so client drivers
can switch to use the dma_request_chan() API.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Arnd Bergmann 
---
 drivers/dma/omap-dma.c   | 4 
 include/linux/omap-dma.h | 6 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index f86827ac0c8a..9794b073d7d7 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1153,6 +1153,10 @@ static int omap_dma_probe(struct platform_device *pdev)
return rc;
}
 
+   od->ddev.filter.map = od->plat->slave_map;
+   od->ddev.filter.mapcnt = od->plat->slavecnt;
+   od->ddev.filter.fn = omap_dma_filter_fn;
+
rc = dma_async_device_register(>ddev);
if (rc) {
pr_warn("OMAP-DMA: failed to register slave DMA engine device: 
%d\n",
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 88fa8af2b937..1d99b61adc65 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -267,6 +267,9 @@ struct omap_dma_reg {
u8  type;
 };
 
+#define SDMA_FILTER_PARAM(hw_req)  ((int[]) { (hw_req) })
+struct dma_slave_map;
+
 /* System DMA platform data structure */
 struct omap_system_dma_plat_info {
const struct omap_dma_reg *reg_map;
@@ -278,6 +281,9 @@ struct omap_system_dma_plat_info {
void (*clear_dma)(int lch);
void (*dma_write)(u32 val, int reg, int lch);
u32 (*dma_read)(int reg, int lch);
+
+   const struct dma_slave_map *slave_map;
+   int slavecnt;
 };
 
 #ifdef CONFIG_ARCH_OMAP2PLUS
-- 
2.6.4

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

[PATCH V03 2/5] dmaengine: core: Move and merge the code paths using private_candidate

2015-12-14 Thread Peter Ujfalusi 
Channel matching with private_candidate() is used in two paths, the error
checking is slightly different in them and they are duplicating code also.
Move the code under find_candidate() to provide consistent execution and
going to allow us to reuse this mode of channel lookup later.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Arnd Bergmann 
---
 drivers/dma/dmaengine.c | 81 +
 1 file changed, 42 insertions(+), 39 deletions(-)

diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 6311e1fc80be..ea9d66982d40 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -546,6 +546,42 @@ static struct dma_chan *private_candidate(const 
dma_cap_mask_t *mask,
return NULL;
 }
 
+static struct dma_chan *find_candidate(struct dma_device *device,
+  const dma_cap_mask_t *mask,
+  dma_filter_fn fn, void *fn_param)
+{
+   struct dma_chan *chan = private_candidate(mask, device, fn, fn_param);
+   int err;
+
+   if (chan) {
+   /* Found a suitable channel, try to grab, prep, and return it.
+* We first set DMA_PRIVATE to disable balance_ref_count as this
+* channel will not be published in the general-purpose
+* allocator
+*/
+   dma_cap_set(DMA_PRIVATE, device->cap_mask);
+   device->privatecnt++;
+   err = dma_chan_get(chan);
+
+   if (err) {
+   if (err == -ENODEV) {
+   pr_debug("%s: %s module removed\n", __func__,
+dma_chan_name(chan));
+   list_del_rcu(>global_node);
+   } else
+   pr_debug("%s: failed to get %s: (%d)\n",
+__func__, dma_chan_name(chan), err);
+
+   if (--device->privatecnt == 0)
+   dma_cap_clear(DMA_PRIVATE, device->cap_mask);
+
+   chan = ERR_PTR(err);
+   }
+   }
+
+   return chan ? chan : ERR_PTR(-EPROBE_DEFER);
+}
+
 /**
  * dma_get_slave_channel - try to get specific channel exclusively
  * @chan: target channel
@@ -584,7 +620,6 @@ struct dma_chan *dma_get_any_slave_channel(struct 
dma_device *device)
 {
dma_cap_mask_t mask;
struct dma_chan *chan;
-   int err;
 
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
@@ -592,23 +627,11 @@ struct dma_chan *dma_get_any_slave_channel(struct 
dma_device *device)
/* lock against __dma_request_channel */
mutex_lock(_list_mutex);
 
-   chan = private_candidate(, device, NULL, NULL);
-   if (chan) {
-   dma_cap_set(DMA_PRIVATE, device->cap_mask);
-   device->privatecnt++;
-   err = dma_chan_get(chan);
-   if (err) {
-   pr_debug("%s: failed to get %s: (%d)\n",
-   __func__, dma_chan_name(chan), err);
-   chan = NULL;
-   if (--device->privatecnt == 0)
-   dma_cap_clear(DMA_PRIVATE, device->cap_mask);
-   }
-   }
+   chan = find_candidate(device, , NULL, NULL);
 
mutex_unlock(_list_mutex);
 
-   return chan;
+   return IS_ERR(chan) ? NULL : chan;
 }
 EXPORT_SYMBOL_GPL(dma_get_any_slave_channel);
 
@@ -625,35 +648,15 @@ struct dma_chan *__dma_request_channel(const 
dma_cap_mask_t *mask,
 {
struct dma_device *device, *_d;
struct dma_chan *chan = NULL;
-   int err;
 
/* Find a channel */
mutex_lock(_list_mutex);
list_for_each_entry_safe(device, _d, _device_list, global_node) {
-   chan = private_candidate(mask, device, fn, fn_param);
-   if (chan) {
-   /* Found a suitable channel, try to grab, prep, and
-* return it.  We first set DMA_PRIVATE to disable
-* balance_ref_count as this channel will not be
-* published in the general-purpose allocator
-*/
-   dma_cap_set(DMA_PRIVATE, device->cap_mask);
-   device->privatecnt++;
-   err = dma_chan_get(chan);
+   chan = find_candidate(device, mask, fn, fn_param);
+   if (!IS_ERR(chan))
+   break;
 
-   if (err == -ENODEV) {
-   pr_debug("%s: %s module removed\n",
-__func__, dma_chan_name(chan));
-   list_del_rcu(>global_node);
-   } else if (err)
-

Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*

2015-12-14 Thread Ley Foon Tan 
On Mon, Dec 14, 2015 at 4:24 PM, Thierry Reding
 wrote:
> On Mon, Dec 14, 2015 at 09:19:30AM +0100, Geert Uytterhoeven wrote:
>> Hi Paul,
>>
>> On Sun, Dec 13, 2015 at 2:41 AM, Paul Gortmaker
>>  wrote:
>> > This series of commits is a slice of a larger project to ensure
>> > people don't have dead code for module removal in non-modular
>> > drivers.  Overall there was roughly 5k lines of dead code in the
>> > kernel due to this.  So far we've fixed several areas, like tty,
>> > x86, net, etc. and we continue to work on other areas.
>> >
>> > There are several reasons to not use module_init for code that can
>> > never be built as a module, but the big ones are:
>> >
>> >  (1) it is easy to accidentally code up unused module_exit and remove code
>> >  (2) it can be misleading when reading the source, thinking it can be
>> >   modular when the Makefile and/or Kconfig prohibit it
>> >  (3) it requires the include of the module.h header file which in turn
>> >  includes nearly everything else.
>> >
>> > Here we convert some module_init() calls into device_initcall() and delete
>> > any module_exit and remove code that gets orphaned in the process, for
>> > an overall net code reduction, which is always welcome.
>> >
>> > The use of device_initcall ensures that the init function ordering
>> > remains unchanged, but one could argue that PCI host code might be more
>> > appropriate to be handled under subsys_initcall.  Fortunately we can
>> > revisit making this extra change at a later date if desired; it does
>> > not need to happen now, and we reduce the risk of introducing
>> > regressions at this point in time by separating the two changes.
>> >
>> > Over half of the drivers changed here already explicitly disallowed any
>> > unbind operations.  For the rest we make them the same, since there is
>> > not really any sensible use case to unbind any built-in bus support that
>> > I can think of.
>>
>> Personally, I think all of these should become tristate, so distro kernels
>> don't have to build in PCI(e) support for all SoCs. multi_v7_defconfig 
>> kernels
>> are becoming too big.
>>
>> That does not preclude making these modules un-unloadable, though.
>
> Most of these can't be made tristate as-is, because they use symbols
> that aren't exported. Many of those symbols can easily be exported, so
> its just a matter of getting the respective patches merged. I disagree
> with making the modules non-unloadable, though. I have a local branch
> with changes necessary to unload the host controller driver and it
> works just fine.
>
PCIe host driver that use fixup (DECLARE_PCI_FIXUP_*) can't use tristate.
Fixup region is in kernel region and this region if not updated when
loading a module.

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

Re: [PATCH 00/10] drivers/pci: avoid module_init in non-modular host/pci*

2015-12-14 Thread Michal Simek 
On 14.12.2015 09:24, Thierry Reding wrote:
> On Mon, Dec 14, 2015 at 09:19:30AM +0100, Geert Uytterhoeven wrote:
>> Hi Paul,
>>
>> On Sun, Dec 13, 2015 at 2:41 AM, Paul Gortmaker
>>  wrote:
>>> This series of commits is a slice of a larger project to ensure
>>> people don't have dead code for module removal in non-modular
>>> drivers.  Overall there was roughly 5k lines of dead code in the
>>> kernel due to this.  So far we've fixed several areas, like tty,
>>> x86, net, etc. and we continue to work on other areas.
>>>
>>> There are several reasons to not use module_init for code that can
>>> never be built as a module, but the big ones are:
>>>
>>>  (1) it is easy to accidentally code up unused module_exit and remove code
>>>  (2) it can be misleading when reading the source, thinking it can be
>>>   modular when the Makefile and/or Kconfig prohibit it
>>>  (3) it requires the include of the module.h header file which in turn
>>>  includes nearly everything else.
>>>
>>> Here we convert some module_init() calls into device_initcall() and delete
>>> any module_exit and remove code that gets orphaned in the process, for
>>> an overall net code reduction, which is always welcome.
>>>
>>> The use of device_initcall ensures that the init function ordering
>>> remains unchanged, but one could argue that PCI host code might be more
>>> appropriate to be handled under subsys_initcall.  Fortunately we can
>>> revisit making this extra change at a later date if desired; it does
>>> not need to happen now, and we reduce the risk of introducing
>>> regressions at this point in time by separating the two changes.
>>>
>>> Over half of the drivers changed here already explicitly disallowed any
>>> unbind operations.  For the rest we make them the same, since there is
>>> not really any sensible use case to unbind any built-in bus support that
>>> I can think of.
>>
>> Personally, I think all of these should become tristate, so distro kernels
>> don't have to build in PCI(e) support for all SoCs. multi_v7_defconfig 
>> kernels
>> are becoming too big.
>>
>> That does not preclude making these modules un-unloadable, though.
> 
> Most of these can't be made tristate as-is, because they use symbols
> that aren't exported. Many of those symbols can easily be exported, so
> its just a matter of getting the respective patches merged. I disagree
> with making the modules non-unloadable, though. I have a local branch
> with changes necessary to unload the host controller driver and it
> works just fine.

Great.

Send them out.

Thanks,
Michal

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