Re: [PATCH-v6 0/4] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards

[Artem Bityutskiy]

On Tue, 2009-11-24 at 20:55 +0530, Vimal Singh wrote:
> On Tue, Nov 24, 2009 at 8:36 PM, Artem Bityutskiy  wrote:
> > On Thu, 2009-11-19 at 19:38 +0530, Vimal Singh wrote:
> >> Here is the v6 of this patch series. I am cc'ing mtd list too this time.
> >>
> >>
> >> From 8bc97108cf9c78216f1ea5407ccbd900e6b63dc2 Mon Sep 17 00:00:00 2001
> >> From: Vimal Singh 
> >> Date: Thu, 19 Nov 2009 19:28:11 +0530
> >>
> >> This patch series adds flash support for NAND (in sdp, zoom and ldp),
> >> OneNAND and NOR (in sdp)
> >>
> >> Tested on Zoom2 and 3430SDP
> >>
> >> Vimal Singh (4):
> >> [PATCH-v6 1/4] OMAP2/3: Add support for flash on SDP boards
> >> [PATCH-v6 2/4] OMAP3: Add support for NAND on ZOOM/LDP boards
> >> [PATCH-v6 3/4] OMAP: Zoom2: Enable NAND and JFFS2 support in defconfig
> >> [PATCH-v6 4/4] OMAP: 3430SDP: Enable NAND in defconfig
> >
> > Is it possible to separate the MTD and OMAP parts?
> 
> 1st patch does migration of gpmc low level calls from omap2.c to gpmc-nand.c.
> I am not sure how we can have separate patches for this.

Ok. It looks like you intend to merge this stuff via linux-omap, which
seems right.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
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: [RFC] [PATCH] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)

[Paul Walmsley]

On Thu, 26 Nov 2009, Janusz Krzysztofik wrote:

> Thursday 26 November 2009 03:08:30 Paul Walmsley napisał(a):
> > On Wed, 25 Nov 2009, Janusz Krzysztofik wrote:
> > > It turned out not that simple. Since arch/arm/mach-omap1/lcd_dma.c
> > > exports several functions that are called unconditionaly from
> > > drivers/video/omap/lcdc.c AND the latter is linked into the omapfb
> > > driver based on CONFIG_ARCH_OMAP1=y, linking in the former can't be
> > > limited to selected OMAP1 subarchs unless at least
> > > drivers/video/omap/{Kconfig,Makefile}, if not drivers/video/omap/lcdc.c
> > > itself either, are modified for that as well. Am I missing something?
> > >
> > > If not, I can see two options:
> > > 1. Keep arch/arm/mach-omap1/lcd_dma.c linked in for any OMAP1 subarch
> > > unless CONFIG_FB_OMAP is not set. That can be cleaned up further after
> > > the drivers/video/omap/* stuff is ever modified.
> > > 2. Include drivers/video/omap/* modifications into this series.
> > >
> > > What do you suggest?
> >
> > Let's take option 1 for right now.  Maybe one of the htcwizard people
> > might take that project up after the LCD DMA split is merged.
> 
> I probably missed a third option: conditionally replacing declarations of 
> those functions required by lcdc.c with coresponding fake static inline 
> definitions inside an #ifdef block in lcd_dma.h. What do you think?

Just took a quick look at that lcdc.c file; I think we'd better leave 
those functions in, since they are so tightly integrated to the code. 
Hopefully one of the OMAP730/750/850 people can tease them out, since 
they've got a platform to test on.  Sound reasonable?  Less work for us, 
anyway :-)

- Paul

Re: omap3evm: touchscreen delays on pm branch

[Hemanth V]

- Original Message - 
From: "Premi, Sanjeev" 

To: 
Sent: Thursday, November 26, 2009 10:32 PM
Subject: omap3evm: touchscreen delays on pm branch



Hi,

I am finding the response of touchscreen on the omap3evm very slow.

Here is my test:
On console, I run : watch -n2 "cat /proc/interrupts"
Then, I tap the touchscreen approximately once per second. However,
(usually) no interrupts are registered. As I increase the frequency
of 'taps' more and more interrupts are registered. But still not
matching exact taps.

However, when I keep the cpu busy with "cat /dev/zero > /dev/null &"
each tap is recognized.

EVM uses GPIO175 for touchscreen. I notice that Zoom2 uses GPIO102.
Both are not on BANK0.

Is the behavior same on ZOOM2 as well?


I dont see this problem on Zoom2/Zoom3, I am able to see interrupts being
incremented for every touch.



Best regards,
Sanjeev
--
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] DSPBRIDGE: Interface tightening to check for invalid

[Ramos Falcon, Ernesto]

Hi,

>-Original Message-
>From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
>Sent: Tuesday, November 24, 2009 2:51 AM
>To: Ramos Falcon, Ernesto
>Cc: linux-omap@vger.kernel.org; Ramirez Luna, Omar; imre.d...@nokia.com;
>Shah, Bhavin
>Subject: Re: [PATCH] DSPBRIDGE: Interface tightening to check for invalid
>
>Hi Ernesto,
>
>From: "ext Ramos Falcon, Ernesto" 
>Subject: [PATCH] DSPBRIDGE: Interface tightening to check for invalid
>Date: Mon, 23 Nov 2009 21:12:08 +0100
>
>> From f28ec22e48a9b61ac00b7711e035e117bdc71aeb Mon Sep 17 00:00:00 2001
>> From: Ernesto Ramos 
>> Date: Mon, 23 Nov 2009 12:16:45 -0600
>> Subject: [PATCH] DSPBRIDGE: Interface tightening to check for invalid
>inputs.
>>
>> Move the error checking to kernel to address usecases
>> accessing kernel API directly.
>
>"memory_check_vma()" wasn't implemented for normal ioctl parameter
>checking, but one for bridge cache operations with kernel crash risk,
>especially with the following patch:
>
>  http://marc.info/?l=linux-omap&m=125810716419520&w=2
>
>This is because these memory area is expected that:
>
>  - its pages have been already populated.
>  - its pages shouldn't be swapped out.
>
>Otherwise there's risk of kernel crash at these cache operation,
>although "find_vma()" and "follow_page()" may be a bit heavier
>operation.
>

The intention with this patch is to further strengthen the dsp bridge driver.
I already executed some test cases to measure performance and the impact seems 
to be ~ 0.3% for a big amount of memory maps and flush memory commands, the 
latency impact is not even noticeable.

>For most of the normal cases, which just checks ioctl parameters,
>normal "access_ok()" would be enough. If it tries to access kernel
>address, just it returns error to userland. If it tries to access
>invalid address in user address space, the process dies with
>SIGSEGV. I think that normally it's ok that a process dies because of
>invalid address access rather than performance degrade.
>

I intended to use access_ok() for the purpose to check ioctl parameters, 
however, access_ok() seems not to work, I was able to send any invalid address 
to the bridge driver and no errors where reported. It seems that access_ok is 
rejecting only addresses that belong to the kernel space but the user would be 
able to send invalid address anyway.

>So I think that "memory_check_vma()" doesn't fit for normal ioctl
>parameter checking("copy_from_user"/"copy_to_user"), but "access_ok()"
>would work in most of normal cases.
>
>In macros, __cp_fm_usr()/__cp_to_usr(), adding "access_ok()" checking
>for pointers may work fine, I guess.
>

access_ok() is already called within copy_to_user() but the verification is 
being done after most of the processing is done, the intentions is to add these 
checks before any processing happens, and as I mentioned before access_ok does 
not work for all cases.

>> Signed-off-by: Ernesto Ramos 
>> ---
>>  arch/arm/plat-omap/include/dspbridge/dbdefs.h |3 +-
>>  drivers/dsp/bridge/pmgr/wcd.c |  263
>+++--
>>  drivers/dsp/bridge/rmgr/proc.c|   42 
>>  3 files changed, 249 insertions(+), 59 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

Re: [PATCH 0/8] Omap mux changes for v2.6.33 merge window (Series short description)

[Tony Lindgren]

* Mike Rapoport  [091126 03:19]:
> Tony,
> 
> Tony Lindgren wrote:
> > * Tony Lindgren  [091125 16:17]:
> >> Hi all,
> >>
> >> Here are some omap mux updates for review. These
> >> are intended for the v2.6.33 merge window.
> > 
> > Forgot to edit the subject :)
> > 
> > Also, these patches are available in the mux branch
> > of the linux-omap tree for easy testing.
> 
> After all the discussions we had, what would be preferable way to define the
> board mux configuration? The omap_board_mux array or a calls for
> omap_mux_init_signal?

You should be able to just boot with CONFIG_DEBUG_FS,
check how the pins are set, and adjust as needed via sysfs.
Then when happy with the settings, just do:

# cat /sys/kernel/debug/omap_mux/board
OMAP3_MUX(CAM_D0, OMAP_PIN_INPUT | OMAP_PIN_OFF_WAKEUPENABLE | OMAP_MUX_MODE4),
OMAP3_MUX(CAM_D10, OMAP_PIN_OUTPUT | OMAP_MUX_MODE7), 
OMAP3_MUX(CAM_D11, OMAP_PIN_INPUT | OMAP_PIN_OFF_WAKEUPENABLE | OMAP_MUX_MODE4),
OMAP3_MUX(CAM_D1, OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE | 
OMAP_MUX_MODE4),
OMAP3_MUX(CAM_D2, OMAP_PIN_INPUT | OMAP_PIN_OFF_WAKEUPENABLE | OMAP_MUX_MODE4), 
OMAP3_MUX(CAM_D3, OMAP_PIN_OUTPUT | OMAP_MUX_MODE4),
OMAP3_MUX(CAM_D4, OMAP_PIN_OUTPUT | OMAP_MUX_MODE7),
OMAP3_MUX(CAM_D5, OMAP_PIN_OUTPUT | OMAP_MUX_MODE4),
OMAP3_MUX(CAM_D6, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
OMAP3_MUX(CAM_D7, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
OMAP3_MUX(CAM_D8, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
OMAP3_MUX(CAM_D9, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
...

And then use the output for the struct omap_board_mux board_mux[]
in your board-*.c files.

For the common device init functions and omap_hwmod, we probably
want to use the signal names. That allows more generic initialization
of the internal devices, but some pins for sure still need to
be muxed in a board specific way.

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

omap3evm: touchscreen delays on pm branch

[Premi, Sanjeev]

Hi,

I am finding the response of touchscreen on the omap3evm very slow.

Here is my test:
On console, I run : watch -n2 "cat /proc/interrupts"
Then, I tap the touchscreen approximately once per second. However,
(usually) no interrupts are registered. As I increase the frequency
of 'taps' more and more interrupts are registered. But still not
matching exact taps.

However, when I keep the cpu busy with "cat /dev/zero > /dev/null &"
each tap is recognized.

EVM uses GPIO175 for touchscreen. I notice that Zoom2 uses GPIO102.
Both are not on BANK0.

Is the behavior same on ZOOM2 as well?

Best regards,
Sanjeev
--
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: Enabling HSUSB1 port on OMAP3430 labrador

[Gadiyar, Anand]

Kovacs Peter Tamas wrote:
> 
> Dear Anand,
> 
> thank you very much for your exhaustive answer and help. Unfortunately 
> it seems there is no clock signal coming out of the HSUSB1_CLK line.
> 
> >> We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host.
> >> To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to 
> >> the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).
> >>
> >> I have all these USB related kernel config options enabled:
> >> USB_EHCI_HCD
> >> USB_OHCI_HCD
> >> USB_MUSB_HDRC
> >> TWL4030_USB
> >>
> >> My guess was that either EHCI or the Inventra should be the one enabling 
> >> that USB port on the OMAP, but no luck.
> >> The external USB port on the MDK works fine with this configuration.
> >>
> >> The pin multiplexing configuration in the board file omap3430-labrador.c 
> >> in u-boot also seems to be correct (although the config of USB1_STP 
> >> seems to be strange, but changing that didn't work either).
> >> 
> >
> > HSUSB1 is not supposed to be used with the labrador (do you have a link
> > to the board schematics with the mods?). HSUSB1 is the EHCI port.
> >   
> What do you mean not supposed to be used? HSUSB0 goes to the TWL4030 and 
> then out of the casing. HSUSB2 goes to the ISP1702, but the pins are not 
> wired out on the Logic MDK baseboard so we cannot use that. Thus only 
> one possibility remains if we need an extra USB port inside the casing, 
> which is HSUSB1.


I meant there was nothing connected to it on the default board.
The pads are possibly brought out to the expansion connector, but
I haven't checked the schematic - so I'm not sure. I don't think
anyone's tried hooking up a transceiver to that port.


> > Not sure why the pad conf is done in u-boot for this board, but maybe
> > it was a copy-paste thing. That being said, if you've got the part
> > installed correctly, it ought to work.
> >   
> Yes, I can also see these pin multiplexing configs in 
> arch/arm/mach-omap2/usb-ehci.c.
> I have defined CONFIG_OMAP_EHCI_PHY_MODE there to make sure they are PHY 
> (couldn't find it in menuconfig, but this macro seems to be used in this 
> single file).
> Still, the clock goes high when powering the board on, and it remains 
> there forever.
> 
> I recall seeing a TI-specific kernel source in another git repository, 
> which had menuconfig options for setting PHY/TLL, maybe the USB code is 
> different too?
> 
> >> Note, the ISP1507A is connected to the following pins of the BGA:
> >> HSUSB1_STP (AF10)
> >> HSUSB1_CLK (AE10)
> >> HSUSB1_DIR (AF9)
> >> HSUSB1_NXP (AG9)
> >> HSUSB1_D0 (AF11)
> >> HSUSB1_D1 (AG12)
> >> HSUSB1_D2 (AH12)
> >> HSUSB1_D3 (AH14)
> >> HSUSB1_D4 (AE11)
> >> HSUSB1_D5 (AH9)
> >> HSUSB1_D6 (AF13)
> >> HSUSB1_D7 (AE13)
> >> 
> >
> > These are the pads for EHCI. So I suppose that's what you're trying to use.
> >   
> We suspect there might be a confusion here.
> According to the Logic 3430 SOM board schematic, HSUSB1_CLK is AE10 (and 
> also ETK_CLK, MMC3_CMD, GPIO_13).
> According to the OMAP3430 Multimedia Processor Data Manual version N 
> (OMAP3430_ES1.0_POP_DM_V_N.pdf), the AE10 pin can be ETK_CLK, HW_DBG1, 

Not sure about this - if it says ES1.0, that's a really old silicon
version. The HSUSB block was not present in that chip and there are
very very few of these chips floating around.

ES2.0 and greater all have this block and all boards in the wild (including
the labrador) should have an ES2 or greater chip.

> GPIO_13 and SYS_NDMAREQ1, so it mentions HW_DBG1 as Mode3 instead of USB.
> Then, in mach_omap2/usb-ehci.c, I can see  
> omap_cfg_reg(Y8_3430_USB1HS_PHY_CLK); Does this mean that Y8 is 
> configured as USB? According to the Logic schematic pin Y8 is UART1_RX 
> or GPIO_151, but not USB at all.

No, this is incorrect. Go with the setting in mach-omap2/mux.c.
All packages have the same pads for HSUSB1 lines, so there should be
no issue with this.

> 
> So far we have used the pins as seen in the Logic schematic for creating 
> an extension board with a number of SPI and GPIO signals, and everything 
> worked perfectly. Why are the pins described differently?
> 
> > Note that EHCI on the OMAP3 supports only the input clocking mode. This
> > might mean you need to check if you've configured the PHY correctly for
> > this mode. (No XTAL required, OMAP provides the clock to the PHY).
> > NXP seems to have removed all mention of this mode from their
> > data sheets, so you might want to check with them.
> >   
> Thanks, this is our fault. The clock pin of the ISP1507 is output only, 
> so it seems not to be compatible with the OMAP3430.
> The clock pin of the ISP1504 can be configured for I/O, however this 
> component is quite difficult to get, but it seems it's necessary.

You might want to take a look at the NXP ISP1703. I believe it's
available now and does officially support the input-clocking mode.
(Disclaimer: I haven't personally used with my OMAP3 SDP , but I was
informed that it works

Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

[Philby John]

On Thu, 2009-11-26 at 20:52 +0530, Aggarwal, Anuj wrote:
> > -Original Message-
> > From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> > Sent: Thursday, November 26, 2009 8:41 PM
> > To: Aggarwal, Anuj
> > Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org;
> > Arun KS
> > Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
> > hang
> > 
> > On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote:
> > 
> > > driver, although I am not sure if the problem is in the audio driver.
> > > When tried to capture, using NFS as storage, it gives overrun error and
> > comes out with:
> > > arecord: pcm_read:1617: read error: Input/output error
> > 
> > > It happen always after ~20 sec, file size ~5MB. Tried with multiple
> > > configurations in arecord but no use.
> > > When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't
> > > come too when I try to store the captured audio file on a MMC card.
> > 
> > > Any idea what could be the problem? Why arecord goes for a toss after a
> > > single overrun error and why it is happening always after ~20 sec? Is
> > > there something which can be tried to narrow down the problem?
> > 
> > Sounds like you've narrowed the problem down to a performance issue with
> > NFS writeout - it's probably having trouble keeping up with your I/O
> > rate.  This isn't 100% surprising with smaller systems, sometimes tuning
> > the NFS configuration can resolve the issue but sometimes the hardware
> > is just underspecified.
> [Aggarwal, Anuj] I am still surprised how this could be a NFS writeout issue
> as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd
> command is used for read/write to further check NFS performance, 2Mbps for 
> write and 4Mbps for read is observed.
> Does that still mean nfs is the culprit? What could be tweaked in 
> audio/network driver to avoid this problem, any suggestions?

My two cents... could also try connecting the target directly to your
host machine (using nfs), through a cross-cable (one with the Tx and Rx
crossed). If no errors are seen, then it surely must be an attribution
of network congestion.

Regards,
Philby

--
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: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

[Mark Brown]

On Thu, Nov 26, 2009 at 08:52:08PM +0530, Aggarwal, Anuj wrote:

> [Aggarwal, Anuj] I am still surprised how this could be a NFS writeout issue
> as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd
> command is used for read/write to further check NFS performance, 2Mbps for 
> write and 4Mbps for read is observed.
> Does that still mean nfs is the culprit? What could be tweaked in 
> audio/network driver to avoid this problem, any suggestions?

There can also be issues with the way the data gets pushed into NFS
interacting poorly - it's not just the raw data rate that's in play
here, it's also things like how often the writes are done and how big
they are.  Possibly also overhead from interacting with the ethernet
chip but that's not normally an issue for anything modern.

The fact that this only happens when NFS is in use seems a fairly clear
pointer to an interacton there.

> [Aggarwal, Anuj] Any other utility to try capture which does error
> recovering too?

Not for the console off the top of my head, and TBH I don't really know
how good the error handling is in the various apps.  You could also try
playing with the buffer size options in arecord.
--
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: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

[Aggarwal, Anuj]

The performance numbers are in Mbytes/sec. Sorry for the typo :(

> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Aggarwal, Anuj
> Sent: Thursday, November 26, 2009 8:52 PM
> To: Mark Brown
> Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org;
> Arun KS
> Subject: RE: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
> hang
> 
> > -Original Message-
> > From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> > Sent: Thursday, November 26, 2009 8:41 PM
> > To: Aggarwal, Anuj
> > Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-
> o...@vger.kernel.org;
> > Arun KS
> > Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
> > hang
> >
> > On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote:
> >
> > > driver, although I am not sure if the problem is in the audio driver.
> > > When tried to capture, using NFS as storage, it gives overrun error
> and
> > comes out with:
> > > arecord: pcm_read:1617: read error: Input/output error
> >
> > > It happen always after ~20 sec, file size ~5MB. Tried with multiple
> > > configurations in arecord but no use.
> > > When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't
> > > come too when I try to store the captured audio file on a MMC card.
> >
> > > Any idea what could be the problem? Why arecord goes for a toss after
> a
> > > single overrun error and why it is happening always after ~20 sec? Is
> > > there something which can be tried to narrow down the problem?
> >
> > Sounds like you've narrowed the problem down to a performance issue with
> > NFS writeout - it's probably having trouble keeping up with your I/O
> > rate.  This isn't 100% surprising with smaller systems, sometimes tuning
> > the NFS configuration can resolve the issue but sometimes the hardware
> > is just underspecified.
> [Aggarwal, Anuj] I am still surprised how this could be a NFS writeout
> issue
> as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd
> command is used for read/write to further check NFS performance, 2Mbps for
> write and 4Mbps for read is observed.
> Does that still mean nfs is the culprit? What could be tweaked in
> audio/network driver to avoid this problem, any suggestions?
> >
> > arecord is a pretty basic program and doesn't try terribly hard to
> > recover from errors.
> [Aggarwal, Anuj] Any other utility to try capture which does error
> recovering too?
> --
> 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: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Koen Kooi]

Op 26 nov 2009, om 15:20 heeft Tomi Valkeinen het volgende geschreven:

>> My kernel bootargs are:
>> mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/mmcblk0p2
>> rootfstype=ext2 rootdelay=1 nohz=off omapfb.rotate=1 omapfb.vrfb=y
>> omapfb.debug=y omapdss.debug=y

Try allocating some more VRAM for fb0 and fb1 and change 'rootdelay=1' to 
'rootwait' and remove 'nohz=off'

regards,

Koen--
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: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

[Aggarwal, Anuj]

> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Thursday, November 26, 2009 8:41 PM
> To: Aggarwal, Anuj
> Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org;
> Arun KS
> Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
> hang
> 
> On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote:
> 
> > driver, although I am not sure if the problem is in the audio driver.
> > When tried to capture, using NFS as storage, it gives overrun error and
> comes out with:
> > arecord: pcm_read:1617: read error: Input/output error
> 
> > It happen always after ~20 sec, file size ~5MB. Tried with multiple
> > configurations in arecord but no use.
> > When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't
> > come too when I try to store the captured audio file on a MMC card.
> 
> > Any idea what could be the problem? Why arecord goes for a toss after a
> > single overrun error and why it is happening always after ~20 sec? Is
> > there something which can be tried to narrow down the problem?
> 
> Sounds like you've narrowed the problem down to a performance issue with
> NFS writeout - it's probably having trouble keeping up with your I/O
> rate.  This isn't 100% surprising with smaller systems, sometimes tuning
> the NFS configuration can resolve the issue but sometimes the hardware
> is just underspecified.
[Aggarwal, Anuj] I am still surprised how this could be a NFS writeout issue
as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd
command is used for read/write to further check NFS performance, 2Mbps for 
write and 4Mbps for read is observed.
Does that still mean nfs is the culprit? What could be tweaked in audio/network 
driver to avoid this problem, any suggestions?
> 
> arecord is a pretty basic program and doesn't try terribly hard to
> recover from errors.
[Aggarwal, Anuj] Any other utility to try capture which does error 
recovering too?
--
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: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

[Mark Brown]

On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote:

> driver, although I am not sure if the problem is in the audio driver. 
> When tried to capture, using NFS as storage, it gives overrun error and comes 
> out with:
> arecord: pcm_read:1617: read error: Input/output error

> It happen always after ~20 sec, file size ~5MB. Tried with multiple
> configurations in arecord but no use.
> When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't 
> come too when I try to store the captured audio file on a MMC card.

> Any idea what could be the problem? Why arecord goes for a toss after a 
> single overrun error and why it is happening always after ~20 sec? Is
> there something which can be tried to narrow down the problem?

Sounds like you've narrowed the problem down to a performance issue with
NFS writeout - it's probably having trouble keeping up with your I/O
rate.  This isn't 100% surprising with smaller systems, sometimes tuning
the NFS configuration can resolve the issue but sometimes the hardware
is just underspecified.

arecord is a pretty basic program and doesn't try terribly hard to
recover from errors.
--
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 0/4] AM3517: MMC: Add support for HSMMC

[Aggarwal, Anuj]

> -Original Message-
> From: Aggarwal, Anuj
> Sent: Monday, November 23, 2009 11:55 PM
> To: linux-omap@vger.kernel.org
> Cc: Aggarwal, Anuj
> Subject: [PATCH 0/4] AM3517: MMC: Add support for HSMMC
> 
> This patch series adds support for HSMMC for AM3517 platform.
> It also enables the HSMMC driver in the AM3517 defconfig.
> 
> Anuj Aggarwal (4):
>   AM3517: MMC: Add low-level init code for HSMMC controller
>   AM3517: MMC: Modifying board-evm file to add mmc_init
>   AM3517: MMC: Modifying Makefile to enable MMC init
>   AM3517: MMC: Make HSMMC driver built-in
> 
>  arch/arm/configs/am3517_evm_defconfig |   21 +++-
>  arch/arm/mach-omap2/Makefile  |3 +-
>  arch/arm/mach-omap2/board-am3517evm.c |   22 +++
>  arch/arm/mach-omap2/mmc-am3517evm.c   |  267
> +
>  arch/arm/mach-omap2/mmc-am3517evm.h   |   22 +++
>  5 files changed, 333 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/mach-omap2/mmc-am3517evm.c
>  create mode 100644 arch/arm/mach-omap2/mmc-am3517evm.h

[Aggarwal, Anuj] Any comments on the patch series?
--
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: Enabling HSUSB1 port on OMAP3430 labrador

[Kovacs Peter Tamas]

Dear Anand, All,

We are trying to make the HSUSB1 port on the OMAP3430 work as an USB 
host.
To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected 
to the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).


I have all these USB related kernel config options enabled:
USB_EHCI_HCD
USB_OHCI_HCD
USB_MUSB_HDRC
TWL4030_USB

My guess was that either EHCI or the Inventra should be the one 
enabling that USB port on the OMAP, but no luck.

The external USB port on the MDK works fine with this configuration.

The pin multiplexing configuration in the board file 
omap3430-labrador.c in u-boot also seems to be correct (although the 
config of USB1_STP seems to be strange, but changing that didn't 
work either).  

Not sure why the pad conf is done in u-boot for this board, but maybe
it was a copy-paste thing. That being said, if you've got the part
installed correctly, it ought to work.
  
Yes, I can also see these pin multiplexing configs in 
arch/arm/mach-omap2/usb-ehci.c.
I have defined CONFIG_OMAP_EHCI_PHY_MODE there to make sure they are 
PHY (couldn't find it in menuconfig, but this macro seems to be used 
in this single file).
Still, the clock goes high when powering the board on, and it remains 
there forever.


I recall seeing a TI-specific kernel source in another git repository, 
which had menuconfig options for setting PHY/TLL, maybe the USB code 
is different too?
After having no clock signal on the HSUSB1_CLK with the kernel pulled 
from from git.kernel.org/linux/kernel/linux-omap-2.6.git, I've tried 
some older ti-2.6.xx kernel branches from 
git.omapzoom.org/repo/omapkernel.git


branch ti-2.6.27-omap3 didn't compile.
branch ti-2.6.26-omap3 kind of works, but the HSUSB1_CLK is still dead.
branch ti-2.6.24-omap3 works, and during booting I can see a clock 
signal on HSUSB1_CLK, and also the STP signal seems to go high and back 
low as expected!


Is it possible that this feature is broken some months ago? I'll go and 
compare the relevant files, but your suggestions on how to make this 
work again in newer kernels are welcome.


Thanks,
Peter

--
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: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

[Aggarwal, Anuj]

> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Thursday, November 26, 2009 3:53 PM
> To: Aggarwal, Anuj
> Cc: 'Troy Kisky'; alsa-de...@alsa-project.org; linux-omap@vger.kernel.org;
> Arun KS
> Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
> hang
> 
> On Thu, Nov 26, 2009 at 08:31:11AM +0530, Aggarwal, Anuj wrote:
> 
> > I have already tried that but it doesn't fix the problem entirely.
> > Still, I was not able to playback properly because the bias settings
> > were not handled correctly and as you can see, it writes to some
> > invalid registers too (all registers don't exist between 0 and
> ARRAY_SIZE).
> 
> Please also note the following patch which is queued for 2.6.32:
> 
> commit 50b6bce59d154b5db137907a5c0ed45a4e7a3829
> Author: Mark Brown 
> Date:   Mon Nov 23 13:11:53 2009 +
> 
> ASoC: Fix suspend with active audio streams
> 
[Aggarwal, Anuj] I am also seeing one more problem with the original 
driver, although I am not sure if the problem is in the audio driver. 
When tried to capture, using NFS as storage, it gives overrun error and comes 
out with:
arecord: pcm_read:1617: read error: Input/output error

It happen always after ~20 sec, file size ~5MB. Tried with multiple
configurations in arecord but no use.
When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't 
come too when I try to store the captured audio file on a MMC card.

Any idea what could be the problem? Why arecord goes for a toss after a 
single overrun error and why it is happening always after ~20 sec? Is
there something which can be tried to narrow down the problem?

--
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: [RFC] [PATCH] OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1 (Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set)

[Janusz Krzysztofik]

Thursday 26 November 2009 03:08:30 Paul Walmsley napisał(a):
> On Wed, 25 Nov 2009, Janusz Krzysztofik wrote:
> > It turned out not that simple. Since arch/arm/mach-omap1/lcd_dma.c
> > exports several functions that are called unconditionaly from
> > drivers/video/omap/lcdc.c AND the latter is linked into the omapfb
> > driver based on CONFIG_ARCH_OMAP1=y, linking in the former can't be
> > limited to selected OMAP1 subarchs unless at least
> > drivers/video/omap/{Kconfig,Makefile}, if not drivers/video/omap/lcdc.c
> > itself either, are modified for that as well. Am I missing something?
> >
> > If not, I can see two options:
> > 1. Keep arch/arm/mach-omap1/lcd_dma.c linked in for any OMAP1 subarch
> > unless CONFIG_FB_OMAP is not set. That can be cleaned up further after
> > the drivers/video/omap/* stuff is ever modified.
> > 2. Include drivers/video/omap/* modifications into this series.
> >
> > What do you suggest?
>
> Let's take option 1 for right now.  Maybe one of the htcwizard people
> might take that project up after the LCD DMA split is merged.

Paul,

I probably missed a third option: conditionally replacing declarations of 
those functions required by lcdc.c with coresponding fake static inline 
definitions inside an #ifdef block in lcd_dma.h. What do you think?

Thanks,
Janusz
--
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: Problems using DSS2 on OMAP3 EVM / Angstrom with rotation

[Tomi Valkeinen]

Hi,

On Wed, 2009-11-25 at 01:14 +0100, ext Eino-Ville Talvala wrote:
> Hi,
> 
> I'm trying to get Xorg running on an Angstrom distro image on the OMAP3
> EVM, with a rotated framebuffer.  The default screen orientation on the
> EVM is portrait, and I'm trying to change this to landscape.  Without
> any tweaking, using a kernel with your latest v5 DSS patches added on
> top (and Vaibhav's OMAP3 EVM DSS patches), DSS works and Angstrom
> happily displays both its initial bootup screen, and then the X server
> starts successfully.
> 
> Using the omapfb.rotate=1 kernel command-line option, the initial bootup
> screen still works, but as soon as the X server tries to start up, I get
> the following error on the console:
> 
> Starting GPE display manager: gpe-dm
> omapdss MANAGER error: dispc_setup_plane failed for ovl 0
> omapdss MANAGER error: configure_overlay 0 failed

It sounds to me that gpe-dm (or something running after that) is trying
to configure the overlay to 480x640 mode, and failing. If the initial
bootup screen (I believe this is drawn from the linux side, not boot
loader?) is fine, it hints that the problem is in the X server or some
other user space component.

> My kernel bootargs are:
> mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/mmcblk0p2
> rootfstype=ext2 rootdelay=1 nohz=off omapfb.rotate=1 omapfb.vrfb=y
> omapfb.debug=y omapdss.debug=y
> 
> Without vrfb=y, the initial boot screen won't show up, with a console
> message of 'omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX', and
> the same error for Xorg.

In practice you always have to use VRFB rotation on OMAP3, so no point
in trying without.

> I'd appreciate any advice you could give me - doing this (in theory
> simple) screen orientation change is really stumping me.

It sounds to me that the DSS and omapfb is working fine. I also tried
booting SDP board with similar boot arguments, and it's working fine
(although I'm not running X).

Perhaps there's some application that checks the display dimensions,
which are 480x640, and tries to use those regardless of the rotation.

 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

Re: [PATCH 0/9] dspbridge cleanup patches

[Felipe Contreras]

On Tue, Nov 24, 2009 at 2:50 AM, Omar Ramirez Luna  wrote:
> Following patches are cleanups, removing history of files,
> tab spacing and also remove DPC layer.

Any plans for the first release?

MODULE_VERSION("0.1");

-- 
Felipe Contreras
--
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: [RFC][PATCH v2] OMAP: McBSP: Use register cache

[Janusz Krzysztofik]

Thursday 26 November 2009 09:00:00 Jarkko Nikula napisał(a):
> Hi
>
> On Tue, 24 Nov 2009 12:31:16 +0100
>
> Janusz Krzysztofik  wrote:
> > -#define OMAP_MCBSP_READ(base, reg) \
> > -   omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg)
> > -#define OMAP_MCBSP_WRITE(base, reg, val) \
> > -   omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val)
> > +#define OMAP_MCBSP_READ(mcbsp, reg) \
> > +   omap_mcbsp_read(mcbsp->io_base, OMAP_MCBSP_REG_##reg)
> > +#define OMAP_MCBSP_WRITE(mcbsp, reg, val) \
> > +   omap_mcbsp_write(mcbsp->io_base, OMAP_MCBSP_REG_##reg, val)
> > +
> > +#define OMAP_MCBSP_CREAD(mcbsp, reg) \
> > +   (mcbsp->reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1])
> > +#define OMAP_MCBSP_CWRITE(mcbsp, reg, val) \
> > +   omap_mcbsp_write(mcbsp->io_base, OMAP_MCBSP_REG_##reg, \
> > +   mcbsp->reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1] \
> > +   = val)
> > +
>
> Have rather single write writing both the cache and actual register.
> I.e. keep the OMAP_MCBSP_WRITE since writes should always go to hw and
> makes the patch smaller.

Jarkko,
Not that I am against making things simpler, but please reconsider:

1. Is there any point for caching data written to DXR registers?

2. There is at least one register, WAKEUPEN, never updated bit by bit, but 
always rewritten from scratch with a few different values that can be 
computed easily from other msbsp structure member values. For these rare 
cases, is it any worth to bypass the cache while writing them, saving a few 
instructions maybe?

3. Sometimes a register is written several times in succession with different 
values, like SYSCON inside omap34xx_mcbsp_free(), for example. Could all 
writes but the last one bypass the cache for the same reason?

Another axample is omap_mcbsp_start() fiddling with SPCR2 several times. 
However, there is a udelay(500) inbetween that I am not sure if can ever 
happen to be interleaved with a concurrent suspend or idle or something like 
that requiring the cache being up-to-date.

That said, please confirm if a single write macro with caching still seems 
sufficient, or a separate one without caching would provide enough benefits 
to keep it as well.

> I also found the OMAP_MCBSP_CREAD a little 
> unclear so I suggest to name is as OMAP_MCBSP_READ_CACHE.

I just tried to minimize line wrapping :/. If we agree on a single caching 
version of OMAP_MCBSP_WRITE(), what about OMAP_CACHE_READ()? If no better 
ideas, I'll use what you suggest.

> > +#define OMAP_MCBSP_BREAD(mcbsp, reg) \
> > +   (mcbsp->reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1] \
> > +   = OMAP_MCBSP_READ(mcbsp->io_base, reg))
>
> Why is this? There is nothing eating this :-)

It's a part of a possible solution I am considering for SYSCON register 
handling. See below.

> > dev_dbg(mcbsp->dev, "DRR2:  0x%04x\n",
> > -   OMAP_MCBSP_READ(mcbsp->io_base, DRR2));
> > +   OMAP_MCBSP_READ(mcbsp, DRR2));
>
> These changes are worth to send as a separate cleanup patch. Will make
> the actual cache patch smaller and easier to follow.

OK, but let me recap that first. We have two options:

1. All macros accept very same arguments, as long as applicable.
   This is what I have put in my patch.

2. Every macro is optimized in respect of its argumnets, ie.
OMAP_MCBSP_READ(io_base, ...)
OMAP_MCBSP_READ_CACHE(reg_cache, ...)
OMAP_MCBSP_WRITE(mcbsp, ...)

Which one do you think is better?

> > @@ -93,15 +104,15 @@ static irqreturn_t omap_mcbsp_tx_irq_han
> > struct omap_mcbsp *mcbsp_tx = dev_id;
> > u16 irqst_spcr2;
> >
> > -   irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx->io_base, SPCR2);
> > +   irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx, SPCR2);
> > dev_dbg(mcbsp_tx->dev, "TX IRQ callback : 0x%x\n", irqst_spcr2);
> >
> > if (irqst_spcr2 & XSYNC_ERR) {
> > dev_err(mcbsp_tx->dev, "TX Frame Sync Error! : 0x%x\n",
> > irqst_spcr2);
> > /* Writing zero to XSYNC_ERR clears the IRQ */
> > -   OMAP_MCBSP_WRITE(mcbsp_tx->io_base, SPCR2,
> > -   irqst_spcr2 & ~(XSYNC_ERR));
> > +   OMAP_MCBSP_CWRITE(mcbsp_tx, SPCR2,
> > +   OMAP_MCBSP_CREAD(mcbsp_tx, SPCR2) & ~(XSYNC_ERR));
>
> I was thinking that should these read+read_cache changes be a separate
> patch for fixing the 1510 issues since no other OMAPs are known to
> corrupt registers and plain hw read is enough for them.

