public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Alice Hennessy <ahennessy@mvista.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: mtd@infradead.org, ahennessy@mvista.com
Subject: MTD support for 8x16 devices
Date: Tue, 29 Aug 2000 16:54:07 -0700	[thread overview]
Message-ID: <39AC4D1F.BFBEEA21@mvista.com> (raw)
In-Reply-To: 31647.965720843@cygnus.co.uk

Hi,

 I am using the MTD driver  to accomodate two different products,  one  with
an AMD
and one  with an Intel Strata.   Both are the 8x16 variety.   I have several
questions:

1. The Strata is placed on the board as a byte wide device so I've added
another check in cfi_probe_new_chip() to try accessing the cfi ident info at
address 0xaa as well as the 0x55  (for buswidth of 1) and return an
"cfi_ident_adjustment" so that cfi_cfi_probe can correctly access the cfi
ident info (since the cfi ident field InterfaceDesc hasn't been read yet).
Is this an acceptable method to handle this?

2.  I've added code to support  1_by_8 functions in cfi_cmdset_0001.c for the
strata.  I've also added big endian and unaligned support in
cfi_amdext_write_2_by_16().   I've also added some support to handle different
erase sector sizes within one chip.  Has any of this already been checked in
recently?  And what is the procedure?

3.  For both products, I have made use of  my own combo of physmap.c and
nora.c so that the flash address and len can be set in menuconfig and the
flash can be partitioned.    It seems that this version of physmap.c can be
used in a very generic way if we also move buswidth into menuconfig.   I'm
also thinking about different ways for the partition sizes to be set outside
of physmap.c.   - any opinions?   Perhaps board specifics should be contained
in a header file and
be set via menuconfig or command line or ?

4.   I need to implement a char device where the customer wants to write to
the flash and have all the erase details handle by the driver.  They want to
simply do a dd into the device.  They don't need a file system
implementation.   Has there been any thought about doing this type of thing at
the driver level?


Alice







To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

  parent reply	other threads:[~2000-08-29 23:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-07 19:48 get_module_symbol / put_module_symbol Sébastien Côté
2000-08-08  7:47 ` David Woodhouse
2000-08-08 12:50   ` Sébastien Côté
2000-08-29 23:54   ` Alice Hennessy [this message]
2000-08-30  1:02     ` MTD support for 8x16 devices Stéphane Laroche
2000-08-30  8:48     ` David Woodhouse
2000-09-01  1:05       ` Alice Hennessy
2000-09-04 13:16         ` David Woodhouse
2000-09-07 18:39           ` get_module_symbol Alice Hennessy
2000-09-08  7:34             ` get_module_symbol David Woodhouse

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=39AC4D1F.BFBEEA21@mvista.com \
    --to=ahennessy@mvista.com \
    --cc=dwmw2@infradead.org \
    --cc=mtd@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