Re: [PATCH] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
On Tuesday 09 October 2012 02:27 PM, Vaibhav Hiremath wrote: This patch adds of_have_populated_dt() check before creating Signed-off-by: Vaibhav Hiremath Cc: Afzal Mohammed Reviewed-by: Afzal Mohammed -- 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] rtc: kconfig: fix RTC_INTF defaults connected to RTC_CLASS
On Wednesday 10 October 2012 05:39 AM, Kevin Hilman wrote: From: Kevin Hilman commit 6b8029fab64164b5895d58d23229b75c82e3a6fc (rtc: kconfig: remove unnecessary dependencies) removed various 'depends on RTC_CLASS' dependencies but also removed a few 'default RTC_CLASS' statements, which actually changed default behavior. This resulted in the various RTC interfaces (sysfs, proc, dev) all being disabled by default, even when RTC_CLASS is enabled: # CONFIG_RTC_INTF_SYSFS is not set # CONFIG_RTC_INTF_PROC is not set # CONFIG_RTC_INTF_DEV is not set which is different from previous behavior (all of these where enabled.) To fix, add back the 'default RTC_CLASS' statments to each of the RTC_INTF_* options. Thanks for fixing this. config RTC_INTF_DEV boolean "/dev/rtcN (character devices)" + default RTC_CLASS help Say yes here if you want to use your RTCs using the /dev interfaces, which "udev" sets up as /dev/rtc0 through Acked-by: Venu Byravarasu -- 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 1/3] OMAP: VRFB: convert vrfb to platform device
On Tue, 2012-10-09 at 13:37 -0700, Kevin Hilman wrote: > Hi Tomi, > > Tomi Valkeinen writes: > > > This patch converts vrfb library into a platform device, in an effort to > > remove omap dependencies. > > > > The platform device is registered in arch/arm/plat-omap/fb.c and > > assigned resources depending on whether running on omap2 or omap3. > > > > The vrfb driver will parse those resources and use them to access vrfb > > configuration registers and the vrfb virtual rotation areas. > > > > Signed-off-by: Tomi Valkeinen > > Cc: Tony Lindgren > > [...] > > I was having a quick look at this for the context save/restore piece in > order to understand how this driver's context is being saved/restored. > > Looking at mainline, I don't see where omap_vrfb_restore_context() is > being called currently. Am I missing something? No, the driver is missing something. I noticed the same thing. It seems ctx restore for vrfb has never been functional in mainline. I don't really have any recollection if this was left out intentionally from mainline (possibly because we didn't have a good way to handle it at that point), or was it just a mistake. Nobody has complained about it, though, so it can't be a major problem =). Vrfb is a platform device/driver after this patch. Do you see any problem with handling the context restore in runtime PM's runtime_resume callback? Hmm, I guess then we could have a problem if omapdss and omapfb are resumed before vrfb. Any way to manage the suspend/resume ordering of unrelated (i.e. no parent/child relation) devices? Tomi signature.asc Description: This is a digitally signed message part
Re: Issue with _are_all_hardreset_lines_asserted()
Hi,
On 9 October 2012 00:38, Paul Walmsley wrote:
> cc Vaibhav due to the AM33xx change
>
> Hi
>
> On Thu, 4 Oct 2012, Archit Taneja wrote:
>
>> I was trying out the linux-next kernel, and I noticed that DSS MODULEMODE
>> bits
>> are never cleared.
>>
>> In _omap4_disable_module(), there is a check:
>>
>> ...
>>
>> if (!_are_all_hardreset_lines_asserted(oh))
>> return 0;
>>
>> /* MODULEMODE bits cleared here */
>> ...
>> ...
>> ...
>>
>> The function _are_all_hardreset_lines_asserted() returns false if
>> 'oh->rst_lines_cnt == 0', so we bail out from _omap4_disable_module() before
>> clearing the MODULEMODE bits.
>>
>> Is this correct behavior? This would prevent all hwmods who have
>> rst_lines_cnt
>> as 0 to not get their MODULEMODE bits cleared.
>
> You're right, that looks bogus. What do you think about the following
> patch?
I was a little busy creating the patch but seems like Paul beat me to
it, yes it was a wrong case on disable_module.
> From: Paul Walmsley
> Date: Mon, 8 Oct 2012 23:08:15 -0600
> Subject: [PATCH] ARM: OMAP4/AM335x: hwmod: fix disable_module regression in
> hardreset handling
>
> Commit eb05f691290e99ee0bd1672317d6add789523c1e ("ARM: OMAP: hwmod:
> partially un-reset hwmods might not be properly enabled") added code
> to skip the IP block disable sequence if any hardreset lines were left
> unasserted. But this did not handle the case when no hardreset lines
> were associated with a module, which is the general case. In that
> situation, the IP block would be skipped, which is likely to cause PM
> regressions.
>
> So, modify _omap4_disable_module() and _am33xx_disable_module() to
> only bail out early if there are any hardreset lines asserted. And
> move the AM33xx test above the actual module disable code to ensure
> that the behavior is consistent.
I think that on _omap4_disable_module() we want to check if the module
is deasserted rather than if it is asserted.
E.g.: If you have 2 hwmods for the same module (ipu with reset "cpu0"
and mmu_ipu with reset "mmu") controlled by different drivers,
depending on which one is idled first, the other one will cause L3
aborts given that the module is already disabled. So, if ipu is idled
and disabled first, then all tear down operations on iommu will cause
L3 aborts.
I created the following:
From: Omar Ramirez Luna
Subject: [PATCH] ARM: OMAP: hwmod: allow hwmods without reset lines to be
disabled
_are_all_hardreset_lines_asserted treats hwmods without reset lines
as always deasserted, this is correct for: _enable, _idle and
_shutdown paths, however for _omap4_disable_module it might not
result in the correct behavior, given that:
- hwmod without reset line can be safely disabled.
- hwmod with 1 or more reset lines, must be completely asserted
before disabled or be left to integration code to handle it.
Create a function to check for any hwmod to be partially out of
hardreset and bail of _omap4_disable_module if this is the case.
Hwmods without reset lines can skip these check and continue.
Reported-by: Archit Taneja
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 299ca28..f9d9bfb 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1698,6 +1698,29 @@ static bool
_are_all_hardreset_lines_asserted(struct omap_hwmod *oh)
}
/**
+ * _are_any_hardreset_lines_deasserted - true if part of @oh isn't hard-reset
+ * @oh: struct omap_hwmod *
+ *
+ * If any hardreset line associated with @oh is deasserted, then return true.
+ * Otherwise, if no hardreset lines associated with @oh are deasserted,
+ * then return false. This function is used to avoid SOC's disable_module to
+ * be called while the @oh is still deasserted.
+ *
+ * Check for oh->rst_lines_cnt is left to the caller, since a return value
+ * could mean that a hwmod with no reset lines is deasserted.
+ */
+static bool _are_any_hardreset_lines_deasserted(struct omap_hwmod *oh)
+{
+ int i;
+
+ for (i = 0; i < oh->rst_lines_cnt; i++)
+ if (_read_hardreset(oh, oh->rst_lines[i].name) == 0)
+ return true;
+
+ return false;
+}
+
+/**
* _omap4_disable_module - enable CLKCTRL modulemode on OMAP4
* @oh: struct omap_hwmod *
*
@@ -1713,9 +1736,12 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
/*
* Since integration code might still be doing something, only
-* disable if all lines are under hardreset.
+* disable if all lines are under hardreset. Explicitly check for
+* reset lines before the call, otherwise the abscence of a reset
+* line is assumed as a deasserted hwmod and won't execute the
+* disable sequence.
*/
- if (!_are_all_hardreset_lines_as
Re: [PATCH v2 1/2] omap3: Provide means for changing CSI2 PHY configuration
Sakari Ailus writes: > Hi Kevin, > > Thanks for the comments! > > On Tue, Oct 09, 2012 at 01:50:04PM -0700, Kevin Hilman wrote: >> Hi Sakari, >> >> Sakari Ailus writes: >> >> > The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to >> > the actual CSI-2 receivers outside the ISP itself. Allow changing this >> > configuration from the ISP driver. >> > >> > Signed-off-by: Sakari Ailus >> >> These control module registers (CSIRXFE, CAMERA_PHY_CTRL) are in the >> CORE powerdomain, so they will be lost during off-mode transitions. So, >> I suspect you'll also want to add them to the save/restore functions in >> control.c in order for this to work across off-mode transitions. > > I've got another patch that implements this in the ISP driver instead. > > http://www.spinics.net/lists/linux-media/msg54781.html> Oops, sorry. I should've looked at v3. > The ISP also can't wake up the MPU from the off mode, so I don't think > losing the register contents is necessarily an issue. The registers will be > written to a new value whenever streaming is started. Perhaps adding a note > about that would be worthwhile. Yes, I suggest mentioning that these register are not saved/restored and why would be helpful. 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 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
* Péter Ujfalusi [121009 02:03]: > On 10/08/2012 07:35 PM, Tony Lindgren wrote: > > > - omap-dma.c and omap-pcm.c can test the arch locally as > > omap1 and omap2 cannot be compiled together because of > > conflicting compiler flags > > > sound/soc/omap/omap-pcm.c |9 +++-- > > Tony: is this going to be included in 3.7? Hmm I guess we could try to get this out of the way to cut down the dependencies. Let's if maintainers of the other affected drivers this is OK for the -rc series. 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
[PATCH] rtc: kconfig: fix RTC_INTF defaults connected to RTC_CLASS
From: Kevin Hilman commit 6b8029fab64164b5895d58d23229b75c82e3a6fc (rtc: kconfig: remove unnecessary dependencies) removed various 'depends on RTC_CLASS' dependencies but also removed a few 'default RTC_CLASS' statements, which actually changed default behavior. This resulted in the various RTC interfaces (sysfs, proc, dev) all being disabled by default, even when RTC_CLASS is enabled: # CONFIG_RTC_INTF_SYSFS is not set # CONFIG_RTC_INTF_PROC is not set # CONFIG_RTC_INTF_DEV is not set which is different from previous behavior (all of these where enabled.) To fix, add back the 'default RTC_CLASS' statments to each of the RTC_INTF_* options. I noticed this because some RTC tests started failing on my TI OMAP platforms because /dev/rtc0 was not present anymore, even though the driver was present and RTC_CLASS was enabled. Cc: Venu Byravarasu Cc: Andrew Morton Signed-off-by: Kevin Hilman --- Targeted as a fix for v3.7-rc. Applies on Linus' master, just after merging "Andrew's patch bomb" commit 11126c611e10abb18b6f1ed0300c0548c3906b54 drivers/rtc/Kconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index e069f17..19c03ab 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -59,6 +59,7 @@ comment "RTC interfaces" config RTC_INTF_SYSFS boolean "/sys/class/rtc/rtcN (sysfs)" depends on SYSFS + default RTC_CLASS help Say yes here if you want to use your RTCs using sysfs interfaces, /sys/class/rtc/rtc0 through /sys/.../rtcN. @@ -68,6 +69,7 @@ config RTC_INTF_SYSFS config RTC_INTF_PROC boolean "/proc/driver/rtc (procfs for rtcN)" depends on PROC_FS + default RTC_CLASS help Say yes here if you want to use your system clock RTC through the proc interface, /proc/driver/rtc. @@ -79,6 +81,7 @@ config RTC_INTF_PROC config RTC_INTF_DEV boolean "/dev/rtcN (character devices)" + default RTC_CLASS help Say yes here if you want to use your RTCs using the /dev interfaces, which "udev" sets up as /dev/rtc0 through -- 1.7.9.2 -- 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: [GIT PULL 1/5] omap fixes for v3.7-rc1
Hi, On Tue, Oct 9, 2012 at 11:46 AM, Tony Lindgren wrote: > The following changes since commit 5e090ed7af10729a396a25df43d69a236e789736: > > Merge tag 'soc-late' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2012-10-07 > 20:55:16 +0900) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v3.7-rc1/fixes-signed Applied 1-5. Thanks! -Olof -- 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/2] omap3: Provide means for changing CSI2 PHY configuration
Hi Kevin, Thanks for the comments! On Tue, Oct 09, 2012 at 01:50:04PM -0700, Kevin Hilman wrote: > Hi Sakari, > > Sakari Ailus writes: > > > The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to > > the actual CSI-2 receivers outside the ISP itself. Allow changing this > > configuration from the ISP driver. > > > > Signed-off-by: Sakari Ailus > > These control module registers (CSIRXFE, CAMERA_PHY_CTRL) are in the > CORE powerdomain, so they will be lost during off-mode transitions. So, > I suspect you'll also want to add them to the save/restore functions in > control.c in order for this to work across off-mode transitions. I've got another patch that implements this in the ISP driver instead. http://www.spinics.net/lists/linux-media/msg54781.html> The ISP also can't wake up the MPU from the off mode, so I don't think losing the register contents is necessarily an issue. The registers will be written to a new value whenever streaming is started. Perhaps adding a note about that would be worthwhile. Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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: omap DSS cmdline resolution not working for HDMI?
* Tomi Valkeinen [121009 06:08]: > On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote: > > > Looks like somehow also output_size won't change when changing > > display output from DVI to HDMI. > > > > If I boot with DVI panel at 1600x1200, then try to switch to the > > HDMI monitor with the following script: > > > > #!/bin/sh > > > > export dvi=display0 > > export hdmi=display1 > > export overlay=overlay0 > > > > echo 0 > /sys/devices/platform/omapdss/$dvi/enabled > > echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled > > echo "85500,1366/70/213/143,768/3/24/3" > > > /sys/devices/platform/omapdss/$hdmi/timings > > echo 0 > /sys/devices/platform/omapdss/$overlay/enabled > > echo tv > /sys/devices/platform/omapdss/$overlay/manager > > #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size > > echo 1 > /sys/devices/platform/omapdss/$overlay/enabled > > cat /sys/devices/platform/omapdss/$hdmi/timings > > cat /sys/devices/platform/omapdss/$overlay/output_size > > > > I get the following which may provide more clues: > > > > [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the > > output with video overlays dd > > [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the > > display area (0 + 1600 >= 13) > > [64370.840972] omapdss APPLY error: failed to enable manager 1: > > check_settings failed > > [64370.849670] omapdss HDMI error: failed to power on device > > [64370.855407] omapdss error: failed to power on > > [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the > > display area (0 + 1600 >= 13) > > [64370.872436] omapdss APPLY error: failed to enable manager 1: > > check_settings failed > > [64370.880798] omapdss HDMI error: failed to power on device > > [64370.886505] omapdss error: failed to power on > > 85500,1366/70/213/143,768/3/24/3 > > 1600,1200 > > Well, it's not that simple =). There are three things to consider: > > - Framebuffer in the sdram. It has xres and yres parameters. > - Overlay, and it's input size (from fb) and output sizes (must fit into > the display). > - Display, which has certain size depending on video mode. > > Only VID overlays can have different input and output sizes, GFX overlay > does not support scaling. > > In the script above you don't change the fb at all. You can do that with > when the overlay is disabled, for example: > > fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768 > > But that only works if there's enough memory allocated for the > framebuffer, but that is the case for you if the fb was bigger > initially. Otherwise you need to set the new size > with /sys/class/graphics/fb0/size before resizing the fb. > > And, of course, the framebuffer cannot be in use at that time by, for > example, X. Thanks for the explanation, I'll give that a try at some point. > Yes, it's complex! I hope omapdrm will make all things simple, and we > can forget omapfb. In hindsight, I should've designed omapfb to be much > simpler, and only use gfx overlay. Making it support all overlays is a > never ending source for problems and complexity. Heh oh well it works reasonably for most cases I guess. > > FYI, I'm also seeing the DVI monitor blank out on it's own for > > about a second or so on regular basis every 10 minutes or so. > > No idea what's causing that, maybe it's a reminder to take > > a short break :) > > Well that's something different. I've recently done some testing with > using DSI PLL for generating pixel clock, and I've seen unstabilities > with that. But perhaps there's something else wrong also, even when > using the PRCM for pix clock as in your case. > > Does your monitor ever report something like bad signal or such? Yes I've seen that too, but that seems to be different issue and I may have passed wrong timings in that case. I guess the random blanking for a second or so could also be an occastional bad timing. No warnings in that case on the monitor though. 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] ARM: OMAP: move old debug-devices.c and debug-leds.c to be OMAP2+ only for now
* Paul Walmsley [121009 13:12]: > > OK if you want to leave it there, it's fine with me. Looks like it > should go into drivers/ at some point though? Yes it should be just a regular device driver eventually at some point. But no rush, let's first get the dependencies between device drivers and core omap code removed by removing the remaining mach and plat includes. 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: [GIT PULL] ARM: OMAP: warnings/hwmod/clock fixes for pre-3.7-rc1
* Paul Walmsley [121009 12:31]: > On Tue, 9 Oct 2012, Tony Lindgren wrote: > > > * Paul Walmsley [121009 09:05]: > > > > > > N800 isn't booting; this is a problem present in the base commit and > > > is due to serial driver breakage: > > > > > >http://www.spinics.net/lists/arm-kernel/msg196034.html > > > > This might be related also to the n800 booting in sys mode > > that causes issues with the recent hyp patches. A fix for > > that has been queued, for more info see the thread > > "v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode". > > Thanks for the pointer. That one would break the boot quite early, right? > This one has the same symptoms as the serial issue, where it bombs out > after: > > [0.948394] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled > [0.974273] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP > UART0 > [0.986968] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP > UART1 > > (hang) Yes the sys mode hangs right away and only prints a few lines with earlyprintk. 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 v2 1/2] omap3: Provide means for changing CSI2 PHY configuration
Hi Sakari, Sakari Ailus writes: > The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to > the actual CSI-2 receivers outside the ISP itself. Allow changing this > configuration from the ISP driver. > > Signed-off-by: Sakari Ailus These control module registers (CSIRXFE, CAMERA_PHY_CTRL) are in the CORE powerdomain, so they will be lost during off-mode transitions. So, I suspect you'll also want to add them to the save/restore functions in control.c in order for this to work across off-mode transitions. 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: [PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
Hi Tomi, Tomi Valkeinen writes: > This patch converts vrfb library into a platform device, in an effort to > remove omap dependencies. > > The platform device is registered in arch/arm/plat-omap/fb.c and > assigned resources depending on whether running on omap2 or omap3. > > The vrfb driver will parse those resources and use them to access vrfb > configuration registers and the vrfb virtual rotation areas. > > Signed-off-by: Tomi Valkeinen > Cc: Tony Lindgren [...] I was having a quick look at this for the context save/restore piece in order to understand how this driver's context is being saved/restored. Looking at mainline, I don't see where omap_vrfb_restore_context() is being called currently. Am I missing something? 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: OMAP: resolve sparse warning concerning debug_card_init()
Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 ("ARM: OMAP: move
debug_card_init() function") results in the following new sparse
warning:
arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init' was
not declared. Should it be static?
Fix by implementing Tony's suggestion to add a "sideways include" to the
new location of the debug-devices.h file in arch/arm/mach-omap2/.
Signed-off-by: Paul Walmsley
Cc: Igor Grinberg
Cc: Tony Lindgren
---
arch/arm/plat-omap/debug-devices.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/plat-omap/debug-devices.c
b/arch/arm/plat-omap/debug-devices.c
index c7a4c09..5a4678e 100644
--- a/arch/arm/plat-omap/debug-devices.c
+++ b/arch/arm/plat-omap/debug-devices.c
@@ -16,6 +16,7 @@
#include
#include
+#include "../mach-omap2/debug-devices.h"
/* Many OMAP development platforms reuse the same "debug board"; these
* platforms include H2, H3, H4, and Perseus2.
--
1.7.10.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] ARM: OMAP: move old debug-devices.c and debug-leds.c to be OMAP2+ only for now
On Mon, 8 Oct 2012, Tony Lindgren wrote: > Hmm are you sure that omap1 is not using debug-leds.c? > At least the initcall seems like it should run on omap1 > if enabled. You're right, it's probably able to run on OMAP1. Looks like I got confused by the bogus Kconfig dependency from OMAP_DEBUG_LEDS -> OMAP_DEBUG_DEVICES, since debug_card_init() is only called from the H4 board init. > The sideways include here is OK, it does not get exposed to > the drivers, it seems that plat-omap is still the right location > for at least debug-leds.c code. OK if you want to leave it there, it's fine with me. Looks like it should go into drivers/ at some point though? Will send a patch to do the sideways include to fix the sparse warning. - 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: [GIT PULL] ARM: OMAP: warnings/hwmod/clock fixes for pre-3.7-rc1
On Tue, 9 Oct 2012, Tony Lindgren wrote: > * Paul Walmsley [121009 09:05]: > > > > N800 isn't booting; this is a problem present in the base commit and > > is due to serial driver breakage: > > > >http://www.spinics.net/lists/arm-kernel/msg196034.html > > This might be related also to the n800 booting in sys mode > that causes issues with the recent hyp patches. A fix for > that has been queued, for more info see the thread > "v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode". Thanks for the pointer. That one would break the boot quite early, right? This one has the same symptoms as the serial issue, where it bombs out after: [0.948394] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [0.974273] omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 88) is a OMAP UART0 [0.986968] omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 89) is a OMAP UART1 (hang) - 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: [GIT PULL] ARM: OMAP: warnings/hwmod/clock fixes for pre-3.7-rc1
* Paul Walmsley [121009 09:05]: > > N800 isn't booting; this is a problem present in the base commit and > is due to serial driver breakage: > >http://www.spinics.net/lists/arm-kernel/msg196034.html This might be related also to the n800 booting in sys mode that causes issues with the recent hyp patches. A fix for that has been queued, for more info see the thread "v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode". 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 03/13] ARM: edma: add DT and runtime PM support for AM335x
On Fri, Sep 21, 2012 at 08:53:06AM +, Hebbar, Gururaja wrote:
> On Thu, Sep 20, 2012 at 20:13:36, Porter, Matt wrote:
> > Adds support for parsing the TI EDMA DT data into the required
> > EDMA private API platform data.
> >
> > Calls runtime PM API only in the DT case in order to unidle the
> > associated hwmods on AM335x.
> >
> > Signed-off-by: Matt Porter
> > ---
> > arch/arm/common/edma.c | 252
> > --
> > arch/arm/include/asm/mach/edma.h |8 +-
> > 2 files changed, 244 insertions(+), 16 deletions(-)
>
> The binding documentation should be updated along with the driver
> change that does introduce the binding. You could just merged patch #4
> and #5.
Hi Gururaja,
Sorry I missed these comments for this long...
I've been asked by maintainers to keep the binding separate in other
drivers. It is documentation that is independent of the driver in
any case...I'll move the binding before this implementation though.
> > diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> > index 001d268..f337f81 100644
> > --- a/arch/arm/common/edma.c
> > +++ b/arch/arm/common/edma.c
> > @@ -24,6 +24,13 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> >
> > #include
> >
> > @@ -1366,30 +1373,236 @@ void edma_clear_event(unsigned channel)
> > EXPORT_SYMBOL(edma_clear_event);
> >
> > /*---*/
> > +static int edma_of_read_u32_to_s8_array(const struct device_node *np,
> > +const char *propname, s8 *out_values,
> > +size_t sz)
> > +{
> > + struct property *prop = of_find_property(np, propname, NULL);
> > + const __be32 *val;
> > +
> > + if (!prop)
> > + return -EINVAL;
> > + if (!prop->value)
> > + return -ENODATA;
> > + if ((sz * sizeof(u32)) > prop->length)
> > + return -EOVERFLOW;
> > +
> > + val = prop->value;
> > +
> > + while (sz--)
> > + *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
> > +
> > + /* Terminate it */
> > + *out_values++ = -1;
> > + *out_values++ = -1;
> > +
> > + return 0;
> > +}
> > +
> > +static int edma_of_read_u32_to_s16_array(const struct device_node *np,
> > +const char *propname, s16 *out_values,
> > +size_t sz)
> > +{
> > + struct property *prop = of_find_property(np, propname, NULL);
> > + const __be32 *val;
> > +
> > + if (!prop)
> > + return -EINVAL;
> > + if (!prop->value)
> > + return -ENODATA;
> > + if ((sz * sizeof(u32)) > prop->length)
> > + return -EOVERFLOW;
> > +
> > + val = prop->value;
> > +
> > + while (sz--)
> > + *out_values++ = (s16)(be32_to_cpup(val++) & 0x);
> > +
> > + /* Terminate it */
> > + *out_values++ = -1;
> > + *out_values++ = -1;
> > +
> > + return 0;
> > +}
> > +
> > +static int edma_of_parse_dt(struct device *dev,
> > + struct device_node *node,
> > + struct edma_soc_info *pdata)
> > +{
> > + int ret = 0;
> > + u32 value;
> > + struct property *prop;
> > + size_t sz;
> > + struct edma_rsv_info *rsv_info;
> > + s16 (*rsv_chans)[2], (*rsv_slots)[2];
> > + s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
> > +
> > + ret = of_property_read_u32(node, "dma-channels", &value);
> > + if (ret < 0)
> > + return ret;
> > + pdata->n_channel = value;
> > +
> > + ret = of_property_read_u32(node, "ti,edma-regions", &value);
> > + if (ret < 0)
> > + return ret;
> > + pdata->n_region = value;
> > +
> > + ret = of_property_read_u32(node, "ti,edma-slots", &value);
> > + if (ret < 0)
> > + return ret;
> > + pdata->n_slot = value;
> > +
> > + pdata->n_cc = 1;
> > + /* This is unused */
> > + pdata->n_tc = 3;
> > +
> > + rsv_info =
> > + devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
> > + if (!rsv_info)
> > + return -ENOMEM;
> > + pdata->rsv = rsv_info;
> > +
> > + /* Build the reserved channel/slots arrays */
> > + prop = of_find_property(node, "ti,edma-reserved-channels", &sz);
> > + if (!prop)
> > + return -EINVAL;
> > +
> > + rsv_chans =
> > + devm_kzalloc(dev, sz/sizeof(s16) + 2*sizeof(s16), GFP_KERNEL);
> > + if (!rsv_chans)
> > + return -ENOMEM;
> > + pdata->rsv->rsv_chans = rsv_chans;
> > +
> > + ret = edma_of_read_u32_to_s16_array(node, "ti,edma-reserved-channels",
> > + (s16 *)rsv_chans, sz/sizeof(u32));
> > + if (ret < 0)
> > + return ret;
> > +
> > + prop = of_find_property(node, "ti,edma-reserved-slots", &sz);
> > + if (!prop)
> > + return -EINVAL;
> > +
>
> Binding Documentation mentions edma-reserve
[GIT PULL 1/5] omap fixes for v3.7-rc1
The following changes since commit 5e090ed7af10729a396a25df43d69a236e789736: Merge tag 'soc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2012-10-07 20:55:16 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc1/fixes-signed for you to fetch changes up to 224cd7115abb5b05a5d665551452c271449ce80b: arm/omap: Replace board_ref_clock with enum values (2012-10-08 18:09:30 -0700) This branch contains one counter locking fix and an alignment fix. Other fixes are warning fixes, fixes for return value checks. I've also included removal of some extra semicolons, dropping of some duplicate includes, and an a change for wl12xx enumeration that are not strictly fixes but would be good to get out of the way for -rc1. Afzal Mohammed (1): ARM: OMAP2+: gpmc: annotate exit sections properly Axel Lin (1): ARM: OMAP: OMAP_DEBUG_LEDS needs to select LEDS_CLASS Colin Cross (1): ARM: OMAP: counter: add locking to read_persistent_clock Peter Senna Tschudin (3): arch/arm/mach-omap1/devices.c: Remove unecessary semicolon arch/arm/mach-omap2: Remove unecessary semicolon arch/arm/plat-omap/omap-pm-noop.c: Remove unecessary semicolon R Sricharan (1): ARM: OMAP2+: Round of the carve out memory requested to section_size Raphael Assenat (1): AM35xx: Add missing hwmod entry for the HDQ/1-Wire present in AM3505/3517 CPUs. Shubhrajyoti D (1): ARM: OMAP: rx51: Fix a section mismatch warn Vaibhav Hiremath (1): ARM: OMAP2+: Add am335x evm and bone targets to common Makefile Vikram Narayanan (1): arm/omap: Replace board_ref_clock with enum values Wei Yongjun (4): OMAPDSS: fix return value check in create_dss_pdev() ARM: OMAP: hsmmc: fix return value check in omap_hsmmc_init_one() ARM: OMAP: fix return value check in realtime_counter_init() ARM: OMAP2+: remove duplicated include from board-omap3stalker.c Yegor Yefremov (1): arm: increase FORCE_MAX_ZONEORDER for TI AM33XX arch/arm/Kconfig |1 + arch/arm/boot/dts/Makefile |4 +++- arch/arm/mach-omap1/devices.c|2 +- arch/arm/mach-omap2/board-flash.c|2 +- arch/arm/mach-omap2/board-omap3stalker.c |5 - arch/arm/mach-omap2/board-omap4panda.c |3 +-- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |3 +-- arch/arm/mach-omap2/clkt_clksel.c|2 +- arch/arm/mach-omap2/display.c|2 +- arch/arm/mach-omap2/gpmc.c |4 ++-- arch/arm/mach-omap2/hsmmc.c |2 +- arch/arm/mach-omap2/mux.c|2 +- arch/arm/mach-omap2/omap-secure.c|4 ++-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |7 --- arch/arm/mach-omap2/pm-debug.c |2 +- arch/arm/mach-omap2/timer.c |2 +- arch/arm/plat-omap/Kconfig |1 + arch/arm/plat-omap/counter_32k.c | 21 ++--- arch/arm/plat-omap/omap-pm-noop.c|8 20 files changed, 42 insertions(+), 37 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
[GIT PULL] ARM: OMAP: warnings/hwmod/clock fixes for pre-3.7-rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659: Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-a-for-pre3.7 for you to fetch changes up to e9332b6eed82973a8f75f1f3d57babaa331d703c: ARM: OMAP4/AM335x: hwmod: fix disable_module regression in hardreset handling (2012-10-08 23:08:15 -0600) - Some OMAP fixes for the 3.7 merge window, fixing mismerges, branch integration issues, and bugs after the arm-soc merges. Basic test logs are available here: http://www.pwsan.com/omap/testlogs/devel_late_fixes_3.7/20121009084003/ N800 isn't booting; this is a problem present in the base commit and is due to serial driver breakage: http://www.spinics.net/lists/arm-kernel/msg196034.html - Jon Hunter (2): ARM: OMAP2+: hwmod data: Fix PMU interrupt definitions ARM: OMAP3: fix workaround for EMU clockdomain Paul Walmsley (2): ARM: OMAP: omap3evm: fix new sparse warning ARM: OMAP4/AM335x: hwmod: fix disable_module regression in hardreset handling Vaibhav Hiremath (1): ARM: am33xx: clk: Update clkdev table to add mcasp alias arch/arm/mach-omap2/board-omap3evm.c |3 +- arch/arm/mach-omap2/clock33xx_data.c |2 + arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 44 ++-- arch/arm/mach-omap2/omap_hwmod.c | 31 -- arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +- 6 files changed, 54 insertions(+), 30 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQdEqIAAoJEMePsQ0LvSpLjvYP/RlejvRetwDYUSpwjgre/xfz BA+we3wgi/wgZ3xbdlcFKfdj2l+jzLxspr1pt6MSFzZqJJVKPj1xgHCPJZe4QFX3 waurd+p4OUcO7qKoLQo7up9nfzsI4vnxjyDXjEUCLjAaEq18qqMi4YQEdncotrZU hOL8yFE9ol6Ds2dLtTulnxMfqbMILa5ek+NSVWizbQbVPh8opklRQwRSbYmAgCze USY410kyP/WVXa1hern5UnyEo4nzVpXAFf4+3LVil05p/vWgB4i/JwUINAYNr1sr L1ells+x0z9RKybTNsrDxTQmwY8Jr+TyZJ3uikccFTpqo+TfwcfZN++Qrx+/0Q5z GCVB4dp2aH4QLas9yTFGp/3X2BiPx5AwKX9mqhnOR3peq1lBS1D9V+BTmKAHoY6n w2XzAF3jpE2qNLnxIym46TJYRHGrc1o6U0U5dHxjQZVx796rgUHEIZEfVznWj6lS GaU3b8YQKN3EPKbrdIQ2y5bVEf0SnLdiOjJo+tTVBGhQ7eiVMRN6btYt8Fod2Rlq TXleGmDGKUKI43omeALn2fJWgNrm1GIPSPU1aa3TMZQN7qa/FHyAimcY5QOqU+HT uCUmsSukw6oIfWvV8hyN/R7AovvqaKYpyPUvxOM09G/WnoRGahk3eFHpUcEGQGqD 6PQY5o1skH1C4B++o0EL =Yvqo -END PGP SIGNATURE- -- 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: OMAP4: hwmod data: Add McASP data port address space
Hi Benoit,
Have you had a chance to look at this patch? Maybe you want me to submit
it differently or to a different list?
Thanks!
Ricardo
On 09/27/2012 11:33 AM, Ricardo Neri wrote:
McASP has a configuration port and a data port. This patch adds the address
space entry for the data port as described in the OMAP4 TRM.
Also, add names to the address spaces.
Signed-off-by: Ricardo Neri
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f31f3bc..cb5b463 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4951,10 +4951,16 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcasp
= {
static struct omap_hwmod_addr_space omap44xx_mcasp_dma_addrs[] = {
{
+ .name = "cfg",
.pa_start = 0x49028000,
.pa_end = 0x490283ff,
.flags = ADDR_TYPE_RT
},
+ {
+ .name = "dat",
+ .pa_start = 0x4902A000,
+ .pa_end = 0x4902Afff,
+ },
{ }
};
--
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 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
Hi,
On Saturday 06 October 2012 06:08 PM, Russell King - ARM Linux wrote:
Hi,
This series of patches fixes multiple flow control issues with the OMAP
serial driver, and prepares the driver for DMA engine conversion. We
require hardware assisted flow control to work properly for DMA support
otherwise we have no way to properly pause the transmitter.
This is generated against v3.6, and has been developed mainly by testing
on the OMAP4430 SDP platform.
Flow control seems to be really broken in the OMAP serial driver as things
stand today. It just about works with software flow control because the
generic serial core layer is inserting those characters, but only when the
legacy DMA support is not being used. Otherwise, flow control is
completely non-functional.
Issues identified in the OMAP serial driver are:
- set_mctrl() can only assert modem control lines, once asserted it
is not possible to deassert them.
- IXOFF controls sending of XON/XOFF characters, not the reception of
these sequences.
- IXON controls the recognition of XON/XOFF characters, not the transmission
of the same.
- Wrong bitmasks for hardware assisted software flow control. Bit 2
in EFR enables sending of XON2/XOFF2 which are never set.
- No point comparing received characters against XOFF2 ('special character
detect') as XOFF2 is not set.
- Fix multiple places where bits 6 and 5 of MCR are attempted to be
altered, but because EFR ECB is unset, these bits remain unaffected.
This effectively prevents us accessing the right XON/XOFF/TCR/TLR
registers.
- Remove unnecessary read-backs of EFR/MCR/LCR registers - these registers
don't change beneath us, they are configuration registers which hold their
values. Not only does this simplify the code, but it makes it more
readable, and more importantly ensures that we work from a consistent
state where ->efr never has ECB set, and ->mcr never has the TCRTLR
bit set.
- Fix disablement of hardware flow control and IXANY modes; once enabled
these could never be disabled because nothing in the code ever clears
these configuration bits.
Once that lot is fixed, these patches expand serial_core to permit hardware
assisted flow control by:
- adding throttle/unthrottle callbacks into low level serial drivers,
which allow them to take whatever action is necessary with hardware
assisted flow control to throttle the remote end. In the case of
OMAP serial, this means disabling the RX interrupts so that the FIFO
fills to the watermark.
We then have a number of cleanups to the OMAP serial code to make the
set_termios() function clearer and less prone to the kinds of mistakes
identified above. This results in a great simplification of the flow
control configuration code.
The OMAP serial driver hacks around with the transmit buffer allocation;
lets clean that up so that drivers can cleanly allocate their transmitter
buffer using coherent memory if that's what they desire.
Finally, the last few patches clean up the plat/omap-serial.h header file,
moving most of its contents into the OMAP serial driver itself. Most of
this is private to the OMAP serial driver and should never have been
shared with anything else.
I have omitted to include the conversion of the transmit paths to DMA
engine. Even with all the above fixed, it has issues when DMA transmit
is in progress, and a program issues a TCSETS call (as `less' does after
it has written its prompt.) At the moment, this causes lots of junk to
be emitted from the serial port when issuing `dmesg | less' which sometimes
brings the port to a complete halt.
As the OMAP DMA hardware does not have a clean pause when performing a
MEM->DEV transfer (it discards its FIFO) I do not see a solution to this,
which probably means that we can _not_ ever support transmit DMA on OMAP
platforms.
This means the xmit buffer allocation patches are not that useful unless
a solution to that can be found.
Now, the remaining question is, how much of this patch set do we think
about merging, and when. Given that flow control in this driver has been
broken for a very long time, and no one has apparantly noticed, I don't
think there's any urgency to this, so given its size, my preference would
be to queue it up for the next merge window. The thing that would worry
me about applying some of the initial patches is that they may change
the behaviour today and make any problems here more visible.
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Boot Tested this patch series against v3.6 tag(applied cleanly) on panda
board and
PM tested(hitting off in Idle and suspend) on omap3630 based beagle board.
Note, I also tested the patches against the current master but only
after rebasing, since the current master includes serial patches from
Felipe Balbi[1].
[1] https://lkml.org/lkml/2012/8/24/1
Re: omap DSS cmdline resolution not working for HDMI?
On Fri, 2012-10-05 at 09:43 -0700, Tony Lindgren wrote: > Looks like somehow also output_size won't change when changing > display output from DVI to HDMI. > > If I boot with DVI panel at 1600x1200, then try to switch to the > HDMI monitor with the following script: > > #!/bin/sh > > export dvi=display0 > export hdmi=display1 > export overlay=overlay0 > > echo 0 > /sys/devices/platform/omapdss/$dvi/enabled > echo 1 > /sys/devices/platform/omapdss/$hdmi/enabled > echo "85500,1366/70/213/143,768/3/24/3" > > /sys/devices/platform/omapdss/$hdmi/timings > echo 0 > /sys/devices/platform/omapdss/$overlay/enabled > echo tv > /sys/devices/platform/omapdss/$overlay/manager > #echo "1366,768" > /sys/devices/platform/omapdss/$overlay/output_size > echo 1 > /sys/devices/platform/omapdss/$overlay/enabled > cat /sys/devices/platform/omapdss/$hdmi/timings > cat /sys/devices/platform/omapdss/$overlay/output_size > > I get the following which may provide more clues: > > [64370.820312] omapdss DISPC error: SYNC_LOST on channel tv, restarting the > output with video overlays dd > [64370.831024] omapdss OVERLAY error: overlay 0 horizontally not inside the > display area (0 + 1600 >= 13) > [64370.840972] omapdss APPLY error: failed to enable manager 1: > check_settings failed > [64370.849670] omapdss HDMI error: failed to power on device > [64370.855407] omapdss error: failed to power on > [64370.862487] omapdss OVERLAY error: overlay 0 horizontally not inside the > display area (0 + 1600 >= 13) > [64370.872436] omapdss APPLY error: failed to enable manager 1: > check_settings failed > [64370.880798] omapdss HDMI error: failed to power on device > [64370.886505] omapdss error: failed to power on > 85500,1366/70/213/143,768/3/24/3 > 1600,1200 Well, it's not that simple =). There are three things to consider: - Framebuffer in the sdram. It has xres and yres parameters. - Overlay, and it's input size (from fb) and output sizes (must fit into the display). - Display, which has certain size depending on video mode. Only VID overlays can have different input and output sizes, GFX overlay does not support scaling. In the script above you don't change the fb at all. You can do that with when the overlay is disabled, for example: fbset -xres 1366 -vxres 1366 -yres 768 -vyres 768 But that only works if there's enough memory allocated for the framebuffer, but that is the case for you if the fb was bigger initially. Otherwise you need to set the new size with /sys/class/graphics/fb0/size before resizing the fb. And, of course, the framebuffer cannot be in use at that time by, for example, X. Yes, it's complex! I hope omapdrm will make all things simple, and we can forget omapfb. In hindsight, I should've designed omapfb to be much simpler, and only use gfx overlay. Making it support all overlays is a never ending source for problems and complexity. > FYI, I'm also seeing the DVI monitor blank out on it's own for > about a second or so on regular basis every 10 minutes or so. > No idea what's causing that, maybe it's a reminder to take > a short break :) Well that's something different. I've recently done some testing with using DSI PLL for generating pixel clock, and I've seen unstabilities with that. But perhaps there's something else wrong also, even when using the PRCM for pix clock as in your case. Does your monitor ever report something like bad signal or such? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Tony, On Tuesday 09 October 2012 08:31 AM, Tony Lindgren wrote: * Afzal Mohammed [121005 09:02]: Proposed generic routine has been tested on OneNAND (async) on OMAP3EVM rev C (as mainline does not have the OneNAND support for this, local patch were used to test). For other cases of custom timing calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing calculation routine was verified by simulating on OMAP3EVM. Have you tested to make sure this works if you change the L3 frequency? With changed L3 frequency it was not tested. I do not have a single board that is supported in mainline that calculates on the run gpmc timing from device timing. What has been tested here is OneNAND working in asynchronous mode on omap3evm, but it's support is not available in mainline, so private patch had to be used to test it. All other peripherals were tested by simulation, i.e. by comparing output from existing custom timing routine & generic routine for particular frequencies. That should probably be tested as a sanity check. Maybe you can force the L3 for some test boots for this, I don't think we scale it by default. On omap3evm, don't know whether L3 frequency can be changed & still have a working Kernel. I am not sure whether it is worth attempting as OneNAND on omap3evm is not supported in mainline. 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: [PATCHv2 2/3] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
On Tue, 2012-10-09 at 12:54 +, Hiremath, Vaibhav wrote: > On Tue, Oct 09, 2012 at 18:00:25, Valkeinen, Tomi wrote: > > Now that vrfb driver is not omap dependent anymore, we can move vrfb.h > > from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h. > > > > Which baseline you are using? I tried it with linux-omap/master, patch[1/3] > is failing - It's based on omapdss master, which is what I've sent in the pull request for 3.7. > patching file arch/arm/plat-omap/include/plat/vrfb.h > patching file drivers/media/video/omap/omap_vout.c > Hunk #1 FAILED at 45. > 1 out of 1 hunk FAILED -- saving rejects to file > drivers/media/video/omap/omap_vout.c.rej > patching file drivers/media/video/omap/omap_vout_vrfb.c > Hunk #1 FAILED at 17. > 1 out of 1 hunk FAILED -- saving rejects to file > drivers/media/video/omap/omap_vout_vrfb.c.rej > patching file drivers/media/video/omap/omap_voutdef.h > Hunk #1 FAILED at 12. > 1 out of 1 hunk FAILED -- saving rejects to file > drivers/media/video/omap/omap_voutdef.h.rej > patching file drivers/video/omap2/omapfb/omapfb-ioctl.c > patching file drivers/video/omap2/omapfb/omapfb-main.c > Hunk #1 succeeded at 33 with fuzz 2 (offset 1 line). > patching file drivers/video/omap2/omapfb/omapfb-sysfs.c > patching file drivers/video/omap2/vrfb.c > patching file include/video/omapvrfb.h > > > > Note that, the directory structure has been changed in the mainline, > Now V4L2 OMAP Display driver is in "drivers/media/platform/omap/" > > You have to rebase the patches and resend it. Yep, I'll rebase it on top of 3.7-rc1 when that's out, so that Tony can pull that branch into his tree also. I guess the omap_vout changes should apply easily, as it's just include filename changes. Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCHv2 2/3] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
On Tue, Oct 09, 2012 at 18:00:25, Valkeinen, Tomi wrote:
> Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
> from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.
>
Which baseline you are using? I tried it with linux-omap/master, patch[1/3] is
failing -
patching file arch/arm/plat-omap/include/plat/vrfb.h
patching file drivers/media/video/omap/omap_vout.c
Hunk #1 FAILED at 45.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/video/omap/omap_vout.c.rej
patching file drivers/media/video/omap/omap_vout_vrfb.c
Hunk #1 FAILED at 17.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/video/omap/omap_vout_vrfb.c.rej
patching file drivers/media/video/omap/omap_voutdef.h
Hunk #1 FAILED at 12.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/media/video/omap/omap_voutdef.h.rej
patching file drivers/video/omap2/omapfb/omapfb-ioctl.c
patching file drivers/video/omap2/omapfb/omapfb-main.c
Hunk #1 succeeded at 33 with fuzz 2 (offset 1 line).
patching file drivers/video/omap2/omapfb/omapfb-sysfs.c
patching file drivers/video/omap2/vrfb.c
patching file include/video/omapvrfb.h
Note that, the directory structure has been changed in the mainline,
Now V4L2 OMAP Display driver is in "drivers/media/platform/omap/"
You have to rebase the patches and resend it.
Thanks,
Vaibhav
> Signed-off-by: Tomi Valkeinen
> Cc: Tony Lindgren
> Cc: Vaibhav Hiremath
> ---
> arch/arm/plat-omap/include/plat/vrfb.h| 66
> -
> drivers/media/video/omap/omap_vout.c |2 +-
> drivers/media/video/omap/omap_vout_vrfb.c |2 +-
> drivers/media/video/omap/omap_voutdef.h |2 +-
> drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +-
> drivers/video/omap2/omapfb/omapfb-main.c |2 +-
> drivers/video/omap2/omapfb/omapfb-sysfs.c |2 +-
> drivers/video/omap2/vrfb.c|2 +-
> include/video/omapvrfb.h | 66
> +
> 9 files changed, 73 insertions(+), 73 deletions(-)
> delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
> create mode 100644 include/video/omapvrfb.h
>
> diff --git a/arch/arm/plat-omap/include/plat/vrfb.h
> b/arch/arm/plat-omap/include/plat/vrfb.h
> deleted file mode 100644
> index dafbb77..000
> --- a/arch/arm/plat-omap/include/plat/vrfb.h
> +++ /dev/null
> @@ -1,66 +0,0 @@
> -/*
> - * VRFB Rotation Engine
> - *
> - * Copyright (C) 2009 Nokia Corporation
> - * Author: Tomi Valkeinen
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but
> - * WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> - * General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License along
> - * with this program; if not, write to the Free Software Foundation, Inc.,
> - * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> - */
> -
> -#ifndef __OMAP_VRFB_H__
> -#define __OMAP_VRFB_H__
> -
> -#define OMAP_VRFB_LINE_LEN 2048
> -
> -struct vrfb {
> - u8 context;
> - void __iomem *vaddr[4];
> - unsigned long paddr[4];
> - u16 xres;
> - u16 yres;
> - u16 xoffset;
> - u16 yoffset;
> - u8 bytespp;
> - bool yuv_mode;
> -};
> -
> -#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
> -extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
> -extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
> -extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
> - u8 bytespp);
> -extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
> -extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
> -extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
> - u16 width, u16 height,
> - unsigned bytespp, bool yuv_mode);
> -extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
> -extern void omap_vrfb_restore_context(void);
> -
> -#else
> -static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
> -static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
> -static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
> - u8 bytespp) {}
> -static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
> - { return 0; }
> -static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
> - { return 0; }
> -static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
> - u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
> -static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
> - { return 0; }
> -static inline vo
RE: [PATCH 4/4] mtd: nand: omap2: Add data correction support
On Fri, Oct 05, 2012 at 19:53:38, Ivan Djelic wrote:
> On Fri, Oct 05, 2012 at 09:51:50AM +0100, Philip, Avinash wrote:
> > On Thu, Oct 04, 2012 at 15:51:03, Philip, Avinash wrote:
> > > On Thu, Oct 04, 2012 at 00:50:45, Ivan Djelic wrote:
> > > > On Wed, Oct 03, 2012 at 03:29:49PM +0100, Philip, Avinash wrote:
> > > > > ELM module can be used for error correction of BCH 4 & 8 bit. Also
> > > > > support read & write page in one shot by adding custom read_page &
> > > > > write_page methods. This helps in optimizing code.
> > > > >
> > > > > New structure member "is_elm_used" is added to know the status of
> > > > > whether the ELM module is used for error correction or not.
> > > > >
> > > > > Note:
> > > > > ECC layout of BCH8 uses 14 bytes for 512 byte of data to make
> > > > > compatible
> > > > > with RBL ECC layout, even though the requirement was only 13 byte.
> > > > > This
> > > > > results a common ecc layout across RBL, U-boot & Linux.
> > > > >
> > > >
> > > > See a few comments below,
> > > >
> > > > (...)
> > > > > +static int omap_elm_correct_data(struct mtd_info *mtd, u_char *dat,
> > > > > + u_char *read_ecc, u_char *calc_ecc)
> > > > > +{
> > > > > + struct omap_nand_info *info = container_of(mtd, struct
> > > > > omap_nand_info,
> > > > > + mtd);
> > > > > + int eccsteps = info->nand.ecc.steps;
> > > > > + int i , j, stat = 0;
> > > > > + int eccsize, eccflag, size;
> > > > > + struct elm_errorvec err_vec[ERROR_VECTOR_MAX];
> > > > > + u_char *ecc_vec = calc_ecc;
> > > > > + enum bch_ecc type;
> > > > > + bool is_error_reported = false;
> > > > > +
> > > > > + /* initialize elm error vector to zero */
> > > > > + memset(err_vec, 0, sizeof(err_vec));
> > > > > + if (info->nand.ecc.strength == BCH8_MAX_ERROR) {
> > > > > + size = BCH8_SIZE;
> > > > > + eccsize = BCH8_ECC_OOB_BYTES;
> > > > > + type = BCH8_ECC;
> > > > > + } else {
> > > > > + size = BCH4_SIZE;
> > > > > + eccsize = BCH4_SIZE;
> > > > > + type = BCH4_ECC;
> > > > > + }
> > > > > +
> > > > > + for (i = 0; i < eccsteps ; i++) {
> > > > > + eccflag = 0;/* initialize eccflag */
> > > > > +
> > > > > + for (j = 0; (j < eccsize); j++) {
> > > > > + if (read_ecc[j] != 0xFF) {
> > > > > + eccflag = 1;/* data area is
> > > > > flashed */
> > > >
> > > > Just a reminder: this way of checking if a page has been programmed is
> > > > not robust to bitflips,
> > > > so you may get into trouble with UBIFS on a fairly recent device.
> >
> > Sorry I missed this point.
> >
> > Here we were checking data in spare area (only in ecc layout 14*4 for BCH8)
> > is 0xFF. If all data
> > in spare area is 0xFF, conclude that the page is erased & no need of error
> > correction. In case
> > of bit flip present in spare area, page will be reported as uncorrectable.
> > But I am not understand understand " trouble with UBIFS on a fairly recent
> > device".
> > Can you little elaborativ
>
> There are at least 2 potential problems when reading an erased page with
> bitflips:
>
> 1. bitflip in data area and no bitflip in spare area (all 0xff)
> Your code will not perform any ECC correction.
> UBIFS does not like finding bitflips in empty pages, see for instance
> http://lists.infradead.org/pipermail/linux-mtd/2012-March/040328.html.
In case of error correction using ELM, syndrome vector calculated after reading
Data area & OOB area. So handling of erased page requires a software workaround.
I am planning something as follows.
I will first check calculated ecc, which would be zero for non error pages.
Then I would check 0xFF in OOB area (for erased page) by checking number of
bit zeros in OOB area. If it is 0xFF (number of bit zero count is zero),
set entire page as 0xFF if number of bit zeros is less than max bit flips
(8 or 4) by counting the number of bit zero's in data area.
This logic is implemented in fsmc_nand.c
See commit
mtd: fsmc: Newly erased page read algorithm implemented
>
> 2. bitflip in ECC bytes in spare area
> Your code will report an uncorrectable error upon reading; if this happens
> while reading a partially programmed UBI block,
> I guess you will lose data.
In case of uncorrectable errors due to bit flips in spare area,
I can go on checking number of bit zero's in data area + OOB area
are less than max bit flips (8 or 4), I can go on setting the entire
page as 0xFF.
Thanks
Avinash
>
> BR,
> --
> Ivan
>
--
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
[PATCHv2 3/3] OMAP: SDRC: remove VRFB code
Now that VRFB driver handles its registers independently, we can remove
the VRFB related code from OMAP's sdrc.
Signed-off-by: Tomi Valkeinen
Cc: Tony Lindgren
---
arch/arm/mach-omap2/sdrc.c | 16
arch/arm/plat-omap/include/plat/sdrc.h |7 ---
2 files changed, 23 deletions(-)
diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c
index e3d345f..4282e6e 100644
--- a/arch/arm/mach-omap2/sdrc.c
+++ b/arch/arm/mach-omap2/sdrc.c
@@ -160,19 +160,3 @@ void __init omap2_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
sdrc_write_reg(l, SDRC_POWER);
omap2_sms_save_context();
}
-
-void omap2_sms_write_rot_control(u32 val, unsigned ctx)
-{
- sms_write_reg(val, SMS_ROT_CONTROL(ctx));
-}
-
-void omap2_sms_write_rot_size(u32 val, unsigned ctx)
-{
- sms_write_reg(val, SMS_ROT_SIZE(ctx));
-}
-
-void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx)
-{
- sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx));
-}
-
diff --git a/arch/arm/plat-omap/include/plat/sdrc.h
b/arch/arm/plat-omap/include/plat/sdrc.h
index 36d6a76..c68bab2 100644
--- a/arch/arm/plat-omap/include/plat/sdrc.h
+++ b/arch/arm/plat-omap/include/plat/sdrc.h
@@ -94,9 +94,6 @@
/* SMS register offsets - read/write with sms_{read,write}_reg() */
#define SMS_SYSCONFIG 0x010
-#define SMS_ROT_CONTROL(context) (0x180 + 0x10 * context)
-#define SMS_ROT_SIZE(context) (0x184 + 0x10 * context)
-#define SMS_ROT_PHYSICAL_BA(context) (0x188 + 0x10 * context)
/* REVISIT: fill in other SMS registers here */
@@ -137,10 +134,6 @@ int omap2_sdrc_get_params(unsigned long r,
void omap2_sms_save_context(void);
void omap2_sms_restore_context(void);
-void omap2_sms_write_rot_control(u32 val, unsigned ctx);
-void omap2_sms_write_rot_size(u32 val, unsigned ctx);
-void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx);
-
#ifdef CONFIG_ARCH_OMAP2
struct memory_timings {
--
1.7.9.5
--
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
[PATCHv2 2/3] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
Now that vrfb driver is not omap dependent anymore, we can move vrfb.h
from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h.
Signed-off-by: Tomi Valkeinen
Cc: Tony Lindgren
Cc: Vaibhav Hiremath
---
arch/arm/plat-omap/include/plat/vrfb.h| 66 -
drivers/media/video/omap/omap_vout.c |2 +-
drivers/media/video/omap/omap_vout_vrfb.c |2 +-
drivers/media/video/omap/omap_voutdef.h |2 +-
drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +-
drivers/video/omap2/omapfb/omapfb-main.c |2 +-
drivers/video/omap2/omapfb/omapfb-sysfs.c |2 +-
drivers/video/omap2/vrfb.c|2 +-
include/video/omapvrfb.h | 66 +
9 files changed, 73 insertions(+), 73 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h
create mode 100644 include/video/omapvrfb.h
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h
b/arch/arm/plat-omap/include/plat/vrfb.h
deleted file mode 100644
index dafbb77..000
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
- * VRFB Rotation Engine
- *
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __OMAP_VRFB_H__
-#define __OMAP_VRFB_H__
-
-#define OMAP_VRFB_LINE_LEN 2048
-
-struct vrfb {
- u8 context;
- void __iomem *vaddr[4];
- unsigned long paddr[4];
- u16 xres;
- u16 yres;
- u16 xoffset;
- u16 yoffset;
- u8 bytespp;
- bool yuv_mode;
-};
-
-#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
-extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
-extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
-extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
- u8 bytespp);
-extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp);
-extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp);
-extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
- u16 width, u16 height,
- unsigned bytespp, bool yuv_mode);
-extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot);
-extern void omap_vrfb_restore_context(void);
-
-#else
-static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; }
-static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {}
-static inline void omap_vrfb_adjust_size(u16 *width, u16 *height,
- u8 bytespp) {}
-static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp)
- { return 0; }
-static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp)
- { return 0; }
-static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr,
- u16 width, u16 height, unsigned bytespp, bool yuv_mode) {}
-static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot)
- { return 0; }
-static inline void omap_vrfb_restore_context(void) {}
-#endif
-#endif /* __VRFB_H */
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index f721fd2..940f39f 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -45,7 +45,7 @@
#include
#include
-#include
+#include
#include
#include "omap_voutlib.h"
diff --git a/drivers/media/video/omap/omap_vout_vrfb.c
b/drivers/media/video/omap/omap_vout_vrfb.c
index 4be26abf6c..6c37f92 100644
--- a/drivers/media/video/omap/omap_vout_vrfb.c
+++ b/drivers/media/video/omap/omap_vout_vrfb.c
@@ -17,7 +17,7 @@
#include
#include
-#include
+#include
#include "omap_voutdef.h"
#include "omap_voutlib.h"
diff --git a/drivers/media/video/omap/omap_voutdef.h
b/drivers/media/video/omap/omap_voutdef.h
index 27a95d2..9ccfe1f 100644
--- a/drivers/media/video/omap/omap_voutdef.h
+++ b/drivers/media/video/omap/omap_voutdef.h
@@ -12,7 +12,7 @@
#define OMAP_VOUTDEF_H
#include
-#include
+#include
#define YUYV_BPP2
#define RGB565_BPP 2
diff --git a/drivers/video/omap2/omapfb/omapfb-ioctl.c
b/drivers/video/omap2/omapfb/omapfb-ioctl.c
index 606b89f..55a39be 100644
--- a/drivers/video/omap2/omapfb/omapfb-ioctl.c
+++ b/drivers/video/omap2/omapfb/omapfb-ioctl.c
@@ -30,7 +30,7 @@
#include
#include
-#include
+#include
[PATCHv2 1/3] OMAP: VRFB: convert vrfb to platform device
This patch converts vrfb library into a platform device, in an effort to
remove omap dependencies.
The platform device is registered in arch/arm/plat-omap/fb.c and
assigned resources depending on whether running on omap2 or omap3.
The vrfb driver will parse those resources and use them to access vrfb
configuration registers and the vrfb virtual rotation areas.
Signed-off-by: Tomi Valkeinen
Cc: Tony Lindgren
---
arch/arm/plat-omap/fb.c| 59 +++
arch/arm/plat-omap/include/plat/vrfb.h |2 +-
drivers/video/omap2/Kconfig|2 +-
drivers/video/omap2/vrfb.c | 124 ++--
4 files changed, 165 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
index dd6f92c..a390784 100644
--- a/arch/arm/plat-omap/fb.c
+++ b/arch/arm/plat-omap/fb.c
@@ -35,6 +35,65 @@
#include
+#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
+
+/*
+ * The first memory resource is the register region for VRFB,
+ * the rest are VRFB virtual memory areas for each VRFB context.
+ */
+
+static const struct resource omap2_vrfb_resources[] = {
+ DEFINE_RES_MEM_NAMED(0x68008000u, 0x40, "vrfb-regs"),
+ DEFINE_RES_MEM_NAMED(0x7000u, 0x400, "vrfb-area-0"),
+ DEFINE_RES_MEM_NAMED(0x7400u, 0x400, "vrfb-area-1"),
+ DEFINE_RES_MEM_NAMED(0x7800u, 0x400, "vrfb-area-2"),
+ DEFINE_RES_MEM_NAMED(0x7c00u, 0x400, "vrfb-area-3"),
+};
+
+static const struct resource omap3_vrfb_resources[] = {
+ DEFINE_RES_MEM_NAMED(0x6C000180u, 0xc0, "vrfb-regs"),
+ DEFINE_RES_MEM_NAMED(0x7000u, 0x400, "vrfb-area-0"),
+ DEFINE_RES_MEM_NAMED(0x7400u, 0x400, "vrfb-area-1"),
+ DEFINE_RES_MEM_NAMED(0x7800u, 0x400, "vrfb-area-2"),
+ DEFINE_RES_MEM_NAMED(0x7c00u, 0x400, "vrfb-area-3"),
+ DEFINE_RES_MEM_NAMED(0xe000u, 0x400, "vrfb-area-4"),
+ DEFINE_RES_MEM_NAMED(0xe400u, 0x400, "vrfb-area-5"),
+ DEFINE_RES_MEM_NAMED(0xe800u, 0x400, "vrfb-area-6"),
+ DEFINE_RES_MEM_NAMED(0xec00u, 0x400, "vrfb-area-7"),
+ DEFINE_RES_MEM_NAMED(0xf000u, 0x400, "vrfb-area-8"),
+ DEFINE_RES_MEM_NAMED(0xf400u, 0x400, "vrfb-area-9"),
+ DEFINE_RES_MEM_NAMED(0xf800u, 0x400, "vrfb-area-10"),
+ DEFINE_RES_MEM_NAMED(0xfc00u, 0x400, "vrfb-area-11"),
+};
+
+static int __init omap_init_vrfb(void)
+{
+ struct platform_device *pdev;
+ const struct resource *res;
+ unsigned int num_res;
+
+ if (cpu_is_omap24xx()) {
+ res = omap2_vrfb_resources;
+ num_res = ARRAY_SIZE(omap2_vrfb_resources);
+ } else if (cpu_is_omap34xx()) {
+ res = omap3_vrfb_resources;
+ num_res = ARRAY_SIZE(omap3_vrfb_resources);
+ } else {
+ return 0;
+ }
+
+ pdev = platform_device_register_resndata(NULL, "omapvrfb", -1,
+ res, num_res, NULL, 0);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+ else
+ return 0;
+}
+
+arch_initcall(omap_init_vrfb);
+#endif
+
#if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE)
static bool omapfb_lcd_configured;
diff --git a/arch/arm/plat-omap/include/plat/vrfb.h
b/arch/arm/plat-omap/include/plat/vrfb.h
index 3792bde..dafbb77 100644
--- a/arch/arm/plat-omap/include/plat/vrfb.h
+++ b/arch/arm/plat-omap/include/plat/vrfb.h
@@ -35,7 +35,7 @@ struct vrfb {
bool yuv_mode;
};
-#ifdef CONFIG_OMAP2_VRFB
+#if defined(CONFIG_OMAP2_VRFB) || defined(CONFIG_OMAP2_VRFB_MODULE)
extern int omap_vrfb_request_ctx(struct vrfb *vrfb);
extern void omap_vrfb_release_ctx(struct vrfb *vrfb);
extern void omap_vrfb_adjust_size(u16 *width, u16 *height,
diff --git a/drivers/video/omap2/Kconfig b/drivers/video/omap2/Kconfig
index d877c36..4700ca9 100644
--- a/drivers/video/omap2/Kconfig
+++ b/drivers/video/omap2/Kconfig
@@ -2,7 +2,7 @@ config OMAP2_VRAM
bool
config OMAP2_VRFB
- bool
+ tristate
source "drivers/video/omap2/dss/Kconfig"
source "drivers/video/omap2/omapfb/Kconfig"
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 7e99022..fda45cc 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -26,9 +26,9 @@
#include
#include
#include
+#include
#include
-#include
#ifdef DEBUG
#define DBG(format, ...) pr_debug("VRFB: " format, ## __VA_ARGS__)
@@ -36,10 +36,10 @@
#define DBG(format, ...)
#endif
-#define SMS_ROT_VIRT_BASE(context, rot) \
- (((context >= 4) ? 0xD000 : 0x7000) \
-+ (0x400 * (context)) \
-+ (0x100 * (rot)))
+#define SMS_ROT_CONTROL(context) (0x0 + 0x10 * context)
+#define SMS_ROT_SIZE(context) (0x4 + 0x10 * context)
+#define SMS_ROT_PHYSICAL_BA(context) (0x8 + 0x10 * context)
+#define SMS_ROT_VIRT_BASE(rot
[PATCHv2 0/3] OMAP: VRFB: convert to platform device
Hi, This is second version of the patch series. The changes to v1 are: * request mem region for VRFB registers * declare VRFB resources with names * remove unused VRFB code from sdrc * vrfb is now tristate, so that it can be built as a module Tomi Tomi Valkeinen (3): OMAP: VRFB: convert vrfb to platform device OMAP: move arch/arm/plat-omap/include/plat/vrfb.h OMAP: SDRC: remove VRFB code arch/arm/mach-omap2/sdrc.c| 16 arch/arm/plat-omap/fb.c | 59 ++ arch/arm/plat-omap/include/plat/sdrc.h|7 -- arch/arm/plat-omap/include/plat/vrfb.h| 66 --- drivers/media/video/omap/omap_vout.c |2 +- drivers/media/video/omap/omap_vout_vrfb.c |2 +- drivers/media/video/omap/omap_voutdef.h |2 +- drivers/video/omap2/Kconfig |2 +- drivers/video/omap2/omapfb/omapfb-ioctl.c |2 +- drivers/video/omap2/omapfb/omapfb-main.c |2 +- drivers/video/omap2/omapfb/omapfb-sysfs.c |2 +- drivers/video/omap2/vrfb.c| 126 - include/video/omapvrfb.h | 66 +++ 13 files changed, 237 insertions(+), 117 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h create mode 100644 include/video/omapvrfb.h -- 1.7.9.5 -- 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/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
On 10/08/2012 07:35 PM, Tony Lindgren wrote: > - omap-dma.c and omap-pcm.c can test the arch locally as > omap1 and omap2 cannot be compiled together because of > conflicting compiler flags > sound/soc/omap/omap-pcm.c |9 +++-- Tony: is this going to be included in 3.7? Acked-by: Peter Ujfalusi -- 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+: gpmc: Fix kernel BUG for DT boot mode
With recent changes in omap gpmc driver code, in case of DT
boot mode, where bootloader does not configure gpmc cs space
will result into kernel BUG() inside gpmc_mem_init() function,
as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
gpmc_config7[0].baseaddress is set to '0' on reset.
This use-case is applicable for any board/EVM which doesn't have
any peripheral connected to gpmc cs0, for example BeagleXM and
BeagleBone, so DT boot mode fails.
This patch adds of_have_populated_dt() check before creating
device, so that for DT boot mode, gpmc probe will not be called
which is expected behavior, as gpmc is not supported yet from DT.
Signed-off-by: Vaibhav Hiremath
Cc: Afzal Mohammed
Cc: Tony Lindgren
Cc Paul Walmsley
---
This should go in for rc1, as this breaks AM33xx boot.
arch/arm/mach-omap2/gpmc.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8ab1e1b..c68f9e1 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -981,6 +981,10 @@ static int __init omap_gpmc_init(void)
struct platform_device *pdev;
char *oh_name = "gpmc";
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
oh = omap_hwmod_lookup(oh_name);
if (!oh) {
pr_err("Could not look up %s\n", oh_name);
--
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 1/2] OMAP: VRFB: convert vrfb to platform device
On Mon, 2012-10-08 at 10:24 -0700, Tony Lindgren wrote:
> * Tomi Valkeinen [121008 05:31]:
> > This patch converts vrfb library into a platform device, in an effort to
> > remove omap dependencies.
> >
> > The platform device is registered in arch/arm/plat-omap/fb.c and
> > assigned resources depending on whether running on omap2 or omap3.
> >
> > The vrfb driver will parse those resources and use them to access vrfb
> > configuration registers and the vrfb virtual rotation areas.
> >
> > Signed-off-by: Tomi Valkeinen
> > Cc: Tony Lindgren
> > ---
> > arch/arm/plat-omap/fb.c| 53 +++
> > drivers/video/omap2/vrfb.c | 124
> > +---
> > 2 files changed, 157 insertions(+), 20 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c
> > index dd6f92c..d231912 100644
> > --- a/arch/arm/plat-omap/fb.c
> > +++ b/arch/arm/plat-omap/fb.c
> > @@ -35,6 +35,59 @@
> >
> > #include
> >
> > +#if defined(CONFIG_OMAP2_VRFB)
> > +static const struct resource omap2_vrfb_resources[] = {
> > + DEFINE_RES_MEM(0x68008000u, 0x40),
> > + DEFINE_RES_MEM(0x7000u, 0x400),
> > + DEFINE_RES_MEM(0x7400u, 0x400),
> > + DEFINE_RES_MEM(0x7800u, 0x400),
> > + DEFINE_RES_MEM(0x7c00u, 0x400),
> > +};
> > +
> > +static const struct resource omap3_vrfb_resources[] = {
> > + DEFINE_RES_MEM(0x6C000180u, 0xc0),
> > + DEFINE_RES_MEM(0x7000u, 0x400),
> > + DEFINE_RES_MEM(0x7400u, 0x400),
> > + DEFINE_RES_MEM(0x7800u, 0x400),
> > + DEFINE_RES_MEM(0x7c00u, 0x400),
> > + DEFINE_RES_MEM(0xe000u, 0x400),
> > + DEFINE_RES_MEM(0xe400u, 0x400),
> > + DEFINE_RES_MEM(0xe800u, 0x400),
> > + DEFINE_RES_MEM(0xec00u, 0x400),
> > + DEFINE_RES_MEM(0xf000u, 0x400),
> > + DEFINE_RES_MEM(0xf400u, 0x400),
> > + DEFINE_RES_MEM(0xf800u, 0x400),
> > + DEFINE_RES_MEM(0xfc00u, 0x400),
> > +};
>
> Maybe add comments describing what these register are in case
> we have a framework handling them at some point later on?
Sure.
> > --- a/drivers/video/omap2/vrfb.c
> > +++ b/drivers/video/omap2/vrfb.c
> > +#define SMS_ROT_CONTROL(context) (0x0 + 0x10 * context)
> > +#define SMS_ROT_SIZE(context) (0x4 + 0x10 * context)
> > +#define SMS_ROT_PHYSICAL_BA(context) (0x8 + 0x10 * context)
> > +#define SMS_ROT_VIRT_BASE(rot) (0x100 * (rot))
>
> Can you please also remove the old SMS defines and functions
> so other code won't start tinkering with them?
Ok.
> > +static int __init vrfb_probe(struct platform_device *pdev)
> > +{
> > + struct resource *mem;
> > + int i;
> > +
> > + /* first resource is the register res, the rest are vrfb contexts */
> > +
> > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!mem) {
> > + dev_err(&pdev->dev, "can't get vrfb base address\n");
> > + return -EINVAL;
> > + }
>
> Now that we assume vrfb is the only user of this, so you must do
> request_mem_region here as that's the only protection we have.
> If that fails here, then we know something is wrong.
Right, I'll add that.
> > + vrfb_base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
> > + if (!vrfb_base) {
> > + dev_err(&pdev->dev, "can't ioremap vrfb memory\n");
> > + return -ENOMEM;
> > + }
> > +
> > + num_ctxs = pdev->num_resources - 1;
> > +
> > + ctxs = devm_kzalloc(&pdev->dev,
> > + sizeof(struct vrfb_ctx) * num_ctxs,
> > + GFP_KERNEL);
> > +
> > + if (!ctxs)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < num_ctxs; ++i) {
> > + mem = platform_get_resource(pdev, IORESOURCE_MEM, 1 + i);
> > + if (!mem) {
> > + dev_err(&pdev->dev, "can't get vrfb ctx %d address\n",
> > + i);
> > + return -EINVAL;
> > + }
> > +
> > + ctxs[i].base = mem->start;
> > + }
>
> And request_mem_region must also be done for these registers to make
> sure no other code is using them. Again, if it fails, something is
> wrong.
There's already request_mem_region for the VRFB virtual areas, which is
done later when omapfb or somebody else requests a vrfb context with
omap_vrfb_request_ctx(). The memory areas (they are rotated
framebuffers, not registers as such) are not used until then.
Tomi
signature.asc
Description: This is a digitally signed message part
RE: Issue with _are_all_hardreset_lines_asserted()
On Tue, Oct 09, 2012 at 12:29:53, Paul Walmsley wrote:
> On Tue, 9 Oct 2012, Archit Taneja wrote:
>
> > The patch looks fine to me. I tried it out for DSS(with an additional patch
> > to
> > not represent DSS modulemode bits as a slave clock), and modulemode is
> > getting
> > disabled correctly now.
>
> Thanks, I added your Tested-by: and also updated the patch description
> which was a little unclear.
>
>
> - Paul
>
> From: Paul Walmsley
> Date: Mon, 8 Oct 2012 23:08:15 -0600
> Subject: [PATCH] ARM: OMAP4/AM335x: hwmod: fix disable_module regression in
> hardreset handling
>
> Commit eb05f691290e99ee0bd1672317d6add789523c1e ("ARM: OMAP: hwmod:
> partially un-reset hwmods might not be properly enabled") added code
> to skip the IP block disable sequence if all of the block's hardreset
> lines weren't asserted. But this did not handle the case when no
> hardreset lines were associated with a module, which is the general
> case. In that situation, the IP block disable would be skipped. This
> is likely to cause PM regressions.
>
> So, modify _omap4_disable_module() and _am33xx_disable_module() to
> only bail out early if there are any hardreset lines asserted. And
> move the AM33xx test above the actual module disable code to ensure
> that the behavior is consistent.
>
Paul,
I just tested it on Bone + one gpmc fix (will submit shortly) and it boots
up fine for me. I have also tested for module disable, and it works.
Tested-by: Vaibhav Hiremath
Acked-by: Vaibhav Hiremath
Log for reference -
[0.749504] _clkctrl_idlest:109 inst - 0, clkctrl_offs - 84, v - 2
[0.749630] omap_hwmod: timer3: _am33xx_disable_module
[0.749652] _clkctrl_idlest:109 inst - 0, clkctrl_offs - 84, v - 3
[0.749819] _clkctrl_idlest:109 inst - 0, clkctrl_offs - 88, v - 30002
[0.749841] _clkctrl_idlest:109 inst - 0, clkctrl_offs - 88, v - 2
[0.749904] omap_hwmod: timer4: _am33xx_disable_module
[0.749923] _clkctrl_idlest:109 inst - 0, clkctrl_offs - 88, v - 3
[0.750131] _clkctrl_idlest:109 inst - 0, clkctrl_offs - ec, v - 10002
[0.750152] _clkctrl_idlest:109 inst - 0, clkctrl_offs - ec, v - 2
[0.750218] omap_hwmod: timer5: _am33xx_disable_module
[0.750236] _clkctrl_idlest:109 inst - 0, clkctrl_offs - ec, v - 1
[0.750253] _clkctrl_idlest:109 inst - 0, clkctrl_offs - ec, v - 3
[0.750404] _clkctrl_idlest:109 inst - 0, clkctrl_offs - f0, v - 30002
[0.750423] _clkctrl_idlest:109 inst - 0, clkctrl_offs - f0, v - 2
[0.750485] omap_hwmod: timer6: _am33xx_disable_module
[0.750504] _clkctrl_idlest:109 inst - 0, clkctrl_offs - f0, v - 1
[0.750520] _clkctrl_idlest:109 inst - 0, clkctrl_offs - f0, v - 3
[0.750666] _clkctrl_idlest:109 inst - 0, clkctrl_offs - 7c, v - 30002
[0.750685] _clkctrl_idlest:109 inst - 0, clkctrl_offs - 7c, v - 2
[0.750747] omap_hwmod: timer7: _am33xx_disable_module
[0.750765] _clkctrl_idlest:109 inst - 0, clkctrl_offs - 7c, v - 1
[0.750782] _clkctrl_idlest:109 inst - 0, clkctrl_offs - 7c, v - 3
Thanks,
Vaibhav
> Reported-by: Archit Taneja
> Tested-by: Archit Taneja # DSS
> Cc: Omar Ramirez Luna
> Cc: Vaibhav Hiremath
> Signed-off-by: Paul Walmsley
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 31 +++
> 1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 299ca28..b969ab1 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -1698,6 +1698,29 @@ static bool _are_all_hardreset_lines_asserted(struct
> omap_hwmod *oh)
> }
>
> /**
> + * _are_any_hardreset_lines_asserted - return true if any part of @oh is
> + * hard-reset
> + * @oh: struct omap_hwmod *
> + *
> + * If any hardreset lines associated with @oh are asserted, then
> + * return true. Otherwise, if no hardreset lines associated with @oh
> + * are asserted, or if @oh has no hardreset lines, then return false.
> + * This function is used to avoid executing some parts of the IP block
> + * enable/disable sequence if any hardreset line is set.
> + */
> +static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh)
> +{
> + int rst_cnt = 0;
> + int i;
> +
> + for (i = 0; i < oh->rst_lines_cnt && rst_cnt == 0; i++)
> + if (_read_hardreset(oh, oh->rst_lines[i].name) > 0)
> + rst_cnt++;
> +
> + return (rst_cnt) ? true : false;
> +}
> +
> +/**
> * _omap4_disable_module - enable CLKCTRL modulemode on OMAP4
> * @oh: struct omap_hwmod *
> *
> @@ -1715,7 +1738,7 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
>* Since integration code might still be doing something, only
>* disable if all lines are under hardreset.
>*/
> - if (!_are_all_hardreset_lines_asserted(oh))
> + if (_are_any_hardreset_lines_asserted(oh))
> return 0;
>
> pr_debug("omap_hwmod:
Re: Issue with _are_all_hardreset_lines_asserted()
On Tue, 9 Oct 2012, Archit Taneja wrote:
> The patch looks fine to me. I tried it out for DSS(with an additional patch to
> not represent DSS modulemode bits as a slave clock), and modulemode is getting
> disabled correctly now.
Thanks, I added your Tested-by: and also updated the patch description
which was a little unclear.
- Paul
From: Paul Walmsley
Date: Mon, 8 Oct 2012 23:08:15 -0600
Subject: [PATCH] ARM: OMAP4/AM335x: hwmod: fix disable_module regression in
hardreset handling
Commit eb05f691290e99ee0bd1672317d6add789523c1e ("ARM: OMAP: hwmod:
partially un-reset hwmods might not be properly enabled") added code
to skip the IP block disable sequence if all of the block's hardreset
lines weren't asserted. But this did not handle the case when no
hardreset lines were associated with a module, which is the general
case. In that situation, the IP block disable would be skipped. This
is likely to cause PM regressions.
So, modify _omap4_disable_module() and _am33xx_disable_module() to
only bail out early if there are any hardreset lines asserted. And
move the AM33xx test above the actual module disable code to ensure
that the behavior is consistent.
Reported-by: Archit Taneja
Tested-by: Archit Taneja # DSS
Cc: Omar Ramirez Luna
Cc: Vaibhav Hiremath
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 299ca28..b969ab1 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1698,6 +1698,29 @@ static bool _are_all_hardreset_lines_asserted(struct
omap_hwmod *oh)
}
/**
+ * _are_any_hardreset_lines_asserted - return true if any part of @oh is
+ * hard-reset
+ * @oh: struct omap_hwmod *
+ *
+ * If any hardreset lines associated with @oh are asserted, then
+ * return true. Otherwise, if no hardreset lines associated with @oh
+ * are asserted, or if @oh has no hardreset lines, then return false.
+ * This function is used to avoid executing some parts of the IP block
+ * enable/disable sequence if any hardreset line is set.
+ */
+static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh)
+{
+ int rst_cnt = 0;
+ int i;
+
+ for (i = 0; i < oh->rst_lines_cnt && rst_cnt == 0; i++)
+ if (_read_hardreset(oh, oh->rst_lines[i].name) > 0)
+ rst_cnt++;
+
+ return (rst_cnt) ? true : false;
+}
+
+/**
* _omap4_disable_module - enable CLKCTRL modulemode on OMAP4
* @oh: struct omap_hwmod *
*
@@ -1715,7 +1738,7 @@ static int _omap4_disable_module(struct omap_hwmod *oh)
* Since integration code might still be doing something, only
* disable if all lines are under hardreset.
*/
- if (!_are_all_hardreset_lines_asserted(oh))
+ if (_are_any_hardreset_lines_asserted(oh))
return 0;
pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__);
@@ -1749,12 +1772,12 @@ static int _am33xx_disable_module(struct omap_hwmod *oh)
pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__);
+ if (_are_any_hardreset_lines_asserted(oh))
+ return 0;
+
am33xx_cm_module_disable(oh->clkdm->cm_inst, oh->clkdm->clkdm_offs,
oh->prcm.omap4.clkctrl_offs);
- if (_are_all_hardreset_lines_asserted(oh))
- return 0;
-
v = _am33xx_wait_target_disable(oh);
if (v)
pr_warn("omap_hwmod: %s: _wait_target_disable failed\n",
--
1.7.10.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