I see. Do you want the change limited to cpu_is_omap1510() case only?

> > @@ -612,7 +612,6 @@ EXPORT_SYMBOL(omap_mcbsp_stop);
> >  int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
> >  {
> > struct omap_mcbsp *mcbsp;
> > -   void __iomem *base;
> >
> > if (!omap_mcbsp_check_valid_id(id)) {
> > printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
> > @@ -620,28 +619,27 @@ int omap_mcbsp_pollwrite(unsig

[PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules

[Peter Ujfalusi]

Wake-up from McBSP ports are needed, especially when the THRESHOLD
dma mode is in use for audio playback.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-omap2/pm34xx.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 81ed252..6b17647 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -878,12 +878,16 @@ static void __init prcm_setup_regs(void)
/* Enable wakeups in PER */
prm_write_mod_reg(OMAP3430_EN_GPIO2 | OMAP3430_EN_GPIO3 |
  OMAP3430_EN_GPIO4 | OMAP3430_EN_GPIO5 |
- OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3,
+ OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3 |
+ OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 |
+ OMAP3430_EN_MCBSP4,
  OMAP3430_PER_MOD, PM_WKEN);
/* and allow them to wake up MPU */
prm_write_mod_reg(OMAP3430_GRPSEL_GPIO2 | OMAP3430_EN_GPIO3 |
  OMAP3430_GRPSEL_GPIO4 | OMAP3430_EN_GPIO5 |
- OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3,
+ OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3 |
+ OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 |
+ OMAP3430_EN_MCBSP4,
  OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
 
/* Don't attach IVA interrupts */
-- 
1.6.5.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

RE: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display

[Y, Kishore]

> -Original Message-
> From: G, Manjunath Kondaiah
> Sent: Tuesday, November 24, 2009 9:44 PM
> To: Y, Kishore; linux-omap@vger.kernel.org
> Subject: RE: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
> 
> 
> 
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org
> > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Y, Kishore
> > Sent: Friday, November 20, 2009 7:58 PM
> > To: linux-omap@vger.kernel.org
> > Subject: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
> >
> > From df64194feedc16c3f3f552dc26bc3050b7245005 Mon Sep 17 00:00:00 2001
> > From: Mukund Mittal 
> > Date: Fri, 20 Nov 2009 18:35:26 +0530
> > Subject: [PATCH] ZOOM: DSS2: Add nec panel for zoom display
> >
> > Nec panel has been added which is used on both
> > zoom2 and zoom3 boards
> >
> > Signed-off-by: Kishore Y 
> > ---
> >  drivers/video/omap2/displays/panel-nec.c |  291
> > ++
> >  1 files changed, 291 insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/video/omap2/displays/panel-nec.c
> >
> > diff --git a/drivers/video/omap2/displays/panel-nec.c
> > b/drivers/video/omap2/displays/panel-nec.c
> > new file mode 100644
> > index 000..c18f3ba
> > --- /dev/null
> > +++ b/drivers/video/omap2/displays/panel-nec.c
> > @@ -0,0 +1,291 @@
> > +/*
> > + * NEC panel support
> > + *
> > + * Copyright (C) 2008 Nokia Corporation
> > + * Author: Tomi Valkeinen 
> > + *
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be
> > useful, but WITHOUT
> > + * ANY WARRANTY; without even the implied warranty of
> > MERCHANTABILITY or
> > + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
> > Public License for
> > + * more details.
> > + *
> > + * You should have received a copy of the GNU General Public
> > License along with
> > + * this program.  If not, see .
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> 
> This will break the build since header files are moved to plat-omap.
> 
Comments taken. I will release v2 soon with all comments incorporated
> > +#include 
> 
> Remove this.
> 
> > +#include 
> > +#include 
> > +#include 
> > +
> 
> Remove extra line.
> 
Comments taken
> > +#include 
> > +
> > +#define LCD_XRES   800
> > +#define LCD_YRES   480
> > +
> 
> Remove extra line.
> 
> > +#define LCD_PIXCLOCK_MIN   21800 /* NEC MIN PIX
> > Clock is 21.8MHz */
> > +#define LCD_PIXCLOCK_TYP   23800 /* Typical PIX
> > clock is 23.8MHz */
> > +#define LCD_PIXCLOCK_MAX   25700 /* Maximum is 25.7MHz */
> > +
> 
> -Ditto-
> 
> > +/* Current Pixel clock */
> > +#define LCD_PIXEL_CLOCKLCD_PIXCLOCK_MIN
> > +
> > +
> 
> -Ditto-
> 
> > +/*NEC NL8048HL11-01B  Manual
> > + * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
> > + */
> > +
> > +static struct omap_video_timings nec_panel_timings = {
> > +   /* 800 x 480 @ 60 Hz  Reduced blanking VESA CVT 0.31M3-R */
> > +   .x_res  = LCD_XRES,
> > +   .y_res  = LCD_YRES,
> > +   .pixel_clock= LCD_PIXEL_CLOCK,
> > +   .hfp= 6,
> > +   .hsw= 1,
> > +   .hbp= 4,
> > +   .vfp= 3,
> > +   .vsw= 1,
> > +   .vbp= 4,
> > +};
> > +
> > +static int nec_panel_probe(struct omap_dss_device *dssdev)
> > +{
> > +   dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
> > +OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF |
> > +OMAP_DSS_LCD_ONOFF;
> 
> Checkpatch error - ERROR: code indent should use tabs where possible
> 
> > +   dssdev->panel.timings = nec_panel_timings;
> > +   dssdev->panel.recommended_bpp = 16;
> > +
> > +   return 0;
> > +}
> 
> This function will always return zero. Either check for sanity of function
> Parameters or change return value of the API to void.
> 
> > +
> > +static void nec_panel_remove(struct omap_dss_device *dssdev)
> > +{
> > +}
> > +
> > +static int nec_panel_enable(struct omap_dss_device *dssdev)
> > +{
> > +   int r = 0;
> > +
> > +   mdelay(4);
> 
> Add comment to justify the delay values used.
> 
> > +   if (dssdev->platform_enable)
> > +   r = dssdev->platform_enable(dssdev);
> > +
> > +   return r;
> 
> dssdev parameter is never used inside platform_enable.
> 
> I guess platform_enable will always return zero. Please take care
> of error checking conditions.
> 
> > +}
> > +
> > +static void nec_panel_disable(struct omap_dss_device *dssdev)
> > +{
> > +   if (dssdev->platform_disable)
> > +   dssdev->platform_disable(dssdev);
> dssdev parameter is never used inside platform_disable
> 
> > +   mdelay(4);
> Add comment to justify the delay values used.
> 
> > +}
>

Re: [PATCH 0/8] Omap mux changes for v2.6.33 merge window (Series short description)

[Mike Rapoport]

Tony,

Tony Lindgren wrote:
> * Tony Lindgren  [091125 16:17]:
>> Hi all,
>>
>> Here are some omap mux updates for review. These
>> are intended for the v2.6.33 merge window.
> 
> Forgot to edit the subject :)
> 
> Also, these patches are available in the mux branch
> of the linux-omap tree for easy testing.

After all the discussions we had, what would be preferable way to define the
board mux configuration? The omap_board_mux array or a calls for
omap_mux_init_signal?

> 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
> 

-- 
Sincerely yours,
Mike.

--
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/5] OMAP3: Fixed ARM aux ctrl register save/restore

[Gopinath, Thara]

>>-Original Message-
>>From: linux-omap-ow...@vger.kernel.org 
>>[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero
>>Kristo
>>Sent: Thursday, November 12, 2009 3:37 PM
>>To: linux-omap@vger.kernel.org
>>Subject: [PATCH 1/5] OMAP3: Fixed ARM aux ctrl register save/restore
>>
>>From: Tero Kristo 
>>
>>Current value is stored on SDRAM and it is written back during wakeup.
>>Previously a static value of 0x72 was written there.
>>
>>Signed-off-by: Tero Kristo 
>>---
>> arch/arm/mach-omap2/sleep34xx.S |   13 +
>> 1 files changed, 9 insertions(+), 4 deletions(-)
>>
>>diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
>>index 4707ba8..8bd5fc5 100644
>>--- a/arch/arm/mach-omap2/sleep34xx.S
>>+++ b/arch/arm/mach-omap2/sleep34xx.S
>>@@ -278,7 +278,8 @@ restore:
>>  mov r1, #0  @ set task id for ROM code in r1
>>  mov r2, #4  @ set some flags in r2, r6
>>  mov r6, #0xff
>>- adr r3, write_aux_control_params@ r3 points to parameters
>>+ ldr r4, scratchpad_base
>>+ ldr r3, [r4, #0xBC] @ r3 points to parameters
>>  mcr p15, 0, r0, c7, c10, 4  @ data write barrier
>>  mcr p15, 0, r0, c7, c10, 5  @ data memory barrier
>>  .word   0xE1600071  @ call SMI monitor (smi #1)
>>@@ -286,14 +287,14 @@ restore:
>>  b   logic_l1_restore
>> l2_inv_api_params:
>>  .word   0x1, 0x00
>>-write_aux_control_params:
>>- .word   0x1, 0x72
>> l2_inv_gp:
>>  /* Execute smi to invalidate L2 cache */
>>  mov r12, #0x1 @ set up to invalide L2
>> smi:.word 0xE1600070 @ Call SMI monitor (smieq)
>>  /* Write to Aux control register to set some bits */
>>- mov r0, #0x72
>>+ ldr r4, scratchpad_base
>>+ ldr r3, [r4,#0xBC]
>>+ ldr r0, [r3,#4]
>>  mov r12, #0x3
>>  .word 0xE1600070@ Call SMI monitor (smieq)
>> logic_l1_restore:
>>@@ -304,6 +305,7 @@ logic_l1_restore:
>>
>>  ldr r4, scratchpad_base
>>  ldr r3, [r4,#0xBC]
>>+ addsr3, r3, #8
>>  ldmia   r3!, {r4-r6}
>>  mov sp, r4
>>  msr spsr_cxsf, r5
>>@@ -420,6 +422,9 @@ usettbr0:
>> save_context_wfi:
>>  /*b save_context_wfi*/  @ enable to debug save code
>>  mov r8, r0 /* Store SDRAM address in r8 */
>>+ mrc p15, 0, r5, c1, c0, 1   @ Read Auxiliary Control Register
>>+ mov r4, #0x1@ Number of parameters for restore call
>>+ stmia   r8!, {r4-r5}
>> /* Check what that target sleep state is:stored in r1*/
>> /* 1 - Only L1 and logic lost */
>> /* 2 - Only L2 lost */

Looks Ok to me. Acked.
>>--
>>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

[PATCH V2] OMAP3: PM: Fix for MPU power domain MEM BANK position

[Thara Gopinath]

MPU power domain bank 0 bits are displayed in position of bank 1
in PWRSTS and PREPWRSTS registers. So read them from correct
position

Signed-off-by: Thara Gopinath 
Cc: Kevin Hilman 
---
 arch/arm/mach-omap2/powerdomain.c |6 ++
 arch/arm/mach-omap2/powerdomains34xx.h|1 +
 arch/arm/plat-omap/include/plat/powerdomain.h |5 -
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index b6990e3..1af447e 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -985,6 +985,9 @@ int pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
if (pwrdm->banks < (bank + 1))
return -EEXIST;
 
+   if (pwrdm->flags & PWRDM_HAS_MPU_QUIRK)
+   bank = 1;
+
/*
 * The register bit names below may not correspond to the
 * actual names of the bits in each powerdomain's register,
@@ -1032,6 +1035,9 @@ int pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, 
u8 bank)
if (pwrdm->banks < (bank + 1))
return -EEXIST;
 
+   if (pwrdm->flags & PWRDM_HAS_MPU_QUIRK)
+   bank = 1;
+
/*
 * The register bit names below may not correspond to the
 * actual names of the bits in each powerdomain's register,
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h 
b/arch/arm/mach-omap2/powerdomains34xx.h
index fd09b08..588f7e0 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -190,6 +190,7 @@ static struct powerdomain mpu_34xx_pwrdm = {
.wkdep_srcs   = mpu_34xx_wkdeps,
.pwrsts   = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
+   .flags= PWRDM_HAS_MPU_QUIRK,
.banks= 1,
.pwrsts_mem_ret   = {
[0] = PWRSTS_OFF_RET,
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h 
b/arch/arm/plat-omap/include/plat/powerdomain.h
index 3d45ee1..ad070a6 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -40,7 +40,10 @@
 
 /* Powerdomain flags */
 #define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-restore support */
-
+#define PWRDM_HAS_MPU_QUIRK(1 << 1) /* MPU pwr domain has MEM bank 0 bits
+ * in MEM bank 1 position. This is
+ * true for OMAP3430
+ */
 
 /*
  * Number of memory banks that are power-controllable. On OMAP3430, the
-- 
1.5.4.7

--
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: Enabling HSUSB1 port on OMAP3430 labrador

[Kovacs Peter Tamas]

Dear Anand,

thank you very much for your exhaustive answer and help. Unfortunately 
it seems there is no clock signal coming out of the HSUSB1_CLK line.



We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host.
To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to 
the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).


I have all these USB related kernel config options enabled:
USB_EHCI_HCD
USB_OHCI_HCD
USB_MUSB_HDRC
TWL4030_USB

My guess was that either EHCI or the Inventra should be the one enabling 
that USB port on the OMAP, but no luck.

The external USB port on the MDK works fine with this configuration.

The pin multiplexing configuration in the board file omap3430-labrador.c 
in u-boot also seems to be correct (although the config of USB1_STP 
seems to be strange, but changing that didn't work either).



HSUSB1 is not supposed to be used with the labrador (do you have a link
to the board schematics with the mods?). HSUSB1 is the EHCI port.
  
What do you mean not supposed to be used? HSUSB0 goes to the TWL4030 and 
then out of the casing. HSUSB2 goes to the ISP1702, but the pins are not 
wired out on the Logic MDK baseboard so we cannot use that. Thus only 
one possibility remains if we need an extra USB port inside the casing, 
which is HSUSB1.

Not sure why the pad conf is done in u-boot for this board, but maybe
it was a copy-paste thing. That being said, if you've got the part
installed correctly, it ought to work.
  
Yes, I can also see these pin multiplexing configs in 
arch/arm/mach-omap2/usb-ehci.c.
I have defined CONFIG_OMAP_EHCI_PHY_MODE there to make sure they are PHY 
(couldn't find it in menuconfig, but this macro seems to be used in this 
single file).
Still, the clock goes high when powering the board on, and it remains 
there forever.


I recall seeing a TI-specific kernel source in another git repository, 
which had menuconfig options for setting PHY/TLL, maybe the USB code is 
different too?



Note, the ISP1507A is connected to the following pins of the BGA:
HSUSB1_STP (AF10)
HSUSB1_CLK (AE10)
HSUSB1_DIR (AF9)
HSUSB1_NXP (AG9)
HSUSB1_D0 (AF11)
HSUSB1_D1 (AG12)
HSUSB1_D2 (AH12)
HSUSB1_D3 (AH14)
HSUSB1_D4 (AE11)
HSUSB1_D5 (AH9)
HSUSB1_D6 (AF13)
HSUSB1_D7 (AE13)



These are the pads for EHCI. So I suppose that's what you're trying to use.
  

We suspect there might be a confusion here.
According to the Logic 3430 SOM board schematic, HSUSB1_CLK is AE10 (and 
also ETK_CLK, MMC3_CMD, GPIO_13).
According to the OMAP3430 Multimedia Processor Data Manual version N 
(OMAP3430_ES1.0_POP_DM_V_N.pdf), the AE10 pin can be ETK_CLK, HW_DBG1, 
GPIO_13 and SYS_NDMAREQ1, so it mentions HW_DBG1 as Mode3 instead of USB.
Then, in mach_omap2/usb-ehci.c, I can see  
omap_cfg_reg(Y8_3430_USB1HS_PHY_CLK); Does this mean that Y8 is 
configured as USB? According to the Logic schematic pin Y8 is UART1_RX 
or GPIO_151, but not USB at all.


So far we have used the pins as seen in the Logic schematic for creating 
an extension board with a number of SPI and GPIO signals, and everything 
worked perfectly. Why are the pins described differently?



Note that EHCI on the OMAP3 supports only the input clocking mode. This
might mean you need to check if you've configured the PHY correctly for
this mode. (No XTAL required, OMAP provides the clock to the PHY).
NXP seems to have removed all mention of this mode from their
data sheets, so you might want to check with them.
  
Thanks, this is our fault. The clock pin of the ISP1507 is output only, 
so it seems not to be compatible with the OMAP3430.
The clock pin of the ISP1504 can be configured for I/O, however this 
component is quite difficult to get, but it seems it's necessary.

Also, do you see a 60MHz clock when you probe the HSUSB1_CLK line?
  
Unfortunately not. There is a constant high in the CLK line during the 
whole poweron and boot process, no matter if I configure the USB to PHY 
or TLL. We've also tried another Logic OMAP MDK unit and the effect is 
the same.


Could you please suggest what can be the cause of no clock signal (and 
other ULPI signals) appearing at all?


Thanks,
Peter
--
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 v2] musb: Add context save and restore support

[Gadiyar, Anand]

> 
> 
> > >  */
> > > +   reg = musb_readb(musb->mregs, MUSB_POWER);
> > > +   reg &= ~MUSB_POWER_SOFTCONN;
> > > +   musb_writeb(musb->mregs, MUSB_POWER, reg);
> > After this softdisconnect when we subsequently get reconnected followed by
> > a reset we could have changed our speed (LS,FS, HS).
> 
> I didn't get it completely. I think as a peripheral USB speed will remain
> same after resume for the gadget driver it was before suspend?
> 
> If we intend to change the gadget driver then we may have support for a
> different speed but it would anyways happen after resume is completed.
> 

The host side might change, but that shouldn't affect us. This bit is
used to tell MUSB (acting as a peripheral) if it should attempt
to enumerate at HS or not - it will always fall back to FS if the host
does not support it.

So Ajay is correct in restoring this register.

- Anand
--
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: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang

[Mark Brown]

On Thu, Nov 26, 2009 at 08:31:11AM +0530, Aggarwal, Anuj wrote:

> I have already tried that but it doesn't fix the problem entirely.
> Still, I was not able to playback properly because the bias settings
> were not handled correctly and as you can see, it writes to some 
> invalid registers too (all registers don't exist between 0 and ARRAY_SIZE).

Please also note the following patch which is queued for 2.6.32:

commit 50b6bce59d154b5db137907a5c0ed45a4e7a3829
Author: Mark Brown 
Date:   Mon Nov 23 13:11:53 2009 +

ASoC: Fix suspend with active audio streams

When we get a stream suspend event force the power down since otherwise
the stream would remain marked as active.  In future we'll probably want
to make this stream-specific and add an interface to make the power down
of other widgets optional in order to support leaving bypass paths
active while suspending the processor.

Cc: sta...@kernel.org
Reported-by: Joonyoung Shim 
Tested-by: Joonyoung Shim 
Acked-by: Liam Girdwood 
Signed-off-by: Mark Brown 

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index d89f6dc..66d4c16 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -973,9 +973,19 @@ static int dapm_power_widgets(struct snd_soc_codec *codec, 
int event)
if (!w->power_check)
continue;
 
-   power = w->power_check(w);
-   if (power)
-   sys_power = 1;
+   /* If we're suspending then pull down all the 
+* power. */
+   switch (event) {
+   case SND_SOC_DAPM_STREAM_SUSPEND:
+   power = 0;
+   break;
+
+   default:
+   power = w->power_check(w);
+   if (power)
+   sys_power = 1;
+   break;
+   }
 
if (w->power == power)
continue;
@@ -999,8 +1009,12 @@ static int dapm_power_widgets(struct snd_soc_codec 
*codec, int event)
case SND_SOC_DAPM_STREAM_RESUME:
sys_power = 1;
break;
+   case SND_SOC_DAPM_STREAM_SUSPEND:
+   sys_power = 0;
+   break;
case SND_SOC_DAPM_STREAM_NOP:
sys_power = codec->bias_level != SND_SOC_BIAS_STANDBY;
+   break;
default:
break;
}
--
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: DSS2 panel question

[Tomi Valkeinen]

On Wed, 2009-11-25 at 11:53 +0100, ext Grazvydas Ignotas wrote:
> On Mon, Nov 23, 2009 at 7:41 PM, TAO HU  wrote:
> > Hi,
> >
> > One idea as below
> >
> > struct spi_dss_device {
> >  struct omap_dss_device dss_dev;
> >  struct spi_dss_dev_priv  * spi_data;
> > } spi_dss_dev;
> 
> Hm, omap_dss_register_device() takes omap_dss_driver, not
> omap_dss_device. Anyway that wouldn't work if there were 2 instances
> of same panel in one system I guess, as 2 different spi_data instances
> would probe, when there is only one omap_dss_driver.
> 
> Instead I'm thinking to link omap_dss_device with spi in board file
> itself by (ab)using platform_data:
> 
> static struct omap_dss_device pandora_lcd_device = {
> ...
> };
> 
> struct spi_board_info pandora_spi_board_info = {
>   .bus_num = 1,
>   ...
>   .platform_data = pandora_lcd_device,
> };
> 
> Then in panel driver:
> 
> int spi_probe(struct spi_device *spi)
> {
>   struct omap_dss_device *dssdev = spi->dev.platform_data;
>   dev_set_drvdata(&dssdev->dev, spi);
> }
> 
> static int lcd_probe(struct omap_dss_device *dssdev)
> {
>   struct spi_device *spi = dev_get_drvdata(&dssdev->dev);
> }
> 
> Tomi, does that look reasonable to you?

Yes, the linking has to be done inside the board file somehow. I need to
try this at some point with N900's panel driver, but I think it looks
good.

I think you could also link it other way around, store the
spi_board_info inside the dss_device, but I don't immediately see that
this way is better than the other.

 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

RE: [PATCH 1/2 v2] musb: Add context save and restore support

[Gupta, Ajay Kumar]

Hi,
> -Original Message-
> From: Dasgupta, Romit
> Sent: Thursday, November 26, 2009 2:33 PM
> To: Gupta, Ajay Kumar
> Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
> felipe.ba...@nokia.com; Gadiyar, Anand
> Subject: Re: [PATCH 1/2 v2] musb: Add context save and restore support
> 
> > --- a/drivers/usb/musb/musb_core.c
> > +++ b/drivers/usb/musb/musb_core.c
> > @@ -2167,21 +2167,163 @@ static int __devexit musb_remove(struct
> platform_device *pdev)
> >
> >  #ifdef CONFIG_PM
> >
> > +static struct musb_context_registers musb_context;
> > +
> > +void musb_save_context(void __iomem *musb_base)
> > +{
> > +   int i;
> > +
> > +   musb_context.faddr = musb_readb(musb_base, MUSB_FADDR);
> > +   musb_context.power = musb_readb(musb_base, MUSB_POWER);
> > +   musb_context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE);
> > +   musb_context.intrrxe = musb_readw(musb_base, MUSB_INTRRXE);
> > +   musb_context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE);

> > +   musb_context.frame = musb_readw(musb_base, MUSB_FRAME);
> Not necessary for gadget
> > +   musb_context.testmode = musb_readb(musb_base, MUSB_TESTMODE);
> Not sure if it is necessary for gadget.

Right!

..so we can all #ifdefs to save/restore gadget or host only registers.
 

> > +   musb_context.index = musb_readb(musb_base, MUSB_INDEX);
> 
> 

> > +   musb_read_txfifosz(musb_base);
> > +   musb_context.index_regs[i].rxfifosz =
> > +   musb_read_rxfifosz(musb_base);
> 
> If MUSB_CONFIGDATA_DYNFIFO is not set then saving FIFO address and sizes
> are probably not necessary. Not sure if they are detrimental as well.

We can add it within DYNFIFO check.

> > +
> > +   musb_context.index_regs[i].txfunaddr =
> > +   musb_read_txfunaddr(musb_base, i);
> > +   musb_context.index_regs[i].txhubaddr =



> >  */
> > +   reg = musb_readb(musb->mregs, MUSB_POWER);
> > +   reg &= ~MUSB_POWER_SOFTCONN;
> > +   musb_writeb(musb->mregs, MUSB_POWER, reg);
> After this softdisconnect when we subsequently get reconnected followed by
> a reset we could have changed our speed (LS,FS, HS).

I didn't get it completely. I think as a peripheral USB speed will remain
same after resume for the gadget driver it was before suspend?

If we intend to change the gadget driver then we may have support for a
different speed but it would anyways happen after resume is completed.

Regards,
Ajay
> In your resume 
> routine we are writing back our previous speed. I am not sure here but is 
> it not possible that we have reset the controller and then restored back 
> the old speed overwriting the new speed?




--
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 v2] musb: Add context save and restore support

[Romit Dasgupta]

> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -2167,21 +2167,163 @@ static int __devexit musb_remove(struct 
> platform_device *pdev)
> 
>  #ifdef CONFIG_PM
> 
> +static struct musb_context_registers musb_context;
> +
> +void musb_save_context(void __iomem *musb_base)
> +{
> +   int i;
> +
> +   musb_context.faddr = musb_readb(musb_base, MUSB_FADDR);
> +   musb_context.power = musb_readb(musb_base, MUSB_POWER);
> +   musb_context.intrtxe = musb_readw(musb_base, MUSB_INTRTXE);
> +   musb_context.intrrxe = musb_readw(musb_base, MUSB_INTRRXE);
> +   musb_context.intrusbe = musb_readb(musb_base, MUSB_INTRUSBE);
> +   musb_context.frame = musb_readw(musb_base, MUSB_FRAME);
Not necessary for gadget
> +   musb_context.index = musb_readb(musb_base, MUSB_INDEX);

> +   musb_context.testmode = musb_readb(musb_base, MUSB_TESTMODE);
Not sure if it is necessary for gadget.

> +   musb_context.devctl = musb_readb(musb_base, MUSB_DEVCTL);
> +
> +   for (i = 0; i < MUSB_C_NUM_EPS; ++i) {
> +   musb_writeb(musb_base, MUSB_INDEX, i);
> +   musb_context.index_regs[i].txmaxp =
> +   musb_readw(musb_base, 0x10 + MUSB_TXMAXP);
> +   musb_context.index_regs[i].txcsr =
> +   musb_readw(musb_base, 0x10 + MUSB_TXCSR);
> +   musb_context.index_regs[i].rxmaxp =
> +   musb_readw(musb_base, 0x10 + MUSB_RXMAXP);
> +   musb_context.index_regs[i].rxcsr =
> +   musb_readw(musb_base, 0x10 + MUSB_RXCSR);
> +   musb_context.index_regs[i].rxcount =
> +   musb_readw(musb_base, 0x10 + MUSB_RXCOUNT);
> +   musb_context.index_regs[i].txtype =
> +   musb_readb(musb_base, 0x10 + MUSB_TXTYPE);
> +   musb_context.index_regs[i].txinterval =
> +   musb_readb(musb_base, 0x10 + MUSB_TXINTERVAL);
> +   musb_context.index_regs[i].rxtype =
> +   musb_readb(musb_base, 0x10 + MUSB_RXTYPE);
> +   musb_context.index_regs[i].rxinterval =
> +   musb_readb(musb_base, 0x10 + MUSB_RXINTERVAL);
> +
> +   musb_context.index_regs[i].txfifoadd =
> +   musb_read_txfifoadd(musb_base);
> +   musb_context.index_regs[i].rxfifoadd =
> +   musb_read_rxfifoadd(musb_base);
> +   musb_context.index_regs[i].txfifosz =
> +   musb_read_txfifosz(musb_base);
> +   musb_context.index_regs[i].rxfifosz =
> +   musb_read_rxfifosz(musb_base);

If MUSB_CONFIGDATA_DYNFIFO is not set then saving FIFO address and sizes are
probably not necessary. Not sure if they are detrimental as well.
> +
> +   musb_context.index_regs[i].txfunaddr =
> +   musb_read_txfunaddr(musb_base, i);
> +   musb_context.index_regs[i].txhubaddr =
> +   musb_read_txhubaddr(musb_base, i);
> +   musb_context.index_regs[i].txhubport =
> +   musb_read_txhubport(musb_base, i);
> +
> +   musb_context.index_regs[i].rxfunaddr =
> +   musb_read_rxfunaddr(musb_base, i);
> +   musb_context.index_regs[i].rxhubaddr =
> +   musb_read_rxhubaddr(musb_base, i);
> +   musb_context.index_regs[i].rxhubport =
> +   musb_read_rxhubport(musb_base, i);
> +   }
If we are in gadget mode, do we have to save this?
> +
> +   musb_writeb(musb_base, MUSB_INDEX, musb_context.index);
> +
> +   musb_platform_save_context(&musb_context);
> +}
Similar for restore.
>  static int musb_suspend(struct device *dev)
>  {
> struct platform_device *pdev = to_platform_device(dev);
> unsigned long   flags;
> struct musb *musb = dev_to_musb(&pdev->dev);
> +   u8 reg;
> 
> if (!musb->clock)
> return 0;
> 
> spin_lock_irqsave(&musb->lock, flags);
> 
> +   musb_save_context(musb->mregs);
> +
> if (is_peripheral_active(musb)) {
> -   /* FIXME force disconnect unless we know USB will wake
> -* the system up quickly enough to respond ...
> +   /* System is entering into suspend where gadget would not be
> +* able to respond to host and thus it will be in an unknown
> +* state for host.Re-enumemation of gadget is required after
> +* resume to make the gadget functional thus doing a force
> +* disconnect.
>  */
> +   reg = musb_readb(musb->mregs, MUSB_POWER);
> +   reg &= ~MUSB_POWER_SOFTCONN;
> +   musb_writeb(musb->mregs, MUSB_POWER, reg);
After this softdisconnect when we subsequently get reconnected followed by a
rese

Re: [PATCH 0/8] Series short description

[Tony Lindgren]

* Hemanth V  [091125 22:44]:
> - Original Message - From: "Tony Lindgren"
> 
> To: 
> Cc: 
> Sent: Thursday, November 26, 2009 5:48 AM
> Subject: [PATCH 0/8] Series short description
> 
> 
> >Hi all,
> >
> >Here are some omap mux updates for review. These
> >are intended for the v2.6.33 merge window.
> >
> >Initially this series changes the omap34xx mux
> >code, I'm planning on adding 3630, 2420, and 2430
> >code later on.
> >
> >There are several reasons why we need better mux
> >code:
> >
> >- We want to make the mux code more generic and this
> > will allow us to use the internal signal names and
> > gpio numbers instead of mux register offsets. The
> > internal signal names stay the same across omap
> > generations for some devices.
> >
> >- We need to map mux registers to GPIO registers for
> > dynamic muxing of the GPIO pins during off-idle.
> >
> >- We want to be able to override the bootloader mux
> > values for the modded boards, such as the Beagle.
> >
> >- We want to have the mux signals and balls available
> > under debugfs for debugging new drivers.
> 
> Does it also detect conflicts when two drivers try
> to step on each other and overwrite the mux settings of
> other. SPI and EHCI was one of the problems I faced.
 
It does not, but that could be added by adding a
usecount to struct omap_mux.

In fact it's already a problem with the cmdline mux
options as that does not prevent other init code from
muxing over the cmdline options.

But then again, just being able to override the
bootloader settings might do the trick for most people
customizing their Beagle boards.

Currently we're not checking the return values for
muxing, so adding a usecount sounds like a follow-up
patch after these changes.

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] OMAP: I2C: Add mpu wake up latency constraint in i2c

[kalle.jokiniemi]

Hi Ben,

Could you take this patch to i2c tree? The patch has been discussed in 
linux-omap list, and this version was the one that was agreed to pushed forward.

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


I tried it on top of linus' tree and it applied fine. 

- Kalle


> -Original Message-
> From: linux-omap-ow...@vger.kernel.org 
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
> Jokiniemi Kalle (Nokia-D/Tampere)
> Sent: 25. marraskuuta 2009 20:04
> To: ben-li...@fluff.org; linux-...@vger.kernel.org
> Cc: linux-omap@vger.kernel.org; Ujfalusi Peter 
> (Nokia-D/Tampere); Hogander Jouni (Nokia-D/Tampere); 
> khil...@deeprootsystems.com; ext Kalle Jokiniemi; Moiz 
> Sonasath; Jarkko Nikula; Paul Walmsley; Nishanth Menon
> Subject: [PATCH] OMAP: I2C: Add mpu wake up latency constraint in i2c
> 
> From: ext Kalle Jokiniemi 
> 
> 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 
> ---
>  arch/arm/plat-omap/i2c.c  |   54 
> +++-
>  drivers/i2c/busses/i2c-omap.c |   25 ---
>  include/linux/i2c-omap.h  |9 +++
>  3 files changed, 72 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 8b84839..3c122cd 100644
> --- a/arch/arm/plat-omap/i2c.c
> +++ b/arch/arm/plat-omap/i2c.c
> @@ -26,8 +26,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
>  #define OMAP_I2C_SIZE0x3f
>  #define OMAP1_I2C_BASE   0xfffb3800
> @@ -69,14 +71,14 @@ 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]),
>  #if  defined(CONFIG_ARCH_OMAP24XX) || defined(CONFIG_ARCH_OMAP34XX)
> - I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_rate[1]),
> + I2C_DEV_BUILDER(2, i2c_resources[1], &i2c_pdata[1]),
>  #endif
>  #if  defined(CONFIG_ARCH_OMAP34XX)
> - I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_rate[2]),
> + I2C_DEV_BUILDER(3, i2c_resources[2], &i2c_pdata[2]),
>  #endif
>  };
>  
> @@ -100,6 +102,31 @@ static const int omap34xx_pins[][2] = {};
>  
>  #define OMAP_I2C_CMDLINE_SETUP   (BIT(31))
>  
> +#ifdef CONFIG_ARCH_OMAP34XX
> +/*
> + * 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 void __init omap_i2c_mux_pins(int bus)  {
>   int scl, sda;
> @@ -180,8 +207,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] = ints[2];
> - i2c_rate[ints[1] - 1] |= OMAP_I2C_CMDLINE_SETUP;
> + i2c_pdata[ints[1] - 1].clkrate = ints[2];
> + i2c_pdata[ints[1] - 1].clkrate |= OMAP_I2C_CMDLINE_SETUP;
>  
>   return 1;
>  }
> @@ -195,9 +222,10 @@ static int __init 
> omap_register_i2c_bus_cmdline(void)
>  {
>   int i, err = 0;
>  
> - for (i = 0; i < ARRAY_SIZE(i2c_rate); i++)
> - if (i2c_rate[i] & OMAP_I2C_CMDLINE_SETUP) {
> - i2c_rate[i] &= ~OMAP_I2C_CMDLINE_SETUP;
> + for (i = 0; i < ARRAY_SIZE(i2c_pdata);