From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 1B176DDE43 for ; Tue, 3 Jul 2007 22:49:18 +1000 (EST) In-Reply-To: <20070703095114.GA31118@iram.es> References: <20070627065335.GD11191@localhost.localdomain> <20070627071008.GA30648@localhost.localdomain> <20070628100020.GA24215@iram.es> <20070703095114.GA31118@iram.es> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <47b9d4b67d96676d65e04002978d567a@kernel.crashing.org> From: Segher Boessenkool Subject: Re: [PATCH 3/3] First cut at PReP support for arch/powerpc Date: Tue, 3 Jul 2007 14:49:01 +0200 To: Gabriel Paubert Cc: linuxppc-dev@ozlabs.org, Paul Mackerras , David Gibson List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >>>> + external-control; >>>> >>>> Really? >>> >>> Well, is anybody actually using eciwx/ecowx? >> >> That's not the point -- the device tree should only >> say "external-control" if the CPU actually supports >> it; AFAIK, that's 601 only. > > I wonder whether you are mixing up external control > and direct-store segments (the "T" bit in segment registers). =93external-control=94 prop-encoded-array: This property, if present, indicates that the PowerPC microprocessor defined by this CPU node implements the External Control Facility as described in the =93Optional Facilities and Instructions=94 appendix of Book II of [2]. The absence of his property indicates that the PowerPC microprocessor defined by this CPU node does not support the External Control Facility. No, I don't think I'm mixing up anything. G2 CPUs don't support this stuff, do they? >> =46rom my docs, external control has been supported by many > processors, up to many variants of the 750 and even 7440/7450. Hrm I don't think so... ... erm yeah. It's just that it isn't usable on any of those systems ;-) > Now I've never seen any hardware which could make use of these > instructions (you'd need a device on the processor bus that > reacts to the special bus cycles generated by the ec[io]wx > instructions, since no host bridge I've ever met handles them. Yeah exactly. > I've not seen support for external control in the Linux kernel > either (you'd need to setup the EAR SPR and probablly to modify > it on context switches). > > OTOH, the direct-store segments were only implemented in the > original 601, 603 (not 603e) and 604 processors (can't remember > about the 604e) and even then the 601 had special features > in this area. Yah. >>>> + pci@80000000 { >>>> + device_type =3D "pci"; >>>> + compatible =3D "prep"; >>>> >>>> Is that specific enough? >>> >>> On the MVME5100, actually the mapping is more CHRP like, and PCI I/O >>> space is smaller and at a higher address. >> >> Right, so it's not; "compatible" should specify the >> model of PCI host bridge, instead. > > Well, the PCI host bridge is reprogrammable in a very flexible way > and and I actually wrote a boot loader that reprograms it the > way I wanted address space to look like. "compatible" should just say what exactly the hardware is; "prep" isn't good enough to describe a certain PCI host bridge (it doesn't say it is a PHB, to start with!) > I shall send it to > you in a PM (it is quite big, it includes an x86 emulator > which is able to initialize the VGA PMC modules I have by > running the BIOS). Hrm I'm not sure what I should do with that? Segher