Hi Michal,
On Fri, Mar 16, 2012 at 4:57 PM, Michal Simek wrote:
> In previous version I had carverout first which means that code was copyied
> to physical address 0x0 and then vrigns were allocated. Current code
> allocate vring first and then RTOS is not able to run from zero address.
In gener
Hi,
On 3/17/12, Aneesh V wrote:
> Add a driver for the EMIF SDRAM controller used in TI SoCs
>
> EMIF is an SDRAM controller that supports, based on its revision,
> one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
> for LPDDR2.
>
> The driver supports the following features:
> -
Hi Sourav,
On Fri, Mar 16, 2012 at 07:56:29PM +0530, Sourav Poddar wrote:
> From: G, Manjunath Kondaiah
>
> Keypad controller register offsets are different for omap4
> and omap5. Handle these offsets through static mapping and
> assign these mappings during run time.
>
> Signed-off-by: Felipe
On Fri, Mar 16, 2012 at 11:08:43PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Fri, Mar 16, 2012 at 09:36:19AM -0700, Dmitry Torokhov wrote:
> > On Friday, March 16, 2012 07:56:28 PM Sourav Poddar wrote:
> > > From: Felipe Balbi
> > >
> > > This patch allows us to drop the OMAP depencendy
> > > from
On 03/16/2012 05:54 PM, Rob Herring wrote:
On 03/16/2012 06:47 PM, Sascha Hauer wrote:
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
If the common clock code is to go upstream now, it should be marked as
experimental.
On 03/16/2012 06:47 PM, Sascha Hauer wrote:
> Hi Paul,
>
> On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
>> Hi
>>
>> On Fri, 16 Mar 2012, Arnd Bergmann wrote:
>>
>>
>> If the common clock code is to go upstream now, it should be marked as
>> experimental.
>
> No, please don't do
Hi,
Adding Tomi to this thread.
* Russell King - ARM Linux [120316 16:14]:
> Sometime during the last week, the OMAP4430SDP stopped booting - it now
> stops with no kernel messages output:
>
> http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=69
>
> The previously booted ver
Hi Paul,
On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote:
> Hi
>
> On Fri, 16 Mar 2012, Arnd Bergmann wrote:
>
>
> If the common clock code is to go upstream now, it should be marked as
> experimental.
No, please don't do this. This effectively marks the architectures using
the
Sometime during the last week, the OMAP4430SDP stopped booting - it now
stops with no kernel messages output:
http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=69
The previously booted version:
http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=57
worked fin
On Fri, Mar 16, 2012 at 3:21 PM, Paul Walmsley wrote:
> From: Paul Walmsley
> Date: Fri, 16 Mar 2012 16:06:30 -0600
> Subject: [PATCH] clk: mark the common clk code as EXPERIMENTAL for now
>
> Mark the common clk code as depending on CONFIG_EXPERIMENTAL. The API
> is not well-defined and both it
Hi
On Fri, 16 Mar 2012, Arnd Bergmann wrote:
> On Friday 16 March 2012, Arnd Bergmann wrote:
> > >
> > > Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so
> > > that platform ports can gather speed? Several people are waiting for a
> > > somewhat stable version before starting t
EMIF is an SDRAM controller used in various Texas Instruments
SoCs. EMIF supports, based on its revision, one or more of
LPDDR2/DDR2/DDR3 protocols.
Add the basic infrastructure for EMIF driver that includes
driver registration, probe, parsing of platform data etc.
Cc: Greg KH
Signed-off-by: Ane
Add settings that are not dependent on frequency
or any other transient parameters. This includes
- power managment control init
- impedence calibration control
- frequency independent phy configuration registers
- initialization of temperature polling
Cc: Greg KH
Signed-off-by: Aneesh V
---
v2:
On Saturday 17 March 2012 03:03 AM, Greg KH wrote:
On Sat, Mar 17, 2012 at 02:28:47AM +0530, Aneesh V wrote:
Hi Greg,
[...]
I have fixed these comments and pushed my latest patches at:
git://github.com/aneeshv/linux.git
branch: emif-upstream-v4
Sorry, but I don't take git pulls for stuff l
Add debug entries for:
1. calculated registers per frequency
2. last polled value of MR4(temperature level
of LPDDR2 memory)
Cc: Greg KH
Signed-off-by: Aneesh V
---
v2:
- Corrected the frequency value shown in
register cache dump
- replaced __init with __init_or_modu
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
Also clear all interrupts on shut-down. Pending IRQs
may casue problems during warm-reset.
Temperature handling:
EMIF can be configured to poll the temperature level
of an LPDDR2 device
Change SDRAM timings and other settings as necessary
on voltage and frequency changes. We calculate these
register settings based on data from the device data
sheet and inputs such a frequency, voltage state(stable
or ramping), temperature level etc.
TODO: frequency and voltage change handling nee
Add register offsets and bit field definitions
for EMIF module in TI SoCs
Cc: Greg KH
Signed-off-by: Aneesh V
---
v1:
- Improved commit log
- Corrected copyright year
- Changed file name in order to add other defines
needed by the driver in the same file in subsequent
patches
---
drivers/mi
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers.
Right now this is used by the TI EMIF SDRAM controller
driver.
Add a driver for the EMIF SDRAM controller used in TI SoCs
EMIF is an SDRAM controller that supports, based on its revision,
one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
for LPDDR2.
The driver supports the following features:
- Calculates the DDR AC timing parameters to be s
On Saturday 17 March 2012 03:13 AM, Greg KH wrote:
On Sat, Mar 17, 2012 at 02:20:07AM +0530, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data
On Sat, Mar 17, 2012 at 02:20:07AM +0530, Aneesh V wrote:
> add LPDDR2 data from the JEDEC spec JESD209-2. The data
> includes:
>
> 1. Addressing information for LPDDR2 memories of different
>densities and types(S2/S4)
> 2. AC timing data.
>
> This data will useful for memory controller devic
On Sat, Mar 17, 2012 at 02:28:47AM +0530, Aneesh V wrote:
> Hi Greg,
>
> On Friday 16 March 2012 12:32 AM, Greg KH wrote:
> >On Thu, Mar 15, 2012 at 11:47:31PM +0530, Aneesh V wrote:
> >>add LPDDR2 data from the JEDEC spec JESD209-2. The data
> >>includes:
> >>
> >>1. Addressing information for LP
Hi,
On Fri, Mar 16, 2012 at 09:36:19AM -0700, Dmitry Torokhov wrote:
> On Friday, March 16, 2012 07:56:28 PM Sourav Poddar wrote:
> > From: Felipe Balbi
> >
> > This patch allows us to drop the OMAP depencendy
> > from the OMAP4 keypad driver.
> >
> > Signed-off-by: Felipe Balbi
> > Signed-off
Hi Greg,
On Friday 16 March 2012 12:32 AM, Greg KH wrote:
On Thu, Mar 15, 2012 at 11:47:31PM +0530, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
Th
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers.
Right now this is used by the TI EMIF SDRAM controller
driver.
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers
Cc: Greg KH
Signed-off-by: Aneesh V
---
v3:
- Converted EXPOR
Hi,
* Thomas Klute [120316 05:08]:
> Hi,
>
> I have trouble getting the Ethernet port on a Gumstix Overo with Tobi
> expansion board to work with current kernel versions. With the latest
> commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa),
> the output from loading the smsc91
On Fri, Mar 16, 2012 at 04:42:16PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 16-03-2012 3:07, Mark A. Greer wrote:
>
> >From: "Mark A. Greer"
> >@@ -463,7 +462,7 @@ restore:
> > list_for_each_entry(pwrst,&pwrst_list, node) {
> > state = pwrdm_read_prev_pwrst(pwrst->pwrdm);
>
On Friday, March 16, 2012 07:56:28 PM Sourav Poddar wrote:
> From: Felipe Balbi
>
> This patch allows us to drop the OMAP depencendy
> from the OMAP4 keypad driver.
>
> Signed-off-by: Felipe Balbi
> Signed-off-by: Sourav Poddar
> ---
> arch/arm/mach-omap2/board-4430sdp.c|1 +
>
Hi Keshava,
On Mon, Mar 05, 2012 at 08:13:45PM +0530, Munegowda, Keshava wrote:
> On Mon, Mar 5, 2012 at 8:01 PM, Keshava Munegowda
> wrote:
> > From: Keshava Munegowda
> >
> > The TLL configuration is removed from the UHH driver and implemented as
> > a seperate platform driver. Now, the UHH d
On platforms such as OMAP3, certain variants may not have IVA, SGX
or some specific component. We currently have a check to aid fixing
wrong population of OPP entries for issues such as typos. This however
causes a conflict with valid requirement where the SoC variant does
not actually have the mod
Hi Keshava,
On Thu, Mar 08, 2012 at 08:30:21PM +0530, Munegowda, Keshava wrote:
> On Fri, Mar 2, 2012 at 7:36 PM, Munegowda, Keshava
> wrote:
> > On Fri, Feb 24, 2012 at 5:14 PM, Munegowda, Keshava
> > wrote:
> >> On Fri, Feb 24, 2012 at 3:46 PM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Fri
On Fri, Mar 16, 2012 at 7:20 AM, Nishanth Menon wrote:
> From 5275d09c9f1a16c8f0814745e1c313c6cca049f6 Mon Sep 17 00:00:00 2001
> From: Nishanth Menon
> Date: Fri, 16 Mar 2012 09:13:24 -0500
> Subject: [PATCH] OMAP2+: OPP: allow OPP enumeration to continue if device is
> not present
>
> On platf
On Fri, Mar 16, 2012 at 10:47, Maximilian Schwerin
wrote:
>
> sorry my fault! This was not what I was thinking of as generic. Works as
> expected!
Can i take it as an acked-by?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a messag
P3: OPP: Test for IVA subsystem
> before attempting to add IVA OPP
>
> On 10:26-20120316, Maximilian Schwerin wrote:
> [...]
> > > >>> +
> > > >>> + if ((strcmp(opp_def->hwmod_name,"iva") ==
> > > 0) &&
Hi Tony,
On Thu, Mar 15, 2012 at 6:14 PM, Tony Lindgren wrote:
> * jean.pi...@newoldbits.com [120315 09:47]:
>> From: Jean Pihet
>>
>> Move the platform specific macros from the smartreflex header file
>> (arch/arm/mach-omap2/smartreflex.h) in a new header file in plat-omap
>> (arch/arm/plat-om
Hi Ohad,
Ohad Ben-Cohen wrote:
The resource table is an array of 'struct fw_resource' members, where
each resource entry is expressed as a single member of that array.
This approach got us this far, but it has a few drawbacks:
1. Different resource entries end up overloading the same members o
On Fri, Mar 16, 2012 at 7:21 PM, Felipe Balbi wrote:
> On Fri, Mar 16, 2012 at 07:08:57PM +0530, Venkatraman S wrote:
>> From: Balaji T K
>>
>> Enable Auto-CMD12 for multi block read/write on HSMMC
>> Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
>>
>> Signed-off-by: Balaji T K
>> Signed-off-by:
From: G, Manjunath Kondaiah
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Signed-off-by: Felipe Balbi
Signed-off-by: G, Manjunath Kondaiah
Signed-off-by: Sourav Poddar
---
drivers/i
From: Felipe Balbi
This patch allows us to drop the OMAP depencendy
from the OMAP4 keypad driver.
Signed-off-by: Felipe Balbi
Signed-off-by: Sourav Poddar
---
arch/arm/mach-omap2/board-4430sdp.c|1 +
arch/arm/mach-omap2/devices.c |1 +
arch/arm/plat-omap/i
The series consists of two patches.
Patch1 of the series makes omap4 keypad independent of the
architecture by moving platform_data to
Patch2 add support for omap5 onchip keypad.
Tested on omap4430sdp using 3.3-rc6.
Tested on omap5 board using 3.1 custom kernel.
Felipe Balbi (1):
input: keyp
On 10:26-20120316, Maximilian Schwerin wrote:
[...]
> > >>> +
> > >>> + if ((strcmp(opp_def->hwmod_name,"iva") ==
> > 0) && !omap3_has_iva())
> > >>> + continue;
> > >>> +
>
2012/3/16 Tomi Valkeinen :
> On Fri, 2012-03-16 at 01:04 +0200, Ville Syrjälä wrote:
>> On Thu, Mar 15, 2012 at 05:18:52PM +0530, Chandrabhanu Mahapatra wrote:
>> > In OMAP3 DISPC video overlays suffer from some undocumented horizontal
>> > position
>> > and timing related limitations leading to S
On Fri, Mar 16, 2012 at 4:34 AM, Ville Syrjälä wrote:
> On Thu, Mar 15, 2012 at 05:18:52PM +0530, Chandrabhanu Mahapatra wrote:
>> In OMAP3 DISPC video overlays suffer from some undocumented horizontal
>> position
>> and timing related limitations leading to SYNCLOST errors. Whenever the image
>>
There are two ways through which wakeup_en register can be programmed
using gpiolib APIs as shown below. It is seen that in the second case
in _set_gpio_wakeup(), even though bank->suspend_wakeup is updated
correctly, its value is not programmed in wakeup_en register. Fix this.
chip.irq_set_type()
In _enable_gpio_irqbank() when bank->regs->set_irqenable is valid,
gpio_mask can be directly set by writing to set_irqenable register
without overwriting current value. In order to ensure the same is
stored in context.irqenable1, we must read from regs->irqenable
instead of overwriting it with gpio
In omap_gpio_runtime_suspend/resume() the context save/restore should
be independent of bank->enabled_non_wakeup_gpios. This was preventing
context restore of GPIO lines which are not wakeup enabled.
Reported-by: Govindraj Raja
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Santosh Shilimkar
Since we already have bank->context.wake_en to keep track
of gpios which are wakeup enabled, there is no need to have
this field any more.
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Santosh Shilimkar
Acked-by: Felipe Balbi
---
drivers/gpio/gpio-omap.c | 13 ++---
1 files change
Both omap_gpio_suspend() and omap_gpio_resume() does programming
of wakeup_en register.
_gpio_rmw(base, bank->regs->wkup_en, 0x, 0);
_gpio_rmw(base, bank->regs->wkup_en, bank->context.wake_en, 1);
This is redundant in omap_gpio_suspend() because wakeup_en
register automatically gets initia
The GPIO trigger parameter is of type unsigned.
enum {
IRQ_TYPE_NONE = 0x,
IRQ_TYPE_EDGE_RISING= 0x0001,
IRQ_TYPE_EDGE_FALLING = 0x0002,
IRQ_TYPE_EDGE_BOTH = (IRQ_TYPE_EDGE_FALLING |
IRQ_TYPE_EDGE_RISING),
IRQ_TYPE_LEVEL_
There are two functions, _set_gpio_dataout_reg() and _set_gpio_dataout_mask()
which writes to dataout register and the dataout context must be saved.
It is missing in the first function, _set_gpio_dataout_reg(). Fix this.
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Santosh Shilimkar
---
dr
commit 672e302e3c (ARM: OMAP: use edge/level handlers from generic IRQ
framework) removed retrigger support in favor of using generic IRQ
framework. This patch cleans up some unused remnants of that removal.
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Santosh Shilimkar
Acked-by: Felipe Bal
In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
un-necessary operation to compute gpio mask. The gpio offset passed
to gpio_get() is sufficient to do that.
Here is Russell's original comment:
Can someone explain to me this:
#define GPIO_INDEX(bank, gpio) (gpio % bank->width)
#
Since we already have context.fallingdetect and context.risingdetect
there is no more need to have these additional fields. Also, getting
rid of extra reads associated with them.
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Santosh Shilimkar
Acked-by: Felipe Balbi
---
drivers/gpio/gpio-oma
This function should be capable of both enabling and disabling interrupts
based upon the *enable* parameter. Right now the function only enables
the interrupt and *enable* is not used at all. So add the interrupt
disable capability also using the parameter.
Signed-off-by: Tarun Kanti DebBarma
Rev
The cleanup is mostly getting rid of redundant fields in struct gpio_bank{}
as we already have them as part of bank->context now. Also, remove un-used
variable from gpio_irq_handler. Also, the suspend/resume callbacks are
removed bacause they are not needed any more.
The fixes include correction o
There is no more need to have saved_wakeup because bank->context.wake_en
already holds that value. So getting rid of read/write operation associated
with this field.
Signed-off-by: Tarun Kanti DebBarma
Reviewed-by: Santosh Shilimkar
Acked-by: Felipe Balbi
---
drivers/gpio/gpio-omap.c | 12 ++
On Fri, Mar 16, 2012 at 7:16 PM, Cousson, Benoit wrote:
> Hi Tarun,
>
> On 3/16/2012 1:24 PM, Tarun Kanti DebBarma wrote:
>> These two patches incorporate changes to OMAP1 and OMAP2 platforms
>> board files whereby older references to OMAP_GPIO_IRQ macro are
>> now replaced with gpio_to_irq(), the
On Fri, Mar 16, 2012 at 07:08:57PM +0530, Venkatraman S wrote:
> From: Balaji T K
>
> Enable Auto-CMD12 for multi block read/write on HSMMC
> Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
>
> Signed-off-by: Balaji T K
> Signed-off-by: Venkatraman S
> ---
> drivers/mmc/host/omap_hsmmc.c | 16
Hi Tarun,
On 3/16/2012 1:24 PM, Tarun Kanti DebBarma wrote:
> These two patches incorporate changes to OMAP1 and OMAP2 platforms
> board files whereby older references to OMAP_GPIO_IRQ macro are
> now replaced with gpio_to_irq(), thereby getting rid of static
> irq references.
Thanks for the boar
From: Balaji T K
OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
Addng the offset to platform_device resource structure
increments the start address for every insmod operation.
MMC command fails on re-insertion as module due to incorrect register base.
Fix this by updating the ioremap
From: Felipe Balbi
this will delete some boilerplate code, no functional
changes.
Signed-off-by: Felipe Balbi
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_hsmmc.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/d
From: Felipe Balbi
if we put probe() on __init section, that will never
work for multiple module insertions/removals.
In order to make it work properly, move probe to
__devinit section and use platform_driver_register()
instead of platform_driver_probe().
Signed-off-by: Felipe Balbi
Signed-off
From: Felipe Balbi
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneded
dereferences and drop unneded accesses to the platform_device
structure.
Signed-off-by: Felipe Balbi
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_h
From: Balaji T K
call context save api after enabling runtime pm
to make sure register access in context save api happens with clk enabled.
Signed-off-by: Balaji T K
Signed-off-by: Venkatraman S
Cc: stable
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 file changed, 2 insertions(+), 2 dele
From: Balaji T K
pm_runtime_put_sync instead of autosuspend pm runtime API
because iounmap(host->base) follows immediately.
Reported-by: Rajendra Nayak
Signed-off-by: Balaji T K
Signed-off-by: Venkatraman S
Cc: stable
---
drivers/mmc/host/omap_hsmmc.c |3 +--
1 file changed, 1 insertion
From: Balaji T K
Add Dual data rate support for omap_hsmmc
Signed-off-by: Balaji T K
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_hsmmc.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a9ffd70..d682c5e
From: Balaji T K
Enable Auto-CMD12 for multi block read/write on HSMMC
Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
Signed-off-by: Balaji T K
Signed-off-by: Venkatraman S
---
drivers/mmc/host/omap_hsmmc.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a
Chris,
Here are a group of fixes posted by Felipe and Balaji for the
OMAP hsmmc driver in the past few days.
I've rebased them to the lastest mmc-next and posted them
here again. These have also been tested on OMAP4 development platform.
Please feel to apply directly or pull if that's conve
On 03/16/2012 02:28 PM, Cousson, Benoit :
> On 3/16/2012 1:04 PM, Arnd Bergmann wrote:
>> On Friday 16 March 2012, Cousson, Benoit wrote:
>>> And it seems that other ARM SoCs are using it for the same purpose.
>>> There are at least 230+ IORESOURCE_DMA instances in the kernel today.
>>
>> These ten
On Thu, Mar 15, 2012 at 8:42 PM, Shubhrajyoti wrote:
> On Thursday 15 March 2012 08:03 PM, Venkatraman S wrote:
>> From: Balaji T K
>>
>> call context save api after enabling runtime pm
>> to make sure register access in context save api
> If I am not mistaken the api would
> store the number o
On 3/16/2012 1:04 PM, Arnd Bergmann wrote:
On Friday 16 March 2012, Cousson, Benoit wrote:
And it seems that other ARM SoCs are using it for the same purpose.
There are at least 230+ IORESOURCE_DMA instances in the kernel today.
These tend to be the ones that don't use dmaengine but either the
If transceiver is attached to a MMC host of ES2.1 OMAP, it seems
2.1.1.128 erratum doesn't apply and there is no data corruption,
probably because of different signal timing. The workaround for this
erratum disables multiblock reads, which causes dramatic loss of
performance (over 75% slower), so a
Hello.
On 16-03-2012 3:07, Mark A. Greer wrote:
From: "Mark A. Greer"
Currently, pm34xx.c has a mix of printk() and pr_*() statements
so replace the printk() statements with the equivalent pr_*()
statements.
Signed-off-by: Mark A. Greer
---
arch/arm/mach-omap2/pm34xx.c | 17
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQi
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/boa
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma
---
arch/arm/mach-omap1/board-h2.c|8
arch/arm/mach-omap1/board-h3.c|8
arch/arm/mach-omap1/board-
These two patches incorporate changes to OMAP1 and OMAP2 platforms
board files whereby older references to OMAP_GPIO_IRQ macro are
now replaced with gpio_to_irq(), thereby getting rid of static
irq references.
Reference: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git omap/dt
Commit:
On Fri, Mar 16, 2012 at 3:58 AM, Ville Syrjälä wrote:
> On Thu, Mar 15, 2012 at 05:18:28PM +0530, Chandrabhanu Mahapatra wrote:
>> In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times,
>> and
>> up to 2 times in OMAP2. However, with predecimation, the image can be reduced
>>
Hi,
I have trouble getting the Ethernet port on a Gumstix Overo with Tobi
expansion board to work with current kernel versions. With the latest
commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa),
the output from loading the smsc911x driver is as follows:
du14:~# modprobe smsc91
On Friday 16 March 2012, Cousson, Benoit wrote:
> And it seems that other ARM SoCs are using it for the same purpose.
> There are at least 230+ IORESOURCE_DMA instances in the kernel today.
These tend to be the ones that don't use dmaengine but either the
ISA dma api or a platform specific varian
On 3/16/2012 11:03 AM, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
For legacy reason another API will export the DMA request number into a
Linux resource of type IORESOURCE_DMA.
Can you explain which legacy scenarios you think this is going to help with?
We do have a
Hi,
On Friday 16 March 2012 03:46 PM, Archit Taneja wrote:
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit wrote:
The omap_vout driver tries to set the DSS overlay_info using
set_overlay_info()
when the physical address for the overla
On Thu, 2012-03-15 at 07:32 -0500, Rob Clark wrote:
> On Thu, Mar 15, 2012 at 3:46 AM, Tomi Valkeinen wrote:
> > On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote:
> >
> >> > Well, as I said, it's not an issue for me and from my side it can be
> >> > improved later.
> >>
> >> yeah, when CMA is ac
On Fri, Mar 16, 2012 at 04:02:16PM +0530, S, Venkatraman wrote:
> On Thu, Mar 15, 2012 at 8:34 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Mar 15, 2012 at 08:03:42PM +0530, Venkatraman S wrote:
> >> From: Balaji T K
> >>
> >> OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
> >> Add
On Thu, Mar 15, 2012 at 8:34 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Mar 15, 2012 at 08:03:42PM +0530, Venkatraman S wrote:
>> From: Balaji T K
>>
>> OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
>> Addng the offset to platform_device resource structure
>> increments the start addr
On Fri, 2012-03-16 at 01:04 +0200, Ville Syrjälä wrote:
> On Thu, Mar 15, 2012 at 05:18:52PM +0530, Chandrabhanu Mahapatra wrote:
> > In OMAP3 DISPC video overlays suffer from some undocumented horizontal
> > position
> > and timing related limitations leading to SYNCLOST errors. Whenever the
> >
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit wrote:
The omap_vout driver tries to set the DSS overlay_info using set_overlay_info()
when the physical address for the overlay is still not configured. This happens
in omap_vout_probe()
> Von: Kevin Hilman [mailto:khil...@ti.com]
>
> "Menon, Nishanth" writes:
>
> > On Wed, Mar 14, 2012 at 16:15, Kevin Hilman wrote:
> >> Maximilian Schwerin writes:
> >>
> >>> From: Steve Sakoman
> >>>
> >>> Don't try to add IVA OPPs for OMAP3 versions not containing an IVA
> >>> subsystem, a
On Thursday 15 March 2012, Nicolas Ferre wrote:
> For legacy reason another API will export the DMA request number into a
> Linux resource of type IORESOURCE_DMA.
Can you explain which legacy scenarios you think this is going to help with?
> +/**
> + * of_dma_to_resource - Decode a node's DMA and
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
> Thank you both for missing my point.
>
> #define OMAP24XX_DMA_SHA1MD5_RX 13 /* S_DMA_12 */
> #define OMAP34XX_DMA_SHA2MD5_RX 13 /* S_DMA_12 */
>
> #define OMAP242X_DMA_EXT_DMAREQ214 /* S_DMA_13 */
On Wed, Mar 14, 2012 at 21:00:25, Laurent Pinchart wrote:
> Hi Vaibhav,
>
> On Friday 09 March 2012 17:41:57 Vaibhav Hiremath wrote:
> > When rotation is enabled and driver is configured in USERPTR
> > buffer exchange mechanism, in specific use-case driver reports
> > an error,
> >"DMA transac
On Wed, Mar 14, 2012 at 20:22:37, Laurent Pinchart wrote:
> Hi Vaibhav,
>
> Thanks for the patch.
>
> On Friday 09 March 2012 17:44:03 Vaibhav Hiremath wrote:
> > Patch fixes below build warning and section miss-match warning
> > from omap_vout driver -
>
> You should probably not refer to "patc
93 matches
Mail list logo
