[PATCH 7/7] OF: set dma_mask for ARM

[Rob Herring]

On 04/20/2011 03:11 AM, Kristoffer Glembo wrote:
> Hi,
>
> Have you gotten any feedback on this? I am facing the same decision
> on SPARC32. I need to add dma_mask to get USB working on non-PCI
> buses and I'm currently thinking about doing it either the PowerPC
> way or going with the dma_mask =&coherent_dma_mask route. It would be
> nice if we could get some community agreement on which is the proper
> way of doing this.
>

No, only Grant's original comment. I did switch to using a bus notifier 
callback to set the dma_mask pointer so I don't need to modify the DT or 
arch code.

Rob

> Best regards, Kristoffer Glembo
>
>
> On 11/16/2010 11:24 PM, Grant Likely wrote:
>>> On Tue, Nov 16, 2010 at 02:33:55PM -0600, Rob Herring wrote:
>>>> From: Rob Herring<rob.herring at calxeda.com>
>>>>
>>>> Various drivers require dma_mask to be valid, so it needs to be
>>>> setup when doing OF probing on ARM.
>>>>
>>>> Signed-off-by: Rob Herring<rob.herring at calxeda.com>
>>>
>>> I'll let patches 6&   7 lay fallow for the moment.  I'm not
>>> hugely fond of the powerpc approach (which microblaze copies),
>>> but I haven't had a chance to look for a better solution.
>>>
>>
>> Looking at this some more, there's a couple of options I see.
>>
>> Other buses (ISA, PCI, EISA) have a dma_mask in their struct. So
>> perhaps platform_device should just have a dma_mask field.
>>
>> There are several examples of setting dma_mask =&coherent_dma_mask.
>> I'm not sure if this is considered correct. At least on ARM, I
>> don't think these would need to be different.
>>
>> Another option would be using bus notifiers to set the dma_mask
>> like platform_data. But that doesn't seem like a good long term
>> solution.
>>
>> Rob