Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism

2011-10-06 Thread G, Manjunath Kondaiah 
On Tue, Oct 04, 2011 at 05:35:04PM -0600, Grant Likely wrote:
 On Wed, Oct 05, 2011 at 12:05:16AM +0530, G, Manjunath Kondaiah wrote:
  On Tue, Oct 04, 2011 at 09:58:10AM -0600, Grant Likely wrote:
   On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah manj...@ti.com 
   wrote:
On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
Hi Manjunath,
   
Here's the current state of the patch.  The major think that needs to
be done is to convert it to use a separate workqueue as described in
the TODO above.  It also needs some users adapted to it.  One of the
gpio drivers would work; preferably one of the newer drivers that
doesn't have a lot of drivers depending on the early_initcall()
behaviour yet.
   
I have tested this patch on omap3 beagle board by making:
1. omap-gpio driver init as late_initcall instead of postcore_initcall
2. mmc driver probe will request gpio through gpio_request and gpio 
driver
returns -EDEFER_PROBE which in turn makes mmc driver to request 
deferral probe.
3. When deferral probe gets activated, it scans driver entries and it 
will not
find any match for mmc driver probe.
   
   Looks like drivers/mmc/host/omap.c is using platform_driver_probe()
   instead of platform_driver_register().  Add the probe hook to the
   platform_driver structure and change it to call
   platform_driver_register() and it should work.  Don't forget to change
   mmc_omap_probe from __init to __devinit.
  
  Yes. After changing it into platform_driver_register, I can see mmc probe is
  getting completed from deferred probe list. But, MMC upper layer will check 
  probe and it waits for ever since probe_count is not getting incremented.
  
  Log:
  
  [1.807830] platform omap_hsmmc.0: Driver omap_hsmmc requests probe 
  deferral
  
  ...
  
  [1.948760] omap_device: omap_gpio.0: new worst case activate latency 
  0:30517
  [1.959259] OMAP GPIO hardware version 2.5
  
  ...
  
  [2.000488] platform omap_hsmmc.0: Retrying from deferred list
  [2.008026] omap_device: omap_hsmmc.0: new worst case activate latency 
  0:244140
  [2.020080] input: gpio-keys as /devices/platform/gpio-keys/input/input1
  [2.035827] omap_hsmmc omap_hsmmc.0: Probe success...
  [2.042083] twl_rtc twl_rtc: setting system clock to 2000-01-01 01:06:35 
  UTC
  (946688795)
  [2.056030] Waiting for root device /dev/mmcblk0p2...
  [2.061492] driver_probe_done: probe_count = 0
  [2.168518] driver_probe_done: probe_count = 0
  [2.277832] driver_probe_done: probe_count = 0
  [2.387207] driver_probe_done: probe_count = 0
  [2.496582] driver_probe_done: probe_count = 0
  
  Waits for ever in init/do_mount.c:
  if ((ROOT_DEV == 0)  root_wait) {
  printk(KERN_INFO Waiting for root device %s...\n,
  saved_root_name);
  while (driver_probe_done() != 0 ||
  (ROOT_DEV = name_to_dev_t(saved_root_name)) == 0)
  msleep(100);
  async_synchronize_full();
  }
 
 Okay, it looks like the driver deferral workqueue needs to get kicked
 off before the kernel starts waiting for the root filesystem.  Check
 the initcall level that is being used by do_mount, and make sure the
 deferred probe starts before that...
 
 Hmmm wait, that doesn't make sense because the probe is still
 successful.  What triggers the exit conditions in that while loop?
 How would it be different from when the driver can probe successfully
 without deferral?

Looks like OMAP MMC uses TWL GPIO for card detect. I manually changed this 
twl gpio to omap gpio for testing purpose which is causing this problem. 
I have not tried to root cause further, I reverted back to twl gpio and 
requested
omap gpio in mmc driver probe. With omap gpio request and making gpio driver
init as lateinit, deferral probe works fine for MMC driver.

I will post updated patch series.

-Manjunath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism

2011-10-04 Thread G, Manjunath Kondaiah 
Hi Grant,

