Re: [RFC] PCI: BCM5301X: add PCIe2 driver for BCM5301X SoCs

[Ray Jui <rjui@broadcom.com>]

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
>