02 Sep, 2017

1 commit

  • In certain circumstances rpmsg devices needs to acquire a handle to the
    ancestor remoteproc instance, e.g. to invoke rproc_report_crash() when a
    fatal error is detected. Introduce an interface that walks the device
    tree in search for a remoteproc instance and return this.

    Tested-by: Suman Anna
    Signed-off-by: Bjorn Andersson

    Bjorn Andersson
     

31 Jan, 2017

2 commits

  • firmware_loading_complete is used to synchronize operations
    on rproc while asynchronous firmware loading is in progress.
    However, rproc_boot() no longer waits on
    firmware_loading_complete. Hence drop this completion
    variable altogether and handle the race between rproc_del()
    and rproc_boot() using new state RPROC_DELETED.

    The request_firmware_nowait() will hold the reference to
    rproc device by using a get_device()/put_device(), so the
    rproc struct will remain valid even when we return from
    rproc_del() before the asynchronous call to
    rproc_fw_config_virtio() completes.

    CC: Loic Pallardy
    CC: Bjorn Andersson
    Signed-off-by: Sarangdhar Joshi
    Signed-off-by: Bjorn Andersson

    Sarangdhar Joshi
     
  • Add new state RPROC_DELETED to handle synchronization
    between rproc_del() and other operations on rproc. This
    state represents the rproc device that has been "deleted".

    CC: Loic Pallardy
    CC: Bjorn Andersson
    Signed-off-by: Sarangdhar Joshi
    Signed-off-by: Bjorn Andersson

    Sarangdhar Joshi
     

30 Dec, 2016

1 commit

  • Following any fw_rsc_vdev entries in the resource table are two variable
    length arrays, the first one reference vring resources and the second
    one is the virtio config space. The virtio config space is used by
    virtio to communicate status and configuration changes and must as such
    be shared with the remote.

    The reverted commit incorrectly made any changes to the virtio config
    space only affect the local copy, in an attempt to allowing memory
    protection of the shared resource table.

    This reverts commit cda8529346935fc86f476999ac4fbfe4e17abf11.
    Signed-off-by: Bjorn Andersson

    Bjorn Andersson
     

15 Nov, 2016

3 commits


10 Nov, 2016

1 commit

  • A subdevice is an abstract entity that can be used to tie actions to the
    booting and shutting down of a remote processor. The subdevice object is
    expected to be embedded in concrete implementations, allowing for a
    variety of use cases to be implemented.

    Signed-off-by: Bjorn Andersson

    Bjorn Andersson
     

19 Oct, 2016

1 commit

  • Storage of the firmware name was inconsistent, either storing a pointer
    to a name stored with unknown ownership, or a variable length tacked
    onto the end of the struct proc allocated in rproc_alloc.

    In preparation for allowing the firmware of an already allocated struct
    rproc to be changed, instead always keep a locally maintained copy of
    the firmware name.

    Signed-off-by: Matt Redfearn
    Signed-off-by: Bjorn Andersson

    Matt Redfearn
     

03 Oct, 2016

1 commit


07 Sep, 2016

2 commits

  • In current implementation, struct fw_rsc_vdev_vring which describes
    vring resource in firmware resource table owns only device address,
    because it assumes that host is responsible of vring allocation and
    only device address is needed by coprocessor.
    But if vrings need to be fixed in system memory map for any reasons
    (security, SoC charactieristics...), physical address is needed exatly
    identified the memory chunck by host.

    For that let's transform reserved field of struct fw_rsc_vdev_vring
    to pa (physical address).

    Signed-off-by: Loic Pallardy
    Signed-off-by: Bjorn Andersson

    Loic PALLARDY
     
  • Replace 0xFFFFFFFFFFFFFFFF by -1 to fit any type.

    Signed-off-by: Loic Pallardy
    Signed-off-by: Bjorn Andersson

    Loic PALLARDY
     

18 Aug, 2016

2 commits

  • As we moved the vdev handling to the main boot/shutdown code path we can
    further simplify the resource table handling by moving the parsing spet
    to boot as well. The lifespan of the resource table is changed to live
    from rproc_boot() to rproc_shutdown().

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

    Bjorn Andersson
     
  • 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
     

13 Aug, 2016

2 commits


13 May, 2016

1 commit


17 Jun, 2015

2 commits

  • The rproc_da_to_va API is currently used to perform any device to
    kernel address translations to meet the different needs of the remoteproc
    core/drivers (eg: loading). The functionality is achieved within the
    remoteproc core, and is limited only for carveouts allocated within the
    core.

    A new rproc ops, da_to_va, is added to provide flexibility to platform
    implementations to perform the address translation themselves when the
    above conditions cannot be met by the implementations. The rproc_da_to_va()
    API is extended to invoke this ops if present, and fallback to regular
    processing if the platform implementation cannot provide the translation.
    This will allow any remoteproc implementations to translate addresses for
    dedicated memories like internal memories.

    While at this, also update the rproc_da_to_va() documentation since it
    is an exported function.

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

    Suman Anna
     
  • Allow users of remoteproc the ability to get a handle to an rproc by
    passing a phandle supplied in the user's device tree node. This is
    useful in situations that require manual booting of the rproc.

    This patch uses the code removed by commit 40e575b1d0b3 ("remoteproc:
    remove the get_by_name/put API") for the ref counting but is modified
    to use a simple list and locking mechanism and has rproc_get_by_name
    replaced with an rproc_get_by_phandle API.

    Signed-off-by: Dave Gerlach
    Signed-off-by: Suman Anna
    [fix order of Signed-off-by tags]
    Signed-off-by: Ohad Ben-Cohen

    Dave Gerlach
     

12 Mar, 2015

1 commit

  • The remoteproc framework currently relies on iommu_present() on
    the bus the device is on, to perform MMU management. However, this
    logic doesn't scale for multi-arch, especially for processors that
    do not have an IOMMU. Replace this logic instead by using a h/w
    capability flag for the presence of IOMMU in the rproc structure.

    This issue is seen on OMAP platforms when trying to add a remoteproc
    driver for a small Cortex M3 called the WkupM3 used for suspend /
    resume management on TI AM335/AM437x SoCs. This processor does not
    have an MMU. Same is the case with another processor subsystem
    PRU-ICSS on AM335/AM437x. All these are platform devices, and the
    current iommu_present check will not scale for the same kernel image
    to support OMAP4/OMAP5 and AM335/AM437x.

    The existing platform implementation drivers - OMAP remoteproc, STE
    Modem remoteproc and DA8xx remoteproc, are updated as well to properly
    configure the newly added rproc field.

    Cc: Robert Tivy
    Cc: Linus Walleij
    Signed-off-by: Suman Anna
    [small change in the commit title and in a single comment]
    Signed-off-by: Ohad Ben-Cohen

    Suman Anna
     

07 Apr, 2013

2 commits

  • Support virtio configuration space and device status. The virtio
    device can now access the resource table in shared memory.

    Signed-off-by: Sjur Brændeland
    Acked-by: Ido Yariv
    [rebase and style changes]
    Signed-off-by: Ohad Ben-Cohen

    Sjur Brændeland
     
  • Copy resource table from first to second firmware loading.
    After firmware is loaded to memory, update the vdevs resource
    pointer to the resource table kept in device memory.

    Signed-off-by: Sjur Brændeland
    Acked-by: Ido Yariv
    [rebase, terminology and style changes]
    Signed-off-by: Ohad Ben-Cohen

    Ohad Ben-Cohen
     

19 Sep, 2012

1 commit

  • Some of the rproc drivers (STE modem specifically) needs to know
    the range of the notification IDs used for notifying the device.

    Maintain a variable in struct rproc holding the largest allocated
    notification id, so low-level rproc drivers could access it.

    Signed-off-by: Sjur Brændeland
    [ohad: rebase, slightly edit commit log]
    Signed-off-by: Ohad Ben-Cohen

    Sjur Brændeland
     

18 Sep, 2012

3 commits

  • Add a 'recovery' debugfs entry to dynamically disable/enable recovery
    at runtime. This is useful when one is trying to debug an rproc crash;
    without it, a recovery will immediately take place, making it harder
    to debug the crash.

    Contributions from Subramaniam Chanderashekarapuram.

    Examples:

    - disabling recovery:
    $ echo disabled > /remoteproc/remoteproc0/recovery

    - in case you want to recover a crash, but keep recovery disabled
    (useful in debugging sessions when you expect additional crashes
    you want to debug):
    $ echo recover > /remoteproc/remoteproc0/recovery

    - enabling recovery:
    $ echo enabled > /remoteproc/remoteproc0/recovery

    Signed-off-by: Fernando Guzman Lugo
    [ohad: some white space, commentary and commit log changes]
    Signed-off-by: Ohad Ben-Cohen

    Fernando Guzman Lugo
     
  • Add rproc_trigger_recovery() which takes care of the recovery itself,
    by removing, and re-adding, all of the remoteproc's virtio devices.

    This resets all virtio users of the remote processor, during which
    the remote processor is powered off and on again.

    Signed-off-by: Fernando Guzman Lugo
    [ohad: introduce rproc_add_virtio_devices to avoid 1.copying code 2.anomaly]
    [ohad: some white space, naming and commit log changes]
    Signed-off-by: Ohad Ben-Cohen

    Fernando Guzman Lugo
     
  • Allow low-level remoteproc drivers to report rproc crashes by exporting
    a new rproc_report_crash() function (invoking this from non-rproc drivers
    is probably wrong, and should be carefully scrutinized if ever needed).

    rproc_report_crash() can be called from any context; it offloads the
    tasks of handling the crash to a separate thread.

    Handling the crash from a separate thread is helpful because:
    - Ability to call invoke rproc_report_crash() from atomic context, due to
    the fact that many crashes trigger an interrupt, so this function can be
    called directly from ISR context.
    - Avoiding deadlocks which could happen if rproc_report_crash() is called
    from a function which indirectly holds the rproc lock.

    Handling the crash might involve:
    - Remoteproc register dump
    - Remoteproc stack dump
    - Remoteproc core dump
    - Saving Remoteproc traces so they can be read after the crash
    - Reseting the remoteproc in order to make it functional again (hard recovery)

    Right now, we only print the crash type which was detected, and only the
    mmufault type is supported. Remoteproc low-level drivers can add more types
    when needed.

    Signed-off-by: Fernando Guzman Lugo
    [ohad: some commentary, white space and commit log changes]
    Signed-off-by: Ohad Ben-Cohen

    Fernando Guzman Lugo
     

15 Jul, 2012

1 commit

  • Firmware handling is made customizable.
    This is done by creating a separate ops structure for the
    firmware functions that depends on a particular firmware
    format (such as ELF). The ELF functions are default used
    unless the HW driver explicitly injects another firmware
    handler by updating rproc->fw_ops.
    The function rproc_da_to_va() is exported, as custom
    firmware handlers may need to use this function.

    Signed-off-by: Sjur Brændeland
    [ohad: namespace fixes, whitespace fixes, style fixes]
    Signed-off-by: Ohad Ben-Cohen

    Sjur Brændeland
     

06 Jul, 2012

4 commits

  • To make remoteproc's API more intuitive for developers, we adopt
    the driver core's naming, i.e. alloc -> add -> del -> put. We'll also
    add register/unregister when their first user shows up.

    Otherwise - there's no functional change here.

    Suggested by Russell King .

    Cc: Russell King
    Cc: Fernando Guzman Lugo
    Cc: Sjur Brændeland
    Reviewed-by: Linus Walleij
    Acked-by: Stephen Boyd
    Signed-off-by: Ohad Ben-Cohen

    Ohad Ben-Cohen
     
  • Remove rproc_get_by_name() and rproc_put(), and the associated
    remoteproc infrastructure that supports it (i.e. klist and friends),
    because:

    1. No one uses them
    2. Using them is highly discouraged, and any potential user
    will be deeply scrutinized and encouraged to move.

    If a user, that absolutely can't live with the direct boot/shutdown
    model, does show up one day, then bringing this functionality back
    is going to be trivial.

    At this point though, keeping this functionality around is way too
    much of a maintenance burden.

    Cc: Sjur Brændeland
    Cc: Loic Pallardy
    Cc: Ludovic BARRE
    Cc: Michal Simek
    Cc: Fernando Guzman Lugo
    Cc: Suman Anna
    Cc: Mark Grosen
    Acked-by: Stephen Boyd
    Signed-off-by: Ohad Ben-Cohen

    Ohad Ben-Cohen
     
  • Now that every rproc instance contains a device, we don't need a
    kref anymore to maintain the refcount of the rproc instances:
    that's what device are good with!

    This patch removes the now-redundant kref, and switches to
    {get, put}_device instead of kref_{get, put}.

    We also don't need the kref's release function anymore, and instead,
    we just utilize the class's release handler (which is now responsible
    for all memory de-allocations).

    Cc: Stephen Boyd
    Cc: Fernando Guzman Lugo
    Signed-off-by: Ohad Ben-Cohen

    Ohad Ben-Cohen
     
  • For each registered rproc, maintain a generic remoteproc device whose
    parent is the low level platform-specific device (commonly a pdev, but
    it may certainly be any other type of device too).

    With this in hand, the resulting device hierarchy might then look like:

    omap-rproc.0
    |
    - remoteproc0 for suggesting and
    discussing these ideas in one of the remoteproc review threads and
    to Fernando Guzman Lugo for trying them out
    with the (upcoming) runtime PM support for remoteproc.

    Cc: Fernando Guzman Lugo
    Reviewed-by: Stephen Boyd
    Signed-off-by: Ohad Ben-Cohen

    Ohad Ben-Cohen
     

