Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

Hi, On 01/01/16 14:01, Pali Rohár wrote: > Hi Tomi! Can you review this patch? It is waiting here for two years! > > On Thursday 26 December 2013 00:12:39 Ivaylo Dimitrov wrote: >> From: Ivaylo Dimitrov >> >> On memory limited devices, CMA fails easily when asked to

Re: [PATCH 3/7] omapfb: fix error return code

On 26/12/15 17:28, Julia Lawall wrote: > Return a negative error code on failure. > > A simplified version of the semantic match that finds this problem is as > follows: (http://coccinelle.lip6.fr/) > > // > @@ > identifier ret; expression e1,e2; > @@ > ( > if (\(ret < 0\|ret != 0\)) > { ...

Re: OMAP display kconfig options changing

Hi Javier, Tony, On 22/12/15 23:18, Javier Martinez Canillas wrote: >> But if the userspace is using any omapfb specific apps, then yes, update >> is necessary. >> > > Yes but these people should have a migration plan anyways since omapfb > (and fbdev in general) is going away right? Well, I

Re: [PATCH v2] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks

On 25/12/15 15:29, Ivaylo Dimitrov wrote: > > Hi Tomi, > > On 13.01.2014 12:20, Tomi Valkeinen wrote: >> On 2014-01-11 11:39, Ivaylo Dimitrov wrote: >> >>> The patch does not apply cleanly on top of rc7, however I applied it by >>> hand.

Re: [PATCH 5/5] fbdev: omap2: panel-dpi: allow specification of a vcc regulator

Hi, On 19/12/15 22:41, Adam Ford wrote: > Tomi, > > Do you have any thought on how to approach adding sleep/delay > functions? I have a display that requires a small delay before and > after the enable gpio toggle. I assume that some may require a delay > after the regulator starts for it to

Re: [PATCH 3/5] fbdev: omap2: panel-dpi: drop assignment to local variable

On 20/12/15 12:31, Uwe Kleine-König wrote: > Hello, > > On Wed, Dec 16, 2015 at 07:29:17PM +0200, Tomi Valkeinen wrote: >> On 10/12/15 15:11, Uwe Kleine-König wrote: >>> From: Uwe Kleine-König <u.kleine-koe...@pengutronix.de> >>> >>> The vari

Re: [PATCH] OMAPDSS: fix omapfb build error due missing feat functions declaration

Hi Javier, On 21/12/15 20:26, Javier Martinez Canillas wrote: > The omapfb is failing to build in -next due missing declarations for > dss_feat_get_supported_displays() and dss_feat_get_supported_outputs(): > > CC [M] drivers/video/fbdev/omap2//omapfb/dss/dss.o >

OMAP display kconfig options changing

Hi Tony, I've just pushed a patch series to fbdev for-next branch which makes the OMAP DRM and FB drivers independent of each other. This requires changing the related Kconfig options. What should I do with omap2plus_defconfig? At the moment omap2plus_defconfig enables the omapfb driver and

Re: OMAP display kconfig options changing

On 18/12/15 18:05, Tony Lindgren wrote: >> Are you referring to Kconfig options? Or userspace? > > Well sounds like both need updating :) Depends... For simple fb apps, omapdrm works fine, and X with the standard fbdev driver should work with omapdrm too. But if the userspace is using any

Re: OMAP display kconfig options changing

On 18/12/15 15:53, Tony Lindgren wrote: > Hi, > > * Tomi Valkeinen <tomi.valkei...@ti.com> [151218 00:55]: >> Hi Tony, >> >> I've just pushed a patch series to fbdev for-next branch which makes the >> OMAP DRM and FB drivers independent of each other

Re: OMAP display kconfig options changing

On 18/12/15 16:03, Adam Ford wrote: > Tomi, > > I'd like to also test the LogicPD Torpedo which has been using the FB > drivers until this point. I just pushed some LCD info for inclusion in > 4.5, but if I need to make changes, I'd like to do that sooner than The DT data is the same for

Re: [PATCH 4/5] fbdev: omap2: panel-dpi: allow specification of a reset gpio

On 10/12/15 15:11, Uwe Kleine-König wrote: > From: Uwe Kleine-König > > Some displays have a reset input. To assert that the display is > functional the reset gpio must be deasserted. > > Teach the driver to get and drive such a gpio accordingly. > >

Re: [PATCH 3/5] fbdev: omap2: panel-dpi: drop assignment to local variable

