[PATCH] spi: ti-qspi: improve ->remove() callback

2015-10-29 Thread Felipe Balbi 
there's no need to call pm_runtime_get_sync()
followed by pm_runtime_put(). We should, instead,
just call pm_runtime_put_sync() and pm_runtime_disable().

Signed-off-by: Felipe Balbi 
---
 drivers/spi/spi-ti-qspi.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 69c1a95b0615..64318fcfacf2 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -554,16 +554,7 @@ free_master:
 
 static int ti_qspi_remove(struct platform_device *pdev)
 {
-   struct ti_qspi *qspi = platform_get_drvdata(pdev);
-   int ret;
-
-   ret = pm_runtime_get_sync(qspi->dev);
-   if (ret < 0) {
-   dev_err(qspi->dev, "pm_runtime_get_sync() failed\n");
-   return ret;
-   }
-
-   pm_runtime_put(qspi->dev);
+   pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
 
return 0;
-- 
2.6.2

--
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

VoIP Users List

2015-10-29 Thread Craig Carter 


Hi,
 
Would you be interested in acquiring an Email list of "VoIP Users" from USA?


We have data for Avaya IP Telephony (VoIP) Users, Avaya IVR Users , Avaya Unified 
Communications Users , Cisco IP Telephony (VoIP) Users, Cisco Voice and Data 
Networks Users, Cisco VPN Users, Nortel VoIP Users, AT Voice and Data Users, 
Aspect Spectrum ACD Users, Avaya Call Center Users, Avaya IP Agent Users, Avaya IP 
Office Users , Avaya Voice Platform Users , Microsoft Publisher Users , Cisco 
Telephony Hardware Users, Nortel Symposium Call Center Server Users, Vocera 
Communications Users and many more..

Each Record in the List includes: Company, Name, First Name, Last Name, Title, 
HQ Phone, Direct No, Email, Address1, Address2, City, State, Zip, Country, 
Industry, Revenue, Employees, IT Budget, IT Employees, Website, Technology, 
Company HQ Address1, Company HQ Address2, Company HQ City, Company HQ State, 
Company HQ Zip, Company HQ Country and LinkedIn link.

All the contacts are opt-in verified, 100% permission based and can be used for 
unlimited multi-channel marketing.
 
Please let me know your thoughts towards procuring the "VoIP Users List" .


Please brief us on the type of emails you wish to target.

Look forward to your prompt response.

Thanks & Regards
Craig Carter
Research Analyst

If this message is not relevant to you please forward to decision maker.We 
respect your privacy, if you do not wish to receive any further emails from our 
end, please reply with a subject “Leave Out”.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
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: [Gta04-owner] [PATCH 10/13] twl4030_charger: add software controlled linear charging mode.

2015-10-29 Thread Andreas Kemnade 
On Tue, 6 Oct 2015 16:34:07 +0200
Pavel Machek  wrote:

> Hi!
> 
> > Pavel Machek  writes:
> > > On Thu 2015-07-30 10:11:24, NeilBrown wrote:
> > >> 
> > >> Add a 'continuous' option for usb charging which enables
> > >> the "linear" charging mode of the twl4030.
> > >> 
> > >> Linear charging does a good job with not-so-reliable power sources.
> > >> Auto mode does not work well as it switches off when voltage drops
> > >> momentarily.  Care must be taken not to over-charge.
> > >
> > > Can you explain how the user can "care not to over-charge"?
> > 
> > The following text reads:
> > 
> > It was used with a bike hub dynamo since a year or so. In that case
> > there are automatically charging stops when the cyclist needs a break.
> > 
> > so: take a break from cycling occasionally.
> 
> If the charger does not exceed 4.2V, I'd not call it overcharge. (Yes, some 
> clever
> chargers actually let the battery drop below 4.2V when charge is done, but...)
> 
Yes, that is the case. Perhaps it is not to be called overcharge but
it is said that lithium battery charging has to stop if in CV mode the
current drops too low.  In automatic mode the charger does exactly
that.
I would not let a battery for days at 4.2V CV.mode although a lot
of cheap chargers 

