From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Brodkin Subject: Re: [PATCH v2] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems Date: Thu, 22 Feb 2018 16:03:35 +0000 Message-ID: <1519315414.19466.9.camel@synopsys.com> References: <20180222133418.29336-1-Evgeniy.Didin@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Content-ID: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+gla-linux-snps-arc=m.gmane.org@lists.infradead.org To: "Evgeniy.Didin@synopsys.com" Cc: "ulf.hansson@linaro.org" , "Vineet.Gupta1@synopsys.com" , "Alexey.Brodkin@synopsys.com" , "linux-mmc@vger.kernel.org" , "dianders@chromium.org" , "stable@vger.kernel.org" , "jh80.chung@samsung.com" , "linux-snps-arc@lists.infradead.org" , "Eugeniy.Paltsev@synopsys.com" , "shawn.lin@rock-chips.com" List-Id: linux-mmc@vger.kernel.org Hi Shawn, On Thu, 2018-02-22 at 23:28 +0800, Shawn Lin wrote: [snip] > > > Stack Trace: > > > arc_unwind_core.constprop.1+0xd0/0xf4 > > > dump_stack+0x68/0x80 > > > warn_slowpath_null+0x4e/0xec > > > sg_miter_next+0x28/0x20c > > > dw_mci_read_data_pio+0x44/0x190 > > > dw_mmc f000a000.mmc: Unexpected interrupt latency > > I think we tested SD cards but the main reason we missed > this is that we don't use pio mode since dw_mmc decides > the transfer mode via HCON register but we don't have one > platform at hand then to do that. Given the data-transfer-over > interrupt should come after the data hit the RAM, so pio mode > could probably consume more time than IDMAC. That's really interesting. I was under impression that we use internal DMA controller (AKA IDMAC) on that platform (HSDK). This is what we typically see in bootlog (this extract is taken from 4.15-r9): --------------------------------->8-------------------------------- dw_mmc f000a000.mmc: 'num-slots' was deprecated. dw_mmc f000a000.mmc: IDMAC supports 32-bit address mode. dw_mmc f000a000.mmc: Using internal DMA controller. dw_mmc f000a000.mmc: Version ID is 290a dw_mmc f000a000.mmc: DW MMC controller at irq 12,32 bit host data width,16 deep fifo --------------------------------->8-------------------------------- I'm not really sure how PIO mode (which stands for non-DMA mode) got used given we have IDMAC in the hardware. @ Evgeniy, could you please check why IDMAC is not used? -Alexey From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey.Brodkin@synopsys.com (Alexey Brodkin) Date: Thu, 22 Feb 2018 16:03:35 +0000 Subject: [PATCH v2] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems In-Reply-To: References: <20180222133418.29336-1-Evgeniy.Didin@synopsys.com> List-ID: Message-ID: <1519315414.19466.9.camel@synopsys.com> To: linux-snps-arc@lists.infradead.org Hi Shawn, On Thu, 2018-02-22@23:28 +0800, Shawn Lin wrote: [snip] > > > Stack Trace: > > > arc_unwind_core.constprop.1+0xd0/0xf4 > > > dump_stack+0x68/0x80 > > > warn_slowpath_null+0x4e/0xec > > > sg_miter_next+0x28/0x20c > > > dw_mci_read_data_pio+0x44/0x190 > > > dw_mmc f000a000.mmc: Unexpected interrupt latency > > I think we tested SD cards but the main reason we missed > this is that we don't use pio mode since dw_mmc decides > the transfer mode via HCON register but we don't have one > platform at hand then to do that. Given the data-transfer-over > interrupt should come after the data hit the RAM, so pio mode > could probably consume more time than IDMAC. That's really interesting. I was under impression that we use internal DMA controller (AKA IDMAC) on that platform (HSDK). This is what we typically see in bootlog (this extract is taken from 4.15-r9): --------------------------------->8-------------------------------- dw_mmc f000a000.mmc: 'num-slots' was deprecated. dw_mmc f000a000.mmc: IDMAC supports 32-bit address mode. dw_mmc f000a000.mmc: Using internal DMA controller. dw_mmc f000a000.mmc: Version ID is 290a dw_mmc f000a000.mmc: DW MMC controller at irq 12,32 bit host data width,16 deep fifo --------------------------------->8-------------------------------- I'm not really sure how PIO mode (which stands for non-DMA mode) got used given we have IDMAC in the hardware. @ Evgeniy, could you please check why IDMAC is not used? -Alexey From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us01smtprelay-2.synopsys.com ([198.182.60.111]:41379 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933029AbeBVQDj (ORCPT ); Thu, 22 Feb 2018 11:03:39 -0500 From: Alexey Brodkin To: "Evgeniy.Didin@synopsys.com" CC: "jh80.chung@samsung.com" , "Alexey.Brodkin@synopsys.com" , "dianders@chromium.org" , "linux-mmc@vger.kernel.org" , "Vineet.Gupta1@synopsys.com" , "Eugeniy.Paltsev@synopsys.com" , "linux-snps-arc@lists.infradead.org" , "stable@vger.kernel.org" , "shawn.lin@rock-chips.com" , "ulf.hansson@linaro.org" Subject: Re: [PATCH v2] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems Date: Thu, 22 Feb 2018 16:03:35 +0000 Message-ID: <1519315414.19466.9.camel@synopsys.com> References: <20180222133418.29336-1-Evgeniy.Didin@synopsys.com> In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org List-ID: SGkgU2hhd24sDQoNCk9uIFRodSwgMjAxOC0wMi0yMiBhdCAyMzoyOCArMDgwMCwgU2hhd24gTGlu IHdyb3RlOg0KDQpbc25pcF0NCg0KPiA+ID4gU3RhY2sgVHJhY2U6DQo+ID4gPiAgYXJjX3Vud2lu ZF9jb3JlLmNvbnN0cHJvcC4xKzB4ZDAvMHhmNA0KPiA+ID4gIGR1bXBfc3RhY2srMHg2OC8weDgw DQo+ID4gPiAgd2Fybl9zbG93cGF0aF9udWxsKzB4NGUvMHhlYw0KPiA+ID4gIHNnX21pdGVyX25l eHQrMHgyOC8weDIwYw0KPiA+ID4gIGR3X21jaV9yZWFkX2RhdGFfcGlvKzB4NDQvMHgxOTANCj4g PiA+ICBkd19tbWMgZjAwMGEwMDAubW1jOiBVbmV4cGVjdGVkIGludGVycnVwdCBsYXRlbmN5DQo+ IA0KPiBJIHRoaW5rIHdlIHRlc3RlZCBTRCBjYXJkcyBidXQgdGhlIG1haW4gcmVhc29uIHdlIG1p c3NlZA0KPiB0aGlzIGlzIHRoYXQgd2UgZG9uJ3QgdXNlIHBpbyBtb2RlIHNpbmNlIGR3X21tYyBk ZWNpZGVzDQo+IHRoZSB0cmFuc2ZlciBtb2RlIHZpYSBIQ09OIHJlZ2lzdGVyIGJ1dCB3ZSBkb24n dCBoYXZlIG9uZQ0KPiBwbGF0Zm9ybSBhdCBoYW5kIHRoZW4gdG8gZG8gdGhhdC4gR2l2ZW4gdGhl IGRhdGEtdHJhbnNmZXItb3Zlcg0KPiBpbnRlcnJ1cHQgc2hvdWxkIGNvbWUgYWZ0ZXIgdGhlIGRh dGEgaGl0IHRoZSBSQU0sIHNvIHBpbyBtb2RlDQo+IGNvdWxkIHByb2JhYmx5IGNvbnN1bWUgbW9y ZSB0aW1lIHRoYW4gSURNQUMuDQoNClRoYXQncyByZWFsbHkgaW50ZXJlc3RpbmcuDQoNCkkgd2Fz IHVuZGVyIGltcHJlc3Npb24gdGhhdCB3ZSB1c2UgaW50ZXJuYWwgRE1BIGNvbnRyb2xsZXIgKEFL QSBJRE1BQykNCm9uIHRoYXQgcGxhdGZvcm0gKEhTREspLg0KDQpUaGlzIGlzIHdoYXQgd2UgdHlw aWNhbGx5IHNlZSBpbiBib290bG9nICh0aGlzIGV4dHJhY3QgaXMgdGFrZW4gZnJvbQ0KNC4xNS1y OSk6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpkd19tbWMgZjAwMGEwMDAubW1jOiAnbnVtLXNsb3RzJyB3YXMgZGVw cmVjYXRlZC4NCmR3X21tYyBmMDAwYTAwMC5tbWM6IElETUFDIHN1cHBvcnRzIDMyLWJpdCBhZGRy ZXNzIG1vZGUuDQpkd19tbWMgZjAwMGEwMDAubW1jOiBVc2luZyBpbnRlcm5hbCBETUEgY29udHJv bGxlci4NCmR3X21tYyBmMDAwYTAwMC5tbWM6IFZlcnNpb24gSUQgaXMgMjkwYQ0KZHdfbW1jIGYw MDBhMDAwLm1tYzogRFcgTU1DIGNvbnRyb2xsZXIgYXQgaXJxIDEyLDMyIGJpdCBob3N0IGRhdGEg d2lkdGgsMTYgZGVlcCBmaWZvDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkknbSBub3QgcmVhbGx5IHN1cmUgaG93 IFBJTyBtb2RlICh3aGljaCBzdGFuZHMgZm9yIG5vbi1ETUEgbW9kZSkgZ290IHVzZWQNCmdpdmVu IHdlIGhhdmUgSURNQUMgaW4gdGhlIGhhcmR3YXJlLg0KDQpAIEV2Z2VuaXksIGNvdWxkIHlvdSBw bGVhc2UgY2hlY2sgd2h5IElETUFDIGlzIG5vdCB1c2VkPw0KDQotQWxleGV5DQoNCg==