On Fri, Nov 30, 2012 at 09:35:20AM +0000, Grant Likely wrote: > On Wed, 07 Nov 2012 02:34:19 -0500 (EST), David Miller <davem@xxxxxxxxxxxxx> wrote: > > From: Thierry Reding <thierry.reding@xxxxxxxxxxxxxxxxx> > > Date: Wed, 7 Nov 2012 07:52:58 +0100 > > > > > It seems like OF_ADDRESS would be trickier. A comment around line 60 in > > > drivers/of/platform.c says that SPARC doesn't need functions defined in > > > the enclosing #ifdef CONFIG_OF_ADDRESS block. I'm not sure it would be > > > acceptable to remove the conflict nonetheless, even if the functions > > > aren't used. One benefit would be that the code could receive some extra > > > compile coverage. > > ... > > > Finally, OF_IRQ is again just generic code to map device tree data to > > > IRQ domains. While I didn't see the IRQ_DOMAIN symbol selected anywhere > > > in SPARC it should still be possible to run drivers that properly > > > implement IRQ domains on SPARC, right? Or is there any reason why they > > > wouldn't work? > > > > These are the two most conflicted areas for Sparc. > > > > For addresses, we fully compute the full fully resolved physical > > address of all registers of an OF device very early at bootup time > > when we first scan the device tree. > > > > Same goes for interrupts, we fully compute them early in the bootup > > process. > > Right. That's the reason I haven't tackled making all architectures do > the same thing. I've not been confident that I'd get the sparc bits > correct. I think it could be done, but I haven't been able to wrap my > brain around it sufficiently. > > On non-sparc I've actually been moving in the direction of resolving > resources at .probe time to make it easier to handle deferred probing. > So if, for example, a device irq line is routed to a GPIO instead of the > core interrupt controller, then the irq number won't be known until > after the gpio driver .probe occurs. For addresses, this situation is > unlikely, but for all the other kinds of resources (gpios, regs, clocks, irqs, > etc) it is a problem that we're actually seeing. Interesting. I have some I2C devices that run into the problem where their interrupts cannot be resolved at instantiation time so I've had to work around it by calling irq_of_parse_and_map() at .probe() time and return -EPROBE_DEFER if that return NO_IRQ. Are any of your plans documented somewhere? I'd be interested to know how this is supposed to be solved. irq_of_parse_and_map() is not going to work for non-DT setups so the above can't be a proper solution. Thierry
Attachment:
pgpEMmmBU2eFa.pgp
Description: PGP signature
