public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Tero Kristo <t-kristo@ti.com>
Cc: bjorn.andersson@linaro.org, ohad@wizery.com,
	linux-remoteproc@vger.kernel.org, afd@ti.com, s-anna@ti.com,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCHv7 04/15] remoteproc/omap: Add support to parse internal memories from DT
Date: Thu, 5 Mar 2020 09:56:39 -0700	[thread overview]
Message-ID: <20200305165639.GA13914@xps15> (raw)
In-Reply-To: <12cfb0db-f86e-3cd8-5010-d96daa91c184@ti.com>

On Wed, Mar 04, 2020 at 09:08:07PM +0200, Tero Kristo wrote:
> On 04/03/2020 19:32, Mathieu Poirier wrote:
> > On Fri, Feb 21, 2020 at 12:19:25PM +0200, Tero Kristo wrote:
> > > From: Suman Anna <s-anna@ti.com>
> > > 
> > > The OMAP remoteproc driver has been enhanced to parse and store
> > > the kernel mappings for different internal RAM memories that may
> > > be present within each remote processor IP subsystem. Different
> > > devices have varying memories present on current SoCs. The current
> > > support handles the L2RAM for all IPU devices on OMAP4+ SoCs. The
> > > DSPs on OMAP4/OMAP5 only have Unicaches and do not have any L1 or
> > > L2 RAM memories.
> > > 
> > > IPUs are expected to have the L2RAM at a fixed device address of
> > > 0x20000000, based on the current limitations on Attribute MMU
> > > configurations.
> > > 
> > > NOTE:
> > > The current logic doesn't handle the parsing of memories for DRA7
> > > remoteproc devices, and will be added alongside the DRA7 support.
> > > 
> > > Signed-off-by: Suman Anna <s-anna@ti.com>
> > > [t-kristo: converted to parse mem names / device addresses from pdata]
> > > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > > ---
> > >   drivers/remoteproc/omap_remoteproc.c | 89 ++++++++++++++++++++++++++++
> > >   1 file changed, 89 insertions(+)
> > > 
> > > diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> > > index 64b559caadff..4f92b069f5d0 100644
> > > --- a/drivers/remoteproc/omap_remoteproc.c
> > > +++ b/drivers/remoteproc/omap_remoteproc.c
> > > @@ -39,11 +39,27 @@ struct omap_rproc_boot_data {
> > >   	unsigned int boot_reg;
> > >   };
> > > +/**
> > > + * struct omap_rproc_mem - internal memory structure
> > > + * @cpu_addr: MPU virtual address of the memory region
> > > + * @bus_addr: bus address used to access the memory region
> > > + * @dev_addr: device address of the memory region from DSP view
> > > + * @size: size of the memory region
> > > + */
> > > +struct omap_rproc_mem {
> > > +	void __iomem *cpu_addr;
> > > +	phys_addr_t bus_addr;
> > > +	u32 dev_addr;
> > > +	size_t size;
> > > +};
> > > +
> > >   /**
> > >    * struct omap_rproc - omap remote processor state
> > >    * @mbox: mailbox channel handle
> > >    * @client: mailbox client to request the mailbox channel
> > >    * @boot_data: boot data structure for setting processor boot address
> > > + * @mem: internal memory regions data
> > > + * @num_mems: number of internal memory regions
> > >    * @rproc: rproc handle
> > >    * @reset: reset handle
> > >    */
> > > @@ -51,16 +67,30 @@ struct omap_rproc {
> > >   	struct mbox_chan *mbox;
> > >   	struct mbox_client client;
> > >   	struct omap_rproc_boot_data *boot_data;
> > > +	struct omap_rproc_mem *mem;
> > > +	int num_mems;
> > >   	struct rproc *rproc;
> > >   	struct reset_control *reset;
> > >   };
> > > +/**
> > > + * struct omap_rproc_mem_data - memory definitions for an omap remote processor
> > > + * @name: name for this memory entry
> > > + * @dev_addr: device address for the memory entry
> > > + */
> > > +struct omap_rproc_mem_data {
> > > +	const char *name;
> > > +	const u32 dev_addr;
> > > +};
> > > +
> > >   /**
> > >    * struct omap_rproc_dev_data - device data for the omap remote processor
> > >    * @device_name: device name of the remote processor
> > > + * @mems: memory definitions for this remote processor
> > >    */
> > >   struct omap_rproc_dev_data {
> > >   	const char *device_name;
> > > +	const struct omap_rproc_mem_data *mems;
> > >   };
> > >   /**
> > > @@ -223,12 +253,18 @@ static const struct rproc_ops omap_rproc_ops = {
> > >   	.kick		= omap_rproc_kick,
> > >   };
> > > +static const struct omap_rproc_mem_data ipu_mems[] = {
> > > +	{ .name = "l2ram", .dev_addr = 0x20000000 },
> > > +	{ },
> > > +};
> > > +
> > >   static const struct omap_rproc_dev_data omap4_dsp_dev_data = {
> > >   	.device_name	= "dsp",
> > >   };
> > >   static const struct omap_rproc_dev_data omap4_ipu_dev_data = {
> > >   	.device_name	= "ipu",
> > > +	.mems		= ipu_mems,
> > >   };
> > >   static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
> > > @@ -237,6 +273,7 @@ static const struct omap_rproc_dev_data omap5_dsp_dev_data = {
> > >   static const struct omap_rproc_dev_data omap5_ipu_dev_data = {
> > >   	.device_name	= "ipu",
> > > +	.mems		= ipu_mems,
> > >   };
> > >   static const struct of_device_id omap_rproc_of_match[] = {
> > > @@ -311,6 +348,54 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev,
> > >   	return 0;
> > >   }
> > > +static int omap_rproc_of_get_internal_memories(struct platform_device *pdev,
> > > +					       struct rproc *rproc)
> > > +{
> > > +	struct omap_rproc *oproc = rproc->priv;
> > > +	struct device *dev = &pdev->dev;
> > > +	const struct omap_rproc_dev_data *data;
> > > +	struct resource *res;
> > > +	int num_mems;
> > > +	int i;
> > > +
> > > +	data = of_device_get_match_data(&pdev->dev);
> > > +	if (!data)
> > > +		return -ENODEV;
> > > +
> > > +	if (!data->mems)
> > > +		return 0;
> > > +
> > > +	for (num_mems = 0; data->mems[num_mems].name; num_mems++)
> > > +		;
> > 
> > Please use of_property_count_elems_of_size() as it was done in omap_hwmod.c [1]
> 
> There is reason why it was not done like that here. We want to make sure all
> the memories required for the remoteproc are in place, missing any one of
> them is a fatal error as you see in the code few lines below (my comment.)
> 
> > 
> > [1]. https://elixir.bootlin.com/linux/v5.6-rc4/source/arch/arm/mach-omap2/omap_hwmod.c#L717
> > 
> > With the above:
> > 
> > Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> > 
> > 
> > > +
> > > +	oproc->mem = devm_kcalloc(dev, num_mems, sizeof(*oproc->mem),
> > > +				  GFP_KERNEL);
> > > +	if (!oproc->mem)
> > > +		return -ENOMEM;
> > > +
> > > +	for (i = 0; i < num_mems; i++) {
> > > +		res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > > +						   data->mems[i].name);
> > > +		oproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
> > > +		if (IS_ERR(oproc->mem[i].cpu_addr)) {
> > > +			dev_err(dev, "failed to parse and map %s memory\n",
> > > +				data->mems[i].name);
> > > +			return PTR_ERR(oproc->mem[i].cpu_addr);
> > > +		}
> 
> We check here that all the memories required are defined for the remoteproc.
> If we use of_property_count_elems_of_size, we only get the number of
> memories defined in DT.

To make sure all memories are accounted for use data->mem[] in the loop:


        num_mems = of_property_count_elems_of_size();
        oproc->mem = devm_kcalloc();

        for (i = 0; data->mem[i]; i++) {
                res = platform_get_resource_byname(pdev, IORESOURCES_MEM,
                                                   data->mems[i].name);
                oproc->mem[i].cpu_addr = devm_ioremap_resource(dev, res);
                ...
                ...
        }  

> 
> -Tero
> 
> > > +		oproc->mem[i].bus_addr = res->start;
> > > +		oproc->mem[i].dev_addr = data->mems[i].dev_addr;
> > > +		oproc->mem[i].size = resource_size(res);
> > > +
> > > +		dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %pK da 0x%x\n",
> > > +			data->mems[i].name, &oproc->mem[i].bus_addr,
> > > +			oproc->mem[i].size, oproc->mem[i].cpu_addr,
> > > +			oproc->mem[i].dev_addr);
> > > +	}
> > > +	oproc->num_mems = num_mems;
> > > +
> > > +	return 0;
> > > +}
> > > +
> > >   static int omap_rproc_probe(struct platform_device *pdev)
> > >   {
> > >   	struct device_node *np = pdev->dev.of_node;
> > > @@ -350,6 +435,10 @@ static int omap_rproc_probe(struct platform_device *pdev)
> > >   	/* All existing OMAP IPU and DSP processors have an MMU */
> > >   	rproc->has_iommu = true;
> > > +	ret = omap_rproc_of_get_internal_memories(pdev, rproc);
> > > +	if (ret)
> > > +		goto free_rproc;
> > > +
> > >   	ret = omap_rproc_get_boot_data(pdev, rproc);
> > >   	if (ret)
> > >   		goto free_rproc;
> > > -- 
> > > 2.17.1
> > > 
> > > --
> 
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

  reply	other threads:[~2020-03-05 16:56 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-21 10:19 [PATCHv7 00/15] remoteproc: updates for omap remoteproc support Tero Kristo
2020-02-21 10:19 ` [PATCHv7 01/15] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo
2020-02-21 10:19 ` [PATCHv7 02/15] remoteproc/omap: Add device tree support Tero Kristo
2020-03-03 22:53   ` Mathieu Poirier
2020-02-21 10:19 ` [PATCHv7 03/15] remoteproc/omap: Add a sanity check for DSP boot address alignment Tero Kristo
2020-03-03 22:56   ` Mathieu Poirier
2020-02-21 10:19 ` [PATCHv7 04/15] remoteproc/omap: Add support to parse internal memories from DT Tero Kristo
2020-02-24 14:15   ` Andrew F. Davis
2020-02-26  7:48     ` Tero Kristo
2020-03-04 17:32   ` Mathieu Poirier
2020-03-04 19:08     ` Tero Kristo
2020-03-05 16:56       ` Mathieu Poirier [this message]
2020-02-21 10:19 ` [PATCHv7 05/15] remoteproc/omap: Add the rproc ops .da_to_va() implementation Tero Kristo
2020-03-04 17:36   ` Mathieu Poirier
2020-02-21 10:19 ` [PATCHv7 06/15] remoteproc/omap: Initialize and assign reserved memory node Tero Kristo
2020-03-04 17:42   ` Mathieu Poirier
2020-02-21 10:19 ` [PATCHv7 07/15] remoteproc/omap: Add support for DRA7xx remote processors Tero Kristo
2020-03-04 17:48   ` Mathieu Poirier
2020-03-05 17:51     ` Suman Anna
2020-02-21 10:19 ` [PATCHv7 08/15] remoteproc/omap: Remove the platform_data header Tero Kristo
2020-03-04 17:48   ` Mathieu Poirier
2020-02-21 10:19 ` [PATCHv7 09/15] remoteproc/omap: Check for undefined mailbox messages Tero Kristo
2020-03-04 17:49   ` Mathieu Poirier
2020-02-21 10:19 ` [PATCHv7 10/15] remoteproc/omap: Request a timer(s) for remoteproc usage Tero Kristo
2020-03-04 18:33   ` Mathieu Poirier
2020-02-21 10:19 ` [PATCHv7 11/15] remoteproc/omap: Add support for system suspend/resume Tero Kristo
2020-03-04 20:24   ` Mathieu Poirier
2020-02-21 10:19 ` [PATCHv7 12/15] remoteproc/omap: Add support for runtime auto-suspend/resume Tero Kristo
2020-03-04 21:35   ` Mathieu Poirier
2020-03-05  0:13     ` Suman Anna
2020-02-21 10:19 ` [PATCHv7 13/15] remoteproc/omap: Report device exceptions and trigger recovery Tero Kristo
2020-03-04 21:38   ` Mathieu Poirier
2020-02-21 10:19 ` [PATCHv7 14/15] remoteproc/omap: Add watchdog functionality for remote processors Tero Kristo
2020-03-04 22:33   ` Mathieu Poirier
2020-03-05  0:20     ` Suman Anna
2020-03-05 17:13       ` Mathieu Poirier
2020-02-21 10:19 ` [PATCHv7 15/15] remoteproc/omap: Switch to SPDX license identifiers Tero Kristo
2020-03-04 22:42   ` Mathieu Poirier
2020-03-05  0:24     ` Suman Anna
2020-03-05 17:15       ` Mathieu Poirier

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=20200305165639.GA13914@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=afd@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=ohad@wizery.com \
    --cc=s-anna@ti.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