On Sat, Mar 28, 2020 at 7:49 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Sat, Mar 28, 2020 at 05:23:58PM +0100, Daniel Vetter wrote:
> > I'm thinking this is the warning that fired in the 0day report, but I
> > can't double-check yet since 0day didn't upload its source tree
> > anywhere I can
On Thu, Mar 26, 2020 at 10:09:58PM +0100, Wolfram Sang wrote:
> We are deprecating calls which return NULL in favor of new variants which
> return an ERR_PTR. Only build tested.
>
>
> Wolfram Sang (6):
> drm/amdgpu: convert to use i2c_new_client_device()
> drm/gma500: convert to use
Hi Harigovindan
On Fri, Mar 27, 2020 at 01:06:35PM +0530, Harigovindan P wrote:
> Add bindings for visionox rm69299 panel.
>
> Signed-off-by: Harigovindan P
> ---
>
> Changes in v2:
> - Removed unwanted properties from description.
> - Creating source files without execute
Hi Harigovindan
On Fri, Mar 27, 2020 at 01:06:34PM +0530, Harigovindan P wrote:
> Adding support for visionox rm69299 panel driver and adding bindings for the
> same panel.
>
> Harigovindan P (2):
> dt-bindings: display: add visionox rm69299 panel variant
> drm/panel: add support for
On Sat, Mar 28, 2020 at 03:36:40PM -0300, Fabio Estevam wrote:
> Commit 52120e8c7ae3 ("dt-bindings: display: fix panel warnings") removed
> the dsi unit name, but missed to remove the 'reg' property, which causes
> the following 'make dt_binding_check' warning:
>
>
On Sat, Mar 28, 2020 at 03:36:41PM -0300, Fabio Estevam wrote:
> Commit 52120e8c7ae3 ("dt-bindings: display: fix panel warnings") removed
> the dsi unit name, but missed to remove the 'reg' property, which causes
> the following 'make dt_binding_check' warning:
>
>
On Fri, Mar 20, 2020 at 12:21:34PM +0100, Pascal Roeleven wrote:
> Topwise Communication Co,. Ltd. is a company based in Shenzhen. They
> manufacture all kind of products but seem to be focusing on POS nowadays.
>
> Signed-off-by: Pascal Roeleven
Acked-by: Sam Ravnborg
> ---
>
On Fri, Mar 20, 2020 at 12:21:33PM +0100, Pascal Roeleven wrote:
> The KR070PE2T is a 7" panel with a resolution of 800x480.
>
> KR070PE2T is the marking present on the ribbon cable. As this panel is
> probably available under different brands, this marking will catch
> most devices.
>
> As I
Hi Pascal.
On Fri, Mar 20, 2020 at 12:21:32PM +0100, Pascal Roeleven wrote:
> Add the devicetree binding for Starry KR070PE2T
>
> Signed-off-by: Pascal Roeleven
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
>
Hi Daniel.
On Sat, Mar 28, 2020 at 05:23:58PM +0100, Daniel Vetter wrote:
> I'm thinking this is the warning that fired in the 0day report, but I
> can't double-check yet since 0day didn't upload its source tree
> anywhere I can check. And all the drivers I can easily test don't use
>
Commit 52120e8c7ae3 ("dt-bindings: display: fix panel warnings") removed
the dsi unit name, but missed to remove the 'reg' property, which causes
the following 'make dt_binding_check' warning:
Documentation/devicetree/bindings/display/panel/leadtek,ltk500hd1829.example.dts:17.5-29.11:
Warning
Commit 52120e8c7ae3 ("dt-bindings: display: fix panel warnings") removed
the dsi unit name, but missed to remove the 'reg' property, which causes
the following 'make dt_binding_check' warning:
Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.example.dts:17.5-29.11:
Warning
On Fri, Mar 27, 2020 at 6:31 PM Ruhl, Michael J
wrote:
> Is there an example of what the scatterlist would look like in this case?
>
> Does each SG entry always have the page and dma info? or could you have
> entries that have page information only, and entries that have dma info only?
>
> If the
Hi Qiujun
Thanks for looking into the sysbot bugs.
On Sat, Mar 28, 2020 at 11:15:10PM +0800, Qiujun Huang wrote:
> Add check for vc_cons[logo_shown].d, as it can be released by
> vt_ioctl(VT_DISALLOCATE).
>
> Reported-by: syzbot+732528bae351682f1...@syzkaller.appspotmail.com
> Signed-off-by:
On Sat, Mar 28, 2020 at 4:15 PM Qiujun Huang wrote:
> Add check for vc_cons[logo_shown].d, as it can be released by
> vt_ioctl(VT_DISALLOCATE).
Can you pls link to the syzbot report and distill the essence of the
crash/issue here in the commit message? As-is a bit unclear what's
going on. Patch
I'm thinking this is the warning that fired in the 0day report, but I
can't double-check yet since 0day didn't upload its source tree
anywhere I can check. And all the drivers I can easily test don't use
drm_dev_alloc anymore ...
Also if I'm correct supreme amounts of bad luck because usually
https://bugzilla.kernel.org/show_bug.cgi?id=204805
--- Comment #6 from ilkka.pr...@gmail.com ---
Again, seems to be fixed by this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c0fdf3302cb4f186c871684eac5c407a107e480
--
You are receiving this mail
Lyude Paul wrote a very good intro to vblank here:
https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.ca...@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27
Add this to the intro chapter in drm_vblank.c so others
can benefit from it too.
Signed-off-by: Sam Ravnborg
Fix following warnings:
drm_framebuffer.h:342: warning: Function parameter or member 'block_width' not
described in 'drm_afbc_framebuffer'
drm_framebuffer.h:342: warning: Function parameter or member 'block_height' not
described in 'drm_afbc_framebuffer'
Trivial spelling mistakes.
Fix following warning:
gpu_scheduler.h:103: warning: Function parameter or member 'priority' not
described in 'drm_sched_entity'
Signed-off-by: Sam Ravnborg
Cc: Nirmoy Das
Cc: David Airlie
Cc: Daniel Vetter
---
include/drm/gpu_scheduler.h | 1 +
1 file changed, 1 insertion(+)
diff --git
Lyude Paul wrote a nice intro to vblank in the following mail:
https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.ca...@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27
Reading this I managed to spot a glimmer of hope that I one
day would understand some of the fuzz
Add missing documentation to fix following warning:
panel.c:303: warning: Function parameter or member 'bridge' not described in
'drm_panel_bridge_connector'
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Boris Brezillon
Cc: Mihail Atanassov
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc:
Fix kernel-doc warnings for drm_dp_mst_port.fec_capable.
This fixed the following warning:
drm_dp_mst_helper.h:162: warning: Function parameter or member 'fec_capable'
not described in 'drm_dp_mst_port'
Signed-off-by: Sam Ravnborg
Cc: David Francis
Cc: Lyude Paul
Cc: Harry Wentland
Cc:
Document the callbacks:
drm_connector_helper_funcs.prepare_writeback_job
drm_connector_helper_funcs.cleanup_writeback_job
The documentation was pulled from the changelong introducing the
callbacks, originally written by Laurent.
Addign the missing documentation fixes the following
Applied to drm-misc-next.
On Sun, Mar 22, 2020 at 10:24 AM Qiang Yu wrote:
>
> Looks good for me, patch is:
> Reviewed-by: Qiang Yu
>
> Regards,
> Qiang
>
> On Fri, Mar 20, 2020 at 4:35 AM Martin Blumenstingl
> wrote:
> >
> > Most platforms with a Mali-400 or Mali-450 GPU also have support for
Quoting Jason A. Donenfeld (2020-03-28 00:04:22)
> It's not safe to just grab the FPU willy nilly without first checking to
> see if it's available. This patch adds the usual call to may_use_simd()
> and falls back to boring memcpy if it's not available.
These instructions do not use the fpu,
On Fri, Mar 27, 2020 at 05:21:26PM +0100, Marek Szyprowski wrote:
> Scatterlist elements contains both pages and DMA addresses, but one
> should not assume 1:1 relation between them. The sg->length is the size
> of the physical memory chunk described by the sg->page, while
> sg_dma_len(sg) is the
27 matches
Mail list logo
