From: Felipe Balbi
We need to clk_put() and iounmap() to fully release
the resources.
Signed-off-by: Felipe Balbi
---
applies on top of the linux-omap/pm
arch/arm/mach-omap2/usb-musb.c | 33 ++---
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/
On Tue, 18 May 2010 21:13:11 +0100
Liam Girdwood wrote:
> This adds a method to set the MCBSP DMA OP mode.
>
> Signed-off-by: Liam Girdwood
> ---
> arch/arm/plat-omap/include/plat/mcbsp.h |2 ++
> arch/arm/plat-omap/mcbsp.c | 31
> +++
> 2 files
On Tue, 18 May 2010 15:56:46 -0500
"Candelaria Villarreal, Jorge" wrote:
> alsa-devel-boun...@alsa-project.org wrote:
> > Add a mechanism to register a machine specific callback
> > to calculate and set the McBSP Tx/Rx threshold.
> >
...
> > +int omap_bcbsp_set_threshold_func(struct snd_soc_dai
On Tue, 18 May 2010 21:13:12 +0100
Liam Girdwood wrote:
> Add a small API to configure McBSP smart idle modes
> to conserve power.
>
> Signed-off-by: Liam Girdwood
> ---
> arch/arm/plat-omap/include/plat/mcbsp.h | 15
> arch/arm/plat-omap/mcbsp.c | 122
> +
On Tue, 18 May 2010 21:13:10 +0100
Liam Girdwood wrote:
> I've also added a patch to remove the mcbsp DMA op mode sysfs set
> functionality.
> I think DMA op mode is very specific to the mcbsp client driver _only_ and
> shouldn't really be changed by userspace. Please let me know if you use this
(4:59), Guennadi Liakhovetski wrote:
ap4evb uses an LCD, connected to the SoC over the MIPI bus. This patch adds
platform data to configure this display and a static clock activation.
Signed-off-by: Guennadi Liakhovetski
Console framebuffer tested on sh-2.6 tree and sh/dmaengine branch with
the
(4:59), Guennadi Liakhovetski wrote:
> ap4evb uses an LCD, connected to the SoC over the MIPI bus. This patch adds
> platform data to configure this display and a static clock activation.
>
> Signed-off-by: Guennadi Liakhovetski
Console framebuffer tested on sh-2.6 tree and sh/dmaengine branch wit
(4:59), Guennadi Liakhovetski wrote:
> The LCDC block is allowed to use one of the two output data formats, when used
> with MIPI DSI: RGB24 and YUV422. YUV422 is not currently handled by the LCDC
> driver, but we have to add a define for it for MIPI. Fix indentation while
> at it.
>
> Signed-off-
(4:59), Guennadi Liakhovetski wrote:
> Some SH-mobile SoCs have a MIPI DSI controller, that can be used to connect
> MIPI displays to LCDC. This patch adds a platform driver for SH-mobile MIPI
> DSI
> unit. It uses existing hooks in the sh_mobile_lcdcfb.c driver for display
> activation and deacti
(4:59), Guennadi Liakhovetski wrote:
> This header adds defines for MIPI DSI and DCS commands and data formats. See
> http://www.mipi.org/ for details.
>
> Signed-off-by: Guennadi Liakhovetski
Console framebuffer tested on sh-2.6 tree and sh/dmaengine branch with
the necessary clock and intc patch
On Tue, 18 May 2010 14:05:21 +0200, Thomas Weber wrote:
> Some of these patches were submitted earlier but got no comments
> so I am sending them one more time.
>
> These patches correct errors that were done while using the board code
> from beagle board for Devkit8000.
>
> The Devkit8000 use
From: Benoit Cousson
Some initiator modules in OMAP2 & 3 does not have IDLEST bit,
in that case we cannot detect the module readiness by
polling that bit and must exist the function immediately
assuming that the module is ready.
The previous flag was affected to the OCP interface. While it is
te
From: Benoit Cousson
The WARN is a little bit too verbose and is not providing
usefull information in that case.
Signed-off-by: Benoit Cousson
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/
From: Benoit Cousson
The iteration is currently done on the omap_hwmod_ocp_if pointer
and not on the table pointer that reference them.
It worked most of the time because the structure are contiguous in
memory.
Signed-off-by: Benoit Cousson
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2
From: Benoit Cousson
The previous clock API was returning a standard linux error code in
case of failure. This is not the case anymore with the new
omap_clk_get_by_name API. A NULL value means that the clock node
does not exist.
Replace all the IS_ERR check by a !clk check.
Signed-off-by: Benoit
From: Benoit Cousson
During the _init_clocks phase, the iteration is stopped but the
status is still change from _HWMOD_STATE_REGISTERED to
_HWMOD_STATE_CLKS_INITED.
Since the _setup phase will be done nevertheless, it might be
better to keep initializing the others clocks nodes and just
keep the
From: Benoit Cousson
Most of the clock nodes belong to a clock domain, but it is perfectly valid
to have clock without clock domain.
Root clocks for example does not belong to any clock domain.
Keep the warning but reduce the verbosity.
Signed-off-by: Benoit Cousson
Signed-off-by: Paul Walmsley
From: Benoit Cousson
In the lastest OMAP4 hwmod data file, the _hwmod was removed
in order to save some memory space and because it does not
bring a lot.
The same cleanup will be have to done for other hwmods in
OMAP2 & 3 data files.
Signed-off-by: Benoit Cousson
Signed-off-by: Paul Walmsley
From: Benoit Cousson
The automatic HW restore from OFF mode is not functional at all in
OMAP4430 ES1.0.
Because of that, it will be extensively changed in the next Si revision,
and the compatibilty will not be maintained with ES1.0.
Remove the current XXX_RESTORE registers definition to avoid fu
From: Benoit Cousson
The MPU subsystem was named based on internal code name (CHIRON).
This patch will remove all the occurences of the chiron name
are replace it with PRCM_MPU in order to differentiate
the MPU local PRCM to the global one.
Remove PDA_ from PRCM_MPU registers names to stick to t
From: Benoit Cousson
CM1, CM2, PRM, SCRM and MPU_PRCM are already defined in omap44xx.h
Signed-off-by: Benoit Cousson
Signed-off-by: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/prcm-common.h |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm
From: Rajendra Nayak
The pwrsts flag for ALWAYS ON domains like always_on_core_pwrdm
and wkup_pwrdm is wrongly populated with the define for a
powerdomain power state, instead of the allowable state
bitfields.
This causes a few api's to fail sensing invalid pwrst
requested.
Signed-off-by: Rajend
From: Rajendra Nayak
The clock sources for timers on OMAP4 (system clock and 32k
clock) have their names wronly populated.
This patch fixes them so the omap_dm_timer_set_source
does not fail anymore.
Signed-off-by: Rajendra Nayak
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/dmtimer.c |
From: Rajendra Nayak
The cm44xx.h files only had absolute register address
defines for all CM registers.
This patch adds additional register offset defines for all the
registers, so they can be used with apis like cm_read_mod_*
Signed-off-by: Rajendra Nayak
Signed-off-by: Benoit Cousson
Signed
The OMAP2 MPU virtual clock node code attempted to call clk_get_rate()
while the clockfw_lock spinlock was held. Fix by reading the sys_ck
rate directly.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 17 -
1 files changed, 4 insertions(+), 13
Add some missing credits for people who have contributed significant features
or fixes.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Tero Kristo
Cc: Kevin Hilman
Cc: Thara Gopinath
---
arch/arm/mach-omap2/omap_hwmod.c | 10 +-
arch/arm/mach-omap2/powerdomain.c |2 +-
ar
From: Laine Walker-Avina
Add clock framework support for changing the rate of sys_clkout2.
Signed-off-by: Laine Walker-Avina
[p...@pwsan.com: added commit message, added .round_rate pointer]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock3xxx_data.c |2 ++
1 files changed, 2 in
From: Rajendra Nayak
Some powerdomains in OMAP4 support a direct transition from one sleep
state to another deeper sleep state without having to wakeup the
powerdomain. This patch adds an api in the powerdomain framework to
set the LOWPOWERSTATECHANGE bit in PWRSTCTRL register.
Signed-off-by: Ra
From: Rajendra Nayak
Remove the hack put in place while clock framework was still not in
place for OMAP4.
Signed-off-by: Rajendra Nayak
Signed-off-by: Paul Walmsley
---
arch/arm/plat-omap/clock.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/c
From: Rajendra Nayak
The prm44xx.h files only had absolute register address
defines for all PRM registers.
This patch adds additional register offset defines for all the
registers, so they can be used with apis like prm_read_mod_*
Signed-off-by: Rajendra Nayak
Signed-off-by: Benoit Cousson
Sig
From: Benoit Cousson
The return of the omap4_cm_wait_module_ready function is checked
in order to avoid accessing the sysconfig register if the module is
not in the correct state.
In that case the _setup will exit without trying to reset
using sysconfig.
For the moment a warning is printed. A pro
From: Benoit Cousson
The maximum timeout to wait for the PRCM to request that a module
exit idle or reach functionnal state is common to OMAP2/3/4 SoCs,
so, move it to the chip family-common cm.h include file.
Reduce the timeout from 20 ms to 2 ms.
Signed-off-by: Benoit Cousson
Signed-off-by:
From: Benoit Cousson
Accessing the clkctrl register using offset of module & device is hard
to do in OMAP4 due to the way the CM1, CM2, PRM and PRCM_MPU are located
in the address space. There is no common base address anymore for all the
CM registers.
The easiest way to handle that on OMAP4 is t
Hi,
here are some remaining patches intended for 2.6.35, in case
anyone has comments. The series consists almost entirely of fixes:
- hwmod infrastructure fixes from Benoît,
- OMAP4 PRCM macro fixes from Benoît,
- OMAP4 clock/powerdomain fixes from Rajendra,
- and some miscellaneous patches.
Hi Rajendra,
On Tue, 11 May 2010, Rajendra Nayak wrote:
> This is a short series of fixes for OMAP4 in the PM frameworks,
> clock/clockdomain and powerdomain.
>
> regards,
> Rajendra
>
> Rajendra Nayak (5):
> OMAP4 clock: Support clk_set_parent
> OMAP: timers: Fix clock source names for OMA
Specify new power field in struct omap_opp, which is
power exported in milliWatt.
power_usage function gives power consumed in milliWatt seconds
Signed-off-by: Mike Chan
---
arch/arm/plat-omap/cpu-omap.c | 23 ++-
arch/arm/plat-omap/include/plat/omap-pm.h |
Platform must register cpu power function that return power in
milliWatt seconds.
Signed-off-by: Mike Chan
---
Documentation/cgroups/cpuacct.txt |3 +++
include/linux/cpuacct.h |4 +++-
kernel/sched.c| 24 ++--
3 files changed, 28 inser
Implement OMAP platform specific scheduler callbacks for tracking
cpu frequencies per cpuacct cgroup.
Signed-off-by: Mike Chan
---
arch/arm/plat-omap/cpu-omap.c | 66 -
1 files changed, 65 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/cp
Introduce new platform callback hooks for cpuacct for tracking CPU frequencies
Not all platforms / architectures have a set CPU_FREQ_TABLE defined
for CPU transition speeds. In order to track time spent in at various
CPU frequencies, we enable platform callbacks from cpuacct for this accounting.
Rebased onto linux-next.
This patch series introduces cpu frequency and power tracking for cpuacct
cgroups. A similar patch set was discussed a while back and it was concluded
that due to varying architectures (ppc, x86 with overboot) you cannot account
for frequencies and their power consumption
>From 595a54c6a886d8e707e04cbf5d0d9b6d6de7c6ec Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo
Date: Tue, 18 May 2010 20:14:20 -0500
Subject: [PATCH] DSPBRIDGE: fix incorrect reset in bridge_brd_start function
IVA mmu reset was not being done properly, so dsp bootaddress
was not copied to SYS
> This patch is preventing dsp to go to OFF state after MMU Fault,As a
> result DSP recovery is not working.
>
> Here is the reg dump.The value of MAILBOX_IRQENABLE_DSP(0x4809410c)
> should have been 0x1.
@@ -492,12 +452,13 @@ static dsp_status bridge_brd_start(struct wmd_dev_context
*hDevCont
Hello Teerth,
On Fri, 23 Apr 2010, Reddy, Teerth wrote:
> From: Teerth Reddy
>
> This patch has the workaround for errata 1.176.
> In some cases, user is not able to access DDR memory after
> warm-reset.This situation occurs while the warm-reset
> happens during a read access to DDR memory. In
* Tony Lindgren [100517 19:37]:
> Add support for i2c init for omap4.
Below is this one rebased to apply on current for-next.
Regards,
Tony
From: Tony Lindgren
Date: Tue, 18 May 2010 16:19:16 -0700
Subject: [PATCH] omap4: Add support for i2c init
Add support for i2c init for omap4.
This patc
* Tony Lindgren [100517 19:37]:
> Add separate omap_i2c_add_bus functions for mach-omap1
> and mach-omap2. Make the mach-omap2 init set the interrupt
> dynamically to support.
>
> This is needed to add support for omap4 in a way that
> works with multi-omap builds. This will eventually get
> fixe
Since oprofile is a sysdev, its suspend/resume methods are called with
interrupts disabled. Using a mutex (which might sleep) in this atomic
context is not safe.
Since these methods are already called in atomic context, simply
remove the locking in the suspend/resume methods.
Found using lockdep
* Tony Lindgren [100517 19:45]:
> Hi,
>
> * kishore kadiyala [100515 11:15]:
> > Adding MMC1 and MMC2 controllers support for OMAP4
> >
> > V4:
> > - Rebased to "for_next" branch[LO].
> > - The first 3 patches [1,2,3] in the series are Minimal set of changes
> > with which MMC1/MMC2 works [No
On Tue, May 18, 2010 at 04:46:53PM -0700, Kevin Hilman wrote:
> If the _probe() method fails, the 'ts' struct is freed, yet it is
> still used as the drvdata passed to suspend/resume/remove methods.
> Even though the input device does not get registerd, the driver's
> suspend/resume methods still g
If the _probe() method fails, the 'ts' struct is freed, yet it is
still used as the drvdata passed to suspend/resume/remove methods.
Even though the input device does not get registerd, the driver's
suspend/resume methods still get called as it's a registered SPI
device. This patch adds sanity che
* Charulatha V [100518 07:44]:
> This patch adds support for handling GPIO as a HWMOD FW adapted
> platform device for OMAP2PLUS chips.
>
> Signed-off-by: Charulatha V
> --- /dev/null
> +++ b/arch/arm/mach-omap2/gpio.c
> +
> +/*
> + * gpio_init needs to be done before
> + * machine_init functio
* Charulatha V [100518 07:44]:
> This patch series implements GPIO module in platform device model.
> It also makes OMAP2PLUS specific GPIO implemented in HWMOD FW way.
>
> This patch series is created on "origin/pm-wip/runtime".
>
> This patch series is tested on OMAP3430 SDP board. It would be
* Charulatha V [100518 07:44]:
> This is in prepartion for implementing GPIO as a platform device.
> gpio bank's base addresses are moved from gpio.c to plat/gpio.h.
>
> This patch also modifies omap_gpio_init() to make use of
> omap_gpio_chip_init() and omap_gpio_mod_init(). omap_gpio_mod_init()
Hi,
Here you have the list of changes done so far for OMAP4 Keyboard
Controller Support v2. I'll appreciate if someone else has more comments
to share.
Vikram.Pandita.01| struct omap_device global
Govindraj.Raja.01| Extra space between interrupt and probe functions
---
[PATCH v2 1/4] In
Liam Girdwood writes:
> Add a small API to configure McBSP smart idle modes
> to conserve power.
Would be useful here to explain why client drivers need to change
idle modes.
Also, this patch is telling me that it's time the McBSP is converted
over to the omap_hwmod/omap_device infrastructure w
On Thu, 22 Apr 2010, Paul Walmsley wrote:
> Hello Laine,
>
> two minor comments:
>
> On Tue, 6 Apr 2010, Laine Walker-Avina wrote:
>
> >
> > Signed-off-by: Laine Walker-Avina
>
> Please add a brief changelog. Nothing fancy needed...
>
> > ---
> > arch/arm/mach-omap2/clock3xxx_data.c |
alsa-devel-boun...@alsa-project.org wrote:
> Add a mechanism to register a machine specific callback
> to calculate and set the McBSP Tx/Rx threshold.
>
> Signed-off-by: Liam Girdwood
> ---
> sound/soc/omap/omap-mcbsp.c | 22 +-
> sound/soc/omap/omap-mcbsp.h |2 ++
> 2
Liam Girdwood had written, on 05/18/2010 03:13 PM, the following:
Add a small API to configure McBSP smart idle modes
to conserve power.
Signed-off-by: Liam Girdwood
---
arch/arm/plat-omap/include/plat/mcbsp.h | 15
arch/arm/plat-omap/mcbsp.c | 122
On Tue, May 18, 2010 at 09:13:13PM +0100, Liam Girdwood wrote:
> Add a mechanism to register a machine specific callback
> to calculate and set the McBSP Tx/Rx threshold.
It's a shame the default implementation can't work for everyone but
there we are. :(
> Signed-off-by: Liam Girdwood
All of
The mcbsp DMA op mode is tightly integrated with the
mcbsp client driver operation and hence is unsuitable
for userspace configuration via sysfs.
Signed-off-by: Liam Girdwood
---
arch/arm/plat-omap/mcbsp.c | 30 +-
1 files changed, 1 insertions(+), 29 deletions(-)
Add a mechanism to register a machine specific callback
to calculate and set the McBSP Tx/Rx threshold.
Signed-off-by: Liam Girdwood
---
sound/soc/omap/omap-mcbsp.c | 22 +-
sound/soc/omap/omap-mcbsp.h |2 ++
2 files changed, 23 insertions(+), 1 deletions(-)
diff --git
Add a small API to configure McBSP smart idle modes
to conserve power.
Signed-off-by: Liam Girdwood
---
arch/arm/plat-omap/include/plat/mcbsp.h | 15
arch/arm/plat-omap/mcbsp.c | 122 +++
2 files changed, 137 insertions(+), 0 deletions(-)
diff --
This adds a method to set the MCBSP DMA OP mode.
Signed-off-by: Liam Girdwood
---
arch/arm/plat-omap/include/plat/mcbsp.h |2 ++
arch/arm/plat-omap/mcbsp.c | 31 +++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/
This series expands the OMAP mcbsp driver to support changing it's DMA operating
mode and smart idle mode from client drivers. It's primarily aimed at lowering
the power consumption for OMAP ASoC drivers by providing methods to gate clocks
on the mcbsp interface at runtime.
I've also added a patch
From: ext Felipe Contreras
Subject: Re: [PATCH v2 00/17] omap: mailbox: reorganize init
Date: Tue, 18 May 2010 18:57:55 +0200
> On Tue, May 18, 2010 at 4:31 PM, Hiroshi DOYU wrote:
>> From: ext Felipe Contreras
>>> I'm not familiar with this kind of module loading, but certainly not
>>> all sys
Hi Benoît,
On Mon, 10 May 2010, Benoit Cousson wrote:
> This series remove a couple of useless or non-functional registers
> from the OMAP4430 ES1.0 defines.
> It cleans as well the registers that didn't stick to the PRCM
> naming convention and add a couple of new defines for offset.
Thanks, q
Hi Benoît,
On Fri, 7 May 2010, Benoit Cousson wrote:
> Here is the serie based on l-o master that prepare the OMAP4 HWMOD database
> introduction.
>
> It was only tested on OMAP4 GP device for the moment using PAB board.
Thanks, queued for 2.6.35.
- Paul
On Tue, 18 May 2010 15:48:48 +0300
Eduardo Valentin wrote:
> > @@ -285,6 +287,9 @@ static struct regulator_consumer_supply
> > rx51_vmmc2_supplies[] = {
> > /* tlv320aic3x analog supplies */
> > REGULATOR_SUPPLY("AVDD", "2-0018"),
> > REGULATOR_SUPPLY("DRVDD", "2-0018"),
> > + /* t
On Tue, May 18, 2010 at 3:34 PM, Robert Nelson wrote:
> On Tue, May 18, 2010 at 2:55 AM, Tomi Valkeinen
> wrote:
>> On Mon, 2010-05-17 at 16:30 +0200, ext Robert Nelson wrote:
>>> Hi Tomi,
>>>
>>> I've been using your dss2 branch with much success.
>>>
>>> http://gitorious.org/linux-omap-dss2/lin
Hi Hiroshi,
> -Original Message-
> From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
> Sent: Tuesday, May 18, 2010 1:12 AM
> To: Kanigeri, Hari
> Cc: linux-omap@vger.kernel.org; t...@atomide.com; Gupta, Ramesh
> Subject: Re: [PATCH 2/2] omap: iommu-add functionality to get TLB miss
> int
On Tue, May 18, 2010 at 4:31 PM, Hiroshi DOYU wrote:
> From: ext Felipe Contreras
>> I'm not familiar with this kind of module loading, but certainly not
>> all systems have udev.
>>
>> I realized the problem because I have a bare-bones system in my
>> beagleboard where I had to manually load mai
Hi Hiroshi,
> -Original Message-
> From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com]
> Sent: Tuesday, May 18, 2010 1:12 AM
> To: Kanigeri, Hari
> Cc: linux-omap@vger.kernel.org; t...@atomide.com
> Subject: Re: [PATCH 1/2] omap: iommu-update irq mask to be specific about
> twl
>
> > Updat
"Sripathy, Vishwanath" writes:
>> All that being said, why is the voltage level being programmed here?
>>
>> It seems to me that all of this errata handling should be
>> self-contained in the voltage layer.
>
> I am not sure if entire errata can be contained in voltage
> layer. This is because w
Matt Fleming writes:
> On Fri, May 14, 2010 at 09:51:21AM -0700, Kevin Hilman wrote:
>>
>> I don't see a reason either, but it requires patching the MMC core as
>> well as all the users. As I'm not an MMC core person, I thought this
>> best left to someone in that domain.
>>
>> Fixing the core
Kevin,
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Friday, May 14, 2010 11:28 PM
> To: Gulati, Shweta
> Cc: linux-omap@vger.kernel.org; Sripathy, Vishwanath
> Subject: Re: [PATCH V2] OMAP3: PM: Workaround for DPLL3 Lock issue
>
> shweta gulati w
This patch adds support for handling OMAP16xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V
---
arch/arm/mach-omap1/gpio16xx.c | 202
1 files changed, 202 insertions(+), 0 deletions(-)
cr
This is in prepartion for implementing GPIO as a platform device.
gpio bank's base addresses are moved from gpio.c to plat/gpio.h.
This patch also modifies omap_gpio_init() to make use of
omap_gpio_chip_init() and omap_gpio_mod_init(). omap_gpio_mod_init() does
the module init by clearing the stat
This patch removes the usage of omap_gpio_init() in from all
omap board files since omap_gpio_init() does nothing, after gpio
is implemented as a platform device.
Signed-off-by: Charulatha V
---
arch/arm/mach-omap1/board-ams-delta.c |1 -
arch/arm/mach-omap1/board-fsample.c|
This patch adds support for handling OMAP7xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V
---
arch/arm/mach-omap1/gpio7xx.c | 266 +
1 files changed, 266 insertions(+), 0 deletions(-)
cre
Add hwmod structures for GPIO module on OMAP243X
Signed-off-by: Charulatha V
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 270
1 files changed, 270 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap
This patch implements GPIO as a platform device. Also it
implements OMAP2PLUS specific GPIO as HWMOD FW adapted device.
GPIO APIs are used in machine_init functions. Hence it is
required to complete GPIO probe before machine_init. Therefore
GPIO device register and driver register are implemented
This patch series implements GPIO module in platform device model.
It also makes OMAP2PLUS specific GPIO implemented in HWMOD FW way.
This patch series is created on "origin/pm-wip/runtime".
This patch series is tested on OMAP3430 SDP board. It would be of
great help if someone could test the sam
This patch adds support for handling OMAP15xx specific gpio_init
by providing platform device data and doing device registration.
Signed-off-by: Charulatha V
---
arch/arm/mach-omap1/gpio15xx.c | 99
1 files changed, 104 insertions(+), 0 deletions(-)
cre
This patch introduces platform_data structure for GPIO
so that GPIO module can be implemented in platform device model.
Signed-off-by: Charulatha V
---
arch/arm/plat-omap/include/plat/gpio.h | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-oma
Add hwmod structures for GPIO module on OMAP242X
Signed-off-by: Charulatha V
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 222
1 files changed, 222 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap
Add hwmod structures for GPIO module on OMAP3
Signed-off-by: Charulatha V
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 357 +++-
1 files changed, 356 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
This patch adds support for handling GPIO as a HWMOD FW adapted
platform device for OMAP2PLUS chips.
Signed-off-by: Charulatha V
---
arch/arm/mach-omap2/gpio.c | 113
1 files changed, 113 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mac
On Tuesday 18 May 2010 11:07:20 Carlos Chinea wrote:
[cut]
> > > + val |= __raw_readl(omap_ssi->sys +
> > > SSI_MPU_ENABLE_REG(port->num, 0)); + __raw_writel(val,
> > > omap_ssi->sys +
> > > SSI_MPU_ENABLE_REG(port->num, 0)); +
> > > + msg->status = HSI_STATUS_COMPLETED;
> > > +
On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote:
> On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote:
> >Right, because Firmware writers are from the rugged unresponsive uplands
> >of planet
> >ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and
> >Softwa
Hi
> AM35x supports only 32bit read operations so we need to have
> workaround for 8bit and 16bit read operations.
> But don't we need to override musb_readb() and musb_readw() then?
Yes, Correct. I do have another patch on that which I will cleanup and submit
later.
Anyways with currebt three
On Wed, May 5, 2010 at 12:33 PM, Tony Lindgren wrote:
> From: Steve Sakoman
>
> Some Overo add-on boards include a second ethernet port. This patch
> adds support for that second port.
>
> Signed-off-by: Steve Sakoman
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/board-overo.c |
From: ext Felipe Contreras
Subject: Re: [PATCH v2 00/17] omap: mailbox: reorganize init
Date: Tue, 18 May 2010 14:03:26 +0200
> On Tue, May 18, 2010 at 11:46 AM, Hiroshi DOYU wrote:
>> From: ext Felipe Contreras
>> Subject: [PATCH v2 00/17] omap: mailbox: reorganize init
>> Date: Fri, 14 May 20
- Fix space before tabs
- Add missing printk log level
Signed-off-by: Anand Gadiyar
---
Cleanup only - no functional changes
I can break up this into one patch per file if needed,
but I suppose that's unnecessary
arch/arm/mach-omap2/board-am3517evm.c|6 +++---
arch/arm/mach-omap2/b
Hello.
Ajay Kumar Gupta wrote:
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
But don't we need to override musb_readb() and musb_readw() then?
Signed-off-by: Ajay Kumar Gupta
WBR, Sergei
--
To unsubscribe from this list:
On Tue, May 18, 2010 at 3:24 PM, Felipe Contreras
wrote:
>>> Cool. I actually tried your patches to render to the framebuffer, and
>>> everything seemed to work fine. I didn't check for error codes or
>>> anything, so I'm not sure what's going on.
>>
>> How is the framebuffer mmap'ed ?
>
> mmap(NU
Hei Jarkko,
On Tue, May 18, 2010 at 01:06:01PM +0200, Jarkko Nikula wrote:
> Signed-off-by: Jarkko Nikula
> ---
> This is build and boot safe but required if wanting to add support for
> headphones in upcoming sound/soc/omap/rx51.c.
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c | 14 +++
From: Jani Nikula
Move a number of #ifdefs from code into dss.h and elsewhere, and
conditionally define no-op static inline functions, cleaning up the
code. This style is according to Documentation/SubmittingPatches.
Signed-off-by: Jani Nikula
Acked-by: Kevin Hilman
Signed-off-by: Tomi Valkein
From: Jani Nikula
Perform graceful cleanup on errors instead of just bailing out.
Signed-off-by: Jani Nikula
Tested-by: Kevin Hilman
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/core.c | 54 ++-
1 files changed, 41 insertions(+), 13 deletion
From: Roger Quadros
This is the panel used on Nokia N900
Signed-off-by: Roger Quadros
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/displays/Kconfig |6 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-acx565akm.c | 819 +
From: Grazvydas Ignotas
This panel depends on SPI, not I2C.
Signed-off-by: Grazvydas Ignotas
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/displays/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/o
From: Koen Kooi
This patch adds DSS2 support to the beagleboard boardfile. DVI and
TV-out are supported.
Signed-off-by: Koen Kooi
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/board-omap3beagle.c | 101 +++
1 files changed, 75 insertions(+), 26 deletions(-
1 - 100 of 174 matches
Mail list logo