Enable PMIC for beaglebone similar to commit 7a5c6065669c ("ARM:
OMAP2+: omap2plus_defconfig: Add tps65217 support") - this allows
multi_v7_defconfig to boot up on older beaglebone platforms.
Signed-off-by: Nishanth Menon
---
arch/arm/configs/multi_v7_defconfig |2 ++
1 file changed, 2 inser
Enable PMIC for AM437x platforms such as AM437x-sk similar to commit
a186cf10da84 ("ARM: omap2plus_defconfig: enable TPS65218 configs").
This allows multi_v7_defconfig to boot up on AM437x-sk platform.
Signed-off-by: Nishanth Menon
---
arch/arm/configs/multi_v7_defconfig |2 ++
1 file change
ABB and PBIAS are internal LDO control regulators that are needed for
maintaining proper functionality of OMAP architecture SoCs. Enable the
same.
Signed-off-by: Nishanth Menon
---
arch/arm/configs/multi_v7_defconfig |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi
Hi,
As of next-20150409 tag, the following platforms (I have access
to) report failures for AM437x-sk and legacy beaglebone (white).
omap2plus_defconfig boots up fine on these platforms.
So, the basic minimum stuff I could pickup to fix up beaglebone-white
and am437x-sk.
This series is still
* Peter Ujfalusi [150409 12:07]:
> On 04/09/2015 10:01 PM, Tony Lindgren wrote:
> > * Peter Ujfalusi [150409 11:55]:
> >> On 04/09/2015 06:18 PM, Tony Lindgren wrote:
> >>> * Peter Ujfalusi [150409 02:37]:
> The sDMA requests are routed through the DMA crossbar and without the
> crossb
On 04/09/2015 10:01 PM, Tony Lindgren wrote:
> * Peter Ujfalusi [150409 11:55]:
>> On 04/09/2015 06:18 PM, Tony Lindgren wrote:
>>> * Peter Ujfalusi [150409 02:37]:
The sDMA requests are routed through the DMA crossbar and without the
crossbar only peripherals using DMA request 0-127 ca
* Peter Ujfalusi [150409 11:55]:
> On 04/09/2015 06:18 PM, Tony Lindgren wrote:
> > * Peter Ujfalusi [150409 02:37]:
> >> The sDMA requests are routed through the DMA crossbar and without the
> >> crossbar only peripherals using DMA request 0-127 can be used.
> >
> > I assume this can be merged
On 04/09/2015 06:18 PM, Tony Lindgren wrote:
> * Peter Ujfalusi [150409 02:37]:
>> The sDMA requests are routed through the DMA crossbar and without the
>> crossbar only peripherals using DMA request 0-127 can be used.
>
> I assume this can be merged separately from the driver
> changes?
Unfortu
* Tony Lindgren [150331 09:56]:
> * Kishon Vijay Abraham I [150331 09:37]:
> > Hi Tony,
> >
> > On Thursday 26 March 2015 09:34 PM, Tony Lindgren wrote:
> > >* Matthijs van Duin [150326 00:02]:
> > >>On 26 March 2015 at 00:36, Kishon Vijay Abraham I wrote:
> > >>>Let me know if you find any pr
The new AM437x SK Beta boards have removed the
large capacitors on the gpio-matrix column lines
which means we can reduce col-scan-delay-us to 5us
without loosing functionality.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am437x-sk-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion
AM437x Starter Kit uses a NewHaven Display module with
a 4.3" display and EDT FT5306 touchscreen
On that module's new revision, NewHave decided to change
the pinout on the 6 pin flat-pcb touchscreen connector so
that instead of having WAKE pin, we now have RESETn.
The new display module is availa
On Thu, Apr 09, 2015 at 08:09:19AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux [150409 06:49]:
> > On Thu, Apr 09, 2015 at 12:06:58AM +0100, Russell King - ARM Linux wrote:
> > > On Tue, Apr 07, 2015 at 08:22:08AM -0700, Tony Lindgren wrote:
> > > > Works for me. The above needs the f
* Peter Ujfalusi [150409 02:37]:
> The sDMA requests are routed through the DMA crossbar and without the
> crossbar only peripherals using DMA request 0-127 can be used.
I assume this can be merged separately from the driver
changes?
Otherwise we'll have the same kind of "flag day" mess with
the
* Matthijs van Duin [150404 21:26]:
> Hi all,
>
> To my surprise, the am335x clock tree (am33xx-clocks.dtsi) currently
> lists the functional clock of the AES accelerator and other crypto
> modules to be the (max 26 MHz) main osc. This struck me as rather
> unlikely, since the AES module is clock
* Russell King - ARM Linux [150409 06:49]:
> On Thu, Apr 09, 2015 at 12:06:58AM +0100, Russell King - ARM Linux wrote:
> > 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
On Thu, Apr 09, 2015 at 04:17:26PM +0200, Yegor Yefremov wrote:
> On Thu, Apr 9, 2015 at 3:37 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Apr 09, 2015 at 10:42:15AM +0200, Yegor Yefremov wrote:
> >> I see this during the boot:
> >>
> >> platform musb-hdrc.1.auto: Driver musb-hdrc requests prob
On Thu, Apr 9, 2015 at 3:37 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Apr 09, 2015 at 10:42:15AM +0200, Yegor Yefremov wrote:
>> I see this during the boot:
>>
>> platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
>> [ cut here ]
>> WARNING: CPU: 0 PID: 1 a
On Thu, Apr 09, 2015 at 12:06:58AM +0100, Russell King - ARM Linux wrote:
> 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,
Hi,
On Thu, Apr 09, 2015 at 10:42:15AM +0200, Yegor Yefremov wrote:
> I see this during the boot:
>
> platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at drivers/dma/dmaengine.c:863
> dma_async_device_register+0x2a
On Thursday 09 April 2015 14:43:59 Javier Martinez Canillas wrote:
> Hello Pavel,
>
> >
> > diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
> > index d703636..7107ac2 100644
> > --- a/drivers/media/i2c/adp1653.c
> > +++ b/drivers/media/i2c/adp1653.c
> > @@ -35,8 +35,8 @@
> >
Hello Pavel,
On Thu, Apr 9, 2015 at 2:31 PM, Pavel Machek wrote:
> Fix includes according to Sebastian.
>
> Signed-off-by: Pavel Machek
>
> ---
>
> On Thu 2015-04-09 14:19:14, Sebastian Reichel wrote:
>> On Thu, Apr 09, 2015 at 01:29:43PM +0200, Pavel Machek wrote:
>> > On Thu 2015-04-09 11:10:1
Fix includes according to Sebastian.
Signed-off-by: Pavel Machek
---
On Thu 2015-04-09 14:19:14, Sebastian Reichel wrote:
> On Thu, Apr 09, 2015 at 01:29:43PM +0200, Pavel Machek wrote:
> > On Thu 2015-04-09 11:10:17, Sebastian Reichel wrote:
> > > On Thu, Apr 09, 2015 at 09:42:38AM +0200, Pave
On Thu, Apr 09, 2015 at 01:29:43PM +0200, Pavel Machek wrote:
> On Thu 2015-04-09 11:10:17, Sebastian Reichel wrote:
> > On Thu, Apr 09, 2015 at 09:42:38AM +0200, Pavel Machek wrote:
> > > [...]
> > > +#include
> > > +#include
> > > [...]
> >
> > This should probably be
> >
> > #include
> > #i
On Thu 2015-04-09 11:10:17, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Apr 09, 2015 at 09:42:38AM +0200, Pavel Machek wrote:
> > [...]
> > +#include
> > +#include
> > [...]
>
> This should probably be
>
> #include
> #include
And I thought people would only bikesched paint on the
Documentati
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
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
Vinod: is it OK if I send the Documnetation/dmanegine/ update a bit later when
I have finished it?
Changes since v4:
- Comments from Maxime Ripard addressed:
- long line fixed in of-dma.c
- node leaks has been fixed in ti-dma-crossbar
- Using devm_ioremap_resource() in ti-dma-crossbar
- u16 ca
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(-)
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
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 167dbaf6
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
---
drivers/dma/omap-dma.c | 2 +-
1 file
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(-)
On 03/04/15 21:01, Olof Johansson wrote:
> On Mon, Mar 23, 2015 at 12:32:38PM +0200, Roger Quadros wrote:
>> Hi Arnd, Hi Olof,
>>
>> Based on Tony's request I will be sending you pull requests for OMAP-GPMC
>> driver
>> hence forth. I've sent this earlier on the 9th of March but had missed to
>>
Hi,
On Thu, Apr 09, 2015 at 09:42:38AM +0200, Pavel Machek wrote:
> [...]
> +#include
> +#include
> [...]
This should probably be
#include
#include
-- Sebastian
signature.asc
Description: Digital signature
I see this during the boot:
platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/dma/dmaengine.c:863
dma_async_device_register+0x2a8/0x4d8()
this driver doesn't support generic slave capabilities reporting
Module
On 04/08/2015 06:42 PM, Maxime Ripard wrote:
>> ---
>> Documentation/devicetree/bindings/dma/dma.txt | 28 +
>> drivers/dma/dmaengine.c | 7 +++
>> drivers/dma/of-dma.c | 86
>> +++
>> include/linux/dmaengine.h
>> +static inline void ti_dma_xbar_write(void __iomem *iomem, int xbar, int val)
>> +{
>> +writew_relaxed(val, iomem + (xbar * 2));
>
> Silently casting val (an integer) to a u16 isn't really nice I
> guess. At least you could be upfront about it in the prototype.
The value in val is guaranti
Add device tree support for adp1653 flash LED driver.
Signed-off-by: Pavel Machek
---
Second part of a patch after documentation was merged.
Please apply,
Pavel
diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
inde
39 matches
Mail list logo
