[APPLIED] DSPBRIDGE: Camel case removal

[Omar Ramirez Luna]

Hi All,

Camel case removal patch was pushed into dspbridge branch.

This patch removes camel case symbols picked up by script found at:

http://marc.info/?l=linux-omap&m=125353475429517&w=2

It also has Lindent changes on top of it.

The count of modifications is as follows:
166 files changed, 21359 insertions(+), 20952 deletions(-)

Note: as this is a huge patch which changes big part of bridge code, 
when running checkpatch on it, it will alert of issues which were 
already present in the code.


Regards,

Omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap

[Peter Ujfalusi]

On Friday 12 March 2010 00:43:41 ext Mark Brown wrote:

> I can do, though there was some debate about how useful the
> information the hardware returns actually is - could folks confirm
> what the consensus there was, please?

Yeah, that thread went silent without final go or no go...

I do agree with Eero, that the BUFFSTAT register is not the most reliable 
source 
of information, but I still believe that the way we are going to use it will 
give pretty close to the reality estimation on the statuses.
Eero also mentioned timestamp based estimation, which I think can also be used 
in this way:
In element mode, we just return the delay as the whole size of the buffer 
(which 
is not accurate when we initially fill the buffer, and when we drain it at the 
end, but it is not a real problem).
In threshold mode, than we can take timestamp at DMA completion interrupts, and 
calculate the delay based on the FIFO size (FIFO size - samples played out 
since 
the last timstamp). This can also give false numbers at the start of the 
playback (for few periods, until the buffer utilization settles).

So the timestamp based solution looks good, but it is only usable when the 
codec 
is running synchronously. It will definitely falls apart as soon as we use a 
codec like tlv320dac33 in burst mode (FIFO on the codec as well).
We could have ~100 ms between DMA interrupts, so the countdown for McBSP FIFO 
usage is already broken.
Furthermore since there is no way at the moment to actually synchronize the 
omap-mcbsp, omap-pcm and tlv320dac33 (in DMA, McBSP threshold, McBSP mode and 
DAC33 mode sense), there could be cases, that this big silence on the bus (when 
DAC33 is playing from it's buffer) is not happening exactly after the DMA 
filled 
up the McBSP FIFO, but a bit later (could be just one sample away from the next 
McBSP threshold event), which means that the McBSP FIFO is nowhere near to be 
full.
In this case the BUFFSTAT register would give good estimation, than any 
timestamp based solution for McBSP FIFO.

All in all, I think the usage of the BUFFSTAT register is a good compromise for 
all cases, and it is needed for the cases, where the codec also have buffer of 
it's own.
Never the less, we can also add the timestamp based estimation later, but we 
need to make sure, that those can be picked somehow for the given setup.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] DSPBRIDGE: driver version 0.2

[Omar Ramirez Luna]

On 3/5/2010 11:11 PM, Ramirez Luna, Omar wrote:

driver version 0.2

Signed-off-by: Omar Ramirez Luna
---
  drivers/dsp/bridge/rmgr/drv_interface.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)



Pushed to dspbridge.

- omar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature

[Venkatraman S]

Madhusudhan wrote:
>
>
>> -Original Message-
>> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
>> Venkatraman S
>> Sent: Thursday, March 11, 2010 11:43 AM
>> To: Madhusudhan
>> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>> linux-omap@vger.kernel.org
>> Subject: Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
>> autoloading feature
>>
>> Madhusudhan  wrote:
>> >> -Original Message-
>> >> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
>> >> Venkatraman S
>> >> Sent: Thursday, March 11, 2010 4:52 AM
>> >> To: Madhusudhan
>> >> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>> >> linux-omap@vger.kernel.org
>> >> Subject: Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
>> >> autoloading feature
>> >>
>> >> Madhusudhan  wrote:
>> >> >> -Original Message-
>> >> >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> >> >> ow...@vger.kernel.org] On Behalf Of Venkatraman S
>> >> >> Sent: Monday, March 01, 2010 5:27 AM
>> >> >> To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>> >> >> linux-omap@vger.kernel.org
>> >> >> Subject: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
>> >> >> autoloading feature
>> >> >>
>> >> >> Start to use the sDMA descriptor autoloading feature.
>> >> >> For large datablocks, the MMC driver has to repeatedly setup,
>> program
>> >> >> and teardown the
>> >> >> dma channel for each element of the sglist received in
>> >> omap_hsmmc_request.
>> >> >>
>> >> >> By using descriptor autoloading, transfers from / to each element of
>> >> >> the sglist is pre programmed
>> >> >> into a linked list. The sDMA driver completes the entire transaction
>> >> >> and provides a single interrupt.
>> >> >>
>> >> >> Due to this, number of dma interrupts for a typical 100MB transfer
>> on
>> >> the
>> >> >> MMC is
>> >> >> reduced from 25000 to about 400 (approximate). Transfer speeds are
>> >> >> improved by ~5%
>> >> >> (Though it varies on the size of read / write & improves on huge
>> >> >> transfers)
>> >> >>
>> >> >> Descriptor autoloading is available only in 3630 and 4430 (as of
>> now).
>> >> >> Hence normal DMA
>> >> >> mode is also retained.
>> >> >>
>> >> >> Tested on omap4430 sdp.
>> >> >>
>> >> >> Signed-off-by: Venkatraman S 
>> >> >
>> >> > I don't see any issues with this patch except the concern I had on
>> the
>> >> first
>> >> > patch in the series. Why is that change linked to this series?
>> >> >
>> >>   Thanks. The problem was seen only in the context of using descriptor
>> >> load. Would
>> >> you prefer that I post it as a separate patch ?
>> >
>> > My point is why that change is needed for this feature to work?
>> >
>> > When DMA is completed and a callback is received the ch can be freed.
>> Once
>> > TC is received the core is notified of the same.
>> >
>> > Can the first patch be dropped? Or do you see issues?
>> Yes there are issues without this patch when the scatterlist is large
>> (300+ blocks), where the dma completion interrupt is received but the
>> mmc driver hangs waiting for TC. I don't see the issue if I delay the
>> execution of omap_free_dma inside the dma callback.
>
> This is strange. Ideally after the dma cb is received the transfer complete
> interrupt should fire.
>
> Your first patch would break a corner erroneous case the driver is already
> handling. A scenario where TC was received before DMA cb came. There is
> timeout logic in the driver which handles this case to let the request
> succeed if a dma cb was received after a while otherwise err out. See the
> function omap_hsmmc_start_dma_transfer.
>
> Is there a way to keep both the cases handled? If not we have to make
> changes based on which of these scenario is very odd.

   I think these cases are already handled properly. All actions are
taken if, and only if, TC is received.
Once TC is received, the sequence of execution is unaltered by DMA
callback. Dma callback
is effectively a no-op after the final block is transmitted.

   We can in fact get rid of the timeout logic. Of course, the DMA
channel is cleared
once the TC is received, hence there would be no spurious DMA callbacks during
the start of next transaction. [The only hanging case is when the TC
is never triggerred,
even after a successful transfer, but that's another issue altogether]

Regards,
Venkat.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Trying to understand how to use new OMAP mux code

[Premi, Sanjeev]

 
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Barada
> Sent: Friday, March 12, 2010 10:19 AM
> To: Tony Lindgren
> Cc: linux-omap@vger.kernel.org
> Subject: Re: Trying to understand how to use new OMAP mux code
> 
> On Thu, Mar 11, 2010 at 5:48 PM, Tony Lindgren 
>  wrote:
> > * Peter Barada  [100311 14:29]:
> >> 1) Suppose I want to talk to a bluetooth chip through 
> UART2.  UART2_TX
> >>  gives me a choice of pins to hook up to, either to pin 
> AA26 in Mode0,
> >> or pin AF5 in Mode1.  If I use omape_mux_init_signal("uart2_tx",
> >> OMAP_PIN_OUTPUT), which pin will that map to?
> >
> > You need to check the omap package type you're using to find
> > out the correct ball name. If you get lucky, that's already in
> > mux34xx.c and you don't need search through the TRMs :)
> 
> The ball name helps me to identify it, but if I understand correctly,
> none of the mux code allows the use of a ball name - I have to use the
> mode0 name of the ball I want to use (and as you say later qualified
> by the signal I want hooked up to that pi), right?
> 
> >> 2) How can I tell the muxing code that I want a specific pin for my
> >> UART2_TX signal (that's not a GPIO since those can be directly
> >> specified by GPIO number)?
> >
> > Then you want to use the full signal name:
> >
> > omap_mux_init_signal("mode0_name.desired_mode", OMAP_PIN_FLAGS)
> >
> > But as the balls can be separate for each package type, you
> > need to figure that out first.
> 
> If my board sets up the balls packaging right (for a 3530 CBB
> package), then "omap_mux_init_signal("mcbsp3_clkx.uart2_tx",
> OMAP_PIN_OUTPUT);", will setup pin AF5 as mode2, output - thereby
> muxing GPIO pin 142 to the UART2_TX signal?
> 
> Next question is for the AM3517 (491 pin), I see the setup for
> board-am3517evm int he 2.6.33-rc3 kernel refers to the CBB package
> which the comments indicate is a 515 pin package - is this the correct
> package to use for the AM3517?  Since I have to traverse from my
> schematic via ball name to signal name, it helps to know I'm looking
> at the right package list.
> 
> Also, it looks like the references in arch/arm/mach-omap2/mux24xx.c to
> TI forum URLs (e.g.  http://community.ti.com/forums/t/10982.aspx)
> takes you to http://e2e.ti.com/support/default.aspx - do you need a
> "myTI" login to see that forum message?.

No login is required. It is just that the forum backend has changed and
the original link would be leading to a HTTP404 redirecting you to the
main page. If we know the original title, search should help in locating
the original post.

Best regards,
Sanjeev

> 
> 
> > Regards,
> >
> > Tony
> >
> 
> So if I use: omap
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH FIX] OMAP: DSS: Fix for kernel crash during reboot

[hvaibhav]

From: Vaibhav Hiremath 

Kernel crash is observed when you include DSS, respctive drivers and issue
"reboot" command.
Added return from function omapdss_dpi_display_disable, if interface is already
disabled.

Crash Log -

r...@omap3evm:~# reboot

Broadcast message from root (ttyS0) (Fri Dec  4 03:51:10 2009):

