Additional 4 bytes found in the skb is the CRC calculated by the
CPDMA hardware, check the CRC bit in CPDMA status field of
Descriptor and remove the CRC length from the skb. This extra
4 byte can be seen when capturing packets using tcpdump.
This has been tested in TI816x platform.
Lars == Lars Poeschel la...@wh2.tu-dresden.de writes:
Lars From: Lars Poeschel poesc...@lemonage.de
Lars The gpmc driver is actually looking for gpmc,num-cs and
Lars gpmc,num-waitpins properties in DT. The binding doc also states
Lars this.
Lars Correct the properties in the dts to
Hi Pekon,
On 05/20/2013 06:44 AM, Gupta, Pekon wrote:
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
+ pinctrl-0 = matrix_keypad_s0 volume_keys_s0
+ nandflash_pins_s0;
Why add this to
Sorry, I missed that series.
I'm applying it right now.
No issues.. Please pick newer v4 versions of this series.
Following are rebased, updated and tested on linux-3.10-rc3
[PATCH v4,0/3] http://www.spinics.net/lists/linux-omap/msg91165.html
[PATCH v4,1/3]
Sorry, I missed that series.
I'm applying it right now.
No issues.. Please pick newer v4 versions of this series.
Following are rebased, updated and tested on linux-3.10-rc3
[PATCH v4,0/3] http://www.spinics.net/lists/linux-omap/msg91165.html
[PATCH v4,1/3]
On 05/30/2013 09:31 AM, Gupta, Pekon wrote:
Sorry, I missed that series.
I'm applying it right now.
No issues.. Please pick newer v4 versions of this series.
Following are rebased, updated and tested on linux-3.10-rc3
[PATCH v4,0/3] http://www.spinics.net/lists/linux-omap/msg91165.html
Support for omap2evm was removed in v3.0. But only one of its two
lines in this Makefile was removed. Remove the second line too.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Eyeball tested only.
sound/soc/omap/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git
On 5/28/2013 7:35 PM, Mugunthan V N wrote:
On 5/28/2013 3:06 AM, Tony Lindgren wrote:
* Mugunthan V N mugunthan...@ti.com [130526 11:28]:
From: Hebbar Gururaja gururaja.heb...@ti.com
Amend cpsw controller to optionally take a pin control handle and set
the state of the pins to:
- default on
Hi,
The following patch fixes a wrong container_of usage for omap3630.
All sub clock of dpll4 that do not use a reset value as divider are
affected.
For instance CAM_MCLK is 216 MHz instead of the asked 172,8 MHz
Any user of this clock is affected. This is the case for instance if
CAM_XCLKA is
omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of the clock
to be a clk_hw_omap. However, looking at cclock3xxx_data.c, all concerned clock
have parent defined as clk_divider. Instead of using container_of to eventually
get
to the register and directly mess with the divider,
On 05/29/2013 08:22 PM, Kevin Hilman wrote:
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
Starting from the OMAP chips with version2 registers scheme there are
2 registers (I2C_IRQENABLE_SET and I2C_IRQENABLE_CLR) to manage
interrupts instead of the older OMAP chips with old scheme
On 05/09/2013 02:52 AM, Tony Lindgren wrote:
* Roger Quadros rog...@ti.com [130422 03:02]:
The USB host pins are named quite differently between OMAP3 and
OMAP4+ SoCs. To make this managable in code, we create a pin mapping
table (pin_names) that maps pin function to pin name.
This pin
Hi,
Here's are the first sets of patches targeting towards enabling DT for DSS and
changing the DSS device model to be more versatile. The exact division of the
sets of patches is still a bit open, and some splitting up for arch/driver
changes is needed, but most likely there will be at least the
We can currently set the default display (i.e. the initial display) in
the omapdss platform data by using a pointer to the default
omap_dss_device. Internally omapdss uses the device's name to resolve
the default display.
As it's difficult to get the omap_dss_device pointer in the future,
after
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 | 12
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, 14
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 changed, 14
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, dss_get_ctx_loss_count() needs to be changed to get the
platform data from the omapdss device, which is a virtual
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
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
Minor cleanup for the dss_[ovl|mgr]_get_device() functions to make them
more readable.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/apply.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c
Add two helper functions that can be used to find either the DSS output
or the overlay manager that is connected to the given display.
This hides how the output and the manager are actually connected, making
it easier to change the connections in the future.
Signed-off-by: Tomi Valkeinen
Split the function that creates overlay manager structs into two: one
that creates just the structs, and one that creates the sysfs files for
the manager.
This will help us use the overlay manager structs with omapdrm in the
following patches, while still leaving the sysfs files out.
Currently omapdrm creates crtcs, which map directly to DSS overlay
managers, only on demand at init time. This would make it difficult to
manage connecting the display entities in the future, as the code cannot
just search for a suitable overlay manager.
We cannot fix this the sane way, which
Use devm_regulator_get() instead of regulator_get() to simplify code.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c
Separate the regulator initialization code to its own function, removing
duplicate code.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 82 ---
1 file changed, 31 insertions(+), 51 deletions(-)
diff --git
We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.
This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one
Split regulator and DSI PLL init code to their own functions for
clarity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 100 ++
1 file changed, 53 insertions(+), 47 deletions(-)
diff --git
Separate regulator init code into its own function for clarity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 42 ++
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c
Clean up the SDI driver's regulator init to remove the (unused)
omap_dss_device parameter, renaming the function to a more sensible
name, and making the code slightly clearer.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/sdi.c | 41
Clean up the VENC driver's regulator init to remove the (unused)
omap_dss_device parameter, renaming the function to a more sensible
name, and making the code slightly clearer.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/venc.c | 32
Add helper functions to convert between omapdss specific video timings
and the common videomode.
Eventually omapdss will be changed to use only the common video timings,
and these helper functions will make the transition easier.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
In the future the dssdev parameter passed to output drivers will
change its meaning. Instead of being a pointer to the panel device, it's
a pointer to the output instance.
To make the transition easier, some of the uses for this dssdev
parameter can be easily removed.
Signed-off-by: Tomi
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
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 | 54 ---
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
The omap_dss_start_device() and omap_dss_stop_device(), called by the
DSS output drivers, are old relics. They originally did something
totally else, but nowadays they increase the module ref count for panels
that are enabled.
This model is quite broken: the panel modules may be used even before
We currently have omap_dss_device, which represents an external display
device, sometimes an external encoder, sometimes a panel. Then we have
omap_dss_output, which represents DSS's output encoder.
In the future with new display device model, we construct a video
pipeline from the display
omap_dss_get_device() should be called for omap_dss_device before it is
used to increase its refcount. Currently we only increase the refcount
for the underlying device.
This patch adds managing the ref count to the underlying module also,
which contains the ops for the omap_dss_device.
Setup the owner field for DSS output's omap_dss_device so that module
refcounting works.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 1 +
drivers/video/omap2/dss/dsi.c | 1 +
drivers/video/omap2/dss/hdmi.c | 1 +
drivers/video/omap2/dss/rfbi.c | 1 +
Currently omapfb returns EPROBE_DEFER if no displays have been probed at
the time omapfb is probed. However, sometimes some of the displays have
been probed at that time, but not all. We can't return EPROBE_DEFER in
that case, because then one missing driver would cause omapfb to defer
always,
Now that omap_dss_output has been combined into omap_dss_device, we can
add ref counting for the relevant output functions also.
This patch adds omap_dss_get_device() calls to the various find_output()
style functions. This, of course, means that the users of those
find_output functions need to
Add struct module *owner field to omap_dss_device, which points to the
module containing the ops for this omap_dss_device. This will be used to
manage the ref count for the module.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
include/video/omapdss.h | 2 ++
1 file changed, 2
Hi,
Here's are the first sets of patches targeting towards enabling DT for DSS and
changing the DSS device model to be more versatile. The exact division of the
sets of patches is still a bit open, and some splitting up for arch/driver
changes is needed, but most likely there will be at least the
In order to allow multiple display block in a video pipeline, we need to
give the drivers way to register themselves. For now we have
the omapdss_register_display() which is used to register panels, and
dss_register_output() which is used to register DSS encoders.
This patch makes
In the future will have arbitrarily long video pipeline chains, instead
of the current two-entities-per-pipeline model.
This patch changes the affected get/find style functions so that they
properly go through the video pipeline chain, for example when getting
the overlay manager connected to a
With the new DSS device model, we'll have new panel and encoder drivers.
This patch adds the platform data structs for all the new drivers.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
include/video/omap-panel-data.h | 150
1 file changed, 150
Use the new display drivers for OMAP4 Panda and OMAP4 SDP boards.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/dss-common.c | 185 +++
1 file changed, 108 insertions(+), 77 deletions(-)
diff --git
Use the new display drivers for OMAP3 Overo board.
Note that the LCD add-on boards for lcd43 and lcd35 use the same GPIOs
for the panels. This means that both panel devices cannot be probed at
the same time.
DT will handle this correctly, i.e. the DT data will contain the panel
device only for
Use the new display drivers for RX51 board.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 12 ++
arch/arm/mach-omap2/board-rx51-video.c | 35 ++--
2 files changed, 24 insertions(+), 23 deletions(-)
Use the new display drivers for Beagleboard.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 56 +
1 file changed, 36 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
Add new display bus type for DVI. This is not used by omapdss driver
itself, but is used by external encoder chips that output DVI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/display.c | 1 +
include/video/omapdss.h | 1 +
2 files changed, 2
The omapdrm driver currently uses a string comparison to find out if the
display is a DVI display. This is not reliable, and as we now have a
specific display type for DVI, let's use that.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++
1
Add ops style method for using DPI functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 70
Add ops style method for using SDI functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/sdi.c | 78
Add ops style method for using DVI functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
include/video/omapdss.h | 18 ++
1
Add ops style method for using analog TV functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/venc.c | 72
Add ops style method for using HDMI functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 248
Add ops style method for using DSI functionality.
Ops style calls will allow us to have arbitrarily long display
pipelines, where each entity can call ops in the previous display
entity.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 93
Add TFP410 DPI-to-DVI Encoder driver which uses the new DSS device
model and DSS ops.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/Kconfig | 1 +
drivers/video/omap2/Makefile | 1 +
Add TPD12S015 HDMI ESD protection and level shifter encoder driver which
uses the new DSS device model and DSS ops.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
Add DVI Connector driver which uses the new DSS device model and DSS
ops.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile| 1 +
drivers/video/omap2/displays-new/connector-dvi.c |
Add HDMI Connector driver which uses the new DSS device model and DSS
ops.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/Kconfig | 5 +
drivers/video/omap2/displays-new/Makefile | 1 +
Add Analog TV Connector driver which uses the new DSS device model and
DSS ops.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/Kconfig | 5 +
drivers/video/omap2/displays-new/Makefile | 1 +
Add simple DPI Panel driver which uses the new DSS device model and DSS
ops. A simple panel means one that does not require any special setup.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/Kconfig | 5 +
drivers/video/omap2/displays-new/Makefile
Add DSI Command Mode panel driver which uses the new DSS device model
and DSS ops. This driver only supports a very basic set of features
which should be common to all DSI command mode panels.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/Kconfig
Add Sony ACX565AKM panel driver which uses the new DSS device model and
DSS ops.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
Add LG.Philips LB035Q02 panel driver which uses the new DSS device model
and DSS ops.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/Kconfig | 5 +
drivers/video/omap2/displays-new/Makefile | 1 +
SDI driver gets currently the vdds_sdi regulator via omapdss device.
This is not correct, and we'll change the SDI driver to get the
regulator directly.
This patch changes the rx51 board file to add vdds_dsi supply for sdi.0
device.
Note that the vdds_sdi supply for omapdss device is still left
DPI driver gets currently the vdds_dsi regulator via omapdss device.
This is not correct, and we'll change the DPI driver to get the
regulator directly.
This patch changes the relevant board files to add vdds_dsi supply for
dpi.0 device.
Note that the vdds_dsi supply for omapdss device is still
board-cm-t35.c and board-ldp.c contain regulator supply entries for
vdds_dsi. However, the given device name is wrong.
This patch fixes the device name from omapdss_dsi1 to omapdss_dsi.0.
Note that as far as I know, DSI driver is not used on these boards, so
this should not have caused any
On Thu, 30 May 2013 09:37:40 +0200
Paul Bolle pebo...@tiscali.nl wrote:
Support for omap2evm was removed in v3.0. But only one of its two
lines in this Makefile was removed. Remove the second line too.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Eyeball tested only.
The following patch series contain several misc fixes to SmartReflex driver:
1. disable errgen before vpbound disable. Critical fix, needed for
proper work of AVS-VP communicaton protocol.
2. disable runtime PM on driver remove. Trivial - runtime PM cleanup.
3. fix driver name. Trivial - proper
DRIVER_NAME was undefined for SmartReflex. Now it is
defined with valid value smartreflex. It is needed
to define proper value for:
MODULE_ALIAS(platform: DRIVER_NAME);
Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com
Acked-by: Nishanth Menon n...@ti.com
---
Runtime PM should be disabled for device on driver remove,
otherwise runtime PM will be not balanced, and this will cause
an error message, on next driver probe.
Signed-off-by: Andrii Tseglytskyi andrii.tseglyts...@ti.com
Acked-by: Nishanth Menon n...@ti.com
---
drivers/power/avs/smartreflex.c |
From: Nishanth Menon n...@ti.com
vpboundsintr_en is available inside the IP block as an re-sycned
version and one which is not. Due to this, there is an 1 sysclk
cycle window where the SR_SInterruptz signal could be asserted low.
IF, intr_en is cleared on the exact same cycle as the irqclr, an
Pci_enable_device() will set device power state to D0,
so it's no need to do it again in dwc3_pci_probe().
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/usb/dwc3/dwc3-pci.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c
Currently omap3xxx_check_revision() detects ES1.0 and ES1.1 only,
this patch extends it by adding ES2.0 and ES2.1 versions support.
Signed-off-by: Aida Mynzhasova aida.mynzhas...@skitlab.ru
---
arch/arm/mach-omap2/id.c | 11 +--
arch/arm/mach-omap2/soc.h |2 ++
2 files changed, 11
The following patch series introduces a few optimizations for SmartReflex
driver.
1. devm_* API usage for SmartReflex. This allows us to have brilliant resources
handling - allocation/auto free, map/auto unmap. Another benefit - lot of error
checks
can be dropped.
2. Another small optimization
Use of of devm_* API for resource allocation provides benefits such
as auto handling of resource free. This reduces possibility have
memory leaks in case of wrong error handling. All direct release
calls should be removed to avoid races.
Reported-by: Grygorii Strashko grygorii.stras...@ti.com
SmartReflex consists of three entities: SR device, SR class and
SR driver. SmartReflex driver depends on SmartReflex class, but
order of their initialization is not clear. They both use
late_initcall(), and order depends on Makefile calls.
Patch moves initialization of SR class to
On Thu, May 30, 2013 at 09:37:40AM +0200, Paul Bolle wrote:
Support for omap2evm was removed in v3.0. But only one of its two
lines in this Makefile was removed. Remove the second line too.
Applied, thanks.
signature.asc
Description: Digital signature
The OMAP runtime PM implementation was removed in v3.0. But one Makefile
line, which was used to tweak CFLAGS, was overlooked. Remove it too.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested. This cleans up after commit 638080c37a (OMAP2+ / PM: move
runtime PM implementation to use
On 30/05/13 14:09, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
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,
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
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
On 30/05/13 14:12, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
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
On 30/05/13 14:07, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
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
---
Hi Stephen,
On 05/29/2013 05:27 PM, Stephen Warren wrote:
On 05/29/2013 02:39 AM, Benoit Cousson wrote:
Hi Afzal,
On 05/29/2013 10:06 AM, Mohammed, Afzal wrote:
Hi Jon,
On Wed, May 29, 2013 at 03:35:10, Stephen Warren wrote:
On 05/28/2013 03:25 PM, Jon Hunter wrote:
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
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, dss_get_ctx_loss_count() needs to be changed to get the
On Thursday 30 May 2013, Tomi Valkeinen wrote:
On 30/05/13 14:12, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
On some platforms DPI requires a regulator to be enabled to power up the
output pins. This regulator is, for some reason, currently
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
On 05/29/2013 08:22 PM, Kevin Hilman wrote:
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
Starting from the OMAP chips with version2 registers scheme there are
2 registers (I2C_IRQENABLE_SET and I2C_IRQENABLE_CLR) to manage
Andreas Fenkart andreas.fenk...@streamunlimited.com writes:
By also making it return the modified value, we save the readl
needed to update the context.
Signed-off-by: Andreas Fenkart andreas.fenk...@streamunlimited.com
Great cleanups, Thanks!
Some minor comments below...
Also, it would
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
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 +
This patch adds required structures for powerdomain initialization on
the ti816x. It is impossible to use omap3430 structures in order to
initialize powerdomains on ti816x, because there are big differences
between PRCM module base address offsets on these CPUs.
Signed-off-by: Aida Mynzhasova
On 05/30/2013 05:18 PM, Kevin Hilman wrote:
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
On 05/29/2013 08:22 PM, Kevin Hilman wrote:
Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com writes:
Starting from the OMAP chips with version2 registers scheme there are
2 registers
On 14:40 Thu 30 May , Tomi Valkeinen wrote:
On 30/05/13 14:07, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
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.
On 14:28 Thu 30 May , Tomi Valkeinen wrote:
On 30/05/13 14:09, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
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
If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function.
1 - 100 of 118 matches
Mail list logo
