All of lore.kernel.org
 help / color / mirror / Atom feed
From: lauraa@codeaurora.org (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Add pdev_archdata for dmamask
Date: Mon, 27 Jan 2014 17:42:07 -0800	[thread overview]
Message-ID: <52E70AEF.4060602@codeaurora.org> (raw)
In-Reply-To: <20140127193149.GV15937@n2100.arm.linux.org.uk>

On 1/27/2014 11:31 AM, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 09:52:57AM -0800, Laura Abbott wrote:
>> The dma_mask for a device structure is a pointer. This pointer
>> needs to be set up before the dma mask can actually be set. Most
>> frameworks in the kernel take care of setting this up properly but
>> platform devices that don't follow a regular bus structure may not
>> ever have this set. As a result, checks such as dma_capable will
>> always return false on a raw platform device and dma_set_mask will
>> always return -EIO. Fix this by adding a dma_mask in the
>> platform_device archdata and setting it to be the dma_mask. Devices
>> used in other frameworks can change this as needed.
>
> You shouldn't need to do this.  I went through a lot of the drivers we
> currently have, fixing them up in various manners.  The basic rules
> for this stuff are:
>
> - It is the responsibility of the code creating the device to set a
>    reasonable default for the dma mask according to the bus and whether
>    DMA is supportable.
>
> - It is the responsibility of the driver _always_ to make a call to
>    dma_set_mask() and/or dma_set_coherent_mask() according to the
>    driver's needs if the driver is going to be using DMA.
>
> As a work-around for the buggy situation we have in the kernel with DT,
> various buggy workarounds have been incorporated into drivers which
> involve writing directly to the DMA masks, and other such games.  None
> of that is necessary when the dma_coerce_*() functions are used - but
> these are a stop-gap until the DT code gets fixed.
>
> The real answer here is to make DT conform to the first point above
> and not add yet another different hack to the kernel.
>

powerpc ran into this exact problem before and fixed it using this 
method (a77ce8167cc1d0370fcb1d79b367d62e050cb2b0
"driver core: Add ability for arch code to setup pdev_archdata" and
  314b02f503c2c219fde0fcf6f086fda415f8a847 "powerpc: implement 
arch_setup_pdev_archdata") so there is at least some precedent for this 
method.

Are there patches/discussion somewhere else on what a proper solution 
would be in the DT?

Thanks,
Laura

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

  reply	other threads:[~2014-01-28  1:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-27 17:52 [PATCH] arm64: Add pdev_archdata for dmamask Laura Abbott
2014-01-27 18:18 ` Uwe Kleine-König
2014-01-27 19:24   ` Laura Abbott
2014-01-27 20:25   ` Yann Droneaud
2014-01-27 20:36     ` Russell King - ARM Linux
2014-01-27 21:42       ` Yann Droneaud
2014-01-27 21:42         ` Yann Droneaud
2014-01-27 21:42         ` Yann Droneaud
2014-01-27 19:31 ` Russell King - ARM Linux
2014-01-28  1:42   ` Laura Abbott [this message]
2014-02-17 12:29     ` Catalin Marinas
2014-02-17 12:52     ` Russell King - ARM Linux

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=52E70AEF.4060602@codeaurora.org \
    --to=lauraa@codeaurora.org \
    --cc=linux-arm-kernel@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 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.