Move the DPCD read and link setup steps to HPD IRQ handler to remove
an unnecessary dependency between .detect callback and the HPD IRQ
handler before registering it6505 as a DRM bridge. This is safe because
there is always a .detect call after each HPD IRQ handler triggered by
the
Originally, the it6505 relies on a short sleep in the IRQ handler and a
long sleep to make sure it6505->lane_swap and it6505->lane_count is
configured in it6505_extcon_work and it6505_detect, respectively.
Use completion and additional DPCD read to remove the unnecessary waits,
and use a
During device boot, the HPD interrupt could be triggered before the DRM
subsystem registers it6505 as a DRM bridge. In such cases, the driver
tries to access AUX channel and causes NULL pointer dereference.
Initializing the AUX channel earlier to prevent such error.
Fixes: b5c84a9edcd4
The main purpose of this series is to improve the synchronizations of
it6505 driver. The first two patches are required for the third one, but
they alone can be clean ups to the driver.
Changes in v2:
- Remove redundant spaces in it6505_detect
- Read sink count in it6505_irq_hpd
- Add the empty
From: allen chen
Add properties to restrict dp output data-lanes and clock.
Signed-off-by: Pin-Yen Lin
Signed-off-by: Allen Chen
---
.../bindings/display/bridge/ite,it6505.yaml | 43 +++
1 file changed, 43 insertions(+)
diff --git
From: allen chen
Add driver to read data-lanes and link-frequencies from dt property to
restrict output bandwidth.
Signed-off-by: Allen chen
Signed-off-by: Pin-yen Lin
---
drivers/gpu/drm/bridge/ite-it6505.c | 54 +++--
1 file changed, 51 insertions(+), 3 deletions(-)
This series let driver can read properties from dt to restrict dp output
bandwidth.
Changes in v3:
-Rename property name.
Changes in v4:
-Use data-lanes and link-frequencies instead of "ite,dp-output-data-lane-count"
and "ite,dp-output-max-pixel-clock-mhz".
allen chen (2):
dt-bindings:
On Thu, Oct 13, 2022 at 11:05:19AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 13.10.22 um 10:29 schrieb Jocelyn Falempe:
> > For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
> > or "signal out of range" on VGA display.
> > previous code had "m |= 0x80" which was changed to
> >
From: Dave Stevenson
The mapping is incorrect for RGB565_1X16 as it should be
DPI_FORMAT_18BIT_666_RGB_1 instead of DPI_FORMAT_18BIT_666_RGB_3.
Fixes: 08302c35b59d ("drm/vc4: Add DPI driver")
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 2 +-
From: Chris Morgan
Add the MEDIA_BUS_FMT_RGB565_1X24_CPADHI format used by the Geekworm
MZP280 panel for the Raspberry Pi.
Signed-off-by: Chris Morgan
Signed-off-by: Maxime Ripard
---
include/uapi/linux/media-bus-format.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Joerg Quinten
The VC4 DPI output can support multiple BGR666 variants, but they were
never added to the driver. Let's add the the support for those formats.
Signed-off-by: Joerg Quinten
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 6 ++
1 file changed, 6
From: Chris Morgan
The RGB565 format with padding over 24 bits
(MEDIA_BUS_FMT_RGB565_1X24_CPADHI) is supported by the vc4 DPI
controller as "mode 3". This is what the Geekworm MZP280 DPI display
uses, so let's add support for it in the DPI controller driver.
Reviewed-by: Dave Stevenson
From: Dave Stevenson
DPI hasn't really been used up until now, so the default has
been meaningless.
In theory we should be able to pass the desired format for the
adjacent bridge chip through, but framework seems to be missing
for that.
As the main device to use DPI is the VGA666 or Adafruit
From: Joerg Quinten
Add the BGR666 format MEDIA_BUS_FMT_BGR666_1X24_CPADHI supported by the
RaspberryPi.
Signed-off-by: Joerg Quinten
Signed-off-by: Maxime Ripard
---
include/uapi/linux/media-bus-format.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Joerg Quinten
Add the BGR666 format MEDIA_BUS_FMT_BGR666_1X18 supported by the
RaspberryPi.
Signed-off-by: Joerg Quinten
Signed-off-by: Maxime Ripard
---
include/uapi/linux/media-bus-format.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
/vc4_dpi.c | 16 +---
include/uapi/linux/media-bus-format.h | 5 -
2 files changed, 17 insertions(+), 4 deletions(-)
---
base-commit: c9b48b91e2fbb74fb981aa616a6ef3c78194077f
change-id: 20221013-rpi-dpi-improvements-c3d755531c39
Best regards,
--
Maxime Ripard
On 9/29/22 11:21, Maxime Ripard wrote:
> If our HSM clock has not been properly initialized, any register access
> will silently lock up the system.
>
> Let's check that this can't happen by adding a check for the rate before
> any register access, and error out otherwise.
>
> Link:
>
Hello Maxime,
On 9/29/22 11:21, Maxime Ripard wrote:
> This is a revert of commit fd5894fa2413 ("drm/vc4: hdmi: Remove clock
> rate initialization"), with the code slightly moved around.
>
> It turns out that we can't downright remove that code from the driver,
> since the Pi0-3 and Pi4 are in
On 13/10/2022 11:05, Thomas Zimmermann wrote:
Hi
Am 13.10.22 um 10:29 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
On 2022-10-12 16:03:06, Abhinav Kumar wrote:
>
>
> On 10/9/2022 11:50 AM, Marijn Suijten wrote:
> > As per the FIXME this code is entirely duplicate with what is already
> > provided inside drm_dsc_compute_rc_parameters(), and it is yet unknown
> > why this comment was put in place instead of
On 2022-10-12 16:08:07, Abhinav Kumar wrote:
>
>
> On 10/9/2022 11:51 AM, Marijn Suijten wrote:
> > According to the `/* bpc 8 */` comment below only values for a
> > bits_per_component of 8 are currently hardcoded in place. This is
> > further confirmed by downstream sources [1] containing
Hello Maxime,
On 9/2/22 16:41, Maxime Ripard wrote:
> The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In
> order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver
> will register a device matching the HDMI codec driver, and then register
> an ASoC card using
From: Dom Cobley
At least the 4096x2160@60Hz mode requires some overclocking that isn't
available by default, even if hdmi_enable_4kp60 is enabled.
Let's add some logic to detect whether we can satisfy the core clock
requirements for that mode, and prevent it from being used otherwise.
In order to support higher HDMI frequencies, users have to set the
hdmi_enable_4kp60 parameter in their config.txt file.
This will have the side-effect of raising the maximum of the core clock,
tied to the HVS, and managed by the HVS driver.
However, we are querying this in the HDMI driver by
Following the clock rate range improvements to the clock framework,
trying to set a disjoint range on a clock will now result in an error.
Thus, we can't set a minimum rate higher than the maximum reported by
the firmware, or clk_set_min_rate() will fail.
Thus we need to clamp the rate we are
The firmware allows to query for its clocks the operating range of a
given clock. We'll need this for some drivers (KMS, in particular) to
infer the state of some configuration options, so let's create a
function to do so.
Acked-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
In order to support higher HDMI frequencies, users have to set the
hdmi_enable_4kp60 parameter in their config.txt file.
We were detecting this so far by calling clk_round_rate() on the core
clock with the frequency we're supposed to run at when one of those
modes is enabled. Whether or not the
A significant number of RaspberryPi drivers using the firmware don't
have a phandle to it, so end up scanning the device tree to find a node
with the firmware compatible.
That code is duplicated everywhere, so let's introduce a helper instead.
Signed-off-by: Maxime Ripard
---
We'll need the clock IDs in more drivers than just the clock driver from
now on, so let's move them in the firmware header.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 18 --
include/soc/bcm2835/raspberrypi-firmware.h | 18 ++
2
Hi,
Those patches used to be part of a larger clock fixes series:
https://lore.kernel.org/linux-clk/20220715160014.2623107-1-max...@cerno.tech/
However, that series doesn't seem to be getting anywhere, so I've split out
these patches that fix a regression that has been there since 5.18 and that
Hi
Am 13.10.22 um 10:29 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
Tested on G200_SE_A rev 42
This line of code was
Hi Florian,
On Mon, Oct 10, 2022 at 12:07:22PM -0700, Florian Fainelli wrote:
> On 10/10/22 04:44, Maxime Ripard wrote:
> > Hi Florian,
> >
> > On Tue, Sep 20, 2022 at 02:50:19PM +0200, Maxime Ripard wrote:
> > > Those patches used to be part of a larger clock fixes series:
> > >
Test like i915_gem_mman_live_selftests/igt_mmap_migrate can cause
dmesg spamming. Use ratelimit api to reduce log rate.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7038
Cc: Matthew Auld
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
1 file
Add a function for ratelimitted debug print.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Nirmoy Das
---
include/drm/drm_print.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/drm/drm_print.h
Hi Justin,
On Wed, 12 Oct 2022 at 20:12, Justin Green wrote:
> @@ -226,6 +249,32 @@ int mtk_ovl_layer_check(struct device *dev, unsigned
> int idx,
> if (state->fb->format->is_yuv && rotation != 0)
> return -EINVAL;
>
> + if (state->fb->modifier) {
>
Please spell
On Tue, 11 Oct 2022 at 23:11, Abhinav Kumar wrote:
>
> adv7533 bridge tries to dynamically switch lanes based on the
> mode by detaching and attaching the mipi dsi device.
>
> This approach is incorrect because this method of dynamic switch of
> detaching and attaching the mipi dsi device also
Hi Noralf,
On Sat, Oct 01, 2022 at 02:52:06PM +0200, Noralf Trønnes wrote:
> Den 29.09.2022 18.31, skrev Maxime Ripard:
> > Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
> > 625-lines modes in their drivers.
> >
> > Since those modes are fairly standard, and that we'll need
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
Tested on G200_SE_A rev 42
This line of code was moved to another file with
commit 85397f6bc4ff
On Thu, 13 Oct 2022, Gwan-gyeong Mun wrote:
> diff --git a/lib/overflow_kunit.c b/lib/overflow_kunit.c
> index 0d98c9bc75da..44da9d190057 100644
> --- a/lib/overflow_kunit.c
> +++ b/lib/overflow_kunit.c
> @@ -16,6 +16,11 @@
> #include
> #include
>
> +/* We're expecting to do a lot of
在 2022/10/13 14:39, Cai Huoqing 写道:
On 27 9月 22 13:38:47, Yuan Can wrote:
After commit 64ff18911878("drm/omap: Enable COLOR_ENCODING and COLOR_RANGE
Hi yuan,
This is not a valid Fixes: tag.
Add to your ~/.gitconfig and add:
[pretty]
fixes = Fixes: %h (\"%s\")
You can then do
git
Il 12/10/22 21:12, Justin Green ha scritto:
Tested on MT8195 and confirmed both correct video output and improved DRAM
bandwidth performance.
v3:
* Replaced pitch bitshift math with union based approach.
* Refactored overlay register writes to shared code between non-AFBC and
AFBC.
* Minor
Hello,
On 10/12/22 16:27, Michal Suchánek wrote:
[...]
>>
>> If you are using the framebuffer code from vga.c, I would guess that
>> that you can run a big-endian kernel with qemu-system-ppc64,
>> or a little-endian kernel with qemu-system-ppc64le and get the
>> correct colors, while running a
On 10/11/22 18:51, Javier Martinez Canillas wrote:
> Add a helper function and make drivers that have the same logic in their
> struct drm_crtc_helper_funcs .atomic_check handler to use this instead.
>
> Patch #1, #2 and #3 are just cleanups for the mgag200, simpledrm and
> ssd130x drivers
On 30.09.2022 17:45, Matt Roper wrote:
> Rather than treating multicast registers as 'i915_reg_t' let's define
> them as a completely new type. This will allow the compiler to help us
> make sure we're using multicast-aware functions to operate on multicast
> registers.
>
> This plan does break
From: Kees Cook
Implement a robust overflows_type() macro to test if a variable or
constant value would overflow another variable or type. This can be
used as a constant expression for static_assert() (which requires a
constant expression[1][2]) when used on constant values. This must be
On 27 9月 22 13:38:47, Yuan Can wrote:
> After commit 64ff18911878("drm/omap: Enable COLOR_ENCODING and COLOR_RANGE
Hi yuan,
This is not a valid Fixes: tag.
Add to your ~/.gitconfig and add:
[pretty]
fixes = Fixes: %h (\"%s\")
You can then do
git log --pretty=fixes 64ff18911878
and
On 10/12/22 21:18, Kees Cook wrote:
Add MIPS to fb_* helpers list for iomem addresses. This silences Sparse
warnings about lacking __iomem address space casts:
drivers/video/fbdev/pvr2fb.c:800:9: sparse: sparse: incorrect type in argument
1 (different address spaces)
101 - 147 of 147 matches
Mail list logo
