Please, don't remove Cc list.
I'm discouraged to answer on personal mails related to open source.
+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?
>
> 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.
--
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Intel Finland Oy
--
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
