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, determi
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 inte
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 'ide_pci_device_t'
---
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
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 recovery clock count as a difference between the total
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 inte
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
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 p
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 appl
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
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
active/re
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, remo
On Friday 09 February 2007 23:29, 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
> c
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 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 mo
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 ti
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 dma_host_{
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, determi
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 recovery clock count as a difference between the total
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
[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 recovery
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 fiddling with the DMA capable bits in the speedproc() -- they
>do
On Thursday 08 February 2007 09:58, 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?
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?
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 B
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 libat
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
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 PI
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 wrtiti
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, a
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
> >>>stat
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
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 -- address
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
> calcula
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 he
38 matches
Mail list logo