Question about C6657 PCIe LTSSM_STATE

Hi 

We will likely need to work with design team on this as this information is not captured in the user guide.

Will need some time to get back to you on this.

Regards

Mukul

Hi Mukul,

Thank you for the reply.
The customer have no clue to fix this problem right now,
so that it's so helpful.

Okay, I will wait.

best regards,
g.f.

Hi g.f

On the question on LTSSM states HOT_RESET_ENTRY and HOT_RESET, the explanation is as follows:

 

The PCIe standard states that the EndPoint(EP) should transition to HOT_RESET state when it sees two consecutive TS1 ordered sets with hot reset bit set.

 In the hardware implementation, the controller will transition to HOT_RESET_ENTRY (0x1E) when the hot reset entry condition as described above is met. The EP will stay in the HOT_RESET_ENTRY state until a 2ms timer expires and them transition to the HOT_RESET (0x1F) state. The LTSSM will transition from HOT_RESET to PRE_DETECT_QUIET state once the reset goes away. 

Hope this helps.

Regards
Mukul 

Hi Mukul,

Thank you so much for the support.
I understood the transition of the LTSSM.

I will ask to my customer in what kind of state
LTSSM has changed after HOT_RESET_ENTRY.

By the way, after LTSSM state transit to PRE_DETECT_QUIET,
does PCIe module need to be re-initialized as following sequence?

1.Set PCIe module Power Domain to OFF state
2.Set PCIe module Power Domain to ON state
3.Re-initialize PCIe module

best regards,
g.f.

Hi Mukul,

My customer checked  the LTSSM state.
It never changed to HOT_RESET(0x1F) from HOT_RESET_ENTRY(0x1E).
Q1. What kind of factor can be considered?

Q2.Is there any problem to perform a re-setup of PCIe
in the state of HOT_RESET_ENTRY?

By the way, you said that after reset goes away he LTSSM will transition from HOT_RESET to PRE_DETECT_QUIET state.
Q3. If it passes for a definite period of time after PRE_DETECT_QUIET (0x05),
does it become DETECT_QUIET (0x00)?

best regards,
g.f.

G.F 

Can you give us a little more background on the failures your customer is facing?

Can you elaborate further on the PCIe-Host connection? Is this issue happening during power up / during boot up? Is customer using PCie boot mode?

Is this issue on some boards or they are seeing this on all boards? Is it possible to reproduce on the EVM?

Regards

Mukul 

Hi Mukul,

Thank you for the reply.

PCIe-Host connection is as following:
i.MX(PCI RC) - PCIe Switch - C6657(PCIe EP)

>Is this issue happening during power up / during boot up?
>Is customer using PCie boot mode?

Yes, this issue was happening during power up and also after bootup.
The C6657 doesn't detect Hot Reset.

They are not using PCIe boot mode but using SPI boot mode.

>Is this issue on some boards or they are seeing this on all boards?

They have 4 boards and this issue is happening on all 4 boards.

>Is it possible to reproduce on the EVM?

No, they can't reproduce on the EVM.

Now, the customer changed their system spec so as not issuing HotReset during power-up.
But they want to know how C6657 will detect the HOTRESET.
Because after the link between C6657 PCIe EP and RC was established,the RC might issue the HOTRESET.

At the customer board, LTSSM never changed to HOT_RESET from HOT_RESET_ENTRY
after RC issue the HOTRESET. After LTSSM transition to HOT_RESET_ENTRY,
it never change from HOT_RESET_ENTRY to other.
Which means C6657 never detect the HOTRESET from RC.

best regards,
g.f.

g.f

What software is being used by the customer. My limited understanding talking to some experts (more knowledgeable on DM816x device family) on this is that the SW has to still handle the HOT_RESET. The PCIe EP raises the PM interrupt when it receives a HOT_RESET from the RC.

So want to see if this could be an issue with software in use?

Regards

Mukul 

Hi Mukul,

Thank you for the response.

As far as I know, they are using following MCSDK source code for PCIe configuration.
C:\ti\mcsdk_2_01_01_04\tools\boot_loader\ibl\src\device\c665x\c665xinit.c
iblPCIeWorkaround()

What is PM interrupt? Is it PCIEXpress_PM_INT(Power Module Interrupt)?

best regards,
g.f.

g.f.,

Yes, PM interrupt is "49 PCIEXpress_PM_INT Power management interrupt" in C6657 data sheet, it is secondary input into CIC0.

I saw there are two methods in SW to handle this:

Method 1: SW configure a PCIEXpress_PM_INT interrupt, in ISR, PCIE link training is re-started

1. RC (NOT TI) starts HOT_RESET_ENTRY state
2. RC sends PCIE EP (TI 6657) TS1 ordered set to signal HOT_RESET
3. 6657 EP LTSSM transitions to HOT_RESET_ENTRY and raises PM interrupt
4. PM interrupt needs to be serviced by CPU and the EP needs to be reset to activate link training sequence

For interrupt, you can look at: http://processors.wiki.ti.com/index.php/Configuring_Interrupts_on_Keystone_Devices

For reset, I believe you disable CMD_STATUS register, LTSSM_EN bit (bit 0), then re-enable this bit should be OK. For more completeness, you might need to PSC off the PCIE module, PSC ON the PCIE module, then re-configure the PCIE. 

Method 2,

Without adding interrupt handler, in iblPCIeWorkaround() code, we have something like this:

while((DEVICE_REG32_R(PCIE_BASE_ADDR + PCIE_DEBUG0) & 0x11)!=0x11);    /* Wait for training to complete */

Without knowing whether/when RC is sending out HOT_RESET, you can change like below with a while loop:

- If link is not up, disable LTSSM_EN bit, then re-enable it

- wait for a few ms, check link again.

- if link is up, wait for sometime, check it again for a few times, to make sure it is stable, then break the while loop.

We had observed that when KSI EVM works with a PC. sometimes the link is not up. We simply re-enabled link training just once, it worked. 

Regards, Eric  

Hi Eric,

Thank you for the reply.

Method 2 requires polling process but the customer doesn't want to use polling.
Also they were asking me whether there are interrupt which is issued by HOTRESET.
Therefore, I will introduce Method1 to my customer.

best regards,
g.f.

Hi Eric,

Let me ask about PCIExpress_PM_INT.

I'm looking at the PCIe User's Guide(sprugs6d) page.61 Table 2-10 "PCIESS Interrupt Events".
Are PCIExpress_PM_INT and these interrupt related?

There are 4 "Power management and reset event interrupts" and three of them are for RC mode only.
"Power management turn-off message interrupt" is the only interrupt for EP mode.

Do we also need to enable this "Power management turn-off message interrupt"
to use the PCIExpress_PM_INT for detecting HOT reset from RC(Not TI)?

best regards,
g.f.

Yes, "PCIEXpress_PM_INT Power management interrupt" in CIC0 interrupt event input table is "Power management and reset event interrupts" in PCIE user guide, table 2-10.

My understanding the event number 13 in PCIESS is only used in ISR to EOI, that is, writing 13 into 0x2180_0050 (IRQ_EOI).

Regards, Eric