Re: [PATCH] PCI: Add quirk to clear MSI-X

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

 



When I say "BIOS" I mean collectively "all" of this firmware.

I don't understand the point you're making here.  I don't think it
matters whether this device-specific knowledge is in APU
microcontroller firmware, BIOS, Linux, etc.

I'm trying to suggest that if we zoom all the way in and look just at
the PCIe TLPs, we would see two config writes that put the device in
D3hot, then back in D0.  A working device should end up either back in
D0active with MSI-X fully enabled (if No_Soft_Reset is set and MSI-X
was originally enabled), or in D0uninitialized (if No_Soft_Reset is
clear).

But with this device, apparently some additional software intervention
is required, i.e., after the config write to go back to D0, we need
two more writes to clear and set the MSI-X enable bit.

My point is that's only needed if the hardware wasn't initialized correctly. If it's initialized properly then it behaves like you expect.


Let's say somebody runs coreboot on this platform.  Does coreboot need
this device-specific knowledge?


Yes; the exact same bug will happen with a coreboot implementation that had the initialization done improperly.


If we need device-specific code in BIOS or Linux, I'd say
that's a workaround.

Something I'd like to point out in case it wasn't apparent is Windows
doesn't actually hit this problem.  It doesn't matter if the correct
hardware initialization code is included in "BIOS" or not.

That's interesting because it means there's something we (I, at least)
don't understand about what's going on here.  Maybe Windows never puts
the device in D3hot at runtime?  Or maybe Windows disables MSI-X
before putting it into D3 and re-enables it after going to D0?  I
don't know how Windows power management works, so I'm not sure this
tells us anything useful about Linux.

Windows does put it into D3hot at runtime when nothing is plugged in, just like Linux does.

I believe you're right the difference is that Windows turns off MSI-X before putting it into D3 and re-enables it after going to D0. So this behavior doesn't happen there.

Basavaraj - can you please confirm that?



[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