Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Feb 2001 18:00:40 -0800
From:      Mike Smith <msmith@freebsd.org>
To:        Peter Jeremy <peter.jeremy@alcatel.com.au>
Cc:        alpha@freebsd.org
Subject:   Re: Accessing a PCI device by `physical' address 
Message-ID:  <200102150200.f1F20ei02223@mass.dis.org>
In-Reply-To: Your message of "Thu, 15 Feb 2001 12:40:01 %2B1100." <20010215124001.A71053@gsmx07.alcatel.com.au> 

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

(should have been posted to -alpha)

This actually poses quite a problem.  The way that the PCI code is 
architected now means that you can't actually talk to any of the PCI 
hardware until after the root bridge has been discovered.

However, I think that you're not in such a bad position as you think.  
From my understanding of the Alpha, you don't actually need to init the 
TGA to become console in the "early" console phase at all; you can keep 
using the SRM console vectors until the driver "really" probes/attaches.

Thinking about it some more, though, this probably doesn't integrate well 
with syscons.  8(

I'm kinda stumped, here.  I don't think there's a clean way to do this, 
which is bad.  We probably need to fix this.  Thoughts?

> I'm trying to port an Alpha video driver (TGA) from -stable to
> -current and have run into a problem converting some calls to
> pci_cfgread() and pci_cfgwrite().
> 
> The Alpha firmware reports the location of the console video card as a
> physical hose, bus type, bus, slot value.  In -stable, the card can be
> accessed by calling pci_cfg{read,write}() with this information.
>
> In -current, pci_cfg{read,write}() have been replaced by
> pci_{read,write}_config(), but the latter function needs a device_t
> structure that defines both the device and it's parent.
> Unfortunately, I don't have the relevant device_t available.  In any
> case, based on my reading of the code, I need to access the PCI config
> registers before the video card has been probed/attached via the
> normal bus/device scan.
> 
> Luckily, there's only one point at which I need this `physical' access.
> The call backtrace is:
> 	pci_cfg{read,write}()
> 	tga_configure()
> 	vid_configure()
> 	scvidprobe()
> 	sccnattach()
> 	<<system_specific>>_cons_init()
> 	alpha_init()
> 	...
> 
> Does anyone have any useful suggestions?[1]  Is there an `approved'
> mechanism to bypass the bus abstraction layers?  Is is practical to
> hand-craft a device_t that will satisfy pci_{read,write}_config()?
> 
> [1] I don't count "throw out the TGA" as a useful suggestion.
> 
> Peter
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102150200.f1F20ei02223>