AM57xx does not have ATL block integrated.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 6463f9ef2b54
To be able to control the gate for the clkout2 clock output.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b
On 02/25/2015 05:05 PM, Arnd Bergmann wrote:
The change to enable OMAP5 support on this platform was a little too
eager in adding a 'select' for a particular clock driver that might
not be enabled in all configurations, which in turn leads to a build
error:
warning:
The DRA7x has more peripherals with DMA requests than the sDMA can handle:
205 vs 127. All DMA requests are routed through the DMA crossbar, which can
be configured to route selected incoming DMA requests to specific sDMA
request.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers
Instead of magic numbers in the code, use define for number of logical DMA
channels and DMA requests.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma
Use the dma-requests property from DT to get the number of DMA requests.
In case of legacy boot or failure to find the property, use the default
127 as number of requests.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 11 ++-
1 file changed, 10
to
be added.
The omap-dma part of changes are based on the dma property name change series:
https://lkml.org/lkml/2015/2/20/182
but the code has fallback so it is working w/o the changes in that series.
Regards,
Peter
---
Peter Ujfalusi (6):
dmaengine: of_dma: Support for DMA routers
dmaengine
channels with HW request lines will make it
harder to implement MEM_TO_MEM mode for the driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
generic
enough to be used in different environments.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/dma/dma.txt | 27
drivers/dma/dmaengine.c | 7 ++
drivers/dma/of-dma.c | 92
On 02/24/2015 04:25 PM, Russell King - ARM Linux wrote:
On Tue, Feb 24, 2015 at 04:21:21PM +0200, Peter Ujfalusi wrote:
Use the dma-requests property from DT to get the number of DMA requests.
In case of legacy boot or failure to find the property, use the default
127 as number of requests
The sDMA requests are routed through the DMA crossbar and without the
crossbar only peripherals using DMA request 0-127 can be used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 57 ++---
1 file changed, 33
On 02/24/2015 04:28 PM, Russell King - ARM Linux wrote:
On Tue, Feb 24, 2015 at 04:21:22PM +0200, Peter Ujfalusi wrote:
Do not direct map the virtual channels to sDMA request number. When the
sDMA is behind of a crossbar this direct mapping can cause situations when
certain channel can
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm
are not in use at the moment, but it is going to be
needed
for the crossbar driver it is better to fix it right now so we do not need to
patch .dtsi and .c files at the same time later.
Tony: I would really appreciate if this could go in within the current merge
window.
Thanks,
Peter
Peter
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm
On 02/12/2015 11:08 AM, Kiran Padwal wrote:
This patch add a missing check on the return value of devm_kzalloc,
which would cause a NULL pointer dereference in a OOM situation.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com
...@infradead.org
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 1 +
arch/arm/mach-omap2/omap_hwmod.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 92afb723dcfc..2db380420b6f
On 02/06/2015 09:26 PM, Peter Ujfalusi wrote:
Yeah, I've never really bothered with data too much, its a debug
feature. So lock_class_key is 8 bytes, and strictly speaking you could
union them over other fields, all we really need is unique addresses, we
don't actually use the storage.
True
On 02/06/2015 08:32 PM, Peter Zijlstra wrote:
On Fri, Feb 06, 2015 at 06:05:32PM +0200, Peter Ujfalusi wrote:
Certainly looks much simpler, but it adds quite a bit of data to the
omap_hwmod struct, and we have a _lot_ of them for omap2plus configuration.
ls -al vmlinux
w/o any the lockdep
On 02/06/2015 04:13 PM, Peter Zijlstra wrote:
On Fri, Feb 06, 2015 at 02:48:34PM +0200, Peter Ujfalusi wrote:
Hi,
In case when hwmods are used in nested way the lockdep validator will print
out
a warning message about possible deadlock situation:
[4.514882
The ATL hwmod can be used in nested way when it is selected to be the
functional clock for McASP. For this lockdep validator will trigger false
positive warning.
By assigning separate class to atl locking will sort this out.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach
subclass to those hwmods which
could be used in nested way.
Regards,
Peter
---
Peter Ujfalusi (2):
ARM: omap2+: omap_hwmod: Use _nested version of spinlock for oh-_lock
ARM: DRA7: hwmod_data: Change locked_class for atl hwmod
arch/arm/mach-omap2/omap_hwmod.c | 16
arch
select ATL clock
as functional clock, which will trigger nested oh-_lock usage. This will
trigger false warning from lockdep validator since it is dealing with
classes and for it all hwmod clocks are the same class.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2
On 02/04/2015 12:25 AM, Benoît Thébaudeau wrote:
Dear Jyri Sarha,
Sorry to come late.
On Mon, Feb 2, 2015 at 3:48 PM, Jyri Sarha jsa...@ti.com wrote:
[...]
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index b7ebce0..cb92cdb 100644
---
On 02/04/2015 11:33 AM, Benoît Thébaudeau wrote:
What I meant was to do the following instead:
/*
* ADC PGA mix input volumes. From -12 to 0 dB in 1.5 dB steps. Disconnected
* below -12 dB
*/
static const DECLARE_TLV_DB_SCALE(mix_tlv, -1350, 150, 1);
/* Left PGA Mixer for
On 02/04/2015 01:11 PM, Benoît Thébaudeau wrote:
Dear Peter Ujfalusi,
On Wed, Feb 4, 2015 at 11:02 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
On 02/04/2015 11:33 AM, Benoît Thébaudeau wrote:
What I meant was to do the following instead:
/*
* ADC PGA mix input volumes. From -12 to 0
On 01/30/2015 06:02 PM, Jyri Sarha wrote:
Disables GPIO support and LINE2 input and renames Mic3 input to Mic2,
if tlv320aic3104 mode is seleced. Devicetree binding document is
updated accordingly.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../devicetree/bindings/sound/tlv320aic3x.txt
On 01/30/2015 02:40 PM, Peter Ujfalusi wrote:
On 01/30/2015 12:37 PM, Pavel Machek wrote:
Hi!
I looked around the diff between 3.18 and 3.19, reverted these, and
audio quality is back to reasonable level.
Actually, reverting 368494093354ac613a80c2e1d77602aa12473cf0 seems
enough.
Any
On 01/30/2015 12:37 PM, Pavel Machek wrote:
Hi!
I looked around the diff between 3.18 and 3.19, reverted these, and
audio quality is back to reasonable level.
Actually, reverting 368494093354ac613a80c2e1d77602aa12473cf0 seems
enough.
Any quick patches to test? Or should we revert so
On 01/29/2015 09:35 AM, Jarkko Nikula wrote:
On Wed, Jan 28, 2015 at 11:41:44PM +0100, Pavel Machek wrote:
On Wed 2015-01-28 20:15:46, Jarkko Nikula wrote:
On 01/26/2015 03:20 PM, Peter Ujfalusi wrote:
On 01/18/2015 02:01 PM, Pavel Machek wrote:
No need to go that far. N900 has been supported
On 01/27/2015 03:32 PM, Pavel Machek wrote:
On Tue 2015-01-27 15:27:58, Peter Ujfalusi wrote:
Hi,
On 01/26/2015 10:51 PM, Pali Rohár wrote:
qemu does not emulate it
Not sure about this... How does qemu emulate tlv320aic3106, tpa6130a2a,
McBSP,
sDMA for audio to work? What about the other
Hi,
On 01/26/2015 10:51 PM, Pali Rohár wrote:
qemu does not emulate it
Not sure about this... How does qemu emulate tlv320aic3106, tpa6130a2a, McBSP,
sDMA for audio to work? What about the other three GPIOs in this machine driver?
The nokia,n900-audio compatible mandates that the
On 01/18/2015 02:01 PM, Pavel Machek wrote:
Hi!
If you have any idea about playback problems, help would be still
welcome. I'll have to do bisect, otherwise, and it will not be easy.
In 3.18, sound is nice and clear.
In 3.19, sound is unusable. It produces nasty tone when it should be
Hi,
On 01/22/2015 03:40 AM, Olof Johansson wrote:
Hi,
On Thu, Nov 27, 2014 at 2:41 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
include/linux/platform_data/ is not a correct place to keep the API
definitions for edma, it is meant to be only for the pdata for the device.
Clean up
entry
Among other boards I have my daVinci board (OMAP-L138-EVM) boots fine with
this patch.
Tested-by: Peter Ujfalusi peter.ujfal...@ti.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
on CLKR/CLKX
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Thomas Niederprüm nied...@physik.uni-kl.de
---
sound/soc/omap/omap-mcbsp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index bd3ef2a
On 01/16/2015 05:06 PM, Thomas Niederprüm wrote:
Unfortunately the omap-mcbsp driver only supports synchronous configuration
for tx/rx (since almost all McBSP instance can only be used this way). The
first stream will configure both tx and rx to have the same properties. Even
if you are using
On 01/16/2015 12:28 AM, Thomas Niederprüm wrote:
This patch fixes faulty behaviour in a setup where the input clock for
the SRG is fed through the CLKR pin but the McBSP is configured to be
master (SND_SOC_DAIFMT_CBS_CFS). In that case of course CLKR must not be
configured as output pin.
On 01/16/2015 12:15 PM, Thomas Niederprüm wrote:
Am Freitag, den 16.01.2015, 11:15 +0200 schrieb Peter Ujfalusi:
On 01/16/2015 12:28 AM, Thomas Niederprüm wrote:
This patch fixes faulty behaviour in a setup where the input clock for
the SRG is fed through the CLKR pin but the McBSP
On 12/18/2014 06:41 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [141217 09:28]:
And then there are these too in the current mainline that are
clock related:
omap4xxx_dt_clk_init: failed to configure ABE DPLL!
...
clock: dpll_abe_ck failed transition to 'locked'
clock:
On 12/18/2014 01:49 PM, Mark Brown wrote:
On Thu, Dec 18, 2014 at 10:16:18AM +, Russell King - ARM Linux wrote:
So that doesn't work - but importantly, it does point towards a
possible culpret - snd_soc_of_parse_audio_routing().
This is obvious when you stop and think about what it's
On 12/08/2014 02:49 PM, Vinod Koul wrote:
On Thu, Nov 27, 2014 at 12:41:31PM +0200, Peter Ujfalusi wrote:
include/linux/platform_data/ is not a correct place to keep the API
definitions for edma, it is meant to be only for the pdata for the device.
Clean up this by moving the API to include
On 11/28/2014 12:51 PM, Arnd Bergmann wrote:
On Friday 28 November 2014 09:16:24 Peter Ujfalusi wrote:
On 11/27/2014 11:52 PM, Arnd Bergmann wrote:
On Thursday 27 November 2014 20:46:12 Peter Ujfalusi wrote:
I see. With this series I did not planed to fix all edma related issues,
just
---
Peter Ujfalusi (3):
ASoC: davinci-evm: Do not include edma headers
ARM: edma: Rename header file for dmaengine filter function definition
ARM: edma: Split up header file to platform_data and API file
arch/arm/common/edma.c | 3 +-
arch/arm/mach-davinci/devices.c
Rename the include/linux/edma.h to include/linux/edma-dmaengine.h
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 2 +-
drivers/mmc/host/davinci_mmc.c | 3 +--
drivers/spi/spi-davinci.c | 2 +-
include/linux/edma-dmaengine.h | 29
include/linux/platform_data/ is not a correct place to keep the API
definitions for edma, it is meant to be only for the pdata for the device.
Clean up this by moving the API to include/linux/edma.h
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c
The machine driver has no business with the underlying dma.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/davinci/davinci-evm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 158cb3d1db70
On 11/27/2014 01:14 PM, Arnd Bergmann wrote:
On Thursday 27 November 2014 12:41:30 Peter Ujfalusi wrote:
diff --git a/include/linux/edma-dmaengine.h b/include/linux/edma-dmaengine.h
new file mode 100644
index ..8a2602809a77
--- /dev/null
+++ b/include/linux/edma-dmaengine.h
On 11/27/2014 04:50 PM, Arnd Bergmann wrote:
On Thursday 27 November 2014 16:23:31 Peter Ujfalusi wrote:
This will only work in case of legacy boot. When booting with DT we do not
have pdata and after this patch in dt boot we are not going to be able to get
the DMA resources either
On 11/27/2014 11:52 PM, Arnd Bergmann wrote:
On Thursday 27 November 2014 20:46:12 Peter Ujfalusi wrote:
I see. With this series I did not planed to fix all edma related issues, just
as a start clean up the related header files. I would rather not add fixes to
mmc, spi, etc drivers since
Sarha jsa...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/sound/omap-hdmi-audio.h | 43
sound/soc/omap/Kconfig | 15 ++
sound/soc/omap/Makefile |2 +
sound/soc/omap/omap-hdmi-audio.c | 407
++
4 files
-off-by: Jyri Sarha jsa...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/Kconfig | 13 --
sound/soc/omap/Makefile |4 -
sound/soc/omap/omap-hdmi-card.c | 87 --
sound/soc/omap/omap-hdmi.c | 364
).
With this patch we don't BUG in the scenario described.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Cc: vinod.k...@intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma
It is safe to call the pm sync calls in interrupt context in this driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/clk/ti/clk-dra7-atl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c
index af29359677da
On 09/18/2014 07:12 PM, Sebastian Andrzej Siewior wrote:
* Peter Ujfalusi | 2014-09-18 12:42:24 [+0300]:
My hunch on what could be causing this that we might have unhandled dma event
and another comes. This will flag the EDMA_EMR register. Any change in this
register will assert error
on the backround...
Can you print out the EDMA_EMCR just before we clear it in the places I have
mentioned? We might get better understanding on which stage we clear it and
probably we can understand how to fix this properly so we are not going to
have missed events on channels.
Acked-by: Peter
Vinod,
On 09/16/2014 10:45 PM, Peter Ujfalusi wrote:
Hi,
Changes since v2:
- fix typo in patch two
- Acked-by added from Russell
When the audio is paused/resumed (application paused the sream or board
suspend)
the audio was only playing back one period worth of data and then stops
to be played back and the DMA will stop, since the linking is disabled.
The link need to be enabled in omap_dma_start() to make sure that cyclic
transfer can continue.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 12
1 file changed, 12 insertions(+)
diff
On 09/16/2014 04:22 PM, Russell King - ARM Linux wrote:
On Tue, Sep 16, 2014 at 04:06:25PM +0300, Peter Ujfalusi wrote:
When the audio stream is paused or suspended we stop the sDMA and when it
is unpsues/resumed we start the channel without reconfiguring it.
The omap_dma_stop() clears
since this could happen right after
coming out from suspend.
Regards,
Peter
---
Peter Ujfalusi (2):
dmaengine: omap-dma: Add memory barrier to dma_resume path
dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
drivers/dma/omap-dma.c | 5 +
1 file changed, 5 insertions(+)
--
2.1.0
Add mb() call to resume path to ensure the necessary barrier.
Resume can happen after waking up from suspend for example.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap
to be played back and the DMA will stop, since the linking is disabled.
We need to restore the CLINK_CTRL register in case of resume.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/omap-dma.c b/drivers
and it is not restored in
start.
Also add memory barrier call to resume path since this could happen right after
coming out from suspend.
Regards,
Peter
---
Peter Ujfalusi (2):
dmaengine: omap-dma: Add memory barrier to dma_resume path
dmaengine: omap-dma: Restore the CLINK_CTRL in resume path
Add mb() call to resume path to ensure the necessary barrier.
Resume can happen after waking up from suspend for example.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/omap-dma.c | 2 ++
1 file changed, 2 insertions
to be played back and the DMA will stop, since the linking is disabled.
We need to restore the CLINK_CTRL register in case of resume.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/dma/omap-dma.c | 3 +++
1 file changed, 3 insertions
On 09/12/2014 04:39 PM, Tero Kristo wrote:
of_clk_add_provider makes an internal copy of the parent_names property
while its called, thus it is no longer needed after this call and can
be freed.
Thanks Tero, indeed this was overlooked in the original driver.
Acked-by: Peter Ujfalusi
+++---
1 file changed, 77 insertions(+), 51 deletions(-)
Tested-by: Peter Ujfalusi peter.ujfal...@ti.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
On 08/01/2014 04:15 PM, Tero Kristo wrote:
Hi,
This patch adds possibility to register external clocks (outside the main
SoC) on TI boards through device tree. Clock sources as such include for
example twl-6030 / twl-6040 chips and variants which can be used to clock
for example audio /
In case of edma_alloc_slot() failure during probe we should return the error
unchanged to make debugging easier.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
DT boot does not yet support more than one edma device. To avoid issues at
runtime we should not register the second device when the kernel is booted
with DT.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
On 07/29/2014 07:12 PM, Mike Turquette wrote:
Oh yea, seems this got lost into the myriad of branches I have. I can push
this on top of my for-v3.17/ti-clk-drv if you like.
That is the easiest thing for me. I think that Peter wanted to take
this as a fix for 3.16 though. Peter is that
On 07/16/2014 03:29 PM, Peter Ujfalusi wrote:
Hi,
After this series clients can ask to not receive notifications after each
period.
In this case we can disable the completion interrupt since the position
reporting
does not rely on it for cyclic mode.
Patchset for ASoC part has been sent
On 07/08/2014 01:46 PM, Peter Ujfalusi wrote:
Hi,
It is preferred that audio is served with the highest priority queue in order
to
avoid delays in data transfer between memory and audio IP.
The following series will add an API to arch code to assign a channel to a
given
queue
If the client (audio) does not request interrupts for every period we can
disable them.
With updated audio driver stack we can play audio w/o the need to process
any edma interrupts.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 6 +++---
1 file changed, 3
pulse some_music.mp3
# yet another terminal to monitor the interrupts
watch cat /proc/interrupts
# note the non increasing number of edma interrupts ;)
Regards,
Peter
---
Peter Ujfalusi (2):
dma: edma: Update caps-residue_granularity to match with reality
dma: edma: Support to suppress
The edma can report accurate DMA position so update the residue_granularity
to DMA_RESIDUE_GRANULARITY_BURST.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
On 05/06/2014 04:39 PM, Peter Ujfalusi wrote:
Tero: can I have your ack for this patch or do you have further concerns?
Yea looks good to me, except for the fact that there is some work on getting
default rate/parent support through DT. I would like a comment from Mike
about
the estimate
On 07/11/2014 07:14 AM, Himangi Saraogi wrote:
This patch introduces the use of managed interfaces like devm_clk_get
and does away with the clk_puts in the probe and remove functions. A
label is also done away with.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Himangi
and is completely
removed.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Himangi Saraogi himangi...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
---
sound/soc/omap/omap-dmic.c | 35 ---
1 file changed, 8 insertions(+), 27 deletions
Hi,
This set is to enable audio (finally) on the omap5-uevm. We have been waiting
for the palmas 32K clock driver to make it to upstream, which it did and it is
already in linux-next.
With the three patch we can have audio working on omap5-uevm with linux-next.
Regards,
Peter
---
Peter Ujfalusi
clk32kg-audio clock is needed for twl6040 codec.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 1e1b05768cec..9166d479ac1b
The board uses twl6040 as audio codec. Move the corresponding pinctrl as
well under the node.
twl6040 needs 32k clock from palams.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 20 +++-
1 file changed, 19 insertions(+), 1 deletion
The board uses twl6040 codec connected via McPDM link. McBSP1 and McBSP2 can
be used for FM/BT.
At the same time move the pinctrl handling to the correct place - under the
corresponding nodes.
Audio connectors on the board:
Headset in/out
Stereo Line out
Stereo Line in.
Signed-off-by: Peter
Hi Tony,
On 07/07/2014 02:46 PM, Tony Lindgren wrote:
* Jyri Sarha jsa...@ti.com [140626 12:26]:
This code is not working currently and it can be removed. There is a
conflict in sharing resources with the actual HDMI driver and with
the ASoC HDMI audio DAI driver.
Is this OK to queue for
Move the DMA channel used in cyclic mode (audio) to the highest priority
event queue which helps to reduce audio problems.
When the channel is terminated, move it back to the default queue.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 8
1 file changed, 8
Use the lowest priority queue as default for clients.
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/edma.c
index 485be42519b9..f834aae7720f 100644
In some cases it is desired to move a channel to a specific event queue.
Such a use case is audio, where it is preferred that it is served with
highest priority compared to other DMA clients.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 28
priority.
In the dmaengine driver we move the cyclic channel to queue0 (highest priority)
and move it back to default queue when the channel is terminated.
Regards,
Peter
---
Peter Ujfalusi (3):
ARM: edma: Set default queue to lowest priority
ARM: edma: Add edma_assign_channel_eventq() to move
On 07/08/2014 07:25 PM, Manish Badarkhe wrote:
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Changes since V1:
Aligned
On 07/08/2014 07:53 PM, Manish Badarkhe wrote:
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Changes since V1:
Aligned
On 07/08/2014 07:47 PM, Manish Badarkhe wrote:
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
Jut to make things easier I think we should not have this patch applied since
Jyri's OMAP4+
On 07/06/2014 09:49 AM, Manish Badarkhe wrote:
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
---
:100644 100644 eb9c392... 1dc95b5... Msound/soc/omap/omap-hdmi.c
On 07/05/2014 08:09 AM, Manish Badarkhe wrote:
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
---
:100644 100644 efe2cd6... bfc8f8e... Msound/soc/omap/omap-mcbsp.c
On 07/06/2014 09:50 AM, Manish Badarkhe wrote:
Replaced snd_soc_register_component with its devres equivalent,
devm_snd_soc_register_component.
Signed-off-by: Manish Badarkhe badarkhe.man...@gmail.com
---
:100644 100644 6925d71... 011e30e... Msound/soc/omap/omap-dmic.c
The use of FIFO in McASP can reduce the risk of audio under/overrun and
lowers the load on the memories since the DMA will operate in bursts.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
The use of FIFO in McASP can reduce the risk of audio under/overrun and
lowers the load on the memories since the DMA will operate in bursts.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Hi Javier,
On 06/27/2014 09:23 PM, Javier Martinez Canillas wrote:
Hello Peter,
On Fri, Jun 27, 2014 at 8:01 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Palmas class of devices can provide 32K clock(s) to be used by other devices
on the board. Depending on the actual device the provided
501 - 600 of 1965 matches
Mail list logo
