From: "David.Wu" <wdc@rock-chips.com>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: David Wu <david.wu@rock-chips.com>,
khilman@kernel.org, nm@ti.com, huangtao@rock-chips.com,
cf@rock-chips.com, zyw@rock-chips.com, xjq@rock-chips.com,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PM / AVS: rockchip-io: add GRF and PMUGRF types to distinguish
Date: Tue, 2 Feb 2016 17:38:43 +0800 [thread overview]
Message-ID: <56B07923.9020900@rock-chips.com> (raw)
In-Reply-To: <5354361.hQXgJ7cEGx@diego>
Hi Heiko,
在 2016/2/2 5:17, Heiko Stübner 写道:
> Hi David,
>
> Am Montag, 1. Februar 2016, 16:54:38 schrieb David.Wu:
>> 在 2016/1/30 20:39, Heiko Stuebner 写道:
>>> Am Samstag, 30. Januar 2016, 20:01:45 schrieb David Wu:
>>>> As rk3368 contained two separated iodomain areas, this was
>>>> determined to use which regmap base address.
>>>>
>>>> Signed-off-by: David Wu <david.wu@rock-chips.com>
>>> I don't think we need to specify this on a driver level. Both GRF areas
>>> are
>>> "General register files" only located in two separate power-domains.
>>> So the rockchip,grf property should work for both. Especially as nothing
>>> keeps designers from introducing yet another GRF-area somewhere else ;-)
>>>
>>> >From when I started working on the rk3368, I still have a preliminary
>>>
>>> patches for that sitting here, so I've attached on how I envisoned that to
>>> work.
>> Okay, i agree to you, but it make someone a little confused just from
>> the drive code,
>> not DT file, about pmugrf regmap base address.:-)
>>
>> How do you feel about intergating GRF and PMU drivers in one driver?
>> Thanks!
> I will very strongly disagree here ;-) .
> Similar to the power-domains being part of the pmu, the io-domains are
> part of their individual GRFs. So if you want it really clean and tidy the way
> to go foward will be the attached patches. Compile-tested only.
Thanks for your reply, the patchs look better than mine.
I have tested them on sdk board and i found something may be wrong.
"parent->of_node" instead of "parent", as the parent is not null if
parent-node not used.
if (parent->of_node) {
iod->grf = syscon_node_to_regmap(parent->of_node);
} else {
dev_dbg(&pdev->dev, "falling back to old binding\n");
iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
}
> Other things like the usbphy control should move there as well in the long
> run. But that's not immediate necessary.
>
>
> Heiko
WARNING: multiple messages have this Message-ID (diff)
From: wdc@rock-chips.com (David.Wu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PM / AVS: rockchip-io: add GRF and PMUGRF types to distinguish
Date: Tue, 2 Feb 2016 17:38:43 +0800 [thread overview]
Message-ID: <56B07923.9020900@rock-chips.com> (raw)
In-Reply-To: <5354361.hQXgJ7cEGx@diego>
Hi Heiko,
? 2016/2/2 5:17, Heiko St?bner ??:
> Hi David,
>
> Am Montag, 1. Februar 2016, 16:54:38 schrieb David.Wu:
>> ? 2016/1/30 20:39, Heiko Stuebner ??:
>>> Am Samstag, 30. Januar 2016, 20:01:45 schrieb David Wu:
>>>> As rk3368 contained two separated iodomain areas, this was
>>>> determined to use which regmap base address.
>>>>
>>>> Signed-off-by: David Wu <david.wu@rock-chips.com>
>>> I don't think we need to specify this on a driver level. Both GRF areas
>>> are
>>> "General register files" only located in two separate power-domains.
>>> So the rockchip,grf property should work for both. Especially as nothing
>>> keeps designers from introducing yet another GRF-area somewhere else ;-)
>>>
>>> >From when I started working on the rk3368, I still have a preliminary
>>>
>>> patches for that sitting here, so I've attached on how I envisoned that to
>>> work.
>> Okay, i agree to you, but it make someone a little confused just from
>> the drive code,
>> not DT file, about pmugrf regmap base address.:-)
>>
>> How do you feel about intergating GRF and PMU drivers in one driver?
>> Thanks!
> I will very strongly disagree here ;-) .
> Similar to the power-domains being part of the pmu, the io-domains are
> part of their individual GRFs. So if you want it really clean and tidy the way
> to go foward will be the attached patches. Compile-tested only.
Thanks for your reply, the patchs look better than mine.
I have tested them on sdk board and i found something may be wrong.
"parent->of_node" instead of "parent", as the parent is not null if
parent-node not used.
if (parent->of_node) {
iod->grf = syscon_node_to_regmap(parent->of_node);
} else {
dev_dbg(&pdev->dev, "falling back to old binding\n");
iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
}
> Other things like the usbphy control should move there as well in the long
> run. But that's not immediate necessary.
>
>
> Heiko
next prev parent reply other threads:[~2016-02-02 9:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-30 12:01 [PATCH] PM / AVS: rockchip-io: add GRF and PMUGRF types to distinguish David Wu
2016-01-30 12:01 ` David Wu
2016-01-30 12:01 ` David Wu
2016-01-30 12:39 ` Heiko Stuebner
2016-01-30 12:39 ` Heiko Stuebner
2016-01-30 12:39 ` Heiko Stuebner
2016-02-01 8:54 ` David.Wu
2016-02-01 8:54 ` David.Wu
2016-02-01 21:17 ` Heiko Stübner
2016-02-01 21:17 ` Heiko Stübner
2016-02-01 21:17 ` Heiko Stübner
2016-02-02 9:38 ` David.Wu [this message]
2016-02-02 9:38 ` David.Wu
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=56B07923.9020900@rock-chips.com \
--to=wdc@rock-chips.com \
--cc=cf@rock-chips.com \
--cc=david.wu@rock-chips.com \
--cc=heiko@sntech.de \
--cc=huangtao@rock-chips.com \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=nm@ti.com \
--cc=xjq@rock-chips.com \
--cc=zyw@rock-chips.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.