USB stack vs bus_dma_tag_t
Radek Kujawa
Yesterday evening I tried to compile kernel for Amiga with USB stack included. I stumbed upon following error:
# compile A1200DEV/uhub.o
(...)
In file included from /Users/rkujawa/NetBSD-src/src/sys/dev/usb/uhub.c:53:
/Users/rkujawa/NetBSD-src/src/sys/dev/usb/usbdivar.h:123: error: expected specifier-qualifier-list before 'bus_dma_tag_t'
Brief look at the source gave me impression that:
- Amiga port of NetBSD does not support MI DMA machinery
- There's bus_dma_tag_t in arch/m68k but not in arch/amiga
- USB stack thinks that every port is capable of MI DMA
- USB stack thinks that every driver does DMA transfers
I don't need real implementation of bus_dma, as SUBWAY is not a DMA controller anyway. I just need the data structures for USB stack. DMA transfers can be faked by driver, it was already done in SL811HS driver. Albeit this looks ugly and proper solution would be introduction of non-DMA Host Controller concept to USB stack. Requirement of bus_dma structures must stay in USB stack anyway, because there are DMA controllers that need it.
How does bus_dma implementation of arch/m68k relate to arch/amiga? Can it be easily glued together to provide what I need? Ofcourse that would not bring proper DMA handling to amiga port, because it needs far more MD code.
Best regards,
Radoslaw Kujawa
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Frank Wille
Radek Kujawa <radosla...@c0ff33.net> wrote:
> error: expected specifier-qualifier-list before 'bus_dma_tag_t'
>
> Brief look at the source gave me impression that:
> - Amiga port of NetBSD does not support MI DMA machinery
> - There's bus_dma_tag_t in arch/m68k but not in arch/amiga
Yes.
> - USB stack thinks that every port is capable of MI DMA
> - USB stack thinks that every driver does DMA transfers
Probably. Don't know for sure.
> How does bus_dma implementation of arch/m68k relate to arch/amiga?
It is not used yet.
> Can it be easily glued together to provide what I need? Ofcourse that
> would not bring proper DMA handling to amiga port, because it needs
> far more MD code.
I really hoped somebody else would have replied to this. I have never
done anything with bus_dma functions.
When you look at mac68k you just need to define a m68k_bus_dma_tag in
mainbus.c and pass the tag to all attached devices. The dma functions
are all defined in m68k/m68k/bus_dma.c.
I admit I have no idea how those functions determine if a memory space
is dma-capable or not. But it should be enough to make it compile.
--
Frank Wille
Radek Kujawa
Wiadomość napisana w dniu 2010-10-13, o godz. 14:36, przez Frank Wille:
>> Can it be easily glued together to provide what I need? Ofcourse that
>> would not bring proper DMA handling to amiga port, because it needs
>> far more MD code.
>
> mainbus.c and pass the tag to all attached devices. The dma functions
> are all defined in m68k/m68k/bus_dma.c.
I already hacked contents of m68k bus_dma.h into amiga bus.h. It was
enough for USB stack to compile. I'll look into bus_dma
implementations of other ports later. Though, I would prefer not to
mess with it - I don't really understand what is going on in this code.
SUBWAY driver is slowly progressing. I have probe prototype working:
http://c0ff33.net/~rkujawa/subway-probe.txt
It is quite nice, because due to design of SUBWAY it does not need any
writes to bus, only series of reads. So I think it would be okay to
include driver even in GENERIC kernel.
Speaking of GENERIC kernel. Current autoconf mechanism in amiga port
does not work well for clockport cards. Now we can either attach to
mainbus by means of autoconf.c (really ugly for anything but
mainboards devices), or by zbus which is fine for real Zorro cards,
but not for clockport stuff.
There's one problem that makes writing drivers for clockport devices
difficult. Clockport is available on many base addresses, and address
depends on physical location of clockport. A1200 mainboard clockport
has different address than X-Surf clockport, different than ZIV
busboard clockport, etc. etc. In current situation, handling this is
up to person developing the device driver. SUBWAY driver should work
on original clockport and various Zorro clockports. But I don't want
to probe all these posible locations inside of my driver... And
tomorrow someone may create clockport on other base address.
I propose that we (read: mostly I) implement thin abstration layer,
that would simplify writing clockport cards drivers. Clockport layer
would provide information on base address to the device driver. It
could be configured manually, by setting base address in config file,
or automatically by matching known clockport carrier at zbus.
Configuration file could look like this:
clockport0 at mainbus addr 0xd80000 # A1200 mainboard clockport
clockport* at zbus? # various Zorro clockports
tduhc0 at clockport? # E3B SUBWAY USB Controller
If someone bought unofficial clockport adapter (like A603, CPU
clockport adapter), that does use other base address, he could just
change address in config file. No changes to the driver required!
Ofcourse, all of this is against amiga idea of autoconfiguration, but
so are clockport cards.
Frank Wille
>> When you look at mac68k you just need to define a m68k_bus_dma_tag in
>> mainbus.c and pass the tag to all attached devices. The dma functions
>> are all defined in m68k/m68k/bus_dma.c.
>
>
> I already hacked contents of m68k bus_dma.h into amiga bus.h. It was
> enough for USB stack to compile. I'll look into bus_dma
> implementations of other ports later.
Ok. I'm sure we can find a solution when your driver is working some day.
> I propose that we (read: mostly I) implement thin abstration layer,
> that would simplify writing clockport cards drivers. Clockport layer
> would provide information on base address to the device driver. It
> could be configured manually, by setting base address in config file,
> or automatically by matching known clockport carrier at zbus.
>
> Configuration file could look like this:
>
> clockport0 at mainbus addr 0xd80000 # A1200 mainboard clockport
> clockport* at zbus? # various Zorro clockports
> tduhc0 at clockport? # E3B SUBWAY USB Controller
That looks like a good idea for me.
But what is a Zorro clockport? Does it really exist? Do you have examples?
--
Frank Wille
Radek Kujawa
>> Configuration file could look like this:
>>
>> clockport0 at mainbus addr 0xd80000 # A1200 mainboard clockport
>> clockport* at zbus? # various Zorro clockports
>> tduhc0 at clockport? # E3B SUBWAY USB Controller
>
> That looks like a good idea for me.
>
> But what is a Zorro clockport? Does it really exist? Do you have
> examples?
It is simply a clockport located on a Zorro card. Best known Zorro
cards with clockports include Individual Computers Buddha and X-Surf.
Clockports on a card usually have different base address than original
A1200 clockport - this way it is possible to have more than one
clockport device in a computer.
Match code for clockport at zbus should contain list of vendors and
device IDs of cards carrying clockport, along with their default base
adresses. It is not possible to "detect" a clockport in any other way.
There is one disadvantage - we have to attach clockport layer to a
card that already has some other driver attached, e.g. wdc at zbus in
case of Buddha.
In some cases base address of such clockport is static, always the
same, and in some cases it is configured dynamically. I think most
clockports on Zorro cards are static, but I know at least one that is
configurable - clockport on a Deneb USB controller. It is probably
possible to change its base address via software.
By introducing this layer we move responsibility of knowing base
adress from device driver to clockport layer. Therefore driver
programmer does not have to worry about location of clockport and its
address.
Best regards,
Radoslaw Kujawa
Frank Wille
>>> clockport0 at mainbus addr 0xd80000 # A1200 mainboard clockport
>>> clockport* at zbus? # various Zorro clockports
>>> tduhc0 at clockport? # E3B SUBWAY USB Controller
>>
>> [...]
>> But what is a Zorro clockport? Does it really exist? Do you have
>> examples?
>
> It is simply a clockport located on a Zorro card. Best known Zorro
> cards with clockports include Individual Computers Buddha and X-Surf.
Ok, but then the clockport should attach to that specific Zorro card and not
to the zbus directly. For example:
ne* at zbus0
clockport* at ne? # X-surf clockport
> Match code for clockport at zbus should contain list of vendors and
> device IDs of cards carrying clockport, along with their default base
> adresses.
When you do it like above the X-surf would know the address of its
clockport.
> In some cases base address of such clockport is static, always the
> same, and in some cases it is configured dynamically. I think most
> clockports on Zorro cards are static, but I know at least one that is
> configurable - clockport on a Deneb USB controller. It is probably
> possible to change its base address via software.
But the Deneb driver (when it ever exists) would probably know a way to
determine this address, so there is no problem.
--
Frank Wille
Radek Kujawa
Wiadomość napisana w dniu 2010-10-18, o godz. 23:04, przez Frank Wille:
> Radek Kujawa wrote:
>
>>>> clockport0 at mainbus addr 0xd80000 # A1200 mainboard clockport
>>>> clockport* at zbus? # various Zorro clockports
>>>> tduhc0 at clockport? # E3B SUBWAY USB Controller
>>>
>>> [...]
>>> But what is a Zorro clockport? Does it really exist? Do you have
>>> examples?
>>
>> It is simply a clockport located on a Zorro card. Best known Zorro
>> cards with clockports include Individual Computers Buddha and X-Surf.
>
> Ok, but then the clockport should attach to that specific Zorro card
> and not
> to the zbus directly. For example:
>
> ne* at zbus0
> clockport* at ne? # X-surf clockport
I understand what you mean but... ne is a cross-platform driver for a
NE2000 chip and it does know absolutely nothing about clockports. Why
should it know? On a hardware level, clockport on these cards is
attached to Zorro bus directly ;). Connecting any device to such
clockport is like connecting it to super simplified non-
autoconfiguring zbus. Clockport does share the PCB with ne or wdc, but
these functions are totally separate. We could even support clockports
even on Zorro devices where main functionality is unsupported (think
VarIO, ZIV busboard etc.).
Also, doing it like you suggest means I have to include clockport
support code in every driver/MD attachment code (right?). I'm not sure
that is justified, considering simple nature of clockport. I think
that all trivial clockports could be handled by just one driver, as
the only difference is base address.
>> In some cases base address of such clockport is static, always the
>> same, and in some cases it is configured dynamically. I think most
>> clockports on Zorro cards are static, but I know at least one that is
>> configurable - clockport on a Deneb USB controller. It is probably
>> possible to change its base address via software.
>
> But the Deneb driver (when it ever exists) would probably know a way
> to
> determine this address, so there is no problem.
Yes, but Deneb is a special case. Here it would certainly make sense
to configure clockport at deneb, as in:
deneb* at zbus0 # Deneb card
clockport* at deneb? # Deneb's configurable clockport
dehci at deneb? # Deneb EHCI USB 2.0 Controller
usb* at dehci? # USB bus
But this case is totally different than Buddha, X-Surf etc. Here we
need special code to prepare clockport and use it (and it is handled
through card's FPGA).
Neverthless, I'll start with implementing clockport at mainbus.
Best regards,
Radoslaw Kujawa
Ignatios Souvatzis
>
> Wiadomo?? napisana w dniu 2010-10-18, o godz. 23:04, przez Frank Wille:
>
> >Radek Kujawa wrote:
> >
> >>>>clockport0 at mainbus addr 0xd80000 # A1200 mainboard clockport
> >>>>clockport* at zbus? # various Zorro clockports
> >>>>tduhc0 at clockport? # E3B SUBWAY USB Controller
> >>>
> >>>[...]
> >>>But what is a Zorro clockport? Does it really exist? Do you have
> >>>examples?
> >>
> >>It is simply a clockport located on a Zorro card. Best known Zorro
> >>cards with clockports include Individual Computers Buddha and X-Surf.
> >
> >Ok, but then the clockport should attach to that specific Zorro
> >card and not
> >to the zbus directly. For example:
> >
> >ne* at zbus0
> >clockport* at ne? # X-surf clockport
>
> I understand what you mean but... ne is a cross-platform driver for
> a NE2000 chip and it does know absolutely nothing about clockports.
> Why should it know? On a hardware level, clockport on these cards is
> attached to Zorro bus directly ;).
No, it is not. It is attached to part of the address space of the
zbus card.
So you'd rather attach:
xsurf* at zbus0
ne* at xsurf?
clockport* at xsurf?
-is
Radek Kujawa
> On Mon, Oct 18, 2010 at 11:57:28PM +0200, Radek Kujawa wrote:
> > >
> > >Ok, but then the clockport should attach to that specific Zorro
> > >card and not
> > >to the zbus directly. For example:
> > >
> > >ne* at zbus0
> > >clockport* at ne? # X-surf clockport
> >
> > I understand what you mean but... ne is a cross-platform driver for
> > a NE2000 chip and it does know absolutely nothing about clockports.
> > Why should it know? On a hardware level, clockport on these cards is
> > attached to Zorro bus directly ;).
>
> zbus card.
Yes, I oversimplified, my point was that it is not attached to ne.
> So you'd rather attach:
>
> xsurf* at zbus0
> ne* at xsurf?
> clockport* at xsurf?
Makes sense for me, but does it mean that I have to introduce additional layer for evey zbus card carrying clockport? I can do it this way, but I would have to modify many drivers. And I would not be able to test most of these, because I don't have appropriate hardware - it seems risky.
Frank Wille
Radek Kujawa <radosla...@c0ff33.net> wrote:
> > > >ne* at zbus0
> > > >clockport* at ne? # X-surf clockport
> > >
> > > I understand what you mean but... ne is a cross-platform driver
> > > for a NE2000 chip and it does know absolutely nothing about
> > > clockports. Why should it know? On a hardware level, clockport on
> > > these cards is attached to Zorro bus directly ;).
> >
> > No, it is not. It is attached to part of the address space of the
> > zbus card.
>
> Yes, I oversimplified, my point was that it is not attached to ne.
But it is. For Amiga the "ne" device is either AriadneII or X-Surf.
if_ne_zbus.c is just the frontend which attaches one of those Zorro cards,
but it can still use the MI ne2000_attach() backend for them.
> > So you'd rather attach:
> >
> > xsurf* at zbus0
> > ne* at xsurf?
> > clockport* at xsurf?
Hmm... I don't think so. ;)
> Makes sense for me, but does it mean that I have to introduce
> additional layer for evey zbus card carrying clockport?
No. You just make a single clockport.c file for your interface, which
will attach to all devices which need it.
> I can do it
> this way, but I would have to modify many drivers. And I would not be
> able to test most of these, because I don't have appropriate hardware
> - it seems risky.
And unnecessary. Please don't do that. :)
To use the X-Surf example, you would just add some code at the end of
ne_zbus_attach(), which fills some confargs structure with the
information supplied by this Zorro card (e.g. address of clockport),
then call config_found(your_device, confargs, print) to automatically
attach a clockport device to it.
Then the clockport device can call config_found() for further devices
which attach to this clockport using the address from confargs.
What can be attached where and which files and dependencies exist is
defined in conf/files.amiga.
Please read autoconf(9) for more information about the auto configuration
process.
--
Frank Wille
Ignatios Souvatzis
> On Tue, 19 Oct 2010 15:28:33 +0200
> Radek Kujawa <radosla...@c0ff33.net> wrote:
>
> > > > >clockport* at ne? # X-surf clockport
> > > >
> > > > I understand what you mean but... ne is a cross-platform driver
> > > > for a NE2000 chip and it does know absolutely nothing about
> > > > clockports. Why should it know? On a hardware level, clockport on
> > > > these cards is attached to Zorro bus directly ;).
> > >
You'd write this?
device clockport ...
attach clockport at ne_zbus with ...
Regards,
-is
Frank Wille
Ignatios Souvatzis <i...@netbsd.org> wrote:
> > To use the X-Surf example, you would just add some code at the end
> > of ne_zbus_attach(), which fills some confargs structure with the
> > information supplied by this Zorro card (e.g. address of clockport),
> > then call config_found(your_device, confargs, print) to
> > automatically attach a clockport device to it.
> >
> > Then the clockport device can call config_found() for further
> > devices which attach to this clockport using the address from
> > confargs.
> >
> > What can be attached where and which files and dependencies exist is
> > defined in conf/files.amiga.
>
> You'd write this?
>
> device clockport ...
> attach clockport at ne_zbus with ...
I fear it is not that simple. We want clockport to attach to any device
which supports it, not just to one. So I would rather try:
device clockport
attach clockport at clkportbus
file dev/clockport.c
attach ne at zbus with ne_zbus: rtl80x9, clkportbus
file arch/amiga/dev/if_ne_zbus.c ne_zbus needs-flag
device mainbus: clkportbus
Don't know if the syntax is correct, but maybe you get the idea?
--
Frank Wille