OF: set dma_mask for ARM

PATCH In review Kristoffer Glembo 2 participants 2 messages Apr 20, 2011 1 message not in the archive

lore

Share & tools

lore

Kristoffer Glembo

author

2011-04-20 08:11 UTC #0 lore raw

PATCH 7/7 OF: set dma_mask for ARM

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.

Best regards,
Kristoffer Glembo

Quoted 26 lines · Grant Likely

Quoted 12 lines · Rob Herring
Quoted 6 lines
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

A message that is not in the archive (sent off-list or not yet received): 4DAE9540.8040006-FkzTOoA/[email protected]

Rob Herring

2011-04-20 12:06 UTC #2 lore raw

Quoted 9 lines · Kristoffer Glembo

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

Quoted 31 lines

Best regards, Kristoffer Glembo
Quoted 27 lines · Grant Likely
Quoted 12 lines · Rob Herring
Quoted 6 lines
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