Tejun Heo wrote:
Fix various bugs in pio/mwdma mode programming.
* Control bits in the timing register wasn't cleared properly while
programming PIO mode.
* MWDMA mode programming cleared the wrong part of control bits.
* MWDMA mode programming cleared udma_mask even when the controller
do
On Fri, 25 May 2007 19:16:58 +0200
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Fix various bugs in pio/mwdma mode programming.
>
> * Control bits in the timing register wasn't cleared properly while
> programming PIO mode.
>
> * MWDMA mode programming cleared the wrong part of control bits.
>
> *
Fix various bugs in pio/mwdma mode programming.
* Control bits in the timing register wasn't cleared properly while
programming PIO mode.
* MWDMA mode programming cleared the wrong part of control bits.
* MWDMA mode programming cleared udma_mask even when the controller
doesn't support UDMA.
Art Haas wrote:
On Wed, Feb 07, 2007 at 11:53:17AM +0900, Tejun Heo wrote:
Art Haas wrote:
Also, zero out the features register before issuing PACKET_IDENTIFY,
if the code isn't already doing that.
Okay.
SUCCESS!
Yay!
...
So, it succeeded without any DRQ wait. Can you please apply only
On Wed, Feb 07, 2007 at 11:53:17AM +0900, Tejun Heo wrote:
> Art Haas wrote:
> >>>Also, zero out the features register before issuing PACKET_IDENTIFY,
> >>>if the code isn't already doing that.
> >>Okay.
> >>
> >>>After the drive asserts BUSY, and later deasserts BUSY,
> >>>there might be a slight
Art Haas wrote:
Also, zero out the features register before issuing PACKET_IDENTIFY,
if the code isn't already doing that.
Okay.
After the drive asserts BUSY, and later deasserts BUSY,
there might be a slight delay before the drive asserts DRQ.
So, it is possible for the status to read zeros i
On Tue, Feb 06, 2007 at 06:11:44PM +0900, Tejun Heo wrote:
> Mark Lord wrote:
> > Tejun Heo wrote:
> >> ..
> >> Then, PACKET_IDENTIFY after configuring transfer mode fails with
> >> -ENOENT. Meaning it saw (status & (ATA_BUSY|ATA_DRQ|ATA_ERR|ATA_DF)) ==
> >> 0 in HSM_ST.
> > ..
> >> So, PATA gurus
Mark Lord wrote:
> Tejun Heo wrote:
>> ..
>> Then, PACKET_IDENTIFY after configuring transfer mode fails with
>> -ENOENT. Meaning it saw (status & (ATA_BUSY|ATA_DRQ|ATA_ERR|ATA_DF)) ==
>> 0 in HSM_ST.
> ..
>> So, PATA gurus, can you bless us with enlightenment? :-)
>
> Heh.. guaranteeing detecti
Alan wrote:
>>> Yep and if the BIOS programmed the slave into DMA that might not be ideal.
>> How so? The bit will be programmed by set_dmamode() right after
>> set_piomode() is complete.
>
> IFF we also put the device into a DMA mode. A blacklisted device would be
> wrong.
Hmmm... I might be mi
Tejun Heo wrote:
..
Then, PACKET_IDENTIFY after configuring transfer mode fails with
-ENOENT. Meaning it saw (status & (ATA_BUSY|ATA_DRQ|ATA_ERR|ATA_DF)) ==
0 in HSM_ST.
..
So, PATA gurus, can you bless us with enlightenment? :-)
Heh.. guaranteeing detection of all the strange implementatio
> > Yep and if the BIOS programmed the slave into DMA that might not be ideal.
>
> How so? The bit will be programmed by set_dmamode() right after
> set_piomode() is complete.
IFF we also put the device into a DMA mode. A blacklisted device would be
wrong.
> See the difference? Smart one liner
On Sat, Feb 03, 2007 at 11:09:19AM +0900, Tejun Heo wrote:
> (cc'ing Albert, Mark and Sergei. Hi!)
>
> Art Haas wrote:
> > Hi. Sorry to say the CD-ROM is still not found. Full 'dmesg' output
> > listed below in hopes it provides clues.
>
> Erggghh.. I'm sorry too. I thought I found it this time
(cc'ing Albert, Mark and Sergei. Hi!)
Art Haas wrote:
> Hi. Sorry to say the CD-ROM is still not found. Full 'dmesg' output
> listed below in hopes it provides clues.
Erggghh.. I'm sorry too. I thought I found it this time.
> ata_piix :00:07.1: version 2.00ac7
> ata2: PATA max UDMA/33 cmd
Alan wrote:
>> * Control bits in the timing register wasn't cleared properly while
>> programming PIO mode.
>
> Yep and if the BIOS programmed the slave into DMA that might not be ideal.
How so? The bit will be programmed by set_dmamode() right after
set_piomode() is complete.
>> * MWDMA mode
On Sat, Feb 03, 2007 at 12:18:56AM +0900, Tejun Heo wrote:
> Hello, Art Haas, Alan.
>
> Okay, here's another try at fixing the detection bug. I went through
> intel ich docs and compared with the ide piix driver. This patch
> fixes the following problems.
>
> * Control bits in the timing regist
Hello.
Alan wrote:
Actually, I think ata_timing_merge() should just be performed when
setting MWDMA mode... This should be the right thing to do in most cases
(however, this hardware has some complications in the form of only 2-bit
wide active/recovery counts and 2 fast timing bank select bit
On Sat, 03 Feb 2007 01:41:41 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> >Actually, I think ata_timing_merge() should just be performed when
> > setting MWDMA mode... This should be the right thing to do in most cases
> > (however, this hardware has some complications in the form of only 2-bit
Hello.
Mark Lord wrote:
It's amazing how poorly we have programmed PIIX, for the lifespan of
Linux...
Actually, we've only been fiddling timings on PIIX since 1998 or so,
when AH began taking over Linux IDE. Still, 10 years is an eternity.
The most funny thing is that despite being call
> * Control bits in the timing register wasn't cleared properly while
> programming PIO mode.
Yep and if the BIOS programmed the slave into DMA that might not be ideal.
> * MWDMA mode programming cleared the wrong part of control bits. I
> think this can fix your problem.
Your change does n
Jeff Garzik wrote:
It's amazing how poorly we have programmed PIIX, for the lifespan of
Linux...
Actually, we've only been fiddling timings on PIIX since 1998 or so,
when AH began taking over Linux IDE. Still, 10 years is an eternity.
Cheers
-
To unsubscribe from this list: send the line "uns
Sergei Shtylyov wrote:
>> +/* PIO configuration clears DTE unconditionally. It will be
>> + * programmed in set_dmamode which is guaranteed to be called
>> + * after set_piomode if any DMA mode is available.
>> + */
>
>Actually, I think ata_timing_merge() should just be perfor
It's amazing how poorly we have programmed PIIX, for the lifespan of
Linux...
Jeff
-
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
Hello.
Tejun Heo wrote:
Okay, here's another try at fixing the detection bug. I went through
intel ich docs and compared with the ide piix driver. This patch
fixes the following problems.
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index c6bf1a3..51f55a0 100644
--- a/drive
Hello, Art Haas, Alan.
Okay, here's another try at fixing the detection bug. I went through
intel ich docs and compared with the ide piix driver. This patch
fixes the following problems.
* Control bits in the timing register wasn't cleared properly while
programming PIO mode.
* MWDMA mode pr
24 matches
Mail list logo
