Hi Paul, Benoit, Tony,
This series adds PRCM support (except clock tree) for AM43x SoC's.
Please consider this for inclusion in the coming merge window.
Patch 02/11 ARM: OMAP2+: hwmod: AM335x/AM43x: move common data may
not reach mailing lists due to bigger size, this series is also present
From: Ankur Kishore a-kish...@ti.com
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 cm_inst field was a type of
const s16, so make it const u16.
Also modify relevant
Most of IP's in AM335x is present on AM43x and so in those cases both
will use same hwmod database (except for a few cases where clock related
details differ), but there is difference w.r.t register offset between
these. Update register offsets at runtime based on the SoC detected to
help in
Hwmod common to AM43x and AM335x has register offsets different. It is
now updated based on SoC detection at run time, hence remove statically
initialized ones.
Signed-off-by: Afzal Mohammed af...@ti.com
---
.../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 57 --
1 file
Add AM43x CMINST, CDOFFS, RM_RSTST RM_RSTCTRL definitions - minimal
ones that would be used.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/prcm43xx.h | 141 +
1 file changed, 141 insertions(+)
create mode 100644
Add hwmod support for IP's that are present in AM43x, but not in AM335x.
AM43x additional ones added here are,
1. synctimer
2. timer8-11
3. ehrpwm3-5
4. spi2-4
5. gpio4-5
AM43x pruss interconnect which is different as compared to AM335x, has
been taken care.
And register offsets for same hwmod's
From: Ambresh K ambr...@ti.com
Add the data file to describe clock domains in AM43x SoC.
OMAP4 clockdomain operations is being reused here.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/clockdomain.h | 2 +
From: Ambresh K ambr...@ti.com
Add the data file to describe all power domains in AM43x SoC.
OMAP4 powerdomain operations is being reused here.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/powerdomain.h | 1 +
Reuse OMAP4 operations on AM43x.
Context related ops are not used on AM43x, as this would not add value
when using DT and AM43x is DT only boot. This additionally helps not to
add context register offset for each hwmod.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed
Build AM43x power domain, clock domain and hwmod data.
Many of AM43x IP's and interconnects are similar as that in AM335x,
hence AM335x hwmod data is being reused with necessary changes.
Earlier the plan was to reuse AM335x specific PRCM code, but as AM43x
PRCM register layout is much similar to
From: Ambresh K ambr...@ti.com
Initialise AM43x HWMOD, powerdomains and clockdomains.
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/io.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/io.c
On 09/27/2013 08:08 PM, Kevin Hilman wrote:
Javier Martinez Canillas javier.marti...@collabora.co.uk writes:
The GPIO OMAP controller pins can be used as IRQ and GPIO
independently so is necessary to keep track GPIO pins and
IRQ lines usage separately to make sure that the bank will
always
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
Then for the SDIO with device tree, take a look at the following
patches:
[PATCH 0/3] WLAN support for
+ more DT maintainers folks
Hi all,
I know this is mostly boring user space code, but I was expecting a
little bit of comments about at least the bindings syntax:-(
I'd like to know if this is the right direction and if it worth pursuing
in that direction.
The idea was to have at least
Hi Suman,
Apologies for replying to a subthread, due to an earlier mistake on my
part I don't have the original to hand.
On Fri, Sep 27, 2013 at 05:04:22PM +0100, Kumar Gala wrote:
On Sep 17, 2013, at 2:30 PM, Suman Anna wrote:
All the platform-specific hwlock driver implementations need
Hi Suman,
On Fri, Sep 27, 2013 at 05:06:38PM +0100, Kumar Gala wrote:
On Sep 17, 2013, at 2:30 PM, Suman Anna wrote:
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes
Hi Arend,
On 10/01/2013 11:05 AM, Arend van Spriel wrote:
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
Then for the SDIO with device tree, take a look
On 10/01/2013 12:49 PM, Roger Quadros wrote:
Hi Arend,
On 10/01/2013 11:05 AM, Arend van Spriel wrote:
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
On 10/01/2013 11:53 AM, Roger Quadros wrote:
On 10/01/2013 12:49 PM, Roger Quadros wrote:
Hi Arend,
On 10/01/2013 11:05 AM, Arend van Spriel wrote:
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
On 07/19/2013 01:36 PM, Arend van Spriel wrote:
Hi,
On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
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
On Tue, Oct 1, 2013 at 9:34 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Linus,
Since this patch-set doesn't cause any regression and fix a long standing
issue
on OMAP, do you think that it would be possible to include on the -rc series
as
a bugfix or do you prefer
Hi,
On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote:
On 10/01/2013 11:53 AM, Roger Quadros wrote:
On 10/01/2013 12:49 PM, Roger Quadros wrote:
Hi Arend,
On 10/01/2013 11:05 AM, Arend van Spriel wrote:
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM,
Hi, I am sorry for delay answer.
On Thu, 2013-09-26 at 10:46 +0100, Mark Rutland wrote:
On Mon, Sep 23, 2013 at 08:31:48PM +0100, Felipe Balbi wrote:
Hi,
On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core
Hi,
On Mon, 2013-09-23 at 14:31 -0500, Felipe Balbi wrote:
Hi,
On Tue, Aug 20, 2013 at 12:56:03PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration
Hi,
On Mon, 2013-09-23 at 16:03 -0600, Stephen Warren wrote:
On 09/23/2013 01:32 PM, Felipe Balbi wrote:
Hi,
On Wed, Aug 21, 2013 at 04:29:44PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS)
Hi,
On Mon, 2013-09-23 at 14:32 -0500, Felipe Balbi wrote:
Hi,
On Wed, Aug 21, 2013 at 04:29:44PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration
On 10/01/2013 01:53 PM, Arend van Spriel wrote:
On 10/01/2013 11:53 AM, Roger Quadros wrote:
On 10/01/2013 12:49 PM, Roger Quadros wrote:
Hi Arend,
On 10/01/2013 11:05 AM, Arend van Spriel wrote:
On 07/19/2013 12:57 PM, Arend van Spriel wrote:
On 07/19/2013 12:49 PM, Roger Quadros wrote:
Hi Sebastian,
sorry for the long delay, I got distracted by other things.
On 26.09.2013 10:26, Sebastian Andrzej Siewior wrote:
* Daniel Mack | 2013-09-22 16:50:03 [+0200]:
cdd-cd and cdd-descs_phys are allocated DESCS_AREAS times from
init_descs() and freed as often from purge_descs().
On 10/01/2013 03:06 AM, Benoit Cousson wrote:
+ more DT maintainers folks
Hi all,
I know this is mostly boring user space code, but I was expecting a
little bit of comments about at least the bindings syntax:-(
I'd like to know if this is the right direction and if it worth pursuing
in
Hi Roger,
It has been a while, but I would like to pickup this thread. We have a couple
of pandaboards used as test setup. These have an SDIO adapter hooked up to
expansion connector A using MMC2. I have attached the patch file (just ignore
platform_data stuff). Now on one board it works, but
With active users over suspend/resume cycles, it turns out that
more registers, in particular DMA_TDFDQ and RXHPCRA0, have to be
restored on resume.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/dma/cppi41.c | 15 +++
1 file changed, 15 insertions(+)
diff --git
Use cppi41_pop_desc() when appropriate instead of open-coding the same
functionality again. That makes the code more readable. The function has
to be moved some lines up for this change.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/dma/cppi41.c | 23 +++
1 file
While my first series makes the cppi41 driver survive suspend/resume
cycles as long as users are fully removed and added back after resume,
here are some more patches which make it all work completely.
Patch #1 restores more registers on resume time.
Patch #2 is a cosmetic cleanup that emerged
In cppi41_tear_down_chan(), bail out earlier in case td_seen is unset
instead of popping another descriptor when td_desc_seen is also unset.
My system ran into WARN() condition multiple times when
cppi41_tear_down_chan() was called for channels that had all of
td_queued, td_seen and td_seen set
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 it again after
resume.
This works for both PIO
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.
The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.
Signed-off-by:
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.
Signed-off-by: Daniel Mack zon...@gmail.com
---
rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_dsps.c | 4
1 file changed, 4 insertions(+)
diff --git
musb_port_reset() sleeps, so we can't call it from atomic context. It
is, however, called from places inside musb_hub_control() while
musb-lock is held, which leads to a scheduling while atomic warning.
Fix this by moving the logic into a worker, and call it where the
function was previously
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_host.c| 2 ++
drivers/usb/musb/musb_host.h| 2 ++
On 10/01/2013 06:13 AM, Sricharan R wrote:
Hi,
On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
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
This patch adds support for edma driver.
I know the intermediate code in arch/arm/common is going to be purged
eventually when the real dma-engine driver lands, so I don't know
whether it's reasonable to include my patch after all. It might just
server as template for the suspend/resume functions
On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote:
On 10/01/2013 06:13 AM, Sricharan R wrote:
Hi,
On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
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
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams.
The code was shamelessly taken from an ancient BSP tree.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/common/edma.c | 133
Hi,
On Thu, Sep 26, 2013 at 02:00:59AM +0200, Pavel Machek wrote:
On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Rohár wrote:
On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote:
twl-phy.notifier is not initalized
Signed-off-by: Pali Rohár pali.ro...@gmail.com
diff
Hi,
On Tue, Oct 01, 2013 at 03:39:57PM +0200, Daniel Mack wrote:
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.
On 10/01/2013 08:57 AM, Santosh Shilimkar wrote:
On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote:
On 10/01/2013 06:13 AM, Sricharan R wrote:
Hi,
On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
On 09/30/2013 08:59 AM, Sricharan R wrote:
Some socs have a large number of
On 01.10.2013 16:59, Felipe Balbi wrote:
On Tue, Oct 01, 2013 at 03:39:57PM +0200, Daniel Mack wrote:
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams.
The code was shamelessly taken from an ancient BSP tree.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/common/edma.c | 133
Hi Rob,
On 01/10/2013 15:17, Rob Herring wrote:
On 10/01/2013 03:06 AM, Benoit Cousson wrote:
+ more DT maintainers folks
Hi all,
I know this is mostly boring user space code, but I was expecting a
little bit of comments about at least the bindings syntax:-(
I'd like to know if this is the
On Tuesday 01 October 2013 10:53 AM, Rob Herring wrote:
On 10/01/2013 08:57 AM, Santosh Shilimkar wrote:
On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote:
On 10/01/2013 06:13 AM, Sricharan R wrote:
Hi,
On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
On 09/30/2013 08:59 AM,
Hi Rob,
On 01/10/2013 15:17, Rob Herring wrote:
On 10/01/2013 03:06 AM, Benoit Cousson wrote:
+ more DT maintainers folks
Hi all,
I know this is mostly boring user space code, but I was expecting a
little bit of comments about at least the bindings syntax:-(
I'd like to know
On Tue, Oct 01, 2013 at 05:04:04PM +0200, Daniel Mack wrote:
On 01.10.2013 16:59, Felipe Balbi wrote:
On Tue, Oct 01, 2013 at 03:39:57PM +0200, Daniel Mack wrote:
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.
Signed-off-by: Daniel Mack zon...@gmail.com
---
On 10/01/2013 03:09 PM, Daniel Mack wrote:
Hi Sebastian,
Hi Daniel,
sorry for the long delay, I got distracted by other things.
No problem.
Well, I didn't merge the descriptors. Look again at my changes please.
A simplified version of the code as it stands is:
for (i = 0; i
On 01.10.2013 18:22, Sebastian Andrzej Siewior wrote:
On 10/01/2013 03:09 PM, Daniel Mack wrote:
A simplified version of the code as it stands is:
for (i = 0; i DESCS_AREAS; i++)
cdd-cd = dma_alloc_coherent(dev, ..., cdd-descs_phys, GFP_KERNEL);
for (i = 0; i DESCS_AREAS; i++)
On 09/23/2013 03:40 PM, Thierry Reding wrote:
In preparation for adding an optional regulator and enable GPIO to the
driver, split the power on and power off sequences into separate
functions to reduce code duplication at the multiple call sites.
diff --git a/drivers/video/backlight/pwm_bl.c
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
static void __init smdkv210_map_io(void)
@@ -70,6 +70,7 @@ static struct samsung_bl_drvdata samsung_dfl_bl_data
__initdata = {
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Make use of the new enable_gpio field and allow it to be set from DT as
well. Now that all legacy users of platform data have been converted to
initialize this field to an invalid value, it is safe to use the field
from the driver.
diff --git
Daniel Mack zon...@gmail.com writes:
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams.
Please add a little more detail abou why the EDMA loses its context
across suspend/resume (e.g. which power domain(s) its in, and why
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Many backlights require a power supply to work properly. This commit
uses a power-supply regulator, if available, to power up and power down
the panel.
I think that all backlights require a power supply, albeit the supply
may not be
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The default for backlight devices is to be enabled immediately when
registering with the backlight core. This can be useful for setups that
use a simple framebuffer device and where the backlight cannot otherwise
be hooked up to the panel.
On Tue, Oct 01, 2013 at 12:26:07PM -0600, Stephen Warren wrote:
On 09/23/2013 03:40 PM, Thierry Reding wrote:
In preparation for adding an optional regulator and enable GPIO to the
driver, split the power on and power off sequences into separate
functions to reduce code duplication at the
On Tue, Oct 01, 2013 at 12:31:04PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this field needs
to be initialized explicitly.
static void __init smdkv210_map_io(void)
@@ -70,6 +70,7 @@ static
On Tue, Oct 01, 2013 at 12:39:36PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Make use of the new enable_gpio field and allow it to be set from DT as
well. Now that all legacy users of platform data have been converted to
initialize this field to an invalid
On Tue, Oct 1, 2013 at 10:06 AM, Benoit Cousson bcous...@baylibre.com wrote:
Hi Rob,
On 01/10/2013 15:17, Rob Herring wrote:
On 10/01/2013 03:06 AM, Benoit Cousson wrote:
+ more DT maintainers folks
Hi all,
I know this is mostly boring user space code, but I was expecting a
little bit
On Tue, Oct 01, 2013 at 12:43:57PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Many backlights require a power supply to work properly. This commit
uses a power-supply regulator, if available, to power up and power down
the panel.
I think that all
On 10/01/2013 02:43 PM, Thierry Reding wrote:
On Tue, Oct 01, 2013 at 12:31:04PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this
field needs to be initialized explicitly.
static void __init
On 10/01/2013 02:53 PM, Thierry Reding wrote:
On Tue, Oct 01, 2013 at 12:43:57PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Many backlights require a power supply to work properly. This
commit uses a power-supply regulator, if available, to power up
and power
On Tue, Oct 01, 2013 at 12:50:51PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The default for backlight devices is to be enabled immediately when
registering with the backlight core. This can be useful for setups that
use a simple framebuffer device and where
On Tue, Oct 01, 2013 at 02:58:22PM -0600, Stephen Warren wrote:
On 10/01/2013 02:43 PM, Thierry Reding wrote:
On Tue, Oct 01, 2013 at 12:31:04PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
The GPIO API defines 0 as being a valid GPIO number, so this
field
On Tue, Oct 01, 2013 at 02:59:43PM -0600, Stephen Warren wrote:
On 10/01/2013 02:53 PM, Thierry Reding wrote:
On Tue, Oct 01, 2013 at 12:43:57PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
Many backlights require a power supply to work properly. This
commit
Hi,
Any comments about the below patch? If my analysis is correct, this issue
needs to be fixed before any boards that set ONENAND_SYNC_READWRITE can
be converted to DT. So the fix should be applied preferably during the
current rc-cycle.
A.
On Fri, Sep 20, 2013 at 11:01:06PM +0300, Aaro
On 09/24/2013 10:52 AM, Benoit Cousson wrote:
Hi All,
Following the discussion that happened during LCE-2013 and the email
thread started by Tomasz few months ago [1], here is a first attempt
to introduce:
- a schema language to define the bindings accurately
- DTS validation during device
On 14:32-20131001, Eduardo Valentin wrote:
Hello all,
This is a complementary patch series with themal DT support for DRA7.
Although this work depends on the thermal dt parser work [1], I decided
to share it before hand. It also depends on DRA7 DT base port support,
which I fetched from
On 01-10-2013 18:58, Nishanth Menon wrote:
On 14:32-20131001, Eduardo Valentin wrote:
Hello all,
This is a complementary patch series with themal DT support for DRA7.
Although this work depends on the thermal dt parser work [1], I decided
to share it before hand. It also depends on DRA7 DT
76 matches
Mail list logo
