On Mon, May 26, 2014 at 3:51 PM, Arend van Spriel <arend@xxxxxxxxxxxx> wrote: > + Russell > > > On 05/25/14 21:20, Hans de Goede wrote: >> >> Hi, >> >> On 05/25/2014 02:34 PM, Mark Brown wrote: >>> >>> On Sat, May 24, 2014 at 12:06:30PM +0200, Hans de Goede wrote: >>>> >>>> On 05/23/2014 06:27 PM, Mark Brown wrote: >>>>> >>>>> On Fri, May 23, 2014 at 01:50:40PM +0200, Hans de Goede wrote: >>>>>> >>>>>> On 05/23/2014 01:22 PM, Mark Brown wrote: >>> >>> >>>>>> The compatible is not a Linux specific thing, it is a marking saying >>>>>> that something needs to take care of enabling the clks (and whatever >>>>>> else we will make part of the binding for this compatible), before >>>>>> scanning the mmc bus. >>> >>> >>>>> We could just say that the mere presence of a child node with the right >>>>> properties is sufficient to trigger the bus to do the startup? >>> >>> >>>> Yes, except that most involved property names are standardized, ie >>>> clocks, >>>> and we want to be able to opt out of the KISS mmc core code for >>>> (future) complex power on sequences. >>> >>> >>> This is why I'm suggesting keying off the specific compatible strings >>> for drivers that want to opt out of the helpers rather than having a >>> compatible string to enable the helpers (which may depend on the >>> particular Linux version if the feature sets of drivers change for >>> example). >>> >>>>> If the device is sufficiently complicated to need a special power up >>>>> sequence I'd expect we'd be able to have a compatible string which >>>>> would >>>>> provide enough information for us to figure things out. >>> >>> >>>> Hmm, so what you're suggesting is indeed more of an opt out then my >>>> initial >>>> opt-in to KISS powerup idea. So to be clear what you're suggesting is: >>> >>> >>>> mmc core walks host mmc-child nodes. Loads drivers based on compatibles >>>> there. The checks a flag field in the driver to see if the driver wants >>>> to >>>> opt-out of the KISS powerup code. The problem with this is that it won't >>> >>> >>> Yes. >>> >>>> work reliable with modules, think the mmc probe being done from the >>>> ramdisk, >>>> and the driver in question only being available from the rootfs. I >>>> really >>> >>> >>> Why is that a problem - if we have no driver for the device there is no >>> point in powering it up in the first place is there? >> >> >> Well the driver may show up later, so if we only do the power-up once we >> have >> a driver, this means we need to re-check if we need to do the powerup >> later. >> >> Also the mmc people are very much against specifying a driver, as that is >> something which should be probed not specified. I agree with them I've >> already seen boards were more or less standardized sdio modules from >> different >> vendors are used, they have various standard sdio powerup related things, >> like >> an enable signal in standard places, but different editions of the boards >> have different sdio modules soldered on, using different drivers. >> >> I expect that with some care we can make all variants of these boards work >> with >> a single dts file, by using a simple sdio wifi powerup mechanism, and >> after >> that letting the mmc core figure out which module is actually soldered on. >> >>>> believe that using opt-in with a compatible such as simple-sdio-powerup >>>> is by far the safest thing to do, and as an added advantage we don't >>>> need >>>> to worry about how to deal with the future complex power on cases at >>>> all, >>>> we leave all the room in the world for various future scenarios. since >>>> as >>>> soon as the simple-sdio-powerup compatible is not there the mmc core >>>> will >>>> behave as it does today. >>> >>> >>> Please remember that the DT is *supposed* to be an ABI - systems are >>> supposed to be able to ship with a fixed DT and have it work with random >>> operating systems they have no knowledge of (and may not even exist at >>> the time the DT is being created). This means we can't rely on removing >>> a compatible string later on. >> >> >> I know that the DT is an ABI, and I'm not arguing for removing support for >> the simple-sdio-powerup compatible from the kernel when a more complex >> case arrives, nor am I arguing to remove it from the DT for existing >> working >> boards. The idea behind the simple-sdio-powerup compatible is that it >> makes >> the simple powerup behavior opt-in. So if a new board comes along which >> requires something more complex, the people working on this can do what >> ever >> they want / need without the simple powerup code getting in the way, as >> long as they don't *add* the simple-sdio-powerup compatible to their *new* >> DT file. >> >> Basically the idea behind the simple-sdio-powerup compatible is to make >> the worst case scenario for more complex boards to be the scenario which >> we have today, i.e. no support for sdio powerup at all, rather then having >> something in place which actually may get in the way, making things worse >> then they are today. > > > Hi Hans, > > I recalled a recent patchset from Russell King. He was working on i.MX6 > platform with brcmfmac device and ended reworking sdhci/mmc host controller > code in a series of patches [1]. Patch 34 might be similar to what you are > trying to accomplish. I believe that is a resend of Olof's patch I mentioned early in this discussion. :) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
