[PATCH v8 1/3] PCI: host: rcar: Add Renesas R-Car PCIe driver

[Phil Edworthy]

Hi Sergei,

On 24 June 2014 22:19, Sergei wrote:
> On 06/24/2014 02:01 PM, Phil Edworthy wrote:
> 
> >>>>       I'm investigating an imprecise external abort occurring once userland
> is
> >>>> started when I have NetMos
> 
> >>      Or is it MosChip now? Can't remember all their renames. :-)
> 
> > Do you know of somewhere I can buy a card with this chipset in the EU? I
> had a
> > quick search but couldn't find anything.
> 
>     No. But we probably can send such card to you.
That would be handy!

 
> [...]
> 
> >>>>> +
> >>>>> +	/* First resource is for IO */
> >>>>> +	mask = PAR_ENABLE;
> >>>>> +	if (res->flags & IORESOURCE_IO)
> >>>>> +		mask |= IO_SPACE;
> 
> >>>>       For the memory space this works OK as you're identity-mapping the
> >>>> memory
> >>>> ranges in your device trees. However, for the I/O space this means that
> it
> >>>> won't work as the BARs in the PCIe devices get programmed with the
> PCI bus
> >>>> addresses but the PCIe window translation register is programmed
> with a
> >>>> CPU
> >>>> address which don't at all match (given your device trees) and hence
> one
> >>>> can't
> >>>> access the card's I/O mapped registers at all...
> 
> >>> Hmm, I couldn't find any cards that supported I/O, so I wasn't able to
> test
> >>> this. Clearly this is an issue that needs looking into.
> 
> >>      Will you look into it then, or should I?
> 
> > I'll look at it.
> 
>     Thanks.
> 
> [...]
> 
> >>>>> +
> >>>>> +		if (win > PCI_MAX_RESOURCES)
> >>>>> +			break;
> >>>>> +	}
> >>>>> +
> >>>>> +	 err = rcar_pcie_parse_map_dma_ranges(pcie, pdev-
> >dev.of_node);
> >>>>> +	 if (err)
> >>>>> +		return err;
> >>>>> +
> >>>>> +	of_id = of_match_device(rcar_pcie_of_match, pcie->dev);
> >>>>> +	if (!of_id || !of_id->data)
> >>>>> +		return -EINVAL;
> >>>>> +	hw_init_fn = of_id->data;
> >>>>> +
> >>>>> +	/* Failure to get a link might just be that no cards are inserted
> */
> >>>>> +	err = hw_init_fn(pcie);
> >>>>> +	if (err) {
> >>>>> +		dev_info(&pdev->dev, "PCIe link down\n");
> >>>>> +		return 0;
> 
> >>>>       Not quite sure why you exit normally here without enabling the
> >>>> hardware.
> >>>> I think the internal bridge should be visible regardless of whether link is
> >>>> detected or not...
> 
> >>> Why would you want to see the bridge when you can do nothing with it?
> >> Aren't
> 
> >>      Because it's the way PCI works. You have the built-in devices always
> >> present and seen on a PCI bus. :-)
> 
> >>> you are just wasting resources?
> 
> >>      I think it's rather you who are wasting resources. ;-) Why not just fail
> >> the probe when you have no link?
> 
> > Ah, so we currently have a half-way house... not failing the probe, but not
> > enabling the HW. Either all or nothing would be preferable.
> 
>     Actually, I tried ignoring the link test and the kernel died horrible
> death without any console output. :-/ Having enabled the earlyprintk
> support,
> I was able to see the reason: panic("PCI: unable to scan bus!") in
> arch/arm/kernel/bios32.c...
> 
> > Thanks
> > Phil
> 
> WBR, Sergei

Thanks
Phil