All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Andy Gross <andy.gross@linaro.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v6 4/9] media: venus: adding core part and helper functions
Date: Tue, 7 Feb 2017 15:32:02 -0800	[thread overview]
Message-ID: <20170207233202.GI27837@minitux> (raw)
In-Reply-To: <1486473024-21705-5-git-send-email-stanimir.varbanov@linaro.org>

On Tue 07 Feb 05:10 PST 2017, Stanimir Varbanov wrote:

>  * firmware loader
> 

I like the way this turns out, just some style comments below.

[..]
> diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
> new file mode 100644
> index 000000000000..4057696abaf5
> --- /dev/null
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -0,0 +1,151 @@
> +/*
> + * Copyright (C) 2017 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * 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/dma-mapping.h>
> +#include <linux/firmware.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/slab.h>
> +#include <linux/qcom_scm.h>
> +#include <linux/soc/qcom/mdt_loader.h>
> +
> +#define VENUS_FIRMWARE_NAME		"venus.mdt"
> +#define VENUS_PAS_ID			9
> +#define VENUS_FW_MEM_SIZE		SZ_8M
> +
> +struct firmware_mem {
> +	struct device dev;
> +	void *mem_va;
> +	phys_addr_t mem_phys;
> +	size_t mem_size;
> +};
> +
> +static struct firmware_mem fw;

Rather than operating on a global variable I think you should either
return your firmware_mem pointer or the device pointer to the caller of
venus_boot() and have the core pass that back into venus_shutdown().

> +
> +static void device_release_dummy(struct device *dev)
> +{
> +}
> +
> +static int firmware_alloc_mem(struct device *parent, struct firmware_mem *fw)
> +{
> +	struct device_node *np;
> +	struct device *dev = &fw->dev;
> +	int ret;
> +
> +	np = of_get_child_by_name(parent->of_node, "video-firmware");
> +	if (!np)
> +		return -ENODEV;
> +
> +	memset(fw, 0, sizeof(*fw));

This should not be necessary.

Further more, if it's already initialized it's safe to assume that the
allocation below will fail - regardless of you clearing it or not.

> +
> +	dev->of_node = np;
> +	dev->parent = parent;
> +	dev->release = device_release_dummy;
> +
> +	ret = dev_set_name(dev, "venus-fw");
> +	if (ret)
> +		return ret;
> +
> +	ret = device_register(dev);
> +	if (ret < 0)
> +		return ret;
> +
> +	ret = of_reserved_mem_device_init(dev);
> +	if (ret)
> +		goto err_unreg_device;
> +
> +	fw->mem_size = VENUS_FW_MEM_SIZE;
> +
> +	fw->mem_va = dma_alloc_coherent(dev, fw->mem_size, &fw->mem_phys,
> +					GFP_KERNEL);

As this should follow the life of dev you can use dmam_alloc_coherent()
to reduce the clean up paths.

> +	if (!fw->mem_va) {
> +		ret = -ENOMEM;
> +		goto err_mem_device_release;
> +	}
> +
> +	return 0;
> +
> +err_mem_device_release:
> +	of_reserved_mem_device_release(dev);
> +err_unreg_device:
> +	device_unregister(dev);
> +	return ret;
> +}
> +
> +static void firmware_free_mem(struct firmware_mem *fw)
> +{
> +	dma_free_coherent(&fw->dev, fw->mem_size, fw->mem_va, fw->mem_phys);

If you use dmam_alloc_coherent() this goes.

> +	of_reserved_mem_device_release(&fw->dev);

And I would suggest that as this is related to the device you should
release it in the dev->release function; turning this function into
device_unregister(&fw->dev).


(The devres allocation will be freed right before the release function
is called)

> +	device_unregister(&fw->dev);
> +	memset(fw, 0, sizeof(*fw));

This should not be necessary.

> +}
> +
> +static int firmware_load(struct firmware_mem *fw)
> +{
> +	struct device *dev = &fw->dev;
> +	const struct firmware *mdt;
> +	ssize_t fw_size;
> +	int ret;
> +
> +	ret = request_firmware(&mdt, VENUS_FIRMWARE_NAME, dev);
> +	if (ret < 0)
> +		return ret;
> +
> +	fw_size = qcom_mdt_get_size(mdt);
> +	if (fw_size < 0) {
> +		ret = fw_size;
> +		goto err_release_fw;
> +	} else if (fw_size > VENUS_FW_MEM_SIZE) {

You can skip this this check, as qcom_mdt_load() will fail if any part
of the firmware doesn't fit - and we would benefit from making that
error message more verbose.

> +		ret = -ENOMEM;
> +		goto err_release_fw;
> +	}
> +
> +	ret = qcom_mdt_load(&fw->dev, mdt, VENUS_FIRMWARE_NAME, VENUS_PAS_ID,
> +			    fw->mem_va, fw->mem_phys, fw->mem_size);
> +
> +err_release_fw:

This is not only the error path, so "release_fw" would be better.

> +	release_firmware(mdt);
> +
> +	return ret;
> +}
> +
> +int venus_boot(struct device *parent)
> +{
> +	int ret;
> +
> +	if (!qcom_scm_is_available())
> +		return -EPROBE_DEFER;
> +
> +	ret = firmware_alloc_mem(parent, &fw);
> +	if (ret)
> +		return ret;
> +
> +	ret = firmware_load(&fw);
> +	if (ret) {
> +		firmware_free_mem(&fw);
> +		return ret;
> +	}
> +
> +	return qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
> +}
> +
> +int venus_shutdown(void)
> +{
> +	int ret;
> +
> +	ret = qcom_scm_pas_shutdown(VENUS_PAS_ID);
> +	firmware_free_mem(&fw);
> +	return ret;
> +}

Regards,
Bjorn

  reply	other threads:[~2017-02-07 23:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-07 13:10 [PATCH v6 0/9] Qualcomm video decoder/encoder driver Stanimir Varbanov
2017-02-07 13:10 ` [PATCH v6 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management Stanimir Varbanov
2017-02-07 13:10 ` [PATCH v6 2/9] doc: DT: venus: binding document for Qualcomm video driver Stanimir Varbanov
     [not found]   ` <1486473024-21705-3-git-send-email-stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-02-22  0:09     ` Rob Herring
2017-02-22  0:09       ` Rob Herring
2017-02-22  9:25       ` Stanimir Varbanov
     [not found]         ` <88584dd3-165f-2393-433e-95c288a8f473-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-02-22 14:17           ` Rob Herring
2017-02-22 14:17             ` Rob Herring
2017-02-23 13:08             ` Stanimir Varbanov
     [not found]               ` <ced61ede-1d51-18c1-ea00-731dc5887c58-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-02-23 13:16                 ` Rob Herring
2017-02-23 13:16                   ` Rob Herring
2017-02-07 13:10 ` [PATCH v6 3/9] MAINTAINERS: Add Qualcomm Venus video accelerator driver Stanimir Varbanov
2017-02-07 13:10 ` [PATCH v6 4/9] media: venus: adding core part and helper functions Stanimir Varbanov
2017-02-07 23:32   ` Bjorn Andersson [this message]
2017-02-08 15:01     ` Stanimir Varbanov
2017-02-07 13:10 ` [PATCH v6 5/9] media: venus: vdec: add video decoder files Stanimir Varbanov
2017-02-07 13:10 ` [PATCH v6 6/9] media: venus: venc: add video encoder files Stanimir Varbanov
2017-02-07 13:10 ` [PATCH v6 7/9] media: venus: hfi: add Host Firmware Interface (HFI) Stanimir Varbanov
2017-02-07 13:10 ` [PATCH v6 8/9] media: venus: hfi: add Venus HFI files Stanimir Varbanov
2017-02-07 13:10 ` [PATCH v6 9/9] media: venus: enable building of Venus video driver Stanimir Varbanov
2017-02-07 22:38   ` kbuild test robot
2017-02-07 22:38     ` kbuild test robot
2017-02-09 13:38     ` Stanimir Varbanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170207233202.GI27837@minitux \
    --to=bjorn.andersson@linaro.org \
    --cc=andy.gross@linaro.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=stanimir.varbanov@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.