The system is going down for reboot NOW!
INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal
INIT:Stopping telnet daemon.
Stopping syslogd/klogd: stopped syslogd (pid 1187)
stopped klogd (pid 1189)
done
Stopping thttpd.
NOT deconfiguring network interfaces: / is an NFS mount
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Unmounting remote filesystems...
Deactivating swap...
Unmounting local filesystems...
mount: can't find /mnt/ram in /proc/mounts
umount: none busy - remounted read-only
mount: cannot read /proc/mounts: No such file or directory
Rebooting... Unable to handle kernel NULL pointer dereference at virtual
address 007c
pgd = c7dac000
[007c] *pgd=87f52031, *pte=, *ppte=
Internal error: Oops: 17 [#1]
last sysfs file: /sys/kernel/uevent_seqnum
Modules linked in:
CPU: 0Not tainted  (2.6.34-rc1-07844-g49f7ae9-dirty #1)
PC is at omapdss_dpi_display_disable+0x14/0x3c
LR is at omapdss_dpi_display_disable+0x18/0x3c
pc : []lr : []psr: 6013
sp : c6ccde40  ip : fa07  fp : 
r10:   r9 : c6ccc000  r8 : c0030028
r7 : 0002  r6 :   r5 : c019d8e0  r4 : c03d7a98
r3 :   r2 :   r1 : 0002  r0 : 
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 87dac019  DAC: 0015
Process reboot (pid: 1237, stack limit = 0xc6ccc2e8)
Stack: (0xc6ccde40 to 0xc6cce000)
de40: c03d7a98 c01a5ea8  c019d8f0  c01c7e48 c7c44cf8 c7c84170
de60: c03d8ad8 c03da84c fee1dead c01c944c c03d8ad8 c01c5490  c0063f9c
de80:  c0063fdc  c0064178 c7f3d6c0 c0094168 00b4 
dea0:  c028a0e4 bee2fc90 00ee  03b8 c7dad000 
dec0: 0002 c6d54b20 c7c166c0 c7f3d6c0 400ee980 c7f3d6f4 0200 c7c166c0
dee0: c7f3d6c0 c0036560 c7e1c040 c0240700 c03cdfc4 c03ce034 0007 c6ccdfb0
df00: 400ee980 000121d8 c7e1c040 c7e1c0e0 c6c88740 c028bc08 c7e1c040 
df20: c6ccdf20 c6ccdf20 c789c6e8 c789db98  c00b7508 c7801398 c789db98
df40:  c00b4958 c789db98   c00b4fe0 0014 c00a74c8
df60:   c6c88740  c6f866c0 0006 c6c88740 
df80: c6f866c0 c00a45ec c6f866e8 c6f866c0 c6c88740  0001 0004
dfa0: 0058 c002fe80  0001 fee1dead 28121969 01234567 0002
dfc0:  0001 0004 0058 000121d0 0001 0001 
dfe0: 400f6710 bee2fcb8 92f0 400f6728 6010 fee1dead  
[] (omapdss_dpi_display_disable+0x14/0x3c) from []
(generic_panel_disable+0xc/0x18)
[] (generic_panel_disable+0xc/0x18) from []
(dss_disable_device+0x10/0x18)
[] (dss_disable_device+0x10/0x18) from []
(bus_for_each_dev+0x44/0x74)
[] (bus_for_each_dev+0x44/0x74) from []
(platform_drv_shutdown+0x18/0x1c)
[] (platform_drv_shutdown+0x18/0x1c) from []
(device_shutdown+0x54/0x84)
[] (device_shutdown+0x54/0x84) from []
(kernel_restart_prepare+0x24/0x34)
[] (kernel_restart_prepare+0x24/0x34) from []
(kernel_restart+0xc/0x40)
[] (kernel_restart+0xc/0x40) from []
(sys_reboot+0x160/0x1b8)
[] (sys_reboot+0x160/0x1b8) from []
(ret_fast_syscall+0x0/0x2c)
Code: e59031a4 e1a04000 e1a3 e1a0e00f (e593f07c)
***[ end trace c52dd0f51f03150e ]***

Signed-off-by: Vaibhav Hiremath 
---
 drivers/video/omap2/dss/dpi.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 960e977..70c6902 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -210,6 +210,9 @@ EXPORT_SYMBOL(omapdss_dpi_display_enable);

 void omapdss_dpi_display_disable(struct omap_dss_device *dssdev)
 {
+   if (dssdev->state == OMAP_DSS_DISPLAY_DISABLED)
+   return;
+
dssdev->manager->disable(dssdev->manager);

 #ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
--
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 17/19] omap: Add DSI regulator supply to OMAP3EVM board file

[Hiremath, Vaibhav]

> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Friday, March 12, 2010 5:19 AM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Tomi Valkeinen; linux-omap@vger.kernel.org; Hiremath, Vaibhav
> Subject: [PATCH 17/19] omap: Add DSI regulator supply to OMAP3EVM board file
> 
> From: Vaibhav Hiremath 
> 
> With recent changes happened in OMAP2/3 DSS library for regulator interface,
> it
> is required to define DSI regulator supply, without this DSS (in turn Fbdev)
> fails to get regulator.
> 
> Signed-off-by: Vaibhav Hiremath 
> Acked-by: Tomi Valkeinen 
> Signed-off-by: Tony Lindgren 
> ---
>  arch/arm/mach-omap2/board-omap3evm.c |   16 +++-
>  1 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
> omap2/board-omap3evm.c
> index 017bb2f..a05de10 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -514,9 +514,15 @@ static struct regulator_init_data omap3_evm_vdac = {
>  };
> 
>  /* VPLL2 for digital video outputs */
> -static struct regulator_consumer_supply omap3_evm_vpll2_supply = {
> - .supply = "vdvi",
> - .dev= &omap3_evm_lcd_device.dev,
> +static struct regulator_consumer_supply omap3_evm_vpll2_supplies[] = {
> + {
> + .supply = "vdvi",
> + .dev= &omap3_evm_lcd_device.dev,
> + },
> + {
> + .supply = "vdds_dsi",
> + .dev= &omap3_evm_dss_device.dev,
> + },
>  };
> 
>  static struct regulator_init_data omap3_evm_vpll2 = {
> @@ -530,8 +536,8 @@ static struct regulator_init_data omap3_evm_vpll2 = {
>   .valid_ops_mask = REGULATOR_CHANGE_MODE
>   | REGULATOR_CHANGE_STATUS,
>   },
> - .num_consumer_supplies  = 1,
> - .consumer_supplies  = &omap3_evm_vpll2_supply,
> + .num_consumer_supplies  = ARRAY_SIZE(omap3_evm_vpll2_supplies),
> + .consumer_supplies  = omap3_evm_vpll2_supplies,
>  };
> 
>  static struct twl4030_platform_data omap3evm_twldata = {
[Hiremath, Vaibhav] Tony,
Please use the patch below, I have fixed Mark's comments to use devname instead 
of dev.

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index ea1014b..f5c815a 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -514,10 +514,8 @@ static struct regulator_init_data omap3_evm_vdac = {
 };

 /* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply omap3_evm_vpll2_supply = {
-   .supply = "vdds_dsi",
-   .dev= &omap3_evm_dss_device.dev,
-};
+static struct regulator_consumer_supply omap3_evm_vpll2_supply =
+   REGULATOR_SUPPLY("vdds_dsi", "omapdss");

 static struct regulator_init_data omap3_evm_vpll2 = {
.constraints = {


[Hiremath, Vaibhav] Since you have already merged the patch , I have created 
patch on top of linux-omap/master below.



diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index a05de10..f5c815a 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -514,16 +514,8 @@ static struct regulator_init_data omap3_evm_vdac = {
 };

 /* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply omap3_evm_vpll2_supplies[] = {
-   {
-   .supply = "vdvi",
-   .dev= &omap3_evm_lcd_device.dev,
-   },
-   {
-   .supply = "vdds_dsi",
-   .dev= &omap3_evm_dss_device.dev,
-   },
-};
+static struct regulator_consumer_supply omap3_evm_vpll2_supply =
+   REGULATOR_SUPPLY("vdds_dsi", "omapdss");

 static struct regulator_init_data omap3_evm_vpll2 = {
.constraints = {
@@ -536,8 +528,8 @@ static struct regulator_init_data omap3_evm_vpll2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
-   .num_consumer_supplies  = ARRAY_SIZE(omap3_evm_vpll2_supplies),
-   .consumer_supplies  = omap3_evm_vpll2_supplies,
+   .num_consumer_supplies  = 1,
+   .consumer_supplies  = &omap3_evm_vpll2_supply,
 };

 static struct twl4030_platform_data omap3evm_twldata = {
diff --git a/drivers/mtd/maps/omap_nor.c b/drivers/mtd/maps/omap_nor.c
deleted file mode 100644
index e69de29..000

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Trying to understand how to use new OMAP mux code

[Peter Barada]

On Thu, Mar 11, 2010 at 5:48 PM, Tony Lindgren  wrote:
> * Peter Barada  [100311 14:29]:
>> 1) Suppose I want to talk to a bluetooth chip through UART2.  UART2_TX
>>  gives me a choice of pins to hook up to, either to pin AA26 in Mode0,
>> or pin AF5 in Mode1.  If I use omape_mux_init_signal("uart2_tx",
>> OMAP_PIN_OUTPUT), which pin will that map to?
>
> You need to check the omap package type you're using to find
> out the correct ball name. If you get lucky, that's already in
> mux34xx.c and you don't need search through the TRMs :)

The ball name helps me to identify it, but if I understand correctly,
none of the mux code allows the use of a ball name - I have to use the
mode0 name of the ball I want to use (and as you say later qualified
by the signal I want hooked up to that pi), right?

>> 2) How can I tell the muxing code that I want a specific pin for my
>> UART2_TX signal (that's not a GPIO since those can be directly
>> specified by GPIO number)?
>
> Then you want to use the full signal name:
>
> omap_mux_init_signal("mode0_name.desired_mode", OMAP_PIN_FLAGS)
>
> But as the balls can be separate for each package type, you
> need to figure that out first.

If my board sets up the balls packaging right (for a 3530 CBB
package), then "omap_mux_init_signal("mcbsp3_clkx.uart2_tx",
OMAP_PIN_OUTPUT);", will setup pin AF5 as mode2, output - thereby
muxing GPIO pin 142 to the UART2_TX signal?

Next question is for the AM3517 (491 pin), I see the setup for
board-am3517evm int he 2.6.33-rc3 kernel refers to the CBB package
which the comments indicate is a 515 pin package - is this the correct
package to use for the AM3517?  Since I have to traverse from my
schematic via ball name to signal name, it helps to know I'm looking
at the right package list.

Also, it looks like the references in arch/arm/mach-omap2/mux24xx.c to
TI forum URLs (e.g.  http://community.ti.com/forums/t/10982.aspx)
takes you to http://e2e.ti.com/support/default.aspx - do you need a
"myTI" login to see that forum message?.


> Regards,
>
> Tony
>

So if I use: omap
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature

[Madhusudhan]

> -Original Message-
> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
> Venkatraman S
> Sent: Thursday, March 11, 2010 11:43 AM
> To: Madhusudhan
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-omap@vger.kernel.org
> Subject: Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
> autoloading feature
> 
> Madhusudhan  wrote:
> >> -Original Message-
> >> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
> >> Venkatraman S
> >> Sent: Thursday, March 11, 2010 4:52 AM
> >> To: Madhusudhan
> >> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >> linux-omap@vger.kernel.org
> >> Subject: Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
> >> autoloading feature
> >>
> >> Madhusudhan  wrote:
> >> >> -Original Message-
> >> >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> >> >> ow...@vger.kernel.org] On Behalf Of Venkatraman S
> >> >> Sent: Monday, March 01, 2010 5:27 AM
> >> >> To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >> >> linux-omap@vger.kernel.org
> >> >> Subject: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
> >> >> autoloading feature
> >> >>
> >> >> Start to use the sDMA descriptor autoloading feature.
> >> >> For large datablocks, the MMC driver has to repeatedly setup,
> program
> >> >> and teardown the
> >> >> dma channel for each element of the sglist received in
> >> omap_hsmmc_request.
> >> >>
> >> >> By using descriptor autoloading, transfers from / to each element of
> >> >> the sglist is pre programmed
> >> >> into a linked list. The sDMA driver completes the entire transaction
> >> >> and provides a single interrupt.
> >> >>
> >> >> Due to this, number of dma interrupts for a typical 100MB transfer
> on
> >> the
> >> >> MMC is
> >> >> reduced from 25000 to about 400 (approximate). Transfer speeds are
> >> >> improved by ~5%
> >> >> (Though it varies on the size of read / write & improves on huge
> >> >> transfers)
> >> >>
> >> >> Descriptor autoloading is available only in 3630 and 4430 (as of
> now).
> >> >> Hence normal DMA
> >> >> mode is also retained.
> >> >>
> >> >> Tested on omap4430 sdp.
> >> >>
> >> >> Signed-off-by: Venkatraman S 
> >> >
> >> > I don't see any issues with this patch except the concern I had on
> the
> >> first
> >> > patch in the series. Why is that change linked to this series?
> >> >
> >>   Thanks. The problem was seen only in the context of using descriptor
> >> load. Would
> >> you prefer that I post it as a separate patch ?
> >
> > My point is why that change is needed for this feature to work?
> >
> > When DMA is completed and a callback is received the ch can be freed.
> Once
> > TC is received the core is notified of the same.
> >
> > Can the first patch be dropped? Or do you see issues?
> Yes there are issues without this patch when the scatterlist is large
> (300+ blocks), where the dma completion interrupt is received but the
> mmc driver hangs waiting for TC. I don't see the issue if I delay the
> execution of omap_free_dma inside the dma callback.

This is strange. Ideally after the dma cb is received the transfer complete
interrupt should fire.

Your first patch would break a corner erroneous case the driver is already
handling. A scenario where TC was received before DMA cb came. There is
timeout logic in the driver which handles this case to let the request
succeed if a dma cb was received after a while otherwise err out. See the
function omap_hsmmc_start_dma_transfer.

Is there a way to keep both the cases handled? If not we have to make
changes based on which of these scenario is very odd.

Regards,
Madhu

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] OMAP3 : clock data: Update name string for EMAC clocks.

[Paul Walmsley]

On Thu, 11 Mar 2010, Sriramakrishnan wrote:

> The emac driver uses generic name for the module and phy
> clocks. Updated the omap3xxx_clks table to match the names
> used by the Davinci emac driver.
> 
> Signed-off-by: Sriramakrishnan 

Acked-by: Paul Walmsley 

At some point, someone should go through that davinci_emac.c driver and 
change the DaVinci references to "TI" or something generic, now that this 
core exists on DaVinci, OMAP, etc.

> ---
>  arch/arm/mach-omap2/clock3xxx_data.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
> b/arch/arm/mach-omap2/clock3xxx_data.c
> index d5153b6..989da2e 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3472,8 +3472,8 @@ static struct omap_clk omap3xxx_clks[] = {
>   CLK(NULL,   "ipss_ick", &ipss_ick,  CK_AM35XX),
>   CLK(NULL,   "rmii_ck",  &rmii_ck,   CK_AM35XX),
>   CLK(NULL,   "pclk_ck",  &pclk_ck,   CK_AM35XX),
> - CLK("davinci_emac", "ick",  &emac_ick,  CK_AM35XX),
> - CLK("davinci_emac", "fck",  &emac_fck,  CK_AM35XX),
> + CLK("davinci_emac", "emac_clk", &emac_ick,  CK_AM35XX),
> + CLK("davinci_emac", "phy_clk",  &emac_fck,  CK_AM35XX),
>   CLK("vpfe-capture", "master",   &vpfe_ick,  CK_AM35XX),
>   CLK("vpfe-capture", "slave",&vpfe_fck,  CK_AM35XX),
>   CLK("musb_hdrc","ick",  &hsotgusb_ick_am35xx,   
> CK_AM35XX),
> -- 
> 1.6.2.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] [I2C-OMAP] Add support for 16-bit registers

[Tony Lindgren]

* Kevin Hilman  [100311 08:36]:
> Tony Lindgren  writes:
> >
> > Anyways, for the future, considering how critical this driver is
> > for all omaps.. And considering how badly this driver needs some
> > updates done..
> >
> > How about we pile up the i2c-omap patches for testing into linux-omap
> > branch first, then ask Ben to pull it around -rc6 after we've all
> > acked and tested the changes?
> >
> > Ben does that sound OK to you?
> 
> Here's another one to add to omap-testing then.
> 
> This one has been submitted to linux-i2c a couple times and been in
> the OMAP PM branch for a while.

OK, let's add that to omap-testing after we're done with the initial
fixes. This does not currently apply on top of omap-testing, BTW.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 19b/19] ARM/OMAP: Remove the +x bit from a couple of source files

[Tony Lindgren]

>From 5aeb05c97c94f03627ad6983a0b5069ea539d084 Mon Sep 17 00:00:00 2001
From: Andrew Clayton 
Date: Sat, 6 Mar 2010 00:14:46 +
Subject: [PATCH] ARM/OMAP: Remove the +x bit from a couple of source files

Remove the +x bit from a couple of source files

Signed-off-by: Andrew Clayton 
Signed-off-by: Tony Lindgren 

diff --git a/arch/arm/mach-omap2/board-3630sdp.c 
b/arch/arm/mach-omap2/board-3630sdp.c
old mode 100755
new mode 100644
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c 
b/arch/arm/mach-omap2/board-zoom-peripherals.c
old mode 100755
new mode 100644
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 19/19] omap: McBSP: Drop unnecessary status/error bit clearing on reg_cacheretrieved register values

[Tony Lindgren]

* Tony Lindgren  [100311 16:04]:
> From eee91441bf26c6ea88656eb9866e706b1e07d30b Mon Sep 17 00:00:00 2001
> From: Janusz Krzysztofik 
> Date: Tue, 23 Feb 2010 15:50:38 +
> Subject: [PATCH] omap: McBSP: Drop unnecessary status/error bit clearing on 
> reg_cacheretrieved register values
> 
> The MsBSP register cache will never have any error/status flags set, since
> these flags are never written to the reg_cache. So it is kind of not
> necessary to clear these flags, which are actually always 0.
> 
> In other words, clearing the status/error flags are not necessary, since the
> reg_cache will never got these bits set. We can just write back the
> register content from the cache as it is when clearing an error condition.
> 
> Tested on Amstrad Delta.

And this one is really patch 18/19. Sorry again.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 18/19] omap: Add DSI regulator supply to OMAP3EVM board file

[Tony Lindgren]

* Tony Lindgren  [100311 15:55]:
> From 9c7ceeb2621349f180be4779d954352bcc8df9cd Mon Sep 17 00:00:00 2001
> From: Vaibhav Hiremath 
> Date: Thu, 11 Mar 2010 08:55:17 +
> Subject: [PATCH] omap: Add DSI regulator supply to OMAP3EVM board file
> 
> With recent changes happened in OMAP2/3 DSS library for regulator interface, 
> it
> is required to define DSI regulator supply, without this DSS (in turn Fbdev)
> fails to get regulator.

Oops, had to manually send the last two messages.. This is already
at 17/18, so please ignore.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 12/19] omap: Fix gpio_resume_after_retention

[Aguirre, Sergio]

> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Thursday, March 11, 2010 5:57 PM
> To: Aguirre, Sergio
> Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
> Subject: Re: [PATCH 12/19] omap: Fix gpio_resume_after_retention
> 
> * Aguirre, Sergio  [100311 15:47]:
> > Hi Tony,
> >
> > > -Original Message-
> > > From: Tony Lindgren [mailto:t...@atomide.com]
> > > Sent: Thursday, March 11, 2010 5:49 PM
> > > To: linux-arm-ker...@lists.infradead.org
> > > Cc: Aguirre, Sergio; linux-omap@vger.kernel.org
> > > Subject: [PATCH 12/19] omap: Fix gpio_resume_after_retention
> > >
> > > From: Tony Lindgren 
> >
> > Something funky mix happened with the authorship here :)
> >
> > Should be:
> >
> > From: Sergio Aguirre 
> 
> Thanks, updated patch below.
> 
> I think this issue is related to applying patches from
> patchwork.kernel.org with email addresses in Lastname, Firstname
> format..

Hmm... I see.

I normally send my patches with this alias:

alias gsend='git send-email --smtp-server /usr/bin/msmtp --from "Sergio Aguirre 
" --envelope-sender="Sergio Aguirre "'

and then just do:

gsend --to='linux-omap@vger.kernel.org' 
patches/forLO_20100311/0001-mypatch.patch

But somehow the patch ends up (I'm guessing through TI LDAP server) changing 
that to "Aguirre, Sergio"...

and also Patchworks seems to continue display my old fullname: "Aguirre 
Rodriguez, Sergio Alberto"... I guess it's in a static data cache somewhere, 
maybe?

Does anyone know how to overcome this kind of scenario, and force what --from 
param says?

Regards,
Sergio

> 
> Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 19/19] omap: McBSP: Drop unnecessary status/error bit clearing on reg_cacheretrieved register values

[Tony Lindgren]

>From eee91441bf26c6ea88656eb9866e706b1e07d30b Mon Sep 17 00:00:00 2001
From: Janusz Krzysztofik 
Date: Tue, 23 Feb 2010 15:50:38 +
Subject: [PATCH] omap: McBSP: Drop unnecessary status/error bit clearing on 
reg_cacheretrieved register values

The MsBSP register cache will never have any error/status flags set, since
these flags are never written to the reg_cache. So it is kind of not
necessary to clear these flags, which are actually always 0.

In other words, clearing the status/error flags are not necessary, since the
reg_cache will never got these bits set. We can just write back the
register content from the cache as it is when clearing an error condition.

Tested on Amstrad Delta.

Reported-by: Peter Ujfalusi 
Signed-off-by: Janusz Krzysztofik 
Acked-by: Jarkko Nikula 
Signed-off-by: Tony Lindgren 

diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e47686e..52dfcc8 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -133,8 +133,7 @@ static irqreturn_t omap_mcbsp_tx_irq_handler(int irq, void 
*dev_id)
dev_err(mcbsp_tx->dev, "TX Frame Sync Error! : 0x%x\n",
irqst_spcr2);
/* Writing zero to XSYNC_ERR clears the IRQ */
-   MCBSP_WRITE(mcbsp_tx, SPCR2,
-   MCBSP_READ_CACHE(mcbsp_tx, SPCR2) & ~(XSYNC_ERR));
+   MCBSP_WRITE(mcbsp_tx, SPCR2, MCBSP_READ_CACHE(mcbsp_tx, SPCR2));
} else {
complete(&mcbsp_tx->tx_irq_completion);
}
@@ -154,8 +153,7 @@ static irqreturn_t omap_mcbsp_rx_irq_handler(int irq, void 
*dev_id)
dev_err(mcbsp_rx->dev, "RX Frame Sync Error! : 0x%x\n",
irqst_spcr1);
/* Writing zero to RSYNC_ERR clears the IRQ */
-   MCBSP_WRITE(mcbsp_rx, SPCR1,
-   MCBSP_READ_CACHE(mcbsp_rx, SPCR1) & ~(RSYNC_ERR));
+   MCBSP_WRITE(mcbsp_rx, SPCR1, MCBSP_READ_CACHE(mcbsp_rx, SPCR1));
} else {
complete(&mcbsp_rx->tx_irq_completion);
}
@@ -934,8 +932,7 @@ int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
/* if frame sync error - clear the error */
if (MCBSP_READ(mcbsp, SPCR2) & XSYNC_ERR) {
/* clear error */
-   MCBSP_WRITE(mcbsp, SPCR2,
-   MCBSP_READ_CACHE(mcbsp, SPCR2) & (~XSYNC_ERR));
+   MCBSP_WRITE(mcbsp, SPCR2, MCBSP_READ_CACHE(mcbsp, SPCR2));
/* resend */
return -1;
} else {
@@ -975,8 +972,7 @@ int omap_mcbsp_pollread(unsigned int id, u16 *buf)
/* if frame sync error - clear the error */
if (MCBSP_READ(mcbsp, SPCR1) & RSYNC_ERR) {
/* clear error */
-   MCBSP_WRITE(mcbsp, SPCR1,
-   MCBSP_READ_CACHE(mcbsp, SPCR1) & (~RSYNC_ERR));
+   MCBSP_WRITE(mcbsp, SPCR1, MCBSP_READ_CACHE(mcbsp, SPCR1));
/* resend */
return -1;
} else {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 18/19] omap: Add DSI regulator supply to OMAP3EVM board file

[Tony Lindgren]

>From 9c7ceeb2621349f180be4779d954352bcc8df9cd Mon Sep 17 00:00:00 2001
From: Vaibhav Hiremath 
Date: Thu, 11 Mar 2010 08:55:17 +
Subject: [PATCH] omap: Add DSI regulator supply to OMAP3EVM board file

With recent changes happened in OMAP2/3 DSS library for regulator interface, it
is required to define DSI regulator supply, without this DSS (in turn Fbdev)
fails to get regulator.

Signed-off-by: Vaibhav Hiremath 
Acked-by: Tomi Valkeinen 
Signed-off-by: Tony Lindgren 

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 017bb2f..a05de10 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -514,9 +514,15 @@ static struct regulator_init_data omap3_evm_vdac = {
 };
 
 /* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply omap3_evm_vpll2_supply = {
-   .supply = "vdvi",
-   .dev= &omap3_evm_lcd_device.dev,
+static struct regulator_consumer_supply omap3_evm_vpll2_supplies[] = {
+   {
+   .supply = "vdvi",
+   .dev= &omap3_evm_lcd_device.dev,
+   },
+   {
+   .supply = "vdds_dsi",
+   .dev= &omap3_evm_dss_device.dev,
+   },
 };
 
 static struct regulator_init_data omap3_evm_vpll2 = {
@@ -530,8 +536,8 @@ static struct regulator_init_data omap3_evm_vpll2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
-   .num_consumer_supplies  = 1,
-   .consumer_supplies  = &omap3_evm_vpll2_supply,
+   .num_consumer_supplies  = ARRAY_SIZE(omap3_evm_vpll2_supplies),
+   .consumer_supplies  = omap3_evm_vpll2_supplies,
 };
 
 static struct twl4030_platform_data omap3evm_twldata = {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 12/19] omap: Fix gpio_resume_after_retention

[Tony Lindgren]

* Aguirre, Sergio  [100311 15:47]:
> Hi Tony,
> 
> > -Original Message-
> > From: Tony Lindgren [mailto:t...@atomide.com]
> > Sent: Thursday, March 11, 2010 5:49 PM
> > To: linux-arm-ker...@lists.infradead.org
> > Cc: Aguirre, Sergio; linux-omap@vger.kernel.org
> > Subject: [PATCH 12/19] omap: Fix gpio_resume_after_retention
> > 
> > From: Tony Lindgren 
> 
> Something funky mix happened with the authorship here :)
> 
> Should be:
> 
> From: Sergio Aguirre 

Thanks, updated patch below.

I think this issue is related to applying patches from
patchwork.kernel.org with email addresses in Lastname, Firstname
format..

Tony
>From f00d649703fbedbdeb33d63c4c4731656e11297c Mon Sep 17 00:00:00 2001
From: Sergio Aguirre 
Date: Wed, 3 Mar 2010 16:21:08 +
Subject: [PATCH] omap: Fix gpio_resume_after_retention

For omap4 case, this was wrongly writing GPIO_LEVELDETECTx
registers with OMAP24XX_ offset and OMAP4_ offset.

Bug introduced in commit:

  commit 3f1686a9bfe74979c6ad538c78039730f665f77e
  Author: Tony Lindgren 
  Date:   Mon Feb 15 09:27:25 2010 -0800

  omap: Fix gpio.c for multi-omap for omap4

Signed-off-by: Sergio Aguirre 
Signed-off-by: Tony Lindgren 

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 337199e..76a347b 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2140,18 +2140,18 @@ void omap2_gpio_resume_after_retention(void)
 		if (gen) {
 			u32 old0, old1;
 
-			if (cpu_is_omap24xx() || cpu_is_omap44xx()) {
+			if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
 old0 = __raw_readl(bank->base +
 	OMAP24XX_GPIO_LEVELDETECT0);
 old1 = __raw_readl(bank->base +
 	OMAP24XX_GPIO_LEVELDETECT1);
-			__raw_writel(old0 | gen, bank->base +
+__raw_writel(old0 | gen, bank->base +
 	OMAP24XX_GPIO_LEVELDETECT0);
-			__raw_writel(old1 | gen, bank->base +
+__raw_writel(old1 | gen, bank->base +
 	OMAP24XX_GPIO_LEVELDETECT1);
-			__raw_writel(old0, bank->base +
+__raw_writel(old0, bank->base +
 	OMAP24XX_GPIO_LEVELDETECT0);
-			__raw_writel(old1, bank->base +
+__raw_writel(old1, bank->base +
 	OMAP24XX_GPIO_LEVELDETECT1);
 			}
 

RE: [PATCH 12/19] omap: Fix gpio_resume_after_retention

[Aguirre, Sergio]

Hi Tony,

> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Thursday, March 11, 2010 5:49 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Aguirre, Sergio; linux-omap@vger.kernel.org
> Subject: [PATCH 12/19] omap: Fix gpio_resume_after_retention
> 
> From: Tony Lindgren 

Something funky mix happened with the authorship here :)

Should be:

From: Sergio Aguirre 

Regards,
Sergio

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 17/19] omap: Add DSI regulator supply to OMAP3EVM board file

[Tony Lindgren]

From: Vaibhav Hiremath 

With recent changes happened in OMAP2/3 DSS library for regulator interface, it
is required to define DSI regulator supply, without this DSS (in turn Fbdev)
fails to get regulator.

Signed-off-by: Vaibhav Hiremath 
Acked-by: Tomi Valkeinen 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-omap3evm.c |   16 +++-
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 017bb2f..a05de10 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -514,9 +514,15 @@ static struct regulator_init_data omap3_evm_vdac = {
 };
 
 /* VPLL2 for digital video outputs */
-static struct regulator_consumer_supply omap3_evm_vpll2_supply = {
-   .supply = "vdvi",
-   .dev= &omap3_evm_lcd_device.dev,
+static struct regulator_consumer_supply omap3_evm_vpll2_supplies[] = {
+   {
+   .supply = "vdvi",
+   .dev= &omap3_evm_lcd_device.dev,
+   },
+   {
+   .supply = "vdds_dsi",
+   .dev= &omap3_evm_dss_device.dev,
+   },
 };
 
 static struct regulator_init_data omap3_evm_vpll2 = {
@@ -530,8 +536,8 @@ static struct regulator_init_data omap3_evm_vpll2 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
-   .num_consumer_supplies  = 1,
-   .consumer_supplies  = &omap3_evm_vpll2_supply,
+   .num_consumer_supplies  = ARRAY_SIZE(omap3_evm_vpll2_supplies),
+   .consumer_supplies  = omap3_evm_vpll2_supplies,
 };
 
 static struct twl4030_platform_data omap3evm_twldata = {

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 16/19] OMAP4: fix temporary hacks that break multi-omap PM

[Tony Lindgren]

From: Kevin Hilman 

When building for multi-omap, and OMAP4 is enabled, CONFIG_ARCH_OMAP4
will be true and prevent included code from building/running for
OMAP2/3 as well.

This problem exists in io.c where some hwmod/PM/SDRC init code is
prevented from running even on OMAP2/3 when OMAP4 is included in a
multi-OMAP build.

A quick glance suggests that this #ifndef is no longer needed in most
of the cases.  In the remaining cases, the function is wrapped with
"if (cpu_is_omap24xx() || cpu_is_omap34xx())" which will be optimized
out for OMAP4-only builds.

Note that this is only a short-term fix.  Longer-term, OMAP4
needs to create init functions for SDRC and hwmod late-init.

Tested-by: Santosh Shilimkar 
Signed-off-by: Kevin Hilman 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/io.c |   13 ++---
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index ae89d55..87f676a 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -309,7 +309,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params 
*sdrc_cs0,
 {
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_autodeps);
-#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once the clkdev is ready */
if (cpu_is_omap242x())
omap2420_hwmod_init();
else if (cpu_is_omap243x())
@@ -319,7 +318,6 @@ void __init omap2_init_common_hw(struct omap_sdrc_params 
*sdrc_cs0,
omap2_mux_init();
/* The OPP tables have to be registered before a clk init */
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
-#endif
 
if (cpu_is_omap2420())
omap2420_clk_init();
@@ -333,11 +331,12 @@ void __init omap2_init_common_hw(struct omap_sdrc_params 
*sdrc_cs0,
pr_err("Could not init clock framework - unknown CPU\n");
 
omap_serial_early_init();
-#ifndef CONFIG_ARCH_OMAP4
-   omap_hwmod_late_init();
+   if (cpu_is_omap24xx() || cpu_is_omap34xx())   /* FIXME: OMAP4 */
+   omap_hwmod_late_init();
omap_pm_if_init();
-   omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
-   _omap2_init_reprogram_sdrc();
-#endif
+   if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+   omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
+   _omap2_init_reprogram_sdrc();
+   }
gpmc_init();
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 15/19] OMAP2: cpu_is_omap2*: fix compile-time removal of unused code

[Tony Lindgren]

From: Kevin Hilman 

Currently if omap2420 is defined but not omap2430, cpu_is_omap2430()
is still defined as a macro, instead of #define'd to zero.  This
results in conditional cpu_is_omap2430() code still being compiled,
and leads to possible compile/link errors.  In particular for hwmod
init.

To fix, add extra #ifdefs to CPU check macros to ensure that the
is_omap* macros are zero for each OMAP2 if they are not configured
into the kernel.

Tested-by: Santosh Shilimkar 
Signed-off-by: Kevin Hilman 
Signed-off-by: Tony Lindgren 
---
 arch/arm/plat-omap/include/plat/cpu.h |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
b/arch/arm/plat-omap/include/plat/cpu.h
index ed8786c..7514174 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -167,10 +167,14 @@ IS_OMAP_SUBCLASS(443x, 0x443)
 #if defined(MULTI_OMAP2)
 # if defined(CONFIG_ARCH_OMAP2)
 #  undef  cpu_is_omap24xx
-#  undef  cpu_is_omap242x
-#  undef  cpu_is_omap243x
 #  define cpu_is_omap24xx()is_omap24xx()
+# endif
+# if defined (CONFIG_ARCH_OMAP2420)
+#  undef  cpu_is_omap242x
 #  define cpu_is_omap242x()is_omap242x()
+# endif
+# if defined (CONFIG_ARCH_OMAP2430)
+#  undef  cpu_is_omap243x
 #  define cpu_is_omap243x()is_omap243x()
 # endif
 # if defined(CONFIG_ARCH_OMAP3)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 14/19] omap3: pandora: add missing i2c3 board_info

[Tony Lindgren]

From: Grazvydas Ignotas 

This will allow BQ27500 fuel gauge to function.

Signed-off-by: Grazvydas Ignotas 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-omap3pandora.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
index 51a5315..395d049 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -459,12 +459,20 @@ static struct i2c_board_info __initdata 
omap3pandora_i2c_boardinfo[] = {
},
 };
 
+static struct i2c_board_info __initdata omap3pandora_i2c3_boardinfo[] = {
+   {
+   I2C_BOARD_INFO("bq27500", 0x55),
+   .flags = I2C_CLIENT_WAKE,
+   },
+};
+
 static int __init omap3pandora_i2c_init(void)
 {
omap_register_i2c_bus(1, 2600, omap3pandora_i2c_boardinfo,
ARRAY_SIZE(omap3pandora_i2c_boardinfo));
/* i2c2 pins are not connected */
-   omap_register_i2c_bus(3, 100, NULL, 0);
+   omap_register_i2c_bus(3, 100, omap3pandora_i2c3_boardinfo,
+   ARRAY_SIZE(omap3pandora_i2c3_boardinfo));
return 0;
 }
 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/19] omap: mach-omap2/io.c: fix function declarations

[Tony Lindgren]

From: Aaro Koskinen 

Get rid of the following warnings:

warning: non-ANSI function declaration of function [...]

Signed-off-by: Aaro Koskinen 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/io.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 402e8f0..ae89d55 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -237,7 +237,7 @@ static void __init _omap2_map_common_io(void)
 }
 
 #ifdef CONFIG_ARCH_OMAP2420
-void __init omap242x_map_common_io()
+void __init omap242x_map_common_io(void)
 {
iotable_init(omap24xx_io_desc, ARRAY_SIZE(omap24xx_io_desc));
iotable_init(omap242x_io_desc, ARRAY_SIZE(omap242x_io_desc));
@@ -246,7 +246,7 @@ void __init omap242x_map_common_io()
 #endif
 
 #ifdef CONFIG_ARCH_OMAP2430
-void __init omap243x_map_common_io()
+void __init omap243x_map_common_io(void)
 {
iotable_init(omap24xx_io_desc, ARRAY_SIZE(omap24xx_io_desc));
iotable_init(omap243x_io_desc, ARRAY_SIZE(omap243x_io_desc));
@@ -255,7 +255,7 @@ void __init omap243x_map_common_io()
 #endif
 
 #ifdef CONFIG_ARCH_OMAP3
-void __init omap34xx_map_common_io()
+void __init omap34xx_map_common_io(void)
 {
iotable_init(omap34xx_io_desc, ARRAY_SIZE(omap34xx_io_desc));
_omap2_map_common_io();
@@ -263,7 +263,7 @@ void __init omap34xx_map_common_io()
 #endif
 
 #ifdef CONFIG_ARCH_OMAP4
-void __init omap44xx_map_common_io()
+void __init omap44xx_map_common_io(void)
 {
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
_omap2_map_common_io();

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/19] omap: Fix gpio_resume_after_retention

[Tony Lindgren]

From: Tony Lindgren 

For omap4 case, this was wrongly writing GPIO_LEVELDETECTx
registers with OMAP24XX_ offset and OMAP4_ offset.

Bug introduced in commit:

  commit 3f1686a9bfe74979c6ad538c78039730f665f77e
  Author: Tony Lindgren 
  Date:   Mon Feb 15 09:27:25 2010 -0800

  omap: Fix gpio.c for multi-omap for omap4

Signed-off-by: Sergio Aguirre 
Signed-off-by: Tony Lindgren 
---
 arch/arm/plat-omap/gpio.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 337199e..76a347b 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2140,18 +2140,18 @@ void omap2_gpio_resume_after_retention(void)
if (gen) {
u32 old0, old1;
 
-   if (cpu_is_omap24xx() || cpu_is_omap44xx()) {
+   if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
old0 = __raw_readl(bank->base +
OMAP24XX_GPIO_LEVELDETECT0);
old1 = __raw_readl(bank->base +
OMAP24XX_GPIO_LEVELDETECT1);
-   __raw_writel(old0 | gen, bank->base +
+   __raw_writel(old0 | gen, bank->base +
OMAP24XX_GPIO_LEVELDETECT0);
-   __raw_writel(old1 | gen, bank->base +
+   __raw_writel(old1 | gen, bank->base +
OMAP24XX_GPIO_LEVELDETECT1);
-   __raw_writel(old0, bank->base +
+   __raw_writel(old0, bank->base +
OMAP24XX_GPIO_LEVELDETECT0);
-   __raw_writel(old1, bank->base +
+   __raw_writel(old1, bank->base +
OMAP24XX_GPIO_LEVELDETECT1);
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/19] omap3: Fix support for the LEDs connected to GPIO outputs on IGEP v2board

[Tony Lindgren]

From: Enric Balletbo i Serra 

Select CONFIG_LEDS_GPIO to enable IGEP v2 LED support and control of supported
LEDs from userspace. Otherwise GPIO LEDs are exported as GPIO 26, 27 and 28 
using
the gpiolib framework.

Signed-off-by: Enric Balletbo i Serra 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-igep0020.c |   54 +++---
 1 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 4f1accf..3c7789d 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -39,8 +38,8 @@
 #define IGEP2_SMSC911X_CS   5
 #define IGEP2_SMSC911X_GPIO 176
 #define IGEP2_GPIO_USBH_NRESET  24
-#define IGEP2_GPIO_LED0_RED26
-#define IGEP2_GPIO_LED0_GREEN  27
+#define IGEP2_GPIO_LED0_GREEN  26
+#define IGEP2_GPIO_LED0_RED27
 #define IGEP2_GPIO_LED1_RED28
 #define IGEP2_GPIO_DVI_PUP 170
 #define IGEP2_GPIO_WIFI_NPD94
@@ -355,34 +354,50 @@ static void __init igep2_display_init(void)
gpio_direction_output(IGEP2_GPIO_DVI_PUP, 1))
pr_err("IGEP v2: Could not obtain gpio GPIO_DVI_PUP\n");
 }
-#ifdef CONFIG_LEDS_TRIGGERS
-static struct gpio_led gpio_leds[] = {
+
+#if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
+#include 
+
+static struct gpio_led igep2_gpio_leds[] = {
{
-   .name = "GPIO_LED1_RED",
+   .name = "led0:red",
+   .gpio = IGEP2_GPIO_LED0_RED,
+   },
+   {
+   .name = "led0:green",
.default_trigger = "heartbeat",
+   .gpio = IGEP2_GPIO_LED0_GREEN,
+   },
+   {
+   .name = "led1:red",
.gpio = IGEP2_GPIO_LED1_RED,
},
 };
 
-static struct gpio_led_platform_data gpio_leds_info = {
-   .leds   = gpio_leds,
-   .num_leds   = ARRAY_SIZE(gpio_leds),
+static struct gpio_led_platform_data igep2_led_pdata = {
+   .leds   = igep2_gpio_leds,
+   .num_leds   = ARRAY_SIZE(igep2_gpio_leds),
 };
 
-static struct platform_device leds_gpio = {
+static struct platform_device igep2_led_device = {
 .name   = "leds-gpio",
 .id = -1,
 .dev= {
-.platform_data  =  &gpio_leds_info,
+.platform_data  =  &igep2_led_pdata,
},
 };
+
+static void __init igep2_init_led(void)
+{
+   platform_device_register(&igep2_led_device);
+}
+
+#else
+static inline void igep2_init_led(void) {}
 #endif
 
 static struct platform_device *igep2_devices[] __initdata = {
&igep2_dss_device,
-#ifdef CONFIG_LEDS_TRIGGERS
-   &leds_gpio,
-#endif
 };
 
 static void __init igep2_init_irq(void)
@@ -471,31 +486,34 @@ static void __init igep2_init(void)
usb_ehci_init(&ehci_pdata);
 
igep2_flash_init();
+   igep2_init_led();
igep2_display_init();
igep2_init_smsc911x();
 
/* GPIO userspace leds */
-   if ((gpio_request(IGEP2_GPIO_LED0_RED, "GPIO_LED0_RED") == 0) &&
+#if !defined(CONFIG_LEDS_GPIO) && !defined(CONFIG_LEDS_GPIO_MODULE)
+   if ((gpio_request(IGEP2_GPIO_LED0_RED, "led0:red") == 0) &&
(gpio_direction_output(IGEP2_GPIO_LED0_RED, 1) == 0)) {
gpio_export(IGEP2_GPIO_LED0_RED, 0);
gpio_set_value(IGEP2_GPIO_LED0_RED, 0);
} else
pr_warning("IGEP v2: Could not obtain gpio GPIO_LED0_RED\n");
 
-   if ((gpio_request(IGEP2_GPIO_LED0_GREEN, "GPIO_LED0_GREEN") == 0) &&
+   if ((gpio_request(IGEP2_GPIO_LED0_GREEN, "led0:green") == 0) &&
(gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 1) == 0)) {
gpio_export(IGEP2_GPIO_LED0_GREEN, 0);
gpio_set_value(IGEP2_GPIO_LED0_GREEN, 0);
} else
pr_warning("IGEP v2: Could not obtain gpio GPIO_LED0_GREEN\n");
-#ifndef CONFIG_LEDS_TRIGGERS
-   if ((gpio_request(IGEP2_GPIO_LED1_RED, "GPIO_LED1_RED") == 0) &&
+
+   if ((gpio_request(IGEP2_GPIO_LED1_RED, "led1:red") == 0) &&
(gpio_direction_output(IGEP2_GPIO_LED1_RED, 1) == 0)) {
gpio_export(IGEP2_GPIO_LED1_RED, 0);
gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
} else
pr_warning("IGEP v2: Could not obtain gpio GPIO_LED1_RED\n");
 #endif
+
/* GPIO W-LAN + Bluetooth combo module */
if ((gpio_request(IGEP2_GPIO_WIFI_NPD, "GPIO_WIFI_NPD") == 0) &&
(gpio_direction_output(IGEP2_GPIO_WIFI_NPD, 1) == 0)) {

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 10/19] omap: Checkpatch cleanup for blizzard.h

[Tony Lindgren]

From: Andrea Gelmini 

arch/arm/plat-omap/include/plat/blizzard.h:9:
ERROR: spaces prohibited around that ':' (ctx:WxW)

Signed-off-by: Andrea Gelmini 
Signed-off-by: Tony Lindgren 
---
 arch/arm/plat-omap/include/plat/blizzard.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/blizzard.h 
b/arch/arm/plat-omap/include/plat/blizzard.h
index 8d160f1..56e7f2e 100644
--- a/arch/arm/plat-omap/include/plat/blizzard.h
+++ b/arch/arm/plat-omap/include/plat/blizzard.h
@@ -6,7 +6,7 @@ struct blizzard_platform_data {
void(*power_down)(struct device *dev);
unsigned long   (*get_clock_rate)(struct device *dev);
 
-   unsignedte_connected : 1;
+   unsignedte_connected:1;
 };
 
 #endif

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/19] omap: pass the reboot command to the boot loader

[Tony Lindgren]

From: Aaro Koskinen 

This patch follows the commit be093beb608edf821b45fe00a8a080fb5c6ed4af
by Russell King:

  OMAP wishes to pass state to the boot loader upon reboot in order
  to instruct it whether to wait for USB-based reflashing or not.
  There is already a facility to do this via the reboot() syscall,
  except we ignore the string passed to machine_restart().

The patch adds the missing parameter to omap1_arch_reset() and
omap_prcm_arch_reset(), and modifies the latter to pass the reboot
command parameter to the boot loader instead of reboot mode (which is
for kernel internal use only and cannot be modified by the userspace).

Signed-off-by: Aaro Koskinen 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/prcm.c   |4 ++--
 arch/arm/plat-omap/include/plat/prcm.h   |2 +-
 arch/arm/plat-omap/include/plat/system.h |6 +++---
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 81872aa..9537f6f 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -133,7 +133,7 @@ u32 omap_prcm_get_reset_sources(void)
 EXPORT_SYMBOL(omap_prcm_get_reset_sources);
 
 /* Resets clock rates and reboots the system. Only called from system.h */
-void omap_prcm_arch_reset(char mode)
+void omap_prcm_arch_reset(char mode, const char *cmd)
 {
s16 prcm_offs = 0;
 
@@ -145,7 +145,7 @@ void omap_prcm_arch_reset(char mode)
u32 l;
 
prcm_offs = OMAP3430_GR_MOD;
-   l = ('B' << 24) | ('M' << 16) | mode;
+   l = ('B' << 24) | ('M' << 16) | (cmd ? (u8)*cmd : 0);
/* Reserve the first word in scratchpad for communicating
 * with the boot ROM. A pointer to a data structure
 * describing the boot process can be stored there,
diff --git a/arch/arm/plat-omap/include/plat/prcm.h 
b/arch/arm/plat-omap/include/plat/prcm.h
index d6a0e27..9fbd914 100644
--- a/arch/arm/plat-omap/include/plat/prcm.h
+++ b/arch/arm/plat-omap/include/plat/prcm.h
@@ -24,7 +24,7 @@
 #define __ASM_ARM_ARCH_OMAP_PRCM_H
 
 u32 omap_prcm_get_reset_sources(void);
-void omap_prcm_arch_reset(char mode);
+void omap_prcm_arch_reset(char mode, const char *cmd);
 int omap2_cm_wait_idlest(void __iomem *reg, u32 mask, u8 idlest,
 const char *name);
 
diff --git a/arch/arm/plat-omap/include/plat/system.h 
b/arch/arm/plat-omap/include/plat/system.h
index c58a4ef..d0a119f 100644
--- a/arch/arm/plat-omap/include/plat/system.h
+++ b/arch/arm/plat-omap/include/plat/system.h
@@ -22,7 +22,7 @@ static inline void arch_idle(void)
cpu_do_idle();
 }
 
-static inline void omap1_arch_reset(char mode)
+static inline void omap1_arch_reset(char mode, const char *cmd)
 {
/*
 * Workaround for 5912/1611b bug mentioned in sprz209d.pdf p. 28
@@ -43,9 +43,9 @@ static inline void omap1_arch_reset(char mode)
 static inline void arch_reset(char mode, const char *cmd)
 {
if (!cpu_class_is_omap2())
-   omap1_arch_reset(mode);
+   omap1_arch_reset(mode, cmd);
else
-   omap_prcm_arch_reset(mode);
+   omap_prcm_arch_reset(mode, cmd);
 }
 
 #endif

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/19] omap2/3/4: mailbox: remove compiler warning

[Tony Lindgren]

From: Suman Anna 

Remove a compiler warning in device-specific
mailbox module.

Signed-off-by: Suman Anna 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/mailbox.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 52a981c..318f363 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -430,19 +430,19 @@ static int __devinit omap2_mbox_probe(struct 
platform_device *pdev)
if (unlikely(!res)) {
dev_err(&pdev->dev, "invalid irq resource\n");
ret = -ENODEV;
-   goto err_iva1;
+   omap_mbox_unregister(&mbox_dsp_info);
+   goto err_dsp;
}
mbox_iva_info.irq = res->start;
ret = omap_mbox_register(&pdev->dev, &mbox_iva_info);
-   if (ret)
-   goto err_iva1;
+   if (ret) {
+   omap_mbox_unregister(&mbox_dsp_info);
+   goto err_dsp;
+   }
}
 #endif
return 0;
 
-err_iva1:
-   omap_mbox_unregister(&mbox_dsp_info);
-
 err_dsp:
iounmap(mbox_base);
return ret;

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/19] OMAP2: serial.c: Fix number of uarts in early_init

[Tony Lindgren]

From: Thomas Weber 

The omap_serial_early_init prints the following errors:

Could not get uart4_ick
Could not get uart4_fck

because all the uarts available in omap_uart[] will be initialized.
Only omap4430 and omap3630 have 4 uarts at the moment.
This patch reduces the number of uarts when cpu is not omap4430 or
omap3630.

Signed-off-by: Thomas Weber 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/serial.c |   15 ++-
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index b79bc89..da77930 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -644,16 +644,21 @@ static void serial_out_override(struct uart_port *up, int 
offset, int value)
 }
 void __init omap_serial_early_init(void)
 {
-   int i;
+   int i, nr_ports;
char name[16];
 
+   if (!(cpu_is_omap3630() || cpu_is_omap4430()))
+   nr_ports = 3;
+   else
+   nr_ports = ARRAY_SIZE(omap_uart);
+
/*
 * Make sure the serial ports are muxed on at this point.
 * You have to mux them off in device drivers later on
 * if not needed.
 */
 
-   for (i = 0; i < ARRAY_SIZE(omap_uart); i++) {
+   for (i = 0; i < nr_ports; i++) {
struct omap_uart_state *uart = &omap_uart[i];
struct platform_device *pdev = &uart->pdev;
struct device *dev = &pdev->dev;
@@ -669,17 +674,17 @@ void __init omap_serial_early_init(void)
continue;
}
 
-   sprintf(name, "uart%d_ick", i+1);
+   sprintf(name, "uart%d_ick", i + 1);
uart->ick = clk_get(NULL, name);
if (IS_ERR(uart->ick)) {
-   printk(KERN_ERR "Could not get uart%d_ick\n", i+1);
+   printk(KERN_ERR "Could not get uart%d_ick\n", i + 1);
uart->ick = NULL;
}
 
sprintf(name, "uart%d_fck", i+1);
uart->fck = clk_get(NULL, name);
if (IS_ERR(uart->fck)) {
-   printk(KERN_ERR "Could not get uart%d_fck\n", i+1);
+   printk(KERN_ERR "Could not get uart%d_fck\n", i + 1);
uart->fck = NULL;
}
 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/19] omap: Enable PM_RUNTIME in defconfigs to avoid USB compile errors

[Tony Lindgren]

While waiting for the related USB patch, fix compile by enabling
it in the defconfigs. As discussed at:

http://thread.gmane.org/gmane.linux.usb.general/27432/focus=4460

Otherwise we'll get errors like:

drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in this 
function)
drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is reported 
only once
drivers/usb/core/hcd.c:1892: error: for each function it appears in.)

Signed-off-by: Tony Lindgren 
---
 arch/arm/configs/cm_t35_defconfig  |2 +-
 arch/arm/configs/n770_defconfig|1 +
 arch/arm/configs/omap3_beagle_defconfig|1 +
 arch/arm/configs/omap3_defconfig   |2 +-
 arch/arm/configs/omap3_evm_defconfig   |1 +
 arch/arm/configs/omap3_touchbook_defconfig |2 +-
 arch/arm/configs/omap_3430sdp_defconfig|1 +
 arch/arm/configs/omap_3630sdp_defconfig|2 +-
 arch/arm/configs/omap_h2_1610_defconfig|1 +
 arch/arm/configs/omap_zoom2_defconfig  |1 +
 arch/arm/configs/omap_zoom3_defconfig  |2 +-
 arch/arm/configs/rx51_defconfig|1 +
 12 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm/configs/cm_t35_defconfig 
b/arch/arm/configs/cm_t35_defconfig
index 893cd26..032b49b 100644
--- a/arch/arm/configs/cm_t35_defconfig
+++ b/arch/arm/configs/cm_t35_defconfig
@@ -358,7 +358,7 @@ CONFIG_PM_SLEEP=y
 CONFIG_SUSPEND=y
 CONFIG_SUSPEND_FREEZER=y
 # CONFIG_APM_EMULATION is not set
-# CONFIG_PM_RUNTIME is not set
+CONFIG_PM_RUNTIME=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_NET=y
 
diff --git a/arch/arm/configs/n770_defconfig b/arch/arm/configs/n770_defconfig
index 75cae18..de0c28a 100644
--- a/arch/arm/configs/n770_defconfig
+++ b/arch/arm/configs/n770_defconfig
@@ -308,6 +308,7 @@ CONFIG_PM_SLEEP=y
 CONFIG_SUSPEND_UP_POSSIBLE=y
 CONFIG_SUSPEND=y
 # CONFIG_APM_EMULATION is not set
+CONFIG_PM_RUNTIME=y
 
 #
 # Networking
diff --git a/arch/arm/configs/omap3_beagle_defconfig 
b/arch/arm/configs/omap3_beagle_defconfig
index c7999f5..5a9e95f 100644
--- a/arch/arm/configs/omap3_beagle_defconfig
+++ b/arch/arm/configs/omap3_beagle_defconfig
@@ -324,6 +324,7 @@ CONFIG_PM_SLEEP=y
 CONFIG_SUSPEND=y
 CONFIG_SUSPEND_FREEZER=y
 # CONFIG_APM_EMULATION is not set
+CONFIG_PM_RUNTIME=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_NET=y
 
diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig
index 714835e..d6ad921 100644
--- a/arch/arm/configs/omap3_defconfig
+++ b/arch/arm/configs/omap3_defconfig
@@ -450,7 +450,7 @@ CONFIG_SUSPEND=y
 # CONFIG_PM_TEST_SUSPEND is not set
 CONFIG_SUSPEND_FREEZER=y
 # CONFIG_APM_EMULATION is not set
-# CONFIG_PM_RUNTIME is not set
+CONFIG_PM_RUNTIME=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_NET=y
 
diff --git a/arch/arm/configs/omap3_evm_defconfig 
b/arch/arm/configs/omap3_evm_defconfig
index e2ad859..a6dd6d1 100644
--- a/arch/arm/configs/omap3_evm_defconfig
+++ b/arch/arm/configs/omap3_evm_defconfig
@@ -340,6 +340,7 @@ CONFIG_PM_SLEEP=y
 CONFIG_SUSPEND=y
 CONFIG_SUSPEND_FREEZER=y
 # CONFIG_APM_EMULATION is not set
+CONFIG_PM_RUNTIME=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_NET=y
 
diff --git a/arch/arm/configs/omap3_touchbook_defconfig 
b/arch/arm/configs/omap3_touchbook_defconfig
index 74fe6be..968fbaa 100644
--- a/arch/arm/configs/omap3_touchbook_defconfig
+++ b/arch/arm/configs/omap3_touchbook_defconfig
@@ -368,7 +368,7 @@ CONFIG_SUSPEND=y
 # CONFIG_PM_TEST_SUSPEND is not set
 CONFIG_SUSPEND_FREEZER=y
 # CONFIG_APM_EMULATION is not set
-# CONFIG_PM_RUNTIME is not set
+CONFIG_PM_RUNTIME=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_NET=y
 
diff --git a/arch/arm/configs/omap_3430sdp_defconfig 
b/arch/arm/configs/omap_3430sdp_defconfig
index bb2917e..ddde429 100644
--- a/arch/arm/configs/omap_3430sdp_defconfig
+++ b/arch/arm/configs/omap_3430sdp_defconfig
@@ -363,6 +363,7 @@ CONFIG_PM_SLEEP=y
 CONFIG_SUSPEND=y
 CONFIG_SUSPEND_FREEZER=y
 # CONFIG_APM_EMULATION is not set
+CONFIG_PM_RUNTIME=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_NET=y
 
diff --git a/arch/arm/configs/omap_3630sdp_defconfig 
b/arch/arm/configs/omap_3630sdp_defconfig
index d25c3d4..609f348 100644
--- a/arch/arm/configs/omap_3630sdp_defconfig
+++ b/arch/arm/configs/omap_3630sdp_defconfig
@@ -361,7 +361,7 @@ CONFIG_SUSPEND=y
 # CONFIG_PM_TEST_SUSPEND is not set
 CONFIG_SUSPEND_FREEZER=y
 # CONFIG_APM_EMULATION is not set
-# CONFIG_PM_RUNTIME is not set
+CONFIG_PM_RUNTIME=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_NET=y
 
diff --git a/arch/arm/configs/omap_h2_1610_defconfig 
b/arch/arm/configs/omap_h2_1610_defconfig
index 5231895..91ef2ed 100644
--- a/arch/arm/configs/omap_h2_1610_defconfig
+++ b/arch/arm/configs/omap_h2_1610_defconfig
@@ -331,6 +331,7 @@ CONFIG_PM_SLEEP=y
 CONFIG_SUSPEND=y
 CONFIG_SUSPEND_FREEZER=y
 # CONFIG_APM_EMULATION is not set
+CONFIG_PM_RUNTIME=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 
 #
diff --git a/arch/arm/configs/omap_zoom2_defconfig 
b/arch/arm/configs/omap_zoom2_defconfig
index a82e813..f5c6e11 100644
--- a

[PATCH 05/19] omap2: Update n8x0 defconfig to test multi-omap and DMA api changes

[Tony Lindgren]

Recent DMA API changes broke compile for tusb6010. While
testing the fixes for tusb6010, I had to update the n8x0
defconfig quite a bit. Might as well merge it while at it
to make it more usable as we're using this to test the
multi-omap booting between V6 and V7 ARMs.

Also, anybody using n8x0 with a current kernel will most
likely want to mount root on the MMC instead of the onenand
to keep the Maemo install intact.

Enable I2C, REGULATOR, MMC, MFD, PM, and USB. Also change the root
to /dev/mmcblk0p2 instead of the onenand.

Signed-off-by: Tony Lindgren 
---
 arch/arm/configs/n8x0_defconfig |  160 +++
 1 files changed, 142 insertions(+), 18 deletions(-)

diff --git a/arch/arm/configs/n8x0_defconfig b/arch/arm/configs/n8x0_defconfig
index e6f667c..216ad00 100644
--- a/arch/arm/configs/n8x0_defconfig
+++ b/arch/arm/configs/n8x0_defconfig
@@ -191,6 +191,7 @@ CONFIG_ARCH_OMAP=y
 #
 CONFIG_ARCH_OMAP_OTG=y
 # CONFIG_ARCH_OMAP1 is not set
+CONFIG_ARCH_OMAP2PLUS=y
 CONFIG_ARCH_OMAP2=y
 # CONFIG_ARCH_OMAP3 is not set
 # CONFIG_ARCH_OMAP4 is not set
@@ -198,8 +199,6 @@ CONFIG_ARCH_OMAP2=y
 #
 # OMAP Feature Selections
 #
-# CONFIG_OMAP_DEBUG_POWERDOMAIN is not set
-# CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set
 CONFIG_OMAP_RESET_CLOCKS=y
 # CONFIG_OMAP_MUX is not set
 # CONFIG_OMAP_MCBSP is not set
@@ -208,15 +207,13 @@ CONFIG_OMAP_MBOX_FWK=y
 CONFIG_OMAP_32K_TIMER=y
 CONFIG_OMAP_32K_TIMER_HZ=128
 CONFIG_OMAP_DM_TIMER=y
-# CONFIG_OMAP_LL_DEBUG_UART1 is not set
-# CONFIG_OMAP_LL_DEBUG_UART2 is not set
-CONFIG_OMAP_LL_DEBUG_UART3=y
+# CONFIG_OMAP_PM_NONE is not set
+CONFIG_OMAP_PM_NOOP=y
 # CONFIG_MACH_OMAP_GENERIC is not set
 
 #
 # OMAP Core Type
 #
-CONFIG_ARCH_OMAP24XX=y
 CONFIG_ARCH_OMAP2420=y
 # CONFIG_ARCH_OMAP2430 is not set
 
@@ -227,6 +224,9 @@ CONFIG_MACH_OMAP2_TUSB6010=y
 # CONFIG_MACH_OMAP_H4 is not set
 # CONFIG_MACH_OMAP_APOLLON is not set
 # CONFIG_MACH_OMAP_2430SDP is not set
+CONFIG_MACH_NOKIA_N800=y
+CONFIG_MACH_NOKIA_N810=y
+CONFIG_MACH_NOKIA_N810_WIMAX=y
 CONFIG_MACH_NOKIA_N8X0=y
 
 #
@@ -303,7 +303,7 @@ CONFIG_ALIGNMENT_TRAP=y
 CONFIG_ZBOOT_ROM_TEXT=0x10C08000
 CONFIG_ZBOOT_ROM_BSS=0x1020
 # CONFIG_ZBOOT_ROM is not set
-CONFIG_CMDLINE="root=1f03 rootfstype=jffs2 console=ttyS2,115200n8"
+CONFIG_CMDLINE="root=/dev/mmcblk0p2 console=ttyS2,115200n8 debug earlyprintk 
rootwait"
 # CONFIG_XIP_KERNEL is not set
 # CONFIG_KEXEC is not set
 
@@ -337,7 +337,14 @@ CONFIG_HAVE_AOUT=y
 #
 # Power management options
 #
-# CONFIG_PM is not set
+CONFIG_PM=y
+# CONFIG_PM_DEBUG is not set
+CONFIG_PM_SLEEP=y
+CONFIG_SUSPEND=y
+CONFIG_SUSPEND_FREEZER=y
+# CONFIG_APM_EMULATION is not set
+CONFIG_PM_RUNTIME=y
+CONFIG_PM_OPS=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_NET=y
 
@@ -617,7 +624,55 @@ CONFIG_UNIX98_PTYS=y
 # CONFIG_R3964 is not set
 # CONFIG_RAW_DRIVER is not set
 # CONFIG_TCG_TPM is not set
-# CONFIG_I2C is not set
+CONFIG_I2C=y
+CONFIG_I2C_BOARDINFO=y
+# CONFIG_I2C_COMPAT is not set
+# CONFIG_I2C_CHARDEV is not set
+# CONFIG_I2C_HELPER_AUTO is not set
+# CONFIG_I2C_SMBUS is not set
+
+#
+# I2C Algorithms
+#
+# CONFIG_I2C_ALGOBIT is not set
+# CONFIG_I2C_ALGOPCF is not set
+# CONFIG_I2C_ALGOPCA is not set
+
+#
+# I2C Hardware Bus support
+#
+
+#
+# I2C system bus drivers (mostly embedded / system-on-chip)
+#
+# CONFIG_I2C_DESIGNWARE is not set
+# CONFIG_I2C_GPIO is not set
+# CONFIG_I2C_OCORES is not set
+CONFIG_I2C_OMAP=y
+# CONFIG_I2C_SIMTEC is not set
+# CONFIG_I2C_XILINX is not set
+
+#
+# External I2C/SMBus adapter drivers
+#
+# CONFIG_I2C_PARPORT_LIGHT is not set
+# CONFIG_I2C_TAOS_EVM is not set
+# CONFIG_I2C_TINY_USB is not set
+
+#
+# Other I2C/SMBus bus drivers
+#
+# CONFIG_I2C_PCA_PLATFORM is not set
+# CONFIG_I2C_STUB is not set
+
+#
+# Miscellaneous I2C Chip support
+#
+# CONFIG_SENSORS_TSL2550 is not set
+# CONFIG_I2C_DEBUG_CORE is not set
+# CONFIG_I2C_DEBUG_ALGO is not set
+# CONFIG_I2C_DEBUG_BUS is not set
+# CONFIG_I2C_DEBUG_CHIP is not set
 CONFIG_SPI=y
 # CONFIG_SPI_DEBUG is not set
 CONFIG_SPI_MASTER=y
@@ -673,15 +728,44 @@ CONFIG_SSB_POSSIBLE=y
 # Multifunction device drivers
 #
 # CONFIG_MFD_CORE is not set
+# CONFIG_MFD_88PM860X is not set
 # CONFIG_MFD_SM501 is not set
 # CONFIG_MFD_ASIC3 is not set
 # CONFIG_HTC_EGPIO is not set
 # CONFIG_HTC_PASIC3 is not set
+# CONFIG_HTC_I2CPLD is not set
+# CONFIG_TPS65010 is not set
+CONFIG_MENELAUS=y
+# CONFIG_TWL4030_CORE is not set
 # CONFIG_MFD_TMIO is not set
 # CONFIG_MFD_T7L66XB is not set
 # CONFIG_MFD_TC6387XB is not set
 # CONFIG_MFD_TC6393XB is not set
+# CONFIG_PMIC_DA903X is not set
+# CONFIG_PMIC_ADP5520 is not set
+# CONFIG_MFD_MAX8925 is not set
+# CONFIG_MFD_WM8400 is not set
+# CONFIG_MFD_WM831X is not set
+# CONFIG_MFD_WM8350_I2C is not set
+# CONFIG_MFD_WM8994 is not set
+# CONFIG_MFD_PCF50633 is not set
+# CONFIG_MFD_MC13783 is not set
+# CONFIG_AB3100_CORE is not set
 # CONFIG_EZX_PCAP is not set
+# CONFIG_AB4500_CORE is not set
+CONFIG_REGULATOR=y
+# CONFIG_REGULATOR_DEBUG is not set

[PATCH 04/19] omap2: add USB initialization for tusb6010

[Tony Lindgren]

From: Francisco Alecrim 

Based on Kalle's and Tony's patches. Some variables re-organized
and unused code removed.

Signed-off-by: Kalle Valo 
Signed-off-by: Francisco Alecrim 
[t...@atomide.com: this is needed to fix the related tusb6010 DMA API changes]
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-n8x0.c |   98 ++
 arch/arm/mach-omap2/clock2420_data.c |1 
 2 files changed, 99 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 4cab052..da9bcb8 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -37,6 +37,103 @@ static int slot1_cover_open;
 static int slot2_cover_open;
 static struct device *mmc_device;
 
+#define TUSB6010_ASYNC_CS  1
+#define TUSB6010_SYNC_CS   4
+#define TUSB6010_GPIO_INT  58
+#define TUSB6010_GPIO_ENABLE   0
+#define TUSB6010_DMACHAN   0x3f
+
+#if defined(CONFIG_USB_TUSB6010) || \
+   defined(CONFIG_USB_TUSB6010_MODULE)
+/*
+ * Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
+ * 1.5 V voltage regulators of PM companion chip. Companion chip will then
+ * provide then PGOOD signal to TUSB6010 which will release it from reset.
+ */
+static int tusb_set_power(int state)
+{
+   int i, retval = 0;
+
+   if (state) {
+   gpio_set_value(TUSB6010_GPIO_ENABLE, 1);
+   msleep(1);
+
+   /* Wait until TUSB6010 pulls INT pin down */
+   i = 100;
+   while (i && gpio_get_value(TUSB6010_GPIO_INT)) {
+   msleep(1);
+   i--;
+   }
+
+   if (!i) {
+   printk(KERN_ERR "tusb: powerup failed\n");
+   retval = -ENODEV;
+   }
+   } else {
+   gpio_set_value(TUSB6010_GPIO_ENABLE, 0);
+   msleep(10);
+   }
+
+   return retval;
+}
+
+static struct musb_hdrc_config musb_config = {
+   .multipoint = 1,
+   .dyn_fifo   = 1,
+   .num_eps= 16,
+   .ram_bits   = 12,
+};
+
+static struct musb_hdrc_platform_data tusb_data = {
+#if defined(CONFIG_USB_MUSB_OTG)
+   .mode   = MUSB_OTG,
+#elif defined(CONFIG_USB_MUSB_PERIPHERAL)
+   .mode   = MUSB_PERIPHERAL,
+#else /* defined(CONFIG_USB_MUSB_HOST) */
+   .mode   = MUSB_HOST,
+#endif
+   .set_power  = tusb_set_power,
+   .min_power  = 25,   /* x2 = 50 mA drawn from VBUS as peripheral */
+   .power  = 100,  /* Max 100 mA VBUS for host mode */
+   .config = &musb_config,
+};
+
+static void __init n8x0_usb_init(void)
+{
+   int ret = 0;
+   static char announce[] __initdata = KERN_INFO "TUSB 6010\n";
+
+   /* PM companion chip power control pin */
+   ret = gpio_request(TUSB6010_GPIO_ENABLE, "TUSB6010 enable");
+   if (ret != 0) {
+   printk(KERN_ERR "Could not get TUSB power GPIO%i\n",
+  TUSB6010_GPIO_ENABLE);
+   return;
+   }
+   gpio_direction_output(TUSB6010_GPIO_ENABLE, 0);
+
+   tusb_set_power(0);
+
+   ret = tusb6010_setup_interface(&tusb_data, TUSB6010_REFCLK_19, 2,
+   TUSB6010_ASYNC_CS, TUSB6010_SYNC_CS,
+   TUSB6010_GPIO_INT, TUSB6010_DMACHAN);
+   if (ret != 0)
+   goto err;
+
+   printk(announce);
+
+   return;
+
+err:
+   gpio_free(TUSB6010_GPIO_ENABLE);
+}
+#else
+
+static void __init n8x0_usb_init(void) {}
+
+#endif /*CONFIG_USB_TUSB6010 */
+
+
 static struct omap2_mcspi_device_config p54spi_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,
@@ -562,6 +659,7 @@ static void __init n8x0_init_machine(void)
n8x0_menelaus_init();
n8x0_onenand_init();
n8x0_mmc_init();
+   n8x0_usb_init();
 }
 
 MACHINE_START(NOKIA_N800, "Nokia N800")
diff --git a/arch/arm/mach-omap2/clock2420_data.c 
b/arch/arm/mach-omap2/clock2420_data.c
index f12af95..d932b14 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1841,6 +1841,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL,   "aes_ick",  &aes_ick,   CK_242X),
CLK(NULL,   "pka_ick",  &pka_ick,   CK_242X),
CLK(NULL,   "usb_fck",  &usb_fck,   CK_242X),
+   CLK("musb_hdrc","fck",  &osc_ck,CK_242X),
 };
 
 /*

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/19] omap4: Fix build break by moving omap_smc1 into a separate .S

[Tony Lindgren]

From: Santosh Shilimkar 

This patch moves omap_smc1 function to a seperate omap44xx-smc.S file
and sets compile flags as -Wa,-march=armv7-a.

This fix was suggested by Tony Lindgren 

Signed-off-by: Santosh Shilimkar 
[t...@atomide.com: otherwise multi-omap build with V6 and V7 breaks]
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/Makefile|3 +++
 arch/arm/mach-omap2/board-4430sdp.c |   26 +-
 arch/arm/mach-omap2/omap44xx-smc.S  |   32 
 3 files changed, 36 insertions(+), 25 deletions(-)
 create mode 100644 arch/arm/mach-omap2/omap44xx-smc.S

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 2069fb3..4b9fc57 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -22,6 +22,9 @@ obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
 # SMP support ONLY available for OMAP4
 obj-$(CONFIG_SMP)  += omap-smp.o omap-headsmp.o
 obj-$(CONFIG_LOCAL_TIMERS) += timer-mpu.o
+obj-$(CONFIG_ARCH_OMAP4)   += omap44xx-smc.o
+
+AFLAGS_omap44xx-smc.o  :=-Wa,-march=armv7-a
 
 # Functions loaded to SRAM
 obj-$(CONFIG_ARCH_OMAP2420)+= sram242x.o
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 180ac11..b88f28c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -50,33 +50,9 @@ static struct omap_board_config_kernel sdp4430_config[] 
__initdata = {
 };
 
 #ifdef CONFIG_CACHE_L2X0
-noinline void omap_smc1(u32 fn, u32 arg)
-{
-   register u32 r12 asm("r12") = fn;
-   register u32 r0 asm("r0") = arg;
-
-   /* This is common routine cache secure monitor API used to
-* modify the PL310 secure registers.
-* r0 contains the value to be modified and "r12" contains
-* the monitor API number. It uses few CPU registers
-* internally and hence they need be backed up including
-* link register "lr".
-* Explicitly save r11 and r12 the compiler generated code
-* won't save it.
-*/
-   asm volatile(
-   "stmfd r13!, {r11,r12}\n"
-   "dsb\n"
-   "smc\n"
-   "ldmfd r13!, {r11,r12}\n"
-   : "+r" (r0), "+r" (r12)
-   :
-   : "r4", "r5", "r10", "lr", "cc");
-}
-EXPORT_SYMBOL(omap_smc1);
-
 static int __init omap_l2_cache_init(void)
 {
+   extern void omap_smc1(u32 fn, u32 arg);
void __iomem *l2cache_base;
 
/* To avoid code running on other OMAPs in
diff --git a/arch/arm/mach-omap2/omap44xx-smc.S 
b/arch/arm/mach-omap2/omap44xx-smc.S
new file mode 100644
index 000..89bb2b1
--- /dev/null
+++ b/arch/arm/mach-omap2/omap44xx-smc.S
@@ -0,0 +1,32 @@
+/*
+ * OMAP44xx secure APIs file.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Written by Santosh Shilimkar 
+ *
+ *
+ * This program is free software,you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+
+/*
+ * This is common routine to manage secure monitor API
+ * used to modify the PL310 secure registers.
+ * 'r0' contains the value to be modified and 'r12' contains
+ * the monitor API number. It uses few CPU registers
+ * internally and hence they need be backed up including
+ * link register "lr".
+ * Function signature : void omap_smc1(u32 fn, u32 arg)
+ */
+
+ENTRY(omap_smc1)
+   stmfd   sp!, {r2-r12, lr}
+   mov r12, r0
+   mov r0, r1
+   dsb
+   smc
+   ldmfd   sp!, {r2-r12, pc}
+END(omap_smc1)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/19] omap2/3/4: ehci: avoid compiler error with touchbook

[Tony Lindgren]

From: Felipe Balbi 

the early_param() call in board-omap3touchbook.c expands to:

static const char __setup_str_early_touchbook_revision[]
__section(.init.rodata) _aligned(1) = tbr;
[...]

and we have a non-const variable being added to the
same section:

static struct ehci_hcd_omap_platform_data ehci_pdata
__section(.init.rodata);

because of that, gcc generates a section type conflict
which can (and actually should) be avoided by marking
const every variable marked with __initconst.

This patch fixes that for the ehci_hdc_omap_platform_data.

Signed-off-by: Felipe Balbi 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-3430sdp.c|2 +-
 arch/arm/mach-omap2/board-3630sdp.c|2 +-
 arch/arm/mach-omap2/board-am3517evm.c  |2 +-
 arch/arm/mach-omap2/board-cm-t35.c |2 +-
 arch/arm/mach-omap2/board-devkit8000.c |2 +-
 arch/arm/mach-omap2/board-igep0020.c   |2 +-
 arch/arm/mach-omap2/board-omap3beagle.c|2 +-
 arch/arm/mach-omap2/board-omap3evm.c   |2 +-
 arch/arm/mach-omap2/board-omap3pandora.c   |2 +-
 arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
 arch/arm/mach-omap2/board-overo.c  |2 +-
 arch/arm/mach-omap2/board-zoom3.c  |2 +-
 arch/arm/mach-omap2/usb-ehci.c |6 +++---
 arch/arm/plat-omap/include/plat/usb.h  |2 +-
 14 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index a101029..5822bcf 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -648,7 +648,7 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
 }
 
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
 
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-3630sdp.c 
b/arch/arm/mach-omap2/board-3630sdp.c
index 4386d2b..a0a2a11 100755
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -54,7 +54,7 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
 }
 
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
 
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 70c1861..6ae8805 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -273,7 +273,7 @@ static void __init am3517_evm_init_irq(void)
omap_gpio_init();
 }
 
-static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index afa77ca..2de4f79 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -612,7 +612,7 @@ static struct omap2_hsmmc_info mmc[] = {
{}  /* Terminator */
 };
 
-static struct ehci_hcd_omap_platform_data ehci_pdata = {
+static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 3710190..5bfc13b 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -636,7 +636,7 @@ static struct omap_musb_board_data musb_board_data = {
.power  = 100,
 };
 
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
 
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 9958987..4f1accf 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -442,7 +442,7 @@ static struct omap_musb_board_data musb_board_data = {
.power  = 100,
 };
 
-static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
diff --git a/arch/arm/mach-omap2/board-omap3

[PATCH 01/19] omap3: Fix compile for Touch Book early_param

[Tony Lindgren]

Commit 2b0d8c251b8876d530a6bf671eb5425838fa698a changed ARM to use
the common early_param code. Fix compile for Touch Book accordingly.

Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/board-omap3touchbook.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3touchbook.c 
b/arch/arm/mach-omap2/board-omap3touchbook.c
index 3943d0f..2a5bf5c 100644
--- a/arch/arm/mach-omap2/board-omap3touchbook.c
+++ b/arch/arm/mach-omap2/board-omap3touchbook.c
@@ -518,14 +518,14 @@ static void omap3_touchbook_poweroff(void)
gpio_direction_output(TB_KILL_POWER_GPIO, 0);
 }
 
-static void __init early_touchbook_revision(char **p)
+static int __init early_touchbook_revision(char *p)
 {
-   if (!*p)
-   return;
+   if (!p)
+   return 0;
 
-   strict_strtoul(*p, 10, &touchbook_revision);
+   return strict_strtoul(p, 10, &touchbook_revision);
 }
-__early_param("tbr=", early_touchbook_revision);
+early_param("tbr", early_touchbook_revision);
 
 static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_ULPI,

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/19] omap-fixes for 2.6.34-rc1

[Tony Lindgren]

Hi all,

Here's some omap fixes for review.

I also threw in the n8x0 platform init for tusb6010 and
updated the defconfig as those were needed to fix and test
the tusb6010 for the DMA API changes as posted earlier.

Regards,

Tony

---

Aaro Koskinen (2):
  omap: pass the reboot command to the boot loader
  omap: mach-omap2/io.c: fix function declarations

Andrea Gelmini (1):
  omap: Checkpatch cleanup for blizzard.h

Andrew Clayton (1):
  ARM/OMAP: Remove the +x bit from a couple of source files

Enric Balletbo i Serra (1):
  omap3: Fix support for the LEDs connected to GPIO outputs on IGEP v2board

Felipe Balbi (1):
  omap2/3/4: ehci: avoid compiler error with touchbook

Francisco Alecrim (1):
  omap2: add USB initialization for tusb6010

Grazvydas Ignotas (1):
  omap3: pandora: add missing i2c3 board_info

Janusz Krzysztofik (1):
  omap: McBSP: Drop unnecessary status/error bit clearing on 
reg_cacheretrieved register values

Kevin Hilman (2):
  OMAP2: cpu_is_omap2*: fix compile-time removal of unused code
  OMAP4: fix temporary hacks that break multi-omap PM

Santosh Shilimkar (1):
  omap4: Fix build break by moving omap_smc1 into a separate .S

Suman Anna (1):
  omap2/3/4: mailbox: remove compiler warning

Thomas Weber (1):
  OMAP2: serial.c: Fix number of uarts in early_init

Tony Lindgren (4):
  omap3: Fix compile for Touch Book early_param
  omap2: Update n8x0 defconfig to test multi-omap and DMA api changes
  omap: Enable PM_RUNTIME in defconfigs to avoid USB compile errors
  omap: Fix gpio_resume_after_retention

Vaibhav Hiremath (1):
  omap: Add DSI regulator supply to OMAP3EVM board file


 arch/arm/configs/cm_t35_defconfig|2 
 arch/arm/configs/n770_defconfig  |1 
 arch/arm/configs/n8x0_defconfig  |  160 +++---
 arch/arm/configs/omap3_beagle_defconfig  |1 
 arch/arm/configs/omap3_defconfig |2 
 arch/arm/configs/omap3_evm_defconfig |1 
 arch/arm/configs/omap3_touchbook_defconfig   |2 
 arch/arm/configs/omap_3430sdp_defconfig  |1 
 arch/arm/configs/omap_3630sdp_defconfig  |2 
 arch/arm/configs/omap_h2_1610_defconfig  |1 
 arch/arm/configs/omap_zoom2_defconfig|1 
 arch/arm/configs/omap_zoom3_defconfig|2 
 arch/arm/configs/rx51_defconfig  |1 
 arch/arm/mach-omap2/Makefile |3 
 arch/arm/mach-omap2/board-3430sdp.c  |2 
 arch/arm/mach-omap2/board-3630sdp.c  |2 
 arch/arm/mach-omap2/board-4430sdp.c  |   26 
 arch/arm/mach-omap2/board-am3517evm.c|2 
 arch/arm/mach-omap2/board-cm-t35.c   |2 
 arch/arm/mach-omap2/board-devkit8000.c   |2 
 arch/arm/mach-omap2/board-igep0020.c |   56 ++---
 arch/arm/mach-omap2/board-n8x0.c |   98 
 arch/arm/mach-omap2/board-omap3beagle.c  |2 
 arch/arm/mach-omap2/board-omap3evm.c |   18 ++-
 arch/arm/mach-omap2/board-omap3pandora.c |   12 ++
 arch/arm/mach-omap2/board-omap3touchbook.c   |   12 +-
 arch/arm/mach-omap2/board-overo.c|2 
 arch/arm/mach-omap2/board-zoom-peripherals.c |0 
 arch/arm/mach-omap2/board-zoom3.c|2 
 arch/arm/mach-omap2/clock2420_data.c |1 
 arch/arm/mach-omap2/io.c |   21 ++-
 arch/arm/mach-omap2/mailbox.c|   12 +-
 arch/arm/mach-omap2/omap44xx-smc.S   |   32 +
 arch/arm/mach-omap2/prcm.c   |4 -
 arch/arm/mach-omap2/serial.c |   15 ++
 arch/arm/mach-omap2/usb-ehci.c   |6 -
 arch/arm/plat-omap/gpio.c|   10 +-
 arch/arm/plat-omap/include/plat/blizzard.h   |2 
 arch/arm/plat-omap/include/plat/cpu.h|8 +
 arch/arm/plat-omap/include/plat/prcm.h   |2 
 arch/arm/plat-omap/include/plat/system.h |6 -
 arch/arm/plat-omap/include/plat/usb.h|2 
 arch/arm/plat-omap/mcbsp.c   |   12 +-
 43 files changed, 414 insertions(+), 137 deletions(-)
 mode change 100755 => 100644 arch/arm/mach-omap2/board-3630sdp.c
 mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-peripherals.c
 create mode 100644 arch/arm/mach-omap2/omap44xx-smc.S

-- 
Signature
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Trying to understand how to use new OMAP mux code

[Tony Lindgren]

* Peter Barada  [100311 14:29]:
> 1) Suppose I want to talk to a bluetooth chip through UART2.  UART2_TX
>  gives me a choice of pins to hook up to, either to pin AA26 in Mode0,
> or pin AF5 in Mode1.  If I use omape_mux_init_signal("uart2_tx",
> OMAP_PIN_OUTPUT), which pin will that map to?

You need to check the omap package type you're using to find
out the correct ball name. If you get lucky, that's already in
mux34xx.c and you don't need search through the TRMs :)
 
> 2) How can I tell the muxing code that I want a specific pin for my
> UART2_TX signal (that's not a GPIO since those can be directly
> specified by GPIO number)?

