New driver

New driver

[Pixel]

Hello!

I've just joined this mailing-list so forgive-me if I do some mistakes.

I've done a little add-on to the linux kernel source in order to build
directly the driver for the em8300 chip. This chip is the main chip
of the DXR3 and Hollywood Plus mpeg decompression cards. Since now, the
source of this driver was an external source tree and it builded four
modules that drives the cards. But since the major update of the
2.4.0's Makefiles, it wasn't able to compile up.

As I really wanted to use both of them, I tried my best to make it
working and it cames into a patch against the linux-2.4.0-test13-pre4
kernel.

It adds a new section into the configuration tree in order to support
the mpeg decompression cards. And so it builds correctly this driver.

I wanted to share what I've done but since I'm very new to kernel hacking
I don't know what to do with my patch. Could you give me some hints?

Thanks!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: New driver

[Keith Owens]

On Thu, 28 Dec 2000 22:19:37 +0100 (CET), 
Pixel@the-truth.nobis.phear.org wrote:
>I wanted to share what I've done but since I'm very new to kernel hacking
>I don't know what to do with my patch. Could you give me some hints?

linux/Documentation/SubmittingPatches

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: New driver

[Pixel]

> 
> On Thu, 28 Dec 2000 22:19:37 +0100 (CET), 
> Pixel@the-truth.nobis.phear.org wrote:
> >I wanted to share what I've done but since I'm very new to kernel hacking
> >I don't know what to do with my patch. Could you give me some hints?
> 
> linux/Documentation/SubmittingPatches
> 

Ok. Since it's a new category, there's no maintainers for it. I'll post the patch here. 

And since it's quite a bit patch (about 120Kb) you can download the plain text patch at
this URL: http://www.ifrance.com/nobis/em8300-patch.

This patch is against the linux-2.4.0-test13-pre5 source tree.

Description: this is the integration of the em8300 driver available at
 http://dxr3.sourceforge.net

The primary driver is only an external source driver. So I decided to try to build it
directly into the kernel source tree (there was incompatibilities with the new
Makefile system) and to add a devfs support for the devices. As it is a new category,
I've added a submenu to the configuration system: MPEG cards into the Multimedia
section. Please note I didn't wrote this driver but simply integrated an existing
driver.

  -- Nicolas Noble

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: New driver

[Paul Davis]

>What is the "official" procedure to integrate  my driver ?

my approach has always been:

   cd $TOP_OF_ALSA_TREE
   find . -type f | xargs grep SOME_OTHER_CARD_NAME

where SOME_OTHER_CARD_NAME is picked from a suitable existing driver.
this lets me see all the places i have to refer to it.

but there must be a better way :)



-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

New driver

[mjander]

Hi,

I started writing a new driver for the Aureal Vortex soundcards.
Now the howto is pretty  good, and the  basic stuff is nearly
complete, but
how do i integrate  my driver into the configure scripts,
Makefiles, and
all sorts of  thingiees that  makee up the tree ?
I placed the driver (several files) into  the directory
"pci/vortex". I  managed to get the configure script to recognice
the "vortex" card fiddling in the  acinclude.m4  file,  but  when
i  do "make" it doesnt compile  the  files in "/pci/vortex". This
directory has a  apropiate makefile  (i  took the one  of the
emu10k1 an d modiifyed it).

What is the "official" procedure to integrate  my driver ?

Thanks.

Manuel Jander
.
__________________________________________________
Enviado via NewPlanet WebMail en embedded.cl


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: New driver

[Takashi Iwai]

Hi,

At Tue,  4 Mar 2003 19:35:35 -0400,
mjander wrote:
> 
> Hi,
> 
> I started writing a new driver for the Aureal Vortex soundcards.

wow, how did you get hardware information?

> Now the howto is pretty  good, and the  basic stuff is nearly
> complete, but
> how do i integrate  my driver into the configure scripts,
> Makefiles, and
> all sorts of  thingiees that  makee up the tree ?
> 
> I placed the driver (several files) into  the directory
> "pci/vortex". I  managed to get the configure script to recognice
> the "vortex" card fiddling in the  acinclude.m4  file,  but  when
> i  do "make" it doesnt compile  the  files in "/pci/vortex". This
> directory has a  apropiate makefile  (i  took the one  of the
> emu10k1 an d modiifyed it).
> 
> What is the "official" procedure to integrate  my driver ?

