Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Dec 2008 08:40:53 -0800
From:      Marcel Moolenaar <xcllnt@mac.com>
To:        rea-fbsd@codelabs.ru
Cc:        Boris Samorodov <bsam@ipt.ru>, freebsd-current@FreeBSD.org
Subject:   Re: Timeda 8-multiport adapter: only 2 ports available
Message-ID:  <A15C478D-B22F-4F5B-B584-F6D9BE368D55@mac.com>
In-Reply-To: <u86IhinAe98poBxKoJlfe3b/pNw@TT2a40bhZF2dUby2PPEihZ1bSVY>
References:  <92804393@bb.ipt.ru> <26722819@bb.ipt.ru> <dgryeQY4GEVsW/%2Bo7hiHda0rsyw@Nv45r0f9gWT8HCu35qu0Xm2Zg98> <26719629@bb.ipt.ru> <19F75E66-0535-4982-9726-E2C0A03117EA@mac.com> <u86IhinAe98poBxKoJlfe3b/pNw@TT2a40bhZF2dUby2PPEihZ1bSVY>

next in thread | previous in thread | raw e-mail | index | archive | help

On Dec 11, 2008, at 12:50 AM, Eygene Ryabinkin wrote:

> Marcel, Boris, good day.
>
> Wed, Dec 10, 2008 at 05:00:24PM -0800, Marcel Moolenaar wrote:
>>> Seems that just the same card should work:
>>> http://lists.freebsd.org/pipermail/freebsd-stable/2008-May/042505.html
>>>
>>> I've added some diagnistic. But 'rid' is not what you want, I guess:
>>
>> The RID is fine. It should always be 0.
>
> Seems like a dumb question, but nevertheless.
>
> What I don't understand is the following: BAR to port mapping for
> the Timedia is tricky, it mixes BARs and offsets for the different
> ports (you should know this, since you wrote the support ;)).

Correct (on both accounts :-)

> But in uart_bus_probe you're passing rid = 0 and it is used for  
> resource
> allocation and consequently the same rid is used for all ports (at  
> least
> I read the code in this way).  But puc_get_bar() uses calculated rid
> values, but does essentially the same thing: resource allocation via
> bus_alloc_resource().  And sc->sc_bas is initialized from the obtained
> sc->sc_rres (inside uart_bus_probe) and it is subsequently used for
> ns8250_probe() that is failing.
>
> I see that uart_bus_pci.c calls uart_bus_probe() with the actual rid.
> It does not mean that puc code should do the same, but ...

It could have been done that way, but such is not necessary.
It would not have been a problem for uart to do it, as can
be seen from uart_bus_pci.c, but it would have introduced
some complexity for sio(4). We needed to support sio(4) at
that time and I didn't want to touch sio(4) at all. Since
puc(4) needs to maintain a mapping from the child's device_t
to some internal data structure, it was trivial to have the
child use RID 0 in all cases and have that mapped to the
right bus tag and handle pair...

FYI,

-- 
Marcel Moolenaar
xcllnt@mac.com






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A15C478D-B22F-4F5B-B584-F6D9BE368D55>