From: "Huang, Tao" <huangtao@rock-chips.com>
To: Heiko Stuebner <heiko@sntech.de>
Cc: "jianqun.xu" <jay.xu@rock-chips.com>,
wsa@the-dreams.de, wdc@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 16:48:59 +0800 [thread overview]
Message-ID: <568B837B.50607@rock-chips.com> (raw)
In-Reply-To: <7893052.zgDX0r4i77@phil>
Hi, Heiko:
On 2016年01月05日 16:00, Heiko Stuebner wrote:
> Hi Tao,
>
> Am Dienstag, 5. Januar 2016, 15:42:32 schrieb Huang, Tao:
>> I don't think this is a good idea. This will trigger a lots of init call
>> failed. Before pmic init, all i2c device driver transmit will failed,
>> and because i2c is slow bus, and i2c transmit may failed by other
>> reasons, so the i2c driver and i2c device driver will try many times to
>> make sure the transmit completion. These unnecessary transmission will
>> make Linux boot very slow.
>
> In general, the slowdown won't be _this_ much if touchscreen drivers need
> one deferral-round before i2c is available. I'm also only pointing out
> things I remember from the last time this came up.
>
> rk3x-i2c even was here already:
> http://www.spinics.net/lists/linux-i2c/msg16680.html
OK. I don't agree with the rule, but we will follow it.
>
>
>> I2C bus should be subsys, and we can easy resolve this problem, why we
>> depends on a complicated and slow implementation?
>
> because it's the only safe way to do that. Because now you need i2c-init at
> subsys-init time, some months later some other soc may need some other
> ordering, especially needing i2c-init later/earlier.
>
> Going through the deferral mechanism is the only way currently available to
> actually make this work on all socs.
>
> Tomeu from Collabora is working on some better scheme to optimize device
> probing order but it looks like this may be a bit off still.
>
>
>>> 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.
>>
>> Unfortunately, mostly driver do not support regulator api. They are
>> suppose power is on.
>
> Having touchscreen drivers support its proper supply-regulators is not
> rocket science ;-) [0] , so I would consider this a bug in the touchscreen
> driver itself.
I don't just talk about touch screen driver, most i2c device driver such
as input sensor/camera/rtc/battery will suffer. So people will see their
drivers do not work or slow down on rk3368 platform :(
Thanks!
Huang, Tao
WARNING: multiple messages have this Message-ID (diff)
From: huangtao@rock-chips.com (Huang, Tao)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] i2c: rk3x: init module as subsys call
Date: Tue, 5 Jan 2016 16:48:59 +0800 [thread overview]
Message-ID: <568B837B.50607@rock-chips.com> (raw)
In-Reply-To: <7893052.zgDX0r4i77@phil>
Hi, Heiko:
On 2016?01?05? 16:00, Heiko Stuebner wrote:
> Hi Tao,
>
> Am Dienstag, 5. Januar 2016, 15:42:32 schrieb Huang, Tao:
>> I don't think this is a good idea. This will trigger a lots of init call
>> failed. Before pmic init, all i2c device driver transmit will failed,
>> and because i2c is slow bus, and i2c transmit may failed by other
>> reasons, so the i2c driver and i2c device driver will try many times to
>> make sure the transmit completion. These unnecessary transmission will
>> make Linux boot very slow.
>
> In general, the slowdown won't be _this_ much if touchscreen drivers need
> one deferral-round before i2c is available. I'm also only pointing out
> things I remember from the last time this came up.
>
> rk3x-i2c even was here already:
> http://www.spinics.net/lists/linux-i2c/msg16680.html
OK. I don't agree with the rule, but we will follow it.
>
>
>> I2C bus should be subsys, and we can easy resolve this problem, why we
>> depends on a complicated and slow implementation?
>
> because it's the only safe way to do that. Because now you need i2c-init at
> subsys-init time, some months later some other soc may need some other
> ordering, especially needing i2c-init later/earlier.
>
> Going through the deferral mechanism is the only way currently available to
> actually make this work on all socs.
>
> Tomeu from Collabora is working on some better scheme to optimize device
> probing order but it looks like this may be a bit off still.
>
>
>>> 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.
>>
>> Unfortunately, mostly driver do not support regulator api. They are
>> suppose power is on.
>
> Having touchscreen drivers support its proper supply-regulators is not
> rocket science ;-) [0] , so I would consider this a bug in the touchscreen
> driver itself.
I don't just talk about touch screen driver, most i2c device driver such
as input sensor/camera/rtc/battery will suffer. So people will see their
drivers do not work or slow down on rk3368 platform :(
Thanks!
Huang, Tao
next prev parent reply other threads:[~2016-01-05 8:49 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 [this message]
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
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=568B837B.50607@rock-chips.com \
--to=huangtao@rock-chips.com \
--cc=heiko@sntech.de \
--cc=jay.xu@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.