lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2117643.K71DO8KEF6@diego>
Date: Tue, 10 Dec 2024 11:01:34 +0100
From: Heiko Stübner <heiko@...ech.de>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
 Andy Yan <andyshrk@....com>
Cc: Daniel Semkowicz <dse@...umatec.com>,
 Diederik de Haas <didi.debian@...ow.org>, andy.yan@...k-chips.com,
 Laurent.pinchart@...asonboard.com, andrzej.hajda@...el.com,
 conor+dt@...nel.org, devicetree@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, jernej.skrabec@...il.com, jonas@...boo.se,
 krzk+dt@...nel.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
 maarten.lankhorst@...ux.intel.com, mripard@...nel.org,
 neil.armstrong@...aro.org, quentin.schulz@...rry.de, rfoss@...nel.org,
 robh@...nel.org, tzimmermann@...e.de
Subject:
 Re: [PATCH v3 0/3] drm/rockchip: Add driver for the new DSI2 controller

Am Dienstag, 10. Dezember 2024, 02:54:09 CET schrieb Andy Yan:
> 
> Hi Dmitry,
> 
> 在 2024-12-10 09:45:11,"Dmitry Baryshkov" <dmitry.baryshkov@...aro.org> 写道:
> >On Tue, 10 Dec 2024 at 03:22, Andy Yan <andyshrk@....com> wrote:
> >>
> >>
> >> Hi Dmitry,
> >>
> >> 在 2024-12-10 09:01:38,"Dmitry Baryshkov" <dmitry.baryshkov@...aro.org> 写道:
> >> >On Tue, Dec 10, 2024 at 08:50:51AM +0800, Andy Yan wrote:
> >> >>
> >> >>
> >> >> Hi,
> >> >>
> >> >> At 2024-12-10 07:12:26, "Heiko Stübner" <heiko@...ech.de> wrote:
> >> >> >Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas:
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote:
> >> >> >> > On 03.12.24 21:54, Heiko Stuebner wrote:
> >> >> >> > > This series adds a bridge and glue driver for the DSI2 controller found
> >> >> >> > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block.
> >> >> >> > >
> >> >> >> >
> >> >> >> > I did more tests with different LVDS displays. I tested following
> >> >> >> > configurations with DSI/LVDS bridge:
> >> >> >> > - 1024x600@...01
> >> >> >> > - 1024x768@...02
> >> >> >> > - 1280x800@...07
> >> >> >> > - 1366x768@...06
> >> >> >> >
> >> >> >> > All of them worked without issues, except 1366x768.
> >> >> >> > With this resolution, video is blurry, and offset incorrectly
> >> >> >> > to the left. There are also repeating errors on the console:
> >> >> >> >
> >> >> >> >   rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3
> >> >> >> >
> >> >> >> > In correct operation with other resolutions, there is no error.
> >> >> >> > I am not sure if this is a problem in your series or rather in VOP2
> >> >> >> > driver.
> >> >> >
> >> >> >This really sounds like something is wrong on the vop side.
> >> >> >The interrupt is part of the vop, the divisable by 4 things likely too.
> >> >>
> >> >> This is a hardware limitation on vop side:
> >> >> The horizontal resolution must be 4 pixel aligned.
> >> >
> >> >Then mode_valid() and atomic_check() must reject modes that don't fit.
> >>
> >> We round down to 4 pixel aligned in mode_fixup in our bsp kernel,
> >
> >What is meant by the "bsp kernel" here? I don't see it being present
> 
> bsp kernel means downstream vendor kernel.
> 
> >in the mainline kernel. So, if the mode is unsupported, it should be
> 
> Will it be acceptable to add this round down in the mainline mode_fixup?

personally I'd like that.

I.e. the thing in the examoke above is an LVDS display, so has essentially
fixed resolution. So adapting the resolution may or may not be possible
(some for DSI or whatever) .

Doing that rounding-down AND emitting a dev_warn about that fact would
be preferrable to me personally, though I don't know if there is some
different precedent in other parts of DRM.


Heiko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