> If the charger _does_ exceed 4.2V, then the battery will explode. Don't do 
> that. Don't
> offer that to the user.
> 
> On a related note... I've just killed USB charger by overloading it. They are 
> not protected.
> 
> I believe your automatically-pull-max-power really should stick to the 
> well-known charging
> currents (.5A, 1A, 1.7A), at the very minimum.
> 
The main reason for the patch was to prevent switching off charging
when Vbus drops low. The reason was not to get out extremely much
current out of the charger.
The electrical characteristics of a  bicycle as a power source are.
- the amount of current available changes
   - 500mA at around 17km/h
- you cannot destroy it by electrically overloading

If the current is set to e.g. 500mA and that linear charging mode is
enabled, the battery gets the maximum current available (upto
500mA) regardless of the speed which is often changing.

Regards,
Andreas Kemnade


signature.asc
Description: PGP signature

[GIT PULL] two omap regression fixes for v4.3-rc cycle

2015-10-29 Thread Tony Lindgren 
The following changes since commit 57df5380853460bc66b59a46273ce113c923d39c:

  ARM: OMAP2+: Fix imprecise external abort caused by bogus SRAM init 
(2015-10-19 08:55:46 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.3/fixes-rc7

for you to fetch changes up to 8f2279d5d908119a08e906be1c6b69c744d0c379:

  usb: musb: omap2430: Fix regression caused by driver core change (2015-10-28 
10:16:04 -0700)


Two omap regression fixes:

- Fix omap3 MUSB with DMA caused by driver core changes

- Fix LCD DMA interrupt number for omap1 that did not
  get changed for sparse IRQ changes


Aaro Koskinen (1):
  ARM: OMAP1: fix incorrect INT_DMA_LCD

Tony Lindgren (1):
  usb: musb: omap2430: Fix regression caused by driver core change

 drivers/usb/musb/omap2430.c | 29 +++--
 include/linux/omap-dma.h|  2 +-
 2 files changed, 24 insertions(+), 7 deletions(-)
--
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 0/3] dmaengine: ti-dma-crossbar: channel reserving and edma3-tcc support

2015-10-29 Thread Peter Ujfalusi 
Hi,

This series depends on the eDMA work I have done, which has been now applied:
https://lkml.org/lkml/2015/10/16/64

DRA7 family of chips have both sDMA and eDMA. Currently only sDMA can be used
becasue the old driver stack for eDMA did not allowed integration w/o hacks.

Due to the nature of eDMA the crossbar needs to know which eDMA events it can
use to map incoming events towards the eDMA. In eDMA a channel is wired to be
used with one specific event. For example eDMA event 14 can only be handled by
eDMA channel 14.
The eDMA itself can be shared by different processors in the system (ARM, DSP,
etc) and since ARM/Linux is the master we need to know which channels are used
by other cores. Also we need to mask out channels used for memcpy from the
events we use for HW triggers.

Regards,
Peter
---
Peter Ujfalusi (3):
  dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr
  dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event
ranges
  dmaengine: ti-dma-crossbar: dra7: Support for eDMA with new bindings

 .../devicetree/bindings/dma/ti-dma-crossbar.txt|  6 ++
 drivers/dma/ti-dma-crossbar.c  | 81 +++---
 2 files changed, 76 insertions(+), 11 deletions(-)

-- 
2.6.1

--
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 3/3] dmaengine: ti-dma-crossbar: dra7: Support for eDMA with new bindings

2015-10-29 Thread Peter Ujfalusi 
Allow the crossbar driver to be used with the eDMA node with non legacy
binding.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti-dma-crossbar.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 1a41f75a4d1f..b7b21a243e37 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -289,6 +289,10 @@ static const struct of_device_id ti_dra7_master_match[] = {
.compatible = "ti,edma3",
.data = (void *)TI_XBAR_EDMA_OFFSET,
},
+   {
+   .compatible = "ti,edma3-tpcc",
+   .data = (void *)TI_XBAR_EDMA_OFFSET,
+   },
{},
 };
 
-- 
2.6.1

--
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/3] dmaengine: ti-dma-crossbar: dra7: Use bitops instead of idr

2015-10-29 Thread Peter Ujfalusi 
The use of idr was nice, but it was a bit heavy and we did not need the
features it provides. Using simple bitmap to track allocated DMA channels
is adequate here and it will be easier to add support for reserving
channels later on.

Signed-off-by: Peter Ujfalusi 
---
 drivers/dma/ti-dma-crossbar.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index a415edbe61b1..5fe1909d4ec4 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -198,7 +197,8 @@ struct ti_dra7_xbar_data {
void __iomem *iomem;
 
struct dma_router dmarouter;
-   struct idr map_idr;
+   struct mutex mutex;
+   unsigned long *dma_inuse;
 
u16 safe_val; /* Value to rest the crossbar lines */
u32 xbar_requests; /* number of DMA requests connected to XBAR */
@@ -225,7 +225,9 @@ static void ti_dra7_xbar_free(struct device *dev, void 
*route_data)
map->xbar_in, map->xbar_out);
 
ti_dra7_xbar_write(xbar->iomem, map->xbar_out, xbar->safe_val);
-   idr_remove(>map_idr, map->xbar_out);
+   mutex_lock(>mutex);
+   clear_bit(map->xbar_out, xbar->dma_inuse);
+   mutex_unlock(>mutex);
kfree(map);
 }
 
@@ -255,8 +257,17 @@ static void *ti_dra7_xbar_route_allocate(struct 
of_phandle_args *dma_spec,
return ERR_PTR(-ENOMEM);
}
 
-   map->xbar_out = idr_alloc(>map_idr, NULL, 0, xbar->dma_requests,
- GFP_KERNEL);
+   mutex_lock(>mutex);
+   map->xbar_out = find_next_zero_bit(xbar->dma_inuse, xbar->dma_requests,
+  0);
+   mutex_unlock(>mutex);
+   if (map->xbar_out) {
+   dev_err(>dev, "Run out of free DMA requests\n");
+   kfree(map);
+   return ERR_PTR(-ENOMEM);
+   }
+   set_bit(map->xbar_out, xbar->dma_inuse);
+
map->xbar_in = (u16)dma_spec->args[0];
 
dma_spec->args[0] = map->xbar_out + xbar->dma_offset;
@@ -299,8 +310,6 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
if (!xbar)
return -ENOMEM;
 
-   idr_init(>map_idr);
-
dma_node = of_parse_phandle(node, "dma-masters", 0);
if (!dma_node) {
dev_err(>dev, "Can't get DMA master node\n");
@@ -322,6 +331,12 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
}
of_node_put(dma_node);
 
