devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vikash Garodia <vgarodia@codeaurora.org>
To: Tomasz Figa <tfiga@google.com>
Cc: Rob Herring <robh@kernel.org>, Hans Verkuil <hverkuil@xs4all.nl>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Andy Gross <andy.gross@linaro.org>,
	bjorn.andersson@linaro.org,
	Stanimir Varbanov <stanimir.varbanov@linaro.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-soc@vger.kernel.org, devicetree@vger.kernel.org,
	Alexandre Courbot <acourbot@chromium.org>,
	linux-media-owner@vger.kernel.org
Subject: Re: [PATCH v2 5/5] venus: register separate driver for firmware device
Date: Wed, 06 Jun 2018 18:33:56 +0530	[thread overview]
Message-ID: <f220c6aef40ea3fbcc3b6adcec234527@codeaurora.org> (raw)
In-Reply-To: <CAAFQd5DGKnU15pjF2+eyMUaSuE0FCr2FMF90WrJb+kXt80xBCw@mail.gmail.com>

On 2018-06-06 10:16, Tomasz Figa wrote:
> Hi Rob,
> 
> On Wed, Jun 6, 2018 at 6:08 AM Rob Herring <robh@kernel.org> wrote:
>> 
>> On Sat, Jun 02, 2018 at 01:56:08AM +0530, Vikash Garodia wrote:
>> > A separate child device is added for video firmware.
>> > This is needed to
>> > [1] configure the firmware context bank with the desired SID.
>> > [2] ensure that the iova for firmware region is from 0x0.
>> >
>> > Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
>> > ---
>> >  .../devicetree/bindings/media/qcom,venus.txt       |  8 +++-
>> >  drivers/media/platform/qcom/venus/core.c           | 48 +++++++++++++++++++---
>> >  drivers/media/platform/qcom/venus/firmware.c       | 20 ++++++++-
>> >  drivers/media/platform/qcom/venus/firmware.h       |  2 +
>> >  4 files changed, 71 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
>> > index 00d0d1b..701cbe8 100644
>> > --- a/Documentation/devicetree/bindings/media/qcom,venus.txt
>> > +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
>> > @@ -53,7 +53,7 @@
>> >
>> >  * Subnodes
>> >  The Venus video-codec node must contain two subnodes representing
>> > -video-decoder and video-encoder.
>> > +video-decoder and video-encoder, one optional firmware subnode.
>> >
>> >  Every of video-encoder or video-decoder subnode should have:
>> >
>> > @@ -79,6 +79,8 @@ Every of video-encoder or video-decoder subnode should have:
>> >                   power domain which is responsible for collapsing
>> >                   and restoring power to the subcore.
>> >
>> > +The firmware sub node must contain the iommus specifiers for ARM9.
>> > +
>> >  * An Example
>> >       video-codec@1d00000 {
>> >               compatible = "qcom,msm8916-venus";
>> > @@ -105,4 +107,8 @@ Every of video-encoder or video-decoder subnode should have:
>> >                       clock-names = "core";
>> >                       power-domains = <&mmcc VENUS_CORE1_GDSC>;
>> >               };
>> > +             venus-firmware {
>> > +                     compatible = "qcom,venus-firmware-no-tz";
>> > +                     iommus = <&apps_smmu 0x10b2 0x0>;
>> 
>> This mostly looks like you are adding a node in order to create a
>> platform device. DT is not the only way to create platform devices and
>> shouldn't be used when the device is not really a separate h/w device.
>> Plus it seems like it is debatable that you even need a driver.
>> 
>> For iommus, just move it up to the parent (or add to existing prop).
> 
> As far as I understood the issue from reading this series and also
> talking a bit with Stanimir, there are multiple (physical?) ports from
> the Venus hardware block and that includes one dedicated for firmware
> loading, which has IOVA range restrictions up to 6 MiBs or something
> like that.
> 
> If we add the firmware port to the iommus property of the main node,
> we would bind it to the same IOVA address space as the other ports and
> so it would be part of the main full 32-bit IOMMU domain.

Not really port-wise, but the restriction part is right. Once the 
firmware
is loaded, the ARM9 can only execute those firmware instructions if it 
is
present in iova address 0x0.
Merging it to parent device cannot guarantee that the firmware memory is
mapped from 0x0.

> Best regards,
> Tomasz

      parent reply	other threads:[~2018-06-06 13:03 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-01 20:26 [PATCH v2 0/5] Venus updates - PIL Vikash Garodia
2018-06-01 20:26 ` [PATCH v2 1/5] media: venus: add a routine to reset ARM9 Vikash Garodia
2018-06-01 22:15   ` Stanimir Varbanov
2018-06-05 10:57     ` Vinod
2018-06-06  1:34       ` Alexandre Courbot
2018-07-04  8:35     ` Vikash Garodia
2018-06-22 23:15   ` Bjorn Andersson
2018-06-01 20:26 ` [PATCH v2 2/5] media: venus: add a routine to set venus state Vikash Garodia
2018-06-01 21:21   ` Jordan Crouse
2018-06-04 12:54     ` Tomasz Figa
2018-07-04  7:59       ` Vikash Garodia
2018-07-04  9:00         ` Tomasz Figa
2018-07-04  9:41           ` Vikash Garodia
2018-07-04 10:08             ` Tomasz Figa
2018-06-04 13:50   ` Stanimir Varbanov
2018-07-04  8:08     ` Vikash Garodia
2018-06-05 11:03   ` Vinod
2018-06-01 20:26 ` [PATCH v2 3/5] venus: add check to make scm calls Vikash Garodia
2018-06-01 21:22   ` Jordan Crouse
2018-06-04 12:58   ` Tomasz Figa
2018-06-22 23:19     ` Bjorn Andersson
2018-06-01 20:26 ` [PATCH v2 4/5] media: venus: add no TZ boot and shutdown routine Vikash Garodia
2018-06-01 21:30   ` Jordan Crouse
2018-06-04 13:09   ` Tomasz Figa
2018-06-01 20:26 ` [PATCH v2 5/5] venus: register separate driver for firmware device Vikash Garodia
2018-06-01 21:32   ` Jordan Crouse
2018-06-04 13:18   ` Tomasz Figa
2018-06-04 13:56     ` Stanimir Varbanov
2018-06-05  4:08       ` Tomasz Figa
2018-06-05  8:45         ` Stanimir Varbanov
2018-06-06  5:41           ` Tomasz Figa
2018-06-06 16:46       ` Bjorn Andersson
2018-06-05 21:07   ` Rob Herring
2018-06-06  4:46     ` Tomasz Figa
2018-06-06 12:53       ` Rob Herring
2018-06-06 13:03       ` Vikash Garodia [this message]

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=f220c6aef40ea3fbcc3b6adcec234527@codeaurora.org \
    --to=vgarodia@codeaurora.org \
    --cc=acourbot@chromium.org \
    --cc=andy.gross@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media-owner@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mchehab@kernel.org \
    --cc=robh@kernel.org \
    --cc=stanimir.varbanov@linaro.org \
    --cc=tfiga@google.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;
as well as URLs for NNTP newsgroup(s).