es it time to sleep (I have
mine set to 3 minutes right now)
3) "on/off" button on keyboard
4) hdparm -Y /dev/hda (this case still generates similar errors.)
This patch does NOT fix another symptom:
o "irq timeout: status=0xd0 { Busy }" followed by "ide0: reset
definitely
a better solution. I just have no clue how to implement it.
thanks,
grant
Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://w
ware doesn't know *anything* about the PCI devices and the arch
support has to set everything up - PCI MMIO space is not currently
supported there. And new servers (like L2000 or A500) with "PAT PDC" only
initialize PCI devices for boot. OS has to initialize the rest.
grant
Grant
rt regions is the access method.
Access method varies by platform (for parisc arch) and I don't
want to see user apps encoding the access method for specific platforms
by default. If someone intentionally wants to build an app for a
specific platform, that's different.
grant
Grant Grundler
parisc-linux {PCI
in the near
future so parisc builds actually work from linus' tree.
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
Index: drivers/pci/Makefile
===
RCS file: /home/cvs/parisc/linux/drivers/pci/Makefile,v
these chips further confirms my
theory :-)
Yup. *sigh*. Between chip bugs, tradeoffs of performance, time to market,
and simple programming interface, things got pretty ugly (its the
old saying about "Pick any two").
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.
a and parisc/PAT_PDC systems don't use this
code since the registers programmed in pci_setup_bridge().
This makes me think none of the other arches attempt to
support PCI-PCI bridges. Is that correct?
thanks,
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
To unsubscribe
nd see if I can find a machine locally
which has this same "feature").
thanks,
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
l do (some of?) the routing.
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please r
Ivan Kokshaysky wrote:
On Fri, Mar 02, 2001 at 11:32:35AM -0800, Grant Grundler wrote:
Code in parisc-linux CVS (based on 2.4.0) does boot on my OB800
(133Mhz Pentium), C3000, and A500 with PCI-PCI bridge support
working. I'm quite certain PCI-PCI bridge configuration (ie BIOS
didn't
od exchange since it's forcing me to revisit
code I haven't looked at in a few monthes with a fresh perspective.
This (and my previous) reply took me about 4 hours to write.
I have to keep looking at code. :^)
Ivan.
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.
etchable Memory - do we need to deal with it? Though looking
at modern x86 systems I tend to keep it disabled :-)
Ditto for parisc.
3. pdev_enable_device() - it's a bit ugly, confuses people and
possibly is not needed at all.
Agreed.
thanks,
grant
Grant Grundler
parisc-linux {PCI|IOMMU
On parisc-linux mailing list, Grant Grundler wrote:
After surveying all the arches that define __HAVE_ARCH_CMPXCHG:
./include/asm-alpha/system.h:#define __HAVE_ARCH_CMPXCHG 1
./include/asm-i386/system.h:#define __HAVE_ARCH_CMPXCHG 1
./include/asm-ia64/system.h:#define __HAVE_ARCH_CMPXCHG 1
specific optimisers might
re-order the "elem-next = list-head" statement to be quite a bit more
than 1 or 2 cycles from the xchg() operation.
thanks,
grant
Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253
-
To unsubscribe from this list: send the line "unsubscribe lin
ooops...
--- Forwarded Message
[EMAIL PROTECTED]: host vger.rutgers.edu[128.6.14.121] said: 550
[EMAIL PROTECTED]... User unknown
Date: Fri, 3 Nov 2000 09:54:19 -0800 (PST)
From: Grant Grundler [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: PATCH
site to merging upstream (either to Alan Cox or Linus).
thanks,
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
.
grant
Grant Grundler
parisc PCI|IOMMU|SMP hacker
+1 408-447-7253
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
Hi Ivan, Jeff,
Appended is the 2.4.4 patch for PCI Fast Back-Back (FBB) support.
Could you please review/comment on it?
Some caveats/notes:
o Since I'm on the road (visiting relatives in Germany mostly, currently
in Zurich), I'm only able to verify it boots on my Omnibook 800.
PA-RISC port
Hi Ivan,
Can you explain why pci_assign_unassigned_resources()
calls pdev_enable_device() for every PCI device instead
of having each PCI *driver* call pci_enable_device()
as part of driver initialization?
I'm thinking I missed something that a comment in the code
should have explained.
After
s instead of hacking this in pci_bus_fixup() later.
thanks,
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
the driver to just ignore MSI and not use it.
ie use regular PCI IRQ lines for interrupts.
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Philipp Rumpf wrote:
On Wed, 14 Feb 2001, Grant Grundler wrote:
Having people look things up in the spec isn't very user friendly.
Having the constants in some well-known header file should be sufficient,
shouldn't it ?
I would hope anyone bothering to include the constants in a document
On Thu, Mar 15, 2007 at 11:37:20AM +0900, Tejun Heo wrote:
...
Also, the current implementation doesn't have any arch independent part.
I thnk you meant arch dependent here.
It's wholly contained in arch independent PCI layer, but it might be
beneficial to have arch dependent hooks (IRQ
On Tue, Mar 27, 2007 at 07:23:16AM -0600, Eric W. Biederman wrote:
I guess I should add that I'm not certain that the code is exactly correct
there are weird differences between enable/disable and mask.
My understanding was enable would clear (or ignore) pending interrupts
and unmask would
On Mon, Mar 26, 2007 at 04:18:22PM -0700, Mitch Williams wrote:
This patch fixes a kernel bug which is triggered when using the
irqbalance daemon with MSI-X hardware.
Because both MSI-X interrupt messages and MSI-X table writes are posted,
it's possible for them to cross while in-flight.
On Sat, Mar 31, 2007 at 04:27:46PM +0530, Milind Arun Choudhary wrote:
Clean up ROUND_?UP, Use ALIGN where ever appropriate.
Signed-off-by: Milind Arun Choudhary [EMAIL PROTECTED]
Milind,
Looks good to me.
Signed-off-by: Grant Grundler [EMAIL PROTECTED]
Kyle,
can you remind me how
On Sun, Apr 01, 2007 at 01:06:46PM +0530, Milind Arun Choudhary wrote:
ROUND_UP macro cleanup, use ALIGN where ever appropriate
Signed-off-by: Milind Arun Choudhary [EMAIL PROTECTED]
Also looks good to me. Just one white space nit we can fixup by hand.
Signed-off-by: Grant Grundler [EMAIL
On Wed, Jan 09, 2008 at 03:30:58PM -0600, James Bottomley wrote:
...
Also, all of this is quite separate from the PCIe loose ordering
stuff. In fact, it's quite conceivable that SGI could hook up a PCIe
3.0 host bridge to the Altix NUMA interconnect, so that you could have
a PCI bus that
On Fri, Jan 11, 2008 at 02:27:16PM -0600, Kumar Gala wrote:
I'm getting the following message from the kernel on an embedded ppc32
system:
PCI: Failed to allocate mem resource #9:[EMAIL PROTECTED] for :00:00.0
The HW setup is a PCIe host controller and an e1000 NIC card.
...
I'm happy
On Thu, Nov 08, 2007 at 05:24:00PM -0600, Linas Vepstas wrote:
...
E.g. 4 port Gige card could directly support the host and 3 guests with
somewhat
lower risk of tromping on each other's MMIO space.
If Xen is cooperative, this seems a bit paranoid. I don't recall ever
seeing a
On Wed, Nov 14, 2007 at 08:17:33AM +1100, Benjamin Herrenschmidt wrote:
...
Though he's trying to fix a real issue, his patch is not the right
approach imho.
A better approach would be to have a mechanism to be triggered by the
hypervisor administration tools that will attempt to reassign
On Wed, Nov 14, 2007 at 07:16:18PM +1100, Benjamin Herrenschmidt wrote:
We already have that something: pci_enable_device().
The guest OS Arch code can then do the reassignment.
See 3.1 Enable the PCI device in Documentation/pci.txt.
No, that can't be done there because that would mean
Andrew,
Please include in -mm. Cosmetic - but I appreciate correct spelling too.
On Mon, Dec 17, 2007 at 11:30:11AM -0800, Joe Perches wrote:
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Signed-off-by: Grant Grundler [EMAIL PROTECTED]
thanks,
grant
---
include/asm-parisc/elf.h |2
Andrew,
ditto - thanks
On Mon, Dec 17, 2007 at 11:40:10AM -0800, Joe Perches wrote:
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Signed-off-by: Grant Grundler [EMAIL PROTECTED]
thanks again,
grant
---
drivers/parisc/ccio-dma.c |4 ++--
drivers/parisc/hppb.c |2 +-
2 files
to pci.txt that add
pci_enable_device_io() and _mmio() as well. )
Signed-off-by: Grant Grundler [EMAIL PROTECTED]
diff --git a/Documentation/pci.txt b/Documentation/pci.txt
index 7754f5a..72b20c6 100644
--- a/Documentation/pci.txt
+++ b/Documentation/pci.txt
@@ -274,8 +274,6 @@ the PCI device
Just a style nit...
On Tue, Dec 18, 2007 at 10:01:14AM +1100, Benjamin Herrenschmidt wrote:
This patch converts users of pci_enable_device_bars() to the new
pci_enable_device_{io,mem} interface.
The new API fits nicely, except maybe for the QLA case where a bit of
code re-organization might
On Tue, Dec 18, 2007 at 10:01:15AM +1100, Benjamin Herrenschmidt wrote:
This patch changes the PowerPC PCI code to disable IO and/or Memory
decoding on a PCI device when a resource of that type failed to be
allocated. This is done to avoid having unallocated dangling BARs enabled
that might
On Sun, Dec 23, 2007 at 03:16:24PM -0500, Loic Prylli wrote:
...
I just realized one thing: the bar sizing code in pci_read_bases() (that
writes 0x in the bars) does not seem to disable the
PCI_COMMAND_MEM/PCI_COMMAND_IO bits in the cmd register before
manipulating the BARs. And it
On Thu, Dec 20, 2007 at 02:40:06PM -0800, Greg KH wrote:
Sure, I realize this, but it solves the problem in one way for broken
hardware, such that it at least allows it to work, right? It also
provides a better incentive for the manufacturer to fix their bios,
which as you are on-site at HP,
On Wed, Dec 26, 2007 at 08:26:27AM +1100, Benjamin Herrenschmidt wrote:
This is exactly what's supposed to be happening, but the code is buggy
and nobody noticed :-) (I'm mixing up IORESOURCE_* flags and
PCI_COMMAND_* flags). Thanks for reviewing !
Note that this patch isn't in the
On Wed, Oct 24, 2007 at 11:17:40AM +0200, John Sigler wrote:
...
I've tested with a vanilla 2.6.22.10 kernel (no PREEMPT_RT patch).
That system also locks up and remains completely unresponsive (I can't open
new ssh sessions, the system won't answer ICMP echo requests).
How do driver writers
On Sun, Oct 28, 2007 at 01:03:36PM -0700, Greg KH wrote:
On Sun, Oct 28, 2007 at 03:53:20PM -0400, Barak Fargoun wrote:
...
About your question: today, some of the hypervisors are using linux
kernel as their domain-0 (e.g. Xen). In order to implement direct
hardware access for these native
On Sun, Feb 10, 2008 at 07:51:22AM -0700, Matthew Wilcox wrote:
From: Matthew Wilcox [EMAIL PROTECTED]
Date: Sun, 10 Feb 2008 09:45:28 -0500
Subject: [PATCH] Change pci_raw_ops to pci_raw_read/write
...
-static int
-pci_read (struct pci_bus *bus, unsigned int devfn, int where, int size, u32
(dev-bus, PCI_DEVFN(8, 0), 0x4c, word);
Yeah, this should work even though we don't have a dev for it.
Acked-by: Grant Grundler [EMAIL PROTECTED]
thanks,
grant
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Mon, Feb 11, 2008 at 09:18:49AM -0800, Linus Torvalds wrote:
I put it in the commit message, but it wasn't on page 34 when I checked (I
changed it to 69),
Sorry - page 34 was just the first reference to Extended Configuration
Registers when I originally scrounged up the info for willy.
Page
...@gmail.com
Thanks! Looks good to me.
Acked-by: Grant Grundler grund...@parisc-linux.org
cheers,
grant
---
drivers/net/ethernet/dec/tulip/dmfe.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/dmfe.c
b/drivers/net
On Tue, Oct 23, 2012 at 1:02 PM, Kees Cook keesc...@chromium.org wrote:
This config item has not carried much meaning for a while now and is
almost always enabled by default. As agreed during the Linux kernel
summit, remove it.
CC: Grant Grundler grund...@parisc-linux.org
Acked-by: Grant
[+jejb to cc]
On Tue, Sep 25, 2007 at 04:58:43PM -0700, [EMAIL PROTECTED] wrote:
This is a followup to http://lkml.org/lkml/2007/8/24/280
Despite Grant's desire for a more elegant solution, there's
not much new here. I moved the API change from pci.h to
dma-mapping.h and removed the pci_
On Thu, Sep 27, 2007 at 06:13:02PM -0700, [EMAIL PROTECTED] wrote:
Document dma_flags_set_dmabarrier().
Signed-off-by: Arthur Kepner [EMAIL PROTECTED]
This looks really good!
thanks,
grant
Acked-by: Grant Grundler [EMAIL PROTECTED]
---
DMA-API.txt | 26
On Thu, Aug 30, 2007 at 03:46:56PM -0700, Jason Gaston wrote:
This updated patch adds the Intel Tolapai LPC and SMBus Controller DID's.
Signed-off-by: ?Jason Gaston [EMAIL PROTECTED]
--- linux-2.6.23-rc4/arch/i386/pci/irq.c.orig 2007-08-27 18:32:35.0
-0700
+++
On Sun, Aug 12, 2007 at 10:54:49AM -0400, Mathieu Desnoyers wrote:
Use the new generic cmpxchg_local (disables interrupt). Also use the generic
cmpxchg as fallback if SMP is not set.
Mathieu,
thanks for adding __cmpxchg_local to parisc but why do we need it?
By definition, atomic operators
On Fri, Aug 24, 2007 at 11:02:32AM -0700, [EMAIL PROTECTED] wrote:
On Altix, DMA may be reordered within the NUMA interconnect.
This can be a problem with Infiniband, where DMA to Completion
Queues can race with data DMA. This patchset allows a driver
to associate a memory region with a
,
grant
Diff+Commit entry against 2.6.22.5:
local_t is a variant of atomic_t and has related ops to match.
Add reference for local_t documentation to atomic_ops.txt.
Signed-off-by: Grant Grundler [EMAIL PROTECTED]
--- 2.6.22.5-ORIG/Documentation/atomic_ops.txt 2007-08-27 22:50:27.0
to DaveM
since he seems to be the maintainer of atomic_ops.txt.
cheers,
grant
thanks,
grant
Diff+Commit entry against 2.6.22.5:
local_t is a variant of atomic_t and has related ops to match.
Add reference for local_t documentation to atomic_ops.txt.
Signed-off-by: Grant
On Sat, Aug 25, 2007 at 07:55:56PM -0600, Matthew Wilcox wrote:
This patch, loosely based on a patch from Robert Hancock, which was in
turn based on a patch from Jesse Barnes, fixes a boot-time hang on my
shiny new PC. The 'conflict' mentioned in the patch in my case happens
to be between
On Tue, Aug 28, 2007 at 11:59:08AM -0600, Grant Grundler wrote:
On Sat, Aug 25, 2007 at 07:55:56PM -0600, Matthew Wilcox wrote:
This patch, loosely based on a patch from Robert Hancock, which was in
turn based on a patch from Jesse Barnes, fixes a boot-time hang on my
shiny new PC
[davem: patch for you at the bottom to Documentation/atomic_ops.txt ]
On Tue, Aug 28, 2007 at 02:38:35PM -0400, Mathieu Desnoyers wrote:
* Grant Grundler ([EMAIL PROTECTED]) wrote:
On Tue, Aug 28, 2007 at 07:50:18AM -0400, Mathieu Desnoyers wrote:
...
So I don't expect to come with an upper
On Wed, Aug 29, 2007 at 08:19:53AM -0400, Mathieu Desnoyers wrote:
local_t Documentation update 2
Grant Grundler was asking for more detail about correct usage of local atomic
operations and suggested adding the resulting summary to local_ops.txt.
Please add a bit more detail. If DaveM
On Wed, Aug 08, 2007 at 05:28:46PM -0700, Joe Perches wrote:
Some uses of printk are missing KERN_level on the second
and subsequent lines.
Nice! Thanks!
ACK the three parisc-linux bits.
thanks,
grant
For instance:
printk(KERN_INFO line1: %d\nline2: %d\n, val1, val2);
Line1 is
On Wed, Aug 08, 2007 at 12:56:41AM +0200, Rafael J. Wysocki wrote:
...
Apologies, I missed this. I'll look to our new tulip maintainer to
queue your resent patch, or at least ACK it...
OK
Below is the updated version. It's functionally equivalent to the previous
one.
ACK. Looks
.
thanks
grant
Signed-off-by: Grant Grundler [EMAIL PROTECTED]
diff --git a/arch/parisc/kernel/smp.c b/arch/parisc/kernel/smp.c
index 04c7e1d..c9ce659 100644
--- a/arch/parisc/kernel/smp.c
+++ b/arch/parisc/kernel/smp.c
@@ -333,12 +333,12 @@ smp_call_function (void (*func) (void *info), void *info
On Mon, Jul 30, 2007 at 03:31:58PM -0400, Kyle McMartin wrote:
On Mon, Jul 30, 2007 at 01:04:13PM -0600, Valerie Henson wrote:
The Tulip network driver needs a new maintainer! I no longer have
time to maintain the Tulip network driver and I'm stepping down. Jeff
Garzik would be happy to
On Wed, Aug 01, 2007 at 04:55:00PM +0200, Michal Piotrowski wrote:
Hi,
Coding style fix
Acked-by: Grant Grundler [EMAIL PROTECTED]
thanks,
grant
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
Signed-off-by: Michal Piotrowski [EMAIL PROTECTED]
--- linux-mm-clean
On Thu, Aug 02, 2007 at 09:43:29AM -0700, Greg KH wrote:
...
It wasn't just MIPS. IBM has a very popular blade system that has huge
issues with this, and I think there are some other IBM systems based on
the same BIOS that also do bad things if we don't grab the USB
controller away from the
On Tue, Apr 05, 2005 at 10:15:18PM -0700, Gerrit Huizenga wrote:
SpecSDET, Aim7 or ReAim from OSDL are probably what you are thinking of.
SDET isn't publicly available.
I hope by now osdl-reaim is called osdl-aim7:
http://lkml.org/lkml/2003/8/1/172
grant
-
To unsubscribe from this list:
On Mon, Apr 11, 2005 at 10:54:25PM +0200, Jesper Juhl wrote:
Get rid of redundant NULL pointer checks before kfree() in arch/parisc/ as
well as a few blank lines.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
thanks!
Commited to cvs.parisc-linux.org:
On Sun, Feb 06, 2005 at 03:26:15PM +0100, Jean Delvare wrote:
Maarten Deprez then converted it to the proper kernel coding-style:
http://marc.theaimsgroup.com/?l=linux-kernelm=110726276414532
...
Any chance we could get the PCI folks to review the code and push it
upwards if it is OK?
I'm not
On Mon, Jan 31, 2005 at 01:40:04PM -0600, Brian King wrote:
CC'ing the linux-pci mailing list...
thanks...
This patch adds an arch hook so
that individual archs can indicate if the underlying system supports
expanded config space accesses or not.
@@ -653,6 +653,8 @@ static int
On Tue, Jul 05, 2005 at 01:46:20PM -0400, John W. Linville wrote:
On Sat, Jul 02, 2005 at 01:29:54AM -0600, Grant Grundler wrote:
On Thu, Jun 30, 2005 at 10:26:37PM -0400, John W. Linville wrote:
+ /* Some devices lose PCI config header data during D3hot-D0
Can you name some of those
On Tue, Jul 12, 2005 at 12:21:38AM +0200, Dominik Brodowski wrote:
In yenta_socket, we default to using the resource setting of the CardBus
bridge. However, this is a PCI-bus-centric view of resources and thus
needs to be converted to generic resources first. Therefore, add a call
to
On Thu, Jul 14, 2005 at 02:53:27PM +0100, Russell King wrote:
On Thu, Jul 14, 2005 at 03:53:44PM +0400, Ivan Kokshaysky wrote:
The setup-bus code doesn't work correctly for configurations
with more than one display adapter in the same PCI domain.
This stuff actually is a leftover of an
On Wed, Jul 06, 2005 at 02:11:42PM +0900, Hidetoshi Seto wrote:
[This is 5 of 10 patches, iochk-05-check_bridge.patch]
...
It means that A or B hits a bus error, but there is no data
which one actually hits the error. So, C should notify the
error to both of A and B, and clear the H's
On Sat, Jul 23, 2005 at 09:54:11PM +0200, Dominik Brodowski wrote:
Oh, yes, I seem to have missed it. Sorry. Does this patch look good?
Yes.
Acked-by: Grant Grundler [EMAIL PROTECTED]
I'll commit this to the cvs.parisc-linux.org tree as well.
Willy can let me deal with the collision if it's
Tom,
A co-worker made the following observation (I'm paraphrasing):
...this proposal does not deal with the Error Reporting ECN.
For example, they do not show the advisory non-fatal bit in
the correctable error status register.
I believe he is referring to the Error
On Tue, Mar 15, 2005 at 01:54:32PM -0800, Nguyen, Tom L wrote:
On Tuesday, March 15, 2005 12:12 PM Grant Grundler wrote:
Tom,
A co-worker made the following observation (I'm paraphrasing):
...this proposal does not deal with the Error Reporting ECN.
For example, they do not show
On Tue, Mar 15, 2005 at 04:51:01PM -0600, Linas Vepstas wrote:
Hi,
On Fri, Mar 11, 2005 at 04:12:18PM -0800, long was heard to remark:
+void hw_aer_unregister(void)
+{
+ struct pci_dev *dev = (struct pci_dev*)host-dev;
I'm more nervous about host being defined as a global
instead of
On Tue, Mar 15, 2005 at 01:11:39PM -0700, Grant Grundler wrote:
Tom,
A co-worker made the following observation (I'm paraphrasing):
...this proposal does not deal with the Error Reporting ECN.
For example, they do not show the advisory non-fatal bit in
the correctable error
On Fri, Mar 18, 2005 at 09:24:02AM -0800, Nguyen, Tom L wrote:
Likewise, with EEH the device driver could take recovery action on its
own. But we don't want to end up with multiple sets of recovery code
in drivers, if possible. Also we want the recovery code to be as
simple as possible,
On Tue, Mar 15, 2005 at 07:12:07PM -0700, Grant Grundler wrote:
...
He was referring to an unpublished draft Error Reporting ECN.
You'll have to talk to Intel's PCI-SIG representative to get a copy.
Good News: the Error Reporting ECN is now posted on the PCISIG website.
http
On Thu, Mar 31, 2005 at 07:52:06PM -0800, Jim Gifford wrote:
Grant
Thanx for your feedback. I got it working, but I don't think the
patch is the best. Here is the patch, and the information, but if you
can recommend a different way to fix it, let me know.
I can not reccomend one. I can
On Fri, Apr 01, 2005 at 08:46:33AM -0800, Jim Gifford wrote:
Code paths exist in tulip_select_media() where the last thing the
driver does to the NIC is io_write(). This could easily be a posted
write flush problem. Does replacing flush_cache_all() with
ioread32(ioaddr + CSR12) also work?
On Fri, Apr 01, 2005 at 12:23:25PM -0800, Jim Gifford wrote:
Grant,
Thank you, I took your driver as a reference and added in the cobalt
specifics to the eeprom.c file, works perfectly now.
Cool! very welcome.
Can you do me a favor and submit a diff of all the tulip changes
you have at
On Mon, Jan 24, 2005 at 10:29:52AM -0200, Marcelo Tosatti wrote:
Grant Grundler and James Bottomley have been working on this area,
they might want to add some comments to this discussion.
It seems HP (Grant et all) has pursued using big pages on IA64 (64K)
for this purpose.
Marcello
On Tue, Jan 25, 2005 at 09:02:34AM -0500, Mukker, Atul wrote:
The megaraid driver is open source, do you see anything that driver can do
to improve performance. We would greatly appreciate any feedback in this
regard and definitely incorporate in the driver. The FW under Linux and
windows is
On Thu, Jan 27, 2005 at 08:28:43AM -0800, Jesse Barnes wrote:
But then again,
I suppose if a platform supports more than one legacy I/O space,
Eh?! there can only be *one* legacy I/O space.
We can support multipl IO port spaces, but only one can be the legacy.
Moving the VGA device can only
On Fri, Jan 28, 2005 at 01:36:48PM -0500, Jon Smirl wrote:
If it is intended to work with multiple IO Port address spaces,
then it needs to use the pci_dev-resource[] and mangle that appropriately.
Post a patch an I will incorporate it.
Sorry - I only wanted to point out the short coming.
On Fri, Jan 28, 2005 at 02:26:40PM -0500, Jon Smirl wrote:
Next year we are going to see a lot of multiple VGAs. Depending on
configuration the Nvidia4 chipset can support from one up to eight PCI
Express video cards simultaneously.
Oh geezsomeone is going to implement IO port space on PCI
On Fri, Jan 28, 2005 at 10:41:41AM -0800, Jesse Barnes wrote:
Eh?! there can only be *one* legacy I/O space.
We can support multipl IO port spaces, but only one can be the legacy.
What do you mean? If you define legacy I/O space to be
0x-0x, then yes of
On Fri, Jan 28, 2005 at 11:41:16AM -0800, Jesse Barnes wrote:
Yeah, I think I understand. We could probably do the same thing on sn2
as you do on parisc--add a 'segment 0' offset to the port so that it's routed
correctly. I think that's a little less flexible than adding a new resource
On Thu, Jan 20, 2005 at 08:43:30AM +1100, Paul Mackerras wrote:
I suggest read_poll(), write_poll(), spin_poll(),...
Erm...those names sound way too much like existing interfaces.
Perhaps check_read_lock()/check_write_lock() ?
If they don't get used too much, the longer name should be ok.
Last year Seungwon Jeon (Samsung) fixed a bug in CLKDIV computation.
But when debugging a related issue (http://crbug.com/221828) I found
the code unreadable. This rewrite simplifies the computation and
explains each step.
Signed-off-by: Grant Grundler grund...@chromium.org
---
Tested on Samsung
I've attached the test program I wrote to compare the different
flavors of CLKDIV computation: old (3.4 kernel), current upstream, and
my rewrite.
thanks
grant
On Tue, Mar 26, 2013 at 3:50 PM, Grant Grundler grund...@chromium.org wrote:
Last year Seungwon Jeon (Samsung) fixed a bug in CLKDIV
Sorry - please ignore the previous version. Did not include a
copyright (implied to be mine...but it's not) nor license.
Same thing but with proper attribution.
cheers,
grant
On Tue, Mar 26, 2013 at 3:53 PM, Grant Grundler grund...@chromium.org wrote:
I've attached the test program I wrote
On Wed, Mar 27, 2013 at 5:25 AM, Seungwon Jeon tgih@samsung.com wrote:
On Wednesday, March 27, 2013, Grant Grundler wrote:
Last year Seungwon Jeon (Samsung) fixed a bug in CLKDIV computation.
For easily identifying, it would be good to point the commit id and subject.
commit id
On Wed, Mar 27, 2013 at 8:07 AM, Doug Anderson diand...@chromium.org wrote:
Grant,
Thanks for posting! See below...
thanks for reviewing/feedback! :)
On Tue, Mar 26, 2013 at 3:50 PM, Grant Grundler grund...@chromium.org wrote:
Last year Seungwon Jeon (Samsung) fixed a bug in CLKDIV
Hi Chris,
On Wed, Mar 27, 2013 at 10:58 AM, Chris Ball c...@laptop.org wrote:
Hi Grant,
...
Please use the following (standard) syntax in the commit message:
Commit e419990b5e8 (mmc: dw_mmc: correct the calculation for CLKDIV)
fixed a bug in CLKDIV computation. [..]
Ok - I didn't know that
When backporting Commit e419990b5e8 (mmc: dw_mmc: correct the
calculation for CLKDIV) to 3.4 kernel and debugging
a FW issue, I found the code unreadable. This rewrite simplifies
the computation and explains each step.
Signed-off-by: Grant Grundler grund...@chromium.org
---
V2: rewrote commit
On Thu, Sep 01, 2005 at 05:45:54PM -0500, Brent Casavant wrote:
...
The first is serialization of all I/O reads and writes. This will
be a severe problem on systems with large numbers of PCI buses, the
very type of system that stands the most to gain in reliability from
these efforts. At a
On Fri, Sep 02, 2005 at 06:56:35PM -0500, Brian King wrote:
Andrew Morton wrote:
Brian King [EMAIL PROTECTED] wrote:
+void pci_block_user_cfg_access(struct pci_dev *dev)
+{
+ unsigned long flags;
+
+ pci_save_state(dev);
+ spin_lock_irqsave(pci_lock, flags);
+
On Fri, Sep 02, 2005 at 11:16:10AM -0700, david mosberger wrote:
Sorry - I think this is BS.
Please run mmio_test on your box and share the results.
mmio_test is available here:
svn co http://svn.gnumonks.org/trunk/mmio_test/
Reads are slow, sure, but writes are not (or
1 - 100 of 626 matches
Mail list logo
