Hi,
On 08/10/2016 10:14 AM, Tejun Heo wrote:
Hello, Tom.
On Wed, Aug 10, 2016 at 06:04:10PM +0800, Tom Yan wrote:
On 10 August 2016 at 11:26, Tejun Heo <tj@xxxxxxxxxx> wrote:
Hmmm.. why not? The hardware limit is 64k and the driver is using a
Is that referring to the maximum number of entries allowed in the
PRDT, Physical Region Descriptor Table (which is, more precisely,
65535)?
Yeap.
Not necessarily. A single sg entry can point to an area larger than
PAGE_SIZE.
You mean the 4MB limit of "Data Byte Count" in "DW3: Description
Information" of the PRDT? Is that what max_segment_size (which is set
to a general fallback of 65536:
http://lxr.free-electrons.com/ident?i=dma_get_max_seg_size) is about
in this case?
Ah, ahci isn't setting the hardware limit properly but yeah that's the
maximum segment size.
And my point was, it will be a multiple of 168 anyway, if 1344 is just
an example.
As written above, that probably makes the ahci command table size
nicely aligned.
I think that's what bothers me ultimately, cause I don't see how 168
makes it (more) nicely aligned (or even, aligned to what?).
Hmmm... Looked at the sizes and they don't seem to align to anything
meaningful. No idea.
The 168 makes AHCI_CMD_TBL_SZ equal to 2816
AHCI_CMD_TBL_SZ = AHCI_CMD_TBL_HDR_SZ + (AHCI_MAX_SG * 16)
AHCI_CMD_TBL_SZ = 128 + (168 * 16)
I think if you add in AHCI_CMD_SLOT_SZ (1024) and AHCI_RX_FIS_SZ (256)
the DMA is 4K aligned, I think that is where the 168 came from.
Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
