On Thursday 10 May 2007, Sergei Shtylyov wrote:
Fix two minor issues with PCI0646 chip reporting in the init_chipset() method:
IRQ workaround enabled message printed out not only for revision 0x01 and
CMD646: chipset revision printed twice (by IDE core and the driver itself).
Also, remove
---
The patch have been tested on PCI-649 only.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix two minor issues with PCI0646 chip reporting in the init_chipset() method:
IRQ workaround enabled message printed out not only for revision 0x01 and
CMD646: chipset revision printed twice (by IDE core and the driver itself).
Also, remove empty/pointless switch cases for the chips other than
On Saturday 03 March 2007, Sergei Shtylyov wrote:
[PATCH] cmd64x: fix recovery time calculation
The driver wrongly takes the address setup time into account when calculating
the PIO recovery time -- this leads to slight overclocking of the PIO modes 0
and 1 (so, the prayers failed to help,
[PATCH] cmd64x: fix recovery time calculation
The driver wrongly takes the address setup time into account when calculating
the PIO recovery time -- this leads to slight overclocking of the PIO modes 0
and 1 (so, the prayers failed to help, as usual :-). Rework the code to be
calculating
Hi,
On Wednesday 28 February 2007, Sergei Shtylyov wrote:
Add back the multiword DMA support (I think nobody will miss single-word DMA).
In order to do it, a number of changes had to be done:
- rename program_drive_counts() to program_cycle_times(), pass to it cycle's
total/active times
On Monday 26 February 2007, Sergei Shtylyov wrote:
The driver wrongly takes the address setup time into account when calculating
the PIO recovery time -- this leads to slight overclocking of the PIO modes 0
and 1 (so, the prayers failed to help, as usual :-). Rework the code to be
Hello, I wrote:
The driver used to merge the address setup timing for the secondary channel but
this must have been done for both channels actually despite the primary channel
had separate registers for each drive (I'afraid that this is too common mistake
in both hardware and software --
Add back the multiword DMA support (I think nobody will miss single-word DMA).
In order to do it, a number of changes had to be done:
- rename program_drive_counts() to program_cycle_times(), pass to it cycle's
total/active times instead of the clock counts, and convert them into the
The driver used to merge the address setup timing for the secondary channel but
this must have been done for both channels actually despite the primary channel
had separate registers for each drive (I'afraid that this is too common mistake
in both hardware and software -- address setup timing must
On Friday 16 February 2007, Sergei Shtylyov wrote:
Fold the parts of the ide_dma_end() methods indetical to __ide_dma_end() into
a
mere call to it.
Start using faster versions of the ide_dma_end() and ide_dma_test_irq()
methods
for the PCI0646U and newer chips that have the duplicate
On Tuesday 20 February 2007, Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
The IDE core looks at the wrong bit when checking if the secondary channel
is
enabled on PCI0646 -- CFR bit 8 is read-ahead disable, bit 3 is the correct
one.
I guess that you meant CNTRL
Hello.
Bartlomiej Zolnierkiewicz wrote:
The IDE core looks at the wrong bit when checking if the secondary channel is
enabled on PCI0646 -- CFR bit 8 is read-ahead disable, bit 3 is the correct one.
I guess that you meant CNTRL here?
Yeah, and bit 7. :-
[ I corrected this in the
On Thursday 15 February 2007 14:53, Sergei Shtylyov wrote:
The driver's ide_dma_test_irq() method was reading the MRDMODE register even
on
PCI0643/6 where it was write-only -- fix this by always reading the backward-
compatible interrupt bits, renaming dma_alt_stat to irq_stat as these
On Wednesday 14 February 2007 23:35, Sergei Shtylyov wrote:
The IDE core looks at the wrong bit when checking if the secondary channel is
enabled on PCI0646 -- CFR bit 8 is read-ahead disable, bit 3 is the correct
one.
I guess that you meant CNTRL here?
[ I corrected this in the applied
On Thursday 15 February 2007 20:17, Sergei Shtylyov wrote:
Fix several issues with the driver's procfs output:
- when testing if channel is enabled, the code looks at the simplex bits,
not
at the real enable bits -- add #define for the primary channel enable bit;
- UltraDMA modes 0,
On Thu, 8 Feb 2007 09:58:45 +0100 (MET), Mikael Pettersson wrote:
On Thu, 8 Feb 2007 00:00:32 +0300, Sergei Shtylyov wrote:
Remove the bogus code pretending to set SW/MW DMA timings -- I wonder whether
its author really thought that he could achieve that wrtiting to BMIDE status
registers? Stop
Mikael Pettersson wrote:
On Thu, 8 Feb 2007 09:58:45 +0100 (MET), Mikael Pettersson wrote:
On Thu, 8 Feb 2007 00:00:32 +0300, Sergei Shtylyov wrote:
Remove the bogus code pretending to set SW/MW DMA timings -- I wonder whether
its author really thought that he could achieve that wrtiting to
Hello.
Sergei Shtylyov wrote:
The intent of the patch was exactly to *remove* broken DMA support
until it's fixed (which requires more work). It only worked by chance
-- because MWDMA2 timings are the same as of PIO4. Have patience please.
You may also consider switching to the
Hi,
On Friday 16 February 2007 14:11, Sergei Shtylyov wrote:
Mikael Pettersson wrote:
On Thu, 8 Feb 2007 09:58:45 +0100 (MET), Mikael Pettersson wrote:
On Thu, 8 Feb 2007 00:00:32 +0300, Sergei Shtylyov wrote:
Remove the bogus code pretending to set SW/MW DMA timings -- I wonder
On Friday 16 February 2007 14:39, Sergei Shtylyov wrote:
Hello.
Sergei Shtylyov wrote:
The intent of the patch was exactly to *remove* broken DMA support
until it's fixed (which requires more work). It only worked by chance
-- because MWDMA2 timings are the same as of PIO4. Have
Hello.
Bartlomiej Zolnierkiewicz wrote:
Mikael Pettersson wrote:
Remove the bogus code pretending to set SW/MW DMA timings -- I wonder whether
its author really thought that he could achieve that wrtiting to BMIDE status
registers? Stop fiddling with the DMA capable bits in the speedproc()
Hello.
Bartlomiej Zolnierkiewicz wrote:
The intent of the patch was exactly to *remove* broken DMA support
until it's fixed (which requires more work). It only worked by chance
-- because MWDMA2 timings are the same as of PIO4. Have patience please.
You may also consider switching to
On Friday 16 February 2007 16:00, Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
Mikael Pettersson wrote:
Remove the bogus code pretending to set SW/MW DMA timings -- I wonder
whether
its author really thought that he could achieve that wrtiting to BMIDE
status
Hello.
Bartlomiej Zolnierkiewicz wrote:
Remove the bogus code pretending to set SW/MW DMA timings -- I wonder whether
its author really thought that he could achieve that wrtiting to BMIDE status
registers? Stop fiddling with the DMA capable bits in the speedproc() -- they
do not enable DMA,
On Friday 16 February 2007 16:34, Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
Remove the bogus code pretending to set SW/MW DMA timings -- I wonder
whether
its author really thought that he could achieve that wrtiting to BMIDE
status
registers? Stop fiddling with
Fold the parts of the ide_dma_end() methods indetical to __ide_dma_end() into a
mere call to it.
Start using faster versions of the ide_dma_end() and ide_dma_test_irq() methods
for the PCI0646U and newer chips that have the duplicate interrupt status bits
in the I/O mapped MRDMODE register,
Fold the parts of the ide_dma_end() methods indetical to __ide_dma_end() into a
mere call to it.
Start using faster versions of the ide_dma_end() and ide_dma_test_irq() methods
for the PCI0646U and newer chips that have the duplicate interrupt status bits
in the I/O mapped MRDMODE register,
The driver's ide_dma_test_irq() method was reading the MRDMODE register even on
PCI0643/6 where it was write-only -- fix this by always reading the backward-
compatible interrupt bits, renaming dma_alt_stat to irq_stat as these interrupt
status bits are not coupled to DMA.
In addition, wrong
Fix several issues with the driver's procfs output:
- when testing if channel is enabled, the code looks at the simplex bits, not
at the real enable bits -- add #define for the primary channel enable bit;
- UltraDMA modes 0, 1, 3 for slave drive reported incorrectly due to using the
master
The driver's ide_dma_test_irq() method was reading the MRDMODE register even on
PCI0643/6 where it was write-only -- fix this by always reading the backward-
compatible interrupt bits, renaming dma_alt_stat to irq_stat as these interrupt
status bits are not coupled to DMA.
In addition, wrong
The IDE core looks at the wrong bit when checking if the secondary channel is
enabled on PCI0646 -- CFR bit 8 is read-ahead disable, bit 3 is the correct one.
Starting with PCI0646U chip, the primary channel can also be enbled/disabled --
so, add 'enablebits' initializers to each
Remove the bogus code pretending to set SW/MW DMA timings -- I wonder whether
its author really thought that he could achieve that wrtiting to BMIDE status
registers? Stop fiddling with the DMA capable bits in the speedproc() -- they
do not enable DMA, and are properly dealt with by the
33 matches
Mail list logo
