On 04/01/2014 01:09 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [140331 08:20]:
Hi,
This set is continuation for the work started earlier to cleanup the CM/PRM
and attempt to make it a separate driver. This set depends on these
two sets:
CM/PRM cleanup set:
The USB3 PHY driver (ti-pipe3) was updated so that the relevant
clock phandles are expected in the DT node.
Provide the necessary clocks.
Reported-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6
Hi Tony,
The following patch fixes USB3 on OMAP5 on linux-next.
There was a patch [1] that added named clocks to the USB3 phy driver
but somehow the dts part got missed out.
Due to that USB3 on OMAP5 is currently broken on linux-next and
this patch should fix it.
cheers,
-roger
[1] -
prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases
with the same texts printed in case we hit them. It helps when debugging if
we know exactly which callback generated the errors.
At the same time change the debug level for descriptor allocation failure
from dbg to err
It helps to identify issues if we have some information regarding to the
channel which the event is associated.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c
In case of not supported direction it is better to print the direction also.
It is unlikely, but in such an event it helps with the debugging.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git
With the callback implemented omap-dma can provide information to client
drivers regarding to supported address widths, directions, residue
granularity, etc.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 18 ++
1 file changed, 18 insertions(+)
diff
Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high
priority channels, like audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/common/edma.c
For later use save the number of queues available for the CC.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 19520e2519d9..be267b2080be 100644
---
We only support DEV_TO_MEM or MEM_TO_DEV directions with edma driver and the
check for the direction has been already done in the function calling
edma_config_pset().
The error reporting is redundant and also the else if () can be removed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
When using eDMA3 via dmaengine all dma channels will use the default queue.
Since during request time we do not have means to change this it need to be done
later, before the DMA has been started.
With the added function it is possible to move the channel to a non default
queue if it is possible,
To improve latency with cyclic DMA operation it is preferred to
use different eventq/tc than the default which is used by all
other drivers (mmc, spi, i2c, etc).
When preparing the cyclic dma ask for non default queue for the
channel which is going to be used with cyclic mode.
Signed-off-by:
Pause/Resume can be used by the audio stack when the stream is paused/resumed
The edma platform code has support for this and the legacy audio stack used
this.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 28
1 file changed, 28
Indicate that the edma dmaengine driver has support for cyclic mode.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 1 +
drivers/dma/edma.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index
Hi,
This is basically a resend of the previous series:
https://lkml.org/lkml/2014/3/13/119
with removed ASoC patches (most of them are applied already).
Changes since v1:
- ASoC patches removed
- Comments from Andriy Shevchenko addressed
- patch added to fix cases when src/dst_maxburst is set to
When clients asks for maxburst = 0 it is basically the same case as if they
were asking for maxburst = 1 since in both case ASYNC need to be used and
the eDMA is expected to write/read one word per DMA request.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 4
The edmacc_param struct should follow the layout of the paRAM area in the
HW. Be explicit on the size of the fields (u32) and also mark the struct
as packed to avoid any padding on non 32bit architectures.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/platform_data/edma.h
Hi,
Changes since v3:
- Tony's ack added
Changes since v2:
Comments from Alexander Shiyan addressed:
- Do not check the return of platform_get_resource() - no need to do that
- Use devm_ioremap_resource() instead devm_request_and_ioremap()
Changes since v1:
- Fixed Santosh's email address in
We can then remove the iounmap() calls from probe and remove.
Since the driver requests the resources via index we can do the mem resource
request within a for loop.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren
Use dev_err() which will going to print the driver's name as well and the
KERN_ERR level is sufficient in this case (we also print via dev_err when
there is an error with the mem resources)
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
With this we can remove the free_irq() calls from probe and remove.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/bus/omap_l3_noc.c | 23 +--
1 file changed, 5
It is NOP after the devm_* conversion.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/bus/omap_l3_noc.c | 6 --
1 file changed, 6 deletions(-)
diff --git
We can remove the kfree() calls from probe and remove.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/bus/omap_l3_noc.c | 11 +++
1 file changed, 3 insertions(+), 8
]
[0.392169] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:162
omap3_l3_app_irq+0x100/0x128()
[0.392186] Modules linked in:
[0.392221] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.14.0-next-20140401-6-g6e78bd6 #1
[0.392279] [c0014cd8] (unwind_backtrace) from [c0011968
If for some reason the boot loader enabled the audpwron GPIO we will have
pending IRQs to be handled. This seams to break twl6040 for some reason
leading to non working i2c communication (i2c timeouts). Clearing the INTID
register after we requested the audpwron GPIO (and set it to low) will
Make sure that we patch the ACCCTL register as the first thing when the
driver loads, thus configuring I2C fast mode and i2c access for dual access
registers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040.c | 7 +++
1 file changed, 3 insertions(+), 4
All boards using twl6040 configures the i2c bus to 400KHz. While twl6040's
defaults to normal mode (100KHz). So far twl6040 has no problem with i2c
communication in this configuration it is safer to select fast i2c mode.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi,
While looking into a report by Florian Vaussard [1] I have noticed couple of
most
likely unrelated issues:
- all boards using twl6040 configures the i2c bus to 400KHz while twl6040 is set
to 100KHz as default.
- if I set the audpwron GPIO high [2] in the bootloader the i2c communication
next-20140401-omap2plus_defconfig
craneboard: Boot FAIL: http://slexy.org/raw/s2QxOJkvil
multi_v7_defconfig seems to boot fine as well
(http://slexy.org/raw/s20Tg7ldyt).
next-20140331-omap2plus_defconfig
craneboard: Boot PASS: http://slexy.org/raw/s21s8CTKxd
diffstat between next-20140331
On Tue, Apr 1, 2014 at 8:57 AM, Nishanth Menon n...@ti.com wrote:
next-20140401-omap2plus_defconfig
craneboard: Boot FAIL: http://slexy.org/raw/s2QxOJkvil
Looks like a false alarm.. Apologies..
http://slexy.org/raw/s21jnBobtP - i did rerun multiple times and i
see it working consistently
On Tue, Apr 01, 2014 at 01:37:27PM +0300, Roger Quadros wrote:
The USB3 PHY driver (ti-pipe3) was updated so that the relevant
clock phandles are expected in the DT node.
Provide the necessary clocks.
Reported-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Roger Quadros
Wrong documentation in pinmux description can be especially confusing.
Keep it proper.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
arch/arm/boot/dts/am335x-evm.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
On 02/24/2014 12:35 PM, Paul Walmsley wrote:
Boot to userspace:
FAIL ( 1/12): 2430sdp
http://www.pwsan.com/omap/testlogs/test_v3.14-rc4/20140224102552/boot/2430sdp/
Figured out why 2430sdp does not boot with MMC filesystem.
DEVCONTROL0,1 needs to be modelled in DT-only boot as well.
* Tero Kristo t-kri...@ti.com [140401 01:38]:
On 04/01/2014 01:09 AM, Tony Lindgren wrote:
We don't want to make access to these registers available without
proper frameworks as that will lead into misuse by various drivers.
And cleaning up that mess later in is a huge pain.
Currently,
current algorithm in allocate_free_irq() is O(n),
by just keeping track of last allocated IRQ with a
simple unsigned integer, we can find a free IRQ
in O(1).
Signed-off-by: Felipe Balbi ba...@ti.com
---
compile-tested only as J6 DTS is currently missing crossbar
altogether :-(
There's a
On Tue, Apr 01, 2014 at 05:44:19PM -0500, Felipe Balbi wrote:
current algorithm in allocate_free_irq() is O(n),
by just keeping track of last allocated IRQ with a
simple unsigned integer, we can find a free IRQ
in O(1).
Signed-off-by: Felipe Balbi ba...@ti.com
---
compile-tested only as
37 matches
Mail list logo
