Linux SNPS ARC Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: l.stach@pengutronix.de (Lucas Stach)
To: linux-snps-arc@lists.infradead.org
Subject: [RFC] etnaviv: missing dma_mask
Date: Thu, 23 Aug 2018 10:54:16 +0200	[thread overview]
Message-ID: <1535014456.2724.1.camel@pengutronix.de> (raw)
In-Reply-To: <20180817064222.GB10811@lst.de>

Am Freitag, den 17.08.2018, 08:42 +0200 schrieb Christoph Hellwig:
> On Tue, Aug 14, 2018@05:12:25PM +0300, Eugeniy Paltsev wrote:
> > Hi Lucas, Christoph,
> > 
> > After switching ARC to generic dma_noncoherent cache ops?
> > etnaviv driver start failing on dma maping functions because of
> > dma_mask lack.
> > 
> > So I'm wondering is it valid case to have device which is
> > DMA capable and doesn't have dma_mask set?
> > 
> > If not, then I guess something like that should work
> > (at least it works for ARC):
> 
> This looks ok is a minimal fix:
> 
> Reviewed-by: Christoph Hellwig <hch at lst.de>
> 
> But why doesn't this device have a dma-range property in DT?

Because the etnaviv device is a virtual device not represented in DT,
as it is only used to expose the DRM device, which may cover multiple
GPU core devices. The GPU core devices are properly configured from DT,
but unfortunately many of the dma related operations happen through the
DRM device. We could fix this by replacing many of the DRM helpers with
etnaviv specific functions handling dma per GPU core, but it isn't a
clear win right now, as generally on SoCs with multiple GPU cores, the
devices are on the same bus and have the same dma requirements.

Regards,
Lucas

      reply	other threads:[~2018-08-23  8:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-14 14:12 [RFC] etnaviv: missing dma_mask Eugeniy Paltsev
2018-08-17  6:42 ` Christoph Hellwig
2018-08-23  8:54   ` Lucas Stach [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=1535014456.2724.1.camel@pengutronix.de \
    --to=l.stach@pengutronix.de \
    --cc=linux-snps-arc@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox