From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Guruswamy Senthilvadivu <svadivu@ti.com>
Cc: khilman@deeprootsystems.com, tomi.valkeinen@nokia.com,
paul@pwsan.com, hvaibhav@ti.com, linux-omap@vger.kernel.org
Subject: Re: [PATCH v1 06/16] OMAP3: hwmod DSS: Build omap_device for each DSS HWIP
Date: Thu, 7 Oct 2010 21:30:04 +0200 [thread overview]
Message-ID: <20101007213004.178ef60b@surf> (raw)
In-Reply-To: <1286363699-9614-7-git-send-email-svadivu@ti.com>
Hello Senthil,
On Wed, 6 Oct 2010 16:44:49 +0530
Guruswamy Senthilvadivu <svadivu@ti.com> wrote:
> void __init omap_display_init(struct omap_dss_board_info
> *board_data)
> {
> + struct omap_hwmod *oh;
> + struct omap_device *od;
> + int l, i;
> + struct omap_display_platform_data pdata;
> + char *oh_name[] = {
> + "dss_dss",
> + "dss_dispc",
> + "dss_dsi1",
> + "dss_rfbi",
> + "dss_venc"
> + };
I think it's more common to write it this way:
char *oh_name[] = { "dss_dss", "dss_dispc", "dss_dsi1",
"dss_rfbi", "dss_venc" };
but I understand that this is just a matter of taste.
> +
> + for (i = 0; i < ARRAY_SIZE(oh_name); i++) {
> + l = snprintf(oh_name[i], MAX_OMAP_DSS_HWMOD_NAME_LEN,
> + oh_name[i]);
> + WARN(l >= MAX_OMAP_DSS_HWMOD_NAME_LEN,
> + "String buffer overflow in DSS device setup\n");
Using snprintf() just to get the length of a string is a bit overkill.
strlen() is part of the kernel API :-)
However, about the name, see below.
> +
> + oh = omap_hwmod_lookup(oh_name[i]);
> + if (!oh) {
> + pr_err("Could not look up %s\n", oh_name[i]);
> + return ;
No space needed between return and the semi-colon.
> + }
> + strncpy(pdata.name, oh_name[i], sizeof(oh_name[i]));
Why do you need this name into the platform_data ? omap_device_build()
will already fill the omap_device->platform_device->name field with
exactly oh_name[i]. So your drivers can just do platform_device->name
to get the name if they need it.
> + pdata.board_data = board_data;
> + pdata.board_data->get_last_off_on_transaction_id = NULL;
> + pdata.device_enable = omap_device_enable;
> + pdata.device_idle = omap_device_idle;
> + pdata.device_shutdown = omap_device_shutdown;
pdata is defined outside of the loop, so you're passing the same pdata
address to each omap_device_build() call. Therefore, there's no need to
initialize pdata at each iteration of the loop.
> +struct omap_display_platform_data {
> + char name[MAX_OMAP_DSS_HWMOD_NAME_LEN];
> + struct omap_dss_board_info *board_data;
> + int (*device_enable)(struct platform_device *pdev);
> + int (*device_shutdown)(struct platform_device *pdev);
> + int (*device_idle)(struct platform_device *pdev);
> +};
I'm probably missing something, but I don't see those new
device_enable, device_shutdown, device_idle fields being used in the
following patches in your series. Did I look at the wrong place ?
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2010-10-07 19:30 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-06 11:14 [PATCH v1 00/16] OMAP3: hwmod DSS Adaptation Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 01/16] OMAP2420: hwmod data: add DSS DISPC RFBI VENC Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 02/16] OMAP2430: " Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 03/16] OMAP3: hwmod data: add DSS DISPC RFBI DSI VENC Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 04/16] OMAP3: hwmod data: change dss_hwmod to dss_dss_hwmod Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 05/16] OMAP3 DSS Driver register moved to mach_omap2 Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 06/16] OMAP3: hwmod DSS: Build omap_device for each DSS HWIP Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 07/16] OMAP3: hwmod DSS: Create platform_driver for each DSS HW IP Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 08/16] OMAP3: clock data: change dss driver name Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 09/16] OMAP3: hwmod DSS: Move clocks from core driver to dss driver Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 10/16] OMAP3: hwmod DSS: DSS Move init,exit to driver Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 11/16] OMAP3: hwmod DSS: RFBI " Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 12/16] OMAP3: hwmod DSS: DISPC " Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 13/16] OMAP3: hwmod DSS: VENC " Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 14/16] OMAP3: hwmod DSS: DSI Move init, exit " Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 15/16] OMAP3: hwmod DSS: Use platform device to get baseaddr Guruswamy Senthilvadivu
2010-10-06 11:14 ` [PATCH v1 16/16] OMAP3: hwmod DSS: Get DSS IRQ from platform device Guruswamy Senthilvadivu
2010-10-07 20:00 ` [PATCH v1 14/16] OMAP3: hwmod DSS: DSI Move init, exit to driver Thomas Petazzoni
2010-10-07 19:57 ` [PATCH v1 13/16] OMAP3: hwmod DSS: VENC Move init,exit " Thomas Petazzoni
2010-10-08 7:09 ` Guruswamy, Senthilvadivu
2010-10-06 14:19 ` [PATCH v1 12/16] OMAP3: hwmod DSS: DISPC " Premi, Sanjeev
2010-10-07 6:16 ` Guruswamy, Senthilvadivu
2010-10-07 7:17 ` Cousson, Benoit
2010-10-07 8:44 ` Guruswamy, Senthilvadivu
2010-10-07 9:04 ` Cousson, Benoit
2010-10-07 19:48 ` Thomas Petazzoni
2010-10-07 19:47 ` [PATCH v1 11/16] OMAP3: hwmod DSS: RFBI " Thomas Petazzoni
2010-10-08 7:13 ` Guruswamy, Senthilvadivu
2010-10-07 19:47 ` [PATCH v1 07/16] OMAP3: hwmod DSS: Create platform_driver for each DSS HW IP Thomas Petazzoni
2010-10-07 19:49 ` Thomas Petazzoni
2010-10-08 7:11 ` Guruswamy, Senthilvadivu
2010-10-08 7:43 ` Thomas Petazzoni
2010-10-07 19:30 ` Thomas Petazzoni [this message]
2010-10-07 19:06 ` [PATCH v1 05/16] OMAP3 DSS Driver register moved to mach_omap2 Thomas Petazzoni
2010-10-08 6:54 ` Guruswamy, Senthilvadivu
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=20101007213004.178ef60b@surf \
--to=thomas.petazzoni@free-electrons.com \
--cc=hvaibhav@ti.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=svadivu@ti.com \
--cc=tomi.valkeinen@nokia.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