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 certain display timings with high output bit-depths
> using
> > multiple output
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #25 from Petteri Aimonen (j...@kernelbug.mail.kapsi.fi) ---
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 exception" in
dmesg is not.
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 end of connector register.
Signed-off-by: Jeykumar Sankaran
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #24 from Cyrax (ev...@hotmail.com) ---
(In reply to Petteri Aimonen from comment #16)
> I hit the same issue, using Ubuntu 20.04. It happened when switching window
> to Firefox. For me it only crashed Xorg, ssh to the machine still
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #23 from Cyrax (ev...@hotmail.com) ---
Created attachment 289483
--> https://bugzilla.kernel.org/attachment.cgi?id=289483=edit
used decode_stacktrace.sh to previous dmesg log
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=206987
Cyrax (ev...@hotmail.com) changed:
What|Removed |Added
Kernel Version|5.7.0-rc3 |5.7.0
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #22 from Cyrax (ev...@hotmail.com) ---
Created attachment 289481
--> https://bugzilla.kernel.org/attachment.cgi?id=289481=edit
config file used to build kernel 5.7.0 with KASAN etc
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #21 from Cyrax (ev...@hotmail.com) ---
Created attachment 289479
--> https://bugzilla.kernel.org/attachment.cgi?id=289479=edit
dmesg output kernel 5.7.0
--
You are receiving this mail because:
You are watching the assignee of the
Hi Dave,
v2 with the dpu clk and bw scaling patch that had issues on armv7 reverted.
updated description of original pull req:
Not too huge this time around, but a bunch of interesting new
stuff:
* new gpu support: a405, a640, a650
* dpu: color processing support
* mdp5: support for msm8x36
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 vblanks are supported ofc.
>
> Some drivers do this already, but most
https://bugzilla.kernel.org/show_bug.cgi?id=207383
Duncan (1i5t5.dun...@cox.net) changed:
What|Removed |Added
Summary|[Regression] 5.7-rc:|[Regression] 5.7
Hi Adrian,
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, but
> the current practice for drivers is to leave the encoder
Hi Sandor,
Thank you for the patch.
On Mon, Jun 01, 2020 at 02:17:37PM +0800, sandor...@nxp.com wrote:
> From: Sandor Yu
>
> Document the bindings used for the Cadence MHDP HDMI/DP bridge.
>
> Signed-off-by: Sandor Yu
> ---
> .../bindings/display/bridge/cdns,mhdp.yaml| 46
Hi Sandor,
Thank you for the patch.
On Mon, Jun 01, 2020 at 02:17:33PM +0800, sandor...@nxp.com wrote:
> From: Sandor Yu
>
> This adds initial support for MHDP DP bridge driver.
> Basic DP functions are supported, that include:
> -Video mode set on-the-fly
> -Cable hotplug detect
> -MAX
On Tue, Jun 02, 2020 at 02:55:52PM +0100, Emil Velikov wrote:
> On Mon, 1 Jun 2020 at 07:29, wrote:
> >
> > From: Sandor Yu
> >
> > - Extracted common fields from cdn_dp_device to a new cdns_mhdp_device
> > structure which will be used by two separate drivers later on.
> > - Moved some
Hi all,
Today's linux-next merge of the drm-intel-fixes tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_lrc.c
between commit:
f53ae29c0ea1 ("drm/i915/gt: Include a few tracek for timeslicing")
from Linus' tree and commit:
00febf644648 ("drm/i915/gt: Incorporate the virtual engine
On Tue, Jun 02, 2020 at 11:16:17AM +0200, Piotr Stankiewicz wrote:
> 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
On Wed, 3 Jun 2020 at 08:14, Linus Torvalds
wrote:
>
> On Mon, Jun 1, 2020 at 11:06 PM Dave Airlie wrote:
> >
> > I've pushed a merged by me tree here, which I think gets them all
> > correct, but please let me know if you think different.
> >
Hi Emil,
On Sun, May 31, 2020 at 05:54:04PM +0100, Emil Velikov wrote:
> HI Laurent,
>
> From a quick glance the series looks really good and neat.
Thank you :-)
> Then again, I don't know much about the hardware to provide meaningful
> review.
>
> A couple of small ideas below.
>
> On Sat,
The pull request you sent on Tue, 2 Jun 2020 16:06:32 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-06-02
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/faa392181a0bd42c5478175cef601adeecdc91b6
Thank you!
--
Deet-doot-dot, I am a bot.
On Mon, Jun 1, 2020 at 11:06 PM Dave Airlie wrote:
>
> I've pushed a merged by me tree here, which I think gets them all
> correct, but please let me know if you think different.
> https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-5.8-merged
Ok, I get the same result, except my resolution
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 ("drm/tidss: Use simple encoder") because commit
On Tue, Jun 2, 2020 at 2:21 PM Linus Torvalds
wrote:
>
> Hmm. Some of them are due to your previous mis-merges.
>
> Your commit 937eea297e26 ("Merge tag 'amd-drm-next-5.8-2020-04-24' of
> git://people.freedesktop.org/~agd5f/linux into drm-next") seems to
> have mis-merged the CONFIG_DEBUG_FS
On Mon, Jun 1, 2020 at 11:06 PM Dave Airlie wrote:
>
> This tree is a bit conflicty, the i915 ones are probably the hairy
> ones, but amdgpu has a bunch as well, along with smattering of others.
Hmm. Some of them are due to your previous mis-merges.
Your commit 937eea297e26 ("Merge tag
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 LCD panel with LVDS interface.
> > The panel has dual LVDS
Hi Bartlomiej
On Mon, Jun 01, 2020 at 12:37:00PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On 4/22/20 9:18 AM, Jason Yan wrote:
> > Fix the following coccicheck warning:
> >
> > drivers/video/fbdev/uvesafb.c:48:12-17: WARNING: Assignment of 0/1 to
> > bool variable
> >
Hi Maxime,
Am 27.05.20 um 17:47 schrieb Maxime Ripard:
> Hi everyone,
>
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
>
> The main differences are that there's two HDMI controllers and that
Hi,
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 15:12, Maxime Ripard wrote:
>>> Hi Eric
>>>
>>> On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote:
On Wed, May 27, 2020 at 8:50
On Tue, Jun 02, 2020 at 11:58:36AM +0200, Daniel Vetter wrote:
> On Tue, Jun 02, 2020 at 10:38:46AM +0300, Pekka Paalanen wrote:
> > On Mon, 01 Jun 2020 14:48:58 +
> > Simon Ser wrote:
> >
> > > Describe what a "BAD" link-status means for user-space and how it should
> > > handle it. The
On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson
wrote:
>
> Hi Maxime and Eric
>
> On Tue, 2 Jun 2020 at 15:12, Maxime Ripard wrote:
> >
> > 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
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 sharing the same CRTC (Pekka)
- Add paragraph about performing an
Hi,
Den 02.06.2020 19.05, skrev Felipe Balbi:
>
> Hi,
>
> 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
On Tuesday, June 2, 2020 9:38 AM, Pekka Paalanen wrote:
> Can it happen that there will be no modes left in
> the list?
Reading drm_helper_probe_single_connector_modes, this sounds unlikely
but possible.
This isn't specific to link-status though. This can be the case on a
regular hotplug
On Tue, Jun 2, 2020 at 1:13 PM wrote:
>
> bisected: commit 4dea25853a6c0c16e373665153bd9eb6edc6319e
>
> drm/[radeon|amdgpu]: Replace one-element array and use struct_size() helper
> ...
> Also, make use of the new struct_size() helper to properly calculate the
> size of struct
Alan Stern wrote:
> > > A gadget driver can STALL in response to a control-OUT data packet,
> > > but only before it has seen the packet.
> >
> > How can it do that for OUT, and IN if possible there too?
>
> In the way described just above: The gadget driver's SETUP handler tells
> the UDC to
On Tue, Jun 2, 2020 at 5:52 AM Maxime Ripard wrote:
>
> 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
Hi Stefan,
On Tue, Jun 02, 2020 at 04:34:07PM +0200, Stefan Agner wrote:
> On 2020-06-02 15:12, 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 2020-03-09 20:51, Laurent Pinchart
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 2020-03-09 20:51, Laurent Pinchart wrote:
> > > > Replace the manual connector
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 Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 7 +++
1 file changed,
bisected: commit 4dea25853a6c0c16e373665153bd9eb6edc6319e
drm/[radeon|amdgpu]: Replace one-element array and use struct_size() helper
...
Also, make use of the new struct_size() helper to properly calculate the
size of struct SISLANDS_SMC_SWSTATE.
regards,
--
Sylvain
Hi,
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 USB interface with one bulk
> out
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 as to disable all the CRTCS when
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 return from this
On Tue, Jun 02, 2020 at 05:21:50AM +, Peter Stuge wrote:
> > The USB protocol forbids a device from sending a STALL response to a
> > SETUP packet. The only valid response is ACK. Thus, there is no way
> > to prevent the host from sending its DATA packet for a control-OUT
> > transfer.
>
>
Hi Maxime and Eric
On Tue, 2 Jun 2020 at 15:12, Maxime Ripard wrote:
>
> 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
> > >
On Tue, 2 Jun 2020 at 01:31, Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg wrote:
> >
> > The Seiko 70WVW2T is a discontinued product, but may be used somewhere.
> > Tested on a proprietary product.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Søren Andersen
> >
On Tue, Jun 2, 2020 at 10:35 AM Andy Shevchenko
wrote:
>
> On Tue, Jun 2, 2020 at 5:21 PM Alex Deucher wrote:
> > On Tue, Jun 2, 2020 at 10:00 AM Andy Shevchenko
> > wrote:
> > > On Tue, Jun 2, 2020 at 4:38 PM Ruhl, Michael J
> > > wrote:
> > > > >From: dri-devel On Behalf Of
> > > > >Piotr
On Tue, Jun 2, 2020 at 5:21 PM Alex Deucher wrote:
> On Tue, Jun 2, 2020 at 10:00 AM Andy Shevchenko
> wrote:
> > On Tue, Jun 2, 2020 at 4:38 PM Ruhl, Michael J
> > wrote:
> > > >From: dri-devel On Behalf Of
> > > >Piotr Stankiewicz
> > > > int nvec =
On 2020-06-02 15:12, Daniel Vetter wrote:
> On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote:
>> Hi Stefan,
>>
>> On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote:
>> > On 2020-03-09 20:51, Laurent Pinchart wrote:
>> > > Replace the manual connector implementation based
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 implement is fast skipping of fragmented
address
On Tue, Jun 2, 2020 at 10:00 AM Andy Shevchenko
wrote:
>
> On Tue, Jun 2, 2020 at 4:38 PM Ruhl, Michael J
> wrote:
> > >-Original Message-
> > >From: dri-devel On Behalf Of
> > >Piotr Stankiewicz
> > >Sent: Tuesday, June 2, 2020 5:21 AM
> > >To: Alex Deucher ; Christian König
> > >;
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 engine so
> that no display transactions are
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 implement is fast skipping of fragmented
address space for bottom-up and top-down.
But
Hi Sam,
On Mon, 1 Jun 2020 at 07:52, Sam Ravnborg wrote:
>
> v3:
> - Dropped video patch that was reviewd and thus applied
> - Updated kernel-doc so all fields now have a short intro
> - Improved readability in a lot of places, thanks to review
>feedback from Daniel - thanks!
> - Added
On Tue, Jun 2, 2020 at 4:38 PM Ruhl, Michael J wrote:
> >-Original Message-
> >From: dri-devel On Behalf Of
> >Piotr Stankiewicz
> >Sent: Tuesday, June 2, 2020 5:21 AM
> >To: Alex Deucher ; Christian König
> >; David Zhou ; David
> >Airlie ; Daniel Vetter
> >Cc: Stankiewicz, Piotr ;
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 largely based on his comments in IRC and
from
HI Sandor Yu
On Mon, 1 Jun 2020 at 07:29, wrote:
>
> From: Sandor Yu
>
> - Extracted common fields from cdn_dp_device to a new cdns_mhdp_device
> structure which will be used by two separate drivers later on.
> - Moved some datatypes (audio_format, audio_info, vic_pxl_encoding_format,
>
>-Original Message-
>From: dri-devel On Behalf Of
>Piotr Stankiewicz
>Sent: Tuesday, June 2, 2020 5:21 AM
>To: Alex Deucher ; Christian König
>; David Zhou ; David
>Airlie ; Daniel Vetter
>Cc: Stankiewicz, Piotr ; dri-
>de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; linux-
On Mon, Jun 01, 2020 at 11:35:54AM +0100, Brian Starkey wrote:
> On Wed, May 27, 2020 at 10:55:34AM +0200, Daniel Vetter wrote:
> > On Wed, May 27, 2020 at 08:52:00AM +, Simon Ser wrote:
> > > There have suggestions to bake pitch alignment, address alignement,
> > > contiguous memory or other
Hi Bart,
On Mon, Jun 01, 2020 at 03:25:25PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> On 5/25/20 9:11 AM, Tiezhu Yang wrote:
> > When call function devm_platform_ioremap_resource(), we should use IS_ERR()
> > to check the return value and return PTR_ERR() if failed.
> >
> > Signed-off-by:
On Sat, May 30, 2020 at 05:14:21AM +0300, Laurent Pinchart wrote:
> Hi Stefan,
>
> On Mon, Mar 23, 2020 at 10:27:21PM +0100, Stefan Agner wrote:
> > On 2020-03-09 20:51, Laurent Pinchart wrote:
> > > Replace the manual connector implementation based on drm_panel with the
> > > drm_panel_bridge
Hi Daniel,
On Tue, Jun 02, 2020 at 11:55:05AM +0200, Daniel Vetter wrote:
> This is already done as part of the drm_atomic_helper_shutdown(),
> and in that case only for the crtc which are actually on.
>
> v2: I overlooked that malidp also needs to have it's interrupt shut
> down reordered.
Got
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 kill the interrupt handling before we
> shut down crtc, so need to
Hi Daniel,
On Tue, Jun 02, 2020 at 11:51:39AM +0200, Daniel Vetter wrote:
> This is already done as part of the drm_atomic_helper_shutdown(),
> and in that case only for the crtc which are actually on.
>
I'm pretty sure that it didn't used to be the case when I wrote the code
and I was hitting
Hi Adrian,
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. Sorry for
> > the late response, Yannick and I will review it
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 LCD panel with LVDS interface.
> The panel has dual LVDS channels.
>
> My panel is manufactured by US Micro Products(USMP). There is a tag at
>
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 implement is fast skipping of fragmented
address space for bottom-up and top-down.
But what this test here exercises is the fast skipping of
On Mon, 1 Jun 2020 at 01:25, Rodrigo Siqueira
wrote:
>
> Hi,
>
> First of all, thanks a lot for all your patch. And thanks Emil for your
> feedback.
>
> I have a suggestion here:
>
> Emil:
> Could you give me your Acked-by or maybe Reviewed-by for the writeback
> series? With that, I can finally
On Mon, 11 May 2020 at 12:55, Rodrigo Siqueira wrote:
> # SPDX-License-Identifier: GPL-2.0-only
> -vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o
> vkms_composer.o
> +vkms-y := \
> + vkms_drv.o \
> + vkms_plane.o \
> + vkms_output.o \
> +
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 hurry since tidss is out only in v5.7,
On Tue, Jun 2, 2020 at 1:52 PM Bartlomiej Zolnierkiewicz
wrote:
> Since we lack the hardware (or proper emulator setup) for
> testing needed changes add FIXMEs to document the issues
> (so at least they are not forgotten).
>
> Cc: Al Viro
> Cc: Geert Uytterhoeven
> Signed-off-by: Bartlomiej
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 was killed off a long time ago,
> > when arch/ppc/ was still king, but these
Since we lack the hardware (or proper emulator setup) for
testing needed changes add FIXMEs to document the issues
(so at least they are not forgotten).
Cc: Al Viro
Cc: Geert Uytterhoeven
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2:
- rebased on top of updated patch #1/2
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 #ifdefs were missed, because
> they didn't test for CONFIG_APUS.
Add
Den 02.06.2020 04.32, skrev Alan Stern:
> On Tue, Jun 02, 2020 at 12:12:07AM +, Peter Stuge wrote:
>
> ...
>
>> The way I read composite_setup() after try_fun_setup: it calls f->setup()
>> when available, and that can return < 0 to stall.
>>
>> I expect that composite_setup() and thus
On Tue, 12 May 2020 at 12:34, Emil Velikov wrote:
>
> Hi Rodrigo,
>
> On Mon, 11 May 2020 at 12:55, Rodrigo Siqueira
> wrote:
> >
> > From: Rodrigo Siqueira
> >
> > The compute_crc() function is responsible for calculating the
> > framebuffer CRC value; due to the XRGB format, this function
On 6/2/20 1:07 PM, John Paul Adrian Glaubitz wrote:
> 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
Hi Rodrigo,
On Mon, 11 May 2020 at 12:55, Rodrigo Siqueira wrote:
> -static uint32_t _vkms_get_crc(struct vkms_composer *primary_composer,
> - struct vkms_composer *cursor_composer)
> +static int compose_planes(void **vaddr_out,
> + struct
Hi Adrian,
On Tue, Jun 2, 2020 at 12:41 PM John Paul Adrian Glaubitz
wrote:
> On 6/2/20 12:37 PM, Bartlomiej Zolnierkiewicz 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
Since we lack the hardware (or proper emulator setup) for
testing needed changes add FIXMEs to document the issues
(so at least they are not forgotten).
Cc: Al Viro
Cc: Geert Uytterhoeven
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/amifb.c |2 ++
1 file changed, 2
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 #ifdefs were missed, because
> they didn't test for CONFIG_APUS.
The original patch was basically fine. Just add a Fixes tag and resend.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Rohan,
url:
https://github.com/0day-ci/linux/commits/Rohan-Garg/drm-ioctl-Add-a-ioctl-to-set-and-get-a-label-on-GEM-objects/20200531-000134
base: https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
exynos-drm-next
config: i386-randconfig-m021-20200531 (attached as
On Tue, Jun 2, 2020 at 12:58 PM Stankiewicz, Piotr
wrote:
> > -Original Message-
> > From: Andy Shevchenko
> > Sent: Tuesday, June 2, 2020 11:49 AM
> > To: Stankiewicz, Piotr
> > Cc: Alex Deucher ; Christian König
> > ; David Zhou ; David
> > Airlie ; Daniel Vetter ; amd-
> >
> -Original Message-
> From: Andy Shevchenko
> Sent: Tuesday, June 2, 2020 11:49 AM
> To: Stankiewicz, Piotr
> Cc: Alex Deucher ; Christian König
> ; David Zhou ; David
> Airlie ; Daniel Vetter ; amd-
> g...@lists.freedesktop.org; dri-devel ; Linux
> Kernel Mailing List
> Subject: Re:
On Tue, Jun 02, 2020 at 10:38:46AM +0300, Pekka Paalanen wrote:
> On Mon, 01 Jun 2020 14:48:58 +
> 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].
> >
> > [1]:
> >
This is already done as part of the drm_atomic_helper_shutdown(),
and in that case only for the crtc which are actually on.
v2: I overlooked that malidp also needs to have it's interrupt shut
down reordered.
Signed-off-by: Daniel Vetter
Cc: Liviu Dudau
Cc: Brian Starkey
---
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 kill the interrupt handling before we
shut down crtc, so need to reorder that.
Signed-off-by: Daniel Vetter
Cc: Liviu Dudau
Cc: Brian Starkey
This is already done as part of the drm_atomic_helper_shutdown(),
and in that case only for the crtc which are actually on.
Signed-off-by: Daniel Vetter
Cc: Liviu Dudau
Cc: Brian Starkey
Cc:
---
drivers/gpu/drm/arm/malidp_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git
Only when vblanks are supported ofc.
Some drivers do this already, but most unfortunately missed it. This
opens up bugs after driver load, before the crtc is enabled for the
first time. syzbot spotted this when loading vkms as a secondary
output. Given how many drivers are buggy it's best to
On Tue, Jun 2, 2020 at 12:24 PM 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
> ---
>
Op 12-05-2020 om 11:08 schreef Christian König:
> Am 12.05.20 um 10:59 schrieb Daniel Vetter:
>> But only for non-zero timeout, to avoid false positives.
>>
>> One question here is whether the might_sleep should be unconditional,
>> or only for real timeouts. I'm not sure, so went with the more
>>
On Sat, May 30, 2020 at 06:22:58AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote:
> > Only when vblanks are supported ofc.
> >
> > Some drivers do this already, but most unfortunately missed it. This
>
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 | 8
1 file changed, 4 insertions(+),
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
On Fri, May 29, 2020 at 06:31:56PM +0200, Sylwester Nawrocki wrote:
> This patch adds a generic interconnect driver for Exynos SoCs in order
> to provide interconnect functionality for each "samsung,exynos-bus"
> compatible device.
>
> The SoC topology is a graph (or more specifically, a tree)
On Fri, May 29, 2020 at 06:31:55PM +0200, Sylwester Nawrocki wrote:
> Add documentation for new optional properties in the exynos bus nodes:
> samsung,interconnect-parent, #interconnect-cells.
> These properties allow to specify the SoC interconnect structure which
> then allows the interconnect
https://bugzilla.kernel.org/show_bug.cgi?id=205827
sander44 (ionut_n2...@yahoo.com) changed:
What|Removed |Added
Resolution|CODE_FIX|UNREPRODUCIBLE
--
https://bugzilla.kernel.org/show_bug.cgi?id=205827
sander44 (ionut_n2...@yahoo.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, 01 Jun 2020 14:48:58 +
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].
>
> [1]:
>
1 - 100 of 127 matches
Mail list logo
