Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device

On 10.05.2018 00:21, Peter Rosin wrote: > On 2018-05-09 17:53, Peter Rosin wrote: >> On 2018-05-09 17:08, Andrzej Hajda wrote: >>> On 04.05.2018 15:51, Peter Rosin wrote: >>>> Bridge drivers can now (temporarily, in a transition phase) select if >>>>

Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device

On 10.05.2018 00:21, Peter Rosin wrote: > On 2018-05-09 17:53, Peter Rosin wrote: >> On 2018-05-09 17:08, Andrzej Hajda wrote: >>> On 04.05.2018 15:51, Peter Rosin wrote: >>>> Bridge drivers can now (temporarily, in a transition phase) select if >>>>

Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device

On 04.05.2018 15:51, Peter Rosin wrote: > Bridge drivers can now (temporarily, in a transition phase) select if > they want to provide a full owner device or keep just providing an > of_node. > > By providing a full owner device, the bridge drivers no longer need > to provide an of_node since that

Re: [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device

On 04.05.2018 15:51, Peter Rosin wrote: > Bridge drivers can now (temporarily, in a transition phase) select if > they want to provide a full owner device or keep just providing an > of_node. > > By providing a full owner device, the bridge drivers no longer need > to provide an of_node since that

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

On 07.05.2018 15:43, Peter Rosin wrote: > On 2018-05-07 14:59, Andrzej Hajda wrote: >> On 04.05.2018 15:52, Peter Rosin wrote: >>> If the bridge supplier is unbound, this will bring the bridge consumer >>> down along with the bridge. Thus, there will no longer linger any

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

On 07.05.2018 15:43, Peter Rosin wrote: > On 2018-05-07 14:59, Andrzej Hajda wrote: >> On 04.05.2018 15:52, Peter Rosin wrote: >>> If the bridge supplier is unbound, this will bring the bridge consumer >>> down along with the bridge. Thus, there will no longer linger any

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

On 07.05.2018 15:53, Daniel Vetter wrote: > On Mon, May 07, 2018 at 02:59:45PM +0200, Andrzej Hajda wrote: >> On 04.05.2018 15:52, Peter Rosin wrote: >>> If the bridge supplier is unbound, this will bring the bridge consumer >>> down along with the bridge. Thus, ther

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

On 07.05.2018 15:53, Daniel Vetter wrote: > On Mon, May 07, 2018 at 02:59:45PM +0200, Andrzej Hajda wrote: >> On 04.05.2018 15:52, Peter Rosin wrote: >>> If the bridge supplier is unbound, this will bring the bridge consumer >>> down along with the bridge. Thus, ther

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

On 04.05.2018 15:52, Peter Rosin wrote: > If the bridge supplier is unbound, this will bring the bridge consumer > down along with the bridge. Thus, there will no longer linger any > dangling pointers from the bridge consumer (the drm_device) to some > non-existent bridge supplier. I understand

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

On 04.05.2018 15:52, Peter Rosin wrote: > If the bridge supplier is unbound, this will bring the bridge consumer > down along with the bridge. Thus, there will no longer linger any > dangling pointers from the bridge consumer (the drm_device) to some > non-existent bridge supplier. I understand

Re: [PATCH v2 03/13] drm/kms/mode/exynos-dsi: using helper func drm_display_mode_to_videomode for calculating timing parameters

Hi Satendra Singh Thakur, On 07.05.2018 05:32, Satendra Singh Thakur wrote: > To avoid duplicate logic for the same > > Signed-off-by: Satendra Singh Thakur > Acked-by: Madhur Verma > Cc: Hemanshu Srivastava Whole

Re: [PATCH v2 03/13] drm/kms/mode/exynos-dsi: using helper func drm_display_mode_to_videomode for calculating timing parameters

Hi Satendra Singh Thakur, On 07.05.2018 05:32, Satendra Singh Thakur wrote: > To avoid duplicate logic for the same > > Signed-off-by: Satendra Singh Thakur > Acked-by: Madhur Verma > Cc: Hemanshu Srivastava Whole exynos_dsi_mode_set callback is redundant, so I have posted patch removing it

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'

On 06.05.2018 02:46, Randy Dunlap wrote: > On 05/05/2018 04:22 PM, kbuild test robot wrote: >> Hi Maciej, >> >> FYI, the error/warning still remains. > Hi M. Robot, > > I am cc-ing dri-de...@lists.freedesktop.org so that they are aware of the > multiple times that you have posted this kbuild error

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2229: undefined reference to `extcon_find_edev_by_node'

On 06.05.2018 02:46, Randy Dunlap wrote: > On 05/05/2018 04:22 PM, kbuild test robot wrote: >> Hi Maciej, >> >> FYI, the error/warning still remains. > Hi M. Robot, > > I am cc-ing dri-de...@lists.freedesktop.org so that they are aware of the > multiple times that you have posted this kbuild error

Re: [PATCH 00/24] device link, bridge supplier <-> drm device

Hi Peter, On 27.04.2018 00:31, Peter Rosin wrote: > Hi! > > It was noted by Russel King [1] that bridges (not using components) > might disappear unexpectedly if the owner of the bridge was unbound. > Jyri Sarha had previously noted the same thing with panels [2]. Jyri > came up with using device

Re: [PATCH 00/24] device link, bridge supplier <-> drm device

Hi Peter, On 27.04.2018 00:31, Peter Rosin wrote: > Hi! > > It was noted by Russel King [1] that bridges (not using components) > might disappear unexpectedly if the owner of the bridge was unbound. > Jyri Sarha had previously noted the same thing with panels [2]. Jyri > came up with using device

Re: [PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode_set

On 25.01.2018 16:55, Philippe Cornu wrote: > The "adjusted_mode" clock value (ie the real pixel clock) is more > accurate than "mode" clock value (ie the panel/bridge requested > clock value). It offers a better preciseness for timing > computations and allows to reduce the extra dsi bandwidth in

Re: [PATCH] drm/bridge/synopsys: dsi: use adjusted_mode in mode_set

On 25.01.2018 16:55, Philippe Cornu wrote: > The "adjusted_mode" clock value (ie the real pixel clock) is more > accurate than "mode" clock value (ie the panel/bridge requested > clock value). It offers a better preciseness for timing > computations and allows to reduce the extra dsi bandwidth in

Re: [RESEND PATCH v6 00/27] DRM Rockchip rk3399 (Kevin)

On 23.04.2018 12:49, Enric Balletbo i Serra wrote: > Hi Andrzej, > > This is the rebased version of v6 series. This patchset includes cleanups, > improvements, and bug fixes for Rockchip DRM driver and PSR support. > > This version is a RESEND of v6 with few changes. The following two > patches

Re: [RESEND PATCH v6 00/27] DRM Rockchip rk3399 (Kevin)

On 23.04.2018 12:49, Enric Balletbo i Serra wrote: > Hi Andrzej, > > This is the rebased version of v6 series. This patchset includes cleanups, > improvements, and bug fixes for Rockchip DRM driver and PSR support. > > This version is a RESEND of v6 with few changes. The following two > patches

Re: [PATCH] drm/bridge/sii8620: fix link error

Hi Tobias, On 23.04.2018 10:47, Tobias Regnery wrote: > With CONFIG_EXTCON=m and CONFIG_DRM_SIL_SII8620=y we see the following link > error: > > drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_remove': > sil-sii8620.c:(.text+0xd5): undefined reference to > `extcon_unregister_notifier'

Re: [PATCH] drm/bridge/sii8620: fix link error

Hi Tobias, On 23.04.2018 10:47, Tobias Regnery wrote: > With CONFIG_EXTCON=m and CONFIG_DRM_SIL_SII8620=y we see the following link > error: > > drivers/gpu/drm/bridge/sil-sii8620.o: In function `sii8620_remove': > sil-sii8620.c:(.text+0xd5): undefined reference to > `extcon_unregister_notifier'

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

Hi Enric, On 05.04.2018 11:49, Enric Balletbo i Serra wrote: > From: "Kristian H. Kristensen" > > To improve PSR exit latency, we speculatively start exiting when we > receive input events. Occasionally, this may lead to false positives, > but most of the time we get a

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

Hi Enric, On 05.04.2018 11:49, Enric Balletbo i Serra wrote: > From: "Kristian H. Kristensen" > > To improve PSR exit latency, we speculatively start exiting when we > receive input events. Occasionally, this may lead to false positives, > but most of the time we get a head start on coming out

Re: [PATCH v9 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

On 18.04.2018 16:40, Jacopo Mondi wrote: > As I have another series which is based on this one + Eagle board display > support, I'm re-sending this one to fix the small issue I pointed out in my > reply to v8. > > Simon: no changes to Eagle DTS series, so the last one sent is still the good > one.

Re: [PATCH v9 0/2] drm: Add Thine THC63LVD1024 LVDS decoder bridge

On 18.04.2018 16:40, Jacopo Mondi wrote: > As I have another series which is based on this one + Eagle board display > support, I'm re-sending this one to fix the small issue I pointed out in my > reply to v8. > > Simon: no changes to Eagle DTS series, so the last one sent is still the good > one.

Re: [PATCH v6 28/30] drm/rockchip: Disable PSR from reboot notifier

On 05.04.2018 11:49, Enric Balletbo i Serra wrote: > From: Tomasz Figa > > It looks like the driver subsystem detaches devices from power domains > at shutdown without consent of the drivers. It looks bit strange. Could you elaborate more on it. Could you show the code

Re: [PATCH v6 28/30] drm/rockchip: Disable PSR from reboot notifier

On 05.04.2018 11:49, Enric Balletbo i Serra wrote: > From: Tomasz Figa > > It looks like the driver subsystem detaches devices from power domains > at shutdown without consent of the drivers. It looks bit strange. Could you elaborate more on it. Could you show the code performing the detach?

Re: [PATCH v6 30/30] drm/rockchip: psr: Remove flush by CRTC

to multiple encoders. > > Signed-off-by: Tomasz Figa <tf...@chromium.org> > Signed-off-by: Thierry Escande <thierry.esca...@collabora.com> > Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com> > Tested-by: Marek Szyprowski <m.szyprow...@sams

Re: [PATCH v6 30/30] drm/rockchip: psr: Remove flush by CRTC

> > Signed-off-by: Tomasz Figa > Signed-off-by: Thierry Escande > Signed-off-by: Enric Balletbo i Serra > Tested-by: Marek Szyprowski Reviewed-by: Andrzej Hajda  -- Regards Andrzej > --- > > drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 35 > ---

Re: [PATCH v6 29/30] drm/rockchip: Disallow PSR for the whole atomic commit

c_state, i) { > + encoder_mask |= crtc_state->encoder_mask; > + encoder_mask |= crtc->state->encoder_mask; Looks clever and cryptic. More readable would be with for_each_oldnew_crtc_in_state. Anyway: Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>  -- Regards Andrzej > +

Re: [PATCH v6 29/30] drm/rockchip: Disallow PSR for the whole atomic commit

i; > + > + for_each_old_crtc_in_state(state, crtc, crtc_state, i) { > + encoder_mask |= crtc_state->encoder_mask; > + encoder_mask |= crtc->state->encoder_mask; Looks clever and cryptic. More readable would be with for_each_oldnew_crtc

Re: [PATCH v6 27/30] drm/rockchip: psr: Sanitize semantics of allow/disallow API

o make the hardware enter > + * PSR mode in PSR_FLUSH_TIMEOUT_MS. > + * > * Returns: > * Zero on success, negative errno on failure. > */ > -int rockchip_drm_psr_activate(struct drm_encoder *encoder) > +int rockchip_drm_psr_inhibit_put(struct drm_encoder *encoder) > { > struct psr_dr

Re: [PATCH v6 27/30] drm/rockchip: psr: Sanitize semantics of allow/disallow API

p_drm_psr_activate(struct drm_encoder *encoder) > +int rockchip_drm_psr_inhibit_put(struct drm_encoder *encoder) > { > struct psr_drv *psr = find_psr_by_encoder(encoder); > > @@ -115,21 +120,29 @@ int rockchip_drm_psr_activate(struct drm_encoder > *encoder

Re: [PATCH v6 26/30] drm/rockchip: psr: Avoid redundant calls to .set() callback

On 05.04.2018 11:49, Enric Balletbo i Serra wrote: > From: Tomasz Figa > > The first time after we call rockchip_drm_do_flush() after > rockchip_drm_psr_register(), we go from PSR_DISABLE to PSR_FLUSH. The > difference between PSR_DISABLE and PSR_FLUSH is whether or not we

Re: [PATCH v6 26/30] drm/rockchip: psr: Avoid redundant calls to .set() callback

On 05.04.2018 11:49, Enric Balletbo i Serra wrote: > From: Tomasz Figa > > The first time after we call rockchip_drm_do_flush() after > rockchip_drm_psr_register(), we go from PSR_DISABLE to PSR_FLUSH. The > difference between PSR_DISABLE and PSR_FLUSH is whether or not we have a > delayed work

Re: [PATCH v6 25/30] drm/rockchip: Cancel PSR enable work before changing the state

{ > + cancel_delayed_work_sync(>flush_work); > psr_set_state(psr, PSR_FLUSH); > mod_delayed_work(system_wq, >flush_work, PSR_FLUSH_TIMEOUT_MS); I guess you can change it to schedule_delayed_work then. Anyway: Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>  -- Regard

Re: [PATCH v6 25/30] drm/rockchip: Cancel PSR enable work before changing the state

he PSR encoder > @@ -198,6 +186,7 @@ EXPORT_SYMBOL(rockchip_drm_psr_deactivate); > > static void rockchip_drm_do_flush(struct psr_drv *psr) > { > + cancel_delayed_work_sync(>flush_work); > psr_set_state(psr, PSR_FLUSH); > mod_delayed_work(system_wq, >flush_work, PSR_F

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

+CC: linux-input list and maintainer On 05.04.2018 11:49, Enric Balletbo i Serra wrote: > From: "Kristian H. Kristensen" > > To improve PSR exit latency, we speculatively start exiting when we > receive input events. Occasionally, this may lead to false positives, > but

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

+CC: linux-input list and maintainer On 05.04.2018 11:49, Enric Balletbo i Serra wrote: > From: "Kristian H. Kristensen" > > To improve PSR exit latency, we speculatively start exiting when we > receive input events. Occasionally, this may lead to false positives, > but most of the time we get

Re: [PATCH v6 23/30] drm/rockchip: analogix_dp: Do not call Analogix code before bind

as a safeguard and skip calling > Analogix entry points if it is an ERR_PTR(). >From purity PoV I would store either 0 either valid pointer in dp->adp, but functionally it should be the same. Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>  -- Regards Andrzej > > Signed-off-

Re: [PATCH v6 23/30] drm/rockchip: analogix_dp: Do not call Analogix code before bind

g > Analogix entry points if it is an ERR_PTR(). >From purity PoV I would store either 0 either valid pointer in dp->adp, but functionally it should be the same. Reviewed-by: Andrzej Hajda  -- Regards Andrzej > > Signed-off-by: Tomasz Figa > Signed-off-by: Thierry Escand

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to `extcon_unregister_notifier'

On 06.04.2018 12:34, Chanwoo Choi wrote: > Hi Andrzej, > > On 2018년 04월 06일 19:14, Andrzej Hajda wrote: >> Hi Chanwoo, >> >> It looks like something went wrong, sii8620 patch was merged without >> extcon dependencies. >> Could you look at it? > If ad

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to `extcon_unregister_notifier'

On 06.04.2018 12:34, Chanwoo Choi wrote: > Hi Andrzej, > > On 2018년 04월 06일 19:14, Andrzej Hajda wrote: >> Hi Chanwoo, >> >> It looks like something went wrong, sii8620 patch was merged without >> extcon dependencies. >> Could you look at it? > If ad

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to `extcon_unregister_notifier'

Hi Chanwoo, It looks like something went wrong, sii8620 patch was merged without extcon dependencies. Could you look at it? Regards Andrzej On 06.04.2018 11:52, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head:

Re: drivers/gpu/drm/bridge/sil-sii8620.c:2405: undefined reference to `extcon_unregister_notifier'

Hi Chanwoo, It looks like something went wrong, sii8620 patch was merged without extcon dependencies. Could you look at it? Regards Andrzej On 06.04.2018 11:52, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head:

Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 27.03.2018 09:36, Geert Uytterhoeven wrote: > Hi Andrzej, > > On Tue, Mar 27, 2018 at 9:28 AM, Andrzej Hajda <a.ha...@samsung.com> wrote: >>>> --- /dev/null >>>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c >>>> +static void thc63_enable(

Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 27.03.2018 09:36, Geert Uytterhoeven wrote: > Hi Andrzej, > > On Tue, Mar 27, 2018 at 9:28 AM, Andrzej Hajda wrote: >>>> --- /dev/null >>>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c >>>> +static void thc63_enable(struct drm_bridge *bridge) >>

Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 27.03.2018 08:24, Vladimir Zapolskiy wrote: > Hi Jacopo, > > On 03/16/2018 05:16 PM, Jacopo Mondi wrote: >> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel >> output converter. >> >> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmond

Re: [PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 27.03.2018 08:24, Vladimir Zapolskiy wrote: > Hi Jacopo, > > On 03/16/2018 05:16 PM, Jacopo Mondi wrote: >> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel >> output converter. >> >> Signed-off-by: Jacopo Mondi >> Reviewed-by

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

patch. >>> >>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote: >>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings. >>>> >>>> Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> >>

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

patch. >>> >>> On Friday, 16 March 2018 17:16:37 EET Jacopo Mondi wrote: >>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings. >>>> >>>> Signed-off-by: Jacopo Mondi >>>> Reviewed-by: Andrzej Hajda >>>> Re

Re: [PATCH v4 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

has been so-far > omitted from DTS. Now that a driver is available, describe it in DT > as well. > > Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org> Reviewed-by: Andrzej Hajda <a.ha...@samsung.com>  -- Regards Andrzej > --- > arch/a

Re: [PATCH v4 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle

has been so-far > omitted from DTS. Now that a driver is available, describe it in DT > as well. > > Signed-off-by: Jacopo Mondi Reviewed-by: Andrzej Hajda  -- Regards Andrzej > --- > arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 > +++--- &g

Re: [PATCH v4 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

;dev, "Unable to get \"oe-gpios\"\n"); > + return PTR_ERR(thc63->oe); > + } > + > + thc63->pdwn = devm_gpiod_get_optional(thc63->dev, "pdwn", > + GPIOD_OUT_HIGH); > + if (IS_ERR(th

Re: [PATCH v4 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

return PTR_ERR(thc63->oe); > + } > + > + thc63->pdwn = devm_gpiod_get_optional(thc63->dev, "pdwn", > + GPIOD_OUT_HIGH); > + if (IS_ERR(thc63->pdwn)) { > + dev_err(thc63->de

Re: [PATCH v4 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

y for PLL circuitry > +- pdwn-gpios: Power down GPIO signal. Active low. > +- oe-gpios: Output enable GPIO signal. Active high. Nitpick: different lines ends differently: period, dot, nothing. Another thing if there will be next iteration it would be good to emphasize converter has no

Re: [PATCH v4 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

-gpios: Power down GPIO signal. Active low. > +- oe-gpios: Output enable GPIO signal. Active high. Nitpick: different lines ends differently: period, dot, nothing. Another thing if there will be next iteration it would be good to emphasize converter has no control bus. Anyway: Reviewed-by: Andrzej

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

STEM) Serious omission, sorry for that. > > On 12/03/18 09:02, Andrzej Hajda wrote: >> On 09.03.2018 11:24, Roger Quadros wrote: >>> Hi, >>> >>> On 27/02/18 09:11, Andrzej Hajda wrote: >>>> These bindings allow to describe most known standard

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

On 12.03.2018 11:41, Roger Quadros wrote: > Andrezej, > > Why don't you have any of the USB maintainers in to/cc? > > Greg Kroah-Hartman (supporter:USB SUBSYSTEM) > Felipe Balbi (maintainer:USB GADGET/PERIPHERAL SUBSYSTEM) Serious omission, sorry for that. > > On 12/03

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 14.03.2018 11:09, jacopo mondi wrote: > Hi Andrzej, > thanks for review > > On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote: >> On 13.03.2018 15:30, Jacopo Mondi wrote: >>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 14.03.2018 11:09, jacopo mondi wrote: > Hi Andrzej, > thanks for review > > On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote: >> On 13.03.2018 15:30, Jacopo Mondi wrote: >>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 13.03.2018 15:30, Jacopo Mondi wrote: > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel > output decoder. IMO converter suits here better, but it is just suggestion. > > Signed-off-by: Jacopo Mondi > --- > drivers/gpu/drm/bridge/Kconfig

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

On 13.03.2018 15:30, Jacopo Mondi wrote: > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel > output decoder. IMO converter suits here better, but it is just suggestion. > > Signed-off-by: Jacopo Mondi > --- > drivers/gpu/drm/bridge/Kconfig| 7 + >

Re: [PATCH v3 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

On 13.03.2018 15:30, Jacopo Mondi wrote: > Document Thine THC63LVD1024 LVDS decoder device tree bindings. > > Signed-off-by: Jacopo Mondi > --- > .../bindings/display/bridge/thine,thc63lvd1024.txt | 63 > ++ > 1 file changed, 63 insertions(+) >

Re: [PATCH v3 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

On 13.03.2018 15:30, Jacopo Mondi wrote: > Document Thine THC63LVD1024 LVDS decoder device tree bindings. > > Signed-off-by: Jacopo Mondi > --- > .../bindings/display/bridge/thine,thc63lvd1024.txt | 63 > ++ > 1 file changed, 63 insertions(+) > create mode 100644 >

Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge

On 12.03.2018 13:30, jacopo mondi wrote: > Hi Andrzej, > > On Mon, Mar 12, 2018 at 10:07:27AM +0100, Andrzej Hajda wrote: >> On 09.03.2018 14:51, Jacopo Mondi wrote: >>> Hello, >>>after some discussion on the proposed bindings for generic lvds decoder >>

Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge

On 12.03.2018 13:30, jacopo mondi wrote: > Hi Andrzej, > > On Mon, Mar 12, 2018 at 10:07:27AM +0100, Andrzej Hajda wrote: >> On 09.03.2018 14:51, Jacopo Mondi wrote: >>> Hello, >>>after some discussion on the proposed bindings for generic lvds decoder >>

Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge

On 09.03.2018 14:51, Jacopo Mondi wrote: > Hello, >after some discussion on the proposed bindings for generic lvds decoder and > Thine THC63LVD1024, I decided to drop the THC63 specific part and just live > with > a transparent decoder that does not support any configuration from DT. > >

Re: [PATCH v2 0/3] drm: Add LVDS decoder bridge

On 09.03.2018 14:51, Jacopo Mondi wrote: > Hello, >after some discussion on the proposed bindings for generic lvds decoder and > Thine THC63LVD1024, I decided to drop the THC63 specific part and just live > with > a transparent decoder that does not support any configuration from DT. > >

Re: [PATCH v2 2/3] drm: bridge: Add LVDS decoder driver

On 09.03.2018 14:51, Jacopo Mondi wrote: > Add transparent LVDS decoder driver. > > A transparent LVDS decoder is a DRM bridge device that does not require > any configuration and converts LVDS input to digital CMOS/TTL parallel > data output. Neither code, neither bindings are LVDS specific,

Re: [PATCH v2 2/3] drm: bridge: Add LVDS decoder driver

On 09.03.2018 14:51, Jacopo Mondi wrote: > Add transparent LVDS decoder driver. > > A transparent LVDS decoder is a DRM bridge device that does not require > any configuration and converts LVDS input to digital CMOS/TTL parallel > data output. Neither code, neither bindings are LVDS specific,

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

On 12.03.2018 08:02, Andrzej Hajda wrote: > On 09.03.2018 11:24, Roger Quadros wrote: >> Hi, >> >> On 27/02/18 09:11, Andrzej Hajda wrote: >>> These bindings allow to describe most known standard USB connectors >>> and it should be possible to extend it if ne

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

On 12.03.2018 08:02, Andrzej Hajda wrote: > On 09.03.2018 11:24, Roger Quadros wrote: >> Hi, >> >> On 27/02/18 09:11, Andrzej Hajda wrote: >>> These bindings allow to describe most known standard USB connectors >>> and it should be possible to extend it if ne

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

On 09.03.2018 11:24, Roger Quadros wrote: > Hi, > > On 27/02/18 09:11, Andrzej Hajda wrote: >> These bindings allow to describe most known standard USB connectors >> and it should be possible to extend it if necessary. >> USB connectors, beside USB can be us

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

On 09.03.2018 11:24, Roger Quadros wrote: > Hi, > > On 27/02/18 09:11, Andrzej Hajda wrote: >> These bindings allow to describe most known standard USB connectors >> and it should be possible to extend it if necessary. >> USB connectors, beside USB can be us

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

Hi Chanwoo, On 08.03.2018 02:52, Chanwoo Choi wrote: > Hi Andrzej, Archit, > > On 2018년 03월 07일 20:13, Andrzej Hajda wrote: >> Hi Chanwoo, Archit, >> >> On 07.03.2018 05:48, Chanwoo Choi wrote: >>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >>>> H

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

Hi Chanwoo, On 08.03.2018 02:52, Chanwoo Choi wrote: > Hi Andrzej, Archit, > > On 2018년 03월 07일 20:13, Andrzej Hajda wrote: >> Hi Chanwoo, Archit, >> >> On 07.03.2018 05:48, Chanwoo Choi wrote: >>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >>>> H

Re: [PATCH 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

On 08.03.2018 16:24, Jacopo Mondi wrote: > Document Thine THC63LVD1024 LVDS decoder. > > Signed-off-by: Jacopo Mondi > --- > .../bindings/display/bridge/thine,thc63lvd1024.txt | 59 > ++ > 1 file changed, 59 insertions(+) > create mode 100644 >

Re: [PATCH 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

On 08.03.2018 16:24, Jacopo Mondi wrote: > Document Thine THC63LVD1024 LVDS decoder. > > Signed-off-by: Jacopo Mondi > --- > .../bindings/display/bridge/thine,thc63lvd1024.txt | 59 > ++ > 1 file changed, 59 insertions(+) > create mode 100644 >

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

On 07.03.2018 12:22, Krzysztof Kozlowski wrote: > On Wed, Mar 7, 2018 at 12:13 PM, Andrzej Hajda <a.ha...@samsung.com> wrote: >> Hi Chanwoo, Archit, >> >> On 07.03.2018 05:48, Chanwoo Choi wrote: >>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >>>> H

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

On 07.03.2018 12:22, Krzysztof Kozlowski wrote: > On Wed, Mar 7, 2018 at 12:13 PM, Andrzej Hajda wrote: >> Hi Chanwoo, Archit, >> >> On 07.03.2018 05:48, Chanwoo Choi wrote: >>> On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >>>> Hi Rob and Andrzej, >&

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

Hi Chanwoo, Archit, On 07.03.2018 05:48, Chanwoo Choi wrote: > On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >> Hi Rob and Andrzej, >> >> On 2018년 03월 06일 21:53, Andrzej Hajda wrote: >>> Hi Rob, Chanwoo, Krzysztof, >>> >>> >>> On 27.02.2

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

Hi Chanwoo, Archit, On 07.03.2018 05:48, Chanwoo Choi wrote: > On 2018년 03월 07일 11:12, Chanwoo Choi wrote: >> Hi Rob and Andrzej, >> >> On 2018년 03월 06일 21:53, Andrzej Hajda wrote: >>> Hi Rob, Chanwoo, Krzysztof, >>> >>> >>> On 27.02.2

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

Hi Rob, Chanwoo, Krzysztof, On 27.02.2018 08:11, Andrzej Hajda wrote: > Hi, > > Thanks for reviews of previous iterations. > > This patchset introduces USB physical connector bindings, together with > working example. > I have removed RFC prefix - the patchset seems to be

Re: [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector

Hi Rob, Chanwoo, Krzysztof, On 27.02.2018 08:11, Andrzej Hajda wrote: > Hi, > > Thanks for reviews of previous iterations. > > This patchset introduces USB physical connector bindings, together with > working example. > I have removed RFC prefix - the patchset seems to be

Re: [PATCH] drm/bridge/synopsys: dsi: readl_poll_timeout return value clean up

On 02.03.2018 14:15, Philippe CORNU wrote: > Hi Andrzej, > > > On 03/02/2018 11:21 AM, Andrzej Hajda wrote: >> On 01.03.2018 10:00, Philippe CORNU wrote: >>> Hi Archit, Andrzej & Laurent, >>> >>> May I ask you please your feedback on th

Re: [PATCH] drm/bridge/synopsys: dsi: readl_poll_timeout return value clean up

On 02.03.2018 14:15, Philippe CORNU wrote: > Hi Andrzej, > > > On 03/02/2018 11:21 AM, Andrzej Hajda wrote: >> On 01.03.2018 10:00, Philippe CORNU wrote: >>> Hi Archit, Andrzej & Laurent, >>> >>> May I ask you please your feedback on th

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

On 02.03.2018 14:13, Heikki Krogerus wrote: > Hi, > > On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote: >> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed >> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

On 02.03.2018 14:13, Heikki Krogerus wrote: > Hi, > > On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote: >> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed >> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.

Re: [PATCH] drm/bridge/synopsys: dsi: readl_poll_timeout return value clean up

dingStyle says nothing about it, so I suppose it is matter of personal taste. Anyway I can give it: Reviewed-by: Andrzej Hajda  -- Regards Andrzej >> --- >> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 10 +- >> 1 file changed, 5 insertions(+), 5 deletions(-) >&g

Re: [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

On 27.02.2018 23:26, Chanwoo Choi wrote: > Hi, > > On 2018년 02월 27일 21:05, Andrzej Hajda wrote: >> On 27.02.2018 12:08, Chanwoo Choi wrote: >>> Hi, >>> >>> On 2018년 02월 27일 16:11, Andrzej Hajda wrote: >>>> From: Maciej Purski <m.pur...

Re: [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

On 27.02.2018 23:26, Chanwoo Choi wrote: > Hi, > > On 2018년 02월 27일 21:05, Andrzej Hajda wrote: >> On 27.02.2018 12:08, Chanwoo Choi wrote: >>> Hi, >>> >>> On 2018년 02월 27일 16:11, Andrzej Hajda wrote: >>>> From: Maciej Purski >>>&g

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

On 27.02.2018 22:24, Rob Herring wrote: > On Wed, Feb 21, 2018 at 2:55 AM, Andrzej Hajda <a.ha...@samsung.com> wrote: >> OF graph describes MHL data lanes between MHL and respective USB >> connector. >> >> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com&g

Re: [PATCH v4 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

On 27.02.2018 22:24, Rob Herring wrote: > On Wed, Feb 21, 2018 at 2:55 AM, Andrzej Hajda wrote: >> OF graph describes MHL data lanes between MHL and respective USB >> connector. >> >> Signed-off-by: Andrzej Hajda >> --- >> v4: >> - added missing reg

[PATCH v6 5/6] extcon: add possibility to get extcon device by OF node

Since extcon property is not allowed in DT, extcon subsystem requires another way to get extcon device. Lets try the simplest approach - get edev by of_node. Signed-off-by: Andrzej Hajda <a.ha...@samsung.com> Acked-by: Chanwoo Choi <cw00.c...@samsung.com> --- v5: func

[PATCH v6 5/6] extcon: add possibility to get extcon device by OF node

Since extcon property is not allowed in DT, extcon subsystem requires another way to get extcon device. Lets try the simplest approach - get edev by of_node. Signed-off-by: Andrzej Hajda Acked-by: Chanwoo Choi --- v5: function renamed to extcon_find_edev_by_node (Andy) v2: changed label

Re: [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

On 27.02.2018 12:08, Chanwoo Choi wrote: > Hi, > > On 2018년 02월 27일 16:11, Andrzej Hajda wrote: >> From: Maciej Purski <m.pur...@samsung.com> >> >> Currently MHL chip must be turned on permanently to detect MHL cable. It >> duplicates micro-USB control

Re: [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL

On 27.02.2018 12:08, Chanwoo Choi wrote: > Hi, > > On 2018년 02월 27일 16:11, Andrzej Hajda wrote: >> From: Maciej Purski >> >> Currently MHL chip must be turned on permanently to detect MHL cable. It >> duplicates micro-USB controller's (MUIC) functionality and co

[PATCH v5 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector

OF graph describes MHL data lanes between MHL and respective USB connector. Signed-off-by: Andrzej Hajda <a.ha...@samsung.com> --- v5: removed extra parenthesis (kbuild test robot) v4: added missing reg property in connector's port node (Krzysztof) --- .../boot/dts/exynos/exynos54

<    1   2   3   4   5   6   7   8   9   10   >