> On 25. 02. 20 17:32, Rob Herring wrote:
> > On Mon, Feb 17, 2020 at 8:28 AM Michal Simek <michal.simek@xxxxxxxxxx>
> wrote:
> >>
> >> Hi Rob,
> >>
> >> On 14. 02. 20 0:47, Rob Herring wrote:
> >>> On Wed, Feb 12, 2020 at 2:58 AM Michal Simek
> <michal.simek@xxxxxxxxxx> wrote:
> >>>>
> >>>>
> >>>> I am sending this series as before SMP support.
> >>>> Most of these patches are clean ups and should be easy to review
> >>>> them. I expect there will be more discussions about SMP support.
> >>>
> >>> While not really related to adding SMP, any chance you or someone
> >>> could look at moving microblaze PCI support to drivers/pci/? I
> >>> suspect much of the code should drop out as we have common helpers
> >>> for much of it now. That would leave only powerpc and mips for DT+PCI
> platforms.
> >>
> >> can you please suggest changes which could be done?
> >> I have CC Bharat and he could look at it.
> >
> > Look at the host controller drivers in drivers/pci/controller/.
> > pci-host-{generic,common}.c is a good template to start with as that's
> > a controller with standard config space accesses and no h/w setup
> > needed. Essentially you need to call devm_pci_alloc_host_bridge(),
> > pci_parse_request_of_pci_ranges() and pci_host_probe() with whatever
> > h/w setup you need in between those calls.
> >
> > Looking at the microblaze PCI code, looks like you may need custom
> > config space accessors which is quite common. Probably all the
> > resource and device scanning can be removed. If you look at arm64, all
> > the arch PCI code is just for ACPI.
Hi Rob,
Can you please let us know why we might need custom config space accessors ?
We tested pci_generic_config_read/write accessors on microblaze, and we
did not see any issues.
Regards,
Bharat
