2010-08-16 17:48:09     Use of SD Host in non-DMA mode?

2010-08-16 17:48:09     Use of SD Host in non-DMA mode?

Scott Wagner (UNITED STATES)

Message: 92466   

Hello,

As many people have observed, the BF548 SD Host controller shares (well, actually fights for) DMA channel 22 with the NAND controller.  Thus it appears to be impossible within the current kernel to use NAND and SD simultaneously.

(It's not even really feasible to build both the SD and NAND subsystems as modules and swap between them.  I tried this, and the NAND subsystem does not unload cleanly - I get a kernel exception when unloading bf5xx_nand.ko.)

So, I have been considering creating a compile-time option in drivers/mmc/host/bfin_sdh.c which would discard SDH DMA and just use direct CPU access to the SD host controller FIFO.

    Has anyone tried this approach before?  Any pointers here?

    If this hasn't been done to date, does anyone see any obvious pitfalls or caveats in doing this (other than that it will not work well on Rev. 0 silicon - see   www.analog.com/static/imported-files/ic_anom/ADSP.BF542.BF544.BF547.BF548.BF549.RevH.01.29.09.pdf, issue 05000349)?

    Can anyone add any more info / encouragement / discouragement to this approach?

Thanks

Scott Wagner

QuoteReplyEditDelete

2010-08-16 20:55:58     Re: Use of SD Host in non-DMA mode?

Mike Frysinger (UNITED STATES)

Message: 92470   

the conflict has nothing to do with software.  it is purely a hardware limitation.  if you read the HRM, it's quite clear:

    • NFC/SDH (transmit and receive channels share one DMA channel)

    |  DMA22  |  DMAC1  |  0xA  |  SDH/NFC receive/transmit  |

    *2   NFC (NAND flash controller) and SDH (secure digital host) share a PMAP assignment on DMAC1. For more information on enabling the NFC, see “DMA Controller 1 Peripheral Multiplexer (DMAC1_PERIMUX) Register” on page 5-129.

nothing software does can change this.

the nand module unload issue has been fixed in svn already, so update your svn tree (branch and/or trunk)

a glance at the HRM indicates that P[olled]IO mode with the SDH might work, but we've never tried.  the NFC has a P[olled]IO mode driver already in u-boot, but not linux.  in either case, i dont think it'd be hard, but i'd be skeptical of performance (both with the peripheral and the system in general) since you cant use interrupts or dma.

anomaly 349 isnt a big deal considering we dont support bf54x-0.0 or bf54x-0.1 -- the DDR anomalies cannot be worked around.

QuoteReplyEditDelete

2010-08-17 08:37:10     Re: Use of SD Host in non-DMA mode?

Scott Wagner (UNITED STATES)

Message: 92506   

Hi Mike,

Thanks for your reply!

Sorry - I was somewhat unclear.  I understand (from reading the HRM) the shared nature of DMA 22 in hardware.  So, since my application relies primarily on NAND flash, but uses SD only sporadically, I would like to retain NFC usage of DMA, and "demote" SDH to PIO mode.  The intent of my question was to see if anyone had either tried PIO in linux with SDH, or knew of any particular roadblocks to doing so.

Your tip about the u-boot SDH PIO usage is very helpful - I'll look there.

Also useful to know that I don't have to worry about 05000349 - it was a concern when I was doing the initial research.

So, I guess I'll give the linux PIO SDH driver a try.  If I'm successful, I'll offer the patch back to the community.

Regards,

Scott Wagner

QuoteReplyEditDelete

2010-08-17 08:46:28     Re: Use of SD Host in non-DMA mode?

Mike Frysinger (UNITED STATES)

Message: 92509   

be aware that the SIC takes interrupts via the DMA controller (SDH -> DMA22 -> SIC).  so if the NFC has DMA22, i dont think any interrupts will fire from the SDH.  thus you probably need to have a polling system.  i havent verified this behavior; this is just my understanding of how things work.  perhaps though the dma perimux affects only data transfer while the interrupt lines are always hooked up ...

i said there was a NFC PIO driver in u-boot, not SDH.  we use DMA in u-boot with the SDH.

QuoteReplyEditDelete

2010-08-17 09:13:29     Re: Use of SD Host in non-DMA mode?

Scott Wagner (UNITED STATES)

Message: 92512   

Thanks for the clarification.  You're right - I misread the u-boot PIO support as being for SDH. Mia culpa.

I have really not researched this at all, so it may be a silly question ... but ... do you have any thoughts / reaction to the idea of using MDMA for reading / writing the SDH FIFO?

Thanks

Scott

QuoteReplyEditDelete

2010-08-17 09:23:00     Re: Use of SD Host in non-DMA mode?

Mike Frysinger (UNITED STATES)

Message: 92514   

my understanding of the DMAC is that MDMA channels (src/dst) are hard coded together.

i also believe the bus architecture is such that the MMRs live on the PAB, and the core is the only master of the PAB, so you cannot target MMR space with any DMAC.

QuoteReplyEditDelete

2010-08-17 09:48:05     Re: Use of SD Host in non-DMA mode?

Scott Wagner (UNITED STATES)

Message: 92515   

You're right, of course - the two halves of the MDMA are hard-wired together: the idea was to use them as a pair, and have one channel read / write the FIFO address.  Of course, the fact that the SDH registers are on the PAB and inaccessible to the MDMA channel is a show-stopper there.

I looked at the SDH interrupt mask register definition - it looks like the tx and rx FIFO watermark flags can generate an interrupt if bits 14 and 15 (respectively) of the interrupt mask register are set.  That is, these flags appear to be no different than, say, the CMD CRC fail or Data Timeout flags in the ability to generate an SDH interrupt.  I agree that the DMA channel 22 SDA/NFC interrupt (IRQ67) won't be triggered by the SDH under PIO mode, but SDH Mask 0 and SDH Mask 1 interrupts (IRQ 72 and IRQ 73, respectively) should still work - right?  So, I should still be able to do interrupt-driven IO and not be entirely polled, I think.

-Scott

QuoteReplyEditDelete

2010-08-17 09:58:00     Re: Use of SD Host in non-DMA mode?

Mike Frysinger (UNITED STATES)

Message: 92516   

yes, the SIC shows the SDH mask interrupts as being dedicated, so those should fire, so you're probably right that my dreary polled outlook isnt so dreary.

QuoteReplyEditDelete

2010-08-20 18:32:20     Re: Use of SD Host in non-DMA mode?

Scott Wagner (UNITED STATES)

Message: 92651   

For anyone who has been following this thread ... I was successful in modifying the code from a DMA to a PIO based sdh driver, BUT IT DOES NOT WORK RIGHT:

The SD Host engine expects to be able to read / write this FIFO at whatever speed it needs to communicate with the SD card.  When using DMA, the driver keeps up nicely.  However, when using PIO, which is slower, the SD Host overruns the FIFO on read and underruns it on write - so the whole scheme is unworkable.

Well, it was worth a try.  Sigh!

QuoteReplyEditDelete

2010-08-20 23:59:50     Re: Use of SD Host in non-DMA mode?

Mike Frysinger (UNITED STATES)

Message: 92652   

thanks for the update

if you really want SD, then doing MMC/SPI might be worth looking into

QuoteReplyEditDelete

2010-08-22 21:43:07     Re: Use of SD Host in non-DMA mode?

Cliff Cai (CHINA)

Message: 92673   

Hi Scott,

As an alternative,have you tried to make NAND work in PIO mode?I think it's much easier,since the PIO read/write functions are already included in the driver.

Thanks

Cliff

QuoteReplyEditDelete

2010-08-27 17:00:05     Re: Use of SD Host in non-DMA mode?

Scott Wagner (UNITED STATES)

Message: 92880   

I thought this through a bit, and realized that the lowest impact approach is to write a bit of multiplexing software protected by a mutex which disallows simultaneous access.  I experimented with this approach, and it works - except that I have encountered the NFC host DMA problem described by Barry Song, Mike Frysinger, and others at https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=6011.

[Here Barry concludes the discussion on 28 June 2010 by saying, 'Now handled by processor.support@analog.com, and the thread is "NFC hardware issue (SR#: 1016128)".]

So, I guess I have to abandon hope here and follow Cliff's suggestion to just use PIO with the NFC, at least until somebody fixes the NFC DMA issue.  It's not a problem with the mux idea itself - just that the NFC is broken in DMA mode I think.