RE: [PATCH] OMAP: Exporting functions doing common register access

> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Aggarwal, Anuj > Sent: Tuesday, November 17, 2009 11:28 AM > To: Paul Walmsley > Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org > Subject: RE: [PATCH] OMAP: E

RE: [PATCH v2 1/1] omap: serial: fix non-empty uart fifo read abort

On Tue, 17 Nov 2009 17:39:11 -0600 Vikram Pandita wrote: > OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. > Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. Minor nitpicking for the changelog. OMAP3430 is better instead of OMAP3 here, since the 3

RE: [PATCH 2/8] musb: Get power (mA) from board data

Hi, > -Original Message- > From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] > Sent: Tuesday, November 17, 2009 9:12 PM > To: Gupta, Ajay Kumar > Cc: linux-...@vger.kernel.org; davinci-linux-open- > sou...@linux.davincidsp.com; coolo...@kernel.org; felipe.ba...@nokia.com; > linux-omap@

RE: [PATCH 4/8] musb: Update setup_usb() call for all Davinci boards

Hi, > -Original Message- > From: Sergei Shtylyov [mailto:sshtyl...@ru.mvista.com] > Sent: Tuesday, November 17, 2009 9:24 PM > To: Gupta, Ajay Kumar > Cc: linux-...@vger.kernel.org; davinci-linux-open- > sou...@linux.davincidsp.com; coolo...@kernel.org; felipe.ba...@nokia.com; > linux-omap@

RE: [PATCH 3/8] musb: Update musb_init() call for all OMAP3 boards

Hi, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Sergei Shtylyov > Sent: Tuesday, November 17, 2009 10:01 PM > To: Gupta, Ajay Kumar > Cc: linux-...@vger.kernel.org; davinci-linux-open- > sou...@linux.davincidsp.com;

Re: Is the OMAP patch process badly flawed?

On 17/11/09 22:07, Felipe Contreras wrote: > On Tue, Nov 17, 2009 at 3:30 PM, Sid Boyce wrote: >> I'm curious - I download, build and test kernels on x86 and x86_64 >> platforms, -rc, -rc-git and -git all build and run. > > [...] > >> I would expect patches sent upstream would result in all the

Re: [PATCH 2/9 v2] omap3: pm: introduce opp accessor functions

Menon, Nishanth had written, on 11/15/2009 08:54 AM, the following: [...] b) Improvements of the omap accessor functions, I will send out few of the proposals I can think of later when I get some free time.. we can discuss that too. Here is my initial proposal, do feel free to comment/add/modify

RE: [PATCH v2 1/1] omap: serial: fix non-empty uart fifo read abort

>-Original Message- >From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk] >Sent: Tuesday, November 17, 2009 7:00 PM >To: Pandita, Vikram >Cc: linux-omap@vger.kernel.org; Pandita, Vikram >Subject: Re: [PATCH v2 1/1] omap: serial: fix non-empty uart fifo read abort > >On Tue, 17 Nov 2009 17:39:

[PATCH 8/8] OMAP: omap_device: use UINT_MAX for default wakeup latency limit

The _dev_wakeup_lat_limit field of struct omap_device is u32, so use UINT_MAX instead of INT_MAX for the default maximum. Signed-off-by: Kevin Hilman --- arch/arm/plat-omap/omap_device.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/

[PATCH 2/8] OMAP: hwmod: warn on missing clockdomain

WARN if a clock/hwmod is missing a clockdomain association since resulting hwmod will not be able to correctly enable/disable clocks. Signed-off-by: Kevin Hilman --- arch/arm/mach-omap2/omap_hwmod.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/om

[PATCH 7/8] OMAP: omap_device: warn about expected latencies only if non-zero

When checking measured [de]activate latencies against expected latencies, only print warning if driver has provided a non-zero latency. This allows drivers to set their [de]activate latencies to zero when they are not known, or are don't care, and the omap_device core will not complain about unexp

[PATCH 3/8] OMAP3 hwmod: Add automatic OCP_SYSCONFIG AUTOIDLE handling

From: Paul Walmsley This patch fills in the OCP_SYSCONFIG.AUTOIDLE handling in the OMAP hwmod code. After this patch, the hwmod code will set the module AUTOIDLE bit (generally .OCP_SYSCONFIG.AUTOIDLE) to 1 by default upon enable, and 1 upon disable. If the hwmod flag HWMOD_NO_AUTOIDLE is set,

