> But I don't understand the whole issue you have.
> Just schedule a request and wait for the device to ack.
> The Host controller does the polling for you as long as the request is
> queued and the timeout value supplied with the request did not time out.
> That has nothing to do with FreeBSD - it
On Mon, May 03, 2004 at 04:37:22PM -0400, Rita Lin wrote:
> > But I don't understand the whole issue you have.
> > Just schedule a request and wait for the device to ack.
> > The Host controller does the polling for you as long as the request is
> > queued and the timeout value supplied with the re
> Igh - that sounds like a very bad device design then.
> There would have been lots a ways to do in a clean way without
> additional pipes - such as transfering 0 sized packets to trigger a
> status inquiry or by adding status bytes in each packet.
> For what purpose do you need to poll the status
On Mon, May 03, 2004 at 05:36:47PM -0400, Rita Lin wrote:
> > Igh - that sounds like a very bad device design then.
> > There would have been lots a ways to do in a clean way without
> > additional pipes - such as transfering 0 sized packets to trigger a
> > status inquiry or by adding status bytes
> That is what I call a bad design.
> You waste resources because the device designer did not take the
> features he had available.
Okay, I guess so. There are also other minor things that I don't understand
why
the device is implemented the way it is. Since I don't make it, and I don't
work for
t
On Mon, May 03, 2004 at 06:48:14PM -0400, Rita Lin wrote:
> > That is what I call a bad design.
> > You waste resources because the device designer did not take the
> > features he had available.
> Okay, I guess so. There are also other minor things that I don't understand
> why
> the device is imp
On Sun, May 02, 2004 at 10:38:42AM -0400, Rita Lin wrote:
> Hello,
>
> I'm writing a USB driver for a device that does not have any interrupt. It only has
> Bulk-in and Bulk-out. A periodic polling status from default pipe is required to
> have a smooth data transfer. I used timeout() routine to
Hello,
I'm writing a USB driver for a device that does not have any interrupt. It only has
Bulk-in and Bulk-out. A periodic polling status from default pipe is required to have
a smooth data transfer. I used timeout() routine to call usbd_do_request() for
polling. I thought maybe timeout() is c
In message: <[EMAIL PROTECTED]>
Bruce M Simpson <[EMAIL PROTECTED]> writes:
: Craig,
:
: On Sat, Nov 08, 2003 at 10:11:22PM -0500, Craig StJean wrote:
: > I have a prism2 USB wireless device. I've never written drivers before but I have
been developing for the past 8 years. Could some
Craig,
On Sat, Nov 08, 2003 at 10:11:22PM -0500, Craig StJean wrote:
> I have a prism2 USB wireless device. I've never written drivers before but I have
> been developing for the past 8 years. Could someone guide me to a website or
> something that would help me write a USB wrapper for the wi de
I have a prism2 USB wireless device. I've never written drivers before but I have been
developing for the past 8 years. Could someone guide me to a website or something that
would help me write a USB wrapper for the wi device? I have a copy of the old uwi
driver which is now broken so it may hel
On Mon, Feb 10, 2003 at 10:13:28AM -0800, [EMAIL PROTECTED] wrote:
> Hi.
>
> I am looking at writing a FreeBSD device driver for a new PCI card.
> I looked at the FreeBSD documentation on device drivers (PCI)
> but couldn't find much.
>
> Can anyone point me at appropriate references/documentatio
Hi.
I am looking at writing a FreeBSD device driver for a new PCI card.
I looked at the FreeBSD documentation on device drivers (PCI)
but couldn't find much.
Can anyone point me at appropriate references/documentation (4.*) or URL?
I apologize if this is an old thread...
Paul Fronberg
[EMAIL PR
On Fri, 2 Mar 2001, Dmitry Dicky wrote:
> Hi fellows,
>
> I'm writing some device driver which should pass some data to the user
> space.
>
> The part of the device read routine looks as follows:
>
> --
> int
> dev_read(dev_t dev, struct uio *uio, int ioflag)
>
Hi fellows,
I'm writing some device driver which should pass some data to the user
space.
The part of the device read routine looks as follows:
--
int
dev_read(dev_t dev, struct uio *uio, int ioflag)
{
int err = 0;
/* ... */
amnt = MIN(uio->uio_resid, cnt
I sent this message on the freebsd-mobile mailing list. Since it is
related to the newpcm/csa driver, I think folks on the hackers list may be
able to help.
Summary:
- newpcm/csa driver on 4.2-stable doesn't work on my thinkpad a20p
- Same laptop with NetBSD 1.5, it works fine (clcs d
> I load the driver the first time, and it loads correctly. I unload it and
> reload it and it attempts to attach twice (with the exact same resource
> values). I unload and reload it and it attempts to load 3 times, unload/reload
> ... 4 times (you see the pattern). If I load the second module
"David E. Cross" wrote:
>
> > > Thank you...
> > >
> > > After a couple of hours, Jon Chen and I have figured out most of what you
> > > just said :P :)
> > >
> > > How would one use hints with a kld?
> >
> > Badly. 8( You can only really set them with the loader right now.
> >
> > There are a c
> > Thank you...
> >
> > After a couple of hours, Jon Chen and I have figured out most of what you
> > just said :P :)
> >
> > How would one use hints with a kld?
>
> Badly. 8( You can only really set them with the loader right now.
>
> There are a couple of kernel datastores that need some
Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "David E. Cross" writes:
> : How would one use hints with a kld?
>
> Load the hints at boot time and hope you get it right. Other than
> that, it is bog simple. We use klds for all our drivers at Timing
> Solutions and load the hints at boot t
In message <[EMAIL PROTECTED]> "David E. Cross" writes:
: How would one use hints with a kld?
Load the hints at boot time and hope you get it right. Other than
that, it is bog simple. We use klds for all our drivers at Timing
Solutions and load the hints at boot time.
There's no way to change
> > Thank you...
> >
> > After a couple of hours, Jon Chen and I have figured out most of what you
> > just said :P :)
> >
> > How would one use hints with a kld?
>
> Badly. 8( You can only really set them with the loader right now.
>
> There are a couple of kernel datastores that need some
> Thank you...
>
> After a couple of hours, Jon Chen and I have figured out most of what you
> just said :P :)
>
> How would one use hints with a kld?
Badly. 8( You can only really set them with the loader right now.
There are a couple of kernel datastores that need some tweaking; the
envir
Thank you...
After a couple of hours, Jon Chen and I have figured out most of what you
just said :P :)
How would one use hints with a kld?
--
David Cross | email: [EMAIL PROTECTED]
Lab Director | Rm: 308 Lally Hall
Rensselaer Polytech
You're doing this "all wrong". 8)
If you know what the device's settings are, you want an identify routine
which will create the device instance and set up resources for it.
If you want the user to be able to tweak the settings, you want a set of
device hints and a normal ISA probe routine.
-On [20010117 17:00], David E. Cross ([EMAIL PROTECTED]) wrote:
>Given that code, I get the following attach messages from the kernel:
>
>"das1400adc2: at port 0x310-0x312 irq 5 drq 1,5 on isa0"
>Uhm... I set neither the IRQ nor the drq... where does it get these from, and
>how can I get it to "d
I am writing a simple, I/O only device driver (no lectures about /dev/io
please ;). It has not PnP abilities, and I have run into the following
problem with bus_set_resource():
static int das1400adc_isa_probe(device_t dev)
{
struct das1400adc_softc *sc = device_get_softc(dev);
Mike-
> I should have summarised this by saying: Correct use of the latency
> timer will shorten your DMA bursts for you when necessary, giving you the
> best of both worlds. When it's safe to run a long burst, you will. When
> you need to push a device off the bus, that will happen too.
Af
> > On Sun, 05 Dec 1999, you wrote:
> Conversely, you can achieve the same latency reduction by setting the
> latency timer to 16, without increasing your overheads there. (This isn't
> actually entirely true, as you may run into busmaster ping-pong with more
> than one in the system, but you'll g
> On Sun, 05 Dec 1999, you wrote:
> >
> > > The question: Why doesn't this work... it seem so straight forward...
> >
> > I'm not sure about the code in question, but the basic assumptions you're
> > making about PCI's behaviour are flawed. To achieve the goal you're
> > trying to, you need to
On Sun, 05 Dec 1999, you wrote:
>
> > The question: Why doesn't this work... it seem so straight forward...
>
> I'm not sure about the code in question, but the basic assumptions you're
> making about PCI's behaviour are flawed. To achieve the goal you're
> trying to, you need to reduce the va
On Wed, 8 Sep 1999, Matt Thomas wrote:
> LANCE. It's supported by the DEPCA attachment (though as ISA). Very
> nice card. It has 128KB of local RAM (which can be moved to almost any
> where in phyical memory). The only real botch is that the IRQ is a write
> only register so you need to read th
At 01:41 PM 9/8/99 , Jason Thorpe wrote:
>On Wed, 8 Sep 1999 00:17:52 +0200 (CEST)
> Wilko Bulte wrote:
>
> > There was also an DE-422 EISA card. Dunno if they are different.
>
>I'm not sure what a DE-422 had on it... Matt?
LANCE. It's supported by the DEPCA attachment (though as ISA). Very
On Wed, 8 Sep 1999, Matt Thomas wrote:
> LANCE. It's supported by the DEPCA attachment (though as ISA). Very
> nice card. It has 128KB of local RAM (which can be moved to almost any
> where in phyical memory). The only real botch is that the IRQ is a write
> only register so you need to read t
At 01:41 PM 9/8/99 , Jason Thorpe wrote:
>On Wed, 8 Sep 1999 00:17:52 +0200 (CEST)
> Wilko Bulte <[EMAIL PROTECTED]> wrote:
>
> > There was also an DE-422 EISA card. Dunno if they are different.
>
>I'm not sure what a DE-422 had on it... Matt?
LANCE. It's supported by the DEPCA attachment (t
On Wed, 8 Sep 1999 00:17:52 +0200 (CEST)
Wilko Bulte wrote:
> There was also an DE-422 EISA card. Dunno if they are different.
I'm not sure what a DE-422 had on it... Matt?
> Do you have/want one? I could try to get you one. EISA is dead of course,
> but older machines tend to have EISA s
On Wed, 8 Sep 1999, Wilko Bulte wrote:
> There was also an DE-422 EISA card. Dunno if they are different.
>
> Do you have/want one? I could try to get you one. EISA is dead of course,
> but older machines tend to have EISA slots to spare, and PCI in short
> supply.
I'd love to find an EISA based
Of all the gin joints in all the towns in all the world, Jason Thorpe
had to walk into mine and say:
> > However, the main problem is keeping the chip from zapping memory that it
> > doesn't own. Normally I use mbuf cluster buffers in the receive ring, but
> > I would only tell the chip that t
On Wed, 8 Sep 1999 00:17:52 +0200 (CEST)
Wilko Bulte <[EMAIL PROTECTED]> wrote:
> There was also an DE-422 EISA card. Dunno if they are different.
I'm not sure what a DE-422 had on it... Matt?
> Do you have/want one? I could try to get you one. EISA is dead of course,
> but older machines
On Wed, 8 Sep 1999, Wilko Bulte wrote:
> There was also an DE-422 EISA card. Dunno if they are different.
>
> Do you have/want one? I could try to get you one. EISA is dead of course,
> but older machines tend to have EISA slots to spare, and PCI in short
> supply.
I'd love to find an EISA based
Of all the gin joints in all the towns in all the world, Jason Thorpe
had to walk into mine and say:
> > However, the main problem is keeping the chip from zapping memory that it
> > doesn't own. Normally I use mbuf cluster buffers in the receive ring, but
> > I would only tell the chip that
On Wed, 8 Sep 1999 10:12:51 -0400 (EDT)
Bill Paul wrote:
> Well, yes, but I made some assumptions in order to do it. The assumption
> is that whatever the current speed setting is now, the link partner's
> speed setting is exactly opposite. So if I detect the condition, I first
> toggle the
On Wed, 8 Sep 1999 10:12:51 -0400 (EDT)
Bill Paul <[EMAIL PROTECTED]> wrote:
> Well, yes, but I made some assumptions in order to do it. The assumption
> is that whatever the current speed setting is now, the link partner's
> speed setting is exactly opposite. So if I detect the condition, I
As Jason Thorpe wrote ...
> On Tue, 7 Sep 1999 03:11:24 -0400 (EDT)
> Bill Paul wrote:
>
> > The SiS 900 only has one combined status/control word in its
> > descriptor structure (some of the bits mean different things depending
> > on whether the descriptors are in the RX ring or TX ring)
As Jason Thorpe wrote ...
> On Tue, 7 Sep 1999 03:11:24 -0400 (EDT)
> Bill Paul <[EMAIL PROTECTED]> wrote:
>
> > The SiS 900 only has one combined status/control word in its
> > descriptor structure (some of the bits mean different things depending
> > on whether the descriptors are in the
Of all the gin joints in all the towns in all the world, Jason Thorpe
had to walk into mine and say:
> > I'm assuming you actually have a Winbond card. If you do, try this for
>
> Yah, some Unicom card, I think.
>
> > me: connect the Winbond to a link partner who's media settings you can
>
Of all the gin joints in all the towns in all the world, Jason Thorpe
had to walk into mine and say:
> > I'm assuming you actually have a Winbond card. If you do, try this for
>
> Yah, some Unicom card, I think.
>
> > me: connect the Winbond to a link partner who's media settings you can
>
On Tue, 7 Sep 1999 21:13:22 -0400 (EDT)
Bill Paul wrote:
> Well, the older chipsets make it even harder on you: you have to know
> just the right way to twiddle the bits in the GPIO register in order to
> program the media settings, and to figure that out you're supposed to
> read the media
On Tue, 7 Sep 1999 21:13:22 -0400 (EDT)
Bill Paul <[EMAIL PROTECTED]> wrote:
> Well, the older chipsets make it even harder on you: you have to know
> just the right way to twiddle the bits in the GPIO register in order to
> program the media settings, and to figure that out you're supposed
Of all the gin joints in all the towns in all the world, Jason Thorpe
had to walk into mine and say:
> [ snip ... all the quirks ]
>
> ...I'm well aware of all of these :-)
>
> Amusingly, these are the same kinds of quirks you have to deal with for
> a unified *genuine DEC Tulip* driver. E.g.
Of all the gin joints in all the towns in all the world, Jason Thorpe
had to walk into mine and say:
> [ snip ... all the quirks ]
>
> ...I'm well aware of all of these :-)
>
> Amusingly, these are the same kinds of quirks you have to deal with for
> a unified *genuine DEC Tulip* driver. E.g.
On Tue, 7 Sep 1999 03:11:24 -0400 (EDT)
Bill Paul wrote:
> The SiS 900 only has one combined status/control word in its
> descriptor structure (some of the bits mean different things depending
> on whether the descriptors are in the RX ring or TX ring) instead of a
> separate status and
On Tue, 7 Sep 1999 03:11:24 -0400 (EDT)
Bill Paul <[EMAIL PROTECTED]> wrote:
> The SiS 900 only has one combined status/control word in its
> descriptor structure (some of the bits mean different things depending
> on whether the descriptors are in the RX ring or TX ring) instead of a
>
Of all the gin joints in all the towns in all the world, Jason Thorpe
had to walk into mine and say:
> On Fri, 03 Sep 1999 16:23:00 -0600
> Wes Peters wrote:
>
> > > > See, for instance, the al, ax, mx, pn, vr, and wb drivers. ;^)
> > > ^^
> > >
Of all the gin joints in all the towns in all the world, Jason Thorpe
had to walk into mine and say:
> On Fri, 03 Sep 1999 16:23:00 -0600
> Wes Peters <[EMAIL PROTECTED]> wrote:
>
> > > > See, for instance, the al, ax, mx, pn, vr, and wb drivers. ;^)
> > >
On Fri, 03 Sep 1999 16:23:00 -0600
Wes Peters <[EMAIL PROTECTED]> wrote:
> > > See, for instance, the al, ax, mx, pn, vr, and wb drivers. ;^)
> > ^^
> > Especially this one.. it's not a Tulip clone :-)
>
> Oh? vr(4) disagrees:
On Fri, 03 Sep 1999 16:23:00 -0600
Wes Peters wrote:
> > > See, for instance, the al, ax, mx, pn, vr, and wb drivers. ;^)
> > ^^
> > Especially this one.. it's not a Tulip clone :-)
>
> Oh? vr(4) disagrees:
>
> The VIA
Jason Thorpe wrote:
>
> On Wed, 01 Sep 1999 15:46:40 -0600
> Wes Peters wrote:
>
> > Is this a real tulip, or one of the recent clones? Bill Paul has written a
> > number of drivers for various near clones of the Tulip, none of which work
> > quite like the Tulip (of course).
> >
> > See,
Jason Thorpe wrote:
>
> On Wed, 01 Sep 1999 15:46:40 -0600
> Wes Peters <[EMAIL PROTECTED]> wrote:
>
> > Is this a real tulip, or one of the recent clones? Bill Paul has written a
> > number of drivers for various near clones of the Tulip, none of which work
> > quite like the Tulip (of cou
On Wed, 01 Sep 1999 15:46:40 -0600
Wes Peters wrote:
> Is this a real tulip, or one of the recent clones? Bill Paul has written a
> number of drivers for various near clones of the Tulip, none of which work
> quite like the Tulip (of course).
>
> See, for instance, the al, ax, mx, pn, vr
"David E. Cross" wrote:
>
> I am modifying the tulip device driver to support this xircom card. I have it
> almost entirely working, *except* that it goes into infinite re-neogitiate
> loops. The card probes correctly at bootup, but any attempt to change
> information via ifconfig ("ifconfig de0
On Wed, 01 Sep 1999 15:46:40 -0600
Wes Peters <[EMAIL PROTECTED]> wrote:
> Is this a real tulip, or one of the recent clones? Bill Paul has written a
> number of drivers for various near clones of the Tulip, none of which work
> quite like the Tulip (of course).
>
> See, for instance, th
"David E. Cross" wrote:
>
> I am modifying the tulip device driver to support this xircom card. I have it
> almost entirely working, *except* that it goes into infinite re-neogitiate
> loops. The card probes correctly at bootup, but any attempt to change
> information via ifconfig ("ifconfig de
I am modifying the tulip device driver to support this xircom card. I have it
almost entirely working, *except* that it goes into infinite re-neogitiate
loops. The card probes correctly at bootup, but any attempt to change
information via ifconfig ("ifconfig de0 inet ..." and "ifconfig de0 up",
I am modifying the tulip device driver to support this xircom card. I have it
almost entirely working, *except* that it goes into infinite re-neogitiate
loops. The card probes correctly at bootup, but any attempt to change
information via ifconfig ("ifconfig de0 inet ..." and "ifconfig de0 up",
65 matches
Mail list logo
