Re: [RFT 0/3] cxgb4: use request_firmware_nowait()

[Casey Leedom]

On 06/24/14 08:55, Casey Leedom wrote:
> On 06/23/14 17:29, Luis R. Rodriguez wrote:
> > On Mon, Jun 23, 2014 at 12:06:48PM -0700, Casey Leedom wrote:
> >
> > > Also, it might be useful if there was a way for the driver
> > > module to "tell" the timeout mechanism that forward progress _is_ being
> > > made so it doesn't blow away the driver module load.
> > Indeed if this is actually needed, but believe the issue here for the
> > huge delays might be instead the lack of not using 
> > request_firmware_direct()
> > and actual device initialization time, which I do not believe we 
> > penalize,
> > we should be penalizing only the amount of time it takes either the
> > kernel or udev to read the firmware from the filesystem.
>
>   If you want I can time the actual phases of loading new firmware: 
> request_firmware(), writing it to FLASH, release_firmware() ...

  So I just did this for a normal modprobe (after the system is up):

Jiffies    Process
-----------------------------------------------------------------------
      0    begin firmware load process
      3    request_firmware() returns
      7    start looking at the adapter
     10    finish reading the first sector of existing adapter firmware
     26    we've decided that we're going to upgrade the firmware
     28    actual firmware upgrade process starts
    448    we've finished halting the adapter processor
    451    we enter the firmware write routine
  8,470    we've finished erasing the firmware FLASH sectors
 14,336    write of new firmware is complete
 14,340    the new firmware load is complete
 14,949    the adapter processor has been restarted; new firmware running
 14,952    firmware upgrade process complete

Maybe request_firmware() takes more time during the boot phase but as we 
can see from the above timings, it's the actual firmware upgrade process 
which takes the most time ...

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