From: Phil Edworthy <phil.edworthy@renesas.com> To: Marek Vasut <marek.vasut@gmail.com>, Bjorn Helgaas <helgaas@kernel.org>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, Marek Vasut <marek.vasut+renesas@gmail.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Simon Horman <horms+renesas@verge.net.au>, Wolfram Sang <wsa@the-dreams.de>, "linux-renesas-soc@vger.kernel.org" <linux-renesas-soc@vger.kernel.org> Subject: RE: [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling Date: Mon, 20 Aug 2018 13:44:48 +0000 [thread overview] Message-ID: <TY1PR01MB176994051783997958BAB14AF5320@TY1PR01MB1769.jpnprd01.prod.outlook.com> (raw) In-Reply-To: <9b91bbd9-64df-764e-e553-a37463549a92@gmail.com> Hello, Sorry for the delay. On 08 August 2018 14:30, Marek Vasut wrote: > On 07/25/2018 11:08 PM, Marek Vasut wrote: > > On 06/13/2018 07:25 PM, Bjorn Helgaas wrote: > >> On Wed, Jun 13, 2018 at 04:52:52PM +0100, Lorenzo Pieralisi wrote: > >>> On Wed, Jun 13, 2018 at 08:53:08AM -0500, Bjorn Helgaas wrote: > >>>> On Wed, Jun 13, 2018 at 01:54:51AM +0200, Marek Vasut wrote: > >>>>> On 06/11/2018 03:59 PM, Bjorn Helgaas wrote: > >>>>>> On Sun, Jun 10, 2018 at 03:57:10PM +0200, Marek Vasut wrote: > >>>>>>> On 11/17/2017 06:49 PM, Lorenzo Pieralisi wrote: > >>>>>>>> On Fri, Nov 10, 2017 at 10:58:42PM +0100, Marek Vasut wrote: > >>>>>>>>> From: Phil Edworthy <phil.edworthy@renesas.com> > >>>>>>>>> > >>>>>>>>> Most PCIe host controllers support L0s and L1 power states via > ASPM. > >>>>>>>>> The R-Car hardware only supports L0s, so when the system > >>>>>>>>> suspends and resumes we have to manually handle L1. > >>>>>>>>> When the system suspends, cards can put themselves into L1 > and > >>>>>>>>> send a > >>>>>>>> > >>>>>>>> I assumed L1 entry has to be negotiated depending upon the PCIe > >>>>>>>> hierarchy capabilities, I would appreciate if you can explain > >>>>>>>> to me what's the root cause of the issue please. > >>>>>>> > >>>>>>> You should probably ignore the suspend/resume part altogether. > >>>>>>> The issue here is that the cards can enter L1 state, while the > >>>>>>> controller won't do that automatically, it can only detect that the > link went into L1 state. > >>>>>>> If that happens,the driver must manually put the controller to L1 > state. > >>>>>>> The controller can transition out of L1 state automatically though. > >>>>>> > >>>>>> From earlier discussion I thought the R-Car root port did not > >>>>>> advertise L1 support. > >>>>> > >>>>> Which discussion ? This one or somewhere else ? > >>>> > >>>> > https://lkml.kernel.org/r/HK2PR0601MB1393D917D343E6363484CA68F5CB0 > @ > >>>> HK2PR0601MB1393.apcprd06.prod.outlook.com > >>>> > >>>> Re-reading that, I think I see my misunderstanding. I was only > >>>> considering L1 in the ASPM context. I didn't realize the L1 > >>>> implications of devices being in states other than D0. > >>>> > >>>> Obviously L1 support for ASPM is optional and advertised via Link > >>>> Capabilities. But per PCIe r4.0, sec 5.2, L1 support is required > >>>> for PCI-PM compatible power management, and is entered "whenever > >>>> all Functions ... are programmed to a D-state other than D0." > >>>> > >>>> So I guess this means *every* device is supposed to support L1 when > >>>> it is in a non-D0 power state. I think *this* is the case you're > >>>> solving. > >>>> > >>>> A little more of this detail, e.g., that this issue has nothing to > >>>> do with ASPM, it's probably an R-Car erratum that the RC can't > >>>> transition from L1 to L0, etc., in the changelog would really help > >>>> clear things up for me. > >>> > >>> I think that the issue is related to the L0->L1 transition upon > >>> system suspend (ie the kernel must force the controller into L1 when > >>> all devices are in a sleep state) and for this specific reason I > >>> still think that checking for a PM_Enter_L1 DLLP reception and doing > >>> the L0->L1 transition within a config access is wrong and prone to > >>> error (what's the rationale behind that ?), this ought to be done > >>> using PM methods in the host controller driver. > >> > >> But doesn't the problem happen whenever the link goes to L1, for any > >> reason? E.g., runtime power management might put an endpoint in D3 > >> even if we're not doing a whole system suspend. A user could even > >> force the endpoint to D3 by writing to PCI_PM_CTRL with "setpci". If > >> that's the case, I don't think the host controller PM methods will be > >> enough to work around the issue. > > > > I think so, it's the link that goes into L1 state and this can happen > > without any action from the controller side. > > > >> The comment in the patch ("If we are not in L1 link state and we have > >> received PM_ENTER_L1 DLLP, transition to L1 link state") suggests > >> that the R-Car host doesn't handle step 10 in PCIe r4.0, sec 5.3.2.1 > >> correctly, i.e., it doesn't complete the transition of the link to L1. > >> > >> Putting this workaround in the config accessor makes sense to me > >> because in this situation the endpoint thinks it's in L1 and it won't > >> receive TLPs for config accesses. Apparently forcing the RP to L1 > >> completes the L1 entry, and the RP correctly handles the "Exit from > >> L1 State" (sec 5.3.2.2) that's required when the RP needs to send a > >> TLP to the endpoint. That my understanding. > >> I think there's still a potential issue if the endpoint goes to a > >> non-D0 state, the link is stuck in this transitional state (endpoint > >> thinks it's L1, RP thinks it's L0), and the *endpoint* wants to exit > >> L1, e.g., so it can send a PME message for a wakeup. I don't know > >> what happens then. > > > > Is there some hardware which I can use to simulate this situation ? > > > >> If there were a real erratum writeup for this, it would probably > >> discuss this situation. > > > > I went through the latest errata sheet and don't see anything. The > > datasheet only mentions that L0/L0s/L1 is supported and L2 is not > supported. > > > Maybe Phil can comment on this too ? There is no errata for this that I know of. The rcar RP supports L0/L0s/L1 in hardware, but only supports L0s via ASPM, i.e. you need software to poke some registers to make the RP transition to L1. However, both before and after this patch, the RP does not transition L1 when the endpoints change to L1. This patch only transitions the RP to L1 during accessing a card's config registers, if the RP is not in L1 link state and has received PM_ENTER_L1 DLLP (e.g. resume). After this, the hardware will handle the transition out of L1. The relevant part of the rcar manual says: "After a recovery to L0, if the device is in the Non-D0 state and PM_Enter_L1 DLLP is transmitted from the downstream device, software should confirm that hardware is in the L0 state (PMSR.PMSTATE = L0) and initiate the L1 transition sequence again (write 1 to PMCTLR.L1IATN). In this case, the sequence is: L0 → L1 → L0 recovery → L1 again." I don’t think the potential issue that Bjorn talked about can happen because the RP does go into L1. I could be wrong though... The driver should also have a runtime-PM hook to transition to L1 on suspend in order to save power. However, that is somewhat separate to the problem the patch fixes. Phil
WARNING: multiple messages have this Message-ID (diff)
From: Phil Edworthy <phil.edworthy@renesas.com> To: Marek Vasut <marek.vasut@gmail.com>, Bjorn Helgaas <helgaas@kernel.org>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, Marek Vasut <marek.vasut+renesas@gmail.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Simon Horman <horms+renesas@verge.net.au>, Wolfram Sang <wsa@the-dreams.de>, "linux-renesas-soc@vger.kernel.org" <linux-renesas-soc@vger.kernel.org> Subject: RE: [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling Date: Mon, 20 Aug 2018 13:44:48 +0000 [thread overview] Message-ID: <TY1PR01MB176994051783997958BAB14AF5320@TY1PR01MB1769.jpnprd01.prod.outlook.com> (raw) In-Reply-To: <9b91bbd9-64df-764e-e553-a37463549a92@gmail.com> SGVsbG8sDQoNClNvcnJ5IGZvciB0aGUgZGVsYXkuDQoNCk9uIDA4IEF1Z3VzdCAyMDE4IDE0OjMw LCBNYXJlayBWYXN1dCB3cm90ZToNCj4gT24gMDcvMjUvMjAxOCAxMTowOCBQTSwgTWFyZWsgVmFz dXQgd3JvdGU6DQo+ID4gT24gMDYvMTMvMjAxOCAwNzoyNSBQTSwgQmpvcm4gSGVsZ2FhcyB3cm90 ZToNCj4gPj4gT24gV2VkLCBKdW4gMTMsIDIwMTggYXQgMDQ6NTI6NTJQTSArMDEwMCwgTG9yZW56 byBQaWVyYWxpc2kgd3JvdGU6DQo+ID4+PiBPbiBXZWQsIEp1biAxMywgMjAxOCBhdCAwODo1Mzow OEFNIC0wNTAwLCBCam9ybiBIZWxnYWFzIHdyb3RlOg0KPiA+Pj4+IE9uIFdlZCwgSnVuIDEzLCAy MDE4IGF0IDAxOjU0OjUxQU0gKzAyMDAsIE1hcmVrIFZhc3V0IHdyb3RlOg0KPiA+Pj4+PiBPbiAw Ni8xMS8yMDE4IDAzOjU5IFBNLCBCam9ybiBIZWxnYWFzIHdyb3RlOg0KPiA+Pj4+Pj4gT24gU3Vu LCBKdW4gMTAsIDIwMTggYXQgMDM6NTc6MTBQTSArMDIwMCwgTWFyZWsgVmFzdXQgd3JvdGU6DQo+ ID4+Pj4+Pj4gT24gMTEvMTcvMjAxNyAwNjo0OSBQTSwgTG9yZW56byBQaWVyYWxpc2kgd3JvdGU6 DQo+ID4+Pj4+Pj4+IE9uIEZyaSwgTm92IDEwLCAyMDE3IGF0IDEwOjU4OjQyUE0gKzAxMDAsIE1h cmVrIFZhc3V0IHdyb3RlOg0KPiA+Pj4+Pj4+Pj4gRnJvbTogUGhpbCBFZHdvcnRoeSA8cGhpbC5l ZHdvcnRoeUByZW5lc2FzLmNvbT4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBNb3N0IFBDSWUg aG9zdCBjb250cm9sbGVycyBzdXBwb3J0IEwwcyBhbmQgTDEgcG93ZXIgc3RhdGVzIHZpYQ0KPiBB U1BNLg0KPiA+Pj4+Pj4+Pj4gVGhlIFItQ2FyIGhhcmR3YXJlIG9ubHkgc3VwcG9ydHMgTDBzLCBz byB3aGVuIHRoZSBzeXN0ZW0NCj4gPj4+Pj4+Pj4+IHN1c3BlbmRzIGFuZCByZXN1bWVzIHdlIGhh dmUgdG8gbWFudWFsbHkgaGFuZGxlIEwxLg0KPiA+Pj4+Pj4+Pj4gV2hlbiB0aGUgc3lzdGVtIHN1 c3BlbmRzLCBjYXJkcyBjYW4gcHV0IHRoZW1zZWx2ZXMgaW50byBMMQ0KPiBhbmQNCj4gPj4+Pj4+ Pj4+IHNlbmQgYQ0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBJIGFzc3VtZWQgTDEgZW50cnkgaGFz IHRvIGJlIG5lZ290aWF0ZWQgZGVwZW5kaW5nIHVwb24gdGhlIFBDSWUNCj4gPj4+Pj4+Pj4gaGll cmFyY2h5IGNhcGFiaWxpdGllcywgSSB3b3VsZCBhcHByZWNpYXRlIGlmIHlvdSBjYW4gZXhwbGFp bg0KPiA+Pj4+Pj4+PiB0byBtZSB3aGF0J3MgdGhlIHJvb3QgY2F1c2Ugb2YgdGhlIGlzc3VlIHBs ZWFzZS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFlvdSBzaG91bGQgcHJvYmFibHkgaWdub3JlIHRo ZSBzdXNwZW5kL3Jlc3VtZSBwYXJ0IGFsdG9nZXRoZXIuDQo+ID4+Pj4+Pj4gVGhlIGlzc3VlIGhl cmUgaXMgdGhhdCB0aGUgY2FyZHMgY2FuIGVudGVyIEwxIHN0YXRlLCB3aGlsZSB0aGUNCj4gPj4+ Pj4+PiBjb250cm9sbGVyIHdvbid0IGRvIHRoYXQgYXV0b21hdGljYWxseSwgaXQgY2FuIG9ubHkg ZGV0ZWN0IHRoYXQgdGhlDQo+IGxpbmsgd2VudCBpbnRvIEwxIHN0YXRlLg0KPiA+Pj4+Pj4+IElm IHRoYXQgaGFwcGVucyx0aGUgZHJpdmVyIG11c3QgbWFudWFsbHkgcHV0IHRoZSBjb250cm9sbGVy IHRvIEwxDQo+IHN0YXRlLg0KPiA+Pj4+Pj4+IFRoZSBjb250cm9sbGVyIGNhbiB0cmFuc2l0aW9u IG91dCBvZiBMMSBzdGF0ZSBhdXRvbWF0aWNhbGx5IHRob3VnaC4NCj4gPj4+Pj4+DQo+ID4+Pj4+ PiBGcm9tIGVhcmxpZXIgZGlzY3Vzc2lvbiBJIHRob3VnaHQgdGhlIFItQ2FyIHJvb3QgcG9ydCBk aWQgbm90DQo+ID4+Pj4+PiBhZHZlcnRpc2UgTDEgc3VwcG9ydC4NCj4gPj4+Pj4NCj4gPj4+Pj4g V2hpY2ggZGlzY3Vzc2lvbiA/IFRoaXMgb25lIG9yIHNvbWV3aGVyZSBlbHNlID8NCj4gPj4+Pg0K PiA+Pj4+DQo+IGh0dHBzOi8vbGttbC5rZXJuZWwub3JnL3IvSEsyUFIwNjAxTUIxMzkzRDkxN0Qz NDNFNjM2MzQ4NENBNjhGNUNCMA0KPiBADQo+ID4+Pj4gSEsyUFIwNjAxTUIxMzkzLmFwY3ByZDA2 LnByb2Qub3V0bG9vay5jb20NCj4gPj4+Pg0KPiA+Pj4+IFJlLXJlYWRpbmcgdGhhdCwgSSB0aGlu ayBJIHNlZSBteSBtaXN1bmRlcnN0YW5kaW5nLiAgSSB3YXMgb25seQ0KPiA+Pj4+IGNvbnNpZGVy aW5nIEwxIGluIHRoZSBBU1BNIGNvbnRleHQuICBJIGRpZG4ndCByZWFsaXplIHRoZSBMMQ0KPiA+ Pj4+IGltcGxpY2F0aW9ucyBvZiBkZXZpY2VzIGJlaW5nIGluIHN0YXRlcyBvdGhlciB0aGFuIEQw Lg0KPiA+Pj4+DQo+ID4+Pj4gT2J2aW91c2x5IEwxIHN1cHBvcnQgZm9yIEFTUE0gaXMgb3B0aW9u YWwgYW5kIGFkdmVydGlzZWQgdmlhIExpbmsNCj4gPj4+PiBDYXBhYmlsaXRpZXMuICBCdXQgcGVy IFBDSWUgcjQuMCwgc2VjIDUuMiwgTDEgc3VwcG9ydCBpcyByZXF1aXJlZA0KPiA+Pj4+IGZvciBQ Q0ktUE0gY29tcGF0aWJsZSBwb3dlciBtYW5hZ2VtZW50LCBhbmQgaXMgZW50ZXJlZCAid2hlbmV2 ZXINCj4gPj4+PiBhbGwgRnVuY3Rpb25zIC4uLiBhcmUgcHJvZ3JhbW1lZCB0byBhIEQtc3RhdGUg b3RoZXIgdGhhbiBEMC4iDQo+ID4+Pj4NCj4gPj4+PiBTbyBJIGd1ZXNzIHRoaXMgbWVhbnMgKmV2 ZXJ5KiBkZXZpY2UgaXMgc3VwcG9zZWQgdG8gc3VwcG9ydCBMMSB3aGVuDQo+ID4+Pj4gaXQgaXMg aW4gYSBub24tRDAgcG93ZXIgc3RhdGUuICBJIHRoaW5rICp0aGlzKiBpcyB0aGUgY2FzZSB5b3Un cmUNCj4gPj4+PiBzb2x2aW5nLg0KPiA+Pj4+DQo+ID4+Pj4gQSBsaXR0bGUgbW9yZSBvZiB0aGlz IGRldGFpbCwgZS5nLiwgdGhhdCB0aGlzIGlzc3VlIGhhcyBub3RoaW5nIHRvDQo+ID4+Pj4gZG8g d2l0aCBBU1BNLCBpdCdzIHByb2JhYmx5IGFuIFItQ2FyIGVycmF0dW0gdGhhdCB0aGUgUkMgY2Fu J3QNCj4gPj4+PiB0cmFuc2l0aW9uIGZyb20gTDEgdG8gTDAsIGV0Yy4sIGluIHRoZSBjaGFuZ2Vs b2cgd291bGQgcmVhbGx5IGhlbHANCj4gPj4+PiBjbGVhciB0aGluZ3MgdXAgZm9yIG1lLg0KPiA+ Pj4NCj4gPj4+IEkgdGhpbmsgdGhhdCB0aGUgaXNzdWUgaXMgcmVsYXRlZCB0byB0aGUgTDAtPkwx IHRyYW5zaXRpb24gdXBvbg0KPiA+Pj4gc3lzdGVtIHN1c3BlbmQgKGllIHRoZSBrZXJuZWwgbXVz dCBmb3JjZSB0aGUgY29udHJvbGxlciBpbnRvIEwxIHdoZW4NCj4gPj4+IGFsbCBkZXZpY2VzIGFy ZSBpbiBhIHNsZWVwIHN0YXRlKSBhbmQgZm9yIHRoaXMgc3BlY2lmaWMgcmVhc29uIEkNCj4gPj4+ IHN0aWxsIHRoaW5rIHRoYXQgY2hlY2tpbmcgZm9yIGEgUE1fRW50ZXJfTDEgRExMUCByZWNlcHRp b24gYW5kIGRvaW5nDQo+ID4+PiB0aGUgTDAtPkwxIHRyYW5zaXRpb24gd2l0aGluIGEgY29uZmln IGFjY2VzcyBpcyB3cm9uZyBhbmQgcHJvbmUgdG8NCj4gPj4+IGVycm9yICh3aGF0J3MgdGhlIHJh dGlvbmFsZSBiZWhpbmQgdGhhdCA/KSwgdGhpcyBvdWdodCB0byBiZSBkb25lDQo+ID4+PiB1c2lu ZyBQTSBtZXRob2RzIGluIHRoZSBob3N0IGNvbnRyb2xsZXIgZHJpdmVyLg0KPiA+Pg0KPiA+PiBC dXQgZG9lc24ndCB0aGUgcHJvYmxlbSBoYXBwZW4gd2hlbmV2ZXIgdGhlIGxpbmsgZ29lcyB0byBM MSwgZm9yIGFueQ0KPiA+PiByZWFzb24/ICBFLmcuLCBydW50aW1lIHBvd2VyIG1hbmFnZW1lbnQg bWlnaHQgcHV0IGFuIGVuZHBvaW50IGluIEQzDQo+ID4+IGV2ZW4gaWYgd2UncmUgbm90IGRvaW5n IGEgd2hvbGUgc3lzdGVtIHN1c3BlbmQuICBBIHVzZXIgY291bGQgZXZlbg0KPiA+PiBmb3JjZSB0 aGUgZW5kcG9pbnQgdG8gRDMgYnkgd3JpdGluZyB0byBQQ0lfUE1fQ1RSTCB3aXRoICJzZXRwY2ki LiAgSWYNCj4gPj4gdGhhdCdzIHRoZSBjYXNlLCBJIGRvbid0IHRoaW5rIHRoZSBob3N0IGNvbnRy b2xsZXIgUE0gbWV0aG9kcyB3aWxsIGJlDQo+ID4+IGVub3VnaCB0byB3b3JrIGFyb3VuZCB0aGUg aXNzdWUuDQo+ID4NCj4gPiBJIHRoaW5rIHNvLCBpdCdzIHRoZSBsaW5rIHRoYXQgZ29lcyBpbnRv IEwxIHN0YXRlIGFuZCB0aGlzIGNhbiBoYXBwZW4NCj4gPiB3aXRob3V0IGFueSBhY3Rpb24gZnJv bSB0aGUgY29udHJvbGxlciBzaWRlLg0KPiA+DQo+ID4+IFRoZSBjb21tZW50IGluIHRoZSBwYXRj aCAoIklmIHdlIGFyZSBub3QgaW4gTDEgbGluayBzdGF0ZSBhbmQgd2UgaGF2ZQ0KPiA+PiByZWNl aXZlZCBQTV9FTlRFUl9MMSBETExQLCB0cmFuc2l0aW9uIHRvIEwxIGxpbmsgc3RhdGUiKSBzdWdn ZXN0cw0KPiA+PiB0aGF0IHRoZSBSLUNhciBob3N0IGRvZXNuJ3QgaGFuZGxlIHN0ZXAgMTAgaW4g UENJZSByNC4wLCBzZWMgNS4zLjIuMQ0KPiA+PiBjb3JyZWN0bHksIGkuZS4sIGl0IGRvZXNuJ3Qg Y29tcGxldGUgdGhlIHRyYW5zaXRpb24gb2YgdGhlIGxpbmsgdG8gTDEuDQo+ID4+DQo+ID4+IFB1 dHRpbmcgdGhpcyB3b3JrYXJvdW5kIGluIHRoZSBjb25maWcgYWNjZXNzb3IgbWFrZXMgc2Vuc2Ug dG8gbWUNCj4gPj4gYmVjYXVzZSBpbiB0aGlzIHNpdHVhdGlvbiB0aGUgZW5kcG9pbnQgdGhpbmtz IGl0J3MgaW4gTDEgYW5kIGl0IHdvbid0DQo+ID4+IHJlY2VpdmUgVExQcyBmb3IgY29uZmlnIGFj Y2Vzc2VzLiAgQXBwYXJlbnRseSBmb3JjaW5nIHRoZSBSUCB0byBMMQ0KPiA+PiBjb21wbGV0ZXMg dGhlIEwxIGVudHJ5LCBhbmQgdGhlIFJQIGNvcnJlY3RseSBoYW5kbGVzIHRoZSAiRXhpdCBmcm9t DQo+ID4+IEwxIFN0YXRlIiAoc2VjIDUuMy4yLjIpIHRoYXQncyByZXF1aXJlZCB3aGVuIHRoZSBS UCBuZWVkcyB0byBzZW5kIGENCj4gPj4gVExQIHRvIHRoZSBlbmRwb2ludC4NClRoYXQgbXkgdW5k ZXJzdGFuZGluZy4NCg0KPiA+PiBJIHRoaW5rIHRoZXJlJ3Mgc3RpbGwgYSBwb3RlbnRpYWwgaXNz dWUgaWYgdGhlIGVuZHBvaW50IGdvZXMgdG8gYQ0KPiA+PiBub24tRDAgc3RhdGUsIHRoZSBsaW5r IGlzIHN0dWNrIGluIHRoaXMgdHJhbnNpdGlvbmFsIHN0YXRlIChlbmRwb2ludA0KPiA+PiB0aGlu a3MgaXQncyBMMSwgUlAgdGhpbmtzIGl0J3MgTDApLCBhbmQgdGhlICplbmRwb2ludCogd2FudHMg dG8gZXhpdA0KPiA+PiBMMSwgZS5nLiwgc28gaXQgY2FuIHNlbmQgYSBQTUUgbWVzc2FnZSBmb3Ig YSB3YWtldXAuICBJIGRvbid0IGtub3cNCj4gPj4gd2hhdCBoYXBwZW5zIHRoZW4uDQo+ID4NCj4g PiBJcyB0aGVyZSBzb21lIGhhcmR3YXJlIHdoaWNoIEkgY2FuIHVzZSB0byBzaW11bGF0ZSB0aGlz IHNpdHVhdGlvbiA/DQo+ID4NCj4gPj4gSWYgdGhlcmUgd2VyZSBhIHJlYWwgZXJyYXR1bSB3cml0 ZXVwIGZvciB0aGlzLCBpdCB3b3VsZCBwcm9iYWJseQ0KPiA+PiBkaXNjdXNzIHRoaXMgc2l0dWF0 aW9uLg0KPiA+DQo+ID4gSSB3ZW50IHRocm91Z2ggdGhlIGxhdGVzdCBlcnJhdGEgc2hlZXQgYW5k IGRvbid0IHNlZSBhbnl0aGluZy4gVGhlDQo+ID4gZGF0YXNoZWV0IG9ubHkgbWVudGlvbnMgdGhh dCBMMC9MMHMvTDEgaXMgc3VwcG9ydGVkIGFuZCBMMiBpcyBub3QNCj4gc3VwcG9ydGVkLg0KPg0K PiA+IE1heWJlIFBoaWwgY2FuIGNvbW1lbnQgb24gdGhpcyB0b28gPw0KVGhlcmUgaXMgbm8gZXJy YXRhIGZvciB0aGlzIHRoYXQgSSBrbm93IG9mLg0KDQpUaGUgcmNhciBSUCBzdXBwb3J0cyBMMC9M MHMvTDEgaW4gaGFyZHdhcmUsIGJ1dCBvbmx5IHN1cHBvcnRzIEwwcyB2aWEgQVNQTSwNCmkuZS4g eW91IG5lZWQgc29mdHdhcmUgdG8gcG9rZSBzb21lIHJlZ2lzdGVycyB0byBtYWtlIHRoZSBSUCB0 cmFuc2l0aW9uIHRvIEwxLg0KDQpIb3dldmVyLCBib3RoIGJlZm9yZSBhbmQgYWZ0ZXIgdGhpcyBw YXRjaCwgdGhlIFJQIGRvZXMgbm90IHRyYW5zaXRpb24gTDENCndoZW4gdGhlIGVuZHBvaW50cyBj aGFuZ2UgdG8gTDEuDQpUaGlzIHBhdGNoIG9ubHkgdHJhbnNpdGlvbnMgdGhlIFJQIHRvIEwxIGR1 cmluZyBhY2Nlc3NpbmcgYSBjYXJkJ3MgY29uZmlnDQpyZWdpc3RlcnMsIGlmIHRoZSBSUCBpcyBu b3QgaW4gTDEgbGluayBzdGF0ZSBhbmQgaGFzIHJlY2VpdmVkIFBNX0VOVEVSX0wxIERMTFANCihl LmcuIHJlc3VtZSkuIEFmdGVyIHRoaXMsIHRoZSBoYXJkd2FyZSB3aWxsIGhhbmRsZSB0aGUgdHJh bnNpdGlvbiBvdXQgb2YgTDEuDQoNClRoZSByZWxldmFudCBwYXJ0IG9mIHRoZSByY2FyIG1hbnVh bCBzYXlzOg0KIkFmdGVyIGEgcmVjb3ZlcnkgdG8gTDAsIGlmIHRoZSBkZXZpY2UgaXMgaW4gdGhl IE5vbi1EMCBzdGF0ZSBhbmQgUE1fRW50ZXJfTDEgRExMUCBpcyB0cmFuc21pdHRlZCBmcm9tIHRo ZSBkb3duc3RyZWFtIGRldmljZSwgc29mdHdhcmUgc2hvdWxkIGNvbmZpcm0gdGhhdCBoYXJkd2Fy ZSBpcyBpbiB0aGUgTDAgc3RhdGUgKFBNU1IuUE1TVEFURSA9IEwwKSBhbmQgaW5pdGlhdGUgdGhl IEwxIHRyYW5zaXRpb24gc2VxdWVuY2UgYWdhaW4gKHdyaXRlIDEgdG8gUE1DVExSLkwxSUFUTiku IEluIHRoaXMgY2FzZSwgdGhlIHNlcXVlbmNlIGlzOiBMMCDihpIgTDEg4oaSIEwwIHJlY292ZXJ5 IOKGkiBMMSBhZ2Fpbi4iDQoNCkkgZG9u4oCZdCB0aGluayB0aGUgcG90ZW50aWFsIGlzc3VlIHRo YXQgQmpvcm4gdGFsa2VkIGFib3V0IGNhbiBoYXBwZW4NCmJlY2F1c2UgdGhlIFJQIGRvZXMgZ28g aW50byBMMS4gSSBjb3VsZCBiZSB3cm9uZyB0aG91Z2guLi4NCg0KVGhlIGRyaXZlciBzaG91bGQg YWxzbyBoYXZlIGEgcnVudGltZS1QTSBob29rIHRvIHRyYW5zaXRpb24gdG8gTDEgb24gDQpzdXNw ZW5kIGluIG9yZGVyIHRvIHNhdmUgcG93ZXIuIEhvd2V2ZXIsIHRoYXQgaXMgc29tZXdoYXQgc2Vw YXJhdGUNCnRvIHRoZSBwcm9ibGVtIHRoZSBwYXRjaCBmaXhlcy4NCg0KUGhpbA0K
next prev parent reply other threads:[~2018-08-20 17:00 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-10 21:58 [PATCH V2 0/5] PCI: rcar: Add suspend/resume support Marek Vasut 2017-11-10 21:58 ` [PATCH V2 1/5] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl() Marek Vasut 2017-11-13 7:03 ` Simon Horman 2017-11-10 21:58 ` [PATCH V2 2/5] PCI: rcar: Clean up the macros Marek Vasut 2017-11-13 7:03 ` Simon Horman 2017-11-13 18:11 ` Marek Vasut 2017-11-15 13:28 ` Simon Horman 2017-11-22 11:20 ` Marek Vasut 2017-11-10 21:58 ` [PATCH V2 3/5] PCI: rcar: Add the initialization of PCIe link in resume_noirq Marek Vasut 2017-11-13 7:05 ` Simon Horman 2017-11-10 21:58 ` [PATCH V2 4/5] PCI: rcar: Support runtime PM, link state L1 handling Marek Vasut 2017-11-13 7:05 ` Simon Horman 2017-11-17 17:49 ` Lorenzo Pieralisi 2018-06-10 13:57 ` Marek Vasut 2018-06-11 13:59 ` Bjorn Helgaas 2018-06-12 23:54 ` Marek Vasut 2018-06-13 13:53 ` Bjorn Helgaas 2018-06-13 15:52 ` Lorenzo Pieralisi 2018-06-13 17:25 ` Bjorn Helgaas 2018-06-14 11:43 ` Lorenzo Pieralisi 2018-07-25 21:08 ` Marek Vasut 2018-08-08 13:29 ` Marek Vasut 2018-08-20 13:44 ` Phil Edworthy [this message] 2018-08-20 13:44 ` Phil Edworthy 2018-08-20 14:47 ` Lorenzo Pieralisi 2018-08-21 8:58 ` Phil Edworthy 2018-08-21 8:58 ` Phil Edworthy 2018-08-21 15:32 ` Lorenzo Pieralisi 2018-08-22 9:20 ` Phil Edworthy 2018-08-22 9:20 ` Phil Edworthy 2018-08-14 16:25 ` Lorenzo Pieralisi 2017-11-10 21:58 ` [PATCH V2 5/5] PCI: rcar: Add the suspend/resume for pcie-rcar driver Marek Vasut 2017-11-15 13:27 ` Simon Horman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=TY1PR01MB176994051783997958BAB14AF5320@TY1PR01MB1769.jpnprd01.prod.outlook.com \ --to=phil.edworthy@renesas.com \ --cc=geert+renesas@glider.be \ --cc=helgaas@kernel.org \ --cc=horms+renesas@verge.net.au \ --cc=linux-pci@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=marek.vasut+renesas@gmail.com \ --cc=marek.vasut@gmail.com \ --cc=wsa@the-dreams.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.