Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bcm2708_fb: Add ARCH_BCM2835 support #970

Merged
merged 6 commits into from May 19, 2015
Merged

Conversation

notro
Copy link
Contributor

@notro notro commented May 18, 2015

Use bcm2708_fb on ARCH_BCM2835 instead of SIMPLE_FB.
Add DT node on MACH_BCM270x.
Remove mach/dma.h which is not needed anymore.

Tested on Pi1 and Pi2 regular kernel with and without DT + ARCH_BCM2835.

notro and others added 6 commits May 18, 2015 19:47
Add Device Tree support.
Pass the device to dma_alloc_coherent() in order to get the
correct bus address on ARCH_BCM2835.
Use the new DMA legacy API header file.
Including <mach/platform.h> is not necessary.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
This header file can be removed since there are no more users.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Add bcm2708-fb to Device Tree and don't add the
platform device when booting in DT mode.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
There exists a tiny MMU, configurable only by the VC (running the
closed firmware), which maps from the ARM's physical addresses to bus
addresses.  These bus addresses determine the caching behavior in the
VC's L1/L2 (note: separate from the ARM's L1/L2) according to the top
2 bits.  The bits in the bus address mean:

From the VideoCore processor:
0x0... L1 and L2 cache allocating and coherent
0x4... L1 non-allocating, but coherent. L2 allocating and coherent
0x8... L1 non-allocating, but coherent. L2 non-allocating, but coherent
0xc... SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or coherent

From the GPU peripherals (note: all peripherals bypass the L1
cache. The ARM will see this view once through the VC MMU):
0x0... Do not use
0x4... L1 non-allocating, and incoherent. L2 allocating and coherent.
0x8... L1 non-allocating, and incoherent. L2 non-allocating, but coherent
0xc... SDRAM alias. Cache is bypassed. Not L1 or L2 allocating or coherent

The 2835 firmware always configures the MMU to turn ARM physical
addresses with 0x0 top bits to 0x4, meaning present in L2 but
incoherent with L1.  However, any bus addresses we were generating in
the kernel to be passed to a device had 0x0 bits.  That would be a
reserved (possibly totally incoherent) value if sent to a GPU
peripheral like USB, or L1 allocating if sent to the VC (like a
firmware property request).  By setting dma-ranges, all of the devices
below it get a dev->dma_pfn_offset, so that dma_alloc_coherent() and
friends return addresses with 0x4 bits and avoid cache incoherency.

This matches the behavior in the downstream 2708 kernel (see
BUS_OFFSET in arch/arm/mach-bcm2708/include/mach/memory.h).

Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Cc: popcornmix@gmail.com
Add framebuffer device to Device Tree.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Enable the bcm2708 framebuffer driver.
Disable the simple framebuffer driver, which matches the
device handed over by u-boot.

Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
@popcornmix
Copy link
Collaborator

Looks okay to me. @pelwell ?

pelwell added a commit that referenced this pull request May 19, 2015
bcm2708_fb: Add ARCH_BCM2835 support
@pelwell pelwell merged commit 9112b62 into raspberrypi:rpi-4.0.y May 19, 2015
@notro notro deleted the fb branch May 19, 2015 09:19
@pelwell
Copy link
Contributor

pelwell commented May 19, 2015

Just a footnote: we should now consider Compute Module when making changes to the core devices. I missed enabling the MMC interface on CMs, and this change should probably have enabled the FB there as well. I've pushed patches correcting both of those.

@notro
Copy link
Contributor Author

notro commented May 19, 2015

Thanks, I will keep that in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants