Has anyone hacked up PictBridge gadget-side support so that a device without
a host controller can speak to a printer?
Ciao,
-ch
ch--at--murgatroid.com
ch--at--hpl.hp.com
---
SF email is sponsored by - The IT Product Guide
Read honest & ca
> The other path introduced by my patch where IRQ_NONE can be returned
> gets used only at times when the controller is not running
> and hence is
> incapable of generating interrupts. So it shouldn't be a problem.
>
> Would this be satisfactory? Or do you prefer to change the
> core interrup
TED]
> Sent: Tuesday, February 08, 2005 12:58 PM
> To: Greg KH
> Cc: USB development list; Christopher Hoover
> Subject: [PATCH as460 (8/10)] USBcore: implement usb_add_hcd
> and usb_remove_hcd (SA)
>
> Greg:
>
> This patch contains the changes to the ohci-sa1
> So all I/O buffers _must_ be allocated using kmalloc()
Use GFP_DMA flag on the kmalloc() call, too, whenever possible.
/* Flag - indicates that the buffer will be suitable for DMA. Ignored
on some
platforms, used as appropriate on others */
#define GFP_DMA __GFP_DMA
This will
> So my first guess would be something related to sa platform
changes.
Yep. Found it. dev->dma_mask == 0, but that only began to matter
recently.
Cheers,
-ch
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get crac
>
> I'm seeng regression with OHCI under 2.5.65: my device, a Blue Gear
> B091H1 Bluetooth dongle, fails to accept its address under
> 2.5.65. If I reboot under 2.5.59, it works OK although I do
> get an initial "USB device not accepting new address".
Additional details:
I cannot get any of s
I upgraded my SA-1110/SA- platform from 2.5.59-rmk1 to 2.5.65-rmk1.
I'm seeng regression with OHCI under 2.5.65: my device, a Blue Gear
B091H1 Bluetooth dongle, fails to accept its address under 2.5.65. If
I reboot under 2.5.59, it works OK although I do get an initial "USB
device not accep
> Perhaps it would be better to hand parse the structure out?
That's certainly a workable solution. Any structures passed up from
user space to the kernel would likewise need to be similarly hand
parsed. We need to audit the code to see where else this might show up.
Another possibility is to
libusb (cvs development branch) fails on ARM and probably on other RISC
architectures under Linux because key structures passed from the kernel
to user space differ in the use of the packed attribute.
In particular struct usb_device_descriptor comes up as 20 bytes in user
space and as 18 bytes in
> Why? What is that needed for? Oh wait, you don't have a pci device,
> right?
Correct.
>So where in the device tree does the sa111 controller show up?
>What type of bus is it on?
rmk and pat worked this out:
/sys/bus/system/devices/SA0
/sys/bus/RAB/devices/0400
[ Sorry; this time without patch mangling ... ]
Dereferencing hcd.pdev will always oops with SA-. It has to be
treated as a cookie, not a pointer in any common OHCI HCD code.
Apparently we need a clean way to go from struct device * to struct
ohci_hcd *. I added dev_to_ohci that does the o
-Original Message-
From: [EMAIL PROTECTED]
[mailto:linux-arm-kernel-admin@;lists.arm.linux.org.uk] On Behalf Of
Christopher Hoover
Sent: Monday, October 28, 2002 4:03 PM
To: [EMAIL PROTECTED]
Cc: Linux-Arm-Kernel (Linux-Arm-Kernel); David Brownell
Subject: [PATCH] 2.5.44 SA- ohci-hcd
Dereferencing hcd.pdev will always oops with SA-. It has to be
treated as a cookie, not a pointer in any common OHCI HCD code.
Apparently we need a clean way to go from struct device * to struct
ohci_hcd *. I added dev_to_ohci that does the obvious thing and added
separate implementations f
I'll look into this as soon as I can get a chance, but in the meantime
here's a quick FYI:
For 2.5.40-rmk1 on ARM:
CONFIG_USB_OHCI_HCD=m doesn't link because of unresolved symbols.
Something is screwy with the pci/dma exports.
CONFIG_USB_OHCI_HCD=y doesn't boot. It oopses in device_create_fil
>> The arm changes should be split into clean, logical
>> chunks and placed in the ARM patch system.
> By arm changes do you mean just the DMA stuff or the OHCI SA
changes
> as well?
rmk and Linus and the other maintainers require patches to be separated
into small, discrete pieces. It mak
Matthew Dharm wrote:
> See my patches from yesterday for the fix for this.
Yep. That did it. Thanks.
-ch
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
__
This device worked in 2.5.24-rmk1.
-ch
# modprobe usb-storage
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
scsi0 : SCSI emulation for USB Mass Storage devices
Vendor: TREK2000 Model: TD-G2 Rev: W1.1
Type: Direct-Access
Unlike previous version, this one doesn't oops and is perspicuous.
Please apply.
--- linux-2.5.26-rmk1/drivers/usb/core/usb.cTue Jul 16 16:49:34 2002
+++ linux-2.5.26-rmk1-ch1/drivers/usb/core/usb.cMon Jul 22 10:49:05 2002
@@ -1221,56 +1221,59 @@ int usb_set_address(struct usb_device
The second strchr was returning 0.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On
> Behalf Of David Brownell
> Sent: Monday, July 22, 2002 8:03 AM
> To: Christopher Hoover
> Cc: [EMAIL PROTECTED]
> Subject: Re:
> I will not take new patches for MixedCase variables, sorry.
Sigh. OK, I'll change it.
> And what exactly is this patch trying to fix? What is wrong
> with the existing code?
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=102732358205252&w=2
> Do you have a specific device that th
This version doesn't oops and is perspicuous.
I haved tested it in the "both strings" case (which made the old code
oops) and in the "no strings" case.
-ch
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--- linux-2.5.26-rmk1/drivers/usb/core/usb.cTue Jul 16 16:49:34 2002
+++ linux-2.5.26-rmk1-ch1/d
set_device_description is oopsing with a null pointer at boot for me on
2.5.26-rmk1 with ohci-hcd on sa-. The problem apparently is the new
code that computes a clever name for the device -- a "return" statement
after the first sprintf() gets around the problem. If the problem isn't
obvious
This is needed by 2.5.26-rmk1. greg k-h: please apply.
--- linux-2.5.26-rmk1/drivers/usb/host/ohci-sa.cSun Jul 21 18:29:34 2002
+++ linux-2.5.26-rmk1-ch1/drivers/usb/host/ohci-sa.cSun Jul 21 21:03:22
+2002
@@ -14,6 +14,7 @@
*/
#include
+#include
#include
#include
> > > drivers/built-in.o: In function `sa_ohci_init':
> > > drivers/built-in.o(.text.init+0x3bb4): relocation truncated
> > > to fit: R_ARM_PC24 text.exit
> > > drivers/built-in.o(.text.init+0x3c08): relocation truncated
> > > to fit: R_ARM_PC24 text.exit
> >
>
> Looks like __init code call
gt;>r6; c040ec00 <_end+97be8/491efe8>
>>r4; c040ec60 <_end+97c48/491efe8>
Trace; c02c7828
Trace; c4ca0f04 <[pwc]pwc_isoc_cleanup+4c/6c>
Trace; c4ca0eb8 <[pwc]pwc_isoc_cleanup+0/6c>
Trace; c4ca0f4c <[pwc]pwc_try_video_mode+28/a8>
Trace; c4ca0f24 <[pwc]pw
uffer 0 at c4cfe000.
pwc Allocated frame buffer 1 at c4d7.
pwc Allocated frame buffer 2 at c4de2000.
{boom!}
Hewlett-Packard Laboratories Badge-4
Blob port by Christopher Hoover <[EMAIL PROTECTED]>
SDRAM: 64 Mbytes (row bits=12, col bits=9)
SDRAM: setting type typ1=0, typ0=1
Consid
While usb-storage is happy, pwc with my Logitech QuickCam 3000 Pro is
not. This is on arm 2.5.24-rmk1 with patch 1167/3.
With the camera plugged in, insmod'ing ohci-hcd first and then pwc, I
get a hang (no sysrq response) or crash straight into the boot loader.
With the camera plugged in, insm
You may want to backport patch 1167/3 to 2.4. The sa-pcibuf.c in
rmk's 2.4.x and 2.5.x source tree has several serious bugs.
I dobut that's enough to get you around the "not in interrupt" assertion
...
-ch
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED
Good news:
2.5.24 + rmk1 + patch 1167/3 (or 1167/2) is more winning than ever with
usb-storage. Before this, dd'ing off a CF device would *ALWAYS* crash
the kernel in bizarre fashion. Woohoo!
Thanks to all.
-ch
# uname -a
Linux localhost.localdomain 2.5.24-rmk1-ch1 #1 Tue Jul 9 16:08:17
> What kind of problems are you seeing?
Well, since you asked ... :-)
In general things are working hugely better than they ever have for me.
Part of this was a bug in the SA- dma workaround code. I squashed
that with a re-write.
Here's what I see in my current round of testing.
1) I can
e which don't allow DMA
- * to/from addresses above 1MB.
+ * Special pci_map/unmap_single routines for SA-.
*
- * Brad Parker ([EMAIL PROTECTED])
+ * These functions utilize bouncer buffers to compensate for a bug in
+ * the SA- hardware which don't allow DMA to/from addres
; To: Christopher Hoover
> Cc: [EMAIL PROTECTED]
> Subject: Re: [linux-usb-devel] [PATCH] videodev_proc_destroy
> undefined (mkii)
>
>
> On Tue, Jun 11, 2002 at 03:26:34PM -0700, Christopher Hoover wrote:
> > # This is a BitKeeper generated patch for the following project: #
&
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.5 USB kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611 -> 1.613
#
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.5 USB kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.611 -> 1.612
#
Doh! I meant 2.5.21.
> -Original Message-
> From: Jean Tourrilhes [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 6:14 PM
> To: Christopher Hoover
> Cc: 'David Brownell'; [EMAIL PROTECTED]; 'Greg KH'
> Subject: Re: [linux-usb-devel] HC
> Am I right to conclude that Christopher Hoover was able to
> get that very same card working in a different system?
No, I haven't tried my Opti card (yes, jt, I have my own now :-)) in
quite some time. It is certainly possible that some of the recent
changes broke x86.
I'm
bd: /bin/true add 2
#
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 10, 2002 9:13 AM
> To: Christopher Hoover
> Cc: [EMAIL PROTECTED]
> Subject: Re: [linux-usb-devel] [PATCH] Fix bogus array access
> oops in usb.c (no interfac
I fixed this in my patch. The "golden" gcc for arm is 2.95.3.
-ch
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On
> Behalf Of David Brownell
> Sent: Sunday, June 09, 2002 7:50 AM
> To: [EMAIL PROTECTED]
> Subject: [linux-usb-devel] [Fwd: [PATCH] Fix 2.
This one fell through the cracks according to bk usb-2.5 -- this
prevents a bogus array access when the active configuration contains
no interfaces. It isn't clear why this happens to me on ocassion, but
when it does the kernel oopses.
Cheers,
-ch
--
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PRO
Shouldn't we use pci_alloc_consistent (or indirectly via pci_pool_alloc)
instead of kmalloc?
-ch
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On
> Behalf Of Roland Dreier
> Sent: Friday, June 07, 2002 4:57 PM
> To: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
@@ -610,16 +603,11 @@
urb_priv->td_cnt = 0;
if (data_len) {
-#ifdef CONFIG_PCI
data = pci_map_single (ohci->hcd.pdev,
- urb->transfer_buffer, data_len,
- usb_pipeout (urb->pipe)
-
ec0d8)
[...]
==
Complete raw oops and decoded oops attached.
-ch
--
Christopher Hoover
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
ksymoops 2.4.5 on i686 2.4.19-pre3-ac2-friction1. Options used
-v ./vmlinux (default)
-K (de
es balky like
mine.
Cheers,
-ch
--
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 05, 2002 10:19 PM
> To: David Brownell; Christopher Hoover;
> [EMAIL PROTECTED];
> [EMAIL PR
The SA- OHCI (at least the one on my board) sometimes get in a
screwy mode and reports no interfaces. I haven't been able to track
down why yet.
-ch
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 05, 2002 4:55 PM
> To: C
; by usb_unlink_urb
-* (real work done in a SOF intr, by dl_del_list).
+* (real work done in a SOF intr, by finish_unlinks).
*/
if (urb_priv->td_cnt == urb_priv->length) {
diff -X dontdiff.txt -Naur linux-2.5.20/drivers/usb/host/usb-ohci.c
linux-2.5.20-usbwork/drivers/usb/host/usb-ohci.c
--- linux-2.5.20/drivers/usb/host/usb-ohci.cSun Jun 2 18:44:44 2002
+++ linux-2.5.20-usbwork/drivers/usb/host/usb-ohci.cWed Jun 5 17:41:37 2002
@@ -66,7 +66,12 @@
#inclu
OK, here's the patch against 2.5.20. I broke into three pieces -- one
that pulls the PCI support out of core/hcd.c, one that fixes a bug or
two in the old ohci driver, and one for the new ohci driver that
splits the bus glue out and adds SA- support.
It works on SA-1110/SA-0 when dropped
diff -X dontdiff.txt -Naur linux-2.5.20/drivers/usb/core/hcd.c
linux-2.5.20-usbwork/drivers/usb/core/hcd.c
--- linux-2.5.20/drivers/usb/core/hcd.c Sun Jun 2 18:44:50 2002
+++ linux-2.5.20-usbwork/drivers/usb/core/hcd.c Wed Jun 5 17:46:26 2002
@@ -44,9 +44,9 @@
#ifdef CONFIG_USB_DEBUG
-
> Would you mind making up a patch against a clean 2.5.20 (or
> my usb-2.5 bk tree) with this change.
>
> I don't know if the ARM group wants to add this to their
> tree, but I'm trying to remove the USB ARM portions from
> their tree, so they don't have to maintain them anymore :)
If rmk is
The patch is host controller *independent* -- that code shouldn't ever
access into that array unless there are elements in it.
> -Original Message-
> From: Greg KH [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 05, 2002 3:56 PM
> To: Christopher Hoover
>
Fyi.
-Original Message-
From: Christopher Hoover [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 2:48 PM
To: [EMAIL PROTECTED]
Subject: [PATCH] ush-ohci fixes
Move iounmap from core to bus glue support (pci needs to iounamp,
sa- does not).
Pickup up fix for urb->n
If there are no interfaces on the active configuration, you get an
oops. I'm guessing this probably shouldn't ever happen, but it does
on occassion with the balky SA- OHCI HC.
-ch
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
PATCH_FOLLOWS
KernelVersion: 2.5.18-rmk1
diff -X ../dontdiff
eissued, until "deleted" by usb_unlink_urb
-* (real work done in a SOF intr, by dl_del_list).
+* (real work done in a SOF intr, by finish_unlinks).
*/
53 matches
Mail list logo
