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?
> + 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()?
> +static int bcm2835_mbox_property_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + int ret = 0;
> +
> + mbox_property = devm_kzalloc(dev, sizeof(*mbox_property),
> + GFP_KERNEL);
> + if (!mbox_property) {
> + dev_err(dev, "Failed to allocate device memory\n");
Duplicate error message.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
