linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Mike Dunn <mikedunn@newsguy.com>
To: Marek Vasut <marek.vasut@gmail.com>
Cc: linux-mtd@lists.infradead.org, Robert Jarzmik <robert.jarzmik@free.fr>
Subject: Re: [PATCH] Add driver for M-sys / Sandisk diskonchip G4 nand flash
Date: Wed, 12 Oct 2011 19:25:51 -0700	[thread overview]
Message-ID: <4E964C2F.9040608@newsguy.com> (raw)
In-Reply-To: <201110130226.38567.marek.vasut@gmail.com>

On 10/12/2011 05:26 PM, Marek Vasut wrote:
> On Wednesday, October 12, 2011 11:28:34 PM Robert Jarzmik wrote:
>> Mike Dunn <mikedunn@newsguy.com> writes:
>>> This is a driver for the diskonchip G4 in my Palm Treo680.  I've tested
>>> it fairly well; it passes the nandtest utility, and I've been able to
>>> create a ubifs using it.
> Hi Robert,
> I had a look at your driver, to see how close it was to the docg3 I
>>
>>  - docg4 doesn't need to write to an "address register" before reading some
>>  random register (ie. between io+0x1000 and io+0x1800), docg3 needs it
> This can be done on both ...

Is that right?  I haven't tried writing it on the G4.  The TrueFFS library never
writes it on the G4, so I didn't.  I called it the "read-enable" register on the
P3.  "Address register" is probably more accurate.

> See above ... you can determine if it's G3 or G4 by version register iirc ?

Correct.  They both have ID registers.
>>  - some read/write sequences are different, with different registers, and
>> with additionnal reads in your case (ie. the MYSTERY register for
>> example).
> This can be done on G3 too?

Sequences are very different.  And G4 has quirks like registers that have to be
written twice in succession with the same value.  And the number of nops between
reads may be important.

>
> Definitelly looking forward to this too. I can try on PalmT5 if you like, it 
> SHOULD have a G3.

According to the link to the old hh.org page you sent me, it does.

As far as combining drivers goes, basically all the low-level stuff will be
different.  There would have to be separate functions for the register
interactions; e.g., what I called read_page_prologue() and Robert called
read_page_prepare().  What could (and probably should) be similiar is the
integration with the mtd nand infrastructure code.  This is messy, due to the
fact that all the DOC devices have a proprietary controller that does not
comport to the standard nand commands that the mtd code expects.  That may be a
good reason to try to combine them.  My feeling is that we should develop in
tandem, and strive to converge structurally.  Then we can maybe take a look at
combining if it makes sense.  Right now we're at different points of
development, with original work done in isolation, and I think we'd only be
getting in each others' way and confusing things.

Mike

  reply	other threads:[~2011-10-13  2:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-10 14:48 [PATCH] Add driver for M-sys / Sandisk diskonchip G4 nand flash Mike Dunn
2011-10-10 15:51 ` Marek Vasut
2011-10-10 18:12   ` Ivan Djelic
2011-10-10 21:02     ` Mike Dunn
2011-10-11 11:50       ` Ivan Djelic
2011-10-11 19:17         ` Mike Dunn
2011-10-12 18:49           ` Ivan Djelic
2011-10-13  1:18             ` Mike Dunn
2011-10-13  6:58             ` Robert Jarzmik
2011-10-13  8:37               ` Ivan Djelic
2011-10-13 15:52                 ` Mike Dunn
2011-10-10 20:20   ` Mike Dunn
2011-10-12 21:28 ` Robert Jarzmik
2011-10-13  0:26   ` Marek Vasut
2011-10-13  2:25     ` Mike Dunn [this message]
2011-10-13  1:53   ` Mike Dunn
2011-10-17 21:45   ` Mike Dunn
2011-10-20 16:31     ` Artem Bityutskiy
2011-10-20 19:57       ` Mike Dunn

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=4E964C2F.9040608@newsguy.com \
    --to=mikedunn@newsguy.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=robert.jarzmik@free.fr \
    /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;
as well as URLs for NNTP newsgroup(s).