linux-phytec-ti

TEMP: remoteproc/pru: use different firmware names for ethernet

The PRUSS Ethernet usecase is currently designed to have the PRUSS
ethernet driver perform the load and boot of a PRU device (in the
expected fashion), though the ethernet driver wants the flexibility
to use a specific firmware name. The remoteproc core infrastructure
provides an 'auto-boot' feature (load and boot automatically) using
a firmware name supplied to it during the remoteproc registration
time. The remoteproc core also provides a sysfs interface for
changing the firmware and starting/stopping a processor when it
is not started, but otherwise uses the pre-registered firmware name
for all regular usage.

It cannot be currently determined whether the PRUs are being used for
an Ethernet usecase or the previously supported generic usecases. A
decision is made by introducing a module parameter 'use_eth_fw' and
on the assumption that Ethernet usecases are to be supported only on
IDK boards. Even on current AM57xx IDK boards, PRUSS1 is not capable
of enabling Ethernet functionality due to board pin mux issues, so
augment the module parameter based decision making with an instance
specific functionality capabilities flag. This logic is used to
provide different firmware names during remoteproc registration
time, and set the auto-boot to false for Ethernet supported
instances.

The above assumptions and/or solution is not solid and is not scalable
in general. Long term solution would be to enhance the remoteproc core
to provide a kernel-level API for setting the firmware name and have
the PRU Ethernet driver supply the firmware name based on its usecases
(eg: Dual-EMAC or Switch). The PRU remoteproc driver would probably
need to be configured for no 'auto-boot' to meet its myriad usecases
and leave the starting andstopping of the PRUs to either kernel client
drivers or to userspace applications.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>