All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Felipe Balbi <balbi@ti.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux USB Mailing List <linux-usb@vger.kernel.org>
Subject: Re: DeviceTree and children devices
Date: Mon, 24 Oct 2011 09:41:24 +0200	[thread overview]
Message-ID: <20111024074124.GB8708@ponder.secretlab.ca> (raw)
In-Reply-To: <20111024064227.GW5453@legolas.emea.dhcp.ti.com>

On Mon, Oct 24, 2011 at 09:42:28AM +0300, Felipe Balbi wrote:
> Hi Grant,
> 
> I have a question about how DeviceTree should be written in case a
> device has a child device.
> 
> The way things are integrated on OMAP is that we will always have a
> parent device which is a wrapper around an IP core in order to
> integrate with the OMAP context (clocks, power management, etc).
> 
> That wrapper has its own address space and its own IRQ number
> (generally). On my dwc3 driver I have modeled the OMAP wrapper as a
> parent device which allocates a child device for the core IP driver.
> This makes it a lot easier to re-use the core IP driver on other SoCs or
> PCI (there's a glue layer for PCI too).
> 
> So I wonder if we should describe that on DeviceTree and not have the
> OMAP glue layer allocate the core IP driver. Just to illustrate, here's
> what we have:
> 
> static int dwc3_omap_probe(struct platform_device *pdev)
> {
> 	struct platform_device	*dwc3;
> 	struct resource		res[2];
> 
> 	dwc3 = platform_device_alloc("dwc3", -1);
> 	/* check*/
> 
> 	dwc3->dev.parent = &pdev->dev;
> 
> 	/* copy DMA fields from parent too */
> 
> 	res[0].start = start_address;
> 	res[0].end = end_address;
> 	res[0].flags = IORESOURCE_MEM;
> 
> 	res[1].start = irq_number;
> 	res[1].flags = IORESOURCE_IRQ;
> 
> 	ret = platform_add_resources(dwc3, res, ARRAY_SIZE(res));
> 	/* check */
> 
> 	return platform_add_device(dwc3);
> }
> 
> and I wonder if I should have a DeviceTree like so:
> 
> usb@xxxxx {
> 	compatible = "ti,dwc3-omap";		// This is TI OMAP
> 						// wrapper
> 	range = <....>;
> 
> 	...
> 
> 	usb@yyyy {
> 		compatible = "synopsys,dwc3",	// This is core IP
> 						// inside wrapper
> 
> 		...
> 	};
> };
> 
> then I can drop the dwc3 platform_device allocation and all of that
> resource copying, etc.
> 
> What do you think ?

Looks reasonable to me.  of_platform_populate() should be able to
handle the device generation for you here.

g.


  reply	other threads:[~2011-10-24  7:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-24  6:42 DeviceTree and children devices Felipe Balbi
2011-10-24  7:41 ` Grant Likely [this message]
2011-10-24  7:49   ` Felipe Balbi
2011-10-24  7:58     ` Grant Likely
2011-10-24  8:12       ` Felipe Balbi
2011-10-24  8:23         ` Grant Likely

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=20111024074124.GB8708@ponder.secretlab.ca \
    --to=grant.likely@secretlab.ca \
    --cc=balbi@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.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.