Hi Stefan,
On Wed, 25 Jan 2023 at 00:53, Stefan Herbrechtsmeier
<stefan.herbrechtsmeier-...@weidmueller.com> wrote:
>
> Hi Simon,
>
> Am 24.01.2023 um 23:44 schrieb Simon Glass:
> > Hi Stefan,
> >
> > On Tue, 24 Jan 2023 at 05:14, Stefan Herbrechtsmeier
> > <stefan.herbrechtsmeier-...@weidmueller.com> wrote:
> >> Hi Simon,
> >>
> >> Am 24.01.2023 um 11:55 schrieb Simon Glass:
> >>> Hi Stefan,
> >>>
> >>> On Tue, 24 Jan 2023 at 01:12, Stefan Herbrechtsmeier
> >>> <stefan.herbrechtsmeier-...@weidmueller.com> wrote:
> >>>> Hi Simon,
> >>>>
> >>>> Am 22.12.2022 um 00:08 schrieb Simon Glass:
> >>>>> The attribute syntax is quite verbose. Use the macro provided for this
> >>>>> purpose.
> >>>>>
> >>>>> Signed-off-by: Simon Glass <s...@chromium.org>
> >>>>> ---
> >>>>>
> >>>>> arch/arm/cpu/armv7/s5p-common/timer.c | 2 +-
> >>>>> arch/arm/mach-exynos/include/mach/cpu.h | 6 +++---
> >>>>> arch/x86/include/asm/global_data.h | 2 +-
> >>>>> arch/x86/include/asm/msr.h | 2 +-
> >>>>> arch/x86/include/asm/u-boot-x86.h | 2 +-
> >>>>> common/spl/spl_fit.c | 1 +
> >>>>> doc/develop/trace.rst | 2 +-
> >>>>> lib/efi_loader/efi_freestanding.c | 4 ++--
> >>>>> lib/trace.c | 26
> >>>>> +++++++++++--------------
> >>>>> 9 files changed, 22 insertions(+), 25 deletions(-)
> >>>>>
> >>>> [snip]
> >>>>
> >>>>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> >>>>> index 08da7fed88e..0e026bb3d8e 100644
> >>>>> --- a/common/spl/spl_fit.c
> >>>>> +++ b/common/spl/spl_fit.c
> >>>>> @@ -599,6 +599,7 @@ static int spl_fit_upload_fpga(struct spl_fit_info
> >>>>> *ctx, int node,
> >>>>> debug("Ignoring compatible = %s property\n",
> >>>>> compatible);
> >>>>> }
> >>>>> + return 0;
> >>>>>
> >>>>> ret = fpga_load(devnum, (void *)fpga_image->load_addr,
> >>>>> fpga_image->size, BIT_FULL, flags);
> >>>> This return makes the spl_fit_upload_fpga function useless. I assume
> >>>> this change was by accident.
> >>> Yes that was a mistake. I'll send a patch.
> >> Thanks.
> >>
> >>> Do you think it would be possible to create a sandbox driver for the
> >>> FPGA uclass? Then we could add some tests for this code.
> >> A sandbox driver exists but the uclass is only an empty dummy.
> >>
> >> The fpga subsystem use its own structs to describe the hardware and the
> >> fpga_load function for example is a wrapper for xilinx_load, altera_load
> >> and lattice_load.
> > Yes, I think fpga_load should become a uclass operation. See how this
> > is done for other uclasses.
>
> The problem is that the fpga subsystem doesn't use uclass at the moment.
> The fpga is init and added by the cpu code (see
> arch/arm/mach-zynq/cpu.c). The subsystem functions use the devnum
> (index) to select the added structure.
>
> Is it possible to add a ulcass device from cpu code as a first step to
> convert the functions into uclass functions.
OK that sounds good, thanks. It should be specified in the DT.
Regards,
Simon
