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 b/drivers/dma
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 b/arch/arm/common
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
--- a/arch
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
, otherwise (when only one EQ/TC is available for the CC)
the default queue is going to be used.
For example: For optimal system performance the audio (cyclic) DMA should
be placed to a separate queue which is different than what the rest of the
system is using.
Signed-off-by: Peter Ujfalusi
-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 1dd9e8806975..10048b40fac8 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -628,6 +628,9 @@ static struct dma_async_tx_descriptor
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
have included some debug cleanups for the edma dmaengine driver also.
Regards,
Peter
---
Peter Ujfalusi (14):
platform_data: edma: Be precise with the paRAM struct
dma: edma: Correct the handling of src/dst_maxburst == 0
dma: edma: Add support for DMA_PAUSE/RESUME operation
dma: edma: Set
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
://www.spinics.net/lists/linux-omap/msg90531.html
Regards,
Peter
---
Peter Ujfalusi (5):
drivers: bus: omap_l3: Convert to use devm_kzalloc
drivers: bus: omap_l3: Convert to use devm_ioremap_resource()
drivers: bus: omap_l3: Convert to use devm_request_irq()
drivers: bus: omap_l3: Remove the platform
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 a/drivers/bus
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 deletions
) will
ensure that the chip will operate normally in this case as well.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index dc5c05940e96..2e6504a8e1e3 100644
--- a/drivers/mfd
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 deletions
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
---
drivers/mfd/twl6040
the audpwron on PandaBoards: gpio set 127
Regards,
Peter
---
Peter Ujfalusi (3):
mfd: twl6040: Select i2c fast mode as default with regmap patch
mfd: twl6040: Move register patching earlier in probe
mfd: twl6040: Clear the interrupt ID register before requesting IRQ
drivers/mfd/twl6040.c
On 03/17/2014 04:09 PM, Tomi Valkeinen wrote:
Hi,
I noticed that my omap4 panda does not boot with today's linux-next
(8808b950581f71e3ee4cf8e6cae479f4c7106405). I didn't have much time to study
it, but I didn't find any posts about the issue with a quick look. Below is
the crash.
I did
On 03/13/2014 03:46 PM, Mark Brown wrote:
On Thu, Mar 13, 2014 at 11:18:22AM +0200, Peter Ujfalusi wrote:
With this series AM335x and AM447x will use the dmaengine PCM for audio. The
daVinci devices will keep using the davinci-pcm for now since I do not have
means to test them but the code
Hi Tony,
On 03/12/2014 07:37 PM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [140307 05:39]:
With the callback implemented omap-dma can provide information to client
drivers regarding to supported address widths, directions, residue
granularity, etc.
This may need some
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
-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/davinci/davinci-mcasp.c | 20
1 file changed, 20 insertions(+)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 958933614ca4..17d1112bce24 100644
--- a/sound/soc/davinci/davinci
Platform driver glue for SoC using eDMA3 to use dmaengine PCM.
The maximum number of periods need to be limited to 19 since the
edma dmaengine driver limits the paRAM slot use for audio at
in cyclic mode.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/davinci/Kconfig| 1
When we boot with non-DT mode the damengine will need the channel number and
a filter function in order to get the channel.
The filter_data is filled in the DAI driver while the filter_function will
be provided by the edma-pcm driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound
Remove the dai startup callback and do the dma_data setup for dmaengine
in the dai_probe function.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/davinci/davinci-mcasp.c | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git
since all other error cases are dev_err and this failure is
similarly fatal as the other ones.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index
Use the edma-pcm with AM335x and AM447x SoCs.
Keep using the davinci-pcm for DaVinci devices, they can be switched to use
the dmaengine based driver later when they are verified to work correctly.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/davinci/davinci-mcasp.c | 46
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 b/drivers/dma
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
-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 86d6a3fb0d92..604c7c94c731 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -624,6 +624,9 @@ static struct dma_async_tx_descriptor
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 b/arch/arm/common
, otherwise (when only one EQ/TC is available for the CC)
the default queue is going to be used.
For example: For optimal system performance the audio (cyclic) DMA should
be placed to a separate queue which is different than what the rest of the
system is using.
Signed-off-by: Peter Ujfalusi
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
--- a/arch
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
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
that DA850/OMAP-L138 works with this series (which boots w/o DT).
Regards,
Peter
---
Peter Ujfalusi (18):
platform_data: edma: Be precise with the paRAM struct
dma: edma: Add support for DMA_PAUSE/RESUME operation
dma: edma: Set DMA_CYCLIC capability flag
arm: common: edma: Select event queue 1
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
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
On 03/13/2014 12:28 PM, Lars-Peter Clausen wrote:
On 03/13/2014 10:18 AM, Peter Ujfalusi wrote: [...]
+static const struct snd_pcm_hardware edma_pcm_hardware = { +.info
= SNDRV_PCM_INFO_MMAP | + SNDRV_PCM_INFO_MMAP_VALID | +
SNDRV_PCM_INFO_BATCH
On 03/13/2014 12:28 PM, Lars-Peter Clausen wrote:
+int edma_pcm_platform_register(struct device *dev)
+{
+if (dev-of_node)
+return snd_dmaengine_pcm_register(dev,
+edma_dmaengine_pcm_config,
+SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
Since the
On 03/13/2014 02:53 PM, Shevchenko, Andriy wrote:
On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
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
On 03/13/2014 03:03 PM, Shevchenko, Andriy wrote:
On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
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
. (It can be checked few lines above the patched code -
these registers are marked as unused there.)
As a consequence three registers of audio submodule are treated as
inaccessible (preamplifier carkit right and both handsfree registers).
CC: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off
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/omap-dma.c | 18 ++
1 file changed, 18 insertions
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.shilimkar@ti
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.shilimkar@ti
---
drivers/bus
It is NOP after the devm_* conversion.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilimkar@ti
---
drivers/bus/omap_l3_noc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index
On 03/04/2014 11:01 AM, Peter Ujfalusi wrote:
We can remove the kfree() calls from probe and remove.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilimkar@ti
Where did the .com went from Santosh's email address??
I'll resend it in a minute
-omap/msg90531.html
Regards,
Peter
---
Peter Ujfalusi (5):
drivers: bus: omap_l3: Convert to use devm_kzalloc
drivers: bus: omap_l3: Convert to use devm_request_and_ioremap()
drivers: bus: omap_l3: Convert to use devm_request_irq()
drivers: bus: omap_l3: Remove the platform driver's remove
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.shilimkar@ti
---
drivers/bus/omap_l3_noc.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git
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
---
drivers/bus/omap_l3_noc.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git
It is NOP after the devm_* conversion.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/bus/omap_l3_noc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index
when doing some spring cleanup
on my HDD:
http://www.spinics.net/lists/linux-omap/msg90531.html
Regards,
Peter
---
Peter Ujfalusi (5):
drivers: bus: omap_l3: Convert to use devm_kzalloc
drivers: bus: omap_l3: Convert to use devm_request_and_ioremap()
drivers: bus: omap_l3: Convert to use
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
---
drivers/bus
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
---
drivers/bus/omap_l3_noc.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/bus
We can remove the kfree() calls from probe and remove.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilimkar@ti
---
drivers/bus/omap_l3_noc.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b
On 03/04/2014 11:23 AM, Alexander Shiyan wrote:
- l3-l3_base[2] = ioremap(res-start, resource_size(res));
- if (!l3-l3_base[2]) {
- dev_err(pdev-dev, ioremap failed\n);
- ret = -ENOMEM;
- goto err2;
+ l3-l3_base[i] =
On 03/04/2014 11:12 AM, Alexander Shiyan wrote:
Вторник, 4 марта 2014, 11:01 +02:00 от Peter Ujfalusi
peter.ujfal...@ti.com:
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
On 03/04/2014 11:12 AM, Alexander Shiyan wrote:
Вторник, 4 марта 2014, 11:01 +02:00 от Peter Ujfalusi
peter.ujfal...@ti.com:
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
Regards,
Peter
---
Peter Ujfalusi (5):
drivers: bus: omap_l3: Convert to use devm_kzalloc
drivers: bus: omap_l3: Convert to use devm_ioremap_resource()
drivers: bus: omap_l3: Convert to use devm_request_irq()
drivers: bus: omap_l3: Remove the platform driver's remove function
drivers: bus
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
---
drivers/bus/omap_l3_noc.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git
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
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
---
drivers/bus/omap_l3_noc.c | 59
It is NOP after the devm_* conversion.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/bus/omap_l3_noc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index
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
---
drivers/bus/omap_l3_noc.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/bus
On 02/28/2014 05:07 PM, Nishanth Menon wrote:
On 02/28/2014 08:26 AM, Peter Ujfalusi wrote:
On 02/28/2014 03:30 PM, Nishanth Menon wrote:
TWL6030 can do 3.3MHz by default and there are no speed registers to
configure.
According to the datasheet the speed of twl6030 is limited to 2.4MHz. I
On 02/28/2014 03:30 PM, Nishanth Menon wrote:
TWL6030 can do 3.3MHz by default and there are no speed registers to
configure.
According to the datasheet the speed of twl6030 is limited to 2.4MHz. I have
not seen registers or pins to select the speed. As the documentation puts
this: High-speed
On 02/26/2014 12:31 PM, Florian Vaussard wrote:
I statistically checked that the sleep should be placed after the GPIO
request, so indeed this seems to be the problem, and your explanation is
plausible. Can you send a proper patch?
Now, related to this, I managed to found a part of the
, PandaBoardES, OMAP4-blaze (SDP)
[1] http://www.spinics.net/lists/arm-kernel/msg310725.html
[2] Command in u-boot to enable the audpwron on PandaBoards: gpio set 127
Regards,
Peter
---
Peter Ujfalusi (3):
mfd: twl6040: Select i2c fast mode as default with regmap patch
mfd: twl6040: Move
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
---
drivers/mfd/twl6040
) will
ensure that the chip will operate normally in this case as well.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index 693d547db1de..ea8acfb029df 100644
--- a/drivers/mfd
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 | 8
1 file changed, 4 insertions(+), 4 deletions
On 02/26/2014 11:14 AM, Jyri Sarha wrote:
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/codecs/Kconfig |4
sound/soc/codecs/Makefile |2 ++
2 files changed, 6 insertions(+)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 983d087a..ead9dc5
On 02/27/2014 04:24 PM, Nishanth Menon wrote:
we should ideally have been using highspeed for i2c bus.
is'nt it better if i2c_check_functionality (and adding required flags
for func) be used to check the adapter speed and decide this in the
driver instead of hardcoding the bus speed within
On 02/27/2014 05:00 PM, Nishanth Menon wrote:
The other option might be to blindly configure 6040 to max speed -
but then you do have an issue with that single register write
operation to configure the speed?
Yes, exactly. It is unfortunate that twl6040's i2c speed is configured via i2c
write.
On 02/26/2014 11:53 AM, Florian Vaussard wrote:
On 02/26/2014 08:26 AM, Peter Ujfalusi wrote:
On 02/25/2014 05:41 PM, Florian Vaussard wrote:
If the power was not enabled at all, I would be unable to read the
revision register, no? And delaying the probe by one millisecond would
be of no help
-by: Peter Ujfalusi peter.ujfal...@ti.com
Florian Vaussard (2):
mfd: twl6040: Check for error when reading revision register
mfd: twl6040: Remove duplicate register write
drivers/mfd/twl6040.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--
Péter
--
To unsubscribe
Hi Florian,
On 02/25/2014 12:30 PM, Florian Vaussard wrote:
Hi Peter,
I got recently to work on the DT support for an OMAP4 board [1], and I
encountered some troubles with the probe of the twl6040 audio codec on
3.14-rc kernels. On 3.13, things were working correctly. So I somewhat
managed
On 02/25/2014 05:41 PM, Florian Vaussard wrote:
If the power was not enabled at all, I would be unable to read the
revision register, no? And delaying the probe by one millisecond would
be of no help in this case IMHO.
One thing which might cause this is that if the audpwron GPIO is set high
Hi,
On 02/18/2014 11:43 AM, Paolo Pisati wrote:
HDMI codec dummy entries for Panda/ES.
Signed-off-by: Paolo Pisati paolo.pis...@canonical.com
---
Depends on 0f7f3d1 ASoC: hdmi-codec: Add devicetree binding with
documentation, eligible for a 3.14-rcX fix.
On 02/19/2014 12:54 PM, Paolo Pisati wrote:
On Wed, Feb 19, 2014 at 10:15:24AM +0200, Peter Ujfalusi wrote:
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..f4aeaa1 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b
Hi Benoit,
OMAP: Put the audio nodes to disabled styate by default and board dts files
should
enable the nodes which is used on the board.
am335x: correct the audio mclk clock. This patch has been marked to go to 3.13
stable as well.
Regards,
Peter
---
Peter Ujfalusi (9):
ARM: DTS
Attach the pinctrl nodes to their respective device node:
mcbsp1, mcpdm and twl6040.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap4
All audio nodes has been set to disabled state in omap4.dtsi file.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 12
1 file changed, 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts
All audio nodes has been set to disabled state in omap4.dtsi file.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 513b01774966
Board dts files will need to enable the IP nodes which they are using and
does not have to care about the not used ones (to disable them).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot
Attach the pinctrl nodes to their respective device node:
mcbsp1, mcbsp2, dmic, mcpdm and twl6040.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/arch
Board dts files will need to enable the IP nodes which they are using and
does not have to care about the not used ones (to disable them).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot
In omap2420.dtsi and omap2430.dtsi disable all mcbsp nodes and board dts
files can explicitly enable the mcbsp they are using.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap2420.dtsi | 2 ++
arch/arm/boot/dts/omap2430.dtsi | 5 +
2 files changed, 7 insertions
In omap3.dtsi disable all mcbsp nodes and board dts files can explicitly
enable the mcbsp they are using.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 4
arch/arm/boot/dts/omap3-beagle.dts | 4
arch/arm/boot/dts/omap3-devkit8000
The clock for audio is sourced from virt_2400_ck, so the correct
frequency is 2400.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: sta...@vger.kernel.org # 3.13.x
---
arch/arm/boot/dts/am335x-evmsk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm
701 - 800 of 1965 matches
Mail list logo
