On 3/25/2013 3:54 PM, Viresh Kumar wrote:
On 25 March 2013 15:11, Sekhar Nori nsek...@ti.com wrote:
So down in the cpufreq driver probe below, we bail out if freq_table is
not provided. So all this checking for freq_table in the code you pasted
above is superfluous. If you can clean that part
Hi,
On 03/25/2013 04:58 PM, Lars-Peter Clausen wrote:
The omap PCM driver provides a set_threshold callback which gets called by the
PCM driver when either playback or capture is started. The only DAI driver
which
sets this callback is the mcbsp driver. This patch removes the callback from
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
property but its description after.
This is confusing so we move
On 03/25/2013 06:15 PM, Russell King - ARM Linux wrote:
What I'm talking about is having a physical channel scheduler in place
across DMA engines which have more virtual channels than physical
channels. Some DMA engine implementations sort of do this already (eg,
AMBA PL08x stuff) but again,
On Monday 25 March 2013, John Stultz wrote:
On 03/25/2013 03:36 PM, Arnd Bergmann wrote:
On Monday 25 March 2013, Rob Herring wrote:
I count integrator-cp, realview, versatile and non-DT VExpress that do
this (not surprisingly) and 25 platforms or timer implementations plus
arm64 that do
Register a device tree clock provider for the clocks
on the OMAP4 SoC. Also provide the binding information.
For now we only provide AUXCLKs.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/clock/omap4-clock.txt | 33
arch/arm/boot/dts/omap4.dtsi
Hello,
regarding your patch against arch/arm/Kconfig:
@@ -1215,7 +1215,7 @@ config ARM_ERRATA_430973
depends on CPU_V7
help
This option enables the workaround for the 430973 Cortex-A8
- (r1p0..r1p2) erratum. If a code sequence containing an ARM/Thumb
+
Hi,
To make it possible to add DT support to DSS, and later use the Common Display
Framework, we need to change the DSS device model. We currently have a custom
dss bus, and omap_dss_devices on that bus, and the aim is to get rid of that
bus.
The panel devices will be converted occording to the
omapdss output drivers always read the platform data. This crashes when
there's no platform data when using DT.
Add a check to read the platform data only if it exists.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c |3 ++-
Add a support function to find a DSS output by given name. This is used
in later patches to link the panels to DSS outputs.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/output.c | 13 +
include/video/omapdss.h |1 +
2 files changed,
Add a support function to find a DSS output by given DT node. This is
used in later patches to link the panels to DSS outputs.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/output.c | 13 +
include/video/omapdss.h |1 +
2 files
When using DT, dss device does not have platform data. However,
dss_get_ctx_loss_count() uses dss device's platform data to find the
get_ctx_loss_count function pointer.
To fix this, change dss_get_ctx_loss_count() needs to be changed to get
the platform data from the omapdss device, which is a
On some platforms DPI requires a regulator to be enabled to power up the
output pins. This regulator is, for some reason, currently attached to
the virtual omapdss device, instead of the DPI device. This does not
work for DT, as the regulator mappings need to be described in the DT
data, and the
omap_dss_get_next_device() uses the dss bus to iterate over the
displays. This patch changes omap_dss_get_next_device() to use the new
panel list instead.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/display.c | 63 +++--
1
We have support functions to suspend and resume all the displays that
are used with system suspend. These functions use the dss bus to iterate
the display devices.
As we aim to remove the custom dss bus totally, this patch removes the
explicit use of dss bus from these functions. Instead the
We aim to remove the custom omapdss bus totally, as it's quite a strange
construct and won't be compatible with common display framework. One
problem on the road is that we have sysfs files for each display, and
they depend on the omapdss bus.
This patch creates the display sysfs files
We are about to remove the dss bus support, which also means that the
omap_dss_device won't be a real device anymore. This means that the
embedded dev struct needs to be removed from omap_dss_device.
After we've finished the removal of the dss bus, we see the following
changes:
- struct
This patch adds new way to register DSI panels. This new method will be
used by the panel drivers that are converted away from the current dss
bus based model.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 55 -
This patch adds new way to register HDMI panels. This new method will be
used by the panel drivers that are converted away from the current dss
bus based model.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.h |2 ++
drivers/video/omap2/dss/hdmi.c | 41
The forthcoming omap_dss_device to platform_device conversion requires a
few new fields to the TFP410 platform data. Add the platform data fields
here so that we can make the board file changes independently of the
panel driver changes.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
This patch adds new way to register DPI panels. This new method will be
used by the panel drivers that are converted away from the current dss
bus based model.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 35 ++-
Convert panel-generic-dpi driver from omap_dss_driver to a platform
driver. The driver uses the new panel support from omapdss.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-generic-dpi.c | 141 ++
1 file changed, 91
The forthcoming omap_dss_device to platform_device conversion requires a
few new fields to the generic-dpi-panel platform data. Add the platform
data fields here so that we can make the board file changes
independently of the panel driver changes.
Signed-off-by: Tomi Valkeinen
The forthcoming omap_dss_device to platform_device conversion requires a
few new fields to the Taal platform data. Add the platform data fields
here so that we can make the board file changes independently of the
panel driver changes.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
Convert Taal driver from omap_dss_driver to a platform driver. The
driver uses the new panel support from omapdss.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-taal.c | 294 +
1 file changed, 173 insertions(+), 121
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/dss-common.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c
Change Pandaboard and 4430SDP to use the new HDMI platform driver
instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/dss-common.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-overo.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git
Change 4430SDP to use the new Taal platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/dss-common.c | 41 --
1 file changed, 17 insertions(+), 24 deletions(-)
diff --git
Convert HDMI driver from omap_dss_driver to a platform driver. The
driver uses the new panel support from omapdss.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi_panel.c | 48 +++---
1 file changed, 38 insertions(+), 10
We currently use the omapdss bus (which contains all the available
displays) to iterate the displays. As the omapdss bus is on its way out,
this needs to be changed.
Instead of using the dss bus to iterate displays, this patch adds our
own list of displays which we manage. The panels on the dss
Convert TFP410 driver from omap_dss_driver to a platform driver. The
driver uses the new panel support from omapdss.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-tfp410.c | 205 +--
1 file changed, 128 insertions(+), 77
SDI requires a regulator to operate. This regulator is, for some reason,
currently attached to the virtual omapdss device, instead of the SDI
device. This does not work for DT, as the regulator mappings need to be
described in the DT data, and the virtual omapdss device is not present
there.
Fix
Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-overo.c | 71 +++--
1 file changed, 36 insertions(+), 35 deletions(-)
diff --git
These are misc fixes and improvements within omapdrm and omapdss. The fixes do
the
following:
- Make omapdrm smarter to choose the right overlay managers as it's crtcs. This
makes sure that omapdrm is functional for OMAP platforms with different
combinations of panels connected to it.
- Fix
modeset_init iterates through all the registered omapdss devices and has some
initial checks to see if the panel has a driver and the required driver ops for
it to be usable by omapdrm.
The function bails out from modeset_init if a panel doesn't meet the
requirements, and stops the registration
The omapdrm driver currently takes a config/module arg to figure out the number
of crtcs it needs to create. We could create as many crtcs as there are overlay
managers in the DSS hardware, but we don't do that because each crtc eats up
one DSS overlay, and that reduces the number of planes we can
The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
yet, we require some muxing at the
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The
Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the
DSI PLL Fint range, this was previously just copied from
Each version of OMAP has a limitation on the maximum pixel clock frequency
supported by an overlay manager. This limit isn't checked by omapdss. Add
dispc feats for lcd and tv managers and check whether the target timings can
be supported or not.
The pixel clock limitations are actually more
When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we
need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This
is needed because the stride for the UV plane(using a 16 bit Tiler container) is
double the stride for the Y plane(using a 8 bit Tiler
DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve
more power savings when DISPC is configured in Smart Standby mode. This
mechanism leads to underflows when multiple DISPC pipes are enabled.
There is a register field which can let us revert to the older mechanism of
Hi Javier,
On 03/26/2013 10:33 AM, Javier Martinez Canillas wrote:
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells property listed before #interrupt-controller
On Mon, Mar 25, 2013 at 04:58:16PM +0100, Lars-Peter Clausen wrote:
The omap PCM driver provides a set_threshold callback which gets called by the
PCM driver when either playback or capture is started. The only DAI driver
which
sets this callback is the mcbsp driver. This patch removes the
On 03/26/2013 03:10 PM, Benoit Cousson wrote:
Hi Javier,
On 03/26/2013 10:33 AM, Javier Martinez Canillas wrote:
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the OMAP GPIO controller has the
#interrupt-cells
Hi Santosh,
The series looks good to me. I've just applied it and update my branch.
I just slightly modified some changelog to fix typos.
Thanks,
Benoit
On 03/19/2013 02:30 PM, Santosh Shilimkar wrote:
Benoit,
Here is the branch rebased and updated against your 'for_3.10/dt' branch.
Few
On Tuesday 26 March 2013 08:01 PM, Benoit Cousson wrote:
Hi Santosh,
The series looks good to me. I've just applied it and update my branch.
I just slightly modified some changelog to fix typos.
Thanks Benoit !!
Will pull your updated branch.
Regards,
Santosh
--
To unsubscribe from this
On 03/26/2013 03:29 PM, Benoit Cousson wrote:
On 03/26/2013 03:10 PM, Benoit Cousson wrote:
Hi Javier,
On 03/26/2013 10:33 AM, Javier Martinez Canillas wrote:
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The binding documentation for the
On Mon, 25 Mar 2013, Vaibhav Hiremath wrote:
During common-clock migration, .clkdm_name field got missed
for clkdiv32k_ick clock, which leaves clk_24mhz_clkdm
unused; so boot process will try to disable the clockdomain
even childs of this clock is enabled, which keeps child modules
in idle
Here are some basic OMAP test results for Linux v3.9-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc4/20130324120244/
Test summary
Build:
FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only,
Hi
On Tue, 19 Mar 2013, Santosh Shilimkar wrote:
On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote:
Test summary
Thanks for the summary Paul. A usual, it is quite exhaustive.
Would that it were true. These tests are really only very superficial.
Here are some major
On Mon, 7 Jan 2013 20:51:03 +0200, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Document the beaglebone's cape driver bindings.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Hi Pantelis,
I'll go back and review the driver in a minute, but I'll start here
since
On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Hi Lee,
On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
At the end of the line, some kind of hardware glue is going to be
needed.
I just feel that drawing from a sample size of 1 (maybe 2 if I
On Tue, Mar 26, 2013 at 04:16:10PM +, Grant Likely wrote:
On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
Hi Lee,
On Jan 8, 2013, at 12:00 PM, Lee Jones wrote:
At the end of the line, some kind of hardware glue is going to be
Hi.
On Tue, 19 Mar 2013, Tero Kristo wrote:
I think you should definitely upgrade your bootloader, the old one you
are using is prone to cause trouble due to bugs it has, and we have no
simple way to workaround the issues it causes on kernel side.
So, the kernel should be independent of the
Hi,
On Thu, 14 Mar 2013, Hiremath, Vaibhav wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Tuesday, March 12, 2013 10:10 PM
To: linux-omap@vger.kernel.org
Cc:
Hi,
On Tue, 12 Mar 2013, Suman Anna wrote:
The OMAP mailbox platform driver code has been cleaned up to
remove the dependencies with soc.h in preparation for moving
the mailbox code to drivers folder.
The code relied on cpu_is_xxx/soc_is_xxx macros previously to
pick the the right set of
Paul,
The OMAP mailbox platform driver code has been cleaned up to remove
the dependencies with soc.h in preparation for moving the mailbox code
to drivers folder.
The code relied on cpu_is_xxx/soc_is_xxx macros previously to pick the
the right set of mailbox devices and register with
* Tomi Valkeinen tomi.valkei...@ti.com [130326 06:38]:
Hi,
To make it possible to add DT support to DSS, and later use the Common Display
Framework, we need to change the DSS device model. We currently have a custom
dss bus, and omap_dss_devices on that bus, and the aim is to get rid of that
On Mon, Mar 25, 2013 at 02:31:26PM -0500, Jon Hunter wrote:
Hi Russell,
On 03/19/2013 12:59 PM, Tony Lindgren wrote:
Hi Russell,
Can we use your commit 71856843 (ARM: OMAP: use consistent error checking)
as an immutable base for further omap dmtimer and gpmc work?
I saw that you
Hi
On Thu, 21 Mar 2013, Rajendra Nayak wrote:
clk inits on OMAP happen quite early, even before slab is available.
The dependency comes from the fact that the timer init code starts to
use clocks and hwmod and we need clocks to be initialized by then.
There are various problems doing clk
62 matches
Mail list logo
