On Mon, Apr 06, 2015 at 01:45:22PM -0500, Nishanth Menon wrote:
On 04/06/2015 10:27 AM, Felipe Balbi wrote:
Hi,
On Mon, Apr 06, 2015 at 10:17:37AM -0500, Nishanth Menon wrote:
On 04/06/2015 10:01 AM, Mark Brown wrote:
On Mon, Apr 06, 2015 at 02:58:29PM +0100, Russell King - ARM Linux
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
---
Hi,
Vinod: is it OK if I send the Documnetation/dmanegine/ update a bit later when
we agree on what form it should be?
Changes since v3:
- Comments from Russell:
- Warnings removed in case of non DT boot when taking the DMA request number
- Reduced the number of channels presented to DMAengine
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 request
line of the DMA controller.
Signed-off-by: Peter Ujfalusi
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
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 | 12 +++-
1 file changed, 11
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 not be requested since the crossbar request number
will no longer match with the sDMA request line.
The direct mapping for virtual
Since the mapping between the hardware request lines and channels has been
removed it no longer make sense to have too many channels.
Set the number of channels to match with the number of logical channels
supported by sDMA.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
DMA routers are transparent devices used to mux DMA requests from
peripherals to DMA controllers. They are used when the SoC integrates more
devices with DMA requests then their controller can handle.
DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request
lines, but in SoC
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
Hi,
On Wed, Apr 08, 2015 at 04:14:47PM +0300, Peter Ujfalusi wrote:
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
Hi,
On Wed, Apr 08, 2015 at 04:14:45PM +0300, Peter Ujfalusi wrote:
DMA routers are transparent devices used to mux DMA requests from
peripherals to DMA controllers. They are used when the SoC integrates more
devices with DMA requests then their controller can handle.
DRA7x is one example of
* Russell King - ARM Linux li...@arm.linux.org.uk [150408 16:09]:
On Tue, Apr 07, 2015 at 08:44:05AM -0700, Tony Lindgren wrote:
And then on top of that patch, we can fix the sefaulting issues with the
following, what do you guys think?
Has this change been tested on OMAP secure parts?
On 04/08/2015 04:23 PM, Nishanth Menon wrote:
Thermal framework may already be ready and cooling policies might
already be functional when we are attempting to register gpio fan as
a cooling device. This can be reproduced by changing probe order in
which registration of various modules are done
From: Grygorii Strashko grygorii.stras...@linaro.org
The interrupt polarity provided in devicetree is used to configure
the interrupt controller(ARM GIC), however, it seems that we have an
inverter at the GIC boundary inside AM57xx which inverts the signal
input from sys_irq external interrupt
Hi Felipe,
On Wed, 8 Apr 2015 11:35:59 -0500 Felipe Balbi ba...@ti.com wrote:
On Mon, Apr 06, 2015 at 01:45:22PM -0500, Nishanth Menon wrote:
On 04/06/2015 10:27 AM, Felipe Balbi wrote:
Hi,
On Mon, Apr 06, 2015 at 10:17:37AM -0500, Nishanth Menon wrote:
On 04/06/2015 10:01 AM,
Thermal framework may already be ready and cooling policies might
already be functional when we are attempting to register gpio fan as
a cooling device. This can be reproduced by changing probe order in
which registration of various modules are done in a system. In such
a case, kernel generates an
On Tue, Apr 07, 2015 at 08:22:08AM -0700, Tony Lindgren wrote:
Works for me. The above needs the following fix folded in to build:
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -532,7 +532,7 @@ __v7_ca9mp_proc_info:
__v7_ca8_proc_info:
.long 0x410fc080
.long
With commit bc078316d86c (ARM: dts: DRA7: Add node for RTC), we now
have AM57xx RTC register itself as alias 0 even before DS1307 or TPS
rtc drivers are loaded up. However, since neither TPS, nor AM57xx RTC
are capable of being backedup by battery, we would like to maintain
the primary rtc as
On Tue, Apr 07, 2015 at 08:44:05AM -0700, Tony Lindgren wrote:
And then on top of that patch, we can fix the sefaulting issues with the
following, what do you guys think?
Has this change been tested on OMAP secure parts?
8
From: Tony Lindgren t...@atomide.com
Date: Tue,
Couple of fixes for MCP79410 RTC on BeagleBoard-X15 platform. This is
not urgent enough for 4.0 material, but will be good to have it on one
of 4.1 rcs. tested on next-20150407:
http://pastebin.ubuntu.com/1033/
(NOTE: I believe DRA7 rtc still needs reset driver to be done before it can be
21 matches
Mail list logo