Then you want to use the full signal name:

omap_mux_init_signal("mode0_name.desired_mode", OMAP_PIN_FLAGS) 

But as the balls can be separate for each package type, you
need to figure that out first.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap

[Mark Brown]

On 11 Mar 2010, at 22:26, Tony Lindgren  wrote:


* Mark Brown  [100303 05:34]:

On Wed, Mar 03, 2010 at 03:08:03PM +0200, Peter Ujfalusi wrote:


Peter Ujfalusi (5):
 ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry
 ASoC: core: soc level wrapper for pcm_pointer callback
 ASoC: core: Add delay operation to snd_soc_dai_ops


I'll apply these just now, thanks!


 OMAP3: McBSP: Add interface for FIFO caused delay query
 ASoC: OMAP3: Report delay caused by the internal FIFO


These also look OK to me but there's the arch/arm dependency.


I think the only one is the McBSP patch above.

Care to take that too to keep things working?

Acked-by: Tony Lindgren 


I can do, though there was some debate about how useful the  
information the hardware returns actually is - could folks confirm  
what the consensus there was, please?

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: compile break on dss2 branch for zoom3

[Tony Lindgren]

* Felipe Balbi  [100311 05:09]:
> On Thu, Mar 11, 2010 at 12:43:00PM +0100, Valkeinen Tomi (Nokia-D/Helsinki) 
> wrote:
> >>When I disable usb, build goes through but the board does not bootup with 
> >>this image. It is stuck at uncompressing linux.
> >
> >Yes, mainstream linux tree seems to be broken. Not much I can do to help
> >you there. You can try rebasing on top of later mainstrean version,
> >perhaps it's been fixed there.
> 
> you need to enable CONFIG_PM_RUNTIME

