linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sameo@linux.intel.com (Samuel Ortiz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 01/13] mfd: pruss mfd driver.
Date: Tue, 22 Feb 2011 11:31:27 +0100	[thread overview]
Message-ID: <20110222103127.GC30279@sortiz-mobl> (raw)
In-Reply-To: <37B3755C4AE64BAA805DFBAEBDC3D9E4@subhasishg>

Hi Subhasish,

On Tue, Feb 22, 2011 at 11:13:38AM +0530, Subhasish Ghosh wrote:
> Thank you for your comments.
No problem.

> >>diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >>index fd01836..6c437df 100644
> >>--- a/drivers/mfd/Kconfig
> >>+++ b/drivers/mfd/Kconfig
> >>@@ -81,6 +81,16 @@ config MFD_DM355EVM_MSP
> >>   boards.  MSP430 firmware manages resets and power sequencing,
> >>   inputs from buttons and the IR remote, LEDs, an RTC, and more.
> >>
> >>+config MFD_DA8XX_PRUSS
> >>+ tristate "Texas Instruments DA8XX PRUSS support"
> >>+ depends on ARCH_DAVINCI && ARCH_DAVINCI_DA850
> >Why are we depending on those ?
> 
> SG -- The PRUSS core in only available within DA850 and DA830,
>            DA830 support is not yet implemented.
Sure, but if there are no actual code dependencies, I'd like to get rid of
those depends.