On 10/12/15 15:11, Uwe Kleine-König wrote: > From: Uwe Kleine-König > > The variable gpio is only used to store the return value of > devm_gpiod_get_optional just to assign it to a member of the driver > data. > > Get rid of this local variable and assign to

Re: [PATCH 1/5] fbdev: omap2: panel-dpi: in .disable first disable backlight then display

On 10/12/15 15:11, Uwe Kleine-König wrote: > From: Uwe Kleine-König > > This makes .disable operate in reverse order compared to .enable. > > Signed-off-by: Uwe Kleine-König > --- >

Re: [PATCH 5/5] fbdev: omap2: panel-dpi: allow specification of a vcc regulator

On 10/12/15 15:11, Uwe Kleine-König wrote: > From: Uwe Kleine-König > > To allow supporting displays that need some logic to enable power to the > display add support for a vcc-supply property to drive a regulator. > > Signed-off-by: Uwe Kleine-König

Re: [PATCH 2/5] fbdev: omap2: panel-dpi: simplify gpio setting

On 10/12/15 15:11, Uwe Kleine-König wrote: > From: Uwe Kleine-König > > gpiod_set_value_cansleep is a noop when the passed descriptor is NULL. > So there is no need to duplicate the check for NULL; just call the > function unconditionally instead. > >

