On Tue, Jul 31 2018, Sergio Paracuellos wrote: > This patch series include an attempt to avoid the use of custom > read and writes in driver code and use PCI subsystem common ones. > > In order to do this 'map_bus' callback is implemented and also > data structures for driver are included. The regs base address > ranges and data is being readed from device tree and the driver > gets clean a lot of code. > > This patchet also removes all legacy PCI code using now PCI_DRIVERS_GENERIC > kernel api. > > Changes in v7: > - PATCH 1: Store resources in mt7621_pci data structure. > - PATCH 1: Change completely function > mt7621_pci_parse_request_of_pci_ranges > to parse resources from ranges manually instead of use the function > devm_of_pci_get_host_bridge_resources. This is closer to the mips pci > legacy > code. > - PATCH 1: Create 'mt7621_pcie_request_resources' function to request > resources > parsed from ranges property in the DT. Use pci_add_resource_offset and > set them > manually like the mips pci-legacy code do. > - PATCH 1: don't delete function setup_cm_memory_region and call it with > memory > resource. > - Other patches rebased and adapted to this changes. >
No good, sorry.
mt7621_pci_parse_request_of_pci_ranges()
calls of_pci_range_to_resource() which, for IO resources,
calls
port = pci_address_to_pio(range->cpu_addr);
->cpu_addr is 1e160000
and pci_address_to_pci sees that this is larger that IO_SPACE_LIMIT
(0xffff) and returns -1.
So the pci probe failed.
Maybe mips should have a arch-specific pci_address_to_pio, which does
the setp_cm_memory_region() thing.... just a random guess really.
Though if I hack pci_address_to_pio() to succeed, I get:
[ 1.990000] mt7621-pci 1e140000.pcie: resource collision: [io
0x1e160000-0x1e16ffff] conflicts with PCI IO [io 0x0000-0xffff]
which looks a little weird ... why do those conflict? Maybe because
everything has to fit into "PCI IO"..
I'm getting lost...
Thanks,
NeilBrown
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