On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
 Allow drivers to report at probe time that they cannot get all the resources
 required by the device, and should be retried at a later time.
 
 This should completely solve the problem of getting devices
 initialized in the right order.  Right now this is mostly handled by
 mucking about with initcall ordering which is a complete hack, and
 doesn't even remotely handle the case where device drivers are in
 modules.  This approach completely sidesteps the issues by allowing
 driver registration to occur in any order, and any driver can request
 to be retried after a few more other drivers get probed.
 
 v3: - Hold off workqueue scheduling until late_initcall so that the bulk
   of driver probes are complete before we start retrying deferred devices.
 - Tested with simple use cases.  Still needs more testing though.
   Using it to get rid of the gpio early_initcall madness, or to replace
   the ASoC internal probe deferral code would be ideal.
 v2: - added locking so it should no longer be utterly broken in that regard
 - remove device from deferred list at device_del time.
 - Still completely untested with any real use case, but has been
   boot tested.
 
 TODO: - Create a separate singlethread_workqueue so that drivers can't
 mess things up by calling flush_work().
   - Maybe this should be wrapped with a kconfig symbol so it can
 be compiled out on systems that don't care.
 
 Signed-off-by: Grant Likely grant.lik...@secretlab.ca
 Cc: Greg Kroah-Hartman g...@kroah.com
 Cc: Mark Brown broo...@opensource.wolfsonmicro.com
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Dilan Lee di...@nvidia.com
 Cc: Manjunath GKondaiah manjunath.gkonda...@linaro.org
 ---
 
 Hi Manjunath,
 
 Here's the current state of the patch.  The major think that needs to
 be done is to convert it to use a separate workqueue as described in
 the TODO above.  It also needs some users adapted to it.  One of the
 gpio drivers would work; preferably one of the newer drivers that
 doesn't have a lot of drivers depending on the early_initcall()
 behaviour yet.

I have tested this patch on omap3 beagle board by making:
1. omap-gpio driver init as late_initcall instead of postcore_initcall
2. mmc driver probe will request gpio through gpio_request and gpio driver
returns -EDEFER_PROBE which in turn makes mmc driver to request deferral probe.
3. When deferral probe gets activated, it scans driver entries and it will not 
find any match for mmc driver probe.

After step 3, mmc driver probe will not get called due to device and driver
mismatch during bus_for_each_drv execution.

The behaviour is no different when it is used with singlethread_workqueue.

Here is bootlog:
Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Reading boot sector
Loading u-boot.bin from mmc


U-Boot 2009.11 (Feb 23 2010 - 15:33:48)

OMAP3530-GP ES3.0, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  128 MB
NAND:  256 MiB
In:serial
Out:   serial
Err:   serial
Board revision Ax/Bx
Die ID #5ac4000304013f8901001001
Hit any key to stop autoboot:  0 
mmc0 is available
mmc - MMC sub-system

Usage:
mmc init [dev] - init MMC sub system
mmc device [dev] - show or set current device
reading uImage

3237432 bytes read
## Booting kernel from Legacy Image at 8000 ...
  Image Name:   Linux-3.1.0-rc8-1-g4dc9843-d
  Image Type:   ARM Linux Kernel Image (uncompressed)
  Data Size:3237368 Bytes =  3.1 MB
  Load Address: 80008000
  Entry Point:  80008000
  Verifying Checksum ... OK
  Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[0.00] Linux version 3.1.0-rc8-1-g4dc9843-dirty 
(manju@manju-desktop) (gcc version 4.5.2 (Ubuntu/Linaro4.5.2-8ubuntu3) ) #7 SMP 
Tue Oct 4 19:19:49 IST 2011
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f
[0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction 
cache
[0.00] Machine: OMAP3 Beagle Board
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] OMAP3430/3530 ES3.0 (l2cache iva sgx neon isp)

...

[3.554656] driver_probe_device: drv-name: omap_hsmmc
[3.560241] omap_hsmmc_probe: ...Enter *
[3.566955] omap_hsmmc_gpio_init: . enter .
[3.572906] platform omap_hsmmc.0: Driver omap_hsmmc requests probe deferral

