From: Tony Lindgren <tony@atomide.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
"Péter Ujfalusi" <peter.ujfalusi@ti.com>,
"Benoît Cousson" <b-cousson@ti.com>
Subject: Re: [PATCH 02/11] ARM: OMAP4+: AESS: enable internal auto-gating during initial setup
Date: Thu, 7 Jun 2012 00:48:32 -0700 [thread overview]
Message-ID: <20120607074831.GY12766@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1206070121150.6684@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [120607 00:35]:
> On Thu, 7 Jun 2012, Tony Lindgren wrote:
>
> > It seems that most/many IP blocks need their custom reset hacks, and
> > it's not limited to just few instances?
>
> Only four out of the fifty-seven omap_hwmod_classes defined in
> mach-omap2/omap_hwmod_44xx_data.c after this series have custom reset
> functions used:
>
> $ fgrep 'struct omap_hwmod_class ' arch/arm/mach-omap2/omap_hwmod_44xx_data.c | wc -l
> 57
> $ fgrep '.reset' arch/arm/mach-omap2/omap_hwmod_44xx_data.c | wc -l
> 4
>
> That's 7% of the classes. In terms of the total number of IP block
> instances that use custom reset functions viewed against the total number
> of instances on the chip, the percentage is even smaller.
OK so that's not too bad then. But there's also the omap2_wd_timer_disable
pre_shutdown too. And there's also the sysconfig autoidle bit for each driver
that we're tweaking in the bus level code?
If we can remove the ioremapping and accessing driver registers in the bus
level code things get much simpler for the bus level code.
> > AFAIK there's no need to reset the IP blocks before the driver init,
> > it's really needed for PM. So it's not needed early on, and it's OK to
> > require running the driver init for driver modules that are not in use
> > to reset them properly. After all, the hardware is on the device, even
> > if it's not being used.
>
> I don't think I'm following you. It's not just PM; the problem is also
> with kexec or buggy bootloaders. If an IP block isn't reset when the
> kernel boots, and is doing DMA or anything else that could affect the
> reset of the system, it could easily cause unpredictable behavior or
> crashes in unrelated kernel code.
Still sounds like the responsibility of the bootloaders and drivers to
set things up properly, that's the standard behaviour.
> It's also worth mentioning that many IP blocks, such as AESS, don't have
> Linux drivers.
Sounds like it should have a minimal driver then, just to reset it if
nothing else.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/11] ARM: OMAP4+: AESS: enable internal auto-gating during initial setup
Date: Thu, 7 Jun 2012 00:48:32 -0700 [thread overview]
Message-ID: <20120607074831.GY12766@atomide.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1206070121150.6684@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [120607 00:35]:
> On Thu, 7 Jun 2012, Tony Lindgren wrote:
>
> > It seems that most/many IP blocks need their custom reset hacks, and
> > it's not limited to just few instances?
>
> Only four out of the fifty-seven omap_hwmod_classes defined in
> mach-omap2/omap_hwmod_44xx_data.c after this series have custom reset
> functions used:
>
> $ fgrep 'struct omap_hwmod_class ' arch/arm/mach-omap2/omap_hwmod_44xx_data.c | wc -l
> 57
> $ fgrep '.reset' arch/arm/mach-omap2/omap_hwmod_44xx_data.c | wc -l
> 4
>
> That's 7% of the classes. In terms of the total number of IP block
> instances that use custom reset functions viewed against the total number
> of instances on the chip, the percentage is even smaller.
OK so that's not too bad then. But there's also the omap2_wd_timer_disable
pre_shutdown too. And there's also the sysconfig autoidle bit for each driver
that we're tweaking in the bus level code?
If we can remove the ioremapping and accessing driver registers in the bus
level code things get much simpler for the bus level code.
> > AFAIK there's no need to reset the IP blocks before the driver init,
> > it's really needed for PM. So it's not needed early on, and it's OK to
> > require running the driver init for driver modules that are not in use
> > to reset them properly. After all, the hardware is on the device, even
> > if it's not being used.
>
> I don't think I'm following you. It's not just PM; the problem is also
> with kexec or buggy bootloaders. If an IP block isn't reset when the
> kernel boots, and is doing DMA or anything else that could affect the
> reset of the system, it could easily cause unpredictable behavior or
> crashes in unrelated kernel code.
Still sounds like the responsibility of the bootloaders and drivers to
set things up properly, that's the standard behaviour.
> It's also worth mentioning that many IP blocks, such as AESS, don't have
> Linux drivers.
Sounds like it should have a minimal driver then, just to reset it if
nothing else.
Regards,
Tony
next prev parent reply other threads:[~2012-06-07 7:48 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-07 6:13 [PATCH 00/11] ARM: OMAP: core/hwmod: first set of fixes for 3.5-rc Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 6:13 ` [PATCH 01/11] ARM: OMAP2+: hwmod: add setup_preprogram hook Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 6:13 ` [PATCH 02/11] ARM: OMAP4+: AESS: enable internal auto-gating during initial setup Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 7:19 ` Tony Lindgren
2012-06-07 7:19 ` Tony Lindgren
2012-06-07 7:31 ` Paul Walmsley
2012-06-07 7:31 ` Paul Walmsley
2012-06-07 7:48 ` Tony Lindgren [this message]
2012-06-07 7:48 ` Tony Lindgren
2012-06-07 10:45 ` Paul Walmsley
2012-06-07 10:45 ` Paul Walmsley
2012-06-07 11:08 ` Tony Lindgren
2012-06-07 11:08 ` Tony Lindgren
2012-06-07 6:13 ` [PATCH 03/11] ARM: OMAP4: hwmod data: add SL2IF hardreset line Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 6:13 ` [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb) Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 7:31 ` Tony Lindgren
2012-06-07 7:31 ` Tony Lindgren
2012-06-07 7:33 ` Felipe Balbi
2012-06-07 7:33 ` Felipe Balbi
2012-06-07 8:00 ` Tony Lindgren
2012-06-07 8:00 ` Tony Lindgren
2012-06-07 7:40 ` Paul Walmsley
2012-06-07 7:40 ` Paul Walmsley
2012-06-07 7:51 ` Tony Lindgren
2012-06-07 7:51 ` Tony Lindgren
2012-06-07 7:55 ` Felipe Balbi
2012-06-07 7:55 ` Felipe Balbi
2012-06-07 8:02 ` Cousson, Benoit
2012-06-07 8:02 ` Cousson, Benoit
2012-06-07 8:10 ` Tony Lindgren
2012-06-07 8:10 ` Tony Lindgren
2012-06-07 8:14 ` Felipe Balbi
2012-06-07 8:14 ` Felipe Balbi
2012-06-07 10:52 ` Paul Walmsley
2012-06-07 10:52 ` Paul Walmsley
2012-06-07 12:30 ` Cousson, Benoit
2012-06-07 12:30 ` Cousson, Benoit
2012-06-08 1:11 ` Paul Walmsley
2012-06-08 1:11 ` Paul Walmsley
2012-06-08 13:13 ` Cousson, Benoit
2012-06-08 13:13 ` Cousson, Benoit
2012-06-08 13:28 ` Paul Walmsley
2012-06-08 13:28 ` Paul Walmsley
2012-06-08 19:32 ` Hiremath, Vaibhav
2012-06-08 19:32 ` Hiremath, Vaibhav
2012-06-08 23:10 ` AM335x CPSW reset (was "RE: [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)") Paul Walmsley
2012-06-08 23:10 ` Paul Walmsley
2012-06-09 8:39 ` Hiremath, Vaibhav
2012-06-09 8:39 ` Hiremath, Vaibhav
2012-06-09 16:05 ` Paul Walmsley
2012-06-09 16:05 ` Paul Walmsley
2012-06-11 6:15 ` [PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb) Tony Lindgren
2012-06-11 6:15 ` Tony Lindgren
2012-06-11 8:04 ` Paul Walmsley
2012-06-11 8:04 ` Paul Walmsley
2012-06-11 9:24 ` Cousson, Benoit
2012-06-11 9:24 ` Cousson, Benoit
2012-06-11 16:20 ` Paul Walmsley
2012-06-11 16:20 ` Paul Walmsley
2012-06-07 10:20 ` Paul Walmsley
2012-06-07 10:20 ` Paul Walmsley
2012-06-07 10:52 ` Tony Lindgren
2012-06-07 10:52 ` Tony Lindgren
2012-06-07 22:05 ` Paul Walmsley
2012-06-07 22:05 ` Paul Walmsley
2012-06-08 6:38 ` Tony Lindgren
2012-06-08 6:38 ` Tony Lindgren
2012-06-09 1:31 ` Paul Walmsley
2012-06-09 1:31 ` Paul Walmsley
2012-06-11 6:21 ` Tony Lindgren
2012-06-11 6:21 ` Tony Lindgren
2012-06-07 6:13 ` [PATCH 05/11] ARM: OMAP2+: hwmod code/data: fix 32K sync timer Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 6:59 ` Hiremath, Vaibhav
2012-06-07 6:59 ` Hiremath, Vaibhav
2012-06-07 7:08 ` Paul Walmsley
2012-06-07 7:08 ` Paul Walmsley
2012-06-07 18:09 ` Hiremath, Vaibhav
2012-06-07 18:09 ` Hiremath, Vaibhav
2012-06-07 20:03 ` Paul Walmsley
2012-06-07 20:03 ` Paul Walmsley
2012-06-08 19:10 ` Hiremath, Vaibhav
2012-06-08 19:10 ` Hiremath, Vaibhav
2012-06-11 9:12 ` Cousson, Benoit
2012-06-11 9:12 ` Cousson, Benoit
2012-06-08 13:22 ` Tero Kristo
2012-06-08 13:22 ` Tero Kristo
2012-06-08 23:18 ` Paul Walmsley
2012-06-08 23:18 ` Paul Walmsley
2012-06-07 6:13 ` [PATCH 06/11] ARM: OMAP4+: hwmod: fix issue causing IPs not going back to Smart-Standby Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 6:13 ` [PATCH 07/11] ARM: OMAP: PM: Lock clocks list while generating summary Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 6:13 ` [PATCH 08/11] ARM: OMAP2+: CM: increase the module disable timeout Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 6:13 ` [PATCH 09/11] ARM: OMAP4: clock data: add clockdomains for clocks used as main clocks Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 6:39 ` Rajendra Nayak
2012-06-07 6:39 ` Rajendra Nayak
2012-06-18 17:41 ` Paul Walmsley
2012-06-18 17:41 ` Paul Walmsley
2012-06-19 5:15 ` Rajendra Nayak
2012-06-19 5:15 ` Rajendra Nayak
2012-06-07 6:13 ` [PATCH 10/11] ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-07 6:13 ` [PATCH 11/11] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init Paul Walmsley
2012-06-07 6:13 ` Paul Walmsley
2012-06-08 13:30 ` [PATCH 00/11] ARM: OMAP: core/hwmod: first set of fixes for 3.5-rc Tero Kristo
2012-06-08 13:30 ` Tero Kristo
2012-06-09 1:15 ` Paul Walmsley
2012-06-09 1:15 ` Paul Walmsley
2012-06-13 23:55 ` Paul Walmsley
2012-06-13 23:55 ` Paul Walmsley
2012-06-14 7:36 ` Tero Kristo
2012-06-14 7:36 ` Tero Kristo
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=20120607074831.GY12766@atomide.com \
--to=tony@atomide.com \
--cc=b-cousson@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=peter.ujfalusi@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 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.