On Mon, 29 Sep 2008 10:46:33 +0530
ext Arun KS [EMAIL PROTECTED] wrote:
The system hangs when there is a request for mcbsp in the platform
driver of omap ie.. at
File:sound/soc/omap/omap-mcbsp.c
Function: omap_mcbsp_dai_startup
omap_mcbsp_request(mcbsp_data-bus_id);
This is executed when we
On Mon, Sep 29, 2008 at 1:14 PM, Jarkko Nikula [EMAIL PROTECTED] wrote:
On Mon, 29 Sep 2008 10:46:33 +0530
ext Arun KS [EMAIL PROTECTED] wrote:
The system hangs when there is a request for mcbsp in the platform
driver of omap ie.. at
File:sound/soc/omap/omap-mcbsp.c
Function:
Hi Russel,
Sorry for late reply.
I applied the patch and tested, but it didn't resolves my problem.
I found that code hangs at this point.
File : arch/arm/plat-omap/mcbsp.c
Function: omap_mcbsp_request
if (mcbsp-pdata mcbsp-pdata-ops mcbsp-pdata-ops-request)
On Wed, Sep 03, 2008 at 11:33:51AM -0400, Eduardo Valentin wrote:
@@ -159,7 +159,7 @@ static struct omap_mcbsp_platform_data
omap730_mcbsp_pdata[] = {
#ifdef CONFIG_ARCH_OMAP15XX
static struct omap_mcbsp_platform_data omap15xx_mcbsp_pdata[] = {
{
- .virt_base
* Russell King - ARM Linux [EMAIL PROTECTED] [080904 02:47]:
On Wed, Sep 03, 2008 at 11:33:51AM -0400, Eduardo Valentin wrote:
@@ -159,7 +159,7 @@ static struct omap_mcbsp_platform_data
omap730_mcbsp_pdata[] = {
#ifdef CONFIG_ARCH_OMAP15XX
static struct omap_mcbsp_platform_data
On Thu, Sep 04, 2008 at 09:10:34AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux [EMAIL PROTECTED] [080904 02:47]:
On Wed, Sep 03, 2008 at 11:33:51AM -0400, Eduardo Valentin wrote:
@@ -159,7 +159,7 @@ static struct omap_mcbsp_platform_data
omap730_mcbsp_pdata[] = {
#ifdef
* Russell King - ARM Linux [EMAIL PROTECTED] [080904 09:13]:
On Thu, Sep 04, 2008 at 09:10:34AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux [EMAIL PROTECTED] [080904 02:47]:
On Wed, Sep 03, 2008 at 11:33:51AM -0400, Eduardo Valentin wrote:
@@ -159,7 +159,7 @@ static struct
On Thu, Sep 04, 2008 at 09:29:19AM -0700, Tony Lindgren wrote:
That was fast :) Sounds we'll have a patch to test soon.
Of course. In my tree. The master branch contains the minimal fixes,
and the devel branch contains everything. If you want the individual
patches, either pull the tree or
* Russell King - ARM Linux [EMAIL PROTECTED] [080904 10:07]:
On Thu, Sep 04, 2008 at 09:29:19AM -0700, Tony Lindgren wrote:
That was fast :) Sounds we'll have a patch to test soon.
Of course. In my tree. The master branch contains the minimal fixes,
and the devel branch contains
On Thu, Sep 04, 2008 at 10:58:13AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux [EMAIL PROTECTED] [080904 10:07]:
On Thu, Sep 04, 2008 at 09:29:19AM -0700, Tony Lindgren wrote:
That was fast :) Sounds we'll have a patch to test soon.
Of course. In my tree. The master branch
* Russell King - ARM Linux [EMAIL PROTECTED] [080904 14:01]:
On Thu, Sep 04, 2008 at 10:58:13AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux [EMAIL PROTECTED] [080904 10:07]:
On Thu, Sep 04, 2008 at 09:29:19AM -0700, Tony Lindgren wrote:
That was fast :) Sounds we'll have a
* Tony Lindgren [EMAIL PROTECTED] [080904 14:20]:
* Russell King - ARM Linux [EMAIL PROTECTED] [080904 14:01]:
On Thu, Sep 04, 2008 at 10:58:13AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux [EMAIL PROTECTED] [080904 10:07]:
On Thu, Sep 04, 2008 at 09:29:19AM -0700, Tony
Hello Russell, Tony,
in arch/arm/plat-omap/include/mach/io.h, shouldn't these casts be
__force void __iomem * ?
#define IO_ADDRESS(pa) ((void __iomem *)__IO_ADDRESS(pa))
#define OMAP1_IO_ADDRESS(pa)((void __iomem *)__OMAP1_IO_ADDRESS(pa))
#define OMAP2_IO_ADDRESS(pa)((void
On Thu, 4 Sep 2008, Paul Walmsley wrote:
Hello Russell, Tony,
in arch/arm/plat-omap/include/mach/io.h, shouldn't these casts be
__force void __iomem * ?
#define IO_ADDRESS(pa)((void __iomem *)__IO_ADDRESS(pa))
#define OMAP1_IO_ADDRESS(pa) ((void __iomem
On Tue, Sep 02, 2008 at 03:15:10PM -0700, Tony Lindgren wrote:
Back online now. These changes look ggood to me in general, except
I suggest that we use the following standard:
- Keep OMAP1_IO_ADDRESS() and OMAP2_IO_ADDRESS() as I have some
experimental patches to compile in both omap1 and
Hi Tony,
On Tue, Sep 2, 2008 at 6:15 PM, Tony Lindgren [EMAIL PROTECTED] wrote:
Hi,
* David Brownell [EMAIL PROTECTED] [080831 14:47]:
On Wednesday 27 August 2008, Russell King wrote:
I sent a similar patch to the one below against mainline to Tony today.
And I'm glad to see those
* Russell King - ARM Linux [EMAIL PROTECTED] [080903 00:56]:
On Tue, Sep 02, 2008 at 03:15:10PM -0700, Tony Lindgren wrote:
Back online now. These changes look ggood to me in general, except
I suggest that we use the following standard:
- Keep OMAP1_IO_ADDRESS() and OMAP2_IO_ADDRESS() as
* Tony Lindgren [EMAIL PROTECTED] [080902 15:16]:
Hi,
* David Brownell [EMAIL PROTECTED] [080831 14:47]:
On Wednesday 27 August 2008, Russell King wrote:
snip
So I can try my patch for the omap_udc thing ... even though for
OSK the mainline kernel ** DOES NOT BOOT ** and dies even
Hi,
On Wed, Sep 3, 2008 at 2:48 PM, Russell King [EMAIL PROTECTED] wrote:
On Wed, Sep 03, 2008 at 11:33:51AM -0400, Eduardo Valentin wrote:
@@ -159,7 +159,7 @@ static struct omap_mcbsp_platform_data
omap730_mcbsp_pdata[] = {
#ifdef CONFIG_ARCH_OMAP15XX
static struct
On Wed, Sep 03, 2008 at 09:40:08AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux [EMAIL PROTECTED] [080903 00:56]:
- Use io_p2v() for initializing dynamic stuff as it can be a function
for non-optimized multiboot binaries.
It can't become a function - it's used in structure
On Wed, Sep 03, 2008 at 03:33:55PM -0400, Eduardo Valentin wrote:
Hi,
On Wed, Sep 3, 2008 at 2:48 PM, Russell King [EMAIL PROTECTED] wrote:
On Wed, Sep 03, 2008 at 11:33:51AM -0400, Eduardo Valentin wrote:
@@ -159,7 +159,7 @@ static struct omap_mcbsp_platform_data
* Russell King - ARM Linux [EMAIL PROTECTED] [080903 12:34]:
On Wed, Sep 03, 2008 at 09:40:08AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux [EMAIL PROTECTED] [080903 00:56]:
- Use io_p2v() for initializing dynamic stuff as it can be a function
for non-optimized multiboot
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Russell King - ARM Linux
Sent: Wednesday, September 03, 2008 2:34 PM
snip
The question is why do we need it? If the correct physical address
is passed, then things should work out just fine anyway, especially
if
Hi Russell,
On Wed, Sep 3, 2008 at 3:48 PM, Russell King - ARM Linux
[EMAIL PROTECTED] wrote:
On Wed, Sep 03, 2008 at 03:33:55PM -0400, Eduardo Valentin wrote:
Hi,
On Wed, Sep 3, 2008 at 2:48 PM, Russell King [EMAIL PROTECTED] wrote:
On Wed, Sep 03, 2008 at 11:33:51AM -0400, Eduardo
On Wed, Sep 03, 2008 at 02:58:10PM -0500, Woodruff, Richard wrote:
Fixed translations do have some benefits. You can ensure that you are
using section or super section descriptors to cover large areas. This
does result in better TLB usage. Along with freeing up TLB entries you
also
* Woodruff, Richard [EMAIL PROTECTED] [080903 12:58]:
From: [EMAIL PROTECTED] [mailto:linux-omap-
[EMAIL PROTECTED] On Behalf Of Russell King - ARM Linux
Sent: Wednesday, September 03, 2008 2:34 PM
snip
The question is why do we need it? If the correct physical address
is passed,
* Russell King - ARM Linux [EMAIL PROTECTED] [080903 12:49]:
On Wed, Sep 03, 2008 at 03:33:55PM -0400, Eduardo Valentin wrote:
Hi,
On Wed, Sep 3, 2008 at 2:48 PM, Russell King [EMAIL PROTECTED] wrote:
On Wed, Sep 03, 2008 at 11:33:51AM -0400, Eduardo Valentin wrote:
@@ -159,7 +159,7
On Wed, Sep 03, 2008 at 04:04:11PM -0400, Eduardo Valentin wrote:
Hi Russell,
On Wed, Sep 3, 2008 at 3:48 PM, Russell King - ARM Linux
[EMAIL PROTECTED] wrote:
Yes, that will be virtual. But what does it mean to call:
omap_set_dma_dest_params()
specifying a virtual address?
* Tony Lindgren [EMAIL PROTECTED] [080903 13:50]:
* Russell King - ARM Linux [EMAIL PROTECTED] [080903 13:46]:
On Wed, Sep 03, 2008 at 04:04:11PM -0400, Eduardo Valentin wrote:
Hi Russell,
On Wed, Sep 3, 2008 at 3:48 PM, Russell King - ARM Linux
[EMAIL PROTECTED] wrote:
Yes,
Op 3 sep 2008, om 22:45 heeft Russell King - ARM Linux het volgende
geschreven:
I would look up this CDSA register in the OMAP manuals, if they were
accessible... Are they not publically available? (Google isn't
helping, neither is searching on ti.com...)
Try
* Russell King - ARM Linux [EMAIL PROTECTED] [080903 14:07]:
On Wed, Sep 03, 2008 at 01:56:18PM -0700, Tony Lindgren wrote:
* Tony Lindgren [EMAIL PROTECTED] [080903 13:50]:
There is a 3450 public TRM somewhere AFAIK, anybody got a link for that?
At least 5912 TRM is available somewhere.
On Wednesday 03 September 2008, Woodruff, Richard wrote:
Fixed translations do have some benefits. You can ensure that you
are using section or super section descriptors to cover large areas.
This does result in better TLB usage. Along with freeing up TLB
entries you also generally avoid TLB
Hi Russell,
On Wed, Sep 3, 2008 at 5:04 PM, Russell King - ARM Linux
[EMAIL PROTECTED] wrote:
On Wed, Sep 03, 2008 at 01:37:21PM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux [EMAIL PROTECTED] [080903 12:49]:
Yes, that will be virtual. But what does it mean to call:
* Woodruff, Richard [EMAIL PROTECTED] [080903 14:32]:
From: Tony Lindgren [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 3:33 PM
snip
Fixed translations do have some benefits. You can ensure that you are
using section or super section descriptors to cover large areas.
On Wednesday 03 September 2008, Russell King - ARM Linux wrote:
- virtual addresses are pointer like.
- physical addresses are integer like.
So, if it's a physical address, it should be stored in an integer type
large enough to contain it, and that means something like u32, or
unsigned
On Wed, Sep 03, 2008 at 04:32:10PM -0500, Woodruff, Richard wrote:
From: Tony Lindgren [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 3:33 PM
snip
Fixed translations do have some benefits. You can ensure that you are
using section or super section descriptors to cover
From: David Brownell [mailto:[EMAIL PROTECTED]
snip
On Wednesday 03 September 2008, Woodruff, Richard wrote:
Fixed translations do have some benefits. You can ensure that you
are using section or super section descriptors to cover large areas.
This does result in better TLB usage. Along
On Wed, Sep 03, 2008 at 03:05:59PM -0700, David Brownell wrote:
According to Mr. Grep, there are at least 10 ARMs that work
like that in mainline. Maybe Russell can recommend one of
them as a preferred model.
As I've been trying to say, I see this as a separate issue for the near
future. At
On Wed, Sep 03, 2008 at 02:09:14PM -0700, David Brownell wrote:
On Wednesday 03 September 2008, Tony Lindgren wrote:
I still want to hear on the other build fix in the patch, and there's
also a missing function for mmc stuff which I've not looked into yet.
The mpuio build fix?
On Wed, Sep 03, 2008 at 02:35:52PM -0700, David Brownell wrote:
On Wednesday 03 September 2008, Russell King - ARM Linux wrote:
- virtual addresses are pointer like.
- physical addresses are integer like.
So, if it's a physical address, it should be stored in an integer type
large
On Wednesday 03 September 2008, Tony Lindgren wrote:
My OSK is booting just fine here with current mainline and the
omap_osk_5912_defconfig. This is the current head at
2.6.27-rc5-00100-gec0c15a. Have you checked if yours boots with
the mainline omap_osk_5912_defconfig?
Today's root seems to
* Russell King - ARM Linux [EMAIL PROTECTED] [080903 15:57]:
On Wed, Sep 03, 2008 at 03:05:59PM -0700, David Brownell wrote:
According to Mr. Grep, there are at least 10 ARMs that work
like that in mainline. Maybe Russell can recommend one of
them as a preferred model.
As I've been
On Wednesday 03 September 2008, Russell King - ARM Linux wrote:
On Wed, Sep 03, 2008 at 03:05:59PM -0700, David Brownell wrote:
According to Mr. Grep, there are at least 10 ARMs that work
like that [__arch_ioremap] in mainline. Maybe Russell can
recommend one of them as a preferred model.
Hi,
* David Brownell [EMAIL PROTECTED] [080831 14:47]:
On Wednesday 27 August 2008, Russell King wrote:
I sent a similar patch to the one below against mainline to Tony today.
And I'm glad to see those updates. I used to constantly trip over
code doing strange stuff in those areas, and it
44 matches
Mail list logo