ah, that's not on the howto yet :)

first, the test drivers should be put into alsa-driver tree.  they
will be brought up to alsa-kernel tree eventually and submitted to
linux 2.5 kernel later.

in your case, alsa-driver/pci/vx222 or alsa-driver/pci/pdplus would be
a good example. 
add the vortex directory to extra-subdir-y in alsa-driver/pci/Makefile:

extra-subdir-y	:= pdplus vx222 vortex

create a new Makefile in alsa-driver/pci/vortex (see vx222 or pdplus
Makefile).

add the definition to alsa-driver/utils/Modules.dep like below:

%dir linux/sound/pci/vortex
|snd-vortex snd-pcm ...

where the second and later arguments are dependent lowlevel modules.

and also define the necessary dependency in
alsa-driver/acore/Makefile or whererever the dependent lowlevel
modules exist.

finally, run ./cvscompile to regenerate the configure script, etc.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

new driver

[Ken Schneider]

I have been sent the sources for the LSI LOGIC, Inc. Ultra ATA100 IDE raid 
controller as found on the mainboard of the HP ML330 computer. I requested 
information concerning the inclusion of the code into the kernel tree and 
have been informed that the source is open and can be included as stated in 
all of the .c and .h files.
Example:

/*
 * Linux MegaRAID IDEal Software RAID Stack
 * Copyright (c) 2003 LSI Logic Corporation
 *-----------------------------------------------------------------------------
 *
 *  This program is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation; either version 2 of the License, or
 *  (at your option) any later version.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program; if not, write to the Free Software
 *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 *
 *-----------------------------------------------------------------------------
 */

Having this code included will make the life of many people much easier in 
being able to use the raid function of the controller.

I have been able (with the help of people on the SuSE mailing list) to get the 
module compiled for the 2.4 kernel. As the 2.6 tree and compilation 
procedures have changed I can no longer get the module to compile, I am not a 
programmer as I know just enough about C to be dangerous.

Copies of the correspondence and the sources are available either from me or 
tech support at LSI Logic Corp. 

Any help in this matter would be appreciated. I am also willing to be a guinea 
pig for any testing of the module.

Ken Schneider

kschneider@bout-tyme.net

Re: new driver

[Christoph Hellwig]

On Sat, Feb 14, 2004 at 07:06:12PM -0500, Ken Schneider wrote:
> I have been sent the sources for the LSI LOGIC, Inc. Ultra ATA100 IDE raid 
> controller as found on the mainboard of the HP ML330 computer. I requested 
> information concerning the inclusion of the code into the kernel tree and 
> have been informed that the source is open and can be included as stated in 
> all of the .c and .h files.

We're generally not including software raid as LLDD.  We'd be interested in
both drivers for the underlying ide controller (if not yet support by linux)
and a tool to setup the tables for device mapper.

btw, where is the source for the driver you're talking about?

Re: new driver

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

On Sun, 2004-02-15 at 10:29, Christoph Hellwig wrote:
> On Sat, Feb 14, 2004 at 07:06:12PM -0500, Ken Schneider wrote:
> > I have been sent the sources for the LSI LOGIC, Inc. Ultra ATA100 IDE raid 
> > controller as found on the mainboard of the HP ML330 computer. I requested 
> > information concerning the inclusion of the code into the kernel tree and 
> > have been informed that the source is open and can be included as stated in 
> > all of the .c and .h files.
> 
> We're generally not including software raid as LLDD.  We'd be interested in
> both drivers for the underlying ide controller (if not yet support by linux)
> and a tool to setup the tables for device mapper.

and for 2.4 as ataraid driver; writing one is like a few hours of work
at most so do send a pointer to the source :)



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new driver

[Jeff Garzik]

Ken Schneider wrote:
> I have been sent the sources for the LSI LOGIC, Inc. Ultra ATA100 IDE raid 
> controller as found on the mainboard of the HP ML330 computer. I requested 
> information concerning the inclusion of the code into the kernel tree and 
> have been informed that the source is open and can be included as stated in 
> all of the .c and .h files.


Just to echo the others...

You need to add two drivers:

1) low-level hardware driver for this LSI hardware
2) software RAID driver

They are distinct and separate, when you're talking about software RAID.

Regards,

	Jeff (SATA maintainer)

RE: new driver

[Tomita, Haruo]

Dear Eric,

Eric wrote;

Eric> There was an effort I started to open source some of
Eric> the driver, which was linked to a pre-compiled library. 

The pre-compiled library(megaide_lib.o) is included. 
The object of the megaide driver is created by linking this library.
I believe that the source of the exhibited portion is
a portion except the algorithm of RAID.
These are efforts and the results of Atul and Manoj.

However, since the library of binary distribution is included,
I think that the kernel version which operates will be limited.
If there is the solution method of this problem,
please let me know.

-- Haruo

Re: new driver

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]


On Wed, Feb 18, 2004 at 05:51:17PM +0900, Tomita, Haruo wrote:
> Dear Eric,
> 
> Eric wrote;
> 
> Eric> There was an effort I started to open source some of
> Eric> the driver, which was linked to a pre-compiled library. 
> 
> The pre-compiled library(megaide_lib.o) is included. 

Then the driver is not available under the terms of the GPL.... 
(and not compatible with the kernel license so inclusion is not possible)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: new driver

[Ken Schneider]

On Wed, 2004-02-18 at 07:29, Arjan van de Ven wrote:
> On Wed, Feb 18, 2004 at 05:51:17PM +0900, Tomita, Haruo wrote:
> > Dear Eric,
> > 
> > Eric wrote;
> > 
> > Eric> There was an effort I started to open source some of
> > Eric> the driver, which was linked to a pre-compiled library. 
> > 
> > The pre-compiled library(megaide_lib.o) is included. 
> 
> Then the driver is not available under the terms of the GPL.... 
> (and not compatible with the kernel license so inclusion is not possible)

And therefore should not any reference to the GPL in the other files. I
think this should be all or nothing.

-- 
Ken Schneider <kschneider@bout-tyme.net>

RE: new driver

[Tomita, Haruo]

Hi ken,

Eric> There was an effort I started to open source some of
Eric> the driver, which was linked to a pre-compiled library. 

Haruo> The pre-compiled library(megaide_lib.o) is included. 

Arjan> Then the driver is not available under the terms of the GPL.... 
Arjan> (and not compatible with the kernel license so inclusion is not possible)
 
Ken> And therefore should not any reference to the GPL in the 
Ken> other files. I think this should be all or nothing.

Is it that the source code of megaide_lib.o should be opened?

-- 
Haruo

RE: new driver

[Ken Schneider]

On Wed, 2004-02-18 at 18:39, Tomita, Haruo wrote:
> Hi ken,
> 
> Eric> There was an effort I started to open source some of
> Eric> the driver, which was linked to a pre-compiled library. 
> 
> Haruo> The pre-compiled library(megaide_lib.o) is included. 
> 
> Arjan> Then the driver is not available under the terms of the GPL.... 
> Arjan> (and not compatible with the kernel license so inclusion is not possible)
>  
> Ken> And therefore should not any reference to the GPL in the 
> Ken> other files. I think this should be all or nothing.
> 
> Is it that the source code of megaide_lib.o should be opened?

I was told by people on another list that if any part is closed the
entire package will not be included in the kernel tree. So yes
negaide.lib.o should be open sourced or LSI should provide drivers to
linux users as well as any other platform that uses their hardware.

-- 
Ken Schneider <kschneider@bout-tyme.net>

RE: new driver

[Doelfel, Hardy]

Hi Haruo,
the library will stay closed source. The header files are only meant to make
it easier to compile for different kernel versions.

Thanks
	Hardy

-----Original Message-----
From: Tomita, Haruo [mailto:haruo.tomita@toshiba.co.jp]
Sent: Wednesday, February 18, 2004 6:40 PM
To: Ken Schneider; Arjan van de Ven
Cc: Moore, Eric Dean; linux-scsi@vger.kernel.org; Doelfel, Hardy; Mukker,
Atul; Jarrett, Peter B.
Subject: RE: new driver


