Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

On 25/04/18 14:13, Bartlomiej Zolnierkiewicz wrote: > > On Monday, April 23, 2018 05:11:14 PM Tomi Valkeinen wrote: >> On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote: >> >>> Ideally we should be able to build both drivers in the same kernel >>> (especial

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

On 25/04/18 13:02, Laurent Pinchart wrote: > Hi Tomi, > > On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote: >> On 25/04/18 12:03, Laurent Pinchart wrote: >>> Could we trim down omapfb to remove support for the devices supported by >>> omapdrm

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

On 25/04/18 12:03, Laurent Pinchart wrote: > Could we trim down omapfb to remove support for the devices supported by > omapdrm ? I was thinking about just that. But, of course, it's not quite straightforward either. We've got DSI manual update functionality in OMAP3-OMAP5 SoCs, which covers a

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

On 23/04/18 23:09, Mauro Carvalho Chehab wrote: >> I don't think it's worth it renaming the common symbols. They will change >> over >> time as omapdrm is under heavy rework, and it's painful enough without >> having >> to handle cross-tree changes. > > It could just rename the

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote: > Ideally we should be able to build both drivers in the same kernel > (especially as modules). > > I was hoping that it could be fixed easily but then I discovered > the root source of the problem: > > drivers/gpu/drm/omapdrm/dss/display.o:

Re: [PATCH v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST

deo/fbdev/omap2/Kconfig > +++ b/drivers/video/fbdev/omap2/Kconfig > @@ -1,4 +1,4 @@ > -if ARCH_OMAP2PLUS > +if ARCH_OMAP2PLUS || COMPILE_TEST > > source "drivers/video/fbdev/omap2/omapfb/Kconfig" > > Acked-by: Tomi Valkeinen <tomi.valkei...@ti.com> Tom

Re: [PATCH for 4.15] omapdrm/dss/hdmi4_cec: fix interrupt handling

On 04/12/17 15:32, Hans Verkuil wrote: The omap4 CEC hardware cannot tell a Nack from a Low Drive from an Arbitration Lost error, so just report a Nack, which is almost certainly the reason for the error anyway. This also simplifies the implementation. The only three interrupts that need to be

Re: [PATCHv2 0/9] omapdrm: hdmi4: add CEC support

 Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 12/10/17 12:42, Hans Verkuil wrote: > On 10/12/17 10:03, Tomi Valkeinen wrote: >> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsink

Re: [PATCHv2 0/9] omapdrm: hdmi4: add CEC support

 Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 12/10/17 09:50, Hans Verkuil wrote: >> I can't test with a TV, so no CEC for me... But otherwise I think the >> series works ok now, and looks ok. So I'll apply,

Re: [PATCHv2 0/9] omapdrm: hdmi4: add CEC support

Hi Hans, >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 11/08/17 13:57, Tomi Valkeinen wrote: >> >>> I'm doing some testing with this series on my panda. One issue I see is >>>

Re: [PATCHv2 0/9] omapdrm: hdmi4: add CEC support

Hi Hans, Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 11/08/17 13:57, Tomi Valkeinen wrote: > I'm doing some testing with this series on my panda. One issue I see is > that when I unload the display m

Re: [PATCHv2 0/9] omapdrm: hdmi4: add CEC support

 Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 11/08/17 13:57, Tomi Valkeinen wrote: > Hi Hans, > > On 02/08/17 11:53, Hans Verkuil wrote: >> From: Hans Verkuil <hans.verk...@cisco.com> &g

Re: [PATCHv2 0/9] omapdrm: hdmi4: add CEC support

Hi Hans, Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 02/08/17 11:53, Hans Verkuil wrote: > From: Hans Verkuil > > This patch series adds CEC support for the omap4. It is based on >

Re: [PATCH 8/8] omapdrm: hdmi4: hook up the HDMI CEC support

On 08/06/17 10:34, Hans Verkuil wrote: >> Peter is about to send hotplug-interrupt-handling series, I think the >> HPD function work should be done on top of that, as otherwise it'll just >> conflict horribly. > > Has that been merged yet? And if so, what git repo/branch should I base > my next

Re: [PATCH 8/8] omapdrm: hdmi4: hook up the HDMI CEC support

On 06/05/17 14:58, Hans Verkuil wrote: > My assumption was that hdmi_display_disable() was called when the hotplug > would go > away. But I discovered that that isn't the case, or at least not when X is > running. > It seems that the actual HPD check is done in hdmic_detect() in >

Re: [PATCH 0/8] omapdrm: add OMAP4 CEC support

On 14/04/17 13:25, Hans Verkuil wrote: > From: Hans Verkuil > > This patch series adds support for the OMAP4 HDMI CEC IP core. What is this series based on? It doesn't apply to drm-next, and: fatal: sha1 information is lacking or useless

Re: [PATCH 2/8] omapdrm: encoder-tpd12s015: keep ls_oe_gpio high if CEC is enabled

On 14/04/17 13:25, Hans Verkuil wrote: > From: Hans Verkuil > > When the OMAP4 CEC support is enabled the CEC pin should always > be on. So keep ls_oe_gpio high when CONFIG_OMAP4_DSS_HDMI_CEC > is set. > > Background: even if the HPD is low it should still be possible >

Re: [PATCH 6/8] omapdrm: hdmi4: refcount hdmi_power_on/off_core

On 14/04/17 13:25, Hans Verkuil wrote: > From: Hans Verkuil > > The hdmi_power_on/off_core functions can be called multiple times: > when the HPD changes and when the HDMI CEC support needs to power > the HDMI core. > > So use a counter to know when to really power on or

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

dmi_cec.hdmi_cec */ > + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /* > hdmi_cec.hdmi_cec */ > OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /* > hdmi_scl.hdmi_scl */ > OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0)

Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

On 13/04/17 12:12, Hans Verkuil wrote: >> Is there anything else CEC needs to access or control (besides the CEC >> IP itself)? > > The CEC framework needs to be informed about the physical address contained > in the EDID (part of the CEA-861 block). And when the HPD goes down it needs > to be

Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

On 12/04/17 17:04, Hans Verkuil wrote: >> So is some other driver supporting this already? Or is the omap4 the >> first platform you're trying this on? > > No, there are quite a few CEC drivers by now, but typically the CEC block is > a totally independent IP block with its own power, irq, etc.

Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

On 12/04/17 16:03, Hans Verkuil wrote: > I noticed while experimenting with this that tpd_disconnect() in > drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c isn't called when > I disconnect the HDMI cable. Is that a bug somewhere? > > I would expect that tpd_connect and tpd_disconnect are

Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

On 08/04/17 13:11, Hans Verkuil wrote: > So, this is a bit of a blast from the past since the omap4 CEC development > has been on hold for almost a year. But I am about to resume my work on this > now that the CEC framework was merged. > > The latest code is here, if you are interested: > >

Re: [Patch 0/2] media: ti-vpe: allow user specified stride

allow use of user specified stride > > drivers/media/platform/ti-vpe/vpdma.c | 14 -- > drivers/media/platform/ti-vpe/vpdma.h | 6 +++--- > drivers/media/platform/ti-vpe/vpe.c | 34 -- > 3 files changed, 31 insertions(+), 23 deletion

Re: [Patch 2/2] media: ti-vpe: vpe: allow use of user specified stride

Hi, On 13/02/17 15:06, Benoit Parrot wrote: > Bytesperline/stride was always overwritten by VPE to the most > adequate value based on needed alignment. > > However in order to make use of arbitrary size DMA buffer it > is better to use the user space provide stride instead. > > The driver will

Re: [PATCH] [media] ti-vpe: get rid of some smatch warnings

Hi, On 22/11/16 13:09, Mauro Carvalho Chehab wrote: > When compiled on i386, it produces several warnings: > > ./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an > lvalue > ./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an > lvalue >

Re: [RFC PATCH 2/3] omap4: add CEC support

On 10/05/16 15:26, Hans Verkuil wrote: >>> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi >>> index 2bd9c83..1bb490f 100644 >>> --- a/arch/arm/boot/dts/omap4.dtsi >>> +++ b/arch/arm/boot/dts/omap4.dtsi >>> @@ -1006,8 +1006,9 @@ >>> reg =

Re: [RFC PATCH 2/3] omap4: add CEC support

Hi Hans, On 29/04/16 12:39, Hans Verkuil wrote: > From: Hans Verkuil > > Signed-off-by: Hans Verkuil > --- > arch/arm/boot/dts/omap4-panda-a4.dts | 2 +- > arch/arm/boot/dts/omap4-panda-es.dts | 2 +- > arch/arm/boot/dts/omap4.dtsi

Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

s015. > > Signed-off-by: Hans Verkuil <hans.verk...@cisco.com> > Suggested-by: Tomi Valkeinen <tomi.valkei...@ti.com> > --- > drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --g

Re: [PATCH 2/9] [media] media: omap_vout: Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns()

On 12/06/15 12:26, Laurent Pinchart wrote: Hi Tomi, On Friday 12 June 2015 12:21:13 Tomi Valkeinen wrote: On 11/06/15 07:21, Laurent Pinchart wrote: On Wednesday 10 June 2015 06:20:45 Mauro Carvalho Chehab wrote: From: Jan Kara j...@suse.cz Convert omap_vout_uservirt_to_phys() to use

Re: [PATCH 2/9] [media] media: omap_vout: Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns()

On 11/06/15 07:21, Laurent Pinchart wrote: Hello, (CC'ing Tomi Valkeinen) On Wednesday 10 June 2015 06:20:45 Mauro Carvalho Chehab wrote: From: Jan Kara j...@suse.cz Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of hand made mapping of virtual address

Re: [PATCH v7 1/3] of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint

/soc_camera.c| 3 ++- drivers/of/base.c | 9 + drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 7 +-- 6 files changed, 12 insertions(+), 48 deletions(-) For omapdss: Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc

Re: [PATCH 3/3] driver:gpio remove all usage of gpio_remove retval in driver

/fbdev/via/via-gpio.c | 10 +++--- Tomi can you ACK this? Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: OpenPGP digital signature

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 20/03/14 19:01, Grant Likely wrote: I think depending on a generic graph walk is where I have the biggest concern about the design. I don't think it is a good idea for the master device to try a generic walk over the graph looking for other devices that might be components because it

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 21/03/14 13:47, Grant Likely wrote: I'm firm on the opinion that the checking must also happen at runtime. The biggest part of my objection has been how easy it would be to get a linkage out of sync, and dtc is not necessarily the last tool to touch the dtb before the kernel gets booted. I

Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 21/03/14 00:32, Laurent Pinchart wrote: The OF graph bindings documentation could just specify the ports node as optional and mandate individual device bindings to specify it as mandatory or forbidden (possibly with a default behaviour to avoid making all device bindings too verbose).

Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 21/03/14 16:13, Laurent Pinchart wrote: Hi Tomi, On Friday 21 March 2014 15:37:17 Tomi Valkeinen wrote: On 21/03/14 00:32, Laurent Pinchart wrote: The OF graph bindings documentation could just specify the ports node as optional and mandate individual device bindings to specify

Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of

On 18/03/14 01:30, Laurent Pinchart wrote: I agree with you. I know that DT bindings review takes too much time, slows development down and is just generally painful. I'm trying to reply to this e- mail thread as fast as possible, but I'm also busy with other tasks :-/ The lack of formal

Re: [GIT PULL] Move device tree graph parsing helpers to drivers/of

Hi Philipp, Grant, On 14/03/14 14:19, Philipp Zabel wrote: People completely disagree about the direction the phandle links should point in. I am still of the opinion that the generic binding should describe just the topology, that the endpoint links in the kernel should represent an

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 12/03/14 12:25, Russell King - ARM Linux wrote: On Mon, Mar 10, 2014 at 02:52:53PM +0100, Laurent Pinchart wrote: In theory unidirectional links in DT are indeed enough. However, let's not forget the following. - There's no such thing as single start points for graphs. Sure, in some

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 11/03/14 13:43, Laurent Pinchart wrote: We could scan the whole tree for entities, ports and endpoints once, in the base oftree code, and put that into a graph structure, adding the backlinks. The of_graph_* helpers could then use that graph instead of the device tree. That could work.

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 11/03/14 15:16, Laurent Pinchart wrote: And if I gathered Grant's opinion correctly (correct me if I'm wrong), he thinks things should be explicit, i.e. the bindings for, say, an encoder should state that the encoder's output endpoint _must_ contain a remote-endpoint property, whereas the

Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 08/03/14 14:23, Grant Likely wrote: That's fine. In that case the driver would specifically require the endpoint to be that one node although the above looks a little weird The driver can't require that. It's up to the board designer to decide how many endpoints are used. A driver may

Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

On 08/03/14 14:25, Grant Likely wrote: Sure. If endpoints are logical, then only create the ones actually hooked up. No problem there. But nor do I see any issue with having empty connections if the board author things it makes sense to have them in the dtsi. I don't think they are usually

Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 10/03/14 10:58, Andrzej Hajda wrote: I want to propose another solution to simplify bindings, in fact I have few ideas to consider: 1. Use named ports instead of address-cells/regs. Ie instead of port@number schema, use port-function. This will allow to avoid ports node and

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 08/03/14 13:41, Grant Likely wrote: Ok. If we go for single directional link, the question is then: which way? And is the direction different for display and camera, which are kind of reflections of each other? In general I would recommend choosing whichever device you would sensibly

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 10/03/14 15:52, Laurent Pinchart wrote: In theory unidirectional links in DT are indeed enough. However, let's not forget the following. - There's no such thing as single start points for graphs. Sure, in some simple cases the graph will have a single start point, but that's not a

Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

On 07/03/14 20:11, Grant Likely wrote: Any board not using that port can just leave the endpoint disconnected. Hmm I see. I'm against that. I think the SoC dtsi should not contain endpoint node, or even port node (at least usually). It doesn't know how many endpoints, if any, a particular

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 07/03/14 19:05, Grant Likely wrote: On Wed, 26 Feb 2014 15:48:49 +0100, Philipp Zabel p.za...@pengutronix.de wrote: Hi Grant, thank you for the comments. Hi Philipp, I've got lots of comments and quesitons below, but I must say thank you for doing this. It is a helpful description.

Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 07/03/14 19:18, Grant Likely wrote: From a pattern perspective I have no problem with that From an individual driver binding perspective that is just dumb! It's fine for the ports node to be optional, but an individual driver using the binding should be explicit about which it will

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 07/03/14 19:06, Grant Likely wrote: On Thu, 27 Feb 2014 10:36:36 +0200, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 26/02/14 16:48, Philipp Zabel wrote: I would like the document to acknowledge the difference from the phandle+args pattern used elsewhere and a description of when

Re: [PATCH v5 5/7] [media] of: move common endpoint parsing to drivers/of

On 04/03/14 17:47, Philipp Zabel wrote: Am Dienstag, den 04.03.2014, 14:21 +0200 schrieb Tomi Valkeinen: On 04/03/14 13:36, Philipp Zabel wrote: [...] Can port_node be NULL? Probably only if something is quite wrong, but maybe it's safer to return error in that case. both

Re: [PATCH v6 0/8] Move device tree graph parsing helpers to drivers/of

devices of: Warn if of_graph_parse_endpoint is called with the root node So, as I've pointed out, I don't agree with the API, as it's too limited and I can't use it, but as this series is (mostly) about moving the current API to a common place, it's fine for me. Acked-by: Tomi Valkeinen

Re: [PATCH v5 5/7] [media] of: move common endpoint parsing to drivers/of

Hi Philipp, On 27/02/14 19:35, Philipp Zabel wrote: This patch adds a new struct of_endpoint which is then embedded in struct v4l2_of_endpoint and contains the endpoint properties that are not V4L2 (or even media) specific: the port number, endpoint id, local device tree node and remote

Re: [PATCH v5 6/7] of: Implement simplified graph binding for single port devices

On 27/02/14 19:35, Philipp Zabel wrote: For simple devices with only one port, it can be made implicit. The endpoint node can be a direct child of the device node. snip @@ -2105,9 +2112,11 @@ struct device_node *of_graph_get_remote_port_parent( /* Get remote endpoint node. */ np

Re: [PATCH v5 5/7] [media] of: move common endpoint parsing to drivers/of

On 04/03/14 13:36, Philipp Zabel wrote: Hi Tomi, Am Dienstag, den 04.03.2014, 10:58 +0200 schrieb Tomi Valkeinen: [...] +int of_graph_parse_endpoint(const struct device_node *node, + struct of_endpoint *endpoint) +{ + struct device_node *port_node = of_get_parent

Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

On 26/02/14 17:47, Philipp Zabel wrote: Ok, that looks compact enough. I still don't see the need to change make the remote-endpoint property required to achieve this, though. On the other hand, I wouldn't object to making it mandatory either. Sure, having remote-endpoint as required doesn't

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

On 26/02/14 16:48, Philipp Zabel wrote: I would like the document to acknowledge the difference from the phandle+args pattern used elsewhere and a description of when it would be appropriate to use this instead of a simpler binding. Alright. The main point of this binding is that the

Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

On 27/02/14 12:52, Philipp Zabel wrote: This is a bit verbose, and if your output port is on an encoder device with multiple inputs, the correct port number would become a bit unintuitive. For example, we'd have to use port@4 as the output encoder units that have a 4-port input multiplexer

Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

On 25/02/14 16:58, Philipp Zabel wrote: +Optional endpoint properties + + +- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node. Why is that optional? What use is an endpoint, if it's not connected to something? Also, if this is being

Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

On 26/02/14 16:57, Philipp Zabel wrote: Hi Tomi, Am Mittwoch, den 26.02.2014, 15:14 +0200 schrieb Tomi Valkeinen: On 25/02/14 16:58, Philipp Zabel wrote: +Optional endpoint properties + + +- remote-endpoint: phandle to an 'endpoint' subnode of a remote device

Re: [PATCH v2] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/media

Hi, On 11/02/14 23:41, Philipp Zabel wrote: From: Philipp Zabel philipp.za...@gmail.com This patch moves the parsing helpers used to parse connected graphs in the device tree, like the video interface bindings documented in Documentation/devicetree/bindings/media/video-interfaces.txt, from

Re: [PATCH] omap_vout: Add DVI display type support

OMAP_DISPLAY_TYPE_DPI: + case OMAP_DISPLAY_TYPE_DVI: if (mgr_id == OMAP_DSS_CHANNEL_LCD) irq = DISPC_IRQ_VSYNC; else if (mgr_id == OMAP_DSS_CHANNEL_LCD2) Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: OpenPGP

Re: [RFR 2/2] drm/panel: Add simple panel support

On 24/10/13 13:40, Laurent Pinchart wrote: panel { remote = remote-endpoint; common-video-property = asd; }; panel { port { endpoint { remote = remote-endpoint; common-video-property = asd; }; };

Re: [PATCH/RFC v3 00/19] Common Display Framework

On 17/10/13 10:48, Andrzej Hajda wrote: The main function of DSI is to transport pixels from one IP to another IP and this function IMO should not be modeled by display entity. Power, clocks, etc will be performed via control bus according to panel demands. If 'DSI chip' has additional

Re: [PATCH/RFC v3 00/19] Common Display Framework

On 17/10/13 15:26, Andrzej Hajda wrote: I am not sure what exactly the encoder performs, if this is only image transport from dispc to panel CDF pipeline in both cases should look like: dispc panel The only difference is that panels will be connected via different Linux bus adapters,

Re: [PATCH/RFC v3 00/19] Common Display Framework

On 09/10/13 17:08, Andrzej Hajda wrote: As I have adopted existing internal driver for MIPI-DSI bus, I did not take too much care for DT. You are right, 'bta-timeout' is a configuration parameter (however its minimal value is determined by characteristic of the DSI-slave). On the other

Re: [PATCH/RFC v3 00/19] Common Display Framework

On 11/10/13 14:19, Andrzej Hajda wrote: On 10/11/2013 08:37 AM, Tomi Valkeinen wrote: The minimum bta-timeout should be deducable from the DSI bus speed, shouldn't it? Thus there's no need to define it anywhere. Hmm, specification says This specified period shall be longer then the maximum

Re: [PATCH/RFC v3 00/19] Common Display Framework

On 11/10/13 17:16, Andrzej Hajda wrote: Picture size, content and format is the same on input and on output of DSI. The same bits which enters DSI appears on the output. Internally bits order can be different but practically you are configuring DSI master and slave with the same format.

Re: [PATCH V5 4/5] video: exynos_mipi_dsim: Use the generic PHY driver

++--- 3 files changed, 13 insertions(+), 12 deletions(-) Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: OpenPGP digital signature

Re: [PATCH/RFC v3 00/19] Common Display Framework

Hi Andrzej, On 02/10/13 15:23, Andrzej Hajda wrote: Using Linux buses for DBI/DSI = I still don't see how it would work. I've covered this multiple times in previous posts so I'm not going into more details now. I implemented DSI (just command mode for now) as

Re: [PATCH 1/6] v4l: ti-vpe: Create a vpdma helper library

Hi, On 02/08/13 17:03, Archit Taneja wrote: +struct vpdma_data_format vpdma_yuv_fmts[] = { + [VPDMA_DATA_FMT_Y444] = { + .data_type = DATA_TYPE_Y444, + .depth = 8, + }, This, and all the other tables, should probably be consts? +static void

Re: [PATCH 2/6] v4l: ti-vpe: Add helpers for creating VPDMA descriptors

On 02/08/13 17:03, Archit Taneja wrote: Create functions which the VPE driver can use to create a VPDMA descriptor and add it to a VPDMA descriptor list. These functions take a pointer to an existing list, and append the configuration/data/control descriptor header to the list. In the case

Re: [PATCH 3/6] v4l: ti-vpe: Add VPE mem to mem driver

On 02/08/13 17:03, Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats.

Re: [PATCH 1/6] v4l: ti-vpe: Create a vpdma helper library

On 05/08/13 14:26, Archit Taneja wrote: On Monday 05 August 2013 01:43 PM, Tomi Valkeinen wrote: +/* + * submit a list of DMA descriptors to the VPE VPDMA, do not wait for completion + */ +int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list) +{ +/* we always

Re: [PATCH 2/6] v4l: ti-vpe: Add helpers for creating VPDMA descriptors

On 05/08/13 15:05, Archit Taneja wrote: On Monday 05 August 2013 02:41 PM, Tomi Valkeinen wrote: There's quite a bit of code in these dump functions, and they are always called. I'm sure getting that data is good for debugging, but I presume they are quite useless for normal use. So I think

Re: [omapdss] fault in dispc_write_irqenable [was: Re: [omap3isp] xclk deadlock]

On 26/07/13 18:37, Jakub Piotr Cłapa wrote: Using omapfb, or...? I hope not omap_vout, because that's rather unmaintained =). Laurent's live application is using the V4L2 API for video output (to get free YUV conversion and DMA) so I guess this unfortunatelly counts as using omap_vout. Are

Re: [omap3isp] xclk deadlock

On 17/07/13 15:50, Laurent Pinchart wrote: Hi Jakub, (CC'ing Tomi Valkeinen) On Friday 12 July 2013 16:44:44 Jakub Piotr Cłapa wrote: 2. When exiting from live the kernel hangs more often then not (sometimes it is accompanied by Unhandled fault: external abort on non-linefetch

Re: [PATCH v17 2/7] video: add display_timing and videomode

Ping. On 2013-02-18 16:09, Tomi Valkeinen wrote: Hi Steffen, On 2013-01-25 11:01, Steffen Trumtrar wrote: +/* VESA display monitor timing parameters */ +#define VESA_DMT_HSYNC_LOW BIT(0) +#define VESA_DMT_HSYNC_HIGH BIT(1) +#define VESA_DMT_VSYNC_LOW BIT(2

Re: [PATCH v17 2/7] video: add display_timing and videomode

On 2013-02-27 18:05, Steffen Trumtrar wrote: Ah, sorry. Forgot to answer this. On Wed, Feb 27, 2013 at 05:45:31PM +0200, Tomi Valkeinen wrote: Ping. On 2013-02-18 16:09, Tomi Valkeinen wrote: Hi Steffen, On 2013-01-25 11:01, Steffen Trumtrar wrote: +/* VESA display monitor timing

Re: [PATCH v17 2/7] video: add display_timing and videomode

Hi Steffen, On 2013-01-25 11:01, Steffen Trumtrar wrote: +/* VESA display monitor timing parameters */ +#define VESA_DMT_HSYNC_LOW BIT(0) +#define VESA_DMT_HSYNC_HIGH BIT(1) +#define VESA_DMT_VSYNC_LOW BIT(2) +#define VESA_DMT_VSYNC_HIGH BIT(3) + +/*

Re: AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)

On 2013-02-14 11:30, Florian Neuhaus wrote: Hi Tomi, Tomi Valkeinen wrote on 2013-02-07: FIFO underflow means that the DSS hardware wasn't able to fetch enough pixel data in time to output them to the panel. Sometimes this happens because of plain misconfiguration, but usually

Re: AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)

On 2013-02-14 13:07, Laurent Pinchart wrote: In many cases underflows are rather hard to debug and solve. There are things in the DSS hardware like FIFO thresholds and prefetch, and VRFB tile sizes, which can be changed (although unfortunately only by modifying the drivers). How they should

Re: [RFC v2 0/5] Common Display Framework

On 2013-02-04 12:05, Marcus Lorentzon wrote: As discussed at FOSDEM I will give DSI bus with full feature set a try. Please do, but as a reminder I want to raise the issues I see with a DSI bus: - A device can be a child of only one bus. So if DSI is used only for video, the device is a child

Re: CDF meeting @FOSDEM report

On 2013-02-06 16:44, Alex Deucher wrote: On Wed, Feb 6, 2013 at 6:11 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: What is an encoder? Something that takes a video signal in, and lets the CPU store the received data to memory? Isn't that a decoder? Or do you mean something that takes

Re: [RFC v2 0/5] Common Display Framework

On 2012-12-19 16:57, Jani Nikula wrote: It just seems to me that, at least from a DRM/KMS perspective, adding another layer (=CDF) for HDMI or DP (or legacy outputs) would be overengineering it. They are pretty well standardized, and I don't see there would be a need to write multiple display

Re: [RFC v2 0/5] Common Display Framework

On 2012-12-19 17:26, Rob Clark wrote: On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula jani.nik...@linux.intel.com wrote: Hi Laurent - On Tue, 18 Dec 2012, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Jani, On Monday 17 December 2012 18:53:37 Jani Nikula wrote: I can see

Re: [RFC v2 0/5] Common Display Framework

On 2012-12-17 16:36, Laurent Pinchart wrote: Hi Tomi, I finally have time to work on a v3 :-) On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: On 2012-11-22 23:45, Laurent Pinchart wrote: From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Hi everybody, Here's

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

On 2012-12-07 16:12, Philipp Zabel wrote: Hi, Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen: So what does the pixelclk-inverted mean? Normally the SoC drives pixel data on rising edge, and the panel samples it at falling edge? And vice-versa for inverted? Or the other way

Re: [PATCHv15 2/7] video: add display_timing and videomode

On 2012-12-06 12:07, Grant Likely wrote: On Mon, 26 Nov 2012 16:39:58 +0100, Steffen Trumtrar s.trumt...@pengutronix.de wrote: On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote: On 2012-11-26 11:07, Steffen Trumtrar wrote: +/* + * Subsystem independent description

Re: [RFC v2 3/5] video: display: Add MIPI DBI bus support

Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/video/display/Kconfig|4 + drivers/video/display/Makefile |1 +

Re: [PATCH 0/2] omap_vout: remove cpu_is_* uses

On 2012-11-28 17:13, Laurent Pinchart wrote: Hi Tomi, On Monday 12 November 2012 15:33:38 Tomi Valkeinen wrote: Hi, This patch removes use of cpu_is_* funcs from omap_vout, and uses omapdss's version instead. The other patch removes an unneeded plat/dma.h include. These are based

Re: [PATCH 0/2] omap_vout: remove cpu_is_* uses

On 2012-11-29 19:05, Mauro Carvalho Chehab wrote: Em Thu, 29 Nov 2012 17:39:45 +0100 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: Please rather queue the cpu_is_omap removal to v3.8 so I can remove plat/cpu.h for omap2+. In that case the patches should go through the DSS

Re: [RFC v2 2/5] video: panel: Add DPI panel support

Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: +static void panel_dpi_release(struct display_entity *entity) +{ + struct panel_dpi *panel = to_panel_dpi(entity); + + kfree(panel); +} + +static int panel_dpi_remove(struct platform_device *pdev) +{ + struct panel_dpi *panel

Re: [RFC v2 1/5] video: Add generic display entity core

Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: +/** + * display_entity_get_modes - Get video modes supported by the display entity + * @entity The display entity + * @modes: Pointer to an array of modes + * + * Fill the modes argument with a pointer to an array of video modes. The array

Re: [PATCHv15 2/7] video: add display_timing and videomode

On 2012-11-26 11:07, Steffen Trumtrar wrote: +/* + * Subsystem independent description of a videomode. + * Can be generated from struct display_timing. + */ +struct videomode { + u32 pixelclock; /* pixelclock in Hz */ I don't know if this is of any importance, but the linux

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

Hi, On 2012-11-26 11:07, Steffen Trumtrar wrote: This adds support for reading display timings from DT into a struct display_timings. The of_display_timing implementation supports multiple subnodes. All children are read into an array, that can be queried. If no native mode is specified,

Re: [PATCHv15 3/7] video: add of helper for display timings/videomode

On 2012-11-26 18:10, Steffen Trumtrar wrote: Hi, On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote: +optional properties: + - hsync-active: hsync pulse is active low/high/ignored + - vsync-active: vsync pulse is active low/high/ignored + - de-active: data-enable pulse

Re: [RFC v2 0/5] Common Display Framework

Hi, On 2012-11-22 23:45, Laurent Pinchart wrote: From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Hi everybody, Here's the second RFC of what was previously known as the Generic Panel Framework. Nice work! Thanks for working on this. I was doing some testing with the

Re: [RFC v2 0/5] Common Display Framework

On 2012-11-23 21:56, Thierry Reding wrote: On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote: [...] Display entities are accessed by driver using notifiers. Any driver can register a display entity notifier with the CDF, which then calls the notifier when a matching display

  1   2   >