[U-Boot] [PATCH v2 00/12] spi: sf: ICH SPI driver fix and flash params update

[Bin Meng]

Hi Jagan,

On Wed, Nov 5, 2014 at 5:21 AM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
> On 1 November 2014 14:23, Bin Meng <bmeng.cn at gmail.com> wrote:
>> This series fix several bugs in current ICH SPI driver as well as
>> adding byte program support for the SST25* flash.
>>
>> Flash params are updated to explicitly list supported read commands
>> and change flash sector size to 4KiB as long as flash supports
>> sector erase (20h) command.
>>
>> Changes for v2:
>>   - Rebased to u-boot-spi/mater.
>>   - Reviewed and updated the params of all currently supported flash
>>     parts per their datasheets.
>>   - Corrected AT25DF321 JEDEC ID.
>>   - Corrected Atmel bulk erase command to 50h instead of D8h.
>>   - Added AT25DF321A, W25X10, W25X20, W25X80 params.
>>
>>
>> Bin Meng (12):
>>   spi/ich.c: Fix a bug of reading from a non-64 bytes aligned address
>>   spi/ich.c: Set the rx operation mode for ich 7
>>   spi: sf: Support byte program for sst spi flash
>>   sf: Update SST flash params
>>   sf: Update Atmel flash params
>>   sf: Update EON flash params
>>   sf: Update GigaDevice flash params
>>   sf: Update Macronix flash params
>>   sf: Update Spansion flash params
>>   sf: Update Micron flash params
>>   sf: Update Winbond flash params
>>   sf: Give proper spacing between flash table params
>
> I think you combined two or more changes(unrelated) in a common patches and
> Added Bulk erase support in e_cmd_rd of sf_params ie quite not correct.

Do you mean I should let PATCH 1/2/3 go as a separate patch set? Since
these 3 are tested on my x86 board, could it be Simon to pick up these
patches instead of through the u-boot-spi? Also I don't understand you
comments about "adding bulk erase support in e_cmd_rd is not correct".
The e_cmd_rd in sf_params is updated to specify all supported read
commands the flash can support. There is no bulk erase here.

> Please fix those and send me one more.
>
> Mean while I will look at your scenario like you're controller only supports AS,
> As I said before as AS of AF both are similar way of transferring
> except the dummy
> bits passing from the driver, try to see the fix on driver point of of
> instead of digging
> common sf stuff.

Fixing on the driver part might be possible, might be not. Even though
it is possible, I don't want to do that as the ICH manual explicitly
says fast read command (0Bh) is not supported by the controller. As
far as I can test, actually all of the commands which require an
additional dummy byte after the address cycle fail to work. The
matches what the manual says.

Regards,
Bin