Hi ken,

Eric> There was an effort I started to open source some of
Eric> the driver, which was linked to a pre-compiled library. 

Haruo> The pre-compiled library(megaide_lib.o) is included. 

Arjan> Then the driver is not available under the terms of the GPL.... 
Arjan> (and not compatible with the kernel license so inclusion is not
possible)
 
Ken> And therefore should not any reference to the GPL in the 
Ken> other files. I think this should be all or nothing.

Is it that the source code of megaide_lib.o should be opened?

-- 
Haruo

Re: new driver

[Jeff Garzik]

Ken Schneider wrote:
> On Wed, 2004-02-18 at 18:39, Tomita, Haruo wrote:
> 
>>Hi ken,
>>
>>Eric> There was an effort I started to open source some of
>>Eric> the driver, which was linked to a pre-compiled library. 
>>
>>Haruo> The pre-compiled library(megaide_lib.o) is included. 
>>
>>Arjan> Then the driver is not available under the terms of the GPL.... 
>>Arjan> (and not compatible with the kernel license so inclusion is not possible)
>> 
>>Ken> And therefore should not any reference to the GPL in the 
>>Ken> other files. I think this should be all or nothing.
>>
>>Is it that the source code of megaide_lib.o should be opened?
> 
> 
> I was told by people on another list that if any part is closed the
> entire package will not be included in the kernel tree. So yes
> negaide.lib.o should be open sourced or LSI should provide drivers to
> linux users as well as any other platform that uses their hardware.


Correct.  Drivers must be 100% open source, or they are not included in 
Linux.

This is dictated by the GNU General Public License, under which all 
kernel code is licensed.

	Jeff

New driver

[Ian Molton]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

Hi.

Here is my first run at the TC6393XB NAND/Smartmedia controller driver.

Currently the chip init is nonexistant - its done by wince on my board and I have no way of booting without wince on it yet, so I have no plan to implement it until I can test it (this will be soon, probably).

Hardware ECC seems to be broken. the code is present but disabled, for educational purposes.

this driver requires the read_id override patch (which I will post shortly).

