From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arend van Spriel Subject: Re: RFC: representing sdio devices oob interrupt, clks, etc. in device tree Date: Tue, 27 May 2014 22:27:43 +0200 Message-ID: <5384F53F.4020408@broadcom.com> References: <20140525123452.GS22111@sirena.org.uk> <53824294.1090609@redhat.com> <20140526103807.GV22111@sirena.org.uk> <538321AB.4050006@redhat.com> <20140526142225.GF22111@sirena.org.uk> <538356DA.7090302@redhat.com> <53838023.2080807@redhat.com> <20140527175326.GZ12304@sirena.org.uk> <20140527185535.GB27420@quad.lixom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-gw1-out.broadcom.com ([216.31.210.62]:6955 "EHLO mail-gw1-out.broadcom.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753643AbaE0U1t (ORCPT ); Tue, 27 May 2014 16:27:49 -0400 In-Reply-To: <20140527185535.GB27420@quad.lixom.net> Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: Olof Johansson Cc: Mark Brown , Ulf Hansson , Hans de Goede , Tomasz Figa , Chen-Yu Tsai , Sascha Hauer , Chris Ball , Maxime Ripard , linux-mmc , linux-arm-kernel , devicetree , Russell King - ARM Linux , Fabio Estevam , Arnd Bergmann , Jyri Sarha , Linus Walleij On 05/27/14 20:55, Olof Johansson wrote: > On Tue, May 27, 2014 at 06:53:26PM +0100, Mark Brown wrote: >> On Tue, May 27, 2014 at 03:50:33PM +0200, Ulf Hansson wrote: >> >>> To describe the HW in DT, the embedded SDIO card (actually it could be >>> any type of embedded card) shall be modelled as a child node to the >>> mmc host in DT. Similar to what you have proposed, but with the >>> difference that the child node _must_ contain a DT compatible string, >>> which means a "powerup-driver" can be probed. >> >>> Yes, I understand we might need one DT compatible string per board, >>> but that's because we need to model the hardware - and it differs. >> >>> To clarify my view, we do need a "powerup-driver" and the primary >>> reason is that we must not model "power up sequences" within DT. >>> Typically I see the "powerup-driver" as a simple platform driver >>> attached to the platform bus, but I that could of course differ. >> >> This then either conflicts with cases where we need to describe the >> actual contents of the slot with a compatible string or means that the >> SDIO driver needs to handle powerup sequencing since we should be >> binding to the first compatible we find. If the host controller driver >> and/or subsystem is going to deal with the powering up it's not clear >> that it specifically needs to be the compatible property that's used >> to determine the powerup method, it could just be a boolean or a >> 'power-method = blah' property (where blah is one of a series of strings >> defining methods). Alternatively we could have separate nodes for the >> slot and SDIO device but that feels meh. What's the hard requirement >> for it to specifically be a compatible property? > > +1. Just because we have a subnode in a device tree, we don't have to have > a driver bind against it. The MMC core code could go down into the subnodes, > find a "power-method =" property and go ahead and parse the rest of it. > There's no requirement that we do this through the Linux driver model of > probe(), etc. I prefer a power-method property over compatible matching. The fact that the subnode has a compatible string and properties for the device driver should not matter. >>> The slot will be the first level of child node under the mmc host, >>> then each slot may have a child node which models the embedded card. >>> But, let's leave that discussion for now. :-) >> >> OK, that's the separate node for the slot and device. >> >>> Powerup driver's ->probe(): >>> Typically the "powerup driver" will need to register a few callback >>> functions towards the mmc core. Typically at mmc_of_parse(), those >>> callbacks will have to be connected to a particular mmc host. >> >>> I would like to see three different callbacks, mirroring each of the >>> mmc_ios power_mode states MMC_POWER_OFF|UP|ON. >> >>> The power up sequence, performed by the mmc core: >>> The mmc_power_up|off functions, will invoke the registered "powerup >>> driver's" callbacks if they exists for the particular host it operates >>> on. >> >> There's also the need for the SDIO device to be able to get at the >> resources provided and actively work with them at runtime if it wants to >> manage things more actively (partial poweroff for low power states or >> managing clock rates for example). > > Again, I think it gets overly complicated by using a full driver for the > power management. Abstracted out into something separate and scalable > as number of devices grow? Sure, definitely. As a driver? Not convinced. I think somewhere in the thread Hans already indicated the term 'driver' was a misnomer. While monitoring the discussion I was wondering whether this type of power-up sequence handling is specific to mmc/sdio or could it also apply to say spi, i2c, or whatever. In other words, could the power-up sequence code be placed in drivers/of code. Regards, Arend From mboxrd@z Thu Jan 1 00:00:00 1970 From: arend@broadcom.com (Arend van Spriel) Date: Tue, 27 May 2014 22:27:43 +0200 Subject: RFC: representing sdio devices oob interrupt, clks, etc. in device tree In-Reply-To: <20140527185535.GB27420@quad.lixom.net> References: <20140525123452.GS22111@sirena.org.uk> <53824294.1090609@redhat.com> <20140526103807.GV22111@sirena.org.uk> <538321AB.4050006@redhat.com> <20140526142225.GF22111@sirena.org.uk> <538356DA.7090302@redhat.com> <53838023.2080807@redhat.com> <20140527175326.GZ12304@sirena.org.uk> <20140527185535.GB27420@quad.lixom.net> Message-ID: <5384F53F.4020408@broadcom.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 05/27/14 20:55, Olof Johansson wrote: > On Tue, May 27, 2014 at 06:53:26PM +0100, Mark Brown wrote: >> On Tue, May 27, 2014 at 03:50:33PM +0200, Ulf Hansson wrote: >> >>> To describe the HW in DT, the embedded SDIO card (actually it could be >>> any type of embedded card) shall be modelled as a child node to the >>> mmc host in DT. Similar to what you have proposed, but with the >>> difference that the child node _must_ contain a DT compatible string, >>> which means a "powerup-driver" can be probed. >> >>> Yes, I understand we might need one DT compatible string per board, >>> but that's because we need to model the hardware - and it differs. >> >>> To clarify my view, we do need a "powerup-driver" and the primary >>> reason is that we must not model "power up sequences" within DT. >>> Typically I see the "powerup-driver" as a simple platform driver >>> attached to the platform bus, but I that could of course differ. >> >> This then either conflicts with cases where we need to describe the >> actual contents of the slot with a compatible string or means that the >> SDIO driver needs to handle powerup sequencing since we should be >> binding to the first compatible we find. If the host controller driver >> and/or subsystem is going to deal with the powering up it's not clear >> that it specifically needs to be the compatible property that's used >> to determine the powerup method, it could just be a boolean or a >> 'power-method = blah' property (where blah is one of a series of strings >> defining methods). Alternatively we could have separate nodes for the >> slot and SDIO device but that feels meh. What's the hard requirement >> for it to specifically be a compatible property? > > +1. Just because we have a subnode in a device tree, we don't have to have > a driver bind against it. The MMC core code could go down into the subnodes, > find a "power-method =" property and go ahead and parse the rest of it. > There's no requirement that we do this through the Linux driver model of > probe(), etc. I prefer a power-method property over compatible matching. The fact that the subnode has a compatible string and properties for the device driver should not matter. >>> The slot will be the first level of child node under the mmc host, >>> then each slot may have a child node which models the embedded card. >>> But, let's leave that discussion for now. :-) >> >> OK, that's the separate node for the slot and device. >> >>> Powerup driver's ->probe(): >>> Typically the "powerup driver" will need to register a few callback >>> functions towards the mmc core. Typically at mmc_of_parse(), those >>> callbacks will have to be connected to a particular mmc host. >> >>> I would like to see three different callbacks, mirroring each of the >>> mmc_ios power_mode states MMC_POWER_OFF|UP|ON. >> >>> The power up sequence, performed by the mmc core: >>> The mmc_power_up|off functions, will invoke the registered "powerup >>> driver's" callbacks if they exists for the particular host it operates >>> on. >> >> There's also the need for the SDIO device to be able to get at the >> resources provided and actively work with them at runtime if it wants to >> manage things more actively (partial poweroff for low power states or >> managing clock rates for example). > > Again, I think it gets overly complicated by using a full driver for the > power management. Abstracted out into something separate and scalable > as number of devices grow? Sure, definitely. As a driver? Not convinced. I think somewhere in the thread Hans already indicated the term 'driver' was a misnomer. While monitoring the discussion I was wondering whether this type of power-up sequence handling is specific to mmc/sdio or could it also apply to say spi, i2c, or whatever. In other words, could the power-up sequence code be placed in drivers/of code. Regards, Arend