Bernard Zhao 於 2020年10月13日 週二 下午4:55寫道：
>
> Function mtk_hdmi_aud_set_input always return 0, no need to
> keep the return value. Functions mtk_hdmi_aud_enable_packet &
> mtk_hdmi_aud_on_off_hw_ncts are the same, these two functions
> just call next functions. Maybe it`s a bit better to just call
The heap-helpers code was not as generic as initially hoped
and it is now not being used, so remove it from the tree.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc:
Since the heap-helpers logic ended up not being as generic as
hoped, move the heap-helpers dma_buf_ops implementations into
the cma_heap directly.
This will allow us to remove the heap_helpers code in a following
patch.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc:
In preparation for some patches to optmize the system
heap code, rework the dmabuf exporter to utilize sgtables rather
then pageslists for tracking the associated pages.
This will allow for large order page allocations, as well as
more efficient page pooling.
In doing so, the system heap stops
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.e...@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices,
Keep track of the heap device struct.
This will be useful for special DMA allocations
and actions.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc:
While the system heap can return non-contiguous pages,
try to allocate larger order pages if possible.
This will allow slight performance gains and make implementing
page pooling easier.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren
Hey All,
So this is another revision of my patch series to performance
optimizations to the dma-buf system heap.
This series reworks the system heap to use sgtables, and then
consolidates the pagelist method from the heap-helpers into the
CMA heap. After which the heap-helpers logic is removed
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 5:18 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 5:28 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATCH
On Fri, Oct 16, 2020 at 12:03 PM John Stultz wrote:
> On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote:
> > On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote:
> > > @@ -426,6 +487,16 @@ static int system_heap_create(void)
> > > if (IS_ERR(sys_heap))
> > > return
On Wed, Sep 16, 2020 at 10:19 AM Lyude Paul wrote:
>
> Since we're about to start adding support for Intel's magic HDR
> backlight interface over DPCD, we need to ensure we're properly
> programming this field so that Intel specific sink services are exposed.
> Otherwise, 0x300-0x3ff will just
From: Colin Ian King
Don't populate const arrays on the stack but instead make them
static. Makes the object code smaller by 7 bytes.
Before:
textdata bss dec hex filename
1040418284 0 112325 1b6c5 drm/nouveau/nvkm/subdev/bios/init.o
After:
textdata
Hi Zhang Qilong
On Wed, Sep 16, 2020 at 07:13:53PM +0800, Qilong Zhang wrote:
> Use the devm_platform_ioremap_resource_byname() helper instead of
> calling platform_get_resource_byname() and devm_ioremap_resource()
> separately.
>
> Signed-off-by: Zhang Qilong
Thanks, applied to
Hi Qinglang Miao
On Wed, Sep 16, 2020 at 02:21:23PM +0800, Qinglang Miao wrote:
> Use for_each_child_of_node() macro instead of open coding it.
>
> Signed-off-by: Qinglang Miao
Applied to drm-misc-next.
Sam
> ---
> drivers/video/fbdev/nvidia/nv_of.c | 3 +--
> 1 file changed, 1
Hi Xin Ji
On Fri, Sep 18, 2020 at 06:18:19PM +0800, Xin Ji wrote:
> Hi all,
>
> The following series add support for the Slimport ANX7625 transmitter, a
> ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable
> device.
Thanks for all the iterations on this series. Driver looks
On Sat, Oct 17, 2020 at 07:01:38AM +1000, David Airlie wrote:
> On Fri, Oct 16, 2020 at 6:03 PM KuoHsiang Chou
> wrote:
> >
> > The patch is upstreamed
> > 1. For RHEL7.x, because its native kernel is suggested to update
> >from 3.10 to 4.9 on 2 ODM's platform.
> > 2. For AST2600.
> > 3. For
Hi Qinglang Miao
On Mon, Sep 21, 2020 at 09:10:52PM +0800, Qinglang Miao wrote:
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao
Applied this and the following patch to drm-misc-next.
Note: I did not touch the drm/* patches, I expect someone else to pick
them up. As they are
Hi Qinglang Miao
On Mon, Sep 21, 2020 at 09:10:51PM +0800, Qinglang Miao wrote:
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao
I dropped the changes to gpio-cs5535.c when I applied this patch to
drm-misc-next. It looks like an accident that it was included here.
Hi Liu Shixin
On Mon, Sep 21, 2020 at 04:24:43PM +0800, Liu Shixin wrote:
> Simplify the return expression.
>
> Signed-off-by: Liu Shixin
Thanks.
Applied this and the following two patches to drm-misc-next.
They will appear in -next in a few weeks.
Sam
> ---
>
On Mon, Sep 21, 2020 at 09:10:49PM +0800, Qinglang Miao wrote:
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao
Thanks, applied to drm-misc-next.
Sam
> ---
> .../fbdev/omap2/omapfb/displays/connector-analog-tv.c | 7 +--
> 1 file changed, 1 insertion(+), 6
Hi Biju, Laurent
On Tue, Sep 22, 2020 at 01:55:26PM +0300, Laurent Pinchart wrote:
> From: Biju Das
>
> Add the support for enabling optional regulator that may be used as VCC
> source.
>
> Signed-off-by: Biju Das
> Reviewed-by: Laurent Pinchart
> [Replaced 'error' variable with 'ret']
>
On Fri, Oct 16, 2020 at 6:03 PM KuoHsiang Chou
wrote:
>
> The patch is upstreamed
> 1. For RHEL7.x, because its native kernel is suggested to update
>from 3.10 to 4.9 on 2 ODM's platform.
> 2. For AST2600.
> 3. For ASTDP.
> 4. v1.11
Hi,
I've cc'ed Thomas who is maintaining this upstream,
Hi Wang Qing
On Tue, Sep 22, 2020 at 08:14:24PM +0800, Wang Qing wrote:
> Use kobj_to_dev() instead of container_of()
>
> Signed-off-by: Wang Qing
Thanks, applied to drm-misc-next. Patch will appear in -next in a few
weeks.
Sam
> ---
> drivers/video/fbdev/aty/radeon_base.c | 4 ++--
Hi Li Heng
On Thu, Sep 24, 2020 at 10:18:26PM +0800, Li Heng wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/video/fbdev/sis/300vtbl.h:1064:28: warning:
> ‘SiS300_CHTVVCLKSONTSC’ defined but not used [-Wunused-const-variable=]
>
> Reported-by: Hulk Robot
> Signed-off-by: Li
Hi Yannick
On Fri, Sep 25, 2020 at 04:16:18PM +0200, Yannick Fertre wrote:
> Compute new timings to get a framerate of 50fps with a pixel clock
> @54Mhz.
>
> Signed-off-by: Yannick Fertre
Thanks, applied to drm-misc-next.
Sorry for taking so long time.
Sam
> ---
>
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 11:58 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re:
Please fix the checkpatch errors, you can run it locally by running "dim
checkpatch drm-tip/drm-tip..HEAD", search for instructions of how to fetch
and setup dim.
Also no need to CC drm-devel for patches that only touches i915, drm-devel is
for drivers that don't have it's own list and for
> -Original Message-
> From: Jason Gunthorpe
> Sent: Friday, October 16, 2020 12:00 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re:
Hi Lubomir.
On Sat, Sep 26, 2020 at 02:07:19AM +0200, Lubomir Rintel wrote:
> Himax HX8837 is used to drive the LCD panel on OLPC platforms.
>
> It controls the panel backlight and is able to refresh it when the LCD
> controller (and the rest of the plaform) is powered off.
>
> It also converts
https://bugzilla.kernel.org/show_bug.cgi?id=209721
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Haxk20 from comment #4)
> That fixes it. Would be nice to see it in the next drm-fixes.
Already queued up:
https://patchwork.freedesktop.org/patch/395141/
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=209721
--- Comment #5 from Haxk20 (haxk...@gmail.com) ---
I will keep the bug opened until it is in linus tree
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
https://bugzilla.kernel.org/show_bug.cgi?id=209721
--- Comment #4 from Haxk20 (haxk...@gmail.com) ---
(In reply to Alex Deucher from comment #2)
> Does this patch fix it?
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.
> 10=44264591a8c4da7090a4bfd10e04f4cb8fe60afe
That fixes
Hi Kevin,
> v7:
> 1. Fix DTC unit name warnings
> 2. Fix the problem of maintainers
> 3. Call drmm_mode_config_init to mode config init
> 4. Embed drm_device in sprd_drm and use devm_drm_dev_alloc
> 5. Replace DRM_XXX with drm_xxx on KMS module, but not suitable for other
> subsystems
> 6.
Hi Yu Wang
On Wed, Sep 30, 2020 at 08:18:59AM +, Xu Wang wrote:
> Because clk_disable_unprepare already checked NULL clock parameter,
> so the additional checks are unnecessary, just remove it
>
> Signed-off-by: Xu Wang
Thanks, applied to drm-misc-next. I will appear in linux-next in a few
On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote:
> On Sat, Oct 03, 2020 at 04:02:57AM +, John Stultz wrote:
> > @@ -215,8 +236,12 @@ static void *system_heap_do_vmap(struct
> > system_heap_buffer *buffer)
> > struct page **pages = vmalloc(sizeof(struct page *) * npages);
> >
On Thu, Oct 8, 2020 at 4:36 AM Brian Starkey wrote:
>
> Hi John,
>
> On Sat, Oct 03, 2020 at 04:02:50AM +, John Stultz wrote:
> > Hey All,
>
> ...
>
> >
> > I did add to this series a reworked version of my uncached
> > system heap implementation I was submitting a few weeks back.
> > Since
Hi Douglas.
On Fri, Oct 02, 2020 at 02:03:51PM -0700, Douglas Anderson wrote:
> On some panels hooked up to the ti-sn65dsi86 bridge chip we found that
> link training was failing. Specifically, we'd see:
>
> ti_sn65dsi86 2-002d: [drm:ti_sn_bridge_enable] *ERROR* Link training
> failed, link
On Fri, Oct 16, 2020 at 1:29 AM Greg Kroah-Hartman
wrote:
>
> On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote:
> > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote:
> > > The ION android code has long been marked to be removed, now that we
> > > dma-buf support merged into the real part
Hi Marek.
On Sat, Oct 03, 2020 at 01:07:26AM +0200, Marek Vasut wrote:
> The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW
> or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode.
So after reading this paragrahp I assumed this patch would fix this, alas
there is no
On Tue, Oct 13, 2020 at 04:52:05PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml
>
There's some refactoring of usb-hcd.yaml and XHCI schema under review
and this may need some refactoring on top of it.
> Signed-off-by: Chunfeng Yun
> ---
>
On Tue, 13 Oct 2020 16:52:04 +0800, Chunfeng Yun wrote:
> Convert mediatek,musb.txt to YAML schema mediatek,musb.yaml
>
> Cc: Min Guo
> Signed-off-by: Chunfeng Yun
> ---
> v2: new patch
> ---
> .../devicetree/bindings/usb/mediatek,musb.txt | 57 -
> .../bindings/usb/mediatek,musb.yaml
On Tue, 13 Oct 2020 16:52:03 +0800, Chunfeng Yun wrote:
> Convert HDMI PHY binding to YAML schema mediatek,ufs-phy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v2: fix binding check warning of reg in example
> ---
> .../display/mediatek/mediatek,hdmi.txt| 17 +---
>
On Tue, 13 Oct 2020 16:52:02 +0800, Chunfeng Yun wrote:
> Convert phy-mtk-ufs.txt to YAML schema mediatek,ufs-phy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v2: fix binding check warning of reg in example
> ---
> .../bindings/phy/mediatek,ufs-phy.yaml| 64 +++
>
On Fri, Oct 16, 2020 at 7:02 PM Melissa Wen wrote:
>
> On 10/16, Daniel Vetter wrote:
> > On Fri, Oct 16, 2020 at 12:38 PM Simon Ser wrote:
> > >
> > > > The only thing we support is xrgb.
> > > >
> > > > Signed-off-by: Daniel Vetter
> > > > Cc: Rodrigo Siqueira
> > > > Cc: Melissa Wen
>
On Tue, Oct 13, 2020 at 04:52:01PM +0800, Chunfeng Yun wrote:
> Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v2: modify description and compatible
> ---
> .../bindings/phy/mediatek,tphy.yaml | 263 ++
>
On Tue, Oct 13, 2020 at 04:52:01PM +0800, Chunfeng Yun wrote:
> Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v2: modify description and compatible
> ---
> .../bindings/phy/mediatek,tphy.yaml | 263 ++
>
On 10/16, Daniel Vetter wrote:
> On Fri, Oct 16, 2020 at 12:38 PM Simon Ser wrote:
> >
> > > The only thing we support is xrgb.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Rodrigo Siqueira
> > > Cc: Melissa Wen
> > > Cc: Haneen Mohammed
> > > Cc: Daniel Vetter
> > > ---
> > >
On Tue, Oct 13, 2020 at 04:52:00PM +0800, Chunfeng Yun wrote:
> Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v2: modify description and compatible definition suggested by Rob
> ---
> .../bindings/phy/mediatek,xsphy.yaml | 200
On Thu, Oct 8, 2020 at 1:24 AM Ville Syrjälä
wrote:
>
> On Wed, Oct 07, 2020 at 09:44:09AM -0700, Rob Clark wrote:
> > On Mon, Oct 5, 2020 at 5:15 AM Ville Syrjälä
> > wrote:
> > >
> > > On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote:
> > > > On Fri, Oct 2, 2020 at 4:05 AM Ville
Hi Marek.
On Sat, Oct 03, 2020 at 01:08:23AM +0200, Marek Vasut wrote:
> The OnSemi FIN3385 Parallel-to-LVDS encoder has a dedicated input line to
> select input pixel data sampling edge. Add DT property "pixelclk-active",
> same as the one used by display timings, and configure bus flags based
https://bugzilla.kernel.org/show_bug.cgi?id=209721
--- Comment #3 from Haxk20 (haxk...@gmail.com) ---
Will build it in and report back.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
https://bugzilla.kernel.org/show_bug.cgi?id=203471
--- Comment #23 from Haxk20 (haxk...@gmail.com) ---
For people wondering yes this is still an issue. The bug is 1 year old now.
scatter/gather support has been enabled in the kernel for a long time now yet
its still broken.
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=209721
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=209721
--- Comment #1 from Haxk20 (haxk...@gmail.com) ---
The HEAD of the kernel is current head on mainline. That is
"9ff9b0d392ea08090cd1780fb196f36dbb586529"
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=209721
Bug ID: 209721
Summary: No output after AMDGPU loads.
Product: Drivers
Version: 2.5
Kernel Version: Linux Master branch
Hardware: All
OS: Linux
Tree:
On Fri, Oct 16, 2020 at 7:11 AM Krishna Manikandan
wrote:
>
> When there are back to back commits with async cursor update,
> there is a case where second commit can program the DPU hw
> blocks while first didn't complete flushing config to HW.
>
> Synchronize the compositions such that second
Hi Bogdan
On Mon, Oct 05, 2020 at 05:12:08PM +0300, Bogdan Togorean wrote:
> From: Lars-Peter Clausen
>
> The AXI HDMI HDL driver is the driver for the HDL graphics core which is
> used on various FPGA designs. It's mostly used to interface with the
> ADV7511 driver on some Zynq boards (e.g.
When there is a chain of bridges attached to the encoder,
the bus_format should be ideally set from the input format of the
first bridge in the chain.
Use the bridge state to get the negotiated bus_format.
If the bridge does not support format negotiation, error out
and fail.
Signed-off-by:
When the next bridge does not specify any bus flags, use the
bridge->timings->input_bus_flags as fallback when propagating
bus flags from next bridge to current bridge.
Signed-off-by: Nikhil Devshatwar
---
drivers/gpu/drm/drm_bridge.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
With new connector model, tfp410 will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Use helper functions for state management.
Support one of the two RGB formats as selected from DT
To be able to support connector operations across multiple
bridges, it is recommended that the connector should be
created by the SoC driver instead of the bridges.
Modify the tidss modesetting initialization sequence to
create the connector and attach bridges with flag
This series moves the tidss to using new connectoe model, where the
SoC driver (tidss) creates the connector and all the bridges are
attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
Since the bridges do not create the connector, the bus format and
bus_flag is set after the format
With new connector model, mhdp bridge will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Support a single format for input.
Signed-off-by: Nikhil Devshatwar
---
Hi Guido.
On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote:
>
> The first patch in this series fixes dereferencing a NULL mode in the error
> path. The second one extends the resets to not only reset RESX but also
> TP_RSTN
> since otherwise the display will stay completely blank. I
On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
> On Fri, 9 Oct 2020 17:20:18 +0300
> Ville Syrjälä wrote:
>
> > On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
> > > On Fri, 9 Oct 2020 16:10:25 +0300
> > > Ville Syrjälä wrote:
> > >
> > > > On Fri, Oct 09,
On 10/16/2020 3:49 AM, Matthias Kaehlcke wrote:
Hi,
On Thu, Oct 15, 2020 at 12:07:01AM +0530, man...@codeaurora.org wrote:
On 2020-10-14 18:59, Akhil P Oommen wrote:
On 10/9/2020 10:27 PM, Matthias Kaehlcke wrote:
On Fri, Oct 09, 2020 at 08:05:10AM -0700, Doug Anderson wrote:
Hi,
On Thu,
On Fri, Oct 16, 2020 at 02:19:42PM +0200, Thomas Zimmermann wrote:
> Hi
>
> On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg wrote:
>
> > Hi Thomas.
> >
> > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > > At least sparc64 requires I/O-specific access to framebuffers.
Hi
On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> > For drivers with
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct
On 13/10/2020 14:53, Mauro Carvalho Chehab wrote:
As reported by Sphinx:
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147:
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_wait_unlocked'.
On 16/10/2020 14:50, Jani Nikula wrote:
On Fri, 16 Oct 2020, Lionel Landwerlin wrote:
On 16/10/2020 14:37, Mauro Carvalho Chehab wrote:
Em Fri, 16 Oct 2020 14:01:07 +0300
Joonas Lahtinen escreveu:
+ Lionel
Can you please take a look at best resolving the below problem.
Maybe we should
On 13/10/2020 14:53, Mauro Carvalho Chehab wrote:
As reported by Sphinx:
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147:
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_wait_unlocked'.
https://bugzilla.kernel.org/show_bug.cgi?id=209673
cornelius.riemenschnei...@googlemail.com changed:
What|Removed |Added
Kernel Version|5.8.14-arch1-1 |5.9.0
--
You
https://bugzilla.kernel.org/show_bug.cgi?id=209673
--- Comment #9 from cornelius.riemenschnei...@googlemail.com ---
Created attachment 293037
--> https://bugzilla.kernel.org/attachment.cgi?id=293037=edit
crashing dmesg #6
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=209673
--- Comment #8 from cornelius.riemenschnei...@googlemail.com ---
Created attachment 293035
--> https://bugzilla.kernel.org/attachment.cgi?id=293035=edit
crashing dmesg #5
I compiled my own 5.9.0 kernel without any arch linux specific patches,
On Fri, 16 Oct 2020, Lionel Landwerlin wrote:
> On 16/10/2020 14:37, Mauro Carvalho Chehab wrote:
>> Em Fri, 16 Oct 2020 14:01:07 +0300
>> Joonas Lahtinen escreveu:
>>
>>> + Lionel
>>>
>>> Can you please take a look at best resolving the below problem.
>>>
>>> Maybe we should eliminate the
On Fri, Oct 16, 2020 at 11:30:04AM +0200, Daniel Vetter wrote:
> On Fri, Oct 16, 2020 at 10:54 AM Shawn Guo wrote:
> >
> > On Fri, Oct 16, 2020 at 09:58:46AM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 16, 2020 at 9:13 AM Shawn Guo wrote:
> > > >
> > > > Commit 5caa0feafcc6 ("drm/vblank: Lock
On 16/10/2020 14:37, Mauro Carvalho Chehab wrote:
Em Fri, 16 Oct 2020 14:01:07 +0300
Joonas Lahtinen escreveu:
+ Lionel
Can you please take a look at best resolving the below problem.
Maybe we should eliminate the duplicate declarations? Updating such
a list manually seems error prone to
Em Fri, 16 Oct 2020 14:01:07 +0300
Joonas Lahtinen escreveu:
> + Lionel
>
> Can you please take a look at best resolving the below problem.
>
> Maybe we should eliminate the duplicate declarations? Updating such
> a list manually seems error prone to me.
For Kernel 5.10, IMO the best is to
On Fri, Oct 16, 2020 at 12:38 PM Simon Ser wrote:
>
> > The only thing we support is xrgb.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Melissa Wen
> > Cc: Haneen Mohammed
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
> > 1 file
Hi
On Fri, 16 Oct 2020 12:58:54 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> > For drivers with
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
> ---
> include/linux/dma-buf-map.h |
+ Lionel
Can you please take a look at best resolving the below problem.
Maybe we should eliminate the duplicate declarations? Updating such
a list manually seems error prone to me.
Regards, Joonas
Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59)
> As reported by Sphinx:
>
>
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct
On Thu, 15 Oct 2020 10:10:15 +0200 Thomas Zimmermann
wrote:
> On Wed, 14 Oct 2020 08:57:22 + Xu Wang wrote:
>
> > Because clk_prepare_enable() and clk_disable_unprepare() already checked
> > NULL clock parameter, so the additional checks are unnecessary, just
> > remove them.
> >
> >
Hi Sam
On Fri, 16 Oct 2020 12:08:54 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> > To do framebuffer updates, one needs memcpy from system memory and a
> > pointer-increment function. Add both interfaces with documentation.
> >
> The only thing we support is xrgb.
>
> Signed-off-by: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Melissa Wen
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 10/15, Daniel Vetter wrote:
> On Mon, Oct 12, 2020 at 09:59:22AM -0300, Melissa Wen wrote:
> > On 10/10, Daniel Vetter wrote:
> > > The only thing we support is xrgb.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Rodrigo Siqueira
> > > Cc: Melissa Wen
> > > Cc: Haneen Mohammed
> >
Hi,
Thanks for this improvement.
I could see that it increased the IGT test coverage, including now the
fbdev test cases.
On 10/10, Daniel Vetter wrote:
> Hooray for generic fbdev support, making this a oneliner. We just
> needed to fix preferred_depth fixed and the vmap support added first.
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
Looks good.
Reviewed-by: Sam Ravnborg
On Thu, 15 Oct 2020 10:08:27 +0200 Thomas Zimmermann
wrote:
> On Wed, 14 Oct 2020 08:49:20 + Xu Wang wrote:
>
> > Because clk_prepare_enable() and clk_disable_unprepare() already checked
> > NULL clock parameter, so the additional checks are unnecessary, just
> > remove them.
> >
> >
On Thu, 15 Oct 2020 10:08:27 +0200 Thomas Zimmermann
wrote:
> On Wed, 14 Oct 2020 08:49:20 + Xu Wang wrote:
>
> > Because clk_prepare_enable() and clk_disable_unprepare() already checked
> > NULL clock parameter, so the additional checks are unnecessary, just
> > remove them.
> >
> >
Am 15.10.20 um 19:52 schrieb Thomas Zimmermann:
Hi
On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote:
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in
https://bugzilla.kernel.org/show_bug.cgi?id=209713
Bug ID: 209713
Summary: amdgpu
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_l
ink_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0
[amdgpu] when resuming
On Fri, Oct 16, 2020 at 10:54 AM Shawn Guo wrote:
>
> On Fri, Oct 16, 2020 at 09:58:46AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 16, 2020 at 9:13 AM Shawn Guo wrote:
> > >
> > > Commit 5caa0feafcc6 ("drm/vblank: Lock down vblank->hwmode more") added
> > > WARN_ON_ONCE() for atomic drivers to
https://bugzilla.kernel.org/show_bug.cgi?id=209673
--- Comment #7 from cornelius.riemenschnei...@googlemail.com ---
Created attachment 293011
--> https://bugzilla.kernel.org/attachment.cgi?id=293011=edit
crashing dmesg #4
And it crashed again.
--
You are receiving this mail because:
You are
On Fri, Oct 16, 2020 at 09:58:46AM +0200, Daniel Vetter wrote:
> On Fri, Oct 16, 2020 at 9:13 AM Shawn Guo wrote:
> >
> > Commit 5caa0feafcc6 ("drm/vblank: Lock down vblank->hwmode more") added
> > WARN_ON_ONCE() for atomic drivers to warn the case that vsync is enabled
> > before a mode has been
https://bugzilla.kernel.org/show_bug.cgi?id=208981
--- Comment #9 from florian.laro...@googlemail.com ---
Hello,
Am Mi., 14. Okt. 2020 um 11:44 Uhr schrieb
:
> - Kernel 5.8.14 and 5.9 with mostly Gentoo kernel config
> - AMD Ryzen 7 PRO 4750G CPU+iGPU
> - ASRock A520M-ITX/ac mainboard + ECC
1 - 100 of 109 matches
Mail list logo