[PATCH 6/8] OMAP: omap_device: use read_persistent_clock() instead of getnstimeofday()

During suspend and resume, when omap_device deactivation and activation is happening, the timekeeping subsystem has likely already been suspended. Thus getnstimeofday() will fail and trigger a WARN(). Use read_persistent_clock() instead of getnstimeofday() to avoid this. Signed-off-by: Kevin Hil

[PATCH 4/8] OMAP: omap_device: deactivate latency typo

The deactivate hook should use 'deactivate_lat' instead of 'activate_lat' when doing checking on expected latency values. Signed-off-by: Kevin Hilman --- arch/arm/plat-omap/omap_device.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c

[PATCH 5/8] OMAP: omap_device: add usecounting

Add use counters to omap_device to enable multiple potential users of an omap_device. This is needed if ever there are multiple users or multiple instances of a driver with a single omap_device. Without usecounting, with multiple users, the first one to call idle may forcibly idle the device whil

[PATCH 1/8] OMAP3: clock: add clockdomains for UART1 & 2

UART1 & 2 were missing clockdomains resulting in broken omap_hwmod init for these devices. Signed-off-by: Kevin Hilman --- arch/arm/mach-omap2/clock34xx.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h i

[PATCH 0/8] omap_hwmod/omap_device prep work

In converting the UART drivers over to omap_hwmod/omap_device, I found a few issues. Kevin Hilman (7): OMAP3: clock: add clockdomains for UART1 & 2 OMAP: hwmod: warn on missing clockdomain OMAP: omap_device: deactivate latency typo OMAP: omap_device: add usecounting OMAP: omap_device: u

Re: [PATCH v2 1/1] omap: serial: fix non-empty uart fifo read abort

On Tue, 17 Nov 2009 17:39:11 -0600 Vikram Pandita wrote: > OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. > Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. > > Overrigt the default 8250 read handler: mem_serial_in() > by a custom handler: serial_

Re: [PATCH v2 1/1] omap: serial: fix non-empty uart fifo read abort

Pandita, Vikram had written, on 11/17/2009 05:39 PM, the following: OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. Overrigt the default 8250 read handler: mem_serial_in() <- I am just be

Re: [PATCH v2 1/1] omap: serial: fix non-empty uart fifo read abort

Vikram Pandita writes: > OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. > Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. > > Overrigt the default 8250 read handler: mem_serial_in() > by a custom handler: serial_in_8250() > > serial_in_8250() make

Re: linux-next: manual merge of the omap_dss2 tree with the omap tree

Hi Tomi, On Tue, 17 Nov 2009 12:00:31 +0200 Tomi Valkeinen wrote: > > On Mon, 2009-11-16 at 19:34 +0100, ext Tony Lindgren wrote: > > Tomi, please update your patch by leaving out the now unnecessary > > TWL4030 and regulator sections. See also the updated version of > > your patch attached. >

[PATCH v2] OMAP: timekeeping: time should not stop during suspend