...

[3.712097] driver_probe_device: drv-name: omap_gpio
[3.717681] omap_device: omap_gpio.0: new worst case activate latency 0: 
30517
[3.727813] OMAP GPIO hardware version 2.5
[3.732421] driver_probe_device: drv-name: omap_gpio
[3.739776] driver_probe_device: drv-name: omap_gpio
[3.747039] driver_probe_device: drv-name: omap_gpio
[3.754241] driver_probe_device: drv-name: omap_gpio
[3.761413] driver_probe_device: drv-name:

Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism

2011-10-04 Thread Grant Likely 
On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah manj...@ti.com wrote:
 On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
 Hi Manjunath,

 Here's the current state of the patch.  The major think that needs to
 be done is to convert it to use a separate workqueue as described in
 the TODO above.  It also needs some users adapted to it.  One of the
 gpio drivers would work; preferably one of the newer drivers that
 doesn't have a lot of drivers depending on the early_initcall()
 behaviour yet.

 I have tested this patch on omap3 beagle board by making:
 1. omap-gpio driver init as late_initcall instead of postcore_initcall
 2. mmc driver probe will request gpio through gpio_request and gpio driver
 returns -EDEFER_PROBE which in turn makes mmc driver to request deferral 
 probe.
 3. When deferral probe gets activated, it scans driver entries and it will not
 find any match for mmc driver probe.

Looks like drivers/mmc/host/omap.c is using platform_driver_probe()
instead of platform_driver_register().  Add the probe hook to the
platform_driver structure and change it to call
platform_driver_register() and it should work.  Don't forget to change
mmc_omap_probe from __init to __devinit.

g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism

2011-10-04 Thread G, Manjunath Kondaiah 
On Tue, Oct 04, 2011 at 09:58:10AM -0600, Grant Likely wrote:
 On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah manj...@ti.com wrote:
  On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
  Hi Manjunath,
 
  Here's the current state of the patch.  The major think that needs to
  be done is to convert it to use a separate workqueue as described in
  the TODO above.  It also needs some users adapted to it.  One of the
  gpio drivers would work; preferably one of the newer drivers that
  doesn't have a lot of drivers depending on the early_initcall()
  behaviour yet.
 
  I have tested this patch on omap3 beagle board by making:
  1. omap-gpio driver init as late_initcall instead of postcore_initcall
  2. mmc driver probe will request gpio through gpio_request and gpio driver
  returns -EDEFER_PROBE which in turn makes mmc driver to request deferral 
  probe.
  3. When deferral probe gets activated, it scans driver entries and it will 
  not
  find any match for mmc driver probe.
 
 Looks like drivers/mmc/host/omap.c is using platform_driver_probe()
 instead of platform_driver_register().  Add the probe hook to the
 platform_driver structure and change it to call
 platform_driver_register() and it should work.  Don't forget to change
 mmc_omap_probe from __init to __devinit.

Yes. After changing it into platform_driver_register, I can see mmc probe is
getting completed from deferred probe list. But, MMC upper layer will check 
probe and it waits for ever since probe_count is not getting incremented.

Log:

[1.807830] platform omap_hsmmc.0: Driver omap_hsmmc requests probe deferral

...

[1.948760] omap_device: omap_gpio.0: new worst case activate latency 0:30517
[1.959259] OMAP GPIO hardware version 2.5

...

[2.000488] platform omap_hsmmc.0: Retrying from deferred list
[2.008026] omap_device: omap_hsmmc.0: new worst case activate latency 
0:244140
[2.020080] input: gpio-keys as /devices/platform/gpio-keys/input/input1
[2.035827] omap_hsmmc omap_hsmmc.0: Probe success...
[2.042083] twl_rtc twl_rtc: setting system clock to 2000-01-01 01:06:35 UTC
(946688795)
[2.056030] Waiting for root device /dev/mmcblk0p2...
[2.061492] driver_probe_done: probe_count = 0
[2.168518] driver_probe_done: probe_count = 0
[2.277832] driver_probe_done: probe_count = 0
[2.387207] driver_probe_done: probe_count = 0
[2.496582] driver_probe_done: probe_count = 0

