On 20/01/15 07:23, Nicholas Mc Guire wrote:
if(!wait_for_completion_interruptible_timeout(...))
only handles the timeout case - this patch adds handling the
signal case the same as timeout and cleans up.
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
Only the timeout case was
On 10/03/15 16:46, Russell King - ARM Linux wrote:
In which case, let me propose that the exynos fbdev driver needs to be
moved to drivers/staging, and stay there until this stuff gets fixed.
drivers/staging is supposed to be for stuff which isn't up to the mark,
and which is potentially
On 12/01/15 10:43, Joonyoung Shim wrote:
+Cc Tomi Valkeinen,
Hi Uwe,
On 01/12/2015 04:50 PM, Uwe Kleine-König wrote:
Hello,
On Mon, Jan 12, 2015 at 11:53:02AM +0900, Joonyoung Shim wrote:
This is required in order to ensure that core system devices such as
voltage regulators attached
On 18/12/14 15:48, nick wrote:
Lucas,
That's fair do you known of anyone who does have the hardware so we can test
my patch. If you do then we can get this fixed rather
easily.
Cheers Nick
On 2014-12-18 08:39 AM, Lucas Stach wrote:
Am Donnerstag, den 18.12.2014, 08:35 -0500 schrieb
On 12/12/14 11:51, Javier Martinez Canillas wrote:
Tomi and Laurent,
You asked Ajay to change his series to use the video port and enpoints DT
bindings instead of phandles, could you please review his latest version?
Looking only at the binding documentation patch, looks good to me.
Tomi
On 06/10/14 17:40, Laurent Pinchart wrote:
But seriously speaking, I was thinking about this. I'd really like to
have a generic video-mux node, that would still somehow allow us to have
device specific configurations for the video sources and sinks (which
the endpoints provide us), without
On 07/10/14 10:23, Laurent Pinchart wrote:
You mean the bridge driver would somehow take a peek into panel1 and
panel2 nodes, looking for bridge specific properties? Sounds somewhat
fragile to me... How would the bridge driver know a property is for the
bridge?
No, I mean the bridge driver
On 20/09/14 14:22, Ajay kumar wrote:
Well, I am okay with using video ports to describe the relationship
between the encoder, bridge and the panel.
But, its just that I need to make use of 2 functions when phandle
does it using just one function ;)
-panel_node =
On 25/09/14 09:23, Thierry Reding wrote:
How are cameras different? The CPU wants to capture video data from the
camera, so it needs to go look for a video capture device, which in turn
needs to involve a sensor.
Let's say we have an XXX-to-YYY encoder. We use that encoder to convert
the
On 23/09/14 17:41, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 12:34:54PM +0200, Andrzej Hajda wrote:
On 09/23/2014 12:10 PM, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
On 09/23/2014 10:35 AM, Thierry Reding wrote:
[...]
But I agree that it would
On 23/09/14 17:45, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 02:31:35PM +0300, Tomi Valkeinen wrote:
On 23/09/14 12:39, Thierry Reding wrote:
My point is that if you use plain phandles you usually have the
meta-data already. Referring to the above example, bridge0 knows that it
should
On 23/09/14 17:58, Thierry Reding wrote:
But if a panel driver controls its video source, it makes sense for the
panel driver to get its video source in its probe, and that happens
easiest if the panel has a link to the video source.
That's an orthogonal problem. You speak about the link in
On 23/09/14 08:53, Thierry Reding wrote:
Yes, it's true we need a mux there. But we still have the complication
that for panel0 we may need different ps8622 settings than for panel1.
Yes, and that's why the bridge should be querying the panel for the
information it needs to determine the
On 23/09/14 09:04, Thierry Reding wrote:
I certainly agree that it's useful to have standard ways to describe at
least various aspects. For example I think it would be useful to add
standard properties for a bridge's connections, such as bridge or
panel to allow bridge chaining and attaching
On 23/09/14 09:21, Thierry Reding wrote:
Well, I can write almost any kind of bindings, and then evidently my
device would work. For me, on my board.
Well, that's the whole problem with DT. For many devices we only have a
single setup to test against. And even when we have several they
On 23/09/14 11:35, Thierry Reding wrote:
Well, a display controller is never going to attach to a panel directly.
With parallel RGB, that (almost) happens. There's voltage level shifting
probably in the middle, but I don't see anything else there.
But I agree that it would be nice to unify
On 23/09/14 12:28, Thierry Reding wrote:
But, for example, let's say that the board is designed in a way that for
panel0 the bridge needs to output a bit higher level voltages than for
panel1. That's not a property of the panel, so it can't be queried from
the panel.
That feature (varying
On 23/09/14 12:39, Thierry Reding wrote:
My point is that if you use plain phandles you usually have the
meta-data already. Referring to the above example, bridge0 knows that it
should look for a bridge with phandle bridge1, whereas bridge1 knows
that the device it is connected to is a panel.
On 23/09/14 12:53, Thierry Reding wrote:
Yes, but in this case we know of existing boards that have complex
setups. It's not theoretical.
Complex setups involving /this particular/ bridge and binding are
theoretical at this point, however.
Right, but this discussion, at least from my part,
On 23/09/14 13:01, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 12:40:24PM +0300, Tomi Valkeinen wrote:
On 23/09/14 11:35, Thierry Reding wrote:
Well, a display controller is never going to attach to a panel directly.
With parallel RGB, that (almost) happens. There's voltage level shifting
On 23/09/14 17:29, Thierry Reding wrote:
Trying to do this within the bridge's node directly has two flaws:
1) It violates the DT principle of describing hardware. The
device itself does not know anything about multiple streams
and deals only with a single input and output.
On 23/09/14 17:38, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 03:09:44PM +0300, Tomi Valkeinen wrote:
On 23/09/14 13:01, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 12:40:24PM +0300, Tomi Valkeinen wrote:
[...]
What exactly is a bridge and what is an encoder? Those are DRM
constructs
On 22/09/14 10:54, Thierry Reding wrote:
I wish all new display component bindings would use the video
ports/endpoints to describe the connections. It will be very difficult
to improve the display driver model later if we're missing such critical
pieces from the DT bindings.
I disagree.
On 22/09/14 11:06, Thierry Reding wrote:
Why do we need a complex graph when it can be handled using a simple
phandle?
Maybe in your case you can handle it with simple phandle. Can you
guarantee that it's enough for everyone, on all platforms?
Nobody can guarantee that. An interesting
On 22/09/14 11:26, Thierry Reding wrote:
On Fri, Sep 19, 2014 at 05:28:37PM +0300, Tomi Valkeinen wrote:
On 19/09/14 16:59, Ajay kumar wrote:
I am not really able to understand, what's stopping us from using this
bridge on a board with complex display connections. To use ps8622 driver,
one
On 20/09/14 18:27, Javier Martinez Canillas wrote:
I see that Documentation/devicetree/bindings/video/ti,omap-dss.txt
mentions that the Video Ports binding documentation is in
Documentation/devicetree/bindings/video/video-ports.txt but I don't
see that this file exists in the kernel [1]. I
On 18/09/14 08:50, Ajay kumar wrote:
Why do we need a complex graph when it can be handled using a simple
phandle?
Maybe in your case you can handle it with simple phandle. Can you
guarantee that it's enough for everyone, on all platforms?
Yes, as of now exynos5420-peach-pit and
On 19/09/14 16:59, Ajay kumar wrote:
I am not really able to understand, what's stopping us from using this
bridge on a board with complex display connections. To use ps8622 driver,
one needs to attach it to the DRM framework. For this, the DRM driver
Remember that when we talk about DT
On 27/08/14 17:39, Ajay Kumar wrote:
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/video/bridge/ps8622.txt| 20
1 file changed, 20 insertions(+)
On 17/09/14 17:29, Ajay kumar wrote:
Hi Tomi,
Thanks for your comments.
On Wed, Sep 17, 2014 at 5:22 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 27/08/14 17:39, Ajay Kumar wrote:
Add documentation for DT properties supported by ps8622/ps8625
eDP-LVDS converter.
Signed-off
On 22/07/14 06:41, YoungJun Cho wrote:
Yes, this command is related with Nokia.
Last Friday, I met panel vendor guy for some issues.
At the break time, I asked him for about this Read IDs(04H), why it is
not included in DCS specification.
He said that this command was originated by Nokia.
On 22/07/14 10:49, Thierry Reding wrote:
But what I was trying to say is that if the Read IDs command isn't an
official DCS command, maybe it would be a better idea to use the DDB
instead. I assume that even if it isn't the same information it would
at least be a superset and therefore a
On 30/06/14 22:14, Vasily Khoruzhick wrote:
Use clk_prepare_enable/clk_disable_unprepare to make the driver
work properly with common clock framework.
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
drivers/video/fbdev/s3c2410fb.c | 10 +-
1 file changed, 5 insertions(+),
On 01/07/14 00:32, Kukjin Kim wrote:
This patch removes fimd codes for s5p6440 and s5p6450 SoCs.
Signed-off-by: Kukjin Kim kgene@samsung.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
---
.../devicetree/bindings/video/samsung-fimd.txt |1 -
drivers/video/fbdev/Kconfig
a dependency if they depend on
one of the supported architectures specifically.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Kukjin Kim kgene@samsung.com
---
drivers/video/exynos/Kconfig |2
On 07/03/14 14:22, Andrzej Hajda wrote:
I think we should even extend the bindings to fimd:
dsi {
port@0 {
dsi_0: endpoint {
remote-endpoint=fimd_0;
}
}
port@1 {
dsi_1: endpoint {
remote-endpoint=lvds_0;
}
}
}
On 07/03/14 16:17, Andrzej Hajda wrote:
On 03/07/2014 02:28 PM, Tomi Valkeinen wrote:
(...)
There are many possible connections from FIMD, some of them:
FIMD --- RGB panel, external
FIMD --- DSI, on SoC
FIMD --- eDP, on SoC
FIMD --- ImageEnhacer, on SoC
This sounds similar to OMAP
On 04/03/14 14:00, Andrzej Hajda wrote:
I have made video path binding optional, in case of video bus
if the specific video path is not present driver uses the bus it is
connected to.
In case DSI panel is controlled via different bus the path should be
specified
explicitly.
I have no
On 12/02/14 13:31, Andrzej Hajda wrote:
The patch adds s6e8aa0 panel node for trats2.
It adds also trats2 specific properties for DSI
and regulator required by panel.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
arch/arm/boot/dts/exynos4412-trats2.dts | 47
On 28/02/14 15:31, Tomi Valkeinen wrote:
Compared to what I've done on OMAP, you don't seem to specify the video
inputs for the tc358764 at all. In this case it's obvious, as the chip
is a child of the DSI master. But the chip could as well be controlled
via i2c, and so be placed as a child
On 12/02/14 13:31, Andrzej Hajda wrote:
The patch adds bridge and panel nodes.
It adds also DSI properties specific for arndale board.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
arch/arm/boot/dts/exynos5250-arndale.dts | 39
1 file changed, 39
On 2013-11-15 04:52, Sachin Kamat wrote:
+ Tomi
Hi Olof,
On 15 November 2013 02:39, Olof Johansson o...@lixom.net wrote:
commit 7e0be9f9f7cba3356f75b86737dbe3a005da067e ('video: exynos_mipi_dsim:
Use the generic PHY driver') resulted in a warning about an unused
variable:
++---
3 files changed, 13 insertions(+), 12 deletions(-)
Acked-by: Tomi Valkeinen tomi.valkei...@ti.com
Tomi
signature.asc
Description: OpenPGP digital signature
On 02/07/13 14:26, Mark Brown wrote:
From: Mark Brown broo...@linaro.org
Ensure that the definitions of functions match the prototypes used by
other modules by including the header with the prototypes in the files
with the definitions.
Signed-off-by: Mark Brown broo...@linaro.org
Thanks,
Hi,
On 2013-04-11 03:04, Arnd Bergmann wrote:
In multiplatform configurations, we cannot include headers
provided by only the exynos platform. Fortunately a number
of drivers that include those headers do not actually need
them, so we can just remove the inclusions.
Signed-off-by: Arnd
On 2013-02-08 16:54, Marcus Lorentzon wrote:
On 02/08/2013 03:02 PM, Tomi Valkeinen wrote:
On 2013-02-08 15:28, Marcus Lorentzon wrote:
When we do that we stop-setup-start during blanking. So our DSS is
optimized to be able to do that without getting blocked. All DSI video
mode panels
On 2013-02-11 11:31, Marcus Lorentzon wrote:
Ok, so what about a compromise which I think would work for both HWs
... we allow the configure operation during video on, then each HW
driver could decide if this means you have to stop or not to do the
changes required. But then it is also
Hi,
On 2013-02-03 21:17, Tomasz Figa wrote:
Hi Laurent,
On Saturday 02 of February 2013 11:39:59 Laurent Pinchart wrote:
Hi Tomasz,
Thank you for your RFC.
On Wednesday 30 January 2013 16:38:59 Tomasz Figa wrote:
Changes done to Tomi's edition of CDF:
- Replaced set_operation_mode,
On 2013-02-08 14:40, Marcus Lorentzon wrote:
I agree, but I think it should be
setup-enable-video_on-video_off-disable-setup-...
I don't think there is any interface parameters that should be changed
while link is enabled. And if there are, they should be identified and
split out into a
On 2013-02-08 15:28, Marcus Lorentzon wrote:
When we do that we stop-setup-start during blanking. So our DSS is
optimized to be able to do that without getting blocked. All DSI video
mode panels (and DPI) products we have done so far have not had any
issue with that (as long as DSI HS clock
On Tue, 2011-09-20 at 20:08 +0300, Baruch Siach wrote:
Hi Ajay,
On Tue, Sep 20, 2011 at 08:56:57PM +0530, Ajay kumar wrote:
Hi Baruch,
On Tue, Sep 20, 2011 at 4:54 PM, Baruch Siach bar...@tkos.co.il wrote:
Hi Ajay,
On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:
On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
This patch adds a data structure definiton to hold framebuffer windows/planes.
An ioctl number is also added to provide user access
to change window position dynamically.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Signed-off-by:
On Tue, 2011-09-20 at 20:16 +0530, Ajay kumar wrote:
Hi Tomi,
On Tue, Sep 20, 2011 at 4:40 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
This patch adds a data structure definiton to hold framebuffer
windows/planes.
An ioctl
On Tue, 2011-09-20 at 16:55 +, Florian Tobias Schandinat wrote:
Did you have a look at the (existing) API [1] Laurent proposed for discovering
the internal connections between the framebuffers (or with any other devices)?
I know the basics of media controller, but I haven't really looked
Hi,
On Thu, 2011-09-01 at 16:45 +, Florian Tobias Schandinat wrote:
Hi all,
On 08/25/2011 07:51 PM, Ajay Kumar wrote:
Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP
seem to be doing window/plane positioning in their driver code.
Is it possible to have this
55 matches
Mail list logo
