Re: State of Linux graphics

[Eric Anholt]

On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
 I've written an article that surveys the current State of Linux
 graphics and proposes a possible path forward. This is a long article
 containing a lot of detailed technical information as a guide to
 future developers. Skip over the detailed parts if they aren't
 relevant to your area of work.
 
 http://www.freedesktop.org/~jonsmirl/graphics.html
 
 Topics include the current X server, framebuffer, Xgl, graphics
 drivers, multiuser support, using the GPU, and a new server design.
 Hopefully it will help you fill in the pieces and build an overall
 picture of the graphics landscape.
 
 The article has been reviewed but if it still contains technical
 errors please let me know. Opinions on the content are also
 appreciated.

EXA extends the XAA driver concept to use the 3D hardware to accelerate
the X Render extension.  No, EXA is a different acceleration
architecture making different basic design decisions related to memory
management and driver API.

If the old hardware is missing the hardware needed to accelerate render
there is nothing EXA can do to help.  Better memory management allows
for better performance with composite due to improved placement of
pixmaps, which XAA doesn't do.  So EXA can help.

So it ends up that the hardware EXA works on is the same hardware we
already had existing OpenGL drivers for.  No.  See, for example, the nv
or i128 driver ports, both completed in very short timeframes.

The EXA driver programs the 3D hardware from the 2D XAA driver adding
yet another conflicting user to the long line of programs all trying to
use the video hardware at the same time.  No, EXA is not an addition to
XAA, it's a replacement.  It's not yet another conflicting user on
your machine (and I have yet to actually see this purported conflict in
my usage of either acceleration architecture).

There is also a danger that EXA will keep expanding to expose more of
the chip’s 3D capabilities.  If people put effort into this because
they see value in it, without breaking other people's code, why is this
a danger?

-- 
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/  [EMAIL PROTECTED]


signature.asc
Description: This is a digitally signed message part

Re: [RFC] [PATCH] DRM TTM Memory Manager patch

[Eric Anholt]

:
lock_hardware()
map(backbuffer)
map(frontbuffer)
map(vertices)
map(some_buffer)
rendering with cpu
unmaps(...)
unlock_hardware()

Note: map blocks on fencing, and if you don't pass the magic
while-validated flag, then validate blocks on unmap.

If we've got GL buffer objects shared between clients, we've got easy
deadlocks available:

client A map buffer 1
client B locks
client B validates buffer 2
client A map buffer 2 (block)
client B validates buffer 1 (block)

I'm not sure to what extent GL allows buffer object sharing, but with
EXT_tfp we're going to need to be dealing with this for the
X Server versus GL interactions.

5) Fixing locking by not doing it
So, it looks like the existing hardware lock isn't cutting it for
avoiding deadlocks.  Additionally, we'd like to get to a point where I
can have some random app running things on my graphics card with my GUI
server clueless that it's happening (more access control would be
needed, but allowing lock pushdown is the main design issue here, I
think).  That pretty much means having a hardware lock that an app can
hold for an arbitrary amount of time has to go away.

Since we've got the lock_hardware() around any series of validates for
rendering, we've been thinking about pushing that whole series of
operations into one device-specific (probably?) ioctl:

submit_buffers(buffer_list, relocation_list, bool full_state)

There's a comment suggesting that this is a good idea on
intel_batchbuffers already.  This submit_buffers would do:

choose offsets to validate into
perform relocations
validate the buffers with the given flags
emit flush if indicated
emit the fence

For multi-context hardware, the kernel then gets to choose which
rendering context this batchbuffer will be run on.  If it can't give you
a context with the same state, it returns EBUSY or whatever and you
resubmit with full state upload and the flag saying so.  Additionally,
the kernel can then do reasonable simulation of multi-context hardware
on hardware with context save/restore, which we haven't been doing
before.

Also, since the kernel has all the buffers needed for validate at once,
it can be smarter about placing the allocations, as right now you could
possibly get aperture fragmentation from early validates which prevent
later buffer validations from succeeding.

With this and removing what appears to be an unnecessary hardware lock
from the texture write, we've got userland locking out of the hardware
rendering path, we've got a nice system for multi-context hardware and
the ability for the kernel to simulate multiple contexts if not, and we
can remove most of the userland interface, getting us down to:

bo_create
bo_map
bo_unmap
bo_ref
bo_unref
submit_buffers
fence_reference
fence_unreference
fence_wait

That's a lot less than 25 entrypoints, and I like that.  Plus, with this
and the DRM modesetting work, adding access control and batchbuffer
validation is all that's needed to get the kernel scheduling arbitrary
programs doing random things on the card with your gui unaware of it.

But this still leaves the map versus validate deadlocks.  The
closest we've come up with to a solution is: Maps never block on maps,
validate blocks on unmap, and map blocks on (write-flushed if necessary)
fence completion.  It is up to threads performing submit_buffers and
maps on shared objects to arrange external synchronization to avoid
deadlock.  This has the advantage that those threads likely have some
sort of protocol requirements for rendering consistency between those
objects, and are going to be doing some sort of synchronization anyway.
I'm just not sure yet on how feasible it is to bend GL into this model.

-- 
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] PM / Domains: If an OF node is found but no device probed yet, defer.

[Eric Anholt]

Ulf Hansson ulf.hans...@linaro.org writes:

 On 13 March 2015 at 19:01, Kevin Hilman khil...@kernel.org wrote:
 Geert Uytterhoeven ge...@linux-m68k.org writes:

 On Wed, Mar 11, 2015 at 11:08 PM, Rafael J. Wysocki r...@rjwysocki.net 
 wrote:
 More CCes.

 On Wednesday, March 11, 2015 08:27:28 AM Eric Anholt wrote:
 If we've declared a power domain in the OF, and the OF node is found
 but the requested domain hasn't been registered on it yet, then we
 probably have just tried to probe before the power domain driver has.
 Defer our device's probe until it shows up.

 Signed-off-by: Eric Anholt e...@anholt.net

 Kevin, Ulf, any chance to have a look at this, please?

 ---

 I ran into this when turning my ad-hoc code for BCM2835 (Raspberry Pi)
 USB poweron support in the DWC2 controller to an OF-based power domain
 declaration.

 I guess you are initializing the PM domains from module_init()?

 I use core_initcall() in arch/arm/mach-shmobile/pm-rmobile.c to make sure 
 it's
 initialized earlier, as e.g. the interrupt controller uses 
 postcore_initcall().

 Yeah, I think most existing users are initizling PM domains early, but IMO
 we should be working towards supporting PM domains that are created
 later as well (as this patch does.)

 I do agree, that we _should_ allow PM domains to be created later/any
 time. Unfortunate, that's not going to be a simple one-liner patch.
 :-)

 To have genpd_dev_pm_attach() return -EPROBE_DEFER, due to that the PM
 domain hasn’t been _initialized_ yet, we need to know whether a PM
 domain exists at all for the device. In principle we need to split the
 work done by genpd_dev_pm_attach() into the two parts described below.

 1.
 At struct device creation time, done from the OF core, we also need
 to parse for a PM domain node. If such is found, we somehow needs to
 assigned it to the device.

 Normally we would have assigned the struct dev_pm_domain in the struct
 device to deal with this, but that has some implications. Currently
 the struct dev_pm_domain is created from SoC specific code and it's
 also done at different init levels.

I haven't made sense of what's actually proposed here, so I'm not
stepping forward to write this.  I think I'd be less confused if the
struct device references in the explanation made it clear which ones
were the pm domain controller and which were the pm domain consumer.


signature.asc
Description: PGP signature

[PATCH] PM / Domains: If an OF node is found but no device probed yet, defer.

[Eric Anholt]

If we've declared a power domain in the OF, and the OF node is found
but the requested domain hasn't been registered on it yet, then we
probably have just tried to probe before the power domain driver has.
Defer our device's probe until it shows up.

Signed-off-by: Eric Anholt e...@anholt.net
---

I ran into this when turning my ad-hoc code for BCM2835 (Raspberry Pi)
USB poweron support in the DWC2 controller to an OF-based power domain
declaration.

