From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: davinci-linux-open-source@linux.davincidsp.com
Cc: Prabhakar Lad <prabhakar.csengg@gmail.com>,
LMML <linux-media@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@infradead.org>
Subject: Re: [PATCH 01/14] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Date: Thu, 20 Sep 2012 00:01:45 +0200 [thread overview]
Message-ID: <2048611.Sb6fiWUyvr@avalon> (raw)
In-Reply-To: <1347626804-5703-2-git-send-email-prabhakar.lad@ti.com>
Hi Prabhakar,
Thanks for the patch.
On Friday 14 September 2012 18:16:31 Prabhakar Lad wrote:
> From: Manjunath Hadli <manjunath.hadli@ti.com>
>
> add support for dm3xx IPIPEIF hardware setup. This is the
> lowest software layer for the dm3x vpfe driver which directly
> accesses hardware. Add support for features like default
> pixel correction, dark frame substraction and hardware setup.
>
> Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
> Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
> ---
> drivers/media/platform/davinci/dm3xx_ipipeif.c | 318 +++++++++++++++++++++
> drivers/media/platform/davinci/dm3xx_ipipeif.h | 262 +++++++++++++++++++
> include/linux/dm3xx_ipipeif.h | 62 +++++
> 3 files changed, 642 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/platform/davinci/dm3xx_ipipeif.c
> create mode 100644 drivers/media/platform/davinci/dm3xx_ipipeif.h
> create mode 100644 include/linux/dm3xx_ipipeif.h
>
> diff --git a/drivers/media/platform/davinci/dm3xx_ipipeif.c
> b/drivers/media/platform/davinci/dm3xx_ipipeif.c new file mode 100644
> index 0000000..7961a74
> --- /dev/null
> +++ b/drivers/media/platform/davinci/dm3xx_ipipeif.c
[snip]
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/uaccess.h>
> +#include <linux/v4l2-mediabus.h>
> +#include <linux/platform_device.h>
Just a side note, I usually sort headers alphabetically, but feel free to use
whatever convention you like.
> +#include "dm3xx_ipipeif.h"
> +
> +static void *__iomem ipipeif_base_addr;
That's not good. You shouldn't have global constants like that. The value
should instead be stored in your device structure, that you will need to pass
around to all functions.
> +static inline u32 regr_if(u32 offset)
> +{
> + return readl(ipipeif_base_addr + offset);
> +}
> +
> +static inline void regw_if(u32 val, u32 offset)
> +{
> + writel(val, ipipeif_base_addr + offset);
> +}
Maybe ipipeif_read() and ipipeif_write() ?
> +void ipipeif_set_enable()
> +{
> + regw_if(1, IPIPEIF_ENABLE);
> +}
Please define constants in a header file for register values, masks and shifts
instead of hardcoding the raw numbers.
[snip]
> +static int __devinit dm3xx_ipipeif_probe(struct platform_device *pdev)
> +{
> + static resource_size_t res_len;
> + struct resource *res;
> + int status;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -ENOENT;
> +
> + res_len = resource_size(res);
> +
> + res = request_mem_region(res->start, res_len, res->name);
> + if (!res)
> + return -EBUSY;
> +
> + ipipeif_base_addr = ioremap_nocache(res->start, res_len);
> + if (!ipipeif_base_addr) {
> + status = -EBUSY;
> + goto fail;
> + }
> + return 0;
> +
> +fail:
> + release_mem_region(res->start, res_len);
> +
> + return status;
> +}
> +
> +static int dm3xx_ipipeif_remove(struct platform_device *pdev)
> +{
> + struct resource *res;
> +
> + iounmap(ipipeif_base_addr);
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (res)
> + release_mem_region(res->start, resource_size(res));
> + return 0;
> +}
> +
> +static struct platform_driver dm3xx_ipipeif_driver = {
> + .driver = {
> + .name = "dm3xx_ipipeif",
> + .owner = THIS_MODULE,
> + },
> + .remove = __devexit_p(dm3xx_ipipeif_remove),
> + .probe = dm3xx_ipipeif_probe,
> +};
> +
> +static int dm3xx_ipipeif_init(void)
> +{
> + return platform_driver_register(&dm3xx_ipipeif_driver);
> +}
> +
> +static void dm3xx_ipipeif_exit(void)
> +{
> + platform_driver_unregister(&dm3xx_ipipeif_driver);
> +}
> +
> +module_init(dm3xx_ipipeif_init);
> +module_exit(dm3xx_ipipeif_exit);
I'm not sure to like this. You're registering a module for a device that
essentially sits there without doing anything, except providing functions that
can be called by other modules.
I somehow feel that the way the code is split amongst the different layers
isn't optimal. Could you briefly explain the rationale behind the current
architecture ?
(BTW, please use the module_platform_driver() macro instead of
module_init/module_exit)
[snip]
> diff --git a/include/linux/dm3xx_ipipeif.h b/include/linux/dm3xx_ipipeif.h
> new file mode 100644
> index 0000000..1c1a830
> --- /dev/null
> +++ b/include/linux/dm3xx_ipipeif.h
[snip]
> +#include <media/davinci/vpfe_types.h>
> +#include <media/davinci/vpfe.h>
This header file defines part of the userspace API, but includes media/
headers that are not exported to userspace.
Header files should be split between 3 directories:
- Definitions required by platform data used to go to media/ but the new
include/linux/platform_data/ directory might be preferred nowadays. I have no
strong opinion on this, as other headers are already in media/ you can
probably keep using it for now.
- Definitions requires by userspace should go to include/linux/
- The rest should go to drivers/media/platform/davinci/.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2012-09-19 22:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 12:46 [PATCH 00/14] Media Controller capture driver for DM365 Prabhakar Lad
2012-09-14 12:46 ` [PATCH 01/14] davinci: vpfe: add dm3xx IPIPEIF hardware support module Prabhakar Lad
2012-09-19 22:01 ` Laurent Pinchart [this message]
2012-09-22 5:08 ` Prabhakar Lad
2012-09-14 12:46 ` [PATCH 02/14] davinci: vpfe: add IPIPE hardware layer support Prabhakar Lad
2012-09-23 14:36 ` Sakari Ailus
2012-09-24 4:59 ` Prabhakar Lad
2012-09-14 12:46 ` [PATCH 03/14] davinci: vpfe: add IPIPE support for media controller driver Prabhakar Lad
2012-09-14 12:46 ` [PATCH 04/14] davinci: vpfe: add support for CCDC hardware for dm365 Prabhakar Lad
2012-09-14 12:46 ` [PATCH 05/14] davinci: vpfe: add ccdc driver with media controller interface Prabhakar Lad
2012-09-14 12:46 ` [PATCH 06/14] davinci: vpfe: add v4l2 video driver support Prabhakar Lad
2012-09-14 13:30 ` Hans Verkuil
2012-09-22 5:03 ` Prabhakar Lad
2012-09-14 12:46 ` [PATCH 07/14] davinci: vpfe: v4l2 capture driver with media interface Prabhakar Lad
2012-09-14 12:46 ` [PATCH 08/14] davinci: vpfe: previewer driver based on v4l2 media controller framework Prabhakar Lad
2012-09-14 12:46 ` [PATCH 09/14] davinci: vpfe: resizer driver based on media framework Prabhakar Lad
2012-09-14 12:46 ` [PATCH 10/14] dm365: vpss: setup ISP registers Prabhakar Lad
2012-09-14 12:46 ` [PATCH 11/14] dm365: vpss: set vpss clk ctrl Prabhakar Lad
2012-09-14 12:46 ` [PATCH 12/14] dm365: vpss: add vpss helper functions to be used in the main driver for setting hardware parameters Prabhakar Lad
2012-09-14 12:46 ` [PATCH 13/14] davinci: vpfe: build infrastructure for dm365 Prabhakar Lad
2012-09-14 12:46 ` [PATCH 14/14] [media] davinci: vpfe: Add documentation Prabhakar Lad
2012-09-23 15:16 ` [PATCH 00/14] Media Controller capture driver for DM365 Sakari Ailus
2012-09-24 4:49 ` Prabhakar Lad
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=2048611.Sb6fiWUyvr@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=davinci-linux-open-source@linux.davincidsp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@infradead.org \
--cc=prabhakar.csengg@gmail.com \
/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.