I have a patch queued up to do that for the related defconfig
files while we wait for the usb patch to get merged. Will post
later today.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] omap2_mcspi: Flush posted writes

[Tony Lindgren]

* Roman Tereshonkov  [100310 02:16]:
> mcspi_write_chconf0 is used to control rx/tx triggering.
> Post-write flushing is needed to get the immediate effect.
> 
> Signed-off-by: Roman Tereshonkov 
> ---
>  drivers/spi/omap2_mcspi.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index 715c518..35b31fe 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -203,6 +203,7 @@ static inline void mcspi_write_chconf0(const struct 
> spi_device *spi, u32 val)
>  
>   cs->chconf0 = val;
>   mcspi_write_cs_reg(spi, OMAP2_MCSPI_CHCONF0, val);
> + mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHCONF0);
>  }
>  
>  static void omap2_mcspi_set_dma_req(const struct spi_device *spi,

Looks like good fixes, these should be resent to the
spi list and maintainers. See the MAINTAINERS file.

Regards,

Tony 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM/OMAP: Remove the +x bit from a couple of source files

[Tony Lindgren]

* Andrew Clayton  [100305 16:33]:
> Signed-off-by: Andrew Clayton 
> ---
>  0 files changed, 0 insertions(+), 0 deletions(-)
>  mode change 100755 => 100644 arch/arm/mach-omap2/board-3630sdp.c
>  mode change 100755 => 100644 arch/arm/mach-omap2/board-zoom-peripherals.c
> 
> diff --git a/arch/arm/mach-omap2/board-3630sdp.c 
> b/arch/arm/mach-omap2/board-3630sdp.c
> old mode 100755
> new mode 100644
> diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c 
> b/arch/arm/mach-omap2/board-zoom-peripherals.c
> old mode 100755
> new mode 100644

Uhh, not again.. Applying, thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Trying to understand how to use new OMAP mux code

[Peter Barada]

1) Suppose I want to talk to a bluetooth chip through UART2.  UART2_TX
 gives me a choice of pins to hook up to, either to pin AA26 in Mode0,