drivers/base/power/domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index ba4abbe..2b93c98 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2064,7 +2064,7 @@ EXPORT_SYMBOL_GPL(of_genpd_del_provider);
 struct generic_pm_domain *of_genpd_get_from_provider(
struct of_phandle_args *genpdspec)
 {
-   struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
+   struct generic_pm_domain *genpd = ERR_PTR(-EPROBE_DEFER);
struct of_genpd_provider *provider;
 
mutex_lock(of_genpd_mutex);
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / Domains: If an OF node is found but no device probed yet, defer.

[Eric Anholt]

Geert Uytterhoeven ge...@linux-m68k.org writes:

 On Wed, Mar 11, 2015 at 11:08 PM, Rafael J. Wysocki r...@rjwysocki.net 
 wrote:
 More CCes.

 On Wednesday, March 11, 2015 08:27:28 AM Eric Anholt wrote:
 If we've declared a power domain in the OF, and the OF node is found
 but the requested domain hasn't been registered on it yet, then we
 probably have just tried to probe before the power domain driver has.
 Defer our device's probe until it shows up.

 Signed-off-by: Eric Anholt e...@anholt.net

 Kevin, Ulf, any chance to have a look at this, please?

 ---

 I ran into this when turning my ad-hoc code for BCM2835 (Raspberry Pi)
 USB poweron support in the DWC2 controller to an OF-based power domain
 declaration.

 I guess you are initializing the PM domains from module_init()?

 I use core_initcall() in arch/arm/mach-shmobile/pm-rmobile.c to make sure it's
 initialized earlier, as e.g. the interrupt controller uses 
 postcore_initcall().

Yeah, it's just going through normal DT-based module initialization as a
module_platform_driver().  And it depends on another platform driver
(the mailbox to talk to the firmware in the first place), so it's
unlikely to show up early.

The BCM2835 architecture maintainers don't appear to be fans of fixed
init sequence stuff (our sequence is just bcm2835_setup_restart(),
bcm2835_init_clocks(), of_platform_populate()), and I figured
dependencies expressed in DT were supposed to be the ideal way for
things these days.  I can try turning my drivers into fixed init
sequence code, but I don't expect this to go over well.

 drivers/base/power/domain.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
 index ba4abbe..2b93c98 100644
 --- a/drivers/base/power/domain.c
 +++ b/drivers/base/power/domain.c
 @@ -2064,7 +2064,7 @@ EXPORT_SYMBOL_GPL(of_genpd_del_provider);
  struct generic_pm_domain *of_genpd_get_from_provider(
   struct of_phandle_args *genpdspec)
  {
 - struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
 + struct generic_pm_domain *genpd = ERR_PTR(-EPROBE_DEFER);

 Currently platform_drv_probe() just continues if dev_pm_domain_attach() 
 returns
 a different error than -EPROBE_DEFER, which is what you are seeing.

 Your change does have the side effect that a new DT with PM domains won't
 work on an older kernel that doesn't have the PM domain driver yet.

 Whether this is a good or a bad thing depends on your bootloader. If all PM
 domains are powered when Linux boots, it can work without PM domain driver.
 Since DT PM domains are quite recent, I guess this is the case for most
 existing SoCs.

The main bootloader doesn't turn on these domains, thus why I wrote a
driver for it (so I could get USB and thus netowrking).  You can
chainload U-Boot and it'll turn it on USB for you, though.

Is there a way we could maybe tell if there's a driver due to try
probing on the node but that hasn't had a chance yet?  That could
mitigate the backwards kernel compat for new DT problem.


signature.asc
Description: PGP signature

Re: [PATCH 2/3 v8] mailbox: Enable BCM2835 mailbox support

[Eric Anholt]

Noralf Trønnes nor...@tronnes.org writes:

 Den 05.05.2015 22:27, skrev Eric Anholt:
 From: Lubomir Rintel lkund...@v3.sk

 This mailbox driver provides a single mailbox channel to write 32-bit
 values to the VPU and get a 32-bit response.  The Raspberry Pi
 firmware uses this mailbox channel to implement firmware calls, while
 Roku 2 (despite being derived from the same firmware tree) doesn't.

 The driver was originally submitted by Lubomir, based on the
 out-of-tree 2708 mailbox driver.  Eric Anholt fixed it up for
 upstreaming, with the major functional change being that it now has no
 notion of multiple channels (since that is a firmware-dependent
 concept) and instead the raspberrypi-firmware driver will do that
 bit-twiddling in its own messages.
 ...
 +static struct platform_driver bcm2835_mbox_driver = {
 +.driver = {
 +.name = bcm2835-mbox,
 +.owner = THIS_MODULE,
 +.of_match_table = bcm2835_mbox_of_match,
 +},
 +.probe  = bcm2835_mbox_probe,
 +.remove = bcm2835_mbox_remove,
 +};
 +module_platform_driver(bcm2835_mbox_driver);

 I have tested this driver and the firmware driver booting directly
 from the VideoCore bootloader (no uboot).
 The mailbox driver loads too late to turn on USB power:

Yeah, I have a patch on my branches that returns -EPROBE_DEFER when
trying to get a power domain and not finding the provider.  It was
rejected by the maintainers in favor of a proposed solution whose
description I didn't quite follow.

 This silences the warning:
 struct raspberrypi_power_domain raspberrypi_power_domain_usb = {
  .base = {
  .power_on_latency_ns = 6,

Oh, nice.  Thanks!


signature.asc
Description: PGP signature

Re: [PATCH] ARM: bcm2835: Use 0x4 prefix for DMA bus addresses to SDRAM.

[Eric Anholt]

Noralf Trønnes nor...@tronnes.org writes:

 Den 04.05.2015 21:33, skrev Eric Anholt:
 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 e...@anholt.net
 Cc: popcorn...@gmail.com
 ---
   arch/arm/boot/dts/bcm2835.dtsi | 1 +
   1 file changed, 1 insertion(+)

 diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
 index 5734650..2df1b5c 100644
 --- a/arch/arm/boot/dts/bcm2835.dtsi
 +++ b/arch/arm/boot/dts/bcm2835.dtsi
 @@ -15,6 +15,7 @@
  #address-cells = 1;
  #size-cells = 1;
  ranges = 0x7e00 0x2000 0x0200;
 +dma-ranges = 0x4000 0x 0x1f00;
   
  timer@7e003000 {
  compatible = brcm,bcm2835-system-timer;

 This was quite a coincidence. I discovered the need for 'dma-ranges'
 yesterday while trying to get the downstream bcm2708_fb driver to
 work with ARCH_BCM2835. The driver is using the mailbox to get info
 about the framebuffer from the firmware. When it failed I discovered
 that the bus address was wrong.

 What I don't understand, is that mmc and spi works fine with a wrong
 bus address. It's only the framebuffer driver and the vchiq driver
 when using mailbox that fails.

 Tested-by: Noralf Trønnes nor...@tronnes.org

Yeah, it was the mailbox driver I've been trying to merge, on pi2, that
made me get this patch together.  I'm suspicious that 0x0 works the same
as 0x4 for GPU peripherals (mmc, spi, vc4) on pi1, though I've had
occasional instability (something like 3 events per ~5000 tests) that I
sure hope is due to this.


signature.asc
Description: PGP signature

[PATCH] ARM: bcm2835: Use 0x4 prefix for DMA bus addresses to SDRAM.

[Eric Anholt]

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 e...@anholt.net
Cc: popcorn...@gmail.com
---
 arch/arm/boot/dts/bcm2835.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 5734650..2df1b5c 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -15,6 +15,7 @@
#address-cells = 1;
#size-cells = 1;
ranges = 0x7e00 0x2000 0x0200;
+   dma-ranges = 0x4000 0x 0x1f00;
 
timer@7e003000 {
compatible = brcm,bcm2835-system-timer;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3 v2] ARM: bcm2835: Add the mailbox to the device tree

[Eric Anholt]

Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Lee Jones lee.jo...@linaro.org
Acked-by: Stephen Warren swar...@wwwdotorg.org
---

v2: Update for #mbox-cells 0 change in the driver.

 arch/arm/boot/dts/bcm2835.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 4d4c129..4ff1b83 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -61,6 +61,13 @@
reg = 0x7e104000 0x10;
};
 
+   mailbox: mailbox@7e00b800 {
+   compatible = brcm,bcm2835-mbox;
+   reg = 0x7e00b880 0x40;
+   interrupts = 0 1;
+   #mbox-cells = 0;
+   };
+
gpio: gpio@7e20 {
compatible = brcm,bcm2835-gpio;
reg = 0x7e20 0xb4;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: bcm2835: Use 0x4 prefix for DMA bus addresses to SDRAM.

[Eric Anholt]

Stephen Warren swar...@wwwdotorg.org writes:

 On 05/04/2015 01:33 PM, Eric Anholt wrote:
 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).

 diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi

  #address-cells = 1;
  #size-cells = 1;
  ranges = 0x7e00 0x2000 0x0200;
 +dma-ranges = 0x4000 0x 0x1f00;

 Oh well that's a nice and simple patch; I had been avoiding looking into 
 fixing the kernel for this since I was worried it'd be rather complex!

 I'm puzzled why the length cell of ranges and dma-ranges differs though? 
 Assuming there's a good explanation for that,

Nope, you're right, it should be 0x2000.  '0x1f' came from going
back from the '0x3f' on the pi2, but pi2 just has a chunk lost to the
bus mapping.


signature.asc
Description: PGP signature

[PATCH v2] ARM: bcm2835: Use 0x4 prefix for DMA bus addresses to SDRAM.

[Eric Anholt]

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 e...@anholt.net
Tested-by: Noralf Trønnes nor...@tronnes.org
Acked-by: Stephen Warren swar...@wwwdotorg.org
Cc: popcorn...@gmail.com
---

v2: Fix length of the range from 0x1f00 to 0x2000, fixing the
translation for the last 16MB.

 arch/arm/boot/dts/bcm2835.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index eb33a8c..3c899b3 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -15,6 +15,7 @@
#address-cells = 1;
#size-cells = 1;
ranges = 0x7e00 0x2000 0x0200;
+   dma-ranges = 0x4000 0x 0x2000;
 
timer@7e003000 {
compatible = brcm,bcm2835-system-timer;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3 v8] mailbox: Enable BCM2835 mailbox support

[Eric Anholt]

From: Lubomir Rintel lkund...@v3.sk

This mailbox driver provides a single mailbox channel to write 32-bit
values to the VPU and get a 32-bit response.  The Raspberry Pi
firmware uses this mailbox channel to implement firmware calls, while
Roku 2 (despite being derived from the same firmware tree) doesn't.

The driver was originally submitted by Lubomir, based on the
out-of-tree 2708 mailbox driver.  Eric Anholt fixed it up for
upstreaming, with the major functional change being that it now has no
notion of multiple channels (since that is a firmware-dependent
concept) and instead the raspberrypi-firmware driver will do that
bit-twiddling in its own messages.

Signed-off-by: Lubomir Rintel lkund...@v3.sk
Signed-off-by: Craig McGeachie slap...@yahoo.com.au
Signed-off-by: Eric Anholt e...@anholt.net
Cc: Jassi Brar jassisinghb...@gmail.com
Acked-by: Stephen Warren swar...@wwwdotorg.org
---

v2: Squashed Craig's work for review, carried over to new version of
Mailbox framework (changes by Lubomir)

v3: Fix multi-line comment style.  Refer to the documentation by
filename.  Only declare one MODULE_AUTHOR.  Alphabetize includes.
Drop some excessive dev_dbg()s (changes by anholt).

v4: Use the new bcm2835_peripheral_read_workaround(), drop the
unnecessary wmb()s, make the messages be a pointer to u32, rather
than u32-cast-as-pointer, fold in small static functions, drop
extra error messages, clean up sizeof() arg for malloc, disable
interrupts on unload (changes by anholt).

v5: Rewrite as a single-channel driver, where the old notion of
channels will now be interpreted by an rpi-specific driver.  Minor
style fix.  Drop peripheral_read_workaround() since it's been
noted that readl() covers the non-interrupt half of it, and I
found that we would need to resolve read ordering in the interrupt
handler anyway (changes by anholt).

v6: rewrite commit message, only turn on interrupts when a client is
present, drop the started flag, use BIT() macro, update Broadcom
copyright (changes by anholt, from Jassi's review).  Drop s-o-b of
Jassi and Suman, who appear to have been accidentally added by
Craig (noted by Lubomir).

v7: Drop the txdone-style check in send_data, since the core will make
sure we're not called until the previous one is done.  Fix mbox
to be static (changes by anholt, from review by Jassi).

v8: Fix compiler warning from txdone check removal.  Add a summary of
anholt's changes to the commit message.  Supply our own of_xlate
to insist that 0 mbox-cells are provided.  Replace global *mbox
with container_of()s. Drop our driver's extra struct device
*dev.

 drivers/mailbox/Kconfig   |   8 ++
 drivers/mailbox/Makefile  |   2 +
 drivers/mailbox/bcm2835-mailbox.c | 217 ++
 3 files changed, 227 insertions(+)
 create mode 100644 drivers/mailbox/bcm2835-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 84b0a2d..ab574da 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -60,4 +60,12 @@ config ALTERA_MBOX
  An implementation of the Altera Mailbox soft core. It is used
  to send message between processors. Say Y here if you want to use the
  Altera mailbox support.
+
+config BCM2835_MBOX
+   tristate BCM2835 Mailbox
+   depends on ARCH_BCM2835
+   help
+ An implementation of the BCM2385 Mailbox.  It is used to invoke
+ the services of the Videocore. Say Y here if you want to use the
+ BCM2835 Mailbox.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index b18201e..8e6d822 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -11,3 +11,5 @@ obj-$(CONFIG_OMAP2PLUS_MBOX)  += omap-mailbox.o
 obj-$(CONFIG_PCC)  += pcc.o
 
 obj-$(CONFIG_ALTERA_MBOX)  += mailbox-altera.o
+
+obj-$(CONFIG_BCM2835_MBOX) += bcm2835-mailbox.o
diff --git a/drivers/mailbox/bcm2835-mailbox.c 
b/drivers/mailbox/bcm2835-mailbox.c
new file mode 100644
index 000..16c3453
--- /dev/null
+++ b/drivers/mailbox/bcm2835-mailbox.c
@@ -0,0 +1,217 @@
+/*
+ *  Copyright (C) 2010,2015 Broadcom
+ *  Copyright (C) 2013-2014 Lubomir Rintel
+ *  Copyright (C) 2013 Craig McGeachie
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This device provides a mechanism for writing to the mailboxes,
+ * that are shared between the ARM and the VideoCore processor
+ *
+ * Parts of the driver are based on:
+ *  - arch/arm/mach-bcm2708/vcio.c file written by Gray Girling that was
+ *obtained from branch rpi-3.6.y of git://github.com/raspberrypi/
+ *linux.git
+ *  - drivers/mailbox/bcm2835-ipc.c by Lubomir Rintel at
+ *https://github.com/hackerspace/rpi-linux/blob/lr-raspberry-pi/drivers/
+ *mailbox/bcm2835

[PATCH 1/3 v6] dt/bindings: Add binding for the BCM2835 mailbox driver

[Eric Anholt]

From: Lubomir Rintel lkund...@v3.sk

This patch was split out of Lubomir's original mailbox patch by Eric
Anholt, and the required properties documentation and examples have
been filled out more completely and updated for the driver being
changed to expose a single channel.

Signed-off-by: Lubomir Rintel lkund...@v3.sk
Signed-off-by: Craig McGeachie slap...@yahoo.com.au
Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Lee Jones lee.jo...@linaro.org
Acked-by: Stephen Warren swar...@wwwdotorg.org
---

v2: Split into a separate patch for submitting to the devicetree list.
Consistently start node docs with a capital letter. device's
address in the example shouldn't have 0x. Drop machine-specific
interrupt numbers from the docs.  (changes by anholt).

v3: Move the file to just bcm2835-mbox.txt, clean up formatting
(changes by anholt, from review by Lee Jones).

v4: Move file back by consensus from various Broadcom platform
maintainers (changes by anholt, acked by Lee Jones).

v5: Document that the mailbox cell should be 0 in clients, and add an
example of a client.

v6: Add change description to commit message separate from this
version section.  Update for #mbox-cells 0 change.

 .../bindings/mailbox/brcm,bcm2835-mbox.txt | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt 
b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
new file mode 100644
index 000..e893615
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
@@ -0,0 +1,26 @@
+Broadcom BCM2835 VideoCore mailbox IPC
+
+Required properties:
+
+- compatible:  Should be brcm,bcm2835-mbox
+- reg: Specifies base physical address and size of the registers
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+- #mbox-cells: Specifies the number of cells needed to encode a mailbox
+ channel. The value shall be 0, since there is only one
+ mailbox channel implemented by the device.
+
+Example:
+
+mailbox: mailbox@7e00b800 {
+   compatible = brcm,bcm2835-mbox;
+   reg = 0x7e00b880 0x40;
+   interrupts = 0 1;
+   #mbox-cells = 0;
+};
+
+firmware: firmware {
+   compatible = raspberrypi,firmware;
+   mboxes = mailbox;
+   #power-domain-cells = 1;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [PATCH 2/3 v8] mailbox: Enable BCM2835 mailbox support

[Eric Anholt]

Alexander Stein alexander...@web.de writes:

 On Thursday 07 May 2015, 12:54:20 wrote Eric Anholt:
 Noralf Trønnes nor...@tronnes.org writes:
 
  Den 05.05.2015 22:27, skrev Eric Anholt:
  From: Lubomir Rintel lkund...@v3.sk
 
  This mailbox driver provides a single mailbox channel to write 32-bit
  values to the VPU and get a 32-bit response.  The Raspberry Pi
  firmware uses this mailbox channel to implement firmware calls, while
  Roku 2 (despite being derived from the same firmware tree) doesn't.
 
  The driver was originally submitted by Lubomir, based on the
  out-of-tree 2708 mailbox driver.  Eric Anholt fixed it up for
  upstreaming, with the major functional change being that it now has no
  notion of multiple channels (since that is a firmware-dependent
  concept) and instead the raspberrypi-firmware driver will do that
  bit-twiddling in its own messages.
  ...
  +static struct platform_driver bcm2835_mbox_driver = {
  + .driver = {
  + .name = bcm2835-mbox,
  + .owner = THIS_MODULE,
  + .of_match_table = bcm2835_mbox_of_match,
  + },
  + .probe  = bcm2835_mbox_probe,
  + .remove = bcm2835_mbox_remove,
  +};
  +module_platform_driver(bcm2835_mbox_driver);
 
  I have tested this driver and the firmware driver booting directly
  from the VideoCore bootloader (no uboot).
  The mailbox driver loads too late to turn on USB power:
 
 Yeah, I have a patch on my branches that returns -EPROBE_DEFER when
 trying to get a power domain and not finding the provider.  It was
 rejected by the maintainers in favor of a proposed solution whose
 description I didn't quite follow.

 Do you have a link for this thread?

https://lkml.org/lkml/2015/3/11/483


signature.asc
Description: PGP signature

[PATCH 1/3 v2] dt/bindings: Add binding for the Raspberry Pi firmware driver

[Eric Anholt]

This driver will provide support for calls into the firmware that will
be used by other drivers like cpufreq and vc4.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Improve commit message, point to mailbox.txt for how mboxes work.

 .../devicetree/bindings/arm/bcm/raspberrypi,firmware.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt
new file mode 100644
index 000..33b0043
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt
@@ -0,0 +1,16 @@
+Raspberry Pi VideoCore firmware driver
+
+Required properties:
+
+- compatible:  Should be rasbperrypi,firmware
+- mboxes:  Single-entry list which specifies which mailbox
+ controller and channel is used.  See
+ Documentation/devicetree/bindings/mailbox/mailbox.txt
+ for the semantics of this property
+
+Example:
+
+firmware {
+   compatible = rasbperrypi,firmware;
+   mboxes = mailbox;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3 v2] ARM: bcm2835: Add the Raspberry Pi firmware driver

[Eric Anholt]

This gives us a function for making mailbox property channel requests
of the firmware, which is most notable in that it will let us get and
set clock rates.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Drop power-domains stuff for now since we don't have the driver
core support to make it useful.  Move to drivers/firmware/.
Capitalize the enums.  De-global the firmware variable.  Use the
firmware device to allocate our DMA buffer, so that the dma-ranges
DT property gets respected.  Simplify the property tag transaction
interface even more, leaving a multi-tag interface still
available.  For conciseness, rename raspberrypi to rpi on all
functions/enums/structs, and the firmware variable to fw.
Print when the driver is probed successfully, since debugging
-EPROBE_DEFER handling is such a big part of bcm2835 development.
Drop -EBUSY mailbox handling since the mailbox core has been fixed
to return -EPROBE_DEFER in -next.

Note that I don't think I've done what srwarren wanted for
-EPROBE_DEFER, because I'm not clear what he wants.  I think he might
just be asking for a function that does:

/*
 * Returns 0 if the firmware device is probed and available, otherwise
 * -EPROBE_DEFER.
 */
int rpi_firmware_get(struct device_node *firmware_node)
{
struct platform_device *pdev = of_find_device_by_node(of_node);
if (!platform_get_drvdata(pdev))
return -EPROBE_DEFER;
return 0;
}
EXPORT_SYMBOL(rpi_firmware_get)

If that's all, I'm happy to add it.

Note that a client could currently do this:

ret = rpi_firmware_property_list(firmware_node, NULL, 0);

in exchange for a bit of overhead in the case that it's actually probed already.


 drivers/firmware/Makefile  |   1 +
 drivers/firmware/raspberrypi.c | 224 +
 .../soc/bcm2835/raspberrypi-firmware-property.h| 114 +++
 3 files changed, 339 insertions(+)
 create mode 100644 drivers/firmware/raspberrypi.c
 create mode 100644 include/soc/bcm2835/raspberrypi-firmware-property.h

diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 3fdd391..41ced28 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ISCSI_IBFT)  += iscsi_ibft.o
 obj-$(CONFIG_FIRMWARE_MEMMAP)  += memmap.o
 obj-$(CONFIG_QCOM_SCM) += qcom_scm.o
 CFLAGS_qcom_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
+obj-$(CONFIG_BCM2835_MBOX) += raspberrypi.o
 
 obj-$(CONFIG_GOOGLE_FIRMWARE)  += google/
 obj-$(CONFIG_EFI)  += efi/
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
new file mode 100644
index 000..61bde1b
--- /dev/null
+++ b/drivers/firmware/raspberrypi.c
@@ -0,0 +1,224 @@
+/*
+ *  Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Defines interfaces for interacting wtih the Raspberry Pi firmware's
+ * property channel.
+ */
+
+#include linux/dma-mapping.h
+#include linux/mailbox_client.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include soc/bcm2835/raspberrypi-firmware-property.h
+
+#define MBOX_MSG(chan, data28) (((data28)  ~0xf) | ((chan)  0xf))
+#define MBOX_CHAN(msg) ((msg)  0xf)
+#define MBOX_DATA28(msg)   ((msg)  ~0xf)
+#define MBOX_CHAN_PROPERTY 8
+
+struct rpi_firmware {
+   struct mbox_client cl;
+   struct mbox_chan *chan; /* The property channel. */
+   struct completion c;
+   u32 enabled;
+};
+
+static DEFINE_MUTEX(transaction_lock);
+
+static void response_callback(struct mbox_client *cl, void *msg)
+{
+   struct rpi_firmware *fw = container_of(cl, struct rpi_firmware, cl);
+   complete(fw-c);
+}
+
+/*
+ * Sends a request to the firmware through the BCM2835 mailbox driver,
+ * and synchronously waits for the reply.
+ */
+static int
+rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
+{
+   u32 message = MBOX_MSG(chan, data);
+   int ret;
+
+   WARN_ON(data  0xf);
+
+   mutex_lock(transaction_lock);
+   reinit_completion(fw-c);
+   ret = mbox_send_message(fw-chan, message);
+   if (ret = 0) {
+   wait_for_completion(fw-c);
+   ret = 0;
+   } else {
+   dev_err(fw-cl.dev, mbox_send_message returned %d\n, ret);
+   }
+   mutex_unlock(transaction_lock);
+
+   return ret;
+}
+
+/*
+ * Submits a set of concatenated tags to the VPU firmware through the
+ * mailbox property interface.
+ *
+ * The buffer header and the ending tag are added by this function and
+ * don't need to be supplied, just the actual tags for your operation.
+ * See struct rpi_firmware_property_tag_header for the per-tag

[PATCH 3/3 v2] ARM: bcm2835: Add the firmware driver information to the RPi DT

[Eric Anholt]

Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Lee Jones l...@kernel.org (previous version with pm-domains)
---

v2: Drop pm-domains stuff since I've dropped it from the firmware
driver for now, until we get drivers/base fixed.

 arch/arm/boot/dts/bcm2835-rpi.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 46780bb..ace33f6 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -14,6 +14,13 @@
linux,default-trigger = heartbeat;
};
};
+
+   soc {
+   firmware: firmware {
+   compatible = raspberrypi,firmware;
+   mboxes = mailbox;
+   };
+   };
 };
 
 gpio {
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RPi firmware driver v2

[Eric Anholt]

Here's a new version of the firmware driver.  This series applies on
top of for-rpi-next from Lee Jones's tree:

git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git

But it won't actually probe without merging in mailbox-for-next:

https://git.linaro.org/landing-teams/working/fujitsu/integration.git

I've dropped the pm-domains code for now, since it wasn't doing
anything useful for us yet without the drivers/base support.  However,
this code has been useful for building a proper clk provider for the
Pi, which can be found at:

https://github.com/anholt/linux/tree/rpi-dt-clocks

Andrea Merello apparently got a cpufreq driver working on top of the
non-DT version of this clk provider:

https://github.com/andreamerello/linux-mach-bcm/tree/bcm2836-cpufreq

I think we might manage with a generic dt-cpufreq implementation,
though.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mailbox/bcm2835: Fix mailbox full detection.

[Eric Anholt]

With the VC reader blocked and the ARM writing, MAIL0_STA reads empty
permanently while MAIL1_STA goes from empty (0x4000) to non-empty
(0x0001-0x0007) to full (0x8008).

This bug ended up having no effect on us, because all of our
transactions in the client driver were synchronous and under a mutex.

Suggested-by: Phil Elwell p...@raspberrypi.org
Signed-off-by: Eric Anholt e...@anholt.net
---

This is a port of a patch by Noralf from the downstream Raspberry Pi
tree.  Noralf said he didn't want attribution on this patch, even if
it looks a lot like his.

 drivers/mailbox/bcm2835-mailbox.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mailbox/bcm2835-mailbox.c 
b/drivers/mailbox/bcm2835-mailbox.c
index 4b13268..0b47dd4 100644
--- a/drivers/mailbox/bcm2835-mailbox.c
+++ b/drivers/mailbox/bcm2835-mailbox.c
@@ -49,6 +49,7 @@
 #define MAIL0_STA  (ARM_0_MAIL0 + 0x18)
 #define MAIL0_CNF  (ARM_0_MAIL0 + 0x1C)
 #define MAIL1_WRT  (ARM_0_MAIL1 + 0x00)
+#define MAIL1_STA  (ARM_0_MAIL1 + 0x18)
 
 /* Status register: FIFO state. */
 #define ARM_MS_FULLBIT(31)
@@ -117,7 +118,7 @@ static bool bcm2835_last_tx_done(struct mbox_chan *link)
bool ret;
 
spin_lock(mbox-lock);
-   ret = !(readl(mbox-regs + MAIL0_STA)  ARM_MS_FULL);
+   ret = !(readl(mbox-regs + MAIL1_STA)  ARM_MS_FULL);
spin_unlock(mbox-lock);
return ret;
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3 v2] ARM: bcm2835: Add the Raspberry Pi firmware driver

[Eric Anholt]

Noralf Trønnes nor...@tronnes.org writes:

 Den 13.05.2015 21:00, skrev Eric Anholt:
 This gives us a function for making mailbox property channel requests
 of the firmware, which is most notable in that it will let us get and
 set clock rates.

 Signed-off-by: Eric Anholt e...@anholt.net
 ---

 [...]

 +/*
 + * Submits a single tag to the VPU firmware through the mailbox
 + * property interface.
 + *
 + * This is a convenience wrapper around
 + * rpi_firmware_property_list() to avoid some of the
 + * boilerplate in property calls.
 + */
 +int rpi_firmware_property(struct device_node *of_node,
 +  u32 tag, void *tag_data, size_t buf_size)

 To use the firmware property functions, I need a DT node pointer.
 Since Device Tree is dynamic now, should I fetch the firmware node
 each time, or should I do that in probe and store the node pointer?

 Device Tree:
  firmware: firmware {
  compatible = raspberrypi,firmware;
  };

  thermal {
  compatible = brcm,bcm2835-thermal;
  firmware = firmware;
  };

I'm doing it in probe in my clients -- I don't see why the firmware
device's node would change.


signature.asc
Description: PGP signature

[PATCH 1/3 v3] dt/bindings: Add binding for the Raspberry Pi firmware driver

[Eric Anholt]

This driver will provide support for calls into the firmware that will
be used by other drivers like cpufreq and vc4.
---

v2: Improve commit message, point to mailbox.txt for how mboxes work.
v3: Use Lee's suggestion for mailbox phandle docs, fix spelling of
raspberry.

 .../devicetree/bindings/arm/bcm/raspberrypi,firmware.txt   | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt

diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt
new file mode 100644
index 000..dbf60f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt
@@ -0,0 +1,14 @@
+Raspberry Pi VideoCore firmware driver
+
+Required properties:
+
+- compatible:  Should be rasbperrypi,firmware
+- mboxes:  Phandle to the firmware device's Mailbox.
+ (See: ../mailbox/mailbox.txt for more information)
+
+Example:
+
+firmware {
+   compatible = raspberrypi,firmware;
+   mboxes = mailbox;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3 v3] ARM: bcm2835: Add the Raspberry Pi firmware driver

[Eric Anholt]

This gives us a function for making mailbox property channel requests
of the firmware, which is most notable in that it will let us get and
set clock rates.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Drop power-domains stuff for now since we don't have the driver
core support to make it useful.  Move to drivers/firmware/.
Capitalize the enums.  De-global the firmware variable.  Use the
firmware device to allocate our DMA buffer, so that the dma-ranges
DT property gets respected.  Simplify the property tag transaction
interface even more, leaving a multi-tag interface still
available.  For conciseness, rename raspberrypi to rpi on all
functions/enums/structs, and the firmware variable to fw.
Print when the driver is probed successfully, since debugging
-EPROBE_DEFER handling is such a big part of bcm2835 development.
Drop -EBUSY mailbox handling since the mailbox core has been fixed
to return -EPROBE_DEFER in -next.

v3: Use kernel-doc style for big comments (from Noralf), drop stale
comment, use dev when freeing DMA as well.

 drivers/firmware/Makefile  |   1 +
 drivers/firmware/raspberrypi.c | 230 +
 .../soc/bcm2835/raspberrypi-firmware-property.h| 112 ++
 3 files changed, 343 insertions(+)
 create mode 100644 drivers/firmware/raspberrypi.c
 create mode 100644 include/soc/bcm2835/raspberrypi-firmware-property.h

diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 3fdd391..41ced28 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ISCSI_IBFT)  += iscsi_ibft.o
 obj-$(CONFIG_FIRMWARE_MEMMAP)  += memmap.o
 obj-$(CONFIG_QCOM_SCM) += qcom_scm.o
 CFLAGS_qcom_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
+obj-$(CONFIG_BCM2835_MBOX) += raspberrypi.o
 
 obj-$(CONFIG_GOOGLE_FIRMWARE)  += google/
 obj-$(CONFIG_EFI)  += efi/
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
new file mode 100644
index 000..d612815
--- /dev/null
+++ b/drivers/firmware/raspberrypi.c
@@ -0,0 +1,230 @@
+/*
+ *  Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Defines interfaces for interacting wtih the Raspberry Pi firmware's
+ * property channel.
+ */
+
+#include linux/dma-mapping.h
+#include linux/mailbox_client.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include soc/bcm2835/raspberrypi-firmware-property.h
+
+#define MBOX_MSG(chan, data28) (((data28)  ~0xf) | ((chan)  0xf))
+#define MBOX_CHAN(msg) ((msg)  0xf)
+#define MBOX_DATA28(msg)   ((msg)  ~0xf)
+#define MBOX_CHAN_PROPERTY 8
+
+struct rpi_firmware {
+   struct mbox_client cl;
+   struct mbox_chan *chan; /* The property channel. */
+   struct completion c;
+   u32 enabled;
+};
+
+static DEFINE_MUTEX(transaction_lock);
+
+static void response_callback(struct mbox_client *cl, void *msg)
+{
+   struct rpi_firmware *fw = container_of(cl, struct rpi_firmware, cl);
+   complete(fw-c);
+}
+
+/*
+ * Sends a request to the firmware through the BCM2835 mailbox driver,
+ * and synchronously waits for the reply.
+ */
+static int
+rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
+{
+   u32 message = MBOX_MSG(chan, data);
+   int ret;
+
+   WARN_ON(data  0xf);
+
+   mutex_lock(transaction_lock);
+   reinit_completion(fw-c);
+   ret = mbox_send_message(fw-chan, message);
+   if (ret = 0) {
+   wait_for_completion(fw-c);
+   ret = 0;
+   } else {
+   dev_err(fw-cl.dev, mbox_send_message returned %d\n, ret);
+   }
+   mutex_unlock(transaction_lock);
+
+   return ret;
+}
+
+/**
+ * rpi_firmware_property_list - Submit firmware property list
+ * @of_node:   Pointer to the firmware Device Tree node.
+ * @data:  Buffer holding tags.
+ * @tag_size:  Size of tags buffer.
+ *
+ * Submits a set of concatenated tags to the VPU firmware through the
+ * mailbox property interface.
+ *
+ * The buffer header and the ending tag are added by this function and
+ * don't need to be supplied, just the actual tags for your operation.
+ * See struct rpi_firmware_property_tag_header for the per-tag
+ * structure.
+ */
+int rpi_firmware_property_list(struct device_node *of_node,
+  void *data, size_t tag_size)
+{
+   struct platform_device *pdev = of_find_device_by_node(of_node);
+   struct rpi_firmware *fw = platform_get_drvdata(pdev);
+   size_t size = tag_size + 12;
+   u32 *buf;
+   dma_addr_t bus_addr;
+   int ret = 0;
+
+   if (!fw)
+   return -EPROBE_DEFER

Raspberry Pi DT clocks series

[Eric Anholt]

Here's a series to add a real clock provider on Raspberry Pi.
Previously, we've been using a mix of fixed clocks from clk-bcm2835.c
(though some of them failed to get used by their intended consumers),
and fixed-clock nodes in the DT.

This driver gives us the ability to enable/disable our clocks, and
also lets us get and set frequency values.  This will let us build a
cpufreq driver (Andrea Merello has done some work on this front, and
has a couple of options available), and get correct frequencies on the
Raspberry Pi 2 without hardcoding new values.

This branch can be found at:

https://github.com/anholt/linux/tree/rpi-dt-clocks

which also has a patch for the MMC clock which is not included yet due
to a bug in the sdhci driver.  The series applies on top of
rpi-mailbox, whose code is currently out for review:

http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-May/001762.html

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/7] ARM: bcm2835: Add a Raspberry Pi-specific clock driver.

[Eric Anholt]

Unfortunately, the clock manager's registers are not accessible by the
ARM, so we have to request that the firmware modify our clocks for us.

This driver only registers the clocks at the point they are requested
by a client driver.  This is partially to support returning
-EPROBE_DEFER when the firmware driver isn't supported yet, but it
also avoids issues with disabling unused clocks due to them not yet
being connected to their consumers in the DT.

Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/clk/Makefile  |   1 +
 drivers/clk/clk-raspberrypi.c | 241 ++
 include/dt-bindings/clk/raspberrypi.h |  23 
 3 files changed, 265 insertions(+)
 create mode 100644 drivers/clk/clk-raspberrypi.c
 create mode 100644 include/dt-bindings/clk/raspberrypi.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 3d00c25..6a5dafa 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MACH_ASM9260)+= clk-asm9260.o
 obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)+= clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)   += clk-axm5516.o
 obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
+obj-$(CONFIG_ARCH_BCM2835) += clk-raspberrypi.o
 obj-$(CONFIG_COMMON_CLK_CDCE706)   += clk-cdce706.o
 obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
 obj-$(CONFIG_ARCH_EFM32)   += clk-efm32gg.o
diff --git a/drivers/clk/clk-raspberrypi.c b/drivers/clk/clk-raspberrypi.c
new file mode 100644
index 000..5745875
--- /dev/null
+++ b/drivers/clk/clk-raspberrypi.c
@@ -0,0 +1,241 @@
+/*
+ * Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Implements a clock provider for the clocks controlled by the
+ * firmware on Raspberry Pi.
+ *
+ * These clocks are controlled by the CLOCKMAN peripheral in the
+ * hardware, but the ARM doesn't have access to the registers for
+ * them.  As a result, we have to call into the firmware to get it to
+ * enable, disable, and set their frequencies.
+ *
+ * We don't have an interface for getting the set of frequencies
+ * available from the hardware.  We can request a min/max, but other
+ * than that we have to request a frequency and take what it gives us.
+ */
+
+#include dt-bindings/clk/raspberrypi.h
+#include linux/clk-provider.h
+#include soc/bcm2835/raspberrypi-firmware-property.h
+
+struct rpi_firmware_clock {
+   /* Clock definitions in our static struct. */
+   int clock_id;
+   const char *name;
+
+   /* The rest are filled in at init time. */
+   struct clk_hw hw;
+   struct device *dev;
+   struct device_node *firmware_node;
+};
+
+static struct rpi_firmware_clock rpi_clocks[] = {
+   [RPI_CLOCK_EMMC] = { 1, emmc },
+   [RPI_CLOCK_UART0] = { 2, uart0 },
+   [RPI_CLOCK_ARM] = { 3, arm },
+   [RPI_CLOCK_CORE] = { 4, core },
+   [RPI_CLOCK_V3D] = { 5, v3d },
+   [RPI_CLOCK_H264] = { 6, h264 },
+   [RPI_CLOCK_ISP] = { 7, isp },
+   [RPI_CLOCK_SDRAM] = { 8, sdram },
+   [RPI_CLOCK_PIXEL] = { 9, pixel },
+   [RPI_CLOCK_PWM] = { 10, pwm },
+};
+
+static int rpi_clk_is_on(struct clk_hw *hw)
+{
+   struct rpi_firmware_clock *rpi_clk =
+   container_of(hw, struct rpi_firmware_clock, hw);
+   u32 packet[2];
+   int ret;
+
+   packet[0] = rpi_clk-clock_id;
+   packet[1] = 0;
+   ret = rpi_firmware_property(rpi_clk-firmware_node,
+   RPI_FIRMWARE_GET_CLOCK_STATE,
+   packet, sizeof(packet));
+   if (ret) {
+   dev_err(rpi_clk-dev, Failed to get clock state\n);
+   return 0;
+   }
+
+   return packet[1] != 0;
+}
+
+static int rpi_clk_set_state(struct rpi_firmware_clock *rpi_clk, bool on)
+{
+   u32 packet[2];
+   int ret;
+
+   packet[0] = rpi_clk-clock_id;
+   packet[1] = on;
+   ret = rpi_firmware_property(rpi_clk-firmware_node,
+   RPI_FIRMWARE_SET_CLOCK_STATE,
+   packet, sizeof(packet));
+   if (ret || (packet[1]  (1  1))) {
+   dev_err(rpi_clk-dev, Failed to set clock state\n);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int rpi_clk_on(struct clk_hw *hw)
+{
+   struct rpi_firmware_clock *rpi_clk =
+   container_of(hw, struct rpi_firmware_clock, hw);
+
+   return rpi_clk_set_state(rpi_clk, true);
+}
+
+static void rpi_clk_off(struct clk_hw *hw)
+{
+   struct rpi_firmware_clock *rpi_clk =
+   container_of(hw, struct rpi_firmware_clock, hw);
+
+   rpi_clk_set_state(rpi_clk, false);
+}
+
+static unsigned long rpi_clk_get_rate(struct clk_hw *hw,
+ unsigned long

[PATCH 7/7] ARM: bcm2835: Tie SPI clock to the core clock rate.

[Eric Anholt]

We were previously using a fixed clock declared in the 2835 DT, but
it's actually the core clock, and it might not be the same if you had
adjusted it using the firmware's config.txt.

Signed-off-by: Eric Anholt e...@anholt.net
---

This is the only patch in the series I haven't really tested, since I
don't have any SPI devices.

 arch/arm/boot/dts/bcm2835-rpi.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 53285a3..994c8e7 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -69,3 +69,7 @@
 firmware_clocks RPI_CLOCK_CORE;
clock-names = uartclk, apb_pclk;
 };
+
+spi {
+   clocks = firmware_clocks RPI_CLOCK_CORE;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/7] ARM: bcm2835: Drop never-used clock-frequency property of uart0.

[Eric Anholt]

This appears to have been copy-and-paste from another serial driver's
DT.  The driver has never used this value -- instead, the pl011 driver
is getting the fixed 20201000.uart clock from clk-bcm2835.c.

Signed-off-by: Eric Anholt e...@anholt.net
---
 arch/arm/boot/dts/bcm2835.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 301c73f..32f5830 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -96,7 +96,6 @@
compatible = brcm,bcm2835-pl011, arm,pl011, 
arm,primecell;
reg = 0x7e201000 0x1000;
interrupts = 2 25;
-   clock-frequency = 300;
arm,primecell-periphid = 0x00241011;
};
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/7] ARM: bcm2835: Drop the fixed sys_pclk.

