All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Gautam <vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
	linux-arm-msm
	<linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Tomasz Figa <tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
	Jordan Crouse <jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Sean Paul <seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	freedreno
	<freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: [PATCH v2 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg*
Date: Thu, 29 Nov 2018 15:14:21 +0530	[thread overview]
Message-ID: <CAFp+6iFDanGLoWf95CR2Etq76tC8+dpciOcJzou4QfAUO3WRQA@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGuM-R0=KRSmT+bt6SBaZg_ea3A_YFE+xfR_oCH9d9uORA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Wed, Nov 28, 2018 at 6:09 PM Rob Clark <robdclark@gmail.com> wrote:
>
> On Wed, Nov 28, 2018 at 2:39 AM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > > +             /*
> > > +              * dma_sync_sg_*() flush the physical pages, so point
> > > +              * sg->dma_address to the physical ones for the right behavior.
> > > +              */
> > > +             for_each_sg(msm_obj->sgt->sgl, s, msm_obj->sgt->nents, i)
> > > +                     sg_dma_address(s) = sg_phys(s);
> > > +
> >
> > I'm sorry, but this is completely bogus and not acceptable.
> >
> > The only place that is allowed to initialize sg_dma_address is
> > dma_map_sg.  If the default dma ops don't work for your setup we have
> > major a problem and need to fix the dma api / iommu integration instead
> > of hacking around it.
>
> I agree that the dma/iommu integration is very problematic for drm (in
> particular, gpu drivers that use the iommu as an gpu mmu)..  Really we
> need a way that a driver can opt-out of this, and access the cpu cache
> APIs directly, skipping the dma API entirely.  But as it is, we've had
> to hack around the dma API.  I'm not really sure this hack is any
> worse than abusing dma_(un)map_sg() for doing cache operations.
>
> I probably should have paid more attention and nak'd the dma/iommu
> integration before it landed.  But given that now we are stuck in this
> situation, while I'm certainly interested if anyone has some ideas
> about how to let drivers opt out of the dma/iommu integration and
> bypass the dma API layer, I'm ok with replacing a hack with a less-bad
> hack.

May I take it as a positive nod to respin the next version?

Regards
Vivek

>
> BR,
> -R



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Gautam <vivek.gautam@codeaurora.org>
To: Rob Clark <robdclark@gmail.com>
Cc: hch@infradead.org, David Airlie <airlied@linux.ie>,
	Tomasz Figa <tfiga@chromium.org>,
	open list <linux-kernel@vger.kernel.org>,
	freedreno <freedreno@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Jordan Crouse <jcrouse@codeaurora.org>,
	Sean Paul <seanpaul@chromium.org>
Subject: Re: [PATCH v2 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg*
Date: Thu, 29 Nov 2018 15:14:21 +0530	[thread overview]
Message-ID: <CAFp+6iFDanGLoWf95CR2Etq76tC8+dpciOcJzou4QfAUO3WRQA@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGuM-R0=KRSmT+bt6SBaZg_ea3A_YFE+xfR_oCH9d9uORA@mail.gmail.com>

On Wed, Nov 28, 2018 at 6:09 PM Rob Clark <robdclark@gmail.com> wrote:
>
> On Wed, Nov 28, 2018 at 2:39 AM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > > +             /*
> > > +              * dma_sync_sg_*() flush the physical pages, so point
> > > +              * sg->dma_address to the physical ones for the right behavior.
> > > +              */
> > > +             for_each_sg(msm_obj->sgt->sgl, s, msm_obj->sgt->nents, i)
> > > +                     sg_dma_address(s) = sg_phys(s);
> > > +
> >
> > I'm sorry, but this is completely bogus and not acceptable.
> >
> > The only place that is allowed to initialize sg_dma_address is
> > dma_map_sg.  If the default dma ops don't work for your setup we have
> > major a problem and need to fix the dma api / iommu integration instead
> > of hacking around it.
>
> I agree that the dma/iommu integration is very problematic for drm (in
> particular, gpu drivers that use the iommu as an gpu mmu)..  Really we
> need a way that a driver can opt-out of this, and access the cpu cache
> APIs directly, skipping the dma API entirely.  But as it is, we've had
> to hack around the dma API.  I'm not really sure this hack is any
> worse than abusing dma_(un)map_sg() for doing cache operations.
>
> I probably should have paid more attention and nak'd the dma/iommu
> integration before it landed.  But given that now we are stuck in this
> situation, while I'm certainly interested if anyone has some ideas
> about how to let drivers opt out of the dma/iommu integration and
> bypass the dma API layer, I'm ok with replacing a hack with a less-bad
> hack.

May I take it as a positive nod to respin the next version?

Regards
Vivek

>
> BR,
> -R



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

  parent reply	other threads:[~2018-11-29  9:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 21:37 [PATCH v2 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg* Vivek Gautam
2018-11-26 21:37 ` Vivek Gautam
     [not found] ` <20181126213710.3084-1-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-11-28  3:09   ` Tomasz Figa
2018-11-28  3:09     ` Tomasz Figa
2018-11-29  9:43     ` Vivek Gautam
2018-11-28  7:39 ` Christoph Hellwig
     [not found]   ` <20181128073940.GA13072-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2018-11-28  9:02     ` Vivek Gautam
2018-11-28  9:02       ` Vivek Gautam
2018-11-28 12:38     ` Rob Clark
2018-11-28 12:38       ` Rob Clark
     [not found]       ` <CAF6AEGuM-R0=KRSmT+bt6SBaZg_ea3A_YFE+xfR_oCH9d9uORA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-11-29  9:44         ` Vivek Gautam [this message]
2018-11-29  9:44           ` Vivek Gautam
2018-11-28 14:19   ` Lukas Wunner

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=CAFp+6iFDanGLoWf95CR2Etq76tC8+dpciOcJzou4QfAUO3WRQA@mail.gmail.com \
    --to=vivek.gautam-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
    --cc=airlied-cv59FeDIM0c@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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: link
Be 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.