On 20 July 2015 at 11:25, Wang Haikun <haikun.w...@freescale.com> wrote: > On 5/11/2015 10:59 AM, Simon Glass wrote: >> Hi, >> >> On 10 May 2015 at 07:04, Jagan Teki <jt...@openedev.com> wrote: >>> On 8 May 2015 at 13:51, haikun.w...@freescale.com >>> <haikun.w...@freescale.com> wrote: >>>> On 5/8/2015 1:53 PM, Jagan Teki wrote: >>>>> On 8 May 2015 at 08:14, haikun.w...@freescale.com >>>>> <haikun.w...@freescale.com> wrote: >>>>>> On 5/7/2015 7:44 PM, Jagan Teki wrote: >>>>>>> On 6 May 2015 at 02:30, Simon Glass <s...@chromium.org> wrote: >>>>>>>> On 5 May 2015 at 05:37, haikun.w...@freescale.com >>>>>>>> <haikun.w...@freescale.com> wrote: >>>>>>>>> On 5/1/2015 9:54 AM, Simon Glass wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 29 April 2015 at 04:40, Haikun Wang <haikun.w...@freescale.com> >>>>>>>>>> wrote: >>>>>>>>>>> Add command "sf info" to show the information of the current SPI >>>>>>>>>>> flash device. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Haikun Wang <haikun.w...@freescale.com> >>>>>>>>>>> --- >>>>>>>>>>> In current sf driver, we show the debug information during the >>>>>>>>>>> flash probe >>>>>>>>>>> period. >>>>>>>>>>> >>>>>>>>>>> In case of without DM SPI, we need to run command "sf probe" to get >>>>>>>>>>> the debug >>>>>>>>>>> information of the current SPI flash device. "sf probe" will >>>>>>>>>>> re-identify the >>>>>>>>>>> device every time and it reduce the efficiency. We can get the >>>>>>>>>>> debug information >>>>>>>>>>> without any re-identify process using "sf info". >>>>>>> >>>>>>> So for non-dm case, sf probe and sf info does same? >>>>>> For non-dm case, sf info only show the information store in the current >>>>>> struct spi_flash, sf_probe will re-probe the SPI flash and create a new >>>>>> struct spi-flash. >>>>> >>>>> How could it be, in non-dm case sf probe will detect the flash and >>>>> print the info >>>>> from drivers/mtd/spi/sf_probe.c So sf probe every-time will >>>>> re-identify the device >>>>> and print the info. >>>> I approve of what you said. >>>> We don't have divergence about the difference between "sf probe" and "sf >>>> info". >>>> I just want to emphasize that "sf probe" re-identify the device, create >>>> a new "spi_flash" and print the info, "sf info" only print the current >>>> info. >>>>> >>>>> BTW: regarding this patch, unlike any command in u-boot (for my >>>>> understanding) >>>>> sf probe has a run-time capable detection option based on bus:cs hz mode >>>>> from user. So it better to skip the re-identify the same fitlash if >>>>> the flash is identified before >>>>> in sf probe logic and try to print the info in it instead of going >>>>> another stale command just >>>>> by doing print using earlier commands settings (sf probe). >>>>> >>>> I think we get to a common view that it is unnecessary to re-identify >>>> the device if it has been identified. >>>> Divergence is that you think this should be completed through updating >>>> the sf probe logic and I think we should add the new command "sf info". >>>> "sf info" resolves the problem in a more simpler way. >>>> User will be more clearly about the functions of the sf commands if we >>>> add a new command "sf info". >>>> From the literal meaning of the command "sf probe" should identify the >>>> device and the command "sf info" show the information of current device. >>> >>> Yes, I agree that 'sf info' simply show the current device info in a >>> simpler way. >>> But, being with my previous statement it simply print the info which >>> is derived from >>> 'sf probe' So why should we go and do the same thing in 'sf probe' >>> with increasing >>> one more command which does part of same as before. >>> >>> Yes, 'sf probe' is doing unnecessary re-identify the device so may be we can >>> fix that, ie going to be a real fix other than adding new command. >>> >>> Please think in that direction, adding new command in u-boot is really a big >>> step to think in whole u-boot development point of view. >> >> We have an 'info' command for usb, mmc, scsi, etc. and they don't have >> side-effects like re-probing the device. I think it makes sense to >> support something like this for sf, at least for driver model. >> >> Also, with driver model it would be good if the sf could automatically >> probe when used, rather than needing to probe it explicitly. We could >> also support more than one active flash, and a command to switch >> between them (like mmc dev and the like). Even better if we could >> specific the device in the 'sf read/write/erase' commands. >> >> [snip] >> >> Regards, >> Simon >> > Update my email address.
Pls- send the next version by add some text on commit message. thanks! -- Jagan | openedev. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
