From: Jianqun Xu <jay.xu@rock-chips.com>
To: Heiko Stuebner <heiko@sntech.de>
Cc: wsa@the-dreams.de, wdc@rock-chips.com, huangtao@rock-chips.com,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i2c: rk3x: init module as subsys call
Date: Tue, 5 Jan 2016 15:42:55 +0800 [thread overview]
Message-ID: <568B73FF.9090508@rock-chips.com> (raw)
In-Reply-To: <2513923.8oltbpbAin@phil>
Hi Heiko:
在 05/01/2016 15:02, Heiko Stuebner 写道:
> Hi Jianqun,
>
> Am Dienstag, 5. Januar 2016, 11:02:18 schrieb jianqun.xu:
>> From: Xu Jianqun <jay.xu@rock-chips.com>
>>
>> There is a requirement from pmic device, which is on the i2c bus,
>> that the pmic needs to be called earlier then devices powered by
>> the outputs of the pmic, if not, the devices maybe fail to probe.
>>
>> For example, a pmic on i2c0, and touchscreen device on i2c2,
>> i2c0: - pmic(rk818)
>> i2c2: - ts(gt911), powered by rk818 on i2c0
>>
>> The problem will happen if the i2c2 node in dts file is ordered
>> before i2c0 node, then ts(gt911) will be probed before pmic(rk818),
>> since the power from the pmic(rk818) for ts(gt911) hasn't enabled,
>> so ts(gt911) will fail to probe due to the failure of i2c test.
>>
>> But if we set the i2c0 node before i2c2, there is no this issue.
>>
>> The stable way to make sure that pmic can be intalized before other
>> peripher devices is to make the pmic module be subsys call, the i2c
>> module need to be subsys call firstly.
>
> I do believe that came up in the past already and the direction from then
> was (and most likely still is) that drivers should make use of the probe-
> deferral mechanism instead of wiggling with the initcall ordering.
>
> Your touchscreen will have a "xyz-supply" property and I think the
> regulator-framework should already emit a -EPROBE_DEFER at regulator_get,
> when the regulator is specified but not available yet.
>
It seems more reasonable, thanks for advice, I will have a try.
>
> Heiko
>
>>
>> Signed-off-by: Xu Jianqun <jay.xu@rock-chips.com>
>> ---
>> drivers/i2c/busses/i2c-rk3x.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
>> index c1935eb..00e5959 100644
>> --- a/drivers/i2c/busses/i2c-rk3x.c
>> +++ b/drivers/i2c/busses/i2c-rk3x.c
>> @@ -1037,7 +1037,17 @@ static struct platform_driver rk3x_i2c_driver = {
>> },
>> };
>>
>> -module_platform_driver(rk3x_i2c_driver);
>> +static int __init rk3x_i2c_init(void)
>> +{
>> + return platform_driver_register(&rk3x_i2c_driver);
>> +}
>> +subsys_initcall(rk3x_i2c_init);
>> +
>> +static void __exit rk3x_i2c_exit(void)
>> +{
>> + platform_driver_unregister(&rk3x_i2c_driver);
>> +}
>> +module_exit(rk3x_i2c_exit);
>>
>> MODULE_DESCRIPTION("Rockchip RK3xxx I2C Bus driver");
>> MODULE_AUTHOR("Max Schwarz <max.schwarz@online.de>");
>
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: jay.xu@rock-chips.com (Jianqun Xu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] i2c: rk3x: init module as subsys call
Date: Tue, 5 Jan 2016 15:42:55 +0800 [thread overview]
Message-ID: <568B73FF.9090508@rock-chips.com> (raw)
In-Reply-To: <2513923.8oltbpbAin@phil>
Hi Heiko:
? 05/01/2016 15:02, Heiko Stuebner ??:
> Hi Jianqun,
>
> Am Dienstag, 5. Januar 2016, 11:02:18 schrieb jianqun.xu:
>> From: Xu Jianqun <jay.xu@rock-chips.com>
>>
>> There is a requirement from pmic device, which is on the i2c bus,
>> that the pmic needs to be called earlier then devices powered by
>> the outputs of the pmic, if not, the devices maybe fail to probe.
>>
>> For example, a pmic on i2c0, and touchscreen device on i2c2,
>> i2c0: - pmic(rk818)
>> i2c2: - ts(gt911), powered by rk818 on i2c0
>>
>> The problem will happen if the i2c2 node in dts file is ordered
>> before i2c0 node, then ts(gt911) will be probed before pmic(rk818),
>> since the power from the pmic(rk818) for ts(gt911) hasn't enabled,
>> so ts(gt911) will fail to probe due to the failure of i2c test.
>>
>> But if we set the i2c0 node before i2c2, there is no this issue.
>>
>> The stable way to make sure that pmic can be intalized before other
>> peripher devices is to make the pmic module be subsys call, the i2c
>> module need to be subsys call firstly.
>
> I do believe that came up in the past already and the direction from then
> was (and most likely still is) that drivers should make use of the probe-
> deferral mechanism instead of wiggling with the initcall ordering.
>
> Your touchscreen will have a "xyz-supply" property and I think the
> regulator-framework should already emit a -EPROBE_DEFER at regulator_get,
> when the regulator is specified but not available yet.
>
It seems more reasonable, thanks for advice, I will have a try.
>
> Heiko
>
>>
>> Signed-off-by: Xu Jianqun <jay.xu@rock-chips.com>
>> ---
>> drivers/i2c/busses/i2c-rk3x.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
>> index c1935eb..00e5959 100644
>> --- a/drivers/i2c/busses/i2c-rk3x.c
>> +++ b/drivers/i2c/busses/i2c-rk3x.c
>> @@ -1037,7 +1037,17 @@ static struct platform_driver rk3x_i2c_driver = {
>> },
>> };
>>
>> -module_platform_driver(rk3x_i2c_driver);
>> +static int __init rk3x_i2c_init(void)
>> +{
>> + return platform_driver_register(&rk3x_i2c_driver);
>> +}
>> +subsys_initcall(rk3x_i2c_init);
>> +
>> +static void __exit rk3x_i2c_exit(void)
>> +{
>> + platform_driver_unregister(&rk3x_i2c_driver);
>> +}
>> +module_exit(rk3x_i2c_exit);
>>
>> MODULE_DESCRIPTION("Rockchip RK3xxx I2C Bus driver");
>> MODULE_AUTHOR("Max Schwarz <max.schwarz@online.de>");
>
>
>
>
next prev parent reply other threads:[~2016-01-05 7:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-05 3:02 [PATCH] i2c: rk3x: init module as subsys call jianqun.xu
2016-01-05 3:02 ` jianqun.xu
2016-01-05 7:02 ` Heiko Stuebner
2016-01-05 7:02 ` Heiko Stuebner
2016-01-05 7:42 ` Huang, Tao
2016-01-05 7:42 ` Huang, Tao
2016-01-05 7:42 ` Huang, Tao
2016-01-05 8:00 ` Heiko Stuebner
2016-01-05 8:00 ` Heiko Stuebner
2016-01-05 8:48 ` Huang, Tao
2016-01-05 8:48 ` Huang, Tao
2016-01-05 10:01 ` Wolfram Sang
2016-01-05 10:01 ` Wolfram Sang
2016-01-05 7:42 ` Jianqun Xu [this message]
2016-01-05 7:42 ` Jianqun Xu
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=568B73FF.9090508@rock-chips.com \
--to=jay.xu@rock-chips.com \
--cc=heiko@sntech.de \
--cc=huangtao@rock-chips.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=wdc@rock-chips.com \
--cc=wsa@the-dreams.de \
/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.