2.4 stuff.

OK, I've just merged the inter_module_xxx changes from 2.4 as I said I was going to do last week - yes it took me over a week to do it because I got distracted and fixed PCMCIA in 2.4 instead.

This will break the build on 2.2 if you don't have Keith's inter_module_xxx patch applied. But you had to apply a patch anyway to make put_module_symbol() work. Hopefully, it'll end up in 2.2.1[89] and we'll all be happy.

2.2.17 and above also contain the new module_init() code so I've (at least partially) carried out my threat to stop maintaining the initcalls. If you care, fix it. If you care and don't have CVS write access, send me a SSH public key.

Note that a handful of drivers now ought to put the module_init() version inside #if LINUX_VERSION_CODE >= 0x20211 instead of 0x20300

My current plan is to give Linus a selective update of the MTD code some time early in the 2.4 series. In it, I'm intending to include:
- mtdpart stuff
- New mtdblock
- New NFTL
- New DiskOnChip driver, _preferably_ with DOC_SINGLE_DRIVER
- API changes - set_vpp() and anything else that's momentarily slipped my notoriously vague attention.
- Any new map drivers which are appropriate - probably the SA1100 one.
- New CFI code iff it actually works next time I try it on my boards :)

Speak up if there's something missing which you think ought to be included, or alternatively if there's something in there which you think I ought to omit.

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

IMHO this is a must. Since I'm probably the one who made it break for your board please don't hesitate to bother me with that so we could fix it.

Nicolas

To unsubscribe, send "unsubscribe mtd" to [email protected]

OK, I've tested v1.46 on the same board with non-interleaved 16-bit flash where it previously failed. It now appears to work.

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

[email protected] said (Re CFI code):

OK, I've just given Linus a fairly large update for 2.4.0-test12. It's at ftp.uk.linux.org:/pub/people/dwmw2/forlinus/mtd-patch-whole

It's got everything in it that I said I was going to send except

1. New CFI code. That's not because I'm intending to leave the CFI code out, but before I do it, because I wanted to let the discussion about block write sizes settle, and test the AMD command set code on the new toy that landed on my desk on Friday.

2. New map drivers. I haven't decided which ones to add yet, if any.

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

I think the block write discussion has settled on the current code.

Nicolas

To unsubscribe, send "unsubscribe mtd" to [email protected]

Cool. I'll get the AMD code up and running on the new toy on my desk and send it off to Linus then.

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]

I just looked at the cfi_cmdset_0002.c code. This will goof on big endian as far as I can see. A major cleanup, like what happened for cfi_cmdset_0001.c, would be welcome there as well.

First, those functions could be cleaned out:

amd_send_cmd_at()
-----------------
- referenced only once;
- it applies cpu_to_le() on values which have already been correctly converted in cfi_build_cmd()... oops!;
- it should use cfi_write() instead of the current switch(map->buswidth) {...};
- probably diserve to be killed anyway.

amd_write_val()
---------------
- cfi_write() already does the same.

amd_read_val()
--------------
- cfi-read() already does the same.

Next, cfi_amdstd_write_byte_16() and cfi_amdstd_write_bytes_32() could greatly benefit from being generalized i.e. merged together and even folded into cfi_amdstd_write(). The code in cfi-cmdset-001.c should be a great example for that. It also removes all the #ifdef noise while still preserving the ability for the compiler to optimize away the unused code when a specific bus geometry is selected. In addition, such code as

	tmp = map->read32(map, ofs);
	tmp = be32_to_cpu(tmp);
	memcpy((u_char *)&tmp, buf, len);
	tmp = cpu_to_be32(tmp);

or ...

	tmp = map->read32(map, ofs - 1);
	tmp = (be32_to_cpu(tmp) & 0xFF000000) | buf[2] | (buf[1]  << 8) | buf[0] << 16;
	tmp = cpu_to_be32(tmp);

looks quite awful and suspicious to me.

Next, all calls to udelay() should be combined with a test on current->need_resched and call schedule() instead of udelay() when true. Otherwise kiss goodbye to your system's low latency when writes occur.

The last observation is the difference between cmdset-0001 and cmdset-002 for the state in which the task is put while waiting for the chip. For cmdset-001 the task is set to TASK_UNINTERRUPTIBLE for some reasons which are surely valuable for cmdset-002 as well.

So enough criticism for now. I would have been happy to clean this up myself, however I don't have any toys with AMD flash in it so couldn't test the changes at all which lower my motivation to do such work...

Nicolas

To unsubscribe, send "unsubscribe mtd" to [email protected]

I've made some minor local changes so that both cfi_cmdset_0002.c and
cfi_probe.c work for my big endian, 4 byte AMD flash board. I can carry it further
by making it more like cfi_cmdset_0001.c if you need a volunteer and don't need it by tomorrow :-)

Alice

To unsubscribe, send "unsubscribe mtd" to [email protected]

Thanks, that'll be useful. I'll be looking at it soon, but I haven't managed to get this board to respond to the CFI probe yet, so I'm not sure when I'll get to do it. Hopefully soon.

--
dwmw2

To unsubscribe, send "unsubscribe mtd" to [email protected]