All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Alex Dubov <oakad@yahoo.com>,
	arnd@arndb.de, tglx@linutronix.de
Subject: Re: Plan for adding XD support in mtd layer
Date: Thu, 26 Nov 2009 09:27:15 +0100	[thread overview]
Message-ID: <20091126082715.GG10944@logfs.org> (raw)
In-Reply-To: <1259191365.15916.31.camel@maxim-laptop>

On Thu, 26 November 2009 01:22:45 +0200, Maxim Levitsky wrote:
> > 
> > According to FMTP140E.PDF, CIS and IDI are stored in sector 0 or the
> > first non-defective block.  In other words, it can be read and written
> > normally, without any magic.  Certainly not the atrocities I tried not
> > to remember.
> I wish I had the spec.

It used to be semi-free.  You could download it for your name and
address.  But I believe I'm not legally able to forward it to you and
the official site seems to be down.  Most of the information can also
be found here:
http://www.win.tue.nl/~aeb/linux/smartmedia/SmartMedia_Format.pdf
And there seems to be a copy available at pudn:
http://en.pudn.com/downloads137/doc/fileformat/detail585996_en.html

> I don't know the format of the CIS, and I know that special command is
> used to query the ID.
> CIS these days isn't used for anything and I hoped not to touch that
> thing.

:)

> I wont argue on that one with you, but why not to add the new field.
> It is quite generic, it could be card vendor information or so?
> Few bits of custom information to assign for each card no?
> 
> 
> I am taking about these:
> 
> struct xd_card_id1 {
> unsigned char maker_code;
> unsigned char device_code;
> unsigned char option_code1;
> unsigned char option_code2;
> } __attribute__((packed));
> 
> struct xd_card_id2 {
> unsigned char characteristics_code;
> #define XD_CARD_CELL_TYPE_MASK   0xc0
> #define XD_CARD_MULTI_BLOCK_MASK 0x30
> 
> unsigned char vendor_code1;
> unsigned char size_code;
> unsigned char vendor_code2;
> unsigned char vendor_code3;
> } __attribute__((packed));
> 
> struct xd_card_id3 {
> unsigned char vendor_code1;
> unsigned char vendor_code2;
> unsigned char id_code;
> unsigned char vendor_code3;
> } __attribute__((packed));
> 
> 
> Are these 32 bit values copied from CIF?
> 
> These values are read using commands:
> 
> XD_CARD_CMD_ID1         = 0x90,
> XD_CARD_CMD_ID2         = 0x91,
> XD_CARD_CMD_ID3         = 0x9a
> 
> 
> I need especially the xd_card_id1.device_code because this specifies the
> media type, but xd_card_id3.id_code is used to detemine if media is
> smartmedia or XD.

If you add this information to a struct xD_card and have mtd->priv point
to said structure, wouldn't that be enough for your purposes?

Jörn

-- 
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories

  reply	other threads:[~2009-11-26  8:27 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-21  0:25 XD/smartmedia - how to implement it right? Maxim Levitsky
2009-11-21 10:25 ` Jörn Engel
2009-11-22 12:58   ` Maxim Levitsky
2009-11-24 23:50     ` Plan for adding XD support in mtd layer Maxim Levitsky
2009-11-25 10:40       ` Jörn Engel
2009-11-25 13:20         ` Maxim Levitsky
2009-11-25 15:34           ` Jörn Engel
2009-11-25 16:17             ` Maxim Levitsky
2009-11-25 20:59               ` Jörn Engel
2009-11-25 23:22                 ` Maxim Levitsky
2009-11-26  8:27                   ` Jörn Engel [this message]
2009-11-26 13:02                     ` Maxim Levitsky
2009-11-26 13:42                       ` Jörn Engel
2009-11-26 21:38                         ` Maxim Levitsky
2009-11-28  7:22   ` XD/smartmedia - how to implement it right? Alex Dubov
2009-11-28 10:36     ` Maxim Levitsky
2009-11-30 12:35       ` Alex Dubov
2009-11-30 13:58         ` Maxim Levitsky
2009-11-30 23:04           ` Maxim Levitsky
2009-12-01  8:22             ` Jörn Engel
2009-12-01 16:10               ` Alex Dubov
2009-12-01 16:41                 ` Maxim Levitsky
2009-12-11 23:48               ` Maxim Levitsky
2009-12-05 19:09           ` Pavel Machek
2009-12-06 21:27             ` Maxim Levitsky
2009-12-07 15:13               ` Arnd Bergmann

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=20091126082715.GG10944@logfs.org \
    --to=joern@logfs.org \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    --cc=oakad@yahoo.com \
    --cc=tglx@linutronix.de \
    /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.