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