[Eric Anholt]

Nothing uses it, and I can't find any evidence that anything ever has.

Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/clk/clk-bcm2835.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/clk/clk-bcm2835.c b/drivers/clk/clk-bcm2835.c
index 6b950ca..dd295e4 100644
--- a/drivers/clk/clk-bcm2835.c
+++ b/drivers/clk/clk-bcm2835.c
@@ -32,11 +32,6 @@ void __init bcm2835_init_clocks(void)
struct clk *clk;
int ret;
 
-   clk = clk_register_fixed_rate(NULL, sys_pclk, NULL, CLK_IS_ROOT,
-   25000);
-   if (IS_ERR(clk))
-   pr_err(sys_pclk not registered\n);
-
clk = clk_register_fixed_rate(NULL, apb_pclk, NULL, CLK_IS_ROOT,
12600);
if (IS_ERR(clk))
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/7] ARM: bcm2835: Add DT for the firmware clocks driver.

[Eric Anholt]

Signed-off-by: Eric Anholt e...@anholt.net
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index ace33f6..ac5f84c 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -20,6 +20,12 @@
compatible = raspberrypi,firmware;
mboxes = mailbox;
};
+
+   firmware_clocks: firmware-clocks {
+   compatible = raspberrypi,firmware-clocks;
+   #clock-cells = 1;
+   firmware = firmware;
+   };
};
 };
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/7] dt/bindings: Add binding for the Raspberry Pi clock provider

[Eric Anholt]

The hardware clocks are not controllable by the ARM, so we have to
make requests to the firmware to do so from the VPU side.  This will
let us replace fixed clocks in our DT with actual clock control (and
correct frequency information).

Signed-off-by: Eric Anholt e...@anholt.net
---
 .../bindings/clock/raspberrypi,firmware-clocks.txt | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/raspberrypi,firmware-clocks.txt

diff --git 
a/Documentation/devicetree/bindings/clock/raspberrypi,firmware-clocks.txt 
b/Documentation/devicetree/bindings/clock/raspberrypi,firmware-clocks.txt
new file mode 100644
index 000..9e1f21b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/raspberrypi,firmware-clocks.txt
@@ -0,0 +1,24 @@
+Raspberry Pi firmware clock provider.
+
+The Raspberry Pi architecture doesn't provide direct access to the
+CLOCKMAN peripheral from the ARM side, so Linux has to make requests
+to the VPU firmware to program them.
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible:  Should be raspberrypi,firmware-clocks
+
+- #clock-cells:Shall have value 1.  The permitted clock-specifier 
values
+ can be found in include/dt-bindings/clk/raspberrypi.h.
+
+- firmware:Phandle to the firmware driver node.
+
+Example:
+
+firmware_clocks: firmware-clocks {
+   compatible = raspberrypi,firmware-clocks;
+   #clock-cells = 1;
+   firmware = firmware;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/7] ARM: bcm2835: Use the RPi firmware clocks for uart.

[Eric Anholt]

This gets us a correct apb_pclk, which previously was accidentally
using the 20201000.uart clock from clk-bcm2835.c, due to the
fallback clk_get_sys() path.

Signed-off-by: Eric Anholt e...@anholt.net
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 7 +++
 arch/arm/boot/dts/bcm2835.dtsi | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index ac5f84c..53285a3 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,3 +1,4 @@
+#include dt-bindings/clk/raspberrypi.h
 #include bcm2835.dtsi
 
 / {
@@ -62,3 +63,9 @@
status = okay;
bus-width = 4;
 };
+
+uart0 {
+   clocks = firmware_clocks RPI_CLOCK_UART0,
+firmware_clocks RPI_CLOCK_CORE;
+   clock-names = uartclk, apb_pclk;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 32f5830..5be2862 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -92,7 +92,7 @@
#interrupt-cells = 2;
};
 
-   uart@7e201000 {
+   uart0: uart@7e201000 {
compatible = brcm,bcm2835-pl011, arm,pl011, 
arm,primecell;
reg = 0x7e201000 0x1000;
interrupts = 2 25;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: bcm2835: Use 0x4 prefix for DMA bus addresses to SDRAM.

[Eric Anholt]

Lee Jones l...@kernel.org writes:

 On Tue, 05 May 2015, Eric Anholt wrote:

 Stephen Warren swar...@wwwdotorg.org writes:
 
  On 05/04/2015 01:33 PM, Eric Anholt wrote:
  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).
 
  diff --git a/arch/arm/boot/dts/bcm2835.dtsi 
  b/arch/arm/boot/dts/bcm2835.dtsi
 
#address-cells = 1;
#size-cells = 1;
ranges = 0x7e00 0x2000 0x0200;
  + dma-ranges = 0x4000 0x 0x1f00;
 
  Oh well that's a nice and simple patch; I had been avoiding looking into 
  fixing the kernel for this since I was worried it'd be rather complex!
 
  I'm puzzled why the length cell of ranges and dma-ranges differs though? 
  Assuming there's a good explanation for that,
 
 Nope, you're right, it should be 0x2000.  '0x1f' came from going
 back from the '0x3f' on the pi2, but pi2 just has a chunk lost to the
 bus mapping.

 So are you going to fix this and send another patch?

I see it having hit the list:

http://lists.infradead.org/pipermail/linux-rpi-kernel/2015-May/001699.html

but I'm missing both versions in my inbox, so I'm not sure what
happened.


signature.asc
Description: PGP signature

Re: [PATCH 1/3 v2] dt/bindings: Add binding for the Raspberry Pi firmware driver

[Eric Anholt]

Lee Jones l...@kernel.org writes:

 On Wed, 13 May 2015, Eric Anholt wrote:

 This driver will provide support for calls into the firmware that will
 be used by other drivers like cpufreq and vc4.
 
 Signed-off-by: Eric Anholt e...@anholt.net
 ---
 
 v2: Improve commit message, point to mailbox.txt for how mboxes work.
 
  .../devicetree/bindings/arm/bcm/raspberrypi,firmware.txt | 16 
 
  1 file changed, 16 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt
 
 diff --git 
 a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt 
 b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt
 new file mode 100644
 index 000..33b0043
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,firmware.txt
 @@ -0,0 +1,16 @@
 +Raspberry Pi VideoCore firmware driver
 +
 +Required properties:
 +
 +- compatible:   Should be rasbperrypi,firmware
 +- mboxes:   Single-entry list which specifies which mailbox
 +  controller and channel is used.  See
 +  Documentation/devicetree/bindings/mailbox/mailbox.txt
 +  for the semantics of this property

 That's not what it looks like to me.  There is no mention of channels
 in a 0 cell property.  Keep it simple.  How about:

 Phandle to the firmware device's Mailbox.
 (See: ../mailbox/mailbox.txt for more information)

Sounds good to me.


signature.asc
Description: PGP signature

Re: [PATCH v3 1/7] dt/bindings: Add binding for the Raspberry Pi clock provider

[Eric Anholt]

Eric Anholt e...@anholt.net writes:

 The hardware clocks are not controllable by the ARM, so we have to
 make requests to the firmware to do so from the VPU side.  This will
 let us replace fixed clocks in our DT with actual clock control (and
 correct frequency information).

 v2: Include the dt-bindings header in this commit instead of the next
 one.  Make the clock indices match the firmware clock IDs.  Rename
 the binding's compat string.  Move the firmware phandle to be
 under a vendor-specific namespace.

Having failed to move the versioning bits below --- again, I'm adding
scripting to hopefully catch myself if I'm about to do it again.


signature.asc
Description: PGP signature

[PATCH v3 5/7] ARM: bcm2835: Drop the fixed sys_pclk.

[Eric Anholt]

Nothing uses it, and I can't find any evidence that anything ever has.

Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/clk/clk-bcm2835.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/clk/clk-bcm2835.c b/drivers/clk/clk-bcm2835.c
index 6b950ca..dd295e4 100644
--- a/drivers/clk/clk-bcm2835.c
+++ b/drivers/clk/clk-bcm2835.c
@@ -32,11 +32,6 @@ void __init bcm2835_init_clocks(void)
struct clk *clk;
int ret;
 
-   clk = clk_register_fixed_rate(NULL, sys_pclk, NULL, CLK_IS_ROOT,
-   25000);
-   if (IS_ERR(clk))
-   pr_err(sys_pclk not registered\n);
-
clk = clk_register_fixed_rate(NULL, apb_pclk, NULL, CLK_IS_ROOT,
12600);
if (IS_ERR(clk))
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/7] ARM: bcm2835: Add a Raspberry Pi-specific clock driver.

[Eric Anholt]

Unfortunately, the clock manager's registers are not accessible by the
ARM, so we have to request that the firmware modify our clocks for us.

This driver only registers the clocks at the point they are requested
by a client driver.  This is partially to support returning
-EPROBE_DEFER when the firmware driver isn't supported yet, but it
also avoids issues with disabling unused clocks due to them not yet
being connected to their consumers in the DT.

v2: Declare the mutex static (from review by Baruch Siach), merge
description and copyright comments.

v3: Update for new rpi firmware API.  Update the compatible string.
Make the firmware handle be under a vendor-namespaced property.
Make the DT indices match the firmware clock IDs.  Move the driver
under the firmware driver's Kconfig, since it requires it.  Move a
container_of() from 2 callers into the callee.

Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/clk/Makefile  |   1 +
 drivers/clk/clk-raspberrypi.c | 242 ++
 2 files changed, 243 insertions(+)
 create mode 100644 drivers/clk/clk-raspberrypi.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 3d00c25..0525c6b 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MACH_ASM9260)+= clk-asm9260.o
 obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)+= clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)   += clk-axm5516.o
 obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
+obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += clk-raspberrypi.o
 obj-$(CONFIG_COMMON_CLK_CDCE706)   += clk-cdce706.o
 obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
 obj-$(CONFIG_ARCH_EFM32)   += clk-efm32gg.o
diff --git a/drivers/clk/clk-raspberrypi.c b/drivers/clk/clk-raspberrypi.c
new file mode 100644
index 000..e1071d1
--- /dev/null
+++ b/drivers/clk/clk-raspberrypi.c
@@ -0,0 +1,242 @@
+/*
+ * Implements a clock provider for the clocks controlled by the
+ * firmware on Raspberry Pi.
+ *
+ * These clocks are controlled by the CLOCKMAN peripheral in the
+ * hardware, but the ARM doesn't have access to the registers for
+ * them.  As a result, we have to call into the firmware to get it to
+ * enable, disable, and set their frequencies.
+ *
+ * We don't have an interface for getting the set of frequencies
+ * available from the hardware.  We can request a min/max, but other
+ * than that we have to request a frequency and take what it gives us.
+ *
+ * Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/clk/raspberrypi.h
+#include linux/clk-provider.h
+#include soc/bcm2835/raspberrypi-firmware.h
+
+struct rpi_firmware_clock {
+   /* Clock definitions in our static struct. */
+   const char *name;
+
+   /* The rest are filled in at init time. */
+   struct clk_hw hw;
+   struct device *dev;
+   struct rpi_firmware *firmware;
+};
+
+static struct rpi_firmware_clock rpi_clocks[] = {
+   [RPI_CLOCK_EMMC] = { emmc },
+   [RPI_CLOCK_UART0] = { uart0 },
+   [RPI_CLOCK_ARM] = { arm },
+   [RPI_CLOCK_CORE] = { core },
+   [RPI_CLOCK_V3D] = { v3d },
+   [RPI_CLOCK_H264] = { h264 },
+   [RPI_CLOCK_ISP] = { isp },
+   [RPI_CLOCK_SDRAM] = { sdram },
+   [RPI_CLOCK_PIXEL] = { pixel },
+   [RPI_CLOCK_PWM] = { pwm },
+};
+
+static int rpi_clock_id(struct rpi_firmware_clock *rpi_clk)
+{
+   return rpi_clk - rpi_clocks;
+}
+
+static int rpi_clk_is_on(struct clk_hw *hw)
+{
+   struct rpi_firmware_clock *rpi_clk =
+   container_of(hw, struct rpi_firmware_clock, hw);
+   u32 packet[2];
+   int ret;
+
+   packet[0] = rpi_clock_id(rpi_clk);
+   packet[1] = 0;
+   ret = rpi_firmware_property(rpi_clk-firmware,
+   RPI_FIRMWARE_GET_CLOCK_STATE,
+   packet, sizeof(packet));
+   if (ret) {
+   dev_err(rpi_clk-dev, Failed to get clock state\n);
+   return 0;
+   }
+
+   return packet[1] != 0;
+}
+
+static int rpi_clk_set_state(struct clk_hw *hw, bool on)
+{
+   struct rpi_firmware_clock *rpi_clk =
+   container_of(hw, struct rpi_firmware_clock, hw);
+   u32 packet[2];
+   int ret;
+
+   packet[0] = rpi_clock_id(rpi_clk);
+   packet[1] = on;
+   ret = rpi_firmware_property(rpi_clk-firmware,
+   RPI_FIRMWARE_SET_CLOCK_STATE,
+   packet, sizeof(packet));
+   if (ret || (packet[1]  (1  1))) {
+   dev_err(rpi_clk-dev, Failed to set clock state\n);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int rpi_clk_on(struct clk_hw *hw)
+{
+   return rpi_clk_set_state(hw, true

[PATCH v3 1/7] dt/bindings: Add binding for the Raspberry Pi clock provider

[Eric Anholt]

The hardware clocks are not controllable by the ARM, so we have to
make requests to the firmware to do so from the VPU side.  This will
let us replace fixed clocks in our DT with actual clock control (and
correct frequency information).

v2: Include the dt-bindings header in this commit instead of the next
one.  Make the clock indices match the firmware clock IDs.  Rename
the binding's compat string.  Move the firmware phandle to be
under a vendor-specific namespace.

Signed-off-by: Eric Anholt e...@anholt.net
---
 .../clock/raspberrypi,bcm2835-firmware-clocks.txt  | 25 ++
 include/dt-bindings/clk/raspberrypi.h  | 23 
 2 files changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
 create mode 100644 include/dt-bindings/clk/raspberrypi.h

diff --git 
a/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
 
b/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
new file mode 100644
index 000..0972602
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
@@ -0,0 +1,25 @@
+Raspberry Pi firmware clock provider.
+
+The Raspberry Pi architecture doesn't provide direct access to the
+CLOCKMAN peripheral from the ARM side, so Linux has to make requests
+to the VPU firmware to program them.
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible:  Should be raspberrypi,bcm2835-firmware-clocks
+
+- #clock-cells:Shall have value 1.  The permitted 
clock-specifier
+ values can be found in
+ include/dt-bindings/clk/raspberrypi.h.
+
+- raspberrypi,firmware:Phandle to the firmware driver node.
+
+Example:
+
+firmware_clocks: firmware-clocks {
+   compatible = raspberrypi,bcm2835-firmware-clocks;
+   #clock-cells = 1;
+   raspberrypi,firmware = firmware;
+};
diff --git a/include/dt-bindings/clk/raspberrypi.h 
b/include/dt-bindings/clk/raspberrypi.h
new file mode 100644
index 000..ceec90f
--- /dev/null
+++ b/include/dt-bindings/clk/raspberrypi.h
@@ -0,0 +1,23 @@
+#/*
+ *  Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _DT_BINDINGS_CLK_RASPBERRYPI_H
+#define _DT_BINDINGS_CLK_RASPBERRYPI_H
+
+#define RPI_CLOCK_EMMC 1
+#define RPI_CLOCK_UART02
+#define RPI_CLOCK_ARM  3
+#define RPI_CLOCK_CORE 4
+#define RPI_CLOCK_V3D  5
+#define RPI_CLOCK_H264 6
+#define RPI_CLOCK_ISP  7
+#define RPI_CLOCK_SDRAM8
+#define RPI_CLOCK_PIXEL9
+#define RPI_CLOCK_PWM  10
+
+#endif
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 6/7] ARM: bcm2835: Use the RPi firmware clocks for uart.

[Eric Anholt]

This gets us a correct apb_pclk, which previously was accidentally
using the 20201000.uart clock from clk-bcm2835.c, due to the
fallback clk_get_sys() path.

Signed-off-by: Eric Anholt e...@anholt.net
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 7 +++
 arch/arm/boot/dts/bcm2835.dtsi | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 7cc47fb..9549eb8 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,3 +1,4 @@
+#include dt-bindings/clk/raspberrypi.h
 #include bcm2835.dtsi
 
 / {
@@ -62,3 +63,9 @@
status = okay;
bus-width = 4;
 };
+
+uart0 {
+   clocks = firmware_clocks RPI_CLOCK_UART0,
+firmware_clocks RPI_CLOCK_CORE;
+   clock-names = uartclk, apb_pclk;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 32f5830..5be2862 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -92,7 +92,7 @@
#interrupt-cells = 2;
};
 
-   uart@7e201000 {
+   uart0: uart@7e201000 {
compatible = brcm,bcm2835-pl011, arm,pl011, 
arm,primecell;
reg = 0x7e201000 0x1000;
interrupts = 2 25;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 3/7] ARM: bcm2835: Add DT for the firmware clocks driver.

[Eric Anholt]

v2: Rename our compat string to mention bcm2835, and make our firmware
phandle be under a vendor-namespaced property.

Signed-off-by: Eric Anholt e...@anholt.net
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index ab5474e..7cc47fb 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -20,6 +20,12 @@
compatible = raspberrypi,bcm2835-firmware;
mboxes = mailbox;
};
+
+   firmware_clocks: firmware-clocks {
+   compatible = raspberrypi,bcm2835-firmware-clocks;
+   #clock-cells = 1;
+   raspberrypi,firmware = firmware;
+   };
};
 };
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 4/7] ARM: bcm2835: Drop never-used clock-frequency property of uart0.

[Eric Anholt]

This appears to have been copy-and-paste from another serial driver's
DT.  The driver has never used this value -- instead, the pl011 driver
is getting the fixed 20201000.uart clock from clk-bcm2835.c.

Signed-off-by: Eric Anholt e...@anholt.net
---
 arch/arm/boot/dts/bcm2835.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 301c73f..32f5830 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -96,7 +96,6 @@
compatible = brcm,bcm2835-pl011, arm,pl011, 
arm,primecell;
reg = 0x7e201000 0x1000;
interrupts = 2 25;
-   clock-frequency = 300;
arm,primecell-periphid = 0x00241011;
};
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 7/7] ARM: bcm2835: Tie SPI clock to the core clock rate.

[Eric Anholt]

We were previously using a fixed clock declared in the 2835 DT, but
it's actually the core clock, and it might not be the same if you had
adjusted it using the firmware's config.txt.

Signed-off-by: Eric Anholt e...@anholt.net
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 9549eb8..0a32123 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -69,3 +69,7 @@
 firmware_clocks RPI_CLOCK_CORE;
clock-names = uartclk, apb_pclk;
 };
+
+spi {
+   clocks = firmware_clocks RPI_CLOCK_CORE;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 2/3] ARM: bcm2835: Add the Raspberry Pi firmware driver

[Eric Anholt]

This gives us a function for making mailbox property channel requests
of the firmware, which is most notable in that it will let us get and
set clock rates.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Drop power-domains stuff for now since we don't have the driver
core support to make it useful.  Move to drivers/firmware/.
Capitalize the enums.  De-global the firmware variable.  Use the
firmware device to allocate our DMA buffer, so that the dma-ranges
DT property gets respected.  Simplify the property tag transaction
interface even more, leaving a multi-tag interface still
available.  For conciseness, rename raspberrypi to rpi on all
functions/enums/structs, and the firmware variable to fw.
Print when the driver is probed successfully, since debugging
-EPROBE_DEFER handling is such a big part of bcm2835 development.
Drop -EBUSY mailbox handling since the mailbox core has been fixed
to return -EPROBE_DEFER in -next.

v3: Use kernel-doc style for big comments (from Noralf), drop stale
comment, use dev when freeing DMA as well.

v4: Move description comment into copyright comment, drop a dead
initialization of ret, and print the firmware revision at probe
time.

v5: Rename the compatible to raspberrypi,bcm2835-firmware, move
include to not say property, add functions to get struct
rpi_firmware from the device_node and put when done, make property
functions take the rpi_firmware instead and never return
-EPROBE_DEFER, put the driver under its own RASPBERRYPI_FIRMWARE
Kconfig.

v6: Drop the try_module_get/module_put stuff, since all clients will
be referencing our symbols in order to call those functions,
anyway.  Fix the kerneldoc comments for the changes in v5.

 drivers/firmware/Kconfig   |   7 +
 drivers/firmware/Makefile  |   1 +
 drivers/firmware/raspberrypi.c | 260 +
 include/soc/bcm2835/raspberrypi-firmware.h | 115 +
 4 files changed, 383 insertions(+)
 create mode 100644 drivers/firmware/raspberrypi.c
 create mode 100644 include/soc/bcm2835/raspberrypi-firmware.h

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 6517132..564aa5b 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -136,6 +136,13 @@ config QCOM_SCM
bool
depends on ARM || ARM64
 
+config RASPBERRYPI_FIRMWARE
+   tristate Raspberry Pi Firmware Driver
+   depends on BCM2835_MBOX
+   help
+ This option enables support for communicating with the firmware on the
+ Raspberry Pi.
+
 source drivers/firmware/google/Kconfig
 source drivers/firmware/efi/Kconfig
 
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 3fdd391..ee101a2 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ISCSI_IBFT)  += iscsi_ibft.o
 obj-$(CONFIG_FIRMWARE_MEMMAP)  += memmap.o
 obj-$(CONFIG_QCOM_SCM) += qcom_scm.o
 CFLAGS_qcom_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
+obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o
 
 obj-$(CONFIG_GOOGLE_FIRMWARE)  += google/
 obj-$(CONFIG_EFI)  += efi/
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
new file mode 100644
index 000..dd506cd
--- /dev/null
+++ b/drivers/firmware/raspberrypi.c
@@ -0,0 +1,260 @@
+/*
+ * Defines interfaces for interacting wtih the Raspberry Pi firmware's
+ * property channel.
+ *
+ * Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/dma-mapping.h
+#include linux/mailbox_client.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include soc/bcm2835/raspberrypi-firmware.h
+
+#define MBOX_MSG(chan, data28) (((data28)  ~0xf) | ((chan)  0xf))
+#define MBOX_CHAN(msg) ((msg)  0xf)
+#define MBOX_DATA28(msg)   ((msg)  ~0xf)
+#define MBOX_CHAN_PROPERTY 8
+
+struct rpi_firmware {
+   struct mbox_client cl;
+   struct mbox_chan *chan; /* The property channel. */
+   struct completion c;
+   u32 enabled;
+};
+
+static DEFINE_MUTEX(transaction_lock);
+
+static void response_callback(struct mbox_client *cl, void *msg)
+{
+   struct rpi_firmware *fw = container_of(cl, struct rpi_firmware, cl);
+   complete(fw-c);
+}
+
+/*
+ * Sends a request to the firmware through the BCM2835 mailbox driver,
+ * and synchronously waits for the reply.
+ */
+static int
+rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
+{
+   u32 message = MBOX_MSG(chan, data);
+   int ret;
+
+   WARN_ON(data  0xf);
+
+   mutex_lock(transaction_lock);
+   reinit_completion(fw-c);
+   ret = mbox_send_message

[PATCH v7 1/3] dt/bindings: Add binding for the Raspberry Pi firmware driver

[Eric Anholt]

This driver will provide support for calls into the firmware that will
be used by other drivers like cpufreq and vc4.

Acked-by: Stephen Warren swar...@wwwdotorg.org
Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Improve commit message, point to mailbox.txt for how mboxes work.
v3: Use Lee's suggestion for mailbox phandle docs, fix spelling of
raspberry.
v4: Change the compatible string to raspberrypi,bcm2835-firmware
(requested by Lee, agreed by Stephen)
v5: Add missing s-o-b, fix spelling.

 .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt

diff --git 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
new file mode 100644
index 000..6824b31
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
@@ -0,0 +1,14 @@
+Raspberry Pi VideoCore firmware driver
+
+Required properties:
+
+- compatible:  Should be raspberrypi,bcm2835-firmware
+- mboxes:  Phandle to the firmware device's Mailbox.
+ (See: ../mailbox/mailbox.txt for more information)
+
+Example:
+
+firmware {
+   compatible = raspberrypi,bcm2835-firmware;
+   mboxes = mailbox;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 3/3] ARM: bcm2835: Add the firmware driver information to the RPi DT

[Eric Anholt]

Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Lee Jones l...@kernel.org (previous version with pm-domains)
Acked-by: Stephen Warren swar...@wwwdotorg.org
---

v2: Drop pm-domains stuff since I've dropped it from the firmware
driver for now, until we get drivers/base fixed.

v3: Rename the compatible to raspberrypi,bcm2835-firmware

 arch/arm/boot/dts/bcm2835-rpi.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 46780bb..ab5474e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -14,6 +14,13 @@
linux,default-trigger = heartbeat;
};
};
+
+   soc {
+   firmware: firmware {
+   compatible = raspberrypi,bcm2835-firmware;
+   mboxes = mailbox;
+   };
+   };
 };
 
 gpio {
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3 v4] ARM: bcm2835: Add the Raspberry Pi firmware driver

[Eric Anholt]

Noralf Trønnes nor...@tronnes.org writes:

 Den 28.05.2015 20:33, skrev Eric Anholt:
 This gives us a function for making mailbox property channel requests
 of the firmware, which is most notable in that it will let us get and
 set clock rates.

 Signed-off-by: Eric Anholt e...@anholt.net
 ...
 +static int rpi_firmware_probe(struct platform_device *pdev)
 +{
 +struct device *dev = pdev-dev;
 +struct rpi_firmware *fw;
 +
 +fw = devm_kzalloc(dev, sizeof(*fw), GFP_KERNEL);
 +if (!fw)
 +return -ENOMEM;
 +
 +fw-cl.dev = dev;
 +fw-cl.rx_callback = response_callback;
 +fw-cl.tx_block = true;
 +
 +fw-chan = mbox_request_channel(fw-cl, 0);
 +if (IS_ERR(fw-chan)) {
 +int ret = PTR_ERR(fw-chan);
 +if (ret != -EPROBE_DEFER)
 +dev_err(dev, Failed to get mbox channel: %d\n, ret);
 +return ret;
 +}
 +
 +init_completion(fw-c);
 +
 +platform_set_drvdata(pdev, fw);
 +
 +rpi_firmware_print_firmware_revision(dev);
 +
 +return 0;
 +}
 +
 +static int rpi_firmware_remove(struct platform_device *pdev)
 +{
 +struct rpi_firmware *fw = platform_get_drvdata(pdev);
 +
 +mbox_free_channel(fw-chan);

 I guess driver data has to be reset here:
 platform_set_drvdata(pdev, NULL);

Fixed.


signature.asc
Description: PGP signature

Re: [PATCH 2/3 v4] ARM: bcm2835: Add the Raspberry Pi firmware driver

[Eric Anholt]

Stephen Warren swar...@wwwdotorg.org writes:

 On 05/28/2015 12:33 PM, Eric Anholt wrote:
 This gives us a function for making mailbox property channel requests
 of the firmware, which is most notable in that it will let us get and
 set clock rates.

 This thread was rather hard to follow since updated versions of patches
 were sent in response to the original posting rather than as a new
 thread. Generally it's best to post a complete copy of each new version
 of the series, and as a completely standalone thread.

Will do.

 diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile

 +obj-$(CONFIG_BCM2835_MBOX)  += raspberrypi.o

 I think this warrants its own Kconfig option that depends on _MBOX.

Done, called it RASPBERRPI_FIRMWARE

 diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c

 +int rpi_firmware_property_list(struct device_node *of_node,
 +   void *data, size_t tag_size)
 +{
 +struct platform_device *pdev = of_find_device_by_node(of_node);

 I would expect the of_node - pdev mapping to happen at client device
 probe time. Simplest for this driver would be if the
 client-probe-time-mapping function returned the struct rpi_firmware
 and the client passed that to this function.

Done.

 +struct rpi_firmware *fw = platform_get_drvdata(pdev);
 +size_t size = tag_size + 12;
 +u32 *buf;
 +dma_addr_t bus_addr;
 +int ret;
 +
 +if (!fw)
 +return -EPROBE_DEFER;

 That return code should only be used in functions called at probe time.
 While I do see the expectation is that clients call this function once
 at probe time and hence guarantee to see -EPROBE_DEFER at probe time (if
 at all), it's rather odd for a function that's intended to be called at
 times other that probe() to ever have the possibility of returning
 -EPROBE_DEFER. If somehow that values gets returned at another time,
 it's going to be rather confusing to the client.

Dropped now that I'm passing fw in.

 +buf[0] = size;
 +buf[1] = RPI_FIRMWARE_STATUS_REQUEST;
 +memcpy(buf[2], data, tag_size);
 +buf[size / 4 - 1] = RPI_FIRMWARE_PROPERTY_END;

 Out of curiosity, why not require the client to format the entire
 message itself? In theory at least, the client could submit a whole
 string of tags at once, so it really seems like the client should be
 constructing the whole message.

Because it's something extra for the client to screw up?  I mean, if we
were going for super high performance, we'd have the client asking us
for a DMA buffer to write into, and they'd write the whole thing, and
submit that back to us.  But we don't need that, because the property
channel is used so rarely.

I briefly used multi-tag in a not-for-upstream KMS-using-the-firmware
branch, but it turned out the FB MBOX channel was strictly better (once
I worked around a fw bug).


signature.asc
Description: PGP signature

Re: [PATCH] mailbox/bcm2835: Fix mailbox full detection.

[Eric Anholt]

Stephen Warren swar...@wwwdotorg.org writes:

 On 05/13/2015 02:10 PM, Eric Anholt wrote:
 With the VC reader blocked and the ARM writing, MAIL0_STA reads empty
 permanently while MAIL1_STA goes from empty (0x4000) to non-empty
 (0x0001-0x0007) to full (0x8008).

 This bug ended up having no effect on us, because all of our
 transactions in the client driver were synchronous and under a mutex.

 If you could get someone at the RPi Foundation or Broadcom to update the 
 register descriptions and example code at the following URLs, that would 
 be rather useful. Otherwise, this code will appear incorrect when 
 compared against the documentation:

 https://github.com/raspberrypi/firmware/wiki/Mailboxes
 (Mailbox registers at the bottom)

 https://github.com/raspberrypi/firmware/wiki/Accessing-mailboxes
 (Sample code)

Since it's a wiki, I went ahead and edited the first one.  Hopefully
that clarifies how the c++ in the other page is supposed to be used.

 diff --git a/drivers/mailbox/bcm2835-mailbox.c 
 b/drivers/mailbox/bcm2835-mailbox.c

 @@ -117,7 +118,7 @@ static bool bcm2835_last_tx_done(struct mbox_chan *link)
  bool ret;

  spin_lock(mbox-lock);
 -ret = !(readl(mbox-regs + MAIL0_STA)  ARM_MS_FULL);
 +ret = !(readl(mbox-regs + MAIL1_STA)  ARM_MS_FULL);

 What does tx done mean semantically?

 If tx done means remote side received all our messages, then surely 
 this should check MAIL1_STA for emptiness, which is different to the 
 not full check implemented here?

 If tx done means there's space to transmit more messages, then 
 consider this:

The mailbox core appears to use this hook as there's space to transmit
more messages.  The name does seem really confusing.


signature.asc
Description: PGP signature

[PATCH 2/7 v2] ARM: bcm2835: Add a Raspberry Pi-specific clock driver.

[Eric Anholt]

Unfortunately, the clock manager's registers are not accessible by the
ARM, so we have to request that the firmware modify our clocks for us.

This driver only registers the clocks at the point they are requested
by a client driver.  This is partially to support returning
-EPROBE_DEFER when the firmware driver isn't supported yet, but it
also avoids issues with disabling unused clocks due to them not yet
being connected to their consumers in the DT.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Declare the mutex static (from review by Baruch Siach), merge
description and copyright comments.

 drivers/clk/Makefile  |   1 +
 drivers/clk/clk-raspberrypi.c | 239 ++
 include/dt-bindings/clk/raspberrypi.h |  23 
 3 files changed, 263 insertions(+)
 create mode 100644 drivers/clk/clk-raspberrypi.c
 create mode 100644 include/dt-bindings/clk/raspberrypi.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 3d00c25..6a5dafa 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MACH_ASM9260)+= clk-asm9260.o
 obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)+= clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)   += clk-axm5516.o
 obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
+obj-$(CONFIG_ARCH_BCM2835) += clk-raspberrypi.o
 obj-$(CONFIG_COMMON_CLK_CDCE706)   += clk-cdce706.o
 obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
 obj-$(CONFIG_ARCH_EFM32)   += clk-efm32gg.o
diff --git a/drivers/clk/clk-raspberrypi.c b/drivers/clk/clk-raspberrypi.c
new file mode 100644
index 000..b9d8f44
--- /dev/null
+++ b/drivers/clk/clk-raspberrypi.c
@@ -0,0 +1,239 @@
+/*
+ * Implements a clock provider for the clocks controlled by the
+ * firmware on Raspberry Pi.
+ *
+ * These clocks are controlled by the CLOCKMAN peripheral in the
+ * hardware, but the ARM doesn't have access to the registers for
+ * them.  As a result, we have to call into the firmware to get it to
+ * enable, disable, and set their frequencies.
+ *
+ * We don't have an interface for getting the set of frequencies
+ * available from the hardware.  We can request a min/max, but other
+ * than that we have to request a frequency and take what it gives us.
+ *
+ * Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/clk/raspberrypi.h
+#include linux/clk-provider.h
+#include soc/bcm2835/raspberrypi-firmware-property.h
+
+struct rpi_firmware_clock {
+   /* Clock definitions in our static struct. */
+   int clock_id;
+   const char *name;
+
+   /* The rest are filled in at init time. */
+   struct clk_hw hw;
+   struct device *dev;
+   struct device_node *firmware_node;
+};
+
+static struct rpi_firmware_clock rpi_clocks[] = {
+   [RPI_CLOCK_EMMC] = { 1, emmc },
+   [RPI_CLOCK_UART0] = { 2, uart0 },
+   [RPI_CLOCK_ARM] = { 3, arm },
+   [RPI_CLOCK_CORE] = { 4, core },
+   [RPI_CLOCK_V3D] = { 5, v3d },
+   [RPI_CLOCK_H264] = { 6, h264 },
+   [RPI_CLOCK_ISP] = { 7, isp },
+   [RPI_CLOCK_SDRAM] = { 8, sdram },
+   [RPI_CLOCK_PIXEL] = { 9, pixel },
+   [RPI_CLOCK_PWM] = { 10, pwm },
+};
+
+static int rpi_clk_is_on(struct clk_hw *hw)
+{
+   struct rpi_firmware_clock *rpi_clk =
+   container_of(hw, struct rpi_firmware_clock, hw);
+   u32 packet[2];
+   int ret;
+
+   packet[0] = rpi_clk-clock_id;
+   packet[1] = 0;
+   ret = rpi_firmware_property(rpi_clk-firmware_node,
+   RPI_FIRMWARE_GET_CLOCK_STATE,
+   packet, sizeof(packet));
+   if (ret) {
+   dev_err(rpi_clk-dev, Failed to get clock state\n);
+   return 0;
+   }
+
+   return packet[1] != 0;
+}
+
+static int rpi_clk_set_state(struct rpi_firmware_clock *rpi_clk, bool on)
+{
+   u32 packet[2];
+   int ret;
+
+   packet[0] = rpi_clk-clock_id;
+   packet[1] = on;
+   ret = rpi_firmware_property(rpi_clk-firmware_node,
+   RPI_FIRMWARE_SET_CLOCK_STATE,
+   packet, sizeof(packet));
+   if (ret || (packet[1]  (1  1))) {
+   dev_err(rpi_clk-dev, Failed to set clock state\n);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int rpi_clk_on(struct clk_hw *hw)
+{
+   struct rpi_firmware_clock *rpi_clk =
+   container_of(hw, struct rpi_firmware_clock, hw);
+
+   return rpi_clk_set_state(rpi_clk, true);
+}
+
+static void rpi_clk_off(struct clk_hw *hw)
+{
+   struct rpi_firmware_clock *rpi_clk =
+   container_of(hw, struct rpi_firmware_clock, hw);
+
+   rpi_clk_set_state(rpi_clk, false);
+}
+
+static unsigned

[PATCH 2/3 v4] ARM: bcm2835: Add the Raspberry Pi firmware driver

[Eric Anholt]

This gives us a function for making mailbox property channel requests
of the firmware, which is most notable in that it will let us get and
set clock rates.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Drop power-domains stuff for now since we don't have the driver
core support to make it useful.  Move to drivers/firmware/.
Capitalize the enums.  De-global the firmware variable.  Use the
firmware device to allocate our DMA buffer, so that the dma-ranges
DT property gets respected.  Simplify the property tag transaction
interface even more, leaving a multi-tag interface still
available.  For conciseness, rename raspberrypi to rpi on all
functions/enums/structs, and the firmware variable to fw.
Print when the driver is probed successfully, since debugging
-EPROBE_DEFER handling is such a big part of bcm2835 development.
Drop -EBUSY mailbox handling since the mailbox core has been fixed
to return -EPROBE_DEFER in -next.

v3: Use kernel-doc style for big comments (from Noralf), drop stale
comment, use dev when freeing DMA as well.

v4: Move description comment into copyright comment, drop a dead
initialization of ret, and print the firmware revision at probe
time.

 drivers/firmware/Makefile  |   1 +
 drivers/firmware/raspberrypi.c | 248 +
 .../soc/bcm2835/raspberrypi-firmware-property.h| 112 ++
 3 files changed, 361 insertions(+)
 create mode 100644 drivers/firmware/raspberrypi.c
 create mode 100644 include/soc/bcm2835/raspberrypi-firmware-property.h

diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 3fdd391..41ced28 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ISCSI_IBFT)  += iscsi_ibft.o
 obj-$(CONFIG_FIRMWARE_MEMMAP)  += memmap.o
 obj-$(CONFIG_QCOM_SCM) += qcom_scm.o
 CFLAGS_qcom_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
+obj-$(CONFIG_BCM2835_MBOX) += raspberrypi.o
 
 obj-$(CONFIG_GOOGLE_FIRMWARE)  += google/
 obj-$(CONFIG_EFI)  += efi/
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
new file mode 100644
index 000..e121467
--- /dev/null
+++ b/drivers/firmware/raspberrypi.c
@@ -0,0 +1,248 @@
+/*
+ * Defines interfaces for interacting wtih the Raspberry Pi firmware's
+ * property channel.
+ *
+ * Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/dma-mapping.h
+#include linux/mailbox_client.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include soc/bcm2835/raspberrypi-firmware-property.h
+
+#define MBOX_MSG(chan, data28) (((data28)  ~0xf) | ((chan)  0xf))
+#define MBOX_CHAN(msg) ((msg)  0xf)
+#define MBOX_DATA28(msg)   ((msg)  ~0xf)
+#define MBOX_CHAN_PROPERTY 8
+
+struct rpi_firmware {
+   struct mbox_client cl;
+   struct mbox_chan *chan; /* The property channel. */
+   struct completion c;
+   u32 enabled;
+};
+
+static DEFINE_MUTEX(transaction_lock);
+
+static void response_callback(struct mbox_client *cl, void *msg)
+{
+   struct rpi_firmware *fw = container_of(cl, struct rpi_firmware, cl);
+   complete(fw-c);
+}
+
+/*
+ * Sends a request to the firmware through the BCM2835 mailbox driver,
+ * and synchronously waits for the reply.
+ */
+static int
+rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
+{
+   u32 message = MBOX_MSG(chan, data);
+   int ret;
+
+   WARN_ON(data  0xf);
+
+   mutex_lock(transaction_lock);
+   reinit_completion(fw-c);
+   ret = mbox_send_message(fw-chan, message);
+   if (ret = 0) {
+   wait_for_completion(fw-c);
+   ret = 0;
+   } else {
+   dev_err(fw-cl.dev, mbox_send_message returned %d\n, ret);
+   }
+   mutex_unlock(transaction_lock);
+
+   return ret;
+}
+
+/**
+ * rpi_firmware_property_list - Submit firmware property list
+ * @of_node:   Pointer to the firmware Device Tree node.
+ * @data:  Buffer holding tags.
+ * @tag_size:  Size of tags buffer.
+ *
+ * Submits a set of concatenated tags to the VPU firmware through the
+ * mailbox property interface.
+ *
+ * The buffer header and the ending tag are added by this function and
+ * don't need to be supplied, just the actual tags for your operation.
+ * See struct rpi_firmware_property_tag_header for the per-tag
+ * structure.
+ */
+int rpi_firmware_property_list(struct device_node *of_node,
+  void *data, size_t tag_size)
+{
+   struct platform_device *pdev = of_find_device_by_node(of_node);
+   struct rpi_firmware *fw = platform_get_drvdata(pdev);
+   size_t size = tag_size + 12

[PATCH v5 3/3] ARM: bcm2835: Add the firmware driver information to the RPi DT

[Eric Anholt]

v2: Drop pm-domains stuff since I've dropped it from the firmware
driver for now, until we get drivers/base fixed.

v3: Rename the compatible to raspberrypi,bcm2835-firmware

Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Lee Jones l...@kernel.org (previous version with pm-domains)
Acked-by: Stephen Warren swar...@wwwdotorg.org
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 46780bb..ab5474e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -14,6 +14,13 @@
linux,default-trigger = heartbeat;
};
};
+
+   soc {
+   firmware: firmware {
+   compatible = raspberrypi,bcm2835-firmware;
+   mboxes = mailbox;
+   };
+   };
 };
 
 gpio {
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 2/3] ARM: bcm2835: Add the Raspberry Pi firmware driver

[Eric Anholt]

This gives us a function for making mailbox property channel requests
of the firmware, which is most notable in that it will let us get and
set clock rates.

v2: Drop power-domains stuff for now since we don't have the driver
core support to make it useful.  Move to drivers/firmware/.
Capitalize the enums.  De-global the firmware variable.  Use the
firmware device to allocate our DMA buffer, so that the dma-ranges
DT property gets respected.  Simplify the property tag transaction
interface even more, leaving a multi-tag interface still
available.  For conciseness, rename raspberrypi to rpi on all
functions/enums/structs, and the firmware variable to fw.
Print when the driver is probed successfully, since debugging
-EPROBE_DEFER handling is such a big part of bcm2835 development.
Drop -EBUSY mailbox handling since the mailbox core has been fixed
to return -EPROBE_DEFER in -next.

v3: Use kernel-doc style for big comments (from Noralf), drop stale
comment, use dev when freeing DMA as well.

v4: Move description comment into copyright comment, drop a dead
initialization of ret, and print the firmware revision at probe
time.

v5: Rename the compatible to raspberrypi,bcm2835-firmware, move
include to not say property, add functions to get struct
rpi_firmware from the device_node and put when done, make property
functions take the rpi_firmware instead and never return
-EPROBE_DEFER, put the driver under its own RASPBERRYPI_FIRMWARE
Kconfig.

Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/firmware/Kconfig   |   7 +
 drivers/firmware/Makefile  |   1 +
 drivers/firmware/raspberrypi.c | 272 +
 include/soc/bcm2835/raspberrypi-firmware.h | 116 
 4 files changed, 396 insertions(+)
 create mode 100644 drivers/firmware/raspberrypi.c
 create mode 100644 include/soc/bcm2835/raspberrypi-firmware.h

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 6517132..564aa5b 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -136,6 +136,13 @@ config QCOM_SCM
bool
depends on ARM || ARM64
 
+config RASPBERRYPI_FIRMWARE
+   tristate Raspberry Pi Firmware Driver
+   depends on BCM2835_MBOX
+   help
+ This option enables support for communicating with the firmware on the
+ Raspberry Pi.
+
 source drivers/firmware/google/Kconfig
 source drivers/firmware/efi/Kconfig
 
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 3fdd391..ee101a2 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ISCSI_IBFT)  += iscsi_ibft.o
 obj-$(CONFIG_FIRMWARE_MEMMAP)  += memmap.o
 obj-$(CONFIG_QCOM_SCM) += qcom_scm.o
 CFLAGS_qcom_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
+obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o
 
 obj-$(CONFIG_GOOGLE_FIRMWARE)  += google/
 obj-$(CONFIG_EFI)  += efi/
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
new file mode 100644
index 000..e4a033a
--- /dev/null
+++ b/drivers/firmware/raspberrypi.c
@@ -0,0 +1,272 @@
+/*
+ * Defines interfaces for interacting wtih the Raspberry Pi firmware's
+ * property channel.
+ *
+ * Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/dma-mapping.h
+#include linux/mailbox_client.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include soc/bcm2835/raspberrypi-firmware.h
+
+#define MBOX_MSG(chan, data28) (((data28)  ~0xf) | ((chan)  0xf))
+#define MBOX_CHAN(msg) ((msg)  0xf)
+#define MBOX_DATA28(msg)   ((msg)  ~0xf)
+#define MBOX_CHAN_PROPERTY 8
+
+struct rpi_firmware {
+   struct mbox_client cl;
+   struct mbox_chan *chan; /* The property channel. */
+   struct completion c;
+   u32 enabled;
+};
+
+static DEFINE_MUTEX(transaction_lock);
+
+static void response_callback(struct mbox_client *cl, void *msg)
+{
+   struct rpi_firmware *fw = container_of(cl, struct rpi_firmware, cl);
+   complete(fw-c);
+}
+
+/*
+ * Sends a request to the firmware through the BCM2835 mailbox driver,
+ * and synchronously waits for the reply.
+ */
+static int
+rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
+{
+   u32 message = MBOX_MSG(chan, data);
+   int ret;
+
+   WARN_ON(data  0xf);
+
+   mutex_lock(transaction_lock);
+   reinit_completion(fw-c);
+   ret = mbox_send_message(fw-chan, message);
+   if (ret = 0) {
+   wait_for_completion(fw-c);
+   ret = 0;
+   } else {
+   dev_err(fw-cl.dev, mbox_send_message returned %d\n, ret

[PATCH v5 1/3] dt/bindings: Add binding for the Raspberry Pi firmware driver

[Eric Anholt]

This driver will provide support for calls into the firmware that will
be used by other drivers like cpufreq and vc4.

v2: Improve commit message, point to mailbox.txt for how mboxes work.
v3: Use Lee's suggestion for mailbox phandle docs, fix spelling of
raspberry.
v4: Change the compatible string to raspberrypi,bcm2835-firmware
(requested by Lee, agreed by Stephen)

Acked-by: Stephen Warren swar...@wwwdotorg.org
---
 .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt

diff --git 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
new file mode 100644
index 000..5fb1868
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
@@ -0,0 +1,14 @@
+Raspberry Pi VideoCore firmware driver
+
+Required properties:
+
+- compatible:  Should be rasbperrypi,bcm2835-firmware
+- mboxes:  Phandle to the firmware device's Mailbox.
+ (See: ../mailbox/mailbox.txt for more information)
+
+Example:
+
+firmware {
+   compatible = raspberrypi,bcm2835-firmware;
+   mboxes = mailbox;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: sdhci-bcm2835: Actually enable the clock

[Eric Anholt]

We're currently using a fixed frequency clock specified in the DT, so
enabling is a no-op.  However, the RPi firmware-based clocks driver
can actually disable unused clocks, so when switching to use it we
ended up losing our MMC clock once all devices were probed.

Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/mmc/host/sdhci-bcm2835.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index 0ef0343..09aff3a 100644
--- a/drivers/mmc/host/sdhci-bcm2835.c
+++ b/drivers/mmc/host/sdhci-bcm2835.c
@@ -172,6 +172,11 @@ static int bcm2835_sdhci_probe(struct platform_device 
*pdev)
ret = PTR_ERR(pltfm_host-clk);
goto err;
}
+   ret = clk_prepare_enable(pltfm_host-clk);
+   if (ret) {
+   dev_err(pdev-dev, failed to enable host clk\n);
+   goto err;
+   }
 
return sdhci_add_host(host);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 2/3] ARM: bcm2835: Add the Raspberry Pi firmware driver

[Eric Anholt]

Paul Bolle pebo...@tiscali.nl writes:

 On Fri, 2015-05-29 at 12:42 -0700, Eric Anholt wrote:
 This gives us a function for making mailbox property channel requests
 of the firmware, which is most notable in that it will let us get and
 set clock rates.

 v6: Drop the try_module_get/module_put stuff, since all clients will
 be referencing our symbols in order to call those functions,
 anyway.  Fix the kerneldoc comments for the changes in v5.

 (This style of commit explanation is getting quite common. I must say I
 rather dislike it. I think people should just update the entire commit
 explanation when needed, and not simply paste any changes at the end of
 it, thereby forcing the the reader to determine which older parts are
 actually overruled by newer parts. Besides, many, or maybe even most, of
 the changes are really not interesting enough to keep in the commit
 explanation.)

It was a slip-up that I didn't move it below the '---'this time (I
changed my workflow a bit, and missed the step).  I was assuming that
Lee would just trim them on pulling in the changes.

 --- /dev/null
 +++ b/drivers/firmware/raspberrypi.c

 +EXPORT_SYMBOL_GPL(rpi_firmware_property_list);

 +EXPORT_SYMBOL_GPL(rpi_firmware_property);

 A patch that uses these exports hit lkml recently:
 https://lkml.org/lkml/2015/5/28/596 .

 +EXPORT_SYMBOL_GPL(rpi_firmware_get);

 But I didn't spot a (recent) patch that uses this export. Is it queued
 somewhere?

This is from the v5 changes due to review feedback, and the clients need
to be changed to use it.


signature.asc
Description: PGP signature

Re: [PATCH 5/7] ARM: bcm2835: Drop the fixed sys_pclk.

[Eric Anholt]

Stephen Warren swar...@wwwdotorg.org writes:

 On 05/18/2015 01:43 PM, Eric Anholt wrote:
 Nothing uses it, and I can't find any evidence that anything ever has.

 Does the clock actually exist though? If it does, it seems reasonable to
 keep it.

Yes, it's kept in the form of the core clock in the RPi driver, and the
clock-frequency values in spi and i2c in bcm2835.dtsi.


signature.asc
Description: PGP signature

Re: [PATCH 2/7] ARM: bcm2835: Add a Raspberry Pi-specific clock driver.

[Eric Anholt]

Stephen Boyd sb...@codeaurora.org writes:

 On 05/28, Stephen Warren wrote:
 On 05/18/2015 01:43 PM, Eric Anholt wrote:
  Unfortunately, the clock manager's registers are not accessible by the
  ARM, so we have to request that the firmware modify our clocks for us.
  
  This driver only registers the clocks at the point they are requested
  by a client driver.  This is partially to support returning
  -EPROBE_DEFER when the firmware driver isn't supported yet, but it
  also avoids issues with disabling unused clocks due to them not yet
  being connected to their consumers in the DT.
 
 It looks like you forgot to CC the clock subsystem maintainers:
 
 M:  Mike Turquette mturque...@linaro.org
 M:  Stephen Boyd sb...@codeaurora.org
 

 Thanks, except I don't have the full patch context here to review
 the patch.

 The description above sounds like a neat solution, but has the
 disadvantage that the clocks without a client won't show up in debugfs.
 I wonder if the clock maintainers know of a better way?

 Can you mark them as CLK_IGNORE_UNUSED? The probe defer problem
 has a solution in sight (see more below).

  +  init.flags = CLK_IS_ROOT;
 
 Is it possible to add clock parent information to the driver, so the
 clocks are all hooked together into the correct tree, rather than all
 looking like root clocks?
 
 One of the many reasons I didn't do anything FW-wise for the kernel was
 the hope that such information would be forthcoming, and hence we could
 have complete kernel drivers.
 
  +void __init rpi_firmware_init_clock_provider(struct device_node *node)
  +{
  +  /* We delay construction of our struct clks until get time,
  +   * because we need to be able to return -EPROBE_DEFER if the
  +   * firmware driver isn't up yet.  clk core doesn't support
  +   * re-probing on -EPROBE_DEFER, but callers of clk_get can.
 
 Oh, that's nasty. What would it take to fix the clock core to support
 deferred probe? It really should.

 There are patches to support probe defer from clk_get() but they
 stalled because sunxi is needs to keep clocks on from their
 providing driver (termed critical clocks). If we can resolve
 the critical clocks thing then we should be able to support
 probe defer, unless we find other users of orphaned clk
 pointers.

Great!  I'm certainly happy to switch to a normal registration of all my
clocks once -EPROBE_DEFER works from the clock provider init.

If those patches aren't landing this release, that also gives us a
release to wire up all the clock consumers in the DT before we get hit
by stable DT ABI, so we'll be able to give a nice limited set of
CLOCK_IGNORE_UNUSED in the flags when we transition.


signature.asc
Description: PGP signature

[PATCH v6 2/3] ARM: bcm2835: Add the Raspberry Pi firmware driver

[Eric Anholt]

This gives us a function for making mailbox property channel requests
of the firmware, which is most notable in that it will let us get and
set clock rates.

v2: Drop power-domains stuff for now since we don't have the driver
core support to make it useful.  Move to drivers/firmware/.
Capitalize the enums.  De-global the firmware variable.  Use the
firmware device to allocate our DMA buffer, so that the dma-ranges
DT property gets respected.  Simplify the property tag transaction
interface even more, leaving a multi-tag interface still
available.  For conciseness, rename raspberrypi to rpi on all
functions/enums/structs, and the firmware variable to fw.
Print when the driver is probed successfully, since debugging
-EPROBE_DEFER handling is such a big part of bcm2835 development.
Drop -EBUSY mailbox handling since the mailbox core has been fixed
to return -EPROBE_DEFER in -next.

v3: Use kernel-doc style for big comments (from Noralf), drop stale
comment, use dev when freeing DMA as well.

v4: Move description comment into copyright comment, drop a dead
initialization of ret, and print the firmware revision at probe
time.

v5: Rename the compatible to raspberrypi,bcm2835-firmware, move
include to not say property, add functions to get struct
rpi_firmware from the device_node and put when done, make property
functions take the rpi_firmware instead and never return
-EPROBE_DEFER, put the driver under its own RASPBERRYPI_FIRMWARE
Kconfig.

v6: Drop the try_module_get/module_put stuff, since all clients will
be referencing our symbols in order to call those functions,
anyway.  Fix the kerneldoc comments for the changes in v5.

Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/firmware/Kconfig   |   7 +
 drivers/firmware/Makefile  |   1 +
 drivers/firmware/raspberrypi.c | 260 +
 include/soc/bcm2835/raspberrypi-firmware.h | 115 +
 4 files changed, 383 insertions(+)
 create mode 100644 drivers/firmware/raspberrypi.c
 create mode 100644 include/soc/bcm2835/raspberrypi-firmware.h

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 6517132..564aa5b 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -136,6 +136,13 @@ config QCOM_SCM
bool
depends on ARM || ARM64
 
+config RASPBERRYPI_FIRMWARE
+   tristate Raspberry Pi Firmware Driver
+   depends on BCM2835_MBOX
+   help
+ This option enables support for communicating with the firmware on the
+ Raspberry Pi.
+
 source drivers/firmware/google/Kconfig
 source drivers/firmware/efi/Kconfig
 
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 3fdd391..ee101a2 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_ISCSI_IBFT)  += iscsi_ibft.o
 obj-$(CONFIG_FIRMWARE_MEMMAP)  += memmap.o
 obj-$(CONFIG_QCOM_SCM) += qcom_scm.o
 CFLAGS_qcom_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
+obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += raspberrypi.o
 
 obj-$(CONFIG_GOOGLE_FIRMWARE)  += google/
 obj-$(CONFIG_EFI)  += efi/
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
new file mode 100644
index 000..dd506cd
--- /dev/null
+++ b/drivers/firmware/raspberrypi.c
@@ -0,0 +1,260 @@
+/*
+ * Defines interfaces for interacting wtih the Raspberry Pi firmware's
+ * property channel.
+ *
+ * Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/dma-mapping.h
+#include linux/mailbox_client.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include soc/bcm2835/raspberrypi-firmware.h
+
+#define MBOX_MSG(chan, data28) (((data28)  ~0xf) | ((chan)  0xf))
+#define MBOX_CHAN(msg) ((msg)  0xf)
+#define MBOX_DATA28(msg)   ((msg)  ~0xf)
+#define MBOX_CHAN_PROPERTY 8
+
+struct rpi_firmware {
+   struct mbox_client cl;
+   struct mbox_chan *chan; /* The property channel. */
+   struct completion c;
+   u32 enabled;
+};
+
+static DEFINE_MUTEX(transaction_lock);
+
+static void response_callback(struct mbox_client *cl, void *msg)
+{
+   struct rpi_firmware *fw = container_of(cl, struct rpi_firmware, cl);
+   complete(fw-c);
+}
+
+/*
+ * Sends a request to the firmware through the BCM2835 mailbox driver,
+ * and synchronously waits for the reply.
+ */
+static int
+rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
+{
+   u32 message = MBOX_MSG(chan, data);
+   int ret;
+
+   WARN_ON(data  0xf);
+
+   mutex_lock(transaction_lock);
+   reinit_completion(fw-c);
+   ret = mbox_send_message(fw

[PATCH v6 1/3] dt/bindings: Add binding for the Raspberry Pi firmware driver

[Eric Anholt]

This driver will provide support for calls into the firmware that will
be used by other drivers like cpufreq and vc4.

v2: Improve commit message, point to mailbox.txt for how mboxes work.
v3: Use Lee's suggestion for mailbox phandle docs, fix spelling of
raspberry.
v4: Change the compatible string to raspberrypi,bcm2835-firmware
(requested by Lee, agreed by Stephen)

Acked-by: Stephen Warren swar...@wwwdotorg.org
---
 .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt

diff --git 
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt 
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
new file mode 100644
index 000..5fb1868
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
@@ -0,0 +1,14 @@
+Raspberry Pi VideoCore firmware driver
+
+Required properties:
+
+- compatible:  Should be rasbperrypi,bcm2835-firmware
+- mboxes:  Phandle to the firmware device's Mailbox.
+ (See: ../mailbox/mailbox.txt for more information)
+
+Example:
+
+firmware {
+   compatible = raspberrypi,bcm2835-firmware;
+   mboxes = mailbox;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 3/3] ARM: bcm2835: Add the firmware driver information to the RPi DT

[Eric Anholt]

v2: Drop pm-domains stuff since I've dropped it from the firmware
driver for now, until we get drivers/base fixed.

v3: Rename the compatible to raspberrypi,bcm2835-firmware

Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Lee Jones l...@kernel.org (previous version with pm-domains)
Acked-by: Stephen Warren swar...@wwwdotorg.org
---
 arch/arm/boot/dts/bcm2835-rpi.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 46780bb..ab5474e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -14,6 +14,13 @@
linux,default-trigger = heartbeat;
};
};
+
+   soc {
+   firmware: firmware {
+   compatible = raspberrypi,bcm2835-firmware;
+   mboxes = mailbox;
+   };
+   };
 };
 
 gpio {
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/7] ARM: bcm2835: Add a Raspberry Pi-specific clock driver.

[Eric Anholt]

Stephen Warren swar...@wwwdotorg.org writes:

 On 05/18/2015 01:43 PM, Eric Anholt wrote:
  obj-$(CONFIG_ARCH_BCM2835)  += clk-bcm2835.o
 +obj-$(CONFIG_ARCH_BCM2835)  += clk-raspberrypi.o

 Shouldn't this replace the old legacy code in clk-bcm2835.c?

I don't think we can, because of DT backwards compat (Sigh).

 I wonder if a separate Kconfig symbol is warranted for the clock driver.
 Looking at the context in the patch, it's common not to do that though.

I've moved it under RASPBERRYPI_FIRMWARE, since it needs that to build.

 diff --git a/drivers/clk/clk-raspberrypi.c b/drivers/clk/clk-raspberrypi.c

 +struct rpi_firmware_clock {
 +/* Clock definitions in our static struct. */
 +int clock_id;

 Why not just use the raw HW IDs (from the mailbox protocol) as the ID in
 DT and the driver? The only thing that would need to change is to add a
 error check for clkspec-args[0] == 0 in
 rpi_firmware_delayed_get_clk(). The advantage would be that
 include/dt-bindings/clk/raspberrypi.h would exactly match the firmware
 protocol, and hence be easily correlated with the documentation.

Done.

 +static int rpi_clk_set_rate(struct clk_hw *hw,
 +unsigned long rate, unsigned long parent_rate)
 +{
 +struct rpi_firmware_clock *rpi_clk =
 +container_of(hw, struct rpi_firmware_clock, hw);
 +u32 packet[2];
 +int ret;
 +
 +packet[0] = rpi_clk-clock_id;
 +packet[1] = rate;
 +ret = rpi_firmware_property(rpi_clk-firmware_node,

 The docs indicate there's a third word here skip setting turbo. Is
 that optional?

 https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface

Yeah, it's optional based on the buffer size specified in the packet.

 +static long rpi_clk_round_rate(struct clk_hw *hw, unsigned long rate,
 +   unsigned long *parent_rate)
 +{
 +/*
 + * The firmware will end up rounding our rate to something,
 + * but we don't have an interface for it.  Just return the
 + * requested value, and it'll get updated after the clock gets
 + * set.
 + */
 +return rate;
 +}

 Hmm. I wonder if that will confuse things; I thought the purpose of
 round_rate() was so code could know exactly what would happen ahead of time?

Well, we don't have the ability.  Things seem to work, anyway.
Certainly better than just living with fixed clocks for everything like
we are today.

 +static struct clk *rpi_firmware_delayed_get_clk(struct
 of_phandle_args *clkspec, + void *_data)

 +rpi_clk = rpi_clocks[clkspec-args[0]];
 +
 +firmware_node = of_parse_phandle(of_node, firmware, 0);
 +if (!firmware_node) {
 +dev_err(dev, %s: Missing firmware node\n, rpi_clk-name);
 +return ERR_PTR(-ENODEV);
 +}
 +
 +/* Try a no-op transaction to see if the driver is loaded yet. */
 +ret = rpi_firmware_property_list(firmware_node, NULL, 0);
 +if (ret)
 +return ERR_PTR(ret);

 I would move all that into this driver's probe().

We can't move all this into the driver's probe, because this is where
we're returning -EPROBE_DEFER.  We could potentially do just the phandle
parse up front and allocate some memory to pass it and our own device
node to this function through the _data arg, but I don't see much point.

 +CLK_OF_DECLARE(rpi_firmware_clocks, raspberrypi,firmware-clocks,
 +   rpi_firmware_init_clock_provider);

 Oh, I guess the same comment as for the firmware node applies re: the
 over-genericity of the DT compatible value applies here too. Perhaps
 raspberrypi,bcm2835-firmware-clocks to match Lee's proposal for the
 firmware node?

Done.


signature.asc
Description: PGP signature

Re: [PATCH] mmc: sdhci-bcm2835: Actually enable the clock

[Eric Anholt]

Russell King - ARM Linux li...@arm.linux.org.uk writes:

 On Thu, May 28, 2015 at 05:03:12PM -0700, Eric Anholt wrote:
 We're currently using a fixed frequency clock specified in the DT, so
 enabling is a no-op.  However, the RPi firmware-based clocks driver
 can actually disable unused clocks, so when switching to use it we
 ended up losing our MMC clock once all devices were probed.
 
 Signed-off-by: Eric Anholt e...@anholt.net
 ---
  drivers/mmc/host/sdhci-bcm2835.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/drivers/mmc/host/sdhci-bcm2835.c 
 b/drivers/mmc/host/sdhci-bcm2835.c
 index 0ef0343..09aff3a 100644
 --- a/drivers/mmc/host/sdhci-bcm2835.c
 +++ b/drivers/mmc/host/sdhci-bcm2835.c
 @@ -172,6 +172,11 @@ static int bcm2835_sdhci_probe(struct platform_device 
 *pdev)
  ret = PTR_ERR(pltfm_host-clk);
  goto err;
  }
 +ret = clk_prepare_enable(pltfm_host-clk);
 +if (ret) {
 +dev_err(pdev-dev, failed to enable host clk\n);
 +goto err;
 +}
  
  return sdhci_add_host(host);

 Where's the error clean-up path for a failed sdhci_add_host()?

We were already missing required cleanup in that path, so I didn't
notice.  Sending a new version with a fix for that.


signature.asc
Description: PGP signature

[PATCH v2 1/2] mmc: sdhci-bcm2835: Clean up platform allocations if sdhci init fails.

[Eric Anholt]

Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/mmc/host/sdhci-bcm2835.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index 0ef0343..32f4046 100644
--- a/drivers/mmc/host/sdhci-bcm2835.c
+++ b/drivers/mmc/host/sdhci-bcm2835.c
@@ -173,8 +173,11 @@ static int bcm2835_sdhci_probe(struct platform_device 
*pdev)
goto err;
}
 
-   return sdhci_add_host(host);
+   ret = sdhci_add_host(host);
+   if (ret)
+   goto err;
 
+   return 0;
 err:
sdhci_pltfm_free(pdev);
return ret;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] mmc: sdhci-bcm2835: Actually enable the clock

[Eric Anholt]

We're currently using a fixed frequency clock specified in the DT, so
enabling is a no-op.  However, the RPi firmware-based clocks driver
can actually disable unused clocks, so when switching to use it we
ended up losing our MMC clock once all devices were probed.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Re-disable our clock on sdhci_add_host() failure.

 drivers/mmc/host/sdhci-bcm2835.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-bcm2835.c b/drivers/mmc/host/sdhci-bcm2835.c
index 32f4046..1c65d46 100644
--- a/drivers/mmc/host/sdhci-bcm2835.c
+++ b/drivers/mmc/host/sdhci-bcm2835.c
@@ -172,12 +172,19 @@ static int bcm2835_sdhci_probe(struct platform_device 
*pdev)
ret = PTR_ERR(pltfm_host-clk);
goto err;
}
+   ret = clk_prepare_enable(pltfm_host-clk);
+   if (ret) {
+   dev_err(pdev-dev, failed to enable host clk\n);
+   goto err;
+   }
 
ret = sdhci_add_host(host);
if (ret)
-   goto err;
+   goto err_clk;
 
return 0;
+err_clk:
+   clk_disable_unprepare(pltfm_host-clk);
 err:
sdhci_pltfm_free(pdev);
return ret;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/7] ARM: bcm2835: Add a Raspberry Pi-specific clock driver.

[Eric Anholt]

Stephen Warren swar...@wwwdotorg.org writes:

 On 05/18/2015 01:43 PM, Eric Anholt wrote:
 +init.flags = CLK_IS_ROOT;

 Is it possible to add clock parent information to the driver, so the
 clocks are all hooked together into the correct tree, rather than all
 looking like root clocks?

 One of the many reasons I didn't do anything FW-wise for the kernel was
 the hope that such information would be forthcoming, and hence we could
 have complete kernel drivers.

As far as I can tell, none of these clocks are the parent of any other.

There's a layer of PLLs, then clockman almost always just dividing off
of those.  In response to a clockman request (which is what this
property tag quickly maps to), only PLLH ever gets changed as a result
of RPI_CLOCK_PIXEL.  PLLH feeds the HDMI and VEC (SDTV).  We don't have
an SDTV clock for us to control through these interfaces, so there are
no conflicts that I can see.  Only two clockman clocks I see divide off
of on other clockman clocks, and we don't have access to those.


signature.asc
Description: PGP signature

Re: [PATCH v3 1/7] dt/bindings: Add binding for the Raspberry Pi clock provider

[Eric Anholt]

Lee Jones l...@kernel.org writes:

 If I were the Clock Maintainer, I would have probably missed this
 patch.  You _must_ intimate which subsystem you are submitting to.

 The hardware clocks are not controllable by the ARM, so we have to
 make requests to the firmware to do so from the VPU side.  This will
 let us replace fixed clocks in our DT with actual clock control (and
 correct frequency information).
 
 v2: Include the dt-bindings header in this commit instead of the next
 one.  Make the clock indices match the firmware clock IDs.  Rename
 the binding's compat string.  Move the firmware phandle to be
 under a vendor-specific namespace.
 
 Signed-off-by: Eric Anholt e...@anholt.net
 ---
  .../clock/raspberrypi,bcm2835-firmware-clocks.txt  | 25 
 ++
  include/dt-bindings/clk/raspberrypi.h  | 23 
  2 files changed, 48 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
  create mode 100644 include/dt-bindings/clk/raspberrypi.h
 
 diff --git 
 a/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
  
 b/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
 new file mode 100644
 index 000..0972602
 --- /dev/null
 +++ 
 b/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
 @@ -0,0 +1,25 @@
 +Raspberry Pi firmware clock provider.
 +
 +The Raspberry Pi architecture doesn't provide direct access to the
 +CLOCKMAN peripheral from the ARM side, so Linux has to make requests
 +to the VPU firmware to program them.
 +
 +This binding uses the common clock binding:
 +Documentation/devicetree/bindings/clock/clock-bindings.txt
 +
 +Required properties:
 +- compatible:   Should be raspberrypi,bcm2835-firmware-clocks
 +
 +- #clock-cells: Shall have value 1.  The permitted 
 clock-specifier
 +  values can be found in
 +  include/dt-bindings/clk/raspberrypi.h.
 +
 +- raspberrypi,firmware: Phandle to the firmware driver node.

 I think 'firmware' is a candidate for a generic phandle name.

Stephen Warren asked in the last version that I change it from
firmware to raspberrypi,firmware, which made sense to me since we're
not some core infrastructure using these references.  Which should it
be?


signature.asc
Description: PGP signature

[PATCH 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Eric Anholt]

Signed-off-by: Eric Anholt e...@anholt.net
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cef..d0dc42c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3573,6 +3573,12 @@ S:   Maintained
 F: drivers/gpu/drm/rockchip/
 F: Documentation/devicetree/bindings/video/rockchip*
 
