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
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
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
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
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
++ 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 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
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 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 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 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 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
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
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
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
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
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
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 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
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
>>
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
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 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 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
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 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.
>
>
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
>
> 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 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
Hi,
On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote:
> This is the version 5th of the Driver.
>
> Following are the features supported.
> 1. Provides V4L2 user interface for the video pipelines of DSS
> 2. Basic streaming working on LCD and TV.
> 3. Support for various pixel formats like
On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote:
> Remove the code in omap_vout_probe() which calls display->driver->update() for
> all the displays. This isn't correct because:
>
> - An update in probe doesn't make sense, because we don't have any valid
> content
> to show at this time.
On Tue, 2011-09-27 at 12:09 +0530, Hiremath, Vaibhav wrote:
> Please look at the patch carefully, it does exactly same thing. I
> understand the use-case what Archit explained in the last email but in
> this patch context, the use-case change anything here in this patch.
With the current code, th
On Tue, 2011-09-27 at 12:24 +0530, Hiremath, Vaibhav wrote:
> If you look at the patch, the patch barely checks for the condition
> and
> makes sure that the interrupt is either of VSYNC or VSYNC2, else
> return. Rest everything is same.
This is what the current code does, in clearer form and slig
On Tue, 2011-09-27 at 12:32 +0530, Archit Taneja wrote:
> On Tuesday 27 September 2011 11:40 AM, Valkeinen, Tomi wrote:
> > On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote:
> >> Remove the code in omap_vout_probe() which calls display->driver->update()
> >> for
> >> all the displays. This i
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 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
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 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
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 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 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
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
ged, 13 insertions(+), 12 deletions(-)
Acked-by: Tomi Valkeinen
Tomi
signature.asc
Description: OpenPGP digital signature
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
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
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
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 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: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 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
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 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
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 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
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 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
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 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: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 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 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 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 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 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 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 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 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 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
-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
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
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,
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 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
>
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 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-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-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-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 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 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-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-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
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)
> +
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)
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-
Hi,
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If
Oookay, where to start... ;)
A few cosmetic/general comments first.
I find the file naming a bit strange. You have panel.c, which is the
core framework,
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> +/*
> -
> + * Bus operations
> + */
> +
> +void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long cmd)
> +{
> + dev->bus->ops->write_comma
On Fri, 2012-08-17 at 12:02 +0200, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the review.
>
> On Friday 17 August 2012 12:03:02 Tomi Valkeinen wrote:
> > On Fri, 2012-08-17 at 02:49 +0200, L
On Fri, 2012-08-17 at 13:10 +0200, Laurent Pinchart wrote:
> What kind of directory structure do you have in mind ? Panels are already
> isolated in drivers/video/panel/ so we could already ditch the panel- prefix
> in drivers.
The same directory also contains files for the framework and buses.
On Fri, 2012-08-17 at 14:33 +0200, Laurent Pinchart wrote:
> > But first, the data type should be byte, not unsigned long. How would
> > you write 8 bits or 16 bits with your API?
>
> u8 and u16 both fit in an unsigned long :-) Please see below.
Ah, I see, so the driver would just discard 24 bit
On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
> Hi Tomi,
> mipi-dbi-bus might not belong to include/video/panel/ though, as it can be
> used for non-panel devices (at least in theory). The future mipi-dsi-bus
> certainly will.
They are both display busses. So while they could be us
On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote:
> > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote:
> > > Hi Tomi,
> > >
> > > mipi-dbi-bus might not belong to
Hi,
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> Hi everybody,
>
> While working on DT bindings for the Renesas Mobile SoC display controller
> (a.k.a. LCDC) I quickly realized that display panel implementation based on
> board code callbacks would need to be replaced by a driver-
Hi,
On Thu, 2012-10-04 at 19:59 +0200, Steffen Trumtrar wrote:
> Signed-off-by: Steffen Trumtrar
> ---
> .../devicetree/bindings/video/display-timings.txt | 222
>
> drivers/of/Kconfig |5 +
> drivers/of/Makefile
On Mon, 2012-10-08 at 10:07 +0300, Tomi Valkeinen wrote:
> Hi,
> I don't see you setting disp->default_timing to OF_DEFAULT_TIMING in
> case there's no default_timing found.
>
> Or, at least I presume OF_DEFAULT_TIMING is meant to mark non-existing
> default timing
On Thu, 2012-10-04 at 19:59 +0200, Steffen Trumtrar wrote:
> Get videomode from devicetree in a format appropriate for the
> backend. drm_display_mode and fb_videomode are supported atm.
> Uses the display signal timings from of_display_timings
>
> Signed-off-by: Steffen Trumtrar
> ---
> drivers
On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
> In general, I might be misunderstanding something, but don't we have to
> distinguish between 2 types of information about display timings: (1) is
> defined by the display controller requirements, is known to the display
> driver
On Mon, 2012-10-08 at 14:04 +0200, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Monday 08 October 2012 12:01:18 Tomi Valkeinen wrote:
> > On Mon, 2012-10-08 at 10:25 +0200, Guennadi Liakhovetski wrote:
> > > In general, I might be misunderstanding something, but don't
On 2012-03-09 10:03, Hiremath, Vaibhav wrote:
> On Fri, Mar 09, 2012 at 05:17:41, Laurent Pinchart wrote:
>> Hi Archit,
>>
>> On Wednesday 07 March 2012 14:31:16 Archit Taneja wrote:
>>> The omap_vout driver tries to set the DSS overlay_info using
>>> set_overlay_info() when the physical address fo
On 2012-10-31 15:13, Laurent Pinchart wrote:
>> OMAP SoC
>>
>>
>> So here's first the SoC specific display nodes. OMAP has a DSS (display
>> subsystem) block, which contains the following elements:
>>
>> - DISPC (display controller) reads the pixels from memory and outputs
>> them using s
1 - 100 of 142 matches
Mail list logo
