NVIDIA Corporation C77 [GeForce 8300] (rev a2) has chipset 0xaa which
supports HDMI Audio.
Signed-off-by: Alexander Stein alexander.st...@informatik.tu-chemnitz.de
---
drivers/gpu/drm/nouveau/nouveau_hdmi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu
working again.
It should work on any HDMI head, but due to lacking ahrdware I could
only test the (1st) one.
It also might be possible that similar code is needed for nva3, which I
can't test.
Signed-off-by: Alexander Stein alexander.st...@informatik.tu-chemnitz.de
---
This patch should also be added
On Tuesday 14 June 2016 17:20:36, Meng Yi wrote:
> This patch creates another Encoder for HDMI port, and linking the Encoder
> to appropriate DRM bridge. And this Encoder using same CRTC with RGB-LCD.
> For RGB-LCD and HDMI using the same hardware connection to DCU, RGB-LCD
> panel should be
On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> On 2016-05-24 19:14, Meng Yi wrote:
> > I found that its regmap endianness issue, so I want to replace the
> > "regmap".
> Hm, replace with what? Note that we need some kind of endianness
> convertion since the IP is big endian on LS1021a and
Hi,
On Wednesday 25 May 2016 08:58:31, Meng Yi wrote:
> > On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> > > On 2016-05-24 19:14, Meng Yi wrote:
> > > > I found that its regmap endianness issue, so I want to replace the
> > > > "regmap".
> > >
> > > Hm, replace with what? Note that we
On Wednesday 25 May 2016 10:25:29, Meng Yi wrote:
> Hi Alexander,
> Thanks for your reply.
>
> > Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child
> > commit in my repo. Both touch only i915 related things. Please do a proper
> > bisect and name the offending commit. On which
On Thursday 26 May 2016 08:18:30, Meng Yi wrote:
> Hi Alexander,
>
> > From your backtrace I guess wait_event_timeout is called in some atomic
> > context (might_sleep(); is called inside wait_event_timeout). This has
> > nothing to do with regmap.
>
> Here is my view of point:
> Since IRQ setup
On Thursday 26 May 2016 08:23:42, Meng Yi wrote:
> Hi Mark,
>
> > You've not specifically described the problem here - what are the
> > endiannesses of both the CPU and the device you're talking to? What
> > specifically is the endianess problem you are seeing, what are you seeing
> > and what
Using REGCACHE_RBTREE for MMIO regmap is not valid as spinlock's will be
used during cache allocation.
This fixes the following bug:
BUG: sleeping function called from invalid context at mm/slab.h:388
in_atomic(): 1, irqs_disabled(): 128, pid: 192, name: udevd
[...]
Signed-off-by: Alexander
Hi,
some comments below.
On Monday 28 March 2016 19:00:00, Stefan Agner wrote:
> Add driver for the TCON (timing controller) module. The TCON module
> is a separate module attached after the DCU (display controller
> unit). Each DCU instance has its own, directly connected TCON
> instance. The
On Friday 25 March 2016 09:24:28, Stefan Agner wrote:
> Hi Alexander,
>
> On 2016-03-24 06:33, Alexander Stein wrote:
> > Using REGCACHE_RBTREE for MMIO regmap is not valid as spinlock's will be
> > used during cache allocation.
> >
> > This fixes the followin
On Tuesday 29 March 2016 00:11:13, Stefan Agner wrote:
> >> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> >> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> >>
> >> @@ -14,6 +14,7 @@ Required properties:
> >> Optional properties:
> >> - clocks: Second
working again.
It should work on any HDMI head, but due to lacking ahrdware I could
only test the (1st) one.
It also might be possible that similar code is needed for nva3, which I
can't test.
Signed-off-by: Alexander Stein
---
This patch should also be added to stable kernels.
drivers/gpu/drm/nouveau
pe to REGCACHE_FLAT, but neither _LZO or _RBTREE
(see https://lkml.org/lkml/2015/7/16/552 for that)
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein at systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office
NVIDIA Corporation C77 [GeForce 8300] (rev a2) has chipset 0xaa which
supports HDMI Audio.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/nouveau/nouveau_hdmi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hdmi.c
b/drivers/gpu
Hello Laurent,
On Tue, Oct 12, 2021 at 10:43 +0200, Laurent Pinchart wrote:
> On Tue, Oct 12, 2021 at 08:48:43AM +0200, Alexander Stein wrote:
> > VCC needs to be enabled before releasing the enable GPIO.
> >
> > Reviewed-by: Sam Ravnborg
> > Signed-off-by: Alexander
Hi Sam,
On Mon, 11 Oct 2021 22:29:30 +0200, Sam Ravnborg wrote:
> > VCC needs to be enabled before releasing the enable GPIO.
> >
> > Signed-off-by: Alexander Stein
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 15 ++-
> > 1 file c
From: Laurent Pinchart
The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled by
means not available to the kernel. Make the GPIO optional.
Signed-off-by: Laurent Pinchart
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 1
Add a VCC regulator which needs to be enabled before the EN pin is
released.
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings
Changes in V2 of this set:
* Add patch from Laurent for fixing the binding regarding optional GPIO
* Reorder patches so bindings are changed beforehand
* Add small fixes from Sam's review
Alexander Stein (3):
drm/bridge: ti-sn65dsi83: Make enable GPIO optional
dt-bindings: drm/bridge: ti
The enable signal may not be controllable by the kernel. Make it
optional.
This is a similar to commit bbda1704fc15 ("drm/bridge: ti-sn65dsi86: Make
enable GPIO optional")
Reviewed-by: Laurent Pinchart
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
drivers/gpu/drm
VCC needs to be enabled before releasing the enable GPIO.
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu
VCC needs to be enabled before releasing the enable GPIO.
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge
The enable signal may not be controllable by the kernel. Make it
optional.
This is a similar to commit bbda1704fc15 ("drm/bridge: ti-sn65dsi86: Make
enable GPIO optional")
Reviewed-by: Laurent Pinchart
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
drivers/gpu/drm
From: Laurent Pinchart
The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled by
means not available to the kernel. Make the GPIO optional.
Signed-off-by: Laurent Pinchart
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 1
Add a VCC regulator which needs to be enabled before the EN pin is
released.
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings
patches so bindings are changed beforehand
* Add small fixes from Sam's review
Alexander Stein (3):
drm/bridge: ti-sn65dsi83: Make enable GPIO optional
dt-bindings: drm/bridge: ti-sn65dsi83: Add vcc supply bindings
drm/bridge: ti-sn65dsi83: Add vcc supply regulator support
Laurent Pinchart
ings/display/bridge/ti,sn65dsi83.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> @@ -93,7 +93,6 @@ properties:
> required:
>- compatible
>- reg
> - - enable-gpios
>- ports
>
> allOf:
>
> base-commit: 1e39445
On Wed, Oct 6, 2021 at 3:21 PM Rob Herring
wrote:
> On Wed, Oct 6, 2021 at 2:47 AM Alexander Stein
> wrote:
> >
> > Add a VCC regulator which needs to be enabled before the EN pin is
> > released.
> >
> > Signed-off-by: Alexander Stein
> > ---
>
Add a VCC regulator which needs to be enabled before the EN pin is
released.
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83
The enable signal may not be controllable by the kernel. Make it
optional.
This is a similar to commit bbda1704fc15 ("drm/bridge: ti-sn65dsi86: Make
enable GPIO optional")
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 2 +-
1 file changed, 1 insertion(+),
VCC needs to be enabled before releasing the enable GPIO.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
Add small fixes from Sam's review
Alexander Stein (3):
drm/bridge: ti-sn65dsi83: Make enable GPIO optional
dt-bindings: drm/bridge: ti-sn65dsi83: Add vcc supply bindings
drm/bridge: ti-sn65dsi83: Add vcc supply regulator support
Laurent Pinchart (1):
dt-bindings: display: bridge: sn65d
VCC needs to be enabled before releasing the enable GPIO.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index
The enable signal may not be controllable by the kernel. Make it
optional.
This is a similar to commit bbda1704fc15 ("drm/bridge: ti-sn65dsi86: Make
enable GPIO optional")
Reviewed-by: Laurent Pinchart
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
drivers/gpu/drm
Add a VCC regulator which needs to be enabled before the EN pin is
released.
Reviewed-by: Sam Ravnborg
Acked-by: Rob Herring
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation
From: Laurent Pinchart
The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled by
means not available to the kernel. Make the GPIO optional.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti
Am Donnerstag, dem 09.12.2021 um 12:37 +0530 schrieb Jagan Teki:
> On Thu, Nov 18, 2021 at 2:50 PM Alexander Stein
> <
> alexander.st...@ew.tq-group.com
> > wrote:
> > From: Laurent Pinchart <
> > laurent.pinch...@ideasonboard.com
> > >
> >
Add a VCC regulator which needs to be enabled before the EN pin is
released.
Reviewed-by: Sam Ravnborg
Acked-by: Rob Herring
Reviewed-by: Jagan Teki
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4
1 file changed, 4 insertions
VCC needs to be enabled before releasing the enable GPIO.
Reviewed-by: Laurent Pinchart
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm
The enable signal may not be controllable by the kernel. Make it
optional.
This is a similar to commit bbda1704fc15 ("drm/bridge: ti-sn65dsi86: Make
enable GPIO optional")
Reviewed-by: Laurent Pinchart
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
drivers/gpu/drm
/disable to sn65dsi83_atomic_pre_enable and
sn65dsi83_atomic_disable
Changes in V2 of this set:
* Add patch from Laurent for fixing the binding regarding optional GPIO
* Reorder patches so bindings are changed beforehand
* Add small fixes from Sam's review
Alexander Stein (3):
drm/bridge: ti-sn65dsi83: Make enable GPIO
From: Laurent Pinchart
The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled by
means not available to the kernel. Make the GPIO optional.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti
Am Mittwoch, 2. Februar 2022, 09:30:38 CET schrieb Marek Vasut:
> On 2/2/22 09:17, Alexander Stein wrote:
> > mxsfb should not never dereference the NULL pointer which
>
> ... not ever ... but that's really a nitpick.
Doh, I just copied it from my mail...
You want me
/
[2]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220121131238.507567-1-alexander.st...@ew.tq-group.com/
Alexander Stein (2):
drm: mxsfb: Use dev_err_probe() helper
drm: mxsfb: Fix NULL pointer dereference
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +--
drivers/gpu/drm/mxsfb
Use the dev_err_probe() helper, instead of open-coding the same
operation. This also adds a nice hint in
/sys/kernel/debug/devices_deferred.
Reviewed-by: Marek Vasut
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions
mxsfb should not never dereference the NULL pointer which
drm_atomic_get_new_bridge_state is allowed to return.
Assume a fixed format instead.
Fixes: commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge
if present")
Signed-off-by: Alexander Stein
---
drivers/gpu
Am Mittwoch, 2. Februar 2022, 09:29:20 CET schrieb Marek Vasut:
> On 2/2/22 09:17, Alexander Stein wrote:
> > Use the dev_err_probe() helper, instead of open-coding the same
> > operation. This also adds a nice hint in
> > /sys/kernel/debug/devices_deferred.
> >
&
Hi Laurent,
Am Donnerstag, 3. Februar 2022, 00:45:59 CET schrieb Laurent Pinchart:
> [...]
> You're right that there's an issue, but a revert isn't the right option.
> The commit you're reverting never made it in a stable release, because
> it was deemed to not be a good enough option.
>
> First
sn65dsi83_host_attach is called from probe, so silence message upon
deferred probe. This can happen, e.g. if the bridge driver is built-in, but
the host is built as module.
Signed-off-by: Alexander Stein
---
This might look a bit weird in the first place, but the real benefit is
usage
There is no need to require non-sleeping GPIO access. Silence the
WARN_ON() if GPIO is using e.g. I2C expanders.
Signed-off-by: Alexander Stein
---
If the GPIO is from an expander on I2C, this warning will rise
obviously. Straight forward fix.
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 4 ++--
1
_get_sync()/pm_runtime_put_sync() calls in .atomic_enable
> and .atomic_disable callbacks turn the clock ON and OFF at the right
> time.
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
> Cc: Lucas Stach
> Cc: Peng Fan
> Cc: Robby Cai
>
Use the dev_err_probe() helper, instead of open-coding the same
operation. This also adds a nice hint in
/sys/kernel/debug/devices_deferred.
Signed-off-by: Alexander Stein
---
Based on next-20220120
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
Do not deference the NULL pointer if the bridge does not return a
bridge state. Assume a fixed format instead.
Fixes: commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge
if present")
Signed-off-by: Alexander Stein
---
This can happen if a "ti,sn75lvds83&
Am Freitag, 21. Januar 2022, 14:14:01 CET schrieb Marek Vasut:
> On 1/21/22 14:12, Alexander Stein wrote:
> > Do not deference the NULL pointer if the bridge does not return a
> > bridge state. Assume a fixed format instead.
> >
> > Fixes: commit b776b0f00f24 ("
Hello Lucas,
Am Mittwoch, 6. April 2022, 18:01:13 CEST schrieb Lucas Stach:
> Hi all,
>
> this adds support for the HDMI output pipeline on the i.MX8MP.
> It currently depends on the i.MX8MP HDMI power domain series [1]
> and support for the new LCDIF [2] in the i.MX8MP. I guess the
>
Hi Jagan,
thanks for picking this up again and sending a new version.
Am Freitag, 8. April 2022, 18:20:57 CEST schrieb Jagan Teki:
> This series supports common bridge support for Samsung MIPI DSIM
> which is used in Exynos and i.MX8MM SoC's.
>
> Previous RFC can be available here [1].
>
> The
Am Mittwoch, 6. April 2022, 11:29:29 CEST schrieb Marek Vasut:
> In case the MXSFB is connected to a bridge, attempt to obtain bus flags
> from that bridge state too. The bus flags may specify e.g. the DE signal
> polarity.
>
> Signed-off-by: Marek Vasut
> Cc: Alexander St
Hi Sandor,
thanks for working on this.
Am Donnerstag, 7. September 2023, 03:05:33 CEST schrieb Sandor Yu:
> Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ
>
> Cadence HDP-TX PHY could be put in either DP mode or
> HDMI mode base on the configuration chosen.
> DisplayPort PHY mode is
Hi Sandor,
thanks for the update.
One small typo in the commit message: 'Creat' -> 'Create'
Am Dienstag, 17. Oktober 2023, 09:03:57 CEST schrieb Sandor Yu:
> MHDP8546 mailbox access functions will be share to other mhdp driver
> and Cadence HDP-TX HDMI/DP PHY drivers.
> Create a new mhdp helper
; Signed-off-by: Sandor Yu
> Tested-by: Alexander Stein
> ---
> v10->v11:
> - remove MODULE_ALIAS() from mhdp8501 driver.
>
> v9->v10:
> - struct cdns_mhdp_device is renamed to cdns_mhdp8501_device.
> - update for mhdp helper driver is introduced.
> Remove head file cdns-
d in the driver.
>
> Signed-off-by: Sandor Yu
> Tested-by: Alexander Stein
> ---
> v9->v11:
> *No change.
>
> drivers/phy/freescale/Kconfig | 10 +
> drivers/phy/freescale/Makefile | 1 +
> drivers/phy/freescale/phy-fsl-imx8mq-hdmi
Hi Sandor,
thanks for the patch.
Am Dienstag, 17. Oktober 2023, 09:04:02 CEST schrieb Sandor Yu:
> Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ
>
> Cadence HDP-TX PHY could be put in either DP mode or
> HDMI mode base on the configuration chosen.
> DisplayPort PHY mode is configurated
3")
Signed-off-by: Markus Niebel
Signed-off-by: Alexander Stein
Reviewed-by: Sam Ravnborg
---
Changes in v2:
* Collected Sam's R-b
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/
; Signed-off-by: Sandor Yu
> Tested-by: Alexander Stein
> ---
> v9->v10:
> - struct cdns_mhdp_device is renamed to cdns_mhdp8501_device.
> - update for mhdp helper driver is introduced.
> Remove head file cdns-mhdp-mailbox.h and add cdns-mhdp-helper.h
> Add struct cdns_
Hi Sandor,
thanks for the updated series.
Am Freitag, 13. Oktober 2023, 05:24:20 CEST schrieb Sandor Yu:
> MHDP8546 mailbox access functions will be share to other mhdp driver
> and Cadence HDP-TX HDMI/DP PHY drivers.
> Create a new mhdp helper driver and move all those functions into.
>
>
Hi,
Am Donnerstag, 19. Oktober 2023, 13:19:51 CEST schrieb Dmitry Baryshkov:
> On Thu, 19 Oct 2023 at 12:26, Maxime Ripard wrote:
> > On Mon, Oct 16, 2023 at 07:53:48PM +0300, Dmitry Baryshkov wrote:
> > > The MIPI DSI links do not fully fall into the DRM callbacks model.
> >
> > Explaining why
Am Montag, 23. Oktober 2023, 09:34:42 CEST schrieb Dmitry Baryshkov:
> On Mon, 23 Oct 2023 at 09:52, Alexander Stein
>
> wrote:
> > Hi Dmitry,
> >
> > Am Sonntag, 22. Oktober 2023, 12:49:41 CEST schrieb Dmitry Baryshkov:
> > > On Thu, 19 Oct 2023 at 14:42,
Hi Dmitry,
Am Sonntag, 22. Oktober 2023, 12:49:41 CEST schrieb Dmitry Baryshkov:
> On Thu, 19 Oct 2023 at 14:42, Alexander Stein
>
> wrote:
> > Hi,
> >
> > Am Donnerstag, 19. Oktober 2023, 13:19:51 CEST schrieb Dmitry Baryshkov:
> > > On Thu, 19 Oct
Hi Sandor,
Am Montag, 16. Oktober 2023, 05:05:54 CEST schrieb Sandor Yu:
> Hi Alexander,
>
> Thanks your comments,
>
> > Hi Sandor,
> >
> > thanks for the updated series.
> >
> > Am Freitag, 13. Oktober 2023, 05:24:20 CEST schrieb Sandor Yu:
> > > MHDP8546 mailbox access functions will be
Currently the output the following output is printed upon each interrupt:
tc358767 1-000f: GPIO0:
This spams the kernel log while debugging an IRQ storm from the bridge.
Only print the debug output if the GPIO hotplug event actually happened.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm
Hi,
this small series improves debugging the tc358767 driver by using dev_err_probe
for additional information (patch 1) and print IRQ debug output only if hotplug
status actually changed.
Best regards,
Alexander
Alexander Stein (2):
drm/bridge: tc358767: Use dev_err_probe
drm: bridge
The function calls preceding these returns can return -EPROBE_DEFER. So
use dev_err_probe to add some information to
/sys/kernel/debug/devices_deferred
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
While at it, also add missing register definitions. HDCP registers are
skipped as they are not named, range 0x0980 - 0x09ac.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 75 ++-
1 file changed, 74 insertions(+), 1 deletion(-)
diff --git
://lore.kernel.org/dri-devel/20230817075234.1075736-1-alexander.st...@ew.tq-group.com/T/#t
Alexander Stein (7):
drm: bridge: tc358767: Use regmap_access_table for writeable registers
drm: bridge: tc358767: Fix order of register defines
drm: bridge: tc358767: Add more registers to non-writeable range
drm
Using ranges it is easier to add more register where writing is not allowed,
especially for sequences of registers.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge
Use the register names from the datasheet. No functional change intended.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu
Sort the list by the starting address to ease adding new entries.
No functional change intended.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm
0x0510 is bigger than 0x50c, order them accordingly.
No functional change intended.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge
These registers might change their value without any host write operation.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index b56dd3861dc2a
This is the single register which clears its value upon read operation.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/tc358767.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index f1d9deabae39b
Hello,
I'm currently trying to get the TC9595 (tc358767.c) running on my imx93
platform. For probing the EDID/DPCD information I need to put the DSI lanes
into LP-11 (stop) state.
For this I was trying to call drm_atomic_bridge_chain_pre_enable() inside
tc_connector_get_modes(), if bridge is
Am Montag, 21. August 2023, 19:14:39 CEST schrieb Rob Herring:
> On Thu, 10 Aug 2023 16:44:49 +0200, Alexander Stein wrote:
> > MAC address can be provided by a nvmem-cell, thus allow referencing a
> > source for the address. Fixes the warning:
> > arch/arm/boot/dts/nx
@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
Signed-off-by: Alexander Stein
---
Changes in v2:
* Adjust the indentation
Considering Laurent's input IMHO -517 should not occur when using component
framework, e.g. drivers/gpu/drm/mcde/mcde_drv.c. This should warrant to only
print
Hi Tomi,
Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen:
> These two patches are needed to make tc358767 work in the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector.
>
> I have tested this with TI AM654 EVM with a tc358767 add-on card
> connected to
Hi Lucas,
Am Mittwoch, 6. April 2022, 18:01:22 CEST schrieb Lucas Stach:
> This adds the DT nodes for all the peripherals that make up the
> HDMI display pipeline.
>
> Signed-off-by: Lucas Stach
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 80 +++
> 1 file changed,
Hi Marco,
Am Montag, 30. Mai 2022, 17:05:48 CEST schrieb Marco Felsch:
> The bridge device can now also be enabled/disabled by an external reset
> controller. So the device now supports either enable/disable by simple
> GPIO or by an Reset-Controller.
>
> Signed-off-by: Marco Felsch
> ---
>
ous LCDIF
> variants. The new LCDIFv3 also supports 36bit address space.
>
> Add a separate driver which is really a fork of MXSFB driver with the
> i.MX8MP LCDIF variant handling filled in.
>
> Signed-off-by: Marek Vasut
> Cc: Alexander Stein
> Cc: Laurent Pinchart
> Cc: Luca
Am Dienstag, 24. Mai 2022, 09:29:43 CEST schrieb Marek Vasut:
> On 5/24/22 09:09, Alexander Stein wrote:
> > Hi Marek,
>
> Hi,
>
> > Am Donnerstag, 19. Mai 2022, 13:48:49 CEST schrieb Marek Vasut:
> >> Add support for i.MX8MP LCDIF variant. This is called LCDIFv3
Hi Marek,
Am Dienstag, 24. Mai 2022, 09:29:43 CEST schrieb Marek Vasut:
> On 5/24/22 09:09, Alexander Stein wrote:
> > Hi Marek,
>
> Hi,
>
> > Am Donnerstag, 19. Mai 2022, 13:48:49 CEST schrieb Marek Vasut:
> >> Add support for i.MX8MP LCDI
gt; variants. The new LCDIFv3 also supports 36bit address space.
>
> Add a separate driver which is really a fork of MXSFB driver with the
> i.MX8MP LCDIF variant handling filled in.
>
> Tested-by: Alexander Stein
> Tested-by: Martyn Welch
> Signed-off-by: Marek Vasut
> Cc: Ale
Add more warning/debug messages during probe. E.g. a single -EPROBE_DEFER
might have several causes, these messages help finding the origin.
Signed-off-by: Alexander Stein
---
* New in v2
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
There is no need to require non-sleeping GPIO access. Silence the
WARN_ON() if GPIO is using e.g. I2C expanders.
Signed-off-by: Alexander Stein
---
Change in v2:
* None
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
: Could not find backlight
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/panel/panel-simple.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4a2e580a2f7b..8fb1c563c96a 100644
Am Donnerstag, 9. Juni 2022, 08:49:26 CEST schrieb Liu Ying:
> This patch adds a helper to support LDB drm bridge drivers for
> i.MX SoCs. Helper functions supported by this helper should
> implement common logics for all LDB modules embedded in i.MX SoCs.
>
> Tested-by: Marcel Ziswiler #
Hi,
Am Freitag, 10. Juni 2022, 05:01:21 CEST schrieb Liu Ying:
> > reading this I got reminded of fsl-ldb [1], which is accepted
> > already. At a
> > first glance reading the RM the LDB peripheral are similar, although
> > not
> > identical. Is it worth merging them into one driver (at some
-mipi-dsim
>
> Patch 0013: add i.MX8MM DSIM support
>
> Tested in Engicam i.Core MX8M Mini SoM.
>
> Anyone interested, please have a look on this repo [2]
>
> [2] https://github.com/openedev/kernel/tree/imx8mm-dsi-v2
I suspect you meant https://github.com/openedev/kernel/t
Hi Marek,
Am Freitag, 6. Mai 2022, 10:57:05 CEST schrieb Marek Szyprowski:
> Hi Alexander,
>
> On 05.05.2022 13:55, Alexander Stein wrote:
> > Am Donnerstag, 5. Mai 2022, 09:38:48 CEST schrieb Jagan Teki:
> >> On Thu, May 5, 2022 at 12:57 PM Alexander Stein
> >>
Hi Lucas,
Am Freitag, 6. Mai 2022, 20:10:25 CEST schrieb Lucas Stach:
> second round of the i.MX8MP HDMI work. Still not split up into proper
> parts for merging through the various trees this needs to go into, but
> should make it easy for people to test.
>
> I've worked in the feedback I got
Hello Jagan,
thanks for the quick response.
Am Donnerstag, 5. Mai 2022, 09:38:48 CEST schrieb Jagan Teki:
> On Thu, May 5, 2022 at 12:57 PM Alexander Stein
>
> wrote:
> > Hello Jagan,
> >
> > thanks for the second version of this patchset.
> >
> >
1 - 100 of 297 matches
Mail list logo
