26 Mar, 2020

1 commit

  • With upcoming changes in elf loader for elf64 support, section size will
    be a u64. When used with da_to_va, this will potentially lead to
    overflow if using the current "int" type for len argument. Change
    da_to_va prototype to use a size_t for len and fix all users of this
    function.

    Reviewed-by: Bjorn Andersson
    Reviewed-by: Mathieu Poirier
    Signed-off-by: Clement Leger
    Link: https://lore.kernel.org/r/20200302093902.27849-2-cleger@kalray.eu
    Signed-off-by: Bjorn Andersson

    Clement Leger
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation this program is
    distributed in the hope that it will be useful but without any
    warranty without even the implied warranty of merchantability or
    fitness for a particular purpose see the gnu general public license
    for more details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 655 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Kate Stewart
    Reviewed-by: Richard Fontana
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

19 Jan, 2017

1 commit

  • Declare rproc_ops structures as const as they are only passed as an
    argument to the function rproc_alloc. This argument is of type const, so
    rproc_ops structures having this property can be declared const too.
    Done using Coccinelle:

    @r1 disable optional_qualifier @
    identifier i;
    position p;
    @@
    static struct rproc_ops i@p = {...};

    @ok1@
    identifier r1.i;
    position p;
    @@
    rproc_alloc(...,&i@p,...)

    @bad@
    position p!={r1.p,ok1.p};
    identifier r1.i;
    @@
    i@p

    @depends on !bad disable optional_qualifier@
    identifier r1.i;
    @@
    +const
    struct rproc_ops i;

    File size details:

    Size of the file remoteproc/da8xx_remoteproc.o remains the same before and
    after applying the changes.

    text data bss dec hex filename
    1312 100 4 1416 588 remoteproc/da8xx_remoteproc.o
    1312 100 4 1416 588 remoteproc/da8xx_remoteproc.o

    970 240 0 1210 4ba remoteproc/omap_remoteproc.o
    1002 192 0 1194 4aa remoteproc/omap_remoteproc.o

    1901 240 0 2141 85d remoteproc/st_remoteproc.o
    1933 192 0 2125 84d remoteproc/st_remoteproc.o

    1288 96 0 1384 568 remoteproc/st_slim_rproc.o
    1320 64 0 1384 568 remoteproc/st_slim_rproc.o

    2121 240 0 2361 939 remoteproc/wkup_m3_rproc.o
    2161 192 0 2353 931 remoteproc/wkup_m3_rproc.o

    Signed-off-by: Bhumika Goyal
    Signed-off-by: Bjorn Andersson

    Bhumika Goyal
     

03 Oct, 2016

1 commit


18 Aug, 2016

1 commit

  • Introduce an "auto-boot" flag on rprocs to make it possible to flag
    remote processors without vdevs to automatically boot once the firmware
    is found.

    Preserve previous behavior of the wkup_m3 processor being explicitly
    booted by a consumer.

    Cc: Lee Jones
    Cc: Loic Pallardy
    Cc: Suman Anna
    Signed-off-by: Bjorn Andersson

    Bjorn Andersson
     

30 Jan, 2016

1 commit


17 Jun, 2015

1 commit

  • Add a remoteproc driver to load the firmware and boot a small
    Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This
    Wakeup M3 remote processor is an integrated Cortex M3 that allows
    the SoC to enter the lowest possible power state by taking control
    from the MPU after it has gone into its own low power state and
    shutting off any additional peripherals.

    The Wakeup M3 processor has two internal memory regions - 16 kB of
    unified instruction memory called UMEM used to store executable
    code, and 8 kB of data memory called DMEM used for all data sections.
    The Wakeup M3 processor executes its code entirely from within the
    UMEM and uses the DMEM for any data. It does not use any external
    memory or any other external resources. The device address view has
    the UMEM at address 0x0 and DMEM at address 0x80000, and these are
    computed automatically within the driver based on relative address
    calculation from the corresponding device tree IOMEM resources.
    These device addresses are used to aid the core remoteproc ELF
    loader code to properly translate and load the firmware segments
    through the .rproc_da_to_va ops.

    Signed-off-by: Dave Gerlach
    Signed-off-by: Suman Anna
    Signed-off-by: Ohad Ben-Cohen

    Dave Gerlach