Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210425123607.26537-1-kevin3.tang@gmail.com> <20210425123607.26537-5-kevin3.tang@gmail.com>
 <20210430092249.n75to2das5m6p4zb@gilmour> <CAFPSGXYJxWJDo1cz+kJB8J9YayGx1hYa=04K5OJ3DHh9ifbuRQ@mail.gmail.com>
 <YKI26bZGAA+ZNLLj@8bytes.org> <bc0e3025-60bd-c6b4-117f-592dc1c1a2f0@arm.com> <CAAfSe-ughdeZ7YaVsXuWeGNq-+Q+_z+P=aeKpj957kE6d-hLmQ@mail.gmail.com>
In-Reply-To: <CAAfSe-ughdeZ7YaVsXuWeGNq-+Q+_z+P=aeKpj957kE6d-hLmQ@mail.gmail.com>
From:   Chunyan Zhang <zhang.lyra@gmail.com>
Date:   Wed, 26 May 2021 16:07:51 +0800
Message-ID: <CAAfSe-sRjSw=7vAX21OPL5+OfLXJNS9RNf8Lg5Hy56LZwPBwCA@mail.gmail.com>
Subject: Re: [PATCH v5 4/6] drm/sprd: add Unisoc's drm display controller driver
To:     Robin Murphy <robin.murphy@arm.com>
Cc:     Joerg Roedel <joro@8bytes.org>, Kevin Tang <kevin3.tang@gmail.com>,
        Maxime Ripard <maxime@cerno.tech>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Orson Zhai <orsonzhai@gmail.com>,
        "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
        ML dri-devel <dri-devel@lists.freedesktop.org>,
        DTML <devicetree@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

resend for switching to plain text mode.

On Wed, 26 May 2021 at 15:59, Chunyan Zhang <zhang.lyra@gmail.com> wrote:
>
> Hi Robin,
>
> On Tue, 18 May 2021 at 00:35, Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2021-05-17 10:27, Joerg Roedel wrote:
>> > On Fri, Apr 30, 2021 at 08:20:10PM +0800, Kevin Tang wrote:
>> >> Cc  Robin & Joerg
>> >
>> > This is just some GPU internal MMU being used here, it seems. It doesn=
't
>> > use the IOMMU core code, so no Ack needed from the IOMMU side.
>>
>> Except the actual MMU being used is drivers/iommu/sprd_iommu.c - this is
>
> Yes, it is using drivers/iommu/sprd_iommu.c.
>
>>
>>
>> just the display driver poking directly at the interrupt registers of
>> its associated IOMMU instance.
>
>
> Actually the display driver is poking its own interrupt registers in whic=
h some interrupts are caused by using IOMMU, others are purely its own ones=
:
> +/* Interrupt control & status bits */
> +#define BIT_DPU_INT_DONE               BIT(0)
> +#define BIT_DPU_INT_TE                 BIT(1)
> +#define BIT_DPU_INT_ERR                        BIT(2)
> +#define BIT_DPU_INT_UPDATE_DONE                BIT(4)
> +#define BIT_DPU_INT_VSYNC              BIT(5)
> +#define BIT_DPU_INT_MMU_VAOR_RD                BIT(16)
> +#define BIT_DPU_INT_MMU_VAOR_WR                BIT(17)
> +#define BIT_DPU_INT_MMU_INV_RD         BIT(18)
> +#define BIT_DPU_INT_MMU_INV_WR         BIT(19)
>
> From what I see in the product code, along with the information my collea=
gues told me, these _INT_MMU_ interrupts only need to be dealt with by clie=
nt devices(i.e. display). IOMMU doesn't even have the INT_STS register for =
some early products which we're trying to support in the mainstream kernel.
>
>>
>> I still think this is wrong, and that it
>> should be treated as a shared interrupt, with the IOMMU driver handling
>> its own registers and reporting to the client through the standard
>> report_iommu_fault() API, especially since there are apparently more
>> blocks using these IOMMU instances than just the display.
>
> For the next generation IOMMU, we will handle interrupts in IOMMU drivers=
 like you say here.
> But like I explained above, we have to leave interrupt handling in the cl=
ient device driver since the IOMMU we 're using in this display device does=
n't have an INT_STS register in the IOMMU register range.
>
> Thanks for the review,
> Chunyan
>
>>
>> Robin.