headers
Jachym Holecek | 1 Feb 2004 01:44
Picon
Favicon

Re: DMA using Interrupt

Hello,

> I want to initialize the DMA using Interrupt Mode, how shall I use the
> concept of Top-Half and Bottom-Half in case of DMA operation.

Simple example might look like this:

	1) Userland process request DMA transfer (a write() on your device
	   file for instance)
	
	2) In the write() handler you initialize the DMA transfer and wait for
	   completion (using [t]sleep(9))
	
	3) Once the transfer is done, your interrupt handler is invoked and
	   wakeup(9)s your process. In effect, the [t]sleep(9) from 2) returns,
	   you finish write()s job and return to userland.
	
> How shall I communicate between the Top-Half and the Bottom-Half?

When you register an interrupt handler, you can provide a (void *) argument
which will then be passed to the interrupt handler. Usually, this will be
your driver's softc structure, you can use some of its fields to communicate
state between the two "levels". When touching some of this shared state, it's
important to protect given section with splXXX(9), so that the interrupt doesn't
come in the middle and see half-updated half-obsolete state. In the example
above, step 2) could look like:

	int 		s;
	...
	s = splnet(); /* or whatever level set during intr registration */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simas Mockevicius | 1 Feb 2004 09:43
Picon

Re: bktr (tv tuner)

Hi,
as promised I got from my friend this mail (translated to english by me:)
...
Dmesg:
vga0 at pci1 dev 0 function 0: Nvidia Corporation GeForce2 MX [NV11]
(rev. 0xb2)
wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation)
wsmux1: connecting to wsdisplay0
bktr0 at pci0 dev 8 function 0
bktr0: interrupting at irq 11
bktr0: PV951 card, Philips FR1216 PAL FM tuner.
radio0 at bktr0
Brooktree product 0x0878 (miscellaneous multimedia, revision 0x11) at
pci0 dev 8 function 1 not configured
eap0 at pci0 dev 11 function 0: Ensoniq AudioPCI 97 (rev. 0x08)
eap0: interrupting at irq 10
eap0: SigmaTel STAC9721/23 codec; 18 bit DAC, 18 bit ADC, SigmaTel 3D

In the kernel config I included those lines:

# TV cards

# Brooktree 848/849/878/879 based TV cards
bktr* at pci? dev ? function ?
radio* at bktr?
options BKTR_OVERRIDE_TUNER=10
options BKTR_SYSTEM_DEFAULT=BROOKTREE_PA

I have attached TV tuner ``line out'' with my sound card ``line-in''
but on NetBSD it is muted by default, so I did this:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ben Harris | 1 Feb 2004 16:22
Picon

Abstracting pckbc(4)

At the moment, pckbd(4) and pms(4) can only attach at pckbc(4).  This is a
bit of a nuisance, since some systems (e.g. those supported by
NetBSD/acorn32) have AT keyboards and PS/2 mice handled by other chips.
I'm currently working on building an abstraction layer, but I'd like some
comments from other people on how it will work.

My current plan is that chip drivers like pckbc(4) would export relatively
simple operations for byte transmission and reception, and a new midlayer
would handle actual commands, with all the retries, timeouts and general
unpleasantness that entails.  pckbd(4) and pms(4) would see much the same
interface as at present, but a lot of the code currently in pckbc.c would
move into the midlayer.

Things named for the abstract interface (including dev/pckbc and all the
functions called by pckbd(4) and pms(4)) would be renamed to pckbport*,
leaving "pckbc" to refer just to the i8042-based controller.  This avoids
changes to kernel configuration files.  The replacement for pckbc_tag_t,
pckbport_tag_t, would be a pointer to a structure full of function
pointers for the midlayer's use and a pointer to controller-private data
(eg struct pckbc_internal).

What have I got wrong or forgotten?

--

-- 
Ben Harris                                                   <bjh21 <at> NetBSD.org>
Portmaster, NetBSD/acorn26           <URL:http://www.NetBSD.org/Ports/acorn26/>
Permalink | Reply | 14 comments |
headers
Alan Barrett | 1 Feb 2004 18:11
Gravatar

Re: Abstracting pckbc(4)

On Sun, 01 Feb 2004, Ben Harris wrote:
> What have I got wrong or forgotten?

You didn't mention support for hot pluggable keyboards and mice.  For
example, if you boot a machine without a keyboard, and plug a keyboard
in later, it would be nice if it worked.

--apb (Alan Barrett)
Permalink | Reply | 11 comments |
headers
Ben Harris | 2 Feb 2004 01:41
Picon

Re: Abstracting pckbc(4)

In article <20040201171116.GB589 <at> apb.cequrux.com> you write:
>On Sun, 01 Feb 2004, Ben Harris wrote:
>> What have I got wrong or forgotten?
>
>You didn't mention support for hot pluggable keyboards and mice.  For
>example, if you boot a machine without a keyboard, and plug a keyboard
>in later, it would be nice if it worked.

Does it work at the moment with pckbc?  If not, I don't plan to add support
for it, since my intention is merely to provide an abstraction to allow for
the replacement of the lower layer of the current pckbc driver, rather than
to add any other new features.  If hot-plugging does currently work with
pckbc, is there anything you think I particularly need to be aware of when
designing my abstraction?

--

-- 
Ben Harris
Permalink | Reply | 10 comments |
headers
Lennart Augustsson | 2 Feb 2004 02:56
Favicon
Gravatar

Re: Abstracting pckbc(4)

Hot plug doesn't work (as far as I know), but you should design the
extra abstraction so it could.  Just make sure to propagate the
detach and activate calls that (presumably) comes from the controller.

	-- Lennart

