linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: b-cousson@ti.com (Cousson, Benoit)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod
Date: Thu, 20 Oct 2011 16:43:37 +0200	[thread overview]
Message-ID: <4EA03399.6080309@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1110131033410.24155@utopia.booyaka.com>

Hi Paul,

Sorry, I kind of forgot to answer that email.

On 10/13/2011 6:38 PM, Paul Walmsley wrote:
> On Wed, 12 Oct 2011, Cousson, Benoit wrote:
>
>> On 10/11/2011 1:26 AM, Paul Walmsley wrote:
>>> On Tue, 11 Oct 2011, Cousson, Benoit wrote:
>>>
>>>> In fact the device name does not have to match the hwmod name. So we
>>>> can just create an "omap2_prm" omap_device for OMAP2, "omap3_prm"
>>>> omap_device for OMAP3... That will allow the relevant PRM driver to
>>>> be bound to the proper device.
>>>
>>> Incidentally, given that we would be using the hwmod name and the version
>>> number to determine the appropriate omap_device name, what IP version
>>> numbers should we assign to these PRM IP blocks for different SoCs?
>>
>> It can just be 1, 2 and 3... The idea is just to differentiate the IP for each
>> OMAP.
>
> So those are basically arbitrary?  Something is not clear here.

Yeah, for me too, I think I did not get your concern...

> In the current hwmod design, IP blocks with different interfaces were
> intended to be uniquely identified by the hwmod name alone.  That is why
> omap_hwmod_lookup() only takes a 'name' parameter.
>
> If I understand what you want to do, you wish to change this to uniquely
> identify them by a (name, interface version number) tuple.

No, not for the same OMAP. The version is different for different OMAP 
version. So far the only IP with 2 different hwmod name for the same 
functionality is the timer. We have timer and timer_1ms, and that's for 
that kind of IP that we introduced the class to still be able to 
identify the functionality for the driver.

> I don't have a problem with this in theory, but it implies some changes to
> the existing model.  Specifically:
>
> - we'll need to add an interface version number to the struct omap_hwmod
>
> - we'll need to modify omap_hwmod_lookup() to take an interface version
> number
>
> - the "ti,hwmod" DT binding that you proposed earlier will need to include
> an interface version number

I still do not understand why we need that for the PRM.
AFAIK, we do have only one version of the PRM at the time. It is not 
similar to the timer case.

I'm still a little bit confused by your usecase.

You have only one PRM instance per OMAP. So you just have to do 
omap_hwmod_lookup("prm") to retrieve the relevant hwmod for the SoC.

If you need to build a different device per SoC to allow different 
driver to be bound to it, you can just append the version number to the 
hwmod name to build the device name.

Am I still missing something?

Regards,
Benoit

  parent reply	other threads:[~2011-10-20 14:43 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-23 12:46 [PATCHv9 00/18] omap PRCM chain handler Tero Kristo
2011-09-23 12:46 ` [PATCHv9 01/18] OMAP2+: hwmod: Add API to enable IO ring wakeup Tero Kristo
2011-09-23 12:46 ` [PATCHv9 02/18] OMAP2+: hwmod: Add API to check IO PAD wakeup status Tero Kristo
2011-09-23 12:46 ` [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod Tero Kristo
2011-10-10 19:24   ` Paul Walmsley
2011-10-10 19:54     ` Cousson, Benoit
2011-10-10 20:11       ` Paul Walmsley
2011-10-10 20:42       ` Paul Walmsley
2011-10-10 22:17         ` Cousson, Benoit
2011-10-10 22:35           ` Paul Walmsley
2011-10-12  8:14             ` Cousson, Benoit
2011-10-10 23:26           ` Paul Walmsley
2011-10-12  8:16             ` Cousson, Benoit
2011-10-13 16:38               ` Paul Walmsley
2011-10-13 16:51                 ` Paul Walmsley
2011-10-20 14:51                   ` Cousson, Benoit
2011-10-20 15:25                     ` Tero Kristo
2011-10-20 14:43                 ` Cousson, Benoit [this message]
2011-09-23 12:46 ` [PATCHv9 04/18] TEMP: OMAP4xxx: " Tero Kristo
2011-09-23 12:46 ` [PATCHv9 05/18] mfd: omap-prm: add driver skeleton Tero Kristo
2011-11-18 21:35   ` Kevin Hilman
2011-09-23 12:46 ` [PATCHv9 06/18] mfd: omap-prm: added chain interrupt handler Tero Kristo
2011-11-17 22:34   ` Kevin Hilman
2011-11-18 19:18     ` Felipe Balbi
2011-11-21 13:10       ` Tero Kristo
2011-09-23 12:46 ` [PATCHv9 07/18] mfd: omap-prm: added suspend prepare and complete callbacks Tero Kristo
2011-11-18 19:02   ` Kevin Hilman
2011-11-21 13:00     ` Tero Kristo
2011-09-23 12:46 ` [PATCHv9 08/18] OMAP2+: mux: add support for PAD wakeup interrupts Tero Kristo
2011-09-23 12:46 ` [PATCHv9 09/18] omap3: pm: use prcm chain handler Tero Kristo
2011-09-23 12:46 ` [PATCHv9 10/18] OMAP3: pm: do not enable PRCM MPU interrupts manually Tero Kristo
2011-09-23 12:46 ` [PATCHv9 11/18] omap3+: add omap prm driver initialization Tero Kristo
2011-09-23 12:46 ` [PATCHv9 12/18] TEMP: serial: added mux support Tero Kristo
2011-09-23 12:46 ` [PATCHv9 13/18] TEMP: 4430sdp: use common serial init with " Tero Kristo
2011-09-23 12:46 ` [PATCHv9 14/18] TEMP: mux: added trace for io wkup event Tero Kristo
2011-09-23 12:46 ` [PATCHv9 15/18] TEMP: OMAP3: pm: remove serial resume / idle calls from idle path Tero Kristo
2011-09-23 12:46 ` [PATCHv9 16/18] TEMP: OMAP3: serial: made serial to work properly with PRCM chain handler Tero Kristo
2011-09-23 12:46 ` [PATCHv9 17/18] TEMP: OMAP: serial: remove padconf hacks Tero Kristo
2011-09-23 12:46 ` [PATCHv9 18/18] TEMP: OMAP device: change pr_warnings to pr_debugs Tero Kristo
2011-09-23 22:23 ` [PATCHv9 00/18] omap PRCM chain handler Valdis.Kletnieks at vt.edu
2011-09-24  5:24   ` Sripathy, Vishwanath
2011-09-24  5:55     ` Valdis.Kletnieks at vt.edu

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=4EA03399.6080309@ti.com \
    --to=b-cousson@ti.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).