Commit 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers")
broke console because there is no damage handling in fb_sys_write()
unlike we have in drm_fb_helper_sys_write().
Let's fix the issue by adding FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS to
use with FB_DEFAULT_DEFERRED_OPS as suggested by T
The framebuffer console stopped updating with commit f231af498c29
("drm/fb-helper: Disconnect damage worker from update logic").
Let's fix the issue by implementing fb_dirty similar to what was done
with commit 039a72ce7e57 ("drm/i915/fbdev: Implement fb_dirty for intel
custom fb helper").
Fixes:
Here are two fixes for omapdrm console.
Regards,
Tony
Changes since v1:
- Add FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS to use with
FB_DEFAULT_DEFERRED_OPS as suggested by Thomas
Tony Lindgren (2):
drm/omapdrm: Fix console by implementing fb_dirty
drm/omapdrm: Fix console with deferred ops
dr
* Thomas Zimmermann [240220 10:42]:
> The changes below look good. You can test by instrumenting
> drm_fb_helper_deferred_io() with printk(). For testing, you can reduce the
> write-back frequency by setting helper->fbdefio.delay to a higher value. If
> you set it to HZ, it should only do a write-
The hs_rate and lp_rate may be used by the dsi host for timing
calculations. The tc358775 has a maximum bit rate of 1 Gbps/lane,
tc358765 has maximurate of 800 Mbps per lane.
Reviewed-by: Michael Walle
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 13 +
1 file
The tc358775 bridge is pin compatible with earlier tc358765 according to
the tc358774xbg_datasheet_en_20190118.pdf documentation. Compared to the
tc358765, the tc358775 supports a STBY GPIO and higher data rates.
The tc358765 has a register bit for video event mode vs video pulse mode.
We must set
Set pre_enable_prev_first to ensure the previous bridge is enabled
first.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Michael Walle
Tested-by: Michael Walle
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/br
Burst and low-power modes are supported both for tc358765 and tc358775.
Reviewed-by: Michael Walle
Tested-by: Michael Walle
Signed-off-by: Tony Lindgren
---
drivers/gpu/drm/bridge/tc358775.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
The current code assumes the data-lanes property is configured on the
DSI host side instead of the bridge side, and assumes DSI host endpoint 1.
Let's standardize on what the other bridge drivers are doing and parse the
data-lanes property for the bridge. Only if data-lanes property is not found,
From: Michael Walle
The stby pin is optional. It is only needed for power-up and down
sequencing. It is not needed, if the power rails cannot by dynamically
enabled.
Because the GPIO is now optional, remove the error message.
Signed-off-by: Michael Walle
Reviewed-by: Dmitry Baryshkov
Acked-by
From: Michael Walle
The bridge always uses 24bpp internally. Therefore, for jeida-18
mapping we need to discard the lowest two bits for each channel and thus
starting with LV_[RGB]2. jeida-24 has the same mapping but uses four
lanes instead of three, with the forth pair transmitting the lowest tw
The tc358765 is similar to tc358775. The tc358765 just an earlier version
of the hardware, and it's pin and register compatible with tc358775 for
most part.
>From the binding point of view the only difference is that the tc358765
does not have stdby-gpios.
Reviewed-by: Krzysztof Kozlowski
Signed
The device uses a clock lane, and 1 to 4 DSI data lanes. Let's add the
data-lanes property starting at 1 similar to what the other bridge
bindings are doing.
Let's also drop the data-lanes properties in the example for the DSI host
controller to avoid confusion. The configuration of the DSI host d
From: Michael Walle
For a normal operation, the stby GPIO is not needed.
The reset pin is required because once the PPI (PHY protocol interface)
is started, it can only be stopped by asserting the reset pin.
Signed-off-by: Michael Walle
Acked-by: Krzysztof Kozlowski
[t...@atomide.com: dropped
Hi all,
Here are v5 patches to improve tc358775 driver and add support for
tc358765.
Regards,
Tony
Changes since v4:
- Update devicetree binding to move allOf after required block
as noted by Krzysztof
Changes since v3:
- Fixed dts binding warnings
Changes since v2:
- Only make stby-gpios
* Krzysztof Kozlowski [240215 18:43]:
> If there is going to be new version, please put allOf: block after
> required: block.
OK will post v5 set.
> Anyway:
>
> Reviewed-by: Krzysztof Kozlowski
Thanks,
Tony
On Thu, 22 Feb 2024 at 17:55, Abel Vesa wrote:
>
> Add the X1E80100 to the list of compatibles and document the is-edp
> flag. The controllers are expected to operate in DP mode by default,
> and this flag can be used to select eDP mode.
>
> Signed-off-by: Abel Vesa
Rob, Krzysztof, Connor, graci
On 24/02/2024 1:32, Carl Vanderlip wrote:
>
> On 2/20/2024 8:01 AM, Oded Gabbay wrote:
>> From: Ofir Bitton
>>
>> Today we read PCI VENDOR-ID in order to make sure PCI link is
>> healthy. Apparently the VENDOR-ID might be stored on host and
>> hence, when we read it we might not access the PCI bu
From: Ondrej Jirman
Identical configurations of planes can lead to different (and wrong)
layer -> pipe routing at HW level, depending on the order of atomic
plane changes.
For example:
- Layer 1 is configured to zpos 0 and thus uses pipe 0. No other layer
is enabled. This is a typical situati
From: Ondrej Jirman
These will be needed later on when we move layer configuration to
crtc update.
Signed-off-by: Ondrej Jirman
Reviewed-by: Maxime Ripard
Reviewed-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +++-
drivers/gpu/drm/sun4i/sun4i_crtc.c| 2 +-
drivers/g
From: Ondrej Jirman
This series refactors blender setup from individual planes to a common
place where it can be performed at once and is easier to reason about.
In the process this fixes a few bugs that allowed blender pipes to be
disabled while corresponding DRM planes were requested to be ena
From: Ondrej Jirman
These structs are identical, use a single struct to represent private
data for the DRM plane. This is a preparation for configuring layer
routing from the CRTC (mixer) instead of current approach of setting
up routing from individual layer's atomic_update callback.
Signed-off
Hi, Manikandan,
On 21.02.2024 07:35, Manikandan Muralidharan wrote:
> This patch series aims to add support for XLCDC IP of sam9x7 SoC family
> to the DRM subsystem.XLCDC IP has additional registers and new
> configuration bits compared to the existing register set of HLCDC IP.
> The new compatibl
On 21.02.2024 07:35, Manikandan Muralidharan wrote:
> Add XLCDC specific driver ops and is_xlcdc flag to separate the
> functionality and to access the controller registers.
> HEO scaling, window resampling, Alpha blending, YUV-to-RGB
> conversion in XLCDC is derived and handled using additional
On 21.02.2024 07:35, Manikandan Muralidharan wrote:
> Add support for the following DPI mode if the encoder type
> is DSI as per the XLCDC IP datasheet:
> - 16BPPCFG1
> - 16BPPCFG2
> - 16BPPCFG3
> - 18BPPCFG1
> - 18BPPCFG2
> - 24BPP
>
> Signed-off-by: Manikandan Muralidharan
> [durai.manicka..
On 21.02.2024 07:35, Manikandan Muralidharan wrote:
> Add LCD IP specific ops in driver data to differentiate
> HLCDC and XLCDC code within the atmel-hlcdc driver files.
> XLCDC in SAM9X7 has different sets of registers and additional
> configuration bits when compared to previous HLCDC IP. Read
From: Arnd Bergmann
This function does not build on 32-bit targets when the compiler
fails to reduce DIV_ROUND_UP() into a shift:
ld.lld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by xe_migrate.c
>>> drivers/gpu/drm/xe/xe_migrate.o:(pte_update_size) in archive
>>> v
From: Arnd Bergmann
clang complains about a nonsensical test on builds with a 32-bit phys_addr_t,
which means resizing will always fail:
drivers/gpu/drm/xe/xe_mmio.c:109:23: error: result of comparison of constant
4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is
alw
From: Arnd Bergmann
When the driver is built-in but the tests are in loadable modules,
the helpers don't actually get put into the driver:
ERROR: modpost: "xe_kunit_helper_alloc_xe_device"
[drivers/gpu/drm/xe/tests/xe_test.ko] undefined!
Change the Makefile to ensure they are always part of th
On 23/02/2024 22:21, Konrad Dybcio wrote:
> Add device tree bindings for graphics clock controller for Qualcomm
> Technology Inc's QCM2290 SoCs.
>
> Signed-off-by: Konrad Dybcio
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
30 matches
Mail list logo