Re: [PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects

On 13/12/15 20:41, H. Nikolaus Schaller wrote: > Great that you did find the real reason of the problem. > > I have tested it on the GTA04 and it also works. > > Will the patches arrive in 4.5? 4.4, I hope. Tomi signature.asc Description: OpenPGP digital signature

Re: [PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects

a4274600a5a67256b91266b0d2624b9c9028909b Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen <tomi.valkei...@ti.com> Date: Tue, 8 Dec 2015 18:32:14 +0200 Subject: [PATCH] drm/omap: fix fbdev pix format to support all platforms omap_fbdev always creates a framebuffer with ARGB pixel format. On OM

Re: [patch] OMAPDSS: DSS: fix a warning message

On 04/12/15 15:14, Dan Carpenter wrote: > The WARN() macro has to take a condition. The current code will just > print the stack trace and the function name instead of the intended > warning message. > > Signed-off-by: Dan Carpenter > > diff --git

Re: [patch] OMAPDSS: DSI: cleanup DSI_IRQ_ERROR_MASK define

On 23/11/15 20:22, Dan Carpenter wrote: > DSI_IRQ_SYNC_LOST was ORed twice so we can remove one. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/video/fbdev/omap2/dss/dsi.c > b/drivers/video/fbdev/omap2/dss/dsi.c > index b3606de..e86df6d 100644 > ---

Re: [PATCH] OMAPDSS: DISPC: Remove boolean comparisons

On 15/10/15 15:29, Luis de Bethencourt wrote: > Boolean tests do not need explicit comparison to true or false. > > Signed-off-by: Luis de Bethencourt > --- > drivers/video/fbdev/omap2/dss/dispc-compat.c | 6 +++--- > drivers/video/fbdev/omap2/dss/dispc.c| 6

Re: [PATCH 1/3] video: omapdss: delete unneeded of_node_put

On 12/10/15 23:43, Julia Lawall wrote: > Device node iterators perform an of_node_put on each iteration, so putting > an of_node_put before a continue results in a double put. > > A simplified version of the semantic match that finds this problem is as > follows (http://coccinelle.lip6.fr): >

Re: [PATCH 2/2] video:omapdrm: make omapdrm assume the tv-out cable is always connected

On 13/11/15 12:29, H. Nikolaus Schaller wrote: > Include VENC in the set of drivers where it is assimed that the cable > is always connected. Like DPI, DSI, DBI and SDI do. > > Otherwise, the VENC will return cable status "unknown" and is not enabled > by the X-server. So there is no video

Re: DM3730 vs 3630 DSS Cock dividers

On 16/10/15 13:23, Tomi Valkeinen wrote: > Ok, so the clock data in the DT and the data in the dss are in sync and > according to the TRM. So the patch in this thread is not correct. > > How about 3730? Are we sure the dpll clocks are the same for 3730 and 3630? > > So

Re: DM3730 vs 3630 DSS Cock dividers

On 13/10/15 10:55, Tero Kristo wrote: > TRMs are correct, 3630 does not have x2 multiplier after DPLL4. > > In the clock data, dpll4_m4x2 path is an x1 multiplier on omap3630, it > is easier to represent this in DT than completely remove the dpll4_*x2 > nodes for omap36xx. This is how it was

Re: DM3730 vs 3630 DSS Cock dividers

On 12.10.2015 19:00, Tony Lindgren wrote: * Adam Ford [151010 13:29]: Tomi and Tony, I am working on the LogicPD DM3730 Torpedo module. If I try to use the DSS, I get the same errors as mentioned in these previous messages found here:

[PATCH] ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on

ce the MMC core detects there is no card inserted, it does a regulator disable which again raises a card insertion interrupt. This happens in a loop causing infinite MMC interrupts. Fixes: 5a0f93c6576a ("ARM: dts: Add am57xx-beagle-x15") Cc: Kishon Vijay Abraham I <kis...@ti.c

Re: [PATCH 28/38] video/omap: remove invalid check

On 21/09/15 16:34, Andrzej Hajda wrote: > regno is unsigned so it cannot be negative. > > The problem has been detected using proposed semantic patch > scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1]. > > [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576 > >

Re: [PATCH v2] fbdev: omap2: connector-dvi: use of_get_i2c_adapter_by_node interface

On 15/09/15 16:12, Vladimir Zapolskiy wrote: > This change is needed to properly lock I2C bus driver, which serves DDC. > > Prior to this change i2c_put_adapter() is misused, which may lead to > an overflow over zero of I2C bus driver user counter. > > Signed-off-by: Vladimir Zapolskiy

Re: [PATCH] omapdss: acx565akm: Fix module autoload for OF platform driver

On 18/09/15 21:44, Luis de Bethencourt wrote: > This platform driver has a OF device ID table but the OF module > alias information is not created so module autoloading won't work. > > Signed-off-by: Luis de Bethencourt > --- > > Hello, > > This patch adds the missing

Re: [PATCH] omapdss: acx565akm: Fix module autoload for OF platform driver

On 24/09/15 13:17, Tomi Valkeinen wrote: > > > On 18/09/15 21:44, Luis de Bethencourt wrote: >> This platform driver has a OF device ID table but the OF module >> alias information is not created so module autoloading won't work. >> >> Signed-off-by: Luis de Be

Re: [PATCH v4] OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled

On 28/08/15 17:21, Jyri Sarha wrote: > Reconfigure and restart audio when display is enabled, if audio > playback was active before. This is needed in a situation when an > audio+video stream application opens the audio stream before the > video. When video stream is opened the display mode may

Re: [PATCH 1/2] OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled

On 26/08/15 16:11, Jyri Sarha wrote: diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c b/drivers/video/fbdev/omap2/dss/hdmi5.c index 7f87578..f352c4b 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5.c @@ -352,6 +352,7 @@ static int read_edid(u8

Re: [PATCH v2] OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled

Hi, On 28/08/15 15:24, Jyri Sarha wrote: Reconfigure and restart audio when display is enabled, if audio playback was active before. The audio configuration is stored when is 'is' - 'it' above is successfully applied and a boolean is set when playback has started and unset when stopped.

Re: [PATCH 1/2] OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled

Hi, On 26/08/15 16:11, Jyri Sarha wrote: I few comments, for the parts I had time to review: diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c b/drivers/video/fbdev/omap2/dss/hdmi5.c index 7f87578..f352c4b 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5.c +++

Re: omapdss: Division by zero in kernel

On 24/07/15 19:03, Pali Rohár wrote: Hello, when on N900 (real HW or qemu) I run this command / # echo 0 /sys/devices/platform/omapdss/overlay0/enabled echo 0 /sys/class/graphics/fb0/size then kernel crash with this error message / # [ 29.904113] Division by zero in kernel.

Re: omapdss: Division by zero in kernel

On 21/08/15 11:48, Pali Rohár wrote: On Friday 21 August 2015 11:42:14 Tomi Valkeinen wrote: On 24/07/15 19:03, Pali Rohár wrote: Hello, when on N900 (real HW or qemu) I run this command / # echo 0 /sys/devices/platform/omapdss/overlay0/enabled echo 0 /sys/class/graphics/fb0/size

Re: [PATCH] Drop owner assignment from i2c_driver (and platform left-overs)

On 10/07/15 09:37, Krzysztof Kozlowski wrote: Hi, The i2c drivers also do not have to set 'owner' field because i2c_register_driver() will do it instead. 'owner' is removed from i2c drivers, which I was able to compile with allyesconfig (arm, arm64, i386, x86_64, ppc64). Only

Re: [PATCH v2 0/2] OMAPDSS: Fix of-node refcount issues

On 07/08/15 14:04, Jyri Sarha wrote: Changes since the first version: - Fix commit descriptions and subject according to Tomi's comments I found couple of refcounting issues related to OMAP DSS of-node handling. Second patch should fix the ERROR: Bad of_node_put() on

Re: [PATCH 2/2] OMAPDSS: of-dss: omap_dss_find_output_by_port_node() keep port refcount

Hi, On 06/08/15 21:41, Jyri Sarha wrote: The only user of dss_of_port_get_parent_device() function is omap_dss_find_output_by_port_node() and it assumes the refcount of the port parameter is not decremented by the call. The subject of the patch should contain dss-of, not of-dss. Although

Re: [PATCH 1/2] OMAPDSS: dss-of: Fix node refcount leak in omapdss_of_get_next_port()

On 06/08/15 21:41, Jyri Sarha wrote: Signed-off-by: Jyri Sarha jsa...@ti.com Please always fill in the patch description. In simplest cases it may be the same as in the subject. --- drivers/video/fbdev/omap2/dss/dss-of.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] ARM: dts: am4372.dtsi: disable rfbi

When DSS nodes were added to am4372.dtsi, the rfbi node was not marked as disabled. This should have been done, as the rule of thumb is to disable all DSS nodes that are not used, and especially rfbi, as we don't have a driver for rfbi. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com

[PATCH 11/11] OMAPDSS: HDMI: wait for framedone when stopping video

ready-made irq handling for HDMI, and this only needs to be done when disabling the HDMI output, this patch implements a simple loop with sleep, polling the FRAMEDONE bit. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/hdmi_wp.c | 16 1 file

[PATCH 05/11] OMAPDSS: DISPC: fix row_inc for OMAP3

when row_inc is used. This patch adds a flag to DISPC driver so that the pixel_inc is added when required. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/dispc.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss

[PATCH 10/11] OMAPDSS: HDMI4: fix error handling

Error handling in hdmi_power_on_full() is not correct, and could leave resources unfreed. Fix this by arranging the error labels correctly. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/hdmi4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 08/11] OMAPDSS: DISPC: do only y decimation on OMAP3

removes x decimation for OMAP3. This will limit some of the more demanding downscaling scenarios, but one could argue that using DSS to downscale such a large amount is insane in the first place, as the produced image is rather bad quality. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com

[PATCH 07/11] OMAPDSS: DISPC: check if scaling setup failed

checks to bail out if the scaling algorithm failed. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/dispc.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index

[PATCH 01/11] OMAPDSS: DISPC: work-around for errata i631

. The issue exist on all OMAP4 and OMAP5 based DSS IPs. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/dispc.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index

[PATCH 04/11] OMAPDSS: DISPC: add check for scaling limits

, but that seems to be for five-tap scaling, which allows scaling down to x0.25. This patch adds checks for both horizontal and vertical scaling. For horizontal the HW always uses 5 taps, so the limit is x0.25. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss

[PATCH 09/11] OMAPDSS: DISPC: scaler debug print

Improve the DISPC debug print for scaling. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/dispc.c | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss

[PATCH 06/11] OMAPDSS: DISPC: fix 64 bit issue in 5-tap

. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/dispc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index 4488d9367bd3..2db1c986e989 100644 --- a/drivers

[PATCH 00/11] OMAPDSS: scaling misc fixes

Hi, Here are some mostly scaling related fixes for omapdss, forward ported from TI's kernel (i.e. they've seen quite a bit of testing there). Tomi Tomi Valkeinen (11): OMAPDSS: DISPC: work-around for errata i631 OMAPDSS: DISPC: fix predecimation for YUV modes OMAPDSS: DISPC: fix

[PATCH 03/11] OMAPDSS: DISPC: fix check_horiz_timing_omap3 args

. This causes the driver to possibly reject scaling that would work. This patch fixes the parameters. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/dispc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss

[PATCH 02/11] OMAPDSS: DISPC: fix predecimation for YUV modes

driver return an error if the user gives uneven input width for a YUV buffer. It also makes the input width even in case of predecimation. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/dispc.c | 36 +++ 1 file changed, 36

[PATCH 2/7] OMAPDSS: refactor dss probe function

Refactor dss probe function by extracting the setup for video plls into a separate function. The call to this function is also moved to a slightly earlier phase, so that in error case we can bail out more easily. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2

[PATCH 6/7] OMAPDSS: componentize omapdss

are registered in that order, which causes the components to be added in that order, which makes the components to be bound in that order. This feels a bit fragile, and we probably should improve the code to manage binds in random order. However, for now, this works fine. Signed-off-by: Tomi Valkeinen

[PATCH 7/7] OMAPDSS: simplify submodule reg/unreg code

properly: if registering a driver fails, we can stop processing and return the error. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/core.c | 46 1 file changed, 15 insertions(+), 31 deletions(-) diff --git a/drivers/video

[PATCH 4/7] OMAPDSS: remove uses of __init/__exit

. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/dispc.c | 20 ++-- drivers/video/fbdev/omap2/dss/dpi.c | 14 +++--- drivers/video/fbdev/omap2/dss/dsi.c | 6 +++--- drivers/video/fbdev/omap2/dss/dss.c | 26

[PATCH 3/7] OMAPDSS: fix dss_init_ports error handling

The return value of dss_init_ports() is not handled at all, causing crashes later if the call failed. This patch adds the error handling, and we also move the call to a slightly earlier place to make bailing out easier. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev

[PATCH 5/7] OMAPDSS: reorder uninit calls

We have a list of function pointers to dss submodule uninit functions. It makes sense to do the uninit in the reverse order to init, but that is not currently the case. This patch reorders the uninit calls to be the reverse of init order. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com

[PATCH 0/7] OMAPDSS: use components (fix probing problems)

this properly, the component system felt fine for the job, and it seems to work nicely. Tomi Tomi Valkeinen (7): OMAPDSS: move 'dss_initialized' to dss driver OMAPDSS: refactor dss probe function OMAPDSS: fix dss_init_ports error handling OMAPDSS: remove uses of __init/__exit OMAPDSS: reorder

[PATCH 1/7] OMAPDSS: move 'dss_initialized' to dss driver

accurately. For now, it'll signal that dss_core is ready, which is not quite correct but still better than previously. The following patches will add component system to omapdss, and after those patches 'dss_initialized' will signal that all the submodules are ready. Signed-off-by: Tomi Valkeinen

Re: [PATCH] fbdev: omap2: remove potential format string leak

On 09/06/15 01:30, Kees Cook wrote: Since kobject_init_and_add takes a format string, make sure that the passed in name cannot be accidentally parsed. Signed-off-by: Kees Cook keesc...@chromium.org --- drivers/video/fbdev/omap2/dss/display-sysfs.c | 2 +- 1 file changed, 1 insertion(+),

Re: [PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

On 03/06/15 20:16, Tony Lindgren wrote: OK, since there are no other merge conflicts that I'm aware of, it's best that you merge the whole branch. I've acked the patches, so for this one too: Ok, I can do that, but isn't this more linux-arm stuff? All the driver side code is already in

Re: [PATCH 0/5] OMAPDSS: HDMI audio compliance fixes

Hi, On 22/04/15 16:22, Jyri Sarha wrote: I have rebased these patches from ti-linux-3.14.y on top of Linux 4.0.0. I tested them briefly on OMAP4 and OMAP5 in my environment, but I could not test any channel count beyond stereo. However, there were no conflicts in the rebase and each fix makes

Re: [PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

On 02/06/15 00:51, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [150531 23:25]: AM57xx Beagle X15 has a HDMI output. This patch adds the device tree nodes required for HDMI. This one does not seem to apply to linux next, did not look further where it conflicts. Looks like

Re: [PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

On 03/06/15 18:44, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [150603 04:28]: On 02/06/15 00:51, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [150531 23:25]: AM57xx Beagle X15 has a HDMI output. This patch adds the device tree nodes required for HDMI

Re: [PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

On 02/06/15 00:51, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [150531 23:25]: AM57xx Beagle X15 has a HDMI output. This patch adds the device tree nodes required for HDMI. This one does not seem to apply to linux next, did not look further where it conflicts. Looks like

Re: [PATCHv3 00/10] ARM: DRA7: add display support

On 01/06/15 08:46, Paul Walmsley wrote: Hi Tomi On Wed, 6 May 2015, Tomi Valkeinen wrote: This series adds the arch/arm/ side of the display support for DRA7 (DRA72x, DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards is added. This series is v3

[PATCHv4 03/10] arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk

-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: devicet...@vger.kernel.org --- arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi index 470f39c4e326..357bedeebfac 100644 --- a/arch/arm

[PATCHv4 00/10] ARM: DRA7: add display support

. Tomi Tomi Valkeinen (10): arm: dra7: add DESHDCP clock CLK: TI: always enable DESHDCP clock arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk ARM: DRA7: hwmod: add DMM hwmod description ARM: DRA7: hwmod: set DSS submodule parent hwmods ARM: OMAP: display: change compat names

[PATCHv4 02/10] CLK: TI: always enable DESHDCP clock

is always enabled, and for DRA7 we have the possibility to gate it. So, as we don't have any clean way to enable and disable the clock based on the need, this patch enables the clock at boot time, making it work similarly to OMAP5. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/clk/ti

[PATCHv4 01/10] arm: dra7: add DESHDCP clock

Add a new Linux clock for DRA7 based SoCs to control DESHDCP clock. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/boot/dts/dra7.dtsi | 5 + arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 + drivers

[PATCHv4 09/10] arm/dts: dra72-evm.dts: add HDMI

DRA72 EVM has a HDMI output. This patch adds the device tree nodes required for HDMI. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: devicet...@vger.kernel.org --- arch/arm/boot/dts/dra72-evm.dts | 110 1 file changed, 110 insertions(+) diff

[PATCHv4 08/10] arm/dts: dra7.dtsi: add DSS support

DRA7xxx contains a very similar DSS to OMAP5. The main differences are: * no DSI or RFBI support. * 1 or 2 dedicated video PLLs. * need to do additional configuration to the DRA7 CONTROL module. DRA72xx has only one video PLL, and DRA74xx has two. Signed-off-by: Tomi Valkeinen tomi.valkei

[PATCHv4 07/10] ARM: OMAP2+: display: detect DRA7 DSS

Add platform code to detect DRA7 DSS. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index 9868d0bc7805..6ab13d18c636 100644 --- a/arch/arm

[PATCHv4 05/10] ARM: DRA7: hwmod: set DSS submodule parent hwmods

Set DSS core hwmod as the parent for all the DSS submodules. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2

[PATCHv4 06/10] ARM: OMAP: display: change compat names to array

Simplify the DSS detection logic by creating a list of the omapdss compat strings, instead of checking each separately with an 'if'. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/display.c | 29 ++--- 1 file changed, 14 insertions(+), 15

[PATCHv4 04/10] ARM: DRA7: hwmod: add DMM hwmod description

Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b

[PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

AM57xx Beagle X15 has a HDMI output. This patch adds the device tree nodes required for HDMI. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: devicet...@vger.kernel.org --- arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 + 1 file changed, 81 insertions

Re: [PATCH] fbdev: omap2: improve usage of gpiod API

On 28/05/15 11:05, Uwe Kleine-König wrote: Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. Also make use of

Re: [PATCHv3 10/10] CLK: TI: always enable DESHDCP clock

On 20/05/15 14:47, Tero Kristo wrote: On 05/06/2015 01:08 PM, Tomi Valkeinen wrote: DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That clock is an odd one, as it is not supposed to be any kind of core clock for DSS, and we don't even support HDCP, but the clock is still

Re: [PATCH v5 0/6] Use DRM component API in tilcdc to connect to tda998x

On 08/05/15 14:27, Jyri Sarha wrote: For all that I know this should be good for taking. Changes since v4 * Rebased on top linux-4.1-rc2 * Drop drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_... * Make connector_funcs const in struct tilcdc_drm_private because struct

Re: [PATCH] video: omap/h3: fix tps65010 dependency

On 22/05/15 17:22, Arnd Bergmann wrote: The h3 LCD driver fails to link when tps65010 is configured as a loadable module: drivers/built-in.o: In function `h3_panel_disable': debugfs.c:(.text+0x206ac): undefined reference to `tps65010_set_gpio_out_value' debugfs.c:(.text+0x206cc):

Re: [PATCHv3 10/10] CLK: TI: always enable DESHDCP clock

On 21/05/15 06:06, Paul Walmsley wrote: Enable falls under the critical clocks discussion that is ongoing. I assume that this is some sort of critical clock that can't be turned off? It only needs to be enabled for this particular display IP subsystem to function:

Re: [PATCHv3 00/10] ARM: DRA7: add display support

Hi, On 06/05/15 13:08, Tomi Valkeinen wrote: Hi, This series adds the arch/arm/ side of the display support for DRA7 (DRA72x, DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards is added. This series is v3, and is based on v4.1-rc2. There are no differences

[PATCHv3 10/10] CLK: TI: always enable DESHDCP clock

is always enabled, and for DRA7 we have the possibility to gate it. So, as we don't have any clean way to enable and disable the clock based on the need, this patch enables the clock at boot time, making it work similarly to OMAP5. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/clk/ti

Re: [GIT PULL] ARM: OMAP2+: OMAP DRA7xx display-related hwmod data changes for v4.1

-for-v4.1/20150403123702/ Tomi Valkeinen (2): ARM: DRA7: hwmod: add DMM hwmod description ARM: DRA7: hwmod: set DSS submodule parent hwmods arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 32

Re: [PATCHv2 03/10] ARM: DRA7: hwmod: set DSS submodule parent hwmods

On 03/04/15 22:03, Paul Walmsley wrote: On Tue, 24 Mar 2015, Tomi Valkeinen wrote: Set DSS core hwmod as the parent for all the DSS submodules. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Thanks, queued. Will send a pull request for this to Tony today, but it may not make

Re: [PATCH v3 0/7] Use DRM component API in tilcdc to connect to tda998x

Hi, On 18/03/15 11:06, Jyri Sarha wrote: I think the patches 1-5 are ready for merging. See the details below. I applied these on top of v4.0-rc3, booted up BBB, and loaded the modules. After doing that and waiting a few secs: # ./s-bbb.sh [ 15.237139] sysrq: SysRq : Changing Loglevel [

[PATCHv2 06/10] arm/dts: dra7.dtsi: add DSS support

DRA7xxx contains a very similar DSS to OMAP5. The main differences are: * no DSI or RFBI support. * 1 or 2 dedicated video PLLs. * need to do additional configuration to the DRA7 CONTROL module. DRA72xx has only one video PLL, and DRA74xx has two. Signed-off-by: Tomi Valkeinen tomi.valkei

[PATCHv2 00/10] ARM: DRA7: add display support

to v1 is that the DESHDCP clock is a real clock, even if we still always enable it at boot time. Tomi Tomi Valkeinen (10): arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk ARM: DRA7: hwmod: add DMM hwmod description ARM: DRA7: hwmod: set DSS submodule parent hwmods ARM: OMAP

[PATCHv2 07/10] arm/dts: dra72-evm.dts: add HDMI

DRA72 EVM has a HDMI output. This patch adds the device tree nodes required for HDMI. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: devicet...@vger.kernel.org --- arch/arm/boot/dts/dra72-evm.dts | 110 1 file changed, 110 insertions(+) diff

[PATCHv2 10/10] CLK: TI: always enable DESHDCP clock

is always enabled, and for DRA7 we have the possibility to gate it. So, as we don't have any clean way to enable and disable the clock based on the need, this patch enables the clock at boot time, making it work similarly to OMAP5. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/clk/ti

[PATCHv2 02/10] ARM: DRA7: hwmod: add DMM hwmod description

Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b

[PATCHv2 08/10] arm/dts: am57xx-beagle-x15.dts: add HDMI

AM57xx Beagle X15 has a HDMI output. This patch adds the device tree nodes required for HDMI. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: devicet...@vger.kernel.org --- arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 + 1 file changed, 81 insertions

[PATCHv2 01/10] arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk

-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: devicet...@vger.kernel.org --- arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi b/arch/arm/boot/dts/dra7xx-clocks.dtsi index 4bdcbd61ce47..0d76233840e6 100644 --- a/arch/arm

[PATCHv2 05/10] ARM: OMAP2+: display: detect DRA7 DSS

Add platform code to detect DRA7 DSS. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c index 9868d0bc7805..6ab13d18c636 100644 --- a/arch/arm

[PATCHv2 04/10] ARM: OMAP: display: change compat names to array

Simplify the DSS detection logic by creating a list of the omapdss compat strings, instead of checking each separately with an 'if'. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/mach-omap2/display.c | 29 ++--- 1 file changed, 14 insertions(+), 15

[PATCHv2 09/10] arm: dra7: add DESHDCP clock

Add a new Linux clock for DRA7 based SoCs to control DESHDCP clock. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- arch/arm/boot/dts/dra7.dtsi | 5 + arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 + drivers

  1   2   3   4   5   6   7   8   9   10   >