+DRM DRIVERS FOR VC4
+M: Eric Anholt e...@anholt.net
+T: git git://github.com/anholt/linux
+S: Maintained
+F: drivers/gpu/drm/vc4/*
+
 DSBR100 USB FM RADIO DRIVER
 M: Alexey Klimov klimov.li...@gmail.com
 L: linux-me...@vger.kernel.org
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Raspberry Pi KMS-only driver

[Eric Anholt]

Here's the first patch series for graphics on the Raspberry Pi.  It
brings up fbcon on KMS, and the xf86-video-modesetting driver runs so
you can do X with no further userspace drivers.

Right now this series doesn't support changing video modes away from
the firmware boot setup, because when I set the pixel clock using the
rpi-dt-clocks series I end up with a black display. even on no-op
modesets.

I've dropped all of the 3D bits from this series, to simplify this
review stage.  See vc4-kms-v3d-rpi2 for a series that works with the
current Mesa driver, based on downstream 2709.  I squashed all of my
messy KMS series down, but kept Derek's patches separate to make sure
he gets credit.

This code can also be found at:

https://github.com/anholt/linux/tree/vc4-kms-squash

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/7] drm/vc4: Use the fbdev_cma helpers

[Eric Anholt]

From: Derek Foreman der...@osg.samsung.com

Keep the fbdev_cma pointer around so we can use it on hotplog and close
to ensure the frame buffer console is in a useful state.

Signed-off-by: Derek Foreman der...@osg.samsung.com
Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/gpu/drm/vc4/vc4_drv.c | 15 +++
 drivers/gpu/drm/vc4/vc4_drv.h |  2 ++
 drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 9ecf4b8b..90414d1 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -14,6 +14,7 @@
 #include linux/module.h
 #include linux/of_platform.h
 #include linux/platform_device.h
+#include drm_fb_cma_helper.h
 
 #include vc4_drv.h
 #include vc4_regs.h
@@ -70,6 +71,11 @@ static int vc4_drm_load(struct drm_device *dev, unsigned 
long flags)
 
 static int vc4_drm_unload(struct drm_device *dev)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   if (vc4-fbdev)
+   drm_fbdev_cma_fini(vc4-fbdev);
+
drm_mode_config_cleanup(dev);
 
component_unbind_all(dev-dev, dev);
@@ -85,6 +91,14 @@ static void vc4_drm_preclose(struct drm_device *dev, struct 
drm_file *file)
vc4_cancel_page_flip(crtc, file);
 }
 
+static void vc4_lastclose(struct drm_device *dev)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   if (vc4-fbdev)
+   drm_fbdev_cma_restore_mode(vc4-fbdev);
+}
+
 static const struct file_operations vc4_drm_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -109,6 +123,7 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_PRIME),
.load = vc4_drm_load,
.unload = vc4_drm_unload,
+   .lastclose = vc4_lastclose,
.set_busid = drm_platform_set_busid,
.preclose = vc4_drm_preclose,
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 1b0a0b0..6edc14b 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -15,6 +15,8 @@ struct vc4_dev {
struct vc4_hdmi *hdmi;
struct vc4_hvs *hvs;
struct vc4_crtc *crtc[3];
+
+   struct drm_fbdev_cma *fbdev;
 };
 
 static inline struct vc4_dev *
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index e5e96bc..a34439f 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -21,7 +21,16 @@
 #include drm_fb_cma_helper.h
 #include vc4_drv.h
 
+static void vc4_output_poll_changed(struct drm_device *dev)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   if (vc4-fbdev)
+   drm_fbdev_cma_hotplug_event(vc4-fbdev);
+}
+
 static const struct drm_mode_config_funcs vc4_mode_funcs = {
+   .output_poll_changed = vc4_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
.fb_create = drm_fb_cma_create,
@@ -54,6 +63,7 @@ fail:
 
 int vc4_kms_load(struct drm_device *dev)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;
 
ret = drm_vblank_init(dev, dev-mode_config.num_crtc);
@@ -73,9 +83,11 @@ int vc4_kms_load(struct drm_device *dev)
 
drm_mode_config_reset(dev);
 
-   drm_fbdev_cma_init(dev, 32,
-  dev-mode_config.num_crtc,
-  dev-mode_config.num_connector);
+   vc4-fbdev = drm_fbdev_cma_init(dev, 32,
+   dev-mode_config.num_crtc,
+   dev-mode_config.num_connector);
+   if (IS_ERR(vc4-fbdev))
+   vc4-fbdev = NULL;
 
drm_kms_helper_poll_init(dev);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/7] drm/vc4: Allow vblank to be disabled

[Eric Anholt]

From: Derek Foreman der...@osg.samsung.com

Signed-off-by: Derek Foreman der...@osg.samsung.com
Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/gpu/drm/vc4/vc4_kms.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index a34439f..f881cd4 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -77,6 +77,8 @@ int vc4_kms_load(struct drm_device *dev)
dev-mode_config.funcs = vc4_mode_funcs;
dev-mode_config.preferred_depth = 24;
 
+   dev-vblank_disable_allowed = true;
+
ret = vc4_init_modeset_objects(dev);
if (ret)
goto fail;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.

[Eric Anholt]

Signed-off-by: Eric Anholt e...@anholt.net
---
 .../devicetree/bindings/gpu/brcm,bcm-vc4.txt   | 83 ++
 1 file changed, 83 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt

diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
new file mode 100644
index 000..2b13e61
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
@@ -0,0 +1,83 @@
+Broadcom VC4 GPU
+
+The VC4 device present on the Raspberry Pi includes a display system
+with HDMI output and the HVS scaler for compositing display planes.
+
+Required properties for VC4:
+- compatible:  Should be brcm,vc4
+- crtcs:   List of references to pixelvalve scanout engines
+- hvss:List of references to HVS video scalers
+- encoders:List of references to output encoders (HDMI, SDTV)
+
+Required properties for Pixel Valve:
+- compatible:  Should be brcm,vc4-pixelvalve
+- reg: Physical base address and length of the PV's registers
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HVS:
+- compatible:  Should be brcm,vc4-hvs
+- reg: Physical base address and length of the HVS's registers
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HDMI
+- compatible:  Should be brcm,vc4-hdmi
+- reg: Physical base address and length of the two register ranges
+ (HDMI and HD)
+- interrupts:  The interrupt numbers
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+- ddc: phandle of the I2C controller used for DDC EDID probing
+- crtc:phandle to the pixelvalve CRTC the HDMI encoder is 
attached to
+
+Optional properties for HDMI:
+- hpd-gpio:The GPIO pin for HDMI hotplug detect (if it doesn't appear
+ as an interrupt/status bit in the HDMI controller
+ itself).  See bindings/pinctrl/brcm,bcm2835-gpio.txt
+
+Example:
+/ {
+   soc {
+   pv0: brcm,vc4-pixelvalve@7e206000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e206000 0x100;
+   interrupts = 2 13; /* pwa2 */
+   };
+
+   pv1: brcm,vc4-pixelvalve@7e207000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e207000 0x100;
+   interrupts = 2 14; /* pwa1 */
+   };
+
+   pv2: brcm,vc4-pixelvalve@7e807000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e807000 0x100;
+   interrupts = 2 10; /* pixelvalve */
+   };
+
+   hvs: brcm,hvs@7e40 {
+   compatible = brcm,vc4-hvs;
+   reg = 0x7e40 0x6000;
+   interrupts = 2 1;
+   };
+
+   hdmi: brcm,vc4-hdmi@7e902000 {
+   compatible = brcm,vc4-hdmi;
+   reg = 0x7e902000 0x600,
+ 0x7e808000 0x100;
+   interrupts = 2 8, 2 9;
+   ddc = i2c2;
+   hpd-gpio = gpio 46 GPIO_ACTIVE_HIGH;
+   crtc = pv2;
+   };
+
+   vc4: vc4@0x7e4c {
+   compatible = brcm,vc4;
+
+   crtcs = pv0, pv1, pv2;
+   encoders = hdmi;
+   hvss = hvs;
+   };
+   };
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/7] ARM: bcm2835: Add the DDC I2C controller to the device tree.

[Eric Anholt]

We need to use it for getting video modes over HDMI.

Signed-off-by: Eric Anholt e...@anholt.net
---
 arch/arm/boot/dts/bcm2835.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 301c73f..8f3ba88 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -149,6 +149,15 @@
status = disabled;
};
 
+   i2c2: i2c@7e805000 {
+   compatible = brcm,bcm2835-i2c;
+   reg = 0x7e805000 0x1000;
+   interrupts = 2 21;
+   clocks = clk_i2c;
+   #address-cells = 1;
+   #size-cells = 0;
+   };
+
usb@7e98 {
compatible = brcm,bcm2835-usb;
reg = 0x7e98 0x1;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/7] ARM: bcm2835: Add VC4 to the device tree.

[Eric Anholt]

Signed-off-by: Eric Anholt e...@anholt.net
---
 arch/arm/boot/dts/bcm2835.dtsi | 43 ++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 8f3ba88..dda67aa 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -1,4 +1,5 @@
 #include dt-bindings/pinctrl/bcm2835.h
+#include dt-bindings/gpio/gpio.h
 #include skeleton.dtsi
 
 / {
@@ -167,6 +168,48 @@
arm-pmu {
compatible = arm,arm1176-pmu;
};
+
+   hdmi: brcm,vc4-hdmi@7e902000 {
+   compatible = brcm,vc4-hdmi;
+   reg = 0x7e902000 0x600,
+ 0x7e808000 0x100;
+   interrupts = 2 8, 2 9;
+   ddc = i2c2;
+   hpd-gpio = gpio 46 GPIO_ACTIVE_HIGH;
+   crtc = pv2;
+   };
+
+   pv0: brcm,vc4-pixelvalve@7e206000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e206000 0x100;
+   interrupts = 2 13; /* pwa2 */
+   };
+
+   pv1: brcm,vc4-pixelvalve@7e207000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e207000 0x100;
+   interrupts = 2 14; /* pwa1 */
+   };
+
+   pv2: brcm,vc4-pixelvalve@7e807000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e807000 0x100;
+   interrupts = 2 10; /* pixelvalve */
+   };
+
+   hvs: brcm,hvs@7e40 {
+   compatible = brcm,vc4-hvs;
+   reg = 0x7e40 0x6000;
+   interrupts = 2 1;
+   };
+
+   vc4: vc4@0x7e4c {
+   compatible = brcm,vc4;
+
+   crtcs = pv0, pv1, pv2;
+   encoders = hdmi;
+   hvss = hvs;
+   };
};
 
clocks {
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

This is the start of a full VC4 driver.  Right now this just supports
configuring the display using a pre-existing video mode (because
changing the pixel clock isn't available yet, and doesn't work when it
is).  However, this is enough for fbcon and bringing up X using
xf86-video-modesetting.

Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/vc4/Kconfig   |  14 +
 drivers/gpu/drm/vc4/Makefile  |  18 ++
 drivers/gpu/drm/vc4/vc4_bo.c  |  54 
 drivers/gpu/drm/vc4/vc4_crtc.c| 583 ++
 drivers/gpu/drm/vc4/vc4_debugfs.c |  38 +++
 drivers/gpu/drm/vc4/vc4_drv.c | 249 +++
 drivers/gpu/drm/vc4/vc4_drv.h | 123 +++
 drivers/gpu/drm/vc4/vc4_hdmi.c| 651 ++
 drivers/gpu/drm/vc4/vc4_hvs.c | 172 ++
 drivers/gpu/drm/vc4/vc4_kms.c |  84 +
 drivers/gpu/drm/vc4/vc4_plane.c   | 320 +++
 drivers/gpu/drm/vc4/vc4_regs.h| 562 
 14 files changed, 2871 insertions(+)
 create mode 100644 drivers/gpu/drm/vc4/Kconfig
 create mode 100644 drivers/gpu/drm/vc4/Makefile
 create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c46ca31..1730a76 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -240,3 +240,5 @@ source drivers/gpu/drm/sti/Kconfig
 source drivers/gpu/drm/amd/amdkfd/Kconfig
 
 source drivers/gpu/drm/imx/Kconfig
+
+source drivers/gpu/drm/vc4/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5713d05..b991ac5 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA) += mga/
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_I915)  += i915/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
+obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
 obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
new file mode 100644
index 000..130cc94
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -0,0 +1,14 @@
+config DRM_VC4
+   tristate Broadcom VC4 Graphics
+   depends on ARCH_BCM2835
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_CMA_HELPER
+   help
+ Choose this option if you have a system that has a Broadcom
+ VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
+
+ This driver requires that avoid_warnings=2 be present in
+ the config.txt for the firmware, to keep it from smashing
+ our display setup.
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
new file mode 100644
index 000..4aa07ca
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -0,0 +1,18 @@
+ccflags-y := -Iinclude/drm
+
+# Please keep these build lists sorted!
+
+# core driver code
+vc4-y := \
+   vc4_bo.o \
+   vc4_crtc.o \
+   vc4_drv.o \
+   vc4_kms.o \
+   vc4_hdmi.o \
+   vc4_hvs.o \
+   vc4_plane.o \
+   $()
+
+vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
+
+obj-$(CONFIG_DRM_VC4)  += vc4.o
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
new file mode 100644
index 000..fee8cac
--- /dev/null
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -0,0 +1,54 @@
+/*
+ *  Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* DOC: VC4 GEM BO management support.
+ *
+ * The VC4 GPU architecture (both scanout and rendering) has direct
+ * access to system memory with no MMU in between.  To support it, we
+ * use the GEM CMA helper functions to allocate contiguous ranges of
+ * physical memory for our BOs.
+ */
+
+#include vc4_drv.h
+
+struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t size)
+{
+   struct drm_gem_cma_object *cma_obj;
+
+   cma_obj = drm_gem_cma_create(dev, size);
+   if (IS_ERR(cma_obj))
+   return NULL;
+   else
+   return to_vc4_bo(cma_obj-base);
+}
+
+int vc4_dumb_create(struct drm_file *file_priv,
+   struct drm_device *dev,
+   struct drm_mode_create_dumb *args)
+{
+   int min_pitch = DIV_ROUND_UP(args-width * args-bpp, 8

Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

r#secure method=pgpmime mode=sign
Stephen Warren swar...@wwwdotorg.org writes:

 On 08/12/2015 06:56 PM, Eric Anholt wrote:
 This is the start of a full VC4 driver.  Right now this just supports
 configuring the display using a pre-existing video mode (because
 changing the pixel clock isn't available yet, and doesn't work when it
 is).  However, this is enough for fbcon and bringing up X using
 xf86-video-modesetting.

 diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig

 +config DRM_VC4
 +tristate Broadcom VC4 Graphics

 +help
 +  Choose this option if you have a system that has a Broadcom
 +  VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
 +
 +  This driver requires that avoid_warnings=2 be present in
 +  the config.txt for the firmware, to keep it from smashing
 +  our display setup.

 The need for avoid_warnings=2 seems like it will trip people up. I
 don't think it's in any config.txt I've seen. Can you expand more on that?

The warnings thing is the firmware watching for undervoltage and then it
calls into dispmanx to overlay a little rainbow box on the screen.  This
of course interferes with our display setup.

I think we'll be able to wire up notifications to Linux for
undervoltage, at which point we can do something useful with that
information, ourselves.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 6/7] ARM: bcm2835: Add the DDC I2C controller to the device tree.

[Eric Anholt]

We need to use it for getting video modes over HDMI.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Mark it as disabled by default, and enable it in bcm2835-rpi.

 arch/arm/boot/dts/bcm2835-rpi.dtsi |  4 
 arch/arm/boot/dts/bcm2835.dtsi | 10 ++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 46780bb..29cc7ba 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -45,6 +45,10 @@
clock-frequency = 10;
 };
 
+i2c2 {
+   status = okay;
+};
+
 sdhci {
status = okay;
bus-width = 4;
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 301c73f..20574cc 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -149,6 +149,16 @@
status = disabled;
};
 
+   i2c2: i2c@7e805000 {
+   compatible = brcm,bcm2835-i2c;
+   reg = 0x7e805000 0x1000;
+   interrupts = 2 21;
+   clocks = clk_i2c;
+   #address-cells = 1;
+   #size-cells = 0;
+   status = disabled;
+   };
+
usb@7e98 {
compatible = brcm,bcm2835-usb;
reg = 0x7e98 0x1;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 7/7] ARM: bcm2835: Add VC4 to the device tree.

[Eric Anholt]

VC4 is the GPU (display and 3D) present on the 2835.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Sort by register address, mark HDMI as disabled by default in the
SoC file and enable it from -rpi.

 arch/arm/boot/dts/bcm2835-rpi.dtsi |  4 
 arch/arm/boot/dts/bcm2835.dtsi | 44 ++
 2 files changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 29cc7ba..f7217906 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -49,6 +49,10 @@
status = okay;
 };
 
+hdmi {
+   status = okay;
+};
+
 sdhci {
status = okay;
bus-width = 4;
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 20574cc..e625a21 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -1,4 +1,5 @@
 #include dt-bindings/pinctrl/bcm2835.h
+#include dt-bindings/gpio/gpio.h
 #include skeleton.dtsi
 
 / {
@@ -131,6 +132,18 @@
status = disabled;
};
 
+   pv0: brcm,vc4-pixelvalve@7e206000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e206000 0x100;
+   interrupts = 2 13; /* pwa2 */
+   };
+
+   pv1: brcm,vc4-pixelvalve@7e207000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e207000 0x100;
+   interrupts = 2 14; /* pwa1 */
+   };
+
sdhci: sdhci@7e30 {
compatible = brcm,bcm2835-sdhci;
reg = 0x7e30 0x100;
@@ -139,6 +152,12 @@
status = disabled;
};
 
+   hvs: brcm,hvs@7e40 {
+   compatible = brcm,vc4-hvs;
+   reg = 0x7e40 0x6000;
+   interrupts = 2 1;
+   };
+
i2c1: i2c@7e804000 {
compatible = brcm,bcm2835-i2c;
reg = 0x7e804000 0x1000;
@@ -159,6 +178,23 @@
status = disabled;
};
 
+   pv2: brcm,vc4-pixelvalve@7e807000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e807000 0x100;
+   interrupts = 2 10; /* pixelvalve */
+   };
+
+   hdmi: brcm,vc4-hdmi@7e902000 {
+   compatible = brcm,vc4-hdmi;
+   reg = 0x7e902000 0x600,
+ 0x7e808000 0x100;
+   interrupts = 2 8, 2 9;
+   ddc = i2c2;
+   hpd-gpio = gpio 46 GPIO_ACTIVE_HIGH;
+   crtc = pv2;
+   status = disabled;
+   };
+
usb@7e98 {
compatible = brcm,bcm2835-usb;
reg = 0x7e98 0x1;
@@ -168,6 +204,14 @@
arm-pmu {
compatible = arm,arm1176-pmu;
};
+
+   vc4: vc4@0x7e4c {
+   compatible = brcm,vc4;
+
+   crtcs = pv0, pv1, pv2;
+   encoders = hdmi;
+   hvss = hvs;
+   };
};
 
clocks {
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

This is the start of a full VC4 driver.  Right now this just supports
configuring the display using a pre-existing video mode (because
changing the pixel clock isn't available yet, and doesn't work when it
is).  However, this is enough for fbcon and bringing up X using
xf86-video-modesetting.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Drop FB_HELPER select thanks to Archit's patches.  Do manual init
ordering instead of using the .load hook.  Structure registration
more like tegra's, but still using the typical component code.
Drop no-op hooks for atomic_begin and mode_fixup() now that
they're optional.  Drop sentinel in Makefile.  Fix minor style
nits I noticed on another reread.

 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/vc4/Kconfig   |  13 +
 drivers/gpu/drm/vc4/Makefile  |  17 +
 drivers/gpu/drm/vc4/vc4_bo.c  |  52 
 drivers/gpu/drm/vc4/vc4_crtc.c| 565 ++
 drivers/gpu/drm/vc4/vc4_debugfs.c |  38 +++
 drivers/gpu/drm/vc4/vc4_drv.c | 271 
 drivers/gpu/drm/vc4/vc4_drv.h | 120 
 drivers/gpu/drm/vc4/vc4_hdmi.c| 633 ++
 drivers/gpu/drm/vc4/vc4_hvs.c | 161 ++
 drivers/gpu/drm/vc4/vc4_kms.c |  84 +
 drivers/gpu/drm/vc4/vc4_plane.c   | 320 +++
 drivers/gpu/drm/vc4/vc4_regs.h| 562 +
 14 files changed, 2839 insertions(+)
 create mode 100644 drivers/gpu/drm/vc4/Kconfig
 create mode 100644 drivers/gpu/drm/vc4/Makefile
 create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 06ae500..19bb0db 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -260,3 +260,5 @@ source drivers/gpu/drm/sti/Kconfig
 source drivers/gpu/drm/amd/amdkfd/Kconfig
 
 source drivers/gpu/drm/imx/Kconfig
+
+source drivers/gpu/drm/vc4/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8858510..283ed8e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA) += mga/
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_I915)  += i915/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
+obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
 obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
new file mode 100644
index 000..e810ef7
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -0,0 +1,13 @@
+config DRM_VC4
+   tristate Broadcom VC4 Graphics
+   depends on ARCH_BCM2835
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   help
+ Choose this option if you have a system that has a Broadcom
+ VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
+
+ This driver requires that avoid_warnings=2 be present in
+ the config.txt for the firmware, to keep it from smashing
+ our display setup.
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
new file mode 100644
index 000..32b4f9c
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -0,0 +1,17 @@
+ccflags-y := -Iinclude/drm
+
+# Please keep these build lists sorted!
+
+# core driver code
+vc4-y := \
+   vc4_bo.o \
+   vc4_crtc.o \
+   vc4_drv.o \
+   vc4_kms.o \
+   vc4_hdmi.o \
+   vc4_hvs.o \
+   vc4_plane.o
+
+vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
+
+obj-$(CONFIG_DRM_VC4)  += vc4.o
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
new file mode 100644
index 000..ab9f510
--- /dev/null
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -0,0 +1,52 @@
+/*
+ *  Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* DOC: VC4 GEM BO management support.
+ *
+ * The VC4 GPU architecture (both scanout and rendering) has direct
+ * access to system memory with no MMU in between.  To support it, we
+ * use the GEM CMA helper functions to allocate contiguous ranges of
+ * physical memory for our BOs.
+ */
+
+#include vc4_drv.h
+
+struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t size)
+{
+   struct drm_gem_cma_object *cma_obj;
+
+   cma_obj = drm_gem_cma_create(dev, size

[PATCH v2 1/7] drm/vc4: Add devicetree bindings for VC4.

[Eric Anholt]

VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
other Broadcom SoCs.

This binding follows the model of msm, imx, sti, and others, where
there is a subsystem node for the whole GPU, with nodes for the
individual HW components within it.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Extend the commit message, fix several nits from Stephen Warren.

 .../devicetree/bindings/gpu/brcm,bcm-vc4.txt   | 79 ++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt

diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
new file mode 100644
index 000..1b9fedc
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
@@ -0,0 +1,79 @@
+Broadcom VC4 GPU
+
+The VC4 device present on the Raspberry Pi includes a display system
+with HDMI output and the HVS scaler for compositing display planes.
+
+Required properties for VC4:
+- compatible:  Should be brcm,vc4
+- crtcs:   List of phandles of pixelvalve scanout engines
+- hvss:List of phandles of HVS video scalers
+- encoders:List of phandles of output encoders (HDMI, SDTV)
+
+Required properties for Pixel Valve:
+- compatible:  Should be brcm,vc4-pixelvalve
+- reg: Physical base address and length of the PV's registers
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HVS:
+- compatible:  Should be brcm,vc4-hvs
+- reg: Physical base address and length of the HVS's registers
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HDMI
+- compatible:  Should be brcm,vc4-hdmi
+- reg: Physical base address and length of the two register ranges
+ (HDMI and HD, in that order)
+- interrupts:  The interrupt numbers
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+- ddc: phandle of the I2C controller used for DDC EDID probing
+- crtc:phandle to the pixelvalve CRTC the HDMI encoder is 
attached to
+
+Optional properties for HDMI:
+- hpd-gpio:The GPIO pin for HDMI hotplug detect (if it doesn't appear
+ as an interrupt/status bit in the HDMI controller
+ itself).  See bindings/pinctrl/brcm,bcm2835-gpio.txt
+
+Example:
+pv0: brcm,vc4-pixelvalve@7e206000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e206000 0x100;
+   interrupts = 2 13; /* pwa2 */
+};
+
+pv1: brcm,vc4-pixelvalve@7e207000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e207000 0x100;
+   interrupts = 2 14; /* pwa1 */
+};
+
+pv2: brcm,vc4-pixelvalve@7e807000 {
+   compatible = brcm,vc4-pixelvalve;
+   reg = 0x7e807000 0x100;
+   interrupts = 2 10; /* pixelvalve */
+};
+
+hvs: brcm,hvs@7e40 {
+   compatible = brcm,vc4-hvs;
+   reg = 0x7e40 0x6000;
+   interrupts = 2 1;
+};
+
+hdmi: brcm,vc4-hdmi@7e902000 {
+   compatible = brcm,vc4-hdmi;
+   reg = 0x7e902000 0x600,
+ 0x7e808000 0x100;
+   interrupts = 2 8, 2 9;
+   ddc = i2c2;
+   hpd-gpio = gpio 46 GPIO_ACTIVE_HIGH;
+   crtc = pv2;
+};
+
+vc4: vc4@0x7e4c {
+   compatible = brcm,vc4;
+
+   crtcs = pv0, pv1, pv2;
+   encoders = hdmi;
+   hvss = hvs;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 5/7] drm/vc4: Allow vblank to be disabled

