Paul,
On Sunday 30 December 2012 11:58 PM, Paul Walmsley wrote:
Apparently, on some OMAPs, the MPU can't be allowed to enter WFI while
certain peripherals are active. It's not clear why, and it's likely
that there is simply some other bug in the driver or integration code.
But since the
On Sunday 30 December 2012 11:58 PM, Paul Walmsley wrote:
There shouldn't be any need to jump to SRAM code if the OMAP CORE
clockdomain (and consequently the SDRAM controller and CORE PLL) stays
active during MPU WFI. The SRAM code should only be needed when the RAM
enters self-refresh. So in
Hello,
This series will update the omap-twl4030 machine driver and the twl4030 codec
driver to enable support for more boards.
With this change we can remove two more machine drivers: zoom2 and sdp3430 since
they will be supported by the common omap-twl4030 machine driver.
The
In order to be able to use the Voice port of twl4030 three bits need to be
handled in VOICE_IF register:
VIF_EN: to enable the voice port (needed for both playback and capture)
VIF_DIN_EN: Need to be enabled for playback only (input to the codec)
VIF_DOUT_EN: Need to be enabled for capture only
The codec driver takes care of these bits.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/zoom2.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/sound/soc/omap/zoom2.c b/sound/soc/omap/zoom2.c
index 771bff2..5845d48 100644
--- a/sound/soc/omap/zoom2.c
The codec driver takes care of these bits.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/sdp3430.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c
index b462a2c..86e77e9 100644
---
In order to avoid breakage update the machine drivers at the same time using
twl4030: omap3pandora, sdp3430 and zoom2
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl4030.c| 10 +++---
sound/soc/omap/omap3pandora.c | 8
sound/soc/omap/sdp3430.c
The codec driver takes care of this.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/sdp3430.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c
index f2e2651..216cbdd 100644
---
When HS extmute is enabled without custom GPIO we should configure the mux
to allow the pin to be used as extmute signal.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/twl4030.c | 44 +++-
1 file changed, 31 insertions(+), 13
Update the common machine driver to support more boards including Zoom2 and
SDP3430.
- Support for voice port of twl4030
- HS jack plug detection support
- The audio routing can be fine tuned via pdata or via provided routing
table from DT.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
These boards are using the common omap-twl4030 machine driver, no need for
separate machine drivers anymore.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/omap/Kconfig | 17
sound/soc/omap/Makefile | 4 -
sound/soc/omap/sdp3430.c | 245
Hello,
omap-twl4030 ASoC machine driver can support more boards with the following
series:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-December/058119.html
Rework the omap-twl4030 audio support code in arch/arm/mach-omap2/ to take
advantages of this. The same machine driver can
Enable the use of extmute on the HS path.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index bb73afc..40c22a7 100644
The HS extmute is not used on Zoom2 boards. Furthermore the GPIO153 is used
as IRQ for the TSC2004 touchscreen controller - for which we do not have
driver upstream, yet.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 11 +++
1 file
Select the most commonly used audio configuration on boards with twl4030
audio:
Headset, Handsfree output and Line in input
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/twl-common.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
Boards with special audio routing can pass a custom omap_tw4030_pdata to the
audio machine driver.
At the same time update the board files using the same audio driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-cm-t35.c | 2 +-
Use the common omap-twl4030 ASoC machine driver for audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
Use the common omap-twl4030 ASoC machine driver for audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
Hello,
Second part of the cleanup of twl-core which aims to make the code a bit more
readable.
It has been tested on: OMAP4 PandaBoard, OMAP4 Blaze, OMAP3 BeagleBoard, OMAP3
Zoom2.
Regards,
Peter
---
Peter Ujfalusi (10):
mfd: twl-core: Clean up module id lookup and definitions
mfd: twl-core:
At boot time we can allocate the twl_modules array dynamically based on the
twl class we are using with devm_kzalloc() instead of the static
twl_modules[] array.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 31 +--
1 file changed,
There is really no point to retry to add children devices in case the
of_platform_populate() fails.
We do not have any information provided via pdata in this case anyways.
Depending on the boot type (legacy or DT) only execute either one.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
twl_i2c_read/write_u8 become as a simple wrapper over the twl_i2c_read/write.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 28
include/linux/i2c/twl.h | 17 +++--
2 files changed, 11 insertions(+), 34 deletions(-)
With the regmap conversion there is no longeer a need to allocate bigger
buffer for writes
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 3 ---
include/linux/i2c/twl.h | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/mfd/twl-core.c
The module id table no longer can have invalid/unused entries.
No need for checking the ID for validity.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/twl-core.c
Instead of using SUB_CHIP_ID* or magic numbers use the twl_mapping table to
look for the subchip ID.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 56 --
1 file changed, 27 insertions(+), 29 deletions(-)
diff
Gather the global variables under a single structure and allocate it with
devm_kzalloc(). It is easier to see them and if in the future we try to add
support for multiple instance of twl in the system it is going to be much
simpler.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
We can fail earlier in case multiple instance of the twl-core is tried to
be loaded.
The twl-core by design only supports one instance.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
When booted with DT we can manage without the dummy pdata.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl-core.c | 31 +++
1 file changed, 7 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index
Use enums for all module definitions:
twl_module_ids for common functionality among twl4030/twl6030
twl4030_module_ids for twl4030 specific ids
twl6030_module_ids for twl6030 specific ids
In this way the list can be managed easier when new functionality going to
be implemented.
Signed-off-by:
Hi
On Mon, 31 Dec 2012, Santosh Shilimkar wrote:
This is more of question. If the limitation is w.r.t MPU power
state then shouldn't we just prevent the MPU power state rather
than blocking the WFI completely.
Can you please clarify if retaining MPU power state in ON can achieve
the same
On Sat, Dec 29, 2012 at 10:04 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
These regulators are common to igep0020 and igep0030 boards
and are needed by smsc911x controller.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Enric Balletbo i Serra
Hi,
This is the second version of the patch series for adding suspend-resume
support for AM33XX. Based on the feedback received on the previous patch
series [1] almost all the patches have undergone a bit a rework.
The 1st two patches depend on the changes for mailbox code migration
from
Mailbox IP on AM33XX is the same as that present in OMAP4.
The single instance of Mailbox IP on AM33XX contains
8 sub-modules and facilitates communication between MPU,
PRUs and WKUP_M3.
The first mailbox sub-module is assigned for communication
between MPU and WKUP-M3.
Signed-off-by: Vaibhav
On AM33XX, the mailbox module between the MPU and the
WKUP-M3 co-processor facilitates a one-way communication.
MPU uses the assigned mailbox sub-module to issue the
interrupt to the WKUP-M3 co-processor which then goes
and reads the the IPC data from registers in the control
module.
WKUP-M3 is
Some of the included header files are not needed so
remove them.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Vaibhav Hiremath
This is necessary to ensure that macros declared here can
be reused from assembly files.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman
OCMC RAM lies in the PER power domain and this memory
support retention.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Vaibhav
TPTC0 needs to be idled and put to standby under SW control.
Add the appropriate flags in the TPTC0 hwmod entry.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman
The current HWMOD code expects the memory region with
the IP's SYSCONFIG register to be marked with ADDR_TYPE_RT
flag.
CPGMAC0 hwmod entry specifies two memory regions and marks
both with the flag ADDR_TYPE_RT although only the 2nd region
has the SYSCONFIG register. This leads to the HWMOD code
WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST)
Update the WKUP-M3 hwmod data to reflect the same.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman
WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST)
Update the hardreset API to ensure that the reset line properly
deasserted.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley
Since AM33XX supports only DT-boot, this is needed
for the appropriate device nodes to be created.
Note: OCMC RAM is part of the PER power domain and supports
retention. The assembly code for low power entry/exit will
run from OCMC RAM. To ensure that the OMAP PM code does not
attempt to disable
The current OMAP timer code registers two timers -
one as clocksource and one as clockevent.
AM33XX has only one usable timer in the WKUP domain
so one of the timers needs suspend-resume support
to restore the configuration to pre-suspend state.
commit adc78e6 (timekeeping: Add suspend and resume
AM33XX has two timers (DTIMER0/1) in the WKUP domain.
On GP devices the source of DMTIMER0 is fixed to an
inaccurate internal 32k RC oscillator and this makes
the DMTIMER0 practically either as a clocksource or
as clockevent.
Currently the timer instance in WKUP domain is used
as the clockevent
On 12/21/2012 06:06 PM, Ezequiel Garcia wrote:
On Fri, Dec 21, 2012 at 12:07 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
commit a99d76f leds: leds-gpio: use gpio_request_one
changed the leds-gpio driver to use gpio_request_one() instead
of gpio_request() +
Add minimal APIs for writing to the IPC and the M3_TXEV registers
in the Control module. These will be used in a subsequent patch which
adds suspend-resume support for AM33XX.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Tony Lingren t...@atomide.com
Cc: Santosh Shilimkar
PM services on AM33XX depend on mailbox for communication
with WKUP-M3 core so ensure that the right config options
are selected. Thanks to Kevin Hilman khil...@deeprootsystems.com
for the suggestion on updating the Kconfig and not just
the omap2plus_defconfig which was done in the previous
With all the requisite changes in place we can now
enable basic PM support on AM33XX. This patch updates
the various OMAP files to enable suspend-resume on
AM33XX.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Tony Lingren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
On Monday 31 December 2012 06:26 PM, Paul Walmsley wrote:
Hi
On Mon, 31 Dec 2012, Santosh Shilimkar wrote:
This is more of question. If the limitation is w.r.t MPU power
state then shouldn't we just prevent the MPU power state rather
than blocking the WFI completely.
Can you please clarify
In preparation for suspend-resume support for AM33XX, add
the assembly file with the code which is copied to internal
memory (OCMC RAM) during bootup and runs from there.
As part of the low power entry (DeepSleep0 mode in AM33XX TRM),
the code running from OCMC RAM does the following
1. Stores
AM335x supports various low power modes as documented
in section 8.1.4.3 of the AM335x TRM which is available
@ http://www.ti.com/litv/pdf/spruh73f
DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a system reboot and is mapped as
the suspend state in the kernel. In
OMAP4 and AM33XX share the same EMIF controller IP. Although there
are significant differences in the IP integration due to which
AM33XX can't reuse the EMIF driver DVFS similar to OMAP4,
it can definitely benefit by reusing the EMIF related macros
defined in drivers/memory/emif.h.
In the current
52 matches
Mail list logo
