If the 'name' array in check_vgem() was not initialized to null, the
value of name[4] may be random. Which will cause strcmp(name, "vgem")
failed.
Signed-off-by: Leon He
---
tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Export finalize function to client which helps append eoc and jump
command to pkt. Let client decide call finalize or not.
Signed-off-by: Dennis YC Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-
include/linux/soc/mediatek/mtk-cmdq.h
When syzkaller tests, there is a UAF:
BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
8810
Read of size 2 by task syz-executor.1/16489
page:ea004000 count:0 mapcount:-127 mapping: (null)
index:0x0
page flags: 0xf()
page
Hi,
Am Montag, 2. März 2020, 21:34:24 CET schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
>
On Mon, 2020-03-02 at 22:34 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
This
Please ignore this patch.
Thanks.
在 2020/3/4 10:02, Zhang Xiaoxu 写道:
When syzkaller tests, there is a UAF:
BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
8810
Read of size 2 by task syz-executor.1/16489
page:ea004000 count:0 mapcount:-127
add write_s function in cmdq helper functions which
writes a constant value to address with large dma
access support.
Signed-off-by: Dennis YC Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 26 ++
include/linux/soc/mediatek/mtk-cmdq.h | 14
Add jump function so that client can jump to any address which
contains instruction.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 12
include/linux/soc/mediatek/mtk-cmdq.h | 11 +++
2 files changed, 23 insertions(+)
diff --git
This patch support gce on mt6779 platform.
Change since v3:
- refine code for local variable usage
- use cmdq error code to consistent with current design
- return error directly after send if error code return
- also modify drm driver which uses cmdq_pkt_wfe api
- add finalize in drm driver
What Xorg prints doesn't mean anything. I don't think there will be
errors in dmesg, you need to run something that does pageflips as fast
as possible and see that the refresh rate is still 60. (modetest with
-v, glmark-drm are examples)
On 3/3/20 7:26 AM, Brian Masney wrote:
On Mon, Mar 02,
When syzkaller tests, there is a UAF:
BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
8810
Read of size 2 by task syz-executor.1/16489
page:ea004000 count:0 mapcount:-127 mapping: (null)
index:0x0
page flags: 0xf()
page
On 02.03.20 09:44, Frieder Schrempf wrote:
> On 26.02.20 17:05, Guido Günther wrote:
>> On Wed, Feb 26, 2020 at 04:54:35PM +0100, Lucas Stach wrote:
>>> On Mi, 2020-02-26 at 15:31 +, Schrempf Frieder wrote:
On 25.02.20 09:13, Frieder Schrempf wrote:
> Hi Lucas,
>
> On 24.02.20
在 2020/3/3 21:59, Ville Syrjälä 写道:
That doesn't match how vc_screenbuf_size is computed elsewhere. Also
a lot of places seem to assume that the screenbuf can be larger than
vga_vram_size (eg. all the memcpy()s pick the smaller size of the
two).
Yes, in the vga source code, we also pick the
On Mon, Mar 2, 2020 at 10:24 PM Gerd Hoffmann wrote:
>
> On Mon, Mar 02, 2020 at 02:14:02PM -0800, Alistair Francis wrote:
> > On Fri, Feb 28, 2020 at 1:57 AM Gerd Hoffmann wrote:
> > >
> > > On Thu, Feb 27, 2020 at 01:04:54PM -0800, Alistair Francis wrote:
> > > > The QEMU model for the Bochs
Hi,
> Am 03.03.2020 um 16:03 schrieb Ville Syrjälä :
>
>> I haven't looked into the driver code, but would it be
>> possible to specify .clock = 0 (or leave it out) to
>> calculate it bottom up? This would avoid such inconsistencies.
>
> I'm going to remove .vrefresh entirely from the struct.
>
* Tony Lindgren [200303 15:14]:
> * Tomi Valkeinen [200303 06:03]:
> > On 24/02/2020 21:12, Tony Lindgren wrote:
> > > + if (sysc_soc->soc == SOC_3430) {
> > > + /* Clear DSS_SDI_CONTROL */
> > > + sysc_write(ddata, dispc_offset + 0x44, 0);
> > > +
> > > + /* Clear
Add assign function in cmdq helper which assign constant value into
internal register by index.
Signed-off-by: Dennis YC Hsieh
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 24 +++-
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
* Tomi Valkeinen [200303 15:36]:
> On 03/03/2020 17:13, Tony Lindgren wrote:
> > Hi,
> >
> > * Tomi Valkeinen [200303 06:03]:
> > > On 24/02/2020 21:12, Tony Lindgren wrote:
> > > > + /* Remap the whole module range to be able to reset dispc
> > > > outputs */
> > > > +
On Tue, Mar 03, 2020 at 08:04:05AM -0500, Jonathan Marek wrote:
> What Xorg prints doesn't mean anything. I don't think there will be errors
> in dmesg, you need to run something that does pageflips as fast as possible
> and see that the refresh rate is still 60. (modetest with -v, glmark-drm are
On Mon, Mar 02, 2020 at 10:36:54PM -0500, Jonathan Marek wrote:
> Another thing: did you verify that the panel still runs at 60hz (and not
> dropping frames to 30hz)? IIRC that was the behavior with lower clock.
Yes, the panel is running at 60 HZ according to the Xorg log with
Ville's patch
Hi Rob,
> Am 03.03.2020 um 15:58 schrieb Rob Herring :
>
> On Thu, Feb 27, 2020 at 01:56:56PM +0100, H. Nikolaus Schaller wrote:
>> Hi Sam,
>>
>>
>> Or that there will appear good tools soon. E.g. some GUI
>> based editor tool would be very helpful so that you don't have
>> to fight with the
Return error code to client if send message fail,
so that client has chance to error handling.
Signed-off-by: Dennis YC Hsieh
Fixes: 576f1b4bc802 ("soc: mediatek: Add Mediatek CMDQ helper")
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
在 2020/3/3 22:46, Ville Syrjälä 写道:
On Tue, Mar 03, 2020 at 10:30:14PM +0800, zhangxiaoxu (A) wrote:
在 2020/3/3 21:59, Ville Syrjälä 写道:
That doesn't match how vc_screenbuf_size is computed elsewhere. Also
a lot of places seem to assume that the screenbuf can be larger than
vga_vram_size
On 03.03.20 16:59, Guido Günther wrote:
> Hi,
> On Tue, Mar 03, 2020 at 11:43:14AM +, Schrempf Frieder wrote:
>> On 02.03.20 09:44, Frieder Schrempf wrote:
>>> On 26.02.20 17:05, Guido Günther wrote:
On Wed, Feb 26, 2020 at 04:54:35PM +0100, Lucas Stach wrote:
> On Mi, 2020-02-26 at
Add clear parameter to let client decide if
event should be clear to 0 after GCE receive it.
Signed-off-by: Dennis YC Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
drivers/soc/mediatek/mtk-cmdq-helper.c | 5 +++--
include/linux/mailbox/mtk-cmdq-mailbox.h | 3 +--
On Tue, Mar 3, 2020 at 8:43 AM Jordan Crouse wrote:
>
> On Mon, Mar 02, 2020 at 09:49:06PM +0100, Sam Ravnborg wrote:
> > Hi Jordan.
> >
> > On Mon, Mar 02, 2020 at 11:23:43AM -0700, Jordan Crouse wrote:
> > > Convert display/msm/gmu.txt to display/msm/gmu.yaml and remove the old
> > > text
euler inclusion
category: bugfix
bugzilla: 31340
DTS: NA
CVE: CVE-2020-8649
---
When syzkaller tests, there is a UAF:
BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
8810
Read of size 2 by task syz-executor.1/16489
On 2020-03-03 15:20, Thierry Reding wrote:
> On Mon, Mar 02, 2020 at 10:53:56PM +, Peter Rosin wrote:
>> On 2020-03-02 21:34, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> The currently listed dotclock disagrees with the currently
>>> listed vrefresh rate. Change the dotclock to match
Hi CK,
On 3/3/20 3:52, CK Hu wrote:
> Hi, Enric:
>
> On Mon, 2020-03-02 at 12:01 +0100, Enric Balletbo i Serra wrote:
>> Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
>> replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
>> Those functions will
On Tue, Mar 03, 2020 at 08:50:28AM -0700, Jeffrey Hugo wrote:
> On Tue, Mar 3, 2020 at 8:43 AM Jordan Crouse wrote:
> >
> > On Mon, Mar 02, 2020 at 09:49:06PM +0100, Sam Ravnborg wrote:
> > > Hi Jordan.
> > >
> > > On Mon, Mar 02, 2020 at 11:23:43AM -0700, Jordan Crouse wrote:
> > > > Convert
If I have time to kill over the weekend I'll do a new rebase of my Nexus
5 patches (my last rebase was back in August on 5.2, and the panel was
working correctly at 60Hz back then).
Looked at it again and it does look like your glmark was vsynced (glmark
explicitly disables vsync so I guess
On Mon, Mar 02, 2020 at 09:15:21PM +0900, David Stevens wrote:
> This change adds a new dma-buf operation that allows dma-bufs to be used
> by virtio drivers to share exported objects. The new operation allows
> the importing driver to query the exporting driver for the UUID which
> identifies the
On Mon, Mar 02, 2020 at 05:00:23PM -0800, Ralph Campbell wrote:
> When memory is migrated to the GPU, it is likely to be accessed by GPU
> code soon afterwards. Instead of waiting for a GPU fault, map the
> migrated memory into the GPU page tables with the same access permissions
> as the source
On Tue, Mar 03, 2020 at 12:37:16PM +0100, Daniel Vetter wrote:
> On Tue, Mar 3, 2020 at 11:53 AM Brian Starkey wrote:
> >
> > Hi,
> >
> > On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> > > On Fri, 21 Feb 2020 10:08:42 +0100
> > > Neil Armstrong wrote:
> > >
> > > > Amlogic
On Tue, Mar 03, 2020 at 02:57:45PM +, Peter Rosin wrote:
>
> On 2020-03-03 15:20, Thierry Reding wrote:
> > On Mon, Mar 02, 2020 at 10:53:56PM +, Peter Rosin wrote:
> >> On 2020-03-02 21:34, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> The currently listed dotclock
Hi Andrzej,
On Tue, 3 Mar 2020 at 12:01, Andrzej Pietrasiewicz
wrote:
>
> Consolidating framebuffer creation into one function will make it easier
> to transition to generic afbc-aware helpers.
>
I'd suggest keeping the refactor a bit simpler.
Say - first folds the functions together. Then do
Hi Andrzej,
On Tue, 3 Mar 2020 at 12:01, Andrzej Pietrasiewicz
wrote:
> * Returns:
> * Pointer to a _framebuffer on success or an error pointer on failure.
> */
> struct drm_framebuffer *
> -drm_gem_fb_create_with_funcs(struct drm_device *dev, struct drm_file *file,
> -
On Mon, Mar 02, 2020 at 08:39:37PM -0800, Kees Cook wrote:
> On Wed, Feb 19, 2020 at 10:22:29PM -0800, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be automatically initialized with compiler instrumentation (as
> > they are not part of any
This reverts commit ff57c6513820efe945b61863cf4a51b79f18b592.
With the commit ff57c6513820 ("drm: kirin: Fix for hikey620
display offset problem") we added support for handling LDI
overflows by resetting the hardware.
However, its been observed that when we do hit the LDI overflow
condition, the
Hi Andrzej,
On Tue, 3 Mar 2020 at 12:01, Andrzej Pietrasiewicz
wrote:
>
> The new struct contains afbc-specific data.
>
> The new function can be used by drivers which support afbc to complete
> the preparation of struct drm_afbc_framebuffer. It must be called after
> allocating the said struct
Hi Sam,
Thank you for the patch.
On Sun, Feb 16, 2020 at 07:15:10PM +0100, Sam Ravnborg wrote:
> Add display-timings.yaml - that references panel-timings.yaml.
> display-timings.yaml will be used for display bindings
> when they are converted to meta-schema format.
>
> For now the old
On Mon, 2020-03-02 at 15:30 +0200, Laurent Pinchart wrote:
> Hi Pankaj,
>
> Thank you for the patch.
>
> On Mon, Mar 02, 2020 at 06:26:46PM +0530, Pankaj Bharadiya wrote:
> > nouveau_drm pointer is not getting used anymore in
> > nv50_mstm_{register,destroy}_connector functions, hence remove it.
On Thu, Feb 27, 2020 at 2:28 AM Christian König
wrote:
>
> Am 26.02.20 um 17:46 schrieb Bas Nieuwenhuizen:
> > On Wed, Feb 26, 2020 at 4:29 PM Jason Ekstrand wrote:
> >> On Wed, Feb 26, 2020 at 4:05 AM Daniel Vetter wrote:
> >>> On Wed, Feb 26, 2020 at 10:16:05AM +0100, Christian König wrote:
>
Hi,
Thanks for your patch, everything lgtm.
Reviewed-by: Rodrigo Siqueira
On 03/02, Melissa Wen wrote:
> The dpp2_get_optimal_number_of_taps function is never used. Removing just for
> code cleaning up.
>
> Signed-off-by: Melissa Wen
> ---
> .../gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c |
Hi Sam,
Thank you for the patch.
On Sun, Feb 16, 2020 at 07:15:13PM +0100, Sam Ravnborg wrote:
> RFC only - not tested yet!
>
> The panel-dpi compatible is a fallback that
> allows the DT to specify the timing.
>
> When matching panel-dpi expect the device tree to include the
> timing
Hi Sam,
Thank you for the patch.
On Sun, Feb 16, 2020 at 07:15:11PM +0100, Sam Ravnborg wrote:
> With panel-timing converted, now convert the single
> remaining .txt user in panel/ of panel-timing to DT schema.
>
> v2:
> - Drop Thierry as maintainer, as this is not a general panel binding
>
Hi Sam,
On Sat, Feb 29, 2020 at 07:13:20PM +0100, Sam Ravnborg wrote:
> On Sun, Feb 16, 2020 at 07:15:08PM +0100, Sam Ravnborg wrote:
> > This set of patches convert display-timing.txt to DT schema.
> > To do that add a panel-timing.yaml file that include all the
> > panel-timing properties and
Vulkan WSI user of the new API:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037
On Tue, Mar 3, 2020 at 1:03 PM Jason Ekstrand wrote:
>
> Explicit synchronization is the future. At least, that seems to be what
> most userspace APIs are agreeing on at this point. However, most of
On 2/25/20 08:17, Jani Nikula wrote:
> On Tue, 25 Feb 2020, "Gustavo A. R. Silva" wrote:
>> The current codebase makes use of the zero-length array language
>> extension to the C90 standard, but the preferred mechanism to declare
>> variable-length types such as these ones is a flexible array
Hi Sam,
On Tue, Feb 18, 2020 at 11:16:38PM +0100, Sam Ravnborg wrote:
> On Tue, Feb 18, 2020 at 02:13:45PM -0600, Rob Herring wrote:
> > On Sun, Feb 16, 2020 at 12:15 PM Sam Ravnborg wrote:
> > >
> > > Add data-mapping property that can be used to specify
> > > the media format used for the
On Tue, Mar 03, 2020 at 10:54:05AM -0500, Brian Masney wrote:
> On Tue, Mar 03, 2020 at 08:50:28AM -0700, Jeffrey Hugo wrote:
> > On Tue, Mar 3, 2020 at 8:43 AM Jordan Crouse wrote:
> > >
> > > On Mon, Mar 02, 2020 at 09:49:06PM +0100, Sam Ravnborg wrote:
> > > > Hi Jordan.
> > > >
> > > > On
Hi Andrzej,
On Tue, 3 Mar 2020 at 12:02, Andrzej Pietrasiewicz
wrote:
> +static struct drm_framebuffer *
> +rockchip_fb_create(struct drm_device *dev, struct drm_file *file,
> + const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + struct drm_afbc_framebuffer *afbc_fb;
> +
On Tue, Mar 03, 2020 at 10:26:27AM +0200, Pekka Paalanen wrote:
> On Fri, 28 Feb 2020 17:31:35 +0100
> Niklas Söderlund wrote:
>
> > Bayer formats are used with cameras and contain green, red and blue
> > components, with alternating lines of red and green, and blue and green
> > pixels in
Explicit synchronization is the future. At least, that seems to be what
most userspace APIs are agreeing on at this point. However, most of our
Linux APIs (both userspace and kernel UAPI) are currently built around
implicit synchronization with dma-buf. While work is ongoing to change
many of
On Mon, Mar 02, 2020 at 10:24:14PM +0100, H. Nikolaus Schaller wrote:
> Hi Ville,
>
> > Am 02.03.2020 um 21:34 schrieb Ville Syrjala
> > :
> >
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the
On Tue, 3 Mar 2020 15:25:41 +0200
Pekka Paalanen wrote:
> On Tue, 3 Mar 2020 12:37:16 +0100
> Daniel Vetter wrote:
>
> > On Tue, Mar 3, 2020 at 11:53 AM Brian Starkey
> > wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> > > > On Fri,
On Fr, 2020-02-28 at 11:37 +0100, Christian Gmeiner wrote:
> Report the correct perfmon domains and signals depending
> on the supported feature flags.
>
> Reported-by: Dan Carpenter
> Fixes: 9e2c2e273012 ("drm/etnaviv: add infrastructure to query perf counter")
> Cc: sta...@vger.kernel.org
>
On Tue, Mar 03, 2020 at 11:20:36AM +0800, Zhang Xiaoxu wrote:
> When syzkaller tests, there is a UAF:
> BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
> 8810
> Read of size 2 by task syz-executor.1/16489
> page:ea004000 count:0 mapcount:-127
On Tue, Mar 03, 2020 at 10:30:14PM +0800, zhangxiaoxu (A) wrote:
>
>
> 在 2020/3/3 21:59, Ville Syrjälä 写道:
> > That doesn't match how vc_screenbuf_size is computed elsewhere. Also
> > a lot of places seem to assume that the screenbuf can be larger than
> > vga_vram_size (eg. all the memcpy()s
On Thu, Feb 27, 2020 at 01:56:56PM +0100, H. Nikolaus Schaller wrote:
> Hi Sam,
>
> > Am 27.02.2020 um 13:23 schrieb Sam Ravnborg :
> >
> > Hi Nikolaus.
> >
> > On Wed, Feb 26, 2020 at 08:12:52PM +0100, H. Nikolaus Schaller wrote:
> >> This patch series adds HDMI output to the jz4780/CI20
On Mon, Mar 02, 2020 at 09:49:06PM +0100, Sam Ravnborg wrote:
> Hi Jordan.
>
> On Mon, Mar 02, 2020 at 11:23:43AM -0700, Jordan Crouse wrote:
> > Convert display/msm/gmu.txt to display/msm/gmu.yaml and remove the old
> > text bindings.
> >
> > Signed-off-by: Jordan Crouse
> > ---
> >
> >
On Mo, 2020-03-02 at 20:13 +0100, Guido Günther wrote:
> At least GC7000 fails to enter runtime suspend for long periods of time since
> the MC becomes busy again even when the FE is idle. The rest of the series
> makes detecting similar issues easier to debug in the future by checking
> all known
On Mon, Mar 02, 2020 at 04:08:59PM -0800, Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
>
On Tue, 3 Mar 2020 18:58:33 +0800, Dennis YC Hsieh wrote:
> Add documentation for the mt6779 gce.
>
> Add gce header file defined the gce hardware event,
> subsys number and constant for mt6779.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> ---
>
On Mon, Mar 02, 2020 at 10:53:56PM +, Peter Rosin wrote:
> On 2020-03-02 21:34, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone tell me which
Hi Ville,
Can you please rebase the series? There are intel_de_write()
changes in existing code.
On 07-Nov-19 8:47 PM, Ville Syrjala wrote:
From: Ville Syrjälä
It irks me to use crtc_state_is_legacy_gamma() inside the guts
of the CHV color management code. Let's get rid of it and instead
just
On Wed, Feb 26, 2020 at 08:12:54PM +0100, H. Nikolaus Schaller wrote:
> From: Zubair Lutfullah Kakakhel
>
> Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
>
> Signed-off-by: Zubair Lutfullah Kakakhel
> ---
> .../bindings/display/ingenic-jz4780-hdmi.txt | 41
On Tue, Mar 03, 2020 at 07:36:35AM +0800, Icenowy Zheng wrote:
>
>
> 于 2020年3月3日 GMT+08:00 上午4:34:22, Ville Syrjala
> 写到:
> >From: Ville Syrjälä
> >
> >The currently listed dotclock disagrees with the currently
> >listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> >Someone
On Mon, Mar 02, 2020 at 11:40:07PM +0200, Vladimir Zapolskiy wrote:
> Hi Ville,
>
> On 3/2/20 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> >
On Mon, Mar 02, 2020 at 10:47:13PM +0100, Sam Ravnborg wrote:
> Hi Ville.
>
> On Mon, Mar 02, 2020 at 10:34:19PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > A lot of the panel drivers put bogus looking values into
> > mode.clock. This series replaces the bogus values with
> >
On 03/03/2020 17:13, Tony Lindgren wrote:
Hi,
* Tomi Valkeinen [200303 06:03]:
On 24/02/2020 21:12, Tony Lindgren wrote:
+ /* Remap the whole module range to be able to reset dispc outputs */
+ devm_iounmap(ddata->dev, ddata->module_va);
+ ddata->module_va =
Hi Lucas,
On Tue, Mar 03, 2020 at 12:55:04PM +0100, Lucas Stach wrote:
> On Mo, 2020-03-02 at 20:13 +0100, Guido Günther wrote:
> > At least GC7000 fails to enter runtime suspend for long periods of time
> > since
> > the MC becomes busy again even when the FE is idle. The rest of the series
> >
On Mon, Mar 2, 2020 at 2:36 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The currently listed dotclock disagrees with the currently
> listed vrefresh rate. Change the dotclock to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
>
> Cc:
On Tue, 3 Mar 2020 12:37:16 +0100
Daniel Vetter wrote:
> On Tue, Mar 3, 2020 at 11:53 AM Brian Starkey wrote:
> >
> > Hi,
> >
> > On Tue, Mar 03, 2020 at 12:10:29PM +0200, Pekka Paalanen wrote:
> > > On Fri, 21 Feb 2020 10:08:42 +0100
> > > Neil Armstrong wrote:
> > >
> > > > Amlogic uses
On Wed, Feb 26, 2020 at 08:12:53PM +0100, H. Nikolaus Schaller wrote:
> From: Zubair Lutfullah Kakakhel
>
> Add DT bindings for the LCD controller on the jz4780 SoC
>
> Signed-off-by: Zubair Lutfullah Kakakhel
> ---
> .../bindings/display/ingenic-jz4780-lcd.txt | 39 +++
> 1
On Tue, Mar 03, 2020 at 08:33:20AM +0100, Marco Felsch wrote:
> Hi Ville,
>
> On 20-03-02 22:34, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The currently listed dotclock disagrees with the currently
> > listed vrefresh rate. Change the dotclock to match the vrefresh.
> >
> > Someone
Prepare for using generic afbc helpers.
Use an existing helper which allows allocating a struct drm_framebuffer
in the driver.
afbc-specific checks should go after drm_gem_fb_init_with_funcs().
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 40
Use available afbc helpers.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 44 +++-
1 file changed, 4 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index
This patch adds support for afbc handling. afbc is a compressed format
which reduces the necessary memory bandwidth.
Co-developed-by: Mark Yao
Signed-off-by: Mark Yao
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
This series adds AFBC support for Rockchip. It is inspired by:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/factory-gru-9017.B-chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
This is the sixth iteration of the afbc series.
Compared to v5 it simplifies
The new struct contains afbc-specific data.
The new function can be used by drivers which support afbc to complete
the preparation of struct drm_afbc_framebuffer. It must be called after
allocating the said struct and calling drm_gem_fb_init_with_funcs().
Signed-off-by: Andrzej Pietrasiewicz
Allow allocating a specialized version of struct drm_framebuffer
by moving the actual fb allocation out of drm_gem_fb_create_with_funcs();
the respective functions names are adjusted to reflect that fact.
Please note, though, that standard size checks are performed on buffers,
so the
Consolidating framebuffer creation into one function will make it easier
to transition to generic afbc-aware helpers.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/arm/malidp_drv.c | 158 +--
1 file changed, 67 insertions(+), 91 deletions(-)
diff --git
Hi,
On Tue, Mar 03, 2020 at 11:43:14AM +, Schrempf Frieder wrote:
> On 02.03.20 09:44, Frieder Schrempf wrote:
> > On 26.02.20 17:05, Guido Günther wrote:
> >> On Wed, Feb 26, 2020 at 04:54:35PM +0100, Lucas Stach wrote:
> >>> On Mi, 2020-02-26 at 15:31 +, Schrempf Frieder wrote:
> On
On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> The currently listed dotclocks disagree with the currently
> listed vrefresh rates. Change the dotclocks to match the vrefresh.
>
> Someone tell me which (if either) of the dotclock or vreresh is
> correct?
I
On 02.03.2020 15:26, Marek Szyprowski wrote:
> Analogix_dp driver acquires all its resources in ->bind() callback, what
> is a bit against the driver component based approach, where driver
> initialization is split into probe(), where all resources are gathered, and
> bind(), where objects are
On Tue, Mar 03, 2020 at 01:10:26PM +0100, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 9:35 PM Ville Syrjala
> wrote:
>
> > From: Ville Syrjälä
> >
> > The currently listed dotclocks disagree with the currently
> > listed vrefresh rates. Change the dotclocks to match the vrefresh.
> >
> >
On 27.02.2020 15:03, Vinay Simha BN wrote:
> dsi2lvds tc358775 bridge driver added
> Tested in apq8016, ifc6309 board and panel
> auo,b101xtn01
Just FYI, there exists already TC358764/5 driver for similar hw, but
controlled via DSI bus.
> Signed-off-by: Vinay Simha BN
> ---
>
Pretty sure the current code is right. If the GAMMA_LUT property can't
be set, it tries to set gamma the old-fashioned way.
On Tue, Mar 3, 2020 at 8:12 AM Devarsh Thakkar wrote:
>
> Hi Rohit,
>
> This makes sense to me as gamma was implemented as optional property.
> Reviewed-By: "Devarsh
The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode,
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
On 3/3/20 4:42 AM, Jason Gunthorpe wrote:
On Mon, Mar 02, 2020 at 05:00:23PM -0800, Ralph Campbell wrote:
When memory is migrated to the GPU, it is likely to be accessed by GPU
code soon afterwards. Instead of waiting for a GPU fault, map the
migrated memory into the GPU page tables with the
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By
On Tue, 2020-02-11 at 13:33 -0500, Lyude Paul wrote:
> - if (!intel_dp_aux_display_control_capable(intel_connector))
> + /*
> + * There are a lot of machines that don't advertise the backlight
> + * control interface to use properly in their VBIOS, :\
> + */
> + if
Hi "Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip linus/master
v5.6-rc4 next-20200303]
[cannot apply to tegra-drm/drm/tegra/for-next]
[if your patch is ap
Hi Andrzej,
I love your patch! Yet something to improve:
[auto build test ERROR on rockchip/for-next]
[also build test ERROR on drm-exynos/exynos-drm-next drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.6-rc4
next-20200303]
[cannot apply to drm/drm-next
On Tue, 2020-02-11 at 13:33 -0500, Lyude Paul wrote:
> The whole point of using OUIs is so that we can recognize certain
> devices and potentially apply quirks for them. Normally this should work
> quite well, but there appears to be quite a number of laptop panels out
> there that will fill the
On Sun, 01 Mar 2020 22:22:25 +
Chris Wilson wrote:
> Quoting Steven Rostedt (2020-03-01 18:18:16)
> > On Sun, 1 Mar 2020 15:52:47 +
> > Chris Wilson wrote:
> >
> > > To facilitate construction of per-client event ringbuffers, in
> > > particular for a per-client debug and error
This function can be reused for hostmem objects.
v2: move virtio_gpu_is_shmem() check to virtio_gpu_cleanup_object()
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 2 +-
drivers/gpu/drm/virtio/virtgpu_object.c | 32 +++--
2 files changed, 20
A resource will be a shmem based resource or a (planned)
vram based resource, so it makes sense to factor out common fields
(resource handle, dumb).
v2: move mapped field to shmem object
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 13 +++
1 - 100 of 219 matches
Mail list logo
