On Sun, May 31, 2020 at 10:22 PM Bharat Kumar Gogada
<bharatku@xxxxxxxxxx> wrote:
>
> > 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.
I was thinking maybe the indirect code might have to be custom, but
maybe everything can be handled in .map_bus().
Rob
