Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1381642 > unrolled thread

Re: [PATCH 0/3] v4.4: Revert "PCI: Implement pcibios_alloc_irq() and

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/3] v4.4: Revert "PCI: Implement pcibios_alloc_irq() and Joerg Roedel <jroedel@suse.de> - 2016-04-18 14:00 +0200
    Re: [PATCH 0/3] v4.4: Revert "PCI: Implement pcibios_alloc_irq() and Bjorn Helgaas <helgaas@kernel.org> - 2016-04-18 16:50 +0200
      Re: [PATCH 0/3] v4.4: Revert "PCI: Implement pcibios_alloc_irq() and Joerg Roedel <jroedel@suse.de> - 2016-04-19 11:50 +0200

#1381642 — Re: [PATCH 0/3] v4.4: Revert "PCI: Implement pcibios_alloc_irq() and

Hi Bjorn,

On Fri, Apr 15, 2016 at 10:08:21AM -0500, Bjorn Helgaas wrote:
> I assume you're thinking about doing pci_enable_resources() before
> the core calls the driver's probe method?  One question there is how
> we would deal with pci_enable_device_mem().  If the core calls
> pci_enable_resources(), it has to assume the driver requires all BARs,
> and there are quite a few drivers that don't need the I/O BARs.

Yes, I think that the problem might be fixed when the resources are
enabled during the pcibios-call.

What do you think of enabling the the resources at probe time for the
pcibios-call and disable them afterwards? Then the driver can re-enable
whatever it needs and keep the rest disabled.



	Joerg

[toc] | [next] | [standalone]

#1381777

On Mon, Apr 18, 2016 at 01:50:15PM +0200, Joerg Roedel wrote:
> Hi Bjorn,
> 
> On Fri, Apr 15, 2016 at 10:08:21AM -0500, Bjorn Helgaas wrote:
> > I assume you're thinking about doing pci_enable_resources() before
> > the core calls the driver's probe method?  One question there is how
> > we would deal with pci_enable_device_mem().  If the core calls
> > pci_enable_resources(), it has to assume the driver requires all BARs,
> > and there are quite a few drivers that don't need the I/O BARs.
> 
> Yes, I think that the problem might be fixed when the resources are
> enabled during the pcibios-call.
> 
> What do you think of enabling the the resources at probe time for the
> pcibios-call and disable them afterwards? Then the driver can re-enable
> whatever it needs and keep the rest disabled.

That might work, but the problem seems to be that we aren't enabling
IRQs correctly, so I'd rather have a fix that explicitly addresses
IRQs than one that relies on some non-obvious connection between
enabling BARs and IRQs.

Bjorn

[toc] | [prev] | [next] | [standalone]

#1382337

On Mon, Apr 18, 2016 at 09:43:36AM -0500, Bjorn Helgaas wrote:
> That might work, but the problem seems to be that we aren't enabling
> IRQs correctly, so I'd rather have a fix that explicitly addresses
> IRQs than one that relies on some non-obvious connection between
> enabling BARs and IRQs.

Yeah, either we or the BIOS does something wrong. The bugzilla entry
states that it works with pci=routeirq. The dmesg from kernel 4.3 shows
that per default ACPI routing is used for IRQs.

The difference this makes in the code is the pcibios_enable_irq function
pointer. For ACPI it points to acpi_pci_irq_enable and in the
pci=routeirq case to pirq_enable_irq.

So the problem appears when acpi_pci_irq_enable is used with device
resources disabled. This might very well also be a bios issue that we
have to work around, no?



	Joerg

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web