mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Suman Anna <s-anna@ti.com>
To: Tero Kristo <t-kristo@ti.com>, <bjorn.andersson@linaro.org>,
	<ohad@wizery.com>, <linux-remoteproc@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <mathieu.poirier@linaro.org>,
	<linux-omap@vger.kernel.org>
Subject: Re: [PATCHv3 08/15] remoteproc/omap: Remove the unused fields from platform data
Date: Thu, 19 Dec 2019 20:44:07 -0600	[thread overview]
Message-ID: <abc17f7b-7664-9064-2e48-4b429847b105@ti.com> (raw)
In-Reply-To: <20191213125537.11509-9-t-kristo@ti.com>

Hi Tero,

On 12/13/19 6:55 AM, Tero Kristo wrote:
> From: Suman Anna <s-anna@ti.com>
> 
> The following fields: .name, .oh_name, .oh_name_opt, .mbox_name,
> .firmware, .ops and .set_bootaddr, are removed from the platform data,
> as these are no longer needed after the addition of DT support to the
> OMAP remoteproc driver.
> 
> The .name field was used to give a name to the remoteproc, and this
> is replaced with the device name. The .ops field was never used by
> the OMAP remoteproc driver. The .mbox_name was used to define the
> sub-mailbox node used for communication with the remote processor,
> and is retrieved using the 'mboxes' property in the DT node. The
> .firmware field is encoded directly in the OMAP remoteproc driver and
> is retrieved using driver match data. The .set_bootaddr ops was used
> for using a OMAP Control Module API to configure the boot address for
> the processor, and is now implemented within the driver using a
> syscon property.
> 
> The .oh_name field is used to define the primary hwmod for the processor
> node, and is represented using the 'ti,hwmods' property in the DT node.
> The .oh_name_opt field was primarily defined to identify the hwmod for
> the second cpu in a dual Cortex-M3/M4 IPU processor sub-system. This
> hwmod entry is no longer defined usually, but rather a single hwmod
> representing both the processors in the IPU sub-system is defined.
> A single firmware image (either in SMP-mode or a combined image for
> non-SMP mode) is used, with both the resets released together always
> as part of the device management. Any power management and recovery
> aspects require that both the processors be managed as one entity due
> to the presence of shared MMU and unicache within the IPU sub-system.
> 
> The OMAP remoteproc platform data structure is eventually expected
> to be removed completely once the other dependencies with the
> mach-omap layer are met.

This patch was a cleanup patch with DT using hwmod, and some of the
description is pertinent to that. Now that you have converted to ti,sysc
& reset with no dependencies against hwmod, the time for removing the
structure is here. Some of the patch description is no longer correct as
well since there is no 'ti,hwmods' :)

> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>  include/linux/platform_data/remoteproc-omap.h | 17 +----------------
>  1 file changed, 1 insertion(+), 16 deletions(-)
> 
> diff --git a/include/linux/platform_data/remoteproc-omap.h b/include/linux/platform_data/remoteproc-omap.h
> index 7e3a16097672..6bea01e199fe 100644
> --- a/include/linux/platform_data/remoteproc-omap.h
> +++ b/include/linux/platform_data/remoteproc-omap.h
> @@ -2,38 +2,23 @@
>  /*
>   * Remote Processor - omap-specific bits
>   *
> - * Copyright (C) 2011 Texas Instruments, Inc.
> + * Copyright (C) 2011-2018 Texas Instruments Incorporated - http://www.ti.com/

%s/2018/2019 when you do update the patch.

regards
Suman

>   * Copyright (C) 2011 Google, Inc.
>   */
>  
>  #ifndef _PLAT_REMOTEPROC_H
>  #define _PLAT_REMOTEPROC_H
>  
> -struct rproc_ops;
>  struct platform_device;
>  
>  /*
>   * struct omap_rproc_pdata - omap remoteproc's platform data
> - * @name: the remoteproc's name
> - * @oh_name: omap hwmod device
> - * @oh_name_opt: optional, secondary omap hwmod device
> - * @firmware: name of firmware file to load
> - * @mbox_name: name of omap mailbox device to use with this rproc
> - * @ops: start/stop rproc handlers
>   * @device_enable: omap-specific handler for enabling a device
>   * @device_shutdown: omap-specific handler for shutting down a device
> - * @set_bootaddr: omap-specific handler for setting the rproc boot address
>   */
>  struct omap_rproc_pdata {
> -	const char *name;
> -	const char *oh_name;
> -	const char *oh_name_opt;
> -	const char *firmware;
> -	const char *mbox_name;
> -	const struct rproc_ops *ops;
>  	int (*device_enable)(struct platform_device *pdev);
>  	int (*device_shutdown)(struct platform_device *pdev);
> -	void (*set_bootaddr)(u32);
>  };
>  
>  #if defined(CONFIG_OMAP_REMOTEPROC) || defined(CONFIG_OMAP_REMOTEPROC_MODULE)
> 


  reply	other threads:[~2019-12-20  2:44 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13 12:55 [PATCHv3 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
2019-12-13 12:55 ` [PATCHv3 01/15] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo
2019-12-20  3:38   ` Suman Anna
2019-12-13 12:55 ` [PATCHv3 02/15] remoteproc/omap: Add device tree support Tero Kristo
2019-12-17 23:01   ` Mathieu Poirier
2019-12-19 11:54     ` Tero Kristo
2019-12-20  2:08       ` Suman Anna
2019-12-20  9:36         ` Tero Kristo
2019-12-20 18:17           ` Suman Anna
2019-12-13 12:55 ` [PATCHv3 03/15] remoteproc/omap: Add a sanity check for DSP boot address alignment Tero Kristo
2019-12-13 12:55 ` [PATCHv3 04/15] remoteproc/omap: Add support to parse internal memories from DT Tero Kristo
2019-12-18  0:22   ` Mathieu Poirier
2019-12-19 12:31     ` Tero Kristo
2019-12-19 17:37       ` Mathieu Poirier
2019-12-20  2:15         ` Suman Anna
2019-12-13 12:55 ` [PATCHv3 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation Tero Kristo
2019-12-18  0:38   ` Mathieu Poirier
2019-12-19 13:18     ` Tero Kristo
2019-12-20  0:12       ` Mathieu Poirier
2019-12-20  2:34         ` Suman Anna
2019-12-20 22:15           ` Mathieu Poirier
2019-12-13 12:55 ` [PATCHv3 06/15] remoteproc/omap: Initialize and assign reserved memory node Tero Kristo
2019-12-13 12:55 ` [PATCHv3 07/15] remoteproc/omap: Add support for DRA7xx remote processors Tero Kristo
2019-12-18 21:31   ` Mathieu Poirier
2019-12-19 13:29     ` Tero Kristo
2019-12-13 12:55 ` [PATCHv3 08/15] remoteproc/omap: Remove the unused fields from platform data Tero Kristo
2019-12-20  2:44   ` Suman Anna [this message]
2019-12-20  9:48     ` Tero Kristo
2019-12-13 12:55 ` [PATCHv3 09/15] remoteproc/omap: Remove the omap_rproc_reserve_cma declaration Tero Kristo
2019-12-20  2:47   ` Suman Anna
2019-12-20  9:49     ` Tero Kristo
2019-12-13 12:55 ` [PATCHv3 10/15] remoteproc/omap: Check for undefined mailbox messages Tero Kristo
2019-12-13 12:55 ` [PATCHv3 11/15] remoteproc/omap: Request a timer(s) for remoteproc usage Tero Kristo
2019-12-18 22:43   ` Mathieu Poirier
2019-12-19 13:43     ` Tero Kristo
2019-12-13 12:55 ` [PATCHv3 12/15] remoteproc/omap: add support for system suspend/resume Tero Kristo
2019-12-19 21:46   ` Mathieu Poirier
2019-12-20  3:11     ` Suman Anna
2019-12-20 11:04       ` Tero Kristo
2019-12-20 18:23         ` Suman Anna
2019-12-20 21:58       ` Mathieu Poirier
2019-12-13 12:55 ` [PATCHv3 13/15] remoteproc/omap: add support for runtime auto-suspend/resume Tero Kristo
2019-12-19 23:43   ` Mathieu Poirier
2019-12-20  3:24     ` Suman Anna
2019-12-20 11:24       ` Tero Kristo
2019-12-20 18:44         ` Suman Anna
2020-01-02 12:50           ` Tero Kristo
2019-12-20 11:08     ` Tero Kristo
2019-12-13 12:55 ` [PATCHv3 14/15] remoteproc/omap: report device exceptions and trigger recovery Tero Kristo
2019-12-13 12:55 ` [PATCHv3 15/15] remoteproc/omap: add watchdog functionality for remote processors Tero Kristo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abc17f7b-7664-9064-2e48-4b429847b105@ti.com \
    --to=s-anna@ti.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=ohad@wizery.com \
    --cc=t-kristo@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®