+   xbar->dma_inuse = devm_kcalloc(>dev,
+  BITS_TO_LONGS(xbar->dma_requests),
+  sizeof(unsigned long), GFP_KERNEL);
+   if (!xbar->dma_inuse)
+   return -ENOMEM;
+
if (of_property_read_u32(node, "dma-requests", >xbar_requests)) {
dev_info(>dev,
 "Missing XBAR input information, using %u.\n",
@@ -343,6 +358,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
xbar->dmarouter.route_free = ti_dra7_xbar_free;
xbar->dma_offset = (u32)match->data;
 
+   mutex_init(>mutex);
platform_set_drvdata(pdev, xbar);
 
/* Reset the crossbar */
-- 
2.6.1

--
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 2/3] dmaengine: ti-dma-crossbar: dra7: Support for reserving DMA event ranges

2015-10-29 Thread Peter Ujfalusi 
In eDMA the events are directly mapped to a DMA channel (for example DMA
event 14 can only be handled by DMA channel 14). If the memcpy is enabled
on the eDMA, there is a possibility that the crossbar driver would assign
DMA event number already allocated in eDMA for memcpy. Furthermore the
eDMA can be shared with DSP in which case the crossbar driver should also
avoid mapping xbar events to DSP used event numbers (or channels).

Signed-off-by: Peter Ujfalusi 
---
 .../devicetree/bindings/dma/ti-dma-crossbar.txt|  6 +++
 drivers/dma/ti-dma-crossbar.c  | 47 --
 2 files changed, 49 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt 
b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
index b152a75dceae..aead5869a28d 100644
--- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
+++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
@@ -14,6 +14,10 @@ The DMA controller node need to have the following 
poroperties:
 
 Optional properties:
 - ti,dma-safe-map: Safe routing value for unused request lines
+- ti,reserved-dma-request-ranges: DMA request ranges which should not be used
+   when mapping xbar input to DMA request, they are either
+   allocated to be used by for example the DSP or they are used as
+   memcpy channels in eDMA.
 
 Notes:
 When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request
@@ -46,6 +50,8 @@ sdma_xbar: dma-router@4a002b78 {
#dma-cells = <1>;
dma-requests = <205>;
ti,dma-safe-map = <0>;
+   /* Protect the sDMA request ranges: 10-14 and 100-126 */
+   ti,reserved-dma-request-ranges = <10 5>, <100 27>;
dma-masters = <>;
 };
 
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 5fe1909d4ec4..1a41f75a4d1f 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -292,14 +292,22 @@ static const struct of_device_id ti_dra7_master_match[] = 
{
{},
 };
 
+static inline void ti_dra7_xbar_reserve(int offset, int len, unsigned long *p)
+{
+   for (; len > 0; len--)
+   clear_bit(offset + (len - 1), p);
+}
+
 static int ti_dra7_xbar_probe(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
struct device_node *dma_node;
struct ti_dra7_xbar_data *xbar;
+   struct property *prop;
struct resource *res;
u32 safe_val;
+   size_t sz;
void __iomem *iomem;
int i, ret;
 
@@ -347,6 +355,33 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
if (!of_property_read_u32(node, "ti,dma-safe-map", _val))
xbar->safe_val = (u16)safe_val;
 
+
+   prop = of_find_property(node, "ti,reserved-dma-request-ranges", );
+   if (prop) {
+   const char pname[] = "ti,reserved-dma-request-ranges";
+   u32 (*rsv_events)[2];
+   size_t nelm = sz / sizeof(*rsv_events);
+   int i;
+
+   if (!nelm)
+   return -EINVAL;
+
+   rsv_events = kcalloc(nelm, sizeof(*rsv_events), GFP_KERNEL);
+   if (!rsv_events)
+   return -ENOMEM;
+
+   ret = of_property_read_u32_array(node, pname, (u32 *)rsv_events,
+nelm * 2);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < nelm; i++) {
+   ti_dra7_xbar_reserve(rsv_events[i][0], rsv_events[i][1],
+xbar->dma_inuse);
+   }
+   kfree(rsv_events);
+   }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
iomem = devm_ioremap_resource(>dev, res);
if (IS_ERR(iomem))
@@ -362,15 +397,19 @@ static int ti_dra7_xbar_probe(struct platform_device 
*pdev)
platform_set_drvdata(pdev, xbar);
 
/* Reset the crossbar */
-   for (i = 0; i < xbar->dma_requests; i++)
-   ti_dra7_xbar_write(xbar->iomem, i, xbar->safe_val);
+   for (i = 0; i < xbar->dma_requests; i++) {
+   if (!test_bit(i, xbar->dma_inuse))
+   ti_dra7_xbar_write(xbar->iomem, i, xbar->safe_val);
+   }
 
ret = of_dma_router_register(node, ti_dra7_xbar_route_allocate,
 >dmarouter);
if (ret) {
/* Restore the defaults for the crossbar */
-   for (i = 0; i < xbar->dma_requests; i++)
-   ti_dra7_xbar_write(xbar->iomem, i, i);
+   for (i = 0; i < xbar->dma_requests; i++) {
+   if (!test_bit(i, xbar->dma_inuse))
+   ti_dra7_xbar_write(xbar->iomem, i, i);
+   }
}
 
return ret;
-- 
2.6.1