Hi Jacopo,
On Wed, Nov 13, 2019 at 11:04 AM Jacopo Mondi wrote:
> Add a driver for the R-Car Display Unit Color Correction Module.
> In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> to perform image enhancement and color correction.
>
> Add support for CMM through a
Hi Tony,
On 27/11/2019 17:45, Tony Lindgren wrote:
Interestingly, the actual panel at least on my EVMs and ePOSes is not
osd057T0559-34ts, but osd070t1718-19ts. Also, I was unable to find any
information about osd057T0559-34ts. I don't know the history with this,
so it is possible that the
Hi Dave,
The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594:
Merge tag 'drm-next-5.5-2019-11-22' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2019-11-26 08:40:23
+1000)
are available in the Git repository at:
git://linuxtv.org/pinchartl/media.git
The CMDQ (Command Queue) in MT8183 is used to help update all
relevant display controller registers with critical time limation.
This patch add cmdq interface in ddp_comp interface, let all
ddp_comp interface can support cpu/cmdq function at the same time.
These patches also can fixup cursor
Unlike other SoCs, MT8183 does not have "shadow"
registers for performaing an atomic video mode
set or page flip at vblank/vsync.
The CMDQ (Commend Queue) in MT8183 is used to help
update all relevant display controller registers
with critical time limation.
Signed-off-by: YT Shen
The state->base.event variable would be access by thread context
in mtk_drm_crtc_atomic_begin() or by interrupt context in
mtk_drm_crtc_finish_page_flip(), so each part should be a critical
section. Fix it.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.
Support to async updates of cursors by using the new atomic
interface for that.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 35 +
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 22 ++-
The CMDQ (Command Queue) in MT8183 is used to help
update all relevant display controller registers
with critical time limation.
This patch add cmdq interface in ddp_comp interface,
let all ddp_comp interface can support cpu/cmdq function
at the same time.
Signed-off-by: YT Shen
Signed-off-by:
The DRM core atomic helper now supports asynchronous commits natively.
The custom drm implementation isn't needed anymore, remove it.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 86 ++
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 ---
2 files
On Thu, 28 Nov 2019 at 11:51, Linus Torvalds
wrote:
>
> On Wed, Nov 27, 2019 at 4:59 PM Dave Airlie wrote:
> >
> > my sample merge is here:
> > https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next-5.5-merged
>
> Hmm. I think you missed a couple: you left a duplicate
>
On Wed, 2019-11-27 at 17:56 +0800, Daniel Vetter wrote:
> On Wed, Nov 27, 2019 at 09:41:52AM +0800, Bibby Hsieh wrote:
> > On Tue, 2019-11-26 at 09:49 +0100, Daniel Vetter wrote:
> > > On Tue, Nov 26, 2019 at 02:29:26PM +0800, Bibby Hsieh wrote:
> > > > The DRM core takes care of all atomic state
On Tue, Nov 26, 2019 at 03:44:26PM +0200, Joonas Lahtinen wrote:
Quoting Niranjana Vishwanathapura (2019-11-22 22:57:23)
Define UAPI for Shared Virtual Memory (SVM) fucntionality including
SVM capability and configurability.
When there is no GPU page fault support available, add ioctls
to
On Wed, 27 Nov 2019 at 21:14, Jani Nikula wrote:
>
> On Thu, 21 Nov 2019, Krzysztof Kozlowski wrote:
> > Adjust indentation from spaces to tab (+optional two spaces) as in
> > coding style with command like:
> > $ sed -e 's/^/\t/' -i */Kconfig
>
> Btw have you updated checkpatch.pl
The pull request you sent on Thu, 28 Nov 2019 10:59:16 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-11-27
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a6ed68d6468bd5a3da78a103344ded1435fed57a
Thank you!
--
Deet-doot-dot, I am a bot.
Hi Jacopo,
Thank you for the patch.
On Wed, Nov 13, 2019 at 11:05:52AM +0100, Jacopo Mondi wrote:
> Add a driver for the R-Car Display Unit Color Correction Module.
>
> In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> to perform image enhancement and color correction.
On Wed, Nov 27, 2019 at 4:59 PM Dave Airlie wrote:
>
> my sample merge is here:
> https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next-5.5-merged
Hmm. I think you missed a couple: you left a duplicate
intel_update_rawclk() around (it got moved into
intel_power_domains_init_hw() by commit
On Wed, Nov 13, 2019 at 02:34:27PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> Sorry for spoiling your v7 ;-)
>
> On Wed, Nov 13, 2019 at 11:04 AM Jacopo Mondi
> wrote:
> > Document the newly added 'cmms' property which accepts a list of phandle
>
> renesas,cmms
Fix applied to my
https://bugs.freedesktop.org/show_bug.cgi?id=107877
--- Comment #35 from Drida Infotech ---
here is the fix
https://www.dridainfotech.com
https://www.dridainfotech.com/bigpond-email-support-phone-number.html
https://www.dridainfotech.com/forgot-bigpond-email-password.html
Hi all,
On Wed, 6 Nov 2019 13:53:40 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> On Thu, 10 Oct 2019 13:14:48 +1100 Stephen Rothwell
> wrote:
> >
> > I added the following merge fix patch for today:
> >
>
> This patch is now just:
>
> From: Stephen Rothwell
> Date: Thu, 10 Oct 2019
Hi all,
On Thu, 10 Oct 2019 12:51:06 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
>
> between commit:
>
> 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
>
> from the drm
On Tue, Nov 26, 2019 at 03:59:31PM +0200, Joonas Lahtinen wrote:
Quoting Niranjan Vishwanathapura (2019-11-25 18:40:57)
On Mon, Nov 25, 2019 at 09:59:37AM +, Chris Wilson wrote:
>Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
>> Shared Virtual Memory (SVM) runtime allocator support
On Wed, Nov 27, 2019 at 06:32:56PM +, Emil Velikov wrote:
> On Wed, 27 Nov 2019 at 18:04, Daniel Vetter wrote:
> >
> > On Wed, Nov 27, 2019 at 04:27:29PM +, Emil Velikov wrote:
> > > On Wed, 27 Nov 2019 at 07:41, Boris Brezillon
> > > wrote:
> > > >
> > > > Hi Emil,
> > > >
> > > > On
On Wed, 27 Nov 2019 at 18:04, Daniel Vetter wrote:
>
> On Wed, Nov 27, 2019 at 04:27:29PM +, Emil Velikov wrote:
> > On Wed, 27 Nov 2019 at 07:41, Boris Brezillon
> > wrote:
> > >
> > > Hi Emil,
> > >
> > > On Fri, 1 Nov 2019 13:03:13 +
> > > Emil Velikov wrote:
> > >
> > > > From:
On Wed, Nov 27, 2019 at 06:32:09PM +0200, Jani Nikula wrote:
> Now that the fbops member of struct fb_info is const, we can star making
> the ops const as well.
>
> Cc: Kirti Wankhede
> Cc: k...@vger.kernel.org
> Signed-off-by: Jani Nikula
You've missed at least drivers/staging/fbtft in your
On Wed, Nov 27, 2019 at 06:32:01PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future.
>
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/video/fbdev/vesafb.c | 6 +++---
> 1 file changed, 3
On Wed, Nov 27, 2019 at 06:32:00PM +0200, Jani Nikula wrote:
> Deferred IO now preserves the fb_ops.
>
> Cc: Bernie Thompson
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Daniel Vetter
Aside: I wonder whether we should start retiring all the fbdev drivers
which
On Wed, Nov 27, 2019 at 07:17:41PM +0100, Daniel Vetter wrote:
> On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> > Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> > and then resetting it to NULL afterwards causes problems all over the
> > place. First, it
On Wed, Nov 27, 2019 at 06:31:59PM +0200, Jani Nikula wrote:
> Deferred IO now preserves the fb_ops.
>
> Cc: Steve Glendinning
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/video/fbdev/smscufx.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
On Wed, Nov 27, 2019 at 06:31:58PM +0200, Jani Nikula wrote:
> Deferred IO now preserves the fb_ops.
>
> Cc: Noralf Trønnes
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 18 ++
> 1 file
On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> and then resetting it to NULL afterwards causes problems all over the
> place. First, it prevents making the fbops member of struct fb_info a
> const pointer,
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #2 from freddyrei...@comcast.net ---
Hello! Glad to see there's others looking at this. My mesa is on 19.3.0_rc4,
but the issue is still happening. That related bug in your second link talks
about 5.4 kernel being out but not having
On Wed, Nov 27, 2019 at 05:05:32PM +, Mihail Atanassov wrote:
> Caused by file removal without adjusting the Makefile.
>
> Fixes: d268f42e6856 ("drm/mediatek: don't open-code drm_gem_fb_create")
> Cc: Daniel Vetter
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Matthias Brugger
> Cc:
On Wed, Nov 27, 2019 at 07:01:16PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> > Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> > and then resetting it to NULL afterwards causes problems all over the
> > place. First, it
Hi Emil
Am 27.11.19 um 17:29 schrieb Emil Velikov:
> Hi Thomas,
>
> On Tue, 26 Nov 2019 at 10:15, Thomas Zimmermann wrote:
>>
>> Adds a conversion function that extracts the device type from the
>> PCI id-table flags. Allows for storing additional information in the
>> other flag bits.
>>
>>
On Wed, Nov 27, 2019 at 04:27:29PM +, Emil Velikov wrote:
> On Wed, 27 Nov 2019 at 07:41, Boris Brezillon
> wrote:
> >
> > Hi Emil,
> >
> > On Fri, 1 Nov 2019 13:03:13 +
> > Emil Velikov wrote:
> >
> > > From: Emil Velikov
> > >
> > > As mentioned by Christian, for drivers which
We're doing a great job for really simple drivers right now, but still
a lot of boilerplate for the bigger ones.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/gpu/todo.rst
Again we could delete a lot more if we'd switch over to the generic
fbdev stuff.
Signed-off-by: Daniel Vetter
---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 4 +-
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 11 +---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 5 +-
If rockchip would switch over to the generic fbdev setup we could
grabage collect even more of all this code (all of the remaining fb
handling code really).
v2: Actually use _with_dirty like the patch subject promised (Andrzej)
Cc: Andrzej Pietrasiewicz
Signed-off-by: Daniel Vetter
Cc: Sandy
On Wed, Nov 27, 2019 at 6:33 PM Andrzej Pietrasiewicz
wrote:
>
> Hi Daniel,
>
> After applying this patch there are some slight differences
> in the effective behavior of the code.
>
> I can't tell if they are important, please see below.
>
> Andrzej
>
> W dniu 15.11.2019 o 10:21, Daniel Vetter
Hi Daniel,
After applying this patch there are some slight differences
in the effective behavior of the code.
I can't tell if they are important, please see below.
Andrzej
W dniu 15.11.2019 o 10:21, Daniel Vetter pisze:
If rockchip would switch over to the generic fbdev setup we could
Caused by file removal without adjusting the Makefile.
Fixes: d268f42e6856 ("drm/mediatek: don't open-code drm_gem_fb_create")
Cc: Daniel Vetter
Cc: CK Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Signed-off-by:
On Wed, Nov 27, 2019 at 06:31:57PM +0200, Jani Nikula wrote:
> Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
> and then resetting it to NULL afterwards causes problems all over the
> place. First, it prevents making the fbops member of struct fb_info a
> const pointer,
On 2019-11-20 12:22 p.m., Colin King wrote:
> From: Colin Ian King
>
> The msg_id field is being assigned twice. Fix this by replacing the second
> assignment with an assignment to msg_size.
>
> Addresses-Coverity: ("Unused value")
> Fixes: 11a00965d261 ("drm/amd/display: Add PSP block to
Now that the fbops member of struct fb_info is const, we can star making
the ops const as well.
Cc: Kirti Wankhede
Cc: k...@vger.kernel.org
Signed-off-by: Jani Nikula
---
samples/vfio-mdev/mdpy-fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/samples/vfio-mdev/mdpy-fb.c
Now that the fbops member of struct fb_info is const, we can star making
the ops const as well.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/68328fb.c | 2 +-
drivers/video/fbdev/acornfb.c | 2 +-
Now that the fbops member of struct fb_info is const, we can star making
the ops const as well.
Cc: Bruno Prémont
Cc: linux-in...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/hid/hid-picolcd_fb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Now that the fbops member of struct fb_info is const, we can star making
the ops const as well.
Cc: Hans Verkuil
Cc: Andy Walls
Cc: linux-me...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Signed-off-by: Jani Nikula
---
drivers/media/pci/ivtv/ivtvfb.c | 3 +--
Use const for fb_ops to let us make the info->fbops pointer const in the
future.
Cc: linux-fb...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/omap/omapfb_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Deferred IO now preserves the fb_ops.
Cc: Steve Glendinning
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/smscufx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/smscufx.c b/drivers/video/fbdev/smscufx.c
index
Now that we no longer modify the fbops, or hold non-const pointers to
it, we can make it const. With that, also deferred_io_private needs to
be const. After this, we can start making the fbops const all over the
place.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
Deferred IO now preserves the fb_ops.
Cc: Bernie Thompson
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/udlfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index fe373b63ddd6..07905d385949
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 2 +-
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/vesafb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/vesafb.c
So I wanted to quickly move our struct fb_ops to const data because we
don't modify it... and this series is where the rabbit hole ends. Ugh.
The main pain point is deferred IO, which is covered in patch
1. Everything gets easier after that. The last 5 could be merged at
leisure.
BR,
Jani.
Deferred IO now preserves the fb_ops.
Cc: Noralf Trønnes
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_fb_helper.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
Use const for fb_ops to let us make the info->fbops pointer const in the
future.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/core/fbmem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c
Modifying fb_ops directly to override fb_mmap with fb_deferred_io_mmap
and then resetting it to NULL afterwards causes problems all over the
place. First, it prevents making the fbops member of struct fb_info a
const pointer, which means we can't make struct fb_ops const
anywhere. Second, a few
Le mer. 27 nov. 2019 à 17:19, Sam Ravnborg a écrit :
>
> Hi Mihail.
>
> > >
> > > I can see from grepping that bridge.driver_private is used
> > > in a couple of other files in sti/
> > >
> > > Like sti_hdmi.c:
> > > bridge->driver_private = hdmi;
> > > bridge->funcs =
Hi Thomas,
On Tue, 26 Nov 2019 at 10:15, Thomas Zimmermann wrote:
>
> Adds a conversion function that extracts the device type from the
> PCI id-table flags. Allows for storing additional information in the
> other flag bits.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 81da87f63a1e ("drm:
On Wed, 27 Nov 2019 at 07:41, Boris Brezillon
wrote:
>
> Hi Emil,
>
> On Fri, 1 Nov 2019 13:03:13 +
> Emil Velikov wrote:
>
> > From: Emil Velikov
> >
> > As mentioned by Christian, for drivers which support only primary nodes
> > this changes the returned error from -EACCES into
From: Emil Velikov
Current validation requires that we're authenticated, even though we can
bypass (by design) the authentication when using a render node.
Let's address the former by following the design decision.
v2: Add simpler validation in the ioctls themselves (Boris)
Cc: Alex Deucher
Hi Mihail.
> >
> > I can see from grepping that bridge.driver_private is used
> > in a couple of other files in sti/
> >
> > Like sti_hdmi.c:
> > bridge->driver_private = hdmi;
> > bridge->funcs = _hdmi_bridge_funcs;
> > drm_bridge_attach(encoder, bridge, NULL);
> >
> >
Am 27.11.19 um 16:32 schrieb Andrey Grodzovsky:
Ping...
Andrey
On 11/26/19 10:36 AM, Andrey Grodzovsky wrote:
On 11/26/19 4:08 AM, Christian König wrote:
Am 25.11.19 um 17:51 schrieb Steven Price:
On 25/11/2019 14:10, Andrey Grodzovsky wrote:
When the sched thread is parked we assume
Ping...
Andrey
On 11/26/19 10:36 AM, Andrey Grodzovsky wrote:
On 11/26/19 4:08 AM, Christian König wrote:
Am 25.11.19 um 17:51 schrieb Steven Price:
On 25/11/2019 14:10, Andrey Grodzovsky wrote:
When the sched thread is parked we assume ring_mirror_list is
not accessed from here.
FWIW I
On Wed, Nov 27, 2019 at 02:42:35PM +, Laurentiu Palcu wrote:
> According to CTA-861 specification, HDR static metadata data block allows a
> sink to indicate which HDR metadata types it supports by setting the SM_0 to
> SM_7 bits. Currently, only Static Metadata Type 1 is supported and this is
Hi Sam,
And thank you for the prompt review comments!
On 26/11/2019 23:26, Sam Ravnborg wrote:
> Hi Jyri.
>
> Took a quick look - looks like a very nice driver.
> Some drive by comments below.
>
> I was left with the impression that there is a lot of code to support
> vblank - and I wonder if
https://bugzilla.kernel.org/show_bug.cgi?id=205675
Pierre-Eric Pelloux-Prayer (pierre-eric.pelloux-pra...@amd.com) changed:
What|Removed |Added
CC|
According to CTA-861 specification, HDR static metadata data block allows a
sink to indicate which HDR metadata types it supports by setting the SM_0 to
SM_7 bits. Currently, only Static Metadata Type 1 is supported and this is
indicated by setting the SM_0 bit to 1.
However, the
On Wed, Nov 27, 2019 at 2:49 PM Alexey Brodkin
wrote:
>
> Hi Daniel,
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: Wednesday, November 27, 2019 1:07 PM
> > To: Alexey Brodkin
> > Cc: Daniel Vetter ; David Airlie ; arcml
> > > a...@lists.infradead.org>; Eugeniy Paltsev ;
On Thu, 21 Nov 2019, Krzysztof Kozlowski wrote:
> Adjust indentation from spaces to tab (+optional two spaces) as in
> coding style with command like:
> $ sed -e 's/^/\t/' -i */Kconfig
Btw have you updated checkpatch.pl to try to keep the Kconfigs from
bitrotting back to having
On Wed, Nov 27, 2019 at 07:28:31AM +, Devarsh Thakkar wrote:
> Thanks for the review Ville, please see inline:
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 26 November 2019 07:15
> > To: Devarsh Thakkar
> > Cc: dri-devel@lists.freedesktop.org; Hyun Kwon ; vcu-
> > team
Hi Tony, Thierry, Laurent,
Any thoughts on the below points?
I think yet another option is to write some omap boot time quirks code, which looks at the DT data,
and changes the panel compatible string (for 1), and removes the timings node (for 2).
Tomi
On 14/11/2019 11:39, Tomi Valkeinen
Am 27.11.19 um 13:38 schrieb Daniel Vetter:
> On Wed, Nov 27, 2019 at 01:31:25PM +0100, Thomas Zimmermann wrote:
>> Hi Daniel
>>
>> Am 27.11.19 um 11:49 schrieb Daniel Vetter:
>>> On Wed, Nov 27, 2019 at 08:31:09AM +0100, Thomas Zimmermann wrote:
When enabling the CRTC after waking up from
On Wed, Nov 27, 2019 at 01:31:25PM +0100, Thomas Zimmermann wrote:
> Hi Daniel
>
> Am 27.11.19 um 11:49 schrieb Daniel Vetter:
> > On Wed, Nov 27, 2019 at 08:31:09AM +0100, Thomas Zimmermann wrote:
> >> When enabling the CRTC after waking up from a power-saving mode, the
> >> primary plane's
Hi Daniel
Am 27.11.19 um 11:49 schrieb Daniel Vetter:
> On Wed, Nov 27, 2019 at 08:31:09AM +0100, Thomas Zimmermann wrote:
>> When enabling the CRTC after waking up from a power-saving mode, the
>> primary plane's framebuffer might be NULL, which leads to a stack trace
>> as shown below.
>>
>>
On 11/27/19 11:05 AM, Christian König wrote:
I don't see the advantage over just increasing the alignment
requirements in the driver side?
The advantage is that we don't fail space allocation if we can't match
the alignment. We instead fall back to a lower alignment if it's
compatible with
On 11/27/19 10:12 AM, Christian König wrote:
Am 27.11.19 um 09:31 schrieb Thomas Hellström (VMware):
From: Thomas Hellstrom
Support huge (PMD-size and PUD-size) page-table entries by providing a
huge_fault() callback.
We still support private mappings and write-notify by splitting the huge
On Wed, Nov 27, 2019 at 12:49 PM Mika Westerberg
wrote:
>
> On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote:
> > Hey-this is almost certainly not the right place in this thread to respond,
> > but this thread has gotten so deep evolution can't push the subject further
> > to
> > the
On Tue, Nov 26, 2019 at 06:10:36PM -0500, Lyude Paul wrote:
> Hey-this is almost certainly not the right place in this thread to respond,
> but this thread has gotten so deep evolution can't push the subject further to
> the right, heh. So I'll just respond here.
:)
> I've been following this
Hi Daniel,
W dniu 15.11.2019 o 10:21, Daniel Vetter pisze:
If rockchip would switch over to the generic fbdev setup we could
grabage collect even more of all this code (all of the remaining fb
handling code really).
Signed-off-by: Daniel Vetter
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc:
On Wed, Nov 27, 2019 at 11:22:45AM +0100, Yannick Fertre wrote:
> From: Yannick Fertré
>
> Some bridges did not registered the post_disable function.
> To avoid a crash, check it before calling.
>
> Signed-off-by: Yannick Fertre
Reviewed-by: Daniel Vetter
> ---
>
On Wed, Nov 27, 2019 at 11:05:56AM +, Mihail Atanassov wrote:
> On Tuesday, 26 November 2019 19:24:45 GMT Sam Ravnborg wrote:
> > Hi Mihail.
>
> Hi Sam,
>
> >
> > > Ack, but with one caveat: bridge->dev is the struct drm_device that is
> > > the bridge client, we need to add a
On Tuesday, 26 November 2019 19:24:45 GMT Sam Ravnborg wrote:
> Hi Mihail.
Hi Sam,
>
> > Ack, but with one caveat: bridge->dev is the struct drm_device that is
> > the bridge client, we need to add a bridge->device (patch 29 in this
> > series) which is the struct device that will manage the
On Tuesday, 26 November 2019 19:37:40 GMT Sam Ravnborg wrote:
> Hi Mihail.
Hi Sam,
>
> On Tue, Nov 26, 2019 at 01:16:26PM +, Mihail Atanassov wrote:
> > No functional change.
> >
> > Signed-off-by: Mihail Atanassov
> > ---
> > drivers/gpu/drm/sti/sti_dvo.c | 4 +---
> > 1 file changed, 1
On Wed, Nov 27, 2019 at 08:31:09AM +0100, Thomas Zimmermann wrote:
> When enabling the CRTC after waking up from a power-saving mode, the
> primary plane's framebuffer might be NULL, which leads to a stack trace
> as shown below.
>
> [ 632.624608] BUG: kernel NULL pointer dereference, address:
On Tue, 26 Nov 2019, Lyude Paul wrote:
> I'm about to post some more review comments for the v2 version of this, but
> some comments down below...
>
> On Tue, 2019-10-08 at 12:19 +0300, Jani Nikula wrote:
>> On Mon, 07 Oct 2019, Adam Jackson wrote:
>> > On Mon, 2019-10-07 at 12:08 +0300, Jani
On Tue, 26 Nov 2019, allen wrote:
> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
> (Defines EDID Structure Version 1, Revision 4) page: 39
> How to determine whether the monitor support RB timing or not?
> EDID 1.4
> First: read detailed timing descriptor and make
From: Yannick Fertré
Add support for it by adding compatible and supported chip data
(default settings used).
The chip data on GT9147 is similar to GT912, like
- config data register has 0x8047 address
- config data register max len is 240
- config data checksum has 8-bit
Signed-off-by: Yannick
Le mer. 13 nov. 2019 à 08:55, Benjamin Gaignard
a écrit :
>
> Fix the warnings that show up with W=1.
> They are all about unused but set variables.
gentle ping to reviewers,
Thanks,
Benjamin
>
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 50
>
From: Yannick Fertré
Convert gpio to irq if not already done by gpio lib.
Signed-off-by: Yannick Fertré
#include
#include
+#include
#include
#include
#include
@@ -392,6 +393,13 @@ static void goodix_free_irq(struct goodix_ts_data *ts)
static int goodix_request_irq(struct
From: Yannick Fertré
The pin control must be set to default as soon as possible to
establish a good video link between tv & bridge hdmi
(encoder mode set is call before encoder enable).
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/ltdc.c | 24 ++--
1 file changed,
From: Yannick Fertré
Read the DSI_INT_ST1 status register to check if
errors occur while reading/writing a command to panel.
In case of error, the transfer is retried 3 times.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 99 +++
1
From: Yannick Fertré
Some bridges did not registered the post_disable function.
To avoid a crash, check it before calling.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On Wed, Nov 27, 2019 at 07:48:04AM +, Alexey Brodkin wrote:
> Hi David, Daniel!
>
> The following changes since commit 8082731830a0b95f7f7a63b78de67de446013c80:
>
> drm/vram: remove unused declaration (2019-11-27 07:51:49 +0100)
>
> are available in the Git repository at:
>
>
I don't see the advantage over just increasing the alignment
requirements in the driver side?
That would be a one liner if I'm not completely mistaken.
Regards,
Christian.
Am 27.11.19 um 09:31 schrieb Thomas Hellström (VMware):
From: Thomas Hellstrom
Using huge page-table entries require
On Wed, Nov 27, 2019 at 09:41:52AM +0800, Bibby Hsieh wrote:
> On Tue, 2019-11-26 at 09:49 +0100, Daniel Vetter wrote:
> > On Tue, Nov 26, 2019 at 02:29:26PM +0800, Bibby Hsieh wrote:
> > > The DRM core takes care of all atomic state refcounting.
> > > However, mediatek drm defers some work that
On Tue, Nov 26, 2019 at 09:27:59PM +0100, Andrzej Pietrasiewicz wrote:
> Hi Daniel,
>
> Thanks for the comments, please see inline
>
> W dniu 25.11.2019 o 09:55, Daniel Vetter pisze:
> > On Thu, Nov 21, 2019 at 06:22:44PM +0100, Andrzej Pietrasiewicz wrote:
> > > These are useful for other users
The fake offset is going to stay, so change the calling convention for
drm_gem_object_funcs.mmap to include the fake offset. Update all users
accordingly.
Note that this reverts 83b8a6f242ea ("drm/gem: Fix mmap fake offset
handling for drm_gem_object_funcs.mmap") and on top then adds the fake
Use the shared address space of the drm device (see drm_open() in
drm_file.c) for dma-bufs too. That removes a difference betweem drm
device mmap vmas and dma-buf mmap vmas and fixes corner cases like
dropping ptes (using madvise(DONTNEED) for example) not working
properly.
Also remove amdgpu
1 - 100 of 125 matches
Mail list logo
