AM35x has musb interface and uses CPPI4.1 DMA engine.
Current patch supports only PIO mode. DMA support can be
added later once basic CPPI4.1 DMA patch is accepted.
Signed-off-by: Ajay Kumar Gupta
---
Changes from v2:
- Added CONFIG_ARCH_AMx
drivers/usb/musb/Kconfig |4 +-
drivers/
AM35x supports only 32bit read operations so we need to have
workaround for 8bit and 16bit read operations.
Signed-off-by: Ajay Kumar Gupta
---
Changes from v2:
- Added CONFIG_ARCH_AMx
drivers/usb/musb/am3517.c| 30 ++
drivers/usb/musb/musb_core.c |
AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine.
It has USB phy built inside the IP itself.
Also added ARCH_AM35x which is required to differentiate musb ips
between OMAP3x and AM35x. This config would be used to for below
purposes,
- Select am3517.c instead of omap2430.c
On Mon, May 24, 2010 at 8:20 AM, Scott Ellis wrote:
> Check spi->chip_select for range before use.
>
> The spi->controller_state check is already in 2.6.34-rc7
>
> Signed-off-by: Scott Ellis
Okay, I've pick up this patch, but please check your Evolution
configuration. Patchwork seems to be barf
Hi,
On Mon, May 24, 2010 at 09:14:24PM +0200, ext Felipe Contreras wrote:
Now, regarding device.h:
which was my only concern
Now, I am pretty sure that platform_device.h will always depend on
device.h that's why I removed them, but I can add them again if
somebody wants to, but again, the si
On Tue, May 25, 2010 at 3:00 AM, Kevin Hilman
wrote:
> Felipe Contreras writes:
>
>> Only OMAP3 would work.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> arch/arm/mach-omap2/devices.c | 103
>> +--
>> arch/arm/mach-omap2/mailbox.c | 14 +--
"Govindraj.R" writes:
> This happening because we are missing these patches:
>
> https://patchwork.kernel.org/patch/84748/
> https://patchwork.kernel.org/patch/84749/
> https://patchwork.kernel.org/patch/84755/
> https://patchwork.kernel.org/patch/84750/
>
> Not part of LO yet.
>
> But we nee
Ohad Ben-Cohen writes:
> On Mon, May 24, 2010 at 10:33 PM, Felipe Contreras
> wrote:
>> On Mon, May 24, 2010 at 8:29 PM, Ohad Ben-Cohen wrote:
>>> On Sat, May 22, 2010 at 8:25 PM, Felipe Contreras
>>> wrote:
I played a bit with omap_hwmod/omap_device for the mailbox, and this is the
Felipe Contreras writes:
> Only OMAP3 would work.
>
> Signed-off-by: Felipe Contreras
> ---
> arch/arm/mach-omap2/devices.c | 103 +--
> arch/arm/mach-omap2/mailbox.c | 14 +---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 45
"Kanigeri, Hari" writes:
> Felipe,
>
>
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
>> ow...@vger.kernel.org] On Behalf Of Felipe Contreras
>> Sent: Saturday, May 22, 2010 12:25 PM
>> To: linux-omap
>> Cc: Hiroshi Doyu; Kevin Hilman; Paul Walmsley; O
On Tuesday 25 May 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" writes:
>
> > On Monday 24 May 2010, Felipe Balbi wrote:
> >> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
> >> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> >> >> This patch series adds a suspend-bloc
"Rafael J. Wysocki" writes:
> On Monday 24 May 2010, Felipe Balbi wrote:
>> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
>> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
>> >> This patch series adds a suspend-block api that provides the same
>> >> functionality as the
On 05/21/2010 03:07 AM, Tomi Valkeinen wrote:
On Thu, 2010-05-20 at 00:33 +0200, ext Steve Sakoman wrote:
I did a quick test build of the current linux-omap head and get a
failure very early on in the boot process in
drivers/video/omap2/vram.c code:
Illegal SDRAM size for VRAM
It is ge
Hi Govindraj,
On 5/20/2010 3:38 PM, Govindraj.R wrote:
With this patch we retain uart name and just "uart"
rather than uart_hwmod as per autogenerated file for
omap4 just to retain common names across hwmod data files.
Also pass rx channel id as first dma platform parameter
to driver.
Why do
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.
Align OMAP2420, 2430 and 3430 data files with the same convention.
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/oma
Add the missing braces in hwmod fw and clean the data for
OMAP2420, 2430 and 3430.
The brace fix was tested on OMAP4 PAB.
Please note that the data changes were built for the 3 platforms
but not tested on board.
The series is based on l-o master.
Thanks,
Benoit
Benoit Cousson (2):
OMAP: hw
As reported by Sergei, a couple of braces were missing after
the WARM removal patch.
[07/22] OMAP: hwmod: Replace WARN by pr_warning if clock lookup failed
https://patchwork.kernel.org/patch/100756/
Signed-off-by: Benoit Cousson
Cc: Paul Walmsley
Cc: Sergei Shtylyov
---
arch/arm/mach-omap2/o
On Mon, May 24, 2010 at 10:29:01PM +0300, Felipe Contreras wrote:
> On Mon, May 24, 2010 at 5:42 PM, Hiroshi DOYU wrote:
> > From: ext Felipe Contreras
>
> >> + if (false);
> >
> > nitpcik:
> > The above may look better as below:
> >
> > if (false)
> > ;
> >
> > "checkp
On Mon, May 24, 2010 at 10:33 PM, Felipe Contreras
wrote:
> On Mon, May 24, 2010 at 8:29 PM, Ohad Ben-Cohen wrote:
>> On Sat, May 22, 2010 at 8:25 PM, Felipe Contreras
>> wrote:
>>> I played a bit with omap_hwmod/omap_device for the mailbox, and this is the
>>> result.
>>
>> Nice move Felipe :)
On Mon, May 24, 2010 at 10:21 PM, Felipe Contreras
wrote:
> On Mon, May 24, 2010 at 7:19 PM, Ohad Ben-Cohen wrote:
>> On Fri, May 21, 2010 at 12:42 PM, Felipe Contreras
>> wrote:
>>> Although I'm still worried that VM_IO != write-combine, but I guess
>>> it's a safe assumption to do for now.
>>
On Mon, May 24, 2010 at 8:29 PM, Ohad Ben-Cohen wrote:
> On Sat, May 22, 2010 at 8:25 PM, Felipe Contreras
> wrote:
>> I played a bit with omap_hwmod/omap_device for the mailbox, and this is the
>> result.
>
> Nice move Felipe :)
Thanks :)
> Can you convert this to use the runtime PM layer, ins
On Mon, May 24, 2010 at 5:42 PM, Hiroshi DOYU wrote:
> From: ext Felipe Contreras
>> + if (false);
>
> nitpcik:
> The above may look better as below:
>
> if (false)
> ;
>
> "checkpatch.pl" also doesn't complain.
Personally I think it looks weird and it's a checkpatch b
On Mon, May 24, 2010 at 7:19 PM, Ohad Ben-Cohen wrote:
> On Fri, May 21, 2010 at 12:42 PM, Felipe Contreras
> wrote:
>> Although I'm still worried that VM_IO != write-combine, but I guess
>> it's a safe assumption to do for now.
>
> small update we missed:
>
> The original code is ignoring VM_IO
On Mon, May 24, 2010 at 9:32 PM, Russell King - ARM Linux
wrote:
> On Mon, May 24, 2010 at 06:24:07PM +0300, Hiroshi DOYU wrote:
>> From: ext Felipe Contreras
>> Subject: [PATCH v3 10/14] omap: mailbox: reorganize registering
>> Date: Sat, 22 May 2010 19:14:21 +0200
>>
>> > platform_get_resource(
On Mon, May 24, 2010 at 8:16 PM, Felipe Balbi wrote:
> personally I don't like this patch since it makes the C-sources rely on
> indirect header inclusion by another header. That's really error prone and
> will cause build failures if someone decides to remove the include
> from plat/mailbox.h.
On Monday 24 May 2010, Felipe Balbi wrote:
> On Mon, May 24, 2010 at 02:46:54AM +0200, ext Rafael J. Wysocki wrote:
> >On Saturday 22 May 2010, Arve Hjønnevåg wrote:
> >> This patch series adds a suspend-block api that provides the same
> >> functionality as the android wakelock api. This version a
On Mon, May 24, 2010 at 06:24:07PM +0300, Hiroshi DOYU wrote:
> From: ext Felipe Contreras
> Subject: [PATCH v3 10/14] omap: mailbox: reorganize registering
> Date: Sat, 22 May 2010 19:14:21 +0200
>
> > platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > - if (unlikely(!res)) {
> > -
On Sat, May 22, 2010 at 8:25 PM, Felipe Contreras
wrote:
> Hi,
>
> I played a bit with omap_hwmod/omap_device for the mailbox, and this is the
> result.
Nice move Felipe :)
Can you convert this to use the runtime PM layer, instead of directly
calling omap_device functions via pdata ?
Thanks,
Oh
Hi,
On Sat, May 22, 2010 at 07:14:25PM +0200, ext Felipe Contreras wrote:
Signed-off-by: Felipe Contreras
---
arch/arm/mach-omap1/mailbox.c |3 ---
arch/arm/mach-omap2/mailbox.c |1 -
arch/arm/plat-omap/include/plat/mailbox.h |3 ++-
arch/arm/plat-omap/mailbox.c
On Tue, May 18, 2010 at 12:12 PM, Felipe Contreras
wrote:
> 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 bran
On Fri, May 21, 2010 at 12:42 PM, Felipe Contreras
wrote:
> Although I'm still worried that VM_IO != write-combine, but I guess
> it's a safe assumption to do for now.
small update we missed:
The original code is ignoring VM_IO buffers as well:
static int memory_sync_vma(unsigned long start, u3
Add two new dspbridge ioctls that mark the
beginnind and end of a DMA transfer.
The direction of the DMA transfer is given as a parameter,
thus all three directions (DMA_BIDIRECTIONAL, DMA_TO_DEVICE
and DMA_FROM_DEVICE) are supported.
Signed-off-by: Ohad Ben-Cohen
---
If you want, you can also re
Add new dspbridge API that ends DMA transfers.
Signed-off-by: Ohad Ben-Cohen
---
If you want, you can also reach me at < ohadb at ti dot com >.
drivers/dsp/bridge/rmgr/proc.c | 68
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/drive
Now that we use standard DMA API instead of low level cache
manipulation API, mem_flush_cache can be removed.
Signed-off-by: Ohad Ben-Cohen
---
If you want, you can also reach me at < ohadb at ti dot com >.
arch/arm/plat-omap/include/dspbridge/drv.h | 15
drivers/dsp/bridge/rmg
Instead of using low level cache manipulation API,
use the standard DMA API. This is achieved by adding
a proc_begin_dma function that takes a generic
dma_data_direction, and then implementing proc_flush_memory
and proc_invalidate_memory by means of proc_begin_dma
in the following manner:
* flush
Eliminate the call to follow_page. Instead, use the page
information that was kept during the proc_map call.
This also has the advantage that users can now only
specify memory areas that were previously mapped.
Signed-off-by: Ohad Ben-Cohen
---
If you want, you can also reach me at < ohadb at ti
Every time the MM application calls proc_map to map
a memory area, remember the details of that mapping,
together with the related page structures.
Whenever a buffer is unmapped, clean up the mapping
information resources.
This information is maintained as part of the
DMM resource tracking mechanis
Enhance dmm_map_object to support additional mapping
and page information. This will be used to keep
track of mapping resources needed later to invoke
DMA transfers to/from the DSP.
Signed-off-by: Ohad Ben-Cohen
---
If you want, you can also reach me at < ohadb at ti dot com >.
arch/arm/plat-
This patchset introduces an approach to eliminate the direct calls
to follow_page and to the low level cache APIs.
The patchset works by caching the page information while memory
is mapped, and then using that information later when needed
instead of calling follow_page. The low level cache API i
Check spi->chip_select for range before use.
The spi->controller_state check is already in 2.6.34-rc7
Signed-off-by: Scott Ellis
drivers/spi/omap2_mcspi.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_m
Please ignore this patch.
Developer preference whether you want this much detail.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: ext Felipe Contreras
Subject: [PATCH v3 10/14] omap: mailbox: reorganize registering
Date: Sat, 22 May 2010 19:14:21 +0200
> platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (unlikely(!res)) {
> - dev_err(&pdev->dev, "invalid mem resource\n");
> - return -E
From: ext Felipe Contreras
Subject: [PATCH v3 13/14] omap: mailbox: simplify omap_mbox_register()
Date: Sat, 22 May 2010 19:14:24 +0200
> No need to dynamically register mailboxes one by one.
>
> Signed-off-by: Felipe Contreras
> ---
> arch/arm/mach-omap1/mailbox.c | 25 ++--
This was convenient in conjunction with some of the previous patches
since platform_device data was already getting read for max_clk_div and
num_cs was there too. Since max_clk_div is no more, maybe this patch
isn't worthwhile.
It's not a bug fix, so no harm ignoring.
I'll regenerate it if asked.
Please ignore this patch.
The changes already in 2.6.34-rc7 are sufficient.
They made it there because I initially submitted to the wrong list.
This patch was expanded from that one to also using the modified clock
divider values from patches 2 and 3 of this series which I have found
aren't need
From: ext Felipe Contreras
Subject: [PATCH v3 13/14] omap: mailbox: simplify omap_mbox_register()
Date: Sat, 22 May 2010 19:14:24 +0200
> No need to dynamically register mailboxes one by one.
Can you squash this into [PATCH 10/14]?
I think that the "struct omap_mbox **list" would make more sens
From: ext Felipe Contreras
Subject: [PATCH v3 11/14] omap: mailbox: only compile for configured archs
Date: Sat, 22 May 2010 19:14:22 +0200
> Signed-off-by: Felipe Contreras
> ---
> arch/arm/mach-omap2/mailbox.c | 14 --
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
> dif
Please disregard this patch.
PaulM from TI responded,
"It appears that this is a documentation error. The module does support
all 16 divide values for the CLKD field"
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/38754/142276.aspx#142276
--
To unsubscribe from this list: se
> "Govindraj.R" writes:
>
>> Patch series is based on remotes/origin/pm-wip/govindraj
>> branch from Kevin's PM tree.
>>
>> Patches are tested with 3430SDP.
>> Have updated 2420/2430 hwmod data files
>> it would be great if some one can test the same.
>
> Hi Govindraj,
>
> This series looks grea
Please disregard this patch.
PaulM from TI responded,
"It appears that this is a documentation error. The module does support
all 16 divide values for the CLKD field"
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/38754/142276.aspx#142276
--
To unsubscribe from this list: se
"Govindraj.R" writes:
> Patch series is based on remotes/origin/pm-wip/govindraj
> branch from Kevin's PM tree.
>
> Patches are tested with 3430SDP.
> Have updated 2420/2430 hwmod data files
> it would be great if some one can test the same.
Hi Govindraj,
This series looks great. I've added it
This patch adds driver support for OMAP3/4 high speed UART.
The driver is made separate from 8250 driver as we cannot
over load 8250 driver with omap platform specific configuration for
features like DMA, it makes easier to implement features like DMA and
hardware flow control and software flow co
Hi Hari,
From: ext Hari Kanigeri
Subject: [PATCH 0/3][v3] omap:iommu-enable TLB miss interrupt
Date: Mon, 24 May 2010 04:01:49 +0200
> The current iommu module doesn't provide the mechanism to get MMU fault on
> TLB miss when working with locked TLB entries and TWL disabled.
> To get the TLB mis
From: Hemanth V
Date: Fri, 21 May 2010 15:52:03 +0530
Subject: [PATCH] misc: ROHM BH1780GLI Ambient light sensor Driver
This patch adds support for ROHM BH1780GLI Ambient light sensor.
BH1780 supports I2C interface. Driver supports read/update of power state and
read of lux value (through SYSFS)
On Mon, May 24, 2010 at 12:29 PM, Hiroshi DOYU wrote:
> From: ext Felipe Contreras
> Subject: Re: [PATCH v2t2 00/17] omap: mailbox:
> Date: Mon, 24 May 2010 10:58:31 +0200
>
>> On Mon, May 24, 2010 at 9:36 AM, Hiroshi DOYU wrote:
> Moreover, Tony says that anything that registers platform de
From: ext Felipe Contreras
Subject: [PATCH v3 01/14] omap: mailbox: trivial whitespace cleanups
Date: Sat, 22 May 2010 19:14:12 +0200
> Signed-off-by: Felipe Contreras
> ---
>
> Hiroshi: I think there's something wrong with your editor =/
Hm...I did something wrong to save them. I'll fix. Than
From: ext Felipe Contreras
Subject: Re: [PATCH v2t2 00/17] omap: mailbox:
Date: Mon, 24 May 2010 10:58:31 +0200
> On Mon, May 24, 2010 at 9:36 AM, Hiroshi DOYU wrote:
Moreover, Tony says that anything that registers platform devices
should be built-in, but omap3-iommu does register dev
On Mon, May 24, 2010 at 9:36 AM, Hiroshi DOYU wrote:
>>> Moreover, Tony says that anything that registers platform devices
>>> should be built-in, but omap3-iommu does register devices and is not
>>> built-in.
>>
>> It seems that this makes you confused. It should have been
>> build-in;). This is
Hi,
On Sun, 2010-05-23 at 14:09 +0200, ext Janusz Krzysztofik wrote:
> Monday 17 May 2010 03:20:13 Janusz Krzysztofik wrote:
> > I was observing the following error messages on my OMAP1 based Amstrad
> > Delta board when first changing from text to graphics mode or vice versa
> > after the LCD dis
Hi,
> Here is a compile-tested patch since I haven't seen this fixed in mainline
> yet. It applies to the tip of Linus' tree.
>
> Attempting to remove usb_nop_xceiv_register() completely will require
> someone
> with more knowledge of davinci and blackfin archs to comment on what
> boards
> need
60 matches
Mail list logo
