On Tue, Apr 28, 2009 at 04:47:52AM -0700, David Brownell wrote: > On Tuesday 28 April 2009, Mark Brown wrote: > > On Tue, Apr 28, 2009 at 02:32:56AM -0700, David Brownell wrote: > > > > > What it lacks is something entirely different: ?driver support > > > > > for the LCD which uses the regulator framework, > > > > It's not VAUX3 that it's saying has incomplete constraints, it's the > > > > board as a whole - if the constraints for the board were fully specified > > > No; driver support != constraint. Only one of the > > > issues is packaged as a "constraint". > > Driver support isn't particularly relevant here. > It's the *entire* point. The driver is talking directly > to the regulator, bypassing this framework. The constraints > on that regulator are fully defined ... and then bypassed. Ah, I see - I didn't realise that there was driver support that doesn't use the regulator API, that had been dropped out of context by that point in the discussion. I guess the LCD driver will be converted to use the API in due course, hopefully there aren't too many other such drivers. This is the sort of use case that made me not want to have the API disable unused regulators by default - there's stuff going on that the regulator API and the code using it doesn't know about (since it's going through some other interface to do the job in this case) so the API can't safely do anything to that regulator. > > > How about: "VAUX3 board support is incomplete". > > > That's accurate. > > No. The constraints being complete is a property of the board as a > > whole and not the particular regulator. > Except ... that "constraint" isn't the issue, it's > unexpected driver behavior. And "board" is exactly This is sufficiently unexpected that it's the first time I've seen anything bypassing the regulator API; in any case, it's just a question of where you see the problem coming from. My terminology comes from the fact that as far as the core is concerned the issue is that the board didn't say it had given the core complete constraints allowing it to fully control the regulators that are visible to it. The reason the board didn't do that is that is that the LCD driver is bypassing the regulator API and the regulator API doesn't have any way to express that possibility. > what I said, so I don't know why you're arguing. > (For the "fun" of it?) David, that is really not necessary or constructive. This sort of disparaging remark has been a constant feature of your interactions on regulator API issues and it is not achieving anything useful. > Board support includes full driver support, as well > as board setup (constraints). That's the common way > to factor it, at any rate -- a "board support package" > addresses both, and they need to work together. s/board/machine driver/; in an ideal world for Linux there is no BSP, it's all mainline. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
