On 08/10/18 15:55, Hans Verkuil wrote:
> On 10/08/2018 02:45 PM, Tomi Valkeinen wrote:
>> Hi Hans,
>>
>> On 04/10/18 12:08, Hans Verkuil wrote:
>>> From: Hans Verkuil
>>>
>>> The TX FIFO has to be cleared if the transmit failed due to e.g.
>&g
On 05/10/18 17:13, Hans Verkuil wrote:
> Tomi,
>
> Can you review this patch and the next? They should go to 4.20.
> This patch in particular is a nasty one, hard to reproduce.
>
> This patch should also be Cc-ed to stable for 4.15 and up.
Done. There's no dependency from the omapdrm patches t
ANSMIT_CNT_INT_MASK);
>
> - /* Set the retry count */
> - REG_FLD_MOD(core->base, HDMI_CEC_DBG_3, attempts - 1, 6, 4);
> -
I presume there's no harm in having a different retry count in the HW
than what was requested via the API?
Reviewed-by: Tomi Valkeinen
Tomi
Hi Hans,
On 04/10/18 12:08, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The TX FIFO has to be cleared if the transmit failed due to e.g.
> a NACK condition, otherwise the hardware will keep trying to
> transmit the message.
>
> An attempt was made to do this, but it was done after the call to
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
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 ?
>
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
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 namespace-conf
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: In
++ 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
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
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 e
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
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, bu
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
>>
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 disp
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
>>
>> This patch seri
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
> the 4.13-rc2 kernel with
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 v
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
> omapdrm/displa
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
(drivers/gpu/drm/omapdrm/dss/hdmi4.c).
Tomi
signature
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
> to use CEC. Some displays
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 off the HDMI core.
>
>
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) /*
> hdmi_sda.hdmi_sda */
>
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 in
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. T
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 bal
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:
>
> http
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
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 s
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
> ./ar
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 = <0x580
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 | 5 +-
> drivers/gpu/drm/omapdrm/dss/Kcon
-off-by: Hans Verkuil
> Suggested-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
> b/drivers/gpu/drm/om
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
>>
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
>>
>> Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of
>
latform/soc_camera/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
signature.asc
Description: OpenPGP digital signature
;> drivers/video/fbdev/via/via-gpio.c | 10 +++---
>
> Tomi can you ACK this?
Acked-by: Tomi Valkeinen
Tomi
signature.asc
Description: OpenPGP digital signature
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 mand
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)
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
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 ca
On 20/03/14 20:49, Laurent Pinchart wrote:
>> The CPU is the _controlling_ component - it's the component that has to
>> configure the peripherals so they all talk to each other in the right
>> way. Therefore, the view of it needs to be CPU centric.
>>
>> If we were providing a DT description for
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 form
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
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 so
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, where
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
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
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
> sen
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 #addres
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 usuall
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
On 08/03/14 17:54, Laurent Pinchart wrote:
>> Sylwester suggested as an alternative, if I understood correctly, to
>> drop the endpoint node and instead keep the port:
>>
>> device-a {
>> implicit_output_ep: port {
>> remote-endpoint = <&explicit_input_ep>;
>> };
>>
On 07/03/14 19:06, Grant Likely wrote:
> On Thu, 27 Feb 2014 10:36:36 +0200, Tomi Valkeinen
> 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 el
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
On 07/03/14 19:05, Grant Likely wrote:
> On Wed, 26 Feb 2014 15:48:49 +0100, Philipp Zabel
> 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.
Thanks f
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
inding for single port devices
> of: Document simplified graph binding for single port 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 se
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 t
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)
>>> +
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.
> @@ -2105,9 +2112,11 @@ struct device_node *of_graph_get_remote_port_parent(
> /* Get remote endpoint node. */
> np
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 en
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
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
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'
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
>>> +
>>> +
>>
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 wo
Hi,
On 11/02/14 23:41, Philipp Zabel wrote:
> From: Philipp Zabel
>
> 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
> drivers/media/v4l
r_display->type) {
> case OMAP_DISPLAY_TYPE_DSI:
> case 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
signature.asc
Description: OpenPGP digital signature
On 24/10/13 13:40, Laurent Pinchart wrote:
>> panel {
>> remote = <&remote-endpoint>;
>> common-video-property = ;
>> };
>>
>> panel {
>> port {
>> endpoint {
>> remote = <&remote-endpoint>;
>> common-video-property = ;
>>
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
> adapter
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
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.
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
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
ged, 13 insertions(+), 12 deletions(-)
Acked-by: Tomi Valkeinen
Tomi
signature.asc
Description: OpenPGP digital signature
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
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 qui
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 vpd
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
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
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 v
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_vo
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 "Unha
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-
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)
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)
> +
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 s
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
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 chil
On 2013-02-06 16:44, Alex Deucher wrote:
> On Wed, Feb 6, 2013 at 6:11 AM, Tomi Valkeinen 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 someth
On 2012-12-19 17:26, Rob Clark wrote:
> On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula
> wrote:
>>
>> Hi Laurent -
>>
>> On Tue, 18 Dec 2012, Laurent Pinchart
>> wrote:
>>> Hi Jani,
>>>
>>> On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
I can see the need for a framework for DSI panel
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 disp
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
>>>
>>>
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
On 2012-12-06 12:07, Grant Likely wrote:
> On Mon, 26 Nov 2012 16:39:58 +0100, Steffen Trumtrar
> wrote:
>> On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote:
>>> On 2012-11-26 11:07, Steffen Trumtrar wrote:
>>>
>>>> +/*
>>>>
Hi,
On 2012-11-22 23:45, Laurent Pinchart wrote:
> From: Laurent Pinchart
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/video/display/Kconfig|4 +
> drivers/video/display/Makefile |1 +
> drivers/video/display/mipi-dbi-bus.c | 228
> +++
On 2012-11-29 19:05, Mauro Carvalho Chehab wrote:
> Em Thu, 29 Nov 2012 17:39:45 +0100
> Laurent Pinchart 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 tree. Mauro, are you fine
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 un
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
>
1 - 100 of 142 matches
Mail list logo
