Re: [PATCH] i2c: rk3x: init module as subsys call

From	"Huang, Tao" <huangtao@rock-chips.com>
Newsgroups	linux.kernel
Subject	Re: [PATCH] i2c: rk3x: init module as subsys call
Date	2016-01-05 09:50 +0100
Message-ID	<qNvtw-80m-7@gated-at.bofh.it> (permalink)
References	<qNqau-4fJ-17@gated-at.bofh.it> <qNtUK-6Zq-21@gated-at.bofh.it> <qNuxs-7ih-7@gated-at.bofh.it> <qNuQO-7Jz-9@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Thread

[PATCH] i2c: rk3x: init module as subsys call "jianqun.xu" <jay.xu@rock-chips.com> - 2016-01-05 04:10 +0100
  Re: [PATCH] i2c: rk3x: init module as subsys call Heiko Stuebner <heiko@sntech.de> - 2016-01-05 08:10 +0100
    Re: [PATCH] i2c: rk3x: init module as subsys call "Huang, Tao" <huangtao@rock-chips.com> - 2016-01-05 08:50 +0100
      Re: [PATCH] i2c: rk3x: init module as subsys call Heiko Stuebner <heiko@sntech.de> - 2016-01-05 09:10 +0100
        Re: [PATCH] i2c: rk3x: init module as subsys call "Huang, Tao" <huangtao@rock-chips.com> - 2016-01-05 09:50 +0100
          Re: [PATCH] i2c: rk3x: init module as subsys call Wolfram Sang <wsa@the-dreams.de> - 2016-01-05 11:10 +0100
    Re: [PATCH] i2c: rk3x: init module as subsys call Jianqun Xu <jay.xu@rock-chips.com> - 2016-01-05 08:50 +0100

csiph-web