[U-Boot] [PATCH v1 1/2] cmd_sf: Add command "sf info" to show current device info

Wang Haikun Haikun.Wang at freescale.com
Mon Jul 20 07:55:19 CEST 2015


On 5/11/2015 10:59 AM, Simon Glass wrote:
> Hi,
>
> On 10 May 2015 at 07:04, Jagan Teki <jteki at openedev.com> wrote:
>> On 8 May 2015 at 13:51, Haikun.Wang at freescale.com
>> <Haikun.Wang at freescale.com> wrote:
>>> On 5/8/2015 1:53 PM, Jagan Teki wrote:
>>>> On 8 May 2015 at 08:14, Haikun.Wang at freescale.com
>>>> <Haikun.Wang at freescale.com> wrote:
>>>>> On 5/7/2015 7:44 PM, Jagan Teki wrote:
>>>>>> On 6 May 2015 at 02:30, Simon Glass <sjg at chromium.org> wrote:
>>>>>>> On 5 May 2015 at 05:37, Haikun.Wang at freescale.com
>>>>>>> <Haikun.Wang at freescale.com> wrote:
>>>>>>>> On 5/1/2015 9:54 AM, Simon Glass wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 29 April 2015 at 04:40, Haikun Wang <haikun.wang at freescale.com> wrote:
>>>>>>>>>> Add command "sf info" to show the information of the current SPI flash device.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Haikun Wang <haikun.wang at 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.



More information about the U-Boot mailing list