Hi Bjorn,
On Tue, Aug 27, 2019 at 12:25:47PM +0300, Mika Westerberg wrote:
> Here are the relevant parts from ICL. I'll send you the full dmesg as
> a separate email. The topology is such that I have 2 Titan Ridge devices
> connected in chain (each include PCIe switch + xHCI). I wait for the
> who
On Mon, Aug 26, 2019 at 05:05:02PM -0500, Bjorn Helgaas wrote:
> On Mon, Aug 26, 2019 at 05:42:42PM +0300, Mika Westerberg wrote:
> > On Mon, Aug 26, 2019 at 09:07:12AM -0500, Bjorn Helgaas wrote:
> > > On Mon, Aug 26, 2019 at 01:17:26PM +0300, Mika Westerberg wrote:
> > > > On Fri, Aug 23, 2019 at
On Mon, Aug 26, 2019 at 05:42:42PM +0300, Mika Westerberg wrote:
> On Mon, Aug 26, 2019 at 09:07:12AM -0500, Bjorn Helgaas wrote:
> > On Mon, Aug 26, 2019 at 01:17:26PM +0300, Mika Westerberg wrote:
> > > On Fri, Aug 23, 2019 at 09:12:54PM -0500, Bjorn Helgaas wrote:
> > > > But the "wait downstre
Am 26.08.19 um 16:42 schrieb Mika Westerberg:
> According to PCI FW 3.2 the OS is responsible for those delays if the
> platform firmware does not provide that _DSM. So simpler way would be
> always do the delays if the _DSM is not there.
Well, that is
* unless we trip over delays that make other
On Mon, Aug 26, 2019 at 09:07:12AM -0500, Bjorn Helgaas wrote:
> On Mon, Aug 26, 2019 at 01:17:26PM +0300, Mika Westerberg wrote:
> > On Fri, Aug 23, 2019 at 09:12:54PM -0500, Bjorn Helgaas wrote:
> > > Hi Mika,
> >
> > Hi,
> >
> > > I'm trying to figure out specifically why we need this and wher
On Mon, Aug 26, 2019 at 01:17:26PM +0300, Mika Westerberg wrote:
> On Fri, Aug 23, 2019 at 09:12:54PM -0500, Bjorn Helgaas wrote:
> > Hi Mika,
>
> Hi,
>
> > I'm trying to figure out specifically why we need this and where it
> > should go. Questions below.
>
> Thanks for looking at this.
>
> >
On Fri, Aug 23, 2019 at 09:12:54PM -0500, Bjorn Helgaas wrote:
> Hi Mika,
Hi,
> I'm trying to figure out specifically why we need this and where it
> should go. Questions below.
Thanks for looking at this.
> On Wed, Aug 21, 2019 at 03:45:19PM +0300, Mika Westerberg wrote:
> > Currently Linux d
Hi Mika,
I'm trying to figure out specifically why we need this and where it
should go. Questions below.
On Wed, Aug 21, 2019 at 03:45:19PM +0300, Mika Westerberg wrote:
> Currently Linux does not follow PCIe spec regarding the required delays
> after reset. A concrete example is a Thunderbolt a
On Thu, Aug 22, 2019 at 08:29:09PM +0200, Matthias Andree wrote:
> Am 21.08.19 um 14:45 schrieb Mika Westerberg:
> > Hi all,
> >
> > As the changelog says this is reworked version that tries to avoid reported
> > issues while at the same time fix the missing delays so we can get ICL
> > systems and
On Wednesday, August 21, 2019 2:45:19 PM CEST Mika Westerberg wrote:
> Currently Linux does not follow PCIe spec regarding the required delays
> after reset. A concrete example is a Thunderbolt add-in-card that
> consists of a PCIe switch and two PCIe endpoints:
>
> +-1b.0-[01-6b]00.0-[02-6b
Am 21.08.19 um 14:45 schrieb Mika Westerberg:
> Hi all,
>
> As the changelog says this is reworked version that tries to avoid reported
> issues while at the same time fix the missing delays so we can get ICL
> systems and at least the one system with Titan Ridge controller working
> properly.
>
>
Currently Linux does not follow PCIe spec regarding the required delays
after reset. A concrete example is a Thunderbolt add-in-card that
consists of a PCIe switch and two PCIe endpoints:
+-1b.0-[01-6b]00.0-[02-6b]--+-00.0-[03]00.0 TBT controller
+-01.0-
12 matches
Mail list logo
