On Sat, 2021-08-28 at 11:38 +0200, Mike Galbraith wrote:
> Enabling kasan or kcsan in my GTX-980 equipped box will in fairly short
> order...
Correction: kasan does NOT reproduce on demand. My bottom line remains
the same though, before enabling, either fix it, or evict it, lest it
take testing c
Hi PAul,
On Sat, Aug 28, 2021 at 12:26:39PM +0100, Paul Cercueil wrote:
> Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
> interface.
>
> Signed-off-by: Paul Cercueil
> ---
> .../bindings/display/panel/auo
Hi Paul & Christophe,
On Sat, Aug 28, 2021 at 12:26:40PM +0100, Paul Cercueil wrote:
> From: Christophe Branchereau
>
> Add driver for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> 24-bit TFT LCD with non-square pixels and a delta-RGB 8-bit interface.
I had expected a:
Co-developed-by:
On Sat, 28 Aug 2021 12:26:39 +0100, Paul Cercueil wrote:
> Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
> interface.
>
> Signed-off-by: Paul Cercueil
> ---
> .../bindings/display/panel/auo,a030jtn01.yaml
Minor typofix noticed when reading the KMS documentation.
Signed-off-by: Alyssa Rosenzweig
---
include/drm/drm_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index fed97e35626f..0c1102dc4d88 100644
--- a/include/drm/d
From: Colin Ian King
Pointer sink is being inintialized with a value that is never read,
it is later being re-assigned a new value. Remove the redundant
initialization.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2
Pushed to drm-misc-next, thanks!
Hi Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
next-20210827]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master drm/drm-next
v5.14-rc7]
[If y
All DSI PHY/PLL drivers were referencing their VCO parent clock by a
global name, most of which don't exist or have been renamed. These
clock drivers seem to function fine without that except the 14nm driver
for the sdm6xx [1].
At the same time all DTs provide a "ref" clock as per the requirement
Hi,
On Sun, 29 Aug 2021 at 23:30, Marijn Suijten
wrote:
>
> All DSI PHY/PLL drivers were referencing their VCO parent clock by a
> global name, most of which don't exist or have been renamed. These
> clock drivers seem to function fine without that except the 14nm driver
> for the sdm6xx [1].
>
Hi Dmitry,
On 8/29/21 10:39 PM, Dmitry Baryshkov wrote:
Hi,
On Sun, 29 Aug 2021 at 23:30, Marijn Suijten
wrote:
All DSI PHY/PLL drivers were referencing their VCO parent clock by a
global name, most of which don't exist or have been renamed. These
clock drivers seem to function fine without
On 7/13/21 10:16 PM, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:3dbdb38e Merge branch 'for-5.14' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1323c40230
kernel config: https://syzkaller.appspot
On Mon, 30 Aug 2021 at 00:53, Marijn Suijten
wrote:
>
> Hi Dmitry,
>
> On 8/29/21 10:39 PM, Dmitry Baryshkov wrote:
> > Hi,
> >
> > On Sun, 29 Aug 2021 at 23:30, Marijn Suijten
> > wrote:
> >>
> >> All DSI PHY/PLL drivers were referencing their VCO parent clock by a
> >> global name, most of whic
I've just been talking with Ben about nouveau having some issues since
this path,
ttm_resource can be subclassed by drivers, and the code below that
copies ttm_resources around pretty much seems to destroy that.
> + struct ttm_resource *src_mem = &bo->mem;
> + struct ttm_resource_man
On 8/29/21 7:27 PM, Tetsuo Handa wrote:
On 2021/08/30 9:24, Randy Dunlap wrote:
Note that yres_virtual is set to 0x1000. Is there no practical limit
(hence limit check) that can be used here?
Also, in vga16fb_check_var(), beginning at line 404:
404 if (yres > vyres)
405
From: Guangming Cao
When mapping the memory represented by a dma-buf into a device's
address space, it might be desireable to map the memory with
certain DMA attributes. Thus, introduce the dma_mapping_attrs
field in the dma_buf_attachment structure so that when
the memory is mapped with dma_buf_
On 2021/08/30 9:24, Randy Dunlap wrote:
> Note that yres_virtual is set to 0x1000. Is there no practical limit
> (hence limit check) that can be used here?
>
> Also, in vga16fb_check_var(), beginning at line 404:
>
> 404 if (yres > vyres)
> 405 vyres = yres;
> 406
Hi Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
next-20210827]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.14]
[If your p
[AMD Official Use Only]
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Cai
> Huoqing
> Sent: Saturday, August 28, 2021 4:41 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@linux.ie; dan...@ffwll.ch
> Cc: amd-...@lists.freedesktop.org
On Mon, Aug 30, 2021 at 11:30:23AM +0800, tcs.ker...@gmail.com wrote:
> From: Haimin Zhang
>
> yres and vyres can be controlled by user mode parameters, and cause
> p->vrows to become a negative value. While this value be passed to real_y
> function, the ypos will be out of screen range.This is a
Am 30.08.21 um 03:54 schrieb Dave Airlie:
I've just been talking with Ben about nouveau having some issues since
this path,
ttm_resource can be subclassed by drivers, and the code below that
copies ttm_resources around pretty much seems to destroy that.
+ struct ttm_resource *src_mem =
Am 27.08.21 um 22:23 schrieb Daniel Vetter:
On Fri, Aug 27, 2021 at 11:07:58AM +0200, Christian König wrote:
Am 26.08.21 um 10:55 schrieb Daniel Vetter:
On Tue, Aug 24, 2021 at 10:12:24AM +0200, Christian König wrote:
Just a gentle ping. Daniel any more comments on this?
Still haven't seen a
Compared to v3, remove the "//9A" and modify boe_panel_prepare timing in
drm/panel: boe-tv101wum-nl6
- _INIT_DCS_CMD(0x5A, 0xBA), //9A
+ _INIT_DCS_CMD(0x5A, 0xBA),
...
...
...
- usleep_range(1, 15000);
+ usleep_range(1, 11000);
Update commit message.
yangc
Add documentation for boe tv110c9m-ll3, inx hj110iz-01a panel.
Signed-off-by: yangcong
Reviewed-by: Douglas Anderson
---
.../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/boe,tv1
Support for these two panels fits in nicely with the existing
panel-boe-tv101wum-nl6 driver as suggested by Sam [1]. The main things
we needed to handle were:
a) These panels need slightly longer delays in two places. Since these
new delays aren't much longer, let's just unconditionally increase
th
The auo,b101uan08.3 panel (already supported by this driver) has
a 3.3V rail that needs to be turned on. For previous users of
this panel this voltage was directly output by pmic. On a new
user (the not-yet-upstream sc7180-trogdor-mrbland board) we need
to turn the 3.3V rail on. Add support in the
26 matches
Mail list logo