> >>+u32 pruss_disable(struct device *dev, u8 pruss_num)
> >>+{
> >>+ struct da8xx_pruss *pruss = dev_get_drvdata(dev->parent);
> >>+ da8xx_prusscore_regs h_pruss;
> >>+ u32 temp_reg;
> >>+
> >>+ if (pruss_num == DA8XX_PRUCORE_0) {
> >>+ /* Disable PRU0  */
> >>+ h_pruss = (da8xx_prusscore_regs)
> >>+ ((u32) pruss->ioaddr + 0x7000);
> >So it seems you're doing this in several places, and I have a few
> >comments:
> >
> >- You don't need the da8xx_prusscore_regs at all.
> >- Define the register map through a set of #define in your header file.
> >- Use a static routine that takes the core number and returns the
> >register map
> >offset.
> >
> >Then routines like this one will look a lot more readable.
> 
> SG -- There are a huge number of PRUSS registers. A lot of them are
> reserved and are expected to change as development on the
>            controller is still ongoing. 
First of all, from what I read in your patch you're only using the CONTROL
offset.

> If we use #defines to plot
> all the registers, then first, there are too many array type
> registers which will need to be duplicated.
What I'm expecting is a small set of defines for the register offsets. You
have 13 fields in your da8xx_prusscore_regs, you only need to define 13
register offsets.

So, if you have a:

static u32 reg_offset(struct device *dev, u8 pru_num)
{
	struct da8xx_pruss *pru = dev_get_drvdata(dev->parent);

	switch (pru_num) {
	case DA8XX_PRUCORE_0:
		return (u32) pru->ioaddr + 0x7000;
	case DA8XX_PRUCORE_1:
		return (u32) pru->ioaddr + 0x7800;
	default:
		return 0;
}


then routines like pruss_enable (which should return an int, btw) would look
like:

int pruss_enable(struct device *dev, u8 pruss_num)
{
	u32 offset = reg_offset(dev, pruss_num);

	if (offset == 0)
		return -EINVAL;

	__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
			offset + PRU_CORE_CONTROL);

	return 0;
}

> >Also, all your exported routines severely lack any sort of locking. An IO
> >mutex or spinlock is mandatory here.
> 
> SG - As per our current implementation, we do not have two devices
> running simultaneously on the PRU,
>        so we do not have any way to test it. We have kept this as an
> enhancement if request comes in for
>        multiple devices.
It's not about having multiple devices at the same time, it's about having
multiple callers writing and reading to the same registers. Since you're
exporting all your I/O routines you have no way to prevent 2 drivers from
writing to the same register at the "same" time. You need locking here,
regardless of the number of devices that you can have on a system.

 
> >>+static int pruss_mfd_add_devices(struct platform_device *pdev)
> >>+{
> >>+ struct da8xx_pruss_devices *dev_data = pdev->dev.platform_data;
> >>+ struct device *dev = &pdev->dev;
> >>+ struct mfd_cell cell;
> >>+ u32 err, count;
> >>+
> >>+ for (count = 0; (dev_data + count)->dev_name != NULL; count++) {
> >>+ memset(&cell, 0, sizeof(struct mfd_cell));
> >>+ cell.id = count;
> >>+ cell.name = (dev_data + count)->dev_name;
> >>+ cell.platform_data = (dev_data + count)->pdata;
> >>+ cell.data_size = (dev_data + count)->pdata_size;
> >>+
> >>+ err = mfd_add_devices(dev, 0, &cell, 1, NULL, 0);
> >>+ if (err) {
> >>+ dev_err(dev, "cannot add mfd cells\n");
> >>+ return err;
> >>+ }
> >>+ }
> >>+ return err;
> >>+}
> >So, what are the potential subdevices for this driver ? If it's a really
> >dynamic setup, I'm fine with passing those as platform data but
> >then do it so
> >that you pass a NULL terminated da8xx_pruss_devices array. That will avoid
> >most of the ugly casts you're doing here.
> 
> SG -- I did not follow your recommendations here, could you please
> elaborate.
>            I am already checking the dev_name for a NULL.
>            This device is basically a microcontroller within DA850,
> so basically any device or protocol can be
>            emulated on it. Currently, we have emulated 8 UARTS using
> the two PRUs and also a CAN device.
Ok, I wasnt sure you can emulate anything on that thing. So I'm fine with you
passing all your devices through platform_data. But I'd prefer this routine to
look like:

[...]
	for (count = 0; dev_data[count] != NULL; count++) {
		memset(&cell, 0, sizeof(struct mfd_cell));
		cell.id			= count;
		cell.name		= dev_data[count]->dev_name;
		cell.platform_data	= dev_data[count]->pdata;
		cell.data_size		= dev_data[count]->pdata_size;

Looks nicer to me.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

  reply	other threads:[~2011-02-22 10:31 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-11 14:51 [PATCH v2 00/13] pruss mfd drivers Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 01/13] mfd: pruss mfd driver Subhasish Ghosh
2011-02-21 16:30   ` Samuel Ortiz
2011-02-22  5:43     ` Subhasish Ghosh
2011-02-22 10:31       ` Samuel Ortiz [this message]
2011-02-22 10:48         ` Wolfgang Grandegger
2011-02-22 11:33           ` Samuel Ortiz
2011-02-22 12:49             ` Subhasish Ghosh
2011-02-22 16:27               ` Wolfgang Grandegger
2011-02-23 12:25         ` Subhasish Ghosh
2011-02-23 13:09         ` Russell King - ARM Linux
2011-02-11 14:51 ` [PATCH v2 02/13] da850: pruss platform specific additions Subhasish Ghosh
2011-02-11 18:41   ` Sergei Shtylyov
2011-02-18  7:18     ` Subhasish Ghosh
2011-02-28 13:04   ` TK, Pratheesh Gangadhar
2011-03-01  6:59     ` Subhasish Ghosh
2011-03-03 11:12       ` TK, Pratheesh Gangadhar
2011-02-11 14:51 ` [PATCH v2 03/13] da850: pruss board " Subhasish Ghosh
2011-02-11 18:43   ` Sergei Shtylyov
2011-02-18  7:18     ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 04/13] mfd: pruss CAN private data Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 05/13] da850: pruss CAN platform specific additions Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 06/13] da850: pruss CAN board " Subhasish Ghosh
2011-02-11 18:45   ` Sergei Shtylyov
2011-02-18  7:19     ` Subhasish Ghosh
2011-02-18  7:19     ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 07/13] da850: pruss CAN platform specific changes for gpios Subhasish Ghosh
2011-02-11 18:47   ` Sergei Shtylyov
2011-02-18  7:20     ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 08/13] da850: pruss CAN board " Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 09/13] can: pruss CAN driver Subhasish Ghosh
2011-02-11 15:06   ` Kurt Van Dijck
2011-02-14  4:54     ` Subhasish Ghosh
     [not found]       ` <4D58D854.5090503@grandegger.com>
2011-02-14  7:42         ` Kurt Van Dijck
2011-02-14  8:45         ` Subhasish Ghosh
     [not found]           ` <4D58F77B.9080005@pengutronix.de>
2011-02-14 13:15             ` Subhasish Ghosh
2011-02-11 15:20   ` Kurt Van Dijck
2011-02-18  7:07     ` Subhasish Ghosh
     [not found]       ` <4D5E2570.10108@grandegger.com>
2011-02-18  8:15         ` Subhasish Ghosh
2011-02-18  8:36           ` Marc Kleine-Budde
2011-02-18  9:09             ` Subhasish Ghosh
2011-02-18 15:07   ` Arnd Bergmann
2011-03-22  7:30     ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 10/13] mfd: pruss SUART private data Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 11/13] da850: pruss SUART board specific additions Subhasish Ghosh
2011-02-11 15:26   ` Michael Williamson
2011-02-18  7:13     ` Subhasish Ghosh
2011-02-11 18:50   ` Sergei Shtylyov
2011-02-22  6:22     ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 12/13] da850: pruss SUART platform " Subhasish Ghosh
2011-02-11 18:55   ` Sergei Shtylyov
2011-02-22  9:18     ` Subhasish Ghosh
2011-02-22 11:20       ` Sergei Shtylyov
2011-02-22 13:24         ` Subhasish Ghosh
2011-02-11 14:51 ` [PATCH v2 13/13] tty: pruss SUART driver Subhasish Ghosh
2011-02-11 16:28   ` Alan Cox
2011-02-18 13:47     ` Subhasish Ghosh
2011-02-18 14:35       ` Alan Cox
2011-02-18 18:23         ` Thomas Gleixner
2011-02-18 18:51           ` Arnd Bergmann
2011-02-22  8:42             ` Subhasish Ghosh
2011-02-22 14:37               ` Greg KH
2011-02-23  5:30                 ` Subhasish Ghosh
2011-02-23 18:20                   ` Greg KH
2011-02-22  8:43             ` Subhasish Ghosh
2011-02-22 16:34               ` Arnd Bergmann
2011-02-24 10:31                 ` Subhasish Ghosh
2011-02-22 10:26     ` Subhasish
2011-02-22 11:11       ` Alan Cox
2011-03-01 13:37         ` Subhasish Ghosh
2011-03-01 14:07           ` Alan Cox

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=20110222103127.GC30279@sortiz-mobl \
    --to=sameo@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.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 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).