From: Noah J. Misch <hidden> Date: 2003-10-20 06:41:08
Greetings,
This is a trivial patch against the Kconfig entry for the VLSI FIR driver to
make it depend on X86. The in-tree code guarantees that the driver will only
build on X86, and according to the comments therein no machine of another
architecture has this hardware anyway.
Granted, no human intelligently configuring a kernel for his or her particular
system would make this mistake, but perhaps someone building a distribution
kernel would. I suggest this patch because it keeps the signal to noise ratio
for those testing allyesconfig builds low.
This patch applies to the linux-2.5 BK tree as of 0400 UTC 10/20/2003, and for
some time before that as well. Please consider for eventual inclusion. It may
be too much of a fringe case until 2.6.0 begins its stable series.
Thanks,
Noah
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1373 -> 1.1374
# drivers/net/irda/Kconfig 1.12 -> 1.13
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/10/16 noah@caltech.edu 1.1374
# Make VLSI_FIR depend on X86. Read the comment just above the #error in
# include/net/irda/vlsi_ir.h for the reason; for now, this driver can never
# compile elsewhere.
# --------------------------------------------
#
diff -Nru a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
--- a/drivers/net/irda/Kconfig Fri Oct 17 13:42:39 2003+++ b/drivers/net/irda/Kconfig Fri Oct 17 13:42:39 2003
From: Martin Diehl <hidden> Date: 2003-10-20 17:33:02
On Sun, 19 Oct 2003, Noah J. Misch wrote:
This is a trivial patch against the Kconfig entry for the VLSI FIR driver to
make it depend on X86. The in-tree code guarantees that the driver will only
build on X86, and according to the comments therein no machine of another
architecture has this hardware anyway.
Well, it would work with any arch, _if_ there was a way to sync the
streaming pci dma buffers before giving them back to hardware. Last time I
checked there was no pci_dma api call to achieve this on all platforms.
For X86 however it's trivial due to cache coherency.
The guy is used with X86 notebooks only - unless whoever owns the
controller design decides to make some CardBus PC-Card for people with
notebooks lacking IrDA-support.
Granted, no human intelligently configuring a kernel for his or her particular
system would make this mistake, but perhaps someone building a distribution
kernel would. I suggest this patch because it keeps the signal to noise ratio
for those testing allyesconfig builds low.
Valid point, yes.
This patch applies to the linux-2.5 BK tree as of 0400 UTC 10/20/2003, and for
some time before that as well. Please consider for eventual inclusion. It may
be too much of a fringe case until 2.6.0 begins its stable series.
From: David S. Miller <hidden> Date: 2003-10-21 07:17:58
On Tue, 21 Oct 2003 09:12:53 +0200 (CEST)
Martin Diehl [off-list ref] wrote:
Last time I checked pci_dma_sync was meant to sync the mapping when
ownership gets transferred from busmaster to cpu, i.e. after hardware
used/modified the buffer. What about the other direction when the cpu
filled a reused streaming map to device and wants to pass ownership to the
busmaster - we need to flush cpu caches to make sure the busmaster sees
the modified data.
That's absolutely correct.
Several times I've noted that this is a BUG in the API, that there
is no way to sync the other way, someone just has to add the interface
hooks then all the platform maintainers will implement it.
Here, do this, add a new interface called pci_dma_sync_to_device()
with the appropriate args. Add a NOP implementation to asm-i386/pci.h
and suitable documentation changes to Documentation/DMA-mapping.txt
When you send me that patch, I'll work with the platform maintainers
to take care of the rest.
Deal?
From: Martin Diehl <hidden> Date: 2003-10-21 07:36:10
On Tue, 21 Oct 2003, David S. Miller wrote:
Here, do this, add a new interface called pci_dma_sync_to_device()
with the appropriate args. Add a NOP implementation to asm-i386/pci.h
and suitable documentation changes to Documentation/DMA-mapping.txt
When you send me that patch, I'll work with the platform maintainers
to take care of the rest.
Deal?
Ok, Thanks. Will do it.
One more question: Shouldn't the i386 implementation instead of being NOP
just call flush_write_buffers() - at least this is what the vlsi-private
implementation is doing at the moment?
Martin
From: David S. Miller <hidden> Date: 2003-10-21 08:18:36
On Tue, 21 Oct 2003 09:33:24 +0200 (CEST)
Martin Diehl [off-list ref] wrote:
One more question: Shouldn't the i386 implementation instead of being NOP
just call flush_write_buffers() - at least this is what the vlsi-private
implementation is doing at the moment?