From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mx.groups.io with SMTP id smtpd.web10.2779.1582159187716804498 for ; Wed, 19 Feb 2020 16:39:47 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.43, mailfrom: hao.a.wu@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2020 16:39:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,462,1574150400"; d="scan'208";a="436418239" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga006.fm.intel.com with ESMTP; 19 Feb 2020 16:39:47 -0800 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 19 Feb 2020 16:39:47 -0800 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 19 Feb 2020 16:39:46 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 19 Feb 2020 16:39:46 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.5]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.196]) with mapi id 14.03.0439.000; Thu, 20 Feb 2020 08:39:43 +0800 From: "Wu, Hao A" To: "Albecki, Mateusz" , "devel@edk2.groups.io" CC: Marcin Wojtas , "Gao, Zhichao" , "Gao, Liming" Subject: Re: [PATCHv2 0/4] MdeModulePkg/SdMmcPciHcDxe: Refactor command processing Thread-Topic: [PATCHv2 0/4] MdeModulePkg/SdMmcPciHcDxe: Refactor command processing Thread-Index: AQHV5z5ps+2WQNCy5UC4DQy/RjFaO6gjPDxQ Date: Thu, 20 Feb 2020 00:39:42 +0000 Message-ID: References: <20200219160508.5856-1-mateusz.albecki@intel.com> In-Reply-To: <20200219160508.5856-1-mateusz.albecki@intel.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: hao.a.wu@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Albecki, Mateusz > Sent: Thursday, February 20, 2020 12:05 AM > To: devel@edk2.groups.io > Cc: Albecki, Mateusz; Wu, Hao A; Marcin Wojtas; Gao, Zhichao; Gao, Liming > Subject: [PATCHv2 0/4] MdeModulePkg/SdMmcPciHcDxe: Refactor > command processing >=20 > This patch series aims to refactor command processing to achieve followin= g >=20 > - Trace the failing TRB packets to see what commands are failing and for > what reasons > - Get the response data even if data transfer timed out to allow easier > debugging > - Fix the PIO mode which is currently completely broken. >=20 > Changes in v2: > - Moved verbose packet prints after the command is finished to capture th= e > successfull command response > - Fixed the debug prints > - PIO data will be moved with width matching the alignment of the block s= ize. > For majority of transfers that means UINT32 width. >=20 > Tests performed: > - Each patch in the series has passed boot from eMMC with ADMAv3 data > transfer mode > - SDMA based boot has been tested with the full patch series > - PIO based boot has been tested with the full patch series > - PIO based data transfer has been additionally tested by creating and > modyfing a file in EFI shell > - Tested async PIO transfer - results below >=20 > Async test results: > I've tested a simple async write and then readback from the eMMMC device > using block IO v2. I have observed > that while the requests are processed correctly by the eMMC driver as soo= n > as they finish platform will sometimes > mibehave. I've tested async without my changes and the strange behavior > reproduces. Right now I am suspecting there > is some problem either in the EDK2 core that performs async or in the > platform specific code. It is also possible that > I coded the Async BlockIo incorrectly although the test code was rather > simple. Additionally I was able > to observe that on many eMMC controllers PIO based data transfer is broke= n. > I was only able to find one platform > that supported PIO. Detailed observation below >=20 > Platform 1 (PIO working). > - Test code was able to perform async write to eMMC LBA 0 > - As soon as the callback is called CPU exception happens > - After reboot test code was able to perform async read > - As soon as the callback is called CPU exception happens > - After reboot sync read was able to confirm that data matches what was > written by async write >=20 > Platform2 (PIO is returning trash data - all 0xAF) > - Test code was able to perform async write(although it didn't realyl cam= e > through to the device) > - After write finished test code was able to perform async read(again all= data > was 0xAF but the logic in the driver works) >=20 > Platform2 (again PIO is returning trash data) > - Test code scheduled 5 async writes. 2 writes finished and after that CP= U > exception was signaled. >=20 > Platform3(also trash data from PIO) > - Test code scheduled one async write as soon as it was done platform > rebooted >=20 > I didn't want to spend any more time debugging this issue as I think it w= ould > turn into the platform debug and what I > observed gave me some confidence that PIO in async is generally working. Hello Mateusz, Could you help to share your async test codes? I can help to double confirm whether the issue you observed is related with them or not. Also, since edk2 repo is under soft freeze period for the next stable tag, = I would prefer for the series to get into the code base after the formal anno= unce of the stable tag (2020-02-28). I will still give the 'Reviewed-by' after m= y review of the series though. Do you have concern for this? Best Regards, Hao Wu >=20 > All tests were performed with eMMC in HS400 @200MHz clock frequency. >=20 > For easier review & integration patch has been pushed here: > Whole series: > https://github.com/malbecki/edk2/tree/emmc_transfer_refactor > Whole series + SDMA force code(test 3): > https://github.com/malbecki/edk2/tree/emmc_transfer_refactor_force_sd > ma > Whole series + PIO force code(test 4): > https://github.com/malbecki/edk2/tree/emmc_transfer_refactor_force_pio >=20 > Cc: Hao A Wu > Cc: Marcin Wojtas > Cc: Zhichao Gao > Cc: Liming Gao >=20 > Mateusz Albecki (4): > MdeModulePkg/SdMmcPciHcDxe: Enhance driver traces > MdeModulePkg/SdMmcPciHcDxe: Read response on command completion > MdeModulePkg/SdMmcPciHcDxe: Refactor data transfer completion > MdeModulePkg/SdMmcPciHcDxe: Fix PIO transfer mode >=20 > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 4 + > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 521 > ++++++++++++++++----- > 2 files changed, 417 insertions(+), 108 deletions(-) >=20 > -- > 2.14.1.windows.1