On 2012-12-18 10:31, Javier Martinez Canillas wrote:
Did you find a solution for this?
Not that I know.
Also I have this log about a locking dependency:
[ 24.690795]
[ 24.690826] ==
[ 24.690826] [ INFO: possible circular locking
On 2012-12-18 15:45, Javier Martinez Canillas wrote:
Hi,
I've tested with the latest stable kernel (Linux 3.7.1) and the video
output is working correctly with the same user-space components.
The complete dmesg is here: http://fpaste.org/1Kv4/
Looking at the logs for both kernels I
On Monday 17 December 2012 05:53 PM, Tomi Valkeinen wrote:
Hi,
On 2012-12-05 12:16, Chandrabhanu Mahapatra wrote:
The DSI specific dss_reg_fields are moved to corresponding dsi_reg_fields
initialized in dsi_feats. The dsi_feats structure is initialized as per
corresponding DSS version in
On Monday 17 December 2012 06:07 PM, Tomi Valkeinen wrote:
On 2012-12-05 12:16, Chandrabhanu Mahapatra wrote:
The register fields in dss_reg_fields specific to DISPC are moved from struct
omap_dss_features to corresponding dispc_reg_fields, initialized in struct
dispc_features, thereby
On Sat, Dec 15, 2012 at 1:52 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
commit 5a8095e9 ARM: dts: Add omap3-beagle.dts
moved the VSIM regulator definition to the twl4030.dtsi to avoid
duplication. A definition for the VSIM regulator was also present
on omap3-igep.dtsi
On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:
damn, this is still part of our v3.7-rc kernel. Original commit was done
with no testing whatsoever and caused a big regression to (at least)
TI's WiFi driver which depend on SDIO to function.
Too bad things break and even when
prom_add_property() has been renamed to of_add_property()
This patch fixes the following comilation error:
arch/arm/mach-omap2/timer.c: In function ‘omap_get_timer_dt’:
arch/arm/mach-omap2/timer.c:178:3: error: implicit declaration of function
‘prom_add_property’
Hello,
downscaling a YUV video from /dev/fb1 silently fails and results in
incorrectly rendered data (each line is shifted a bit more to the right,
turning vertical lines into diagonals) -- observed with Linux 3.6.11 on
omap3/dm3730
test data (an image with vertical bars) is produced by:
On 12/19/2012 10:45 AM, Mark Brown wrote:
On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:
damn, this is still part of our v3.7-rc kernel. Original commit was done
with no testing whatsoever and caused a big regression to (at least)
TI's WiFi driver which depend on SDIO to
Hi Mark,
On Wed, 2012-12-19 at 09:45 +, Mark Brown wrote:
On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:
damn, this is still part of our v3.7-rc kernel. Original commit was done
with no testing whatsoever and caused a big regression to (at least)
TI's WiFi driver which
In the map for reset sources register we use defines intended for
using with PRM_RSTCTRL register. So fix it.
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/mach-omap2/prm44xx.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
To read reset sources registers we have to use PRM_DEVICE_INST
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/mach-omap2/prm44xx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index
From: Nishanth Menon n...@ti.com
RSTTIME is offset 0x8 and RSTST is offset 0x04 for OMAP4430 and
OMAP4460.
Signed-off-by: Nishanth Menon n...@ti.com
[ivan.khoronz...@ti.com: ported from k3.4]
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/mach-omap2/prm44xx.h |4 ++--
1
On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote:
I don't know the state of the common clock framework for OMAPs. Is it already
up in 3.7? Or going for 3.8? 3.9? 3.10?...
We need CCF to resolve this. I can cook up the clock driver for the 32k clock
from twl, but in order to use
Hi Peter, Tony
On Wed, Dec 19, 2012 at 15:20:09, Ujfalusi, Peter wrote:
prom_add_property() has been renamed to of_add_property()
This patch fixes the following comilation error:
arch/arm/mach-omap2/timer.c: In function ‘omap_get_timer_dt’:
arch/arm/mach-omap2/timer.c:178:3: error: implicit
Hi,
On Wednesday 19 December 2012 03:21 PM, Peter Meerwald wrote:
Hello,
downscaling a YUV video from /dev/fb1 silently fails and results in
incorrectly rendered data (each line is shifted a bit more to the right,
turning vertical lines into diagonals) -- observed with Linux 3.6.11 on
On 12/19/2012 11:09 AM, Mark Brown wrote:
On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote:
I don't know the state of the common clock framework for OMAPs. Is it already
up in 3.7? Or going for 3.8? 3.9? 3.10?...
We need CCF to resolve this. I can cook up the clock driver for
On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote:
I think one of the reasons not many people use the mainline with TWL is
exactly because something seems to break on every new kernel release.
I'm one of those who care and report things when I see them.
Well, it's a recursive
On Wed, Dec 19, 2012 at 11:18:11AM +0100, Peter Ujfalusi wrote:
Sure. It must be a clock driver. I already have similar driver (for McPDM fclk
clock) for twl6040.
Let me check linux-next, if CCF is there for OMAP I can send the 32k clock
driver soon (after writing it and testing it). It is
On Wed, 2012-12-19 at 10:28 +, Mark Brown wrote:
On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote:
I think one of the reasons not many people use the mainline with TWL is
exactly because something seems to break on every new kernel release.
I'm one of those who care and
On Wed, 2012-12-19 at 10:32 +, Mark Brown wrote:
On Wed, Dec 19, 2012 at 11:18:11AM +0100, Peter Ujfalusi wrote:
Sure. It must be a clock driver. I already have similar driver (for McPDM
fclk
clock) for twl6040.
Let me check linux-next, if CCF is there for OMAP I can send the 32k
Hello,
In the case we set it to 4, the DISPC_FCLK is fast enough to do the required
downscaling, but in the case when it's set to 0, it might need to pre decimate
rather than try to scale.
this is my understanding as well
I think there is a bug downscaling YUV data when resorting to
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably related to the 32kHz clock in some way (unless
it was one of the other reverts that coincidentally made a difference,
but we don't know what they
On 12/19/2012 11:56 AM, Peter Ujfalusi wrote:
BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
added there:
f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
Which means that _essential_ clocks and pads are no longer configured.
Meanwhile
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
0e8e5c34 regulator: twl: Remove references to 32kHz clock from DT bindings
e76ab829 regulator: twl: Remove references to the twl4030 regulator
029dd3ce regulator: twl: Remove
Hi,
Current mainline on Beaglebone using the omap2plus_defconfig + 3 build fixes
is triggering a BUG()
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.7.0-01415-g55bc169 (a0393953@psplinux063) (gcc
version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Wed Dec 19
On Wed, 2012-12-19 at 11:56 +0100, Peter Ujfalusi wrote:
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably related to the 32kHz clock in some way (unless
it was one of the other reverts that
On 2012-12-19 12:51, Peter Meerwald wrote:
Hello,
In the case we set it to 4, the DISPC_FCLK is fast enough to do the required
downscaling, but in the case when it's set to 0, it might need to pre
decimate
rather than try to scale.
this is my understanding as well
I think there is a
On 2012-12-19 13:19, Tomi Valkeinen wrote:
On 2012-12-19 12:51, Peter Meerwald wrote:
Hello,
In the case we set it to 4, the DISPC_FCLK is fast enough to do the required
downscaling, but in the case when it's set to 0, it might need to pre
decimate
rather than try to scale.
this is my
On Wednesday 19 December 2012 04:51 PM, Tomi Valkeinen wrote:
On 2012-12-19 13:19, Tomi Valkeinen wrote:
On 2012-12-19 12:51, Peter Meerwald wrote:
Hello,
In the case we set it to 4, the DISPC_FCLK is fast enough to do the required
downscaling, but in the case when it's set to 0, it might
On 2012-12-19 13:52, Archit Taneja wrote:
On Wednesday 19 December 2012 04:51 PM, Tomi Valkeinen wrote:
On 2012-12-19 13:19, Tomi Valkeinen wrote:
On 2012-12-19 12:51, Peter Meerwald wrote:
Hello,
In the case we set it to 4, the DISPC_FCLK is fast enough to do the
required
downscaling, but
One thing I'm guessing is that DMA fetching with predecimation isn't really
optimised for omap3, if the pixel clock in Peter's setup is high, the DISPC
DMA might not be able to fetch pixels fast enough in predecimation case. That
sort of supports the possibility of a skewed image seen.
Do
On Wednesday 19 December 2012 05:29 PM, Tomi Valkeinen wrote:
On 2012-12-19 13:52, Archit Taneja wrote:
On Wednesday 19 December 2012 04:51 PM, Tomi Valkeinen wrote:
On 2012-12-19 13:19, Tomi Valkeinen wrote:
On 2012-12-19 12:51, Peter Meerwald wrote:
Hello,
In the case we set it to 4, the
Many OMAP3 based boards such as Beagle, Overo and IGEP use
the TFP410 DPI-to-DVI chip. So, it's good to have it built
as a module by default on OMAP2+ config.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/configs/omap2plus_defconfig |1 +
1 files
The OMAP framebuffer driver now uses the standard dma allocator
instead of the (now removed) omap specific vram allocator.
Enable the Contiguous Memory Allocator by default to allow large
dma memory buffers allocation.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Hi Javier,
On 12/19/2012 10:31 AM, Javier Martinez Canillas wrote:
On Sat, Dec 15, 2012 at 1:52 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
commit 5a8095e9 ARM: dts: Add omap3-beagle.dts
moved the VSIM regulator definition to the twl4030.dtsi to avoid
duplication. A
On 2012-12-19 14:19, Archit Taneja wrote:
The image I get is stable, and clearly something that happens when, say,
row_inc is one pixel too much, or similar.
Ok, about the width in this case. The original width is 400, and what we
finally want is 220. After pre-decimation, the width would
On Wed, Dec 19, 2012 at 1:36 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Javier,
On 12/19/2012 10:31 AM, Javier Martinez Canillas wrote:
On Sat, Dec 15, 2012 at 1:52 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
commit 5a8095e9 ARM: dts: Add omap3-beagle.dts
moved
On Wednesday 19 December 2012 06:07 PM, Tomi Valkeinen wrote:
On 2012-12-19 14:19, Archit Taneja wrote:
The image I get is stable, and clearly something that happens when, say,
row_inc is one pixel too much, or similar.
Ok, about the width in this case. The original width is 400, and what we
Hi,
+Sricharan who commited that
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably related to the 32kHz clock in some way (unless
On 2012-12-19 15:00, Archit Taneja wrote:
On Wednesday 19 December 2012 06:07 PM, Tomi Valkeinen wrote:
On 2012-12-19 14:19, Archit Taneja wrote:
The image I get is stable, and clearly something that happens when,
say,
row_inc is one pixel too much, or similar.
Ok, about the width in this
IGEP technology devices are TI OMAP3 SoC based industrial embedded
and computer-on-module boards. This patch-set adds initial device
tree support for these devices.
The device trees allows to boot from an MMC and are working all the
components that already have device tree support on OMAP3 SoCs:
ISEE IGEPv2 is an TI OMAP3 SoC based embedded board.
This patch adds an initial device tree support to boot
an IGEPv2 from the MMC/SD.
Currently is working everything that is supported by DT
on OMAP3 SoCs (MMC/SD, GPIO LEDs, EEPROM, TWL4030 audio).
Signed-off-by: Javier Martinez Canillas
ISEE IGEP COM Module is an TI OMAP3 SoC computer on module.
This patch adds an initial device tree support to boot an
IGEP COM Module from the MMC/SD.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
---
Changes since
On 12/19/2012 02:01 PM, Felipe Balbi wrote:
Hi,
+Sricharan who commited that
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably
Hi,
On Wed, Dec 19, 2012 at 02:51:14PM +0100, Benoit Cousson wrote:
On 12/19/2012 02:01 PM, Felipe Balbi wrote:
Hi,
+Sricharan who commited that
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't
On Wed, Dec 19, 2012 at 02:51:14PM +0100, Benoit Cousson wrote:
Regarding the 32k clock, I noticed as well that the OMAP4460 panda
u-boot is the only one to enable it at boot time, and thus this is the
only board that can probe the wilink chip properly as of today.
Well, there was nothing in
On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote:
On 12/19/2012 02:01 PM, Felipe Balbi wrote:
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
BTW: have you happened to ubdate u-boot recently? There is a nice easter
egg
added there:
f3f98bb ARM: OMAP4/5: Do not
On 12/19/2012 02:58 PM, Luciano Coelho wrote:
On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote:
On 12/19/2012 02:01 PM, Felipe Balbi wrote:
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
BTW: have you happened to ubdate u-boot recently? There is a nice easter
egg
On 12/19/2012 02:01 PM, Felipe Balbi wrote:
Hi,
+Sricharan who commited that
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
On 12/19/2012 11:45 AM, Luciano Coelho wrote:
Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably
On 2012-12-19 14:33, Javier Martinez Canillas wrote:
Many OMAP3 based boards such as Beagle, Overo and IGEP use
the TFP410 DPI-to-DVI chip. So, it's good to have it built
as a module by default on OMAP2+ config.
Also on OMAP4 boards, like Panda.
Signed-off-by: Javier Martinez Canillas
* Peter Ujfalusi peter.ujfal...@ti.com [121219 02:20]:
On 12/19/2012 11:09 AM, Mark Brown wrote:
On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote:
I don't know the state of the common clock framework for OMAPs. Is it
already
up in 3.7? Or going for 3.8? 3.9? 3.10?...
* Vaibhav Bedia vaibhav.be...@ti.com [121218 22:49]:
Merge commit 752451f (Merge branch 'i2c-embedded/for-next' of
git://git.pengutronix.de/git/wsa/linux)
resulted in a build breakage for OMAP
...
arch/arm/mach-omap2/i2c.c: In function
'omap_pm_set_max_mpu_wakeup_lat_compat':
* Bedia, Vaibhav vaibhav.be...@ti.com [121219 02:18]:
Hi Peter, Tony
On Wed, Dec 19, 2012 at 15:20:09, Ujfalusi, Peter wrote:
prom_add_property() has been renamed to of_add_property()
This patch fixes the following comilation error:
arch/arm/mach-omap2/timer.c: In function
On Wed, 19 Dec 2012, Bedia, Vaibhav wrote:
Current mainline on Beaglebone using the omap2plus_defconfig + 3 build fixes
is triggering a BUG()
...
[0.109688] Security Framework initialized
[0.109889] Mount-cache hash table entries: 512
[0.112674] BUG: spinlock bad magic on
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote:
In the map for reset sources register we use defines intended for
using with PRM_RSTCTRL register. So fix it.
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
Thanks, queued for v3.8-rc fixes.
- Paul
--
To unsubscribe from this list: send
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote:
From: Nishanth Menon n...@ti.com
RSTTIME is offset 0x8 and RSTST is offset 0x04 for OMAP4430 and
OMAP4460.
Signed-off-by: Nishanth Menon n...@ti.com
[ivan.khoronz...@ti.com: ported from k3.4]
Signed-off-by: Ivan Khoronzhuk
On Wed, 19 Dec 2012, Ivan Khoronzhuk wrote:
To read reset sources registers we have to use PRM_DEVICE_INST
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
Thanks, queued for v3.8-rc fixes.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
Hi Vinod,
On 11/15/2012 07:37 PM, Vinod Koul wrote:
On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote:
Hi Vinod,
A few people have been asking me if getting device-tree support for DMA
engine is plan for record for v3.8. I know that you were working through
implementing a common interface
Hi Arnd Olof,
Here's few more trivial build fixes caused by the merge
conflicts.
Tony
The following changes since commit 5031a2a7c12b837a0913c4139ebeb6bbff5e1aa5:
Merge tag 'for-v3.8-part2' of git://git.infradead.org/battery-2.6 (2012-12-19
08:14:08 -0800)
are available in the git
Hi,
On Wednesday 19 December 2012 07:34 PM, Benoit Cousson wrote:
On 12/19/2012 02:58 PM, Luciano Coelho wrote:
On Wed, 2012-12-19 at 14:51 +0100, Benoit Cousson wrote:
On 12/19/2012 02:01 PM, Felipe Balbi wrote:
On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
BTW: have you
Hi all,
These patches enable multiplatform support for omap2plus.
To build and boot it against the current mainline kernel
you need the following:
[PATCH 1/2] ARM: l2x0: Only set .set_debug on PL310 r3p0 and earlier
[PATCH 2/2] ARM: disable errata work-arounds which access secure registers
[GIT
We need to make sure that multiplatform kernels don't
run omap initcalls when booted on other SoCs.
Do this by adding wrapper macros for the initcalls that
return early if soc_is_omap() test fails. This allows
us to easily change the defines later if we have SoC
specific init sections available.
This way the initcalls don't run on other SoCs on multiplatform
kernels. Otherwise we'll get something like this when booting
on vexpress:
omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet
registered
...
WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94()
We only want this initcall to run when the kernel is
booted on omap SoCs. Fix the issue by initializing the
the initcall from separately for omap1 and omap2+.
This fixes the issue for omap2+ multiplatform configs
as we are using omap_subsys_initcall there.
Signed-off-by: Tony Lindgren
Otherwise omap dmaengine will initialized when booted
on other SoCs. Fix this by initializing the platform
device in arch/arm/*omap*/dma.c instead.
Cc: Russell King li...@arm.linux.org.uk
Cc: Dan Williams d...@fb.com
Cc: Vinod Koul vinod.k...@intel.com
Signed-off-by: Tony Lindgren
Add multiplatform debug_ll support by stripping away
the custom hacks to detect the port from debug-macro.S.
Note that this now requires the specific debug_ll port to
be selected in the .config.
The old debug-macro.S will be removed a bit later
once we are sure things work properly with
Flip on multiplatform support for omap2+.
No changes to omap2plus_defconfig needed, but please note
that you may need to update your custom config files to
make sure you have:
CONFIG_ARCH_MULTIPLATFORM=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_OMAP2PLUS=y
And may need CONFIG_ARCH_MULTI_V6=y if
We still need to fix up few places for multiplatform support,
but that can proceed separately. Fix the issue by making the
problem drivers depends !ARCH_MULTIPLATFORM for now.
The remaining pieces that are not multiplatform compatible
for omap2+ SoCs are:
1. Some drivers are using custom
With multiplatform support enabled we are now always
building in vexpress. Let's enable few drivers also as
this allows us to boot omap2plus zImage in qemu for
testing multiplaform related changes.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/configs/omap2plus_defconfig |4
On 12/19/12 08:53, Paul Walmsley wrote:
On Wed, 19 Dec 2012, Bedia, Vaibhav wrote:
Current mainline on Beaglebone using the omap2plus_defconfig + 3 build fixes
is triggering a BUG()
...
[0.109688] Security Framework initialized
[0.109889] Mount-cache hash table entries: 512
[
On Thu, 6 Dec 2012 11:52:06 +0100, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Use more coherent locking in the driver. Use bitfield to store the GPIO
direction and if the pin is configured as output store the status also in a
bitfiled.
In this way we can just look at these bitfields when we
On Thu, 6 Dec 2012 11:52:07 +0100, Peter Ujfalusi peter.ujfal...@ti.com wrote:
This GPIO driver should not configure anything else then GPIOs.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
I'm not sure if this is the right direction. I actually have no problem
with a single driver that
On Thu, 6 Dec 2012 11:52:05 +0100, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Move most of the global variables inside a private structure and allocate
it dynamically.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Applied, thanks
g.
---
drivers/gpio/gpio-twl4030.c | 82
Hi
Grant Likely grant.lik...@secretlab.ca wrote:
On Thu, 6 Dec 2012 11:52:06 +0100, Peter Ujfalusi
peter.ujfal...@ti.com wrote:
Use more coherent locking in the driver. Use bitfield to store the
GPIO
direction and if the pin is configured as output store the status
also in a
bitfiled.
In
Hi Paul,
On 12/09/2012 02:03 PM, Paul Walmsley wrote:
There's no need to determine the current power state for powerdomains
that must be on while the kernel is running. We mark these
powerdomains with a new flag, PWRDM_ACTIVE_WITH_KERNEL. Any
powerdomain marked with that flag is reported as
Add needed platform data so that it's possible to use Retu and e.g. feed
Retu watchdog.
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/mach-omap1/board-nokia770.c | 43 ++
1 file changed, 43 insertions(+)
diff --git
There seems to be a longstanding bug that OHCI USB host controller
does not respond on 1710, possibly because of wrong clocks. Has it ever
worked? See e.g. http://marc.info/?l=linux-omapm=119634441229321w=2. All
register reads return just zeroes:
[1.896606] ohci ohci: OMAP OHCI
[1.912597]
On Wed, 19 Dec 2012 21:53:23 +0100, Michael Trimarchi
mich...@amarulasolutions.com wrote:
Hi
Grant Likely grant.lik...@secretlab.ca wrote:
On Thu, 6 Dec 2012 11:52:06 +0100, Peter Ujfalusi
peter.ujfal...@ti.com wrote:
Use more coherent locking in the driver. Use bitfield to store the
On Fri, 14 Dec 2012 18:05:53 +1100, NeilBrown ne...@suse.de wrote:
On Mon, 10 Sep 2012 10:57:07 -0700 Kevin Hilman khil...@deeprootsystems.com
wrote:
OK thanks, I'll queue this up for v3.6-rc as this should qualify as a
regression.
I don't think this did actually get queued. At least
Hi,
* Aaro Koskinen aaro.koski...@iki.fi [121219 14:10]:
There seems to be a longstanding bug that OHCI USB host controller
does not respond on 1710, possibly because of wrong clocks. Has it ever
worked?
Don't know about 770, but I used to have an old CF card reader
hooked to my osk5912 and
On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
On Tue, 18 Dec 2012, Hebbar Gururaja wrote:
From: Hebbar, Gururaja gururaja.heb...@ti.com
omap4_cminst_wait_module_ready() checks if register offset is NULL.
int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
On Thu, Dec 20, 2012 at 01:53:42, Stephen Boyd wrote:
On 12/19/12 08:53, Paul Walmsley wrote:
On Wed, 19 Dec 2012, Bedia, Vaibhav wrote:
Current mainline on Beaglebone using the omap2plus_defconfig + 3 build
fixes
is triggering a BUG()
...
[0.109688] Security Framework
On Monday 17 December 2012 02:57 PM, Andreas Fenkart wrote:
Please add some changelog here too.
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
---
Patch seems straight forward thought will be interesting where you found
the need of it.
drivers/gpio/gpio-omap.c |2
On 12/19/2012 8:48 PM, Bedia, Vaibhav wrote:
I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM)
have DDR2
and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these at the same
point.
With Stephen's change I don't see this on any of the board variants :)
New
On Monday 17 December 2012 01:33 AM, Tony Lindgren wrote:
Hi all,
Finally it can be dropped. Thanks for help everybody.
Looks fine to me with update plat/cpu.h patch. Thanks
to you as well for all those patches.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from
On Thu, Dec 20, 2012 at 11:55:24, Stephen Boyd wrote:
On 12/19/2012 8:48 PM, Bedia, Vaibhav wrote:
I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM)
have DDR2
and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these at the same
point.
With Stephen's
On 12/19/2012 10:44 PM, Bedia, Vaibhav wrote:
On Thu, Dec 20, 2012 at 11:55:24, Stephen Boyd wrote:
On 12/19/2012 8:48 PM, Bedia, Vaibhav wrote:
I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM)
have DDR2
and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these
On Thu, 20 Dec 2012, Hebbar, Gururaja wrote:
On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
We've got a few hwmods on OMAP44xx that don't have clkctrl_offs registers
listed in the hwmod data, and which are not marked with HWMOD_NO_IDLEST.
What's going to happen in those cases?
The atomic64 library uses a handful of static spin locks to
implement atomic 64-bit operations on architectures without
support for atomic 64-bit instructions. Unfortunately, the
spinlocks are initialized in a pure initcall and that is too late
for the vfs namespace code which wants to use
90 matches
Mail list logo
