All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Ball <cjb@laptop.org>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-mmc@vger.kernel.org, linux-sh@vger.kernel.org,
	Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH/RFC v2 06/11] mmc: tmio-mmc: define device-tree bindings
Date: Wed, 30 Jan 2013 09:09:44 -0500	[thread overview]
Message-ID: <87r4l269uf.fsf@octavius.laptop.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1301301453110.3113@axis700.grange> (Guennadi Liakhovetski's message of "Wed, 30 Jan 2013 15:07:03 +0100 (CET)")

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.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

WARNING: multiple messages have this Message-ID (diff)
From: Chris Ball <cjb@laptop.org>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-mmc@vger.kernel.org, linux-sh@vger.kernel.org,
	Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH/RFC v2 06/11] mmc: tmio-mmc: define device-tree bindings
Date: Wed, 30 Jan 2013 14:09:44 +0000	[thread overview]
Message-ID: <87r4l269uf.fsf@octavius.laptop.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1301301453110.3113@axis700.grange> (Guennadi Liakhovetski's message of "Wed, 30 Jan 2013 15:07:03 +0100 (CET)")

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.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

  reply	other threads:[~2013-01-30 14:09 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-23 15:32 [PATCH v2 00/11] mmc: core and driver DT and related development Guennadi Liakhovetski
2013-01-23 15:32 ` Guennadi Liakhovetski
2013-01-23 15:32 ` [PATCH v2 01/11] mmc: sdhi, tmio: only check flags in tmio-mmc driver proper Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski
2013-01-23 15:32 ` [PATCH v2 02/11] mmc: deprecate redundant cd-inverted and wp-inverted DT properties Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski
2013-01-28 22:23   ` Chris Ball
2013-01-28 22:23     ` Chris Ball
2013-01-30 15:47     ` Arnd Bergmann
2013-01-30 16:02       ` Guennadi Liakhovetski
2013-01-30 16:02         ` Guennadi Liakhovetski
2013-01-30 16:13         ` Guennadi Liakhovetski
2013-01-30 16:13           ` Guennadi Liakhovetski
2013-01-30 16:29           ` Arnd Bergmann
2013-01-30 16:29             ` Arnd Bergmann
2013-01-30 17:03             ` Guennadi Liakhovetski
2013-01-30 17:03               ` Guennadi Liakhovetski
2013-01-31  0:09               ` Arnd Bergmann
2013-01-31  0:20                 ` Chris Ball
2013-01-31  0:20                   ` Chris Ball
2013-01-31  6:47                 ` Guennadi Liakhovetski
2013-01-31  6:47                   ` Guennadi Liakhovetski
2013-01-31  9:00                   ` Arnd Bergmann
2013-01-23 15:32 ` [PATCH v2 03/11] mmc: provide a standard MMC device-tree binding parser centrally Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski
2013-01-23 15:32 ` [PATCH v2 04/11] mmc: (cosmetic) remove "extern" from function declarations Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski
2013-01-23 15:32 ` [PATCH v2 05/11] mmc: sh-mmcif: use mmc_of_parse() to parse standard MMC DT bindings Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski
2013-01-28 22:25   ` Chris Ball
2013-01-28 22:25     ` Chris Ball
2013-01-23 15:32 ` [PATCH/RFC v2 06/11] mmc: tmio-mmc: define device-tree bindings Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski
2013-01-24 15:34   ` Guennadi Liakhovetski
2013-01-24 15:34     ` Guennadi Liakhovetski
2013-01-24 15:39     ` Chris Ball
2013-01-24 15:39       ` Chris Ball
2013-01-24 15:58       ` Guennadi Liakhovetski
2013-01-24 15:58         ` Guennadi Liakhovetski
2013-01-24 16:03         ` Chris Ball
2013-01-24 16:03           ` Chris Ball
2013-01-30 14:07           ` Guennadi Liakhovetski
2013-01-30 14:07             ` Guennadi Liakhovetski
2013-01-30 14:09             ` Chris Ball [this message]
2013-01-30 14:09               ` Chris Ball
2013-02-01  4:23   ` Simon Horman
2013-02-01  4:23     ` Simon Horman
2013-01-23 15:32 ` [PATCH v2 07/11] mmc: tmio-mmc: parse " Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski
2013-01-23 15:32 ` [PATCH v2 08/11] mmc: sh_mobile_sdhi: remove unused .pdata field Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski
2013-01-23 15:32 ` [PATCH v2 09/11] mmc: sh_mobile_sdhi: use managed resource allocations Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski
2013-01-23 15:32 ` [PATCH v2 10/11] mmc: tmio: remove unused and deprecated symbols Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski
2013-01-23 15:32 ` [PATCH v2 11/11] mmc: tmio: add support for the VccQ regulator Guennadi Liakhovetski
2013-01-23 15:32   ` Guennadi Liakhovetski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r4l269uf.fsf@octavius.laptop.org \
    --to=cjb@laptop.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.