[RFC] PCI: BCM5301X: add PCIe2 driver for BCM5301X SoCs
Ray Jui
rjui at broadcom.com
Fri Apr 17 09:07:26 PDT 2015
On 4/17/2015 7:09 AM, Arnd Bergmann wrote:
> (reviving an old thread)
>
> On Sunday 09 November 2014 21:27:40 Arnd Bergmann wrote:
>>
>>>>> + /*
>>>>> + * Inbound address translation setup
>>>>> + * Northstar only maps up to 128 MiB inbound, DRAM could be up to 1 GiB.
>>>>> + *
>>>>> + * For now allow access to entire DRAM, assuming it is less than 128MiB,
>>>>> + * otherwise DMA bouncing mechanism may be required.
>>>>> + * Also consider DMA mask to limit DMA physical address
>>>>> + */
>>>>> + /* 64-bit LE regs, write low word, high is 0 at reset */
>>>>> + bcma_write32(bdev, BCMA_CORE_PCIE2_FUNC0_IMAP1, PHYS_OFFSET | 0x1);
>>>>> + bcma_write32(bdev, BCMA_CORE_PCIE2_IARR1_LOWER,
>>>>> + PHYS_OFFSET | ((SZ_128M >> 20) & 0xff));
>>>>
>>>> Maybe I should bully you into enabling swiotlb on arm32
>>>
>>> This sounds complicated, I hope I can avoid it.
>>
>> I'd really hope that it's not that hard. We basically just need a copy of
>> coherent_swiotlb_dma_ops/noncoherent_swiotlb_dma_ops from arm64 and
>> use those on bcma devices, with the right dma_mask set.
>
> Peter Senna has tested this on bcm4708a0 (Buffalo WZR-1750DHP) and found
> that all RAM is DMA capable, as tested with CONFIG_VMSPLIT_1G. Could
> the code comment here be incorrect, or is it possible that it was fixed
> in later chip versions?
>
> If this works, using CONFIG_VMSPLIT_1G should result in noticeably
> better I/O performance on this chip.
>
> I have created a patch that lets him simulate the broken behavior on his
> machine, so he can work on implementing swiotlb, but it would certainly
> be best to understand which machines are really affected.
>
> Note that the driver that was merged as drivers/pci/host/pcie-iproc.c
> does not seem to touch the BCMA_CORE_PCIE2_IARR1_LOWER (offset 0xd08)
> register, and presumably the power-on default for this register
> maps all of RAM correctly.
That appears to be the case for Cygnus and NS+ but I just realized I
should not make this assumption since this is going to be the driver for
a lot of other iProc based chips. I need to check with our ASIC team on
limitation of PCIe on each chip on inbound mapping and do more
investigation and experiment myself.
Also note I won't have time to work on this in the short-term, but I
will eventually get to it.
Thanks,
Ray
>
> Arnd
>
More information about the linux-arm-kernel
mailing list