07 Mar, 2012

3 commits

  • Remove the hardcoded vring alignment of 4096 bytes,
    and instead utilize tha vring alignment as specified in
    the resource table.

    This is needed for remote processors that have rigid
    memory requirement, and which have found the alignment of
    4096 bytes to be excessively big.

    Signed-off-by: Ohad Ben-Cohen
    Cc: Brian Swetland
    Cc: Iliyan Malchev
    Cc: Arnd Bergmann
    Cc: Grant Likely
    Cc: Rusty Russell
    Cc: Mark Grosen
    Cc: John Williams
    Cc: Michal Simek
    Cc: Loic PALLARDY
    Cc: Ludovic BARRE
    Cc: Omar Ramirez Luna
    Cc: Guzman Lugo Fernando
    Cc: Anna Suman
    Cc: Clark Rob
    Cc: Stephen Boyd
    Cc: Saravana Kannan
    Cc: David Brown
    Cc: Kieran Bingham
    Cc: Tony Lindgren

    Ohad Ben-Cohen
     
  • Now that the resource table supports publishing a virtio device
    in a single resource entry, firmware images can start supporting
    more than a single vdev.

    This patch removes the single vdev limitation of the remoteproc
    framework so multi-vdev firmwares can be leveraged: VDEV resource
    entries are parsed when the rproc is registered, and as a result
    their vrings are set up and the virtio devices are registered
    (and they go away when the rproc goes away).

    Moreover, we no longer only support VIRTIO_ID_RPMSG vdevs; any
    virtio device type goes now. As a result, there's no more any
    rpmsg-specific APIs or code in remoteproc: it all becomes generic
    virtio handling.

    Signed-off-by: Ohad Ben-Cohen
    Cc: Brian Swetland
    Cc: Iliyan Malchev
    Cc: Arnd Bergmann
    Cc: Grant Likely
    Cc: Rusty Russell
    Cc: Mark Grosen
    Cc: John Williams
    Cc: Michal Simek
    Cc: Loic PALLARDY
    Cc: Ludovic BARRE
    Cc: Omar Ramirez Luna
    Cc: Guzman Lugo Fernando
    Cc: Anna Suman
    Cc: Clark Rob
    Cc: Stephen Boyd
    Cc: Saravana Kannan
    Cc: David Brown
    Cc: Kieran Bingham
    Cc: Tony Lindgren

    Ohad Ben-Cohen
     
  • The resource table is an array of 'struct fw_resource' members, where
    each resource entry is expressed as a single member of that array.

    This approach got us this far, but it has a few drawbacks:

    1. Different resource entries end up overloading the same members of 'struct
    fw_resource' with different meanings. The resulting code is error prone
    and hard to read and maintain.

    2. It's impossible to extend 'struct fw_resource' without breaking the
    existing firmware images (and we already want to: we can't introduce the
    new virito device resource entry with the current scheme).

    3. It doesn't scale: 'struct fw_resource' must be as big as the largest
    resource entry type. As a result, smaller resource entries end up
    utilizing only small part of it.

    This is fixed by defining a dedicated structure for every resource type,
    and then converting the resource table to a list of type-value members.
    Instead of a rigid array of homogeneous structs, the resource table
    is turned into a collection of heterogeneous structures.

    This way:
    1. Resource entries consume exactly the amount of bytes they need.
    2. It's easy to extend: just create a new resource entry structure, and assign
    it a new type.
    3. The code is easier to read and maintain: the structures' members names are
    meaningful.

    While we're at it, this patch has several other resource table changes:
    1. The resource table gains a simple header which contains the
    number of entries in the table and their offsets within the table. This
    makes the parsing code simpler and easier to read.
    2. A version member is added to the resource table. Should we change the
    format again, we'll bump up this version to prevent breakage with
    existing firmware images.
    3. The VRING and VIRTIO_DEV resource entries are combined to a single
    VDEV entry. This paves the way to supporting multiple VDEV entries.
    4. Since we don't really support 64-bit rprocs yet, convert two stray u64
    members to u32.

    Signed-off-by: Ohad Ben-Cohen
    Cc: Brian Swetland
    Cc: Iliyan Malchev
    Cc: Arnd Bergmann
    Cc: Grant Likely
    Cc: Rusty Russell
    Cc: Mark Grosen
    Cc: John Williams
    Cc: Michal Simek
    Cc: Loic PALLARDY
    Cc: Ludovic BARRE
    Cc: Omar Ramirez Luna
    Cc: Guzman Lugo Fernando
    Cc: Anna Suman
    Cc: Clark Rob
    Cc: Stephen Boyd
    Cc: Saravana Kannan
    Cc: David Brown
    Cc: Kieran Bingham
    Cc: Tony Lindgren

    Ohad Ben-Cohen
     

