linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).