From: ebiederman@lnxi.com (Eric W. Biederman)
To: Munira Ahmed <munira.ahmed@radixs.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: stdio.h and kernel space
Date: 19 May 2005 23:00:42 -0600 [thread overview]
Message-ID: <m3wtpu330l.fsf@maxwell.lnxi.com> (raw)
In-Reply-To: <1116560734.18096.108.camel@server11>
Munira Ahmed <munira.ahmed@radixs.com> writes:
> Hang on
>
> I am confused now
>
> cfi_cmdset_0002.c implements CFI or a flash driver?
Breaking things down a little more, in the mtd stack there are 3 kinds of drivers.
map drivers that describe how to talk to a given flash chip.
probe drivers that identify what kind of chip you have.
chip drivers that know how to speak a command set and let you flash your chip.
> What I understand from is that
>
> there is one cfi command set just to find out which chip is being used
> and what driver to use.
There is a probe driver. Not a really a command set, but you have
the idea.
There are two JEDEC standard probe methods the original
which simply gives vendor/device id bytes. And the CFI
probe which gives you a little more and means you don't need
a table of devices.
> The other one is the software command set to tell the flash what to
> do.This command set would essentially constitute the driver.
Yes.
> earlier there used to be a JEDEC standard before CFI came in vogue. It
> used to do the same thing which is now done by CFI albeit in some old
> fashioned or may be in not so efficient way. there must be something
> missing in there that's why it is getting out of use. jedec_probe.c
> if I am not wrong implements this standard which is almost obsolete.
The CFI standard seems to be a reaction to the observation that the largest
part of a flash driver that supports multiple chips is the lookup table
by vendor/device that reports the commands set and chip size. After
that everything tends to use either the intel (cfi_cmdset_0001) or the
amd (cfi_cmdset_0002) command set.
It really depends on which market segment you are in which probe methods
are supported. In addition most CFI chips also support the older style
jedec probe as well.
> Now this S29WSxxxN is CFI compliant and uses a software command set
> called JEDEC 42.4 standard to instruct the flash. So CFI in the kernel
> should be able to identify that which chip is used.
>
> No which file in the kernel implements CFI?
cfi_probe.
> how to tell this CFI to use a new driver?
cfi_probe should run on the chip find it and then complain that
it can't find some property. So as long as you have an appropriate
map driver that calls cfi_probe you should be 90% of the way there
and the error messages should be able to guide you in.
> which file if any in the kerenl implements JEDEC 42.2 command set to
> instruct a flash?
JEDEC 42.2 is not a clear reference to me, but I do know that JEDEC has
a standard command set that is very similar to what AMD uses. CFI
enumerates several known commands sets. Which enumeration value does
it describe your command set with. My hunch is that the CFI probe
data returns the value 0002. Once you know which value the
CFI probe data returns then we can talk about adding code.
Eric
next prev parent reply other threads:[~2005-05-20 5:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-16 6:50 stdio.h and kernel space Munira Ahmed
2005-05-16 13:02 ` Ralph Siemsen
2005-05-17 1:26 ` Munira Ahmed
2005-05-18 22:24 ` Ralph Siemsen
2005-05-19 1:45 ` Munira Ahmed
2005-05-19 11:47 ` Ralph Siemsen
2005-05-20 2:40 ` Munira Ahmed
2005-05-20 3:16 ` Eric W. Biederman
2005-05-20 3:45 ` Munira Ahmed
2005-05-20 5:00 ` Eric W. Biederman [this message]
2005-05-20 7:56 ` Munira Ahmed
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=m3wtpu330l.fsf@maxwell.lnxi.com \
--to=ebiederman@lnxi.com \
--cc=linux-mtd@lists.infradead.org \
--cc=munira.ahmed@radixs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox