public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: "Cousson, Benoit" <b-cousson@ti.com>
To: "Premi, Sanjeev" <premi@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: hwmod: multi-omap: disabling smartreflex on AM3517
Date: Tue, 15 Feb 2011 13:47:59 +0100	[thread overview]
Message-ID: <4D5A75FF.5040703@ti.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930248A017D9@dbde02.ent.ti.com>

Hi Sanjeev,

On 2/15/2011 12:51 PM, Premi, Sanjeev wrote:
> AM3517 doesn't support SmartReflex.
>
> However, these HWMODS are defined in omap3xxxx_hwmods[]:
> 	&omap34xx_sr1_hwmod,
> 	&omap34xx_sr2_hwmod,
> 	&omap36xx_sr1_hwmod,
> 	&omap36xx_sr2_hwmod,
>
> (similar definition in l4_slaves as well)
>
> This leads to crash when booting the kernel on AM3517EVM during
> _setup().
>
> I see the field .omap_chip being initialized; but not used.

Yes, it is. During the hwmod initialization (omap_hwmod_init), only the 
hwmods that match the correct chip version are kept.
I guess that your problem is that AM3517 is probably seen as a regular 
3430 for the moment.

> If I were to use this - along with cpu_is_omap3517(), I would need
> to define a new flag e.g. CHIP_IS_AM3517 and add it to almost all
> devices defined in omap_hwmod_3xxx_data.c.
>
> Before going all out on making changes, wanted to check if there is
> a better way. Has this/similar possibility been considered earlier?

Well, this is the best way to do that for my point of view. This 
.omap_chip field was done for that purpose.
During device init, the sr code will do query for the smartreflex hwmod 
and will failed, thus avoiding to do further initialization.

Regards,
Benoit


  reply	other threads:[~2011-02-15 12:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-15 11:51 hwmod: multi-omap: disabling smartreflex on AM3517 Premi, Sanjeev
2011-02-15 12:47 ` Cousson, Benoit [this message]
2011-02-18 12:13   ` Premi, Sanjeev
2011-02-21  9:57     ` Premi, Sanjeev
2011-02-21 10:30       ` Cousson, Benoit
2011-02-21 10:39         ` Premi, Sanjeev
2011-02-21 14:17           ` Cousson, Benoit
2011-02-21 15:41             ` Premi, Sanjeev
2011-02-21 23:40               ` Cousson, Benoit
2011-02-22 13:48                 ` Premi, Sanjeev
2011-02-22 22:53                   ` Cousson, Benoit
2011-02-23  8:46                     ` Premi, Sanjeev
2011-02-23 15:52                       ` Cousson, Benoit
2011-02-25 11:39                         ` Premi, Sanjeev
2011-02-25 12:40                           ` Cousson, Benoit

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=4D5A75FF.5040703@ti.com \
    --to=b-cousson@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=premi@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