Hi!
On 6/2/20 1:04 PM, Geert Uytterhoeven wrote:
>> What do you mean with the sentence "when arch/ppc/ was still king"?
>
> Ah, Bartl copied that from my email ;-)
>
> There used to be APUS support under arch/ppc/.
> Later, 32-bit arch/ppc/ and 64-bit arch/ppc64/ were merged in a new\
> architec
Hi Daniel,
On 6/1/20 10:44 PM, Daniel Lezcano wrote:
On 27/05/2020 11:58, Lukasz Luba wrote:
Add support for other devices than CPUs. The registration function
does not require a valid cpumask pointer and is ready to handle new
devices. Some of the internal structures has been reorganized in or
On 6/2/20 1:13 AM, Tomi Valkeinen wrote:
Hi Santosh,
On 14/02/2020 19:40, santosh.shilim...@oracle.com wrote:
On 2/14/20 1:22 AM, Jyri Sarha wrote:
Resend because the earlier recipient list was wrong.
Now that drm/tidss is queued for mainline, lets add display support for
k2g-evm. There is no
On 27/05/2020 11:58, Lukasz Luba wrote:
> Add support for other devices than CPUs. The registration function
> does not require a valid cpumask pointer and is ready to handle new
> devices. Some of the internal structures has been reorganized in order to
> keep consistent view (like removing per_cp
On Tue, 2 Jun 2020, Al Viro wrote:
> I have done that on aranym (which is how I'd been doing all testing for
> e.g. signal-related m68k patches) and I've seen references to some
> out-of-tree qemu variant doing quadra, but nothing for amiga
> emulators...
>
Laurent Vivier's Quadra 800 emulati
Hi Rob,
On Wed, May 27, 2020 at 01:12:11PM -0600, Rob Herring wrote:
> On Wed, May 27, 2020 at 05:47:36PM +0200, Maxime Ripard wrote:
> > The BCM283x SoCs have a display pipeline composed of several controllers
> > with device tree bindings that are supported by Linux.
> >
> > Now that we have th
Hi Sylwester,
On 6/1/20 7:04 PM, Sylwester Nawrocki wrote:
> Cc: Rob, devicetree ML
>
> On 31.05.2020 01:57, Chanwoo Choi wrote:
>> On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki
>> wrote:
>>>
>>> This patch adds registration of a child platform device for the exynos
>>> interconnect driver.
> Ben has explained this problem:
> https://lore.kernel.org/patchwork/patch/1249592/
> Since the caller will check "pclk" on failure, we don't need to free
> "clk" in gm20b_clk_new() and I think this patch is no longer needed.
* I am curious if it can become easier to see the relationships for
t
Hi Rob,
On Fri, May 29, 2020 at 12:18:33PM -0600, Rob Herring wrote:
> On Wed, May 27, 2020 at 05:49:14PM +0200, Maxime Ripard wrote:
> > The HDMI controllers found in the BCM2711 SoC need some adjustments to the
> > bindings, especially since the registers have been shuffled around in more
> > re
Hi Eric
On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote:
> On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote:
> >
> > The VIDEN bit in the pixelvalve currently being used to enable or disable
> > the pixelvalve seems to not be enough in some situations, which whill end
> > up with t
Hi,
On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote:
> Maxime Ripard 於 2020年5月28日 週四 下午3:30寫道：
> >
> > Hi Daniel,
> >
> > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote:
> > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard wrote:
> > > > I'm about to send a v3 today or
kfree() is called twice for the same variable 'bin', the first is
introduced in commit 0d352a3a8a1f ("drm/v3d: don't leak bin job if
v3d_job_init fails."), while the second is introduced in
commit 29cd13cfd762 ("drm/v3d: Fix memory leak in v3d_submit_cl_ioctl").
The latter one should fail since the
On Tue, Jun 02, 2020 at 02:03:12PM +0200, Geert Uytterhoeven wrote:
> On Tue, Jun 2, 2020 at 1:50 PM Bartlomiej Zolnierkiewicz
> wrote:
> > On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
> > > These #ifdefs are relics from APUS (Amiga Power-Up System), which
> > > added a PPC board. APUS support
Hi Emil,
On 2020-06-02 21:09, Emil Velikov wrote:
On Tue, 2 Jun 2020 at 15:49, Sai Prakash Ranjan
wrote:
Hi Emil,
On 2020-06-02 19:43, Emil Velikov wrote:
> Hi Krishna,
>
> On Tue, 2 Jun 2020 at 08:17, Krishna Manikandan
> wrote:
>>
>> Define shutdown callback for display drm driver,
>> so
> The original patch was basically fine.
I propose to reconsider the interpretation of the software situation once more.
* Should the allocated clock object be kept usable even after
a successful return from this function?
* How much do “destructor” calls matter here for (sub)devices?
> Just
Hi Emil,
On 2020-06-02 19:43, Emil Velikov wrote:
Hi Krishna,
On Tue, 2 Jun 2020 at 08:17, Krishna Manikandan
wrote:
Define shutdown callback for display drm driver,
so as to disable all the CRTCS when shutdown
notification is received by the driver.
This change will turn off the timing en
Hi Geert!
On 6/2/20 12:37 PM, Bartlomiej Zolnierkiewicz wrote:
>
> On 5/14/20 10:21 PM, Geert Uytterhoeven wrote:
>
>> These #ifdefs are relics from APUS (Amiga Power-Up System), which
>> added a PPC board. APUS support was killed off a long time ago,
>> when arch/ppc/ was still king, but these
> On Tue, Jun 02, 2020 at 01:10:34PM +0200, Markus Elfring wrote:
> > > The original patch was basically fine.
> >
> > I propose to reconsider the interpretation of the software situation once
> > more.
> >
> > * Should the allocated clock object be kept usable even after
> > a successful re
On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote:
> On Wed, May 27, 2020 at 8:51 AM Maxime Ripard wrote:
> >
> > the vc4_hdmi driver has some custom structures to hold the data it needs to
> > associate with the drm_encoder and drm_connector structures.
> >
> > However, it allocates the
Hi Eric,
On Wed, May 27, 2020 at 09:33:44AM -0700, Eric Anholt wrote:
> On Wed, May 27, 2020 at 8:49 AM Maxime Ripard wrote:
> >
> > In order to prevent timeouts and stalls in the pipeline, the core clock
> > needs to be maxed at 500MHz during a modeset on the BCM2711.
>
> Like, the whole system
Hi,
Noralf Trønnes writes:
>> I missed this completely until now.
>> Noralf Trønnes writes:
>>> This adds the gadget side support for the Generic USB Display. It presents
>>> a DRM display device as a USB Display configured through configfs.
>>>
>>> The display is implemented as a vendor type U
Hi
Am 02.06.20 um 23:56 schrieb Linus Torvalds:
> On Tue, Jun 2, 2020 at 2:21 PM Linus Torvalds
> wrote:
>>
>> I'm still working through the rest of the merge, so far that was the
>> only one that made me go "Whaa?".
>
> Hmm. I'm also ending up effectively reverting the drm commit
> b28ad7deb2f2
On Wed, Jun 3, 2020 at 9:18 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 02.06.20 um 23:56 schrieb Linus Torvalds:
> > On Tue, Jun 2, 2020 at 2:21 PM Linus Torvalds
> > wrote:
> >>
> >> I'm still working through the rest of the merge, so far that was the
> >> only one that made me go "Whaa?".
> >
>
Hi
Am 25.05.20 um 17:38 schrieb Kieran Bingham:
> On 25/05/2020 13:49, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 22.05.20 um 22:12 schrieb Laurent Pinchart:
>>> Hi Thomas,
>>>
>>> Thank you for the patch.
>>>
>>> On Fri, May 22, 2020 at 03:52:40PM +0200, Thomas Zimmermann wrote:
The rcar-du dri
On Wed, Jun 3, 2020 at 2:19 AM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> May I remind you about the -v option to git-format-patch ? :-) Seriously
> speaking, it really helps review.
>
> On Tue, Jun 02, 2020 at 11:51:38AM +0200, Daniel Vetter wrote:
> > Only when vblan
On Tue, Jun 02, 2020 at 08:13:17PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Tue, Jun 02, 2020 at 03:12:37PM +0200, Daniel Vetter wrote:
> > On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote:
> > > On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote:
> > > > On 202
On Tue, Jun 02, 2020 at 10:00:10AM -0400, Andrey Grodzovsky wrote:
>
> On 6/1/20 10:32 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen
> >
> > Set up the expectations on how hot-unplugging a DRM device should look like
> > to
> > userspace.
> >
> > Written by Daniel Vetter's request and lar
On Tue, Jun 02, 2020 at 08:12:40PM +0300, Laurent Pinchart wrote:
> None of the DSI panels set the connector_type in their panel_desc
> descriptor. As they are all guaranteed to be DSI panels, that's an easy
> fix, set the connector type to DRM_MODE_CONNECTOR_DSI.
>
> Signed-off-by: Laurent Pincha
On Tue, Jun 02, 2020 at 08:37:31PM -0700, Jeykumar Sankaran wrote:
> drm connector notifies userspace on hotplug event prematurely before
> late_register and mode_object register completes. This leads to a race
> between userspace and kernel on updating the IDR list. So, move the
> notification to
https://bugzilla.kernel.org/show_bug.cgi?id=201539
v.j.du...@gmail.com changed:
What|Removed |Added
CC||v.j.du...@gmail.com
--- Comment #55
The .gem_print_info callback in struct drm_driver is obsolete and has
no users left. Remove it.
Signed-off-by: Thomas Zimmermann
Suggested-by: Emil Velikov
---
drivers/gpu/drm/drm_gem.c | 2 --
include/drm/drm_drv.h | 17 -
2 files changed, 19 deletions(-)
diff --git a/dri
The tve200 driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which se
The kirin driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which set
Most of the CMA-based drivers use the default implementation for the
callbacks in struct drm_driver. With this patch, these interfaces are
initialized with a common helper macro and GEM object functions replace
several deprecated interfaces.
The first patch updates the existing macro to similar na
The meson driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_c
The sti driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets CMA GE
The arm driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets
The komeda driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver. All
remaining operations are provided by CMA GEM object functions.
By using
The fsl-dcu driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which s
The imx driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets
The ingenic driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which s
The shmobile driver uses the default implementation for CMA functions.
The DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct
drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which
The tilcdc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which se
Rename the macro to DRM_GEM_CMA_DRIVER_OPS to align with SHMEM
helpers. An internal version is provided for drivers that override
the default .dumb_create callback. Adapt drivers to the changes.
v2:
* provide DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE
Signed-off-by: Thomas Zimmermann
Review
The atmel-hlcdc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
whi
The kirin drivers uses drm_gem_cma_dumb_create_internal() for its
.dumb_create implementation. The function is meant for internal use
only by drivers that require additional buffer setup.
Kirin does not do an additional setup, so convert it over to
drm_gem_cma_dumb_create().
Signed-off-by: Thomas
The rcar-du driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem
The zte driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets
The arc driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which sets
The stm driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_cre
The mcde driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
All remaining operations are provided by CMA GEM object functions.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_cre
The mxsfb driver uses the default implementation for CMA functions. The
DRM_GEM_CMA_DRIVER_OPS macro now sets these defaults in struct drm_driver.
Using DRM_GEM_CMA_DRIVER_OPS introduces several changes: the driver now
sets .gem_create_object to drm_cma_gem_create_object_default_funcs(),
which set
The malidp driver uses the default implementation for CMA functions; except
for the .dumb_create callback. The DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE()
macro now sets these defaults and .dumb_create in struct drm_driver.
By using DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE() the driver now
sets .gem_
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
to their defaults. No functional changes are made.
Signed-off-by: Thomas Zimmermann
Acked-by: Emil Velikov
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers
On 6/2/20 4:25 PM, Christian König wrote:
Am 02.06.20 um 16:13 schrieb Nirmoy:
Hi Christian,
On 6/2/20 2:47 PM, Christian König wrote:
Nirmoy please keep in mind that your current implementation doesn't
fully solve the issue the test case is exercising.
In other words what you have implemen
On Wed, 3 Jun 2020 10:50:28 +0530
Yogish Kulkarni wrote:
> Inline..
>
> On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote:
>
> > On Mon, 1 Jun 2020 09:22:27 +0530
> > Yogish Kulkarni wrote:
> >
> > > Hi,
> > >
> > > For letting DRM clients to select output encoding:
> > > Sink can support
On 02.06.2020 10:21, Krzysztof Kozlowski wrote:
>> +static struct icc_node *exynos_icc_get_parent(struct device_node *np)
>> +{
>> +struct of_phandle_args args;
>> +int num, ret;
>> +
>> +num = of_count_phandle_with_args(np, "samsung,interconnect-parent",
>> +
On Tue, 02 Jun 2020 19:18:15 +
Simon Ser wrote:
> Describe what a "BAD" link-status means for user-space and how it should
> handle it. The logic described has been implemented in igt [1].
>
> v2:
>
> - Change wording to avoid "enabled" (Daniel)
> - Add paragraph about multiple connectors s
Hi Alex,
On Mon, 1 Jun 2020 at 15:25, Alex Deucher wrote:
> On Fri, May 29, 2020 at 11:03 AM Daniel Stone wrote:
> > What Weston _does_ know, however, is that display controller can work
> > with modifier set A, and the GPU can work with modifier set B, and if
> > the client can pick something f
On Wed, Jun 03, 2020 at 12:12:23PM +0300, Pekka Paalanen wrote:
> On Wed, 3 Jun 2020 10:50:28 +0530
> Yogish Kulkarni wrote:
>
> > Inline..
> >
> > On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote:
> >
> > > On Mon, 1 Jun 2020 09:22:27 +0530
> > > Yogish Kulkarni wrote:
> > >
> > > > Hi,
On Thursday, June 27, 2019 4:59 PM, Jani Nikula
wrote:
> On Sat, 22 Jun 2019, Daniel Vetter dan...@ffwll.ch wrote:
>
> > On Wed, Jun 19, 2019 at 10:16 PM Jani Nikula
> > jani.nik...@linux.intel.com wrote:
> >
> > > On Wed, 19 Jun 2019, Daniel Vetter dan...@ffwll.ch wrote:
> > >
> > > > - figur
Hi Chanwoo,
On 01.06.2020 09:58, Chanwoo Choi wrote:
> On 5/30/20 1:32 AM, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski
>>
>> This patch adds interconnect support to exynos-mixer. The mixer works
>> the same as before when CONFIG_INTERCONNECT is 'n'.
>>
>> For proper operation of the video
On Tue, 02 Jun 2020, Emil Velikov
wrote:
Hi Adrian,
Hi Email,
On Mon, 1 Jun 2020 at 10:14, Adrian Ratiu
wrote:
On Fri, 29 May 2020, Philippe CORNU
wrote:
> Hi Adrian, and thank you very much for the patchset. Thank
> you also for having tested it on STM32F769 and STM32MP1.
> Sorr
In update_output_state, the link-status property was reset to GOOD to
ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset
is also performed on an atomic commit without ALLLOW_MODESET. If a
driver reads link-status to figure out whether to re-train the link,
this could cause an
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #26 from Cyrax (ev...@hotmail.com) ---
(In reply to Petteri Aimonen from comment #25)
> Looks like there are two kinds of crash bugs here. Many of the amdgpu
> crashes have been fixed in 5.7.0, but the specific one that gives "simd
> e
On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote:
> In update_output_state, the link-status property was reset to GOOD to
> ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset
> is also performed on an atomic commit without ALLLOW_MODESET. If a
> driver reads link-stat
On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote:
> In update_output_state, the link-status property was reset to GOOD to
> ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset
> is also performed on an atomic commit without ALLLOW_MODESET. If a
I didn't think udate_ou
On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote:
> > In update_output_state, the link-status property was reset to GOOD to
> > ensure legacy drmModeSetCrtc re-trains the link. However this auto-reset
> > is also performed on
The primary objective of this patch series is to change the behaviour
of pci_alloc_irq_vectors_affinity() such that it forwards the MSI-X enable
error code when appropriate. In the process, though, it was pointed out
that there are multiple places in the kernel which check/ask for message
signalled
There are several places in the kernel which check/ask for MSI or MSI-X
interrupts. It would make sense to have a shorthand constant, similar to
PCI_IRQ_ALL_TYPES, to use in these situations. So add PCI_IRQ_MSI_TYPES,
for this purpose.
Signed-off-by: Piotr Stankiewicz
Suggested-by: Andy Shevchenk
Seeing as there is shorthand available to use when asking for any type
of interrupt, or any type of message signalled interrupt, leverage it.
Signed-off-by: Piotr Stankiewicz
Reviewed-by: Andy Shevchenko
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 9 ++---
1 file changed, 2 insertions(+),
On Wed, 03 Jun 2020, Laurent Pinchart
wrote:
Hi Adrian,
Hi Laurent,
Thank you for the patch.
On Mon, Apr 27, 2020 at 11:19:46AM +0300, Adrian Ratiu wrote:
Up until now the assumption was that the synopsis dsi bridge
will directly connect to an encoder provided by the platform
driver, b
Den 28.05.2020 17.27, skrev Emil Velikov:
> On Sun, 24 May 2020 at 19:35, Daniel Vetter wrote:
>>
>> On Sun, May 24, 2020 at 7:46 PM Noralf Trønnes wrote:
>>>
>>>
>>>
>>> Den 24.05.2020 18.13, skrev Paul Cercueil:
Hi list,
I'd like to open a discussion about the current support o
Den 28.05.2020 15.48, skrev Emil Velikov:
> Hi all,
>
> I realise this has landed, so a small FYI comment.
>
> On Sat, 9 May 2020 at 15:16, Noralf Trønnes wrote:
>
>> +int drm_client_framebuffer_flush(struct drm_client_buffer *buffer, struct
>> drm_rect *rect)
>> +{
>> + if (!buffer ||
On Sun, May 31, 2020 at 09:02:11AM -0700, Rob Clark wrote:
> On Thu, May 14, 2020 at 1:11 PM Daniel Vetter wrote:
> >
> > I honestly don't exactly understand what's going on here, but the
> > current code is wrong for sure: It calls dma_buf_vunmap without ever
> > calling dma_buf_vmap.
> >
> > Wha
On Thu, May 14, 2020 at 02:47:57PM +0200, Daniel Vetter wrote:
> On Thu, May 14, 2020 at 09:25:18AM +0200, Thomas Zimmermann wrote:
> > Hi,
> >
> > given the upcoming removal of this file, I don't know if you really want
> > to merge this patch. If so, please see my comment on patch 6 and
>
> Yea
On Thu, May 14, 2020 at 09:30:04AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > Just a bit of light paranoia. Also sprinkle this check over
> > drm_gem_shmem_get_sg_table, which should only be called when
> > exporting, same for the pin/unpin functions,
On Wednesday, June 3, 2020 1:36 PM, Daniel Vetter wrote:
> On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote:
>
> > On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote:
> >
> > > In update_output_state, the link-status property was reset to GOOD to
> > > ensure legacy drmModeSet
> > + * When user-space performs an atomic commit on a connector with a
> > "BAD"
> > + * link-status without resetting the property to "GOOD", it gets
> > + * implicitly reset. This might make the atomic commit fail if the
> > modeset
> > + * is unsuccessful.
>
> I think this
On Wed, Jun 3, 2020 at 7:48 AM Piotr Stankiewicz
wrote:
>
> Seeing as there is shorthand available to use when asking for any type
> of interrupt, or any type of message signalled interrupt, leverage it.
>
> Signed-off-by: Piotr Stankiewicz
> Reviewed-by: Andy Shevchenko
> ---
> drivers/gpu/drm
On Wed, Jun 03, 2020 at 01:27:55PM +, Simon Ser wrote:
> > > + * When user-space performs an atomic commit on a connector with a
> > > "BAD"
> > > + * link-status without resetting the property to "GOOD", it gets
> > > + * implicitly reset. This might make the atomic commit fail
On Wed, Jun 03, 2020 at 01:17:14PM +, Simon Ser wrote:
> On Wednesday, June 3, 2020 1:36 PM, Daniel Vetter wrote:
>
> > On Wed, Jun 03, 2020 at 02:13:43PM +0300, Ville Syrjälä wrote:
> >
> > > On Wed, Jun 03, 2020 at 10:45:23AM +, Simon Ser wrote:
> > >
> > > > In update_output_state, the
On Tue, Jun 02, 2020 at 02:00:16PM +0100, Liviu Dudau wrote:
> On Tue, Jun 02, 2020 at 11:51:40AM +0200, Daniel Vetter wrote:
> > This is already taken care of by drm_atomic_helper_shutdown(), and
> > in that case only for the CRTC which are actually on.
> >
> > Only tricky bit here is that we kil
From: Thierry Reding
Tegra firmware doesn't actually use any version numbers and passing -1
causes the existing firmware binaries not to be found. Use version 0 to
find the correct files.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.c | 2 +-
1 file changed, 1
On Tue, Jun 02, 2020 at 08:12:40PM +0300, Laurent Pinchart wrote:
> None of the DSI panels set the connector_type in their panel_desc
> descriptor. As they are all guaranteed to be DSI panels, that's an easy
> fix, set the connector type to DRM_MODE_CONNECTOR_DSI.
>
> Signed-off-by: Laurent Pincha
On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
>
> Hi Daniel,
>
> On 6/1/20 10:44 PM, Daniel Lezcano wrote:
> > On 27/05/2020 11:58, Lukasz Luba wrote:
> >> Add support for other devices than CPUs. The registration function
> >> does not require a valid cpumask pointer and is ready to handle ne
Hi Maxime,
Am 03.06.20 um 15:14 schrieb Maxime Ripard:
> Hi Stefan,
>
> On Tue, Jun 02, 2020 at 10:03:13PM +0200, Stefan Wahren wrote:
>> Am 02.06.20 um 21:31 schrieb Eric Anholt:
>>> On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson
>>> wrote:
Hi Maxime and Eric
On Tue, 2 Jun 2020 at
On Wed, Jun 3, 2020 at 5:26 PM Lukasz Luba wrote:
>
>
>
> On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
> > On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
> >>
> >> Hi Daniel,
> >>
> >> On 6/1/20 10:44 PM, Daniel Lezcano wrote:
> >>> On 27/05/2020 11:58, Lukasz Luba wrote:
> Add support for
On Wed, 3 Jun 2020 at 15:20, Thierry Reding wrote:
>
> From: Thierry Reding
>
> Tegra firmware doesn't actually use any version numbers and passing -1
> causes the existing firmware binaries not to be found. Use version 0 to
> find the correct files.
>
> Signed-off-by: Thierry Reding
Fixes: ef1
On Wed, Jun 3, 2020 at 6:12 PM Lukasz Luba wrote:
>
>
>
> On 6/3/20 4:40 PM, Rafael J. Wysocki wrote:
> > On Wed, Jun 3, 2020 at 5:26 PM Lukasz Luba wrote:
> >>
> >>
> >>
> >> On 6/3/20 4:13 PM, Rafael J. Wysocki wrote:
> >>> On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote:
>
> Hi Dan
Hi! Was going through my email and found this from last month, it's a bit late
and someone might have reviewed/pushed this already but just in case:
Reviewed-by: Lyude Paul
On Wed, 2020-05-20 at 18:47 +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
Hi Tony,
On 31/05/2020 22:39, Tony Lindgren wrote:
When booting without legacy platform data, we no longer have omap_device
calling PM runtime suspend for us on suspend. This causes the driver
context not be saved as we have no suspend and resume functions defined.
Let's fix the issue by switch
Add some information about pre-atomic modeset properties alongside a
list of suggestions how to handle the different instances.
Signed-off-by: Emil Velikov
---
Documentation/gpu/todo.rst | 32
1 file changed, 32 insertions(+)
diff --git a/Documentation/gpu/todo.
Hi all,
On Wed, 3 Jun 2020 at 10:57, Ville Syrjälä
wrote:
>
> On Wed, Jun 03, 2020 at 12:12:23PM +0300, Pekka Paalanen wrote:
> > On Wed, 3 Jun 2020 10:50:28 +0530
> > Yogish Kulkarni wrote:
> >
> > > Inline..
> > >
> > > On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote:
> > >
> > > > On Mon
On Tue, 2 Jun 2020 at 21:57, Sam Ravnborg wrote:
>
> Hi Emil.
>
> On Tue, Jun 02, 2020 at 01:46:19PM +0100, Emil Velikov wrote:
> > On Tue, 2 Jun 2020 at 08:17, Liu Ying wrote:
> > >
> > > This patch adds support for Kaohsiung Opto-Electronics Inc.
> > > 10.1" TX26D202VM0BWA WUXGA(1920x1200) TFT
Am 02.06.20 um 17:54 schrieb Maxime Ripard:
> On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote:
>> On Wed, May 27, 2020 at 8:51 AM Maxime Ripard wrote:
>>> the vc4_hdmi driver has some custom structures to hold the data it needs to
>>> associate with the drm_encoder and drm_connector st
Looks like a nice cleanup to me. (No idea if at some point there
actually was a reason for a return value...)
Reviewed-by: Roland Scheidegger
Am 30.05.20 um 14:46 schrieb Emil Velikov:
> The function always returns zero (success). Ideally we'll remove it all
> together - although that's requires
TMZ is more complicated. If there is a TMZ buffer used by a command buffer,
then all other used buffers must also be TMZ or read only. If no TMZ
buffers are used by a command buffer, then TMZ is disabled. If a context is
not secure, TMZ is also disabled. A context can switch between secure and
non-
Den 02.06.2020 02.12, skrev Peter Stuge:
> Hi Noralf,
>
> Thanks a lot for going into more detail.
>
> Noralf Trønnes wrote:
>>> Several Linux/DRM internals have "leaked" into the USB protocol - this
>>> should be avoided if you want device implementations other than your
>>> gadget, because th
On Thu, 4 Jun 2020 at 01:43, Emil Velikov wrote:
>
> On Wed, 3 Jun 2020 at 15:20, Thierry Reding wrote:
> >
> > From: Thierry Reding
> >
> > Tegra firmware doesn't actually use any version numbers and passing -1
> > causes the existing firmware binaries not to be found. Use version 0 to
> > find
1 - 100 of 125 matches
Mail list logo