[Eric Anholt]

From: Derek Foreman der...@osg.samsung.com

Signed-off-by: Derek Foreman der...@osg.samsung.com
Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/gpu/drm/vc4/vc4_kms.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index a34439f..f881cd4 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -77,6 +77,8 @@ int vc4_kms_load(struct drm_device *dev)
dev-mode_config.funcs = vc4_mode_funcs;
dev-mode_config.preferred_depth = 24;
 
+   dev-vblank_disable_allowed = true;
+
ret = vc4_init_modeset_objects(dev);
if (ret)
goto fail;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

Daniel Vetter dan...@ffwll.ch writes:

 On Thu, Aug 13, 2015 at 01:44:03PM -0700, Eric Anholt wrote:
 Daniel Vetter dan...@ffwll.ch writes:
 
  On Wed, Aug 12, 2015 at 05:56:16PM -0700, Eric Anholt wrote:
  This is the start of a full VC4 driver.  Right now this just supports
  configuring the display using a pre-existing video mode (because
  changing the pixel clock isn't available yet, and doesn't work when it
  is).  However, this is enough for fbcon and bringing up X using
  xf86-video-modesetting.
  
  Signed-off-by: Eric Anholt e...@anholt.net
  ---
   drivers/gpu/drm/Kconfig   |   2 +
   drivers/gpu/drm/Makefile  |   1 +
   drivers/gpu/drm/vc4/Kconfig   |  14 +
   drivers/gpu/drm/vc4/Makefile  |  18 ++
   drivers/gpu/drm/vc4/vc4_bo.c  |  54 
   drivers/gpu/drm/vc4/vc4_crtc.c| 583 
  ++
   drivers/gpu/drm/vc4/vc4_debugfs.c |  38 +++
   drivers/gpu/drm/vc4/vc4_drv.c | 249 +++
   drivers/gpu/drm/vc4/vc4_drv.h | 123 +++
   drivers/gpu/drm/vc4/vc4_hdmi.c| 651 
  ++
   drivers/gpu/drm/vc4/vc4_hvs.c | 172 ++
   drivers/gpu/drm/vc4/vc4_kms.c |  84 +
   drivers/gpu/drm/vc4/vc4_plane.c   | 320 +++
   drivers/gpu/drm/vc4/vc4_regs.h| 562 
   14 files changed, 2871 insertions(+)
   create mode 100644 drivers/gpu/drm/vc4/Kconfig
   create mode 100644 drivers/gpu/drm/vc4/Makefile
   create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
   create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
   create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
   create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
   create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
   create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
   create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
   create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
   create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
   create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h
 
  Made a quick pass and found a few things to update to latest drm
  developments. Of course didn't look at the hardware details since no clue,
  but looks really nice overall.
 
 If you have anything about the hardware that you were curious about, I'd
 be interested in trying to explain them in the comments to the extent
 that I can.  It's unfortunate that we haven't shipped docs for the
 display side of things, but had to do a lot of reading of the verilog
 just to get this far, anyway.

 The only thing I spotted is that you right now only register a primary and
 cursor plane. I guess the plan we once discussed about exposing piles of
 planes for -modesetting accel isn't there yet?

 But otherwise I really didn't go into the hardware details.

Yeah, I haven't done piles of planes because what we have right now
means I don't have to do the bandwidth limits tracking yet.


signature.asc
Description: PGP signature

Raspberry Pi KMS-only driver V2

[Eric Anholt]

Here's a respin of the RPi KMS series, taking a bunch of review
feedback into account.  It's also rebased on danvet's drm-misc now,
which cut some stub code.  The new series can still be found at:

https://github.com/anholt/linux/tree/vc4-kms-squash

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/7] drm/vc4: Use the fbdev_cma helpers

[Eric Anholt]

From: Derek Foreman der...@osg.samsung.com

Keep the fbdev_cma pointer around so we can use it on hotplog and close
to ensure the frame buffer console is in a useful state.

Signed-off-by: Derek Foreman der...@osg.samsung.com
Signed-off-by: Eric Anholt e...@anholt.net
---
 drivers/gpu/drm/vc4/vc4_drv.c | 14 ++
 drivers/gpu/drm/vc4/vc4_drv.h |  2 ++
 drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index d30aefa..8ebd238 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -14,6 +14,7 @@
 #include linux/module.h
 #include linux/of_platform.h
 #include linux/platform_device.h
+#include drm_fb_cma_helper.h
 
 #include vc4_drv.h
 #include vc4_regs.h
@@ -49,6 +50,14 @@ static void vc4_drm_preclose(struct drm_device *dev, struct 
drm_file *file)
vc4_cancel_page_flip(crtc, file);
 }
 
+static void vc4_lastclose(struct drm_device *dev)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   if (vc4-fbdev)
+   drm_fbdev_cma_restore_mode(vc4-fbdev);
+}
+
 static const struct file_operations vc4_drm_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -71,6 +80,7 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_ATOMIC |
DRIVER_GEM |
DRIVER_PRIME),
+   .lastclose = vc4_lastclose,
.preclose = vc4_drm_preclose,
 
.enable_vblank = vc4_enable_vblank,
@@ -161,6 +171,10 @@ static void vc4_drm_unbind(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = platform_get_drvdata(pdev);
+   struct vc4_dev *vc4 = to_vc4_dev(drm);
+
+   if (vc4-fbdev)
+   drm_fbdev_cma_fini(vc4-fbdev);
 
drm_mode_config_cleanup(drm);
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 282ce0b..24a1cb5 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -15,6 +15,8 @@ struct vc4_dev {
struct vc4_hdmi *hdmi;
struct vc4_hvs *hvs;
struct vc4_crtc *crtc[3];
+
+   struct drm_fbdev_cma *fbdev;
 };
 
 static inline struct vc4_dev *
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index e5e96bc..a34439f 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -21,7 +21,16 @@
 #include drm_fb_cma_helper.h
 #include vc4_drv.h
 
+static void vc4_output_poll_changed(struct drm_device *dev)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   if (vc4-fbdev)
+   drm_fbdev_cma_hotplug_event(vc4-fbdev);
+}
+
 static const struct drm_mode_config_funcs vc4_mode_funcs = {
+   .output_poll_changed = vc4_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
.fb_create = drm_fb_cma_create,
@@ -54,6 +63,7 @@ fail:
 
 int vc4_kms_load(struct drm_device *dev)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;
 
ret = drm_vblank_init(dev, dev-mode_config.num_crtc);
@@ -73,9 +83,11 @@ int vc4_kms_load(struct drm_device *dev)
 
drm_mode_config_reset(dev);
 
-   drm_fbdev_cma_init(dev, 32,
-  dev-mode_config.num_crtc,
-  dev-mode_config.num_connector);
+   vc4-fbdev = drm_fbdev_cma_init(dev, 32,
+   dev-mode_config.num_crtc,
+   dev-mode_config.num_connector);
+   if (IS_ERR(vc4-fbdev))
+   vc4-fbdev = NULL;
 
drm_kms_helper_poll_init(dev);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Eric Anholt]

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Mark it Supported, not Maintained.

 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c9dd5f..5292087 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3592,6 +3592,12 @@ S:   Maintained
 F: drivers/gpu/drm/rockchip/
 F: Documentation/devicetree/bindings/video/rockchip*
 
