Hi again,
On Thu, Sep 23, 2010 at 01:49:10AM -0500, Balbi, Felipe wrote:
@@ -126,6 +128,17 @@ struct musb_hdrc_platform_data {
/* Architecture specific board data */
void*board_data;
+
+ /* check usb device active state*/
+ int (*is_usb_ac
Hi,
>-Original Message-
>From: Balbi, Felipe
>Sent: Thursday, September 23, 2010 12:21 PM
>To: Kalliguddi, Hema
>Cc: Balbi, Felipe; linux-omap@vger.kernel.org;
>linux-...@vger.kernel.org; Tony Lindgren; Kevin Hilman;
>Cousson, Benoit; Paul Walmsley
>Subject: Re: [PATCH 1/9 v3] usb: mus
Hi,
On Thu, Sep 23, 2010 at 01:46:51AM -0500, Kalliguddi, Hema wrote:
Any driver which uses the device->dma_mask will have to it after the
device build.
yeah, let's see what Kevin, Paul and Tony say about it.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
Hi,
On Thu, Sep 23, 2010 at 01:24:19AM -0500, Kalliguddi, Hema wrote:
I understand that. I forgot to Cc Mike for blackfin arch files change.
I will post it again today Cc ing him and try my luck :-)
let's hope for the best, but while at that, would you take care of the
comments on the other pa
Hi,
On Wed, Sep 22, 2010 at 07:30:46PM -0500, Kalliguddi, Hema wrote:
With OMAP core-off support musb was not functional as context was getting
lost after wakeup from core-off. And also musb was blocking the core-off
after loading the gadget driver even with no cable connected sometimes.
Added
Hi,
>-Original Message-
>From: Balbi, Felipe
>Sent: Thursday, September 23, 2010 11:52 AM
>To: Kalliguddi, Hema
>Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>Balbi, Felipe; Tony Lindgren; Kevin Hilman; Cousson, Benoit;
>Paul Walmsley
>Subject: Re: [PATCH 6/9 v3] usb: mus
Hi,
>-Original Message-
>From: Balbi, Felipe
>Sent: Thursday, September 23, 2010 11:51 AM
>To: Kalliguddi, Hema
>Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>Balbi, Felipe; Tony Lindgren; Kevin Hilman; Cousson, Benoit;
>Paul Walmsley
>Subject: Re: [PATCH 5/9 v3] usb: mus
Hi,
On Wed, Sep 22, 2010 at 07:30:30PM -0500, Kalliguddi, Hema wrote:
Calling runtime pm APIs pm_runtime_put_sync() and pm_runtime_get_sync()
for enabling/disabling the clocks,sysconfig settings.
Also need to put the USB in force standby and force idle mode when usb not used
and set it back to
Hi Mike,
>-Original Message-
>From: Kalliguddi, Hema
>Sent: Thursday, September 23, 2010 5:57 AM
>To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
>Cc: Kalliguddi, Hema; Balbi, Felipe; Tony Lindgren; Kevin
>Hilman; Cousson, Benoit; Paul Walmsley
>Subject: [PATCH 1/9 v3] usb: mus
Hi,
>-Original Message-
>From: Balbi, Felipe
>Sent: Thursday, September 23, 2010 11:40 AM
>To: Kalliguddi, Hema
>Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>Balbi, Felipe; Tony Lindgren; Kevin Hilman; Cousson, Benoit;
>Paul Walmsley
>Subject: Re: [PATCH 1/9 v3] usb: mus
On Wed, Sep 22, 2010 at 03:43:14PM -0500, Cousson, Benoit wrote:
Hi Hema,
On 9/23/2010 2:30 AM, Kalliguddi, Hema wrote:
OMAP USBOTG modules has a requirement to set the auto idle bit only after
setting smart idle bit. Modified the _sys_enable api to set the smart idle
first and then the autoidl
On Wed, Sep 22, 2010 at 07:29:55PM -0500, Kalliguddi, Hema wrote:
OMAP2430 hwmod data stuctures are populated with base address, L3 and L4
interface clocks, IRQs,and sysconfig register details.
Signed-off-by: Hema HK
Cc: Felipe Balbi
Cc: Tony Lindgren
Cc: Kevin Hilman
Cc: Cousson, Benoit
Cc
Hi,
On Wed, Sep 22, 2010 at 07:29:10PM -0500, Kalliguddi, Hema wrote:
+#define MAX_OMAP_MUSB_HWMOD_NAME_LEN 16
this isn't used anywhere.
@@ -75,31 +62,30 @@ static struct musb_hdrc_platform_data mu
static u64 musb_dmamask = DMA_BIT_MASK(32);
-static struct platform_device musb_device = {
> >
> > Why not these defines in mach-omap2/dmtimer.c? since register offsets
> are
> > same for omap2plus except omap4 which has additional register offsets.
> Same
> > register offsets are getting repeated in all the omap2plus hwmod
> database.
>
> I agree with Manjunath.
>
> > As kevin suggest
> -Original Message-
> From: G, Manjunath Kondaiah
> Sent: Thursday, September 23, 2010 12:30 AM
> To: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org
> Cc: Cousson, Benoit; Paul Walmsley; Kevin Hilman; Tony Lindgren
> Subject: RE: [PATCHv3 7/17] dmtimer: use list instead of static array
On Wed, Sep 22, 2010 at 07:27:11PM -0500, Kalliguddi, Hema wrote:
Modified the Omap,Blackfin and Davinci board files to add the name of the IRQs
in the resource structures and musb driver to use the get_irq_byname() api to
get the mc and dma irq numbers instead of using the index as the order of
> -Original Message-
> From: G, Manjunath Kondaiah
> Sent: Thursday, September 23, 2010 12:31 AM
> To: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org
> Cc: Basak, Partha; Gopinath, Thara; Cousson, Benoit; Paul Walmsley; Kevin
> Hilman; Tony Lindgren
> Subject: RE: [PATCHv3 2/17] dmtimer
Hi Hari,
On Thu, Sep 23, 2010 at 1:19 AM, Kanigeri, Hari wrote:
> Kishore,
>
>> +int twl6030_mmc_card_detect(struct device *dev, int slot)
>> +{
>> + int ret = -EIO;
>> + u8 read_reg = 0;
>> + struct platform_device *pdev = to_platform_device(dev);
>> +
>> + switch (pdev->id) {
>>
> -Original Message-
> From: Hema HK [mailto:hem...@ti.com]
> Sent: Thursday, September 23, 2010 6:01 AM
> To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
> Cc: Hema HK; Maulik Mankad; Felipe Balbi; Tony Lindgren; Kevin Hilman;
> Cousson, Benoit; Paul Walmsley
> Subject: [PATCH 9
Fix the mailbox support detection for OMAP3630, 3530/25 and 2430.
Signed-off-by: Omar Ramirez Luna
---
- Testing was made under 3630 and 3430 boards.
- Given that 2430 uses similar initialization than OMAP3, changes
to handle this case was added to the patch.
- HWMOD adaptation hopefully should
Rafael J. Wysocki had written, on 09/22/2010 07:03 PM, the following:
[Trimming the CC list slightly.]
[...]
...
First, thanks for addressing the previous comments, things look much better
now. In particular the documentation has been improved a lot in my view.
Thanks for the excellent revi
[Trimming the CC list slightly.]
Hi,
On Wednesday, September 22, 2010, Nishanth Menon wrote:
> SOCs have a standard set of tuples consisting of frequency and
> voltage pairs that the device will support per voltage domain. These
> are called Operating Performance Points or OPPs. The actual
> defi
Am Mittwoch, den 22.09.2010, 08:08 +0200 schrieb Guennadi Liakhovetski:
> On Wed, 22 Sep 2010, hermann pitton wrote:
>
> > Am Mittwoch, den 22.09.2010, 01:23 +0200 schrieb Guennadi Liakhovetski:
> > > On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
> > >
> > > > This is a V4L2 driver for TI OMAP1
Kevin Hilman writes:
[...]
> I also just tested on n900 which has lots of GPIOs configured. On this
> platform, suspend doesn't hit RET because both GPIO3 and GPIO4 are still
> enabled.
OK, I found the bug on n900, and you're off the hook for this one. :)
It's an existing bug and the problem
On Tue, Sep 14, 2010 at 4:02 PM, Kevin Hilman
wrote:
> Laine Walker-Avina writes:
>
>> I just pulled the latest changes today from the linux-omap git tree,
>> and something appears to have broken suspend to RAM on my OMAP3503
>> board.
>
> Is this on the master branch? What defconfig? When was
Hi all,
I'm having some troubles putting my OMAP3503(the one without the DSP
or SGX modules) board to sleep. I'm using the current master on the
l-o git repository.
This is the output from dmesg and the count file after suspending
twice. The first time it wakes immediately after going down, and t
SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, vo
Hema HK writes:
> Cc: Felipe Balbi
> Cc: Tony Lindgren
> Cc: Kevin Hilman
> Cc: Cousson, Benoit
> Cc: Paul Walmsley
>
> This patch series makes OMAP2PLUS musb Module implemented
> in HWMOD FW way. It also implements musb driver to
> use the runtime pm apis.
>
> PATCH[1/8 v3] and [PATCH 2/8 v
"G, Manjunath Kondaiah" writes:
> Hi Tarun,
>
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org
>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
>> DebBarma, Tarun Kanti
>> Sent: Tuesday, September 21, 2010 2:24 PM
>> To: linux-omap@vger.kernel.org
>> Cc: DebBarma
Hello Hema,
On Wed, 22 Sep 2010, Hema HK wrote:
> OMAP USBOTG modules has a requirement to set the auto idle bit only after
> setting smart idle bit. Modified the _sys_enable api to set the smart idle
> first and then the autoidle bit. Setting this will not have any impact on the
> other modules.
Instead of enabling the wifi module explicitly using GPIO, add a fixed
regulator and hook it to MMC host card power control. This way it will
only be enabled when SDIO subsystem wants to talk to it, saving power
(as done by Zoom boards).
Signed-off-by: Grazvydas Ignotas
---
arch/arm/mach-omap2/b
On 9/23/2010 2:28 AM, Kalliguddi, Hema wrote:
From: Cousson, Benoit
OMAP4 hwmod data stuctures are populated with base address, L3 and L4
typo: structures
interface clocks, IRQs,and sysconfig register details.
missing space after comma.
Signed-off-by: Cousson, Benoit
Signed-off-by: Hema
Hi Hema,
On 9/23/2010 2:30 AM, Kalliguddi, Hema wrote:
OMAP USBOTG modules has a requirement to set the auto idle bit only after
setting smart idle bit. Modified the _sys_enable api to set the smart idle
first and then the autoidle bit. Setting this will not have any impact on the
other modules.
"Govindraj.R" writes:
> This patch makes the following:
> - Adds missing wakeup padding register handling.
> - Fixes a hardcode to use PER module ONLY on UART3.
>
> Signed-off-by: Kevin Hilman
> Signed-off-by: Sergio Aguirre
> Signed-off-by: Govindraj.R
> ---
> arch/arm/mach-omap2/serial.c
"Govindraj.R" writes:
> This patch series adds a serial driver to handle uarts on omap platforms.
> Currenlty omap-uarts are handled with 8250 driver, since updating
> this driver with omap specific features will over load
> the 8250 driver with all omap-specific data thus a new driver
> is added
Kishore,
> +int twl6030_mmc_card_detect(struct device *dev, int slot)
> +{
> + int ret = -EIO;
> + u8 read_reg = 0;
> + struct platform_device *pdev = to_platform_device(dev);
> +
> + switch (pdev->id) {
> + case 0:
> + /*
> + * BIT0 of REG_MMC_CTRL
> +
Hema HK writes:
> OMAP3 hwmod data stuctures are populated with base address, L3 and L4
> interface clocks, IRQs,and sysconfig register details.
This has been requested for the other hwmod conversions as well:
Subject prefix for the arch/arm/mach-omap2/* code should be OMAP: (or
OMAP2+, OMAP3,
David Anders writes:
> PandaBoard machine file related cleanups.
>
> David Anders (4):
> omap4: pandaboard: remove unused hsmmc definition
> omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set
> omap4: pandaboard: Adding card detect support for MMC1
> omap4: pandaboard: enabl
Hi -
On Wed, Sep 22, 2010 at 08:26:40PM +0200, Peter Zijlstra wrote:
> [...]
> > Not sure what you mean by "double tracepoints"
> Two different tracepoints in the same location.
Another possibility may be to provide a backward-compatibility module
that maps new tracepoints to old ones. On demand
Here is checkpatch and sparse warnings for this series:
$./scripts/checkpatch.pl --strict timer_patches/*.patch
CHECK: multiple assignments should be avoided
#182: FILE: arch/arm/mach-omap1/dmtimer.c:127:
+ res[1].start = res[1].end = irq;
total: 0 errors, 0 warnings, 1 checks, 267
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> DebBarma, Tarun Kanti
> Sent: Tuesday, September 21, 2010 2:21 PM
> To: linux-omap@vger.kernel.org
> Cc: Gopinath, Thara; Basak, Partha; DebBarma, Tarun Kanti;
> Cou
Hi Tarun,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> DebBarma, Tarun Kanti
> Sent: Tuesday, September 21, 2010 2:24 PM
> To: linux-omap@vger.kernel.org
> Cc: DebBarma, Tarun Kanti; Basak, Partha; Shilimkar, Sa
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> DebBarma, Tarun Kanti
> Sent: Tuesday, September 21, 2010 2:23 PM
> To: linux-omap@vger.kernel.org
> Cc: DebBarma, Tarun Kanti; Cousson, Benoit; Paul Walmsley;
> K
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> DebBarma, Tarun Kanti
> Sent: Tuesday, September 21, 2010 2:21 PM
> To: linux-omap@vger.kernel.org
> Cc: DebBarma, Tarun Kanti; Basak, Partha; Gopinath, Thara;
> Co
[Dropping disc...@lesswatts.org from the CC list.]
On Wednesday, September 22, 2010, Jean Pihet wrote:
> Hi,
>
> Here is a patch that redefines the power events API. The advantages
> are: easier maintainance of the kernel and the
> user space tools, a cleaner and more generic interface, more
> pa
On Wed, 2010-09-22 at 14:36 -0400, Steven Rostedt wrote:
> > I still don't see why you need TRACE_EVENT_ABI for that, if its the same
> > name and the format can be extended you get the same results with what
> > we've got. Apps need to read/parse the format thing anyway.
>
> Just a marker that th
On Wed, 2010-09-22 at 20:26 +0200, Peter Zijlstra wrote:
> On Wed, 2010-09-22 at 14:15 -0400, Steven Rostedt wrote:
> > On Wed, 2010-09-22 at 19:30 +0200, Peter Zijlstra wrote:
> > > On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote:
> > >
> >
> > > That said, I really didn't read this di
On Wednesday 22 September 2010 20:13:19 Arjan van de Ven wrote:
> On 9/22/2010 10:57 AM, Thomas Renninger wrote:
> > On Wed
> >> unfortunately this code is changing a userspace ABI... we really
> >> shouldn't do that if we can avoid it,
> >> and here we can avoid it.
>
> [do you really need to g
On Wed, 2010-09-22 at 20:23 +0200, Ingo Molnar wrote:
> * Steven Rostedt wrote:
>
> > We could add a TRACE_EVENT_ABI() as Ingo has been suggesting. [...]
>
> That would be rather useful.
>
> We could still be flexible about experimental tracepoints (they dont
> hurt), but apps should stick to
On Wed, 2010-09-22 at 14:15 -0400, Steven Rostedt wrote:
> On Wed, 2010-09-22 at 19:30 +0200, Peter Zijlstra wrote:
> > On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote:
> >
>
> > That said, I really didn't read this discussion much, but your stance
> > seems to be that any tracepoint yo
* Steven Rostedt wrote:
> We could add a TRACE_EVENT_ABI() as Ingo has been suggesting. [...]
That would be rather useful.
We could still be flexible about experimental tracepoints (they dont
hurt), but apps should stick to ABI bits - or at least not complain when
non-ABI tracepoints change
Wednesday 22 September 2010 08:53:19 Guennadi Liakhovetski napisał(a):
> That's up to the platform maintainer to review / apply this one, but if
> you like, a couple of nit-picks from me:
Guennadi,
Thanks for also looking at this!
> On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
> > This patch ad
On Wed, 2010-09-22 at 19:30 +0200, Peter Zijlstra wrote:
> On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote:
>
> That said, I really didn't read this discussion much, but your stance
> seems to be that any tracepoint you use must stay valid, and I object to
> that.
We could add a TRACE_
Wednesday 22 September 2010 01:23:22 Guennadi Liakhovetski napisał(a):
> On Sat, 11 Sep 2010, Janusz Krzysztofik wrote:
> > This is a V4L2 driver for TI OMAP1 SoC camera interface.
> >
> > Both videobuf-dma versions are supported, contig and sg, selectable with
> > a module option. The former uses
On 9/22/2010 10:57 AM, Thomas Renninger wrote:
On Wed
unfortunately this code is changing a userspace ABI... we really
shouldn't do that if we can avoid it,
and here we can avoid it.
[do you really need to get personal?]
Wow, this is your first post on this thread
it isn't.
(but I've bee
On Wednesday, September 22, 2010, Arjan van de Ven wrote:
> On 9/22/2010 8:31 AM, Jean Pihet wrote:
> > Hi,
> >
> > Here is a patch that redefines the power events API. The advantages
> > are: easier maintainance of the kernel and the
> > user space tools, a cleaner and more generic interface, mo
Hello.
kishore kadiyala wrote:
From: Benoit Cousson
Avoid possible crash if CONFIG_MMC_OMAP_HS is not set
Signed-off-by: Benoit Cousson
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/board-4430sdp.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git
On Wednesday 22 September 2010 17:33:01 Arjan van de Ven wrote:
> On 9/22/2010 8:31 AM, Jean Pihet wrote:
> > Hi,
> >
> > Here is a patch that redefines the power events API. The advantages
> > are: easier maintainance of the kernel and the
> > user space tools, a cleaner and more generic interfa
On Wednesday 22 September 2010 19:06:54 Arjan van de Ven wrote:
> On 9/22/2010 9:43 AM, Peter Zijlstra wrote:
> > On Wed, 2010-09-22 at 09:32 -0700, Arjan van de Ven wrote:
> >>> What are the apps that are using it? I know about builtin-timechart,
> >>> pytimechart. Is powertop using this as well
On Wed, 2010-09-22 at 10:06 -0700, Arjan van de Ven wrote:
> In this case we're talking about basically a suprious rename of
> something that isn't really an improvement
> (because it makes it harder to subscribe to only one type of event)...
> that's not a good thing.
People have been talking
Hi Madhu,
On Wed, Sep 22, 2010 at 12:13:51PM -0500, Madhusudhan wrote:
> Can you please drop this patch? Sorry, I spoke bit too early on this patch.
> I need to sort out some stuff internally (seems like it will not be released
> as an errata). I will post a revised version a bit later.
No proble
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Tuesday, September 21, 2010 9:47 AM
> To: Madhusudhan
> Cc: c...@laptop.org; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
> santosh.shilim...@ti.com
> Subject: Re: [PATCH] OMAP4: HSMMC cmd line reset ch
On 9/22/2010 9:43 AM, Peter Zijlstra wrote:
On Wed, 2010-09-22 at 09:32 -0700, Arjan van de Ven wrote:
What are the apps that are using it? I know about builtin-timechart,
pytimechart. Is powertop using this as well?
powertop 2.x codebase is as well.
and a bunch of tools we have internal here
Hi Govindraj,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Govindraj.R
> Sent: Wednesday, September 22, 2010 10:15 AM
> To: linux-omap@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; linux-ser...@vger.ke
On Wed, 2010-09-22 at 09:32 -0700, Arjan van de Ven wrote:
Also, please don't cross-post to subscriber only lists, that's annoying
as hell.
(removed the disc...@lesswatts list)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kern
On Wed, 2010-09-22 at 09:32 -0700, Arjan van de Ven wrote:
> > What are the apps that are using it? I know about builtin-timechart,
> > pytimechart. Is powertop using this as well?
>
> powertop 2.x codebase is as well.
>
> and a bunch of tools we have internal here at Intel.
>
> the thing with A
On OMAP4, MMC2 controller has eMMC which draws power from VAUX regulator
on TWL. Though the eMMC supports dual voltage[1.8v/3v] as per ocr register,
its VCC is fixed at 3V for operation. With this once the mmc core selects
the minimum voltage[1.8] supported based on the ocr value read from OCR
reg
From: Benoit Cousson
Avoid possible crash if CONFIG_MMC_OMAP_HS is not set
Signed-off-by: Benoit Cousson
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/board-4430sdp.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
In OMAP4, as per new PM programming model, the legacy registers
which were there in OMAP3 are all shifted by 0x100 while new one's
are added from offset 0 to 0x10.
For OMAP4, the register offset appending of 0x100 done in devices.c
currently, is moved to driver file.This change fits in for current
Adding card detect callback function and card detect configuration
function for MMC1 Controller on OMAP4.
Card detect configuration function does initial configuration of the
MMC Control & PullUp-PullDown registers of Phoenix.
For MMC1 Controller, card detect interrupt source is
twl6030 which is
The patch series is based on mainline 2.6.36-rc5.
The series is tested on OMAP3430SDP and OMAP4430SDP and has dependency on
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34718.html
V2:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35135.html
V1:
http://www.mail-archive.com
On 9/22/2010 8:36 AM, Jean Pihet wrote:
On Wed, Sep 22, 2010 at 5:33 PM, Arjan van de Ven wrote:
On 9/22/2010 8:31 AM, Jean Pihet wrote:
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space tools, a cleaner and mo
Hello.
Hema HK wrote:
OMAP USBOTG modules has a requirement to set the auto idle bit only after
setting smart idle bit. Modified the _sys_enable api to set the smart idle
first and then the autoidle bit. Setting this will not have any impact on the
other modules.
Signed-off-by: Hema HK
Sign
On Wed, 22 Sep 2010, Cousson, Benoit wrote:
> On 9/22/2010 8:43 AM, Nayak, Rajendra wrote:
> >
> > > From: Paul Walmsley [mailto:p...@pwsan.com]
> > > Sent: Wednesday, September 22, 2010 11:47 AM
> > >
> > > We should really get rid of all these 'BITFIELD' defines, and just replace
> > > them wi
On 9/22/2010 8:43 AM, Nayak, Rajendra wrote:
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, September 22, 2010 11:47 AM
Hi Rajendra
On Thu, 16 Sep 2010, Rajendra Nayak wrote:
This patch updates the PRM and CM register bitshifts and masks
for OMAP4430 ES2.0.
Signed-off-by: Raj
Hi Govindraj,
Just one non-functional comment below.
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Raja, Govindraj
> Sent: Wednesday, September 22, 2010 10:15 AM
> To: linux-omap@vger.kernel.org
> Cc: linux-arm-ker.
On Wed, 22 Sep 2010, Benoit Cousson wrote:
> - usim optional clock are its parent had the same name, rename the parent
> usim_fclk -> usim_ck
>
> - OPTFCLKEN_CLK32K is not handled anymore by the USBPHYOCP2SCP module in ES2
> Create a new clock that belongs to CM_ALWON_USBPHY_CLKCTRL register
>
>
- usim optional clock are its parent had the same name, rename the parent
usim_fclk -> usim_ck
- OPTFCLKEN_CLK32K is not handled anymore by the USBPHYOCP2SCP module in ES2
Create a new clock that belongs to CM_ALWON_USBPHY_CLKCTRL register
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Raj
On Wed, Sep 22, 2010 at 5:33 PM, Arjan van de Ven wrote:
> On 9/22/2010 8:31 AM, Jean Pihet wrote:
>>
>> Hi,
>>
>> Here is a patch that redefines the power events API. The advantages
>> are: easier maintainance of the kernel and the
>> user space tools, a cleaner and more generic interface, more
On Wed, 22 Sep 2010, Cousson, Benoit wrote:
> On 9/22/2010 9:33 AM, Paul Walmsley wrote:
> >
> > Hi Benoît, Rajendra,
> >
> > Here's the clock44xx_data.c that I ended up with, after applying the
> > recent patches. It seems to compare well with the autogenerator output,
> > but maybe you might
On 9/22/2010 8:31 AM, Jean Pihet wrote:
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space tools, a cleaner and more generic interface, more
parameters for fine tracing and even documentation!
Thomas, this patch has
Hi,
Here is a patch that redefines the power events API. The advantages
are: easier maintainance of the kernel and the
user space tools, a cleaner and more generic interface, more
parameters for fine tracing and even documentation!
Thomas, this patch has your patch above merged in ('power-trace:
Hello Sergei,
On Wed, 22 Sep 2010, Sergei Shtylyov wrote:
>This line is overindented...
Thanks, updated the patch (below).
- Paul
From 9980ce53c97392a3dbdc9d1ac3e455d79b4167ed Mon Sep 17 00:00:00 2001
From: Rajendra Nayak
Date: Tue, 21 Sep 2010 19:58:30 +0530
Subject: [PATCH] OMAP: hwmod
Tony,
Thanks for your comments.
> * Que, Simon [100811 17:22]:
> > Created driver for OMAP hardware spinlock.
> >
> > - Reserved spinlocks for internal use
> > - Dynamic allocation of unreserved locks
> > - Lock, unlock, and trylock functions, with or without disabling
> irqs/preempt
> > - R
Enable omap-serial driver in /mach-omap2/Kconfig and
move 8250 driver selection for zoom boards. With omap-serial
driver addition all omap-uarts can be handled with
omap-serial driver.
With addition of omap-serial driver console parameter
needs be changed in bootargs from ttyS* should be
replaced
Iniatize all omap-uarts for zoom boards.
Remove serial_init from 3630sdp board init
as zoom_peripheral_init does the same.
Signed-off-by: Kevin Hilman
Signed-off-by: Anand Gadiyar
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/board-3630sdp.c |1 -
arch/arm/mach-omap2/board-zo
This patch makes the following:
- Adds missing wakeup padding register handling.
- Fixes a hardcode to use PER module ONLY on UART3.
Signed-off-by: Kevin Hilman
Signed-off-by: Sergio Aguirre
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c |8 ++--
1 files changed, 6 inser
This patch adds driver support for OMAP2/3/4 high speed UART.
The driver is made separate from 8250 driver as we cannot
over load 8250 driver with omap platform specific configuration for
features like DMA, it makes easier to implement features like DMA and
hardware flow control and software flow
This is only valid for omap 36xx family of chips.
Signed-off-by: Sergio Aguirre
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/clock3xxx_data.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mac
To standarize among other uarts (1 to 3), we shall now:
- Enable uart4 autodile bit.
- Enable uart4 wakeup in PER.
- Allow uart4 to wakeup the MPU.
Signed-off-by: Sergio Aguirre
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
arch/arm/mach-omap2/pm34xx.c
Add prepare idle and resume idle call for uart4 used by 3630.
Cc: Kevin Hilman
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/pm34xx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 043faaa..60baffa
From: Kevin Hilman
Since the UART enable/idle is done during the idle path (with
interrupts disabled), use the non-locking versions of the hwmod
enable/idle functions.
Signed-off-by: Kevin Hilman
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c | 23 +--
1 fil
From: Kevin Hilman
Since the omap_device for UART is currently managed inside the idle
path itself, don't let the bus-level code suspend/resume the UART.
To prevent this, pm_runtime_get() is used when preparing for suspend
and pm_runtime_put() is used when finished with suspend.
Signed-off-by:
From: Kevin Hilman
This patch adds omap_hwmod data for UARTs on OMAP2 and OMAP3
platforms.
UART4 support for 3630 and OMAP2 hwmod data added by Govindraj R.
Signed-off-by: Kevin Hilman
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 193 +
arc
From: Kevin Hilman
Major rework of OMAP UART init for omap_device conversion as well as
use with either 8250 driver or new omap-serial driver.
In preparation for a new omap-serial driver, remove 8250 assumptions
and dependencies from the serial core.
Convert UART core and PM support to use omap
Remove set_uart_globals function as this will not be needed as
physical address for uarts will be taken from hwmod data file.
Cc: Kevin Hilman
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/serial.c |5 -
arch/arm/plat-omap/common.c | 16
From: Benoit Cousson
Add uart1-4 hwmod data into omap4_hwmod data file.
Signed-off-by: Benoit Cousson
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 235
1 files changed, 235 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-o
This patch series adds a serial driver to handle uarts on omap platforms.
Currenlty omap-uarts are handled with 8250 driver, since updating
this driver with omap specific features will over load
the 8250 driver with all omap-specific data thus a new driver
is added to configure and support features
Ohad,
Sorry for the late response, was away from linux-omap mailing list last few
days.
Please see my response.
>
> It would probably make more sense to call pm_runtime_get_sync during
> hwspinlock_request{_specific}, and then call pm_runtime_put during
> hwspinlock_free.
I agree, this looks l
>-Original Message-
>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: Wednesday, September 22, 2010 7:55 PM
>To: Kalliguddi, Hema
>Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha;
>Basak, Partha; Tero Kristo
>Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out
1 - 100 of 150 matches
Mail list logo
