All of lore.kernel.org
 help / color / mirror / Atom feed
From: Omar Ramirez Luna <omar.ramirez@ti.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Tony Lindgren <tony@atomide.com>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	"Gomez Castellanos, Ivan" <ivan.gomez@ti.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	"Ramos Falcon, Ernesto" <ernesto@ti.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	Ameya Palande <ameya.palande@nokia.com>
Subject: Re: [RFC] tidspbridge: use a parameter to allocate shared memory
Date: Thu, 7 Oct 2010 12:13:10 -0500	[thread overview]
Message-ID: <4CADFFA6.50202@ti.com> (raw)
In-Reply-To: <201010071601.04597.laurent.pinchart@ideasonboard.com>

On 10/7/2010 9:01 AM, Laurent Pinchart wrote:
> On Thursday 07 October 2010 10:32:42 Russell King - ARM Linux wrote:
>>
>> ARMv6 and above don't like having multiple mappings with different
>> memory type/shareability/cache attributes.  It's architecturally
>> forbidden.
>>
>> So if you want non-cacheable memory and you want to be architecturally
>> compliant, you have to exclude it from the kernel's direct-mapped
>> memory mapping.
>
> That's why Omar's patch uses 'mem=' to exclude system memory from the kernel
> mappings. That's not ideal though, as that memory will be wasted forever,
> hence my comments regarding whether a non-cacheable mapping was really
> required.

it is not ideal to waste that memory, but strictly speaking old bootmem 
does the same, as no one will be touching that memory. i.e. you compile 
bridge as a module but you never insmod it, the reserved bootmem space 
is there for bridge anyway; same for bootargs tweaking, if you need 
dspbridge and are going to use it then you set aside some memory for it.

What might be a pain for end-user, is to have drivers that need to do 
tweaking to bootargs to work; but right now that is a requirement, until 
a better solution is found/created.

Regards,

Omar


WARNING: multiple messages have this Message-ID (diff)
From: omar.ramirez@ti.com (Omar Ramirez Luna)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] tidspbridge: use a parameter to allocate shared memory
Date: Thu, 7 Oct 2010 12:13:10 -0500	[thread overview]
Message-ID: <4CADFFA6.50202@ti.com> (raw)
In-Reply-To: <201010071601.04597.laurent.pinchart@ideasonboard.com>

On 10/7/2010 9:01 AM, Laurent Pinchart wrote:
> On Thursday 07 October 2010 10:32:42 Russell King - ARM Linux wrote:
>>
>> ARMv6 and above don't like having multiple mappings with different
>> memory type/shareability/cache attributes.  It's architecturally
>> forbidden.
>>
>> So if you want non-cacheable memory and you want to be architecturally
>> compliant, you have to exclude it from the kernel's direct-mapped
>> memory mapping.
>
> That's why Omar's patch uses 'mem=' to exclude system memory from the kernel
> mappings. That's not ideal though, as that memory will be wasted forever,
> hence my comments regarding whether a non-cacheable mapping was really
> required.

it is not ideal to waste that memory, but strictly speaking old bootmem 
does the same, as no one will be touching that memory. i.e. you compile 
bridge as a module but you never insmod it, the reserved bootmem space 
is there for bridge anyway; same for bootargs tweaking, if you need 
dspbridge and are going to use it then you set aside some memory for it.

What might be a pain for end-user, is to have drivers that need to do 
tweaking to bootargs to work; but right now that is a requirement, until 
a better solution is found/created.

Regards,

Omar

  reply	other threads:[~2010-10-07 17:13 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-07  5:45 [RFC] tidspbridge: use a parameter to allocate shared memory Omar Ramirez Luna
2010-10-07  5:45 ` Omar Ramirez Luna
2010-10-07  7:40 ` Laurent Pinchart
2010-10-07  7:40   ` Laurent Pinchart
2010-10-07  8:32   ` Russell King - ARM Linux
2010-10-07  8:32     ` Russell King - ARM Linux
2010-10-07 14:01     ` Laurent Pinchart
2010-10-07 14:01       ` Laurent Pinchart
2010-10-07 17:13       ` Omar Ramirez Luna [this message]
2010-10-07 17:13         ` Omar Ramirez Luna
2010-10-07 19:07       ` Russell King - ARM Linux
2010-10-07 19:07         ` Russell King - ARM Linux
2010-10-07 17:01   ` Omar Ramirez Luna
2010-10-07 17:01     ` Omar Ramirez Luna
2010-10-07 18:22     ` Felipe Contreras
2010-10-07 18:22       ` Felipe Contreras
2010-10-07 19:16       ` Omar Ramirez Luna
2010-10-07 19:16         ` Omar Ramirez Luna
2010-10-08  8:18         ` Felipe Contreras
2010-10-08  8:18           ` Felipe Contreras
2010-10-08 17:20           ` Omar Ramirez Luna
2010-10-08 17:20             ` Omar Ramirez Luna
2010-10-08  8:20         ` Felipe Contreras
2010-10-08  8:20           ` Felipe Contreras
2010-10-08 17:31           ` Omar Ramirez Luna
2010-10-08 17:31             ` Omar Ramirez Luna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CADFFA6.50202@ti.com \
    --to=omar.ramirez@ti.com \
    --cc=ameya.palande@nokia.com \
    --cc=ernesto@ti.com \
    --cc=felipe.contreras@gmail.com \
    --cc=gregkh@suse.de \
    --cc=ivan.gomez@ti.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=ohad@wizery.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.