search for: mikas

On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote: > On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > > > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > > > <mika.westerberg at intel.com> wrote: > > > > > >

On Wed, Jul 22, 2020 at 11:25 AM Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > > On Tue, Jul 21, 2020 at 01:37:12PM -0500, Patrick Volkerding wrote: > > On 7/21/20 10:27 AM, Mika Westerberg wrote: > > > On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote: > > >> Sure thing. Also, feel free to let me know if you'd like access to one

...; last week or so I found systems where the GPU was under the "PCI > > > > Express Root Port" (name from lspci) and on those systems all of that > > > > seems to work. So I am wondering if it's indeed just the 0x1901 one, > > > > which also explains Mikas case that Thunderbolt stuff works as devices > > > > never get populated under this particular bridge controller, but under > > > > those "Root Port"s > > > > > > It always is a PCIe port, but its location within the SoC may matter. > > >...

On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst <kherbst at redhat.com> wrote: > > > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > > > <mika.westerberg

On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote: > > > On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg > > > <mika.westerberg at intel.com>

On Mon, Oct 21, 2019 at 02:00:46PM +0200, Karol Herbst wrote: > On Mon, Oct 21, 2019 at 1:40 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > Hi Karol, > > > > Sorry for commenting late, I just came back from vacation. > > > > On Wed, Oct 16, 2019 at 04:44:49PM +0200, Karol Herbst wrote: > > > Fixes state transitions of

...oot ports that are not > populated with NVidia GPUs. > last week or so I found systems where the GPU was under the "PCI Express Root Port" (name from lspci) and on those systems all of that seems to work. So I am wondering if it's indeed just the 0x1901 one, which also explains Mikas case that Thunderbolt stuff works as devices never get populated under this particular bridge controller, but under those "Root Port"s > Now, one thing is still not clear to me from the discussion so far: is > the _PR3 method you mentioned defined under the GPU device object or &gt...

...ems where the GPU was under the "PCI > > > > > > Express Root Port" (name from lspci) and on those systems all of that > > > > > > seems to work. So I am wondering if it's indeed just the 0x1901 one, > > > > > > which also explains Mikas case that Thunderbolt stuff works as devices > > > > > > never get populated under this particular bridge controller, but under > > > > > > those "Root Port"s > > > > > > > > > > It always is a PCIe port, but its location w...

Even if PR3 support is available on the bridge, it will not be used if the PCI layer considers it unavailable (i.e. on all laptops from 2013 and 2014). Ensure that this condition is checked to allow a fallback to the Optimus DSM for device poweroff. Initially I wanted to call pci_d3cold_enable before checking bridge_d3 (in case the user changed d3cold_allowed), but that is such an unlikely case

...PU was under the "PCI > > > > > > > Express Root Port" (name from lspci) and on those systems all of that > > > > > > > seems to work. So I am wondering if it's indeed just the 0x1901 one, > > > > > > > which also explains Mikas case that Thunderbolt stuff works as devices > > > > > > > never get populated under this particular bridge controller, but under > > > > > > > those "Root Port"s > > > > > > > > > > > > It always is a PCIe port...

?I am running Ubuntu 16.04. I am following this guide: https://wiki2.dovecot.org/HowTo/AntispamWithSieve. At the end when I try to compile the .sieve files, I get this error: sievec(root): Fatal: Plugin 'sieve_imapsieve' not found from directory /usr/lib/dovecot/modules/sieve.? Does anyone know about this? I have dovecot-sieve installed and I'm using Postfix and Spamassassin. --

...; > > > > > > > > Express Root Port" (name from lspci) and on those systems all of that > > > > > > > > > seems to work. So I am wondering if it's indeed just the 0x1901 one, > > > > > > > > > which also explains Mikas case that Thunderbolt stuff works as devices > > > > > > > > > never get populated under this particular bridge controller, but under > > > > > > > > > those "Root Port"s > > > > > > > > > > > > >...

Check whether the kernel really supports power resources for a device, otherwise the power might not be removed when the device is runtime suspended (DSM should still work in these cases where PR does not). This is a workaround for a problem where ACPICA and Windows 10 differ in behavior. ACPICA does not correctly enumerate power resources within a conditional block (due to delayed execution of

On Mon, Sep 30, 2019 at 10:05 AM Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > > Hi Karol, > > On Fri, Sep 27, 2019 at 11:53:48PM +0200, Karol Herbst wrote: > > > What exactly is the serious issue? I guess it's that the rescan > > > doesn't detect the GPU, which means it's not responding to config > > > accesses? Is there

On Tue, Oct 1, 2019 at 10:47 AM Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote: > > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg > > <mika.westerberg at linux.intel.com> wrote: > > > > > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote: > > > >

On Tue, Oct 1, 2019 at 11:11 AM Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > > On Tue, Oct 01, 2019 at 10:56:39AM +0200, Karol Herbst wrote: > > On Tue, Oct 1, 2019 at 10:47 AM Mika Westerberg > > <mika.westerberg at linux.intel.com> wrote: > > > > > > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote: > > > >

On Mon, Oct 21, 2019 at 04:49:09PM +0200, Karol Herbst wrote: > On Mon, Oct 21, 2019 at 4:09 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote: > > > > I really would like to provide you more information about such > > > > workaround but I'm not aware of any ;-) I have

...so I found systems where the GPU was under the "PCI > > > > > Express Root Port" (name from lspci) and on those systems all of that > > > > > seems to work. So I am wondering if it's indeed just the 0x1901 one, > > > > > which also explains Mikas case that Thunderbolt stuff works as devices > > > > > never get populated under this particular bridge controller, but under > > > > > those "Root Port"s > > > > > > > > It always is a PCIe port, but its location within the SoC may ma...

...opulated with NVidia GPUs. > > > > last week or so I found systems where the GPU was under the "PCI > Express Root Port" (name from lspci) and on those systems all of that > seems to work. So I am wondering if it's indeed just the 0x1901 one, > which also explains Mikas case that Thunderbolt stuff works as devices > never get populated under this particular bridge controller, but under > those "Root Port"s It always is a PCIe port, but its location within the SoC may matter. Also some custom AML-based power management is involved and that may be...

...; > > > > > > > > Express Root Port" (name from lspci) and on those systems all of that > > > > > > > > > seems to work. So I am wondering if it's indeed just the 0x1901 one, > > > > > > > > > which also explains Mikas case that Thunderbolt stuff works as devices > > > > > > > > > never get populated under this particular bridge controller, but under > > > > > > > > > those "Root Port"s > > > > > > > > > > > > >...