+DRM DRIVERS FOR VC4
+M: Eric Anholt e...@anholt.net
+T: git git://github.com/anholt/linux
+S: Supported
+F: drivers/gpu/drm/vc4/*
+
 DSBR100 USB FM RADIO DRIVER
 M: Alexey Klimov klimov.li...@gmail.com
 L: linux-me...@vger.kernel.org
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.

[Eric Anholt]

Stephen Warren swar...@wwwdotorg.org writes:

 On 08/12/2015 06:56 PM, Eric Anholt wrote:
 Signed-off-by: Eric Anholt e...@anholt.net

 This one definitely needs a patch description, since someone might not
 know what a VC4 is, and git log won't show the text from the binding
 doc itself. I'd suggest adding the initial paragraph of the binding doc
 as the patch description, or more.

 diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
 b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt

 +- hvss: List of references to HVS video scalers
 +- encoders: List of references to output encoders (HDMI, SDTV)

 Would it make sense to make all those nodes child node of the vc4
 object. That way, there's no need to have these lists of objects; they
 can be automatically built up as the DT is enumerated. I know that e.g.
 the NVIDIA Tegra host1x binding works this way, and I think it may have
 been inspired by other similar cases.

I've looked at tegra, and the component system used by msm appears to be
nicer than it.  To follow tegra's model, it looks like I need to build
this extra bus thing corresponding to host1x that is effectively the
drivers/base/component.c code, so that I can get at vc4's structure from
the component drivers.

 Of course, this is only appropriate if the HW modules really are
 logically children of the VC4 HW module. Perhaps they aren't. If they
 aren't though, I wonder what this vc4 module actually represents in HW?

It's the subsystem, same as we use a subsystem node for msm, sti,
rockchip, imx, and exynos.  This appears to be the common model of how
the collection of graphics-related components is represented in the DT.


signature.asc
Description: PGP signature

Re: [PATCH 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Eric Anholt]

Stephen Warren swar...@wwwdotorg.org writes:

 On 08/12/2015 06:56 PM, Eric Anholt wrote:

 diff --git a/MAINTAINERS b/MAINTAINERS

 +DRM DRIVERS FOR VC4
 +M:  Eric Anholt e...@anholt.net
 +T:  git git://github.com/anholt/linux
 +S:  Maintained
 +F:  drivers/gpu/drm/vc4/*

 S: Supported

Fixed.


signature.asc
Description: PGP signature

Re: [PATCH 6/7] ARM: bcm2835: Add the DDC I2C controller to the device tree.

[Eric Anholt]

Stephen Warren swar...@wwwdotorg.org writes:

 On 08/12/2015 06:56 PM, Eric Anholt wrote:
 We need to use it for getting video modes over HDMI.

 diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi

 +i2c2: i2c@7e805000 {
 +compatible = brcm,bcm2835-i2c;
 +reg = 0x7e805000 0x1000;
 +interrupts = 2 21;
 +clocks = clk_i2c;
 +#address-cells = 1;
 +#size-cells = 0;
 +};

 In an SoC .dtsi file, you'd typically write:

   status = disabled;

 ... in all nodes that represent IO controllers that interface to
 external HW, so that board DT files can/must explicitly choose to enable
 the device if it's actually in use on the board. Some systems might not
 have HDMI and hence might not hook up the HDMI_SCL/SDA pads.

 BCM2835-ARM-Peripherals.pdf states Note that the BSC2 master is used
 dedicated with the HDMI interface and should not be accessed by user
 programs.. Does this imply the Linux kernel shouldn't be touching this
 I2C controller; that the VC4 firmware might also be attempting to use
 it? I wonder how any such sharing of the HW would work.

In order for *any* of this driver to work, we need to ensure that the
firmware doesn't try to write to the corresponding part of the hardware.
DDC I2C is no different.  All that will cause the firmware to do
anything with display is generating mbox/dispmanx requests (through the
firmware driver), and the undervoltage warnings.


signature.asc
Description: PGP signature

Re: [PATCH] irqchip: bcm2836: Use a CPU notifier enable IPIs.

[Eric Anholt]

Thomas Gleixner t...@linutronix.de writes:

 On Mon, 27 Jul 2015, Eric Anholt wrote:
 +/* Unmasks the IPI on the CPU wen it's first brought online. */

 when

 +static int bcm2836_arm_irqchip_cpu_notify(struct notifier_block *nfb,
 +  unsigned long action, void *hcpu)
 +{
 +unsigned int cpu = (unsigned long)hcpu;
 +unsigned int int_reg = LOCAL_MAILBOX_INT_CONTROL0;
 +unsigned int mailbox = 0;
 +
 +if (action == CPU_STARTING || action == CPU_STARTING_FROZEN)
 +bcm2836_arm_irqchip_unmask_per_cpu_irq(int_reg, mailbox, cpu);

 Shouldn't you mask the irq on CPU_DYING?

I was just following what other drivers were doing.  Is CPU_DYING the
only thing that needs masking?


signature.asc
Description: PGP signature

[PATCH v4 4/4] irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2.

[Eric Anholt]

This interrupt controller is the new root interrupt controller with
the timer, PMU events, and IPIs, and the bcm2835's interrupt
controller is chained off of it to handle the peripherals.

I wrote the interrupt chip support, while Andrea Merello wrote the IPI
code.

Signed-off-by: Eric Anholt e...@anholt.net
Signed-off-by: Andrea Merello andrea.mere...@gmail.com
Acked-by: Stephen Warren swar...@wwwdotorg.org
---

v2: Rename functions/globals to bcm2836_arm_local.  Treat per-cpu
interrupts as per-cpu in mask/unmask.  Add comments about how
registers work.
v3: Drop debug printfs from PMU interrupt masking.
v4: Use cpu notifiers to unmask IPIs only when Linux wants the CPU up.

 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-bcm2836.c | 275 ++
 2 files changed, 276 insertions(+)
 create mode 100644 drivers/irqchip/irq-bcm2836.c

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b8d4e96..9727681 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,6 +1,7 @@
 obj-$(CONFIG_IRQCHIP)  += irqchip.o
 
 obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
+obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2836.o
 obj-$(CONFIG_ARCH_EXYNOS)  += exynos-combiner.o
 obj-$(CONFIG_ARCH_HIP04)   += irq-hip04.o
 obj-$(CONFIG_ARCH_MMP) += irq-mmp.o
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
new file mode 100644
index 000..052bd83
--- /dev/null
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -0,0 +1,275 @@
+/*
+ * Root interrupt controller for the BCM2836 (Raspberry Pi 2).
+ *
+ * Copyright 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/cpu.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/irqchip.h
+#include linux/irqdomain.h
+#include asm/exception.h
+
+/*
+ * The low 2 bits identify the CPU that the GPU IRQ goes to, and the
+ * next 2 bits identify the CPU that the GPU FIQ goes to.
+ */
+#define LOCAL_GPU_ROUTING  0x00c
+/* When setting bits 0-3, enables PMU interrupts on that CPU. */
+#define LOCAL_PM_ROUTING_SET   0x010
+/* When setting bits 0-3, disables PMU interrupts on that CPU. */
+#define LOCAL_PM_ROUTING_CLR   0x014
+/*
+ * The low 4 bits of this are the CPU's timer IRQ enables, and the
+ * next 4 bits are the CPU's timer FIQ enables (which override the IRQ
+ * bits).
+ */
+#define LOCAL_TIMER_INT_CONTROL0   0x040
+/*
+ * The low 4 bits of this are the CPU's per-mailbox IRQ enables, and
+ * the next 4 bits are the CPU's per-mailbox FIQ enables (which
+ * override the IRQ bits).
+ */
+#define LOCAL_MAILBOX_INT_CONTROL0 0x050
+/*
+ * The CPU's interrupt status register.  Bits are defined by the the
+ * LOCAL_IRQ_* bits below.
+ */
+#define LOCAL_IRQ_PENDING0 0x060
+/* Same status bits as above, but for FIQ. */
+#define LOCAL_FIQ_PENDING0 0x070
+/*
+ * Mailbox0 write-to-set bits.  There are 16 mailboxes, 4 per CPU, and
+ * these bits are organized by mailbox number and then CPU number.  We
+ * use mailbox 0 for IPIs.  The mailbox's interrupt is raised while
+ * any bit is set.
+ */
+#define LOCAL_MAILBOX0_SET00x080
+/* Mailbox0 write-to-clear bits. */
+#define LOCAL_MAILBOX0_CLR00x0c0
+
+#define LOCAL_IRQ_CNTPSIRQ 0
+#define LOCAL_IRQ_CNTPNSIRQ1
+#define LOCAL_IRQ_CNTHPIRQ 2
+#define LOCAL_IRQ_CNTVIRQ  3
+#define LOCAL_IRQ_MAILBOX0 4
+#define LOCAL_IRQ_MAILBOX1 5
+#define LOCAL_IRQ_MAILBOX2 6
+#define LOCAL_IRQ_MAILBOX3 7
+#define LOCAL_IRQ_GPU_FAST 8
+#define LOCAL_IRQ_PMU_FAST 9
+#define LAST_IRQ   LOCAL_IRQ_PMU_FAST
+
+struct bcm2836_arm_irqchip_intc {
+   struct irq_domain *domain;
+   void __iomem *base;
+};
+
+static struct bcm2836_arm_irqchip_intc intc  __read_mostly;
+
+static void bcm2836_arm_irqchip_mask_per_cpu_irq(unsigned int reg_offset,
+unsigned int bit,
+int cpu)
+{
+   void __iomem *reg = intc.base + reg_offset + 4 * cpu;
+
+   writel(readl(reg)  ~BIT(bit), reg);
+}
+
+static void bcm2836_arm_irqchip_unmask_per_cpu_irq(unsigned int reg_offset,
+  unsigned int bit,
+int cpu)
+{
+   void __iomem *reg = intc.base + reg_offset + 4 * cpu;
+
+   writel(readl(reg

[PATCH v4 3/4] irqchip: Add documentation for the bcm2836 interrupt controller.

[Eric Anholt]

This is a new per-cpu root interrupt controller on the Raspberry Pi 2,
which will chain to the bcm2835 interrupt controller for peripheral
interrupts.

Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Stephen Warren swar...@wwwdotorg.org
---
 .../interrupt-controller/brcm,bcm2836-l1-intc.txt  | 37 ++
 1 file changed, 37 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
new file mode 100644
index 000..f320dcd
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt
@@ -0,0 +1,37 @@
+BCM2836 per-CPU interrupt controller
+
+The BCM2836 has a per-cpu interrupt controller for the timer, PMU
+events, and SMP IPIs.  One of the CPUs may receive interrupts for the
+peripheral (GPU) events, which chain to the BCM2835-style interrupt
+controller.
+
+Required properties:
+
+- compatible:  Should be brcm,bcm2836-l1-intc
+- reg: Specifies base physical address and size of the
+ registers
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Specifies the number of cells needed to encode an
+ interrupt source. The value shall be 1
+
+Please refer to interrupts.txt in this directory for details of the common
+Interrupt Controllers bindings used by client devices.
+
+The interrupt sources are as follows:
+
+0: CNTPSIRQ
+1: CNTPNSIRQ
+2: CNTHPIRQ
+3: CNTVIRQ
+8: GPU_FAST
+9: PMU_FAST
+
+Example:
+
+local_intc: local_intc {
+   compatible = brcm,bcm2836-l1-intc;
+   reg = 0x4000 0x100;
+   interrupt-controller;
+   #interrupt-cells = 1;
+   interrupt-parent = local_intc;
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 1/4] irqchip: bcm2835: Refactor handle_IRQ() calls out of MAKE_HWIRQ.

[Eric Anholt]

For BCM2836, we want to chain into this IRQ chip from the root
controller, and for chaining we need to do something else instead of
handle_IRQ() once we have decoded the IRQ.

Note that this changes the behavior a little bit: Previously for a
non-shortcut IRQ, we'd loop reading and handling the second level IRQ
status until it was cleared before returning to the loop reading the
top level IRQ status (Note that the top level bit is just an OR of the
low level bits).  For the expected case of just one interrupt to be
handled, this was an extra register read, so we're down from 4 to 3
reads.

Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Stephen Warren swar...@wwwdotorg.org
---
 drivers/irqchip/irq-bcm2835.c | 57 ++-
 1 file changed, 29 insertions(+), 28 deletions(-)

diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index e68c3b6..382450a 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -179,44 +179,45 @@ static int __init armctrl_of_init(struct device_node 
*node,
  * handle_IRQ may briefly re-enable interrupts for soft IRQ handling.
  */
 
-static void armctrl_handle_bank(int bank, struct pt_regs *regs)
+static u32 armctrl_translate_bank(int bank)
 {
-   u32 stat, irq;
+   u32 stat = readl_relaxed(intc.pending[bank]);
 
-   while ((stat = readl_relaxed(intc.pending[bank]))) {
-   irq = MAKE_HWIRQ(bank, ffs(stat) - 1);
-   handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
-   }
+   return MAKE_HWIRQ(bank, ffs(stat) - 1);
+}
+
+static u32 armctrl_translate_shortcut(int bank, u32 stat)
+{
+   return MAKE_HWIRQ(bank, shortcuts[ffs(stat  SHORTCUT_SHIFT) - 1]);
 }
 
-static void armctrl_handle_shortcut(int bank, struct pt_regs *regs,
-   u32 stat)
+static u32 get_next_armctrl_hwirq(void)
 {
-   u32 irq = MAKE_HWIRQ(bank, shortcuts[ffs(stat  SHORTCUT_SHIFT) - 1]);
-   handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
+   u32 stat = readl_relaxed(intc.pending[0])  BANK0_VALID_MASK;
+
+   if (stat == 0)
+   return ~0;
+   else if (stat  BANK0_HWIRQ_MASK)
+   return MAKE_HWIRQ(0, ffs(stat  BANK0_HWIRQ_MASK) - 1);
+   else if (stat  SHORTCUT1_MASK)
+   return armctrl_translate_shortcut(1, stat  SHORTCUT1_MASK);
+   else if (stat  SHORTCUT2_MASK)
+   return armctrl_translate_shortcut(2, stat  SHORTCUT2_MASK);
+   else if (stat  BANK1_HWIRQ)
+   return armctrl_translate_bank(1);
+   else if (stat  BANK2_HWIRQ)
+   return armctrl_translate_bank(2);
+   else
+   BUG();
 }
 
 static void __exception_irq_entry bcm2835_handle_irq(
struct pt_regs *regs)
 {
-   u32 stat, irq;
-
-   while ((stat = readl_relaxed(intc.pending[0])  BANK0_VALID_MASK)) {
-   if (stat  BANK0_HWIRQ_MASK) {
-   irq = MAKE_HWIRQ(0, ffs(stat  BANK0_HWIRQ_MASK) - 1);
-   handle_IRQ(irq_linear_revmap(intc.domain, irq), regs);
-   } else if (stat  SHORTCUT1_MASK) {
-   armctrl_handle_shortcut(1, regs, stat  SHORTCUT1_MASK);
-   } else if (stat  SHORTCUT2_MASK) {
-   armctrl_handle_shortcut(2, regs, stat  SHORTCUT2_MASK);
-   } else if (stat  BANK1_HWIRQ) {
-   armctrl_handle_bank(1, regs);
-   } else if (stat  BANK2_HWIRQ) {
-   armctrl_handle_bank(2, regs);
-   } else {
-   BUG();
-   }
-   }
+   u32 hwirq;
+
+   while ((hwirq = get_next_armctrl_hwirq()) != ~0)
+   handle_IRQ(irq_linear_revmap(intc.domain, hwirq), regs);
 }
 
 IRQCHIP_DECLARE(bcm2835_armctrl_ic, brcm,bcm2835-armctrl-ic, 
armctrl_of_init);
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Raspberry Pi 2 interrupt controller support (v4)

[Eric Anholt]

https://github.com/anholt/linux/tree/bcm2836-irqchip

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 2/4] irqchip: bcm2835: Add support for being used as a second level controller.

[Eric Anholt]

The BCM2836 (Raspberry Pi 2) uses two levels of interrupt handling
with the CPU-local interrupts being the root, so we need to register
ours as chained off of the CPU's local interrupt.

Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Stephen Warren swar...@wwwdotorg.org
---

v3: Use a separate compatible value to indicate that the parent
interrupt controller irq is required (Requested by Stephen Warren)

 .../brcm,bcm2835-armctrl-ic.txt| 25 -
 drivers/irqchip/irq-bcm2835.c  | 43 --
 2 files changed, 64 insertions(+), 4 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
index 7da578d..2d6c8bb 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
@@ -5,9 +5,14 @@ The BCM2835 contains a custom top-level interrupt controller, 
which supports
 controller, or the HW block containing it, is referred to occasionally
 as armctrl in the SoC documentation, hence naming of this binding.
 
+The BCM2836 contains the same interrupt controller with the same
+interrupts, but the per-CPU interrupt controller is the root, and an
+interrupt there indicates that the ARMCTRL has an interrupt to handle.
+
 Required properties:
 
-- compatible : should be brcm,bcm2835-armctrl-ic
+- compatible : should be brcm,bcm2835-armctrl-ic or
+ brcm,bcm2836-armctrl-ic
 - reg : Specifies base physical address and size of the registers.
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
@@ -20,6 +25,12 @@ Required properties:
   The 2nd cell contains the interrupt number within the bank. Valid values
   are 0..7 for bank 0, and 0..31 for bank 1.
 
+Additional required properties for brcm,bcm2836-armctrl-ic:
+- interrupt-parent : Specifies the parent interrupt controller when this
+  controller is the second level.
+- interrupts : Specifies the interrupt on the parent for this interrupt
+  controller to handle.
+
 The interrupt sources are as follows:
 
 Bank 0:
@@ -102,9 +113,21 @@ Bank 2:
 
 Example:
 
+/* BCM2835, first level */
 intc: interrupt-controller {
compatible = brcm,bcm2835-armctrl-ic;
reg = 0x7e00b200 0x200;
interrupt-controller;
#interrupt-cells = 2;
 };
+
+/* BCM2836, second level */
+intc: interrupt-controller {
+   compatible = brcm,bcm2836-armctrl-ic;
+   reg = 0x7e00b200 0x200;
+   interrupt-controller;
+   #interrupt-cells = 2;
+
+   interrupt-parent = local_intc;
+   interrupts = 8;
+};
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index 382450a..f968d3f 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -97,6 +97,7 @@ struct armctrl_ic {
 static struct armctrl_ic intc __read_mostly;
 static void __exception_irq_entry bcm2835_handle_irq(
struct pt_regs *regs);
+static void bcm2836_chained_handle_irq(unsigned int irq, struct irq_desc 
*desc);
 
 static void armctrl_mask_irq(struct irq_data *d)
 {
@@ -140,7 +141,8 @@ static const struct irq_domain_ops armctrl_ops = {
 };
 
 static int __init armctrl_of_init(struct device_node *node,
-   struct device_node *parent)
+ struct device_node *parent,
+ bool is_2836)
 {
void __iomem *base;
int irq, b, i;
@@ -169,10 +171,34 @@ static int __init armctrl_of_init(struct device_node 
*node,
}
}
 
-   set_handle_irq(bcm2835_handle_irq);
+   if (is_2836) {
+   int parent_irq = irq_of_parse_and_map(node, 0);
+
+   if (!parent_irq) {
+   panic(%s: unable to get parent interrupt.\n,
+ node-full_name);
+   }
+   irq_set_chained_handler(parent_irq, bcm2836_chained_handle_irq);
+   } else {
+   set_handle_irq(bcm2835_handle_irq);
+   }
+
return 0;
 }
 
+static int __init bcm2835_armctrl_of_init(struct device_node *node,
+ struct device_node *parent)
+{
+   return armctrl_of_init(node, parent, false);
+}
+
+static int __init bcm2836_armctrl_of_init(struct device_node *node,
+ struct device_node *parent)
+{
+   return armctrl_of_init(node, parent, true);
+}
+
+
 /*
  * Handle each interrupt across the entire interrupt controller.  This reads 
the
  * status register before handling each interrupt, which is necessary given 
that
@@ -220,4 +246,15 @@ static void __exception_irq_entry bcm2835_handle_irq(
handle_IRQ(irq_linear_revmap(intc.domain, hwirq), regs

Rasperry Pi clock support

[Eric Anholt]

I'm also avoiding requests to set rate/state when they're a no-op, as
apparently no-op changes to pixel clock break the firmware-configured
display setup.  It *shouldn't* change anything, but I've confirmed
that setting the CPU clock works fine, and after a couple of weeks of
prodding pixel clock now, I'm at a loss for what's going on with it.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 3/3] ARM: bcm2835: Add DT for the firmware clocks driver.

[Eric Anholt]

Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Lee Jones l...@kernel.org
---

v2: Rename our compat string to mention bcm2835, and make our firmware
phandle be under a vendor-namespaced property.

v3: Squashed in the patches to reference the other clocks, to avoid
regressions now that we register all clocks at boot.  Dropped
Stephen's ack, since he hadn't acked the new EMMC change yet.

 arch/arm/boot/dts/bcm2835-rpi.dtsi | 18 ++
 arch/arm/boot/dts/bcm2835.dtsi |  3 +--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index ab5474e..5d370cb 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,3 +1,4 @@
+#include dt-bindings/clk/raspberrypi.h
 #include bcm2835.dtsi
 
 / {
@@ -20,6 +21,12 @@
compatible = raspberrypi,bcm2835-firmware;
mboxes = mailbox;
};
+
+   firmware_clocks: firmware-clocks {
+   compatible = raspberrypi,bcm2835-firmware-clocks;
+   #clock-cells = 1;
+   raspberrypi,firmware = firmware;
+   };
};
 };
 
@@ -55,4 +62,15 @@
 sdhci {
status = okay;
bus-width = 4;
+   clocks = firmware_clocks RPI_CLOCK_EMMC;
+};
+
+uart0 {
+   clocks = firmware_clocks RPI_CLOCK_UART0,
+firmware_clocks RPI_CLOCK_CORE;
+   clock-names = uartclk, apb_pclk;
+};
+
+spi {
+   clocks = firmware_clocks RPI_CLOCK_CORE;
 };
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 301c73f..5be2862 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -92,11 +92,10 @@
#interrupt-cells = 2;
};
 
-   uart@7e201000 {
+   uart0: uart@7e201000 {
compatible = brcm,bcm2835-pl011, arm,pl011, 
arm,primecell;
reg = 0x7e201000 0x1000;
interrupts = 2 25;
-   clock-frequency = 300;
arm,primecell-periphid = 0x00241011;
};
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 1/3] clk: bcm2835: Add binding docs for the Raspberry Pi clock provider

[Eric Anholt]

The hardware clocks are not controllable by the ARM, so we have to
make requests to the firmware to do so from the VPU side.  This will
let us replace fixed clocks in our DT with actual clock control (and
correct frequency information).

Signed-off-by: Eric Anholt e...@anholt.net
Acked-by: Stephen Warren swar...@wwwdotorg.org
Acked-by: Michael Turquette mturque...@baylibre.com
---

v2: Include the dt-bindings header in this commit instead of the next
one.  Make the clock indices match the firmware clock IDs.  Rename
the binding's compat string.  Move the firmware phandle to be
under a vendor-specific namespace.
v3: Mention 'clk' in the subject instead of the more generic
dt/bindings.

 .../clock/raspberrypi,bcm2835-firmware-clocks.txt  | 25 ++
 include/dt-bindings/clk/raspberrypi.h  | 23 
 2 files changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
 create mode 100644 include/dt-bindings/clk/raspberrypi.h

diff --git 
a/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
 
b/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
new file mode 100644
index 000..0972602
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/clock/raspberrypi,bcm2835-firmware-clocks.txt
@@ -0,0 +1,25 @@
+Raspberry Pi firmware clock provider.
+
+The Raspberry Pi architecture doesn't provide direct access to the
+CLOCKMAN peripheral from the ARM side, so Linux has to make requests
+to the VPU firmware to program them.
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible:  Should be raspberrypi,bcm2835-firmware-clocks
+
+- #clock-cells:Shall have value 1.  The permitted 
clock-specifier
+ values can be found in
+ include/dt-bindings/clk/raspberrypi.h.
+
+- raspberrypi,firmware:Phandle to the firmware driver node.
+
+Example:
+
+firmware_clocks: firmware-clocks {
+   compatible = raspberrypi,bcm2835-firmware-clocks;
+   #clock-cells = 1;
+   raspberrypi,firmware = firmware;
+};
diff --git a/include/dt-bindings/clk/raspberrypi.h 
b/include/dt-bindings/clk/raspberrypi.h
new file mode 100644
index 000..ceec90f
--- /dev/null
+++ b/include/dt-bindings/clk/raspberrypi.h
@@ -0,0 +1,23 @@
+#/*
+ *  Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _DT_BINDINGS_CLK_RASPBERRYPI_H
+#define _DT_BINDINGS_CLK_RASPBERRYPI_H
+
+#define RPI_CLOCK_EMMC 1
+#define RPI_CLOCK_UART02
+#define RPI_CLOCK_ARM  3
+#define RPI_CLOCK_CORE 4
+#define RPI_CLOCK_V3D  5
+#define RPI_CLOCK_H264 6
+#define RPI_CLOCK_ISP  7
+#define RPI_CLOCK_SDRAM8
+#define RPI_CLOCK_PIXEL9
+#define RPI_CLOCK_PWM  10
+
+#endif
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

Russell King - ARM Linux li...@arm.linux.org.uk writes:

 On Thu, Aug 13, 2015 at 01:44:03PM -0700, Eric Anholt wrote:
 Struct mutex is here because this code is from the V3D series, with the
 in-kernel BO cache ripped out (it turns out that the CMA allocator is
 slow, and you can't just userspace cache since we have to do allocations
 within the kernel to the tune of a couple per draw and that's too much).

 The CMA allocator is fast until you have pinned pages in its region,
 where it becomes _very_ slow to do allocations, sometimes getting up
 to the order of seconds.

 The main culpret of this are GFP_HIGHUSER_MOVABLE allocations which
 then pin the page.  It doesn't take many of those to make CMA really
 inefficient.

 The problem is that CMA doesn't get any information back from the
 internal page migration about which pages couldn't be moved, so it
 dumbly just tries incrementing the allocation by one page (subject
 to alignment constraints) and retrying again - repeating over the
 entire CMA region.  The bigger the region, the more time this takes.

Ouch.

Since I can workaround the allocation cost, the main problem I have
right now is that I've got a set of small allocations for 3D that all
need to have the same high 4 bits of paddr, because someone cleverly
packed some address bits in a GPU-managed structure.  Any
recommendations for ways to handle this with CMA?


signature.asc
Description: PGP signature

[PATCH v5 2/3] clk: Add a Raspberry Pi-specific clock driver.

[Eric Anholt]

Unfortunately, the clock manager's registers are not accessible by the
ARM, so we have to request that the firmware modify our clocks for us.

This driver only registers the clocks at the point they are requested
by a client driver.  This is partially to support returning
-EPROBE_DEFER when the firmware driver isn't supported yet, but it
also avoids issues with disabling unused clocks due to them not yet
being connected to their consumers in the DT.

Signed-off-by: Eric Anholt e...@anholt.net
---

v2: Declare the mutex static (from review by Baruch Siach), merge
description and copyright comments.

v3: Update for new rpi firmware API.  Update the compatible string.
Make the firmware handle be under a vendor-namespaced property.
Make the DT indices match the firmware clock IDs.  Move the driver
under the firmware driver's Kconfig, since it requires it.  Move a
container_of() from 2 callers into the callee.

v4: Update commit message to mention subsystem.  Add #defines for a
couple of bitfield checks, and use the bitfield check for
rpi_clk_is_on().  Return an error when appropriate in
rpi_clk_is_on(), and don't return specific rpi_firmware_property()
errors in other places when we were only returning -EINVAL.  Add
some comment text describing how return values work from
the firmware.

v5: Restructure as a platform_driver on suggestion from Michael
Turquette.  This works around the -EPROBE_DEFER problem, so now we
can register all of our clocks at probe time.  Store the current
clock rate in the struct, and avoid asking for no-op changes.  It
appears that a no-op change of the pixel clock while the clock is
being used (at boot time when the KMS driver calls
clk_prepare_enable()) actually breaks the display.  Dropped
Stephen's ack since this is a pretty significant rewrite.

 drivers/clk/Makefile  |   1 +
 drivers/clk/clk-raspberrypi.c | 286 ++
 2 files changed, 287 insertions(+)
 create mode 100644 drivers/clk/clk-raspberrypi.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index c4cf075..ad0a4a5 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_MACH_ASM9260)+= clk-asm9260.o
 obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)+= clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)   += clk-axm5516.o
 obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
+obj-$(CONFIG_RASPBERRYPI_FIRMWARE) += clk-raspberrypi.o
 obj-$(CONFIG_COMMON_CLK_CDCE706)   += clk-cdce706.o
 obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
 obj-$(CONFIG_ARCH_EFM32)   += clk-efm32gg.o
diff --git a/drivers/clk/clk-raspberrypi.c b/drivers/clk/clk-raspberrypi.c
new file mode 100644
index 000..a65a028
--- /dev/null
+++ b/drivers/clk/clk-raspberrypi.c
@@ -0,0 +1,286 @@
+/*
+ * Implements a clock provider for the clocks controlled by the
+ * firmware on Raspberry Pi.
+ *
+ * These clocks are controlled by the CLOCKMAN peripheral in the
+ * hardware, but the ARM doesn't have access to the registers for
+ * them.  As a result, we have to call into the firmware to get it to
+ * enable, disable, and set their frequencies.
+ *
+ * We don't have an interface for getting the set of frequencies
+ * available from the hardware.  We can request a min/max, but other
+ * than that we have to request a frequency and take what it gives us.
+ *
+ * Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include dt-bindings/clk/raspberrypi.h
+#include soc/bcm2835/raspberrypi-firmware.h
+
+#define RPI_FIRMWARE_CLOCK_STATE_ENABLED   (1  0)
+#define RPI_FIRMWARE_CLOCK_STATE_ERROR (1  1)
+#define RPI_FIRMWARE_SET_CLOCK_RATE_ERROR  0
+
+static const struct {
+   const char *name;
+   int flags;
+} rpi_clocks[] = {
+   [RPI_CLOCK_EMMC] = { emmc, CLK_IS_ROOT },
+   [RPI_CLOCK_UART0] = { uart0, CLK_IS_ROOT },
+   [RPI_CLOCK_ARM] = { arm, CLK_IS_ROOT | CLK_IGNORE_UNUSED },
+   [RPI_CLOCK_CORE] = { core, CLK_IS_ROOT | CLK_IGNORE_UNUSED },
+   [RPI_CLOCK_V3D] = { v3d, CLK_IS_ROOT },
+   [RPI_CLOCK_H264] = { h264, CLK_IS_ROOT },
+   [RPI_CLOCK_ISP] = { isp, CLK_IS_ROOT },
+   [RPI_CLOCK_SDRAM] = { sdram, CLK_IS_ROOT | CLK_IGNORE_UNUSED },
+   [RPI_CLOCK_PIXEL] = { pixel, CLK_IS_ROOT | CLK_IGNORE_UNUSED },
+   [RPI_CLOCK_PWM] = { pwm, CLK_IS_ROOT },
+};
+
+struct rpi_firmware_clock {
+   /* Clock definitions in our static struct. */
+   const char *name;
+   int flags;
+
+   /* The rest are filled in at init time. */
+   struct clk_hw hw;
+   struct device *dev;
+   struct rpi_firmware *firmware;
+   uint32_t last_rate

Re: [PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

Daniel Vetter dan...@ffwll.ch writes:

 On Wed, Aug 12, 2015 at 05:56:16PM -0700, Eric Anholt wrote:
 This is the start of a full VC4 driver.  Right now this just supports
 configuring the display using a pre-existing video mode (because
 changing the pixel clock isn't available yet, and doesn't work when it
 is).  However, this is enough for fbcon and bringing up X using
 xf86-video-modesetting.
 
 Signed-off-by: Eric Anholt e...@anholt.net
 ---
  drivers/gpu/drm/Kconfig   |   2 +
  drivers/gpu/drm/Makefile  |   1 +
  drivers/gpu/drm/vc4/Kconfig   |  14 +
  drivers/gpu/drm/vc4/Makefile  |  18 ++
  drivers/gpu/drm/vc4/vc4_bo.c  |  54 
  drivers/gpu/drm/vc4/vc4_crtc.c| 583 ++
  drivers/gpu/drm/vc4/vc4_debugfs.c |  38 +++
  drivers/gpu/drm/vc4/vc4_drv.c | 249 +++
  drivers/gpu/drm/vc4/vc4_drv.h | 123 +++
  drivers/gpu/drm/vc4/vc4_hdmi.c| 651 
 ++
  drivers/gpu/drm/vc4/vc4_hvs.c | 172 ++
  drivers/gpu/drm/vc4/vc4_kms.c |  84 +
  drivers/gpu/drm/vc4/vc4_plane.c   | 320 +++
  drivers/gpu/drm/vc4/vc4_regs.h| 562 
  14 files changed, 2871 insertions(+)
  create mode 100644 drivers/gpu/drm/vc4/Kconfig
  create mode 100644 drivers/gpu/drm/vc4/Makefile
  create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
  create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
  create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
  create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
  create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
  create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
  create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
  create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
  create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
  create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h

 Made a quick pass and found a few things to update to latest drm
 developments. Of course didn't look at the hardware details since no clue,
 but looks really nice overall.
 -Daniel

If you have anything about the hardware that you were curious about, I'd
be interested in trying to explain them in the comments to the extent
that I can.  It's unfortunate that we haven't shipped docs for the
display side of things, but had to do a lot of reading of the verilog
just to get this far, anyway.

 diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
 index c46ca31..1730a76 100644
 --- a/drivers/gpu/drm/Kconfig
 +++ b/drivers/gpu/drm/Kconfig
 @@ -240,3 +240,5 @@ source drivers/gpu/drm/sti/Kconfig
  source drivers/gpu/drm/amd/amdkfd/Kconfig
  
  source drivers/gpu/drm/imx/Kconfig
 +
 +source drivers/gpu/drm/vc4/Kconfig
 diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
 index 5713d05..b991ac5 100644
 --- a/drivers/gpu/drm/Makefile
 +++ b/drivers/gpu/drm/Makefile
 @@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA)  += mga/
  obj-$(CONFIG_DRM_I810)  += i810/
  obj-$(CONFIG_DRM_I915)  += i915/
  obj-$(CONFIG_DRM_MGAG200) += mgag200/
 +obj-$(CONFIG_DRM_VC4)  += vc4/
  obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
  obj-$(CONFIG_DRM_SIS)   += sis/
  obj-$(CONFIG_DRM_SAVAGE)+= savage/
 diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
 new file mode 100644
 index 000..130cc94
 --- /dev/null
 +++ b/drivers/gpu/drm/vc4/Kconfig
 @@ -0,0 +1,14 @@
 +config DRM_VC4
 +tristate Broadcom VC4 Graphics
 +depends on ARCH_BCM2835
 +depends on DRM
 +select DRM_KMS_HELPER
 +select DRM_KMS_FB_HELPER
 +select DRM_KMS_CMA_HELPER

 drm-misc/linux-next already has Archit's patches to enable/disable fbdev
 in the core code, so you don't need to bother about these selects here any
 more, it'll no-op out if drm fbdev emulation isn't enabled. Since you're
 reusing cma fbdev helpers I don't think there's any need for other changes
 because of this.

It sounds like I should rebase on that, then?

 +help
 +  Choose this option if you have a system that has a Broadcom
 +  VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
 +
 +  This driver requires that avoid_warnings=2 be present in
 +  the config.txt for the firmware, to keep it from smashing
 +  our display setup.
 diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
 new file mode 100644
 index 000..4aa07ca
 --- /dev/null
 +++ b/drivers/gpu/drm/vc4/Makefile
 @@ -0,0 +1,18 @@
 +ccflags-y := -Iinclude/drm
 +
 +# Please keep these build lists sorted!
 +
 +# core driver code
 +vc4-y := \
 +vc4_bo.o \
 +vc4_crtc.o \
 +vc4_drv.o \
 +vc4_kms.o \
 +vc4_hdmi.o \
 +vc4_hvs.o \
 +vc4_plane.o \
 +$()
 +
 +vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
 +
 +obj-$(CONFIG_DRM_VC4)  += vc4.o
 diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
 new file mode 100644
 index 000..fee8cac
 --- /dev/null
 +++ b/drivers/gpu/drm/vc4/vc4_bo.c
 @@ -0,0 +1,54 @@
 +/*
 + *  Copyright © 2015 Broadcom

Re: [GIT PULL] RPi DT changes due for v4.3

[Eric Anholt]

Olof Johansson o...@lixom.net writes:

 Hi,

 On Tue, Aug 11, 2015 at 05:06:42PM +0100, Lee Jones wrote:
 ARM SoC Chaps,
 
 Please find a couple of simple RPi changes pertaining to Firmware.
 
 The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:
 
   Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git 
 tags/rpi-dt-for-armsoc-4.3
 
 for you to fetch changes up to fd26f8830979de48eb3f1c253eb9d2ee2e468eb6:
 
   dt/bindings: Add binding for the Raspberry Pi firmware driver (2015-08-11 
 16:56:41 +0100)

 I've merged this but I'm a little confused about bcm2835 maintainership:
 I got a MAINTAINERS update from Florian earlier grouped in a set of
 other bcm changes (adding Eric), and now this directly from you.

 In general the bcm platforms are quite diverse and we've asked Florian
 to be the funnel for all of the new ones, but I don't think we talked
 much about 2835 at that time. Should we expect to see merges directly
 from you and the other maintainers there or will it go through Florian?

I'd been talking with Arnd and Florian about the delays in RPi patch
acceptance (Stephen and Lee have limited time to dedicate to 2835), and
Florian suggested me becoming a maintainer and routing patches through
him.  He's been great to work with and has had useful feedback on my
patches.

I was kind of surprised to see Lee send this pull request -- these
patches had been sitting un-merged for 2 months and pings on irc didn't
get replies, so I thought I was stepping in where the others definitely
didn't have time.  It was also odd to see just these two patches, but
not the actual driver.

I'm willing to do the merging process for 2835, and if I'm doing so, I
like the idea of feeding it through a more experienced maintainer who's
ready to look at my pull requests whenever, without bothering the main
arm-soc folks.  My goal here, besides my actual job of getting open
source graphics working for Broadcom, is to hopefully push the rpi
foundation toward getting their code merged, so that this hardware fully
works on stock upstream.


signature.asc
Description: PGP signature

Re: [PATCH v4 2/8] clk: Add a Raspberry Pi-specific clock driver.

[Eric Anholt]

Michael Turquette mturque...@linaro.org writes:

 Hi Eric,

 Quoting Eric Anholt (2015-07-20 12:33:01)
 +void __init rpi_firmware_init_clock_provider(struct device_node *node)
 +{
 +   /* We delay construction of our struct clks until get time,
 +* because we need to be able to return -EPROBE_DEFER if the
 +* firmware driver isn't up yet.  clk core doesn't support
 +* re-probing on -EPROBE_DEFER, but callers of clk_get can.
 +*/
 +   of_clk_add_provider(node, rpi_firmware_delayed_get_clk, node);
 +}
 +
 +CLK_OF_DECLARE(rpi_firmware_clocks, raspberrypi,bcm2835-firmware-clocks,
 +  rpi_firmware_init_clock_provider);

 Do you require CLK_OF_DECLARE here? Could this be a platform driver
 instead?

I'm not actually sure.  The common pattern seemed to be using
CLK_OF_DECLARE (130 files using it versus declaring a struct
platform_driver), and it seems to avoid a whole lot of boilerplate.
What would the advantage be?


signature.asc
Description: PGP signature

[GIT PULL] RPi SOC changes for v4.3

[Eric Anholt]

Following Lee's forwarding of the DT changes for the firmware driver for
4.3, here's the associated driver for the brcm arm-soc tree.

I think this is the first time RPi changes have been forwarded through
Florian.  It was suggested by Florian when I was discussing RPi
upstreaming with him and Arnd.  I think it makes sense, since general
-next trees for Broadcom are maintained there, and he's willing to
accept pull requests at any point.

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

  Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

  http://github.com/anholt/linux tags/rpi-soc-for-4.3-v1

for you to fetch changes up to d39ae82e65dc538295eea0384ed1ad8752dabbae:

  ARM: bcm2835: Add the Raspberry Pi firmware driver (2015-08-11 11:27:13 -0700)


This pull request contains the Raspberry Pi firmware driver, for
communicating with the VPU which has exclusive control of some of the
peripherals.


Eric Anholt (1):
  ARM: bcm2835: Add the Raspberry Pi firmware driver

 drivers/firmware/Kconfig   |   7 +
 drivers/firmware/Makefile  |   1 +
 drivers/firmware/raspberrypi.c | 260 +
 include/soc/bcm2835/raspberrypi-firmware.h | 115 +
 4 files changed, 383 insertions(+)
 create mode 100644 drivers/firmware/raspberrypi.c
 create mode 100644 include/soc/bcm2835/raspberrypi-firmware.h


signature.asc
Description: PGP signature