Sorry for the broken format in the last mail. Seems like thunderbird
broke my setup after upgrading to v60...
Am 30.11.2018 um 16:30 schrieb Philipp Tomsich:
Tom,
On 30.11.2018, at 15:13, Philipp Tomsich
<philipp.toms...@theobroma-systems.com
<mailto:philipp.toms...@theobroma-systems.com>> wrote:
Simon,
On 30.11.2018, at 14:55, Simon Goldschmidt
<simon.k.r.goldschm...@gmail.com
<mailto:simon.k.r.goldschm...@gmail.com>> wrote:
[cut down CC list as gmail won't let me send to that many people :-( ]
Sometimes I wonder if patman will at some point get a feature to
avoid those
endless CC lists for changes like this one.
Am 30.11.2018 um 12:39 schrieb Philipp Tomsich:
A number of MMC drivers uses BOUNCE_BUFFER for their DMA buffers.
This moves it into Kconfig and performs a step-by-step migration for
the affected boards/drivers.
In doing so, it turns out that a few boards/configs enabled
CONFIG_BOUNCE_BUFFER in their config headers without an apparent need.
The migration (using moveconfig) for those boards is kept in a
separate patch, so it can be more easily reviewed by the affected
parties to make a determination whether it is actually needed.
Given that BOUNCE_BUFFER only controls whether the bounce_buffer_*
functions are build and linked, this configuration option could be
entirely removed and the utility functions built unconditionally. For
platforms that don't make use of these functions, the linker will then
remove the unused symbols.
I'll leave the final decision if this would be a better implementation
(or if this should be done in a two-stage process) to someone else...
END.
I think this is a good idea, but I get build errors after applying
patch 2/6 since CONFIG_BOUNCE_BUFFER is now enabled via Kconfig and
defined as 1 while at the same time it is just defined (but to
nothing) in socfpga_common.h.
This is a problem of having multiple individual patches for a
moveconfig-style
change. You need the final patch (6/6) in addition to (1/6) for socfpga.
Can you change or reorder this series so that every commit compiles?
There’s a couple options (none of they appeal to me):
1.I lump everything together into one big change.
2.I have a complete moveconfig (i.e. polluting all defconfig files)
in the
first patch and the individual changes to the MMC drivers then remove
the defconfig entries for their platforms.
3.We skip this part of the conversion and directly skip forward to having
bounce-buffer always included and leave the cleanup to the linker…
I’m happy to change this to any of the 3 options (although I’ll
probably need
a shower afterwards to feel less dirty, if we go with option #1 …)
I now tried option #2, but that leads to the final patch being
subsumed into the
first one (i.e. the maintainers of socfpga and the bcm* ports don’t
get a chance
to say “we confirm that this is not needed, just drop patch 6/6”).
So this boils down to whether Tom is ok with this being a series that
has failures
if not fully applied (i.e. patch 1/1 leaving loose ends that the
follow-on patches
address on a per-MMC-controller and per-platform basis)…
…or if we skip the conversion and trust the linker to do the right thing.
Ok, in that case, I'll leave it up to Tom or others to decide.
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
