On 26.09.2013 15:08, Daniel Mack wrote:
> I've been working on some patches that allow suspending and resuming
> the musb-dsps platform. This was tested for host mode only.
>
> With these patches applied, I can successfully bring an AM335x board
> to suspend with a USB media connected, and access
This makes am35x_pm_ops const and will stub the struct out in case
CONFIG_PM_SLEEP is not set.
Signed-off-by: Daniel Mack
---
I'm resending this series because I've just learned that
SIMPLE_DEV_PM_OPS will stub itself out in case CONFIG_PM_SLEEP is
not set. That makes the the code even smaller.
This removes the DEV_PM_OPS macro and brings this file in line with the
other musb platform drivers.
Signed-off-by: Daniel Mack
---
drivers/usb/musb/ux500.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
inde
This makes bfin_pm_ops const and will stub the struct out in case
CONFIG_PM_SLEEP is not set.
Signed-off-by: Daniel Mack
---
drivers/usb/musb/blackfin.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
in
On 30.09.2013 18:25, Felipe Balbi wrote:
> On Fri, Sep 27, 2013 at 08:47:10PM +0200, Daniel Mack wrote:
>> On 25.09.2013 15:48, Felipe Balbi wrote:
>>> On Tue, Sep 24, 2013 at 08:57:08AM +0200, Daniel Mack wrote:
On 23.09.2013 23:20, Felipe Balbi wrote:
> On Sun, Sep 22, 2013 at 01:46:58PM
Hi,
On Fri, Sep 27, 2013 at 08:47:10PM +0200, Daniel Mack wrote:
> On 25.09.2013 15:48, Felipe Balbi wrote:
> > On Tue, Sep 24, 2013 at 08:57:08AM +0200, Daniel Mack wrote:
> >> On 23.09.2013 23:20, Felipe Balbi wrote:
> >>> On Sun, Sep 22, 2013 at 01:46:58PM +0200, Daniel Mack wrote:
> >>
>
On 09/29/2013 10:12 PM, Paul Walmsley wrote:
> Hi
>
> On Fri, 27 Sep 2013, Suman Anna wrote:
>
>> Paul,
>> The hwmod data patches needs to be merged only after the respective DT
>> node patches are merged, without which the hwmod entry will not have a
>> base address while enabling and idling (us
From: "Mark A. Greer"
Add the generic AM33XX AES module's device tree data and
enable it for the am335x-evm, am335x-evmsk, and am335x-bone
platforms. Also add Documentation file describing the data
for the AES module.
[jo...@ti.com: Dropped interrupt-parent propert]
CC: Paul Walmsley
Signed-o
AM437x SoC has AES module similar to the one on OMAP4.
Add DT node for the same.
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/am4372.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 0fe393a..7e9ff75 100644
From: "Mark A. Greer"
Add the generic AM33XX SHAM module's device tree data and
enable it for the am335x-evm, am335x-evmsk, and am335x-bone
platforms. Also add Documentation file describing the data
for the SHAM module.
[jo...@ti.com: Dropped interrupt-parrent property]
CC: Paul Walmsley
Signe
AM437x SoC has a DES3DES module similar to the one on OMAP4.
Add DT node for the same.
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/am4372.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 7e9ff75..a403172 1
From: Darren Etheridge
Enable the hdmi output and the LCD Controller on BeagleBone
Black. Also configure the correct pinmux for output of
video data from the SoC to the HDMI encoder.
Signed-off-by: Darren Etheridge
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/am335x-boneblack.dts | 48
From: Benoit Parrot
Add LCDC device node in DT for am33xx
Add LCDC and Panel info in DT for am335x-evm
Changes:
- remove redundant/unnecessary SoC specific setting in the board dts
- resolved conflicts on for_3.13/dts
Signed-off-by: Benoit Parrot
Signed-off-by: Joel Fernandes
---
arch/arm/bo
Following series is a collection of dts patches for the below features:
crypto:
aes, sha on am335x
aes, des on am437x
aes, des on omap4
display:
beaglebone black HDMI
am335x-evm panel
Series is based on Benoit Cousson's for_3.13/dts branch (commit sha 45646cd)
Available at: g...@github.com:
OMAP4 has an AES module that uses the omap-aes crypto driver.
Add DT entries for the same.
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/omap4.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 45708e1..16a44d
OMAP4 has an DES3DES module that uses the omap-des crypto driver.
Add DT entries for the same.
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/omap4.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 16a44d6..6
Signed-off-by: Joel Fernandes
---
arch/arm/boot/dts/am33xx.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 0daa1b2..d7be90a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@
On 09/30/2013 08:59 AM, Sricharan R wrote:
> Some socs have a large number of interrupts requests to service
> the needs of its many peripherals and subsystems. All of the interrupt
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to the controllers a
On Monday 30 September 2013 07:52 PM, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, Sricharan R wrote:
>>> In some socs the gic can be preceded by a crossbar IP which
>>> routes the peripheral interrupts to the gic inputs. The peripheral
3.3V fixed regulator does not belong to TPS node - as a result
the fixed regulator is never probed and MMC is continually deferred due
to lack of regulator.
Move the fixed regulator to be at root of platform.
Cc: Joel Fernandes
Cc: Sekhar Nori
Cc: Koen Kooi
Signed-off-by: Nishanth Menon
Test
On 30/09/13 15:22, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, Sricharan R wrote:
>>> In some socs the gic can be preceded by a crossbar IP which
>>> routes the peripheral interrupts to the gic inputs. The peripheral
>>> interrupts are
On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
> On 30/09/13 14:59, Sricharan R wrote:
>> In some socs the gic can be preceded by a crossbar IP which
>> routes the peripheral interrupts to the gic inputs. The peripheral
>> interrupts are associated with a fixed crossbar input line and th
On Monday 30 September 2013 09:59 AM, Sricharan R wrote:
> Some socs have a large number of interrupts requests to service
> the needs of its many peripherals and subsystems. All of the interrupt
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to the
On 30/09/13 14:59, Sricharan R wrote:
> In some socs the gic can be preceded by a crossbar IP which
> routes the peripheral interrupts to the gic inputs. The peripheral
> interrupts are associated with a fixed crossbar input line and the
> crossbar routes that to one of the free gic input line.
>
Enable the crossbar IP support for DRA7xx soc.
Cc: Santosh Shilimkar
Cc: Rajendra Nayak
Cc: Tony Lindgren
Signed-off-by: Sricharan R
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/omap4-common.c |4
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-om
In some socs the gic can be preceded by a crossbar IP which
routes the peripheral interrupts to the gic inputs. The peripheral
interrupts are associated with a fixed crossbar input line and the
crossbar routes that to one of the free gic input line.
The DT entries for peripherals provides the fixe
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the
interrupt lines from the subsystems are not needed at the same
time, so they have to be muxed to the irq-controller appropriately.
In such places a interrupt controllers are
Now with the crossbar IP in picture, the peripherals do not have the
fixed interrupt lines. Instead they rely on the crossbar irqchip to
allocate and map a free interrupt line to its crossbar input. So replacing
all the peripheral interrupt numbers with its fixed crossbar input lines.
Cc: Benoit C
The wakeup gen mask/unmask callback uses the irq element of the
irq_data to setup. The irq is the linux virtual irq number and
is same as the hardware irq number only when the parent irqchip
is setup as a legacy domain. When it is used as a linear domain,
the virtual irqs are allocated dynamically
Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the interrupt
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt controller
__initdata tag should be placed between the variable name and equal
sign for the variable to be placed in the intended .init.data section.
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Kyungmin Park
---
arch/arm/mach-omap1/gpio15xx.c | 8
arch/arm/mach-omap1/gpio16xx.c | 22
Hi Paul,
On Monday 30 September 2013 03:57 PM, Paul Walmsley wrote:
> On Thu, 26 Sep 2013, Afzal Mohammed wrote:
>> From: Ambresh K
>>
>> Add the data file to describe all power domains in AM43x SoC.
>> OMAP4 powerdomain operations is being reused here.
>>
>> Signed-off-by: Ambresh K
>> Signed-
On 09/19/2013 11:44 PM, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King
Acked-by: Hans Verkuil
Regards,
H
Hi Paul,
On Monday 30 September 2013 04:39 PM, Paul Walmsley wrote:
> On Mon, 30 Sep 2013, Afzal Mohammed wrote:
>>> The references to "wkup_pwrdm" on some of these clockdomains don't
>>> look right to me. For example, this clockdomain is listed as being in
>>> AM43XX_CM_WKUP_INST, but its enc
Hi
On Mon, 30 Sep 2013, Afzal Mohammed wrote:
> > The references to "wkup_pwrdm" on some of these clockdomains don't
> > look right to me. For example, this clockdomain is listed as being in
> > AM43XX_CM_WKUP_INST, but its enclosing powerdomain is listed as being in
> > AM43XX_PRM_WKUP_INST.
Hi Paul,
On Monday 30 September 2013 03:01 PM, Paul Walmsley wrote:
> On Thu, 26 Sep 2013, Afzal Mohammed wrote:
>> From: Ambresh K
>>
>> Add the data file to describe clock domains in AM43x SoC.
>> OMAP4 clockdomain operations is being reused here.
>>
>> Signed-off-by: Ambresh K
>> Signed-off-
On Thu, 26 Sep 2013, Afzal Mohammed wrote:
> From: Ambresh K
>
> Add the data file to describe all power domains in AM43x SoC.
> OMAP4 powerdomain operations is being reused here.
>
> Signed-off-by: Ambresh K
> Signed-off-by: Afzal Mohammed
...
> --- /dev/null
> +++ b/arch/arm/mach-omap2/po
On Mon, 30 Sep 2013, Paul Walmsley wrote:
> The references to "wkup_pwrdm" on some of these clockdomains don't
> look right to me. For example, this clockdomain is listed as being in
> AM43XX_CM_WKUP_INST, but its enclosing powerdomain is listed as being in
> AM43XX_PRM_WKUP_INST. Looks to me
Hi
On Thu, 26 Sep 2013, Afzal Mohammed wrote:
> From: Ambresh K
>
> Add the data file to describe clock domains in AM43x SoC.
> OMAP4 clockdomain operations is being reused here.
>
> Signed-off-by: Ambresh K
> Signed-off-by: Afzal Mohammed
> ---
> arch/arm/mach-omap2/clockdomain.h
On Monday 30 September 2013 02:45 PM, Sebastian Andrzej Siewior wrote:
> with DRA7xx and without OMAP5 selected we get
> |arch/arm/mach-omap2/built-in.o:(.arch.info.init+0x40): undefined reference
> to `omap5_realtime_timer_init'
> |make[1]: *** [vmlinux] Error 1
>
> since ARM: DRA7: board-generic
with DRA7xx and without OMAP5 selected we get
|arch/arm/mach-omap2/built-in.o:(.arch.info.init+0x40): undefined reference to
`omap5_realtime_timer_init'
|make[1]: *** [vmlinux] Error 1
since ARM: DRA7: board-generic: Add basic DT support ("439bf39e").
Cc: Tony Lindgren
Cc: R Sricharan
Cc: Raje
Hi Paul,
On Monday 30 September 2013 08:53 AM, Paul Walmsley wrote:
> On Thu, 26 Sep 2013, Afzal Mohammed wrote:
>> Most of the AM43x CM reg address offsets are with MSB bit '1' (on
>> 16-bit value) leading to arithmetic miscalculations while calculating
>> CLOCK ENABLE register's address because
On 27/09/13 14:24, Tero Kristo wrote:
>> Tero, can you queue this patch? Or who should handle this?
>
> I can't queue anything as I don't have maintainership on any of this
> stuff. Paul / Tony should go with this.
Well, I mainly meant preparing a patch with proper description and
sending to rel
44 matches
Mail list logo