[-- Attachment #2: nand_tmio.c --]
[-- Type: application/octet-stream, Size: 10482 bytes --]

/*
 *  drivers/mtd/nand/nand_tmio.c
 *
 * (c) Ian Molton and Sebastian Carlier
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 *
 * This is a driver for the NAND flash controller on the TMIO
 * (Toshiba Multio IO Controller) as found in the toshiba e750 and e800 PDAs.
 *
 * This Driver should support the TC6393XB SoC 'smartmedia' controller.
 *
 * This is alpha quality. This chip did not mesh well with the linux
 * NAND flash base code as it has some funny requirements as to when you can
 * write bytes to the data register (eg. you need to write the address as a
 * 32 bit word).
 *
 * I have used the default mtd NAND read byte and write byte functions since
 * the few places they are used seem to be OK with this. The exception was the
 * read_id code, which had to be split off as an ovverideable function thanks
 * to his chip requiring a word (32bit) read, not two byte accesses, doh!)
 *
 * This chip has a hard ECC unit, but this appears to be buggy, at least for
 * reads. This may be solved by reading halfwords, but thats a hunch I havent
 * tried yet.
 *
 * Oh, also - this code assumes all buffers are a multiple of 4 bytes (1 word)
 * long (due to the use of word read/writes in {read,write,verify}_buf).
 *
 *                                          -Ian Molton <spyro@f2s.com>
 *  Revision history:
 *    23/08/2004     First working version
 * 
 *  TO DO list
 *    Do full chip initialisation (rather than rely on winCE)
 *    Fix hwECC if poss.
 *    Make use of chip 'ready' interrupt.
 *
 */

#include <linux/delay.h>
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/nand_ecc.h>
#include <linux/mtd/partitions.h>
#include <asm/io.h>
#include <asm/sizes.h>

/*
 * MTD structure for TMIO nand controller
 */
static struct mtd_info *tmio_mtd = NULL;

#define TMIO_MODE_REG      0x04  //offset from data reg

#define TMIO_MODE_CLE      0x01
#define TMIO_MODE_ALE      0x02
#define TMIO_MODE_PCNTL    0x04   // Power control
#define TMIO_MODE_LED      0x08   // Optional LED control
#define TMIO_MODE_CE       0x10
#define TMIO_MODE_ECC0     0x20   // ECC control regs.
#define TMIO_MODE_ECC1     0x40   // ...
#define TMIO_MODE_WP       0x80

#define TMIO_STATUS_REG    0x05  // offset from data reg

#define TMIO_STATUS_WPD    0x01    // Write protect seal detected
#define TMIO_STATUS_EJREQ  0x02    // Card Eject Request
#define TMIO_STATUS_CENB   0x04    // Card Enable
#define TMIO_STATUS_STCHG  0x08    // Card Status Change
#define TMIO_STATUS_PWON   0x10    // SmartMedia Power On
#define TMIO_STATUS_MODEL  0x40    // Smartmedia voltage (1 = 5.0 0 = 3.3V)
#define TMIO_STATUS_BUSY   0x80    // High when busy

/* 
 *	hardware specific access to control-lines
 */

static void tmio_read_id(struct mtd_info *mtd, int *maf_id, int *dev_id) {
	struct nand_chip *this = mtd->priv;
	unsigned long id;

	/* Send the command for reading device ID */
	this->cmdfunc (mtd, NAND_CMD_READID, 0x00, -1);

	id = readl(this->IO_ADDR_R);
	*maf_id = id & 0xff;
	*dev_id = (id >> 8) & 0xff;
}

static void tmio_read_buf(struct mtd_info *mtd, u_char *buf, int len)
{
	struct nand_chip *this = mtd->priv;
	u32 *p = (u32*)buf;
	int i;

	if(len & 0x3)
		BUG();

	len >>= 2;

	for (i=0; i < len; i++)
		p[i] = readl(this->IO_ADDR_R);
}

static void tmio_write_buf(struct mtd_info *mtd, const u_char *buf, int len)
{
	struct nand_chip *this = mtd->priv;
	u32 *p = (u32*)buf;
	int i;

	if(len & 0x3)
		BUG();

	len >>= 2;

	for (i=0; i < len; i++)
		writel(p[i], this->IO_ADDR_W);
}

static int tmio_verify_buf(struct mtd_info *mtd, const u_char *buf, int len)
{
	struct nand_chip *this = mtd->priv;
	u32 *p = (u32*)buf;
	int i;

	if(len & 0x3)
		BUG();

	len >>= 2;

	for (i=0; i<len; i++)
		if (p[i] != readl(this->IO_ADDR_R))
			return -EFAULT;

	return 0;
}

static unsigned char stat;
#if 0
// HARDWARE ECC DOESNT WORK YET (hardware bug?)
static void tmio_enable_hwecc(struct mtd_info *mtd, int mode)
{
        struct nand_chip *this = mtd->priv;
	// Reset ECC
	writeb(stat | 0x60, this->IO_ADDR_W + TMIO_MODE_REG);
	readb(this->IO_ADDR_R);
	// Enable ECC
	writeb(stat | 0x20, this->IO_ADDR_W + TMIO_MODE_REG);
}

static int tmio_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
                                 unsigned char *ecc_code)
{
        struct nand_chip *this = mtd->priv;
	unsigned char data_1[4], data_2[4];

	//FIXME: not big-endian safe

	// Read ECC result
	writeb(stat | 0x40, this->IO_ADDR_W + TMIO_MODE_REG);
	*(u32*)data_1 = readl(this->IO_ADDR_R);
	*(u32*)data_2 = readl(this->IO_ADDR_R);
	// Disable ECC
	writeb(stat, this->IO_ADDR_W + TMIO_MODE_REG);
	ecc_code[0] = data_2[0];
	ecc_code[1] = data_1[3];
	ecc_code[2] = data_2[1];
	ecc_code[3] = data_1[1];
	ecc_code[4] = data_1[0];
	ecc_code[5] = data_1[2];
	return 0;
}
#endif

