Re: [PATCH 07/13] ARM: OMAP5: l3: Add l3 error handler support for omap5.
Tony,
On Mon, May 7, 2012 at 11:04 PM, Tony Lindgren t...@atomide.com wrote:
* R, Sricharan r.sricha...@ti.com [120506 00:42]:
Hi Tony,
- if (!(cpu_is_omap44xx()))
+ if ((!(cpu_is_omap44xx())) (!cpu_is_omap54xx()))
return -ENODEV;
for (i = 0; i L3_MODULES; i++) {
Isn't there some unnecessary parens here?
You mean in this above for loop?.
There are multiple statements .
No, both the old (!(cpu_is_omap44xx())) and the added one.
oh ok, will remove those extra ones. Thanks.
Thanks,
Sricharan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ARM: OMAP4: Don't compile cm2xxx_3xxx.c for OMAP4 only builds.
On Tue, May 8, 2012 at 10:39 AM, Paul Walmsley p...@pwsan.com wrote: On Wed, 2 May 2012, Santosh Shilimkar wrote: Since OMAP4 code base now makes use of OMAP4 specific PRCM functions, cm2xxx_3xxx.c need not be compiled for OMAP4 only builds. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com Acked-by: Paul Walmsley p...@pwsan.com Will remove the stub functions in a separate patch. ok -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] ARM: OMAP4+: Add prm and cm base init function.
On Tue, May 8, 2012 at 10:45 AM, Paul Walmsley p...@pwsan.com wrote: On Wed, 2 May 2012, Santosh Shilimkar wrote: From: R Sricharan r.sricha...@ti.com Instead of statically defining seperate arrays for every OMAP4+ archs, have a generic init function to populate the arrays. This avoids the need for creating new array for every arch added in the future that reuses the prm and cm registers read/write code. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks, looks reasonable, will queue this for 3.5. Great. I will drop this one from my clean-up pull request. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion
Hi Jon,
On Mon, May 07, 2012 at 21:32:58, Hunter, Jon wrote:
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, multiple waitpins selected on CS:%u\n, cs);
+ return -EINVAL;
+ break;
+ }
Why not combined case 0 and default? Both are invalid configurations so
just report invalid selection.
Case 0 is not invalid, a case where waitpin is not used, default refers
to when a user selects multiple waitpins wrongly.
Ok. Then for case 0, just return here. If the polarity is set, you could
print an error here.
Different ways of doing things, this looks cleaner to me as already it is
checked, and time of execution in both cases would not differ much.
+ if (gd-have_waitpin) {
+ if (gd-waitpin != idx ||
+ gd-waitpin_polarity != polarity) {
+ dev_err(gpmc-dev, error: conflict: waitpin %u
with polarity %d on device %s.%d\n,
+ gd-waitpin, gd-waitpin_polarity,
+ gd-name, gd-id);
+ return -EBUSY;
+ }
+ } else {
Don't need the else as you are going to return in the above.
Not always, only in case of error
Ok, but seems that it can be simplified a little.
What happens if a device uses more than one wait-pin? In other words a
device with two chip-selects that uses two wait-pins?
Please re-read
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67702.html
and your reply
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 02/39] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Jon, On Mon, May 07, 2012 at 21:42:35, Hunter, Jon wrote: Clk_prd is a platform data passed to the driver, so platform code updates it, where else can it be done ? The point is that you can pass what ever you like. You do not need to pass the frequency you can pass the clock handle instead. As clk rate is required in platform code for timing calculation, and already available, period was passed What happens it the clk_get() of the gpmc_l3_clk fails during the init? Thanks for bringing this point, invalid clk_prd has to be handled by driver. In fact if you migrate to runtime pm then we should not have the clk_get in the gpmc_init any more. Even if converted to RPM, to get clk rate, clk_get has to be done somewhere, right ? Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion
Hi Jon, On Mon, May 07, 2012 at 21:53:34, Hunter, Jon wrote: Write protect is a pin and there is only one. Like the waitpins and CS signals this needs to be associated with a device. It would make sense that this is associated with the cs data. As far as platform are concerned, it is associated with cs, it is only that while configuring CS, it is propagated such that it is done once. Hmmm ... but here it looks like if write-protect is used you are going to turn it on. A feature like this seems that it does need to be handled by the device's driver. Enabling and disabling write-protect are functions that I would expect are exported to the device's driver and not directly enabled in the gpmc driver during probe. However, maybe is could be valid for the write protect to be enabled by default which could make sense. However, I don't see anywhere else in the driver to control it. Shouldn't we warn on multiple devices trying to use write-protect when parsing their configuration? Even if a single device sets write protect, kernel will log it. That does not seem sufficient. It should be flagged as an error. Write protect is a resource like the CS and waitpins and so I would have thought that it should be reserved in the same way. Isn't it valid for multiple devices to make use of write protect pin ? Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure
On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote: A call to request_mem_region() has been introduced in the omap-gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, gpio/omap: Use devm_ API and add request_mem_region). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. Aiaiai found out that your patch adds this gcc warning: Successfully built configuration l2_omap1_defconfig,arm,arm-unknown-linux-gnueabi-, results: --- before_patching.log +++ after_patching.log @@ @@ +drivers/mtd/nand/ams-delta.c: In function 'ams_delta_cleanup': +drivers/mtd/nand/ams-delta.c:285:19: warning: unused variable 'res' [-Wunused-variable] -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 1/4] OMAPDSS: APPLY: Add manager timings as extra_info in private data
On Tue, 2012-05-08 at 09:54 +0530, Archit Taneja wrote: Hi, On Monday 07 May 2012 08:17 PM, Tomi Valkeinen wrote: Hi, dss_ovl|mgr_enable|disable functions handle GO, so you could have a look at them. However, setting the timings is a bit different, so I'm not sure how it should be done. I think we have a few different options: - Separate omapdss internal function (in apply.c) that can be used to set GO after set_timings - set GO in dss_mgr_set_timings(), but don't block - set GO in dss_mgr_set_timings(), and block until the changes are in HW (this is more or less what the dss_ovl|mgr_enable|disable functions do). The first one would be good if the interface drivers would need to set multiple configurations, and we don't want to block after each set call. But we don't have anything like that, at least currently. The second one avoids blocking, but could perhaps cause problems because the timings are not actually used yet when the function returns. I don't see any problem with the last option, so I'm slightly leaning towards it. The 3rd option looks good to me too, but I'm wondering if we would need to do the same things with all manager parameters which are in shadow registers. Like in dpi.c, in dpi_set_mode() we set the DISPC_POL_FREQ and DISPC_DIVISORo registers, writing GO for each parameter would be in efficient, it's good that it doesn't happen much often. Maybe we could group the rest of these parameters. Hmm, that's true. We could make shortcuts with settings that are only changed while the display is off. For example, currently DISPC_POL_FREQ cannot be changed dynamically, so it could only be set when before enabling the output. However, it seems we currently do call dispc_mgr_set_pol_freq() in dpi_set_mode(), which could be called when the output is enabled. But even then we always set the same values, so it doesn't matter. For DISPC_DIVISORo, I guess we could make a shortcut with that also. While it is a shadow register, when we are changing the dss clocks we also set non-shadowed registers. So I think the best way to change clock frequencies is to turn off the output temporarily. Perhaps all the shadow registers currently being set directly from interface drivers are such settings? The code should still be changed so that we only touch the registers when enabling the output. But, of course, a better design and also more future proof would be to handle all shadow registers properly, even if we currently only set them while the output is off. That may be left for future, though. In any case, I think we should mark clearly the places where we set shadow registers directly, without using the apply.c. Perhaps we should even mark all the dispc functions that set shadow registers, like dispc_mgr_set_pol_freq_sh(). But let's not do that now either, as we're quite close to merge window. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 3.4-rc6] MTD: NAND: ams-delta: fix request_mem_region() failure
On Tue, 2012-05-08 at 10:03 +0300, Artem Bityutskiy wrote: On Mon, 2012-05-07 at 22:51 +0200, Janusz Krzysztofik wrote: A call to request_mem_region() has been introduced in the omap-gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, gpio/omap: Use devm_ API and add request_mem_region). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. Aiaiai found out that your patch adds this gcc warning: Successfully built configuration l2_omap1_defconfig,arm,arm-unknown-linux-gnueabi-, results: --- before_patching.log +++ after_patching.log @@ @@ +drivers/mtd/nand/ams-delta.c: In function 'ams_delta_cleanup': +drivers/mtd/nand/ams-delta.c:285:19: warning: unused variable 'res' [-Wunused-variable] But I've fixed this up and pushed to l2-mtd.git. From the commit message I have an impression that you are not going to implement that longer term plan. Dunno if Tony has a plan to force someone to do this by blocking some changes which are not urgent fixes. Hmm? :-) -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[GIT PULL] ARM: OMAP2+: Misc cleanup
Tony,
Please pull the following preparatory cleanup series to add OMAP5 minimal
support. Boot tested on OMAP2430 SDP, OMAP3430 SDP and OMAP4430 SDP platforms.
I have dropped {[PATCH 7/7] ARM: OMAP4+: Add prm and cm base init function}
from this set since Paul is taking that one in his queue.
P.S: While merging this series with linux-omap master, I saw one trivial
Makefile conflict.
The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a:
Linux 3.4-rc5 (2012-04-29 15:19:10 -0700)
are available in the git repository at:
git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
for_3.5/omap_misc_cleanup
R Sricharan (1):
ARM: OMAP2+: dma: Define dma capabilities register bitfields and use them.
Santosh Shilimkar (6):
ARM: OMAP4: Don't compile cm2xxx_3xxx.c for OMAP4 only builds.
ARM: OMAP2+: Clean up wrapping multiple objects in Makefile
ARM: OMAP4: Remove un-used WakeupGen register defines.
ARM: OMAP: dma: Make use of cpu_class_is_omap2() to avoid future patching.
ARM: All OMAP2PLUS machines use omap2 directory so just add one entry
ARM: OMAP4: Reduce the static IO mapping
arch/arm/Makefile |4 +-
arch/arm/mach-omap2/Makefile | 163 ++---
arch/arm/mach-omap2/dma.c | 11 +-
arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |8 -
arch/arm/mach-omap2/io.c | 30
arch/arm/mach-omap2/iomap.h | 28
arch/arm/plat-omap/dma.c |4 +-
arch/arm/plat-omap/include/plat/dma.h |5 +
8 files changed, 93 insertions(+), 160 deletions(-)
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Tue, 2012-05-08 at 10:33 +0530, Archit Taneja wrote:
On Monday 07 May 2012 08:33 PM, Tomi Valkeinen wrote:
On Thu, 2012-05-03 at 12:37 +0530, Archit Taneja wrote:
In order to check the validity of overlay and manager info, there was a
need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't
need to
rely on the display resolution any more.
Create a function dss_mgr_get_timings() which returns the timings in
manager's
private data. Remove the need of passing omap_dss_device structs in the
functions which check for overlay and managers.
Have some initial values for manager timings in apply_init(), these would
ensure
that manager checks don't fail if an interface driver or a panel driver
hasn't
set the manager timings yet.
Signed-off-by: Archit Tanejaarc...@ti.com
+struct omap_video_timings *dss_mgr_get_timings(struct
omap_overlay_manager *mgr)
+{
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ returnmp-timings;
+}
This one returns a pointer into apply.c's internal data structures. The
safest way would be to return a copy, but as it's an omapdss internal
function, I think it's enough to return a pointer to a const struct.
Okay I'll fix that, I was a bit concerned about the locking here, I use
this function in the later series to remove some dssdev references in
dispc.c. I traced the paths and saw that in all cases this function
would be protected by the data_lock spinlock, but not the apply_lock
mutex in all cases. Any thoughts on this?
Hmm, you're right, locking here gets a bit confusing. set_timings has
locks, so logically get_timings should also. But I guess all the uses of
get_timings happens via apply.c, and apply.c already holds the
data_lock, as you said?
Making the get_timings function public (inside omapdss) is a bit nasty,
as it's quite easy to call it without having the appropriate locks. And
actually there's no way to acquire the locks outside apply.c
I'm not sure if it applies here, but as a general strategy, I suggest
doing things in apply.c that require data from apply.c's internal data.
When that's not possible, apply.c should call the functions outside
apply.c, and pass the internal data as parameters (like calls to dispc).
In your case, I for example see dss_mgr_check() calling
dss_mgr_get_timings(). It would be quite easy to pass the timings to
dss_mgr_check() from apply.c, thus removing the need to call the
function. And, as you see, dss_mgr_check() already has a bunch of
parameters, and the idea is the same with those: give the params, so
that dss_mgr_check() doesn't need to ask for them.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 0/7] ARM: OMAP2+: Misc cleanup
On Tuesday 08 May 2012 04:33 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120502 02:51]: This series has some miscellianeous clean up patches which help to add future OMAP2+ device support with bit less changes. It is a preparatory series for adding minimal OMAP5 support. Is this ready to be pulled? Yes. I just sent a pull request to you after dropping [PATCH 7/7] since Paul is taking that in his 3.5 queue. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
On Tuesday 08 May 2012 03:56 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120507 02:53]: Tony, On Thursday 03 May 2012 12:56 PM, R Sricharan wrote: The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Series is generated against the 3.4-rc5. This has been rebased on top of the OMAP2+ cleanup series [1] To get the boot working with omap2plus_defconfig, OMAP5 hwmod/clock/prm/cm database needs to be added. The data and the integrated tree are available in the below git repository OMAP5_DATA: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_data OMAP5_INTEGRATED: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_dt_integrated The series is boot tested on OMAP5430 ES1.0. OMAP2/3/4 build and boot is tested as well to avoid any breakage because of the series. Patch TEMP: ARM: OMAP5: Add cpu_is_omap54xx() checks is temporary and can be dropped once rebased against [2] Patch TEMP: ARM: OMAP5: Update the base address of the 32k-counter is temporary and can be dropped once rebased against [3] [1] http://www.spinics.net/lists/linux-omap/msg69233.html [2] http://www.spinics.net/lists/linux-omap/msg69013.html [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67166.html Do you have a branch where above dependencies are merged ? Seems like those should go into the cleanup branch, and then that can be used as a base. Yep. That will be a good base. How do you suggest to go about updating this series so that above dependencies plus DT support(3.3 based branch in arm-soc tree and needs to be updated against 3.4) is base tree for the patchset. Probably the DT patch should be separate, we can make dt branch depend on the cleanup branch. Sounds good. Btw, who is re-basing the omap-dt branch against 3.4 ? Then the data files should be first posted for reviews (and potentially updated for what we have queued in hwmod-cleanup). Does this series compile on it's own without the data now? This series does compile on it's own without data patches. Data patches needs to re-based against Paul's clean-up and also we need to sort out ES1/ES2 diff so they can wait till then. Probably 3.6+ This series was intentionally made in such a way that it can be merged without data patches. Just for getting boot working on OMAP5 data patches needs to be merged. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Tuesday 08 May 2012 12:46 PM, Tomi Valkeinen wrote:
On Tue, 2012-05-08 at 10:33 +0530, Archit Taneja wrote:
On Monday 07 May 2012 08:33 PM, Tomi Valkeinen wrote:
On Thu, 2012-05-03 at 12:37 +0530, Archit Taneja wrote:
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.
Create a function dss_mgr_get_timings() which returns the timings in manager's
private data. Remove the need of passing omap_dss_device structs in the
functions which check for overlay and managers.
Have some initial values for manager timings in apply_init(), these would ensure
that manager checks don't fail if an interface driver or a panel driver hasn't
set the manager timings yet.
Signed-off-by: Archit Tanejaarc...@ti.com
+struct omap_video_timings *dss_mgr_get_timings(struct omap_overlay_manager
*mgr)
+{
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ returnmp-timings;
+}
This one returns a pointer into apply.c's internal data structures. The
safest way would be to return a copy, but as it's an omapdss internal
function, I think it's enough to return a pointer to a const struct.
Okay I'll fix that, I was a bit concerned about the locking here, I use
this function in the later series to remove some dssdev references in
dispc.c. I traced the paths and saw that in all cases this function
would be protected by the data_lock spinlock, but not the apply_lock
mutex in all cases. Any thoughts on this?
Hmm, you're right, locking here gets a bit confusing. set_timings has
locks, so logically get_timings should also. But I guess all the uses of
get_timings happens via apply.c, and apply.c already holds the
data_lock, as you said?
Yes.
Making the get_timings function public (inside omapdss) is a bit nasty,
as it's quite easy to call it without having the appropriate locks. And
actually there's no way to acquire the locks outside apply.c
I'm not sure if it applies here, but as a general strategy, I suggest
doing things in apply.c that require data from apply.c's internal data.
When that's not possible, apply.c should call the functions outside
apply.c, and pass the internal data as parameters (like calls to dispc).
In your case, I for example see dss_mgr_check() calling
dss_mgr_get_timings(). It would be quite easy to pass the timings to
dss_mgr_check() from apply.c, thus removing the need to call the
function. And, as you see, dss_mgr_check() already has a bunch of
parameters, and the idea is the same with those: give the params, so
that dss_mgr_check() doesn't need to ask for them.
Right, I can do this for dss_mgr_check() and dss_ovl_check(), but if I
you see the misc cleanup patch series I posted, I use
dss_mgr_get_timings() in dispc.c functions to remove some
omap_dss_device references. These DISPC functions are called in
dispc_ovl_setup(), I could pass manager timings in dispc_ovl_setup() so
that it comes directly from apply.c. What do you say?
I guess we can get away from exposing private data in apply to DSS, but
it might get a bit harder when we try to remove other omap_dss_device
references in the future. I'm just guessing though.
Archit
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/16] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature
On 05/03/2012 11:22 PM, Venkatraman S wrote: Standard eMMC (Embedded MultiMedia Card) specification expects to execute one request at a time. If some requests are more important than others, they can't be aborted while the flash procedure is in progress. New versions of the eMMC standard (4.41 and above) specfies a feature called High Priority Interrupt (HPI). This enables an ongoing transaction to be aborted using a special command (HPI command) so that the card is ready to receive new commands immediately. Then the new request can be submitted to the card, and optionally the interrupted command can be resumed again. Some restrictions exist on when and how the command can be used. For example, only write and write-like commands (ERASE) can be preempted, and the urgent request must be a read. In order to support this in software, a) At the top level, some policy decisions have to be made on what is worth preempting for. This implementation uses the demand paging requests and swap read requests as potential reads worth preempting an ongoing long write. This is expected to provide improved responsiveness for smarphones with multitasking capabilities - example would be launch a email application while a video capture session (which causes long writes) is ongoing. Do you have a number to prove it's really big effective? What I have a concern is when we got low memory situation. Then, writing speed for page reclaim is important for response. If we allow read preempt write and write is delay, it means read path takes longer time to get a empty buffer pages in reclaim. In such case, it couldn't be good. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
On 05/07/12 17:48, Alan Stern wrote: On Mon, 7 May 2012, Igor Grinberg wrote: On 05/07/12 17:04, Alan Stern wrote: On Sun, 6 May 2012, Igor Grinberg wrote: Hi Alan, ... Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) and I'd like this to go into 3.5. Also, the dependency patch is already in Linus' tree. It has been merged with fixes (I thought it will happen only during the merge window...). Can you, please take this one? No, I can't, sorry. It has to be accepted by Greg KH. Hmm... I don't mind it be that way, but I'd like to understand: # scripts/get_maintainer.pl -f drivers/usb/host/ehci-omap.c Alan Stern st...@rowland.harvard.edu (maintainer:USB EHCI DRIVER) Felipe Balbi ba...@ti.com (maintainer:OMAP USB SUPPORT) Greg Kroah-Hartman gre...@suse.de (supporter:USB SUBSYSTEM) linux-...@vger.kernel.org (open list:USB EHCI DRIVER) linux-omap@vger.kernel.org (open list:OMAP USB SUPPORT) linux-ker...@vger.kernel.org (open list) This makes you the USB EHCI maintainer, right? Right. I just want to understand... Do you need also ack from Greg to take something to your tree for being applied in the next merge window? No. I don't takes patches at all, and in fact I don't even have a git directory or a login account at kernel.org. All my work goes through Greg; I submit or acknowledge patches and he merges them. Ah, I see. Thanks for the explanation. So currently, I need to do something like this: Greg, This patch has been acked by Alan and Felipe, can you please apply it for the merge window (which is close as I understand from Linus': We've never been closer to a 3.4 release). Thanks -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
From: Axel Haslam axelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
OK, but this also changes the behavior for OMAP3 as well, right? I
don't see in the changelog how this affects OMAP3 and whether it is
still expected to work on OMAP3. When changing common code like this,
the changelog should describe the impacts on to all affected SoCs.
Actually this doesn't change the behavior for OMAP3, as OMAP3 has
defined the ops for read_prev_logic_pwrst + read_prev_mem_pwrst. Looking
at the code more closely it might actually make more sense to implement
these for omap4 as well, instead of hacking this function. I'll check
this out and see if this can be done.
-Tero
As suggested by Vaibhav Bedia, now might be the right time to add this
function to the SoC specific function pointers (struct pwrdm_ops.)
Doing that, the existing function could be used for OMAP3 (and OMAP4 if
the changelog describes that it can/should be used for both.)
Then, when AM33xx support is added, it will be obvious where they will
need to plugin support for that SoC.
Kevin
If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.
Signed-off-by: Axel Haslam axelhas...@gmail.com
[rna...@ti.com: Updated changelog, updated patch to support mem counters]
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..068f06b 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -124,18 +124,22 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
static void _update_logic_membank_counters(struct powerdomain *pwrdm)
{
int i;
- u8 prev_logic_pwrst, prev_mem_pwrst;
+ int logic_pwrst, mem_pwrst;
+
+ logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
+ if (logic_pwrst == -EINVAL)
+ logic_pwrst = pwrdm_read_logic_retst(pwrdm);
- prev_logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
if ((pwrdm-pwrsts_logic_ret == PWRSTS_OFF_RET)
- (prev_logic_pwrst == PWRDM_POWER_OFF))
+ (logic_pwrst == PWRDM_POWER_OFF))
pwrdm-ret_logic_off_counter++;
for (i = 0; i pwrdm-banks; i++) {
- prev_mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
-
+ mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
+ if (mem_pwrst == -EINVAL)
+ mem_pwrst = pwrdm_read_mem_retst(pwrdm, i);
if ((pwrdm-pwrsts_mem_ret[i] == PWRSTS_OFF_RET)
- (prev_mem_pwrst == PWRDM_POWER_OFF))
+ (mem_pwrst == PWRDM_POWER_OFF))
pwrdm-ret_mem_off_counter[i]++;
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] ARM: OMAP2+: PM: protect the power domain state change by a mutex
Hi Paul,
Thanks for the review. Do you plan to review the full set before I
start to address the comments.
On Mon, May 7, 2012 at 8:41 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
This patch is missing a description, which would describe why this lock is
needed and what it protects against. Please add this.
Ok
---
arch/arm/mach-omap2/pm.c | 8 ++--
arch/arm/mach-omap2/powerdomain.c | 1 +
arch/arm/mach-omap2/powerdomain.h | 3 ++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index d0c1c96..6918a13 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -100,15 +100,17 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm,
u32 pwrst)
if (!pwrdm || IS_ERR(pwrdm))
return -EINVAL;
+ mutex_lock(pwrdm-lock);
+
while (!(pwrdm-pwrsts (1 pwrst))) {
if (pwrst == PWRDM_POWER_OFF)
- return ret;
+ goto out;
pwrst--;
}
next_pwrst = pwrdm_read_next_pwrst(pwrdm);
if (next_pwrst == pwrst)
- return ret;
+ goto out;
curr_pwrst = pwrdm_read_pwrst(pwrdm);
if (curr_pwrst PWRDM_POWER_ON) {
@@ -141,6 +143,8 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
pwrst)
break;
}
+out:
+ mutex_unlock(pwrdm-lock);
return ret;
}
So this mutex would protect against simultaneous calls to
omap_set_pwrdm_state(), but shouldn't this protection be extended to
anything that would change the powerdomain's state? For example, couldn't
other calls to pwrdm_set_next_pwrst() race against this function?
The intention behind this patch set is to change the API to only use
omap_set_pwrdm_state to change the power domains states. Probably I
should emphasize more on that in the cover letter and commits
description.
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..319b277 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -102,6 +102,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
INIT_LIST_HEAD(pwrdm-voltdm_node);
voltdm_add_pwrdm(voltdm, pwrdm);
+ mutex_init(pwrdm-lock);
list_add(pwrdm-node, pwrdm_list);
/* Initialize the powerdomain's state counter */
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..6c6567d 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -19,7 +19,7 @@
#include linux/types.h
#include linux/list.h
-
+#include linux/mutex.h
#include linux/atomic.h
#include plat/cpu.h
@@ -116,6 +116,7 @@ struct powerdomain {
struct clockdomain *pwrdm_clkdms[PWRDM_MAX_CLKDMS];
struct list_head node;
struct list_head voltdm_node;
+ struct mutex lock;
int state;
unsigned state_counter[PWRDM_MAX_PWRSTS];
unsigned ret_logic_off_counter;
Please add a kerneldoc entry in the struct powerdomain documentation for
this field.
Ok
- Paul
Thanks,
Jean
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP3: cm-t35: add support for power off
ping x2
On 04/19/12 13:40, Igor Grinberg wrote:
ping!
Tony, can this please, go into 3.5?
On 03/28/12 11:51, Igor Grinberg wrote:
Enable the power off feature of the TPS65930 on-board PMIC.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t35.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 8770be1..46275c6 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -499,6 +499,10 @@ static struct twl4030_gpio_platform_data
cm_t35_gpio_data = {
.setup = cm_t35_twl_gpio_setup,
};
+static struct twl4030_power_data cm_t35_power_data = {
+.use_poweroff = true,
+};
+
static struct twl4030_platform_data cm_t35_twldata = {
/* platform_data for children goes here */
.keypad = cm_t35_kp_data,
@@ -506,6 +510,7 @@ static struct twl4030_platform_data cm_t35_twldata = {
.vmmc1 = cm_t35_vmmc1,
.vsim = cm_t35_vsim,
.vio= cm_t35_vio,
+.power = cm_t35_power_data,
};
static void __init cm_t35_init_i2c(void)
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
From: Axel Haslam axelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
OK, but this also changes the behavior for OMAP3 as well, right? I
don't see in the changelog how this affects OMAP3 and whether it is
still expected to work on OMAP3. When changing common code like this,
the changelog should describe the impacts on to all affected SoCs.
As suggested by Vaibhav Bedia, now might be the right time to add this
function to the SoC specific function pointers (struct pwrdm_ops.)
Doing that, the existing function could be used for OMAP3 (and OMAP4 if
the changelog describes that it can/should be used for both.)
Then, when AM33xx support is added, it will be obvious where they will
need to plugin support for that SoC.
How about the following patch? It will add a couple of redundant
read_prev_pwrst calls, but works in the same way as the original patch,
without touching the generic code. Also, as there have been talks about
adding caching for some of the pwrdm registers (especially the
prev_pwrst), this might not be that big of an issue.
If this looks good to you, I'll re-post the set with this patch.
-Tero
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 9bfb8a0..3d5e8d4 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
powerdomain *pwrdm)
return v;
}
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_logic_retst(pwrdm);
+}
+
static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
bank)
{
u32 m, v;
@@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
powerdomain *pwrdm, u8 bank)
return v;
}
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
u8 bank)
+{
+ if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
{
u32 c = 0;
@@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap4_pwrdm_read_prev_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
.pwrdm_read_mem_pwrst = omap4_pwrdm_read_mem_pwrst,
.pwrdm_read_mem_retst = omap4_pwrdm_read_mem_retst,
+ .pwrdm_read_prev_mem_pwrst = omap4_pwrdm_read_prev_mem_pwrst,
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] ARM: OMAP2+: PM: introduce power domains functional states
Paul,
On Mon, May 7, 2012 at 11:28 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
On Wed, 18 Apr 2012, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
Introduce functional (or logical) states for power domains and the
API functions to read the power domains settings and to convert
between the functional (i.e. logical) and the internal (or registers)
values.
OMAP2, OMAP3 and OMAP4 platforms are defining a conversion routine.
In the new API the function omap_set_pwrdm_state takes the functional
states as parameter; while at it the function is moved to the power
domains code.
The memory and logic states are not using the functional states, this
comes as a subsequent patch.
Signed-off-by: Jean Pihet j-pi...@ti.com
This patch results in several checkpatch warnings; please resolve them.
Oops. Will check and update.
---
arch/arm/mach-omap2/pm.c | 66 ---
arch/arm/mach-omap2/powerdomain-common.c | 61 ++
arch/arm/mach-omap2/powerdomain.c | 175
arch/arm/mach-omap2/powerdomain.h | 21
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 5 +
arch/arm/mach-omap2/powerdomain44xx.c | 2 +
6 files changed, 264 insertions(+), 66 deletions(-)
...
+/*
+ * Functional (i.e. logical) to internal (i.e. registers)
+ * values for the power domains states
+ */
Please use kerneldoc-style function comments.
Ok
+int omap2_pwrdm_func_to_pwrst(struct powerdomain *pwrdm, u8 func_pwrst)
+{
+ int ret;
+
+ switch (func_pwrst) {
+ case PWRDM_FUNC_PWRST_ON:
+ ret = PWRDM_POWER_ON;
+ break;
+ case PWRDM_FUNC_PWRST_INACTIVE:
+ ret = PWRDM_POWER_INACTIVE;
+ break;
+ case PWRDM_FUNC_PWRST_CSWR:
+ case PWRDM_FUNC_PWRST_OSWR:
+ ret = PWRDM_POWER_RET;
+ break;
+ case PWRDM_FUNC_PWRST_OFF:
+ ret = PWRDM_POWER_OFF;
+ break;
+ default:
+ ret = -1;
+ }
+
+ return ret;
+}
At a quick glance, I don't think that this function is appropriate for all
OMAP2+ chips. For example, off-mode is not supported in our OMAP2xxx
kernels. And OMAP2xxx/3xxx do not support the INACTIVE powerstate. So
probably this function should differ by chip, and be located in the
powerdomain[2-4]*xx*.c files.
I hope to make this function as generic as possible, hence the
location (powerdomain-common.c). Some states are not programmed by the
pwrdm_* functions since there forbidden by the contents of the
pwrdm-pwrst field.
Now if the need arises some platform specific function can be defined
for conversion functions since the pwrdm-ops function pointers are
used. I do not think it is needed now but it can easily be changed.
Also, what about the logic and memory bank power states? Shouldn't this
function pass those back as well?
Cf. in the description The memory and logic states are not using the
functional states, this comes as a subsequent patch.
+
+/*
+ * Internal (i.e. registers) to functional (i.e. logical) values
+ * for the power domains states
+ */
Please use kerneldoc-style function documentation.
Ok
+int omap2_pwrdm_pwrst_to_func(struct powerdomain *pwrdm, u8 pwrst)
Probably best to use func_pwrst or fpwrst rather than simply func
here.
Ok. I am for 'omap2_pwrdm_pwrst_to_fpwrst(...)'.
+{
+ int ret;
+
+ switch (pwrst) {
+ case PWRDM_POWER_ON:
+ ret = PWRDM_FUNC_PWRST_ON;
+ break;
+ case PWRDM_POWER_INACTIVE:
+ ret = PWRDM_FUNC_PWRST_INACTIVE;
+ break;
+ case PWRDM_POWER_RET:
+ /*
+ * XXX warning: return OSWR in case of pd in RET and
+ * logic in OFF
+ */
+ ret = PWRDM_FUNC_PWRST_CSWR;
+ break;
+ case PWRDM_POWER_OFF:
+ ret = PWRDM_FUNC_PWRST_OFF;
+ break;
+ default:
+ ret = -1;
+ }
+
+ return ret;
+}
This function also needs to check the bank power states and logic power
states to determine what the actual functional powerstate is.
Same remark as above + there is a comment about it in the code (XXX warning).
+
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 319b277..718fa43 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -466,6 +466,136 @@ int pwrdm_get_mem_bank_count(struct powerdomain *pwrdm)
}
/**
+ * pwrdm_func_to_pwrst - get the internal (i.e. registers) value mapped
+ * to the functional state
Probably best to use func_pwrst or fpwrst rather than simply func
here.
Ok
+ * @pwrdm: struct powerdomain * to query
+ * @func_pwrst: functional power state
+ *
+ * Convert the functional power state to the platform specific power
+ * domain state value.
+ * Returns the internal power domain state
Re: [PATCH] [OMAP] Cleanup Beagleboard DVI reset gpio
Hi Russ,
On 05/07/12 23:00, Russ Dill wrote:
This removes several boot warnings from board-omap3beagle.c:
- gpio_request: gpio--22 (DVI reset) status -22
- Unable to get DVI reset GPIO
There is a combination of leftover code and revision confusion.
Additionally, xM support is currently a hack.
For original Beagleboard this removes the double initialization of GPIO
170, properly configures it as an output, and wraps the initialization
in an if block so that xM does not attempt to request it.
For Beagleboard xM it removes reference to GPIO 129 which was part
of rev A1 and A2 designs, but never functioned. It then properly assigns
beagle_dvi_device.reset_gpio in beagle_twl_gpio_setup and removes the
hack of initializing it high.
Unfortunately, there is no way to tell the difference between xM A2 and
A3. However, GPIO 129 does not function on rev A1 and A2, and the TWL
GPIO used on A3 and beyond is not used on rev A1 and A2, there are no
problems created by this fix.
Tested on Beagleboard-xM Rev C1 and Beagleboard Rev B4.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 35
+--
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 3b9647a..fcb7b56 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -86,7 +86,7 @@ static struct {
} beagle_config = {
.mmc1_gpio_wp = -EINVAL,
.usb_pwr_level = GPIOF_OUT_INIT_LOW,
- .reset_gpio = 129,
+ .reset_gpio = -EINVAL,
While, you are at this one, can you please add a comment
on what device does this gpio reset?
.usr_button_gpio = 4,
};
@@ -238,12 +238,17 @@ static struct omap_dss_board_info beagle_dss_data = {
static void __init beagle_display_init(void)
{
- int r;
-
- r = gpio_request_one(beagle_dvi_device.reset_gpio, GPIOF_OUT_INIT_LOW,
- DVI reset);
- if (r 0)
- printk(KERN_ERR Unable to get DVI reset GPIO\n);
+ if (beagle_config.reset_gpio != -EINVAL) {
Should this be:
if (gpio_is_valid(beagle_config.reset_gpio)) {
?
+ int r;
+
+ omap_mux_init_gpio(beagle_config.reset_gpio, OMAP_PIN_OUTPUT);
+ r = gpio_request_one(beagle_config.reset_gpio,
+ GPIOF_OUT_INIT_LOW, DVI reset);
+ if (r 0)
+ printk(KERN_ERR Unable to get DVI reset GPIO\n);
+ else
+ beagle_dvi_device.reset_gpio = beagle_config.reset_gpio;
+ }
}
#include sdram-micron-mt46h32m32lf-6.h
@@ -296,11 +301,14 @@ static int beagle_twl_gpio_setup(struct device *dev,
if (r)
pr_err(%s: unable to configure nDVI_PWR_EN\n,
__func__);
- r = gpio_request_one(gpio + 2, GPIOF_OUT_INIT_HIGH,
- DVI_LDO_EN);
+
+ r = gpio_request_one(gpio + 2, GPIOF_OUT_INIT_LOW,
+ DVI_PU);
if (r)
- pr_err(%s: unable to configure DVI_LDO_EN\n,
- __func__);
+ pr_err(%s: unable to get DVI_PU GPIO\n, __func__);
+ else
+ beagle_dvi_device.reset_gpio = gpio + 2;
+
} else {
/*
* REVISIT: need ehci-omap hooks for external VBUS
@@ -309,7 +317,6 @@ static int beagle_twl_gpio_setup(struct device *dev,
if (gpio_request_one(gpio + 1, GPIOF_IN, EHCI_nOC))
pr_err(%s: unable to configure EHCI_nOC\n, __func__);
}
- beagle_dvi_device.reset_gpio = beagle_config.reset_gpio;
gpio_request_one(gpio + TWL4030_GPIO_MAX, beagle_config.usb_pwr_level,
nEN_USB_PWR);
@@ -540,10 +547,6 @@ static void __init omap3_beagle_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
- omap_mux_init_gpio(170, OMAP_PIN_INPUT);
- /* REVISIT leave DVI powered down until it's needed ... */
- gpio_request_one(170, GPIOF_OUT_INIT_HIGH, DVI_nPD);
-
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
omap_nand_flash_init(NAND_BUSWIDTH_16, omap3beagle_nand_partitions,
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
On Mon, 2012-05-07 at 10:46 -0700, Tony Lindgren wrote: Hi, * Tomi Valkeinen tomi.valkei...@ti.com [120503 07:01]: Hi, I started cleaning up and restructuring omapdss for device tree, and here's the first set of patches from that ordeal. There's nothing DT specific in these patches, but they are mostly generic cleanups that make sense even without DT. This is the second version of these patches, the previous version can be found from: http://www.spinics.net/lists/linux-fbdev/msg05667.html The first 21 patches, which were in the previous version, have only gotten minor cleanups (and, of course, more testing). The last 4 patches are new. The most important of those patches is the DSI pin config patch, which makes it possible for the panel driver to configure the DSI pins it needs. This series can also be found from: git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base Nice clean up. Can you please put the first 12 arch/arm/*omap*/* touching patches (and the drivers/video dependencies needed) into a separate branch and send me a pull request. That is assuming those patches are now immutable. Then I can pull it into cleanup-dss branch that we both can merge as needed. Ok, I'll see how it goes. Do I have your ack for the board file changes? Do you want to have patches that touch only arch/arm/mach-omap2/display.c, but not the board files? That's a dss specific file, and I don't expect anyone else to make changes to it, so chances for conflicts should be quite minimal. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Tue, 2012-05-08 at 13:08 +0530, Archit Taneja wrote: On Tuesday 08 May 2012 12:46 PM, Tomi Valkeinen wrote: I'm not sure if it applies here, but as a general strategy, I suggest doing things in apply.c that require data from apply.c's internal data. When that's not possible, apply.c should call the functions outside apply.c, and pass the internal data as parameters (like calls to dispc). In your case, I for example see dss_mgr_check() calling dss_mgr_get_timings(). It would be quite easy to pass the timings to dss_mgr_check() from apply.c, thus removing the need to call the function. And, as you see, dss_mgr_check() already has a bunch of parameters, and the idea is the same with those: give the params, so that dss_mgr_check() doesn't need to ask for them. Right, I can do this for dss_mgr_check() and dss_ovl_check(), but if I you see the misc cleanup patch series I posted, I use dss_mgr_get_timings() in dispc.c functions to remove some omap_dss_device references. These DISPC functions are called in dispc_ovl_setup(), I could pass manager timings in dispc_ovl_setup() so that it comes directly from apply.c. What do you say? Yes, I guess dispc_ovl_setup should get the timings pointer also. It's getting a bit complex, but I don't see any simpler way. Especially dispc functions should be quite self contained, dispc.c should not call elsewhere, but it should get all the needed data as parameters. I guess we can get away from exposing private data in apply to DSS, but it might get a bit harder when we try to remove other omap_dss_device references in the future. I'm just guessing though. We have two cases here: 1) using timings when doing apply.c things, as your patches do. In these cases the timings can be passed from apply.c as parameters. 2) using timings outside apply.c. I guess we currently don't have these, but for those we could have a get_timings() function that does take the locks. And similarly for other configs. Of course, that's still not perfect. Even if get_timings() is protected properly, there's no guarantee that the timings won't change right after get_timings has returned. But hopefully all writes and reads to timings would go via the same place, for example dpi.c. And dpi.c's own lock will protect the change of timings while another thread is using them. Btw, there's a typo in OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()'s description, dss_mgr_get_device() should be get_timings in one place. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristot-kri...@ti.com writes:
From: Axel Haslamaxelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
OK, but this also changes the behavior for OMAP3 as well, right? I
don't see in the changelog how this affects OMAP3 and whether it is
still expected to work on OMAP3. When changing common code like this,
the changelog should describe the impacts on to all affected SoCs.
As suggested by Vaibhav Bedia, now might be the right time to add this
function to the SoC specific function pointers (struct pwrdm_ops.)
Doing that, the existing function could be used for OMAP3 (and OMAP4 if
the changelog describes that it can/should be used for both.)
Then, when AM33xx support is added, it will be obvious where they will
need to plugin support for that SoC.
How about the following patch? It will add a couple of redundant
read_prev_pwrst calls, but works in the same way as the original patch,
without touching the generic code. Also, as there have been talks about
adding caching for some of the pwrdm registers (especially the
prev_pwrst), this might not be that big of an issue.
If this looks good to you, I'll re-post the set with this patch.
-Tero
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 9bfb8a0..3d5e8d4 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
powerdomain *pwrdm)
return v;
}
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_logic_retst(pwrdm);
Looks good to me. Do these ever get called with target state programmed
to OFF?
regards,
Rajendra
+}
+
static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
bank)
{
u32 m, v;
@@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
powerdomain *pwrdm, u8 bank)
return v;
}
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
u8 bank)
+{
+ if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
{
u32 c = 0;
@@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap4_pwrdm_read_prev_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
.pwrdm_read_mem_pwrst = omap4_pwrdm_read_mem_pwrst,
.pwrdm_read_mem_retst = omap4_pwrdm_read_mem_retst,
+ .pwrdm_read_prev_mem_pwrst = omap4_pwrdm_read_prev_mem_pwrst,
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/2] ARM: omap_hwmod: add api to enable/disable module level wakeup
From: Govindraj.R govindraj.r...@ti.com On omap2/3 module level wakeup is handled using PM_WKEN registers. Expand the hwmod framework to handle the module level wakeup enable registers. Patch series based on: git://git.pwsan.com/linux-2.6 hwmod_soc_conditional_cleanup_3.5 Tested on Beagle-xm by enabling and disabling uart wakeups from sysfs Series depends on following patches for testing. http://marc.info/?l=linux-omapm=133527588923598w=2 http://marc.info/?l=linux-omapm=133518614022144w=2 Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tero Kristo t-kri...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Rajendra Nayak rna...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Changes from v3: --- Using hwmod soc init support to populate soc specific funcs. http://www.spinics.net/lists/linux-omap/msg69676.html Govindraj.R (2): ARM: OMAP2/3: omap_hwmod: Add api to enable/disable module level wakeup events ARM: omap3: pm: Remove uart module level wakeup configurations arch/arm/mach-omap2/omap_hwmod.c | 29 + arch/arm/mach-omap2/pm34xx.c | 14 +- arch/arm/mach-omap2/prm2xxx_3xxx.c | 16 arch/arm/mach-omap2/prm2xxx_3xxx.h |9 + 4 files changed, 59 insertions(+), 9 deletions(-) -- 1.7.9 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] ARM: OMAP2/3: omap_hwmod: Add api to enable/disable module level wakeup events
From: Govindraj.R govindraj.r...@ti.com
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs.
Add soc specific api to control the module level wakeup mechanism in hwmod
layer. omap_hwmod_enable/disable_wakeup is used from serial.c which should
configure PM_WKEN register to enable or disable the module level wakeup.
Cc: Tero Kristo t-kri...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 29 +
arch/arm/mach-omap2/prm2xxx_3xxx.c | 16
arch/arm/mach-omap2/prm2xxx_3xxx.h |9 +
3 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index acc616c..e82bf80 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -186,6 +186,7 @@ struct omap_hwmod_soc_ops {
int (*is_hardreset_asserted)(struct omap_hwmod *oh,
struct omap_hwmod_rst_info *ohri);
int (*init_clkdm)(struct omap_hwmod *oh);
+ void (*module_wakeup)(struct omap_hwmod *oh, bool set_wake);
};
/* soc_ops: adapts the omap_hwmod code to the currently-booted SoC */
@@ -453,6 +454,27 @@ static int _set_module_autoidle(struct omap_hwmod *oh, u8
autoidle,
}
/**
+ * _enable_module_level_wakeup - enable/disable module level wakeup on hwmod.
+ * @oh: struct omap_hwmod *
+ * @set_wake: bool value indicating to set (true) or clear (false) module level
+ * wakeup enable
+ *
+ * Set or clear the module level wakeup capability the
+ * hwmod @oh. This function configures th PM_WKEN reg bits if they
+ * are available from hwmod. No return value
+ */
+static void _enable_module_level_wakeup(struct omap_hwmod *oh, bool set_wake)
+{
+ if (oh-prcm.omap2.module_offs oh-prcm.omap2.prcm_reg_id
+ oh-prcm.omap2.idlest_idle_bit)
+ omap2_prm_enable_prcm_module_wakeup(
+ oh-prcm.omap2.module_offs,
+ oh-prcm.omap2.prcm_reg_id,
+ oh-prcm.omap2.idlest_idle_bit,
+ set_wake);
+}
+
+/**
* _set_idle_ioring_wakeup - enable/disable IO pad wakeup on hwmod idle for mux
* @oh: struct omap_hwmod *
* @set_wake: bool value indicating to set (true) or clear (false) wakeup
enable
@@ -3242,6 +3264,9 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
_write_sysconfig(v, oh);
}
+ if (soc_ops.module_wakeup)
+ soc_ops.module_wakeup(oh, true);
+
_set_idle_ioring_wakeup(oh, true);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -3275,6 +3300,9 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
_write_sysconfig(v, oh);
}
+ if (soc_ops.module_wakeup)
+ soc_ops.module_wakeup(oh, false);
+
_set_idle_ioring_wakeup(oh, false);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -3561,6 +3589,7 @@ void __init omap_hwmod_init(void)
soc_ops.assert_hardreset = _omap2_assert_hardreset;
soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
+ soc_ops.module_wakeup = _enable_module_level_wakeup;
} else if (cpu_is_omap44xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 9ce7654..85a753e 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -28,6 +28,10 @@
#include prm-regbits-24xx.h
#include prm-regbits-34xx.h
+static const u8 pm_wken_offs[] = {
+ PM_WKEN1, OMAP24XX_PM_WKEN2
+};
+
static const struct omap_prcm_irq omap3_prcm_irqs[] = {
OMAP_PRCM_IRQ(wkup, 0, 0),
OMAP_PRCM_IRQ(io, 9, 1),
@@ -91,6 +95,18 @@ u32 omap2_prm_clear_mod_reg_bits(u32 bits, s16 module, s16
idx)
return omap2_prm_rmw_mod_reg_bits(bits, 0x0, module, idx);
}
+void omap2_prm_enable_prcm_module_wakeup(s16 prcm_mod, u8 prm_reg_id,
+ u8 prm_reg_shift, bool set_wake)
+{
+ if (prm_reg_id (prm_reg_id = ARRAY_SIZE(pm_wken_offs))) {
+ if (set_wake)
+ omap2_prm_set_mod_reg_bits(1 prm_reg_shift,
+ prcm_mod, pm_wken_offs[prm_reg_id - 1]);
+ else
+ omap2_prm_clear_mod_reg_bits(1 prm_reg_shift,
+ prcm_mod, pm_wken_offs[prm_reg_id - 1]);
+ }
+}
/**
*
[PATCH v4 2/2] ARM: omap3: pm: Remove uart module level wakeup configurations
From: Govindraj.R govindraj.r...@ti.com
The uart module level wakeups enabling and disabling
are now handled from uart driver itself remove the uart module
level configurations from pm code.
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 703bd10..7a19498 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -529,8 +529,6 @@ static void __init omap3_d2d_idle(void)
static void __init prcm_setup_regs(void)
{
- u32 omap3630_en_uart4_mask = cpu_is_omap3630() ?
- OMAP3630_EN_UART4_MASK : 0;
u32 omap3630_grpsel_uart4_mask = cpu_is_omap3630() ?
OMAP3630_GRPSEL_UART4_MASK : 0;
@@ -562,13 +560,11 @@ static void __init prcm_setup_regs(void)
OMAP3430_DSS_MOD, PM_WKEN);
/* Enable wakeups in PER */
- omap2_prm_write_mod_reg(omap3630_en_uart4_mask |
- OMAP3430_EN_GPIO2_MASK | OMAP3430_EN_GPIO3_MASK |
- OMAP3430_EN_GPIO4_MASK | OMAP3430_EN_GPIO5_MASK |
- OMAP3430_EN_GPIO6_MASK | OMAP3430_EN_UART3_MASK |
- OMAP3430_EN_MCBSP2_MASK | OMAP3430_EN_MCBSP3_MASK |
- OMAP3430_EN_MCBSP4_MASK,
- OMAP3430_PER_MOD, PM_WKEN);
+ omap2_prm_write_mod_reg(OMAP3430_EN_GPIO2_MASK |
+ OMAP3430_EN_GPIO3_MASK | OMAP3430_EN_GPIO4_MASK |
+ OMAP3430_EN_GPIO5_MASK | OMAP3430_EN_GPIO6_MASK |
+ OMAP3430_EN_MCBSP2_MASK | OMAP3430_EN_MCBSP3_MASK |
+ OMAP3430_EN_MCBSP4_MASK, OMAP3430_PER_MOD, PM_WKEN);
/* and allow them to wake up MPU */
omap2_prm_write_mod_reg(omap3630_grpsel_uart4_mask |
OMAP3430_GRPSEL_GPIO2_MASK |
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Tuesday 08 May 2012 02:22 PM, Tomi Valkeinen wrote: On Tue, 2012-05-08 at 13:08 +0530, Archit Taneja wrote: On Tuesday 08 May 2012 12:46 PM, Tomi Valkeinen wrote: I'm not sure if it applies here, but as a general strategy, I suggest doing things in apply.c that require data from apply.c's internal data. When that's not possible, apply.c should call the functions outside apply.c, and pass the internal data as parameters (like calls to dispc). In your case, I for example see dss_mgr_check() calling dss_mgr_get_timings(). It would be quite easy to pass the timings to dss_mgr_check() from apply.c, thus removing the need to call the function. And, as you see, dss_mgr_check() already has a bunch of parameters, and the idea is the same with those: give the params, so that dss_mgr_check() doesn't need to ask for them. Right, I can do this for dss_mgr_check() and dss_ovl_check(), but if I you see the misc cleanup patch series I posted, I use dss_mgr_get_timings() in dispc.c functions to remove some omap_dss_device references. These DISPC functions are called in dispc_ovl_setup(), I could pass manager timings in dispc_ovl_setup() so that it comes directly from apply.c. What do you say? Yes, I guess dispc_ovl_setup should get the timings pointer also. It's getting a bit complex, but I don't see any simpler way. Especially dispc functions should be quite self contained, dispc.c should not call elsewhere, but it should get all the needed data as parameters. Ok, you are right about dispc.c querying stuff from apply, it should all be one way from apply/interface drivers to the dispc, and if that's the case, then it has to get more complex. We could just pass the data in a nicer way to make the number of arguments passed to dispc functions seem small. I guess we can get away from exposing private data in apply to DSS, but it might get a bit harder when we try to remove other omap_dss_device references in the future. I'm just guessing though. We have two cases here: 1) using timings when doing apply.c things, as your patches do. In these cases the timings can be passed from apply.c as parameters. 2) using timings outside apply.c. I guess we currently don't have these, but for those we could have a get_timings() function that does take the locks. And similarly for other configs. Of course, that's still not perfect. Even if get_timings() is protected properly, there's no guarantee that the timings won't change right after get_timings has returned. But hopefully all writes and reads to timings would go via the same place, for example dpi.c. And dpi.c's own lock will protect the change of timings while another thread is using them. Btw, there's a typo in OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()'s description, dss_mgr_get_device() should be get_timings in one place. Ah ok, I am removing the dss_mgr_get_timings() usage anyway, I'll pass timings through dispc_ovl_setup(). I am also going to make the first patch of the newer set 'OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled' a part of this series since it's more related to applying timings. I posted it in the next series since I had already posted out this series. Archit Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
On Tue, 2012-05-08 at 14:27 +0530, Rajendra Nayak wrote:
On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristot-kri...@ti.com writes:
From: Axel Haslamaxelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
OK, but this also changes the behavior for OMAP3 as well, right? I
don't see in the changelog how this affects OMAP3 and whether it is
still expected to work on OMAP3. When changing common code like this,
the changelog should describe the impacts on to all affected SoCs.
As suggested by Vaibhav Bedia, now might be the right time to add this
function to the SoC specific function pointers (struct pwrdm_ops.)
Doing that, the existing function could be used for OMAP3 (and OMAP4 if
the changelog describes that it can/should be used for both.)
Then, when AM33xx support is added, it will be obvious where they will
need to plugin support for that SoC.
How about the following patch? It will add a couple of redundant
read_prev_pwrst calls, but works in the same way as the original patch,
without touching the generic code. Also, as there have been talks about
adding caching for some of the pwrdm registers (especially the
prev_pwrst), this might not be that big of an issue.
If this looks good to you, I'll re-post the set with this patch.
-Tero
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 9bfb8a0..3d5e8d4 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
powerdomain *pwrdm)
return v;
}
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_logic_retst(pwrdm);
Looks good to me. Do these ever get called with target state programmed
to OFF?
At least with current kernel code, no. But you are right, it might be
better to change these to check against PWRDM_POWER_RET.
-Tero
regards,
Rajendra
+}
+
static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
bank)
{
u32 m, v;
@@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
powerdomain *pwrdm, u8 bank)
return v;
}
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
u8 bank)
+{
+ if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
{
u32 c = 0;
@@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap4_pwrdm_read_prev_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
.pwrdm_read_mem_pwrst = omap4_pwrdm_read_mem_pwrst,
.pwrdm_read_mem_retst = omap4_pwrdm_read_mem_retst,
+ .pwrdm_read_prev_mem_pwrst = omap4_pwrdm_read_prev_mem_pwrst,
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Broken UART I/O wakeups on v3.4-rc4+
On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley p...@pwsan.com wrote: Govindraj, After your commit bce492c04ba8fc66a4ea0a52b181ba255daaaf54 (ARM: OMAP2+: UART: Fix incorrect population of default uart pads), the kernel does not return from static suspend when off-mode is enabled upon an incoming serial character. The following steps reproduce the problem: echo 1 /debug/pm_debug/enable_off_mode echo mem /sys/power/state (send a serial character after suspend is entered) (N.B., on the BeagleBoard, the GPIO-connected USER button can be used to wake the system at this point.) The same is discussed in this thread as in here: http://www.spinics.net/lists/linux-omap/msg68659.html Could you please fix this? We probably aren't too far from the v3.5 merge window opening, so there isn't much time to fix it. okay, one possible solution is to probe pins dynamically and make rx wakeup capable which myself and Tony discussed and came up with this patch [1] or to add rx wakeup pad support for each board, based on uart used as console. -- Thanks, Govindraj.R [1]: http://www.spinics.net/lists/linux-omap/msg67822.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
On Tuesday 08 May 2012 02:39 PM, Tero Kristo wrote:
On Tue, 2012-05-08 at 14:27 +0530, Rajendra Nayak wrote:
On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristot-kri...@ti.com writes:
From: Axel Haslamaxelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
OK, but this also changes the behavior for OMAP3 as well, right? I
don't see in the changelog how this affects OMAP3 and whether it is
still expected to work on OMAP3. When changing common code like this,
the changelog should describe the impacts on to all affected SoCs.
As suggested by Vaibhav Bedia, now might be the right time to add this
function to the SoC specific function pointers (struct pwrdm_ops.)
Doing that, the existing function could be used for OMAP3 (and OMAP4 if
the changelog describes that it can/should be used for both.)
Then, when AM33xx support is added, it will be obvious where they will
need to plugin support for that SoC.
How about the following patch? It will add a couple of redundant
read_prev_pwrst calls, but works in the same way as the original patch,
without touching the generic code. Also, as there have been talks about
adding caching for some of the pwrdm registers (especially the
prev_pwrst), this might not be that big of an issue.
If this looks good to you, I'll re-post the set with this patch.
-Tero
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 9bfb8a0..3d5e8d4 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
powerdomain *pwrdm)
return v;
}
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_logic_retst(pwrdm);
Looks good to me. Do these ever get called with target state programmed
to OFF?
At least with current kernel code, no. But you are right, it might be
better to change these to check against PWRDM_POWER_RET.
But in case of target power state being programmed to OFF, the logic
retst might not be programmed at all, so in case of target state being
OFF, returning the logic retst programmed might as well return
PWRDM_POWER_ON itself, right?
-Tero
regards,
Rajendra
+}
+
static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
bank)
{
u32 m, v;
@@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
powerdomain *pwrdm, u8 bank)
return v;
}
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
u8 bank)
+{
+ if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
{
u32 c = 0;
@@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_clear_all_prev_pwrst = omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap4_pwrdm_read_prev_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
.pwrdm_read_mem_pwrst = omap4_pwrdm_read_mem_pwrst,
.pwrdm_read_mem_retst = omap4_pwrdm_read_mem_retst,
+ .pwrdm_read_prev_mem_pwrst = omap4_pwrdm_read_prev_mem_pwrst,
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/13] ARM: OMAP5: Add the build support
Hi Tony, On 5/7/2012 7:37 PM, Tony Lindgren wrote: * R, Sricharanr.sricha...@ti.com [120506 20:39]: +config MACH_OMAP5_SEVM + bool OMAP5 sevm Board + depends on ARCH_OMAP5 + config OMAP3_EMU bool OMAP3 debugging peripherals depends on ARCH_OMAP3 No need for it here either. Actually, I think this whole chunk can be now left out since it's DT based? he ok, but the concern here was that without this macro the print from compress and subsequently early prints appear broken. machine_is_omap5_sevm becomes zero without this config and machine_is_ is used by the macro _DEBUG_LL_ENTRY uncompress.h. Ah I see. Mmm, still, I guess this mechanism should be deprecated with DT? We cannot keep creating fake board entry since we are not supposed to have MACHINE_ID anymore. That will break DEBUG_LL for sure, but we knew about that current limitation with DT. The point is that we should fix the code to stop relying on a machine id going forward. And maybe we can parse the FDT at that time? Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] omap: mailbox: enable mailbox irq per instance
Hi Juan, On Tue, May 8, 2012 at 1:09 AM, Gutierrez, Juan jgutier...@ti.com wrote: Startup it is now only used to enable pm runtime of the whole mbox module. Btw I really doubt we need to do that in a machine-specific handler, or whether we really need this startup/shutdown abstraction at all. But that's not related to your patch of course... I think, if request_irq is called from the generic layer, it is kind of logical to enable_irq next to it. I somewhat agree, though I was wondering about the implications for OMAP1, which didn't seem to enable_irq at startup at all. Not sure there's much to do here (unless you have some OMAP1 hardware ? :). Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters
On Tue, 2012-05-08 at 14:45 +0530, Rajendra Nayak wrote:
On Tuesday 08 May 2012 02:39 PM, Tero Kristo wrote:
On Tue, 2012-05-08 at 14:27 +0530, Rajendra Nayak wrote:
On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
Tero Kristot-kri...@ti.com writes:
From: Axel Haslamaxelhas...@gmail.com
On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.
In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.
OK, but this also changes the behavior for OMAP3 as well, right? I
don't see in the changelog how this affects OMAP3 and whether it is
still expected to work on OMAP3. When changing common code like this,
the changelog should describe the impacts on to all affected SoCs.
As suggested by Vaibhav Bedia, now might be the right time to add this
function to the SoC specific function pointers (struct pwrdm_ops.)
Doing that, the existing function could be used for OMAP3 (and OMAP4 if
the changelog describes that it can/should be used for both.)
Then, when AM33xx support is added, it will be obvious where they will
need to plugin support for that SoC.
How about the following patch? It will add a couple of redundant
read_prev_pwrst calls, but works in the same way as the original patch,
without touching the generic code. Also, as there have been talks about
adding caching for some of the pwrdm registers (especially the
prev_pwrst), this might not be that big of an issue.
If this looks good to you, I'll re-post the set with this patch.
-Tero
diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 9bfb8a0..3d5e8d4 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
powerdomain *pwrdm)
return v;
}
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+ if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_logic_retst(pwrdm);
Looks good to me. Do these ever get called with target state programmed
to OFF?
At least with current kernel code, no. But you are right, it might be
better to change these to check against PWRDM_POWER_RET.
But in case of target power state being programmed to OFF, the logic
retst might not be programmed at all, so in case of target state being
OFF, returning the logic retst programmed might as well return
PWRDM_POWER_ON itself, right?
You are right, so better to check against OFF and return prev logic +
membank states as OFF also if that is the case, and with RET, return the
programmed state.
-Tero
-Tero
regards,
Rajendra
+}
+
static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
bank)
{
u32 m, v;
@@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
powerdomain *pwrdm, u8 bank)
return v;
}
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
u8 bank)
+{
+ if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+ return PWRDM_POWER_ON;
+
+ return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
{
u32 c = 0;
@@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
.pwrdm_clear_all_prev_pwrst =
omap4_pwrdm_clear_all_prev_pwrst,
.pwrdm_set_logic_retst = omap4_pwrdm_set_logic_retst,
.pwrdm_read_logic_pwrst = omap4_pwrdm_read_logic_pwrst,
+ .pwrdm_read_prev_logic_pwrst= omap4_pwrdm_read_prev_logic_pwrst,
.pwrdm_read_logic_retst = omap4_pwrdm_read_logic_retst,
.pwrdm_read_mem_pwrst = omap4_pwrdm_read_mem_pwrst,
.pwrdm_read_mem_retst = omap4_pwrdm_read_mem_retst,
+ .pwrdm_read_prev_mem_pwrst = omap4_pwrdm_read_prev_mem_pwrst,
.pwrdm_set_mem_onst = omap4_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= omap4_pwrdm_set_mem_retst,
.pwrdm_wait_transition = omap4_pwrdm_wait_transition,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] OMAPDSS: APPLY: Treat overlay manager timings as shadow registers
An overlay manager's timings (the manager size, and blanking parameters if an LCD manager) are DISPC shadow registers, and they should hence follow the correct programming model. This set makes the timings an extra_info parameter in manager's private data . The interface drivers now apply the timings in instead of directly writing to registers. This change also prevents the need to use display resolution for overlay checks, hence making some of the APPLY functions less dependent on the display. Changes since v3: - Make sure that we write to the timing registers and set go bits when calling dss_mgr_set_timings - Don't create dss_mgr_get_timings(), apply should pass the timings rather than outside DSS dunctions querying form it. These patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Archit Taneja (5): OMAPDSS: APPLY: Add manager timings as extra_info in private data OMAPDSS: Apply manager timings instead of direct DISPC writes OMAPDSS: MANAGER: Create a function to check manager timings OMAPDSS: APPLY: Remove display dependency from overlay and manager checks OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled drivers/video/omap2/dss/apply.c | 140 ++--- drivers/video/omap2/dss/dispc.c |2 +- drivers/video/omap2/dss/dpi.c |6 +- drivers/video/omap2/dss/dsi.c |5 +- drivers/video/omap2/dss/dss.h | 13 +++- drivers/video/omap2/dss/hdmi.c|4 +- drivers/video/omap2/dss/manager.c | 19 +- drivers/video/omap2/dss/overlay.c | 20 +++--- drivers/video/omap2/dss/rfbi.c|4 +- drivers/video/omap2/dss/sdi.c |2 +- drivers/video/omap2/dss/venc.c|2 +- 11 files changed, 163 insertions(+), 54 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] OMAPDSS: APPLY: Add manager timings as extra_info in private data
DISPC manager size and DISPC manager blanking parameters(for LCD managers)
follow the shadow register programming model. Currently, they are programmed
directly by the interface drivers.
To configure manager timings using APPLY, there is a need to introduce extra
info flags for managers, similar to what is done for overlays. This is needed
because timings aren't a part of overlay_manager_info struct configured by a
user of DSS, they are configured internally by the interface or panel drivers.
Add dirty and shadow_dirty extra_info flags for managers, update these flags
at the appropriate places. Rewrite the function extra_info_update_ongoing()
slightly as checking for manager's extra_info flags can simplify the code a bit.
Create function dss_mgr_set_timings() which applies the new manager timings to
extra_info and writes it to the registers and set the go bits.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c | 96 +-
drivers/video/omap2/dss/dss.h |2 +
2 files changed, 85 insertions(+), 13 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index b10b3bc..57686f6 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -99,6 +99,11 @@ struct mgr_priv_data {
/* If true, a display is enabled using this manager */
bool enabled;
+
+ bool extra_info_dirty;
+ bool shadow_extra_info_dirty;
+
+ struct omap_video_timings timings;
};
static struct {
@@ -261,6 +266,20 @@ static bool need_isr(void)
if (mp-shadow_info_dirty)
return true;
+ /*
+* NOTE: we don't check extra_info flags for disabled
+* managers, once the manager is enabled, the extra_info
+* related manager changes will be taken in by HW.
+*/
+
+ /* to write new values to registers */
+ if (mp-extra_info_dirty)
+ return true;
+
+ /* to set GO bit */
+ if (mp-shadow_extra_info_dirty)
+ return true;
+
list_for_each_entry(ovl, mgr-overlays, list) {
struct ovl_priv_data *op;
@@ -305,7 +324,7 @@ static bool need_go(struct omap_overlay_manager *mgr)
mp = get_mgr_priv(mgr);
- if (mp-shadow_info_dirty)
+ if (mp-shadow_info_dirty || mp-shadow_extra_info_dirty)
return true;
list_for_each_entry(ovl, mgr-overlays, list) {
@@ -320,20 +339,16 @@ static bool need_go(struct omap_overlay_manager *mgr)
/* returns true if an extra_info field is currently being updated */
static bool extra_info_update_ongoing(void)
{
- const int num_ovls = omap_dss_get_num_overlays();
- struct ovl_priv_data *op;
- struct omap_overlay *ovl;
- struct mgr_priv_data *mp;
+ const int num_mgrs = dss_feat_get_num_mgrs();
int i;
- for (i = 0; i num_ovls; ++i) {
- ovl = omap_dss_get_overlay(i);
- op = get_ovl_priv(ovl);
-
- if (!ovl-manager)
- continue;
+ for (i = 0; i num_mgrs; ++i) {
+ struct omap_overlay_manager *mgr;
+ struct omap_overlay *ovl;
+ struct mgr_priv_data *mp;
- mp = get_mgr_priv(ovl-manager);
+ mgr = omap_dss_get_overlay_manager(i);
+ mp = get_mgr_priv(mgr);
if (!mp-enabled)
continue;
@@ -341,8 +356,15 @@ static bool extra_info_update_ongoing(void)
if (!mp-updating)
continue;
- if (op-extra_info_dirty || op-shadow_extra_info_dirty)
+ if (mp-extra_info_dirty || mp-shadow_extra_info_dirty)
return true;
+
+ list_for_each_entry(ovl, mgr-overlays, list) {
+ struct ovl_priv_data *op = get_ovl_priv(ovl);
+
+ if (op-extra_info_dirty || op-shadow_extra_info_dirty)
+ return true;
+ }
}
return false;
@@ -601,6 +623,22 @@ static void dss_mgr_write_regs(struct omap_overlay_manager
*mgr)
}
}
+static void dss_mgr_write_regs_extra(struct omap_overlay_manager *mgr)
+{
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ DSSDBGF(%d, mgr-id);
+
+ if (!mp-extra_info_dirty)
+ return;
+
+ dispc_mgr_set_timings(mgr-id, mp-timings);
+
+ mp-extra_info_dirty = false;
+ if (mp-updating)
+ mp-shadow_extra_info_dirty = true;
+}
+
static void dss_write_regs_common(void)
{
const int num_mgrs = omap_dss_get_num_overlay_managers();
@@ -654,6 +692,7 @@ static void
[PATCH v3 2/5] OMAPDSS: Apply manager timings instead of direct DISPC writes
Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
interface drivers. The latter function ensures that the timing related DISPC
registers are configured according to the shadow register programming model.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dpi.c |2 +-
drivers/video/omap2/dss/dsi.c |5 ++---
drivers/video/omap2/dss/hdmi.c |2 +-
drivers/video/omap2/dss/rfbi.c |4 ++--
drivers/video/omap2/dss/sdi.c |2 +-
drivers/video/omap2/dss/venc.c |2 +-
6 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index cec1166..5d84ab0 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -156,7 +156,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
t-pixel_clock = pck;
}
- dispc_mgr_set_timings(dssdev-manager-id, t);
+ dss_mgr_set_timings(dssdev-manager, t);
return 0;
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index b6cf03c..db73598 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4219,13 +4219,12 @@ static int dsi_display_init_dispc(struct
omap_dss_device *dssdev)
dispc_mgr_enable_stallmode(dssdev-manager-id, true);
dispc_mgr_enable_fifohandcheck(dssdev-manager-id, 1);
- dispc_mgr_set_timings(dssdev-manager-id, timings);
+ dss_mgr_set_timings(dssdev-manager, timings);
} else {
dispc_mgr_enable_stallmode(dssdev-manager-id, false);
dispc_mgr_enable_fifohandcheck(dssdev-manager-id, 0);
- dispc_mgr_set_timings(dssdev-manager-id,
- dssdev-panel.timings);
+ dss_mgr_set_timings(dssdev-manager, dssdev-panel.timings);
}
dispc_mgr_set_lcd_display_type(dssdev-manager-id,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 56f6e9c..8d4ff8c 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -376,7 +376,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
dispc_enable_gamma_table(0);
/* tv size */
- dispc_mgr_set_timings(dssdev-manager-id, dssdev-panel.timings);
+ dss_mgr_set_timings(dssdev-manager, dssdev-panel.timings);
hdmi.ip_data.ops-video_enable(hdmi.ip_data, 1);
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index a81ffcb..feadfab 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -320,7 +320,7 @@ static void rfbi_transfer_area(struct omap_dss_device
*dssdev, u16 width,
DSSDBG(rfbi_transfer_area %dx%d\n, width, height);
- dispc_mgr_set_timings(dssdev-manager-id, timings);
+ dss_mgr_set_timings(dssdev-manager, timings);
dispc_mgr_enable(dssdev-manager-id, true);
@@ -804,7 +804,7 @@ int omap_rfbi_prepare_update(struct omap_dss_device *dssdev,
if (*w == 0 || *h == 0)
return -EINVAL;
- dispc_mgr_set_timings(dssdev-manager-id, timings);
+ dss_mgr_set_timings(dssdev-manager, timings);
return 0;
}
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 741b834..67fbe7c 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -107,7 +107,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
}
- dispc_mgr_set_timings(dssdev-manager-id, t);
+ dss_mgr_set_timings(dssdev-manager, t);
r = dss_set_clock_div(dss_cinfo);
if (r)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 30bbb63..e237464 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -444,7 +444,7 @@ static int venc_power_on(struct omap_dss_device *dssdev)
timings = dssdev-panel.timings;
timings.y_res /= 2;
- dispc_mgr_set_timings(dssdev-manager-id, timings);
+ dss_mgr_set_timings(dssdev-manager, timings);
r = regulator_enable(venc.vdda_dac_reg);
if (r)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/5] OMAPDSS: MANAGER: Create a function to check manager timings
Create a function dss_mgr_check_timings() which wraps around the function
dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
from interface drivers.
dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
takes the timings maintained in the omap_dss_device struct. This would be later
replaced by the timings stored in the manager's private data.
Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const
omap_video_timings pointer since these functions just check the timings.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |2 +-
drivers/video/omap2/dss/dpi.c |2 +-
drivers/video/omap2/dss/dss.h |4 +++-
drivers/video/omap2/dss/manager.c | 15 +++
4 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 49015b8..2829a92 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2479,7 +2479,7 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp, int
hbp,
}
bool dispc_mgr_timings_ok(enum omap_channel channel,
- struct omap_video_timings *timings)
+ const struct omap_video_timings *timings)
{
bool timings_ok;
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 5d84ab0..8127f46 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -312,7 +312,7 @@ int dpi_check_timings(struct omap_dss_device *dssdev,
unsigned long pck;
struct dispc_clock_info dispc_cinfo;
- if (!dispc_mgr_timings_ok(dssdev-manager-id, timings))
+ if (!dss_mgr_check_timings(dssdev-manager, timings))
return -EINVAL;
if (timings-pixel_clock == 0)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ca59481..7c9b9bc 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -208,6 +208,8 @@ int dss_init_overlay_managers(struct platform_device *pdev);
void dss_uninit_overlay_managers(struct platform_device *pdev);
int dss_mgr_simple_check(struct omap_overlay_manager *mgr,
const struct omap_overlay_manager_info *info);
+int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
+ const struct omap_video_timings *timings);
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
@@ -414,7 +416,7 @@ void dispc_enable_gamma_table(bool enable);
void dispc_set_loadmode(enum omap_dss_load_mode mode);
bool dispc_mgr_timings_ok(enum omap_channel channel,
- struct omap_video_timings *timings);
+ const struct omap_video_timings *timings);
unsigned long dispc_fclk_rate(void);
void dispc_find_clk_divs(bool is_tft, unsigned long req_pck, unsigned long fck,
struct dispc_clock_info *cinfo);
diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index e736460..566fbba 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -654,6 +654,17 @@ static int dss_mgr_check_zorder(struct
omap_overlay_manager *mgr,
return 0;
}
+int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
+ const struct omap_video_timings *timings)
+{
+ if (!dispc_mgr_timings_ok(mgr-id, timings)) {
+ DSSERR(check_manager: invalid timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_dss_device *dssdev,
struct omap_overlay_manager_info *info,
@@ -668,6 +679,10 @@ int dss_mgr_check(struct omap_overlay_manager *mgr,
return r;
}
+ r = dss_mgr_check_timings(mgr, dssdev-panel.timings);
+ if (r)
+ return r;
+
list_for_each_entry(ovl, mgr-overlays, list) {
struct omap_overlay_info *oi;
int r;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.
Pass the manager's timings(in private data) to dss_mgr_check(). Remove the need
of passing omap_dss_device structs in the functions which check for overlay and
managers.
Have some initial values for manager timings in apply_init(), these would ensure
that manager checks don't fail if an interface driver or a panel driver hasn't
set the manager timings yet.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c | 44 ++---
drivers/video/omap2/dss/dss.h |7 +++--
drivers/video/omap2/dss/manager.c |6 ++--
drivers/video/omap2/dss/overlay.c | 20 +++-
4 files changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 57686f6..7d59caf 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -137,10 +137,30 @@ static struct mgr_priv_data *get_mgr_priv(struct
omap_overlay_manager *mgr)
void dss_apply_init(void)
{
const int num_ovls = dss_feat_get_num_ovls();
+ const int num_mgrs = dss_feat_get_num_ovls();
int i;
+ /* Use dummy manager timings during initialization */
+ struct omap_video_timings timings = {
+ .hsw= 1,
+ .hfp= 1,
+ .hbp= 1,
+ .vsw= 1,
+ .vfp= 0,
+ .vbp= 0,
+ .x_res = dss_feat_get_param_max(FEAT_PARAM_MGR_WIDTH),
+ .y_res = dss_feat_get_param_max(FEAT_PARAM_MGR_HEIGHT),
+ };
spin_lock_init(data_lock);
+ for (i = 0; i num_mgrs; i++) {
+ struct mgr_priv_data *mp;
+
+ mp = dss_data.mgr_priv_data_array[i];
+
+ mp-timings = timings;
+ }
+
for (i = 0; i num_ovls; ++i) {
struct ovl_priv_data *op;
@@ -181,7 +201,7 @@ static bool mgr_manual_update(struct omap_overlay_manager
*mgr)
}
static int dss_check_settings_low(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev, bool applying)
+ bool applying)
{
struct omap_overlay_info *oi;
struct omap_overlay_manager_info *mi;
@@ -211,26 +231,24 @@ static int dss_check_settings_low(struct
omap_overlay_manager *mgr,
ois[ovl-id] = oi;
}
- return dss_mgr_check(mgr, dssdev, mi, ois);
+ return dss_mgr_check(mgr, mi, mp-timings, ois);
}
/*
* check manager and overlay settings using overlay_info from data-info
*/
-static int dss_check_settings(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev)
+static int dss_check_settings(struct omap_overlay_manager *mgr)
{
- return dss_check_settings_low(mgr, dssdev, false);
+ return dss_check_settings_low(mgr, false);
}
/*
* check manager and overlay settings using overlay_info from ovl-info if
* dirty and from data-info otherwise
*/
-static int dss_check_settings_apply(struct omap_overlay_manager *mgr,
- struct omap_dss_device *dssdev)
+static int dss_check_settings_apply(struct omap_overlay_manager *mgr)
{
- return dss_check_settings_low(mgr, dssdev, true);
+ return dss_check_settings_low(mgr, true);
}
static bool need_isr(void)
@@ -684,7 +702,7 @@ static void dss_write_regs(void)
if (!mp-enabled || mgr_manual_update(mgr) || mp-busy)
continue;
- r = dss_check_settings(mgr, mgr-device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR(cannot write registers for manager %s:
illegal configuration\n, mgr-name);
@@ -751,7 +769,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr)
WARN_ON(mp-updating);
- r = dss_check_settings(mgr, mgr-device);
+ r = dss_check_settings(mgr);
if (r) {
DSSERR(cannot start manual update: illegal configuration\n);
spin_unlock_irqrestore(data_lock, flags);
@@ -898,7 +916,7 @@ int omap_dss_mgr_apply(struct omap_overlay_manager *mgr)
spin_lock_irqsave(data_lock, flags);
- r = dss_check_settings_apply(mgr, mgr-device);
+ r = dss_check_settings_apply(mgr);
if (r) {
spin_unlock_irqrestore(data_lock, flags);
DSSERR(failed to apply settings: illegal configuration.\n);
@@ -1091,7 +1109,7 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr)
mp-enabled = true;
- r = dss_check_settings(mgr, mgr-device);
+ r = dss_check_settings(mgr);
if (r)
[PATCH v3 5/5] OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
The DPI and HDMI interfaces use their 'set_timing' functions to take in a new
set of timings. If the panel is disabled, they do not disable and re-enable
the interface. Currently, the manager timings are applied in hdmi_power_on()
and dpi_set_mode() respectively, these are not called by set_timings if the
panel is disabled.
When checking overlay and manager data, the DSS driver uses the last applied
manager timings, and not the timings held by omap_dss_device struct. Hence,
there is a need to apply the new manager timings even if the panel is disabled.
Apply the manager timings if the panel is disabled. Eventually, there should be
one common place where the timings are applied independent of the state of the
panel.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dpi.c |2 ++
drivers/video/omap2/dss/hdmi.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 8127f46..1650050 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -298,6 +298,8 @@ void dpi_set_timings(struct omap_dss_device *dssdev,
dispc_runtime_put();
dss_runtime_put();
+ } else {
+ dss_mgr_set_timings(dssdev-manager, timings);
}
}
EXPORT_SYMBOL(dpi_set_timings);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8d4ff8c..32ad712 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -435,6 +435,8 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device
*dssdev)
r = hdmi_power_on(dssdev);
if (r)
DSSERR(failed to power on device\n);
+ } else {
+ dss_mgr_set_timings(dssdev-manager, dssdev-panel.timings);
}
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 05/10] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
On Mon, May 07, 2012 at 10:51:53, J, KEERTHY wrote:
On Fri, May 4, 2012 at 2:42 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
From: Jean Pihet j-pi...@ti.com
Now that omap_test_timeout is only accessible from mach-omap2/,
introduce a similar function for SR.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet j-pi...@ti.com
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 12 ++--
include/linux/power/smartreflex.h | 23 ++-
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d859277..acef08d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -289,9 +289,9 @@ static void sr_v1_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until ERRCONFIG.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, ERRCONFIG_V1)
- ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, ERRCONFIG_V1)
+ ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable
timedout\n,
@@ -334,9 +334,9 @@ static void sr_v2_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until IRQSTATUS.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, IRQSTATUS)
- IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, IRQSTATUS)
+ IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
+ timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable
timedout\n,
diff --git a/include/linux/power/smartreflex.h
b/include/linux/power/smartreflex.h
index 884eaee..78b795e 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -22,7 +22,7 @@
#include linux/types.h
#include linux/platform_device.h
-
+#include linux/delay.h
#include plat/voltage.h
/*
@@ -168,6 +168,27 @@ struct omap_sr {
};
/**
+ * test_cond_timeout - busy-loop, testing a condition
+ * @cond: condition to test until it evaluates to true
+ * @timeout: maximum number of microseconds in the timeout
+ * @index: loop index (integer)
+ *
+ * Loop waiting for @cond to become true or until at least @timeout
+ * microseconds have passed. To use, define some integer @index in the
+ * calling code. After running, if @index == @timeout, then the loop has
+ * timed out.
+ *
+ * Copied from omap_test_timeout */
+#define sr_test_cond_timeout(cond, timeout, index) \
+({ \
+ for (index = 0; index timeout; index++) { \
+ if (cond) \
+ break; \
+ udelay(1); \
+ } \
+})
I think we can use time_after()/time_before() APIs for timeout and
cpu_relax() for
tight loops instead of udelay().
cpu_relax() changes the priority everytime to low and will yield to
another thread.
Considering that we are checking the condition every microsecond does it make
some saving using cpu_relax().
cpu_relax() does not involve any priority changes or scheduling AFAICS.
Have a look at this thread:
http://www.spinics.net/lists/netdev/msg151699.html
Regards
AnilKumar
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
On Tue, May 08, 2012 at 05:18:41, Hilman, Kevin wrote: AnilKumar, Chimata anilku...@ti.com writes: On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote: Hi Mark, Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote: Devfreq and cpufreq are related to dynamic frequency/voltage switching between pre defined Operating Performance Points or the OPPs. Every OPP being a voltage/frequency pair. Smartreflex is a different power management technique. But presumably these things should integrate somehow - for example, should devfreq and cpufreq be providing inputs into what AVS is doing, and if so how? The way it is currently designed, cpufreq/devfreq/regulator layers don't need to know about AVS. The higher-level layers only know about the nominal voltage. AVS hardware does automatic, adaptive, micro-adjustments around that nominal voltage, and these micro-adjustments are managed by the AVS hardware sending commands to the PMIC. (specifically, on OMAP, the AVS sensors provide inputs to the voltage processor (VP) which provide inputs to the voltage controller (VC) which sends commands to the PMIC[1].) The driver proposed here is primarily for initializing the various parameters/sensitivity/etc. of the AVS hardware, but the actual voltage adjustments are done in hardware by VC/VP. The only thing the higher-level layers might potentially need to do to enable/disable AVS around transitions (e.g. when changing OPP, AVS is disabled before changing OPP and only re-enabled when the new nominal voltage has been acheived.) On OMAP, we handle this inside the OMAP-specific voltage layer which is called by the regulator framework, so even the regulators do not need any knowledge of AVS. Kevin, I want to point out some cases of SR implementation where this may not be true. Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR. Under this, SR module issues an interrupt to ARM when there is a need to change the voltage based on temperature changes, ageing etc. Once the interrupt arrives, kernel needs to adjust voltage using regulator API. The voltage change is a micro adjustment as in other SR classes. That can easily be handled writing a plugin specific to class 2B. This driver was designed so plugins for other classes can be supported. Sure, we might need some enhancements for other classes (we already know that we will for class 1 support.) However, the purpose of this series is to do the cleanups necessary for the driver to move to drivers/*. It's perfectly fine with me. My intention was just to highlight that class 2B SR will have to interact with regulator layer for voltage changes, so I guess it is little different from other SR classes. Thanks, AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Tue, 2012-05-08 at 15:28 +0530, Archit Taneja wrote:
In order to check the validity of overlay and manager info, there was a need
to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need
to
rely on the display resolution any more.
Pass the manager's timings(in private data) to dss_mgr_check(). Remove the
need
of passing omap_dss_device structs in the functions which check for overlay
and
managers.
Have some initial values for manager timings in apply_init(), these would
ensure
that manager checks don't fail if an interface driver or a panel driver hasn't
set the manager timings yet.
In what code patch were the initial values needed?
Checking the validity of all the settings is a bit tricky, but currently
I think, as a rule of thumb, we should accept any settings when things
are disabled. So, until the interface driver sets the timings before
enabling the output, all ovl/mgr settings should be allowed. And we
shouldn't even write any shadow registers until the moment the output is
enabled.
Except settings that do not depend on anything, like, if max ovl width
is 2048, it's fine to reject 2049+ width anytime.
-int dss_ovl_check(struct omap_overlay *ovl,
- struct omap_overlay_info *info, struct omap_dss_device *dssdev)
+int dss_ovl_check(struct omap_overlay *ovl, struct omap_overlay_info *info,
+ const struct omap_video_timings *mgr_timings)
{
u16 outw, outh;
- u16 dw, dh;
+ u16 mgr_width, mgr_height;
- if (dssdev == NULL)
- return 0;
-
- dssdev-driver-get_resolution(dssdev, dw, dh);
+ mgr_width = mgr_timings-x_res;
+ mgr_height = mgr_timings-y_res;
I think you could've just used the existing dw and dh variables, thus
avoiding the need to change the rest of the function. The 'd' refers to
display, which is more or less the same as mgr width.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v3 2/5] OMAPDSS: Apply manager timings instead of direct DISPC writes
On Tue, 2012-05-08 at 15:28 +0530, Archit Taneja wrote: Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the interface drivers. The latter function ensures that the timing related DISPC registers are configured according to the shadow register programming model. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/dpi.c |2 +- drivers/video/omap2/dss/dsi.c |5 ++--- drivers/video/omap2/dss/hdmi.c |2 +- drivers/video/omap2/dss/rfbi.c |4 ++-- drivers/video/omap2/dss/sdi.c |2 +- drivers/video/omap2/dss/venc.c |2 +- 6 files changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c index cec1166..5d84ab0 100644 --- a/drivers/video/omap2/dss/dpi.c +++ b/drivers/video/omap2/dss/dpi.c @@ -156,7 +156,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev) t-pixel_clock = pck; } - dispc_mgr_set_timings(dssdev-manager-id, t); + dss_mgr_set_timings(dssdev-manager, t); return 0; } I think you can now remove the dispc_mgr_go() from dpi.c in this patch. And something else, which doesn't need to be fixed now, but just to point out: dpi_set_timings() currently uses runtime_get to enable the HW. If everything was in proper shape, this wouldn't be needed. dpi_set_timings() would call apply.c's functions, and if the output is disabled, the settings would just be stored in ram. So there wouldn't be any need to enable the HW with runtime_get(). Then again, if we do change clock settings or non-shadow registers in dpi_set_timings(), then that's not possible (at least via apply.c's caching system). Tomi signature.asc Description: This is a digitally signed message part
Re: oprofile and ARM A9 hardware counter
Hi Kevin Jon, On 5/8/2012 1:28 AM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunterjon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunterjon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Perfect, thanks. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed here. Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state
Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote:
On Tue, 2012-05-08 at 15:28 +0530, Archit Taneja wrote:
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.
Pass the manager's timings(in private data) to dss_mgr_check(). Remove the need
of passing omap_dss_device structs in the functions which check for overlay and
managers.
Have some initial values for manager timings in apply_init(), these would ensure
that manager checks don't fail if an interface driver or a panel driver hasn't
set the manager timings yet.
In what code patch were the initial values needed?
I guess you meant code path. If a panel driver doesn't have set_timings
op, then we get into trouble with omapfb. The following steps happen:
- try to set timings of display
- create buffers, configure overlays according to omap_dss_device
- call mgr-apply()
- enable the panel
For panels which don't have set_timings populated, if apply is called,
the manager timings are still zero, and the mgr-apply fails when
dss_mgr_check() is called.
When the panel driver's enable is called, the timings are configured in
the interface drivers 'enable'. The enables(like
dpi_display_enable,dsi_display_enable) of all interface driver's call
dss_mgr_set_timings(), so we are sure that the timings are configured by
then. But there is no such guarantee at set timings.
Things used to work previously because we used to simply get the
connected panel and use its dimensions, if there was no panel connected,
we used to skip the check.
Checking the validity of all the settings is a bit tricky, but currently
I think, as a rule of thumb, we should accept any settings when things
are disabled. So, until the interface driver sets the timings before
enabling the output, all ovl/mgr settings should be allowed. And we
We have 2 ways to go about this, one is to have an initial set of
'always valid' values like I have done, the other option is to ignore
manager timing related checks if the manager is disabled, i.e all
configs are okay. To implement the second option, I think our function
dss_check_settings_low() would get more complicated. We would now have
to pass mp-enabled outside of apply, and pass it to dss_mgr_check()
which would further need to pass this to dss_ovl_check(). Hence I used
the first approach.
shouldn't even write any shadow registers until the moment the output is
enabled.
That's being done correctly even now I guess, with the checks for
mp-enabled in wrtie_regs() and set_go_bits().
Except settings that do not depend on anything, like, if max ovl width
is 2048, it's fine to reject 2049+ width anytime.
-int dss_ovl_check(struct omap_overlay *ovl,
- struct omap_overlay_info *info, struct omap_dss_device *dssdev)
+int dss_ovl_check(struct omap_overlay *ovl, struct omap_overlay_info *info,
+ const struct omap_video_timings *mgr_timings)
{
u16 outw, outh;
- u16 dw, dh;
+ u16 mgr_width, mgr_height;
- if (dssdev == NULL)
- return 0;
-
- dssdev-driver-get_resolution(dssdev,dw,dh);
+ mgr_width = mgr_timings-x_res;
+ mgr_height = mgr_timings-y_res;
I think you could've just used the existing dw and dh variables, thus
avoiding the need to change the rest of the function. The 'd' refers to
display, which is more or less the same as mgr width.
I'll fix this.
Archit
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Hi Benoit, On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Kevin Jon, On 5/8/2012 1:28 AM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunterjon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunterjon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Perfect, thanks. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed here. Yes, indeed, we should not hack the flags to fix that kind of issue.
RE: [PATCH v4 00/39] OMAP GPMC driver conversion
Hi Tony, On Tue, May 01, 2012 at 17:49:03, Mohammed, Afzal wrote: GPMC driver conversion patch series. Some peripherals has GPMC helper functions, these has been modified to cater to the needs of GPMC driver. All the boards using GPMC has been adapted to use the new GPMC driver. GPMC HWMOD entry for OMAP2/3 has been added. On OMAP3, kernel does spit omap_hwmod: gpmc: cannot be enabled for reset (3), but peripherals connected via GPMC are working. Really shaky about OMAP2 GPMC HWMOD entry. Would be helpful if someone can help me in resolving warning on OMAP3 verify whether OMAP2 entry is proper. The series adapts to HWMOD. Drivers, NAND OneNAND of OMAP has been modified to make use of GPMC changes cleaned up the now unnecessary exported symbol usages. This series has been made on top of, 5e136da Linux-omap rebuilt: Updated to -rc5, A patch by Javier Martinez Canillas jav...@dowhile0.org, OMAP3: igep0020: Add support for Micron NAND Flash storage memory, has also been incorporated into the series as this was necessary for igep0020 board. This has been tested on omap3 evm (SMSC911x) beagle board (NAND) Please let me know your comments on this series. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] mmc: omap: driver registration cleanups
Cleanups for the legacy omap mmc driver to remove clutter and make it well behaved as module. Venkatraman S (3): mmc: omap: convert to per instance workqueue mmc: omap: make it behave well as module mmc: omap: convert to module_platform_driver drivers/mmc/host/omap.c | 48 +++--- 1 files changed, 16 insertions(+), 32 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] mmc: omap: convert to per instance workqueue
Currently, a global mmc_omap_wq is created for all instances of
omap hosts, which can lead to races and doesn't lend itself to
unload the module cleanly.
Instead, create per instance workqueue and remove the common workqueue.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap.c | 29 -
1 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 887c0e5..2d7628e 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -169,11 +169,11 @@ struct mmc_omap_host {
struct timer_list clk_timer;
spinlock_t clk_lock; /* for changing enabled state */
unsigned intfclk_enabled:1;
+ struct workqueue_struct *mmc_omap_wq;
struct omap_mmc_platform_data *pdata;
};
-static struct workqueue_struct *mmc_omap_wq;
static void mmc_omap_fclk_offdelay(struct mmc_omap_slot *slot)
{
@@ -291,7 +291,7 @@ static void mmc_omap_release_slot(struct mmc_omap_slot
*slot, int clk_enabled)
host-next_slot = new_slot;
host-mmc = new_slot-mmc;
spin_unlock_irqrestore(host-slot_lock, flags);
- queue_work(mmc_omap_wq, host-slot_release_work);
+ queue_work(host-mmc_omap_wq, host-slot_release_work);
return;
}
@@ -459,7 +459,7 @@ mmc_omap_xfer_done(struct mmc_omap_host *host, struct
mmc_data *data)
}
host-stop_data = data;
- queue_work(mmc_omap_wq, host-send_stop_work);
+ queue_work(host-mmc_omap_wq, host-send_stop_work);
}
static void
@@ -639,7 +639,7 @@ mmc_omap_cmd_timer(unsigned long data)
OMAP_MMC_WRITE(host, IE, 0);
disable_irq(host-irq);
host-abort = 1;
- queue_work(mmc_omap_wq, host-cmd_abort_work);
+ queue_work(host-mmc_omap_wq, host-cmd_abort_work);
}
spin_unlock_irqrestore(host-slot_lock, flags);
}
@@ -828,7 +828,7 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
host-abort = 1;
OMAP_MMC_WRITE(host, IE, 0);
disable_irq_nosync(host-irq);
- queue_work(mmc_omap_wq, host-cmd_abort_work);
+ queue_work(host-mmc_omap_wq, host-cmd_abort_work);
return IRQ_HANDLED;
}
@@ -1389,7 +1389,7 @@ static void mmc_omap_remove_slot(struct mmc_omap_slot
*slot)
tasklet_kill(slot-cover_tasklet);
del_timer_sync(slot-cover_timer);
- flush_workqueue(mmc_omap_wq);
+ flush_workqueue(slot-host-mmc_omap_wq);
mmc_remove_host(mmc);
mmc_free_host(mmc);
@@ -1497,6 +1497,10 @@ static int __init mmc_omap_probe(struct platform_device
*pdev)
host-reg_shift = (cpu_is_omap7xx() ? 1 : 2);
+ host-mmc_omap_wq = alloc_workqueue(mmc_omap, 0, 0);
+ if (!host-mmc_omap_wq)
+ goto err_plat_cleanup;
+
return 0;
err_plat_cleanup:
@@ -1542,6 +1546,7 @@ static int mmc_omap_remove(struct platform_device *pdev)
iounmap(host-virt_base);
release_mem_region(pdev-resource[0].start,
pdev-resource[0].end - pdev-resource[0].start + 1);
+ destroy_workqueue(host-mmc_omap_wq);
kfree(host);
@@ -1610,22 +1615,12 @@ static struct platform_driver mmc_omap_driver = {
static int __init mmc_omap_init(void)
{
- int ret;
-
- mmc_omap_wq = alloc_workqueue(mmc_omap, 0, 0);
- if (!mmc_omap_wq)
- return -ENOMEM;
-
- ret = platform_driver_probe(mmc_omap_driver, mmc_omap_probe);
- if (ret)
- destroy_workqueue(mmc_omap_wq);
- return ret;
+ return platform_driver_probe(mmc_omap_driver, mmc_omap_probe);
}
static void __exit mmc_omap_exit(void)
{
platform_driver_unregister(mmc_omap_driver);
- destroy_workqueue(mmc_omap_wq);
}
module_init(mmc_omap_init);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] mmc: omap: make it behave well as module
Use proper __devinit and __devexit annotation for driver
functions. Instantiate the probe function for driver_ops
instead of a probe in the register function.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 2d7628e..0056bd8 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1395,7 +1395,7 @@ static void mmc_omap_remove_slot(struct mmc_omap_slot
*slot)
mmc_free_host(mmc);
}
-static int __init mmc_omap_probe(struct platform_device *pdev)
+static int __devinit mmc_omap_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev-dev.platform_data;
struct mmc_omap_host *host = NULL;
@@ -1522,7 +1522,7 @@ err_free_mem_region:
return ret;
}
-static int mmc_omap_remove(struct platform_device *pdev)
+static int __devexit mmc_omap_remove(struct platform_device *pdev)
{
struct mmc_omap_host *host = platform_get_drvdata(pdev);
int i;
@@ -1604,7 +1604,8 @@ static int mmc_omap_resume(struct platform_device *pdev)
#endif
static struct platform_driver mmc_omap_driver = {
- .remove = mmc_omap_remove,
+ .probe = mmc_omap_probe,
+ .remove = __devexit_p(mmc_omap_remove),
.suspend= mmc_omap_suspend,
.resume = mmc_omap_resume,
.driver = {
@@ -1615,7 +1616,7 @@ static struct platform_driver mmc_omap_driver = {
static int __init mmc_omap_init(void)
{
- return platform_driver_probe(mmc_omap_driver, mmc_omap_probe);
+ return platform_driver_register(mmc_omap_driver);
}
static void __exit mmc_omap_exit(void)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] mmc: omap: convert to module_platform_driver
Get rid of boilerplate code by using module_platform_driver macro,
no functional changes.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 0056bd8..552196c 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1614,19 +1614,7 @@ static struct platform_driver mmc_omap_driver = {
},
};
-static int __init mmc_omap_init(void)
-{
- return platform_driver_register(mmc_omap_driver);
-}
-
-static void __exit mmc_omap_exit(void)
-{
- platform_driver_unregister(mmc_omap_driver);
-}
-
-module_init(mmc_omap_init);
-module_exit(mmc_omap_exit);
-
+module_platform_driver(mmc_omap_driver);
MODULE_DESCRIPTION(OMAP Multimedia Card driver);
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform: DRIVER_NAME);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Tue, 2012-05-08 at 16:52 +0530, Archit Taneja wrote: On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote: Checking the validity of all the settings is a bit tricky, but currently I think, as a rule of thumb, we should accept any settings when things are disabled. So, until the interface driver sets the timings before enabling the output, all ovl/mgr settings should be allowed. And we We have 2 ways to go about this, one is to have an initial set of 'always valid' values like I have done, the other option is to ignore manager timing related checks if the manager is disabled, i.e all configs are okay. To implement the second option, I think our function dss_check_settings_low() would get more complicated. We would now have to pass mp-enabled outside of apply, and pass it to dss_mgr_check() which would further need to pass this to dss_ovl_check(). Hence I used the first approach. I'm not sure about that. We already do it for overlay. In ovl.c we have dss_ovl_simple_check() and dss_ovl_check(). The simple check sees if the settings pass basic sanity check. The check sees if all the ovl mgr settings are compatible with each other. Simple check is done when setting the config, called from dss_ovl_set_info(). The proper check is done later when the actual config is about to be taken into use. If mp-enabled == false, can't we just skip dss_check_settings_low() totally for that manager? We skip the check for ovls the same way. shouldn't even write any shadow registers until the moment the output is enabled. That's being done correctly even now I guess, with the checks for mp-enabled in wrtie_regs() and set_go_bits(). Yes, for timings. I was thinking more about the other settings done in dpi.c currently, like dispc_mgr_set_pol_freq(). That writes directly to registers, so we need runtime_get for that. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/6] OMAPDSS: Misc fixes and cleanups
On Mon, 2012-05-07 at 16:51 +0530, Archit Taneja wrote: The first patch in this series is a follow up on the previously posted series 'OMAPDSS: APPLY: Treat overlay manager timings as shadow registers'. It is required for HDMI and DPI interfaces to work properly, it ensures manager timings are applied in the set_timing() ops for these interfaces. The next 3 patches remove some unnecessary usage of omap_dss_device pointer in DISPC and APPLY. The last 2 patches are miscellaneous fixes and are self explanatory. Reference tree containing this series: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes Tested on OMAP4 SDP. Archit Taneja (6): OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate() OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device() OMAPDSS: Fix DSI_FCLK clock source selection OMAPDSS: DISPC: Remove Fake VSYNC support The first four patches seem to be related (or at least based) to the set_timings series (and the first patch you already had included in later version). Should I take the two last patches and apply them already, as they are fine and don't depend on anything? You could add the first 4 patches into the set_timings series. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/2] OMAPDSS: HDMI: Fix register dump of CORE registers
On Mon, 2012-05-07 at 18:50 +0530, Archit Taneja wrote: The HDMI CORE registers are dumped incorrectly due to incorrect register offset calculations. They are also dumped in a random order, with some of the registers repeated. This series fixes these issues. The patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Tested on OMAP4 SDP. Archit Taneja (2): OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump OMAPDSS: HDMI: define and dump CORE registers in correct order drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 163 +++-- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 57 +-- 2 files changed, 109 insertions(+), 111 deletions(-) Thanks, applying these. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/2] OMAPDSS: HDMI: Fix register dump of CORE registers
Hi, On Tuesday 08 May 2012 05:34 PM, Tomi Valkeinen wrote: On Mon, 2012-05-07 at 18:50 +0530, Archit Taneja wrote: The HDMI CORE registers are dumped incorrectly due to incorrect register offset calculations. They are also dumped in a random order, with some of the registers repeated. This series fixes these issues. The patches apply over: git://gitorious.org/linux-omap-dss2/linux.git dev Tested on OMAP4 SDP. Archit Taneja (2): OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump OMAPDSS: HDMI: define and dump CORE registers in correct order drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 163 +++-- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 57 +-- 2 files changed, 109 insertions(+), 111 deletions(-) Thanks, applying these. In the second patch, there are some unnecessary lines left in the core_dump function(): - DUMPCOREAV(HDMI_CORE_AV_AVI_CHSUM); - for (i = 0; i HDMI_CORE_AV_AVI_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_AVI_DBYTE); - for (i = 0; i HDMI_CORE_AV_SPD_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_SPD_DBYTE); - for (i = 0; i HDMI_CORE_AV_AUD_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_AUD_DBYTE); - - for (i = 0; i HDMI_CORE_AV_MPEG_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_MPEG_DBYTE); - for (i = 0; i HDMI_CORE_AV_GEN_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_GEN_DBYTE); - - for (i = 0; i HDMI_CORE_AV_GEN2_DBYTE_NELEMS; i++) - DUMPCOREAV2(i, HDMI_CORE_AV_GEN2_DBYTE); So you will see 5 annoying empty lines, could you remove those when you apply, i totally missed this out.. Thanks, Archit Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAPDSS: Misc fixes and cleanups
On Tuesday 08 May 2012 05:28 PM, Tomi Valkeinen wrote: On Mon, 2012-05-07 at 16:51 +0530, Archit Taneja wrote: The first patch in this series is a follow up on the previously posted series 'OMAPDSS: APPLY: Treat overlay manager timings as shadow registers'. It is required for HDMI and DPI interfaces to work properly, it ensures manager timings are applied in the set_timing() ops for these interfaces. The next 3 patches remove some unnecessary usage of omap_dss_device pointer in DISPC and APPLY. The last 2 patches are miscellaneous fixes and are self explanatory. Reference tree containing this series: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git mgr_timing_and_fixes Tested on OMAP4 SDP. Archit Taneja (6): OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate() OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device() OMAPDSS: Fix DSI_FCLK clock source selection OMAPDSS: DISPC: Remove Fake VSYNC support The first four patches seem to be related (or at least based) to the set_timings series (and the first patch you already had included in later version). Should I take the two last patches and apply them already, as they are fine and don't depend on anything? You could add the first 4 patches into the set_timings series. Yes, you can apply the last 2 patches. Thanks, Archit Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
On Tuesday 08 May 2012 05:25 PM, Tomi Valkeinen wrote: On Tue, 2012-05-08 at 16:52 +0530, Archit Taneja wrote: On Tuesday 08 May 2012 04:20 PM, Tomi Valkeinen wrote: Checking the validity of all the settings is a bit tricky, but currently I think, as a rule of thumb, we should accept any settings when things are disabled. So, until the interface driver sets the timings before enabling the output, all ovl/mgr settings should be allowed. And we We have 2 ways to go about this, one is to have an initial set of 'always valid' values like I have done, the other option is to ignore manager timing related checks if the manager is disabled, i.e all configs are okay. To implement the second option, I think our function dss_check_settings_low() would get more complicated. We would now have to pass mp-enabled outside of apply, and pass it to dss_mgr_check() which would further need to pass this to dss_ovl_check(). Hence I used the first approach. I'm not sure about that. We already do it for overlay. In ovl.c we have dss_ovl_simple_check() and dss_ovl_check(). The simple check sees if the settings pass basic sanity check. The check sees if all the ovl mgr settings are compatible with each other. Simple check is done when setting the config, called from dss_ovl_set_info(). The proper check is done later when the actual config is about to be taken into use. If mp-enabled == false, can't we just skip dss_check_settings_low() totally for that manager? We skip the check for ovls the same way. Okay, this would work better I guess. If someone tries to enable the manager without setting the timings, that check should fail, and in my approach, it would have passed, and would have led to bad stuff later. shouldn't even write any shadow registers until the moment the output is enabled. That's being done correctly even now I guess, with the checks for mp-enabled in wrtie_regs() and set_go_bits(). Yes, for timings. I was thinking more about the other settings done in dpi.c currently, like dispc_mgr_set_pol_freq(). That writes directly to registers, so we need runtime_get for that. Ok. Archit Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Salut Jean, On 5/8/2012 1:23 PM, Jean Pihet wrote: Hi Benoit, On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoitb-cous...@ti.com wrote: Hi Kevin Jon, On 5/8/2012 1:28 AM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.comwrites: Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.comwrites: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunterjon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunterjon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Perfect, thanks. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the beahvior. In this case, clkdm_allow_idle(), clkdm_deny_idle() are probably what is needed here. Yes, indeed, we should not hack the flags to fix that kind of issue. The flags
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Mon, May 07, 2012 at 02:42:29PM +0100, Santosh Shilimkar wrote: From: R Sricharan r.sricha...@ti.com ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered. But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager. This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5. This patch tries to fix the issue by ensuring that non-DRAM region is marked as a client domain so that XN attribute is effective. A better alternative is to not map un-used regions but since the decompressor code is generic, there might be many exceptions for the devices used like debug console etc. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm/boot/compressed/head.S |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..4dc799b 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -578,7 +578,7 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size mov r9, r0, lsr #18 mov r9, r9, lsl #18 @ start of RAM add r10, r9, #0x1000@ a reasonable RAM size - mov r1, #0x12 + mov r1, #0x32 @ set domain1, XN, valid orr r1, r1, #3 10 add r2, r3, #16384 1: cmp r1, r9 @ if virt start of RAM @@ -587,8 +587,10 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size #else orrhs r1, r1, #0x0c @ set cacheable, bufferable #endif + bichs r1, r1, #0x20 @ set domain0 for DRAM cmp r1, r10 @ if virt end of RAM bichs r1, r1, #0x0c @ clear cacheable, bufferable + orrhs r1, r1, #0x20 @ set domain1 I would leave the same domain (0, set as client) and rather change the XN and cacheability bits once we finished with the DRAM. I think it's cleaner assuming we have two domains and the manager one overrides the XN bit. str r1, [r0], #4@ 1:1 mapping add r1, r1, #1048576 teq r0, r2 @@ -658,6 +660,9 @@ __armv7_mmu_cache_on: movne r1, #-1 mcrne p15, 0, r3, c2, c0, 0 @ load page table pointer mcrne p15, 0, r1, c3, c0, 0 @ load domain access control + bic r1, r1, #0xc + orr r1, r1, #0x4 + mcr p15, 0, r1, c3, c0, 0 @ set domain1 as cliento So here just set domain 0 as client. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] ARM: OMAP5: Add SMP support.
Hello,
On Thu, May 03, 2012 at 08:26:18AM +0100, R Sricharan wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/omap-headsmp.S | 21 ++
arch/arm/mach-omap2/omap-smp.c | 41 +--
3 files changed, 51 insertions(+), 12 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 151fd5b..9424bb6 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -33,6 +33,10 @@
#include common.h
#include clockdomain.h
+#define CPU_MASK 0xff00
+#define CPU_CORTEX_A90x410FC090
+#define CPU_CORTEX_A15 0x410FC0F0
+
/* SCU base address */
static void __iomem *scu_base;
@@ -43,6 +47,14 @@ void __iomem *omap4_get_scu_base(void)
return scu_base;
}
+static inline unsigned int get_a15_core_count(void)
+{
+ unsigned int ncores;
+
+ asm volatile(mrc p15, 1, %0, c9, c0, 2\n : =r (ncores));
+ return ((ncores 24) 3) + 1;
+}
This register (L2 control) only tells you how many cores you have hanging
off the L2 cache, which isn't really viable for future multi-cluster
configurations. You're probably better off either reading the number of CPU
nodes out of the DT (ppc, vexpress) or returning a constant for now
(exynos5).
Will
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] ARM: OMAP5: Add SMP support.
On Tuesday 08 May 2012 06:17 PM, Will Deacon wrote:
Hello,
On Thu, May 03, 2012 at 08:26:18AM +0100, R Sricharan wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/omap-headsmp.S | 21 ++
arch/arm/mach-omap2/omap-smp.c | 41
+--
3 files changed, 51 insertions(+), 12 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 151fd5b..9424bb6 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -33,6 +33,10 @@
#include common.h
#include clockdomain.h
+#define CPU_MASK0xff00
+#define CPU_CORTEX_A9 0x410FC090
+#define CPU_CORTEX_A15 0x410FC0F0
+
/* SCU base address */
static void __iomem *scu_base;
@@ -43,6 +47,14 @@ void __iomem *omap4_get_scu_base(void)
return scu_base;
}
+static inline unsigned int get_a15_core_count(void)
+{
+unsigned int ncores;
+
+asm volatile(mrc p15, 1, %0, c9, c0, 2\n : =r (ncores));
+return ((ncores 24) 3) + 1;
+}
This register (L2 control) only tells you how many cores you have hanging
off the L2 cache, which isn't really viable for future multi-cluster
configurations. You're probably better off either reading the number of CPU
nodes out of the DT (ppc, vexpress) or returning a constant for now
(exynos5).
Thanks will for the information. I agree for the future multiple
packages, this register may not be good enough. We can hard-code
it as well for now.
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2/3: hwmod data: add gpmc
Add gpmc hwmod and associated interconnect data
Signed-off-by: Afzal Mohammed af...@ti.com
---
Hi Paul,
This is patch 13/39 14/39 of v4 OMAP GPMC driver conversion
series modified and squashed into one.
Regards
Afzal
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 18 ++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 18 ++
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 47
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 58
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
arch/arm/mach-omap2/prcm-common.h |2 +
6 files changed, 144 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 2c087ff..55c8c7b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -428,6 +428,23 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp2 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap2420_gpmc_addrs[] = {
+ {
+ .pa_start = 0x6800A000,
+ .pa_end = 0x6800AFFF,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+static struct omap_hwmod_ocp_if omap2420_l3__gpmc = {
+ .master = omap2xxx_l3_main_hwmod,
+ .slave = omap2xxx_gpmc_hwmod,
+ .clk= core_l3_ck,
+ .addr = omap2420_gpmc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -468,6 +485,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
omap2420_l4_core__mailbox,
omap2420_l4_core__mcbsp1,
omap2420_l4_core__mcbsp2,
+ omap2420_l3__gpmc,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 71d9f88..dd224cca 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -838,6 +838,23 @@ static struct omap_hwmod_ocp_if omap2430_l4_core__mcbsp5 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_addr_space omap2430_gpmc_addrs[] = {
+ {
+ .pa_start = 0x6E00,
+ .pa_end = 0x6E000FFF,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+static struct omap_hwmod_ocp_if omap2430_l3__gpmc = {
+ .master = omap2xxx_l3_main_hwmod,
+ .slave = omap2xxx_gpmc_hwmod,
+ .clk= core_l3_ck,
+ .addr = omap2430_gpmc_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -886,6 +903,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[]
__initdata = {
omap2430_l4_core__mcbsp3,
omap2430_l4_core__mcbsp4,
omap2430_l4_core__mcbsp5,
+ omap2430_l3__gpmc,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 45aaa07..091ea65 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -175,6 +175,26 @@ struct omap_hwmod_class omap2xxx_mcspi_class = {
};
/*
+ * 'gpmc' class
+ * general purpose memory controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2xxx_gpmc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2xxx_gpmc_hwmod_class = {
+ .name = gpmc,
+ .sysc = omap2xxx_gpmc_sysc,
+};
+
+/*
* IP blocks
*/
@@ -732,3 +752,30 @@ struct omap_hwmod omap2xxx_mcspi2_hwmod = {
.class = omap2xxx_mcspi_class,
.dev_attr = omap_mcspi2_dev_attr,
};
+
+/* gpmc */
+static struct omap_hwmod_irq_info omap2xxx_gpmc_irqs[] = {
+ { .irq = 20 },
+ { .irq = -1 }
+};
+
+struct omap_hwmod omap2xxx_gpmc_hwmod = {
+ .name = gpmc,
+ .class = omap2xxx_gpmc_hwmod_class,
+ .mpu_irqs = omap2xxx_gpmc_irqs,
+ .main_clk = gpmc_fck,
+ /* HWMOD_INIT_NO_RESET can be removed once kernel is updated
+* to configure GPMC for all peripherals, right now many
+* peripherals depend on bootloader configuration, removing
+* this flag would break GPMC on
RE: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Hi Paul,
On Mon, May 07, 2012 at 16:42:16, Mohammed, Afzal wrote:
+static struct omap_hwmod omap3xxx_gpmc_hwmod = {
+ .name = gpmc,
+ .class = omap3xxx_gpmc_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap3xxx_gpmc_irqs,
+ .main_clk = gpmc_fck,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+};
Is there some reason why you are setting the HWMOD_INIT_NO_RESET flag
here? Seems to me that the kernel should not rely on the bootloader GPMC
configuration, but should use a configuration from the board file or DT.
Major reason was that there are some boards that rely on bootloader
settings, eg. kernel does not do any setting for smsc911x. I did not
want to break those, at least it causes problem with omap3evm
If HWMOD_NO_INIT_RESET is not present, it would break GPMC on
many of the existing boards.
New version of GPMC HWMOD patch has been posted with HWMOD_NO_IDLEST flag,
which is a squashed one with OMAP2xxx HWMOD
Regards
AFzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
On Tue, May 8, 2012 at 2:37 PM, Cousson, Benoit b-cous...@ti.com wrote: Salut Jean, On 5/8/2012 1:23 PM, Jean Pihet wrote: Hi Benoit, On Tue, May 8, 2012 at 1:01 PM, Cousson, Benoitb-cous...@ti.com wrote: Hi Kevin Jon, On 5/8/2012 1:28 AM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Kevin, On 05/07/2012 12:15 PM, Kevin Hilman wrote: Jon Hunterjon-hun...@ti.com writes: Hi Will, On 04/26/2012 01:07 PM, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: Part of the problem is that the clockdomain data for the emu_sys clockdomain is wrong. Here's something to try to fix it. It might just be enough to get it to work. Hmm, doesn't seem to work but I do see the following in dmesg when I try to use perf: powerdomain: waited too long for powerdomain emu_pwrdm to complete transition which is new with your patch. Sorry to nag, but does anybody have a clue where to go from here? I can start digging in the OMAP PM code, but it's all new territory for me. I did a little playing around with this today and I think that I have figured out why this was not working (see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list. Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot is running it is in the transitioning state. So even before the kernel starts. Cheers Jon From 9137ff9c1b382232de7443db0b51b7555846fb62 Mon Sep 17 00:00:00 2001 From: Jon Hunterjon-hun...@ti.com Date: Fri, 4 May 2012 16:48:45 -0500 Subject: [PATCH] ARM: OMAP4: Disable auto enable for EMU CLKDM The flag CLKDM_CAN_HWSUP allows the clock-domain to automatically transition to the enabled and disabled state. This means that as soon as we force a software wake-up on the clock domain, the clock domain will be allowed to idle and put back into the hardware auto state. For the EMU clock domain this is not what we want. We want to keep the clock domain in the software wakeup state while the clock domain is being used and put it back in to the hardware auto state when we have finished using the clock domain. Signed-off-by: Jon Hunterjon-hun...@ti.com With this patch, how is the clkdm ever idled? It does not! Sorry, I was so engrossed with figuring out why the EMU clkdm was being idled as soon as it was enabled, I forgot to check if is ever disabled once we terminated perf :-( IIUC, your patch will get PMU interrupts working, but similarily to previous patches in this thread, it works because it *never* allows the EMU clkdm to idle. This is not a mergeable solution because it will not allow CORE retention (and thus full-chip retention.) Right! What we need is a solution that allows the clkdm to idle, and then to be reinitialzed when it wakes up. Due to the way (I understand) resets in the debugss, allowing the clkdm to idle will cause a reset, so the PMU/CTI interrupts need to be reinitialzied after wakeup. Yes exactly I see that now. I have prototyped the 3 patches and this is working AND the EMU clkdm does go back to idle. I can send out to the list for review. Perfect, thanks. Kevin P.S. Please note there is also already a different fix in mainline for the EMU clkdm data from Paul which adds the force wakeup flag and removes the DISABLE_AUTO flag[1] (but leaves the ENABLE_AUTO flag, because the hardware is capable.) Hmmm ... yes saw this, and you will have to excuse me as I don't fully follow the logic here. In fact, I am thinking we want the opposite ;-) From looking, into this it seems to me that when PMU is running we want the EMU clock domain in software-wakeup state and when PMU is not running we want in the hardware auto state. So far, I'm with you. By keeping the ENABLE_AUTO flag set, as soon as we enable the clock domain it is put right back into the HW_AUTO state This is only because it was in the HWSUP state when _enable was called. If clkdm_deny_idle() is used, that behavior will change. and hence PMU is not working (see _enable() function in arch/arm/mach-omap2/omap_hwmod.c) So really what I think we want is to remove the ENABLE_AUTO flag to keep the clock domain in software wake-up and use the DISABLE_AUTO flag to put the clock domain back in HW_AUTO (note this requires a patch to perform this 2nd part). Well, Paul will have to comment here for the final word, but IIUC, the hwmod flags are supposed to indicate only what the HW is capable of. If we want to change the runtime behavior, we nee to use (or add) APIs to change the
Re: usb: Warnings with the make randconfig make
On Tue, May 08, 2012 at 04:19:46PM +0600, joseph daniel wrote: Hi all, I am getting the following warnings while compiling the 3.4-rc6 kernel with the .config attached. warning: (MOUSE_APPLETOUCH MOUSE_BCM5974 MOUSE_SYNAPTICS_USB JOYSTICK_XPAD TABLET_USB_ACECAD TABLET_USB_AIPTEK TABLET_USB_HANWANG TABLET_USB_KBTAB TABLET_USB_WACOM TOUCHSCREEN_USB_COMPOSITE INPUT_ATI_REMOTE2 INPUT_KEYSPAN_REMOTE INPUT_POWERMATE INPUT_YEALINK INPUT_CM109 RC_ATI_REMOTE IR_IMON IR_MCEUSB IR_REDRAT3 IR_STREAMZAP DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT USB_ARCH_HAS_HCD) This is a known problem, patches gladly accepted to try to resolve it (hint, it's due to DRM_USB) good luck, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)
On Fri, 2012-05-04 at 17:58 +0300, Tomi Valkeinen wrote: On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote: Hi Kevin, Paul, On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote: Ok, I can replicate it now. It seems to be somehow PM related. I normally have USB gadget stuff compiled into kernel so that I can boot via nfsroot with usb. After disabling USB support from the kernel, I can see synclosts. I have no idea yet what could be causing this. I've also tried adding the couple of DSS patches which are in queue for next merge window, that force OPP100 when DSS is enabled. They don't seem to help. Also, at least on my setup, the sync lost doesn't happen very quickly after starting the video output, but (I think) only when the system starts to idle. My init scripts generate keys for sshd and some other stuff, and no sync lost there, only just before the shell prompt do I get a sync lost. Tomi That sounds like the same as I'm seeing. It seems that the sync lost jumps around a bit, from almost immediately (when the graphics are enabled), to up to 3 or 4 seconds later (still just before the shell prompt). I'm assuming that setting the FIFO low and high points fixes your sync losts as well (as in the first patch you sent)? I've also noted that doing things in different orders can sometimes fix the sync lost (such as disabling or enabling DVI output), but this all seems a bit random. I'm just glad someone else has been able to replicate the problem :p Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on omap3, causing DSS losing sync. I didn't notice this earlier as I have USB gadget compiled into my kernel. Removing USB support from the kernel causes the problem to appear, which more or less hints at a PM related issue. Sorry, not sync lost, but FIFO underflow. So DSS is unable to fetch enough pixels to update the panel. And in this case the pixel clock is very low (small panel), so it's nowhere near any limit. And two more interesting points about the problem: Setting DISPC's SIDLEMODE to no-idle seems to remove the issue. With some DISPC's fifo high/low threshold values things seem to work, while with others we get underflows. And as the required bandwidth here is quite small, and the threshold values I tested are close to each other, I don't think it's really a proper bandwidth issue. I'm guessing that certain threshold values cause somehow un-optimal accesses to the memory, and with smart-idle this somehow causes problems. Archit, you looked into the thresholds some time ago. I recall that some threshold values were bad in some way? Were those only for OMAP4? Tomi signature.asc Description: This is a digitally signed message part
OMAP3 EVM kernel
I'm attempting to build a linux kernel (3.4-rc4) for the AM/DM37x Evaluation Module. I built my own cross tools using CrossTools-ng (gcc4.4.3, glibc2.9, binutils2.21.1a). I am using the bootloader that came on the board and booting from the mmc card. Below is the output I get at startup. Should I be attempting this from the tmlind git tree instead of stable? Could someone send me a .config file from a known working kernel? I am dreadfully ignorant about ARM processors, having spent the last 12 years as a PPC guy. I now have this ARM eval kit sitting on my desk that I really need to get working in short order. :) Thanks, --Mike output Texas Instruments X-Loader 1.46 (Aug 16 2010 - 08:13:53) Starting X-loader on MMC Reading boot sector 212880 Bytes Read from MMC Starting OS Bootloader from MMC... Starting OS Bootloader... U-Boot 2009.11 (Aug 16 2010 - 09:35:30) AM37x/DM37x-GP ES2.1, CPU-OPP2 L3-165MHz OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MB NAND: 512 MiB In:serial Out: serial Err: serial Read back SMSC id 0x9220 Die ID #1f6800029ff8015f26ad0f022014 Net: smc911x-0 Hit any key to stop autoboot: 0 mmc1 is available reading boot.scr 307 bytes read Running bootscript from mmc ... ## Executing script at 8200 reading uImage 3944336 bytes read ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.4.0-rc2+ Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3944272 Bytes = 3.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. /output -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 boot failure
Paul Walmsley p...@pwsan.com writes: On Thu, 19 Apr 2012, Igor Grinberg wrote: IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Just tested this on a 3517EVM and the same problem is there too. Does adding nohlt on the cmdline make a difference? The AM35x has known wakeup limitations, and nohlt would at least avoid WFI to see if it's the wakeup problems that are the root cause here. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP1: fix compilation issue in board-sx1.c
From: Artem Bityutskiy artem.bityuts...@linux.intel.com SX1 board requirese i2c, so select it in Kconfig, otherwise I have the following build error: arch/arm/mach-omap1/board-sx1.c: In function 'sx1_i2c_write_byte': arch/arm/mach-omap1/board-sx1.c:58:2: error: implicit declaration of function 'i2c_get_adapter' [-Werror=implicit-function-declaration] arch/arm/mach-omap1/board-sx1.c:58:7: warning: assignment makes pointer from integer without a cast [enabled by default] arch/arm/mach-omap1/board-sx1.c:67:2: error: implicit declaration of function 'i2c_transfer' [-Werror=implicit-function-declaration] arch/arm/mach-omap1/board-sx1.c:68:2: error: implicit declaration of function 'i2c_put_adapter' [-Werror=implicit-function-declaration] arch/arm/mach-omap1/board-sx1.c: In function 'sx1_i2c_read_byte': arch/arm/mach-omap1/board-sx1.c:82:7: warning: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors make[1]: *** [arch/arm/mach-omap1/board-sx1.o] Error 1 make: *** [arch/arm/mach-omap1] Error 2 make: *** Waiting for unfinished jobs Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com --- arch/arm/mach-omap1/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index dfab466..cba3f71 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -132,6 +132,7 @@ config MACH_OMAP_PALMTT config MACH_SX1 bool Siemens SX1 + select I2C depends on ARCH_OMAP1 ARCH_OMAP15XX help Support for the Siemens SX1 phone. To boot the kernel, -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Jean Pihet jean.pi...@newoldbits.com writes: [...] Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. That being said, being able to transition to OFF during idle is a perfectly valid state for most powerdomain in OMAP anyway, so we should be able to restore from OFF mode smoothly. It looks to me that what is missing here is *just* a restore path in the PMU/CTI code. But I'm probably missing some nasty details in this issue :-) Although it is perfectly feasible to have a seamless transition of the EMU power domain, I think the PMU counters will not be accurate anymore since they stop counting events when going to OFF and re-start after the state restore. Good point, but I think the PMU might still works fine because located inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is going to OFF and thus will be reset. Ever better point ;p Thanks for the precision. In any case my point was: can we allow the EMU CD to go OFF or prevent it from doing so? We need to answer that question first. The idea I've suggested is to use runtime PM for this. As long as the PMU is in use, it will be runtime PM enabled (and not allowed to go into HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and then be reset. The next time it is needed, the runtime resume will need to do a full re-init. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Tue, May 8, 2012 at 6:11 PM, Catalin Marinas catalin.mari...@arm.com wrote: On Mon, May 07, 2012 at 02:42:29PM +0100, Santosh Shilimkar wrote: From: R Sricharan r.sricha...@ti.com ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered. But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager. This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5. This patch tries to fix the issue by ensuring that non-DRAM region is marked as a client domain so that XN attribute is effective. A better alternative is to not map un-used regions but since the decompressor code is generic, there might be many exceptions for the devices used like debug console etc. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm/boot/compressed/head.S | 7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..4dc799b 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -578,7 +578,7 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size mov r9, r0, lsr #18 mov r9, r9, lsl #18 @ start of RAM add r10, r9, #0x1000 @ a reasonable RAM size - mov r1, #0x12 + mov r1, #0x32 @ set domain1, XN, valid orr r1, r1, #3 10 add r2, r3, #16384 1: cmp r1, r9 @ if virt start of RAM @@ -587,8 +587,10 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size #else orrhs r1, r1, #0x0c @ set cacheable, bufferable #endif + bichs r1, r1, #0x20 @ set domain0 for DRAM cmp r1, r10 @ if virt end of RAM bichs r1, r1, #0x0c @ clear cacheable, bufferable + orrhs r1, r1, #0x20 @ set domain1 I would leave the same domain (0, set as client) and rather change the XN and cacheability bits once we finished with the DRAM. I think it's cleaner assuming we have two domains and the manager one overrides the XN bit. Ok. Assuming you mean it's _not_ cleaner to have two domains where manager overrides XN attributes Note that DRAM can be in the middle of 4GB address space, so we need to take care of bottom and top address space. Update patch end of the email. Is that fine with you ? Regards Santosh From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001 From: R Sricharan r.sricha...@ti.com Date: Mon, 7 May 2012 15:11:58 +0530 Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space. ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered. But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager. This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5. This patch tries to fix the issue by ensuring that all regions are marked as a client domain so that XN attribute is effective. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm/boot/compressed/head.S | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..a2602b8 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -578,10 +578,12 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size mov r9, r0, lsr #18 mov r9, r9, lsl #18 @ start of RAM add r10, r9, #0x1000@ a reasonable RAM size - mov r1, #0x12 + mov r1, #0x02 @ Default executable section orr r1, r1, #3 10 add r2, r3, #16384 1: cmp
Re: oprofile and ARM A9 hardware counter
On 5/8/2012 4:00 PM, Kevin Hilman wrote: Jean Pihetjean.pi...@newoldbits.com writes: [...] Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. That being said, being able to transition to OFF during idle is a perfectly valid state for most powerdomain in OMAP anyway, so we should be able to restore from OFF mode smoothly. It looks to me that what is missing here is *just* a restore path in the PMU/CTI code. But I'm probably missing some nasty details in this issue :-) Although it is perfectly feasible to have a seamless transition of the EMU power domain, I think the PMU counters will not be accurate anymore since they stop counting events when going to OFF and re-start after the state restore. Good point, but I think the PMU might still works fine because located inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is going to OFF and thus will be reset. Ever better point ;p Thanks for the precision. In any case my point was: can we allow the EMU CD to go OFF or prevent it from doing so? We need to answer that question first. The idea I've suggested is to use runtime PM for this. As long as the PMU is in use, it will be runtime PM enabled (and not allowed to go into HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and then be reset. The next time it is needed, the runtime resume will need to do a full re-init. Oh, but does that mean that this driver is not pm_runtime adapted yet? Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote: From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001 From: R Sricharan r.sricha...@ti.com Date: Mon, 7 May 2012 15:11:58 +0530 Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space. ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered. But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager. This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5. This patch tries to fix the issue by ensuring that all regions are marked as a client domain so that XN attribute is effective. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm/boot/compressed/head.S | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..a2602b8 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -578,10 +578,12 @@ __setup_mmu:sub r3, r4, #16384 @ Page directory size mov r9, r0, lsr #18 mov r9, r9, lsl #18 @ start of RAM add r10, r9, #0x1000@ a reasonable RAM size - mov r1, #0x12 + mov r1, #0x02 @ Default executable section I think it is simpler if you leave the original code here (with XN) orr r1, r1, #3 10 add r2, r3, #16384 1: cmp r1, r9 @ if virt start of RAM + orrlo r1, r1, #0x10 @ Mark XN for non DRAM + bichs r1, r1, #0x10 @ clear XN for DRAM and just do the bichs above. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: irq: Increase no of supported interrupts to 128
With addition to TI81XX, AM33XX family of devices, the number
of interrupts supported has increased to 128, compared to 96.
The current implementation for irq handling is hardcoded to use
96 interrupts (with 3 register-sets to handle), this patch cleanups
the code, to increase maximum number of interrupts support
to 128, with dynamic detection of no of registers required for
handling all interrupts.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
Ideally, we should use dynamic allocation to allocate memory
for registers/arrays, may be too much cleanup for this patch,
so as of now restricting to minimal changes to fit devices
like, am33xx/ti81xx.
arch/arm/mach-omap2/irq.c | 47 +++
arch/arm/plat-omap/include/plat/irqs.h |7 +++-
2 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 80f3ced..ea5aed9 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -58,10 +58,12 @@
static struct omap_irq_bank {
void __iomem *base_reg;
unsigned int nr_irqs;
+ unsigned int nr_regs_req;
} __attribute__ ((aligned(4))) irq_banks[] = {
{
/* MPU INTC */
.nr_irqs= 96,
+ .nr_regs_req= 3,
},
};
@@ -73,8 +75,8 @@ struct omap3_intc_regs {
u32 protection;
u32 idle;
u32 threshold;
- u32 ilr[INTCPS_NR_IRQS];
- u32 mir[INTCPS_NR_MIR_REGS];
+ u32 ilr[INTCPS_MAX_NR_IRQS];
+ u32 mir[INTCPS_MAX_NR_REGS_REQ];
};
/* INTC bank register get/set */
@@ -182,6 +184,7 @@ static void __init omap_init_irq(u32 base, int nr_irqs,
struct omap_irq_bank *bank = irq_banks + i;
bank-nr_irqs = nr_irqs;
+ bank-nr_regs_req = 0;
/* Static mapping, never released */
bank-base_reg = ioremap(base, SZ_4K);
@@ -192,8 +195,10 @@ static void __init omap_init_irq(u32 base, int nr_irqs,
omap_irq_bank_init_one(bank);
- for (j = 0; j bank-nr_irqs; j += 32)
+ for (j = 0; j bank-nr_irqs; j += 32) {
omap_alloc_gc(bank-base_reg + j, j + irq_base, 32);
+ bank-nr_regs_req++;
+ }
nr_of_irqs += bank-nr_irqs;
nr_banks++;
@@ -218,25 +223,19 @@ void __init ti81xx_init_irq(void)
omap_init_irq(OMAP34XX_IC_BASE, 128, NULL);
}
-static inline void omap_intc_handle_irq(void __iomem *base_addr, struct
pt_regs *regs)
+static inline void omap_intc_handle_irq(void __iomem *base_addr,
+ unsigned int no_regs_req, struct pt_regs *regs)
{
- u32 irqnr;
+ u32 irqnr = 0;
do {
- irqnr = readl_relaxed(base_addr + 0x98);
- if (irqnr)
- goto out;
-
- irqnr = readl_relaxed(base_addr + 0xb8);
- if (irqnr)
- goto out;
+ int i = 0;
- irqnr = readl_relaxed(base_addr + 0xd8);
-#ifdef CONFIG_SOC_OMAPTI816X
- if (irqnr)
- goto out;
- irqnr = readl_relaxed(base_addr + 0xf8);
-#endif
+ for (i = 0; i no_regs_req; i++) {
+ irqnr = readl_relaxed(base_addr + 0x98 + (0x20 * i));
+ if (irqnr)
+ goto out;
+ }
out:
if (!irqnr)
@@ -255,7 +254,7 @@ out:
asmlinkage void __exception_irq_entry omap2_intc_handle_irq(struct pt_regs
*regs)
{
void __iomem *base_addr = OMAP2_IRQ_BASE;
- omap_intc_handle_irq(base_addr, regs);
+ omap_intc_handle_irq(base_addr, irq_banks[0].nr_regs_req, regs);
}
int __init omap_intc_of_init(struct device_node *node,
@@ -296,10 +295,10 @@ void omap_intc_save_context(void)
intc_bank_read_reg(bank, INTC_IDLE);
intc_context[ind].threshold =
intc_bank_read_reg(bank, INTC_THRESHOLD);
- for (i = 0; i INTCPS_NR_IRQS; i++)
+ for (i = 0; i bank-nr_irqs; i++)
intc_context[ind].ilr[i] =
intc_bank_read_reg(bank, (0x100 + 0x4*i));
- for (i = 0; i INTCPS_NR_MIR_REGS; i++)
+ for (i = 0; i bank-nr_regs_req; i++)
intc_context[ind].mir[i] =
intc_bank_read_reg(irq_banks[0], INTC_MIR0 +
(0x20 * i));
@@ -322,10 +321,10 @@ void omap_intc_restore_context(void)
bank, INTC_IDLE);
intc_bank_write_reg(intc_context[ind].threshold,
bank, INTC_THRESHOLD);
-
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Tuesday 08 May 2012 07:46 PM, Catalin Marinas wrote: On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote: From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001 From: R Sricharan r.sricha...@ti.com Date: Mon, 7 May 2012 15:11:58 +0530 Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space. ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered. But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager. This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5. This patch tries to fix the issue by ensuring that all regions are marked as a client domain so that XN attribute is effective. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm/boot/compressed/head.S | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..a2602b8 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -578,10 +578,12 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size mov r9, r0, lsr #18 mov r9, r9, lsl #18 @ start of RAM add r10, r9, #0x1000@ a reasonable RAM size -mov r1, #0x12 +mov r1, #0x02 @ Default executable section I think it is simpler if you leave the original code here (with XN) Sounds good. With that updated can I add your ack and push it to the patch system ? Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space.
On Tue, May 08, 2012 at 03:20:43PM +0100, Santosh Shilimkar wrote: On Tuesday 08 May 2012 07:46 PM, Catalin Marinas wrote: On Tue, May 08, 2012 at 03:01:57PM +0100, Shilimkar, Santosh wrote: From b906ef372f0e2dfa7e1fbc3c87406b1c303d8975 Mon Sep 17 00:00:00 2001 From: R Sricharan r.sricha...@ti.com Date: Mon, 7 May 2012 15:11:58 +0530 Subject: [PATCH] ARM: decompressor: Fix mmu mapping for non-DRAM address space. ARM decompressor code setups entire 4GB address space pages. Out of the 4GB, about 256MB are setup with normal memory attributes for needed DRAM and the rest of the address space as Strongly ordered. But since all the sections are mapped in DOMAIN0(Manager), processor like Cortex-A15, can speculatively prefetch from non-DRAM read sensitive areas even in the presence of XN(Non-executable). This is because XN attribute is ignored when domain is Manager. This can lead to accesses to non-accessible address regions leading to various interconnect violations. The issue is observed on OMAP5. This patch tries to fix the issue by ensuring that all regions are marked as a client domain so that XN attribute is effective. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Catalin Marinas catalin.mari...@arm.com --- arch/arm/boot/compressed/head.S | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index dc7e8ce..a2602b8 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -578,10 +578,12 @@ __setup_mmu: sub r3, r4, #16384 @ Page directory size mov r9, r0, lsr #18 mov r9, r9, lsl #18 @ start of RAM add r10, r9, #0x1000@ a reasonable RAM size - mov r1, #0x12 + mov r1, #0x02 @ Default executable section I think it is simpler if you leave the original code here (with XN) Sounds good. With that updated can I add your ack Yes. and push it to the patch system ? That's up to Russell. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: OMAP2+: Cleanup series in order to remove ARCH_OMAPx dependency
In current implementation, some places we are still using ARCH_OMAPx config option, making it difficult to add new devices; for example, while adding am33xx device support I came across multiple instances where I had to patch the existing code to make it work for am33xx. This patch tries to cleanup existing code for some of the ARCH_OMAP2/3/4 dependency on the code. NOTE: Patch series has been boot tested on omap3evm and build tested for all possible combination of OMAP2, 3, 4 configurations. Vaibhav Hiremath (4): ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features arch/arm/mach-omap2/Kconfig | 42 +++ arch/arm/mach-omap2/clock.c | 18 - arch/arm/mach-omap2/common.c|8 +- arch/arm/mach-omap2/common.h|5 +++ arch/arm/mach-omap2/dpll3xxx.c | 14 ++ arch/arm/plat-omap/Makefile |4 +-- arch/arm/plat-omap/include/plat/clock.h | 14 -- 7 files changed, 74 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry
All OMAP2PLUS based devices, builds omap-device.o target; so just add one entry so that there is no need to patch this file for any future OMAP2+ devices. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/plat-omap/Makefile |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index ed8605f..c5b5f05 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -10,9 +10,7 @@ obj-n := obj- := # omap_device support (OMAP2+ only at the moment) -obj-$(CONFIG_ARCH_OMAP2) += omap_device.o -obj-$(CONFIG_ARCH_OMAP3) += omap_device.o -obj-$(CONFIG_ARCH_OMAP4) += omap_device.o +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_device.o obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
In order to remove unnecessary idefs, move noncore and core
dpll ops to dpll3xxx.c file (where it should have been already).
The clkops (clkops_omap3_core_dpll_ops clkops_omap3_noncore_dpll_ops)
is used in clock data files, and dependency is already handled by Makefile
rule.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock.c| 18 --
arch/arm/mach-omap2/dpll3xxx.c | 14 ++
2 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index d9f4931..950a446 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -398,24 +398,6 @@ int omap2_clk_set_parent(struct clk *clk, struct clk
*new_parent)
return omap2_clksel_set_parent(clk, new_parent);
}
-/* OMAP3/4 non-CORE DPLL clkops */
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-
-const struct clkops clkops_omap3_noncore_dpll_ops = {
- .enable = omap3_noncore_dpll_enable,
- .disable= omap3_noncore_dpll_disable,
- .allow_idle = omap3_dpll_allow_idle,
- .deny_idle = omap3_dpll_deny_idle,
-};
-
-const struct clkops clkops_omap3_core_dpll_ops = {
- .allow_idle = omap3_dpll_allow_idle,
- .deny_idle = omap3_dpll_deny_idle,
-};
-
-#endif
-
/*
* OMAP2+ clock reset and init functions
*/
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index fc56745..d15f2a2 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -615,3 +615,17 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
rate = clk-parent-rate * 2;
return rate;
}
+
+/* OMAP3/4 non-CORE DPLL clkops */
+
+const struct clkops clkops_omap3_noncore_dpll_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .allow_idle = omap3_dpll_allow_idle,
+ .deny_idle = omap3_dpll_deny_idle,
+};
+
+const struct clkops clkops_omap3_core_dpll_ops = {
+ .allow_idle = omap3_dpll_allow_idle,
+ .deny_idle = omap3_dpll_deny_idle,
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions as in __omap2_set_globals() function
(except for sdrc).
This patch adds new config flag SOC_HAS_SDRC to handle sdrc,
so that we can reuse same function across omap2/3/4...
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Kconfig |8
arch/arm/mach-omap2/common.c |8 +---
arch/arm/mach-omap2/common.h |5 +
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 0685dc8..2277359 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -20,12 +20,16 @@ config ARCH_OMAP2PLUS_TYPICAL
help
Compile a kernel suitable for booting most boards
+config SOC_HAS_SDRC
+ bool SDRAM Controller support
+
config ARCH_OMAP2
bool TI OMAP2
depends on ARCH_OMAP2PLUS
default y
select CPU_V6
select MULTI_IRQ_HANDLER
+ select SOC_HAS_SDRC
config ARCH_OMAP3
bool TI OMAP3
@@ -37,6 +41,7 @@ config ARCH_OMAP3
select PM_OPP if PM
select ARM_CPU_SUSPEND if PM
select MULTI_IRQ_HANDLER
+ select SOC_HAS_SDRC
config ARCH_OMAP4
bool TI OMAP4
@@ -64,18 +69,21 @@ config SOC_OMAP2420
default y
select OMAP_DM_TIMER
select ARCH_OMAP_OTG
+ select SOC_HAS_SDRC
config SOC_OMAP2430
bool OMAP2430 support
depends on ARCH_OMAP2
default y
select ARCH_OMAP_OTG
+ select SOC_HAS_SDRC
config SOC_OMAP3430
bool OMAP3430 support
depends on ARCH_OMAP3
default y
select ARCH_OMAP_OTG
+ select SOC_HAS_SDRC
config SOC_OMAPTI81XX
bool TI81XX support
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 1549c11..ad8626d 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -29,8 +29,6 @@
/* Global address base setup code */
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
-
static void __init __omap2_set_globals(struct omap_globals *omap2_globals)
{
omap2_set_globals_tap(omap2_globals);
@@ -39,8 +37,6 @@ static void __init __omap2_set_globals(struct omap_globals
*omap2_globals)
omap2_set_globals_prcm(omap2_globals);
}
-#endif
-
#if defined(CONFIG_SOC_OMAP2420)
static struct omap_globals omap242x_globals = {
@@ -170,9 +166,7 @@ static struct omap_globals omap4_globals = {
void __init omap2_set_globals_443x(void)
{
- omap2_set_globals_tap(omap4_globals);
- omap2_set_globals_control(omap4_globals);
- omap2_set_globals_prcm(omap4_globals);
+ __omap2_set_globals(omap4_globals);
}
void __init omap4_map_io(void)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 0e95efc..70dee99 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -122,7 +122,12 @@ void omap2_set_globals_am33xx(void);
/* These get called from omap2_set_globals_(), do not call these */
void omap2_set_globals_tap(struct omap_globals *);
+#if defined(CONFIG_SOC_HAS_SDRC)
void omap2_set_globals_sdrc(struct omap_globals *);
+#else
+static inline void omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
+{ }
+#endif
void omap2_set_globals_control(struct omap_globals *);
void omap2_set_globals_prcm(struct omap_globals *);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
This patch cleans up dpll_data structure, making structure
fields definition based on feature availability for given SoC,
managed using Kconfig rules.
SOC_HAS_DPLL_IDLE: idle state
SOC_HAS_DPLL_RECAL: recalibration capability
SOC_HAS_DPLL_DCO_SEL: dco selection
SOC_HAS_DPLL_SDDIV: sigma-delta div factor
SOC_HAS_DPLL_FREQSEL: frequency selection
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Kconfig | 34 +++
arch/arm/plat-omap/include/plat/clock.h | 14 ++--
2 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2277359..93bf5e2 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -20,6 +20,21 @@ config ARCH_OMAP2PLUS_TYPICAL
help
Compile a kernel suitable for booting most boards
+config SOC_HAS_DPLL_IDLE
+ bool DPLL idle state support
+
+config SOC_HAS_DPLL_RECAL
+ bool DPLL Recalibration support
+
+config SOC_HAS_DPLL_DCO_SEL
+ bool DPLL DCO (Digitally Controlled Oscilators) support
+
+config SOC_HAS_DPLL_SDDIV
+ bool DPLL Sigma-Delta Divider support
+
+config SOC_HAS_DPLL_FREQSEL
+ bool DPLL Freq Select support
+
config SOC_HAS_SDRC
bool SDRAM Controller support
@@ -42,6 +57,11 @@ config ARCH_OMAP3
select ARM_CPU_SUSPEND if PM
select MULTI_IRQ_HANDLER
select SOC_HAS_SDRC
+ select SOC_HAS_DPLL_IDLE
+ select SOC_HAS_DPLL_RECAL
+ select SOC_HAS_DPLL_DCO_SEL
+ select SOC_HAS_DPLL_SDDIV
+ select SOC_HAS_DPLL_FREQSEL
config ARCH_OMAP4
bool TI OMAP4
@@ -59,6 +79,9 @@ config ARCH_OMAP4
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
+ select SOC_HAS_DPLL_IDLE
+ select SOC_HAS_DPLL_RECAL
+ select SOC_HAS_DPLL_SDDIV
comment OMAP Core Type
depends on ARCH_OMAP2
@@ -84,16 +107,27 @@ config SOC_OMAP3430
default y
select ARCH_OMAP_OTG
select SOC_HAS_SDRC
+ select SOC_HAS_DPLL_IDLE
+ select SOC_HAS_DPLL_RECAL
+ select SOC_HAS_DPLL_DCO_SEL
+ select SOC_HAS_DPLL_SDDIV
+ select SOC_HAS_DPLL_FREQSEL
config SOC_OMAPTI81XX
bool TI81XX support
depends on ARCH_OMAP3
default y
+ select SOC_HAS_DPLL_IDLE
+ select SOC_HAS_DPLL_RECAL
+ select SOC_HAS_DPLL_SDDIV
config SOC_OMAPAM33XX
bool AM33XX support
depends on ARCH_OMAP3
default y
+ select SOC_HAS_DPLL_IDLE
+ select SOC_HAS_DPLL_RECAL
+ select SOC_HAS_DPLL_SDDIV
config OMAP_PACKAGE_ZAF
bool
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index d0ef57c..aa81c04 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -156,18 +156,26 @@ struct dpll_data {
u8 min_divider;
u16 max_divider;
u8 modes;
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
+#if defined(CONFIG_SOC_HAS_DPLL_IDLE)
void __iomem*autoidle_reg;
void __iomem*idlest_reg;
u32 autoidle_mask;
- u32 freqsel_mask;
u32 idlest_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_DPLL_FREQSEL)
+ u32 freqsel_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_DPLL_DCO_SEL)
u32 dco_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_DPLL_SDDIV)
u32 sddiv_mask;
+#endif
+#if defined(CONFIG_SOC_HAS_DPLL_RECAL)
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
-# endif
+#endif
u8 flags;
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 01/39] ARM: OMAP2+: gpmc: driver conversion
Hi Afzal,
On 05/08/2012 01:18 AM, Mohammed, Afzal wrote:
Hi Jon,
On Mon, May 07, 2012 at 21:32:58, Hunter, Jon wrote:
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, multiple waitpins selected on CS:%u\n, cs);
+ return -EINVAL;
+ break;
+ }
Why not combined case 0 and default? Both are invalid configurations so
just report invalid selection.
Case 0 is not invalid, a case where waitpin is not used, default refers
to when a user selects multiple waitpins wrongly.
Ok. Then for case 0, just return here. If the polarity is set, you could
print an error here.
Different ways of doing things, this looks cleaner to me as already it is
checked, and time of execution in both cases would not differ much.
Sure. However, I think that this could be simplified so that it is
easier to read. At a minimum you may wish to add some comments to
explain the purposes of the multi-level if-statements as it is not
intuitive for the reader.
+ if (gd-have_waitpin) {
+ if (gd-waitpin != idx ||
+ gd-waitpin_polarity != polarity) {
+ dev_err(gpmc-dev, error: conflict: waitpin %u
with polarity %d on device %s.%d\n,
+ gd-waitpin, gd-waitpin_polarity,
+ gd-name, gd-id);
+ return -EBUSY;
+ }
+ } else {
Don't need the else as you are going to return in the above.
Not always, only in case of error
Ok, but seems that it can be simplified a little.
What happens if a device uses more than one wait-pin? In other words a
device with two chip-selects that uses two wait-pins?
Please re-read
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67702.html
and your reply
Ok thats fine. Sorry for my repeated questions, but I think that this
just highlights that this code is not clear in it purpose. So again may
be some comments would make this all clearer.
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 02/39] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Afzal, On 05/08/2012 01:24 AM, Mohammed, Afzal wrote: Hi Jon, On Mon, May 07, 2012 at 21:42:35, Hunter, Jon wrote: Clk_prd is a platform data passed to the driver, so platform code updates it, where else can it be done ? The point is that you can pass what ever you like. You do not need to pass the frequency you can pass the clock handle instead. As clk rate is required in platform code for timing calculation, and already available, period was passed Sure. What happens it the clk_get() of the gpmc_l3_clk fails during the init? Thanks for bringing this point, invalid clk_prd has to be handled by driver. In fact if you migrate to runtime pm then we should not have the clk_get in the gpmc_init any more. Even if converted to RPM, to get clk rate, clk_get has to be done somewhere, right ? Yes exactly. However, you could now do this in the driver itself like the probe function. Or may be just pass the frequency of the gpmc fclk to the driver and let the driver convert to the period. No reason we need to convert to the period outside of the driver. Hence, we can keep the function to do the conversion static in the driver and don't need to expose externally. Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: am33xx: Make am33xx as a separate class
Initially, we decided to make am33xx family of device to fall
under omap3 class (cpu_is_omap34xx() = true), since it carries
Cortex-A8 core. But while adding complete baseport support
(like, clock, power and hwmod) support, it is observed that,
we are creating more and more problems by treating am33xx device
as omap3 family, as nothing matches between them
(except cortex-A8 mpu).
So, after long discussion we have came to the conclusion that,
we should not consider am33xx device as omap3 family, instead
create separate class (SOC_OMAPAM33XX) under OMAP2PLUS.
This means, for am33xx device, cpu_is_omap34xx() will return false,
and only cpu_is_am33xx() will be true.
Please refer to the link below, for mailing-list discussion on this -
http://www.spinics.net/lists/linux-omap/msg69439.html
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Kconfig |5 -
arch/arm/mach-omap2/Makefile |6 ++
arch/arm/mach-omap2/common.c |2 ++
arch/arm/plat-omap/include/plat/cpu.h |9 ++---
arch/arm/plat-omap/sram.c |2 +-
5 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 93bf5e2..182aa0c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -123,8 +123,11 @@ config SOC_OMAPTI81XX
config SOC_OMAPAM33XX
bool AM33XX support
- depends on ARCH_OMAP3
+ depends on ARCH_OMAP2PLUS
default y
+ select CPU_V7
+ select ARM_CPU_SUSPEND if PM
+ select MULTI_IRQ_HANDLER
select SOC_HAS_DPLL_IDLE
select SOC_HAS_DPLL_RECAL
select SOC_HAS_DPLL_SDDIV
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d8604a3..94a5982 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -16,6 +16,7 @@ secure-common = omap-smc.o
omap-secure.o
obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common)
obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common)
obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common)
+obj-$(CONFIG_SOC_OMAPAM33XX) += irq.o $(hwmod-common)
ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),)
obj-y += mcbsp.o
@@ -93,6 +94,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o
cminst44xx.o \
cm44xx.o prcm_mpu44xx.o \
prminst44xx.o vc44xx_data.o \
vp44xx_data.o prm44xx.o
+obj-$(CONFIG_SOC_OMAPAM33XX) += prcm.o
# OMAP voltage domains
voltagedomain-common := voltage.o vc.o vp.o
@@ -102,6 +104,7 @@ obj-$(CONFIG_ARCH_OMAP3)+=
$(voltagedomain-common) \
voltagedomains3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \
voltagedomains44xx_data.o
+obj-$(CONFIG_SOC_OMAPAM33XX) += $(voltagedomain-common)
# OMAP powerdomain framework
powerdomain-common += powerdomain.o powerdomain-common.o
@@ -116,6 +119,7 @@ obj-$(CONFIG_ARCH_OMAP3)+=
$(powerdomain-common) \
obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) \
powerdomain44xx.o \
powerdomains44xx_data.o
+obj-$(CONFIG_SOC_OMAPAM33XX) += $(powerdomain-common)
# PRCM clockdomain control
clockdomain-common += clockdomain.o \
@@ -132,6 +136,7 @@ obj-$(CONFIG_ARCH_OMAP3)+=
$(clockdomain-common) \
obj-$(CONFIG_ARCH_OMAP4) += $(clockdomain-common) \
clockdomain44xx.o \
clockdomains44xx_data.o
+obj-$(CONFIG_SOC_OMAPAM33XX) += $(clockdomain-common)
# Clock framework
obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o \
@@ -149,6 +154,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= $(clock-common)
clock3xxx.o \
clkt_iclk.o
obj-$(CONFIG_ARCH_OMAP4) += $(clock-common) clock44xx_data.o \
dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_OMAPAM33XX) += $(clock-common) dpll3xxx.o
# OMAP2 clock rate set data (old OPP data)
obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index ad8626d..2e83da8 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -130,7 +130,9 @@ void __init ti81xx_map_io(void)
{
omapti81xx_map_common_io();
}
+#endif
+#if defined(CONFIG_SOC_OMAPAM33XX)
#define AM33XX_TAP_BASE
RE: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
On Mon, 7 May 2012, Mohammed, Afzal wrote:
On Sun, May 06, 2012 at 07:34:07, Paul Walmsley wrote:
(attribution lost)
+static struct omap_hwmod omap3xxx_gpmc_hwmod = {
+ .name = gpmc,
+ .class = omap3xxx_gpmc_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap3xxx_gpmc_irqs,
+ .main_clk = gpmc_fck,
+ .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+};
Is there some reason why you are setting the HWMOD_INIT_NO_RESET flag
here? Seems to me that the kernel should not rely on the bootloader GPMC
configuration, but should use a configuration from the board file or DT.
Major reason was that there are some boards that rely on bootloader
settings, eg. kernel does not do any setting for smsc911x. I did not
want to break those, at least it causes problem with omap3evm, see below
But this is the whole point. The Linux GPMC driver and integration code
should be setting up the GPMC registers based on board file and/or DT
data, before the kernel touches any GPMC devices.
We don't want to rely on the bootloader settings unless we absolutely have
no other choice. Otherwise, the stability of the kernel could easily be
impacted by the bootloader's GPMC timings and other register settings, and
we want to minimize those potential sources of variation.
So if we absolutely have no choice than to keep HWMOD_INIT_NO_RESET here,
which doesn't sound like the case so far, we need to understand exactly
why this is so.
Removing it causes multiple problems, one is that CS0 is valid after
reset of module, with base address starting from zero, which causes
requesting resource failure for CS0, with the way it is currently coded
(GPMC resource starts from 1MB).
Can't this be handled by using a custom hwmod reset function for the GPMC?
Even upon skipping CS0, kernel oops at seemingly unrelated location as
follows, probably due to gpmc reset, as bootloader configured values are
modified to reset value. Omap3 evm uses smsc911x.
Sounds like you've got a good test platform, then :-)
Another issue on OMAP3EVM is the detection of evm revision based on phy id,
by reading hardcoded address, 0x2c00. It had to be skipped to reach till
above mentioned.
Looking at omap3_evm_get_revision() it seems that the OMAP3EVM detection
happens by reading the Ethernet chip's revision register. So can't this
be fixed by programming the GPMC appropriately to access the Ethernet
chip first?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2/3: hwmod data: add gpmc
Hi, On Tue, 8 May 2012, Afzal Mohammed wrote: This is patch 13/39 14/39 of v4 OMAP GPMC driver conversion series modified and squashed into one. ... + /* HWMOD_INIT_NO_RESET can be removed once kernel is updated + * to configure GPMC for all peripherals, right now many + * peripherals depend on bootloader configuration, removing + * this flag would break GPMC on many boards + */ Thanks for combining these. But since you're doing quite a bit of GPMC work, I think we should ensure that the kernel will configure the GPMC before accessing GPMC devices as part of this change. See also http://marc.info/?l=linux-omapm=133649129220098w=2 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
Hi On Tue, 8 May 2012, Mohammed, Afzal wrote: If HWMOD_NO_INIT_RESET is not present, it would break GPMC on many of the existing boards. IMHO, that should also be fixed as part of your changes, to remove what seems to be an unnecessary bootloader dependency. http://marc.info/?l=linux-omapm=133649129220098w=2 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Paul Walmsley p...@pwsan.com [120507 22:35]: On Mon, 7 May 2012, Tony Lindgren wrote: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html I see. Yeah, the problem is that it's hard to figure out which SoCs should go into SOC_OMAP3PLUS. AM33xx? TI81xx? etc. Some of these chips draw some aspects from chips that we've historically considered part of OMAP3, and other aspects from OMAP4-style chips. Yes agreed it should be finer grained and feature specific. What seems better to me would be to use a more specific, IP block-focused macro as needed. So to pick a random example, in mach-omap2/control.c, we currently skip compilation of the scratchpad functions unless CONFIG_ARCH_OMAP3 is defined. Instead of making this SOC_OMAP3PLUS-dependent, or dependent on a mess of CONFIG_SOC_* macros, maybe something like CONFIG_OMAP3430_SCM_SCRATCHPAD_FORMAT? Yes that makes sense. How about let's standardize on naming like SOC_HAS_OMAP3430_SCM_SCRATCHPAD_FORMAT? We already have similar naming for generic things like ARCH_HAS_XYZ. Of course, for some of these cases, maybe it makes more sense to move the code out into a separate file, control-omap3-scratchpad.c or something, and just conditionally compile it to avoid the #ifdefs. Agreed. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] ARM: OMAP5: Add minimal support for OMAP5430 SOC
* Hiremath, Vaibhav hvaib...@ti.com [120507 22:52]: On Tue, May 08, 2012 at 01:05:01, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [120507 12:22]: * Paul Walmsley p...@pwsan.com [120507 12:11]: Hi, On Fri, 4 May 2012, Tony Lindgren wrote: How about we add CONFIG_SOC_OMAP3PLUS in the clean-up series? Then this becomes just: #ifdef CONFIG_SOC_OMAP3PLUS We might want to consider having separate CONFIG_SOC_* values for each SoC. So rather than CONFIG_SOC_OMAP3PLUS, we'd have CONFIG_SOC_OMAP3430, CONFIG_SOC_OMAP3630, etc. Hmm but this would be in addition to the SOC specific options. The goal is to cut down the ifdeffery needed all over the place to add new SoCs, see the experimental patch I posted: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67938.html Of course we could make this finer grained based on features like SOC_HAS_XYZ or SOC_HAS_OMAP3PLUS_PRMXYZBITS if you have some grouping like that in mind. This is much better approach than both ARCH_OMAPx and SOC_OMAP. OK good, so now the question is just what groupings we need.. Got any suggestions? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 boot failure
Hi Kevin, thanks for the suggestion, On Tue, 8 May 2012, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: On Thu, 19 Apr 2012, Igor Grinberg wrote: IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Just tested this on a 3517EVM and the same problem is there too. Does adding nohlt on the cmdline make a difference? The AM35x has known wakeup limitations, and nohlt would at least avoid WFI to see if it's the wakeup problems that are the root cause here. Adding 'nohlt' allows it to go a little farther in the boot, but still hangs. Log below. (Without 'nohlt', it hangs right after calling ip_auto_config+0x0/0xf70 @ 1) - Paul [6.250946] calling net_secret_init+0x0/0x1c @ 1 [6.255981] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs [6.263092] calling tcp_congestion_default+0x0/0xc @ 1 [6.268646] initcall tcp_congestion_default+0x0/0xc returned 0 after 29 usecs [6.276184] calling ip_auto_config+0x0/0xf70 @ 1 [6.325500] mmc0: new high speed SDHC card at address b368 [6.334686] mmcblk0: mmc0:b368 USD 3.75 GiB [6.347686] mmcblk0: p1 p2 p3 [ 18.374359] initcall ip_auto_config+0x0/0xf70 returned -19 after 11809741 use cs [ 18.382141] calling initialize_hashrnd+0x0/0x1c @ 1 [ 18.387420] initcall initialize_hashrnd+0x0/0x1c returned 0 after 59 usecs [ 18.397949] async_waiting @ 1 [ 18.401184] async_continuing @ 1 after 119 usec (hangs) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/13] ARM: OMAP5: Add the build support
* Cousson, Benoit b-cous...@ti.com [120508 02:23]: Hi Tony, On 5/7/2012 7:37 PM, Tony Lindgren wrote: * R, Sricharanr.sricha...@ti.com [120506 20:39]: +config MACH_OMAP5_SEVM + bool OMAP5 sevm Board + depends on ARCH_OMAP5 + config OMAP3_EMU bool OMAP3 debugging peripherals depends on ARCH_OMAP3 No need for it here either. Actually, I think this whole chunk can be now left out since it's DT based? he ok, but the concern here was that without this macro the print from compress and subsequently early prints appear broken. machine_is_omap5_sevm becomes zero without this config and machine_is_ is used by the macro _DEBUG_LL_ENTRY uncompress.h. Ah I see. Mmm, still, I guess this mechanism should be deprecated with DT? We cannot keep creating fake board entry since we are not supposed to have MACHINE_ID anymore. That will break DEBUG_LL for sure, but we knew about that current limitation with DT. For most usecases for DEBUG_LL we can get away in two steps: 1. Debug output for uncompress code based on DT parsing (I think this is already there) 2. Early console/earlyprintk parsed from DT that gets set up in init_early This should be enough for most users, then the people who need to debug early kernel code until init_early is done can patch it in manually. The point is that we should fix the code to stop relying on a machine id going forward. And maybe we can parse the FDT at that time? Yes that should be trivial for most use cases, we just need to initialize the earlycon/earlyprintk based on the DT. See kernel/early_printk.c for more info. We just need to set up the hardware specific function for early_write instead of printch. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] ARM: OMAP5: Add minimal OMAP5 SOC support
* Santosh Shilimkar santosh.shilim...@ti.com [120508 00:27]: On Tuesday 08 May 2012 03:56 AM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120507 02:53]: Tony, On Thursday 03 May 2012 12:56 PM, R Sricharan wrote: The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and hence large part of the peripherals are re-used. OMAP5432 is another variant of OMAP5430, with a memory controller supporting DDR3 and SATA. Series is generated against the 3.4-rc5. This has been rebased on top of the OMAP2+ cleanup series [1] To get the boot working with omap2plus_defconfig, OMAP5 hwmod/clock/prm/cm database needs to be added. The data and the integrated tree are available in the below git repository OMAP5_DATA: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_data OMAP5_INTEGRATED: git://gitorious.org/omap-sw-develoment/linux-omap-dev.git omap5_dt_integrated The series is boot tested on OMAP5430 ES1.0. OMAP2/3/4 build and boot is tested as well to avoid any breakage because of the series. Patch TEMP: ARM: OMAP5: Add cpu_is_omap54xx() checks is temporary and can be dropped once rebased against [2] Patch TEMP: ARM: OMAP5: Update the base address of the 32k-counter is temporary and can be dropped once rebased against [3] [1] http://www.spinics.net/lists/linux-omap/msg69233.html [2] http://www.spinics.net/lists/linux-omap/msg69013.html [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67166.html Do you have a branch where above dependencies are merged ? Seems like those should go into the cleanup branch, and then that can be used as a base. Yep. That will be a good base. How do you suggest to go about updating this series so that above dependencies plus DT support(3.3 based branch in arm-soc tree and needs to be updated against 3.4) is base tree for the patchset. Probably the DT patch should be separate, we can make dt branch depend on the cleanup branch. Sounds good. Btw, who is re-basing the omap-dt branch against 3.4 ? That's already queued up, I can merge in some trivial v3.4 based patches Benoit has and it gets updated automatically. Then the data files should be first posted for reviews (and potentially updated for what we have queued in hwmod-cleanup). Does this series compile on it's own without the data now? This series does compile on it's own without data patches. Data patches needs to re-based against Paul's clean-up and also we need to sort out ES1/ES2 diff so they can wait till then. Probably 3.6+ OK good. This series was intentionally made in such a way that it can be merged without data patches. Just for getting boot working on OMAP5 data patches needs to be merged. Great, excellent. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] OMAPDSS: DT preparation patches v2
* Tomi Valkeinen tomi.valkei...@ti.com [120508 01:48]: On Mon, 2012-05-07 at 10:46 -0700, Tony Lindgren wrote: Hi, * Tomi Valkeinen tomi.valkei...@ti.com [120503 07:01]: Hi, I started cleaning up and restructuring omapdss for device tree, and here's the first set of patches from that ordeal. There's nothing DT specific in these patches, but they are mostly generic cleanups that make sense even without DT. This is the second version of these patches, the previous version can be found from: http://www.spinics.net/lists/linux-fbdev/msg05667.html The first 21 patches, which were in the previous version, have only gotten minor cleanups (and, of course, more testing). The last 4 patches are new. The most important of those patches is the DSI pin config patch, which makes it possible for the panel driver to configure the DSI pins it needs. This series can also be found from: git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base Nice clean up. Can you please put the first 12 arch/arm/*omap*/* touching patches (and the drivers/video dependencies needed) into a separate branch and send me a pull request. That is assuming those patches are now immutable. Then I can pull it into cleanup-dss branch that we both can merge as needed. Ok, I'll see how it goes. Do I have your ack for the board file changes? Acked-by: Tony Lindgren t...@atomide.com Do you want to have patches that touch only arch/arm/mach-omap2/display.c, but not the board files? That's a dss specific file, and I don't expect anyone else to make changes to it, so chances for conflicts should be quite minimal. Yes probably board-*.c files are enough to avoid annoying merge conflicts. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Broken UART I/O wakeups on v3.4-rc4+
On Tue, 8 May 2012, Raja, Govindraj wrote: On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley p...@pwsan.com wrote: The same is discussed in this thread as in here: http://www.spinics.net/lists/linux-omap/msg68659.html OK. Could you please fix this? We probably aren't too far from the v3.5 merge window opening, so there isn't much time to fix it. okay, one possible solution is to probe pins dynamically and make rx wakeup capable which myself and Tony discussed and came up with this patch [1] or to add rx wakeup pad support for each board, based on uart used as console. Oh well, sounds like UART I/O wakeups are going to be broken in v3.4 :-( Do you have a patch ready for Tony to queue for v3.5 to fix this? From the above thread, it looks like Tony had some remaining comments to be addressed on your patch. - Paul
Re: [PATCH 3/4] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
* Vaibhav Hiremath hvaib...@ti.com [120508 08:10]: --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -20,12 +20,16 @@ config ARCH_OMAP2PLUS_TYPICAL help Compile a kernel suitable for booting most boards +config SOC_HAS_SDRC + bool SDRAM Controller support + config ARCH_OMAP2 bool TI OMAP2 depends on ARCH_OMAP2PLUS default y select CPU_V6 select MULTI_IRQ_HANDLER + select SOC_HAS_SDRC config ARCH_OMAP3 bool TI OMAP3 These still need to have OMAP in them, and ideally the type of the block. Something like SOC_HAS_OMAP2_SDRC? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/4] ARM: OMAP2+: CLEANUP: Add new config option for different DPLL features
* Vaibhav Hiremath hvaib...@ti.com [120508 08:10]: This patch cleans up dpll_data structure, making structure fields definition based on feature availability for given SoC, managed using Kconfig rules. SOC_HAS_DPLL_IDLE: idle state SOC_HAS_DPLL_RECAL: recalibration capability SOC_HAS_DPLL_DCO_SEL: dco selection SOC_HAS_DPLL_SDDIV: sigma-delta div factor SOC_HAS_DPLL_FREQSEL: frequency selection These too should be SOC_HAS_OMAPXYZ_DPLL_IDLE etc. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oprofile and ARM A9 hardware counter
Cousson, Benoit b-cous...@ti.com writes: On 5/8/2012 4:00 PM, Kevin Hilman wrote: Jean Pihetjean.pi...@newoldbits.com writes: [...] Yes, indeed, we should not hack the flags to fix that kind of issue. The flags describe what the HW is capable of, and the EMU CD can support HW_AUTO and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid next power state is OFF, meaning that no retention mode is supported. So any transition to idle will go to OFF and lead to a reset upon wakeup. That being said, being able to transition to OFF during idle is a perfectly valid state for most powerdomain in OMAP anyway, so we should be able to restore from OFF mode smoothly. It looks to me that what is missing here is *just* a restore path in the PMU/CTI code. But I'm probably missing some nasty details in this issue :-) Although it is perfectly feasible to have a seamless transition of the EMU power domain, I think the PMU counters will not be accurate anymore since they stop counting events when going to OFF and re-start after the state restore. Good point, but I think the PMU might still works fine because located inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is going to OFF and thus will be reset. Ever better point ;p Thanks for the precision. In any case my point was: can we allow the EMU CD to go OFF or prevent it from doing so? We need to answer that question first. The idea I've suggested is to use runtime PM for this. As long as the PMU is in use, it will be runtime PM enabled (and not allowed to go into HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and then be reset. The next time it is needed, the runtime resume will need to do a full re-init. Oh, but does that mean that this driver is not pm_runtime adapted yet? Actually, it is. Ming Lei has done it. Currently, Will has collected this[1] and is waiting (patiently) for us to produce a real fix that doesn't kill PM in the process. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 boot failure
Paul Walmsley p...@pwsan.com writes: Hi Kevin, thanks for the suggestion, On Tue, 8 May 2012, Kevin Hilman wrote: Paul Walmsley p...@pwsan.com writes: On Thu, 19 Apr 2012, Igor Grinberg wrote: IMO this can be seen on any AM35xx based board with EMAC, or am I mistaken? Just tested this on a 3517EVM and the same problem is there too. Does adding nohlt on the cmdline make a difference? The AM35x has known wakeup limitations, and nohlt would at least avoid WFI to see if it's the wakeup problems that are the root cause here. Adding 'nohlt' allows it to go a little farther in the boot, but still hangs. Log below. (Without 'nohlt', it hangs right after calling ip_auto_config+0x0/0xf70 @ 1) - Paul [6.250946] calling net_secret_init+0x0/0x1c @ 1 [6.255981] initcall net_secret_init+0x0/0x1c returned 0 after 119 usecs [6.263092] calling tcp_congestion_default+0x0/0xc @ 1 [6.268646] initcall tcp_congestion_default+0x0/0xc returned 0 after 29 usecs [6.276184] calling ip_auto_config+0x0/0xf70 @ 1 [6.325500] mmc0: new high speed SDHC card at address b368 [6.334686] mmcblk0: mmc0:b368 USD 3.75 GiB [6.347686] mmcblk0: p1 p2 p3 [ 18.374359] initcall ip_auto_config+0x0/0xf70 returned -19 after 11809741 use cs [ 18.382141] calling initialize_hashrnd+0x0/0x1c @ 1 [ 18.387420] initcall initialize_hashrnd+0x0/0x1c returned 0 after 59 usecs [ 18.397949] async_waiting @ 1 [ 18.401184] async_continuing @ 1 after 119 usec (hangs) Are you still trying nfsroot? Since ip_auto_config failed, it will have no way of mounting the nfsroot and stop there. Do you know why ip setup failed? -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
