No subject

river!
There you know details of manufacturer, supported opcodes and so on.
And there you can decide, if you switch a flash to a "full quad" mode,
that the same opcode now needs to be send on 4 lines!
In the controller driver you don't know these details!

>=20
> spi_flash layer should send any commands based on the respective
> supported, but it is supported by respective spi controller that should
> controller driver must aware.
>=20
> This is more generic solution as we discussed so-many months ago.
> http://u-boot.10912.n7.nabble.com/PATCH-00-12-cmd-sf-Add-support-for-
> read-and-write-instructions-td143749.html

Yes, I agree that this a huge step forward!
But I think, we still have not reached a state which everyone can accept.

>=20
> We tried to discover the supported commands runtime from respective
> flashes, but ie. going to be a huge
> code to decode all these. Instead filling params, like sectors and
> idcodes should be an code driven task as per as
> u-boot code is concern.

As I already said, this is very specific to your controller!

>=20
>> By decoding the cmd itself again? But the data should be a transparent b=
yte
>> stream to the controller!
>> Otherwise you need a table of commands for decoding also inside the
>> controller
>> driver, which I consider a bad idea, as you need to update them (in each
>> driver)
>> for new cmds added to the serial-flash driver!
>>=20
>> In the linux kernel, the solution in the spi layer was to add new
>> elements to
>> the transfer structure (struct spi_transfer -> bitwidth), which can be s=
et
>> for each part of a message.
>> In u-boot we have the spi_xfer function, which has a "flags" parameter
>> we could
>> use for this.
>>=20
>> As long as the details for this (including a spi controller driver,
>> which can handle dual/quad-io transfers) are not fixed, I would suggest
>> to leave the patches regarding the extended cmds out of the series of
>> sf-cleanup (which really looks good!) and fix the issues until the next
>> merge window!
>=20
> I am planning to push this series, as we started this since long months b=
ack.
> We discussed many threads, and tested this approach on read hw as well.
>=20
> Please let me know for any thoughts.

I already said: Please leave some room for more discussions on the extended=
 / quad read topic!
And don't let the rest of the improvements be delayed by this!

>=20
>>=20
>>> Testing repo branch:
>>> -------------------
>>> $ git clone git://git.denx.de/u-boot-spi.git
>>> $ cd u-boot-spi
>>> $ git checkout -b master-next-test origin/master-next-test
>>>=20
>>> REQUEST FOR ALL SPI CODE CONTRIBUTORS/USERS, PLEASE TEST THESE CHANGES
>>> W.R.T YOUR HW IF POSSIBLE.
>>>=20
>>> Please let me know for any issues/concerns/questions.
>>>=20
>>> --
>>> Thanks,
>>> Jagan.
>> Best Regards,
>> Thomas
>>=20
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>

Best Regards,
Thomas