static void tmio_hwcontrol(struct mtd_info *mtd, int cmd) 
{
	struct nand_chip *this = mtd->priv;

	switch(cmd) {

		case NAND_CTL_SETCLE: stat |=  TMIO_MODE_CLE; break;
		case NAND_CTL_CLRCLE: stat &= ~TMIO_MODE_CLE; break;

		case NAND_CTL_SETALE: stat |=  TMIO_MODE_ALE; break;
		case NAND_CTL_CLRALE: stat &= ~TMIO_MODE_ALE; break;

		case NAND_CTL_SETNCE: stat |=  TMIO_MODE_CE; break;
		case NAND_CTL_CLRNCE: stat &= ~TMIO_MODE_CE; break;
	}

	writeb(stat, this->IO_ADDR_W + TMIO_MODE_REG);
}

// This is the main hack to the default drivers - this chip is funy in
// that the address must be written as a word, not three bytes writes.

static void tmio_command (struct mtd_info *mtd, unsigned command, int column, int page_addr)
{
	register struct nand_chip *this = mtd->priv;

	/* Begin command latch cycle */
	this->hwcontrol(mtd, NAND_CTL_SETCLE);
	/*
	 * Write out the command to the device.
	 */
	if (command == NAND_CMD_SEQIN) {
		int readcmd;

		if (column >= mtd->oobblock) {
			/* OOB area */
			column -= mtd->oobblock;
			readcmd = NAND_CMD_READOOB;
		} else if (column < 256) {
			/* First 256 bytes --> READ0 */
			readcmd = NAND_CMD_READ0;
		} else {
			column -= 256;
			readcmd = NAND_CMD_READ1;
		}
		writeb(readcmd, this->IO_ADDR_W);
	}
	writeb(command, this->IO_ADDR_W);

	/* Set ALE and clear CLE to start address cycle */
	this->hwcontrol(mtd, NAND_CTL_CLRCLE);

	if (column != -1 || page_addr != -1) {
		this->hwcontrol(mtd, NAND_CTL_SETALE);

		if (column != -1) {
			/* Adjust columns for 16 bit buswidth */
			writeb(column, this->IO_ADDR_W);
		}
		if (page_addr != -1)
			writel(page_addr & 0x00ffffff, this->IO_ADDR_W);

		/* Latch in address */
		this->hwcontrol(mtd, NAND_CTL_CLRALE);
	}

	/*
	 * program and erase have their own busy handlers
	 * status and sequential in needs no delay
	 */
	switch (command) {
		case NAND_CMD_PAGEPROG:
		case NAND_CMD_ERASE1:
		case NAND_CMD_ERASE2:
		case NAND_CMD_SEQIN:
		case NAND_CMD_STATUS:
			return;
	}

	/* Apply this short delay always to ensure that we do wait tWB in
	 * any case on any machine. */
	ndelay (100);
	/* wait until command is processed */
	while (!this->dev_ready(mtd));
}

/*
 *	read device ready pin
 */
static int tmio_device_ready(struct mtd_info *mtd)
{
	register struct nand_chip *this = mtd->priv;
	return (readb(this->IO_ADDR_R + TMIO_STATUS_REG) & TMIO_STATUS_BUSY) ? 0 : 1;
}

#ifdef CONFIG_MTD_PARTITIONS
// Nice and simple - one big partition.
static struct mtd_partition partition_a = {
	.name = "Internal NAND flash",
	.offset =  0,
	.size =  MTDPART_SIZ_FULL,
};
#endif

// WinCE uses this ECC layout (it uses SSFDC). lets play nice.
struct nand_oobinfo tmio_oobinfo  = {
	.eccpos = {14,13,15,9,8,10},
	.oobfree = {{0,4},{6,2},{11,2}},
	.eccbytes = 6,
	.useecc = MTD_NANDECC_AUTOPLACE,
};

/*
 * Main initialization routine
 */
