From: Bjorn Andersson <bjorn.andersson@linaro.org> To: Stanimir Varbanov <stanimir.varbanov@linaro.org> Cc: Rob Herring <robh@kernel.org>, Andy Gross <andy.gross@linaro.org>, Ohad Ben-Cohen <ohad@wizery.com>, Stephen Boyd <sboyd@codeaurora.org>, Mark Rutland <mark.rutland@arm.com>, Rob Clark <robdclark@gmail.com>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document Date: Fri, 26 Aug 2016 15:23:45 -0700 [thread overview] Message-ID: <20160826222345.GK15161@tuxbot> (raw) In-Reply-To: <3429173a-d55a-51e1-0973-7e5bd31be297@linaro.org> On Thu 25 Aug 04:10 PDT 2016, Stanimir Varbanov wrote: > Hi Bjorn, > > On 08/25/2016 03:05 AM, Bjorn Andersson wrote: > > On Wed 24 Aug 08:36 PDT 2016, Stanimir Varbanov wrote: > > > >> Hi Rob, > >> > >> On 08/23/2016 08:32 PM, Rob Herring wrote: > >>> On Fri, Aug 19, 2016 at 06:53:19PM +0300, Stanimir Varbanov wrote: > >>>> Add devicetree binding document for Venus remote processor. > >>>> > >>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> > >>>> --- > >>>> .../devicetree/bindings/remoteproc/qcom,venus.txt | 33 ++++++++++++++++++++++ > >>>> 1 file changed, 33 insertions(+) > >>>> create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,venus.txt > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt > >>>> new file mode 100644 > >>>> index 000000000000..06a2db60fa38 > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt > >>>> @@ -0,0 +1,33 @@ > >>>> +Qualcomm Venus Peripheral Image Loader > >>>> + > >>>> +This document defines the binding for a component that loads and boots firmware > >>>> +on the Qualcomm Venus remote processor core. > >>> > >>> This does not make sense to me. Venus is the video encoder/decoder h/w, > >>> right? Why is the firmware loader separate from the codec block? Why > >>> rproc is used? Are there multiple clients? Naming it rproc_venus implies > >>> there aren't. And why does the firmware loading need 8MB of memory at a > >>> fixed address? > >>> > >> > >> The firmware for Venus case is 5MB. And here is 8MB because of > >> dma_alloc_from_coherent size restriction. > >> > > > > Then you should specify it 5MB large and we'll have to deal with this > > implementation issue in the code. I've created a JIRA ticket for > > the dma_alloc_from_coherent() behavior. > > Infact it should be 5MB + ~100KB for iommu page table. > Trying to wrap my head around how the iommu part works here. The downstream code seems to indicate that this is a "generic" secure iommu interface - used by venus, camera and kgsl; likely for dealing with DRM protected buffers. As such the iommu tables are not part of the venus rproc; I believe they should either be tied into the msm-iommu driver or perhaps exposed as its own iommu(?). But I presume from your inclusion that you've concluded that the venus firmware we have refuses to execute without these tables at least initialized, is this correct? > > > >> The address is not really fixed, cause the firmware could support > >> relocation. In this example I just picked up the next free memory region > >> in memory-reserved from msm8916.dtsi. > >> > > > > In 8974 we do have a physical region where it's expected to be loaded. > > > > So in line with upcoming remoteproc work we should support referencing a > > reserved-memory node with either reg or size. > > > > In the case of spotting a "reg" we're currently better off using > > ioremap. We're looking at getting the remoteproc core to deal with this > > mess. > > You mean that remoteproc core will parse memory-region property? > It has to, because it's a quite common scenario for remoteproc drivers to either get its backing memory from a static region or be restricted to part of system ram - properties that reserved-memory and memory-region captures already. > > > > > > So, on 8916 I think you should use the form: > > > > venus_mem: venus { > > size = <0x500000>; > > }; > > Don't forget that the physical address where the firmware is stored has > some range, the scm call will fail if it is out of the expected range, > probably because of some security reasons. So maybe alloc-ranges should > be specified here. > Thanks for highlighting this. > > > > And I don't think you should use the shared-dma-pool compatible, because > > this is not a region for multiple devices to allocate dma memory out of. > > Then I cannot reuse reserved-mem infrastructure. > You're right. If I understand the code correctly we need to use the compatible shared-dma-pool and mark it either "no-map" or "reusable", to be able to use dma_alloc_coherent(). But I presume we have the implementation issue of dma_alloc_coherent() failing in either case with the 5MB size. I think we need to look into that - and have created a JIRA ticket for it. Regards, Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> To: Stanimir Varbanov <stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Andy Gross <andy.gross-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Ohad Ben-Cohen <ohad-Ix1uc/W3ht7QT0dZR+AlfA@public.gmane.org>, Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-remoteproc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document Date: Fri, 26 Aug 2016 15:23:45 -0700 [thread overview] Message-ID: <20160826222345.GK15161@tuxbot> (raw) In-Reply-To: <3429173a-d55a-51e1-0973-7e5bd31be297-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> On Thu 25 Aug 04:10 PDT 2016, Stanimir Varbanov wrote: > Hi Bjorn, > > On 08/25/2016 03:05 AM, Bjorn Andersson wrote: > > On Wed 24 Aug 08:36 PDT 2016, Stanimir Varbanov wrote: > > > >> Hi Rob, > >> > >> On 08/23/2016 08:32 PM, Rob Herring wrote: > >>> On Fri, Aug 19, 2016 at 06:53:19PM +0300, Stanimir Varbanov wrote: > >>>> Add devicetree binding document for Venus remote processor. > >>>> > >>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > >>>> --- > >>>> .../devicetree/bindings/remoteproc/qcom,venus.txt | 33 ++++++++++++++++++++++ > >>>> 1 file changed, 33 insertions(+) > >>>> create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,venus.txt > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt > >>>> new file mode 100644 > >>>> index 000000000000..06a2db60fa38 > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt > >>>> @@ -0,0 +1,33 @@ > >>>> +Qualcomm Venus Peripheral Image Loader > >>>> + > >>>> +This document defines the binding for a component that loads and boots firmware > >>>> +on the Qualcomm Venus remote processor core. > >>> > >>> This does not make sense to me. Venus is the video encoder/decoder h/w, > >>> right? Why is the firmware loader separate from the codec block? Why > >>> rproc is used? Are there multiple clients? Naming it rproc_venus implies > >>> there aren't. And why does the firmware loading need 8MB of memory at a > >>> fixed address? > >>> > >> > >> The firmware for Venus case is 5MB. And here is 8MB because of > >> dma_alloc_from_coherent size restriction. > >> > > > > Then you should specify it 5MB large and we'll have to deal with this > > implementation issue in the code. I've created a JIRA ticket for > > the dma_alloc_from_coherent() behavior. > > Infact it should be 5MB + ~100KB for iommu page table. > Trying to wrap my head around how the iommu part works here. The downstream code seems to indicate that this is a "generic" secure iommu interface - used by venus, camera and kgsl; likely for dealing with DRM protected buffers. As such the iommu tables are not part of the venus rproc; I believe they should either be tied into the msm-iommu driver or perhaps exposed as its own iommu(?). But I presume from your inclusion that you've concluded that the venus firmware we have refuses to execute without these tables at least initialized, is this correct? > > > >> The address is not really fixed, cause the firmware could support > >> relocation. In this example I just picked up the next free memory region > >> in memory-reserved from msm8916.dtsi. > >> > > > > In 8974 we do have a physical region where it's expected to be loaded. > > > > So in line with upcoming remoteproc work we should support referencing a > > reserved-memory node with either reg or size. > > > > In the case of spotting a "reg" we're currently better off using > > ioremap. We're looking at getting the remoteproc core to deal with this > > mess. > > You mean that remoteproc core will parse memory-region property? > It has to, because it's a quite common scenario for remoteproc drivers to either get its backing memory from a static region or be restricted to part of system ram - properties that reserved-memory and memory-region captures already. > > > > > > So, on 8916 I think you should use the form: > > > > venus_mem: venus { > > size = <0x500000>; > > }; > > Don't forget that the physical address where the firmware is stored has > some range, the scm call will fail if it is out of the expected range, > probably because of some security reasons. So maybe alloc-ranges should > be specified here. > Thanks for highlighting this. > > > > And I don't think you should use the shared-dma-pool compatible, because > > this is not a region for multiple devices to allocate dma memory out of. > > Then I cannot reuse reserved-mem infrastructure. > You're right. If I understand the code correctly we need to use the compatible shared-dma-pool and mark it either "no-map" or "reusable", to be able to use dma_alloc_coherent(). But I presume we have the implementation issue of dma_alloc_coherent() failing in either case with the 5MB size. I think we need to look into that - and have created a JIRA ticket for it. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-08-26 22:23 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-19 15:53 [PATCH 0/4] Venus remoteproc driver Stanimir Varbanov 2016-08-19 15:53 ` Stanimir Varbanov 2016-08-19 15:53 ` [PATCH 1/4] firmware: qcom: scm: add a video command for state setting Stanimir Varbanov 2016-08-19 15:53 ` Stanimir Varbanov 2016-08-19 15:53 ` [PATCH 2/4] firmware: qcom: scm: add iommu scm calls for pg table Stanimir Varbanov 2016-08-22 16:29 ` kbuild test robot 2016-08-22 16:29 ` kbuild test robot 2016-08-22 16:29 ` kbuild test robot 2016-08-24 18:35 ` Gupta, Puja 2016-08-25 9:08 ` Stanimir Varbanov 2016-08-30 21:15 ` Andy Gross 2016-08-19 15:53 ` [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document Stanimir Varbanov 2016-08-23 17:32 ` Rob Herring 2016-08-23 18:21 ` Bjorn Andersson 2016-08-24 15:36 ` Stanimir Varbanov 2016-08-24 15:36 ` Stanimir Varbanov 2016-08-25 0:05 ` Bjorn Andersson 2016-08-25 11:10 ` Stanimir Varbanov 2016-08-25 11:10 ` Stanimir Varbanov 2016-08-26 22:23 ` Bjorn Andersson [this message] 2016-08-26 22:23 ` Bjorn Andersson 2016-08-29 11:48 ` Stanimir Varbanov 2016-08-30 17:17 ` Bjorn Andersson 2016-09-01 14:58 ` Stanimir Varbanov 2016-09-01 20:46 ` Andy Gross 2016-09-01 20:46 ` Andy Gross 2016-09-02 11:52 ` Marek Szyprowski 2016-09-02 20:12 ` Bjorn Andersson 2016-09-07 11:52 ` Stanimir Varbanov 2016-09-07 11:52 ` Stanimir Varbanov [not found] ` <CGME20160915084644eucas1p1bd3f2078d4e1cb3acfa0ea87557bff4f@eucas1p1.samsung.com> 2016-09-15 8:46 ` Marek Szyprowski 2016-08-19 15:53 ` [PATCH 4/4] remoteproc: qcom: add Venus video core firmware loader driver Stanimir Varbanov 2016-10-18 16:23 ` Stanimir Varbanov 2016-10-18 16:23 ` Stanimir Varbanov
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=20160826222345.GK15161@tuxbot \ --to=bjorn.andersson@linaro.org \ --cc=andy.gross@linaro.org \ --cc=devicetree@vger.kernel.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-remoteproc@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=ohad@wizery.com \ --cc=robdclark@gmail.com \ --cc=robh@kernel.org \ --cc=sboyd@codeaurora.org \ --cc=srinivas.kandagatla@linaro.org \ --cc=stanimir.varbanov@linaro.org \ /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.