From: Bjorn Andersson <bjorn.andersson@linaro.org> To: Tero Kristo <t-kristo@ti.com> Cc: ohad@wizery.com, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, s-anna@ti.com Subject: Re: [PATCH 08/17] remoteproc/omap: Add support for DRA7xx remote processors Date: Tue, 12 Nov 2019 10:13:46 -0800 [thread overview] Message-ID: <20191112181343.GJ3797@yoga> (raw) In-Reply-To: <0d26759a-8a48-e573-cbf6-721c6e5367c1@ti.com> On Tue 12 Nov 00:37 PST 2019, Tero Kristo wrote: > On 12/11/2019 01:37, Bjorn Andersson wrote: > > On Mon 28 Oct 05:42 PDT 2019, Tero Kristo wrote: [..] > > > + for (; data && data->device_name; data++) { > > > + if (!strcmp(dev_name(&pdev->dev), data->device_name)) > > > > I don't fancy the reliance on node names in devicetree, is this well > > defined in the binding? > > I don't think it is.... So, would it be better to just replace the > compatible strings for dra7 remoteprocs to be like ti,dra7-dsp1 / > ti,dra7-dsp2 etc.? I think that would clean up the code also quite a bit. > While it would solve "my" problem I'm not entirely sure about it being a proper way to flag that they should have different default firmware. One way would be to simply rely on a "firmware-name" property read from DeviceTree (this was previously objected to, but we have that for several bindings now). Regards, Bjorn > > > > > + return data->fw_name; > > > + } > > > + > > > + return ERR_PTR(-ENOENT); > > > } > > > static int omap_rproc_get_boot_data(struct platform_device *pdev, > > > @@ -334,7 +384,8 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev, > > > int ret; > > > if (!of_device_is_compatible(np, "ti,omap4-dsp") && > > > - !of_device_is_compatible(np, "ti,omap5-dsp")) > > > + !of_device_is_compatible(np, "ti,omap5-dsp") && > > > + !of_device_is_compatible(np, "ti,dra7-dsp")) > > > return 0; > > > oproc->boot_data = devm_kzalloc(&pdev->dev, sizeof(*oproc->boot_data), > > > @@ -360,18 +411,27 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev, > > > return -EINVAL; > > > } > > > + if (of_device_is_compatible(np, "ti,dra7-dsp")) > > > + oproc->boot_data->boot_reg_shift = 10; > > > > Put this in omap_rproc_dev_data. > > Yeah. > > > > > > + > > > return 0; > > > } > > > static int omap_rproc_of_get_internal_memories(struct platform_device *pdev, > > > struct rproc *rproc) > > > { > > > - static const char * const mem_names[] = {"l2ram"}; > > > + static const char * const ipu_mem_names[] = {"l2ram"}; > > > + static const char * const dra7_dsp_mem_names[] = {"l2ram", "l1pram", > > > + "l1dram"}; > > > struct device_node *np = pdev->dev.of_node; > > > struct omap_rproc *oproc = rproc->priv; > > > struct device *dev = &pdev->dev; > > > + const char * const *mem_names; > > > struct resource *res; > > > int num_mems; > > > + const __be32 *addrp; > > > + u32 l4_offset = 0; > > > + u64 size; > > > int i; > > > /* OMAP4 and OMAP5 DSPs do not have support for flat SRAM */ > > > @@ -379,7 +439,15 @@ static int omap_rproc_of_get_internal_memories(struct platform_device *pdev, > > > of_device_is_compatible(np, "ti,omap5-dsp")) > > > return 0; > > > - num_mems = ARRAY_SIZE(mem_names); > > > + /* DRA7 DSPs have two additional SRAMs at L1 level */ > > > + if (of_device_is_compatible(np, "ti,dra7-dsp")) { > > > + mem_names = dra7_dsp_mem_names; > > > + num_mems = ARRAY_SIZE(dra7_dsp_mem_names); > > > + } else { > > > + mem_names = ipu_mem_names; > > > + num_mems = ARRAY_SIZE(ipu_mem_names); > > > + } > > > + > > > oproc->mem = devm_kcalloc(dev, num_mems, sizeof(*oproc->mem), > > > GFP_KERNEL); > > > if (!oproc->mem) > > > @@ -395,7 +463,26 @@ static int omap_rproc_of_get_internal_memories(struct platform_device *pdev, > > > return PTR_ERR(oproc->mem[i].cpu_addr); > > > } > > > oproc->mem[i].bus_addr = res->start; > > > - oproc->mem[i].dev_addr = OMAP_RPROC_IPU_L2RAM_DEV_ADDR; > > > + > > > + /* > > > + * The DSPs have the internal memories starting at a fixed > > > + * offset of 0x800000 from address 0, and this corresponds to > > > + * L2RAM. The L3 address view has the L2RAM bus address as the > > > + * starting address for the IP, so the L2RAM memory region needs > > > + * to be processed first, and the device addresses for each > > > + * memory region can be computed using the relative offset > > > + * from this base address. > > > + */ > > > + if (of_device_is_compatible(np, "ti,dra7-dsp") && > > > > Please don't use a ternary operator repeatedly, it makes the code hard > > to follow. > > Yeah this parts looks somewhat messy, let me try to fix that. > > -Tero > > > > > Regards, > > Bjorn > > > > > + !strcmp(mem_names[i], "l2ram")) { > > > + addrp = of_get_address(dev->of_node, i, &size, NULL); > > > + l4_offset = of_translate_address(dev->of_node, addrp); > > > + } > > > + oproc->mem[i].dev_addr = > > > + of_device_is_compatible(np, "ti,dra7-dsp") ? > > > + res->start - l4_offset + > > > + OMAP_RPROC_DSP_LOCAL_MEM_OFFSET : > > > + OMAP_RPROC_IPU_L2RAM_DEV_ADDR; > > > oproc->mem[i].size = resource_size(res); > > > dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %p da 0x%x\n", > > > -- > > > 2.17.1 > > > > > > -- > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org> To: Tero Kristo <t-kristo@ti.com> Cc: ohad@wizery.com, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, s-anna@ti.com Subject: Re: [PATCH 08/17] remoteproc/omap: Add support for DRA7xx remote processors Date: Tue, 12 Nov 2019 10:13:43 -0800 [thread overview] Message-ID: <20191112181343.GJ3797@yoga> (raw) In-Reply-To: <0d26759a-8a48-e573-cbf6-721c6e5367c1@ti.com> On Tue 12 Nov 00:37 PST 2019, Tero Kristo wrote: > On 12/11/2019 01:37, Bjorn Andersson wrote: > > On Mon 28 Oct 05:42 PDT 2019, Tero Kristo wrote: [..] > > > + for (; data && data->device_name; data++) { > > > + if (!strcmp(dev_name(&pdev->dev), data->device_name)) > > > > I don't fancy the reliance on node names in devicetree, is this well > > defined in the binding? > > I don't think it is.... So, would it be better to just replace the > compatible strings for dra7 remoteprocs to be like ti,dra7-dsp1 / > ti,dra7-dsp2 etc.? I think that would clean up the code also quite a bit. > While it would solve "my" problem I'm not entirely sure about it being a proper way to flag that they should have different default firmware. One way would be to simply rely on a "firmware-name" property read from DeviceTree (this was previously objected to, but we have that for several bindings now). Regards, Bjorn > > > > > + return data->fw_name; > > > + } > > > + > > > + return ERR_PTR(-ENOENT); > > > } > > > static int omap_rproc_get_boot_data(struct platform_device *pdev, > > > @@ -334,7 +384,8 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev, > > > int ret; > > > if (!of_device_is_compatible(np, "ti,omap4-dsp") && > > > - !of_device_is_compatible(np, "ti,omap5-dsp")) > > > + !of_device_is_compatible(np, "ti,omap5-dsp") && > > > + !of_device_is_compatible(np, "ti,dra7-dsp")) > > > return 0; > > > oproc->boot_data = devm_kzalloc(&pdev->dev, sizeof(*oproc->boot_data), > > > @@ -360,18 +411,27 @@ static int omap_rproc_get_boot_data(struct platform_device *pdev, > > > return -EINVAL; > > > } > > > + if (of_device_is_compatible(np, "ti,dra7-dsp")) > > > + oproc->boot_data->boot_reg_shift = 10; > > > > Put this in omap_rproc_dev_data. > > Yeah. > > > > > > + > > > return 0; > > > } > > > static int omap_rproc_of_get_internal_memories(struct platform_device *pdev, > > > struct rproc *rproc) > > > { > > > - static const char * const mem_names[] = {"l2ram"}; > > > + static const char * const ipu_mem_names[] = {"l2ram"}; > > > + static const char * const dra7_dsp_mem_names[] = {"l2ram", "l1pram", > > > + "l1dram"}; > > > struct device_node *np = pdev->dev.of_node; > > > struct omap_rproc *oproc = rproc->priv; > > > struct device *dev = &pdev->dev; > > > + const char * const *mem_names; > > > struct resource *res; > > > int num_mems; > > > + const __be32 *addrp; > > > + u32 l4_offset = 0; > > > + u64 size; > > > int i; > > > /* OMAP4 and OMAP5 DSPs do not have support for flat SRAM */ > > > @@ -379,7 +439,15 @@ static int omap_rproc_of_get_internal_memories(struct platform_device *pdev, > > > of_device_is_compatible(np, "ti,omap5-dsp")) > > > return 0; > > > - num_mems = ARRAY_SIZE(mem_names); > > > + /* DRA7 DSPs have two additional SRAMs at L1 level */ > > > + if (of_device_is_compatible(np, "ti,dra7-dsp")) { > > > + mem_names = dra7_dsp_mem_names; > > > + num_mems = ARRAY_SIZE(dra7_dsp_mem_names); > > > + } else { > > > + mem_names = ipu_mem_names; > > > + num_mems = ARRAY_SIZE(ipu_mem_names); > > > + } > > > + > > > oproc->mem = devm_kcalloc(dev, num_mems, sizeof(*oproc->mem), > > > GFP_KERNEL); > > > if (!oproc->mem) > > > @@ -395,7 +463,26 @@ static int omap_rproc_of_get_internal_memories(struct platform_device *pdev, > > > return PTR_ERR(oproc->mem[i].cpu_addr); > > > } > > > oproc->mem[i].bus_addr = res->start; > > > - oproc->mem[i].dev_addr = OMAP_RPROC_IPU_L2RAM_DEV_ADDR; > > > + > > > + /* > > > + * The DSPs have the internal memories starting at a fixed > > > + * offset of 0x800000 from address 0, and this corresponds to > > > + * L2RAM. The L3 address view has the L2RAM bus address as the > > > + * starting address for the IP, so the L2RAM memory region needs > > > + * to be processed first, and the device addresses for each > > > + * memory region can be computed using the relative offset > > > + * from this base address. > > > + */ > > > + if (of_device_is_compatible(np, "ti,dra7-dsp") && > > > > Please don't use a ternary operator repeatedly, it makes the code hard > > to follow. > > Yeah this parts looks somewhat messy, let me try to fix that. > > -Tero > > > > > Regards, > > Bjorn > > > > > + !strcmp(mem_names[i], "l2ram")) { > > > + addrp = of_get_address(dev->of_node, i, &size, NULL); > > > + l4_offset = of_translate_address(dev->of_node, addrp); > > > + } > > > + oproc->mem[i].dev_addr = > > > + of_device_is_compatible(np, "ti,dra7-dsp") ? > > > + res->start - l4_offset + > > > + OMAP_RPROC_DSP_LOCAL_MEM_OFFSET : > > > + OMAP_RPROC_IPU_L2RAM_DEV_ADDR; > > > oproc->mem[i].size = resource_size(res); > > > dev_dbg(dev, "memory %8s: bus addr %pa size 0x%x va %p da 0x%x\n", > > > -- > > > 2.17.1 > > > > > > -- > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
next prev parent reply other threads:[~2019-11-12 18:13 UTC|newest] Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-28 12:42 [PATCH 00/17] remoteproc: omap changes on top of v5.4-rc1 Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-10-28 12:42 ` [PATCH 01/17] dt-bindings: remoteproc: Add OMAP remoteproc bindings Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-06 3:27 ` Rob Herring 2019-11-06 3:27 ` Rob Herring 2019-11-06 12:44 ` Tero Kristo 2019-11-06 12:44 ` Tero Kristo 2019-11-06 13:27 ` Rob Herring 2019-11-06 13:27 ` Rob Herring 2019-11-06 13:50 ` Tero Kristo 2019-11-06 13:50 ` Tero Kristo 2019-11-07 14:05 ` [PATCHv2 " Tero Kristo 2019-11-07 14:05 ` Tero Kristo 2019-11-13 14:25 ` Rob Herring 2019-10-28 12:42 ` [PATCH 02/17] remoteproc/omap: Switch to SPDX license identifiers Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-09 1:03 ` Bjorn Andersson 2019-11-09 1:03 ` Bjorn Andersson 2019-11-12 8:16 ` Tero Kristo 2019-11-12 8:16 ` Tero Kristo 2019-12-20 3:30 ` Suman Anna 2019-12-20 3:30 ` Suman Anna 2019-10-28 12:42 ` [PATCH 03/17] remoteproc/omap: Add device tree support Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-11 23:16 ` Bjorn Andersson 2019-11-11 23:16 ` Bjorn Andersson 2019-11-12 8:14 ` Tero Kristo 2019-11-12 8:14 ` Tero Kristo 2019-10-28 12:42 ` [PATCH 04/17] remoteproc/omap: Add a sanity check for DSP boot address alignment Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-11 23:18 ` Bjorn Andersson 2019-11-11 23:18 ` Bjorn Andersson 2019-10-28 12:42 ` [PATCH 05/17] remoteproc/omap: Add support to parse internal memories from DT Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-11 23:21 ` Bjorn Andersson 2019-11-11 23:21 ` Bjorn Andersson 2019-11-12 8:21 ` Tero Kristo 2019-11-12 8:21 ` Tero Kristo 2019-10-28 12:42 ` [PATCH 06/17] remoteproc/omap: Add the rproc ops .da_to_va() implementation Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-11 23:22 ` Bjorn Andersson 2019-11-11 23:22 ` Bjorn Andersson 2019-11-12 8:22 ` Tero Kristo 2019-11-12 8:22 ` Tero Kristo 2019-10-28 12:42 ` [PATCH 07/17] remoteproc/omap: Initialize and assign reserved memory node Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-11 23:23 ` Bjorn Andersson 2019-11-11 23:23 ` Bjorn Andersson 2019-10-28 12:42 ` [PATCH 08/17] remoteproc/omap: Add support for DRA7xx remote processors Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-11 23:37 ` Bjorn Andersson 2019-11-11 23:37 ` Bjorn Andersson 2019-11-12 8:37 ` Tero Kristo 2019-11-12 8:37 ` Tero Kristo 2019-11-12 18:13 ` Bjorn Andersson [this message] 2019-11-12 18:13 ` Bjorn Andersson 2019-11-13 8:08 ` Tero Kristo 2019-11-13 8:08 ` Tero Kristo 2019-10-28 12:42 ` [PATCH 09/17] remoteproc/omap: Remove the unused fields from platform data Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-11 23:37 ` Bjorn Andersson 2019-11-11 23:37 ` Bjorn Andersson 2019-10-28 12:42 ` [PATCH 10/17] remoteproc/omap: Remove the omap_rproc_reserve_cma declaration Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-11 23:37 ` Bjorn Andersson 2019-11-11 23:37 ` Bjorn Andersson 2019-10-28 12:42 ` [PATCH 11/17] remoteproc/omap: Check for undefined mailbox messages Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-11 23:39 ` Bjorn Andersson 2019-11-11 23:39 ` Bjorn Andersson 2019-11-12 8:38 ` Tero Kristo 2019-11-12 8:38 ` Tero Kristo 2019-10-28 12:42 ` [PATCH 12/17] remoteproc/omap: Request a timer(s) for remoteproc usage Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-12 4:13 ` Bjorn Andersson 2019-11-12 4:13 ` Bjorn Andersson 2019-11-12 8:42 ` Tero Kristo 2019-11-12 8:42 ` Tero Kristo 2019-10-28 12:42 ` [PATCH 13/17] remoteproc/omap: add support for system suspend/resume Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-10-30 4:01 ` kbuild test robot 2019-11-12 6:15 ` Bjorn Andersson 2019-11-12 6:15 ` Bjorn Andersson 2019-11-12 8:45 ` Tero Kristo 2019-11-12 8:45 ` Tero Kristo 2019-11-12 18:06 ` Bjorn Andersson 2019-11-12 18:06 ` Bjorn Andersson 2019-10-28 12:42 ` [PATCH 14/17] remoteproc/omap: add support for runtime auto-suspend/resume Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-10-28 12:42 ` [PATCH 15/17] remoteproc/omap: report device exceptions and trigger recovery Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-12 6:26 ` Bjorn Andersson 2019-11-12 6:26 ` Bjorn Andersson 2019-11-12 8:46 ` Tero Kristo 2019-11-12 8:46 ` Tero Kristo 2019-10-28 12:42 ` [PATCH 16/17] remoteproc/omap: add watchdog functionality for remote processors Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-10-28 12:42 ` [PATCH 17/17] remoteproc/omap: fix auto-suspend failure warning during crashed state Tero Kristo 2019-10-28 12:42 ` Tero Kristo 2019-11-12 6:28 ` Bjorn Andersson 2019-11-12 6:28 ` Bjorn Andersson
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=20191112181343.GJ3797@yoga \ --to=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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.