Hi, On Wed, 20 Feb 2013, Felipe Balbi wrote: > On Wed, Feb 20, 2013 at 05:38:49PM +0000, Paul Walmsley wrote: > > > > Drivers shouldn't touch their IP block's SYSCONFIG registers. They don't > > just now I noticed this fun fact: > > "driver's should touch *their* SYSCONFIG registers" > > You're stating yourself that SYSCONFIG belongs to the IP and the IP is > fully controlled by its driver. ;-) Hehe. I should have used some more convoluted expression :-) > > Ideally Linux drivers would be as independent as possible from their SoC- > > or board-specific integration. This includes bus integration, etc. That > > way, an IP block like UART, where most or all of the registers are shared > > with the common 8250 code, might be able to use a shared driver. > > right, then why did we even bother adding omap-serial ? If the whole > idea was to hide integration, what was the point in introducing > omap-serial ? My distant recollection was that the main impetus at the time was DMA support. Which might be moot, now. Not really my parish. > > Also, it should be noted that the TI wrapper isn't necessarily common to > > all TI SoCs :-) The wrapper bits and functions can change from TI SoC to > > SoC. > > yeah, that's because of the chassis architecture definition and has > little value to current discussion ;-) The point was that we don't want to duplicate that code in each driver for each SoC ... rather, it can live in one place, in some separate integration layer. > It does touch the IP block. After the asynchronous PM handshake > (Ack-Req) is successful the IP block isn't in a usable state. Usually that's just because the PRCM has cut some clock to the device. You can chat with Benoît about this if you want; we had a discussion last year about it in relation to the 32K_SYNCTIMER. > > As far as reset goes, the chip-wide reset bits affect the IP block too, > > but we wouldn't put that code into the drivers :-) > > why not ? In the OMAP case, the SoC-wide reset bits are in the PRCM somewhere, which in turn assert reset for a wide set of IP blocks. So there's not much point to putting code for that in the drivers. > What happens when drivers need to reset the IP ? For cases > where we need "reset in runtime", drivers are the best entities to know > exactly where the IP must be reset. We might be miscommunicating. I was mostly referring to SoC-wide reset in my (somewhat silly) counterfactual. So there are at least three kinds of reset in this context, that I think about: 1. SoC-level reset 2. Bus-level reset 3. Device-level reset Ideally these are all independent, even though they might share some of the same hardware mechanisms. The case that's causing us so much hassle is bus-level reset. The problem is that some of the OMAP devices - say, 7-10% - can't be reset and idled simply with a bus-level reset. I'd consider the exceptions as hardware bugs, but we still have to deal with them. > Also, IMHO reset should always be done during probe() so driver can be > dead sure that we're starting from a known state. This is even more > important for the complex IPs which are licensed from RTL vendors and > are used in different SoCs. While arch/arm/mach-abc/ resets every IP > pior to probe() being called, we can't be sure that arch/arm/mach-xyz/ > will do the same thing and imposing such requirement is too difficult. > > Problem just gets worse when you consider SoCs from completely different > architectures (say ARM and Blackfin) using the same IP licensed from > a particular RTL vendor. Or if there's no driver for the device at all :-( - Paul
