Re: [PATCH] i2c: rcar: initialize earlier using subsys_initcall()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Vladimir and Eugeniu,

> The purpose of this patch looks pretty similar to:
> 104522806a7d ("i2c: designware: dw_i2c_init_driver as subsys initcall")
> 74f56c4ad4e4 ("i2c-bfin-twi: move setup to the earlier subsys initcall")
> b8680784875b ("i2c-gpio: Move initialization code to subsys_initcall()")
> 5d3f33318a6c ("[PATCH] i2c-imx: make bus available early")
> ccb3bc16b489 ("i2c-sh_mobile: change module_init() to subsys_initcall()")
> 18dc83a6ea48 ("i2c: i2c-s3c2410: Initialise Samsung I2C controller early")
> 2514cca06be9 ("[ARM] 5394/1: Add static bus numbering support to i2c-versatile")
> 47a9b1379a5e ("i2c-pxa: Initialize early")
> 
> However, the story behind it might be a bit different.

It definately is. The above drivers are very old, from the days where
-EPROBE_DEFER was non-existant. They needed subsys_initcall to be able
to boot. The reason they still have it is simple: reverting to
module_initcall could cause regressions.

This patch is about boot-time. Very different.

> Experimenting with async probing in various rcar-specific drivers (e.g.
> rcar-du, vsp1, rcar-fcp, rcar-vin), it was noticed that in most of
> the cases enabling async probing in one driver introduced some degree of
> inconsistency in the initialization of other builtin drivers.

I have to admit I never played with async probing...

> To give an example, with pure sequential driver initialization, based
> on 5 dmesg logs, the builtin kernel initialization deviation is
> around +/- 5ms, whereas after enabling async probing in e.g. vsp1
> driver, the variance is increased to sometimes +/- 80ms or more.

... so I can't tell if there is something which can be fixed on the
async probe side. I would naively think so.

> This patch fixes it and keeps the startup time consistent after
> switching certain i2c-dependent drivers to asynchronous probing on
> H3-es20-Salvator-X target.

I am not convinced "fix" is the right word here. Why is it not just a
workaround? Are there no other possibilities? I know other solutions are
usually complicated, but playing with init levels is fragile and caused
circular dependencies in the past, so I really don't like them.

> Another effect seems to be improving the init time of rcar_i2c_driver
> itself from ~7ms to ~1ms (assuming CONFIG_I2C_RCAR=y).

That doesn't help the patch much ;), but still interesting because I didn't
expect that. Do you have an idea why?

Regards,

   Wolfram

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux