On Mon, 27 Dec 2010 11:20:38 +0200, Felipe Balbi wrote:
> On Thu, Dec 23, 2010 at 12:16:22PM -0500, Ben Gamari wrote:
> >Is this change slated to go into 2.6.37? As it stands it looks like
> >2.6.37 will be released with completely broken musb support on many boards
> >(including the BeagleBoard).
>>-Original Message-
>>From: Paul Walmsley [mailto:p...@pwsan.com]
>>Sent: Wednesday, December 22, 2010 7:17 AM
>>To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
>>Cc: Gopinath, Thara; Nayak, Rajendra; Cousson, Benoit
>>Subject: Re: [PATCH 03/12] OMAP4: clock data: Ad
Hi David,
On Dec 28, 2010, at 9:44 PM, David Lynch Jr. wrote:
> I am looking for an example of programing the color rotation
> registers.
> I need to swap red and blue in software.
> This should be fairly easy, but some code usi_ng the color rotation
> registers would help.
>
On Wed, Dec 29, 2010 at 11:52:53AM +0100, Gregory CLEMENT wrote:
> When SPI wake up from OFF mode, CS is in the wrong state: force it to the
> inactive state.
>
> During the system life, I monitored the CS behavior using a oscilloscope.
> I also activated debug in omap2_mcspi, so I saw when driver
Make !CONFIG_SUSPEND init declarations identical on all OMAPs and
eliminate some ifdefs.
Signed-off-by: Aaro Koskinen
---
arch/arm/mach-omap2/pm.h |4
arch/arm/mach-omap2/pm24xx.c | 16
arch/arm/mach-omap2/pm34xx.c | 16
arch/arm/mach-omap2/pm44
> -Original Message-
> From: Charles Manning [mailto:mannin...@actrix.gen.nz]
> Sent: Friday, December 17, 2010 3:31 AM
> To: linux-omap@vger.kernel.org
> Cc: Ghorai, Sukumar; Grazvydas Ignotas
> Subject: OMAP NAND redux
>
> Hello All
>
> Over the last while I have been working on getti
nand transfer type (sDMA, Polled, prefetch) can be select from board file,
enabling all transfer type in driver, by default.
this helps in multi-omap build and to select different transfer type for
different board.
Signed-off-by: Sukumar Ghorai
---
arch/arm/plat-omap/include/plat/nand.h |7
add support the irq mode in GPMC.
gpmc_init() function move after omap_init_irq() as it has dependecy on irq.
Signed-off-by: Sukumar Ghorai
---
arch/arm/mach-omap2/board-2430sdp.c|1 +
arch/arm/mach-omap2/board-3430sdp.c|1 +
arch/arm/mach-omap2/board-3630sdp.c|
This patch overrides nand ecc layout and bad block descriptor (for 8-bit
device) to support hw ecc in romcode layout. So as to have in sync with ecc
layout throughout; i.e. x-loader, u-boot and kernel.
This enables to flash x-loader, u-boot, kernel, FS images from kernel itself
and compatiable wit
This patch enable prefetch-irq mode for nand transfer(read, write)
Signed-off-by: Vimal Singh
Signed-off-by: Sukumar Ghorai
---
arch/arm/mach-omap2/board-flash.c |2 +
arch/arm/plat-omap/include/plat/nand.h |4 +-
drivers/mtd/nand/omap2.c | 169 ++
This patch makes it possible to select sw or hw (different layout options)
ecc scheme supported by omap nand driver. And hw ecc layout selected for
sdp and zoom boards, by default.
Signed-off-by: Vimal Singh
Signed-off-by: Sukumar Ghorai
---
arch/arm/mach-omap2/board-flash.c |1 +
arc
zoom3 and 3630-sdp having the x16 nand device.
This patch configure gpmc as x16 and select the currect function in driver
for polled mode (without prefetch enable) transfer.
Signed-off-by: Sukumar Ghorai
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-3630sdp.c |
Configure the FIFO THREASHOLD value different for read and write to keep busy
both filling and to drain out of FIFO at reading and writing.
Signed-off-by: Vimal Singh
Signed-off-by: Sukumar Ghorai
---
arch/arm/mach-omap2/gpmc.c | 11 +++
arch/arm/plat-omap/include/plat/gpm
The following set of patches applies on linux-2.6.
The main motivations behind this patch series are -
1. support NAND I/O in irq mode.
2. support of different ECC schema.
3. also add support ecc layout as like in romcode ecc layout, but not
enabled
v7: NAND type (x16 or
Hi,
On Wed, Dec 29, 2010 at 01:00:00PM +, Liam Girdwood wrote:
Ok, I now think you meant other "ARM architectures" here than other
Linux architectures in general. It does make a more sense for ARM
distribution deployment, but I still think guaranteeing successful build
for this driver on all
On Wed, 2010-12-29 at 14:04 +0200, Felipe Balbi wrote:
> Hi,
>
> On Wed, Dec 29, 2010 at 11:52:51AM +, Liam Girdwood wrote:
> >I agree that drivers should be arch independent when possible, but in
> >this case the OMAP DMIC DAI driver is coupled to the OMAP platform only.
> >i.e. it performs I
Hi,
On Wed, Dec 29, 2010 at 02:38:28AM +0200, Felipe Balbi wrote:
On Tue, 2010-12-28 at 23:58 +, Mark Brown wrote:
On Tue, Dec 28, 2010 at 07:14:19PM +0200, Felipe Balbi wrote:
> +static void twl4030_sih_bus_sync_unlock(unsigned int irq)
> +{
> + struct sih_agent*agent = get_
On Wed, Dec 29, 2010 at 01:59:24PM +0200, Felipe Balbi wrote:
> On Wed, Dec 29, 2010 at 11:56:28AM +, Mark Brown wrote:
> >The other thing with McBSP is that it's a generic programmable serial
> >port and so need not be tied to audio use (though as I understand it
> >other uses are very rare).
Hi,
On Wed, Dec 29, 2010 at 11:52:51AM +, Liam Girdwood wrote:
I agree that drivers should be arch independent when possible, but in
this case the OMAP DMIC DAI driver is coupled to the OMAP platform only.
i.e. it performs IO directly on the OMAP DMIC IP. This IP is only found
on OMAP silico
Hi,
On Wed, Dec 29, 2010 at 11:56:28AM +, Mark Brown wrote:
In this case though the other McBSP user afaik is DaVinci, so in this
case it does make sense to make this driver support both.
The other thing with McBSP is that it's a generic programmable serial
port and so need not be tied to
On Wed, Dec 29, 2010 at 11:52:51AM +, Liam Girdwood wrote:
> In this case though the other McBSP user afaik is DaVinci, so in this
> case it does make sense to make this driver support both.
The other thing with McBSP is that it's a generic programmable serial
port and so need not be tied to
On Wed, 2010-12-29 at 12:44 +0200, Felipe Balbi wrote:
> Hi,
>
> On Wed, Dec 29, 2010 at 10:35:31AM +, Liam Girdwood wrote:
> >> Even though the driver will never work with those other archs, compile
> >> testing with several of them isn't bad at all.
> >
> >This seems unnecessary since this d
In case on OMAP2+ we call set_24xx_gpio_triggering() instead of
updating reg and l values. However, at the end of the function we
perform a write:
__raw_writel(l, reg);
So on OMAP2+ we end up writing 0 to the bank->base which is not
correct (typically this points to GPIO_REVISION register
On 12/29/2010 10:01 AM, Gregory CLEMENT wrote:
>> Hi Gregory,
>>
> Hi Grant,
>
>> Patch does not apply, but I cannot immediately isolate the damage.
>> Please see if you can figure out the issue on your end. Is it your
>> mailer? I could fudge it, but in the long run it is better if this
>> issu
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the clocks
and restore context when device is not used.Each time t
On Wed, Dec 29, 2010 at 11:58:28AM +0200, Dmitry Kasatkin wrote:
> Previous commit "removed redundant locking" introduced
> a bug in handling backlog.
> In certain cases, when async request complete callback will
> call complete() on -EINPROGRESS code, it will cause uncompleted requests.
> It does
Hi,
On Wed, Dec 29, 2010 at 10:35:31AM +, Liam Girdwood wrote:
Even though the driver will never work with those other archs, compile
testing with several of them isn't bad at all.
This seems unnecessary since this driver is for the OMAP platform only
and also means maintainers will have t
On Wed, 2010-12-29 at 11:47 +0200, Felipe Balbi wrote:
> Hi,
>
> On Tue, Dec 28, 2010 at 07:13:58PM -0600, Lambert, David wrote:
> >> one blank line only. BTW, are these used anywwhere outside the dmic.c
> >> driver ? If not, it's better to move the definitions there.
> >>
> >
> >They were origina
On Wed, Dec 29, 2010 at 11:46 AM, Ohad Ben-Cohen wrote:
> On Wed, Dec 29, 2010 at 11:39 AM, Felipe Contreras
> wrote:
>> On Tue, Dec 28, 2010 at 2:37 PM, Ohad Ben-Cohen wrote:
>>> On Tue, Dec 28, 2010 at 2:24 PM, Felipe Contreras
>>> wrote:
user-space crashed, not kernel-space; the code wo
Hi,
Please take this important fix.
- Dmitry
Dmitry Kasatkin (1):
omap-sham: backlog handling fix
drivers/crypto/omap-sham.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to
Previous commit "removed redundant locking" introduced
a bug in handling backlog.
In certain cases, when async request complete callback will
call complete() on -EINPROGRESS code, it will cause uncompleted requests.
It does not happen in implementation similar to crypto test manager,
but it will ha
On Wed, Dec 29, 2010 at 11:42 AM, Felipe Contreras
wrote:
> On Tue, Dec 28, 2010 at 4:48 PM, Ohad Ben-Cohen wrote:
>> On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras
>> wrote:
>>> On Tue, Dec 28, 2010 at 12:56 PM, Ohad Ben-Cohen wrote:
I still don't know how exactly you triggered the bug
Hi,
On Tue, Dec 28, 2010 at 07:13:58PM -0600, Lambert, David wrote:
one blank line only. BTW, are these used anywwhere outside the dmic.c
driver ? If not, it's better to move the definitions there.
They were originally in the omap-dmic.h header, but it was suggested
that we move
them to a pla
On Wed, Dec 29, 2010 at 11:39 AM, Felipe Contreras
wrote:
> On Tue, Dec 28, 2010 at 2:37 PM, Ohad Ben-Cohen wrote:
>> On Tue, Dec 28, 2010 at 2:24 PM, Felipe Contreras
>> wrote:
>>> user-space crashed, not kernel-space; the code would continue to run
>>> and eventually release the lock.
>>
>> So
On Tue, Dec 28, 2010 at 4:48 PM, Ohad Ben-Cohen wrote:
> On Tue, Dec 28, 2010 at 2:12 PM, Felipe Contreras
> wrote:
>> On Tue, Dec 28, 2010 at 12:56 PM, Ohad Ben-Cohen wrote:
>>> I still don't know how exactly you triggered the bug: is gst-dsp
>>> multithreaded ? and one of its threads invoked p
On Tue, Dec 28, 2010 at 2:37 PM, Ohad Ben-Cohen wrote:
> On Tue, Dec 28, 2010 at 2:24 PM, Felipe Contreras
> wrote:
>> user-space crashed, not kernel-space; the code would continue to run
>> and eventually release the lock.
>
> So you'll have to be more specific about the scenario you are describ
> Hi Gregory,
>
Hi Grant,
> Patch does not apply, but I cannot immediately isolate the damage.
> Please see if you can figure out the issue on your end. Is it your
> mailer? I could fudge it, but in the long run it is better if this
> issue can get sorted out now.
>
I found the problem: see b
37 matches
Mail list logo