On 23.07.19 12:16, Ralf Ramsauer wrote:
> 
> 
> On 7/11/19 1:07 AM, Ralf Ramsauer wrote:
>> On 7/10/19 7:22 PM, Jan Kiszka wrote:
>>> On 10.07.19 18:28, Ralf Ramsauer wrote:
>>>>
>>>> On 7/10/19 6:13 PM, Jan Kiszka wrote:
>>>>>> Ok, there's one chance left: According to lspci, the device actually
>>>>>> supports MSI. It's just not being used by Linux. Maybe I can somehow
>>>>>> convince Linux to switch to MSI.
>>>>> Latest kernel already?
>>
>> Latest kernel doesn't change anything.
>>
>>>>>
>>>>
>>>> I'm using the 4.19-rt jailhouse. Do you know of any relevant changes
>>>> upstream? Anyway, it's worth a try, let me test upstream...
>>>>
>>>> At least for 4.19, it looks like I'm not able to easily switch to MSI.
>>>> At the moment, I don't even understand why the kernel actually uses
>>>> legacy interrupts, while MSI cap is present. Something is odd there, I'd
>>>> expect that MSI is, if available, the perefered method. But even the
>>>> root-cell after boot won't enable MSI. Still investigating...
>>>>
>>>> I hope that I can switch to MSI with maybe a dirty hack, but I need more
>>>> time to dig through the kernel's PCI stack (PCI starts bugging me). You
>>>> can find things there you never wanted to know! :-)
>>>
>>> I suspect you are using some 8250 derivative with a similar driver:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=172c33cb61da0df5ccbdf1a8e736c8837d165a00
>>>
>>> Check your concrete driver for its interrupt allocation.
>>
>> Thanks for the pointer, this patch is really helpful and almost exactly
>> what I'm looking for. I want to test the required changes of the driver
>> on Linux without Jailhouse first, before I'm going to test it in a
>> non-root cell.
>>
>> My device uses the standard 8250_pci driver. So I hooked in there, and
>> tried the following hack:
>>
>>
>> diff --git a/drivers/tty/serial/8250/8250_pci.c
>> b/drivers/tty/serial/8250/8250_pci.c
>> index bbe5cba21522..55f8144ef3e0 100644
>> --- a/drivers/tty/serial/8250/8250_pci.c
>> +++ b/drivers/tty/serial/8250/8250_pci.c
>> @@ -3640,10 +3640,20 @@ pciserial_init_ports(struct pci_dev *dev, const
>> struct pciserial_board *board)
>>         priv->dev = dev;
>>         priv->quirk = quirk;
>>
>> +       pci_set_master(dev);
>> +
>> +       rc = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_ALL_TYPES);
>> +       if (rc < 0) {
>> +               kfree(priv);
>> +               priv = ERR_PTR(rc);
>> +               goto err_deinit;
>> +       }
>> +
>>         memset(&uart, 0, sizeof(uart));
>>         uart.port.flags = UPF_SKIP_TEST | UPF_BOOT_AUTOCONF | UPF_SHARE_IRQ;
>>         uart.port.uartclk = board->base_baud * 16;
>> -       uart.port.irq = get_pci_irq(dev, board);
>> +       uart.port.irq = pci_irq_vector(dev, 0);
>>         uart.port.dev = &dev->dev;
>>
>>         for (i = 0; i < nr_ports; i++) {
>>
>>
>> Luckily, probing succeeds. For the device, lspci reports:
>>
>> 01:00.0 Serial controller: Device 1c00:3253 (rev 10) (prog-if 05 [16850])
>> [...]
>>      Capabilities: [68] MSI: Enable+ Count=1/32 Maskable+ 64bit+
>>              Address: 00000000fee00438  Data: 0000
>>              Masking: ffffffff  Pending: 00000000
>>
>> Doesn't look bad so far. MSI is enabled and in use. And as soon as I
>> write to or read from the device (echo / cat), the MSI interrupt appears
>> in /proc/interrupts.
>>
>> But cat won't receive anything, and echo won't write anything. In fact,
>> echoing to the device stalls until I abort with ^C. In both cases, no
>> interrupts occur (according to /proc/interrupts).
>>
>> That would have been too easy.
> 
> Turns out it is that easy. Code above works perfect, but the serial
> card's MSI support seems to be broken. So I went for another PCIe serial
> card, and now it works fine.
> 
> Let me just advertise this product, in case someone else runs into the
> same issue. [1] comes with two serial lines -- one PCI function per
> line, which is pretty nice. Didn't try it yet, but it should be possible
> to assign ports to different cells. Yet, the kernel needs to be patched
> in order to enable MSI.

Would that patch target this particular card? Or a chipset that is different
from the one in the broken card? Then it might be worth pushing it upstream.

Jan

> 
>   Ralf
> 
> [1] https://www.amazon.de/gp/product/B0073LM0S4
> 
>>
>> Thanks
>>   Ralf
>>
>>>
>>> Jan
>>>
>>

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

-- 
You received this message because you are subscribed to the Google Groups 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jailhouse-dev/5ef2896d-0ee3-b93d-2049-4b6c3472cef0%40siemens.com.

Reply via email to