| Message ID | 1358955158-1510-7-git-send-email-g.liakhovetski@gmx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
After an internal discussion it occurred to us, that this binding On Wed, 23 Jan 2013, Guennadi Liakhovetski wrote: [snip] > +- toshiba,mmc-cap-sdio-irq : SDIO IRQ signalling should be used, if > + supported by the hardware, i.e. set MMC_CAP_SDIO_IRQ if > + TMIO_MMC_SDIO_IRQ is also set actually isn't tmio-mmc specific, so, it can be moved to [1] as +- cap-mmc-sdio-irq: SDIO IRQ is supported on this hardware Chris, what do you think? [1] http://www.spinics.net/lists/linux-mmc/msg18625.html Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, Jan 24 2013, Guennadi Liakhovetski wrote: > After an internal discussion it occurred to us, that this binding > > On Wed, 23 Jan 2013, Guennadi Liakhovetski wrote: > > [snip] > >> +- toshiba,mmc-cap-sdio-irq : SDIO IRQ signalling should be used, if >> + supported by the hardware, i.e. set MMC_CAP_SDIO_IRQ if >> + TMIO_MMC_SDIO_IRQ is also set > > actually isn't tmio-mmc specific, so, it can be moved to [1] as > > +- cap-mmc-sdio-irq: SDIO IRQ is supported on this hardware > > Chris, what do you think? Sounds right; perhaps we should call it "enable-sdio-irq" for consistency with the existing "enable-sdio-wakeup" (which sets a pm_caps flag)? Thanks, - Chris.
On Thu, 24 Jan 2013, Chris Ball wrote: > Hi, > > On Thu, Jan 24 2013, Guennadi Liakhovetski wrote: > > After an internal discussion it occurred to us, that this binding > > > > On Wed, 23 Jan 2013, Guennadi Liakhovetski wrote: > > > > [snip] > > > >> +- toshiba,mmc-cap-sdio-irq : SDIO IRQ signalling should be used, if > >> + supported by the hardware, i.e. set MMC_CAP_SDIO_IRQ if > >> + TMIO_MMC_SDIO_IRQ is also set > > > > actually isn't tmio-mmc specific, so, it can be moved to [1] as > > > > +- cap-mmc-sdio-irq: SDIO IRQ is supported on this hardware > > > > Chris, what do you think? > > Sounds right; perhaps we should call it "enable-sdio-irq" for consistency > with the existing "enable-sdio-wakeup" (which sets a pm_caps flag)? I tried to keep this binding similar to others, that I proposed in "mmc: add DT bindings for more MMC capability flags." Actually, the above is indeed wrong, I would call it "cap-sdio-irq." And in that patch I tried to keep binding names resembling as closely as possible respective MMC_CAP_* flags. I think, it would have been better if "enable-sdio-wakeup" and "keep-power-in-suspend" were also named, following the same rule, but it's too late now. Anyway, I'm not too concerned about the names. We can use "enable-sdio-irq" too if you like. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, Jan 24 2013, Guennadi Liakhovetski wrote: > I tried to keep this binding similar to others, that I proposed in "mmc: > add DT bindings for more MMC capability flags." Actually, the above is > indeed wrong, I would call it "cap-sdio-irq." And in that patch I tried to > keep binding names resembling as closely as possible respective MMC_CAP_* > flags. I think, it would have been better if "enable-sdio-wakeup" and > "keep-power-in-suspend" were also named, following the same rule, but it's > too late now. Anyway, I'm not too concerned about the names. We can use > "enable-sdio-irq" too if you like. I see. Okay, let's go with your proposed cap-* for each MMC_CAP_*, and the pm_caps can stay as they are. Thanks! - Chris.
Hi Chris On Thu, 24 Jan 2013, Chris Ball wrote: > Hi, > > On Thu, Jan 24 2013, Guennadi Liakhovetski wrote: > > I tried to keep this binding similar to others, that I proposed in "mmc: > > add DT bindings for more MMC capability flags." Actually, the above is > > indeed wrong, I would call it "cap-sdio-irq." And in that patch I tried to > > keep binding names resembling as closely as possible respective MMC_CAP_* > > flags. I think, it would have been better if "enable-sdio-wakeup" and > > "keep-power-in-suspend" were also named, following the same rule, but it's > > too late now. Anyway, I'm not too concerned about the names. We can use > > "enable-sdio-irq" too if you like. > > I see. Okay, let's go with your proposed cap-* for each MMC_CAP_*, and > the pm_caps can stay as they are. Thanks, let's do that. But in fact, in a recent discussion it has been pointed out to me, that this property +- toshiba,mmc-cap-sdio-irq : SDIO IRQ signalling should be used, if + supported by the hardware, i.e. set MMC_CAP_SDIO_IRQ if + TMIO_MMC_SDIO_IRQ is also set should be common for all MMC drivers: it should be possible to decide per SD interface, whether SDIO IRQ signalling should be enabled. What do you think? Shall we add a global "cap-sdio-irq" DT property instead of a toshiba-specific one? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Wed, Jan 30 2013, Guennadi Liakhovetski wrote: >> On Thu, Jan 24 2013, Guennadi Liakhovetski wrote: >> > I tried to keep this binding similar to others, that I proposed in "mmc: >> > add DT bindings for more MMC capability flags." Actually, the above is >> > indeed wrong, I would call it "cap-sdio-irq." And in that patch I tried to >> > keep binding names resembling as closely as possible respective MMC_CAP_* >> > flags. I think, it would have been better if "enable-sdio-wakeup" and >> > "keep-power-in-suspend" were also named, following the same rule, but it's >> > too late now. Anyway, I'm not too concerned about the names. We can use >> > "enable-sdio-irq" too if you like. >> >> I see. Okay, let's go with your proposed cap-* for each MMC_CAP_*, and >> the pm_caps can stay as they are. > > Thanks, let's do that. But in fact, in a recent discussion it has been > pointed out to me, that this property > > +- toshiba,mmc-cap-sdio-irq : SDIO IRQ signalling should be used, if > + supported by the hardware, i.e. set MMC_CAP_SDIO_IRQ if > + TMIO_MMC_SDIO_IRQ is also set > > should be common for all MMC drivers: it should be possible to decide per > SD interface, whether SDIO IRQ signalling should be enabled. What do you > think? Shall we add a global "cap-sdio-irq" DT property instead of a > toshiba-specific one? Yes, please. - Chris.
On Wed, Jan 23, 2013 at 04:32:33PM +0100, Guennadi Liakhovetski wrote: > Define device-tree bindings for the tmio-mmc driver to be able to specify > parameters, currently provided in platform data. > > Cc: Magnus Damm <magnus.damm@gmail.com> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> > --- > > Please, comment on this one, since it is defining an ABI > > Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mmc/tmio_mmc.txt > > diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt > new file mode 100644 > index 0000000..dd8decd > --- /dev/null > +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt > @@ -0,0 +1,19 @@ > +* Toshiba Mobile IO SD/MMC controller > + > +The tmio-mmc driver doesn't probe its devices actively, instead its binding to > +devices is managed by either MFD drivers or by the sh_mobile_sdhi platform > +driver. Those drivers supply the tmio-mmc driver with platform data, that either > +describe hardware capabilities, known to them, or are obtained by them from > +their own platform data or from their DT information. In the latter case all > +compulsory and any optional properties, common to all SD/MMC drivers, as > +described in mmc.txt, should or can be used. Additionally the following optional > +bindings can be used. They set either respective TMIO_MMC_* flags or MMC_CAP_* > +capabilities. > + > +Optional properties: > +- toshiba,mmc-wrprotect-disable : set TMIO_MMC_WRPROTECT_DISABLE flag > +- toshiba,mmc-blksz-2bytes : set TMIO_MMC_BLKSZ_2BYTES > +- toshiba,mmc-cap-sdio-irq : SDIO IRQ signalling should be used, if > + supported by the hardware, i.e. set MMC_CAP_SDIO_IRQ if > + TMIO_MMC_SDIO_IRQ is also set > +- toshiba,mmc-has-idle-wait : set TMIO_MMC_HAS_IDLE_WAIT FWIW, TMIO_MMC_HAS_IDLE_WAIT appears to be required for SDHI0 to function on the Marzen board. As I have been doing some work on bring up the Marzen board using DT I am very happy to see these new bindings. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt new file mode 100644 index 0000000..dd8decd --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -0,0 +1,19 @@ +* Toshiba Mobile IO SD/MMC controller + +The tmio-mmc driver doesn't probe its devices actively, instead its binding to +devices is managed by either MFD drivers or by the sh_mobile_sdhi platform +driver. Those drivers supply the tmio-mmc driver with platform data, that either +describe hardware capabilities, known to them, or are obtained by them from +their own platform data or from their DT information. In the latter case all +compulsory and any optional properties, common to all SD/MMC drivers, as +described in mmc.txt, should or can be used. Additionally the following optional +bindings can be used. They set either respective TMIO_MMC_* flags or MMC_CAP_* +capabilities. + +Optional properties: +- toshiba,mmc-wrprotect-disable : set TMIO_MMC_WRPROTECT_DISABLE flag +- toshiba,mmc-blksz-2bytes : set TMIO_MMC_BLKSZ_2BYTES +- toshiba,mmc-cap-sdio-irq : SDIO IRQ signalling should be used, if + supported by the hardware, i.e. set MMC_CAP_SDIO_IRQ if + TMIO_MMC_SDIO_IRQ is also set +- toshiba,mmc-has-idle-wait : set TMIO_MMC_HAS_IDLE_WAIT
Define device-tree bindings for the tmio-mmc driver to be able to specify parameters, currently provided in platform data. Cc: Magnus Damm <magnus.damm@gmail.com> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> --- Please, comment on this one, since it is defining an ABI Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/tmio_mmc.txt