From: Jon Hunter <jon-hunter@ti.com>
To: Daniel Mack <zonque@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
x0148406@ti.com, tony@atomide.com, paul@pwsan.com,
nsekhar@ti.com
Subject: Re: [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Date: Thu, 25 Oct 2012 08:22:55 -0500 [thread overview]
Message-ID: <50893D2F.6080205@ti.com> (raw)
In-Reply-To: <508909CC.9000000@gmail.com>
On 10/25/2012 04:43 AM, Daniel Mack wrote:
> Hi Jon,
>
> On 25.10.2012 03:53, Jon Hunter wrote:
>>
>> On 10/22/2012 02:55 PM, Daniel Mack wrote:
>
>>> +Example for an AM33xx board:
>>> +
>>> + gpmc: gpmc@50000000 {
>>> + compatible = "ti,gpmc";
>>> + ti,hwmods = "gpmc";
>>> + reg = <0x50000000 0x1000000>;
>>
>> Nit-pick, that size is quite large for a register range. I recommend
>> looking at the HWMOD data file
>> (arch/arm/mach-omap2/omap_hwmod_33xx_data.c) and see how much space is
>> allocated for the registers (see structure am33xx_gpmc_addr_space).
>
> Yeah but reserving the entire memory as per the reference manual also
> prvents other from poking around in the same register space. Is there a
> scenario in which it would of disadvantage to reserve all that memory?
1. It chews up a large chunk of virtual memory space unnecessarily. For
devices not using HIGHMEM and wish to use say 512MB of RAM, virtual
memory space can be constrained.
2. We don't do that today probably because of #1.
Cheers
Jon
WARNING: multiple messages have this Message-ID (diff)
From: jon-hunter@ti.com (Jon Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Date: Thu, 25 Oct 2012 08:22:55 -0500 [thread overview]
Message-ID: <50893D2F.6080205@ti.com> (raw)
In-Reply-To: <508909CC.9000000@gmail.com>
On 10/25/2012 04:43 AM, Daniel Mack wrote:
> Hi Jon,
>
> On 25.10.2012 03:53, Jon Hunter wrote:
>>
>> On 10/22/2012 02:55 PM, Daniel Mack wrote:
>
>>> +Example for an AM33xx board:
>>> +
>>> + gpmc: gpmc at 50000000 {
>>> + compatible = "ti,gpmc";
>>> + ti,hwmods = "gpmc";
>>> + reg = <0x50000000 0x1000000>;
>>
>> Nit-pick, that size is quite large for a register range. I recommend
>> looking at the HWMOD data file
>> (arch/arm/mach-omap2/omap_hwmod_33xx_data.c) and see how much space is
>> allocated for the registers (see structure am33xx_gpmc_addr_space).
>
> Yeah but reserving the entire memory as per the reference manual also
> prvents other from poking around in the same register space. Is there a
> scenario in which it would of disadvantage to reserve all that memory?
1. It chews up a large chunk of virtual memory space unnecessarily. For
devices not using HIGHMEM and wish to use say 512MB of RAM, virtual
memory space can be constrained.
2. We don't do that today probably because of #1.
Cheers
Jon
next prev parent reply other threads:[~2012-10-25 13:22 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 19:55 [PATCH 0/4] RFC: OMAP GPMC bindings Daniel Mack
2012-10-22 19:55 ` Daniel Mack
2012-10-22 19:55 ` [PATCH 1/4] mtd: omap-nand: pass device_node in platform data Daniel Mack
2012-10-22 19:55 ` Daniel Mack
2012-10-22 19:55 ` [PATCH 2/4] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs Daniel Mack
2012-10-22 19:55 ` Daniel Mack
2012-10-22 19:55 ` [PATCH 3/4] ARM: OMAP: gpmc: don't create devices from initcall on DT Daniel Mack
2012-10-22 19:55 ` Daniel Mack
2012-10-22 19:55 ` [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND Daniel Mack
2012-10-22 19:55 ` Daniel Mack
2012-10-24 23:27 ` Tony Lindgren
2012-10-24 23:27 ` Tony Lindgren
2012-10-24 23:31 ` Daniel Mack
2012-10-24 23:31 ` Daniel Mack
2012-10-29 8:10 ` Afzal Mohammed
2012-10-29 8:10 ` Afzal Mohammed
2012-10-29 11:15 ` Daniel Mack
2012-10-29 11:15 ` Daniel Mack
2012-10-29 11:28 ` Afzal Mohammed
2012-10-29 11:28 ` Afzal Mohammed
2012-10-29 12:32 ` Daniel Mack
2012-10-29 12:32 ` Daniel Mack
2012-10-29 12:56 ` Afzal Mohammed
2012-10-29 12:56 ` Afzal Mohammed
2012-10-25 1:28 ` Jon Hunter
2012-10-25 1:28 ` Jon Hunter
2012-10-25 8:00 ` Daniel Mack
2012-10-25 8:00 ` Daniel Mack
2012-10-25 13:16 ` Jon Hunter
2012-10-25 13:16 ` Jon Hunter
2012-10-29 8:09 ` Afzal Mohammed
2012-10-29 8:09 ` Afzal Mohammed
2012-10-25 1:53 ` Jon Hunter
2012-10-25 1:53 ` Jon Hunter
2012-10-25 9:43 ` Daniel Mack
2012-10-25 9:43 ` Daniel Mack
2012-10-25 13:22 ` Jon Hunter [this message]
2012-10-25 13:22 ` Jon Hunter
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=50893D2F.6080205@ti.com \
--to=jon-hunter@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=paul@pwsan.com \
--cc=tony@atomide.com \
--cc=x0148406@ti.com \
--cc=zonque@gmail.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.