Re: [PATCH 09/10] ARM: bcm2835: Add the mailbox property channel driver.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Stephen Warren <swarren@xxxxxxxxxxxxx> writes:

> On 03/02/2015 01:54 PM, Eric Anholt wrote:
>> Many of the operations with the firmware are done through this mailbox
>> channel pair with a specific packet format.  Notably, it's used for
>> clock control, which is apparently not actually totally possible to do
>> from the ARM side (some regs aren't addressable).  I need clock
>> control for the VC4 DRM driver, to turn on the 3D engine.
>
>> diff --git a/drivers/mailbox/bcm2835-mailbox-property.c b/drivers/mailbox/bcm2835-mailbox-property.c
>> +int bcm_mbox_property(void *data, size_t tag_size)
>
>> +	buf = dma_alloc_coherent(NULL, PAGE_ALIGN(size), &bus_addr, GFP_ATOMIC);
>> +	if (!buf)
>> +		return -ENOMEM;
>
> Can't the driver (this one or the client) maintain some persistent
> buffer rather than allocating/freeing a new one each time. It seems like
> the alloc/free might introduce quite some overhead?

The size of the buffer is arbitrary (up to 1MB), the frequency of
requessts is low, and the hardware's pretty starved for RAM.  However,
we're probably only ever going to see single page allocations, so the
RAM cost is probably low and the allocation time is probably also
correspondingly low (not like when I was trying to do 256k allocations
in the vc4 driver.  ouch).

>> +	writel(size, buf);
>> +	writel(bcm_mbox_status_request, buf + 4);
>> +	memcpy_toio(buf + 8, data, tag_size);
>> +	writel(bcm_mbox_property_end, buf + size - 4);
>
> Since this is just a regular chunk of RAM, can't the code just use
> regular memory writes and memcpy()?

will wmb() guarantee that the compiler won't optimize out my write to
buf[0] and corresponding read from buf[0]?  I was originally treating it
as RAM and using volatile, but then reread the old "don't use volatile"
doc.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux