devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Sebastian Reichel <sre@kernel.org>
Cc: Felipe Balbi <balbi@ti.com>, Lokesh Vutla <lokeshvutla@ti.com>,
	"Kristo, Tero" <t-kristo@ti.com>,
	Linux ARM Kernel Mailing List
	<linux-arm-kernel@lists.infradead.org>,
	Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
	Paul Walmsley <paul@pwsan.com>, Nishanth Menon <nm@ti.com>,
	devicetree@vger.kernel.org
Subject: Re: [RFC/PATCH 5/7] arm: omap: hwmod: allow for registration of class-less hwmods
Date: Thu, 11 Dec 2014 09:32:28 -0800	[thread overview]
Message-ID: <20141211173228.GB2990@atomide.com> (raw)
In-Reply-To: <20141211005238.GC5585@earth.universe>

* Sebastian Reichel <sre@kernel.org> [141210 16:55]:
> On Wed, Dec 10, 2014 at 08:54:33AM -0600, Felipe Balbi wrote:
> > > @@ -2449,6 +2559,12 @@ static int __init _init(struct omap_hwmod *oh, void *data)
> > >  		else if (np && index)
> > >  			pr_warn("omap_hwmod: %s using broken dt data from %s\n",
> > >  				oh->name, np->name);
> > > +
> > > +		if (np) {
> > > +			r = omap_hwmod_init_sysc(np, oh, 0);
> > 
> > this won't handle any binding which lists more than one hwmod on its
> > ti,hwmods property.
> 
> I think Tony planned to remove this kind of multi hwmod references.

Yes we really should do that. But that involves repairs in the drivers,
dts files, and hwmod.

We really should aim for 1 to 1 to 1 mapping of the dts compatible
property to device hwmod to device sysc registers.

Once all the devices are mapped that way, we can deprecate
ti,hwmods in the dts files and set it up automatically based on
the compatible and the instance number of the device.

For an example of how to fix the interlaced device dts entries,
let's look at the EDMA. Instead of the current setup in
am33xx.dtsi:

edma: edma@49000000 {
	compatible = "ti,edma3";
	ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
	reg =   <0x49000000 0x10000>,
		<0x44e10f90 0x40>;
		interrupts = <12 13 14>;
		#dma-cells = <1>;
};

It really should be set up in the following way (eventually
without ti,hwmods):

edma: edma@49000000 {
	compatible = "ti,edma3";
	reg =   <0x49000000 0x10000>,
		<0x44e10f90 0x40>;
	interrupts = <12>;
	#dma-cells = <1>;
};

tptc0 {
	compatible = "ti,edma3-tptc";
	reg = <0x49800000 0x100000>;
	interrupts = <13>;
};

tptc1 {
	compatible = "ti,edma3-tptc";
	reg = <0x49900000 0x100000>;
	interrupts = <14>;
};

tptc2 {
	compatible = "ti,edma3-tptc";
	reg = <0x49900000 0x100000>;
	interrupts = <15>;
};

This is because each tptc entry has it's own sysc register and
can idle on it's own. With the above we can have 1 to 1 to 1 mapping
of compatible property to hwmod to sysc registers for each device.

> IMHO instead of DT referencing the hwmod stuff using ti,hwmods the
> hwmod database should reference the compatible values. This depends
> on omap3 being DT only of course.

Yes agreed.

Regards,

Tony

  parent reply	other threads:[~2014-12-11 17:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-09 22:27 [RFC/PATCH 0/7] arm: omap: move more HWMOD data to DT Felipe Balbi
2014-12-09 22:27 ` [RFC/PATCH 1/7] arm: omap: hwmod: add debugfs interface Felipe Balbi
2014-12-09 22:27 ` [RFC/PATCH 2/7] arm: omap: devicetree: add new properties for OMAP devices Felipe Balbi
2014-12-10 11:07   ` Lokesh Vutla
2014-12-10 15:00     ` Felipe Balbi
2014-12-11  0:46       ` Sebastian Reichel
2014-12-11 14:21         ` Felipe Balbi
2014-12-11 17:11           ` Tony Lindgren
2014-12-09 22:27 ` [RFC/PATCH 3/7] arm: omap: hwmod: drop 'const' qualifier from omap_hwmod_class name Felipe Balbi
2014-12-09 22:27 ` [RFC/PATCH 4/7] arm: omap: device: add support for generating sysconfig data from DT Felipe Balbi
     [not found]   ` <1418164072-19087-5-git-send-email-balbi-l0cyMroinI0@public.gmane.org>
2014-12-10 10:49     ` Lokesh Vutla
2014-12-10 14:48       ` Felipe Balbi
2014-12-09 22:27 ` [RFC/PATCH 5/7] arm: omap: hwmod: allow for registration of class-less hwmods Felipe Balbi
     [not found]   ` <1418164072-19087-6-git-send-email-balbi-l0cyMroinI0@public.gmane.org>
2014-12-10 10:50     ` Lokesh Vutla
2014-12-10 14:54       ` Felipe Balbi
2014-12-11  0:52         ` Sebastian Reichel
2014-12-11 14:23           ` Felipe Balbi
2014-12-11 17:44             ` Sebastian Reichel
2014-12-11 17:56               ` Tony Lindgren
2014-12-11 17:32           ` Tony Lindgren [this message]
2014-12-09 22:27 ` [RFC/PATCH 6/7] arm: boot: dts: am4372: add sysconfig data to all HWMODs Felipe Balbi
2014-12-09 22:27 ` [RFC/PATCH 7/7] arm: omap: hwmod: 43xx: remove sysc and class data Felipe Balbi
2014-12-09 22:30 ` [RFC/PATCH 0/7] arm: omap: move more HWMOD data to DT Felipe Balbi

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=20141211173228.GB2990@atomide.com \
    --to=tony@atomide.com \
    --cc=balbi@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=nm@ti.com \
    --cc=paul@pwsan.com \
    --cc=sre@kernel.org \
    --cc=t-kristo@ti.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).