Hi Arnd,
On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
On Monday 07 January 2013, Tony Lindgren wrote:
At the end of the line, some kind of hardware glue is going to be needed.
I just feel that drawing from a sample size of 1
On Mon, Jan 07, 2013 at 08:38:34PM +, Russell King - ARM Linux wrote:
On Mon, Jan 07, 2013 at 12:21:06PM -0800, Tony Lindgren wrote:
* Ben Hutchings b...@decadent.org.uk [130105 21:29]:
Various drivers use omap_dma_filter_fn() but don't depend on DMA_OMAP.
This is fine because there
AnilKumar == AnilKumar, Chimata anilku...@ti.com writes:
AnilKumar On Wed, Nov 21, 2012 at 17:22:17, AnilKumar, Chimata wrote:
Rename I2C and GPIO nodes according to AM33XX TRM. According to
AM33XX TRM device instances are starting from 0 like i2c0, i2c1
and i2c3.
Signed-off-by:
(adding linux-media ML to cc)
Hi Pantelis
On Tue, 8 Jan 2013, Pantelis Antoniou wrote:
Hi Arnd,
On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
On Monday 07 January 2013, Tony Lindgren wrote:
At the end of the line, some
At the end of the line, some kind of hardware glue is going to be needed.
I just feel that drawing from a sample size of 1 (maybe 2 if I get to
throw
in the beagleboard), it is a bit premature to think about making it overly
general, besides the part that are obviously part of the
Hi Guennadi,
On Jan 8, 2013, at 11:51 AM, Guennadi Liakhovetski wrote:
(adding linux-media ML to cc)
Hi Pantelis
On Tue, 8 Jan 2013, Pantelis Antoniou wrote:
Hi Arnd,
On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
On
Hi Lee,
On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
At the end of the line, some kind of hardware glue is going to be needed.
I just feel that drawing from a sample size of 1 (maybe 2 if I get to
throw
in the beagleboard), it is a bit premature to think about making it overly
general,
On Tue, 08 Jan 2013, Pantelis Antoniou wrote:
Hi Lee,
On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
At the end of the line, some kind of hardware glue is going to be
needed.
I just feel that drawing from a sample size of 1 (maybe 2 if I get to
throw
in the beagleboard), it is
On Mon, Jan 07, 2013 at 09:35:04PM +, Arnd Bergmann wrote:
(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
On Monday 07 January 2013, Tony Lindgren wrote:
At the end of the line, some kind of hardware glue is going to be needed.
I just feel that drawing from a sample
On Tuesday 08 January 2013, Lee Jones wrote:
If there is not, there is no way to automatically load the overlays; you
can always
use the kernel command line, or have the a user space application to
request the loading
of a specific board's overlay.
Unfortunately, there is no way to
Hi Arnd,
On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
On Tuesday 08 January 2013, Lee Jones wrote:
If there is not, there is no way to automatically load the overlays; you
can always
use the kernel command line, or have the a user space application to
request the loading
of a
The iterator correctly handles of_node_put() calls.
Remove it before continue'ing the loop.
Without this patch you get:
ERROR: Bad of_node_put() on /ocp/timer@44e31000!
[c001329c] (unwind_backtrace+0x0/0xe0) from [c03dd8f0]
(of_node_release+0x2c/0xa0)!
[c03dd8f0] (of_node_release+0x2c/0xa0) from
omap hwmod is really sensitive to hwmod misconfiguration.
Getting a minor clock wrong always ended up in a crash.
Attempt to be more resilient by not assigning variables with
error codes and then attempting to use them.
Without this patch, missing a clock ends up with something like this:
The cam_mclk clock is generated through the following clocks chain:
dpll4 - dpll4_m5 - dpll4_m5x2 - cam_mclk
As dpll4_m5 and dpll4_m5x2 do not driver any clock other than cam_mclk,
back-propagate the cam_clk rate changes up to dpll4_m5.
Signed-off-by: Laurent Pinchart
Hello,
Now that the OMAP3 supports the common clock framework, clock rate
back-propagation is available for the ISP clocks. Instead of setting the
cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark the
dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting back-propagation,
Now that the cam_mclk rate changes are back-propagated to dpll4_m5_ck we
can set the cam_mclk rate directly instead of manually setting the rate
of the parent clock.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.c | 18
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
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.
PRUS?
The first mailbox sub-module is assigned
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
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
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
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
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(djrcv_dev-notif_fifo,
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
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:
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
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
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
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
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
TPTC0 needs to be idled and put to standby under SW control.
Add the appropriate flags in the TPTC0 hwmod entry.
Can you please expand TPTC0 in chane log.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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
Vaibhav,
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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:
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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.
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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
Vaibhav,
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
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
Hi Anil,
On 01/02/2013 11:12 AM, AnilKumar, Chimata wrote:
On Wed, Nov 21, 2012 at 17:22:17, AnilKumar, Chimata wrote:
Rename I2C and GPIO nodes according to AM33XX TRM. According to
AM33XX TRM device instances are starting from 0 like i2c0, i2c1
and i2c3.
Signed-off-by: Pantelis Antoniou
On Tuesday 08 January 2013, Pantelis Antoniou wrote:
On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote:
On Tuesday 08 January 2013, Lee Jones wrote:
If there is not, there is no way to automatically load the overlays; you
can always
use the kernel command line, or have the a user space
Hi Javier,
On 12/19/2012 02:33 PM, Javier Martinez Canillas wrote:
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patch-set adds initial device
tree support for these devices.
The device trees allows to boot from an MMC and are working
On Tue, Jan 8, 2013 at 5:13 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 12/19/2012 02:33 PM, Javier Martinez Canillas wrote:
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patch-set adds initial device
tree support for
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.8-rc2/fixes-signed-v2
for you to fetch changes up
On Tue, Jan 8, 2013 at 9:48 AM, Tony Lindgren t...@atomide.com wrote:
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
are available in the git repository at:
Hi Yuanhan,
On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
* Olof Johansson o...@lixom.net [130108 10:04]:
On Tue, Jan 8, 2013 at 9:48 AM, Tony Lindgren t...@atomide.com wrote:
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
are available in the git repository at:
Hello.
On 09/11/2012 01:09 PM, Kishon Vijay Abraham I wrote:
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Belated comments to the patch which didn't pass my message
Commit 00a0b1d58af873d842580dcac55f3b156c3a4077 (usb: musb: omap: Add device
tree support for omap musb glue) assigns result of devm_kzalloc() call to
the 'config' variable but then checks for NULL the 'data' variable (already
checked after previous call). Thus we risk a kernel oops further when
Commit 00a0b1d58af873d842580dcac55f3b156c3a4077 (usb: musb: omap: Add device
tree support for omap musb glue) added assignments of the 'ret' variable to
-ENOMEM on *some* error paths of the calls to devm_kzalloc(), while that
variable was already pre-initialized for to that value, so these
From: Mark A. Greer mgr...@animalcreek.com
The AES controller only needs to be reset once and that will
be done by the hwmod infrastructure, if possible. Therefore,
remove the reset code from the omap-aes driver.
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer
From: Mark A. Greer mgr...@animalcreek.com
Changes from v1:
- Addressed comments by Russ Dill by defining omap_aes_of_match[] to
contain an empty entry (end of list indicator) and defining
omap_aes_get_res_of() instead of incorrectly defining
omap_aes_get_res_dev() when CONFIG_OF is
From: Mark A. Greer mgr...@animalcreek.com
Remove the unnecessary pr_info() calls from omap_aes_probe()
and omap_aes_mod_init().
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 4
1 file changed, 4
From: Mark A. Greer mgr...@animalcreek.com
The OMAP3 and OMAP4/AM33xx versions of the AES crypto
module support the CTR algorithm in addition to ECB
and CBC that the OMAP2 version of the module supports.
So, OMAP2 and OMAP3 share a common register set but
OMAP3 supports CTR while OMAP2 doesn't.
From: Mark A. Greer mgr...@animalcreek.com
Convert the omap-aes crypto driver to use the
pm_runtime API instead of the clk API.
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
From: Mark A. Greer mgr...@animalcreek.com
Add Device Tree suport to the omap-aes crypto
driver. Currently, only support for OMAP2 and
OMAP3 is being added but support for OMAP4 will
be added in a subsequent patch.
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer
From: Mark A. Greer mgr...@animalcreek.com
Add suspend/resume support to the OMAP AES driver.
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 19 +++
1 file changed, 19 insertions(+)
diff --git
From: Mark A. Greer mgr...@animalcreek.com
Remove usage of the private OMAP DMA API.
The dmaengine API will be used instead.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
From: Mark A. Greer mgr...@animalcreek.com
Add support for the OMAP4 version of the AES module
that is present on OMAP4 and AM33xx SoCs.
The modules have several differences including register
offsets and how DMA is triggered. To handle these
differences, a platform_data structure is defined
From: Mark A. Greer mgr...@animalcreek.com
Add code to use the new dmaengine API alongside
the existing DMA code that uses the private
OMAP DMA API. The API to use is chosen by
defining or undefining 'OMAP_AES_DMA_PRIVATE'.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin
From: Mark A. Greer mgr...@animalcreek.com
Use the dma_request_slave_channel_compat() call instead of
the dma_request_channel() call to request a DMA channel.
This allows the omap-aes driver use different DMA engines.
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer
On Fri, Dec 28, 2012 at 02:06:02AM -0800, Russ Dill wrote:
On Fri, Dec 21, 2012 at 10:04 AM, Mark A. Greer mgr...@animalcreek.com
wrote:
From: Mark A. Greer mgr...@animalcreek.com
Add Device Tree suport to the omap-aes crypto
driver. Currently, only support for OMAP2 and
OMAP3 is
On Sun, 30 Dec 2012, Paul Walmsley wrote:
However, for some reason, we don't have an EMAC hwmod -- probably some
bug in the data -- so set the flag on the MDIO hwmod data instead.
Mark and I discussed this in private E-mail. Looks like I managed to
confuse AM33xx and AM3517 :-( Here's the
On Sun, Dec 23, 2012 at 08:40:43AM +, Paul Walmsley wrote:
Hi Mark,
Hi Paul.
On Fri, 21 Dec 2012, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
[This series supersedes the hwmod related patches sent in the
crypto: omap-sham updates and crypto: omap-aes updates
On Tue, Jan 08, 2013 at 07:21:16PM +, Paul Walmsley wrote:
On Sun, 30 Dec 2012, Paul Walmsley wrote:
Hi Paul.
However, for some reason, we don't have an EMAC hwmod -- probably some
bug in the data -- so set the flag on the MDIO hwmod data instead.
Mark and I discussed this in
Dmitry Torokhov dmitry.torok...@gmail.com wrote:
Hi Yuanhan,
On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code
Hi,
I'm trying to get off_mode working reliably on my gta04 mobile phone.
My current stumbling block is USB. The Option GSM module is attached via
USB (there is a separate transceiver chip attached to port 1 which is placed
in OMAP_EHCI_PORT_MODE_PHY).
After a suspend/resume cycle with
On Monday 07 January 2013, Russell King - ARM Linux wrote:
The problem we have is that the way peripheral devices are connected to
their DMA engines can involve additional complexity, which if not handled
correctly results in some platforms being crippled by the API.
I think Vinod was
On Tue, Jan 08, 2013 at 10:16:46AM -0800, Dmitry Torokhov wrote:
Hi Yuanhan,
On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential
Updated version of DRM driver for TI LCD Controller. Since the initial
version of the patch, which only supported TFP410 DVI output, I've added
an output driver for LCD panels (for example, LCD3 or LCD7 cape for the
beagle-bone), and initial support for HDMI output via NXP TDA19988 HDMI
encoder
Add an output panel driver for LCD panels. Tested with LCD3 cape on
beaglebone.
TODO: need some way to control the appropriate backlight device
TODO: probably want to make the DT bindings more generic for panel-info
v1: original
v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis
Driver for the NXP TDA998X i2c hdmi encoder slave.
Signed-off-by: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/i2c/Makefile | 3 +
drivers/gpu/drm/i2c/tda998x_drv.c | 907 ++
2 files changed, 910 insertions(+)
create mode 100644
Add output panel driver for i2c encoder slaves.
Signed-off-by: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/lcdc/Kconfig | 12 ++
drivers/gpu/drm/lcdc/Makefile | 1 +
drivers/gpu/drm/lcdc/lcdc_drv.c | 5 +-
drivers/gpu/drm/lcdc/lcdc_slave.c | 384
On Tue, Jan 08, 2013 at 19:23:44, Shilimkar, Santosh wrote:
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
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,
On Tue, Jan 08, 2013 at 19:26:51, Shilimkar, Santosh wrote:
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
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
On Tue, Jan 08, 2013 at 19:34:41, Shilimkar, Santosh wrote:
[...]
drivers/memory/emif.c |2 +-
drivers/memory/emif.h | 589
---
include/linux/ti_emif.h | 589
+++
You are just moving
On Tue, Jan 08, 2013 at 20:31:44, Shilimkar, Santosh wrote:
[...]
+#endif /* ASSEMBLER */
+
Drop that extra line.
Ok.
#endif
diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 3f25c56..2f2eaa0 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++
On Tue, Jan 08, 2013 at 20:47:28, Shilimkar, Santosh wrote:
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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
Hi Santosh,
On Tue, Jan 08, 2013 at 21:01:51, Shilimkar, Santosh wrote:
Vaibhav,
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
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
On Tue, Jan 08, 2013 at 20:52:37, Shilimkar, Santosh wrote:
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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
On Tue, Jan 08, 2013 at 20:51:08, Shilimkar, Santosh wrote:
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
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
On Tue, Jan 08, 2013 at 20:35:39, Shilimkar, Santosh wrote:
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
TPTC0 needs to be idled and put to standby under SW control.
Add the appropriate flags in the TPTC0 hwmod entry.
Can you please expand TPTC0 in chane log.
Third Party
On Wednesday 09 January 2013 11:08 AM, Bedia, Vaibhav wrote:
On Tue, Jan 08, 2013 at 20:51:08, Shilimkar, Santosh wrote:
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
Add minimal APIs for writing to the IPC and the M3_TXEV registers
in the Control module. These will be used in a
77 matches
Mail list logo
