From: Trent Piepho <tpiepho@freescale.com>
To: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Cc: Jamie Lokier <jamie@shareable.org>,
MTD mailing list <linux-mtd@lists.infradead.org>,
linux-kernel@vger.kernel.org, Bruce_Leonard@selinc.com,
Bruce Leonard <brucle@earthlink.net>
Subject: Re: [PATCH 2/2] Add support for > 2GiB MTD devices
Date: Wed, 27 Aug 2008 15:32:11 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0808271527100.3610@t2.domain.actdsltmp> (raw)
In-Reply-To: <48B5CC98.9000904@gmx.net>
On Wed, 27 Aug 2008, Carl-Daniel Hailfinger wrote:
> On 27.08.2008 20:51, Jamie Lokier wrote:
>> Bruce_Leonard@selinc.com wrote:
>>
>>> I'm still reluctant to change size to a 64-bit value. There's a vague
>>> recolection of early conversations on the list that there would be little
>>> acceptance for that. And that probably has to do with the ongoing
>>> conversation about ABI changes. What I could do to eliminate the
>>> multiplication is introduce the same concept that the NAND layer uses,
>>> shift values. After all, erasesize should always be a power of 2, making
>>> that a power of 2 multiplication which can be done via shifts. By
>>> changing erasesize to erasesize_shift, I'd get something like this:
>>>
>>> return a->num_eraseblocks == 0 ? a->size : a->num_eraseblocks <<
>>> a->erasesize_shift
>>>
>>> How would that suit you?
>>>
>>
>> Are you sure it's always going to be a power of 2?
>>
>> What if someone targets a board with 3 chips wired to shared address
>> and parallel data buses?
>>
>> Or if someone makes a weird chip? Or if you can format it in
>> different ways according to desired ECC level (like you can with CDs)?
>>
>
> IIRC I saw a datasheet for such a chip (selectable erasesize with
> non-power-of-2 default) some weeks ago and it had entered production a
> few months ago. The erasesize was alwas a multiple of 16, though. Sorry
> for not remembering more details.
It seems like the device size is always going to have some zeros in the least
significant bits. Maybe a 32-bit size plus a shift is enough? That could be
a lot more efficient than a 64-bit size and avoid penalizing most users who
don't need >32-bit size chips.
next prev parent reply other threads:[~2008-08-27 22:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <48AB3AAF.3010504@earthlink.net>
2008-08-27 5:40 ` Artem Bityutskiy
2008-08-27 7:15 ` Bruce Leonard
2008-08-27 18:18 ` Bruce_Leonard
2008-08-27 18:51 ` Jamie Lokier
2008-08-27 21:52 ` Carl-Daniel Hailfinger
2008-08-27 22:32 ` Trent Piepho [this message]
2008-08-28 17:48 ` Bruce_Leonard
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=Pine.LNX.4.64.0808271527100.3610@t2.domain.actdsltmp \
--to=tpiepho@freescale.com \
--cc=Bruce_Leonard@selinc.com \
--cc=brucle@earthlink.net \
--cc=c-d.hailfinger.devel.2006@gmx.net \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®