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>