Re: question regarding cacheline size

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Thu, Sep 07, 2006 at 02:53:57PM +0200, Tejun Heo wrote:
> Matthew Wilcox wrote:
> >On Thu, Sep 07, 2006 at 02:33:25PM +0200, Arjan van de Ven wrote:
> >>>So I think we should redo the PCI subsystem to set cacheline size during
> >>>the buswalk rather than waiting for drivers to ask for it to be set.
> >>... while allowing for quirks for devices that go puke when this
> >>register gets written ;)
> >>
> >>(afaik there are a few)
> >
> >So you want:
> >
> >	unsigned int no_cls:1;	/* Device pukes on write to Cacheline Size */
> >
> >in struct pci_dev?
> 
> The spec says that devices can put additional restriction on supported 
> cacheline size (IIRC, the example was something like power of two >= or 
> <= certain size) and should ignore (treat as zero) if unsupported value 
> is written.  So, there might be need for more low level driver 
> involvement which knows device restrictions, but I don't know whether 
> such devices exist.

The problem is that both ends of the bus need to know the cache line
size for some of these commands to work correctly.

Consider, as in Matthew's case, a read command which wraps at the cache
line boundary.  Unless both the master and slave are programmed with the
same cache line size, it's entirely possible for the wrong memory
locations to be read.

Eg, the device might expect 0x118, 0x11c, 0x100, 0x104, but it actually
gets 0x118, 0x11c, 0x120, 0x124 because the target got programmed with
64 while the master was set to 32.

This is, of course, supposing that the memory read command is used in
the cache line wrap mode.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core