2016-11-16 11:13 GMT+01:00 Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>:
> Please, don't remove Cc list.
> I'm discouraged to answer on personal mails related to open source.
Sorry, I just hit reply.
> +Cc [last time]: dmaengine@ mailinig list, Mika
>
> On Tue, 2016-11-15 at 22:03 +0100, Thomas Bohn wrote:
>> 2016-11-15 17:19 GMT+01:00 Andy Shevchenko <andriy.shevchenko@xxxxxxxx
>> tel.com>:
>> >
>> > idma64 itself can't be a culprit of such behaviour.
>> >
>> > The driver is loaded and bound whenever one of I2C, UART or SPI
>> > controllers is enumerated and have DMA capability enabled.
>> >
>> > So, if you check /proc/interrupt and see what is the counterpart for
>> > this DMA IP (some driver with .0 at the end) it would be helpful.
>>
>>
>
>> % cat /proc/interrupts | grep "\.0"
>> 16: 34623 3930 347041 35378 IR-IO-APIC
>> 16-fasteoi idma64.0, i801_smbus, i2c_designware.0
>
> Yes, it's the same as I have.
>
>> > Note D0 for the second one. It actually doesn't have any PM support
>> > at
>> > all.
>> >
>> > % lspci -vv -nk -s1f.4 | grep D[0-3]
>> > ...nothing...
>> >
>> > Can you try to run
>> >
>> > % echo 0000:00:1f.4 >
>> > /sys/bus/pci/devices/0000\:00\:1f.4/driver/unbind
>> >
>> > and see what happens?
>
> So, what is the result of the above?
Nothing. Except that the runtime power management for this driver was
module and powertop said it was "bad". Otherwise I didn't see any
change or even response in the log.
>
>>
>> This lead me to one udev rule I had for power management:
>>
>> ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"
>
>> but removing it and a reboot didn't change anything.
>
> Of course not, you disabled runtime PM for PCI meaning you put _all_
> devices always on.
I know but it was kinda the only visible result I could see.
Thomas
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
