Manager width and height can go up to 4K on OMAP5. Make manager width and height
register field offsets and maximum limits as dispc_features. Create a new
dispc_feature struct for OMAP5 which highlights this difference.
Archit Taneja (2):
OMAPDSS: Add overlay manager width and height limits as
The overlay manager width and height vary in OMAP5 vary from previous OMAPs in
terms of maximum limit and register field positions. Add parameters in
dispc_features for these. Remove params related to manager width and height from
dss_features. We do this because we want to maintain a feature list
Add a dispc_features struct for OMAP5. Previously, OMAP5 used the same struct
as OMAP4. The new struct for OMAP5 contains the updated register field offset
and maximum limit for overlay manager width and height.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |
OMAP* allnoconfig fails:
arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput'
arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_init_postsetup':
twl-common.c:(.init.text+0x8f8): undefined
Hi Omar,
On Wed, Nov 14, 2012 at 4:34 AM, Omar Ramirez Luna omar.l...@linaro.org wrote:
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
Hi Russell,
On 11/14/2012 10:26 AM, Russell King - ARM Linux wrote:
OMAP* allnoconfig fails:
arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput'
arch/arm/mach-omap2/built-in.o: In function
Hi Mark,
On 11/14/2012 08:00 AM, Mark Brown wrote:
On Wed, Nov 14, 2012 at 06:49:58AM +, AnilKumar, Chimata wrote:
Earlier you have a comment on this thread, I am adding my comments
on top of it. Sorry if I am in wrong direction.
Ah, I see. I was just commenting because Benoit was
On 14/11/12 02:30, Ricardo Neri wrote:
Being the name of a machine driver, it aims to describe the connection between
the HDMI IP of the processor and the companion chip it uses to connect to the
outside world. This name tries to follow the same naming convention as in
the OMAP-ABE-TWL6040
Hi Vaibhav,
I'd like to get clarity on the omap_vout maintenance. You've been the
maintainer of omap_vout, but you have lately been quite inactive in this
role, and getting omap_vout patches merged has not been as fluent as it
could be.
Do you still want to continue in this role? Will you have
On Wed, Nov 14, 2012 at 11:08:49AM +0100, Benoit Cousson wrote:
I was wondering that, because exposing a pin to control the whole PMIC
low power mode seems to be something that should be generic enough to be
handled by the regulator framework.
Having something that's controlled by software is
On Wed, Nov 14, 2012 at 11:08:35AM +0100, Peter Ujfalusi wrote:
Hi Russell,
On 11/14/2012 10:26 AM, Russell King - ARM Linux wrote:
OMAP* allnoconfig fails:
arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
twl-common.c:(.text+0x1e08): undefined reference to
On Tue, Nov 06, 2012 at 04:31:32PM +, Paul Walmsley wrote:
This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc.
Here giving the patch name in parens would have really made sense.
Will fix that.
This commit causes I2C timeouts to appear on several OMAP3430/3530-based
boards:
Currently we just queue the transfer and release the
qos constraints, however we donot wait for the transfer
to complete to release the constraint. Move the remove
constraint after the bus busy as we are sure that the
transfers are completed by then.
Signed-off-by: Shubhrajyoti D
Hi Wolfram,
On Wed, Nov 14, 2012 at 11:51 AM, Wolfram Sang w.s...@pengutronix.de wrote:
On Tue, Nov 06, 2012 at 04:31:32PM +, Paul Walmsley wrote:
This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc.
Here giving the patch name in parens would have really made sense.
Will fix
Hi Wolfram, Shubhrajyoti,
On Wed, Nov 14, 2012 at 11:57 AM, Wolfram Sang w.s...@pengutronix.de wrote:
Currently we just queue the transfer and release the
qos constraints, however we donot wait for the transfer
to complete to release the constraint. Move the remove
constraint after the
On Mon, Oct 22, 2012 at 10:42:01AM +0300, Felipe Balbi wrote:
Hi,
On Tue, Oct 16, 2012 at 05:23:20PM +0200, Sebastien Guiriec wrote:
Some GPIO expanders need some early pin control muxing. Due to
legacy boards sometimes the driver uses subsys_initcall instead of
module_init. This patch
On Mon, Nov 05, 2012 at 10:04:43AM +0200, Felipe Balbi wrote:
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
On Wednesday 14 November 2012 04:33 PM, Jean Pihet wrote:
Acked-by: Jean Pihet j-pi...@ti.com
Since I just reverted the QoS patch, I suppose this gets merged into the
original patch when resent?
The best for now is to re-submit a new patch that moves the constraint
release in the original
On 2012-11-14 11:26, Russell King - ARM Linux wrote:
OMAP* allnoconfig fails:
arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
twl-common.c:(.text+0x1e08): undefined reference to `omap_pm_set_min_bus_tput'
arch/arm/mach-omap2/built-in.o: In function
On Mon, Nov 05, 2012 at 05:53:35PM +0530, Shubhrajyoti D wrote:
Shubhrajyoti D (8):
i2c: omap: Fix the revision register read
i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
i2c: omap: remove the dtrev
ARM: i2c: omap: Remove the i207 errata flag
On Wednesday 14 November 2012 05:34 PM, Wolfram Sang wrote:
On Mon, Nov 05, 2012 at 05:53:35PM +0530, Shubhrajyoti D wrote:
Shubhrajyoti D (8):
i2c: omap: Fix the revision register read
i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
i2c: omap: remove the
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
(a simple for loop), when we got to transfer sizes
bigger than the
Hello,
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the AM33xx clock
sysbsystem. A following patch resolves this issue:
diff --git
Hi
On Tue, 13 Nov 2012, Omar Ramirez Luna wrote:
This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path
from enabling modulemode inside CLKCTRL using its clk-enable_reg
field. Instead is left to _omap4_enable_module though soc_ops, as
the one in charge of this setting.
According
On 11/13/2012 12:13 PM, Jon Hunter wrote:
Some source files are including dmtimer.h but not actually using any dmtimer
definitions or functions. Therefore, remove the inclusion dmtimer.h from these
source files.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Hi,
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com wrote:
Hello,
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the AM33xx
clock sysbsystem. A following
On Wed, Nov 14, 2012 at 04:22:45PM +0200, Felipe Balbi wrote:
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
On Tue, Nov 13, 2012 at 11:47:57PM -0800, Kasatkin, Dmitry wrote:
On Fri, Nov 9, 2012 at 9:17 AM, Mark A. Greer mgr...@animalcreek.com wrote:
On Fri, Nov 09, 2012 at 06:28:16PM +0200, Kasatkin, Dmitry wrote:
On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer mgr...@animalcreek.com
wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [121114 03:47]:
On 2012-11-14 11:26, Russell King - ARM Linux wrote:
OMAP* allnoconfig fails:
arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
twl-common.c:(.text+0x1e08): undefined reference to
`omap_pm_set_min_bus_tput'
On 11/14/2012 10:41 AM, Jean Pihet wrote:
Hi,
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com wrote:
Hello,
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in
here's another series for OMAP I2C driver. There are a few cleanups
and one very nice new feature: we can now report how many bytes
we transferred until NACK.
Note that the implemementation for OMAP-I2C turned out to be a
little more complex then I expected, mainly because of the way
* Tony Lindgren t...@atomide.com [121114 08:50]:
* Tomi Valkeinen tomi.valkei...@ti.com [121114 03:47]:
On 2012-11-14 11:26, Russell King - ARM Linux wrote:
OMAP* allnoconfig fails:
arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
Hi Liam,
Thanks for reviewing!
On 11/14/2012 04:16 AM, Liam Girdwood wrote:
On 14/11/12 02:30, Ricardo Neri wrote:
Being the name of a machine driver, it aims to describe the
connection between the HDMI IP of the processor and the companion
chip it uses to connect to the outside world. This
Hi Mark,
Thanks for reviewing!
On 11/13/2012 09:27 PM, Mark Brown wrote:
On Tue, Nov 13, 2012 at 08:30:49PM -0600, Ricardo Neri wrote:
Instead of defining the address offset of the DMA port for transfers of
audio samples, obtain this information from the resources
* Tony Lindgren t...@atomide.com [121114 09:02]:
* Tony Lindgren t...@atomide.com [121114 08:50]:
* Tomi Valkeinen tomi.valkei...@ti.com [121114 03:47]:
On 2012-11-14 11:26, Russell King - ARM Linux wrote:
OMAP* allnoconfig fails:
arch/arm/mach-omap2/built-in.o: In function
Signed-off-by: Wolfram Sang wolf...@the-dreams.de
---
This makes one of my code analyzers happy and makes me a part of the
i2c-omap-patch crowd \o/
drivers/i2c/busses/i2c-omap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
On Wed, Nov 14, 2012 at 01:45:15PM +0200, Tomi Valkeinen wrote:
On 2012-11-14 11:26, Russell King - ARM Linux wrote:
OMAP* allnoconfig fails:
arch/arm/mach-omap2/built-in.o: In function `omap_dss_set_min_bus_tput':
twl-common.c:(.text+0x1e08): undefined reference to
On Wed, Nov 14, 2012 at 09:17:31AM -0800, Tony Lindgren wrote:
Looks like the way to do this not to use oldnoconfig but to do:
$ make KCONFIG_ALLCONFIG=../configs/rmk-omap4430-sdp-noconfig allnoconfig
It seems that oldnoconfig will pick the new options that have default y?
That is the
* Jean Pihet jean.pi...@newoldbits.com [121114 08:43]:
The patch should change the name of the hwmod entry as well, can you
fold this change in the current patch?
This was caused by the merge of omap-for-v3.8/pm into omap-for-v3.8/clock.
I noticed a smilar issue for omap3, but missed at least
Add a new address space/memory resource to d_can device tree node. D_CAN
RAM initialization is achieved through RAMINIT register which is part of
AM33XX control module address space. D_CAN RAM init or de-init should be
done by writing instance corresponding value to control module register.
Till
Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM,
which holds all the message objects during transmission or
receiving of data. This initialization/de-initialization should
be done in synchronous with D_CAN clock.
In case of AM335X-EVM (active user of D_CAN driver) message RAM is
This patch series adds d_can raminit support to c_can/d_can driver,
which is required to init/de-init D_CAN message RAM (holds message
objects). Added corresponding DT changes to get resource of RAMINIT
register and device instance.
These patches were tested on AM335x-EVM along with pinctrl data
Add d_can instances to aliases node to get the D_CAN instance number
from the driver. To initialize D_CAN message RAM, corresponding instance
number is required.
To initialize instance 0 message RAM then 0x1 should be written and for
instance 1 message RAM, 0x2 should be written to control module
Hi,
On Wed, Nov 14, 2012 at 06:21:06PM +0100, Wolfram Sang wrote:
Signed-off-by: Wolfram Sang wolf...@the-dreams.de
fine by me. I'd like to see a commit log (even if obvious) there. But no
strong feelings.
Acked-by: Felipe Balbi ba...@ti.com
---
This makes one of my code analyzers happy
This makes one of my code analyzers happy and makes me a part of the
anything open source which we could all be using ? :-)
'my' as in 'one of those I am using'. It was cppcheck which found that
flaw. Its use for kernel code is limited, but it does find one or the
other thing.
--
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
Unfortunately I don't have the details of errata 751472, but I'm
guessing we need to disable it for
On Wed, Nov 14, 2012 at 10:53:35AM -0800, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
Unfortunately I don't have the
On 11/14/2012 12:53 PM, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
Unfortunately I don't have the details of errata
This patch-series adds support for,
[1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's
[2/7]: Adds parent-child relation between CPSW MDIO module inside cpsw
driver, as in case of AM33XX, the resources are shared and common
register bit-field is provided to control
Enable CPSW support in defconfig which is present in AM33xx SoC
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Acked-by: Richard Cochran richardcoch...@gmail.com
---
arch/arm/configs/omap2plus_defconfig |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
Move network stack halt APIs before halting the hardware to ensure no
packets are queued to hardware during closing the device during
suspend sequence.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Acked-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/ti/cpsw.c |6
From: Richard Cochran richardcoch...@gmail.com
Instead of having a host of different register offsets in the device tree,
this patch simplifies the CPSW code by letting the driver set the proper
register offsets automatically, based on the CPSW version.
Signed-off-by: Richard Cochran
From: Vaibhav Hiremath hvaib...@ti.com
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci family
of devices. Now based on requirement, use-case and available technology
nodes the integration of these sub-modules
From: Vaibhav Hiremath hvaib...@ti.com
By mistake (most likely a copy-paste), instead of pm_runtime_get_sync()
api, driver is calling pm_runtime_put_sync() api in resume callback
function. The bug was introduced by commit id (ae2c07aaf74:
davinci_mdio: runtime PM support).
Now, the reason why it
* Russell King - ARM Linux li...@arm.linux.org.uk [121114 11:03]:
On Wed, Nov 14, 2012 at 10:53:35AM -0800, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor
* Jon Hunter jon-hun...@ti.com [121114 11:09]:
On 11/14/2012 12:53 PM, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
This is a rebase/rework of Frank Hofmann's work, the most recent patchset
being here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/053229.html
The biggest gotcha right now:
If there's any cpu-specific / SoC-specific state that needs (re)init
over a
On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote:
On 11/14/2012 12:53 PM, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an earlier r1p2:
CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7),
* Russell King - ARM Linux li...@arm.linux.org.uk [121114 12:24]:
On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote:
On 11/14/2012 12:53 PM, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot when enabled. The ARM core on it is an
On 11/14/2012 02:32 PM, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [121114 12:24]:
On Wed, Nov 14, 2012 at 01:06:53PM -0600, Jon Hunter wrote:
On 11/14/2012 12:53 PM, Tony Lindgren wrote:
Looks like enabling CONFIG_ARM_ERRATA_751472 causes omap4 blaze
to not boot
* Rob Herring robherri...@gmail.com [121114 13:59]:
On 11/14/2012 02:32 PM, Tony Lindgren wrote:
Checking for the bit already set should work in this case, I'll post
a patch for that shortly.
Can you actually read the state of the diagnostic register in non-secure
mode? If you can on
On Wed, Nov 14, 2012 at 11:07:09AM -0600, Ricardo Neri wrote:
On 11/13/2012 09:27 PM, Mark Brown wrote:
Presumably this needs some other corresponding change in the resource
setup to go in simultaneously...
Yes, the change in the resources setup has been submitted to the
OMAPDSS HDMI driver
* Kevin Hilman khil...@deeprootsystems.com [121113 17:09]:
Tony Lindgren t...@atomide.com writes:
Here's one more booting issue I recently ran into:
- If DEBUG_LL and earlyprintk are enabled, and omap-serial.c
is compiled as a module, the kernel boot hangs early as the
On 11.11.2012 02:56, Daniel Mack wrote:
On 07.11.2012 16:37, Philip, Avinash wrote:
On Wed, Nov 07, 2012 at 15:18:37, Daniel Mack wrote:
On 05.11.2012 14:29, Philip, Avinash wrote:
On Mon, Nov 05, 2012 at 18:28:22, Daniel Mack wrote:
On 05.11.2012 12:03, Philip, Avinash wrote:
On Fri, Nov
From: Kevin Hilman khil...@ti.com
commit c9621844 (ARM: OMAP4: PM: add errata support) introduced errata
handling for OMAP4, but was broken when CONFIG_PM=n.
When CONFIG_PM=n, pm44xx.c is not compiled, yet that is where pm44xx_errata
is defined. However, these errata are needed for the SMP
On 11/14/2012 04:21 PM, Tony Lindgren wrote:
* Rob Herring robherri...@gmail.com [121114 13:59]:
On 11/14/2012 02:32 PM, Tony Lindgren wrote:
Checking for the bit already set should work in this case, I'll post
a patch for that shortly.
Can you actually read the state of the diagnostic
Hi Mike,
On Tuesday 13 November 2012 08:43:23 Mike Turquette wrote:
Quoting Laurent Pinchart (2012-11-13 05:42:35)
On Wednesday 07 November 2012 17:12:35 Mike Turquette wrote:
From: Mike Turquette mturque...@linaro.org
Hi all,
This series is based on top of Paul's PRM/CM
From: Kevin Hilman khil...@ti.com
commit 908b75e8 (ARM: OMAP: add support for oscillator setup) added a new
API for oscillator setup, but is broken when CONFIG_PM=n.
The new functions have dummy definitions when CONFIG_PM=n, but also have
full implementations available, which conflict.
To fix,
* Kevin Hilman khil...@deeprootsystems.com [121114 16:56]:
From: Kevin Hilman khil...@ti.com
commit c9621844 (ARM: OMAP4: PM: add errata support) introduced errata
handling for OMAP4, but was broken when CONFIG_PM=n.
When CONFIG_PM=n, pm44xx.c is not compiled, yet that is where
* Kevin Hilman khil...@deeprootsystems.com [121114 17:15]:
From: Kevin Hilman khil...@ti.com
commit 908b75e8 (ARM: OMAP: add support for oscillator setup) added a new
API for oscillator setup, but is broken when CONFIG_PM=n.
The new functions have dummy definitions when CONFIG_PM=n, but
* Rob Herring robherri...@gmail.com [121114 16:56]:
On 11/14/2012 04:21 PM, Tony Lindgren wrote:
* Rob Herring robherri...@gmail.com [121114 13:59]:
On 11/14/2012 02:32 PM, Tony Lindgren wrote:
Checking for the bit already set should work in this case, I'll post
a patch for that
Hi Mark,
On 11/14/2012 05:08 PM, Mark Brown wrote:
On Wed, Nov 14, 2012 at 11:07:09AM -0600, Ricardo Neri wrote:
On 11/13/2012 09:27 PM, Mark Brown wrote:
Presumably this needs some other corresponding change in the resource
setup to go in simultaneously...
Yes, the change in the
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v3.8/fixes-non-critical-v4-signed
for you to fetch
From: Mugunthan V N mugunthan...@ti.com
Date: Thu, 15 Nov 2012 00:37:53 +0530
This patch-series adds support for,
[1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's
[2/7]: Adds parent-child relation between CPSW MDIO module inside cpsw
driver, as in case of AM33XX,
On Wed, Nov 14, 2012 at 08:33:11PM -0600, Ricardo Neri wrote:
On 11/14/2012 05:08 PM, Mark Brown wrote:
Don't do this. With a change like this which must be made at the same
time over multiple subsystems it is very important that you send all the
but the changes will hit linux-next at some
On Tue, Nov 13, 2012 at 03:38:18PM +0200, Pantelis Antoniou wrote:
Hi Grant,
On Nov 13, 2012, at 2:24 PM, Grant Likely wrote:
On Tue, Nov 13, 2012 at 8:09 AM, Pantelis Antoniou
[snip]
My intention wasn't never to make overlays overly portable. My intention
was to make them in a way that
Currently we just queue the transfer and release the
qos constraints, however we donot wait for the transfer
to complete to release the constraint. Move the remove
constraint after the bus busy as we are sure that the
transfers are completed by then.
Signed-off-by: Shubhrajyoti D
77 matches
Mail list logo
