dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot
this member does not
make any sense (and the driver no longer uses it).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/platform_data/edma.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot
set up a default priority map.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 115 +++--
1 file changed, 73 insertions(+), 42 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index aa9473cb0c23
The struct edma is allocated per CC bases so the member num_cc does not make
any sense. One CC is one CC, it does not have sub CCs.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch
since the very same information can be obtained from the HW.
The mentioned properties are deprecated.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git
There is no need to change the default TC - Queue mapping. By default the
mapping is: TC0 - Q0, TC1 - Q1, etc.
Changing this has no benefits at all and all the board files are just setting
the same mapping back to the HW.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common
It is no longer in use by the driver or board files.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/platform_data/edma.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 12f134b1493c
and they can be
removed from the binding documentation and from the dtsi files as well.
The change will not introduce regression when new kernel is booted using older
DTB (since we just ignore the mentioned properties).
Regards,
Peter
---
Peter Ujfalusi (13):
ARM: edma: No need to clean the pdata
The pdata has been just allocated with devm_kzalloc() in
edma_setup_info_from_dt() and passed to this function.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
On 05/18/2014 06:42 PM, Axel Lin wrote:
Use devm_clk_register() to simplify the code by removing twl6040_clk_remove().
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/clk/clk-twl6040.c | 12 +---
1 file changed, 1 insertion
On 05/19/2014 02:07 PM, Sekhar Nori wrote:
To which baseline do the patches apply? These lines are not present at
least in v3.15-rc5. I am applying the patch without this hunk.
It is generate on top of linux-next-20140515.
next picked up several patches since 3.15-rc and I also have my other
On 05/19/2014 04:06 PM, Sekhar Nori wrote:
On Friday 16 May 2014 05:47 PM, Peter Ujfalusi wrote:
Hi,
Changes since v2:
- Comments from Sekhar and Arnd has been addressed best as I could.
- Use the CCCFG information in all cases instead of pdata provided
information
- To achieve this I
Mike,
On 05/06/2014 04:31 PM, Nishanth Menon wrote:
On 16:24-20140506, Peter Ujfalusi wrote:
Hi,
Changes since v1:
- binding documentation and driver has been separated based on Nishanth
Menon's
comment
Could you take a look at this series please? I really hoped that it would make
On 05/27/2014 12:32 AM, Olof Johansson wrote:
Hi,
On Mon, Apr 14, 2014 at 4:41 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
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
On 05/27/2014 06:03 PM, Joel Fernandes wrote:
On 05/27/2014 05:22 AM, Peter Ujfalusi wrote:
On 05/27/2014 12:32 AM, Olof Johansson wrote:
[..]
I came across this patch when I was looking at a pull request from
Sekhar for EDMA cleanups, and it made me look closer at the contents
of this file
Get the two interrupt line number at the same time by merging the two
instance of if(node){}else{} places.
replace the pdev-dev with the already existing dev which makes it possible
to collapse lines with devm_request_irq()
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common
DTB (since we just ignore the mentioned properties).
Regards,
Peter
---
Peter Ujfalusi (4):
ARM: edma: Get IP information from HW when booting with DT
dt/bindings: ti,edma: Remove redundant properties from documentation
ARM: dts: am33xx: Remove obsolete properties from edma node
ARM: dts
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot
since the very same information can be obtained from the HW.
The mentioned properties can be removed from the binding document.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 6 --
1 file changed, 6 deletions(-)
diff --git
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common
On 05/13/2014 11:33 AM, Sekhar Nori wrote:
On Tuesday 13 May 2014 01:13 PM, Peter Ujfalusi wrote:
Hi,
We are requesting redundant information via DT for the driver since the very
same
data is available in the HW: by reading and decoding the content of CCCFG
register we can get:
Number
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot
dma-channels, ti,edma-regions and ti,edma-slots no longer needed in DT since
the the same information is available in the IP's CCCFG register.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot
since the very same information can be obtained from the HW.
The mentioned properties can be removed from the binding document.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 6 --
1 file changed, 6 deletions(-)
diff --git
The pdata has been just allocated with devm_kzalloc() in
edma_setup_info_from_dt() and passed to this function.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
as well.
The change will not introduce regression when new kernel is booted using older
DTB (since we just ignore the mentioned properties).
Regards,
Peter
---
Peter Ujfalusi (5):
ARM: edma: No need to clean the pdata in edma_of_parse_dt()
ARM: edma: Get IP information from HW when booting with DT
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common
Hi Lee,
On 01/08/2014 10:05 AM, Lee Jones wrote:
Depend on the regmap reg cache implementation for register caching done in
the twl-core driver.
The local register cache can be removed and we can keep only shadow copies
of certain ctl registers for pop noise reduction.
Signed-off-by: Peter
Hi,
On 01/25/2014 05:35 PM, Belisko Marek wrote:
Hello,
booting linux-next (not actual but older from 20.12 gives me following
warning).
I'm booting gta04 device via devicetree with added sound node (copied
from beagleboard)
Not sure what goes wrong on your board. I just tested today's
The new twl_get_regmap() function will return a pointer to the regmap needed
for the given module.
Since both read and write function were using the same code to do the lookup
we can reuse this in both places to simplify the code.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers
To avoid another lookup for the twl4030_priv in there.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl4030.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index c3c15f891270
No need to keep the check defaults functionality anymore.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/i2c/twl.h| 1 -
sound/soc/codecs/twl4030.c | 23 ---
2 files changed, 24 deletions(-)
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c
Depend on the regmap reg cache implementation for register caching done in
the twl-core driver.
The local register cache can be removed and we can keep only shadow copies
of certain ctl registers for pop noise reduction.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs
There's no other users of this functionality, the code can be moved inside
of twl4030_write.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl4030.c | 36
1 file changed, 16 insertions(+), 20 deletions(-)
diff --git a/sound/soc
Over time the multi line alignment got messed up. Correct them in one go
so the code will look consistent.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl4030.c | 93 ++
1 file changed, 45 insertions(+), 48 deletions
will be initialized.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl4030.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index ab2f22299db2..f88207712d3d 100644
--- a/sound/soc/codecs/twl4030.c
to be monitored. With the twl_set_regcache_bypass() the
client driver can switch regcache bypass on and off when it is needed so
we can utilize the regcache for more registers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 21 +
include/linux
Enable regmap's regcache for the audio registers:
i2c address 0x49, register range 0x01 - 0x49
Mark all other registers as volatile to avoid any side effect for the non
audio functions behind 0x49 i2c address.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 111
Simplifies the code a bit and prepares it to the removal of local caching.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl4030.c | 40 +++-
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c
The register states now tracked by the regmap implementation in the core which
makes the reset registers functionality 'redundant' since we know the state
of the registers now all the time.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/i2c/twl.h| 1 -
sound/soc
.
Regards,
Peter
---
Peter Ujfalusi (11):
MFD: twl-core: Simplify IO wrapper functions by moving common code out
MFD: twl-core: API to set the regcache bypass for a given regmap in
twl
MFD: twl-core: Enable regcache for audio registers
ASoC: twl4030: Separate write condition checking from
that it is always
running.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/mfd/twl6040.txt | 2 ++
drivers/mfd/twl6040.c | 10 ++
include/linux/mfd/twl6040.h | 2 ++
3 files changed, 14 insertions
On 04/28/2014 05:18 PM, Grant Likely wrote:
On Thu, 24 Apr 2014 22:01:02 +0100, Grant Likely grant.lik...@secretlab.ca
wrote:
On Thu, Apr 24, 2014 at 8:31 AM, Peter Ujfalusi peter.ujfal...@ti.com
wrote:
Hi Greg, Grant,
On 04/09/2014 01:52 PM, Peter Ujfalusi wrote:
Hi,
Changes since v1
In order to get correct clock dividers for AESS/ABE we need to set the
dpll_abe_m2x2_ck rate to be double of dpll_abe_ck.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/clk/ti/clk-54xx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/ti/clk-54xx.c b
abe_iclk's parent is aess_fclk and not abe_clk.
Also correct the parameters for clock rate calculation as used for OMAP4
since in PRCM level there's no difference between the two platform
regarding to AESS/ABE clocking.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts
In OMAP5 bit 8 in PRCM registers are not defined (Reserved) unlike their
counterpart in OMAP4.
It is better to not write to these bits.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 48 --
1 file changed, 48
When the MCLK is 19.2 or 38.4 MHz the HPPLL need to be enabled and can be
put in bypass mode.
This will fix HPPLL use on boards with 19.2MHz mclk.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040.c | 13 +
1 file changed, 5 insertions(+), 8 deletions
is done via
the clock API there is a posibility to enable the external sleep
control. In this way the clock can be enabled/disabled on demand by the
user of the clock.
See the documentation for more details.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/clk/Kconfig | 7
is done via
the clock API there is a posibility to enable the external sleep
control. In this way the clock can be enabled/disabled on demand by the
user of the clock.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
.../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35
/disabled on demand by the
user of the clock.
Regards,
Peter
---
Peter Ujfalusi (2):
dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio
clocks
clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
.../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 +++
drivers
Mike,
On 04/24/2014 06:03 PM, Tero Kristo wrote:
On 04/24/2014 12:11 PM, Peter Ujfalusi wrote:
Mike, Tero,
On 04/03/2014 09:29 AM, Peter Ujfalusi wrote:
On 04/02/2014 05:12 PM, Tero Kristo wrote:
On 04/02/2014 04:48 PM, Peter Ujfalusi wrote:
ABE DPLL frequency need to be lowered from
On 04/03/2014 04:49 PM, Nishanth Menon wrote:
On 04/03/2014 05:52 AM, Peter Ujfalusi wrote:
[...]
.../devicetree/bindings/clock/clk-palmas.txt | 35 +++
drivers/clk/Kconfig| 7 +
drivers/clk/Makefile | 1 +
drivers/clk
On 04/08/2014 03:47 PM, Grant Likely wrote:
On Tue, Apr 8, 2014 at 3:27 AM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Thu, 3 Apr 2014 10:40:59 +0100, Mark Brown broo...@kernel.org wrote:
On Thu, Apr 03, 2014 at 10:12:07AM +0300, Peter Ujfalusi wrote:
When the kernel is built
On 04/08/2014 03:43 PM, Grant Likely wrote:
On Thu, 3 Apr 2014 10:12:07 +0300, Peter Ujfalusi peter.ujfal...@ti.com
wrote:
When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
when all modules loaded but some driver still stuck in the deferred list
and there is a need
On 04/08/2014 04:35 PM, Peter Ujfalusi wrote:
On 04/08/2014 03:43 PM, Grant Likely wrote:
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 06051767393f..80703de6e6ad 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -53,6 +53,10 @@ static LIST_HEAD(deferred_probe_pending_list
like connecting USB stick, etc.
The proposed solution is to try the deferred queue once more when the last
driver is asking for deferring and we had drivers loaded while this last
driver was probing.
This way we can avoid drivers stuck in the deferred queue.
Regards,
Peter
---
Peter Ujfalusi (2
.
This way we can avoid drivers stuck in the deferred queue.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/base/dd.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 43d573b960ba
Move both functions after driver_deferred_probe_trigger() in the source file
since upcoming patch will need to call the _trigger from _add.
Move also the _del so the functions will be kept together.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/base/dd.c | 40
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
Acked-by: Joel Fernandes jo...@ti.com
---
Hi Vinod,
rebased on:
git://git.infradead.org/users/vkoul/slave-dma.git next
On top
Hi Greg, Grant,
On 04/09/2014 01:52 PM, Peter Ujfalusi wrote:
Hi,
Changes since v1:
- The deferral race detection and handling has been moved to
driver_deferred_probe_trigger() and driver_deferred_probe_add() functions
with
comment section.
- driver_deferred_probe_add/del function
On 04/16/2014 07:05 PM, Joel Fernandes wrote:
On 04/16/2014 07:59 AM, Peter Ujfalusi wrote:
[..]
If the dma-priority is missing we should assume lowest priority (0).
The highest priority depends on the platform. For eDMA3 in AM335x it is
three
level. For designware controller you might have
Hi Mike,
On 04/03/2014 01:52 PM, Peter Ujfalusi wrote:
Palmas class of devices have either twl 32K clock outputs:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one
Mike, Tero,
On 04/03/2014 09:29 AM, Peter Ujfalusi wrote:
On 04/02/2014 05:12 PM, Tero Kristo wrote:
On 04/02/2014 04:48 PM, Peter Ujfalusi wrote:
ABE DPLL frequency need to be lowered from 361267200
to 180633600 to facilitate the ATL requironments.
The dpll_abe_m2x2_ck clock need to be set
Lee,
On 04/01/2014 04:44 PM, Peter Ujfalusi wrote:
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
Hi Mike,
On 04/02/2014 04:55 PM, Peter Ujfalusi wrote:
Hi,
Audio Tracking Logic is designed to be used by HD Radio
applications to synchronize the audio output clocks to the
baseband clock. ATL can be also used to track errors between
two reference clocks (BWS, AWS) and generate
Lee,
On 04/03/2014 01:54 PM, Peter Ujfalusi wrote:
In certain boards the source for the clk32k clock can be gated. In these
boards the clk32k clock can be provided to the driver and it is going to be
enabled/disabled when it is needed.
If the clk32k clock is not provided the driver
On 04/18/2014 12:00 AM, Nishanth Menon wrote:
On 04/17/2014 03:57 PM, Santosh Shilimkar wrote:
I looked at the series and its looks pretty good. Thanks for fixups, updates.
For whole series,
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Thanks.
Patches(including Peter's) is
On 04/24/2014 05:19 PM, Nishanth Menon wrote:
On 04/24/2014 03:55 AM, Peter Ujfalusi wrote:
On 04/18/2014 12:00 AM, Nishanth Menon wrote:
On 04/17/2014 03:57 PM, Santosh Shilimkar wrote:
I looked at the series and its looks pretty good. Thanks for fixups,
updates.
For whole series,
Acked
The new renameat2() system call was only wired up for ARM causing:
CALL
/home/ujfalusi/work/kernel/kernel.org-next-linux-next/scripts/checksyscalls.sh
stdin:1232:2: warning: #warning syscall renameat2 not implemented [-Wcpp]
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi,
I have
Hi,
This might be already fixed.
I have noticed that with linux-next the kernel crashes when trying to use ext4
as rootfs.
Regards,
Peter
---
Peter Ujfalusi (2):
fs: read_write: Check -aio_write in __kernel_write() and vfs_write()
ext4: Fix up the .write callback to use new_sync_write
fs
Other filesystems has been updated but ext4 has been left out and since
ext4 does not provide aio_write callback we have kernel crash in
do_sync_write()
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
fs/ext4/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs
Do similar checks as it has been done in vfs_read for the aio_write
callback.
ext4 for example does not provide aio_write callback causing NULL pointer
dereference in do_sync_write() without this check.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
fs/read_write.c | 8 ++--
1 file
On 04/22/2014 10:05 AM, Peter Ujfalusi wrote:
The new renameat2() system call was only wired up for ARM causing:
obviously I mean that system call was _not_ wired up for ARM causing
I can send the patch again with a fixed up commit message...
CALL
/home/ujfalusi/work/kernel/kernel.org
On 04/15/2014 12:59 AM, Alexandre Belloni wrote:
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
On 04/15/2014 10:14 AM, Simon Horman wrote:
On Tue, Apr 15, 2014 at 10:01:44AM +0300, Peter Ujfalusi wrote:
On 04/15/2014 12:59 AM, Alexandre Belloni wrote:
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 10 ++
1
On 04/14/2014 05:32 PM, Sekhar Nori wrote:
Yes, you can. But as soon as you have other devices using the same priority
(with eDMA3 at least) and asks for a 'long' transfer it can ruin the audio.
During audio playback/capture you execute a long MMC read for example can
introduce a glitch.
On 04/11/2014 01:40 AM, Joel Fernandes wrote:
On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
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
On 04/11/2014 11:17 AM, Sekhar Nori wrote:
On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote:
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
Acked-by: Sekhar Nori nsek...@ti.com
On 04/11/2014 11:56 AM, Sekhar Nori wrote:
On Friday 11 April 2014 02:20 PM, Peter Ujfalusi wrote:
On 04/11/2014 11:17 AM, Sekhar Nori wrote:
On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote:
Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high
priority channels, like
Hi Vinod,
On 04/11/2014 12:42 PM, Vinod Koul wrote:
On Fri, Apr 11, 2014 at 12:38:00PM +0300, Peter Ujfalusi wrote:
On 04/11/2014 11:56 AM, Sekhar Nori wrote:
On Friday 11 April 2014 02:20 PM, Peter Ujfalusi wrote:
On 04/11/2014 11:17 AM, Sekhar Nori wrote:
On Tuesday 01 April 2014 06:36 PM
On 04/11/2014 02:31 PM, Vinod Koul wrote:
I would say that it is channel based config. I don't see the reason why would
one mix different priorities on a configured channel between descriptors.
If not then we can add this in dma_slave_config ?
So adding to the struct for example:
bool
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
Acked-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff
Indicate that the edma dmaengine driver has support for cyclic mode.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@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
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
Acked-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 4 ++--
1 file changed, 2 insertions
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
Acked-by: Joel Fernandes jo...@ti.com
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
Acked-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 18
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
Acked-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/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
Acked-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 11 +--
1 file changed, 5
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
Acked-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 28
Hi Vinod,
On 04/11/2014 03:46 PM, Vinod Koul wrote:
I think the number shouldn't be viewed in absolute terms. If we decide that
(lets
say) 0-7, then any controller should map 0 to lowest and 7 to highest.
For your case you can do this and then intermediate numbers would be medium
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
Acked-by: Joel Fernandes jo
things sorted out I noticed that the debug was
too verbose and the important information was hidden even when the we did not
asked for verbose dmaengine debug.
I have included some debug cleanups for the edma dmaengine driver also.
Regards,
Peter
---
Peter Ujfalusi (10):
platform_data: edma
For later use save the number of queues available for the CC.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@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
On 04/14/2014 03:12 PM, Sekhar Nori wrote:
On Monday 14 April 2014 05:26 PM, Peter Ujfalusi wrote:
Hi Vinod,
On 04/11/2014 03:46 PM, Vinod Koul wrote:
I think the number shouldn't be viewed in absolute terms. If we decide that
(lets
say) 0-7, then any controller should map 0 to lowest
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
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
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
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
501 - 600 of 4568 matches
Mail list logo
