On Fri, 2007-06-08 at 23:02 +0200, Johannes Berg wrote:
On Fri, 2007-06-08 at 13:47 -0700, Greg KH wrote:
It's in my tree. It will be sent to Linus after 2.6.22 is out. Do you
think it needs to go in before 2.6.22 is final? If so, Alan, do you
agree?
Ah ok. Well, I haven't seen the
(such as PPC).
Signed-off-by: Alan Stern [EMAIL PROTECTED]
Looks good, thanks Alan
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE
The comparable routine in uhci-hcd includes this code:
if (!test_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags) || uhci-dead)
goto done;
and likewise, ehci_hub_status_data() includes this:
if (!HC_IS_RUNNING(hcd-state))
return 0;
Something similar
in
one file (I didn't agree but that's what David prefers...)
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Index: linux-powerpc-git/drivers/usb/host/ehci-hcd.c
diff -u linux-powerpc-git/drivers/usb/host/ehci-hcd.c:1.1.1.2
linux-powerpc-git/drivers/usb/host/ehci-hcd.c:1.4
--- linux
On Fri, 2007-01-05 at 08:45 +, Tony Olech wrote:
Hi Ben,
when I tried to include the file that defined the quirks,
ELAN's driver failed to compile.
Thanks for your interest in this issue.
ELAN is currently in favour of open source for linux drivers
of ELAN's hardware, and this type
On Thu, 2007-01-04 at 11:24 +, Tony Olech wrote:
Hi Dave,
The problem I was faced with was getting such things as the
OHCI register layout info, and the solution I came up with
was using the existing header file. It would certainly be
better if the definitions pertaining to the OHCI
On Wed, 2007-01-03 at 17:03 -0800, Andrew Morton wrote:
On Thu, 14 Dec 2006 14:13:28 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
This patch separates support for big endian MMIO register access
and big endian descriptors in order to support the Toshiba SCC
implementation which
On Wed, 2007-01-03 at 17:03 -0800, Andrew Morton wrote:
On Thu, 14 Dec 2006 14:13:28 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
This patch separates support for big endian MMIO register access
and big endian descriptors in order to support the Toshiba SCC
implementation which
On Wed, 2006-12-20 at 13:59 -0800, Greg KH wrote:
On Wed, Dec 13, 2006 at 09:09:55PM +0100, Sylvain Munaut wrote:
PPC embedded systems can have a ohci controller builtin. In the
new model, it will end up as a driver on the of_platform bus,
this patches takes care of them.
of the patch are to convert readl(...) to
ehci_readl(ehci, ...) and similarly for register writes.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
---
A replacement for my 3rd patch.. had a buglet as the Toshiba
On Fri, 2006-12-15 at 06:35 +1100, Benjamin Herrenschmidt wrote:
This patch implements supports for EHCI controllers whose MMIO
registers are big endian and enables that functionality for
the Toshiba SCC chip. It does _not_ add support for big endian
in-memory data structures
This version fixes a stupid bug in the quirks mecanism (passing an
ohci_hcd and expecting an usb_hcd pointer... thanks non-typed
function pointer).
All the patches have been rebased to apply on top of Greg's pending USB
patch queue for 2.6.20
These patches are reworked versions of the patch I
-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
drivers/usb/host/Kconfig| 10 ++
drivers/usb/host/ohci-pci.c | 26 +++
drivers/usb/host/ohci-ppc-soc.c |2
drivers/usb/host/ohci.h | 147 +---
4
of the patch are to convert readl(...) to
ehci_readl(ehci, ...) and similarly for register writes.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
drivers/usb/host/Kconfig |5 +
drivers/usb/host/ehci
Huh. I guess that part of the PCI model has virtues I'm not used to
thinking of. Does that pseudo-configspace cover *all* configuration
for each controllers? Or are things like clocks, clock gating, and
other chip configuration stuff still in separate registers?
Separate. Beside, I'm not
... assuming you fix the OHCI_BIG_ENDIAN_MMIO typo and #ifdef,
and other stuff as noted below. And that you sanity checked it
on some x86 PC, since I didn't make time for that and since we'd
all be unhappy if there were some goof in this area. ;)
I'll try to find an x86 box to boot it on
On Mon, 2006-12-11 at 23:19 -0800, David Brownell wrote:
Acked-by: David Brownell [EMAIL PROTECTED]
... assuming you address the minor comments embedded in the text below.
There was only one comment about a comment... right ? :-)
Ooh, my eyes hurt from all those little one-line changes.
-static inline unsigned int ohci_readl (const struct ohci_hcd *ohci,
- __hc32 __iomem * regs)
+static inline unsigned int _ohci_readl (const struct ohci_hcd *ohci,
+ __hc32 __iomem * regs)
Hmm, didn't
Note: This version addresses David's comments and was quickly tested on
x86 with EHCI. I haven't tested x86 with OHCI due to lack of
hardware, all the x86 boxes here have UHCI junk instead.
All the patches have been rebased to apply on top of Greg's pending USB
patch queue for 2.6.20
These
properly
set before we try to init the controller when using those quirks
for endian swapping (next patch).
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
Index: linux-test-x86/drivers/usb/host/ohci-pci.c
-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
Index: linux-test-x86/drivers/usb/host/ohci-pci.c
===
--- linux-test-x86.orig/drivers/usb/host/ohci-pci.c 2006-12-13
12:58:58.0 +1100
and I hope it will never be.
The guts of the patch are to convert readl(...) to
ehci_readl(ehci, ...) and similarly for register writes.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
Index: linux
of the patch are to convert readl(...) to
ehci_readl(ehci, ...) and similarly for register writes.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
---
Resent with proper subject line, sorry...
Index: linux-test
On Sat, 2006-12-09 at 17:55 +1100, Benjamin Herrenschmidt wrote:
This patch applies David Brownell's suggestion for reworking the
OHCI quirk mecanism via a table of PCI IDs. It adapts the existing
quirks to use that mecanism.
Note that I haven't moved the quirks to reset() as suggested
(This updated version moves the OHCI quirks to the reset callback so
they are run before the controller is initialized, as suggested by
a comment already in the code)
These patches are reworked versions of the patch I posted on behalf of
Toshiba a while ago. I've reworked things significantly,
-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
drivers/usb/host/Kconfig| 10 ++-
drivers/usb/host/ohci-pci.c | 25
drivers/usb/host/ohci-ppc-soc.c |2
drivers/usb/host/ohci.h | 119 ++--
4 files changed, 101 insertions(+), 55
Ishizaki [EMAIL PROTECTED]
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
drivers/usb/host/Kconfig |5 +
drivers/usb/host/ehci-dbg.c | 24
drivers/usb/host/ehci-fsl.c |8 +-
drivers/usb/host/ehci-hcd.c | 92 +---
drivers/usb/host
before we try to init the controller.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
drivers/usb/host/ohci-pci.c | 173 +++-
1 file changed, 110 insertions(+), 63 deletions(-)
Index: linux-work/drivers/usb/host/ohci-pci.c
On Fri, 2006-12-08 at 22:06 -0800, David Brownell wrote:
I'm saying that putting chip-specific workarounds in core driver code
is less attractive than sticking them in bus glue that's specific to
that chip ... especially in cases like this, where the workaround is
essentially writing a
A fake PCI? Strange. It'd make more sense to stick things
onto some bus that's a more direct match. And to make all
those platforms represent IOIF the same way ... reading between
the lines, I suspect you had multiple Linux teams at work, who
didn't cooperate as closely as might have been
+ ohci-flags |= OHCI_BIG_ENDIAN_MMIO;
ANd that should be OHCI_QUIRK_BE_MMIO. Damn, I was sure I test built it,
but I screwed with my .config ...
David, I'll send a new patch, but not before you send me some feedback
in case there are other things to fix.
Cheers,
Ben.
On Sun, 2006-12-10 at 08:29 +1100, Benjamin Herrenschmidt wrote:
+ ohci-flags |= OHCI_BIG_ENDIAN_MMIO;
ANd that should be OHCI_QUIRK_BE_MMIO. Damn, I was sure I test built it,
but I screwed with my .config ...
David, I'll send a new patch, but not before you send me some feedback
not certain if doing so might have side effects.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
drivers/usb/host/ohci-pci.c | 155
1 file changed, 100 insertions(+), 55 deletions(-)
Index: linux-work/drivers/usb/host/ohci-pci.c
These patches are reworked versions of the patch I posted on behalf of
Toshiba a while ago. I've reworked things significantly, mostly to
address David's concerns and my own issues. I've also split the patch.
- Patch 1 : Rework the OHCI quirk mecanism as suggested by David
- Patch 2 : Implement
-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
drivers/usb/host/Kconfig| 10 ++-
drivers/usb/host/ohci-pci.c | 25
drivers/usb/host/ohci-ppc-soc.c |2
drivers/usb/host/ohci.h | 119 ++--
4 files changed, 101 insertions(+), 55
Ishizaki [EMAIL PROTECTED]
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
drivers/usb/host/Kconfig |5 +
drivers/usb/host/ehci-dbg.c | 24
drivers/usb/host/ehci-fsl.c |8 +-
drivers/usb/host/ehci-hcd.c | 92 +---
drivers/usb/host
On Wed, 2006-11-29 at 11:37 -0500, Alan Stern wrote:
Or export a template structure with default values which could be copied.
That is possible, though is a bit more overhead in some cases than
exported functions by the module.
For the second issue, the core could auto load the sub
On Fri, 2006-11-24 at 00:57 -0800, Greg KH wrote:
On Thu, Nov 23, 2006 at 05:12:00PM +0100, [EMAIL PROTECTED] wrote:
From: Nicolas DET [EMAIL PROTECTED]
Hm, is this really from you? The copyright doesn't look like it.
I need a signed-off-by: please, along with a good description of what
I haven't been following this very closely. The problem is that you have
a system with two different kinds of OHCI controllers, thus requiring two
different and incompatible versions of the driver?
Sort-of. Basically, PowerPC can (and must in some case) build a single
kernel image that can
On Tue, 2006-11-07 at 10:17 -0500, Alan Stern wrote:
On Tue, 7 Nov 2006, Benjamin Herrenschmidt wrote:
Just so that you know -- I'm in the middle of submitting one or more
patches that do MMIO in ehci-hcd. Once Greg has accepted them you will
have to update your patch to change my
On Mon, 2006-11-06 at 10:58 -0800, David Brownell wrote:
On Saturday 04 November 2006 10:42 pm, Benjamin Herrenschmidt wrote:
The issue is that those have an EHCI/OHCI pair which has big endian
registers but little manipulates DMA data structures in little endian
form (some would say
Just so that you know -- I'm in the middle of submitting one or more
patches that do MMIO in ehci-hcd. Once Greg has accepted them you will
have to update your patch to change my patch's readl() and writel() calls
to ehci_readl() and ehci_writel(). No big deal.
There doesn't seem to be
On Sun, 2006-11-05 at 12:25 -0500, Alan Stern wrote:
On Sun, 5 Nov 2006, Benjamin Herrenschmidt wrote:
Hi !
I'm sending this patch on behalf of Toshiba. This version of the patch
is mostly for comments, I'll forward a more final one as soon as I get
it from them, possibly addressing
Hi !
I'm sending this patch on behalf of Toshiba. This version of the patch
is mostly for comments, I'll forward a more final one as soon as I get
it from them, possibly addressing comments you guys might have.
The goal is to have that in 2.6.20 along with the support for the
platforms that need
: Greg KH [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Mauro Carvalho Chehab [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED
+ /* Set brightness in backlight device */
+ up(pdata-bd-sem);
+ pdata-bd-props-brightness = brightness;
+ down(pdata-bd-sem);
Ditto. If it's attempting to synchronise against appledisplay_work() in
some way then I'd have thought it was racy..
Heh, smells to me like Michael
On Thu, 2005-12-22 at 08:04 +1000, Nigel Cunningham wrote:
Hi.
Originally sent to LKML, but Greg said this is the place...
I have a HT box with USB mouse support built as modules. Beginning with
2.6.15-rc5 (maybe slightly earlier) a suspend/resume cycle makes the USB
mouse get in an
It's a suspend to disk cycle or to ram ? Do you get those IRQs when you
move the mouse or all the time ? What is irq 99 normally on your
system ?
Well, I'm not sure what that vector 99 thing is, it's x86 world, might
not be an interrupt number... Since it's suspend to disk though, I would
Remember that usb_device suspend is managed only by usbcore,
and drivers themselves connect to a usb_interface of which
several generally exist.
Don't even _think_ of usb_suspend_device() as anything more than
an internal helper routine. Yes, called by the generic suspend
routine that
That's not quite true. usbcore is aware of remote wakeup signals and will
automatically take care of resuming the device and all its interfaces.
Remember, though, that everything you do will be experimental and subject
to change once the runtime PM infrastructure is ready.
By
On Mon, 2005-11-21 at 11:58 -0500, Alan Stern wrote:
Greg:
The earlier USB locking updates didn't touch the suspend/resume routines.
They need updating as well, since now the caller holds the device
semaphore. This patch (as608) makes the necessary changes. It also adds
a line to store
The infrastructure for dynamic local PM hasn't been created yet, so for
now you can do pretty much whatever you like. Not long ago David added a
usb_suspend_root_hub routine to usbcore to help with such things; I don't
know if you will want to use it.
The safest thing is to call
On Thu, 2005-11-24 at 18:18 -0500, Alan Stern wrote:
On Fri, 25 Nov 2005, Benjamin Herrenschmidt wrote:
Ok, so my driver should dpm_runtime_suspend() on itself, which will
cause the driver-suspend() routine to be called from which I can then
call usb_suspend_device(), right ?
It's hard
On Tue, 2005-11-01 at 09:28 +, Alan Cox wrote:
On Maw, 2005-11-01 at 14:30 +1100, Benjamin Herrenschmidt wrote:
Damn, those quirks should really be either more careful or be made
platform specific if they are x86 junk workarounds.
USB handoff is fairly x86 specific. The x86 folks took
On Mon, 2005-10-31 at 16:23 +1100, Paul Mackerras wrote:
My G4 powerbook gets a machine check on boot as a result of commit
478a3bab8c87a9ba4a4ba338314e32bb0c378e62. Putting a return at the
start of quirk_usb_early_handoff fixes it.
The code in quirk_usb_handoff_ohci looks rather bogus in
No PCI quirk code has ever called pci_enable_device() AFAICT.
Most PCI quirks only do config space accesses
Of course the _need_ to do such a thing might be another PPC-specific
(or OpenFirmware-specific?) PCI thing ... we've hit other cases where
PPC breaks things that work on other PCI
On Mon, 2005-10-31 at 19:09 -0800, David Brownell wrote:
On Monday 31 October 2005 6:41 pm, Benjamin Herrenschmidt wrote:
No PCI quirk code has ever called pci_enable_device() AFAICT.
Most PCI quirks only do config space accesses
Some do I/O space access. Few do memory space access
On Tue, 2005-11-01 at 15:52 +1100, Paul Mackerras wrote:
David Brownell writes:
Maybe you should first pay attention to what I pointed out: that
the problem reports I've seen have ONLY been on PPC systems.
Well, there is a problem in the code which is clearly visible just by
This is consistent with Ben's comments.
I don't read PPC assembly ... what's that mean in C? :)
What I posted David, didn't you see my post ? In fact you did as you
also replied :)
I can try sleeping it with the mouse disconnected over the next couple
of days. It seems to me that the
On Mon, 2005-05-09 at 07:31 -0700, David Brownell wrote:
On Monday 09 May 2005 2:25 am, John Steele Scott wrote:
On Sun, 2005-05-08 at 13:13 -0700, David Brownell wrote:
Just to follow up on this, I just recently had the following oops:
Oops: kernel access of bad area, sig: 11 [#1]
I have vague memories of this being discussed at some length last year.
Nothing comprehensive came of it, except that perhaps the kdump code should
spin with irqs off for a couple of seconds so the DMA and IRQs stop.
(Ongoing DMA is not a problem actually, because the kdump
-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Benjamin Herrenschmidt [EMAIL PROTECTED]
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which
://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Benjamin Herrenschmidt [EMAIL PROTECTED]
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users
Yes.
I believe it should just do suspend(PMSG_SUSPEND) before system
shutdown. If you think distintion between shutdown and suspend is
important (I am not 100% convinced it is), we can just add flag
saying this is system shutdown.
Actually this patch should be in the queue somewhere...
On Mon, 2005-04-25 at 13:12 -0700, Greg KH wrote:
People are starting to submit patches for pci drivers that add reboot
notifier hooks, under the guise of fixing up kexec issues with those
drivers.
That is why I proposed this patch, to make it easier for such drivers to
shutdown properly,
So if I understand this correctly, you'd like to manually turn off devices
during a power off. I believe the ACPI spec recommends this for S4 (but
also
to leave on wake devices), but not necessarily S5. Still it may be a good
idea. Comments?
It is neccessary for some machines
the ports unpowered; so I still
need my usb-ehci-power.patch that re-powers ports unconditionnaly.
OK, I just posted the patch cleaning up EHCI port power switching;
that should remove the need for that separate patch. (As well as
fixing some minor annoyances.)
- Dave
--
Benjamin
On Wed, 2005-04-06 at 16:28 -0700, David Brownell wrote:
On Wednesday 06 April 2005 4:02 pm, Benjamin Herrenschmidt wrote:
Thanks for the testing update. I'm glad to know that there seems to
be only one (minor) glitch that's PPC-specific!
Which is just an off-the-shelves NEC EHCI
,
Steve
Stephen Winiecki
PowerPC Embedded Processor Solutions
IBM Microelectronics Division
YM5A/Bldg. 062
3039 Cornwallis Rd.
Research Triangle Park, NC 27709
Telephone : (919) 543-4312 (IBM t/l 441) FAX: -7575
Internet : [EMAIL PROTECTED]
--
Benjamin Herrenschmidt [EMAIL PROTECTED
Hm, I'll look into doing that after 2.6.10, as it does make more sense
in the long run.
I agree. I remember playing with a USB driver in linux a while ago and
spending some time trying to figure out what was going on with byte
order :) I'd rather keep the raw HW (that is: well defined) byte
On Mon, 2004-11-29 at 09:04 +0100, Colin Leroy wrote:
On 27 Nov 2004 at 09h11, Benjamin Herrenschmidt wrote:
Hi,
It's probably a linux-wlan-ng issue...
I suspect PPC resume issues myself.
Colin, you didn't tell us which controller it was ? The NEC one is a
totally normal
On Mon, 2004-11-29 at 23:34 +0100, Colin Leroy wrote:
On 30 Nov 2004 at 09h11, Benjamin Herrenschmidt wrote:
Hi,
Hrm... there is some problem in communication here. I asked you which
controller out of the 3 OHCIs you have in this machine is the culprit,
you give me a list of all
On Fri, 2004-11-26 at 09:57 -0800, David Brownell wrote:
On Friday 26 November 2004 09:37, Colin Leroy wrote:
On 26 Nov 2004 at 09h11, David Brownell wrote:
This isn't a good patch either... maybe your best
bet would be to find out why the IRQs stopped getting
delivered.
It's
If you got the IRQ INTR_SF lossage diagnostic, there's clearly
some problem with IRQ handling after the resume ... is the iBook
firmware (or hardware) doing wierd stuff so that the normal PCI
IRQ calls stopped working?
The iBook hardware isn't doing anything special, the controller is just
be still important, at least on G4 powerpc ? remove_list is the 5th
software word here. Strange, because supposedly it works on x86 and
other uhci using arches, and it works on the G3, but not on the G4.
I think it's more likely we are dealing with an ordering issue of
accesses to memory vs.
On Fri, 2004-06-18 at 16:41, Alan Stern wrote:
On Fri, 18 Jun 2004, Benjamin Herrenschmidt wrote:
I think it's more likely we are dealing with an ordering issue of
accesses to memory vs. mmio, those aren't order unless you use memory
barriers. Actually, it's worse, you need a full mb
-Forwarded Message-
From: Soeren Sonnenburg [EMAIL PROTECTED]
To: Linux Kernel [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Subject: oops on wake up using usb-keyb/mouse on powerbook
Date: Thu, 10 Jun 2004 08:06:20 +0200
Hi!
I get this oops when I use a usb keyboard
mix both a PCI bus (thus little endian devices) and on-chip
big endian peripherals.
The conventions for providing access to chip registers are more
than a bit overloaded, too ... readl() and inw() etc will work
on most processors and busses, but the semantics change.
- Dave
--
Benjamin
So cool ...
I suppose there is no way it can easly be detected to at least printk
something ?
There are different ways to detect that condition, I don't have it all
in mind though, but i used to explicitely stop on error checking if the
next ep in the donelist was on the same ED.
There is
Huh, I thought those were guaranteed to return values in native byte
order on PCI ... something seems screwey there, it's not as if any
PCI device will treat bit 0 in its registers as MSB or LSB depending
on what kind of host you've got.
readl/writel will byteswap on big-endian architectures
But that is impossible as has already been pointed out by Alan Stern.
If a module creates a kobject, how can the module_exit() function ever
be called if that kobject incremented the module reference count?
I just had a lng discussion with Rusty on that subject, it's
indeed a nasty one.
I just had a lng discussion with Rusty on that subject, it's
indeed a nasty one.
Ah, he sucks another person into the module unload discussion. My
sympathies :)
Nah, I started it, since he is about 2 meters from me in the
office, that isn't difficult :)
I agree, it's a difficult
On Wed, 2004-03-31 at 09:55, Greg KH wrote:
Hi,
The patch below backs out Maneesh's sysfs patch that was recently added
to the kernel. In its defense, the original patch did solve some fixes
that could be duplicated on SMP machines, but the side affect of the
patch caused lots of problems.
It detects the device, downloads the firmware, the device disconnects,
but never reconnects. Here's the dmesg log. Worked fine with 2.6.4, we
tried with different keyspan adapters.
usb 1-1: new full speed USB device using address 2
drivers/usb/core/usb.c: registered new driver usbserial
Second, try it without connecting the Netgear MA101 rev B ... that
device didn't seem to have a driver (which was odd), but to actually
use it involves a firmware download followed by device reset. And
that logic is known-flakey.
If neither of those helps, then please repeat with
160x53
Generic RTC Driver v1.07
Macintosh non-volatile memory driver v1.1
pmac_zilog: 0.6 (Benjamin Herrenschmidt [EMAIL PROTECTED])
ttyS0 at MMIO 0x80013020 (irq = 22) is a Z85c30 ESCC - Serial port
ttyS1 at MMIO 0x80013000 (irq = 23) is a Z85c30 ESCC - Serial port
RAMDISK driver initialized: 16
NEC EHCI 1.0, or so I'm told. Standard PCI PM procedures
should work for that. If they really can't, then maybe
you should work this issue separately with Greg?
Looks like, but it's inside an Apple ASIC I think, which
probably means additional stuff, I have to look in Darwin
to be sure.
There'd be different controller-dying cases, since it
was breaking the locking rules. And indirecting through
a pointer that had no value at that point (giving the
compiler warning) is clearly oopsable...
Yup.
Ben.
---
This SF.Net
On Sat, 2004-03-06 at 04:32, David Brownell wrote:
Benjamin Herrenschmidt wrote:
Hi David !
While looking at the remaining diffs between my tree and Linus,
I found some OHCI related bits.
Here's a patch. It does the following:
- Move the pmac specific PM bits where they should
Hi David !
While looking at the remaining diffs between my tree and Linus,
I found some OHCI related bits.
Here's a patch. It does the following:
- Move the pmac specific PM bits where they should be (hcd-pci.c)
- Add a fix for a crash that I had when the HCD died
- Remove a bogus
Well, usb_device-bus-controller is the only access that
should be needed ... much prettier than a tree walk! It's
set up as part of device enumeration.
Some of the usb_buffer_*() mapping calls could probably
start to get inlined now, using the generic DMA calls.
It all depends what the
On Sat, 2004-02-21 at 06:32, Linus Torvalds wrote:
On Fri, 20 Feb 2004, Hollis Blanchard wrote:
Well, I was picturing all those *_dma_supported() functions as being
plugged into (new) fields in struct bus_type:
struct bus_type {
...
int
On Fri, 2004-02-20 at 16:58, Linus Torvalds wrote:
On Thu, 19 Feb 2004, Greg KH wrote:
Here are some USB patches for 2.6.3. Here are the main types of changes:
- switch usb code to use dmapools instead of pcipools which
makes the embedded people happy.
However, this makes
On Fri, 2004-02-20 at 17:30, Linus Torvalds wrote:
On Fri, 20 Feb 2004, Benjamin Herrenschmidt wrote:
A while ago, I've advertised making this API a set of function
pointers attached to the struct device inherited from the bus
parent, so the core code just set one for the root PCIs
if anybody ever passes a non-PCI-related struct device to the
thing).
Let's see if it boots too. So far it's only compiled successfully ;)
Linus
--
Benjamin Herrenschmidt [EMAIL PROTECTED]
---
SF.Net is sponsored by: Speed Start
As for the bigger generic dma mapping discussions for devices, hasn't
this been hashed out a bunch already? For some reason I thought
everyone was happy for now with the way things work, and for 2.7 it was
going to be expanded a bit to help support non-pci based busses (much
like the ARM
Basically, we only care about host devices, since anything else is going
to be talked to through a driver and is thus not even platform-dependent
any more. See what I'm saying?
I see. Well... as long as the actual dma mapping calls are always
done at the host controller level, that's fine
You miss how all of this stuff is being used :-)
USB drivers do things like map DMA memory, and the generic DMA layer vectors it
so that if the USB device is attached to a PCI host the PCI DMA mapping routines
get used.
Hrm... so if the USB device drivers are actually doing the dma mapping
parameters. With PCI, you could even stuff this into pci_bus-sysdata.
I think having a function pointer table for things like dma mapping
and ioremap on all devices would be a very good thing, but not sure
if the powers that be would allow that in 2.6.
~Deepak
--
Benjamin Herrenschmidt [EMAIL
On Sun, 2003-10-12 at 05:59, Greg KH wrote:
On Sat, Oct 11, 2003 at 06:10:14PM +0200, Benjamin Herrenschmidt wrote:
Hi Folks !
There's a small issue with drivers/usb/serial/keyspan_usa90msg.h
The definition for MSR_RI conflicts with some PowerPC CPU definition
(MSR is the Machine
1 - 100 of 135 matches
Mail list logo