Waits for ever in init/do_mount.c:
if ((ROOT_DEV == 0)  root_wait) {
printk(KERN_INFO Waiting for root device %s...\n,
saved_root_name);
while (driver_probe_done() != 0 ||
(ROOT_DEV = name_to_dev_t(saved_root_name)) == 0)
msleep(100);
async_synchronize_full();
}

-Manjunath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism

2011-10-04 Thread Grant Likely 
On Wed, Oct 05, 2011 at 12:05:16AM +0530, G, Manjunath Kondaiah wrote:
 On Tue, Oct 04, 2011 at 09:58:10AM -0600, Grant Likely wrote:
  On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah manj...@ti.com 
  wrote:
   On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
   Hi Manjunath,
  
   Here's the current state of the patch.  The major think that needs to
   be done is to convert it to use a separate workqueue as described in
   the TODO above.  It also needs some users adapted to it.  One of the
   gpio drivers would work; preferably one of the newer drivers that
   doesn't have a lot of drivers depending on the early_initcall()
   behaviour yet.
  
   I have tested this patch on omap3 beagle board by making:
   1. omap-gpio driver init as late_initcall instead of postcore_initcall
   2. mmc driver probe will request gpio through gpio_request and gpio driver
   returns -EDEFER_PROBE which in turn makes mmc driver to request deferral 
   probe.
   3. When deferral probe gets activated, it scans driver entries and it 
   will not
   find any match for mmc driver probe.
  
  Looks like drivers/mmc/host/omap.c is using platform_driver_probe()
  instead of platform_driver_register().  Add the probe hook to the
  platform_driver structure and change it to call
  platform_driver_register() and it should work.  Don't forget to change
  mmc_omap_probe from __init to __devinit.
 
 Yes. After changing it into platform_driver_register, I can see mmc probe is
 getting completed from deferred probe list. But, MMC upper layer will check 
 probe and it waits for ever since probe_count is not getting incremented.
 
 Log:
 
 [1.807830] platform omap_hsmmc.0: Driver omap_hsmmc requests probe 
 deferral
 
 ...
 
 [1.948760] omap_device: omap_gpio.0: new worst case activate latency 
 0:30517
 [1.959259] OMAP GPIO hardware version 2.5
 
 ...
 
 [2.000488] platform omap_hsmmc.0: Retrying from deferred list
 [2.008026] omap_device: omap_hsmmc.0: new worst case activate latency 
 0:244140
 [2.020080] input: gpio-keys as /devices/platform/gpio-keys/input/input1
 [2.035827] omap_hsmmc omap_hsmmc.0: Probe success...
 [2.042083] twl_rtc twl_rtc: setting system clock to 2000-01-01 01:06:35 
 UTC
 (946688795)
 [2.056030] Waiting for root device /dev/mmcblk0p2...
 [2.061492] driver_probe_done: probe_count = 0
 [2.168518] driver_probe_done: probe_count = 0
 [2.277832] driver_probe_done: probe_count = 0
 [2.387207] driver_probe_done: probe_count = 0
 [2.496582] driver_probe_done: probe_count = 0
 
 Waits for ever in init/do_mount.c:
   if ((ROOT_DEV == 0)  root_wait) {
   printk(KERN_INFO Waiting for root device %s...\n,
   saved_root_name);
   while (driver_probe_done() != 0 ||
   (ROOT_DEV = name_to_dev_t(saved_root_name)) == 0)
   msleep(100);
   async_synchronize_full();
   }

Okay, it looks like the driver deferral workqueue needs to get kicked
off before the kernel starts waiting for the root filesystem.  Check
the initcall level that is being used by do_mount, and make sure the
deferred probe starts before that...

Hmmm wait, that doesn't make sense because the probe is still
successful.  What triggers the exit conditions in that while loop?
How would it be different from when the driver can probe successfully
without deferral?

g.

 
 -Manjunath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html