or pin AF5 in Mode1.  If I use omape_mux_init_signal("uart2_tx",
OMAP_PIN_OUTPUT), which pin will that map to?

2) How can I tell the muxing code that I want a specific pin for my
UART2_TX signal (that's not a GPIO since those can be directly
specified by GPIO number)?


Thanks in advance!
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] [PATCH] OMAP: McBSP: Drop unnecessary status/error bit clearing on

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): 28c60b4bee6a948791d68d305701ec2d63ed22fc

PatchWorks
http://patchwork.kernel.org/patch/81476/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=28c60b4bee6a948791d68d305701ec2d63ed22fc


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap

[Tony Lindgren]

* Mark Brown  [100303 05:34]:
> On Wed, Mar 03, 2010 at 03:08:03PM +0200, Peter Ujfalusi wrote:
> 
> > Peter Ujfalusi (5):
> >   ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry
> >   ASoC: core: soc level wrapper for pcm_pointer callback
> >   ASoC: core: Add delay operation to snd_soc_dai_ops
> 
> I'll apply these just now, thanks!
> 
> >   OMAP3: McBSP: Add interface for FIFO caused delay query
> >   ASoC: OMAP3: Report delay caused by the internal FIFO
> 
> These also look OK to me but there's the arch/arm dependency.

I think the only one is the McBSP patch above.

Care to take that too to keep things working?

Acked-by: Tony Lindgren 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: Fixing build warning with omap3_defconfig

[Tony Lindgren]

* Anuj Aggarwal  [100302 02:52]:
> Fixes the below build warning when compiled with omap3_defconfig:
> 
>   CC  arch/arm/mach-omap2/board-am3517evm.o
>   In file included from arch/arm/mach-omap2/board-am3517evm.c:23:
>   include/linux/i2c/pca953x.h:14: warning: 'struct i2c_client' declared
>   inside parameter list
>   include/linux/i2c/pca953x.h:14: warning: its scope is only this definition
>   or declaration, which is probably not what you want
>   include/linux/i2c/pca953x.h:17: warning: 'struct i2c_client' declared inside
>   parameter list
>   CC  arch/arm/mach-omap2/usb-musb.o
> 
> Signed-off-by: Anuj Aggarwal 
> ---
>  include/linux/i2c/pca953x.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/i2c/pca953x.h b/include/linux/i2c/pca953x.h
> index 81736d6..6c8f853 100644
> --- a/include/linux/i2c/pca953x.h
> +++ b/include/linux/i2c/pca953x.h
> @@ -1,4 +1,5 @@
>  /* platform data for the PCA9539 16-bit I/O expander driver */
> +#include 
>  
>  struct pca953x_platform_data {
>   /* number of the first GPIO */
> 

This needs to go via the I2C list.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] Regulator: Registering USB internal LDOs for TWL4030

[Tony Lindgren]

* Aggarwal, Anuj  [100301 22:21]:
> > -Original Message-
> > From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> > Sent: Monday, January 11, 2010 4:26 PM
> > To: Aggarwal, Anuj
> > Cc: linux-omap@vger.kernel.org; l...@slimlogic.co.uk
> > Subject: Re: [PATCH 1/1] Regulator: Registering USB internal LDOs for
> > TWL4030
> > 
> > On Mon, Jan 11, 2010 at 02:55:18PM +0530, Anuj Aggarwal wrote:
> > > Adding member variables for USB internal LDOs in twl4030_platform_data
> > > and registering them in twl-core.c if the variables are populated
> > > from board-evm file.
> > 
> > > Signed-off-by: Anuj Aggarwal 
> > 
> > Acked-by: Mark Brown 
> Tony,
> 
> Can you pull this patch? I have tried it on for-next tip, it applies
> cleanly.

This needs to go to Samuel, see MAINTAINERS file for MFD.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: Replace vdvi with vdds_dsi regulator supply in OMAP3EVM board file

[Tony Lindgren]

* hvaib...@ti.com  [100311 01:28]:
> From: Vaibhav Hiremath 
> 
> With recent changes happened in OMAP2/3 DSS library for regulator interface, 
> it
> is required to define DSI regulator supply, and since we don't need VDVI
> supply so remove it.

This one does not seem to apply, maybe this should be merged into
one of your pending patches?

Tony
 
> Signed-off-by: Vaibhav Hiremath 
> Acked-by: Tomi Valkeinen 
> ---
>  arch/arm/mach-omap2/board-omap3evm.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
> b/arch/arm/mach-omap2/board-omap3evm.c
> index 017bb2f..ea1014b 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -515,8 +515,8 @@ static struct regulator_init_data omap3_evm_vdac = {
> 
>  /* VPLL2 for digital video outputs */
>  static struct regulator_consumer_supply omap3_evm_vpll2_supply = {
> - .supply = "vdvi",
> - .dev= &omap3_evm_lcd_device.dev,
> + .supply = "vdds_dsi",
> + .dev= &omap3_evm_dss_device.dev,
>  };
> 
>  static struct regulator_init_data omap3_evm_vpll2 = {
> --
> 1.6.2.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] [PATCH-Fix] OMAP: Add DSI regulator supply to OMAP3EVM board

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): 6ae6dad6e6da9cc46c3272aeff62d28c6348ace7

PatchWorks
http://patchwork.kernel.org/patch/84823/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=6ae6dad6e6da9cc46c3272aeff62d28c6348ace7


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] [PATCH 2/2] OMAP4: fix temporary hacks that break multi-omap PM

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): f5564bf423cb747c82101d397655216c9d98682f

PatchWorks
http://patchwork.kernel.org/patch/84641/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=f5564bf423cb747c82101d397655216c9d98682f


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] [PATCH 1/2] OMAP2: cpu_is_omap2*: fix compile-time removal of

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): c9846244fa63adfa4930e35a1ee8bec02e0dd1b4

PatchWorks
http://patchwork.kernel.org/patch/84640/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=c9846244fa63adfa4930e35a1ee8bec02e0dd1b4


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] [PATCH] omap3: pandora: add missing i2c3 board_info

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): d47a0b100c5386f12bcdef9071bbd5b3f653e755

PatchWorks
http://patchwork.kernel.org/patch/84535/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=d47a0b100c5386f12bcdef9071bbd5b3f653e755


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] [PATCH] OMAP: mach-omap2/io.c: fix function declarations

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): 90fdcfdb7a3b398377b0ab6ef769845bc5630046

PatchWorks
http://patchwork.kernel.org/patch/83372/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=90fdcfdb7a3b398377b0ab6ef769845bc5630046


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] [PATCH] omap: Fix gpio_resume_after_retention

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): 3be3c2a3edc0d0171fbe5cf5a5267d3a9c58a0ca

PatchWorks
http://patchwork.kernel.org/patch/83370/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=3be3c2a3edc0d0171fbe5cf5a5267d3a9c58a0ca


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] [PATCH] omap3: Fix support for the LEDs connected to GPIO outputs

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): 0ce147cb24d1371ccc49e962af7648fa7a5d9196

PatchWorks
http://patchwork.kernel.org/patch/83403/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0ce147cb24d1371ccc49e962af7648fa7a5d9196


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] omap3: Fix EHCI port for IGEP v2 board.

[Tony Lindgren]

* Enric Balletbo i Serra  [100303 09:34]:
> From: Enric Balletbo i Serra 
> 
> IGEP v2 uses EHCI port 1 instead of EHCI port 2.

This does not seem to apply, can you please refresh please?

Tony
 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  arch/arm/mach-omap2/board-igep0020.c |8 
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-igep0020.c 
> b/arch/arm/mach-omap2/board-igep0020.c
> index 9958987..26f65ca 100644
> --- a/arch/arm/mach-omap2/board-igep0020.c
> +++ b/arch/arm/mach-omap2/board-igep0020.c
> @@ -443,13 +443,13 @@ static struct omap_musb_board_data musb_board_data = {
>  };
>  
>  static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
> - .port_mode[0] = EHCI_HCD_OMAP_MODE_UNKNOWN,
> - .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
> + .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
> + .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
>   .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
>  
>   .phy_reset = true,
> - .reset_gpio_port[0] = -EINVAL,
> - .reset_gpio_port[1] = IGEP2_GPIO_USBH_NRESET,
> + .reset_gpio_port[0] = IGEP2_GPIO_USBH_NRESET,
> + .reset_gpio_port[1] = -EINVAL,
>   .reset_gpio_port[2] = -EINVAL,
>  };
>  
> -- 
> 1.5.4.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] [PATCH 57/66] arch/arm/plat-omap/include/plat/blizzard.h:

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): a694acf36251cf9f454422d9cf43ee3f2c859d66

PatchWorks
http://patchwork.kernel.org/patch/82674/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=a694acf36251cf9f454422d9cf43ee3f2c859d66


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] [PATCHv2] OMAP: pass the reboot command to the boot loader

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): 943c26fba31960a004a4c8eab3a83679cb789d69

PatchWorks
http://patchwork.kernel.org/patch/82291/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=943c26fba31960a004a4c8eab3a83679cb789d69


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[APPLIED] > > [RESEND][PATCH/RFC] OMAP2: serial.c: Fix number of uarts in early_init

[Tony Lindgren]

This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: omap-fixes

Initial commit ID (Likely to change): a347e26b81e9724ac6bc71a537dcdc3a7fa39697

PatchWorks
http://patchwork.kernel.org/patch/81923/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=a347e26b81e9724ac6bc71a537dcdc3a7fa39697


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v3 1/2] OMAP3: SDRC: Dynamic Calculation of SDRC stall latency during DVFS

[Cousson, Benoit]

>From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>ow...@vger.kernel.org] On Behalf Of Pramod Gurav
>

[snip]

>diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S
>index de99ba2..00da20a 100644
>--- a/arch/arm/mach-omap2/sram34xx.S
>+++ b/arch/arm/mach-omap2/sram34xx.S
>@@ -313,3 +313,14 @@ core_m2_mask_val:
> ENTRY(omap3_sram_configure_core_dpll_sz)
>   .word   . - omap3_sram_configure_core_dpll
>
>+ENTRY(__sram_wait_delay)
>+  stmfd   sp!, {lr}   @ store return addr to stack
>+
>+  loop1:
>+  subsr0, r0, #1  @ loop till counter = 0
>+  bne loop1
>+
>+  ldmfd   sp!, {pc}   @ restore return address
>+

If I remember well from my old ARM ASM days, you can even preserve the stack 
and one instruction in that case using the "mov pc, lr"

ENTRY(__sram_wait_delay)
subsr0, r0, #1  @ loop till counter = 0
bne __sram_wait_delay

mov pc, lr


Regards,
Benoit

Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 
036 420 040 R.C.S Antibes. Capital de EUR 753.920



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] usb: Fix USB_SUSPEND dependency for OTG

[Tony Lindgren]

* Gadiyar, Anand  [100311 10:24]:
> Tony Lindgren wrote:
> > 
> > To use this, PM_RUNTIME must be set as discussed at:
> > 
> > http://thread.gmane.org/gmane.linux.usb.general/27432/focus=4460
> > 
> > Otherwise we'll get errors like:
> > 
> > drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in this 
> > function)
> > drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is reported 
> > only once
> > drivers/usb/core/hcd.c:1892: error: for each function it appears in.)
> > 
> > Signed-off-by: Tony Lindgren 
> 
> Hi Tony,
> 
> I already posted this patch last month. Still waiting for it
> to get queued.
> 
> 

OK thanks, I just found the thread but no patches. So my version
can then be dropped.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature

[Tony Lindgren]

* Venkatraman S  [100311 07:04]:
> Tony Lindgren wrote:
> >
> > Does the driver still work in PIO mode?
> >
> > We need to have the drivers capable to fail over to PIO mode
> > as the DMA channels can run out.
> >
> 
>The driver doesn't have an automatic fallback to PIO,
> even without my patch. A error return from omap_request_dma is
> propogated all the way back to the transfer request.
>   The decision to use_dma (the variable) is unaltered.

OK, that might explain some nasty surprises then..

With these patches, does the driver still work in PIO mode though?
 
>Infact, it would be easier to implement a runtime fallback after
> this patch is
> merged as I have separated out the capability and runtime selection.
> (dma_caps and dma_in_use).

Sounds good to me, thanks for looking into it.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/3] usb: Fix USB_SUSPEND dependency for OTG

[Gadiyar, Anand]

Tony Lindgren wrote:
> 
> To use this, PM_RUNTIME must be set as discussed at:
> 
> http://thread.gmane.org/gmane.linux.usb.general/27432/focus=4460
> 
> Otherwise we'll get errors like:
> 
> drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in this 
> function)
> drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is reported 
> only once
> drivers/usb/core/hcd.c:1892: error: for each function it appears in.)
> 
> Signed-off-by: Tony Lindgren 

Hi Tony,

I already posted this patch last month. Still waiting for it
to get queued.



- Anand


> ---
>  drivers/usb/core/Kconfig |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index 97a819c..7e59444 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -109,7 +109,7 @@ config USB_SUSPEND
>  config USB_OTG
>   bool
>   depends on USB && EXPERIMENTAL
> - select USB_SUSPEND
> + depends on USB_SUSPEND
>   default n
>  
>  
> 

[PATCH 3/3] usb: Fix tusb6010 for DMA API

[Tony Lindgren]

Commit 18eabe2347ae7a11b3db768695913724166dfb0e introduced
DMA buffer ownership. Fix tusb6010 accordingly.

Also change the order of musb_read_fifo() to happen after
dma_cache_maint to have the DMA operations completed before
moving the remaining unaligned bytes with PIO. The DMA
access and PIO touch different areas of the FIFO, so this
change only makes the code a bit easier to follow.

Tested on n810 and g_ether with variable size ping test.
The test seems to fail for some ping sizes, but that seems to
be a different problem.

Signed-off-by: Tony Lindgren 
---
 drivers/usb/musb/tusb6010.c  |   13 +
 drivers/usb/musb/tusb6010_omap.c |   22 ++
 2 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index ab776a8..60d3938 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -29,6 +29,19 @@ static void tusb_source_power(struct musb *musb, int is_on);
 #define TUSB_REV_MAJOR(reg_val)((reg_val >> 4) & 0xf)
 #define TUSB_REV_MINOR(reg_val)(reg_val & 0xf)
 
+#ifdef CONFIG_PM
+/* REVISIT: These should be only needed if somebody implements off idle */
+void musb_platform_save_context(struct musb *musb,
+   struct musb_context_registers *musb_context)
+{
+}
+
+void musb_platform_restore_context(struct musb *musb,
+   struct musb_context_registers *musb_context)
+{
+}
+#endif
+
 /*
  * Checks the revision. We need to use the DMA register as 3.0 does not
  * have correct versions for TUSB_PRCM_REV or TUSB_INT_CTRL_REV.
diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index 1c86809..6f0e943 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -38,7 +38,7 @@ struct tusb_omap_dma_ch {
 
struct tusb_omap_dma*tusb_dma;
 
-   void __iomem*dma_addr;
+   dma_addr_t  dma_addr;
 
u32 len;
u16 packet_sz;
@@ -125,6 +125,7 @@ static void tusb_omap_dma_cb(int lch, u16 ch_status, void 
*data)
struct tusb_omap_dma_ch *chdat = to_chdat(channel);
struct tusb_omap_dma*tusb_dma = chdat->tusb_dma;
struct musb *musb = chdat->musb;
+   struct device   *dev = musb->controller;
struct musb_hw_ep   *hw_ep = chdat->hw_ep;
void __iomem*ep_conf = hw_ep->conf;
void __iomem*mbase = musb->mregs;
@@ -172,13 +173,15 @@ static void tusb_omap_dma_cb(int lch, u16 ch_status, void 
*data)
DBG(3, "Using PIO for remaining %lu bytes\n", pio);
buf = phys_to_virt((u32)chdat->dma_addr) + chdat->transfer_len;
if (chdat->tx) {
-   dma_cache_maint(phys_to_virt((u32)chdat->dma_addr),
-   chdat->transfer_len, DMA_TO_DEVICE);
+   dma_unmap_single(dev, chdat->dma_addr,
+   chdat->transfer_len,
+   DMA_TO_DEVICE);
musb_write_fifo(hw_ep, pio, buf);
} else {
+   dma_unmap_single(dev, chdat->dma_addr,
+   chdat->transfer_len,
+   DMA_FROM_DEVICE);
musb_read_fifo(hw_ep, pio, buf);
-   dma_cache_maint(phys_to_virt((u32)chdat->dma_addr),
-   chdat->transfer_len, DMA_FROM_DEVICE);
}
channel->actual_len += pio;
}
@@ -223,6 +226,7 @@ static int tusb_omap_dma_program(struct dma_channel 
*channel, u16 packet_sz,
struct tusb_omap_dma_ch *chdat = to_chdat(channel);
struct tusb_omap_dma*tusb_dma = chdat->tusb_dma;
struct musb *musb = chdat->musb;
+   struct device   *dev = musb->controller;
struct musb_hw_ep   *hw_ep = chdat->hw_ep;
void __iomem*mbase = musb->mregs;
void __iomem*ep_conf = hw_ep->conf;
@@ -298,14 +302,16 @@ static int tusb_omap_dma_program(struct dma_channel 
*channel, u16 packet_sz,
chdat->packet_sz = packet_sz;
chdat->len = len;
channel->actual_len = 0;
-   chdat->dma_addr = (void __iomem *)dma_addr;
+   chdat->dma_addr = dma_addr;
channel->status = MUSB_DMA_STATUS_BUSY;
 
/* Since we're recycling dma areas, we need to clean or invalidate */
if (chdat->tx)
-   dma_cache_maint(phys_to_virt(dma_addr), len, DMA_TO_DEVICE);
+   dma_map_single(dev, phys_to_virt(dma_addr), len,
+   DMA_TO_DEVICE);
else
-   dma_cache_maint(phys_to_virt(dma_addr), len, DMA_F

[PATCH 2/3] usb: Fix USB_SUSPEND dependency for OTG

[Tony Lindgren]

To use this, PM_RUNTIME must be set as discussed at:

http://thread.gmane.org/gmane.linux.usb.general/27432/focus=4460

Otherwise we'll get errors like:

drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in this 
function)
drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is reported 
only once
drivers/usb/core/hcd.c:1892: error: for each function it appears in.)

Signed-off-by: Tony Lindgren 
---
 drivers/usb/core/Kconfig |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index 97a819c..7e59444 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -109,7 +109,7 @@ config USB_SUSPEND
 config USB_OTG
bool
depends on USB && EXPERIMENTAL
-   select USB_SUSPEND
+   depends on USB_SUSPEND
default n
 
 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] usb: Fix compile error for omaps for musb_hdrc

[Tony Lindgren]

CONFIG_ARCH_OMAP34XX is now CONFIG_ARCH_OMAP3.

But since drivers/usb/musb/omap2430.c use CONFIG_PM for these
registers and functions, do the same for the header.

Otherwise we get the following for most omap3 defconfigs:

drivers/usb/musb/omap2430.c:261: error: expected identifier or '(' before 'do'
drivers/usb/musb/omap2430.c:261: error: expected identifier or '(' before 
'while'
drivers/usb/musb/omap2430.c:268: error: expected identifier or '(' before 'do'
drivers/usb/musb/omap2430.c:268: error: expected identifier or '(' before 
'while'

Signed-off-by: Tony Lindgren 
---
 drivers/usb/musb/musb_core.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index d849fb8..cd9f4a9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -469,7 +469,7 @@ struct musb_csr_regs {
 
 struct musb_context_registers {
 
-#if defined(CONFIG_ARCH_OMAP34XX) || defined(CONFIG_ARCH_OMAP2430)
+#ifdef CONFIG_PM
u32 otg_sysconfig, otg_forcestandby;
 #endif
u8 power;
@@ -483,7 +483,7 @@ struct musb_context_registers {
struct musb_csr_regs index_regs[MUSB_C_NUM_EPS];
 };
 
-#if defined(CONFIG_ARCH_OMAP34XX) || defined(CONFIG_ARCH_OMAP2430)
+#ifdef CONFIG_PM
 extern void musb_platform_save_context(struct musb *musb,
struct musb_context_registers *musb_context);
 extern void musb_platform_restore_context(struct musb *musb,

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] USB compile fixes omaps

[Tony Lindgren]

Hi Felipe & Greg,

Here are three fixes to make USB compile for omaps.
Can you please take a look and queue?

The tusb6010 DMA fix needs a platform init patch that I'll
send along with other omap fixes.

Regards,

Tony


---

Tony Lindgren (3):
  usb: Fix compile error for omaps for musb_hdrc
  usb: Fix USB_SUSPEND dependency for OTG
  usb: Fix tusb6010 for DMA API


 drivers/usb/core/Kconfig |2 +-
 drivers/usb/musb/musb_core.h |4 ++--
 drivers/usb/musb/tusb6010.c  |   13 +
 drivers/usb/musb/tusb6010_omap.c |   22 ++
 4 files changed, 30 insertions(+), 11 deletions(-)

-- 
Signature
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature

[Venkatraman S]

Madhusudhan  wrote:
>> -Original Message-
>> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
>> Venkatraman S
>> Sent: Thursday, March 11, 2010 4:52 AM
>> To: Madhusudhan
>> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>> linux-omap@vger.kernel.org
>> Subject: Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
>> autoloading feature
>>
>> Madhusudhan  wrote:
>> >> -Original Message-
>> >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
>> >> ow...@vger.kernel.org] On Behalf Of Venkatraman S
>> >> Sent: Monday, March 01, 2010 5:27 AM
>> >> To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>> >> linux-omap@vger.kernel.org
>> >> Subject: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
>> >> autoloading feature
>> >>
>> >> Start to use the sDMA descriptor autoloading feature.
>> >> For large datablocks, the MMC driver has to repeatedly setup, program
>> >> and teardown the
>> >> dma channel for each element of the sglist received in
>> omap_hsmmc_request.
>> >>
>> >> By using descriptor autoloading, transfers from / to each element of
>> >> the sglist is pre programmed
>> >> into a linked list. The sDMA driver completes the entire transaction
>> >> and provides a single interrupt.
>> >>
>> >> Due to this, number of dma interrupts for a typical 100MB transfer on
>> the
>> >> MMC is
>> >> reduced from 25000 to about 400 (approximate). Transfer speeds are
>> >> improved by ~5%
>> >> (Though it varies on the size of read / write & improves on huge
>> >> transfers)
>> >>
>> >> Descriptor autoloading is available only in 3630 and 4430 (as of now).
>> >> Hence normal DMA
>> >> mode is also retained.
>> >>
>> >> Tested on omap4430 sdp.
>> >>
>> >> Signed-off-by: Venkatraman S 
>> >
>> > I don't see any issues with this patch except the concern I had on the
>> first
>> > patch in the series. Why is that change linked to this series?
>> >
>>   Thanks. The problem was seen only in the context of using descriptor
>> load. Would
>> you prefer that I post it as a separate patch ?
>
> My point is why that change is needed for this feature to work?
>
> When DMA is completed and a callback is received the ch can be freed. Once
> TC is received the core is notified of the same.
>
> Can the first patch be dropped? Or do you see issues?
Yes there are issues without this patch when the scatterlist is large
(300+ blocks), where the dma completion interrupt is received but the
mmc driver hangs waiting for TC. I don't see the issue if I delay the
execution of omap_free_dma inside the dma callback.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] omap4: Fix build break by moving omap_smc1 into a separate .S

[Tony Lindgren]

* Santosh Shilimkar  [100310 23:30]:
> This patch moves omap_smc1 function to a seperate omap44xx-smc.S file
> and sets compile flags as -Wa,-march=armv7-a.

Thanks for doing this, I'll add it to omap-fixes.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv6] OMAP3: Serial: Improved sleep logic

[Tero.Kristo]

 

>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] 
>Sent: 11 March, 2010 18:30
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv6] OMAP3: Serial: Improved sleep logic
>
> writes:
>
>>  
>>
>>>-Original Message-
>>>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] 
>>>Sent: 10 March, 2010 20:21
>>>To: Kristo Tero (Nokia-D/Tampere)
>>>Cc: linux-omap@vger.kernel.org
>>>Subject: Re: [PATCHv6] OMAP3: Serial: Improved sleep logic
>>>
>>>Kevin Hilman  writes:
>>>
 Tero Kristo  writes:

> From: Tero Kristo 
>
> This patch contains following improvements:
> - Only RX interrupt will now kick the sleep prevent timer
> - TX fifo status is checked before disabling clocks, this 
>>>will prevent
>   on-going transmission to be cut
> - Smartidle is now enabled/disabled only while switching 
>>>clocks, as having
>   smartidle enabled while RX/TX prevents any wakeups from 
>>>being received
>   from UART module
> - Added workqueue for wakeup checks, as jiffy timer access 
>>>within the
>   idle loop results into skewed timers as jiffy timers are stopped
> - Added garbage_timer for ignoring the first character 
>>>received during
>   the first tick after clock enable, this prevents garbage 
>>>characters to be
>   received in low sleep states
> - omap_uart_enable_irqs() changed to use enable_irq / 
>>>disable_irq instead
>   of request / free. Using request/free changes the 
>>>behavior after first
>   suspend due to reversed interrupt handler ordering
>
> Signed-off-by: Tero Kristo 

 Thanks Tero.  This version looks good.

 Adding to pm-fixes queue for 2.6.34-rcX after minor change below...

>>>
>>>There's still something slightly strange going on here...
>>>
>>>I noticed via powertop that the garbage timer is now one of the top
>>>reasons for wakeup in an idle system.  Seems like the garbage timer
>>>is firing when it shouldn't be, and triggering unnecessary wakeups
>>>
>>>Based on powertop stats, the garbage timer is firing about 3x more
>>>often than the GPtimer that should be waking the system.
>>
>> You get one timer expire each wakeup cycle, but the system 
>actually fires its own timer for each UART, thus you get 3x. 
>It is possible to optimize the timer a bit by only firing it 
>if we have a wakeup from UART, but this probably causes 
>occasional garbage to the console, if a wakeup from some other 
>source than UART and UART RX happen at the same time. Might be 
>the lesser of two evils though.
>>
>> I can experiment with this change a bit and see how it behaves.
>>
>
>OK, the 3x makes sense, but the garbage timer should never be the
>cause of a wakeup.
>
>Maybe you also need to be sure that the garbage timer is disabled
>before clocks are disabled so it doesn't fire and cause a wakeup.

Yeah, that's another addition that I can do, but I don't think the system is 
actually woken up even though powertop claims so. Powertop is not too reliable 
wakeup source indicator, it only shows the number of expired timers / 
interrupts in most cases, but it does not know whether the device was sleeping 
when the interrupt was raised or not. The number of wakeups can be reliably 
seen from the number of PRCM interrupts that have occurred, but powertop does 
not parse the results too well for OMAP3 currently. And, there is no wakeup 
source indicator anyway available that would be exported from the kernel 
currently. I have fiddled at some point with a patch that does this, but I 
never posted it anywhere.

-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] [I2C-OMAP] Add support for 16-bit registers

[Kevin Hilman]

Tony Lindgren  writes:

> * Kevin Hilman  [100310 10:01]:
>> Tony Lindgren  writes:
>> 
>> > * Cory Maccarrone  [100109 10:34]:
>> >> On Sat, Jan 9, 2010 at 10:33 AM, Tony Lindgren  wrote:
>> >> >
>> >> > Let's plan on adding this into omap-testing branch next week so
>> >> > we can make sure things are OK for the other platforms.
>> >> >
>> >> > Then assuming no issues, let's ask Ben can queue it.
>> >> >
>> >> 
>> >> Excellent, thank you!
>> >
>> > Applied to omap-testing with the following fix. Can you please merge
>> > it into your original patch?
>> 
>> Unfortunately, Tony's additional fix did not make it into the version
>> that was merged to mainline, which results in a crash during
>> probe when using v2.6.34-rc1.
>> 
>> Ben, can you queue the fix below from Tony for -rc2?
>
> The original patch attached again below.
>
> Oops, did I maybe send a wrong patchwork link earlier to the
> patch?
>
> Anyways, for the future, considering how critical this driver is
> for all omaps.. And considering how badly this driver needs some
> updates done..
>
> How about we pile up the i2c-omap patches for testing into linux-omap
> branch first, then ask Ben to pull it around -rc6 after we've all
> acked and tested the changes?
>
> Ben does that sound OK to you?

Here's another one to add to omap-testing then.

This one has been submitted to linux-i2c a couple times and been in
the OMAP PM branch for a while.

Kevin

>From 639d6ce328663c0e6cb1623bc69bcb5d167db2f9 Mon Sep 17 00:00:00 2001
From: Kalle Jokiniemi 
Date: Wed, 21 Oct 2009 14:51:21 +0300
Subject: [PATCH] i2c-omap: add mpu wake up latency constraint in i2c

While waiting for completion of the i2c transfer, the
MPU could hit OFF mode and cause several msecs of
delay that made i2c transfers fail more often. The
extra delays and subsequent re-trys cause i2c clocks
to be active more often. This has also an negative
effect on power consumption.

Created a mechanism for passing and using the
constraint setting function in driver code. The used
mpu wake up latency constraints are now set individually
per bus, and they are calculated based on clock rate
and fifo size.

Thanks to Jarkko Nikula, Moiz Sonasath, Paul Walmsley,
and Nishanth Menon for tuning out the details of
this patch.

Cc: Moiz Sonasath 
Cc: Jarkko Nikula 
Cc: Paul Walmsley 
Cc: Nishanth Menon 
Signed-off-by: Kalle Jokiniemi 
Signed-off-by: Kevin Hilman 
---
 arch/arm/plat-omap/i2c.c  |   55 -
 drivers/i2c/busses/i2c-omap.c |   25 +++---
 include/linux/i2c-omap.h  |9 ++
 3 files changed, 73 insertions(+), 16 deletions(-)
 create mode 100644 include/linux/i2c-omap.h

diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 624e262..36011a1 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,9 +26,12 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 #include 
+#include 
 
 #define OMAP_I2C_SIZE  0x3f
 #define OMAP1_I2C_BASE 0xfffb3800
@@ -70,19 +73,44 @@ static struct resource i2c_resources[][2] = {
},  \
}
 
-static u32 i2c_rate[ARRAY_SIZE(i2c_resources)];
+static struct omap_i2c_bus_platform_data i2c_pdata[ARRAY_SIZE(i2c_resources)];
 static struct platform_device omap_i2c_devices[] = {
-   I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_rate[0]),
+   I2C_DEV_BUILDER(1, i2c_resources[0], &i2c_pdata[0]),
 #ifdefined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
-   I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
+   I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_pdata[1]),
 #endif
 #ifdefined(CONFIG_ARCH_OMAP3)
-   I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
+   I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_pdata[2]),
 #endif
 };
 
 #define OMAP_I2C_CMDLINE_SETUP (BIT(31))
 
+#ifdef CONFIG_ARCH_OMAP3
+/*
+ * omap_i2c_set_wfc_mpu_wkup_lat - sets mpu wake up constraint
+ * @dev:   i2c bus device pointer
+ * @val:   latency constraint to set, -1 to disable constraint
+ *
+ * When waiting for completion of a i2c transfer, we need to set a wake up
+ * latency constraint for the MPU. This is to ensure quick enough wakeup from
+ * idle, when transfer completes.
+ */
+static void omap_i2c_set_wfc_mpu_wkup_lat(struct device *dev, int val)
+{
+   omap_pm_set_max_mpu_wakeup_lat(dev, val);
+}
+#endif
+
+static void __init omap_set_i2c_constraint_func(
+   struct omap_i2c_bus_platform_data *pd)
+{
+   if (cpu_is_omap34xx())
+   pd->set_mpu_wkup_lat = omap_i2c_set_wfc_mpu_wkup_lat;
+   else
+   pd->set_mpu_wkup_lat = NULL;
+}
+
 static int __init omap_i2c_nr_ports(void)
 {
int ports = 0;
@@ -146,8 +174,8 @@ static int __init omap_i2c_bus_setup(char *str)
get_options(str, 3, ints);
if (ints[0] < 2 || ints[1] < 1 || ints[1] > ports)
return 0;
-   i2c_rate[ints[1] - 1] = i

Re: [PATCH 2/2] arm: omap: ehci: avoid compiler error with touchbook

[Tony Lindgren]

* Felipe Balbi  [100310 23:26]:
> hi,
> 
> On Wed, Mar 10, 2010 at 06:15:49PM +0100, ext Tony Lindgren wrote:
> >Updated patch below, is this what you want to do? Maybe reply with
> >an updated patch if you want usb_ehci_init not to use const?
> 
> I'm happy with your version.

OK
 
> >Also, there are other ehci related warnings, see the attached
> >file for that.
> 
> I saw those other warnings and they come from the framework and are
> normal. If I remember Anand had put a patch on ehci-hub.c to kill
> those warnings, maybe it didn't get applied yet.

OK, I'll send out the pending drivers/usb compile fixes to linux-usb
today.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reposting: [PATCH v1] serial: Add OMAP high-speed UART driver.

[Tony Lindgren]

* Govindraj.R  [100311 05:11]:
> 
> Hi Greg,
> 
> Could you please have this patch into your tty tree now?
> 
> As I do not see any further comment in community on this
> for quite long time now.

There are still outstanding comments. I've commented several
times that this patch needs to be posted with the related
patches so people can actually try it out.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv6] OMAP3: Serial: Improved sleep logic

[Kevin Hilman]

 writes:

>  
>
>>-Original Message-
>>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] 
>>Sent: 10 March, 2010 20:21
>>To: Kristo Tero (Nokia-D/Tampere)
>>Cc: linux-omap@vger.kernel.org
>>Subject: Re: [PATCHv6] OMAP3: Serial: Improved sleep logic
>>
>>Kevin Hilman  writes:
>>
>>> Tero Kristo  writes:
>>>
 From: Tero Kristo 

 This patch contains following improvements:
 - Only RX interrupt will now kick the sleep prevent timer
 - TX fifo status is checked before disabling clocks, this 
>>will prevent
   on-going transmission to be cut
 - Smartidle is now enabled/disabled only while switching 
>>clocks, as having
   smartidle enabled while RX/TX prevents any wakeups from 
>>being received
   from UART module
 - Added workqueue for wakeup checks, as jiffy timer access 
>>within the
   idle loop results into skewed timers as jiffy timers are stopped
 - Added garbage_timer for ignoring the first character 
>>received during
   the first tick after clock enable, this prevents garbage 
>>characters to be
   received in low sleep states
 - omap_uart_enable_irqs() changed to use enable_irq / 
>>disable_irq instead
   of request / free. Using request/free changes the 
>>behavior after first
   suspend due to reversed interrupt handler ordering

 Signed-off-by: Tero Kristo 
>>>
>>> Thanks Tero.  This version looks good.
>>>
>>> Adding to pm-fixes queue for 2.6.34-rcX after minor change below...
>>>
>>
>>There's still something slightly strange going on here...
>>
>>I noticed via powertop that the garbage timer is now one of the top
>>reasons for wakeup in an idle system.  Seems like the garbage timer
>>is firing when it shouldn't be, and triggering unnecessary wakeups
>>
>>Based on powertop stats, the garbage timer is firing about 3x more
>>often than the GPtimer that should be waking the system.
>
> You get one timer expire each wakeup cycle, but the system actually fires its 
> own timer for each UART, thus you get 3x. It is possible to optimize the 
> timer a bit by only firing it if we have a wakeup from UART, but this 
> probably causes occasional garbage to the console, if a wakeup from some 
> other source than UART and UART RX happen at the same time. Might be the 
> lesser of two evils though.
>
> I can experiment with this change a bit and see how it behaves.
>

OK, the 3x makes sense, but the garbage timer should never be the
cause of a wakeup.

Maybe you also need to be sure that the garbage timer is disabled
before clocks are disabled so it doesn't fire and cause a wakeup.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature

[Madhusudhan]

> -Original Message-
> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
> Venkatraman S
> Sent: Thursday, March 11, 2010 4:52 AM
> To: Madhusudhan
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-omap@vger.kernel.org
> Subject: Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
> autoloading feature
> 
> Madhusudhan  wrote:
> >> -Original Message-
> >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> >> ow...@vger.kernel.org] On Behalf Of Venkatraman S
> >> Sent: Monday, March 01, 2010 5:27 AM
> >> To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >> linux-omap@vger.kernel.org
> >> Subject: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
> >> autoloading feature
> >>
> >> Start to use the sDMA descriptor autoloading feature.
> >> For large datablocks, the MMC driver has to repeatedly setup, program
> >> and teardown the
> >> dma channel for each element of the sglist received in
> omap_hsmmc_request.
> >>
> >> By using descriptor autoloading, transfers from / to each element of
> >> the sglist is pre programmed
> >> into a linked list. The sDMA driver completes the entire transaction
> >> and provides a single interrupt.
> >>
> >> Due to this, number of dma interrupts for a typical 100MB transfer on
> the
> >> MMC is
> >> reduced from 25000 to about 400 (approximate). Transfer speeds are
> >> improved by ~5%
> >> (Though it varies on the size of read / write & improves on huge
> >> transfers)
> >>
> >> Descriptor autoloading is available only in 3630 and 4430 (as of now).
> >> Hence normal DMA
> >> mode is also retained.
> >>
> >> Tested on omap4430 sdp.
> >>
> >> Signed-off-by: Venkatraman S 
> >
> > I don't see any issues with this patch except the concern I had on the
> first
> > patch in the series. Why is that change linked to this series?
> >
>   Thanks. The problem was seen only in the context of using descriptor
> load. Would
> you prefer that I post it as a separate patch ?

My point is why that change is needed for this feature to work? 

When DMA is completed and a callback is received the ch can be freed. Once
TC is received the core is notified of the same.

Can the first patch be dropped? Or do you see issues?

> Regards,
> Venkat.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv6] OMAP3: Serial: Improved sleep logic

[Tero.Kristo]

 

>-Original Message-
>From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com] 
>Sent: 10 March, 2010 20:21
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: linux-omap@vger.kernel.org
>Subject: Re: [PATCHv6] OMAP3: Serial: Improved sleep logic
>
>Kevin Hilman  writes:
>
>> Tero Kristo  writes:
>>
>>> From: Tero Kristo 
>>>
>>> This patch contains following improvements:
>>> - Only RX interrupt will now kick the sleep prevent timer
>>> - TX fifo status is checked before disabling clocks, this 
>will prevent
>>>   on-going transmission to be cut
>>> - Smartidle is now enabled/disabled only while switching 
>clocks, as having
>>>   smartidle enabled while RX/TX prevents any wakeups from 
>being received
>>>   from UART module
>>> - Added workqueue for wakeup checks, as jiffy timer access 
>within the
>>>   idle loop results into skewed timers as jiffy timers are stopped
>>> - Added garbage_timer for ignoring the first character 
>received during
>>>   the first tick after clock enable, this prevents garbage 
>characters to be
>>>   received in low sleep states
>>> - omap_uart_enable_irqs() changed to use enable_irq / 
>disable_irq instead
>>>   of request / free. Using request/free changes the 
>behavior after first
>>>   suspend due to reversed interrupt handler ordering
>>>
>>> Signed-off-by: Tero Kristo 
>>
>> Thanks Tero.  This version looks good.
>>
>> Adding to pm-fixes queue for 2.6.34-rcX after minor change below...
>>
>
>There's still something slightly strange going on here...
>
>I noticed via powertop that the garbage timer is now one of the top
>reasons for wakeup in an idle system.  Seems like the garbage timer
>is firing when it shouldn't be, and triggering unnecessary wakeups
>
>Based on powertop stats, the garbage timer is firing about 3x more
>often than the GPtimer that should be waking the system.

You get one timer expire each wakeup cycle, but the system actually fires its 
own timer for each UART, thus you get 3x. It is possible to optimize the timer 
a bit by only firing it if we have a wakeup from UART, but this probably causes 
occasional garbage to the console, if a wakeup from some other source than UART 
and UART RX happen at the same time. Might be the lesser of two evils though.

I can experiment with this change a bit and see how it behaves.

>
>I haven't dug any deeper, but this needs to be fixed before merging
>upstream.
>
>Kevin
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] AM35xx EMAC : define submodule offsets.

[Sriramakrishnan]

Define offsets for EMAC sub modules.

Signed-off-by: Sriramakrishnan 
---
 arch/arm/mach-omap2/include/mach/am35xx.h |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/am35xx.h 
b/arch/arm/mach-omap2/include/mach/am35xx.h
index a705f94..472867e 100644
--- a/arch/arm/mach-omap2/include/mach/am35xx.h
+++ b/arch/arm/mach-omap2/include/mach/am35xx.h
@@ -23,4 +23,13 @@
 #define AM35XX_IPSS_HECC_BASE  0x5C05
 #define AM35XX_IPSS_VPFE_BASE  0x5C06
 
-#endif /*  __ASM_ARCH_AM35XX_H */
+#define AM35XX_EMAC_CNTRL_OFFSET   (0x1)
+#define AM35XX_EMAC_CNTRL_MOD_OFFSET   (0x0)
+#define AM35XX_EMAC_CNTRL_RAM_OFFSET   (0x2)
+#define AM35XX_EMAC_MDIO_OFFSET(0x3)
+#define AM35XX_EMAC_CNTRL_RAM_SIZE (0x2000)
+#define AM35XX_EMAC_RAM_ADDR   (AM3517_EMAC_BASE + \
+   AM3517_EMAC_CNTRL_RAM_OFFSET)
+#define AM35XX_EMAC_HW_RAM_ADDR(0x01E2)
+
+#endif  /*  __ASM_ARCH_AM35XX_H */
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] AM35xx : Platform specific hookup for EMAC module

[Sriramakrishnan]

Modified AM35xx EVM init sequence to handle EMAC
initialization.

Signed-off-by: Sriramakrishnan 
---
 arch/arm/mach-omap2/board-am3517evm.c |   98 +
 1 files changed, 98 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 6ae8805..a454995 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -30,11 +31,106 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include "mux.h"
 
