My employment with TI is coming to an end and I will not have access to
the board where this bridge is connected to.
It is better to remove a soon bouncing email address.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 3 ---
1 file changed, 3
On 15/12/2020 16.26, Rob Herring wrote:
> On Tue, 15 Dec 2020 14:42:27 +0200, Peter Ujfalusi wrote:
>> My employment with TI is coming to an end and I will not have access to
>> the board where this bridge is connected to.
>>
>> It is better to remove a soon bouncing
Hi Sam,
On 17/12/2020 19.25, Sam Ravnborg wrote:
>>> dtschema/dtc warnings/errors:
>>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
>>> 'maintainers' is a required property
>>> /builds/robherring/linux-dt-review/Documentation/devicetre
-off-by: Peter Ujfalusi
---
.../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
b/Documentation/devicetree/bindings/display/bridge/toshiba
This reverts commit 1c278e5e3718d15475ec08ee2135f37a6b13361c.
If DRM_OMAP does not select OMAP2_DSS it is possible to build a kernel with
DRM_OMAP only and not selecting OMAP2_DSS. Since omapdrm depends on
OMAP2_DSS this will result on broken kernel build.
Signed-off-by: Peter Ujfalusi
ed as the
DT data need to be fixed first.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 12 +---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 12 +---
3 files changed, 15 insertions(+), 21 deletions(-)
On 28/05/2019 13.32, Tomi Valkeinen wrote:
> On 28/05/2019 13:18, Tony Lindgren wrote:
>> Strange that this is not affecting other x15? I think timer12 would
>> be blocked on HS devices though?
>
> I don't know... I can't believe my x15 would be unique =). Can it be
> something in the kernel con
Hi Andrzej,
On 12/04/2019 10.40, Andrzej Hajda wrote:
> On 12.04.2019 09:33, Andrzej Hajda wrote:
>> On 01.04.2019 14:41, Peter Ujfalusi wrote:
>>> The TFP410 supports 24 bit, single-edge and 12 bit, dual-edge modes.
>>> Depending on how many wires are used (24/12) the
Hi Thierry,
On 23/04/2019 14.55, Thierry Reding wrote:
> On Tue, Feb 26, 2019 at 09:55:19AM +0200, Peter Ujfalusi wrote:
>> Hi,
>>
>> Changes since v2:
>> - Added Reviewed-by from Rob to the binding patches
>> - Added help text to Kconfig (osd101t2587-53ts)
>&
m
>
> On Fri, Feb 15, 2019 at 04:03:15PM +0200, Peter Ujfalusi via dri-devel wrote:
>> The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
>> with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
>> message to be sent from t
Hi Sam,
On 15/02/2019 20.07, Sam Ravnborg wrote:
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
> Please do not use drmP.h in new drivers - we try to get rid of this file.
...
>> +static int osd101t2587_panel_get_modes(struct drm_panel *panel)
>> +{
>> +struct osd
Hi Sam,
On 20/02/2019 13.52, Sam Ravnborg wrote:
> Hi Peter.
>
> On Wed, Feb 20, 2019 at 12:39:11PM +0200, Peter Ujfalusi wrote:
>> Hi Sam,
>>
>> On 15/02/2019 20.07, Sam Ravnborg wrote:
>>>> +#include
>>>> +#include
>>>> +#includ
panel-simple.
Regards,
Peter
---
Peter Ujfalusi (4):
dt-bindings: display: Add bindings for OSD101T2045-53TS
drm/panel: simple: Add support for OSD101T2045-53TS
dt-bindings: display: Add bindings for OSD101T2587-53TS panel
drm/panel: Add OSD101T2587-53TS driver
.../display/panel/osd
This adds the device-tree bindings for the OSD101T2045-53TS 10.1"
1920x1200 panel from One Stop Displays.
Signed-off-by: Peter Ujfalusi
---
.../bindings/display/panel/osd,osd101t2045-53ts.txt | 11 +++
1 file changed, 11 insertions(+)
create mode 100644
Documentation/devic
Add support for the OSD101T2045-53TS 10.1" 1920x1200 panel from One Stop
Displays to the panel-simple driver
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/panel/panel-simple.c | 34
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/panel/
This adds the device-tree bindings for the OSD101T2587-53TS 10.1"
1920x1200 panel from One Stop Displays.
Note: the panel is similar to OSD101T2045-53TS, but it needs additional
MIPI_DSI_TURN_ON_PERIPHERAL message from the host.
Signed-off-by: Peter Ujfalusi
---
.../display/pane
The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
message to be sent from the host to be operational and thus can not be
handled by panel-simple.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu
.
It was observed when - accidentally - booted the kernel from eMMC on BBB
which is 3.8.13-bone79 and it sets this register to 0x0a. After reboot and
tda998x_reset() it remains 0x0a.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/i2c/tda998x_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff
On 22/02/2019 15.47, Peter Ujfalusi wrote:
> Hi,
>
> the original version was sent 14.04.2018:
17.04.2018
> https://patchwork.kernel.org/patch/10344403/
>
> Changes since then:
> - rebased on currentl drm/next
>
> The reset value of the register is 0, the sof
Hi Russell,
On 22/02/2019 16.35, Russell King - ARM Linux admin wrote:
> On Fri, Feb 22, 2019 at 03:47:14PM +0200, Peter Ujfalusi wrote:
>> Hi,
>>
>> the original version was sent 14.04.2018:
>> https://patchwork.kernel.org/patch/10344403/
>>
>> Changes s
hi Russell,
On 22/02/2019 23.27, Russell King wrote:
> Add support for the left and right justified I2S formats as well as the
> more tranditional "Philips" I2S format.
First of all, thank you for the patch, it works.
Tested-by: Peter Ujfalusi
There is however one thing I&
unt of bclk on the bus for the given
format - uses params_width() for divider calculation.
>>>> Signed-off-by: Peter Ujfalusi
>>>> ---
>>>> drivers/gpu/drm/i2c/tda998x_drv.c | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>
Hi Sam,
On 23/02/2019 21.38, Sam Ravnborg wrote:
> Hi Peter.
>
> Driver looks to be in good shape now.
> With the few comments below addressed you can add my:
> Reviewed-by: Sam Ravnborg
>
> Sam
>
> On Fri, Feb 22, 2019 at 03:16:18PM +0200, Peter Ujfalusi wro
This adds the device-tree bindings for the OSD101T2587-53TS 10.1"
1920x1200 panel from One Stop Displays.
Note: the panel is similar to OSD101T2045-53TS, but it needs additional
MIPI_DSI_TURN_ON_PERIPHERAL message from the host.
Signed-off-by: Peter Ujfalusi
Reviewed-by: Rob He
This adds the device-tree bindings for the OSD101T2045-53TS 10.1"
1920x1200 panel from One Stop Displays.
Signed-off-by: Peter Ujfalusi
Reviewed-by: Rob Herring
---
.../bindings/display/panel/osd,osd101t2045-53ts.txt | 11 +++
1 file changed, 11 insertions(+)
create mode 1
Add support for the OSD101T2045-53TS 10.1" 1920x1200 panel from One Stop
Displays to the panel-simple driver
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/panel/panel-simple.c | 34
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/panel/
The panel is similar to OSD101T2045-53TS (which is handled by panel-simple)
with one big difference: osd101t2587-53ts needs MIPI_DSI_TURN_ON_PERIPHERAL
message to be sent from the host to be operational and thus can not be
handled by panel-simple.
Signed-off-by: Peter Ujfalusi
Reviewed-by: Sam
support for OSD101T2045-53TS and OSD101T2587-53TS from One Stop Displays.
The two panel is similar with one big difference: OSD101T2587-53TS requires the
MIPI_DSI_TURN_ON_PERIPHERAL message, thus can not be handled by panel-simple.
Regards,
Peter
---
Peter Ujfalusi (4):
dt-bindings: display
In case mipi_dsi_attach() fails remove the registered panel to avoid added
panel without corresponding device.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/panel/panel-simple.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
hat it could be quite
>> controversial, as it implies that the backlight can no longer be
>> enabled without a bound panel (which IMO makes good sense but could be
>> a matter to debate).
>
> My apologies. This patch brought on such severe deja-vu I got rather
> confused. T
On 28/02/2019 12.31, Tomi Valkeinen wrote:
> On 28/02/2019 12:27, Tomi Valkeinen wrote:
>> Hi Laurent,
>>
>> On 11/02/2019 11:46, Laurent Pinchart wrote:
>>
>>> + /* Get the sampling edge from the endpoint. */
>>> + of_property_read_u32(ep, "pclk-sample", &pclk_sample);
>>> + of_node_put(ep
On 15/03/2019 14.07, Tomi Valkeinen wrote:
>> If the pclk-sample is not defined in DT, it will default to 0 which
>> selects SAMPLE_NEGEDGE (== DRIVE_POSEDGE), right?
>>
>> But all the boards where I can find schematics with tfp410 have their
>> EDGE/HTPLG pin pulled up and according to the documen
On 15/03/2019 15.30, Tomi Valkeinen wrote:
> On 15/03/2019 14:28, Peter Ujfalusi wrote:
>> On 15/03/2019 14.07, Tomi Valkeinen wrote:
>>>> If the pclk-sample is not defined in DT, it will default to 0 which
>>>> selects SAMPLE_NEGEDGE (== DRIVE_POSEDGE), right?
&
In case either the HPD gpio is not specified or when the HPD gpio can not
be used as interrupt we should tell the core that the HPD needs to be
polled for detecting hotplug.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/bridge/ti-tfp410.c | 14 +++---
1 file changed, 11 insertions
tfp410 uave this setup.
Regards,
Peter
---
Peter Ujfalusi (2):
dt-bindings: display: tfp410: Add bus-width parameter property
drm/bridge: ti-tfp410: Set the bus_format
.../bindings/display/bridge/ti,tfp410.txt | 10 +-
drivers/gpu/drm/bridge/ti-tfp410.c | 17
The TFP410 supports 24 bit, single-edge and 12 bit, dual-edge modes.
Depending on how many wires are used (24/12) the driver can set the correct
bus_format.
If the information is not available in DT then assume 24 bit, single-edge
setup.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/bridge
tfp410 can be connect to host processor in 24bit, single-edge (24 lines) or
12bit, dual-edge (12 lines).
Add bus-width to the documentation so it can be used to select between the
two connection scheme.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/display/bridge/ti,tfp410.txt
Hi Jyri,
On 02/04/2019 10.29, Jyri Sarha wrote:
> Implement HDMI audio support by using ASoC HDMI codec. The commit
> implements the necessary callbacks and configuration for the HDMI
> codec and registers a virtual platform device for the codec to attach.
it looks good:
Reviewed-
On 02/04/2019 10.29, Jyri Sarha wrote:
> The sii902x chip family supports also HDMI audio. Add binding for
> describing the necessary i2s and mclk wiring for it.
Reviewed-by: Peter Ujfalusi
> Signed-off-by: Jyri Sarha
> ---
> .../bindings/display/bridge/sii902x
On 02/04/2019 14.21, Laurent Pinchart wrote:
> Hi Peter,
>
> Thank you for the patch.
>
> On Mon, Apr 01, 2019 at 03:33:42PM +0300, Peter Ujfalusi wrote:
>> In case either the HPD gpio is not specified or when the HPD gpio can not
>> be used as interrupt we should
: Peter Ujfalusi
---
Hi,
sorry for the delay, but got distracted a bit with the resend of this...
Let's try again ;)
Changes since v2 (https://lore.kernel.org/patchwork/patch/1002359/):
- Rebased on drm-next
Changes since v1:
- Implement similiar initial power state handling as pwm backlight
Hi,
two small correction on the use of DMAengine API, no functional changes
- Use dmaengine_prep_dma_memcpy() to prepare the memcpy
- do not call dma_async_issue_pending() as it is redundant
Regards,
Peter
---
Peter Ujfalusi (2):
drm/omap: dmm_tiler: Use dmaengine_prep_dma_memcpy() for i878
Instead of dma_dev->device_prep_dma_memcpy() use the existing macro to
prepare the memcpy.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/
dma_sync_wait() is calling it so no need to call it in the driver.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index
The notifier can be called before we have crtc. With the check we can avoid
NULL pointer dereference within tilcdc_crtc_update_clk().
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc
On 02/08/2019 12.35, Jyri Sarha wrote:
> On 02/08/2019 11:39, Peter Ujfalusi wrote:
>> The notifier can be called before we have crtc. With the check we can avoid
>> NULL pointer dereference within tilcdc_crtc_update_clk().
>>
>> Signed-off-by: Peter Ujfalusi
>
&g
TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
Signed-off-by: Peter Ujfalusi
---
.../display/bridge/toshiba,tc358768.yaml | 158 ++
1 file changed, 158 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
diff
-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Peter Ujfalusi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
Hi,
TC358768 is a parallel RGB to MIPI DSI bridge.
The initial driver supports MIPI_DSI_MODE_VIDEO, MIPI_DSI_FMT_RGB888 and
only write is implemented for mipi_dsi_host_ops.transfer due to lack of hardware
where other modes can be tested.
Regards,
Peter
---
Peter Ujfalusi (2):
dt-bindings
Hi Jyri,
On 19/12/2019 10.23, Jyri Sarha wrote:
> Add dt-schema yaml bindig for J721E DSS, J721E version TI Keystone
> Display SubSystem.
>
> Version history:
>
> v2: no change
>
> v3: - reg-names: "wp" -> "wb"
> - Add ports node
> - Add includes to dts example
> - reindent dts exam
ers using it.
Reviewed-by: Peter Ujfalusi
>
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/bridge/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 26ff07ad287b..0a60a56ce6dc 1
On 27/12/2019 0.24, Rob Herring wrote:
> On Tue, Dec 17, 2019 at 12:15:05PM +0200, Peter Ujfalusi wrote:
>> TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> .../display/bridge/toshiba,tc358768.yaml |
Hi Andrzej,
On 16/01/2020 16.35, Andrzej Hajda wrote:
> On 17.12.2019 11:15, Peter Ujfalusi wrote:
>> Add basic support for the Toshiba TC358768 RGB to DSI bridge.
>> Not all the features of the TC358768 is implemented by the initial driver:
>> MIPI_DSI_MODE_VIDEO and MIPI_D
Hi Andrzej,
On 22/01/2020 10.46, Andrzej Hajda wrote:
+struct tc358768_priv {
+ struct device *dev;
+ struct regmap *regmap;
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data supplies[ARRAY_SIZE(tc358768_supplies)];
+ struct clk *refclk;
+
+
-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Peter Ujfalusi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
I_MODE_VIDEO, MIPI_DSI_FMT_RGB888 and
only write is implemented for mipi_dsi_host_ops.transfer due to lack of hardware
where other modes can be tested.
Regards,
Peter
---
Peter Ujfalusi (2):
dt-bindings: display: bridge: Add documentation for Toshiba tc358768
drm/bridge: Add tc358768 driver
.../di
TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
Signed-off-by: Peter Ujfalusi
---
.../display/bridge/toshiba,tc358768.yaml | 158 ++
1 file changed, 158 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
diff
igned int reg)
>> +{
>> +if (tc358768_is_reserved_reg(reg))
>> +return false;
>> +
>> +switch (reg) {
>> +case TC358768_CHIPID:
>> +case TC358768_FIFOSTATUS:
>> +case TC358768_DSITXSTATUS ... (TC358768_DSITXS
TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
Signed-off-by: Peter Ujfalusi
---
.../display/bridge/toshiba,tc358768.yaml | 158 ++
1 file changed, 158 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
diff
-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Peter Ujfalusi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
ver supports MIPI_DSI_MODE_VIDEO, MIPI_DSI_FMT_RGB888 and
only write is implemented for mipi_dsi_host_ops.transfer due to lack of hardware
where other modes can be tested.
Regards,
Peter
---
Peter Ujfalusi (2):
dt-bindings: display: bridge: Add documentation for Toshiba tc358768
drm/bridge: Add tc3
On 27/01/2020 12.56, Peter Ujfalusi wrote:
> Add basic support for the Toshiba TC358768 RGB to DSI bridge.
> Not all the features of the TC358768 is implemented by the initial driver:
> MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested.
>
> Only write is
Hi Rob,
On 27/01/2020 20.49, Rob Herring wrote:
> On Mon, Jan 27, 2020 at 12:56:33PM +0200, Peter Ujfalusi wrote:
>> TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> .../display/bridge/toshiba,tc358768.yaml
writeable_reg(struct device *dev, unsigned int reg)
>> +{
>> +if (tc358768_is_reserved_reg(reg))
>> + return false;
>> +
>> +switch (reg) {
>> +case TC358768_CHIPID:
>> +case TC358768_FIFOSTATUS:
>> +case TC358768_DSITXSTATUS
+1,1044 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Peter Ujfalusi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge.
Signed-off-by: Peter Ujfalusi
---
.../display/bridge/toshiba,tc358768.yaml | 159 ++
1 file changed, 159 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
diff
vers.
Cover letter from v1:
TC358768 is a parallel RGB to MIPI DSI bridge.
The initial driver supports MIPI_DSI_MODE_VIDEO, MIPI_DSI_FMT_RGB888 and
only write is implemented for mipi_dsi_host_ops.transfer due to lack of hardware
where other modes can be tested.
Regards,
Peter
---
Peter Ujfalu
On 04/12/2019 12.55, Jyri Sarha wrote:
> Move to use the new drm panel support in tilcdc together with added
> "newhaven,nhd-4.3-480272ef-atxl"-panel support in drm panel-simple.
Tested-by: Peter Ujfalusi
> Signed-off-by: Jyri Sarha
> ---
> arch/arm/boot/
DMA mask. As we
> use swiotlb for arm with LPAE now, omapdrm needs to catch up and
> actually set a DMA mask.
>
> Change the dma_set_coherent_mask() call to
> dma_coerce_mask_and_coherent() so that the dev->dma_mask is also set.
Reviewed-by: Peter Ujfalusi
> Fixes: ad3c7b18c5b3 (&
-off-by: Peter Ujfalusi
---
drivers/gpu/drm/drm_modes.c | 15 +++
include/drm/drm_connector.h | 4
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ac6a35212501..a77f81f6b1d4 100644
--- a/drivers/gpu/drm
the new interface to check that all needed drivers are loaded.
> In this way we can be sure that all needed drivers are loaded so it is
> safe to continue the probing of omapdrm.
> This method will allow the omapdrm to be probed 'headless', without
> outpu
Use interrupt handler for hpd GPIO to react to HPD changes.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 81 ++
1 file changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
b/drivers/gpu/drm
If the hpd_gpio is valid, use interrupt handler to react to HPD changes.
In case the hpd_gpio is not valid, try to enable hpd detection on the
encoder if it supports it.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 104 ++
1 file
The HPD signal can be used for detecting HDMI cable plug and unplug event
without the need for polling the status of the line.
This will speed up detecting such event because we do not need to wait for
the next poll event to notice the state change.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu
Hi,
this series will add support for HPD in omapdrm. Instead of polling for HPD
changes we can use interrupts to be notified of HPD change, thus we can react to
events faster.
The series is based on top of 4.12-rc1
Regards,
Peter
---
Peter Ujfalusi (3):
drm/omap: Support for HDMI hot plug
case the pm_runtime is disabled we will enable the poll in
nouveau_drm_load() once.
Fixes: cae9ff036eea ("drm/nouveau: Don't enabling polling twice on runtime
resume")
Signed-off-by: Peter Ujfalusi
Cc: Lyude Paul
Cc: Dave Airlie
Cc: Gleb Nemshilov
---
Hi,
this patch was create
On 2017-05-23 12:45, Laurent Pinchart wrote:
> Hi Peter,
>
> Thank you for the patch.
>
> On Monday 15 May 2017 12:03:11 Peter Ujfalusi wrote:
>> If the hpd_gpio is valid, use interrupt handler to react to HPD changes.
>> In case the hpd_gpio is not valid, try to
events faster.
The series is based on top of 4.12-rc3
Regards,
Peter
---
Peter Ujfalusi (3):
drm/omap: Support for HDMI hot plug detection
drm/omap: displays: connector-hdmi: Support for hot plug detection
drm/omap: displays: encoder-tpd12s015: Support for hot plug detection
drivers/gpu
The HPD signal can be used for detecting HDMI cable plug and unplug event
without the need for polling the status of the line.
This will speed up detecting such event because we do not need to wait for
the next poll event to notice the state change.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu
If the hpd_gpio is valid, use interrupt handler to react to HPD changes.
In case the hpd_gpio is not valid, try to enable hpd detection on the
encoder if it supports it.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 104 ++
1 file
Use interrupt handler for hpd GPIO to react to HPD changes.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 81 ++
1 file changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
b/drivers/gpu/drm
: devicetree at vger.kernel.org
Regards,
Peter
---
Peter Ujfalusi (26):
dt-bindings: display: display-timing: Add property to configure sync
drive edge
video: display_timing: Add flags to select the edge when the sync is
driven
video: of: display_timing: Add support for syncclk-active
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/displays
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 3 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 4 +--
drivers/gpu/drm/omapdrm/displays
Configure the DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE flags according to the
binding document.
If the syncclk-active is present in DT, configure the flags accordingly, if
it is omitted it means that the SYNC edge is following the pixdata
configuration.
Signed-off-by: Peter Ujfalusi
CC: Rob Herring
pixel data.
Signed-off-by: Peter Ujfalusi
CC: Rob Herring
CC: Mark Rutland
CC: devicetree at vger.kernel.org
---
Documentation/devicetree/bindings/display/panel/display-timing.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/display
The sync can be - and for some panels it must be - driven on different edge
then the data.
Signed-off-by: Peter Ujfalusi
CC: Rob Herring
CC: Mark Rutland
CC: devicetree at vger.kernel.org
---
include/video/display_timing.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/video
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/displays
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/displays
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c| 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm/displays
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c| 2 +-
drivers/gpu/drm/omapdrm
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c| 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
drivers/gpu/drm/omapdrm
Remove the interlace member and add display_flags to omap_video_timings to
configure the interlace mode.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 2 --
drivers/gpu/drm/omapdrm/dss
Instead of passing the omap_video_timings structure's members individually,
use the pointer to the struct.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 38 ++---
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/dr
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 3 +--
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c| 3 +--
.../gpu/drm/omapdrm
In preparation to move the stack to use the generic videmode
struct for display timing information.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 5 ++---
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c | 5 +++--
.../drm/omapdrm/displays
omap_video_timings struct have the same members as struct videomode, but
their types are different. As first step change the types of the
omap_video_timings struct members to match their counterpart in
struct videomode to catch any type cast related issues.
Signed-off-by: Peter Ujfalusi
omap_video_timings, these can be removed
as well.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 10 +--
drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 10 +--
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 10 +--
drivers/gpu/drm/omapdrm/displays/encoder-opa362
Use 'vm' to refer to a struct videomode instead of 'p', 't', 'timings' or
something else.
The code will be easier to follow if we use consistent names.
Signed-off-by: Peter Ujfalusi
---
.../gpu/drm/omapdrm/displays/connector-analog-tv.c | 26 ++---
dr
1 - 100 of 399 matches
Mail list logo
