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.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