23 Feb, 2012

1 commit


09 Feb, 2012

2 commits

  • RSC_VIRTIO_CFG isn't being used, so remove it.

    Originally it was introduced to overcome a resource table limitation
    that prevented describing a virtio device in a single resource table
    entry.

    The plan though is to describe resource table entries in a TLV fashion,
    where each entry will consume the amount of space it requires,
    so the original limitation is anyway temporary.

    Reported-by: Stephen Boyd
    Signed-off-by: Ohad Ben-Cohen

    Ohad Ben-Cohen
     
  • Modern SoCs typically employ a central symmetric multiprocessing (SMP)
    application processor running Linux, with several other asymmetric
    multiprocessing (AMP) heterogeneous processors running different instances
    of operating system, whether Linux or any other flavor of real-time OS.

    Booting a remote processor in an AMP configuration typically involves:
    - Loading a firmware which contains the OS image
    - Allocating and providing it required system resources (e.g. memory)
    - Programming an IOMMU (when relevant)
    - Powering on the device

    This patch introduces a generic framework that allows drivers to do
    that. In the future, this framework will also include runtime power
    management and error recovery.

    Based on (but now quite far from) work done by Fernando Guzman Lugo
    .

    ELF loader was written by Mark Grosen , based on
    msm's Peripheral Image Loader (PIL) by Stephen Boyd .

    Designed with Brian Swetland .

    Signed-off-by: Ohad Ben-Cohen
    Acked-by: Grant Likely
    Cc: Brian Swetland
    Cc: Arnd Bergmann
    Cc: Tony Lindgren
    Cc: Russell King
    Cc: Rusty Russell
    Cc: Andrew Morton
    Cc: Greg KH
    Cc: Stephen Boyd

    Ohad Ben-Cohen