During suspend, the kernel timekeeping subsystem is shut down. Before suspend and upon resume, it uses a weak function read_persistent_clock() to determine the amount of time that elapsed during suspend. This function was not implemented on OMAP, so from the timekeeping subsystem perspective (and

[PATCH v2 1/1] omap: serial: fix non-empty uart fifo read abort

OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. Overrigt the default 8250 read handler: mem_serial_in() by a custom handler: serial_in_8250() serial_in_8250() makes sure that RX fifo is not read when

[PATCH 12/12] AM35xx: Defconfig for AM3517 EVM board

From: Ranjith Lohithakshan This patch adds a minimal defconfig for AM3517 EVM board. Signed-off-by: Ranjith Lohithakshan Signed-off-by: Tony Lindgren --- arch/arm/configs/am3517_evm_defconfig | 1207 + 1 files changed, 1207 insertions(+), 0 deletions(-) create

[PATCH 11/12] AM35xx: Add support for AM3517 EVM board

From: Ranjith Lohithakshan This patch creates a minimal AM3517 EVM board support. Signed-off-by: Ranjith Lohithakshan Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/Kconfig |4 ++ arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/board-am3517evm.c | 86

[PATCH 10/12] omap3: Add defconfig for IGEP v2 board

From: Enric Balletbo i Serra Add defconfig for IGEP v2 board Signed-off-by: Enric Balletbo i Serra Signed-off-by: Tony Lindgren --- arch/arm/configs/igep0020_defconfig | 1554 +++ 1 files changed, 1554 insertions(+), 0 deletions(-) create mode 100644 arch/arm/

[PATCH 09/12] omap: 3630sdp: defconfig creation

From: vikram pandita Create 3630sdp defconfig file Signed-off-by: Vikram Pandita Signed-off-by: Tony Lindgren --- arch/arm/configs/omap_3630sdp_defconfig | 1611 +++ 1 files changed, 1611 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/omap_3630s

[PATCH 08/12] omap: 3630sdp: introduce 3630 sdp board support

From: vikram pandita Add 3630SDP board support The board shares the same peripherals as a zoom2 main. So reuse the peripheral file of zoom platform. Peripheralzoom2zoom3 sdp3630 --- Ethernetsmscsmscsmc NOR n/a n/a

[PATCH 07/12] omap3: Add minimal IGEP v2 support

From: Enric Balletbo i Serra The IGEP v2 board is a low-cost, fan-less and industrial temperature range single board computer that unleashes laptop-like performance and expandability without the bulk, expense, or noise of typical desktop machines. Its architecture shares much in common with other

[PATCH 06/12] omap3: Add CompuLab CM-T35 defconfig

From: Mike Rapoport Add CompuLab CM-T35 defconfig Signed-off-by: Mike Rapoport Signed-off-by: Tony Lindgren --- arch/arm/configs/cm_t35_defconfig | 1733 + 1 files changed, 1733 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/cm_t35_defco

[PATCH 05/12] omap3: Add CompuLab CM-T35 board support

From: Mike Rapoport This patch adds basic support for CompuLab CM-T35 module. Signed-off-by: Mike Rapoport Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/Kconfig|4 arch/arm/mach-omap2/Makefile |2 arch/arm/mach-omap2/board-cm-t35.c | 507 +++

[PATCH 04/12] omap3: rx51: Add wl1251 wlan driver support

From: Kalle Valo wl1251 is connected to the SPI bus in rx51, add support for this. Signed-off-by: Kalle Valo Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/board-rx51-peripherals.c | 85 ++ 1 files changed, 85 insertions(+), 0 deletions(-) diff --git a/arch/ar

[PATCH 03/12] omap3: rx51: Add SDRAM init

From: Tero Kristo This patch adds board specific SDRAM init for RX51. This patch is a collaboration of work from following people: Juha Yrjola: Original code Lauri Leukkunen: Port to RX51 Tero Kristo: Support for multiple OPP:s, merge of patches Samu Onkalo: Fixed SDRAM parameters according to s

[PATCH 02/12] omap1: Add default kernel configuration for Herald

From: Cory Maccarrone This adds a new defconfig for the HTC Herald series of devices. Signed-off-by: Cory Maccarrone Signed-off-by: Tony Lindgren --- arch/arm/configs/htcherald_defconfig | 1142 ++ 1 files changed, 1142 insertions(+), 0 deletions(-) create mod

[PATCH 01/12] omap1: Add board support and LCD for HTC Herald

From: Cory Maccarrone This patch introduces support for the HTC Herald (T-Mobile Wing, etc.) series of smart phones -- board support and LCD panel settings. Signed-off-by: Cory Maccarrone Signed-off-by: Tony Lindgren --- arch/arm/mach-omap1/Kconfig |6 + arch/arm/mach-omap1/Make

[PATCH 00/12] New omap boards and rx51/n900 updates for 2.6.33

Hi all, Here are some omap patches for review for the 2.6.33 merge window. This series mostly adds support for new boards, and updates the rx51/n900 devices. Regards, Tony --- Cory Maccarrone (2): omap1: Add board support and LCD for HTC Herald omap1: Add default kernel configurat

Re: [PATCH 3/3] OMAP clock/hwmod: fix off-by-one errors

* Pandita, Vikram [091117 09:50]: > Paul > > >-Original Message- > >From: linux-omap-ow...@vger.kernel.org > >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul > >Walmsley > >Sent: Tuesday, November 17, 2009 11:39 AM > >To: Russell King - ARM Linux > >Cc: linux-arm-ker...@lists

[APPLIED] [PATCH 2/3] OMAP3: Clock: Fixed dpll3_m2x2 rate calculation

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): 2dcbc9ebbe46c92e748e6180133d10cce69acb4d PatchWorks http://patchwork.kernel.org/patch/60368/ Git (Likely to change, and takes a while to get mirrore

[APPLIED] [PATCH 1/3] OMAP3 clock: Fix the DPLL freqsel computations

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): 8c3b128f6b50f9b8a6b015afeead77fd6de366a6 PatchWorks http://patchwork.kernel.org/patch/60367/ Git (Likely to change, and takes a while to get mirrore

Re: Is the OMAP patch process badly flawed?

On Tue, Nov 17, 2009 at 3:30 PM, Sid Boyce wrote: > I'm curious - I download, build and test kernels on x86 and x86_64 > platforms, -rc, -rc-git and -git all build and run. [...] > I would expect patches sent upstream would result in all the basics for > long established platforms to be fully co

Re: Is the OMAP patch process badly flawed?

On 17/11/09 14:51, Gadiyar, Anand wrote: > Sid Boyce wrote: > > > I would expect patches sent upstream would result in all the basics for long established platforms to be fully covered. Appreciating that development is quite fast paced with mods and supporting new platforms.

RE: [PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_READ flag

>-Original Message- >From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk] >Sent: Tuesday, November 17, 2009 3:26 PM >To: Pandita, Vikram >Cc: linux-ser...@vger.kernel.org; a...@linux-foundation.org; >linux-omap@vger.kernel.org; Pandita, >Vikram; Shilimkar, Santosh >Subject: Re: [PATCH 1/2] s

