cvs commit: src/sys/dev/matcd creativeif.h matcd.c matcd_data.h matcd_isa.c matcddrv.h options.h

[Frank Durda IV]

[-]Please use the bus_space staff.

[0]On Tue, 17 Jun 2003, Frank Durda IV wrote:
[0]And on what company/school staff would this person be on?
[0]Please elaborate.

In the dimmness of the morning, the use of "staff" (apparently in place of
"stuff") was why I was asking for clarification of the terse statement.
I suppose I should have assumed staff==stuff, but you never know for sure.
This resulted in additional traffic:


[1]mdodd at FreeBSD.ORG writes:
[1]inb()/outb() are not portable.

Their use here doesn't need to be,  for hardware like this that only exists
in the Intel PC world, and as far as I know, only in the ISA world.  No PCI
cards exist with this interface that I'm aware of, at least not from
Creative Labs the main seller of these drives.


[1]mdodd at FreeBSD.ORG continues:
[1]FreeBSD uses a mechanism borrowed from
[1]NetBSD that hides the platform specifics behind a common API.
[1]
[1]See mcd(4) and scd(4) for example.

As to mcd/scd happening to know about these calls you mention, drivers I did
review back in December, but the actual call to these functions is hidden
behind a further macro within MCD, which at the time I assumed bottomed-out
into an inb/outb inline somewhere.   I guess I should have chased MCD_WRITE
and MCD_READ down on the off chance that someone had changed this hardware
access method actually being used.

In any event, had I known about this back in January/February despite the
lack of documentation back then (and apparently still none except in another
operating system), documentation which would hopefully indicate that these
calls absolutely positively did not have any artifacts or behavior outside
of generating an IN or OUT operation to the appropriate port, AND that they
were globally available AND that they were the preferred method for doing
I/O over inb()/outb() that was used for the previous twenty plus years, 
had this been documented, I probably would have switched at that point.


I should mention that the Matsushita hardware is timing-picky on certain
things and if you noticed the use of inb/outb (as was used by this driver
in 2.1.5 thru 4.x releases with no complaint before now), you should have
also noticed that I have to disable all interrupts while issuing commands to
ensure the timing is achieved.  Switching to a far more convoluted way to
just do an IN or OUT BYTE instruction on Intel platform (the only thing the
host adapters were ever made for) is a potential failure point, and smells
like a bloater.

After spending days trying to figure out the mechanisms surrounding the
sc->port_bst/bsh STUFF in order to get anything working earlier in this
project (90% of the time was spent just figuring out how hint port and
other values reach drivers now so probe/attach would work again),  the lack
of a man page for bus_space_read/bus_space_write and friends in my opinion
all tend to make people use as few of the such calls as possible.
Honestly, I found that quite enough deck chairs had been randomly
re-arranged and then not documented in the driver to kernel interfaces (an
interface that stayed largely unchanged in BSD for the first twenty years
or so) to make this effort consume large quantities of time, far more
than it should have done.


And of course the biggie: As inb/outb macros still work on the target
hardware and processor, and work as they did in the previous life of
this driver, so why dump success?  Why even scout around on the off chance
that using inb/outb is not the preferred way to do things any more?

I don't usually go looking in dark alleys to see if any have muggers.


The requirements set forth back in December by the mailing list were simple:
	1.	Change the license agreement on the code so it is liked.
	2.	Make the code compile without warnings.
Here we are.

No one really asked that driver actually function or for the documentation
to be updated, but I assumed that part...  :-)


Hmm.  I just re-confirmed that GCC still sticks the inb/outb opcode inline
in the code at the appropriate place in the assembler/object just like it
used to.  That's important to this driver, because it means no non-specified
or concealed branching, no pushing parms on stacks, no possible faulty
processor serialization/parallelization assumptions, no calls or returns
with their timing or trap penalties, and no possible loss of processor
(assuming disable_intr/enable_intr really disables interrupts at least as
well as spl(7) used to), any or all of which could cause this driver to not
be able to control the hardware.

This is a piece of hardware was designed for the single-task, 100% dedicated
CPU you had in the MS-DOS world, not the multi-tasking or even
multi-processor environment we have here.  Still, by careful management of
I/O and processor distractions, matcd works quite nicely without
permanently hogging the/a processor, and has been tested on quite slow
one and two-processor configurations, where most ISA-based systems live.


By all means, do document these substitute I/O calls you mention, detailing
any timing/interrupt aspects that arise from their use (and how to avoid
them when using the preferred scheme) when compared to a good old (and
predictable) inline inb/outb/inw/outw opcodes.  Such documention covering
these points up would certainly increase the basic awareness of these
functions, and explain their pitfalls, if any. 


I'll be happy to experiment with this alternate method, but would rather
wait until detailed documentation appears on their use and side-effect
potentials.  If things look and test out safe, I'll switch.


Frank Durda IV  <uhclem at freebsd.org>  |"You didn't see the notice about the
or <uhclem.jun03%nemesis.lonestar.org>   | rule change?  It is on display
That Anti-spam address expires Jun  30th | in a locked filing cabinet in a
	http://nemesis.lonestar.org      | disused bathroom in the basement
Copr. 2003, ask before reprinting.       | with a sign on the door saying..."