Use Device Tree to add the bcm2835-mmc device

[notro]

Move the dma and mmc devices to Device Tree.
This enables drivers to get DMA channels using Device Tree.

Tested on Pi1 B+ and Pi2 in both DT and non-DT mode.

[notro]

Error handling in the bcm2835-mmc probe function is broken.
It didn't seem to be an easy fix, so I haven't addressed it.
I'm just flagging the issue here in case someone wants to look at it.

[popcornmix]

Cool. I'll give it a test.
ping @pelwell

[pelwell]

Can you explain why this change is necessary (or why the old code is no longer necessary)?

[notro]

It's explained in the commit message.
I'm following up on this commit that came with 3.19: 9eba553
I guess this is the line that the message refers to: http://lxr.free-electrons.com/source/drivers/dma/dmaengine.c#L875

[popcornmix]

There is a slight gotcha with this. If you update the kernel without updating the dtb, you get a rather worrying file system check failed error on drop to a an emergency root console.

Not saying there is anything we can necessarily do about this, but I imagine I won't be the only user who does this so we might see users hitting this in the future.

[pelwell]

I have no objections. It is good to be moving closer to BCM2835, but it feels wrong having to ADD a platform device to bcm270x.c.

[notro]

There is a slight gotcha with this. If you update the kernel without updating the dtb, you get a rather worrying file system check failed error on drop to a an emergency root console.

I what situation would this happen? Not by using rpi-update?

[popcornmix]

rpi-update users should be safe.
People who build their own kernels or manually switch kernel versions by copying could run into this.
Not a critical issue, but something to be aware of.

[notro]

it feels wrong having to ADD a platform device to bcm270x.c

Hopefully it won't stay there very long 😄

[notro]

I have added .device_prep_slave_sg to bcm2835-dma.c which is working fine except that bcm2708_fb doesn't get it's dma channel and errors out (needs dma.c).

While doing this I discovered that the dmaengine driver always overwrites the dreq from DT with slave_id from config.
This did hide the fact that the dreq=5 I used in the DT node is wrong, it should be 11.
I will try to update this PR tomorrow.

-                       dmas = <&dma 5>,
-                              <&dma 5>;
+                       dmas = <&dma 11>,
+                              <&dma 11>;

                        /* Setup DREQ channel */
-                       c->dreq = c->cfg.slave_id;
+                       if (c->cfg.slave_id)
+                               c->dreq = c->cfg.slave_id;

A related question:
What's the purpose of arch/arm/mach-bcm2709/dmaer.c?
This one also uses dma.c

[pelwell]

It looks like user-mode access to DMA. It's a shame the squashing hides the history.

[popcornmix]

I believe this is complete history:
https://github.com/raspberrypi/linux/commits/rpi-3.10.y/arch/arm/mach-bcm2708/dmaer.c

It was used by Simon Hall in some experimental X acceleration code, and probably in his open source 3d driver competition entry. I don't believe it is currently in use.

In fact it was deleted from mach-bcm2708, so its presence in mach-bcm2709 is only accidental.

[notro]

That's good to hear.

[monroerl]

No this isn't just a problem for user built kernels. I'm using Kali 1.1 as a Pen Test and Forensic tool on the Pi 2 and can't get the Tiny3.5 TFT screen to work at all. I've asked Kali folks about it and they are puzzled as to what happened between the Pi B+ and the Pi 2. The Pi's were built fairly close together so why is aren't TFT's supported for most Nix brews? I'm dieing here. Please help.

[pelwell]

@monroerl What does your problem have to do with this Pull Request? Please find a more appropriate location.

[notro]

The problem with slave_id always being used also applies to the cyclic case:

bcm2835_dma_prep_dma_cyclic():

        /* Setup DREQ channel */
        if (c->cfg.slave_id != 0)
            control_block->info |=
                BCM2835_DMA_PER_MAP(c->cfg.slave_id);


bcm2835_dma_prep_slave_sg():

            c->dreq = c->cfg.slave_id; /* DREQ loaded from config */

So I propose to only use dreq in the prep_dma functions and add this to dma_slave_config:

bcm2835_dma_slave_config():

    if (c->cfg.slave_id)
        c->dreq = c->cfg.slave_id;

@popcornmix Do you have hardware to test i2s (uses cyclic dma) if I make this change?

[popcornmix]

Not sure what I2S devices use cyclic dma. I've only got audio cards that use I2S. Not sure if @pelwell has anything else?

[pelwell]

I'm pretty sure the audio devices use cyclic dma.

[notro]

@koalo submitted both the dmaengine driver and the i2s driver, and it sets slave_id in the probe function and calls snd_dmaengine_pcm_register(). So I guess any i2s audio device will do.
I tried enabling i2s, but it didn't call slave_config during probing at least. But the calls are hidden in the audio subsystem, so it might get called later during an enabling phase or something.
I really don't know neither the DMA subsystem nor the audio subsystem, so I'm on thin ice here.

Maybe I should just fix the slave_sg case which I can test?

[notro]

I have updated the PR:

• dreq in dts file set to 11
• fixed error handling
• honour dreq from DT

[notro]

I skipped dreq/slave_id and the cyclic dma case.
We'll just pick it up later if necessary. It probably won't be a problem before we have switched to bcm2835-dma.c anyway, and slave_id isn't used there.

[popcornmix]

Thanks. Changes look good, we'll accept for wider testing (e.g. this kernel is used in OpenELEC Milhouse nightly builds) and keep an eye out for any regression reports.