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 u
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
> ---
>
> Only the timeout case was being handled
Hi,
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
> ---
>
> Only the timeout case was being ha
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 th
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 schr
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.
To
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 = of_parse_phandle(
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 brid
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), wit
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 So
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
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 abo
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 agre
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
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 inp
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, th
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
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 pa
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
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 b
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 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 att
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
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 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 "
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 i
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 dis
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 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 an
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 wrote:
>> On 27/08/14 17:39, Ajay Kumar wrote:
>>> Add documentation for DT properties supported by ps8622/ps8625
>>> eDP-LVDS
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
> ---
> .../devicetree/bindings/video/bridge/ps8622.txt| 20
>
> 1 file changed, 20 insertions(+)
> create mode 1
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 s
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 No
On 01/07/14 00:32, Kukjin Kim wrote:
> This patch removes fimd codes for s5p6440 and s5p6450 SoCs.
>
> Signed-off-by: Kukjin Kim
> Cc: Tomi Valkeinen
> ---
> .../devicetree/bindings/video/samsung-fimd.txt |1 -
> drivers/video/fbdev/Kconfig
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
> ---
> drivers/video/fbdev/s3c2410fb.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(
enu only need a dependency if they depend on
> one of the supported architectures specifically.
>
> Signed-off-by: Jean Delvare
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: Kukjin Kim
> ---
> drivers/video/exynos/Kconfig |2 +-
>
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
>>
On 07/03/14 15:07, Andrzej Hajda wrote:
> On 03/07/2014 01:32 PM, Tomi Valkeinen wrote:
>> On 07/03/14 14:22, Andrzej Hajda wrote:
>>
>>> I think we should even extend the bindings to fimd:
>>> dsi {
>>> port@0 {
>>> dsi_0:
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 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
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
> ---
> arch/arm/boot/dts/exynos5250-arndale.dts | 39
>
> 1 file changed, 39 insertions(+
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
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
> ---
> arch/arm/boot/dts/exynos4412-trats2.dts | 47
> +
On 2013-11-15 04:52, Sachin Kamat wrote:
> + Tomi
>
> Hi Olof,
>
> On 15 November 2013 02:39, Olof Johansson wrote:
>> commit 7e0be9f9f7cba3356f75b86737dbe3a005da067e ('video: exynos_mipi_dsim:
>> Use the generic PHY driver') resulted in a warning about an unused
>> variable:
>>
>> drivers/video
ged, 13 insertions(+), 12 deletions(-)
Acked-by: Tomi Valkeinen
Tomi
signature.asc
Description: OpenPGP digital signature
On 02/07/13 14:26, Mark Brown wrote:
> From: Mark Brown
>
> 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
Thanks, queued this for 3.12.
Tomi
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: Arn
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
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
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
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 i
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
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 wrote:
> > > Hi Ajay,
> > >
> > > On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:
> > >> T
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
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 wrote:
> > On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
> >> This patch adds a data structure definiton to hold framebuffer
> >> window
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
> Signed-off-by: Banajit Goswami
> S
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 ha
57 matches
Mail list logo
