sam song wrote:
>> sam song wrote:
sam song wrote:
> Attached pls see the details debug log on SUSE Linux Enterprise 10 I
>>> just
> did. As for code, I will send to you in private for it is kind of poor
>>> and
> confidential. Really sorry for that.
Aieee... SLES10. Is it SL
> sam song wrote:
> >> sam song wrote:
> >>> Attached pls see the details debug log on SUSE Linux Enterprise 10 I
> > just
> >>> did. As for code, I will send to you in private for it is kind of poor
> > and
> >>> confidential. Really sorry for that.
> >> Aieee... SLES10. Is it SLES10SP1 or just S
sam song wrote:
>> sam song wrote:
>>> Attached pls see the details debug log on SUSE Linux Enterprise 10 I
> just
>>> did. As for code, I will send to you in private for it is kind of poor
> and
>>> confidential. Really sorry for that.
>> Aieee... SLES10. Is it SLES10SP1 or just SLES10. I'm fair
> sam song wrote:
> > Attached pls see the details debug log on SUSE Linux Enterprise 10 I
just
> > did. As for code, I will send to you in private for it is kind of poor
and
> > confidential. Really sorry for that.
>
> Aieee... SLES10. Is it SLES10SP1 or just SLES10. I'm fairly sure
> passthrou
From: Peter Schwenke <[EMAIL PROTECTED]>
Add more toshiba laptops to broken suspend list. This is from OSDL
bugzilla bug 7780.
tj: re-formatted patch and added description and SOB.
Signed-off-by: Peter Schwenke <[EMAIL PROTECTED]>
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
This one is for
sam song wrote:
> Attached pls see the details debug log on SUSE Linux Enterprise 10 I just
> did. As for code, I will send to you in private for it is kind of poor and
> confidential. Really sorry for that.
Aieee... SLES10. Is it SLES10SP1 or just SLES10. I'm fairly sure
passthrough support is
Tejun Heo wrote:
Mark Lord wrote:
If I were doing this, I'd probably just do PIO for all non bulk xfer
opcodes, same as you, for ease of maintainership.
But I'd also think really hard about some way to allow full DMA
for chipsets/drives that can be trusted. Not a whitelist (like Alan,
I don't
> sam song wrote:
> > Hi,
> >
> > I am convinced that the SATA Disk does support one vendor specific ATA
> > command and got the whole bus trace via Trainer.
> > However, I cannot implement that in the real cases with either HBA or
SATA
> > Controller like ICH5/7 via ATA Pass Thru.
> > So I wonder
Hello,
Mark Lord wrote:
>> One thing I don't understand about this argument is that PIO cycle time
>> is not determined by CPU power. It's bound by PCI and ATA bus speed.
>> If you put a faster CPU on the job, it just ends up wasting the same
>> amount of time burning up more CPU cycles or am I m
sam song wrote:
> Hi,
>
> I am convinced that the SATA Disk does support one vendor specific ATA
> command and got the whole bus trace via Trainer.
> However, I cannot implement that in the real cases with either HBA or SATA
> Controller like ICH5/7 via ATA Pass Thru.
> So I wonder whether there i
Tejun Heo wrote:
> And when reading off Status when idle, we'll need to return 0 from
> irq_handler. That will prevent IRQ screaming IRQ lock and nobody cared
That sentence was "That will prevent IRQ screaming from causing IRQ live
lock..." in my mind. Some packets were lost while transmitting i
Jeff Garzik wrote:
> Actually no, and that is a key benefit of this scheme: if we ensure
> that the polling paths are resilient even in case where interrupts are
> being delivered -- as we must do anyway -- then we don't have to worry
> about interrupt masking, either on the interrupt controller o
Tejun Heo wrote:
Mark Lord wrote:
I'm split on this one. For fast systems (typical notebook/desktop) it's
almost a non-issue either way.
But a lot of media boxes will be using this code, and they tend to have
very low-power, slow-clockrate CPUs in the 200-800Mhz range, and so the
real-time hit
Bjoern Olausson wrote:
> I managed to install WinXP and I think I got the driver to work on WindowsXP.
> The installation was ony possible in IDE Enhaced mode. I wasn't able
> to feed XP the Intel Matrix Storage controller during installation to
> use XP wiith AHCI mode.
>
> I searched around for
>Gaston, Jason D wrote:
>> Does 2.6.24-rc3 support SATA port multipliers?
>>
>> I am getting "ata6.03: COMRESET failed (errno=-5)" error messages
with a
>> SiliconImage PMP connected to an Intel ICH9 SATA controller in AHCI
>> mode.
>
>Yeah, it should work.
>
>> Dmesg output attached.
>
>Eeek.. Can
Phillip Susi wrote:
Tejun Heo wrote:
Agreed. Nobody cared on ATA controllers is usually very effective at
taking the whole machine down. Is there any reason why we don't turn on
irqpoll on turned off IRQs automatically?
Why does a single spurious interrupt cause it to be shut down? I can
s
Phillip Susi wrote:
> Tejun Heo wrote:
>> Agreed. Nobody cared on ATA controllers is usually very effective at
>> taking the whole machine down. Is there any reason why we don't turn on
>> irqpoll on turned off IRQs automatically?
>
> Why does a single spurious interrupt cause it to be shut down
On 11/29/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
>
> I now have affected drives on my desk and am gonna try reproduce it. My
> gut feeling says it's timing related problem on controller / driver
> side. Please wait a bit.
>
> > by the way, and OT, did the Plextor DVD-RW drive reach you, Tejun?
On 11/29/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
>
> I now have affected drives on my desk and am gonna try reproduce it. My
> gut feeling says it's timing related problem on controller / driver
> side. Please wait a bit.
>
Okay, no problem, I am just curious.
> > by the way, and OT, did the Pl
Bjoern Olausson wrote:
> On 11/7/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
>> Thanks. We're currently trying to find out what's actually going on
>> with all these drives. At first, drives which got blacklisted aren't
>> many and made sense (had other problems with NCQ, etc..) but with new
>> gene
Mark Lord wrote:
> I'm split on this one. For fast systems (typical notebook/desktop) it's
> almost a non-issue either way.
>
> But a lot of media boxes will be using this code, and they tend to have
> very low-power, slow-clockrate CPUs in the 200-800Mhz range, and so the
> real-time hit there (
Tejun Heo wrote:
Agreed. Nobody cared on ATA controllers is usually very effective at
taking the whole machine down. Is there any reason why we don't turn on
irqpoll on turned off IRQs automatically?
Why does a single spurious interrupt cause it to be shut down? I can
see if the interrupt i
On Thu, 29 Nov 2007 14:36:30 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> DMA alignment is host restriction so I think it belongs to ata_host if
> >> we ever need it. Do you know of any controller which require such
> >> thing? No need to add complexity when it's not neces
This patch implements Enclosure Management via the LED protocol. See
the AHCI 1.1 spec for details.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
---
Ok, here's one that actually compiles...
drivers/ata/ahci.c| 154 -
drivers/ata
On Thu, 2007-11-29 at 19:37 +, Nick Warne wrote:
> Hi all,
>
> 2.6.23.9
>
> I have noticed after applying Bart's patch to word93 blacklist my new
> DVD drive:
>
> http://lkml.org/lkml/2007/10/23/475
>
> I see now in logs (look at the hdd line:
>
> [dmesg]
> hdc: 39876480 sectors (20416 MB
On Thu, 2007-11-29 at 20:03 +, Nick Warne wrote:
> Yes, but where does the <7> come from?
printk interleaving of functions in ide-cd and ide-iops.
drivers/ide/ide-cd.c ide_cdrom_probe_capabilities could
use something like the string_buf implementations talked
about awhile ago.
-
To unsubscr
Nick Warne wrote:
Hi all,
2.6.23.9
I have noticed after applying Bart's patch to word93 blacklist my new
DVD drive:
http://lkml.org/lkml/2007/10/23/475
I see now in logs (look at the hdd line:
[dmesg]
hdc: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63,
UDMA(66)
hdc: cache flus
Kristen Carlson Accardi wrote:
On Thu, 29 Nov 2007 13:16:07 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
Kristen wrote:
...
+* XXX will need Port Multiplier support
What's that all about ?
I didn't have any hardware that had LED support as well as Port
Multiplier, so I didn't impleme
Hi Jon,
On Thu, 29 Nov 2007 14:51:11 -0500
Jon Masters <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-11-29 at 19:37 +, Nick Warne wrote:
> > Hi all,
> >
> > 2.6.23.9
> >
> > I have noticed after applying Bart's patch to word93 blacklist my
> > new DVD drive:
> >
> > http://lkml.org/lkml/200
Hi all,
2.6.23.9
I have noticed after applying Bart's patch to word93 blacklist my new
DVD drive:
http://lkml.org/lkml/2007/10/23/475
I see now in logs (look at the hdd line:
[dmesg]
hdc: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63,
UDMA(66)
hdc: cache flushes not supported
Alan Cox wrote:
DMA alignment is host restriction so I think it belongs to ata_host if
we ever need it. Do you know of any controller which require such
thing? No need to add complexity when it's not necessary.
If we ever get the blasted inic162x working then that appears to have
some alignme
Mark Lord wrote:
Alan Cox wrote:
DMA alignment is host restriction so I think it belongs to ata_host if
we ever need it. Do you know of any controller which require such
thing? No need to add complexity when it's not necessary.
If we ever get the blasted inic162x working then that appears to
On Thu, 29 Nov 2007 13:16:07 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
> Kristen wrote:
> ...
> >+ * XXX will need Port Multiplier support
>
> What's that all about ?
>
I didn't have any hardware that had LED support as well as Port
Multiplier, so I didn't implement port multiplier support
Alan Cox wrote:
DMA alignment is host restriction so I think it belongs to ata_host if
we ever need it. Do you know of any controller which require such
thing? No need to add complexity when it's not necessary.
If we ever get the blasted inic162x working then that appears to have
some alignme
Tejun Heo wrote:
Tejun Heo wrote:
Alan Cox wrote:
Private command type / transfer length filtering in sata_promise,
pata_it821x and pata_pdc2027x are removed as core layer filtering is
more conservative.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
NAK - as before
This is the wrong way to do
On Thu, 29 Nov 2007 09:48:02 -0800
Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote:
> This patch implements Enclosure Management via the LED protocol. See
> the AHCI 1.1 spec for details.
Whoops, I totally messed up and sent the wrong version of this patch.
I'll send an updated one, ignore thi
> DMA alignment is host restriction so I think it belongs to ata_host if
> we ever need it. Do you know of any controller which require such
> thing? No need to add complexity when it's not necessary.
If we ever get the blasted inic162x working then that appears to have
some alignment limits. At
> So, I thought 16k was a good trade off. Not as comfortable as 64k tho,
> I agree. Would it be worth to add more complexity for this?
Fair point .. I don't know. Perhaps we should wait and see.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [E
Kristen wrote:
...
+* XXX will need Port Multiplier support
What's that all about ?
-
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
Alan Cox wrote:
> On Fri, 30 Nov 2007 01:42:46 +0900
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> Alan Cox wrote:
* Limit the amount of draining to ATAPI_MAX_DRAIN (16k currently).
>>> Why 16 not 64K ?
>> Oops, forgot to answer here. That would result in 16 sg entries for
>> draining which fe
Alan Cox wrote:
>> It's for draining. Let's say drive says it wanna transfer 18 bytes but
>> the buffer is only 13 bytes long. If the transfer method consumes 2
>> bytes per read, it would consume 14 bytes. If the transfer method
>> consumes 4 bytes per read, it would consume 16 bytes. If we dr
This patch implements Enclosure Management via the LED protocol. See
the AHCI 1.1 spec for details.
Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
---
Here's a new version of the Enclosure management patch I sent a few
weeks ago. I tried to incorporate all the feedback, although I'm
On Fri, 30 Nov 2007 01:42:46 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> * Limit the amount of draining to ATAPI_MAX_DRAIN (16k currently).
> >
> > Why 16 not 64K ?
>
> Oops, forgot to answer here. That would result in 16 sg entries for
> draining which felt a bit too much
> It's for draining. Let's say drive says it wanna transfer 18 bytes but
> the buffer is only 13 bytes long. If the transfer method consumes 2
> bytes per read, it would consume 14 bytes. If the transfer method
> consumes 4 bytes per read, it would consume 16 bytes. If we drain too
> much, we r
> If we're gonna take that road, let's lift 16 byte alignment check during
> -rc cycles. It's something which masks the problem half way. It only
> hinders the debugging process.
That would be a good project for the -mm tree. Perhaps lift it to 2, and
also see what happens if the DMA padding is
Bartlomiej Zolnierkiewicz wrote:
* Add IDE_TFLAG_CUSTOM_HANDLER taskfile flag and use it for internal requests
which require custom handlers. Check the flag in do_rw_taskfile() and set
handler accordingly.
* Cleanup ide_init_{specify,restore,setmult}_cmd() and rename it to
ide_tf_set_{spe
Tejun, I am reffering to the post on your hompage
(http://home-tj.org/wiki/index.php/Libata-tj-stable)
---
* Again, Sil4726 doesn't like ahci driver initialization sequence.
During driver initiali
On 11/7/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
>
> Thanks. We're currently trying to find out what's actually going on
> with all these drives. At first, drives which got blacklisted aren't
> many and made sense (had other problems with NCQ, etc..) but with new
> generation drives from many ven
Bartlomiej Zolnierkiewicz wrote:
* Add 'data_buf' and 'nsect' variables in ide_taskfile_ioctl()
to cache data buffer pointer and number of sectors to transfer
(this allows us to have only one ide_diag_taskfile() call).
* Add IDE_TFLAG_WRITE taskfile flag and use it to check whether
the
Alan Cox wrote:
>> * Limit the amount of draining to ATAPI_MAX_DRAIN (16k currently).
>
> Why 16 not 64K ?
Oops, forgot to answer here. That would result in 16 sg entries for
draining which felt a bit too much. As draining is for misc commands, I
thought 16k should be enough.
--
tejun
-
To un
Tejun Heo wrote:
> Alan Cox wrote:
>>> Private command type / transfer length filtering in sata_promise,
>>> pata_it821x and pata_pdc2027x are removed as core layer filtering is
>>> more conservative.
>>>
>>> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>> NAK - as before
>>
>> This is the wrong wa
Alan Cox wrote:
>> Private command type / transfer length filtering in sata_promise,
>> pata_it821x and pata_pdc2027x are removed as core layer filtering is
>> more conservative.
>>
>> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
>
> NAK - as before
>
> This is the wrong way to do stuff. Stop pen
Alan Cox wrote:
> On Thu, 29 Nov 2007 23:33:36 +0900
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> ATAPI DMA is filled with mines. Sector aligned READ transfers usually
>> work but many other commands transfer non-sector aligned or variable
>> number of bytes, and there are devices and controllers
> Private command type / transfer length filtering in sata_promise,
> pata_it821x and pata_pdc2027x are removed as core layer filtering is
> more conservative.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
NAK - as before
This is the wrong way to do stuff. Stop penalizing the 99.99% of users
Alan Cox wrote:
>> * Limit the amount of draining to ATAPI_MAX_DRAIN (16k currently).
>
> Why 16 not 64K ?
>
> Please add a comment to note that the drivers assume
> - drain is only ever done on a stuck PIO xfer
No. ATAPI draining is to accommodate buggy software and hardware and
it's for all m
On Thu, 29 Nov 2007 23:33:36 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> ATAPI DMA is filled with mines. Sector aligned READ transfers usually
> work but many other commands transfer non-sector aligned or variable
> number of bytes, and there are devices and controllers which have
> problems dea
Alan Cox wrote:
> On Thu, 29 Nov 2007 23:33:28 +0900
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> Depending on how many bytes are transferred as a unit, PIO data
>> tranasfer may consume more bytes than requested. Knowing how much
>> data is consumed is necessary to determine how much is left for
On Thu, 29 Nov 2007 23:33:34 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> qc->nbytes doesn't include extra buffers setup by libata core layer
> and my be odd. This patch adds qc->dma_nbytes which includes any
> extra buffers setup by libata core layer and is guaranteed to be
> aligned on 4 byte b
On Thu, 29 Nov 2007 23:33:31 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> With atapi_request_sense() converted to use sg, there's no user of
> non-sg interface. Kill non-sg interface.
>
> * ATA_QCFLAG_SINGLE and ATA_QCFLAG_SG are removed. ATA_QCFLAG_DMAMAP
> is used instead. (this way no LLD
> * Limit the amount of draining to ATAPI_MAX_DRAIN (16k currently).
Why 16 not 64K ?
Please add a comment to note that the drivers assume
- drain is only ever done on a stuck PIO xfer
- drain occurs before any controller error/reset handling is done
-
To unsubscribe from this list: send the line
On Thu, 29 Nov 2007 23:33:28 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Depending on how many bytes are transferred as a unit, PIO data
> tranasfer may consume more bytes than requested. Knowing how much
> data is consumed is necessary to determine how much is left for
> draining. This patch u
On Thu, 29 Nov 2007 23:33:24 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> While updating lbam/h for ATAPI commands, atapi_eh_request_sense() was
> left out. Update it.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
> ---
> drivers/ata/libata-eh.c |
On Thu, 29 Nov 2007 23:33:26 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> ATA_PROT_ATAPI_* are ugly and naming schemes between ATA_PROT_* and
> ATA_PROT_ATAPI_* are inconsistent causing confusion. Rename them to
> ATAPI_PROT_* and make them consistent with ATA counterpart.
>
> Signed-off-by: Tej
Tejun Heo wrote:
> Albert Lee wrote:
>> If the trailing data is odd-lengthed, normally the situation is that
>> we have odd-lengthed real data before the trailing data. e.g. The real
>> data is 9 bytes, but the drive returns 10 bytes (so, the trailing data
>> is 1 byte).
>>
>> In ata_data_xfer(), w
libata used private sg iterator to handle padding sg. Now that sg can
be chained, padding can be handled using standard sg ops. Convert to
chained sg.
* s/qc->__sg/qc->sg/
* s/qc->pad_sgent/qc->extra_sg[]/. Because chaining consumes one sg
entry. There need to be two extra sg entries. The
Misc ATAPI commands may try to transfer more bytes than requested.
For PIO which is performed by libata HSM, this is worked around by
draining extra bytes from __atapi_pio_bytes().
This patch implements drain buffer to perform draining for DMA and
PIO-over-DMA cases. One page is allocated w/ GFP_
qc->nbytes doesn't include extra buffers setup by libata core layer
and my be odd. This patch adds qc->dma_nbytes which includes any
extra buffers setup by libata core layer and is guaranteed to be
aligned on 4 byte boundary.
This value is to be used to program the host controller. As this
repre
Depending on how many bytes are transferred as a unit, PIO data
tranasfer may consume more bytes than requested. Knowing how much
data is consumed is necessary to determine how much is left for
draining. This patch update ->data_xfer such that it returns the
number of consumed bytes.
While at it
ATA_QCFLAG_DMAMAP was a bit peculiar in that it got set during qc
initialization and cleared if DMA mapping wasn't necessary. Make it
more straight forward by making the following changes.
* Don't set it during initialization. Set it after DMA is actually
mapped.
* Add BUG_ON() to guarantee t
atapi_request_sense() is now the only left user of ata_sg_init_one().
Convert it to use sg interface.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Rusty Russel <[EMAIL PROTECTED]>
---
drivers/ata/libata-scsi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers
ATAPI devices come with plethora of bugs and many ATA controllers have
trouble dealing with odd byte DMA transfers. The problem is currently
somewhat masked by not allowing DMA transfers if the transfer size
isn't aligned to 16 bytes plus partial masking in problematic LLDs.
This masking is taken
ATAPI DMA is filled with mines. Sector aligned READ transfers usually
work but many other commands transfer non-sector aligned or variable
number of bytes, and there are devices and controllers which have
problems dealing with such non-aligned DMA transactions.
This patch implement ATAPI per-comm
Add GPCMD_* constants for READ_BUFFER, WRITE_12 and WRITE_BUFFER for
completeness. These will be used libata.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
include/linux/cdrom.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/cdrom.h b/include/linux/cd
Add ATAPI command types - ATAPI_READ, WRITE, RW_BUF, READ_CD and MISC,
and implement atapi_cmd_type() which takes SCSI opcode and returns to
which class the opcode belongs. This will be used later to improve
ATAPI handling.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
include/linux/libata.h
For misc ATAPI commands which transfer variable length data to the
host, overflow can occur due to application or hardware bug. Such
overflows can be ignored safely as long as overflow data is properly
drained. libata HSM implementation has this implemented in
__atapi_pio_bytes() but it isn't eno
With atapi_request_sense() converted to use sg, there's no user of
non-sg interface. Kill non-sg interface.
* ATA_QCFLAG_SINGLE and ATA_QCFLAG_SG are removed. ATA_QCFLAG_DMAMAP
is used instead. (this way no LLD change is necessary)
* qc->buf_virt is removed.
* ata_sg_init_one() and ata_sg_s
While updating lbam/h for ATAPI commands, atapi_eh_request_sense() was
left out. Update it.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-eh.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index
ATA_PROT_ATAPI_* are ugly and naming schemes between ATA_PROT_* and
ATA_PROT_ATAPI_* are inconsistent causing confusion. Rename them to
ATAPI_PROT_* and make them consistent with ATA counterpart.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 24
Hello,
This is the second take of improve-ATAPI-data-transfer patchset.
Changes from the last take [L] are.
* 0005-libata-make-data_xfer-return-the-number-of-consum.patch added
which converts ->data_xfer to return the number of consumed bytes.
* 0006-libata-improve-ATAPI-draining.patch is fix
Several fixes for the AVR32 PATA driver:
* Updated to use new AVR32 SMC timing API. This removes the need for "magic"
constants in signal timing.
* Removed the ATA_FLAG_PIO_POLLING, the driver should use interrupts.
* Removed .port_disable and .irq_ack as these are no longer needed.
* Improved
On Thu, Nov 29 2007 at 1:36 +0200, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Nov 2007 16:14:21 -0700
> Matthew Wilcox <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Nov 28, 2007 at 01:40:36PM -0800, Andrew Morton wrote:
>>> On Wed, 28 Nov 2007 23:01:31 +0300
>>> Alexey Dobriyan <[EMAIL PROTEC
On Thu, 29 Nov 2007 15:18:24 +0800
"Sonic Zhang" <[EMAIL PROTECTED]> wrote:
> Any comment?
Looks fine to me
-
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
82 matches
Mail list logo
