On 6/19/21 10:51 PM, Tom Rini wrote:
Hi,
Currently DM_USB requires OF_CONTROL to be
enabled, otherwise link errors
occur. On the other hand OF_CONTROL requires
board code to be migrated to
DT, which is not always possible or required.
Fix that by conditionally compiling OF_CONTROL
specific sections in USB
related drivers code in the same way like it is
done in the other drivers.
Also, auto select OF_LIBFDT if DM_USB is
selected but OF_CONTROL is not.
Introduce a new Kconfig option OF_NODE used to
compile of_node.c in case
OF_CONTROL is not enabled. Fix deprecation
warning condition as well.
So, what is the use case of this? Why not just enable
DM_USB and OF_CONTROL ?
OF_CONTROL requires migration to device-tree.
That's where the supported platforms are heading anyway. Or is
there some issue with switching the platform you use over to DT
?
OK, let me elaborate: It is about enabling DM_USB on N900 (Nokia
rx-51 board). For various reasons I am not going to discuss (1),
migration to DM was delayed to the point where we saw "[PATCH] arm:
Remove nokia_rx51 board" with a commit message "This board has not
been converted to CONFIG_DM_USB by the deadline. Remove it." posted.
The missing pieces were WDT (a patch is already merged in -next) and
DM_USB. The board itself does not support host mode, but USB TTY is
very useful for debugging purposes. The particular task I am after
is USB DM migration and the $subject patch allows this to be
achieved with relatively little effort (a couple of defconfig
changes), incomparable with the effort needed for migration to DT.
As we are already past the DM migration deadline I think it makes
sense to fulfil its requirements before undertaking such a big task
like migration to DT.
This sounds like a workaround though. Can you instead do the full
conversion of the board? I am sure the board removal patch can be
postponed if there is plan to convert it.
Hard to say if migration to device-tree is even possible on N900 ATM,
enabling OF_CONTROL increases the size of the produced binary with some 100k
(.dtb not included), making the size of the binary way above our budget of
~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51
suffers from ARM errata 430973 and noone can guarantee we're not going to
see SIGILL faults if we enable it. Which it seems we are forced to do even
with DM_USB migration only.
Note that yes, it should be safe to enable thumb mode, but run time
confirmation would be good.
Re workaround - I took examples of #ifdef's from the current u-boot code
(mmc, i2c, etc.) so workaround or not, it is no different to what the other
drivers are doing.
I don't really understand where this requirement to convert to DTS comes
from - will boards that are not converted be removed at some point? When is
that deadline if exists? If there is no such deadline, why shall we spend
who knows how many hours just because "you know, it sounds like a good idea
to convert to DTS"? You understand this is not a trivial task and given the
pace rx-51 patches were reviewed lately, it will easily take 2 years to do
that conversion.
To sum it up - maybe I can do a full DTS migration, but I don't see a point
in doing it ATM. The $subject patch allows rx-51 to be fully migrated to DM
and does nothing different to what already is done all over the place.
So, there are deadlines for migration to device model. The argument
being put forth by the Nokia RX51 folks is that to quote
include/dm/platdata.h (and yes, they aren't using U_BOOT_DRVINFO in this
case, but...):
/**
* NOTE: Avoid using these except in extreme circumstances, where device tree
* is not feasible (e.g. serial driver in SPL where <8KB of SRAM is
* available). U-Boot's driver model uses device tree for configuration.
*
* When of-platdata is in use, U_BOOT_DRVINFO() cannot be used outside of the
* dt-plat.c file created by dtoc
*/
that's them, and it's not an SPL case but full U-Boot and a fixed size
amount of the flash that they can use, no arguing.
As far as I understand, the RX51 has gigabytes of eMMC storage, so it
can use SPL just like any other OMAP3 board.
So we need to make
changes in subsystems they use so that they can continue to work.
So, are the changes being proposed to the generic USB code, such that
DM_USB can be enabled, and when DM_USB_GADGET gets a deadline (Note,
that's not set yet, but that's not to say never, it's just not been set,
so getting ahead of problems here would be appreciated) that can also be
enabled, OK?
I am confused by this reply. I noticed a lot of boards were removed over
time because they were not converted to DM/DT, and to get rid of all the
ifdefs, but now it seems the direction has been completely reversed and
we should start adding back all the ifdefs to cater for boards which are
not converted instead of fixing the boards ?
