On Tue, Jul 31 2018, Sergio Paracuellos wrote: > On Tue, Jul 31, 2018 at 08:55:52AM +1000, NeilBrown wrote: >> On Mon, Jul 30 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 >> > is being readed from device tree and the driver gets clean a lot >> > of code. >> > >> > Also the driver get removes all legacy PCI code using now >> > PCI_DRIVERS_GENERIC. >> > >> > Changes in v6: >> > - Reorder patches to be each patch correct in itself. >> > - PATCH 1 adds also Kconfig to do the step from legacy to generic code >> > - PATCH 1 remaps io space using devm_pci_remap_iospace for io resource >> > in >> > a new function called 'mt7621_pci_parse_request_of_pci_ranges'. >> > - Other patches rebased and adapted with this changes. >> >> No noticeable difference. >> Still hangs after >> [ 8.630000] ahci 0000:01:00.0: enabling device (0000 -> 0002) >> >> the readl() at the start of ahci_enable_ahci() hangs, reading c4017004. >> >> I built on a merge of >> Merge: 527838d470e3 b9f13084580c >> >> linus' master + staging/staging-testing >> >> dmesg below. > > Thanks for this. > .... >> [ 8.430000] bootconsole [early0] disabled >> [ 8.430000] bootconsole [early0] disabled >> [ 8.450000] cacheinfo: Failed to find cpu0 device node >> [ 8.460000] cacheinfo: Unable to detect cache hierarchy for CPU 0 >> [ 8.550000] loop: module loaded >> [ 8.560000] ahci 0000:01:00.0: enabling device (0000 -> 0002) >> >> > > So this last dmesg is the new one with last v6, right? Because I can see
Right.
> that at least now the assigned resources are pretty much the same of the ones
> in the dmesg of the
> original code talking in terms of assigned BAR's and bridge windows. No weird
> BAR 9 anymore, which I think is
> good. We can try to get back the hack which I removed at first and see what
> happend. The hack is
> this function removed in PATCH 2:
>
> -void setup_cm_memory_region(struct resource *mem_resource)
> -{
> - resource_size_t mask;
> - if (mips_cps_numiocu(0)) {
> - /* FIXME: hardware doesn't accept mask values with 1s after
> - * 0s (e.g. 0xffef), so it would be great to warn if that's
> - * about to happen */
> - mask = ~(mem_resource->end - mem_resource->start);
> -
> - write_gcr_reg1_base(mem_resource->start);
> - write_gcr_reg1_mask(mask | CM_GCR_REGn_MASK_CMTGT_IOCU0);
> - printk("PCI coherence region base: 0x%08llx, mask/settings:
> 0x%08llx\n",
> - (unsigned long long)read_gcr_reg1_base(),
> - (unsigned long long)read_gcr_reg1_mask());
> - }
> -}
>
> We can try to add it again and and call it from
> 'mt7621_pci_parse_request_of_pci_ranges'
> in the label of the case of the case 'IORESOURCE_MEM' (as you can see this
> was intentionally
> without code just to test this if this v6 fails):
>
> break;
> case IORESOURCE_MEM:
> + setup_cm_memory_region(res);
> break;
I added setup_cm_memory_region() back in and called it from
mt7621_pci_parse_request_of_pci_ranges()
as suggested.
Now we don't hang at the same place, but crash shortly after.
[ 8.750000] WARNING: CPU: 2 PID: 1 at ../drivers/ata/libahci.c:227
ahci_save_initial_config+0x3c/0x3e0
This is at the end of ahci_enable_ahci(). the HOST_AHCI_EN bit never was
set.
>
> If this also fails we can try to move the call to 'mt7621_pcie_parse_dt(pcie,
> &res);' after the
> HW initialization code just before the list_splice_init(&res,
> &bridge->windows); line:
>
> - err = mt7621_pcie_parse_dt(pcie, &res);
> - if (err) {
> - dev_err(dev, "Parsing DT failed\n");
> - return err;
> - }
> -
> - /*
> iomem_resource.start = 0;
> iomem_resource.end = ~0;
> ...
>
> write_config(0, 0, 0, 0x70c, val);
> }
>
> + err = mt7621_pcie_parse_dt(pcie, &res);
> + if (err) {
> + dev_err(dev, "Parsing DT failed\n");
> + return err;
> + }
> +
> list_splice_init(&res, &bridge->windows);
If I move the call to mt7621_pcie_parse_dt() anywhere after
the call to set_phy_for_ssc() I get a crash at the start of
set_pcie_phy() called from set_phy_for_ssc(), presumably because
pcie->base isn't set.
Keep trying, I'm sure we'll get there.
NeilBrown
>
> (I don't have access now to the laptop with the code and cannot diff
> properly, sorry).
>
> Hopefully it boots now?
>
> Thanks in advance.
>
> Best regards,
> Sergio Paracuellos
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list [email protected] http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
