MOSI- SPI

[ravi]

Hello Octocontrabass

Thanks i will try it and let you know

ravi

[ravi]

It did not work, but IDMA64.c is similar to what i am trying to, the only difference is its using Link list methods and interrupts and i tryin to use the other simple method, register offesets are not same but bit position are same for EHL as far i checked,,, but does not matter i guess

there are only handful of registers but still somewhere i am missing the point.... working on it


manual reads and writes to SPI FIFO are timing consuming, it is taking lot of time to read a single the data from FIFO, if i switch to DMA with linked list , while DMA is dumping data from SPI FIFO to memory and vice-versa,, can CPU do other things involving memory in EHL??? or at least will it cut significant amount time?

Thanks
Ravi

[Octocontrabass]

while DMA is dumping data from SPI FIFO to memory and vice-versa,, can CPU do other things involving memory in EHL???

Yes.

or at least will it cut significant amount time?

SPI is very slow, so DMA will spend a lot of time paused waiting for the FIFO. You probably won't notice any difference.

[ravi]

Hello Octocontrabass

i am not able to get it working, in the mean-time i tried to setup PSE DMA also it also did not work( not sure what configure in maddress and all in the PSE and also not sure that PSE will be able to access memory from PCH, so still lot to know about PSE )

1) When i use the test register SSITR (0x0c) RDC #614109, when i set bit 5, controller should generate DMA transfer,, this also i am not able to see

coming to IDMA64.c

In function, idma64_chan_start, what is your thoughts on this
1) through out the file vdesc, what are these virtual desc, how will they help?
2) why CTL_HI should all be 1's(especially the "Done" bit)
3) RDC #614109, says DMA transfer is initiated when TFS bit SSSR is set, this bit will be set if we water mark the TxFIFO,,, i don't see this implementation in this file
4) is there any documentation available about how to use this driver(or an example you know of if anywhere this file is used), if i load linux (this would be my first experiments with linux on our board)

Thanks
Ravi

[Octocontrabass]

not sure that PSE will be able to access memory from PCH

PSE DMA only works with PSE SPI, the handshake interface isn't connected to PCH SPI.

1) When i use the test register SSITR (0x0c) RDC #614109, when i set bit 5, controller should generate DMA transfer,, this also i am not able to see

It sounds like DMA isn't configured properly. Setting bit 5 generates a request for DMA, but nothing will happen if the DMA controller isn't ready to respond to that request.

1) through out the file vdesc, what are these virtual desc, how will they help?

That's part of the Linux DMA API. It helps Linux drivers share common code.

2) why CTL_HI should all be 1's(especially the "Done" bit)

It isn't. Only BLOCK_TS is set to 0x1FFFF, the rest of CTL_HI is set to 0.

3) RDC #614109, says DMA transfer is initiated when TFS bit SSSR is set, this bit will be set if we water mark the TxFIFO,,, i don't see this implementation in this file

SPI FIFO thresholds are set by the PCH SPI driver. The code in idma64.c is shared by different PCH devices.

4) is there any documentation available about how to use this driver

The idma64 driver is automatically used for all PCH SPI communication. Here's some information on how to use SPI in Linux.

[ravi]

thanks

"PSE DMA only works with PSE SPI, the handshake interface isn't connected to PCH SPI.",, yes i tried to use PSE SPI, but i tried to DMA the data from the main memory(dumb thing ),, it appears that you can only communicate with PSE via HECI

--Ravi

[Octocontrabass]

i tried to DMA the data from the main memory(dumb thing )

Not dumb at all. PSE DMA always has access to main memory.

it appears that you can only communicate with PSE via HECI

PSE device ownership is controlled by your board's firmware. If your board's firmware grants ownership to the main CPU, you can use PSE SPI and PSE DMA without communicating via HECI.

[ravi]

Hello Octocontrabass

yes i have used PSE SPI controlled by host and used it successfully

can you please point me which document i missed to read for the below information
"
"PSE DMA always has access to main memory"", you can use PSE SPI and PSE DMA without communicating via HECI"
"

Thanks
Ravi

[Octocontrabass]

"PSE DMA always has access to main memory"

Datasheet volume 1 (636112), section 22.23.1: "DMA irrespective of PSE/IA ownership can copy data into main memory (DRAM)"

", you can use PSE SPI and PSE DMA without communicating via HECI"

I can't find the document right now, but the Linux drivers for PSE SPI and PSE DMA don't use HECI.

[ravi]

thanks

[ravi]

Hello Octocontrabass

Do have any suggestions on the following registers, i am not very clear what to set in them.

1) RDC-614110, 4.2.130 (IOSF_ADDR_FILLIN_DMA_CH0), how do get to know this

2) RDC-614110, 4.2.122 (DMA_CTL_CHo), i understand bit 0:1, but rest other like bits 11,10 i am not very clear

Thanks
Ravi

[Octocontrabass]

1) RDC-614110, 4.2.130 (IOSF_ADDR_FILLIN_DMA_CH0), how do get to know this

It's the 32 MSBs of the 64-bit source (read) address. If your source address is 32 bits, set this register to 0.

2) RDC-614110, 4.2.122 (DMA_CTL_CHo), i understand bit 0:1, but rest other like bits 11,10 i am not very clear

The rest of the bits can be 0.

IOSF_WR_VC01/IOSF_RD_VC01 (bit 11/10): PCIe Virtual Channel. If you haven't configured Virtual Channels, use VC0.

WR_NON_SNOOP/RD_NON_SNOOP (bit 9/8): PCIe No Snoop attribute. Use 0 for automatic cache coherency. If you use 1, you need to explicitly flush the cache for DMA.

WR_RS/RD_RS (bits 6-3): I'm not sure what a Root Space is. According to Datasheet volume 1 (636112) section 22.23.1.1 table 22-28, the x86 CPU is only allowed to use RS0.

[ravi]

Thsanks

[ravi]

"PSE DMA always has access to main memory"

Datasheet volume 1 (636112), section 22.23.1: "DMA irrespective of PSE/IA ownership can copy data into main memory (DRAM)"

If you see table 22-28 when DMA is host owned 2 possibilities Peripheral <-> DRAM and DRAM <-> DRAM, which i understand .....but while configuring DMA_CTL_CH0 (0x1000 offset, RDC-614110, 4.2.122 (DMA_CTL_CHo)) what should be chosen for bits 1:0?

[Octocontrabass]

Linux chooses SRAM for the peripheral. I didn't see an explanation in any of the documents I looked at, so I'm not sure if that's correct, but it seems to work for Linux.