Properly managing sub-allocations

[John Baldwin-2]

I'm trying to cleanup a few things in apci and I ran into what I think is a
new-bus architecture issue.  Specifically, acpi likes to allocate system
resource resources from its parent, and then turn around and sub-alloc those
out to children.  This mostly works fine except for the bus space details of
the bus tag and bus handle.  Currently acpi(4) just copies the tag from the
corresponding resource from the parent and sets the handle to the start of
the resource.  This just happens to work currently because i386 and amd64 use
the start of the resource for the handle for SYS_RES_IO and overwrite the
handle in nexus_activate_resource() for SYS_RES_MEMORY.  This does add some
ugliness though in that acpi needs to go find the parent resouce to copy the
bus tag.  However, it's current algorithm wouldn't work in general (PC98
needs to alloc bus handles, and it does so in nexus_alloc_resource() for
example).

To solve this, I think we need to stop setting bus tags and handles in
bus_alloc_resource().  One solution might be to add a new bus method to set
those for a resource, but I think the better solution would be to set the bus
tags and handles in bus_activate_resource().  It already sort of does this
for some cases (SYS_RES_MEMORY on x86 for example) and will work with the
existing ACPI model (it already passes up activate_resource to the parent, so
we would just have to remove the explicit setting of the bus tag and handle).

I actually wonder if this isn't how things are supposed to be in the first
place and that the current aberrations are just bugs?

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[M. Warner Losh]

In message: <200610021323.50997.john@...>
            John Baldwin <john@...> writes:
: I'm trying to cleanup a few things in apci and I ran into what I think is a
: new-bus architecture issue.  Specifically, acpi likes to allocate system
: resource resources from its parent, and then turn around and sub-alloc those
: out to children.  This mostly works fine except for the bus space details of
: the bus tag and bus handle.  Currently acpi(4) just copies the tag from the
: corresponding resource from the parent and sets the handle to the start of
: the resource.  This just happens to work currently because i386 and amd64 use
: the start of the resource for the handle for SYS_RES_IO and overwrite the
: handle in nexus_activate_resource() for SYS_RES_MEMORY.  This does add some
: ugliness though in that acpi needs to go find the parent resouce to copy the
: bus tag.  However, it's current algorithm wouldn't work in general (PC98
: needs to alloc bus handles, and it does so in nexus_alloc_resource() for
: example).
:
: To solve this, I think we need to stop setting bus tags and handles in
: bus_alloc_resource().  One solution might be to add a new bus method to set
: those for a resource, but I think the better solution would be to set the bus
: tags and handles in bus_activate_resource().  It already sort of does this
: for some cases (SYS_RES_MEMORY on x86 for example) and will work with the
: existing ACPI model (it already passes up activate_resource to the parent, so
: we would just have to remove the explicit setting of the bus tag and handle).
:
: I actually wonder if this isn't how things are supposed to be in the first
: place and that the current aberrations are just bugs?

I think you are right.  Thinking about it, you can't access the
resources until you've activated them...

However, this may break some existing drivers that allocate a BAR,
peek at its type and then either activate it or allocate another
BAR...  The TAG is valid, but the handle isn't.

This specific problem will never happen in pc98, since there are no
ACPI pc98 machines and can never be.

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[John Baldwin-2]

On Monday 02 October 2006 13:39, M. Warner Losh wrote:
> In message: <200610021323.50997.john@...>
>             John Baldwin <john@...> writes:
> : I'm trying to cleanup a few things in apci and I ran into what I think is
a
> : new-bus architecture issue.  Specifically, acpi likes to allocate system
> : resource resources from its parent, and then turn around and sub-alloc
those
> : out to children.  This mostly works fine except for the bus space details
of
> : the bus tag and bus handle.  Currently acpi(4) just copies the tag from
the
> : corresponding resource from the parent and sets the handle to the start of
> : the resource.  This just happens to work currently because i386 and amd64
use
> : the start of the resource for the handle for SYS_RES_IO and overwrite the
> : handle in nexus_activate_resource() for SYS_RES_MEMORY.  This does add
some
> : ugliness though in that acpi needs to go find the parent resouce to copy
the
> : bus tag.  However, it's current algorithm wouldn't work in general (PC98
> : needs to alloc bus handles, and it does so in nexus_alloc_resource() for
> : example).
> :
> : To solve this, I think we need to stop setting bus tags and handles in
> : bus_alloc_resource().  One solution might be to add a new bus method to
set
> : those for a resource, but I think the better solution would be to set the
bus
> : tags and handles in bus_activate_resource().  It already sort of does this
> : for some cases (SYS_RES_MEMORY on x86 for example) and will work with the
> : existing ACPI model (it already passes up activate_resource to the parent,
so
> : we would just have to remove the explicit setting of the bus tag and
handle).

