[PATCH v2] dt-bindings: display: bridge: tc358768: Change maintainer information

-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

Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information

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 >>>

Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information

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

[PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information

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

[PATCH] drm: xlnx: Use dma_request_chan for DMA channel request

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

Re: [PATCH v3 02/13] backlight: add backlight_is_blank()

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

Re: [PATCH v3 13/13] backlight: use backlight_is_blank() in all backlight drivers

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: > -

Re: [PATCH v2 03/16] backlight: add backlight_is_blank()

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

Re: [PATCH v2 16/16] backlight: use backlight_is_blank() in all backlight drivers

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

Re: [PATCH v2 16/16] backlight: use backlight_is_blank() in all backlight drivers

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

Re: [PATCH] drm/bridge: sii902x: Select SND_SOC_HDMI_CODEC if SND_SOC is configured

rivers 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

[PATCH v4 0/2] drm/bridge: Support for Toshiba tc358768 RGB to DSI bridge

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

[PATCH v4 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

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

[PATCH v4 2/2] drm/bridge: Add tc358768 driver

+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

Re: [PATCH v3 2/2] drm/bridge: Add tc358768 driver

8_is_reserved_reg(reg)) >> + return false; >> + >> +switch (reg) { >> +case TC358768_CHIPID: >> +case TC358768_FIFOSTATUS: >> +case TC358768_DSITXSTATUS ... (TC358768_DSITXSTATUS + 2): >> +case TC358

Re: [PATCH v3 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

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

Re: [PATCH v3 2/2] drm/bridge: Add tc358768 driver

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

[PATCH v3 0/2] drm/bridge: Support for Toshiba tc358768 RGB to DSI bridge

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

[PATCH v3 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

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

[PATCH v3 2/2] drm/bridge: Add tc358768 driver

-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

Re: [PATCH v2 2/2] drm/bridge: Add tc358768 driver

... 0x42f: >> +return true; >> +default: >> +return false; >> +} >> +} >> + >> +static bool tc358768_writeable_reg(struct device *dev, unsigned int reg) >> +{ >> + if (tc358768_is_reserved_reg(reg)) >> +return fals

[PATCH v2 0/2] drm/bridge: Support for Toshiba tc358768 RGB to DSI bridge

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

[PATCH v2 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

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

[PATCH v2 2/2] drm/bridge: Add tc358768 driver

-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

Re: [PATCH 2/2] drm/bridge: Add tc358768 driver

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; + +

Re: [PATCH 2/2] drm/bridge: Add tc358768 driver

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

Re: [PATCH 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

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 |

Re: [PATCH v4 3/5] dt-bindings: display: ti, j721e-dss: Add dt-schema yaml binding

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

[PATCH 0/2] drm/bridge: Support for Toshiba tc358768 RGB to DSI bridge

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

[PATCH 2/2] drm/bridge: Add tc358768 driver

-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

[PATCH 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

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

Re: [PATCH] ARM: dts: am335x-evmsk: Use drm simple-panel instead of tilcdc-panel

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/

Re: [PATCH for-5.3] drm/omap: ensure we have a valid 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 ("arm:

Re: [PATCH] drm/tilcdc: Check priv->crtc validity in cpufreq_transition()

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

[PATCH] drm/tilcdc: Check priv->crtc validity in cpufreq_transition()

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

[PATCH 1/2] drm/omap: dmm_tiler: Use dmaengine_prep_dma_memcpy() for i878 workaround

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/

[PATCH 2/2] drm/omap: dmm_tiler: Remove the dma_async_issue_pending() call

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

[PATCH 0/2] drm/omap: dmm_tiler: Small fixes for i878 workaround

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

[PATCH v3] backlight: gpio-backlight: Correct initial power state handling

-by: 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 have

Re: [PATCH] backlight: gpio-backlight: Set power state instead of brightness at probe

t 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. Then w

Re: [PATCHv6 0/4] omapdrm: DSI command mode panel support

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

Re: [PATCH v3 0/4] drm/panel: Support for OSD101T2045-53TS and OSD101T2587-53TS

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) >&

Re: [PATCH 2/2] drm/bridge: ti-tfp410: Set the bus_format

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

Re: [PATCH] drm/bridge: ti-tfp410: Fall back to HPD polling if HPD irq is not available

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

Re: [PATCH v6 5/6] dt-bindings: display: sii902x: Add HDMI audio bindings

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

Re: [PATCH v6 6/6] drm/bridge: sii902x: Implement HDMI audio support

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-

[PATCH 1/2] dt-bindings: display: tfp410: Add bus-width parameter property

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

[PATCH 2/2] drm/bridge: ti-tfp410: Set the bus_format

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

[PATCH 0/2] drm/bridge: ti-tfp410: Handle bus-format for 24/12 lines selection

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

[PATCH] drm/bridge: ti-tfp410: Fall back to HPD polling if HPD irq is not available

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

Re: [PATCH v3 41/50] drm/bridge: ti-tfp410: Report input bus config through bridge timings

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? &

Re: [PATCH v3 41/50] drm/bridge: ti-tfp410: Report input bus config through bridge timings

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

Re: [PATCH v3 41/50] drm/bridge: ti-tfp410: Report input bus config through bridge timings

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", _sample); >>> + of_node_put(ep);

[PATCH] drm/panel: simple: Fix panel_simple_dsi_probe

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

[PATCH v3 4/4] drm/panel: Add OSD101T2587-53TS driver

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

[PATCH v3 0/4] drm/panel: Support for OSD101T2045-53TS and OSD101T2587-53TS

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

[PATCH v3 1/4] dt-bindings: display: Add bindings for OSD101T2045-53TS

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

[PATCH v3 2/4] drm/panel: simple: Add support for OSD101T2045-53TS

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/

[PATCH v3 3/4] dt-bindings: display: Add bindings for OSD101T2587-53TS 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

Re: [PATCH v2 4/4] drm/panel: Add OSD101T2587-53TS driver

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

Re: [RESEND] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default

nt 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(+) >>>> >>>

Re: [PATCH RFC 1/3] drm/i2c: tda998x: implement different I2S flavours

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'

Re: [RESEND] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default

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

Re: [RESEND] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default

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, th

[RESEND] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default

. 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

[PATCH v2 4/4] drm/panel: Add OSD101T2587-53TS driver

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

[PATCH v2 3/4] dt-bindings: display: Add bindings for OSD101T2587-53TS 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

[PATCH v2 2/4] drm/panel: simple: Add support for OSD101T2045-53TS

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/

[PATCH v2 0/4] drm/panel: Support for OSD101T2045-53TS and OSD101T2587-53TS

by 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

[PATCH v2 1/4] dt-bindings: display: Add bindings for OSD101T2045-53TS

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

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

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

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

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

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

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

[PATCH 0/4] drm/panel: Support for OSD101T2045-53TS and OSD101T2587-53TS

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

[PATCH 1/4] dt-bindings: display: Add bindings for OSD101T2045-53TS

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

[PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

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

[PATCH 3/4] dt-bindings: display: Add bindings for OSD101T2587-53TS 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

[PATCH 2/4] drm/panel: simple: Add support for OSD101T2045-53TS

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/

[PATCH v2] backlight: gpio-backlight: Correct initial power state handling

-by: 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

Re: [PATCH RESEND] backlight: gpio-backlight: Correct initial power state handling

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

[PATCH v4 4/4] drm/omap: partial workaround for DRA7xx DMM errata i878

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/omapdrm

[PATCH v4 0/4] drm/omap: dmm_tiler: fixes and workaround for errata i878

-> 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 Ujfal

[PATCH v4 2/4] drm/omap: dmm_tiler: No need to check if irq is valid in omap_dmm_remove

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

[PATCH v4 3/4] drm/omap: dmm_tiler: Fix interrupt request/free sequence during probe/remove

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

[PATCH v4 1/4] drm/omap: fix memory barrier bug in DMM driver

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 --- drivers/gpu/d

[PATCH] drm/omap: DMM: Fix interrupt request/free sequence during probe/remove

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

[PATCH RESEND] backlight: gpio-backlight: Correct initial power state handling

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 <peter.ujfal...@ti.com> --- Hi, for some reason the original patch got lost: https://patchwork.kernel.org/patch/9445539/ But it is

Re: [PATCH 0/4] drm/omap: minor fixes

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 <peter.ujfal...@ti.com> &g

[PATCH] drm/i2c: tda998x: Reset the I2S_FORMAT (Page0, Reg 0xfc) to it's default

and tda998x_reset() it remains 0x0a. Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> --- 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

[PATCH v3 2/3] dt-bindings: arm: omap: dmm: Document new compatible for DRA7xx family

mi.valkei...@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> Reviewed-by: Rob Herring <r...@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> --- Documentation/devicetree/bindings/arm/omap/dmm.txt | 3 ++- 1 file changed, 2 insertions

[PATCH v3 0/3] drm/omap: Workaround for errata i878

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 .../devicet

[PATCH v3 1/3] drm/omap: dmm_tiler: No need to check if irq is valid in omap_dmm_remove

The driver probe would fail if the irq is not available. Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> --- 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/o

[PATCH v3 3/3] drm/omap: partial workaround for DRA7xx DMM errata i878

uffers, usually). Signed-off-by: Tomi Valkeinen <tomi.valkei...@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> --- drivers/gpu/drm/omapdrm/omap_dmm_priv.h | 8 ++ drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 161 ++- 2 files changed, 165 insertions(+), 4

Re: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

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; >> +

Re: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

On 2018-03-29 13:18, Tomi Valkeinen wrote: > On 22/03/18 15:42, Peter Ujfalusi wrote: >> From: Tomi Valkeinen <tomi.valkei...@ti.com> >> >> Errata i878 says that MPU should not be used to access RAM and DMM at >> the same time. As it's not possible to prev

Re: [PATCH v4 0/6] drm: zpos normalization cleanup and omapdrm to use it

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_ato

[PATCH] drm/omap: fix memory barrier bug in DMM driver

@ti.com> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com> --- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c index c40f90d2db82..27c67bc36203

Re: [PATCH v2 1/2] dt-bindings: arm: omap: dmm: Document new compatible for DRA7xx family

On 2018-03-22 15:42, Peter Ujfalusi wrote: > From: Tomi Valkeinen <tomi.valkei...@ti.com> > > 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

Re: [PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

On 2018-03-22 15:42, Peter Ujfalusi wrote: > From: Tomi Valkeinen <tomi.valkei...@ti.com> > > 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. &g

[PATCH v2 2/2] drm/omap: partial workaround for DRA7xx DMM errata i878

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

  1   2   3   4   >