Hi Simon,
From: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Sent: lundi 4 mars 2019 11:51
On Mon, Mar 4, 2019 at 11:44 AM Patrick DELAUNAY patrick.delaunay@st.com wrote:
Hi Simon,
From: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com Sent: mercredi 27 février 2019 15:50
[reducing the CC list as gmail won't let me send otherwise]
On 27.02.2019 15:20, Patrick Delaunay wrote:
This converts the following to Kconfig: CONFIG_SF_DEFAULT_BUS CONFIG_SF_DEFAULT_CS CONFIG_SF_DEFAULT_MODE CONFIG_SF_DEFAULT_SPEED
I use moveconfig script and then manual check on generated u-boot.cfg to solve the remaining issue.
Signed-off-by: Patrick Delaunay patrick.delaunay@st.com
I admit I haven't followed the patches regarding these defines completely, but isn't moving these to Kconfig the opposite of what we want?
Yes it was my first plan in the series:
http://patchwork.ozlabs.org/project/uboot/list/?series=76834&state=* http://patchwork.ozlabs.org/project/uboot/list/?series=80769&state=*
But it is not possible too many dependency with board using platdata for SPI
initialization and regression after my v3.
Oh, ok. That's sad. But I wouldn't have time to work on this, either...
I always thought the goal would be to move U-Boot to DM and devicetree completely sooner or later (where these defines aren't used). Adding them to Kconfig does not make them optional but makes them *always* present (but probably with default values if not used).
Migration to Kconfig was requested by Jagan in http://patchwork.ozlabs.org/patch/1031768/
The define need to be always define, as they are used in cmd/sf.c They could dependent on CONFIG_CMD_SF when they are no more used is other
part of code (for other purpose).
Well, defaults for that command are not necessarily defaults for use at driver level?
Yes, but today it is the case for some fallback when DT information is not available (dfu_sf / spl_spi). And I don't know solve this issue.
This serie is only a step, I hope in the good direction.
./board/Arcturus/ucp1020/cmd_arc.c ./board/aristainetos/aristainetos-v1.c ./board/aristainetos/aristainetos-v2.c ./board/davinci/da8xxevm/da850evm.c ./board/davinci/da8xxevm/omapl138_lcdk.c ./board/el/el6x/el6x.c ./board/siemens/taurus/taurus.c ./board/Synology/ds414/cmd_syno.c ./board/tqc/tqma6/tqma6.c ./cmd/mvebu/bubt.c ./common/splash_source.c ./common/spl/spl_spi.c ./drivers/dfu/dfu_sf.c
And yes, 0 is the "default" value, so defines are present in .config.
Why it is disturbing if these defines are requested by command sf ?
Because I would have thought with DM, defaults would come from dts, not from some defines.
Anyway, I guess I now understand why you have done it like that. I'm not the SPI maintainer, so I won't interfere. I was only a little bit surprised that this took a different direction as the first things we discussed in that area...
In fact, I am also waiting feedback to be sure that is the good direction.
And as long as this define doesn't interfere with my SPL + U-Boot using the settings from dts, this looks good, I guess.
Yes, no interference: they are used only when DT is not available (tested on my board stm32mp1 ev1 which use only device tree, and it is OK).
Regards, Simon
Regards, Simon
Jagan: can you tell me what is the right direction.for you...
Regards
Patrick
Patrick