[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060907120756.GA29532@flint.arm.linux.org.uk>
Date: Thu, 7 Sep 2006 13:07:56 +0100
From: Russell King <rmk+lkml@....linux.org.uk>
To: Tejun Heo <htejun@...il.com>
Cc: Matthew Wilcox <matthew@....cx>,
linux-pci@...ey.karlin.mff.cuni.cz, Greg KH <greg@...ah.com>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: question regarding cacheline size
On Thu, Sep 07, 2006 at 01:20:22PM +0200, Tejun Heo wrote:
> Matthew Wilcox wrote:
> >Just call pci_set_mwi(), that'll make sure the cache line size is set
> >correctly.
>
> Sounds simple enough. Just two small worries though.
>
> * It has an apparent side effect of setting PCI_COMMAND_INVALIDATE,
> which should be okay in sil3124's case.
>
> * The controller might have some restrictions on configurable cache line
> size. This is the same for MWI, so I guess this problem is just imaginary.
>
> For the time being, I'll go with pci_set_mwi() but IMHO it would be
> better to have a pci helper for this purpose -
> pci_config_cacheline_size() or something.
I've often wondered why we don't set the cache line size when we set the
bus master bit - ISTR when I read the PCI spec (2.1 or 2.2) it implied
that this should be set for bus master operations.
I've certainly seen PCI devices which can bus master and do have the
cache line size register but have the invalidate bit set forced to zero
in the command register.
Makes sense when you consider there are cache line considerations for
"memory read multiple" and "memory read line" bus commands in addition
to the "memory write and invalidate" bus command.
(Consider - if you use memory read line and haven't programmed the
cache line size, how does the master know how long a cache line is and
hence knows when to use this command?)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists