> Andre,
>
> I Looked at the latest IDE preview, and have heavy reservations.
>
> We really should NOT have PCI chipset-tuning code in the kernel
> UNLESS it is required to boot Linux (very unlikely).
Okay, but the special case is Promise 20246 with multi-cards with
non-identical bios versions..........The Ultra33 is the current case
problem...........no-bios no auto-chipset tuning. The FastTrax may have
the same problems.......
The Aladdin needs a real kick in the butt to get it to work correctly.
The silly Simplex DMA flag that is bogus in almost all cases hurts.
VIA has the options of DMA FIFO sizing.............
If you have hard drives on ide0 and atapi devices on ide1, I would want to
maximize my throughput on ide0. The better case would be to match fifo
combinations against raw drive speeds to balance a system. Mixing
UDMA/DMA may need a nudge to get it right.
> Anything that is not required to boot, can probably be done
> much better after booting, by use of a user-mode program
> such as hdparm or a new "chipset-tuner" program.
In the short, I can agree.
In the long, I point back to the ALI and biosless Promise issues.
> The reasons for this are convincing:
>
> -- the kernel is in non-pageable memory,
> and therefore must be kept as small as possible
> (and Linus absolutely *hates* unnecessary bloat).
The location of all the new junk in 'ide-pci.c' may be wrong.
I am thinking of a new function to add to 'typedef struct ide_pci_device_s'
(int) (*chipset_init)(struct pci_dev *dev, const char *name)
This makes the chipset code self contained...........
> -- new chipsets are released every few months,
> whereas the kernel is released every few YEARS,
> so it is impossible for the kernel to keep up.
>
> -- a user-mode program can be much more clever
> and have a fancier user-interface than kernel stuff.
Great, but it would be tough to re-align fifo channels of the VIA after
boot.
> The idea of the present IDE driver design was to implement enough
> generic support (such as safe /proc/ide/*/config updates) functions
> to allow user-mode programs to be developed for PCI chipset tuning.
This great and has proven useful in development of chipset code.
> There is little need or justification for placing direct chipset
> tuning functions (for PCI) into the stock kernel. It just adds bloat
> and discourages development of better user-mode utilities.
I am coming to that conclusion also, but there is one case that I know of
that requires minor "bloat" but that is there already. The AEC6210/UF
chipset must be a sharing interrupt chipset......this is a boot must.
If undeclared hard lock-ups............
> I think the PCI chipset-tuning stuff belongs in a user-mode program.
> Older chipsets have some stuff in the kernel because they are harder
> to support in a generic fashion than the current PCI interfaces.
The VIA and ALI chipset really are handi-capped if not tuned, so in using
your own argument against the timing issue ::
I added "ide_special_settings" for that reason, but it needs to be moved
off to chipset code............
/*
* This allows offboard ide-pci cards the enable a BIOS, verify interrupt
* settings of split-mirror pci-config space, place chipset into init-mode,
* and/or preserve an interrupt if the card is not native ide support.
*/
__initfunc(static unsigned int ide_special_settings (struct pci_dev *dev,
const char *name))
case PCI_DEVICE_ID_AL_M5229:
if (pci_read_config_byte(dev, 0x50, &confreg1))
goto veryspecialsettingserror;
if (!(confreg1 & 0x02))
if (pci_write_config_byte(dev, 0x50, confreg1 | 0x02))
goto veryspecialsettingserror;
if (pci_read_config_byte(dev, PCI_CLASS_PROG, &progif))
goto veryspecialsettingserror;
if (!(progif & 0x40)) {
/*
* The way to enable them is to set progif
* writable at 0x4Dh register, and set bit 6
* of progif to 1:
*/
if (pci_read_config_byte(dev, 0x4d, &confreg0))
goto veryspecialsettingserror;
if (confreg0 & 0x80)
if (pci_write_config_byte(dev, 0x4d, confreg0 & ~0x80))
goto veryspecialsettingserror;
if (pci_write_config_byte(dev, PCI_CLASS_PROG, progif | 0x40))
goto veryspecialsettingserror;
if (confreg0 & 0x80)
if (pci_write_config_byte(dev, 0x4d, confreg0))
errors++;
}
if ((pci_read_config_byte(dev, PCI_CLASS_PROG, &progif)) || (!(progif & 0x40)))
goto veryspecialsettingserror;
All this is required to get the ALI UDMA to even come to the surface.
This I would call this a "unique chipset boot"
> Something to add to the kernel though, would be a drive "setting"
> to allow DMA to be used on drives which failed the DMA autodetect at
> boot.
>
> This function is missing, due to my own shortsightedness.
Your claimed "shortsightedness" has allowed me to find this is a problem
is some cases and legal work-arounds are possible.......
Well I am working on that and it is a real pain...........
> Cheers.
> --
> mlord@pobox.com
>
Now I am doing my very best to keep the format of the driver as before I
started working on it after 2.1.111/112. As I work more and more with the
code, I am trying to move back to a standard core kernel code format and
have all the chipsets be an extention.............careful to keep the bare
minimum of the wierd stuff for basic compatiblity of current
hardware/chipsets.
Lastly I always get your opinion first and consider it; however, I
proposed this in the past and both you and Linus pooh-poohed the concept.
I did go off on my merry way and keep the idea..........thus we have
both VIA and AEC6210 functionality with AEC6210 and PDC20246 with
native bootablity. The idea as brought ALI, HPT343 (once NDA is
released), PDC20246 (multiple cards, PCI/MASTER Mode Set) support.
Please note that in cmd646.c that this is directly needed.
Please note that in ns87415.c that direct pci calls for DMA2 are seeded.
The list goes on...............I only have labled it "PCI Tuning", but it
has been here in the past and added lately by other maintainers. I will
point out that they did keep it inside the chipset source code.......and I
plan to move in that direction before I submit something to Linus.
I also push test cases and require public reports so that everyone can see
that it does work........since IDE-FNG stands for ::
IDE-F(*)NewGuy :: where (*) is you fill in the blank..............
Until you offically pass off the driver publicly, few take the work
seriously and many view me as a rookie..........yes this is true.
However I cut my teeth on kernel 1.2.8-aout and have crawled through
1.3.xxx, walked through 2.0.xx->2.1.65, and began to run since 2.1.99.
Now this is my own opinion of my skills, but I now get paid to write
device drivers............as a consultant on the side.
Cheers,
Andre Hedrick
The IDE-FNG for Linux
The APC UPS Specialist for Linux
http://www.dyer.vanderbilt.edu/server/udma/
http://www.dyer.vanderbilt.edu/server/apcupsd/apcupsd-3.5.0.bin.tar.gz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/