+#define AM35XX_EVM_PHY_MASK(0xF)
+#define AM35XX_EVM_MDIO_FREQUENCY  (100)
+
+static struct emac_platform_data am3517_evm_emac_pdata = {
+   .phy_mask   = AM35XX_EVM_PHY_MASK,
+   .mdio_max_freq  = AM35XX_EVM_MDIO_FREQUENCY,
+   .rmii_en= 1,
+};
+
+static struct resource am3517_emac_resources[] = {
+   {
+   .start  = AM35XX_IPSS_EMAC_BASE,
+   .end= AM35XX_IPSS_EMAC_BASE + 0x3,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+   .end= INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+   .end= INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_TX_PULSE_IRQ,
+   .end= INT_35XX_EMAC_C0_TX_PULSE_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = INT_35XX_EMAC_C0_MISC_PULSE_IRQ,
+   .end= INT_35XX_EMAC_C0_MISC_PULSE_IRQ,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device am3517_emac_device = {
+   .name   = "davinci_emac",
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(am3517_emac_resources),
+   .resource   = am3517_emac_resources,
+};
+
+static void am3517_enable_ethernet_int(void)
+{
+   u32 regval;
+
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_MISC_PULSE_CLR |
+   AM35XX_CPGMAC_C0_RX_THRESH_CLR);
+   omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am3517_disable_ethernet_int(void)
+{
+   u32 regval;
+
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+   AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+   omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+   regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+void am3517_evm_ethernet_init(struct emac_platform_data *pdata)
+{
+   unsigned int regval;
+
+   pdata->ctrl_reg_offset  = AM35XX_EMAC_CNTRL_OFFSET;
+   pdata->ctrl_mod_reg_offset  = AM35XX_EMAC_CNTRL_MOD_OFFSET;
+   pdata->ctrl_ram_offset  = AM35XX_EMAC_CNTRL_RAM_OFFSET;
+   pdata->mdio_reg_offset  = AM35XX_EMAC_MDIO_OFFSET;
+   pdata->ctrl_ram_size= AM35XX_EMAC_CNTRL_RAM_SIZE;
+   pdata->version  = EMAC_VERSION_2;
+   pdata->hw_ram_addr  = AM35XX_EMAC_HW_RAM_ADDR;
+   pdata->interrupt_enable = am3517_enable_ethernet_int;
+   pdata->interrupt_disable= am3517_disable_ethernet_int;
+   am3517_emac_device.dev.platform_data= pdata;
+   platform_device_register(&am3517_emac_device);
+
+   regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+   regval = regval & (~(AM35XX_CPGMACSS_SW_RST));
+   omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+   regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+   return ;
+}
+
+
+
 #define LCD_PANEL_PWR  176
 #define LCD_PANEL_BKLIGHT_PWR  182
 #define LCD_PANEL_PWM  181
@@ -313,6 +409,8 @@ static void __init am3517_evm_init(void)
 
i2c_register_board_info(1, am3517evm_i2c_boardinfo,
ARRAY_SIZE(am3517evm_i2c_boardinfo));
+   /*Ethernet*/
+   am3517_evm_ethernet_init(&am3517_evm_emac_pdata);
 }
 
 static void __init am3517_evm_map_io(void)
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] AM3517 defconfig update : enable EMAC support

[Sriramakrishnan]

Update the default configuration for AM3517EVM to enable
support for EMAC peripheral.

Signed-off-by: Sriramakrishnan 
---
 arch/arm/configs/am3517_evm_defconfig |   70 -
 1 files changed, 69 insertions(+), 1 deletions(-)

diff --git a/arch/arm/configs/am3517_evm_defconfig 
b/arch/arm/configs/am3517_evm_defconfig
index 66a10b5..8d79b20 100644
--- a/arch/arm/configs/am3517_evm_defconfig
+++ b/arch/arm/configs/am3517_evm_defconfig
@@ -517,7 +517,75 @@ CONFIG_SCSI_LOWLEVEL=y
 # CONFIG_SCSI_OSD_INITIATOR is not set
 # CONFIG_ATA is not set
 # CONFIG_MD is not set
-# CONFIG_NETDEVICES is not set
+CONFIG_NETDEVICES=y
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_MACVLAN is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+# CONFIG_VETH is not set
+CONFIG_PHYLIB=y
+
+#
+# MII PHY device drivers
+#
+# CONFIG_MARVELL_PHY is not set
+# CONFIG_DAVICOM_PHY is not set
+# CONFIG_QSEMI_PHY is not set
+# CONFIG_LXT_PHY is not set
+# CONFIG_CICADA_PHY is not set
+# CONFIG_VITESSE_PHY is not set
+# CONFIG_SMSC_PHY is not set
+# CONFIG_BROADCOM_PHY is not set
+# CONFIG_ICPLUS_PHY is not set
+# CONFIG_REALTEK_PHY is not set
+# CONFIG_NATIONAL_PHY is not set
+# CONFIG_STE10XP is not set
+# CONFIG_LSI_ET1011C_PHY is not set
+# CONFIG_FIXED_PHY is not set
+# CONFIG_MDIO_BITBANG is not set
+CONFIG_NET_ETHERNET=y
+# CONFIG_MII is not set
+# CONFIG_AX88796 is not set
+# CONFIG_SMC91X is not set
+CONFIG_TI_DAVINCI_EMAC=y
+# CONFIG_DM9000 is not set
+# CONFIG_ETHOC is not set
+# CONFIG_SMC911X is not set
+# CONFIG_SMSC911X is not set
+# CONFIG_DNET is not set
+# CONFIG_IBM_NEW_EMAC_ZMII is not set
+# CONFIG_IBM_NEW_EMAC_RGMII is not set
+# CONFIG_IBM_NEW_EMAC_TAH is not set
+# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
+# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
+# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
+# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
+# CONFIG_B44 is not set
+# CONFIG_KS8842 is not set
+# CONFIG_KS8851_MLL is not set
+# CONFIG_NETDEV_1000 is not set
+# CONFIG_NETDEV_1 is not set
+# CONFIG_WLAN is not set
+
+#
+# Enable WiMAX (Networking options) to see the WiMAX drivers
+#
+
+#
+# USB Network Adapters
+#
+# CONFIG_USB_CATC is not set
+# CONFIG_USB_KAWETH is not set
+# CONFIG_USB_PEGASUS is not set
+# CONFIG_USB_RTL8150 is not set
+# CONFIG_USB_USBNET is not set
+# CONFIG_WAN is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
 # CONFIG_ISDN is not set
 # CONFIG_PHONE is not set
 
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] AM35xx : Add support for EMAC Peripheral

[Sriramakrishnan]

This patch series adds support for EMAC peripheral on AM35xx
platform. The EMAC peripheral is borrowed from the DaVinci
platform and hence the same driver(davinci_emac) is used.

This patch series has been generated against tip of linux-omap and
depends on the following patches submitted to netdev/linux-davinci
list.

[1].http://patchwork.ozlabs.org/patch/47331/
[2].http://patchwork.ozlabs.org/patch/47332/

Sriramakrishnan (4):
  AM35xx EMAC : define submodule offsets.
  AM35xx : Platform specific hookup for EMAC module
  OMAP3 : clock data: Update name string for EMAC clocks.
  AM3517 defconfig update : enable EMAC support

 arch/arm/configs/am3517_evm_defconfig |   70 -
 arch/arm/mach-omap2/board-am3517evm.c |   98 +
 arch/arm/mach-omap2/clock3xxx_data.c  |4 +-
 arch/arm/mach-omap2/include/mach/am35xx.h |   11 +++-
 4 files changed, 179 insertions(+), 4 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] OMAP3 : clock data: Update name string for EMAC clocks.

[Sriramakrishnan]

The emac driver uses generic name for the module and phy
clocks. Updated the omap3xxx_clks table to match the names
used by the Davinci emac driver.

Signed-off-by: Sriramakrishnan 
---
 arch/arm/mach-omap2/clock3xxx_data.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index d5153b6..989da2e 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3472,8 +3472,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL,   "ipss_ick", &ipss_ick,  CK_AM35XX),
CLK(NULL,   "rmii_ck",  &rmii_ck,   CK_AM35XX),
CLK(NULL,   "pclk_ck",  &pclk_ck,   CK_AM35XX),
-   CLK("davinci_emac", "ick",  &emac_ick,  CK_AM35XX),
-   CLK("davinci_emac", "fck",  &emac_fck,  CK_AM35XX),
+   CLK("davinci_emac", "emac_clk", &emac_ick,  CK_AM35XX),
+   CLK("davinci_emac", "phy_clk",  &emac_fck,  CK_AM35XX),
CLK("vpfe-capture", "master",   &vpfe_ick,  CK_AM35XX),
CLK("vpfe-capture", "slave",&vpfe_fck,  CK_AM35XX),
CLK("musb_hdrc","ick",  &hsotgusb_ick_am35xx,   
CK_AM35XX),
-- 
1.6.2.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature

[Venkatraman S]

Tony Lindgren wrote:
> * Venkatraman S  [100310 06:08]:
>> @@ -1400,14 +1471,23 @@ omap_hsmmc_prepare_data(struct omap_hsmmc_host
>> *host, struct mmc_request *req)
>>                                       | (req->data->blocks << 16));
>>       set_data_timeout(host, req->data->timeout_ns, req->data->timeout_clks);
>>
>> -     if (host->use_dma) {
>> -             ret = omap_hsmmc_start_dma_transfer(host, req);
>> -             if (ret != 0) {
>> -                     dev_dbg(mmc_dev(host->mmc), "MMC start dma failure\n");
>> +     if (host->dma_caps & DMA_TYPE_SDMA) {
>> +             ret = omap_hsmmc_configure_sdma(host, req);
>> +             if (ret)
>>                       return ret;
>> -             }
>> +             host->dma_in_use = DMA_TYPE_SDMA;
>>       }
>> -     return 0;
>> +     if ((host->dma_caps & DMA_TYPE_SDMA_DLOAD) &&
>> +             host->data->sg_len > 4) {
>> +             ret = omap_hsmmc_configure_sdma_sglist(host, req);
>> +             if (ret)
>> +                     return ret;
>> +             host->dma_in_use = DMA_TYPE_SDMA_DLOAD;
>> +
>> +     }
>> +     ret = omap_hsmmc_start_dma_transfer(host);
>> +     return ret;
>> +
>>  }
>
> Does the driver still work in PIO mode?
>
> We need to have the drivers capable to fail over to PIO mode
> as the DMA channels can run out.
>

   The driver doesn't have an automatic fallback to PIO,
even without my patch. A error return from omap_request_dma is
propogated all the way back to the transfer request.
  The decision to use_dma (the variable) is unaltered.

   Infact, it would be easier to implement a runtime fallback after
this patch is
merged as I have separated out the capability and runtime selection.
(dma_caps and dma_in_use).

Regards,

Venkat.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: compile break on dss2 branch for zoom3

[Aguirre, Sergio]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Y, Kishore
> Sent: Thursday, March 11, 2010 7:29 AM
> To: Y, Kishore; Gadiyar, Anand; Tomi Valkeinen
> Cc: linux-omap@vger.kernel.org
> Subject: RE: compile break on dss2 branch for zoom3
> 
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Y, Kishore
> > Sent: Thursday, March 11, 2010 5:23 PM
> > To: Gadiyar, Anand; Tomi Valkeinen
> > Cc: linux-omap@vger.kernel.org
> > Subject: RE: compile break on dss2 branch for zoom3
> >
> > > -Original Message-
> > > From: Gadiyar, Anand
> > > Sent: Thursday, March 11, 2010 5:18 PM
> > > To: Tomi Valkeinen; Y, Kishore
> > > Cc: linux-omap@vger.kernel.org
> > > Subject: RE: compile break on dss2 branch for zoom3
> > >
> > > Tomi Valkeinen wrote:
> > > >
> > > > On Thu, 2010-03-11 at 12:40 +0100, ext Y, Kishore wrote:
> > > > > Hi Tomi,
> > > > >   I am unable to compile dss2 tree for zoom3. Commit I am
> using
> > > following commit id
> > > > >
> > > > > 893d461b538e889da350061edaadeb8a9289913c
> > > > > OMAP: DSS2: quick hack for set mode
> > > > >
> > > > >
> > > > > Error I see is related to usb:-
> > > > > drivers/usb/core/hcd.c: In function 'usb_hcd_resume_root_hub':
> > > > > drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use
> in
> > > this function)
> > > > > drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is
> > > reported only once
> > > > > drivers/usb/core/hcd.c:1892: error: for each function it appears
> > in.)
> > > > > make[3]: *** [drivers/usb/core/hcd.o] Error 1
> > > > > make[2]: *** [drivers/usb/core] Error 2
> > > > > make[1]: *** [drivers/usb] Error 2
> > > > > make: *** [drivers] Error 2
> > > > >
> > > > > When I disable usb, build goes through but the board does not
> bootup
> > > with this image. It is stuck at uncompressing linux.
> > > >
> > > > Yes, mainstream linux tree seems to be broken. Not much I can do to
> > help
> > > > you there. You can try rebasing on top of later mainstrean version,
> > > > perhaps it's been fixed there.
> > > >
> > >
> > > I sent this patch [1] to linux-usb to fix this. It's yet to be queued
> > up.
> > > The alternative is to enable CONFIG_PM_RUNTIME in the build.
> > >
> > > Regards,
> > > Anand
> > >
> > > [1] http://marc.info/?l=linux-usb&m=126675883221098&w=2
> >
> > I will try this out.
> I have tried to use the main line which already has this patch. I am able
> to compile the code without any issues. But board still does not boot. Am
> I missing something?
> 
> My bootargs:
> setenv bootargs console=ttyS3,115200n8 noinitrd root=/dev/nfs rw
> nfsroot=192.168.223.72:/home/x0114913/fs1_inc2_rc0,nolock,rsize=1024,wsize
> =1024 rootdelay=0 ip=192.168.223.251 debug

Can you take this series:

http://marc.info/?l=linux-omap&m=126826639903105&w=2

And test with ttyS0?

Regards,
Sergio

> 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: compile break on dss2 branch for zoom3

[Aguirre, Sergio]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand
> Sent: Thursday, March 11, 2010 5:48 AM
> To: Tomi Valkeinen; Y, Kishore
> Cc: linux-omap@vger.kernel.org
> Subject: RE: compile break on dss2 branch for zoom3
> 
> Tomi Valkeinen wrote:
> >
> > On Thu, 2010-03-11 at 12:40 +0100, ext Y, Kishore wrote:
> > > Hi Tomi,
> > >   I am unable to compile dss2 tree for zoom3. Commit I am using
> following commit id
> > >
> > > 893d461b538e889da350061edaadeb8a9289913c
> > > OMAP: DSS2: quick hack for set mode
> > >
> > >
> > > Error I see is related to usb:-
> > > drivers/usb/core/hcd.c: In function 'usb_hcd_resume_root_hub':
> > > drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in
> this function)
> > > drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is
> reported only once
> > > drivers/usb/core/hcd.c:1892: error: for each function it appears in.)
> > > make[3]: *** [drivers/usb/core/hcd.o] Error 1
> > > make[2]: *** [drivers/usb/core] Error 2
> > > make[1]: *** [drivers/usb] Error 2
> > > make: *** [drivers] Error 2
> > >
> > > When I disable usb, build goes through but the board does not bootup
> with this image. It is stuck at uncompressing linux.
> >
> > Yes, mainstream linux tree seems to be broken. Not much I can do to help
> > you there. You can try rebasing on top of later mainstrean version,
> > perhaps it's been fixed there.
> >
> 
> I sent this patch [1] to linux-usb to fix this. It's yet to be queued up.
> The alternative is to enable CONFIG_PM_RUNTIME in the build.

This fix is in current linux-omap master branch as:

http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=873f7381a049e3814e01d44ba7f12ff13d4653b1

Who's patch is going upstream? Tony's or yours? :)

Regards,
Sergio

> 
> Regards,
> Anand
> 
> [1] http://marc.info/?l=linux-usb&m=126675883221098&w=2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH-Fix] OMAP: Add DSI regulator supply to OMAP3EVM board file

[Hiremath, Vaibhav]

> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Thursday, March 11, 2010 6:18 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; tomi.valkei...@nokia.com
> Subject: Re: [PATCH-Fix] OMAP: Add DSI regulator supply to OMAP3EVM board
> file
> 
> On Thu, Mar 11, 2010 at 02:25:17PM +0530, hvaib...@ti.com wrote:
> 
> > +static struct regulator_consumer_supply omap3_evm_vpll2_supplies[] = {
> > +   {
> > +   .supply = "vdvi",
> > +   .dev= &omap3_evm_lcd_device.dev,
> > +   },
> 
> Please use dev_name for new code.
[Hiremath, Vaibhav] Ok, will change and submit it again shortly.

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: compile break on dss2 branch for zoom3

[Y, Kishore]

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Y, Kishore
> Sent: Thursday, March 11, 2010 5:23 PM
> To: Gadiyar, Anand; Tomi Valkeinen
> Cc: linux-omap@vger.kernel.org
> Subject: RE: compile break on dss2 branch for zoom3
> 
> > -Original Message-
> > From: Gadiyar, Anand
> > Sent: Thursday, March 11, 2010 5:18 PM
> > To: Tomi Valkeinen; Y, Kishore
> > Cc: linux-omap@vger.kernel.org
> > Subject: RE: compile break on dss2 branch for zoom3
> >
> > Tomi Valkeinen wrote:
> > >
> > > On Thu, 2010-03-11 at 12:40 +0100, ext Y, Kishore wrote:
> > > > Hi Tomi,
> > > >   I am unable to compile dss2 tree for zoom3. Commit I am using
> > following commit id
> > > >
> > > > 893d461b538e889da350061edaadeb8a9289913c
> > > > OMAP: DSS2: quick hack for set mode
> > > >
> > > >
> > > > Error I see is related to usb:-
> > > > drivers/usb/core/hcd.c: In function 'usb_hcd_resume_root_hub':
> > > > drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in
> > this function)
> > > > drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is
> > reported only once
> > > > drivers/usb/core/hcd.c:1892: error: for each function it appears
> in.)
> > > > make[3]: *** [drivers/usb/core/hcd.o] Error 1
> > > > make[2]: *** [drivers/usb/core] Error 2
> > > > make[1]: *** [drivers/usb] Error 2
> > > > make: *** [drivers] Error 2
> > > >
> > > > When I disable usb, build goes through but the board does not bootup
> > with this image. It is stuck at uncompressing linux.
> > >
> > > Yes, mainstream linux tree seems to be broken. Not much I can do to
> help
> > > you there. You can try rebasing on top of later mainstrean version,
> > > perhaps it's been fixed there.
> > >
> >
> > I sent this patch [1] to linux-usb to fix this. It's yet to be queued
> up.
> > The alternative is to enable CONFIG_PM_RUNTIME in the build.
> >
> > Regards,
> > Anand
> >
> > [1] http://marc.info/?l=linux-usb&m=126675883221098&w=2
> 
> I will try this out.
I have tried to use the main line which already has this patch. I am able to 
compile the code without any issues. But board still does not boot. Am I 
missing something?

My bootargs:
setenv bootargs console=ttyS3,115200n8 noinitrd root=/dev/nfs rw 
nfsroot=192.168.223.72:/home/x0114913/fs1_inc2_rc0,nolock,rsize=1024,wsize=1024 
rootdelay=0 ip=192.168.223.251 debug

> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reposting: [PATCH v1] serial: Add OMAP high-speed UART driver.

[Govindraj.R]

Hi Greg,

Could you please have this patch into your tty tree now?

As I do not see any further comment in community on this
for quite long time now.

-- 
Regards,
Govindraj.R

