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 sampl
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 [130105 21:29]:
> > > Various drivers use omap_dma_filter_fn() but don't depend on DMA_OMAP.
> > > This is fine because there is a trivial
> "AnilKumar" == AnilKumar, Chimata 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: P
(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 o
> >>> 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 o
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
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 mak
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
> > t
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 fr
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
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
>
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!
[] (unwind_backtrace+0x0/0xe0) from []
(of_node_release+0x2c/0xa0)!
[] (of_node_release+0x2c/0xa0) from []
(of_find_matching_no
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:
omap_hwm
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
---
arch/arm/mach-omap
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, a
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
---
drivers/media/platform/omap3isp/isp.c | 18 ++
drivers/media/platform/omap3i
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 f
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 I
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 relat
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,
DJ_MAX_NUMBER_
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
Cc: Santosh Shilimkar
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Vaibhav Hiremath
---
Acked-by: Santosh Shilimkar
--
To
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
Cc: Santosh Shilimkar
Cc: Paul Walmsley
Cc: Benoit Cousson
Cc: Kevin Hilman
Cc: Vaibhav Hiremath
---
v1->v2:
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
Cc: Santosh Shilimkar
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Vaibhav Hiremath
---
Looks fine to me.
Acked-by:
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
Cc: Santosh Shilimkar
Cc: Benoit Cousson
Cc: Paul
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 region
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
Cc: Santosh Shilimkar
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Vaib
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
Cc: Santosh Shilimkar
Cc: Benoit Cousson
Cc: Paul Walmsley
Cc: Kevin H
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. T
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 th
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
Cc: Tony Lingren
Cc: Santosh Sh
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
for the suggestion on updating the Kconfig and not just
the omap2plus_defconfig which
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: Panteli
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
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 wor
On Tue, Jan 8, 2013 at 5:13 PM, Benoit Cousson 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 these device
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 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:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
> t
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 [130108 10:04]:
> On Tue, Jan 8, 2013 at 9:48 AM, Tony Lindgren 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:
> >
> > git://git.kernel.o
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
Belated comments to the patch which didn't pass my message size filter
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 da
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 assignme
From: "Mark A. Greer"
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
Signed-off-by: Mark A. Greer
---
drivers/crypto/omap-aes.c | 27
From: "Mark A. Greer"
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 not defined.
This patc
From: "Mark A. Greer"
Remove the unnecessary pr_info() calls from omap_aes_probe()
and omap_aes_mod_init().
CC: Dmitry Kasatkin
Signed-off-by: Mark A. Greer
---
drivers/crypto/omap-aes.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes
From: "Mark A. Greer"
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. OMAP4/AM33XX
uses a
From: "Mark A. Greer"
Convert the omap-aes crypto driver to use the
pm_runtime API instead of the clk API.
CC: Kevin Hilman
CC: Dmitry Kasatkin
Signed-off-by: Mark A. Greer
---
drivers/crypto/omap-aes.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
di
From: "Mark A. Greer"
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
Signed-off-by: Mark A. Greer
---
drivers/crypto/omap-aes.c | 123 +
From: "Mark A. Greer"
Add suspend/resume support to the OMAP AES driver.
CC: Dmitry Kasatkin
Signed-off-by: Mark A. Greer
---
drivers/crypto/omap-aes.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index c229852.
From: "Mark A. Greer"
Remove usage of the private OMAP DMA API.
The dmaengine API will be used instead.
CC: Russell King
CC: Dmitry Kasatkin
Signed-off-by: Mark A. Greer
---
drivers/crypto/omap-aes.c | 133 --
1 file changed, 133 deletions(-)
diff
From: "Mark A. Greer"
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 and
contains routine po
From: "Mark A. Greer"
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
CC: Dmitry Kasatkin
Signed-off-by: Mark A. Greer
---
drivers/crypto/oma
From: "Mark A. Greer"
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
Signed-off-by: Mark A. Greer
---
drivers/crypto/omap-aes.c | 12
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
> wrote:
> > From: "Mark A. Greer"
> >
> > Add Device Tree suport to the omap-aes crypto
> > driver. Currently, only support for OMAP2 and
> > OMAP3 is being added but support for OMAP4
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"
> >
> > [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 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 at drivers/hid
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 off_m
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 wo
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
> > potent
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 (v
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
---
drivers/gpu/drm/i2c/Makefile | 3 +
drivers/gpu/drm/i2c/tda998x_drv.c | 907 ++
2 files changed, 910 insertions(+)
create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
dif
Add output panel driver for i2c encoder slaves.
Signed-off-by: Rob Clark
---
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 ++
drivers/
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
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
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 p
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
> > for the s
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 Par
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 sub
77 matches
Mail list logo