All of lore.kernel.org
 help / color / mirror / Atom feed
* Additional arguments to <struct nand_chip.hwcontrol> and .dev_ready functions
@ 2003-07-11 14:49 Juergen Beisert
  2003-07-11 15:13 ` David Woodhouse
  0 siblings, 1 reply; 3+ messages in thread
From: Juergen Beisert @ 2003-07-11 14:49 UTC (permalink / raw)
  To: linux-mtd

Hello all,

I have written a driver for my NAND flash chip application using the mtd 
framework. It works fine when there is only one chip in one memory area 
present.
But if there are more than one NAND chip, you need more than one function for
    struct nand_chip.hwcontrol,
because this function don't know which chips control lines it should change.
Same with
    struct nand_chip.dev_ready.
For which chip it should wait?

Is it possible to add arguments, like a pointer to the struct nand_chip, to 
these functions? Then one of this function could handle more than one chip.

--JB

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Additional arguments to <struct nand_chip.hwcontrol> and .dev_ready functions
  2003-07-11 14:49 Additional arguments to <struct nand_chip.hwcontrol> and .dev_ready functions Juergen Beisert
@ 2003-07-11 15:13 ` David Woodhouse
  2003-07-11 15:47   ` Juergen Beisert
  0 siblings, 1 reply; 3+ messages in thread
From: David Woodhouse @ 2003-07-11 15:13 UTC (permalink / raw)
  To: jbeisert; +Cc: linux-mtd

On Fri, 2003-07-11 at 15:49, Juergen Beisert wrote:
> Hello all,
> 
> I have written a driver for my NAND flash chip application using the mtd 
> framework. It works fine when there is only one chip in one memory area 
> present.
> But if there are more than one NAND chip, you need more than one function for
>     struct nand_chip.hwcontrol,
> because this function don't know which chips control lines it should change.
> Same with
>     struct nand_chip.dev_ready.
> For which chip it should wait?
> 
> Is it possible to add arguments, like a pointer to the struct nand_chip, to 
> these functions? Then one of this function could handle more than one chip.

I've done some work on this in CVS in the last few days. 

For the case where you have two entirely separate NAND flash chips it's
simple enough -- all these functions now take a 'struct mtd_info *'
argument which is sufficient. See the new DiskOnChip driver for an
example of how it works. You can then use mtdconcat to combine two
entirely separate devices into a single logical MTD device, if you want.

In addition to that, I'm working on fixing the generic NAND code to
handle multiple identical chips connected up together, in what seems to
be the most common arrangement where you _share_ the hwcontrol lines but
individually assert each chip's CE line. 

I've done this by adding a chip-number argument to the select_chip()
function. Your board driver can store this chip number if appropriate,
so that in hwcontrol() or dev_ready() it can ensure it's talking to the
correct chip.

So far, nand_scan() takes an extra argument to tell it the maximum
number of chips to attempt to probe, and I have it finding all 9 chips
on my 144MiB DiskOnChip 2000. I've just committed that and I'm now going
through the actual access functions making them select the correct chip
according to the address, etc.

-- 
dwmw2

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Additional arguments to <struct nand_chip.hwcontrol> and .dev_ready functions
  2003-07-11 15:13 ` David Woodhouse
@ 2003-07-11 15:47   ` Juergen Beisert
  0 siblings, 0 replies; 3+ messages in thread
From: Juergen Beisert @ 2003-07-11 15:47 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-mtd

Am Freitag, 11. Juli 2003 17:13 schrieben Sie:
> I've done some work on this in CVS in the last few days.

Very good. Thank you. I have co'ed the tree.

--JB

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-07-11 15:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-11 14:49 Additional arguments to <struct nand_chip.hwcontrol> and .dev_ready functions Juergen Beisert
2003-07-11 15:13 ` David Woodhouse
2003-07-11 15:47   ` Juergen Beisert

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.