06 Jul, 2012

2 commits

  • 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
     

04 Jul, 2012

1 commit

  • Dynamically allocate the vrings' DMA when the remote processor
    is about to be powered on (i.e. when ->find_vqs() is invoked),
    and release them as soon as it is powered off (i.e. when ->del_vqs()
    is invoked).

    The obvious and immediate benefit is better memory utilization, since
    memory for the vrings is now only allocated when the relevant remote
    processor is used.

    Additionally, this approach also makes recovery of a (crashing)
    remote processor easier: one just needs to remove the relevant
    vdevs, and the entire vrings cleanup takes place automagically.

    Tested-by: Fernando Guzman Lugo
    Signed-off-by: Ohad Ben-Cohen

    Ohad Ben-Cohen
     

07 Mar, 2012

4 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
     
  • Boot the remote processor only after setting up the virtqueues,
    and shut it down before deleting them.

    Remote processors should obey virtio status changes, and
    therefore not manipulate/trigger the virtqueues while the virtio
    driver isn't ready, but it's just safer not to rely on that
    (plus a vq access might already be inflight while a vdev
    status is changed).

    We also don't have yet status change notifications, but that's
    a temporary limitation.

    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
     
  • At this point remoteproc can only register a single VIRTIO_ID_RPMSG virtio
    device.

    This limitation is going away soon: remoteproc is getting support for
    registering any number of virtio devices and of any type (as
    published by the firmware of the remote processor).

    Rename remoteproc_rpmsg.c to remoteproc_virtio.c in preparation of
    this generalization work.

    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