> This time CC'ing Linux-serial and LKML too, forgot last time.
>
> --
> Govindraj.R
>
>
> This patch adds driver support for OMAP3/4 high speed UART.
>
> This 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 control configuration with
> this driver as required for the omap-platform.
>
> This patch involves only the core driver and its dependent.
> This patch doesn't incorporate platform specific data as this will be
> posted from linux-omap tree and this driver was tested with Kevins PM
> branch which currently hosts the omap-serial platform data which utilises
> the omap-hwmod framework.
>
> Cc: Tony Lindgren 
> Cc: Olof Johansson 
> Cc: Alan Cox 
> Tested-by: Kevin Hilman 
> Signed-off-by: Govindraj R 
> ---
>  arch/arm/plat-omap/include/plat/omap-serial.h |  128 +++
>  drivers/serial/Kconfig|   27 +
>  drivers/serial/Makefile   |1 +
>  drivers/serial/omap-serial.c  | 1316 
> +
>  include/linux/serial_core.h   |3 +
>  5 files changed, 1475 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h
>  create mode 100644 drivers/serial/omap-serial.c
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
> b/arch/arm/plat-omap/include/plat/omap-serial.h
> new file mode 100644
> index 000..2a1e7f9
> --- /dev/null
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -0,0 +1,128 @@
> +/*
> + * Driver for OMAP-UART controller.
> + * Based on drivers/serial/8250.c
> + *
> + * Copyright (C) 2010 Texas Instruments.
> + *
> + * Authors:
> + *   Govindraj R 
> + *   Thara Gopinath  
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#ifndef __OMAP_SERIAL_H__
> +#define __OMAP_SERIAL_H__
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define DRIVER_NAME  "omap-hsuart"
> +
> +/*
> + * Use tty device name as ttyO, [O -> OMAP]
> + * in bootargs we specify as console=ttyO0 if uart1
> + * is used as console uart.
> + */
> +#define OMAP_SERIAL_NAME "ttyO"
> +
> +#define OMAP_MDR1_DISABLE0x07
> +#define OMAP_MDR1_MODE13X0x03
> +#define OMAP_MDR1_MODE16X0x00
> +#define OMAP_MODE13X_SPEED   230400
> +
> +/*
> + * LCR = 0XBF: Switch to Configuration Mode B.
> + * In configuration mode b allow access
> + * to EFR,DLL,DLH.
> + * Reference OMAP TRM Chapter 17
> + * Section: 1.4.3 Mode Selection
> + */
> +#define OMAP_UART_LCR_CONF_MDB   0XBF
> +
> +/* WER = 0x7F
> + * Enable module level wakeup in WER reg
> + */
> +#define OMAP_UART_WER_MOD_WKUP   0X7F
> +
> +/* Enable XON/XOFF flow control on output */
> +#define OMAP_UART_SW_TX  0x04
> +
> +/* Enable XON/XOFF flow control on input */
> +#define OMAP_UART_SW_RX  0x04
> +
> +#define OMAP_UART_SYSC_RESET 0X07
> +#define OMAP_UART_TCR_TRIG   0X0F
> +#define OMAP_UART_SW_CLR 0XF0
> +
> +#define OMAP_UART_DMA_CH_FREE-1
> +
> +#define RX_TIMEOUT   (3 * HZ)
> +#define OMAP_MAX_HSUART_PORTS4
> +
> +#define MSR_SAVE_FLAGS   UART_MSR_ANY_DELTA
> +
> +struct omap_uart_port_info {
> + booldma_enabled;/* To specify DMA Mode */
> + unsigned intuartclk;/* UART clock rate */
> + void __iomem*membase;   /* ioremap cookie or NULL */
> + resource_size_t mapbase;/* resource base */
> + unsigned long   irqflags;   /* request_irq flags */
> + upf_t   flags;  /* UPF_* flags */
> +};
> +
> +struct uart_omap_dma {
> + u8  uart_dma_tx;
> + u8  uart_dma_rx;
> + int rx_dma_channel;
> + int tx_dma_channel;
> + dma_addr_t  rx_buf_dma_phys;
> + dma_addr_t  tx_buf_dma_phys;
> + unsigned intuart_base;
> + /*
> +  * Buffer for rx dma.It is not required for tx because the buffer
> +  * comes from port structure.
> +  */
> + unsigned char   *rx_buf;
> + unsigned intprev_rx_dma_pos;
> + int tx_buf_size;
> + int tx_dma_used;
> + int rx_dma_used;
> + spinlock_t  tx_lock;
> + spinlock_t  rx_lock;
> + /* timer to poll activity on rx d

Re: compile break on dss2 branch for zoom3

[Felipe Balbi]

On Thu, Mar 11, 2010 at 12:43:00PM +0100, Valkeinen Tomi (Nokia-D/Helsinki) 
wrote:

When I disable usb, build goes through but the board does not bootup with this 
image. It is stuck at uncompressing linux.


Yes, mainstream linux tree seems to be broken. Not much I can do to help
you there. You can try rebasing on top of later mainstrean version,
perhaps it's been fixed there.


you need to enable CONFIG_PM_RUNTIME

--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHV2] OMAP3 PM: Fix for DSP Crash at OPP 1 and 2 under DVFS+SR operation

[Vishwanath BS]

From: Shweta Gulati 

DSP usage at VDD1 OPP1 and OPP2 with Smartreflex enabled and any MM UCs
running DSP codec was earlier restricted as DSP crashed.
The root cause is wrong DPLL1/DPLL2 Bypass clock at VDD1 OPP1 and OPP2.
The solution is to make sure DPLL1/DPLL2 bypass clock is always less than 
maximum supported frequency for the specific OPP

Tested on 3630 ZOOM3.

changes in V2 : Rebased to new OPP implementation

Signed-off-by: Shweta Gulati 
Signed-off-by: Vishwanath BS 
---
 arch/arm/mach-omap2/cm-regbits-34xx.h |4 ++--
 arch/arm/mach-omap2/pm34xx.c  |   23 +++
 arch/arm/mach-omap2/resource34xx.c|   28 +++-
 3 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h 
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index a3a3ca0..ee420ab 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -81,7 +81,7 @@
 
 /* CM_CLKSEL1_PLL_IVA2 */
 #define OMAP3430_IVA2_CLK_SRC_SHIFT19
-#define OMAP3430_IVA2_CLK_SRC_MASK (0x3 << 19)
+#define OMAP3430_IVA2_CLK_SRC_MASK (0x7 << 19)
 #define OMAP3430_IVA2_DPLL_MULT_SHIFT  8
 #define OMAP3430_IVA2_DPLL_MULT_MASK   (0x7ff << 8)
 #define OMAP3430_IVA2_DPLL_DIV_SHIFT   0
@@ -126,7 +126,7 @@
 
 /* CM_CLKSEL1_PLL_MPU */
 #define OMAP3430_MPU_CLK_SRC_SHIFT 19
-#define OMAP3430_MPU_CLK_SRC_MASK  (0x3 << 19)
+#define OMAP3430_MPU_CLK_SRC_MASK  (0x7 << 19)
 #define OMAP3430_MPU_DPLL_MULT_SHIFT   8
 #define OMAP3430_MPU_DPLL_MULT_MASK(0x7ff << 8)
 #define OMAP3430_MPU_DPLL_DIV_SHIFT0
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b51b461..494e5e6
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -828,6 +828,29 @@ static void __init omap3_d2d_idle(void)
 
 static void __init prcm_setup_regs(void)
 {
+   u32 cm_clksel1_mpu, cm_clksel1_iva2;
+
+   /*set Bypass clock dividers for MPU and IVA */
+   cm_clksel1_mpu = cm_read_mod_reg(MPU_MOD, CM_CLKSEL1);
+   cm_clksel1_iva2 = cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSEL1);
+   if (cpu_is_omap3630()) {
+   cm_clksel1_iva2 = (cm_clksel1_iva2 &
+   ~(OMAP3430_IVA2_CLK_SRC_MASK)) |
+   (0x2 << OMAP3430_IVA2_CLK_SRC_SHIFT);
+   cm_clksel1_mpu = (cm_clksel1_mpu &
+   ~(OMAP3430_MPU_CLK_SRC_MASK)) |
+   (0x1 << OMAP3430_MPU_CLK_SRC_SHIFT);
+   } else if (cpu_is_omap34xx()) {
+   cm_clksel1_iva2 = (cm_clksel1_iva2 &
+   ~(OMAP3430_IVA2_CLK_SRC_MASK)) |
+   (0x4 << OMAP3430_IVA2_CLK_SRC_SHIFT);
+   cm_clksel1_mpu = (cm_clksel1_mpu &
+   ~(OMAP3430_MPU_CLK_SRC_MASK)) |
+   (0x2 << OMAP3430_MPU_CLK_SRC_SHIFT);
+   }
+   cm_write_mod_reg(cm_clksel1_iva2, OMAP3430_IVA2_MOD, CM_CLKSEL1);
+   cm_write_mod_reg(cm_clksel1_mpu, MPU_MOD, CM_CLKSEL1);
+
/* XXX Reset all wkdeps. This should be done when initializing
 * powerdomains */
prm_write_mod_reg(0, OMAP3430_IVA2_MOD, PM_WKDEP);
diff --git a/arch/arm/mach-omap2/resource34xx.c 
b/arch/arm/mach-omap2/resource34xx.c
index c6cce8b..03d7fce
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -276,12 +276,13 @@ static unsigned long compute_lpj(unsigned long ref, u_int 
div, u_int mult)
 
 static int program_opp_freq(int res, int target_level, int current_level)
 {
-   int ret = 0, l3_div;
+   int ret = 0, l3_div, mpu_div, iva2_div;
int *curr_opp;
unsigned long mpu_freq, dsp_freq, l3_freq;
 #ifndef CONFIG_CPU_FREQ
unsigned long mpu_cur_freq;
 #endif
+   u32 cm_clksel1_mpu, cm_clksel1_iva2, max_core_clk;
 
/* Check if I can actually switch or not */
if (res == VDD1_OPP) {
@@ -299,6 +300,31 @@ static int program_opp_freq(int res, int target_level, int 
current_level)
 
lock_scratchpad_sem();
if (res == VDD1_OPP) {
+   /* adjust bypass clock diviers */
+   max_core_clk = ULONG_MAX;
+   opp_find_freq_floor(OPP_L3, &max_core_clk);
+   l3_div = cm_read_mod_reg(CORE_MOD, CM_CLKSEL) &
+   OMAP3430_CLKSEL_L3_MASK;
+
+   max_core_clk *= l3_div;
+   mpu_div = 1 << (max_core_clk / mpu_freq);
+   iva2_div = 1 << (max_core_clk / dsp_freq);
+
+   cm_clksel1_mpu = cm_read_mod_reg(MPU_MOD, CM_CLKSEL1);
+   cm_clksel1_iva2 =
+   cm_read_mod_reg(OMAP3430_IVA

Re: [PATCH-Fix] OMAP: Add DSI regulator supply to OMAP3EVM board file

[Mark Brown]

On Thu, Mar 11, 2010 at 02:25:17PM +0530, hvaib...@ti.com wrote:

> +static struct regulator_consumer_supply omap3_evm_vpll2_supplies[] = {
> + {
> + .supply = "vdvi",
> + .dev= &omap3_evm_lcd_device.dev,
> + },

Please use dev_name for new code.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel panic with latest DSS

[Koen Kooi]

Op 11 mrt 2010, om 10:24 heeft Koen Kooi het volgende geschreven:

> 
> Op 10 mrt 2010, om 19:16 heeft Steve Sakoman het volgende geschreven:
> 
>> On Tue, Mar 9, 2010 at 11:58 AM, Steve Sakoman  wrote:
>>> I just updated all my Beagle and Overo DSS patches to apply on the
>>> latest linux-omap head.
>>> 
>>> I ran into a slight issue with parsing defaults, but saw that Tomi had
>>> already posted a workaround for that.
>>> 
>>> With that patch applied I get pretty good results until I try to do
>>> something like play a DVD or display video from a webcam.
>>> 
>>> At that point I get a kernel panic.  See below.
>> 
>> I did a little more research on this.
>> 
>> The issue occurs in the following section of code in
>> drivers/video/omap2/dss/dispc.c:
>> 
>> unsigned long dispc_fclk_rate(void)
>> {
>>  unsigned long r = 0;
>> 
>>  if (dss_get_dispc_clk_source() == DSS_SRC_DSS1_ALWON_FCLK)
>>  r = dss_clk_get_rate(DSS_CLK_FCK1);
>>  else
>> #ifdef CONFIG_OMAP2_DSS_DSI
>>  r = dsi_get_dsi1_pll_rate();
>> #else
>>  BUG();
>> #endif
>>  return r;
>> }
>> 
>> Since my machines don't have DSI displays CONFIG_OMAP2_DSS_DSI is not
>> defined and the BUG() call is triggered.
>> 
>> I don't know enough about what *should* be happening here to propose a
>> fix, but I'll continue looking.
> 
> Not that you need the DSI_PLL config to get tighter timings to do e.g. 
> 74.25MHz for 720p60. I had to rediscover that this week on DM37xx.

That was supposed to read "note", so you *do* need it.--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] USB MUSB patches for OMAP4

[Felipe Balbi]

On Thu, Mar 11, 2010 at 12:55:11PM +0100, ext Maulik Mankad wrote:

Greg,

Here is a Version 2 of driver patches that enable MUSB
driver support for OMAP4.


applied, all three of them

--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH-Fix] OMAP: Add DSI regulator supply to OMAP3EVM board file

[Tomi Valkeinen]

On Thu, 2010-03-11 at 11:03 +0100, ext Hiremath, Vaibhav wrote:
> > 
> [Hiremath, Vaibhav] Tomi, the above patch has already present in main-line. 
> The patch I am talking about is defconfig update for DSS on both OMAP3EVM and 
> AM3517EVM.
> It happened to be the same commit description at your repository when you 
> split it.

Yes, you are right. I seem to have confused the patch with board changes
and defconf changes. I'll take the defconfig changes to my next pull
request.

I also changed the patch descriptions a bit, so that I won't mix them up
again =).

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] USB: MUSB: Add OMAP4 support in MUSB driver

[Maulik Mankad]

This patch adds CONFIG_ARCH_OMAP4 macro within 
MUSB driver.

Signed-off-by: Maulik Mankad 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: David Brownell 
Cc: Sergei Shtylyov 
Cc: Olof Johansson 
---
Index: mainline/drivers/usb/musb/musb_core.c
===
--- mainline.orig/drivers/usb/musb/musb_core.c
+++ mainline/drivers/usb/musb/musb_core.c
@@ -982,7 +982,8 @@ static void musb_shutdown(struct platfor
  * more than selecting one of a bunch of predefined configurations.
  */
 #if defined(CONFIG_USB_TUSB6010) || \
-   defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+   defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) \
+   || defined(CONFIG_ARCH_OMAP4)
 static ushort __initdata fifo_mode = 4;
 #else
 static ushort __initdata fifo_mode = 2;
@@ -1457,7 +1458,8 @@ static int __init musb_core_init(u16 mus
 
 /*-*/
 
-#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3430)
+#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3430) || \
+   defined(CONFIG_ARCH_OMAP4)
 
 static irqreturn_t generic_interrupt(int irq, void *__hci)
 {
Index: mainline/drivers/usb/musb/musb_core.h
===
--- mainline.orig/drivers/usb/musb/musb_core.h
+++ mainline/drivers/usb/musb/musb_core.h
@@ -213,7 +213,8 @@ enum musb_g_ep0_state {
  */
 
 #if defined(CONFIG_ARCH_DAVINCI) || defined(CONFIG_ARCH_OMAP2430) \
-   || defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_BLACKFIN)
+   || defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_BLACKFIN) \
+   || defined(CONFIG_ARCH_OMAP4)
 /* REVISIT indexed access seemed to
  * misbehave (on DaVinci) for at least peripheral IN ...
  */
@@ -596,7 +597,8 @@ extern void musb_hnp_stop(struct musb *m
 extern int musb_platform_set_mode(struct musb *musb, u8 musb_mode);
 
 #if defined(CONFIG_USB_TUSB6010) || defined(CONFIG_BLACKFIN) || \
-   defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
+   defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3) || \
+   defined(CONFIG_ARCH_OMAP4)
 extern void musb_platform_try_idle(struct musb *musb, unsigned long timeout);
 #else
 #define musb_platform_try_idle(x, y)   do {} while (0)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] USB: MUSB: Build MUSB driver for OMAP4

[Maulik Mankad]

This patch updates the Makefile to build the
MUSB driver for OMAP4. It also sets the Kconfig
options for OMAP4.

Signed-off-by: Maulik Mankad 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: David Brownell 
Cc: Sergei Shtylyov 
Cc: Olof Johansson 

Index: mainline/drivers/usb/musb/Kconfig
===
--- mainline.orig/drivers/usb/musb/Kconfig
+++ mainline/drivers/usb/musb/Kconfig
@@ -38,6 +38,7 @@ config USB_MUSB_SOC
default y if ARCH_DAVINCI
default y if ARCH_OMAP2430
default y if ARCH_OMAP3
+   default y if ARCH_OMAP4
default y if (BF54x && !BF544)
default y if (BF52x && !BF522 && !BF523)
 
@@ -50,6 +51,9 @@ comment "OMAP 243x high speed USB suppor
 comment "OMAP 343x high speed USB support"
depends on USB_MUSB_HDRC && ARCH_OMAP3
 
+comment "OMAP 44xx high speed USB support"
+   depends on USB_MUSB_HDRC && ARCH_OMAP4
+
 comment "Blackfin high speed USB Support"
depends on USB_MUSB_HDRC && ((BF54x && !BF544) || (BF52x && !BF522 && 
!BF523))
 
@@ -153,7 +157,7 @@ config MUSB_PIO_ONLY
 config USB_INVENTRA_DMA
bool
depends on USB_MUSB_HDRC && !MUSB_PIO_ONLY
-   default ARCH_OMAP2430 || ARCH_OMAP3 || BLACKFIN
+   default ARCH_OMAP2430 || ARCH_OMAP3 || BLACKFIN || ARCH_OMAP4
help
  Enable DMA transfers using Mentor's engine.
 
Index: mainline/drivers/usb/musb/Makefile
===
--- mainline.orig/drivers/usb/musb/Makefile
+++ mainline/drivers/usb/musb/Makefile
@@ -22,6 +22,10 @@ ifeq ($(CONFIG_ARCH_OMAP3430),y)
musb_hdrc-objs  += omap2430.o
 endif
 
+ifeq ($(CONFIG_ARCH_OMAP4),y)
+   musb_hdrc-objs  += omap2430.o
+endif
+
 ifeq ($(CONFIG_BF54x),y)
musb_hdrc-objs  += blackfin.o
 endif
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] USB: MUSB: Set transceiver interface type

[Maulik Mankad]

Program the OTG_INTERFSEL register based on
transcevier type passed from board file.

Adapt signature of musb_platform_init() function
for davinci, blackfin and tusb6010.

Signed-off-by: Maulik Mankad 
Cc: Felipe Balbi 
Cc: David Brownell 
Cc: Greg Kroah-Hartman 
Cc: Sergei Shtylyov 
Cc: Olof Johansson 
---
 drivers/usb/musb/blackfin.c  |2 +-
 drivers/usb/musb/davinci.c   |2 +-
 drivers/usb/musb/musb_core.c |2 +-
 drivers/usb/musb/musb_core.h |2 +-
 drivers/usb/musb/omap2430.c  |   13 +++--
 drivers/usb/musb/tusb6010.c  |2 +-
 6 files changed, 16 insertions(+), 7 deletions(-)

Index: mainline/drivers/usb/musb/blackfin.c
===
--- mainline.orig/drivers/usb/musb/blackfin.c
+++ mainline/drivers/usb/musb/blackfin.c
@@ -277,7 +277,7 @@ int musb_platform_set_mode(struct musb *
return -EIO;
 }
 
-int __init musb_platform_init(struct musb *musb)
+int __init musb_platform_init(struct musb *musb, void *board_data)
 {
 
/*
Index: mainline/drivers/usb/musb/davinci.c
===
--- mainline.orig/drivers/usb/musb/davinci.c
+++ mainline/drivers/usb/musb/davinci.c
@@ -377,7 +377,7 @@ int musb_platform_set_mode(struct musb *
return -EIO;
 }
 
-int __init musb_platform_init(struct musb *musb)
+int __init musb_platform_init(struct musb *musb, void *board_data)
 {
void __iomem*tibase = musb->ctrl_base;
u32 revision;
Index: mainline/drivers/usb/musb/musb_core.c
===
--- mainline.orig/drivers/usb/musb/musb_core.c
+++ mainline/drivers/usb/musb/musb_core.c
@@ -1948,7 +1948,7 @@ bad_config:
 * isp1504, non-OTG, etc) mostly hooking up through ULPI.
 */
musb->isr = generic_interrupt;
-   status = musb_platform_init(musb);
+   status = musb_platform_init(musb, plat->board_data);
 
if (status < 0)
goto fail;
Index: mainline/drivers/usb/musb/musb_core.h
===
--- mainline.orig/drivers/usb/musb/musb_core.h
+++ mainline/drivers/usb/musb/musb_core.h
@@ -608,7 +608,7 @@ extern int musb_platform_get_vbus_status
 #define musb_platform_get_vbus_status(x)   0
 #endif
 
-extern int __init musb_platform_init(struct musb *musb);
+extern int __init musb_platform_init(struct musb *musb, void *board_data);
 extern int musb_platform_exit(struct musb *musb);
 
 #endif /* __MUSB_CORE_H__ */
Index: mainline/drivers/usb/musb/omap2430.c
===
--- mainline.orig/drivers/usb/musb/omap2430.c
+++ mainline/drivers/usb/musb/omap2430.c
@@ -200,9 +200,10 @@ int musb_platform_set_mode(struct musb *
return 0;
 }
 
-int __init musb_platform_init(struct musb *musb)
+int __init musb_platform_init(struct musb *musb, void *board_data)
 {
u32 l;
+   struct omap_musb_board_data *data = board_data;
 
 #if defined(CONFIG_ARCH_OMAP2430)
omap_cfg_reg(AE5_2430_USB0HS_STP);
@@ -236,7 +237,15 @@ int __init musb_platform_init(struct mus
musb_writel(musb->mregs, OTG_SYSCONFIG, l);
 
l = musb_readl(musb->mregs, OTG_INTERFSEL);
-   l |= ULPI_12PIN;
+
+   if (data->interface_type == MUSB_INTERFACE_UTMI) {
+   /* OMAP4 uses Internal PHY GS70 which uses UTMI interface */
+   l &= ~ULPI_12PIN;   /* Disable ULPI */
+   l |= UTMI_8BIT; /* Enable UTMI  */
+   } else {
+   l |= ULPI_12PIN;
+   }
+
musb_writel(musb->mregs, OTG_INTERFSEL, l);
 
pr_debug("HS USB OTG: revision 0x%x, sysconfig 0x%02x, "
Index: mainline/drivers/usb/musb/tusb6010.c
===
--- mainline.orig/drivers/usb/musb/tusb6010.c
+++ mainline/drivers/usb/musb/tusb6010.c
@@ -1091,7 +1091,7 @@ err:
return -ENODEV;
 }
 
-int __init musb_platform_init(struct musb *musb)
+int __init musb_platform_init(struct musb *musb, void *board_data)
 {
struct platform_device  *pdev;
struct resource *mem;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] USB MUSB patches for OMAP4

[Maulik Mankad]

Greg,

Here is a Version 2 of driver patches that enable MUSB
driver support for OMAP4.

Maulik Mankad(3)

[PATCH v2 1/3] USB: MUSB: Set transceiver interface type
[PATCH v2 2/3] USB: MUSB: Build MUSB driver for OMAP4
[PATCH v2 3/3] USB: MUSB: Add OMAP4 support in MUSB driver

This version is re-based on top of 2.6.34-rc1 + MUSB build fix
patches available at [1].

The [PATCH 2/3] address a comment from Sergei.

The patches are tested on OMAP4430 SDP for MUSB peripheral
mode.

[1] 
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=shortlog;h=refs/heads/for-next
 

Thanks,
Maulik
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: compile break on dss2 branch for zoom3

[Y, Kishore]

> -Original Message-
> From: Gadiyar, Anand
> Sent: Thursday, March 11, 2010 5:18 PM
> To: Tomi Valkeinen; Y, Kishore
> Cc: linux-omap@vger.kernel.org
> Subject: RE: compile break on dss2 branch for zoom3
> 
> Tomi Valkeinen wrote:
> >
> > On Thu, 2010-03-11 at 12:40 +0100, ext Y, Kishore wrote:
> > > Hi Tomi,
> > >   I am unable to compile dss2 tree for zoom3. Commit I am using
> following commit id
> > >
> > > 893d461b538e889da350061edaadeb8a9289913c
> > > OMAP: DSS2: quick hack for set mode
> > >
> > >
> > > Error I see is related to usb:-
> > > drivers/usb/core/hcd.c: In function 'usb_hcd_resume_root_hub':
> > > drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in
> this function)
> > > drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is
> reported only once
> > > drivers/usb/core/hcd.c:1892: error: for each function it appears in.)
> > > make[3]: *** [drivers/usb/core/hcd.o] Error 1
> > > make[2]: *** [drivers/usb/core] Error 2
> > > make[1]: *** [drivers/usb] Error 2
> > > make: *** [drivers] Error 2
> > >
> > > When I disable usb, build goes through but the board does not bootup
> with this image. It is stuck at uncompressing linux.
> >
> > Yes, mainstream linux tree seems to be broken. Not much I can do to help
> > you there. You can try rebasing on top of later mainstrean version,
> > perhaps it's been fixed there.
> >
> 
> I sent this patch [1] to linux-usb to fix this. It's yet to be queued up.
> The alternative is to enable CONFIG_PM_RUNTIME in the build.
> 
> Regards,
> Anand
> 
> [1] http://marc.info/?l=linux-usb&m=126675883221098&w=2

I will try this out.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: compile break on dss2 branch for zoom3

[Gadiyar, Anand]

Tomi Valkeinen wrote:
> 
> On Thu, 2010-03-11 at 12:40 +0100, ext Y, Kishore wrote:
> > Hi Tomi,
> >   I am unable to compile dss2 tree for zoom3. Commit I am using 
> > following commit id
> >
> > 893d461b538e889da350061edaadeb8a9289913c
> > OMAP: DSS2: quick hack for set mode
> >
> >
> > Error I see is related to usb:-
> > drivers/usb/core/hcd.c: In function 'usb_hcd_resume_root_hub':
> > drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in this 
> > function)
> > drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is reported 
> > only once
> > drivers/usb/core/hcd.c:1892: error: for each function it appears in.)
> > make[3]: *** [drivers/usb/core/hcd.o] Error 1
> > make[2]: *** [drivers/usb/core] Error 2
> > make[1]: *** [drivers/usb] Error 2
> > make: *** [drivers] Error 2
> >
> > When I disable usb, build goes through but the board does not bootup with 
> > this image. It is stuck at uncompressing linux.
> 
> Yes, mainstream linux tree seems to be broken. Not much I can do to help
> you there. You can try rebasing on top of later mainstrean version,
> perhaps it's been fixed there.
> 

I sent this patch [1] to linux-usb to fix this. It's yet to be queued up.
The alternative is to enable CONFIG_PM_RUNTIME in the build.

Regards,
Anand

[1] http://marc.info/?l=linux-usb&m=126675883221098&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: compile break on dss2 branch for zoom3

[Tomi Valkeinen]

On Thu, 2010-03-11 at 12:40 +0100, ext Y, Kishore wrote:
> Hi Tomi,
>   I am unable to compile dss2 tree for zoom3. Commit I am using following 
> commit id
> 
> 893d461b538e889da350061edaadeb8a9289913c
> OMAP: DSS2: quick hack for set mode
> 
> 
> Error I see is related to usb:-
> drivers/usb/core/hcd.c: In function 'usb_hcd_resume_root_hub':
> drivers/usb/core/hcd.c:1892: error: 'pm_wq' undeclared (first use in this 
> function)
> drivers/usb/core/hcd.c:1892: error: (Each undeclared identifier is reported 
> only once
> drivers/usb/core/hcd.c:1892: error: for each function it appears in.)
> make[3]: *** [drivers/usb/core/hcd.o] Error 1
> make[2]: *** [drivers/usb/core] Error 2
> make[1]: *** [drivers/usb] Error 2
> make: *** [drivers] Error 2
> 
> When I disable usb, build goes through but the board does not bootup with 
> this image. It is stuck at uncompressing linux.

Yes, mainstream linux tree seems to be broken. Not much I can do to help
you there. You can try rebasing on top of later mainstrean version,
perhaps it's been fixed there.

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html