mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: "Jörn Engel" <joern@logfs.org>
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 15:02:54 +0200	[thread overview]
Message-ID: <1259240574.19687.42.camel@maxim-laptop> (raw)
In-Reply-To: <20091126082715.GG10944@logfs.org>

On Thu, 2009-11-26 at 09:27 +0100, Jörn Engel wrote: 
> 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
This one I have, and there is a brief description of the CIS format,
which seems to indicate that its contents are predefined.

> 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?

I am afraid not.


My plan is to create one 'meta' mtd driver for all XD controllers, and
plug in small drivers.

The meta driver and small driver will share the ->priv structure.

I need a way to pass the ID from mtd driver to FTL, and to userspace via
mtdchar.


Best regards,
Maxim Levitsky


  reply	other threads:[~2009-11-26 13:02 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
2009-11-26 13:02                     ` Maxim Levitsky [this message]
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=1259240574.19687.42.camel@maxim-laptop \
    --to=maximlevitsky@gmail.com \
    --cc=arnd@arndb.de \
    --cc=joern@logfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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®