From owner-freebsd-alpha Wed Feb 14 18: 0:17 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id BDE4D37B4EC for ; Wed, 14 Feb 2001 18:00:14 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f1F20ei02223; Wed, 14 Feb 2001 18:00:40 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102150200.f1F20ei02223@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Peter Jeremy Cc: alpha@freebsd.org Subject: Re: Accessing a PCI device by `physical' address In-reply-to: Your message of "Thu, 15 Feb 2001 12:40:01 +1100." <20010215124001.A71053@gsmx07.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Feb 2001 18:00:40 -0800 From: Mike Smith Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (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() > <>_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