> :
> : I actually wonder if this isn't how things are supposed to be in the first
> : place and that the current aberrations are just bugs?
>
> I think you are right.  Thinking about it, you can't access the
> resources until you've activated them...
>
> However, this may break some existing drivers that allocate a BAR,
> peek at its type and then either activate it or allocate another
> BAR...  The TAG is valid, but the handle isn't.

They generally peak at the BAR register itself though, not the value of
rman_get_bustag() though, right?

> This specific problem will never happen in pc98, since there are no
> ACPI pc98 machines and can never be.

Yeah, but I can cleanup the stuff in ACPI a good bit if I can get it to stop
peeking at the "real" resource to get the bus tag.  Also, I think fixing this
would be important for a driver that wanted to sub-alloc its resources out to
children (like vgapci, which currently cheats on that).

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[M. Warner Losh]

In message: <200610021403.50339.john@...>
            John Baldwin <john@...> writes:
: > However, this may break some existing drivers that allocate a BAR,
: > peek at its type and then either activate it or allocate another
: > BAR...  The TAG is valid, but the handle isn't.
:
: They generally peak at the BAR register itself though, not the value of
: rman_get_bustag() though, right?

Some do, some get the resource and look at it.  There's a lot of
variance here.  Do you put knowledge of how to decode PCI bars into
every driver, or do you let the pci bus take care of it?  Since the
knowledge is nearly trivial, different people decide differenly.  It
is still a technique that has been used, and you'll need to be careful
to make sure you don't break anything.  After all, 0 is a valid I/O
tag and it is also the default value...

: > This specific problem will never happen in pc98, since there are no
: > ACPI pc98 machines and can never be.
:
: Yeah, but I can cleanup the stuff in ACPI a good bit if I can get it
: to stop peeking at the "real" resource to get the bus tag.  Also, I
: think fixing this would be important for a driver that wanted to
: sub-alloc its resources out to children (like vgapci, which
: currently cheats on that).

Good point.  I don't dispute this is a good thing, just that it will
solve a problem we're currently having.  Given the push for embedded,
this is a problem worth solving.

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[John Baldwin-2]

On Monday 02 October 2006 15:42, M. Warner Losh wrote:

> In message: <200610021403.50339.john@...>
>             John Baldwin <john@...> writes:
> : > However, this may break some existing drivers that allocate a BAR,
> : > peek at its type and then either activate it or allocate another
> : > BAR...  The TAG is valid, but the handle isn't.
> :
> : They generally peak at the BAR register itself though, not the value of
> : rman_get_bustag() though, right?
>
> Some do, some get the resource and look at it.  There's a lot of
> variance here.  Do you put knowledge of how to decode PCI bars into
> every driver, or do you let the pci bus take care of it?  Since the
> knowledge is nearly trivial, different people decide differenly.  It
> is still a technique that has been used, and you'll need to be careful
> to make sure you don't break anything.  After all, 0 is a valid I/O
> tag and it is also the default value...

Err, how can code examine the actual bus tag value of a non-active resource?  
By definition it's set an opaque MD value.  You can't compare it against
SYS_RES_MEMORY for example.  On i386 systems it happens to be an int, on some
other systems (alpha maybe?) I think it can be a pointer to a structure of
function pointers for the different bus space operations.  I don't think any
MI code should ever be examining the bus tag or handle except to pass them as
opaque parameters to bus_space_*().

--
John Baldwin
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[M. Warner Losh]

In message: <200610021620.44185.john@...>
            John Baldwin <john@...> writes:
: On Monday 02 October 2006 15:42, M. Warner Losh wrote:
: > In message: <200610021403.50339.john@...>
: >             John Baldwin <john@...> writes:
: > : > However, this may break some existing drivers that allocate a BAR,
: > : > peek at its type and then either activate it or allocate another
: > : > BAR...  The TAG is valid, but the handle isn't.
: > :
: > : They generally peak at the BAR register itself though, not the value of
: > : rman_get_bustag() though, right?
: >
: > Some do, some get the resource and look at it.  There's a lot of
: > variance here.  Do you put knowledge of how to decode PCI bars into
: > every driver, or do you let the pci bus take care of it?  Since the
: > knowledge is nearly trivial, different people decide differenly.  It
: > is still a technique that has been used, and you'll need to be careful
: > to make sure you don't break anything.  After all, 0 is a valid I/O
: > tag and it is also the default value...
:
: Err, how can code examine the actual bus tag value of a non-active resource?  
: By definition it's set an opaque MD value.  You can't compare it against
: SYS_RES_MEMORY for example.  On i386 systems it happens to be an int, on some
: other systems (alpha maybe?) I think it can be a pointer to a structure of
: function pointers for the different bus space operations.  I don't think any
: MI code should ever be examining the bus tag or handle except to pass them as
: opaque parameters to bus_space_*().

Actually, you are right.  I'm confusing success/failure of allocating
a I/O and/or Memory bar with this...

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."