The driver was compile-tested then rebased on drm-misc-next, and not
compile-tested after the rebase; unfortunately the driver didn't compile
anymore when it hit drm-misc-next.
Fixes: 49956b505c53 ("drm/panel: Add panel driver for NewVision NV3052C based
LCDs")
Cc: Christophe Branchereau
Cc: kbu
git master
config: arm64-randconfig-r015-20220408
(https://download.01.org/0day-ci/archive/20220409/202204092137.3rrpn4hr-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/mak
Am 08.04.22 um 18:01 schrieb Matthew Auld:
Hi Christian,
We seem to be hitting a new issue in ttm_bo_move_sync_cleanup(), due
to passing a NULL fence, and I guess with some recent changes this is
now blowing up in at least dma_resv_add_fence(). Question is how
should we handle this? Should we ad
Am 08.04.22 um 23:12 schrieb Chia-I Wu:
In practice, trace_dma_fence_init is good enough and almost no driver
calls trace_dma_fence_emit. But this is still more correct in theory.
Well, the reason why basically no driver is calling this is because it
is pretty much deprecated.
We do have a
On Tue, 5 Apr 2022 10:23:16 -0400
Alex Deucher wrote:
> On Mon, Apr 4, 2022 at 3:39 PM Michele Ballabio
> wrote:
> >
> > On Mon, 4 Apr 2022 13:03:41 -0400
> > Alex Deucher wrote:
> >
> > > On Sun, Apr 3, 2022 at 10:19 AM Michele Ballabio
> > > wrote:
> > > >
> > > > Hi,
> > > > I've hi
On 08/04/2022 23:02, Bjorn Andersson wrote:
> Add an optional reference to the MDSS_CORE reset, which when specified
> can be used by the implementation to reset the hardware blocks.
>
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v2:
> - None
>
Acked-by: Krzysztof Kozlowski
Bes
On 08/04/2022 23:08, Bjorn Andersson wrote:
> Add an optional reference to the MDSS_CORE reset, which when specified
> can be used by the implementation to reset the hardware blocks.
>
> Signed-off-by: Bjorn Andersson
> ---
>
> Resending these two patches again as I put "v2" in the subject, even
The only use of the global variables in r600_blit_shaders.c
were in the old drivers/gpu/drm/radeon/r600_blit.c
This file was removed in
commit 8333f607a631 ("drm/radeon: remove UMS support")
So remove the r600_blit_shaders.[c|h] files
Signed-off-by: Tom Rix
---
drivers/gpu/drm/radeon/Makefile
TWIMC: this mail is primarily send for documentation purposes and for
regzbot, my Linux kernel regression tracking bot. These mails usually
contain '#forregzbot' in the subject, to make them easy to spot and filter.
On 09.04.22 18:28, Michele Ballabio wrote:
> On Tue, 5 Apr 2022 10:23:16 -0400
> A
On Sat, Apr 9, 2022 at 7:33 AM Christian König wrote:
>
> Am 08.04.22 um 23:12 schrieb Chia-I Wu:
> > In practice, trace_dma_fence_init is good enough and almost no driver
> > calls trace_dma_fence_emit. But this is still more correct in theory.
>
> Well, the reason why basically no driver is cal
When the CMM is enabled, the HDSE offset is further adjusted to
compensate for consumed pixels.
Explain this further, with an extra comment at the point the offset is
adjusted.
Suggested-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 +
1
Hi,
today i tested Linux 5.18-rc1 on my Raspberry Pi 400 connected to my
HDMI display (multi_v7_defconfig + CONFIG_ARM_LPAE, firmware:
2021-01-08T14:31:16) and i'm getting these strange errors from
raspberrypi-firmware driver / vc4 during boot:
[ 13.094733] fb0: switching to vc4 from simpl
Hi Phil,
Am 09.04.22 um 22:03 schrieb Phil Elwell:
You know the drill, Stefan - what's in your config.txt?
sure. Everything commented out.
Regards
Phil
On Sat, 9 Apr 2022, 20:26 Stefan Wahren, wrote:
Hi,
today i tested Linux 5.18-rc1 on my Raspberry Pi 400 connected to my
H
The LCDIF controller as present in i.MX28/i.MX6SX/i.MX8M Mini/Nano has
CRC_STAT register, which contains CRC32 of the frame as it was clocked
out of the DPI interface of the LCDIF. This is most likely meant as a
functional safety feature.
Unfortunately, there is zero documentation on how the CRC32
Am 09.04.22 um 21:25 schrieb Stefan Wahren:
Hi,
today i tested Linux 5.18-rc1 on my Raspberry Pi 400 connected to my
HDMI display (multi_v7_defconfig + CONFIG_ARM_LPAE, firmware:
2021-01-08T14:31:16) and i'm getting these strange errors from
raspberrypi-firmware driver / vc4 during boot:
[
Christian König in fact the compiler will very often replace {0} with
a memset call. I don't see a problem using {0} for local arrays with
primitive types.
There should also be no problem with memory alignment. Because the
compiler understands it. Using sizeof is also not a good idea.
More often ev
Christian König, Simon Ser In fact, the code looks strange, we return
the return code, but for some reason we also write false and 0. In my
opinion, the caller should do this.
Of course, you are right, but I look from the position that nothing
should fall in the user system. There may be strange er
You know the drill, Stefan - what's in your config.txt?
Phil
On Sat, 9 Apr 2022, 20:26 Stefan Wahren, wrote:
> Hi,
>
> today i tested Linux 5.18-rc1 on my Raspberry Pi 400 connected to my
> HDMI display (multi_v7_defconfig + CONFIG_ARM_LPAE, firmware:
> 2021-01-08T14:31:16) and i'm getting thes
18 matches
Mail list logo
