i.MX7D PCIe behavior of "Directed_Speed_Change" in "PCIE_PL_G2CR"

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX7D PCIe behavior of "Directed_Speed_Change" in "PCIE_PL_G2CR"

Jump to solution
2,195 Views
andreysmirnov
Contributor IV

Hello,

I am trying to understand the behavior of "Directed_Speed_Change" bit in "Gen2 Control Register (PCIE_PL_G2CR)" register (bit 17 and offset 0x700 + 0x10C) on i.MX7D. From reading the source code of PCIe driver in Freescale BSP (or mainline kernel) it appears that said bit is expected to be cleared by the hardware as a way of handshaking.

Experiments with i.MX6Q and i.MX7D variants of Sabre boards, though, show that when connected to a Gen 1 only peripheral (in my case external i210 PCIe card) i.MX6Q SoC will indeed clear said bit after it is written, where as i.MX7D SoC will not. Is that an expected behavior?

Tags (1)
0 Kudos
1 Solution
1,695 Views
richard_zhu
NXP Employee
NXP Employee

Hi Andrey:

I consulted with IC design team, the different behavior between iMX6Q PCIe and iMX7D PCIe maybe caused by the different controller version.

Regarding to the DOC description, the DIRECT_SPEED_CHANGE should be cleared after the speed change from GEN1 to GEN2. Unfortunately, when GEN1 device is used, the behavior is not documented.

So, IC design guys run the simulation and find out the following behaviors:

  1. DIRECT_SPEED_CHANGE will be cleared in 7D after speed change from GEN1 to GEN2. This matches doc’s description
  2. set MAX link speed(PCIE_CAP_TARGET_LINK_SPEED=0x01) as GEN1 and re-run the simulation, DIRECT_SPEED_CHANGE will not be cleared; remain as 1, this matches your result, but function test is passed, so this bit should not affect the normal PCIe function.

Richard

View solution in original post

3 Replies
1,695 Views
igorpadykov
NXP Employee
NXP Employee

Hi Andrey

this bit is Directed Speed Change. Writing "1" to this
field instructs the LTSSM to initiate a speed change to Gen2
or Gen3 after the link is initialized at Gen1 speed. When the
speed change occurs, the core will clear the contents of this
field; and a read to this field by your software will return a "0".
This is described in IP documentation on below link
https://www.synopsys.com/dw/ipdir.php?ds=dwc_pci_express_dm

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,695 Views
andreysmirnov
Contributor IV

Igor:

That does shed some light on the subject. Unforutuantely I can's seem to see anything but high-level marketing datasheets at the link you provided. Can you elaborate a bit more on "When the speed change occurs, the core will clear the contents of this field; and a read to this field by your software will return 0" as to what would happen if the speed change does not occur?

As I mentioned earlier what I am observing using Freescale BSP is that on i.MX6 the bit does and on i.MX7 does not get cleared by the hardware. If that is not expected behavior would you have any suggestion as to what might cause such behavior?

0 Kudos
1,696 Views
richard_zhu
NXP Employee
NXP Employee

Hi Andrey:

I consulted with IC design team, the different behavior between iMX6Q PCIe and iMX7D PCIe maybe caused by the different controller version.

Regarding to the DOC description, the DIRECT_SPEED_CHANGE should be cleared after the speed change from GEN1 to GEN2. Unfortunately, when GEN1 device is used, the behavior is not documented.

So, IC design guys run the simulation and find out the following behaviors:

  1. DIRECT_SPEED_CHANGE will be cleared in 7D after speed change from GEN1 to GEN2. This matches doc’s description
  2. set MAX link speed(PCIE_CAP_TARGET_LINK_SPEED=0x01) as GEN1 and re-run the simulation, DIRECT_SPEED_CHANGE will not be cleared; remain as 1, this matches your result, but function test is passed, so this bit should not affect the normal PCIe function.

Richard