Re: EHCI host broken -- interrupts disabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[+cc linux-pci]

On Tue, Jan 14, 2014 at 11:47 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 14 Jan 2014, Sarah Sharp wrote:
>
>> Hi Alan,
>
> I'm not a good person to ask about this.  Maybe Bjorn can help.
>
>> All this info is second- or third-hand, so please excuse the extremely
>> vague bug report.
>>
>> A new Intel Atom system (Baytrail) comes with both an xHCI host and an
>> EHCI host, but the BIOS has an "EHCI only" option that hides the xHCI
>> host PCI device from the operating system.  It appears that when the
>> BIOS is in this mode, the EHCI PCI interrupt is disabled, and the host
>> simply doesn't work.
>>
>> Jamie and Gaggery have more details about the system and the exact
>> failure mode.  They can provide dmesg as well as a PCI register space
>> dump, if necessary.  (Jamie and Gaggery, please note, a publicly
>> archived mailing list is Cc'ed.)
>>
>> A customer reports that the following patch fixes the issue:
>>
>> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
>> index 3e86bf4371b3..e77566a021ec 100644
>> --- a/drivers/usb/host/ehci-pci.c
>> +++ b/drivers/usb/host/ehci-pci.c
>> @@ -112,6 +112,9 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
>>       case PCI_VENDOR_ID_INTEL:
>>               if (pdev->device == PCI_DEVICE_ID_INTEL_CE4100_USB)
>>                       hcd->has_tt = 1;
>> +             /* Baytrail BIOS in EHCI only mode fails to enable interrupts */
>> +             if (pdev->device == 0x0f34)
>> +                     pci_intx(pdev, 1);
>>               break;
>>       case PCI_VENDOR_ID_TDI:
>>               if (pdev->device == PCI_DEVICE_ID_TDI_EHCI)
>>
>> I looked through the USB PCI initialization code, and I can't find any
>> place where interrupts are enabled, so I assume the PCI core is supposed
>> to enable interrupts?  Or is it assumed that the system boots with all
>> PCI device interrupts enabled?  In that case, is it a BIOS issue?
>
> As I recall, the original PCI spec did not include any way to enable or
> disable interrupts -- a rather surprising omission.  It was added
> later on.
>
> Anyhow, this is all handled in the PCI core.  The device driver
> shouldn't need to do much more than pci_enable_device() (which handles
> power plus I/O and memory resources) and pci_set_master() (which
> handles DMA).  Nothing about enabling interrupt generation.
>
> A quick search did not show any place where the PCI core explicitly
> enables interrupts on new devices, so maybe it does assume that the
> firmware always enables them.  I don't know what guarantees (if any) a
> BIOS is supposed to fulfill.
>
> It seems like the best place to fix this is probably in the PCI core.

I think dev->irq is supposed to be valid after pci_enable_device(), so
it seems like it would make sense to clear PCI_COMMAND_INTX_DISABLE
there.

I don't know why a BIOS would leave PCI_COMMAND_INTX_DISABLE set for
the EHCI device.  Does it support MSI, and the BIOS assumes the OS
should use that?  I don't see any MSI support in the EHCI code.  In
any case, this doesn't seem like something we need to depend on the
BIOS to do for us.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux