-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
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
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
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
There is no need to use the of_dma_request_slave_channel() directly as
dma_request_chan() is going to try to get the channel via OF as well.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu
roducing this helper will for some drivers results in
> added support for fb_blank. This will be a change in
> functionality, which will improve the backlight driver.
>
> Rolling out this helper to all relevant backlight drivers
> will eliminate almost all accesses to fb_blank.
Review
On 01/06/2020 9.52, Sam Ravnborg wrote:
> Replaces the open-coded checks of the state etc.,
> with the backlight_is_blank() helper.
> This increases readability of the code and align
> the functionality across the drivers.
Reviewed-by: Peter Ujfalusi
> v3:
> - Dropped as3
this helper to all relevant backlight drivers
> will eliminate almost all accesses to fb_blank.
Reviewed-by: Peter Ujfalusi
> v2:
> - Added fb_blank condition (Daniel)
>
> Signed-off-by: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Lee Jones
> Cc: Danie
On 28/05/2020 16.39, Peter Ujfalusi wrote:
> Hi Sam,
>
> On 17/05/2020 22.01, Sam Ravnborg wrote:
>> Replaces the open-coded checks of the state etc.,
>> with the backlight_is_blank() helper.
>> This increases readability of the code and align
>> the
gpio/pwm/led backlight drivers mostly:
Reviewed-by: Peter Ujfalusi
> v2:
> - Fixed so changelog is readable
>
> Signed-off-by: Sam Ravnborg
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Cc: Michael Hennerich
> Cc: Support Opensource
> Cc: Thie
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
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
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
+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
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
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
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
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
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
igned int reg)
>> +{
>> +if (tc358768_is_reserved_reg(reg))
>> +return false;
>> +
>> +switch (reg) {
>> +case TC358768_CHIPID:
>> +case TC358768_FIFOSTATUS:
>> +case TC358768_DSITXSTATUS ... (TC358768_DSITXS
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
-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
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;
+
+
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
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 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
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
-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
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
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 (&
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
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
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
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
: 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
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/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 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)
>&
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
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
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
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-
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
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 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
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
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?
&
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 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
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
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
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/
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
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
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 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&
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
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
.
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
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
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
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/
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
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
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,
Add 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
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
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
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
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/
: Peter Ujfalusi
---
Hi,
Changes since v1:
- Implement similiar initial power state handling as pwm backlight have
Regards,
Peter
drivers/video/backlight/gpio_backlight.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight
Daniel,
On 2018-06-13 18:11, Daniel Thompson wrote:
> On 08/05/18 08:04, Peter Ujfalusi wrote:
>> The default-on property - or the def_value via legacy pdata) should be
>> handled as:
>> if it is 1, the backlight must be enabled (kept enabled)
>> if it is 0, the backl
einen
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 7 ++
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 149 ++-
2 files changed, 154 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
b/drivers/gpu/drm/om
-> dma_addr_t when applicable
- additional wmb()/rmb() added to make sure we have correct behavior
Errata i878 says that MPU should not be used to access RAM and DMM at
the same time. As it's not possible to prevent MPU accessing RAM, we
need to access DMM via a proxy.
Regards,
Peter
---
Peter
The driver probe would fail if the irq is not available.
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/drm/omapdrm/omap_dmm_tiler.c
index
The interrupts should be enabled after the driver initialization to avoid
early interrupts while the driver is not yet ready to handle them.
On removal the interrupts must be disabled before other resources are
released, freed up.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm
lly in RAM, and thus observable by DMM.
The read-back should not be needed. Further study is required to understand
if DMM is somehow special case and read-back is ok, or if DRA7's memory
barriers do not work correctly.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Peter Ujfalusi
---
dri
The interrupts should be enabled after the driver initialization to avoid
early interrupts while the driver is not yet ready to handle them.
On removal the interrupts must be disabled before other resources are
released, freed up.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm
on by default or to
FB_BLANK_POWERDOWN if the backlight should be off by default.
The initial brightness should be set to 1.
Signed-off-by: Peter Ujfalusi
---
Hi,
for some reason the original patch got lost:
https://patchwork.kernel.org/patch/9445539/
But it is still valid, so I'm resendi
On 2018-05-02 12:11, Tomi Valkeinen wrote:
> Hi,
>
> This series has some minor fixes found by a static analysis tool, and one for
> missing linefeeds. As far as I know, we have never hit any of those errors.
To all:
Reviewed-by: Peter Ujfalusi
>
> Tomi
>
> Tom
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 --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 9e67a7b4e3a4..f1714b270d0e 100644
--- a/drivers/gpu/drm/i2c
From: Tomi Valkeinen
Define unique compatible string for the DMM in DRA7xx family.
The new compatible can be used to apply DRA7xx specific workarounds for
ERRATAs, like i878 (MPU Lockup with concurrent DMM and EMIF accesses)
Signed-off-by: Tomi Valkeinen
Signed-off-by: Peter Ujfalusi
MM via a proxy.
Regards,
Peter
---
Peter Ujfalusi (1):
drm/omap: dmm_tiler: No need to check if irq is valid in
omap_dmm_remove
Tomi Valkeinen (2):
dt-bindings: arm: omap: dmm: Document new compatible for DRA7xx family
drm/omap: partial workaround for DRA7xx DMM errata i878
.../de
The driver probe would fail if the irq is not available.
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/drm/omapdrm/omap_dmm_tiler.c
index
ff-by: Tomi Valkeinen
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 8 ++
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 161 ++-
2 files changed, 165 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_priv.h
b/drivers/gp
Hi Laurent,
On 2018-04-04 00:11, Laurent Pinchart wrote:
>> +static int dmm_dma_copy(struct dmm *dmm, dma_addr_t src, dma_addr_t dst)
>> +{
>> +struct dma_device *dma_dev = dmm->wa_dma_chan->device;
>> +struct dma_async_tx_descriptor *tx;
>> +enum dma_status status;
>> +dma_cookie_
On 2018-03-29 13:18, Tomi Valkeinen wrote:
> On 22/03/18 15:42, Peter Ujfalusi wrote:
>> From: Tomi Valkeinen
>>
>> Errata i878 says that MPU should not be used to access RAM and DMM at
>> the same time. As it's not possible to prevent MPU accessing RAM, we
&
On 2018-03-28 12:30, Tomi Valkeinen wrote:
> Hi,
>
> On 06/02/18 14:05, Peter Ujfalusi wrote:
>> Hi,
>>
>> Changes since v3:
>> - Moved the new normalize_zpos bool to be around another bools
>> - Extended the commit message for sti that the drm_atomic_
lly in RAM, and thus observable by DMM.
The read-back should not be needed. Further study is required to understand
if DMM is somehow special case and read-back is ok, or if DRA7's memory
barriers do not work correctly.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Peter Ujfalusi
---
dri
On 2018-03-22 15:42, Peter Ujfalusi wrote:
> From: Tomi Valkeinen
>
> Define unique compatible string for the DMM in DRA7xx family.
>
> The new compatible can be used to apply DRA7xx specific workarounds for
> ERRATAs, like i878 (MPU Lockup with concurrent DMM and EMIF acc
On 2018-03-22 15:42, Peter Ujfalusi wrote:
> From: Tomi Valkeinen
>
> Errata i878 says that MPU should not be used to access RAM and DMM at
> the same time. As it's not possible to prevent MPU accessing RAM, we
> need to access DMM via a proxy.
>
> This patch change
From: Tomi Valkeinen
Errata i878 says that MPU should not be used to access RAM and DMM at
the same time. As it's not possible to prevent MPU accessing RAM, we
need to access DMM via a proxy.
This patch changes DMM driver to access DMM registers via sDMA. Instead
of doing a normal readl/writel c
1 - 100 of 399 matches
Mail list logo
