Hi. This is the mailer daemon at relay2.hichina.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[EMAIL PROTECTED]>: Sorry, I couldn't find a mail exchanger or IP address. (#5.4.4)
--- Below this
Hi,
On Mon, 04 Oct 2004 15:10:47 +0100, Ian Campbell <[EMAIL PROTECTED]>
wrote:
Hi Lothar,
Early in September you were working on a driver for the isp1362 based
upon your work with the ohci-emu/sl811 stuff. I'm just wondering what
the current status of this is. Do you have a webpage with patches
On Thursday 07 October 2004 2:19 pm, Stefan Rompf wrote:
> Hi,
>
> ehci_hub_resume() reads the hub port registers during resume. However, on S3
Well there's a conceptual problem that keeps coming up lately...
encouraged by the current APIs, to be sure! The device doesn't
enter S3 .. it enters P
Hi all.
I'm trying to use a recent driver for the Philips ISP1362 USB OTG
chip. (just as a host for now) Attached is the end of my compiler
output.
Q. Where are DPRINTK and MEMDUMP typically defined?
Where should they be defined? Am I missing a file somewhere?
Thanks,
MikeIn file included from
Hi,
ehci_hub_resume() reads the hub port registers during resume. However, on S3
or swsusp the root hub loses power, making read data invalid and forcing the
user to replug all devices. Saving the data in memory during suspend helps -
at least for my i855gm based notebook.
There are still issu
Hi.
First, I want to say 'Thanks very much' to you (Lothar Wassmann) for
your work on the ohci emulation for the SL811 chip and the ISP1362.
I'm trying to use the ISP1362 with these new drivers at the moment,
and they look good to my eyes.
I've got a couple comments and questions:
1. The ohci-is
David Brownell wrote:
On Thursday 07 October 2004 9:32 am, Feyd wrote:
Are the usb controllers s/g capable?
For some definitions of s/g, yes...
What are the definitions? s/g on pages would be enough.
If so, the usb_buffer_alloc could
use vmalloc for high order allocations.
... no, because if
On Thursday 07 October 2004 9:32 am, Feyd wrote:
>
> Are the usb controllers s/g capable?
For some definitions of s/g, yes...
> If so, the usb_buffer_alloc could
> use vmalloc for high order allocations.
... no, because if you read Documentation/DMA-mapping.txt
you'll see an informative "Wh
Am Donnerstag, 7. Oktober 2004 18:32 schrieb Feyd:
> Oliver Neukum wrote:
> > Am Donnerstag, 7. Oktober 2004 16:26 schrieb Duncan Sands:
> >
> >>>And would be quite wrong. The 2.6 code allows users to trigger
> >>>an allocation of 32K in kernel space. The impact on the VM can be
> >>>dreadful. If
Oliver Neukum wrote:
Am Donnerstag, 7. Oktober 2004 16:26 schrieb Duncan Sands:
And would be quite wrong. The 2.6 code allows users to trigger
an allocation of 32K in kernel space. The impact on the VM can be
dreadful. If anything you should port Manuel's code to 2.6.
Don't you mean 16k? Also, did
On Thu, 7 Oct 2004, j d wrote:
> Hi,
>
> I'm working on linux-2.4.19 with the USB support
> disabled. I need to communicate to the device. I am
> able to initialize the host controller and get the
> device detect on the ports.
Why are you doing all of this with USB support disabled? Why not si
(forwarding from linux-usb-users:)
Hi,
Is anyone successfully using a DYMO LW 3xx series with Linux 2.6?
If so, what kernel version? and please send me the output of
'cat /proc/bus/usb/devices' or 'lsusb' with the device attached.
If this isn't working for anyone with a 2.6 kernel but is wo
Am Donnerstag, 7. Oktober 2004 16:26 schrieb Duncan Sands:
> > And would be quite wrong. The 2.6 code allows users to trigger
> > an allocation of 32K in kernel space. The impact on the VM can be
> > dreadful. If anything you should port Manuel's code to 2.6.
>
> Don't you mean 16k? Also, did you
> And would be quite wrong. The 2.6 code allows users to trigger
> an allocation of 32K in kernel space. The impact on the VM can be
> dreadful. If anything you should port Manuel's code to 2.6.
Don't you mean 16k? Also, did you really see a bad effect in practice?
If so, proc_submiturb should be
Am Donnerstag, 7. Oktober 2004 14:52 schrieb Duncan Sands:
> On Thursday 07 October 2004 14:33, Manuel Odendahl wrote:
> > Hi!
> >
> > On Thu, 7 Oct 2004, Duncan Sands wrote:
> > > Surely you are confusing with control transfers?
> >
> > This is the code that I have in proc_bulk in the 2.4.26 ker
On Thu, 7 Oct 2004, Manuel Odendahl wrote:
> Here is the new patch.
I forgot to attach the file, sorry.
Manuel--- devio-old.c Thu Oct 7 14:27:00 2004
+++ devio.c Thu Oct 7 14:23:28 2004
@@ -19,7 +19,7 @@
* along with this program; if not, write to the Free Software
* Foundatio
On Thursday 07 October 2004 14:33, Manuel Odendahl wrote:
> Hi!
>
> On Thu, 7 Oct 2004, Duncan Sands wrote:
> > Surely you are confusing with control transfers?
>
> This is the code that I have in proc_bulk in the 2.4.26 kernel:
>
> ...
>if (len1 > PAGE_SIZE)
> return -EINVAL;
>if
On Thursday 07 October 2004 13:57, Oliver Neukum wrote:
> Am Donnerstag, 7. Oktober 2004 12:52 schrieb Duncan Sands:
> > > For example, in order to do a 64k BULK OUT transfer, assuming an
> > > endpoint maxPacketSize of 32 bytes, I had to do 2048 ioctls, each
> > > triggering a context switch.
> >
Hi!
On Thu, 7 Oct 2004, Duncan Sands wrote:
> No, you do one ioctl, sending 64k. The host controller will indeed
> send it in 32 byte bits, but that's not your problem.
As Duncan pointed out, my approach was badly flawed, as indeed
partitioning the bulk request in the kernel instead of leaving i
Am Donnerstag, 7. Oktober 2004 12:52 schrieb Duncan Sands:
> > For example, in order to do a 64k BULK OUT transfer, assuming an
> > endpoint maxPacketSize of 32 bytes, I had to do 2048 ioctls, each
> > triggering a context switch.
>
> No, you do one ioctl, sending 64k. The host controller will in
Am Donnerstag, 7. Oktober 2004 11:13 schrieb Manuel Odendahl:
> The patch was applied onto a 2.4.26 kernel, and does not apply to a 2.6
> kernel, but should be no problem to adapt. The changes itself are pretty
> trivial, the proc_bulk function now makes use of proc_bulk_read and
> proc_bulk_write
> For example, in order to do a 64k BULK OUT transfer, assuming an
> endpoint maxPacketSize of 32 bytes, I had to do 2048 ioctls, each
> triggering a context switch.
No, you do one ioctl, sending 64k. The host controller will indeed
send it in 32 byte bits, but that's not your problem.
All the b
Hi!
I am accessing USB devices through the usbdevfs filesystem. I have to do
a lot of big bulk transfers in a very short time frame, and stumbled
upon the limitation that each IOCTL_USB_BULK ioctl could only trigger a
single usb BULK transfer.
For example, in order to do a 64k BULK OUT transfer,
Hi,
Has anyone tried this device? It seems an ideal way to expand
a server with as many terminals as needed, without being limited
by available PCI slots.
Sitecom has no Linux drivers or info on this device, so I guess
it is currently not supported by Linux, but I'm curious what it
would take to
Dimitris Lampridis writes:
> Hi Lothar (again),
>
> I'm missing the ohci-pci-regs.h file. Why is that?
> If i get it right it ought to be ohci.h renamed and with the read/write
> functions also declared. But I don't have the file and although your
> patch adds the line ... #include "ohci-pci-regs.
Hi,
I'm working on linux-2.4.19 with the USB support
disabled. I need to communicate to the device. I am
able to initialize the host controller and get the
device detect on the ports.
Now I'm trying to send the standard control request. I
do not see any error in the USBSTS resgoster while I
send
26 matches
Mail list logo