Ben Harris wrote:
> In article <20040201171116.GB589 <at> apb.cequrux.com> you write:
> 
>>On Sun, 01 Feb 2004, Ben Harris wrote:
>>
>>>What have I got wrong or forgotten?
>>
>>You didn't mention support for hot pluggable keyboards and mice.  For
>>example, if you boot a machine without a keyboard, and plug a keyboard
>>in later, it would be nice if it worked.
> 
> 
> Does it work at the moment with pckbc?  If not, I don't plan to add support
> for it, since my intention is merely to provide an abstraction to allow for
> the replacement of the lower layer of the current pckbc driver, rather than
> to add any other new features.  If hot-plugging does currently work with
> pckbc, is there anything you think I particularly need to be aware of when
> designing my abstraction?
>
Permalink | Reply | 5 comments |
headers
der Mouse | 2 Feb 2004 04:18
Picon

Re: Abstracting pckbc(4)

>> You didn't mention support for hot pluggable keyboards and mice.
>> For example, if you boot a machine without a keyboard, and plug a
>> keyboard in later, it would be nice if it worked.
> Does it work at the moment with pckbc?

After a fashion.  I have seen i386 machines running relatively recent
versions (a 1.6.1 I set up for $ORK, for example) boot without a
keyboard connected (obviously, the BIOS is set to not halt POST on
keyboard error).  The keyboard is detected during autoconf even though
there is no keyboard physically connected; plugging in a keyboard later
Just Works.  (Indeed, I once saw a site that depended on this; they had
a roomful of machines and about two screens and keyboards, which were
on wheels; if you wanted to work with a particular machine, you wheeled
one of the screen-and-keyboard sets to that machine, plugged them in,
and started typing.)

However, people talking about hot-plug often mean devices coming and
going in the device tree as you connect and disconnect the hardware,
and in that sense I haven't seen hot-plug pckbc working.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse <at> rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
Permalink | Reply | 0 comments |
headers
Anand Lalgondar | 2 Feb 2004 07:55

Queries about bus_space (MIPS: TX49)

Hello,

I have some queries regarding 'bus_space' functions, could some please
clarify the same. I have gone through the man pages of 'bus_space' and
noted some of the points that I found relavent for this discussion. These
queries are oriented towards MIPS based TX49 processor architecture
(supports '36-bit Physical address space' and '32-bit or 64-bit
[configurable] virtual address space').

Some points of bus_space:
1. Bus spaces are described by bus space tags, which can only be created
by machine-dependent code. A given machine may have several different
types of bus space (e.g. memory space and I/O space), and thus may
provide multiple different bus space tags.
   - Now as per my knowledge there is nothing like I/O space in TX49
   architecutre (is it correct), so the only bus space tags that can be
   created would be of type memory bus space.

2. Architectures may have several different tags which represent the same
type of space, for instant because of multiple different host bus
interface chipsets.
   - i.e. multiple bus space tags to the memory bus space (0x00000000 -
   0xffffffff), i.e. for example bus space tags first one representing
   from 0x00000000 - 0x3fffffff, other from 0x40000000 - 0xbfffffff, and
   another from 0xc0000000 - 0xffffffff for the same memory bus space ?

3. A range in bus space is described by a bus address and a bus size. The
bus address describes the start of the range in bus space. The bus size
describes the size of the range in bytes.
   - considering the above example:
(Continue reading)

Permalink | Reply | 2 comments |
headers
der Mouse | 2 Feb 2004 08:14
Picon

Re: Queries about bus_space (MIPS: TX49)

> I have some queries regarding 'bus_space' functions, [...]

Well, I'm no bus-space guru, but I do have the time, and I think I know
a little about the bus-space paradigm.  I'm sure someone will slap me
down if I start spouting nonsense.

> 1. Bus spaces are described by bus space tags, which can only be
> created by machine-dependent code.

Right.

> A given machine may have several different types of bus space (e.g.
> memory space and I/O space), and thus may provide multiple different
> bus space tags.

Right.

>    - Now as per my knowledge there is nothing like I/O space in TX49
>    architecutre (is it correct), so the only bus space tags that can
>    be created would be of type memory bus space.

Perhaps at the moment (I don't know).  What you need to do may be to
create a new bus space for your port.  It may be instructive to examine
the i386 implementation, since that does have to deal with an I/O space
that is not accessed like memory.

I once did this.  I had to deal with hardware that had a serial chip of
a type supported by a MI driver, but connected oddly - the CPU-visible
effect was that all addresses relative to the base of the chip were
multiplied by some small constant, 16 I think, by wiring "unusual"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Barrett | 2 Feb 2004 08:54
Gravatar

Re: Abstracting pckbc(4)

On Mon, 02 Feb 2004, Ben Harris wrote:
> >You didn't mention support for hot pluggable keyboards and mice.
> 
> Does it work at the moment with pckbc?

Not properly.  At least in NetBSD/i386, there's some sort of magic
fakery for the keyboard, such that even if the keyboard is not plugged
in at boot time, the "pckbd at pckbc" device node gets attached anyway.
If you plug in in a real keyboard later then it has a fair chance of
working.  But if the mouse is not plugged in at boot time then plugging
it in later does not cause "pms at pckbc" to be attached.

> If not, I don't plan to add support for it,

OK.  But please try to design the abstraction layer in a way that allows
hot plugging to be added later.  I don't know what's required to do
that.

--apb (Alan Barrett)
Permalink | Reply | 2 comments |

Gmane