Re: [PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_READ flag

On Tue, 17 Nov 2009 15:16:55 -0600 Vikram Pandita wrote: > OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. > Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. Nothing wrong with the requirement but I think it would keep 8250.c a lot cleaner if you i

[PATCH 2/2] omap: serial: fix non-empty rx uart fifo abort

OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. so pass the flag UPF_NO_EMPTY_FIFO_READ in plat_serial8250_port, so that 8250 driver does not abort on empty rx fifo read tested on zoom3(3630) board S

[PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_READ flag

OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. So interoduce a flag in 8250 driver: UPF_NO_EMPTY_FIFO_READ If this flag is specified for an 8250 port, then first check if rx fifo has contents, and on

Re: [alsa-devel] Artifacts present in AIC23 capture for 48 KHz sampling rate

Aggarwal, Anuj wrote: >> -Original Message- >> From: Aggarwal, Anuj >> Sent: Friday, November 06, 2009 6:28 PM >> To: alsa-de...@alsa-project.org; 'linux-omap@vger.kernel.org' >> Subject: Artifacts present in AIC23 capture for 48 KHz sampling rate >> >> Hi, >> >> I am observing artifacts (s

Re: [PATCH] OMAP3: PM: Force write last pad config register into save area

Tero Kristo writes: > From: Tero Kristo > > Due to OMAP3 errata XYZ, the save of the last pad register (ETK_D14 and > ETK_D15) can fail sometimes when there is simultaneous OCP access to the > SCM register area. Fixed by writing the last register to the save area. > > Also, optimized the delay l

RE: [PATCH 3/3] OMAP clock/hwmod: fix off-by-one errors

Paul >-Original Message- >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul >Walmsley >Sent: Tuesday, November 17, 2009 11:39 AM >To: Russell King - ARM Linux >Cc: linux-arm-ker...@lists.infradead.org; Juha Leppänen; >linux-omap@vger.kern

Re: [PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_READ flag

* Pandita, Vikram [091117 09:39]: > Tony > > >From: linux-omap-ow...@vger.kernel.org > >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony > >Lindgren > >Sent: Tuesday, November 17, 2009 11:06 AM > >To: Pandita, Vikram > >Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh > >Subject: Re

RE: [PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_READ flag

Tony >From: linux-omap-ow...@vger.kernel.org >[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony >Lindgren >Sent: Tuesday, November 17, 2009 11:06 AM >To: Pandita, Vikram >Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh >Subject: Re: [PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_REA

Re: [PATCH 3/3] OMAP clock/hwmod: fix off-by-one errors

Hi Russell, On Mon, 16 Nov 2009, Russell King - ARM Linux wrote: > On Mon, Nov 16, 2009 at 06:36:55AM -0700, Paul Walmsley wrote: > > Fix loop bailout off-by-one bugs reported by Juha Leppänen > > . > > I'm not sure the new code is any easier to read than the old code. > And what with some check

[APPLIED] [PATCH v2] rx51: add wl1251 wlan driver support

This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 342dd6ea3d2067e84c0fdee5e07e264ce40827e0 PatchWorks http://patchwork.kernel.org/patch/60697/ Git (Likely to change, and takes a while to get mirrored)

Re: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.

* C.A, Subramaniam [091117 06:50]: > Hi Tony, > Following is the version 2 of Patch 8/10 (removing all #fidefs) Thanks, I have now them all in the for-next branch. > +/* OMAP4 specific data structure. Use the cpu_is_omap4xxx() > +to use this*/ I've updated the patch to have this comment is on

[PATCH (for-next)] ASoC: Add support for IGEP v2

From: Enric Balletbo i Serra Signed-off-by: Enric Balletbo i Serra --- arch/arm/mach-omap2/Kconfig |2 +- sound/soc/omap/Kconfig |7 ++ sound/soc/omap/Makefile |2 + sound/soc/omap/igep0020.c | 148 +++ 4 files changed, 158 insert

[APPLIED] [PATCH 10/10] omap mailbox: OMAP4 Mailbox-driver Patch to support tasklet implementation

This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 02a9bc601402df9544f35820fbef72c1b096344c PatchWorks http://patchwork.kernel.org/patch/59793/ Git (Likely to change, and takes a while to get mirrored)

RE: [PATCH] OMAP3: PM: Force write last pad config register into save area

Tero Kristo wrote: > From: Tero Kristo > > Due to OMAP3 errata XYZ, the save of the last pad register (ETK_D14 and XYZ is 1.157 > ETK_D15) can fail sometimes when there is simultaneous OCP access to the > SCM register area. Fixed by writing the last register to the save area. > > Also, optimiz

Re: [PATCH] OMAP3: PM: Force write last pad config register into save area

Tero Kristo had written, on 11/17/2009 10:34 AM, the following: From: Tero Kristo Due to OMAP3 errata XYZ, the save of the last pad register (ETK_D14 and ETK_D15) can fail sometimes when there is simultaneous OCP access to the SCM register area. Fixed by writing the last register to the save ar

Re: [PATCH 2/2] omap: serial: fix non-empty rx uart fifo abort

* Vikram Pandita [091116 15:00]: > Empty uart rx fifo read can cause omap to abort > OMAP silicon affected: OMAP3630, OMAP4430 > OMAP silicon not-affected: omap1/2/3 > > So pass flag UPF_NO_EMPTY_FIFO_READ in plat_serial8250_port, so that 8250 > driver does not abort on empty rx fifo read > > Te

Re: [PATCH 1/2] serial: 8250: add UPF_NO_EMPTY_FIFO_READ flag

* Vikram Pandita [091116 15:00]: > OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO. > Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction. > > So interoduce a flag in 8250 driver: UPF_NO_EMPTY_FIFO_READ > > If this flag is specified for an 8250 port, th

Re: [PATCH 7/10] omap mailbox: expose omap_mbox_enable()/disable_irq()

* C.A, Subramaniam [091117 05:06]: > > -Original Message- > > From: Tony Lindgren [mailto:t...@atomide.com] > > Sent: Saturday, November 14, 2009 6:10 AM > > To: C.A, Subramaniam > > Cc: linux-omap@vger.kernel.org; Gupta, Ramesh; Kanigeri, > > Hari; Hiroshi DOYU > > Subject: Re: [PATCH 7

Scalling_setspeed doesn't work

When I try to change the value of (scalling_setspeed) file ,it doesn't change however it doesn't rise errors as well,,but after changing it and trying to rereading it ,I found that nothing is changed !!!? BTW:-I'm using Linux kernel(2.6.29) on the beagleboard with the power management bra

[PATCH] OMAP3: PM: Force write last pad config register into save area

From: Tero Kristo Due to OMAP3 errata XYZ, the save of the last pad register (ETK_D14 and ETK_D15) can fail sometimes when there is simultaneous OCP access to the SCM register area. Fixed by writing the last register to the save area. Also, optimized the delay loop for the HW save to include an

Re: [PATCH 3/8] musb: Update musb_init() call for all OMAP3 boards

Ajay Kumar Gupta wrote: musb_init() has been modified to pass board specific data so updating this function call from all OMAP3 boards. Signed-off-by: Ajay Kumar Gupta [...] diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c index 1145a25..0e9380c 100644 --- a/a

[PATCH] OMAP3 : Enable TWL4030 Keypad for Zoom2 and Zoom3 boards

The TWL4030 keypad driver is not enabled by default for zoom2 and zoom3 boards. This patch will enable the same for both zoom2 and zoom3 boards. Tested on zoom2(3430) and zoom3(3630) boards. Signed-off-by: Manjunatha GK --- arch/arm/configs/omap_zoom2_defconfig |3 ++- arch/arm/configs/oma

Win FREE OMAP L 138 based HawkBoard !!!

FYI, > -Original Message- > From: Khasim Syed Mohammed [mailto:kha...@beagleboard.org] > Sent: Tuesday, November 17, 2009 9:43 PM > To: beaglebo...@googlegroups.com; hawkbo...@googlegroups.com > Subject: [beagleboard] Win FREE OMAP L 138 based HawkBoard !!! > > Hello, > > Today we will b

[PATCH 2/2] ASoC: Modifying the license string GPLv2 for OMAP3 EVM

Correcting the license string from GPLv2 -> GPL v2. Found the problem while building OMAP3 ASoC driver as module. Signed-off-by: Anuj Aggarwal --- sound/soc/omap/omap3evm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/omap/omap3evm.c b/sound/soc/omap/omap3e

[PATCH 1/2] ASoC: Correcting the config options in soc/omap/Makefile

Wrong config options were being used in the soc/omap/Makefile for OMAP2 & OMAP3 and AM3517 EVMs. Signed-off-by: Anuj Aggarwal --- sound/soc/omap/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 02d6947..a

Re: [PATCH 8/8] musb: set 'extvbus = 0' for Blackfin boards

Ajay Kumar Gupta wrote: Default value of 'extvbus' is being set as '0' to maintain the current programming state of all Blackfin musb boards. Again, you could keep the structures unitialized so that they default to all zeros (which they do anyway for the 'power' and 'potpgt' fields with y

Re: [PATCH v4, for-next] OMAP: DMA: Use some define rather than a hexadecimal constant for LCD register

* Janusz Krzysztofik [091117 02:45]: > Tuesday 17 November 2009 02:24:35 Tony Lindgren napisał(a): > > * Janusz Krzysztofik [091116 16:38]: > > > Tuesday 17 November 2009 01:16:58 Tony Lindgren napisał(a): > > > > * Janusz Krzysztofik [091116 15:13]: > > > > > diff -uprN a/arch/arm/plat-omap/dma

Re: [PATCH 4/8] musb: Update setup_usb() call for all Davinci boards

Ajay Kumar Gupta wrote: setup_usb() has been modified to pass board specific data so updating this function call from all Davinci based boards. Added "struct device;" to fix below compilation warning for Davinci boards. "musb.h: struct device, defined within parameter list" Signed-off-by:

[PATCH v2] rx51: add wl1251 wlan driver support

From: Kalle Valo wl1251 is connected to the SPI bus in rx51, add support for this. Signed-off-by: Kalle Valo --- arch/arm/mach-omap2/board-rx51-peripherals.c | 85 ++ 1 files changed, 85 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-rx51-perip

Re: [PATCH 4/8] musb: Update setup_usb() call for all Davinci boards

Ajay Kumar Gupta wrote: setup_usb() has been modified to pass board specific data so updating this function call from all Davinci based boards. Added "struct device;" to fix below compilation warning for Davinci boards. "musb.h: struct device, defined within parameter list" Signed-off-by:

Re: [PATCH 7/8] musb: set 'extvbus = 0' for Davinci boards

Ajay Kumar Gupta wrote: Default value of 'extvbus' is being set as '0' to maintain the current programming state of all Davinci musb boards. Signed-off-by: Ajay Kumar Gupta Pointless patch again... WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in

Re: [PATCH 6/8] musb: set 'extvbus = 0' for OMAP3 boards

Ajay Kumar Gupta wrote: Default value of 'extvbus' is being set as '0' to maintain the current programming state of all OMAP3 musb boards. This flag should be set to '1' for boards using external vbus supply such as, OMAP3EVM Rev >=E. This patch is rather pointless as the struct fieds not

Re: [PATCH 1/8] musb: Add structure to get board specific data

Ajay Kumar Gupta wrote: Adding 'musb_hdrc_board_data' which will have all the board specific parameters such as; mA power, potpgt, extvbus, gpios etc. Currently only 'power' and 'potpgt' is being moved from existing 'musb_hdrc_platform_data' to 'musb_hdrc_board_data' but any further board speci

Re: [PATCH 4/8] musb: Update setup_usb() call for all Davinci boards

Ajay Kumar Gupta wrote: setup_usb() has been modified to pass board specific data so updating this function call from all Davinci based boards. Added "struct device;" to fix below compilation warning for Davinci boards. "musb.h: struct device, defined within parameter list" You should fi

Re: [PATCH 2/8] musb: Get power (mA) from board data

Hello. Ajay Kumar Gupta wrote: Different board may have different power sourcing capability and now with 'struct musb_hdrc_board_data' in place; pass this data from board files and also modify musb_core.c to get 'power' data from 'plat->board_data'. This should be part of the patch 1/8 to

Re: [PATCH 1/8] musb: Add structure to get board specific data

Hello. Ajay Kumar Gupta wrote: Adding 'musb_hdrc_board_data' which will have all the board specific parameters such as; mA power, potpgt, extvbus, gpios etc. Currently only 'power' and 'potpgt' is being moved from existing 'musb_hdrc_platform_data' to 'musb_hdrc_board_data' but any further b

[PATCH 3/8] musb: Update musb_init() call for all OMAP3 boards

musb_init() has been modified to pass board specific data so updating this function call from all OMAP3 boards. Signed-off-by: Ajay Kumar Gupta --- arch/arm/mach-omap2/board-2430sdp.c |7 ++- arch/arm/mach-omap2/board-3430sdp.c |8 +++- arch/arm/mach-omap2/board-ldp.c

[PATCH 2/8] musb: Get power (mA) from board data

Different board may have different power sourcing capability and now with 'struct musb_hdrc_board_data' in place; pass this data from board files and also modify musb_core.c to get 'power' data from 'plat->board_data'. Signed-off-by: Ajay Kumar Gupta --- drivers/usb/musb/musb_core.c |4 +++-

[PATCH 1/8] musb: Add structure to get board specific data

Adding 'musb_hdrc_board_data' which will have all the board specific parameters such as; mA power, potpgt, extvbus, gpios etc. Currently only 'power' and 'potpgt' is being moved from existing 'musb_hdrc_platform_data' to 'musb_hdrc_board_data' but any further board specific functions or parameter

[PATCH 7/8] musb: set 'extvbus = 0' for Davinci boards

Default value of 'extvbus' is being set as '0' to maintain the current programming state of all Davinci musb boards. Signed-off-by: Ajay Kumar Gupta --- arch/arm/mach-davinci/board-dm355-evm.c |1 + arch/arm/mach-davinci/board-dm355-leopard.c |1 + arch/arm/mach-davinci/board-dm644x-

[PATCH 8/8] musb: set 'extvbus = 0' for Blackfin boards

Default value of 'extvbus' is being set as '0' to maintain the current programming state of all Blackfin musb boards. Signed-off-by: Ajay Kumar Gupta --- arch/blackfin/mach-bf527/boards/cm_bf527.c |6 ++ arch/blackfin/mach-bf527/boards/ezbrd.c|6 ++ arch/blackfin/mach-bf527/b

[PATCH 4/8] musb: Update setup_usb() call for all Davinci boards

setup_usb() has been modified to pass board specific data so updating this function call from all Davinci based boards. Added "struct device;" to fix below compilation warning for Davinci boards. "musb.h: struct device, defined within parameter list" Signed-off-by: Ajay Kumar Gupta --- arch/arm

[PATCH 6/8] musb: set 'extvbus = 0' for OMAP3 boards

Default value of 'extvbus' is being set as '0' to maintain the current programming state of all OMAP3 musb boards. This flag should be set to '1' for boards using external vbus supply such as, OMAP3EVM Rev >=E. Signed-off-by: Ajay Kumar Gupta --- arch/arm/mach-omap2/board-2430sdp.c |1

[PATCH 5/8] musb: Add 'extvbus' in musb_hdrc_board_data

Some of the board might use external Vbus power supply on musb interface which would require to program ULPI_BUSCONTROL register. Adding 'extvbus' flag which can be set from such boards which will be checked at musb driver files before programming ULPI_BUSCONTROL. Signed-off-by: Ajay Kumar Gupta

[PATCH 0/8] musb: Add structure 'musb_hdrc_board_data'

Hi, This patch set adds a new structure 'musb_hdrc_board_data' to get all board specific data from board files. It is actually done to accomodate ULPI_VBUSCONTROL programming required for OMAP3EVM Rev >=E which uses external Vbus supply to support 500mA. Necessarly changes have been done in all

RE: Is the OMAP patch process badly flawed?

Sid Boyce wrote: > >> > >> I would expect patches sent upstream would result in all the basics for > >> long established platforms to be fully covered. Appreciating that > >> development is quite fast paced with mods and supporting new platforms. > >> Could someone please enlighten me? > > > >

[PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox.

Hi Tony, Following is the version 2 of Patch 8/10 (removing all #fidefs) Regards Subbu >From 775dde65217785f519efe2a202489a791460f861 Mon Sep 17 00:00:00 2001 From: C A Subramaniam Date: Fri, 13 Nov 2009 16:42:40 +0530 Subject: [PATCH 8/10 v2] omap mailbox: OMAP4-Mailbox - Adds code changes to

[RFC] [PATCH] V4L2: Allow rotation between stream off-on

This patch is dependent on the patch [PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 >From cda5b97d02784318d89a029a2fde97903610d2b2 Mon Sep 17 00:00:00 2001 From: Kishore Y Date: Wed, 11 Nov 2009 19:22:46 +0530 Subject: [PATCH] V4L2: Allow rotation between stream off-

[RFC] [PATCH] omap_vout: Change allocated buffer to only needed size

This patch is dependent on the patch [PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 >From eb4302232f15e0af075604a9cf24fcaa9688e8a5 Mon Sep 17 00:00:00 2001 From: Kishore Y Date: Tue, 10 Nov 2009 21:44:10 +0530 Subject: [PATCH] omap_vout: Change allocated buffer to on

[RFC] [PATCH] omap_vout: default colorspace for RGB565 set to SRGB

This patch is dependent on the patch [PATCH 4/4] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2 >From 41b85f02f441771ace6c42ee08475ab7be04eb90 Mon Sep 17 00:00:00 2001 From: Kishore Y Date: Wed, 11 Nov 2009 19:47:14 +0530 Subject: [PATCH] omap_vout: default colorspace for RGB565

Re: Is the OMAP patch process badly flawed?

On 17/11/09 13:34, Gadiyar, Anand wrote: > Sid Boyce wrote: >> I'm curious - I download, build and test kernels on x86 and x86_64 >> platforms, -rc, -rc-git and -git all build and run. >> On the OMAP platform I have so far not been able to do that with >> omap-git, omap-dss2-git trees and snapshot

insmod on beagleboard

How can I compile modules and insert it to the kernel on the beagleboard?? After I wrote the C files and tried to compile , it failed and don't know hot to deal with this ?? Any help will be appreciated Thanks in advance. Best Regards, tarek -- To unsubscribe from this list: send the line "unsu

Re: OMAP3515 vs 3525 inversion

On Tue, Nov 17, 2009 at 4:39 PM, Premi, Sanjeev wrote: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sergey Lapin >> Sent: Monday, November 16, 2009 3:59 PM >> To: linux-omap@vger.kernel.org >> Subject: OMAP3515 vs

RE: OMAP3515 vs 3525 inversion

> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sergey Lapin > Sent: Monday, November 16, 2009 3:59 PM > To: linux-omap@vger.kernel.org > Subject: OMAP3515 vs 3525 inversion > > Hi, all! > I think I found a bug in proc

RE: Is the OMAP patch process badly flawed?

Sid Boyce wrote: > I'm curious - I download, build and test kernels on x86 and x86_64 > platforms, -rc, -rc-git and -git all build and run. > On the OMAP platform I have so far not been able to do that with > omap-git, omap-dss2-git trees and snapshots all missing basic hardware > support, e.g:- I

Is the OMAP patch process badly flawed?

I'm curious - I download, build and test kernels on x86 and x86_64 platforms, -rc, -rc-git and -git all build and run. On the OMAP platform I have so far not been able to do that with omap-git, omap-dss2-git trees and snapshots all missing basic hardware support, e.g:- I get the latest from gitorio

RE: Artifacts present in AIC23 capture for 48 KHz sampling rate

> -Original Message- > From: Aggarwal, Anuj > Sent: Friday, November 06, 2009 6:28 PM > To: alsa-de...@alsa-project.org; 'linux-omap@vger.kernel.org' > Subject: Artifacts present in AIC23 capture for 48 KHz sampling rate > > Hi, > > I am observing artifacts (sharp spikes at fixed interval

RE: [PATCH 8/10] omap mailbox: OMAP4-Mailbox - Adds code changes to support OMAP4 mailbox

> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Saturday, November 14, 2009 6:16 AM > To: C.A, Subramaniam > Cc: linux-omap@vger.kernel.org; Gupta, Ramesh; Kanigeri, > Hari; Hiroshi DOYU > Subject: Re: [PATCH 8/10] omap mailbox: OMAP4-Mailbox - Adds > code

  1   2   >