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
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
