All of lore.kernel.org
 help / color / mirror / Atom feed
* ioremap on system memory
@ 2011-11-10  8:06 Marcus Folkesson
  2011-11-10 22:11   ` Ryan Mallon
  0 siblings, 1 reply; 5+ messages in thread
From: Marcus Folkesson @ 2011-11-10  8:06 UTC (permalink / raw)
  To: linux-kernel

Hi,

I'm working with a custom based platform based on OMAP-L138.
A driver we are using is ioremapping system memory. It does this to
share data between the GPP and DSP core.
This is not allowed in later kernel versions since ARMv6+ does not support this.

Is there any good(and easy) way to get around this or is it so
fundamentally wrong that the driver should be written from scratch?

Thanks in advance

Med vänliga hälsningar / Best regards
Marcus Folkesson

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ioremap on system memory
  2011-11-10  8:06 ioremap on system memory Marcus Folkesson
@ 2011-11-10 22:11   ` Ryan Mallon
  0 siblings, 0 replies; 5+ messages in thread
From: Ryan Mallon @ 2011-11-10 22:11 UTC (permalink / raw)
  To: Marcus Folkesson; +Cc: linux-kernel, linux-arm-kernel, m.szyprowski

On 10/11/11 19:06, Marcus Folkesson wrote:

> Hi,
> 
> I'm working with a custom based platform based on OMAP-L138.
> A driver we are using is ioremapping system memory. It does this to
> share data between the GPP and DSP core.
> This is not allowed in later kernel versions since ARMv6+ does not support this.
> 
> Is there any good(and easy) way to get around this or is it so
> fundamentally wrong that the driver should be written from scratch?


Cc'ed the ARM kernel list and Marek Szyprowski (CMA developer). The CMA
patches I think do what you want, but I am not sure if they are merged
yet. The other solution (again, I'm not an expert on this area) is to
not pass the region of memory you want to manage as part of Linux's
normal system memory. See how the OMAP framebuffer driver reserves a
region of SDRAM (arch/arm/plat-omap/fb.c).

Some one else on the ARM list can probably explain in more detail.

~Ryan


^ permalink raw reply	[flat|nested] 5+ messages in thread

* ioremap on system memory
@ 2011-11-10 22:11   ` Ryan Mallon
  0 siblings, 0 replies; 5+ messages in thread
From: Ryan Mallon @ 2011-11-10 22:11 UTC (permalink / raw)
  To: linux-arm-kernel

On 10/11/11 19:06, Marcus Folkesson wrote:

> Hi,
> 
> I'm working with a custom based platform based on OMAP-L138.
> A driver we are using is ioremapping system memory. It does this to
> share data between the GPP and DSP core.
> This is not allowed in later kernel versions since ARMv6+ does not support this.
> 
> Is there any good(and easy) way to get around this or is it so
> fundamentally wrong that the driver should be written from scratch?


Cc'ed the ARM kernel list and Marek Szyprowski (CMA developer). The CMA
patches I think do what you want, but I am not sure if they are merged
yet. The other solution (again, I'm not an expert on this area) is to
not pass the region of memory you want to manage as part of Linux's
normal system memory. See how the OMAP framebuffer driver reserves a
region of SDRAM (arch/arm/plat-omap/fb.c).

Some one else on the ARM list can probably explain in more detail.

~Ryan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: ioremap on system memory
  2011-11-10 22:11   ` Ryan Mallon
@ 2011-11-11  6:59     ` Marcus Folkesson
  -1 siblings, 0 replies; 5+ messages in thread
From: Marcus Folkesson @ 2011-11-11  6:59 UTC (permalink / raw)
  To: Ryan Mallon; +Cc: linux-kernel, linux-arm-kernel, m.szyprowski

2011/11/10 Ryan Mallon <rmallon@gmail.com>
>
> On 10/11/11 19:06, Marcus Folkesson wrote:
>
> > Hi,
> >
> > I'm working with a custom based platform based on OMAP-L138.
> > A driver we are using is ioremapping system memory. It does this to
> > share data between the GPP and DSP core.
> > This is not allowed in later kernel versions since ARMv6+ does not support this.
> >
> > Is there any good(and easy) way to get around this or is it so
> > fundamentally wrong that the driver should be written from scratch?
>
>
> Cc'ed the ARM kernel list and Marek Szyprowski (CMA developer). The CMA
> patches I think do what you want, but I am not sure if they are merged
> yet. The other solution (again, I'm not an expert on this area) is to
> not pass the region of memory you want to manage as part of Linux's
> normal system memory. See how the OMAP framebuffer driver reserves a
> region of SDRAM (arch/arm/plat-omap/fb.c).
>
> Some one else on the ARM list can probably explain in more detail.
>
> ~Ryan
>

Not passing the region of the concerned memory seems to solve the problem.
Thank you!

Med vänliga hälsningar / Best regards
Marcus Folkesson

^ permalink raw reply	[flat|nested] 5+ messages in thread

* ioremap on system memory
@ 2011-11-11  6:59     ` Marcus Folkesson
  0 siblings, 0 replies; 5+ messages in thread
From: Marcus Folkesson @ 2011-11-11  6:59 UTC (permalink / raw)
  To: linux-arm-kernel

2011/11/10 Ryan Mallon <rmallon@gmail.com>
>
> On 10/11/11 19:06, Marcus Folkesson wrote:
>
> > Hi,
> >
> > I'm working with a custom based platform based on OMAP-L138.
> > A driver we are using is ioremapping system memory. It does this to
> > share data between the GPP and DSP core.
> > This is not allowed in later kernel versions since ARMv6+ does not support this.
> >
> > Is there any good(and easy) way to get around this or is it so
> > fundamentally wrong that the driver should be written from scratch?
>
>
> Cc'ed the ARM kernel list and Marek Szyprowski (CMA developer). The CMA
> patches I think do what you want, but I am not sure if they are merged
> yet. The other solution (again, I'm not an expert on this area) is to
> not pass the region of memory you want to manage as part of Linux's
> normal system memory. See how the OMAP framebuffer driver reserves a
> region of SDRAM (arch/arm/plat-omap/fb.c).
>
> Some one else on the ARM list can probably explain in more detail.
>
> ~Ryan
>

Not passing the region of the concerned memory seems to solve the problem.
Thank you!

Med v?nliga h?lsningar / Best regards
Marcus Folkesson

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-11-11  6:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-10  8:06 ioremap on system memory Marcus Folkesson
2011-11-10 22:11 ` Ryan Mallon
2011-11-10 22:11   ` Ryan Mallon
2011-11-11  6:59   ` Marcus Folkesson
2011-11-11  6:59     ` Marcus Folkesson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.