Date: Wed, 2 Jan 2008 14:53:02 -0500 From: John Baldwin <jhb@freebsd.org> To: Marcel Moolenaar <xcllnt@mac.com> Cc: freebsd-embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <200801021453.02931.jhb@freebsd.org> In-Reply-To: <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com> References: <CC4D41C0-7CD7-47A8-8DA0-523B38C65B9A@mac.com> <200801021303.39518.jhb@freebsd.org> <0E7F7277-75F4-4A5A-924D-97C0C9D940CD@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 02 January 2008 02:14:55 pm Marcel Moolenaar wrote:
>
> On Jan 2, 2008, at 10:03 AM, John Baldwin wrote:
>
> > Agreed, and device.FOO would create an unknownX device (much like
> > unprobed
> > PNPBIOS or ACPI-enumerated devices) with a set of properties (if the
> > bus impl
> > uses properties to create devices and doesn't use them purely as
> > additional
> > metadata). For example, I actually figured that the default
> > device.hints type
> > stuff for COM1 would look like this:
> >
> > device.COM1.at="isa"
> > device.COM1.port="0x3f8-0x3ff"
> > device.COM1.irq=4
> > device.COM1.pnpid="PNP0500"
>
> BTW: I like the port range.
I hate that abuot the current hints actually where drives hardcode things like
IO_COMSIZE. I really would like the enumeration data that is provided not by
the firmware to look like something that comes from firmware, on which we
seem to agree.
> > which is what you get with ACPI/PnPBIOS. On i386/amd64 users would
> > probably
> > wish to bind it using something like:
> >
> > device.COM1.driver="sio"
> > device.COM1.unit=0
> >
> > but it wouldn't be required. Note that it would be nice to just
> > say 'device.COM1.unit=0' and not specify a driver at all, but that
> > would not
> > be easy to implement in new-bus.
>
> It can also cause conflicts. With uart and sio, you can
> wire both to the same unit, based on the fact that sio
> attaches to legacy devices by default and uart attaches
> to puc by default. If you remove the sio driver, then you
> end up with 2 wiring directives for the same unit that
> now apply to the same driver. Explicitly specifying the
> driver+unit makes it clear what is meant: if there are
> multiple directives for the same driver+unit, then it's
> obvious that the directives are conflicting and thus that
> it's pilot error.
Yeah. The problem is that in the case of the reversed com ports with ACPI
that's all the users really want is the units to be right, they don't really
care exactly which driver attaches. In some ways it would be nice if we
could just give names to devices and use _UID for that or the node in the
namespace (though the latter can fall down if you have an exceptionally lame
namespace like my laptop's BIOS (see www.freebsd.org/~jhb/gpe/acpi.nc6220,
all non-reserved names in the ACPI tree are Cxxx)) to generate user-visible
device names like /dev entries, but I think that something like that might be
too much upheaval. Also, I'm not sure it would scale well across different
machines. For example, at work we really want the device that is labelled
COM1, COMA, Serial A, whatever, to be the serial console and to have a getty
running on it. Currently the easiest way for us is to bind sio0 to the
resources for COM1 using hints and use /dev/ttyd0. _UID and namespace names
are too unreliable for us to use those unfortunately.
> Anyway, back to hints: your new approach is not disliked
> by me. It fits my concept for the most part. However, in
> order to support embedded hardware, we need to extend the
> syntax (like using a range for the I/O port). Extending
> the syntax may involve some significant work; even to the
> extend that we can call it a rewrite, even if we keep
> calling it hints.
>
> More examples: the e500 core can have up to 4 MACs. Each
> MAC has 3 interrupts. We need to support this. Also, some
> devices have multiple I/O resource ranges. This too needs
> to be supported. If we can modify the current hints
> slightly to support it than I'm happy. It's just that I
> have not seen any consideration for it and could only
> assume it would fall through the cracks.
Regarding resources, I'd really like to be able to specify RIDs so you could
do:
device.FOO.irq.0="4"
device.FOO.port.1="0xa-0xb"
(RID 0 of SYS_RES_IRQ and RID 1 of SYS_RES_IOPORT)
I also wonder if it would be nice to isolate I/O resources in their own
property namespace. Something like:
FOO {
resources {
irq {
0=4
}
ioport {
1=0xa-0xb
}
}
at="blah"
}
We could also call 'at', 'location' perhaps.
> Also, A syntax like:
> FOO {
> sub1=a
> sub2=b
> }
>
> ... can be considered syntactic sugaring, because it
> can mean exactly the same as:
> FOO.sub1=a
> FOO.sub2=b
>
> This too is exactly like hints. So, even a discussion
> about syntax does not mean we need to toss out everything
> we have and start from scratch.
True. My worry here is making sure we can change it from the loader still.
However, I also would still like to have a loader command for managing this
in which case having it be in the kernel environment just like hints may be
less important. That is, if
"device FOO irq.0 4"
will work, then we can replace /boot/device.hints with 'device' invocations
and the backing-store for passing the data from the loader to the kernel is
less important.
> The bottomline: I'm not arguing that we cannot end up with
> something that looks like hints. I'm arguing that if we
> take hints *as they are* and apply your tweaks, that we don't
> solve all the problems we're having or know we will have.
>
> More examples: I think we need to make hints conditional
> so that they can be included in case they're needed, but
> can be disabled/masked in case they're not (and more
> specifically when they're wrong and fry your SoC). Since
> hints as we have them today are unconditional, I can only
> object to using hints because of the fact they are unconditional
> and there's no intention to make them conditional.
Well, they are somewhat conditional now (isa(4) at least respects
the "disabled" hint). Are you looking for a single "turn all of them off"
switch or a per-object disable?
> Anyway: I don't mind if you decide to step away from this,
> but I do think you're making a mistake in that case. If
> anything, it's important that people keep arguing to make
> sure that we find the right balance...
Well, I'll chew some more. At least this time I don't have any code yet that
I'm throwing away.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801021453.02931.jhb>