This patch series aims to refactor command processing to achieve following

- 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.

Changes in v2:
- Moved verbose packet prints after the command is finished to capture the successfull command response
- Fixed the debug prints
- PIO data will be moved with width matching the alignment of the block size. For majority of transfers that means UINT32 width.

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

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 soon 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 broken. I was only able to find one platform
that supported PIO. Detailed observation below

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

Platform2 (PIO is returning trash data - all 0xAF)
- Test code was able to perform async write(although it didn't realyl came 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)

Platform2 (again PIO is returning trash data)
- Test code scheduled 5 async writes. 2 writes finished and after that CPU exception was signaled.

Platform3(also trash data from PIO)
- Test code scheduled one async write as soon as it was done platform rebooted

I didn't want to spend any more time debugging this issue as I think it would turn into the platform debug and what I
observed gave me some confidence that PIO in async is generally working.

All tests were performed with eMMC in HS400 @200MHz clock frequency.

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_sdma
Whole series + PIO force code(test 4): https://github.com/malbecki/edk2/tree/emmc_transfer_refactor_force_pio

Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>

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

 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |   4 +
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   | 521 ++++++++++++++++-----
 2 files changed, 417 insertions(+), 108 deletions(-)

-- 
2.14.1.windows.1

--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#54643): https://edk2.groups.io/g/devel/message/54643
Mute This Topic: https://groups.io/mt/71399250/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

> -----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
> 
> This patch series aims to refactor command processing to achieve following
> 
> - 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.
> 
> Changes in v2:
> - Moved verbose packet prints after the command is finished to capture the
> successfull command response
> - Fixed the debug prints
> - PIO data will be moved with width matching the alignment of the block size.
> For majority of transfers that means UINT32 width.
> 
> 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
> 
> 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 soon
> 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 broken.
> I was only able to find one platform
> that supported PIO. Detailed observation below
> 
> 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
> 
> Platform2 (PIO is returning trash data - all 0xAF)
> - Test code was able to perform async write(although it didn't realyl came
> 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)
> 
> Platform2 (again PIO is returning trash data)
> - Test code scheduled 5 async writes. 2 writes finished and after that CPU
> exception was signaled.
> 
> Platform3(also trash data from PIO)
> - Test code scheduled one async write as soon as it was done platform
> rebooted
> 
> I didn't want to spend any more time debugging this issue as I think it would
> 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 announce
of the stable tag (2020-02-28). I will still give the 'Reviewed-by' after my
review of the series though.

Do you have concern for this?

Best Regards,
Hao Wu


> 
> All tests were performed with eMMC in HS400 @200MHz clock frequency.
> 
> 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
> 
> Cc: Hao A Wu <hao.a.wu@intel.com>
> Cc: Marcin Wojtas <mw@semihalf.com>
> Cc: Zhichao Gao <zhichao.gao@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> 
> 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
> 
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |   4 +
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   | 521
> ++++++++++++++++-----
>  2 files changed, 417 insertions(+), 108 deletions(-)
> 
> --
> 2.14.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#54656): https://edk2.groups.io/g/devel/message/54656
Mute This Topic: https://groups.io/mt/71399250/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Hi,

Github with test code: https://github.com/malbecki/edk2/tree/test_code_for_async

This test code was used as is on Platform2 and it worked if I have only scheduled one request. On platform 1 I had to rebuild it a couple of times to make it read instead of writing when testing after reboot.

Regarding the push - I am fine with this change making it to master after the stable tag.

Thanks,
Mateusz

> -----Original Message-----
> From: Wu, Hao A <hao.a.wu@intel.com>
> Sent: Thursday, February 20, 2020 1:40 AM
> To: Albecki, Mateusz <mateusz.albecki@intel.com>; devel@edk2.groups.io
> Cc: Marcin Wojtas <mw@semihalf.com>; Gao, Zhichao
> <zhichao.gao@intel.com>; Gao, Liming <liming.gao@intel.com>
> Subject: RE: [PATCHv2 0/4] MdeModulePkg/SdMmcPciHcDxe: Refactor
> command processing
> 
> > -----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
> >
> > This patch series aims to refactor command processing to achieve
> > following
> >
> > - 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.
> >
> > Changes in v2:
> > - Moved verbose packet prints after the command is finished to capture
> > the successfull command response
> > - Fixed the debug prints
> > - PIO data will be moved with width matching the alignment of the block
> size.
> > For majority of transfers that means UINT32 width.
> >
> > 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
> >
> > 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 soon 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 broken.
> > I was only able to find one platform
> > that supported PIO. Detailed observation below
> >
> > 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
> >
> > Platform2 (PIO is returning trash data - all 0xAF)
> > - Test code was able to perform async write(although it didn't realyl
> > came 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)
> >
> > Platform2 (again PIO is returning trash data)
> > - Test code scheduled 5 async writes. 2 writes finished and after that
> > CPU exception was signaled.
> >
> > Platform3(also trash data from PIO)
> > - Test code scheduled one async write as soon as it was done platform
> > rebooted
> >
> > I didn't want to spend any more time debugging this issue as I think
> > it would 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
> announce of the stable tag (2020-02-28). I will still give the 'Reviewed-by'
> after my review of the series though.
> 
> Do you have concern for this?
> 
> Best Regards,
> Hao Wu
> 
> 
> >
> > All tests were performed with eMMC in HS400 @200MHz clock frequency.
> >
> > 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
> >
> > Cc: Hao A Wu <hao.a.wu@intel.com>
> > Cc: Marcin Wojtas <mw@semihalf.com>
> > Cc: Zhichao Gao <zhichao.gao@intel.com>
> > Cc: Liming Gao <liming.gao@intel.com>
> >
> > 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
> >
> >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |   4 +
> >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   | 521
> > ++++++++++++++++-----
> >  2 files changed, 417 insertions(+), 108 deletions(-)
> >
> > --
> > 2.14.1.windows.1
> 

--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#54679): https://edk2.groups.io/g/devel/message/54679
Mute This Topic: https://groups.io/mt/71399250/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-