Tejun Heo 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 update -data_xfer such that it returns the
number of consumed
Jeff Garzik wrote:
IMO s/buflen/len/ causes needless patch noise, and makes this harder review
Separating out s/buflen/len/ to a separate patch seemed silly yet I
wanted to renamed it. :-P
If you want to kill it, I'll kill the renaming. If you want it in a
separate patch, I'll separate it
Tejun Heo wrote:
Jeff Garzik wrote:
IMO s/buflen/len/ causes needless patch noise, and makes this harder review
Separating out s/buflen/len/ to a separate patch seemed silly yet I
wanted to renamed it. :-P
If you want to kill it, I'll kill the renaming. If you want it in a
separate patch,
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
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 update
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
draining.
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 risk
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 drain too
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
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
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
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
12 matches
Mail list logo