static int __init tmio_init (void)
{
	struct nand_chip *this;
	int tmio_pbase=0x10000b00;  //FIXME - hardcoded for toshiba eseries PDAs
	int tmio_base;

	// Initial status - write enabled, power on.
	stat = TMIO_MODE_PCNTL | TMIO_MODE_WP;

	/* Allocate memory for MTD device structure and private data */
	tmio_mtd = kmalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip),
	                   GFP_KERNEL);
	if (!tmio_mtd)
		return -ENOMEM;

	/* map physical adress */
	//FIXME - map 0x100? is that the minimum?
	tmio_base = (unsigned long)ioremap(tmio_pbase, 0x100);
	if(!tmio_base) {
		kfree(tmio_mtd);
		return -EIO;
	}

	/* Get pointer to private data */
	this = (struct nand_chip *) (&tmio_mtd[1]);

	/* Initialize structures */
	memset((char *) tmio_mtd, 0, sizeof(struct mtd_info));
	memset((char *) this, 0, sizeof(struct nand_chip));

	/* Link the private data with the MTD structure */
	tmio_mtd->priv = this;

	/* insert callbacks */
	this->IO_ADDR_R  = tmio_base;
	this->IO_ADDR_W  = tmio_base;
	this->cmdfunc    = tmio_command;
	this->hwcontrol  = tmio_hwcontrol;
	this->dev_ready  = tmio_device_ready;
	this->read_id    = tmio_read_id;
	this->read_buf   = tmio_read_buf;
	this->write_buf  = tmio_write_buf;
	this->verify_buf = tmio_verify_buf;
	this->autooob    = &tmio_oobinfo;
	this->eccmode    = NAND_ECC_SOFT;
#if 0
	// HW ECC doesnt work (hardware bug?)
	this->enable_hwecc = tmio_enable_hwecc;
	this->calculate_ecc = tmio_calculate_ecc;
	this->correct_data = nand_correct_data;
	this->eccmode = NAND_ECC_HW6_512;
#endif

	/* Scan to find existence of the device */
	if (nand_scan (tmio_mtd, 1)) {
		iounmap((void *)tmio_base);
		kfree (tmio_mtd);
		return -ENXIO;
	}

	/* Allocate memory for internal data buffer */
	this->data_buf = kmalloc (sizeof(u_char) * (tmio_mtd->oobblock + tmio_mtd->oobsize), GFP_KERNEL);
	if (!this->data_buf) {
		iounmap((void *)tmio_base);
		kfree (tmio_mtd);
		return -ENOMEM;
	}

#ifdef CONFIG_MTD_PARTITIONS
	/* Register the partitions */
	add_mtd_partitions(tmio_mtd, &partition_a, 1);
#endif

	/* Return happy */
	return 0;
}

/*
 * Clean up routine
 */
static void __exit tmio_cleanup (void)
{
	struct nand_chip *this = (struct nand_chip *) &tmio_mtd[1];

	//FIXME - do we need to remove the partition?

	/* Unregister the device */
	del_mtd_device (tmio_mtd);

	/* Free internal data buffer */
	kfree (this->data_buf);

	/* Free the MTD device structure */
	kfree (tmio_mtd);
}

module_init(tmio_init);
module_exit(tmio_cleanup);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Ian Molton and Sebastian Carlier");
MODULE_DESCRIPTION("MTD map driver for TMIO NAND controller.");

Re: New driver

[Ian Molton]

On Tue, 24 Aug 2004 01:09:27 +0100
Ian Molton <spyro@f2s.com> wrote:

> Hi.
> 
> Here is my first run at the TC6393XB NAND/Smartmedia controller driver.

No comments ?

Re: New driver

[Josh Boyer]

On Thu, 2004-08-26 at 14:54, Ian Molton wrote:
> On Tue, 24 Aug 2004 01:09:27 +0100
> Ian Molton <spyro@f2s.com> wrote:
> 
> > Hi.
> > 
> > Here is my first run at the TC6393XB NAND/Smartmedia controller driver.
> 
> No comments ?

You forgot to iounmap in your tmio_cleanup function.

Also, you could put:

if(len & 0x3)
	BUG();

into a macro.  Later, if you can ever guarantee that will never be true,
you can just define the macro to be a no-op.  Just a coding style thing
though.

josh