All of lore.kernel.org
 help / color / mirror / Atom feed
From: Levin Du <djw@t-chip.com.cn>
To: Robin Murphy <robin.murphy@arm.com>, linux-rockchip@lists.infradead.org
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, Wayne Chou <zxf@t-chip.com.cn>,
	Heiko Stuebner <heiko@sntech.de>, Arnd Bergmann <arnd@arndb.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org,
	Sugar Zhang <sugar.zhang@rock-chips.com>,
	Rob Herring <robh+dt@kernel.org>,
	Finley Xiao <finley.xiao@rock-chips.com>,
	David Wu <david.wu@rock-chips.com>,
	William Wu <william.wu@rock-chips.com>,
	Rocky Hao <rocky.hao@rock-chips.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328
Date: Fri, 11 May 2018 11:45:24 +0800	[thread overview]
Message-ID: <3fdfcc9b-90b5-191c-37e0-c99389a4e872@t-chip.com.cn> (raw)
In-Reply-To: <76f2bbde-e158-a186-f136-9fb610a810c5@arm.com>

On 2018-05-10 8:50 PM, Robin Murphy wrote:
> On 10/05/18 10:16, djw@t-chip.com.cn wrote:
>> From: Levin Du <djw@t-chip.com.cn>
>>
>> Adding a new gpio controller named "gpio-syscon10" to rk3328, providing
>> access to the pins defined in the syscon GRF_SOC_CON10.
>
> This is the GPIO_MUTE pin, right? The public TRM is rather vague, but 
> cross-referencing against the datasheet and schematics implies that 
> it's the "gpiomut_*" part of the GRF bit names which is most significant.
>
> It might be worth using a more descriptive name here, since "syscon10" 
> is pretty much meaningless at the board level.
>
> Robin.
>
Previously I though other bits might be able to reference from syscon10, 
other than GPIO_MUTE alone.
If it is renamed to gpio-mute, then the GPIO_MUTE pin is accessed as 
`<&gpio-mute 1>`. Yet other
bits in syscon10 can also be referenced, say, `<&gpio-mute 10>`, which 
is not good.

I'd like to add a `gpio,syscon-bit` property to gpio-syscon, which 
overrides the properties
of bit_count,  data_bit_offset and dir_bit_offset in the driver. For 
example:

                 gpio_mute: gpio-mute {
                         compatible = "rockchip,gpio-syscon";
                         gpio-controller;
                         #gpio-cells = <2>;
                         gpio,syscon-dev = <0 0x0428 0>;
                         gpio,syscon-bit = <1 1 0>;
                 };

That way, the mute pin is strictly specified as <&gpio_mute 0>, and 
<&gpio_mute 1> will be invalid.
I think that is neat, and consistent with the gpio_mute name.

Thanks
Levin

WARNING: multiple messages have this Message-ID (diff)
From: djw@t-chip.com.cn (Levin Du)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328
Date: Fri, 11 May 2018 11:45:24 +0800	[thread overview]
Message-ID: <3fdfcc9b-90b5-191c-37e0-c99389a4e872@t-chip.com.cn> (raw)
In-Reply-To: <76f2bbde-e158-a186-f136-9fb610a810c5@arm.com>

On 2018-05-10 8:50 PM, Robin Murphy wrote:
> On 10/05/18 10:16, djw at t-chip.com.cn wrote:
>> From: Levin Du <djw@t-chip.com.cn>
>>
>> Adding a new gpio controller named "gpio-syscon10" to rk3328, providing
>> access to the pins defined in the syscon GRF_SOC_CON10.
>
> This is the GPIO_MUTE pin, right? The public TRM is rather vague, but 
> cross-referencing against the datasheet and schematics implies that 
> it's the "gpiomut_*" part of the GRF bit names which is most significant.
>
> It might be worth using a more descriptive name here, since "syscon10" 
> is pretty much meaningless at the board level.
>
> Robin.
>
Previously I though other bits might be able to reference from syscon10, 
other than GPIO_MUTE alone.
If it is renamed to gpio-mute, then the GPIO_MUTE pin is accessed as 
`<&gpio-mute 1>`. Yet other
bits in syscon10 can also be referenced, say, `<&gpio-mute 10>`, which 
is not good.

I'd like to add a `gpio,syscon-bit` property to gpio-syscon, which 
overrides the properties
of bit_count,? data_bit_offset and dir_bit_offset in the driver. For 
example:

 ??????????????? gpio_mute: gpio-mute {
 ??????????????????????? compatible = "rockchip,gpio-syscon";
 ??????????????????????? gpio-controller;
 ??????????????????????? #gpio-cells = <2>;
 ??????????????????????? gpio,syscon-dev = <0 0x0428 0>;
 ??????????????????????? gpio,syscon-bit = <1 1 0>;
 ??????????????? };

That way, the mute pin is strictly specified as <&gpio_mute 0>, and 
<&gpio_mute 1> will be invalid.
I think that is neat, and consistent with the gpio_mute name.

Thanks
Levin

  reply	other threads:[~2018-05-11  3:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10  9:16 [PATCH v1 0/5] Add sdmmc UHS support to ROC-RK3328-CC board djw
2018-05-10  9:16 ` djw at t-chip.com.cn
2018-05-10  9:16 ` [PATCH v1 1/5] gpio: syscon: allow fetching syscon from parent node djw
2018-05-10  9:16 ` [PATCH v1 2/5] gpio: syscon: Add gpio-syscon for rockchip djw
2018-05-10  9:16   ` djw at t-chip.com.cn
2018-05-10 14:56   ` Robin Murphy
2018-05-10 14:56     ` Robin Murphy
2018-05-11  2:16     ` Levin Du
2018-05-11  2:16       ` Levin Du
2018-05-10  9:16 ` [PATCH v1 3/5] arm64: dts: rockchip: Add gpio-syscon10 to rk3328 djw
2018-05-10  9:16   ` djw at t-chip.com.cn
2018-05-10 12:50   ` Robin Murphy
2018-05-10 12:50     ` Robin Murphy
2018-05-11  3:45     ` Levin Du [this message]
2018-05-11  3:45       ` Levin Du
2018-05-11 12:24       ` Rob Herring
2018-05-11 12:24         ` Rob Herring
2018-05-14  1:28         ` Levin Du
2018-05-14  1:28           ` Levin Du
2018-05-11 12:22   ` Rob Herring
2018-05-11 12:22     ` Rob Herring
2018-05-14  1:22     ` Levin Du
2018-05-14  1:22       ` Levin Du
2018-05-10  9:16 ` [PATCH v1 4/5] arm64: dts: rockchip: Add io-domain to roc-rk3328-cc djw
2018-05-10  9:16   ` djw at t-chip.com.cn
2018-05-10  9:27 ` djw
2018-05-10  9:27   ` djw at t-chip.com.cn
2018-05-10  9:28 ` [PATCH v1 5/5] arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc djw
2018-05-10  9:28   ` djw at t-chip.com.cn

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=3fdfcc9b-90b5-191c-37e0-c99389a4e872@t-chip.com.cn \
    --to=djw@t-chip.com.cn \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=david.wu@rock-chips.com \
    --cc=devicetree@vger.kernel.org \
    --cc=finley.xiao@rock-chips.com \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rocky.hao@rock-chips.com \
    --cc=sugar.zhang@rock-chips.com \
    --cc=will.deacon@arm.com \
    --cc=william.wu@rock-chips.com \
    --cc=zxf@t-chip.com.cn \
    /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.