On Friday 27 March 2015, Peter Ujfalusi wrote:
> +Required property:
> +- dma-device: phandle of the DMA controller. The router is modifying
> + the DMA requests for this controller.
This property seems rather specific to the case at hand, I would expect that
one mig
* Nishanth Menon [150327 13:35]:
> On 03/26/2015 12:35 PM, Tony Lindgren wrote:
> > * Nishanth Menon [150325 16:32]:
> >> On 03/25/2015 06:25 PM, Praneeth Bajjuri wrote:
> >>> ARM errata 798181 is applicable for OMAP5/DRA7 based devices. So enable
> >>> the same in the build.
> >>>
> >>> DRA7xx i
On 03/26/2015 12:35 PM, Tony Lindgren wrote:
> * Nishanth Menon [150325 16:32]:
>> On 03/25/2015 06:25 PM, Praneeth Bajjuri wrote:
>>> ARM errata 798181 is applicable for OMAP5/DRA7 based devices. So enable
>>> the same in the build.
>>>
>>> DRA7xx is based on Cortex-A15 r2p2 revision.
>>>
>>> ARM
On Fri, Mar 27, 2015 at 02:26:51PM +0200, Peter Ujfalusi wrote:
> + if (!pdev->dev.of_node || of_property_read_u32(pdev->dev.of_node,
> +"dma-requests",
> +&od->dma_requests)) {
> +
On Fri, Mar 27, 2015 at 02:26:52PM +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 not be requested since the crossbar request number
> will no l
* Paul Walmsley [150327 03:09]:
> Hi Tony,
>
> The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
>
> Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
> ta
On 27 March 2015 at 03:06, Will Deacon wrote:
> On Fri, Mar 27, 2015 at 12:25:54AM +, Simon Horman wrote:
>> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
>> > On 26 March 2015 at 06:36, Will Deacon wrote:
>> > > On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote:
>>
On 03/26/2015 07:30 PM, Tony Lindgren wrote:
* Tero Kristo [150326 03:55]:
On 03/26/2015 09:24 AM, Tero Kristo wrote:
On 03/26/2015 01:17 AM, Tony Lindgren wrote:
* Tero Kristo [150325 08:12]:
Splits the clock provider init out of the PRM driver and moves it to
clock driver. This is needed
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
---
drivers/dma/Kconfig |
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 leve
Instead of magic numbers in the code, use define for number of logical DMA
channels and DMA requests.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/omap-dma.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 7dd6dd12
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
---
drivers/dma/omap-dma.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
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 c
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
---
.../devic
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
---
arch/arm/boot/dts/dra7.dtsi | 57 ++---
1 file changed, 33 insertions(+), 24 deletions(-)
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 v2:
- not using regmap for the TI crossbar driver.
Changes since v1:
- Comments from Russell King and Paul Bolle addressed:
- Use the added defined in the omap-d
On 03/26/2015 05:32 PM, Vinod Koul wrote:
>> I have added the DT binding document since this series adds support for
>> routers for platforms booting with DT:
>>
>> Documentation/devicetree/bindings/dma/dma.txt | 28
> I meant the update to Documnetation/dmanegine/ for routers :)
I see. In
On Fri, Mar 27, 2015 at 10:06:12AM +, Will Deacon wrote:
> On Fri, Mar 27, 2015 at 12:25:54AM +, Simon Horman wrote:
> > On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> > > On 26 March 2015 at 06:36, Will Deacon wrote:
> > > > On Thu, Mar 26, 2015 at 12:39:39AM +, Simon
In omap_dma_start_desc the vdesc->node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the
From: Petr Kulhavy
If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan->edesc was not freed.
This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (e
On 20 March 2015 at 15:53, Andreas Fenkart wrote:
> board-rx51 has no card detect pin in the mmc slot, but can detect that
> the (cell-phone) cover has been removed and the card is accessible.
> The semantics between cover/card detect differ, the gpio on the slot
> informs you after the card has b
On 03/23/2015 02:18 PM, grygorii.stras...@linaro.org wrote:
From: Grygorii Strashko
Now in TI OMAP GPIO driver there are a lot of places where
System GPIO number calculated and then converted to GPIO offset.
What is worse is that in many place such conversation performed twice
or even three tim
On Mon, Mar 23, 2015 at 1:18 PM, wrote:
> From: Grygorii Strashko
>
> Now OMAP GPIO driver prepared for GPIO_INDEX() macro removing.
> Do It ;)
>
> Tested-by: Tony Lindgren
> Tested-by: Aaro Koskinen
> Acked-by: Santosh Shilimkar
> Acked-by: Javier Martinez Canillas
> Signed-off-by: Grygori
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony,
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
tags/for
On Mon, Mar 23, 2015 at 1:18 PM, wrote:
> From: Grygorii Strashko
>
> Now OMAP GPIO driver prepared for omap_irq_to_gpio() removing.
> Do it ;)
>
> Tested-by: Tony Lindgren
> Tested-by: Aaro Koskinen
> Acked-by: Santosh Shilimkar
> Acked-by: Javier Martinez Canillas
> Signed-off-by: Grygori
On Mon, Mar 23, 2015 at 1:18 PM, wrote:
> From: Grygorii Strashko
>
> Now OMAP GPIO driver prepared for GPIO_BIT() macro removing.
> Do it ;)
>
> Tested-by: Tony Lindgren
> Tested-by: Aaro Koskinen
> Acked-by: Santosh Shilimkar
> Acked-by: Javier Martinez Canillas
> Signed-off-by: Grygorii
On Mon, Mar 23, 2015 at 1:18 PM, wrote:
> From: Grygorii Strashko
>
> Convert GPIO IRQ functions to use GPIO offset instead of system
> GPIO numbers. This allows to drop unneeded conversations between
> system GPIO <-> GPIO offset which are done in many places and
> many times.
> It is safe to
On Mon, Mar 23, 2015 at 1:18 PM, wrote:
> From: Grygorii Strashko
>
> The 'gpio' parameter isn't needed any more as it
> duplicates 'offset' parameter, so drop it.
>
> Tested-by: Tony Lindgren
> Tested-by: Aaro Koskinen
> Acked-by: Santosh Shilimkar
> Acked-by: Javier Martinez Canillas
> Si
On Fri, Mar 27, 2015 at 12:25:54AM +, Simon Horman wrote:
> On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote:
> > On 26 March 2015 at 06:36, Will Deacon wrote:
> > > On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote:
> > >> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishan
On Mon, Mar 23, 2015 at 1:18 PM, wrote:
> From: Grygorii Strashko
>
> Convert debounce functions to use GPIO offset instead of system
> GPIO numbers. This allows to drop unneeded conversations between
> system GPIO <-> GPIO offset which are done in many places and
> many times.
> It is safe to
On Mon, Mar 23, 2015 at 1:18 PM, wrote:
> From: Grygorii Strashko
>
> Both functions omap_set_gpio_dataout_reg() and
> omap_set_gpio_dataout_mask() accept GPIO offset
> as 'gpio' input parameter, so rename it to 'offset' and
> drop usage of GPIO_BIT() macro.
>
> Tested-by: Tony Lindgren
> Test
On Mon, Mar 23, 2015 at 1:18 PM, wrote:
> From: Grygorii Strashko
>
> Convert omap_gpio_is_input() to use GPIO offset instead of mask and,
> in such way, make code simpler and remove few lines of code.
>
> Tested-by: Tony Lindgren
> Tested-by: Aaro Koskinen
> Acked-by: Santosh Shilimkar
> Ac
On 25 March 2015 at 22:43, NeilBrown wrote:
> Only omap_hsmmc uses enable and disable, and this seems
> to be largely for historical reasons and is no longer
> necessary.
>
> I have tested these patches with an OMAP3 with an
> uSD card on mmc0 and a wifi SDIO device on mmc1.
>
> NeilBrown
>
>
> --
The serializer direction definitions runs from 1 to 2, which does not
suite the purpose. The substream->stream is perfect for the purpose
and should have been used from the beginning.
Signed-off-by: Jyri Sarha
---
sound/soc/davinci/davinci-mcasp.c | 4 ++--
1 file changed, 2 insertions(+), 2 del
Bandgap Temperature read Dtemp can be corrupted
DESCRIPTION
Read accesses to registers listed below can be corrupted due to
incorrect resynchronization between
clock domains.
Read access to registers below can be corrupted :
• CTRL_CORE_DTEMP_MPU/GPU/CORE/
On Friday 27 March 2015 11:32 AM, Keerthy wrote:
On Tuesday 24 March 2015 01:09 AM, Nishanth Menon wrote:
From: Keerthy
Add bandgap and related thermal nodes. The patch adds 5 thermal
sensors. Only one cooling device for mpu as of now. The sensors are
the exact same on both dra72 and dra7.
On 03/22, Fabian Frederick wrote:
>
>
> > On 18 March 2015 at 15:15 Michael Turquette wrote:
> >
> >
> > Quoting Fabian Frederick (2015-03-16 12:59:06)
> > > of_device_id is always used as const.
> > > (See driver.of_match_table and open firmware functions)
> > >
> > > Signed-off-by: Fabian Fred
37 matches
Mail list logo