On Tue, 22 Sep 2020 20:52:06 +0300
Ville Syrjälä wrote:
> Mea culpa. My doc test build was foiled by the sphinx 2 vs. 3
> regression and I was too lazy to start downgrading things.
> Any ETA for getting that fixed btw?
There's a fix of sorts in docs-next (and thus linux-next) now, has been
On Tue, Sep 22, 2020 at 01:39:41PM -0400, Lyude Paul wrote:
> For patches 2 and 3:
>
> Reviewed-by: Lyude Paul
>
> I'll go ahead and push these to drm-intel-next-queued (since drm-misc-next
> doesn't have these patches in yet, and the commits these fix were originally
> merged through
For patches 2 and 3:
Reviewed-by: Lyude Paul
I'll go ahead and push these to drm-intel-next-queued (since drm-misc-next
doesn't have these patches in yet, and the commits these fix were originally
merged through drm-intel-next-queued anyway). thanks!
On Tue, 2020-09-22 at 13:22 +0200, Mauro
On Mon, Sep 21, 2020 at 11:59 PM Daniel Vetter wrote:
>
> On Mon, Sep 21, 2020 at 5:16 PM Rob Clark wrote:
> >
> > On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote:
> > >
> > > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > The android
On 09/19/20 12:37, Rob Clark wrote:
> From: Rob Clark
>
> The android userspace treats the display pipeline as a realtime problem.
> And arguably, if your goal is to not miss frame deadlines (ie. vblank),
> it is. (See https://lwn.net/Articles/809545/ for the best explaination
> that I found.)
On Mon, Sep 21, 2020 at 5:16 PM Rob Clark wrote:
>
> On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote:
> >
> > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > The android userspace treats the display pipeline as a realtime problem.
> > > And
On Mon, Sep 21, 2020 at 9:10 AM Qais Yousef wrote:
>
> On 09/19/20 12:37, Rob Clark wrote:
> > From: Rob Clark
> >
> > The android userspace treats the display pipeline as a realtime problem.
> > And arguably, if your goal is to not miss frame deadlines (ie. vblank),
> > it is. (See
On Mon, Sep 21, 2020 at 8:16 AM Rob Clark wrote:
>
> On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote:
> >
> > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > The android userspace treats the display pipeline as a realtime problem.
> > > And
On Mon, Sep 21, 2020 at 8:16 AM Rob Clark wrote:
>
> On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote:
> >
> > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > The android userspace treats the display pipeline as a realtime problem.
> > > And
On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote:
>
> On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > The android userspace treats the display pipeline as a realtime problem.
> > And arguably, if your goal is to not miss frame deadlines (ie. vblank),
> >
Hello,
On Mon, Sep 21, 2020 at 11:21:54AM +0200, Daniel Vetter wrote:
> The part I don't like about this is that it all feels rather hacked
> together, and if we add more stuff (or there's some different thing in the
> system that also needs rt scheduling) then it doesn't compose.
>
> So
On Mon, Sep 21, 2020 at 11:21:54AM +0200, Daniel Vetter wrote:
> So question to rt/worker folks: What's the best way to let userspace set
> the scheduling mode and priorities of things the kernel does on its
> behalf? Surely we're not the first ones where if userspace runs with some
> rt priority
On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> The android userspace treats the display pipeline as a realtime problem.
> And arguably, if your goal is to not miss frame deadlines (ie. vblank),
> it is. (See https://lwn.net/Articles/809545/ for the best
On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote:
> The fbdev code uses compat_alloc_user_space in a few of its
> compat_ioctl handlers, which tends to be a bit more complicated
> and error-prone than calling the underlying handlers directly,
> so I would like to remove it completely.
Hi Thomas,
On Fri, 18 Sep 2020 at 11:36, Sumit Semwal wrote:
>
> Hello Thomas,
>
> On Mon, 14 Sep 2020 at 16:55, Thomas Zimmermann wrote:
> >
> > Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
> > of dma-buf memory in kernel address space. The functions operate with
Hello Thomas,
On Mon, 14 Sep 2020 at 16:55, Thomas Zimmermann wrote:
>
> Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
> of dma-buf memory in kernel address space. The functions operate with plain
> addresses and the assumption is that the memory can be accessed with
> The DDK blob has the ability to mark only certain areas of memory as
> coherent for performance reasons. For simple things like kmscube I would
> expect that it's basically write-only from the CPU and almost all memory the
> GPU touches isn't touched by the CPU. I.e. coherency isn't helping and
On 2020-09-16 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach, even if it's
clearly the cleaner.
That's bizarre -- this should really be the faster of the two.
Coherency may not be free.
On 17/09/2020 11:51, Tomeu Vizoso wrote:
On 9/17/20 12:38 PM, Steven Price wrote:
On 16/09/2020 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach,
even if it's
clearly the cleaner.
That's
On 9/17/20 12:38 PM, Steven Price wrote:
On 16/09/2020 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach,
even if it's
clearly the cleaner.
That's bizarre -- this should really be the
On 16/09/2020 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach, even if it's
clearly the cleaner.
That's bizarre -- this should really be the faster of the two.
Coherency may not be free.
> So I get a performance regression with the dma-coherent approach, even if it's
> clearly the cleaner.
That's bizarre -- this should really be the faster of the two.
signature.asc
Description: PGP signature
___
dri-devel mailing list
Am 17.09.20 um 09:16 schrieb Thomas Zimmermann:
Hi Christian and Thomas
Am 16.09.20 um 15:37 schrieb Thomas Hellström (Intel):
On 9/16/20 2:59 PM, Christian König wrote:
Am 16.09.20 um 14:24 schrieb Daniel Vetter:
On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
Hi
Am
Hi Christian and Thomas
Am 16.09.20 um 15:37 schrieb Thomas Hellström (Intel):
>
> On 9/16/20 2:59 PM, Christian König wrote:
>> Am 16.09.20 um 14:24 schrieb Daniel Vetter:
>>> On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
Hi
Am 16.09.20 um 11:37 schrieb
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
>
> > So I get a performance regression with the dma-coherent approach, even if
> > it's
> > clearly the cleaner.
>
> That's bizarre -- this should really be the faster of the two.
Coherency may not be free. CortexA9 had something like
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
> Hi all,
>
> I polished up my original proof-of-concept a little while back, but now
> that I've got my hands on my Juno again I've been able to actually test
> it to my satisfaction, so here are proper patches!
I tested on the Kkadas VIM3,
On 9/16/20 2:59 PM, Christian König wrote:
Am 16.09.20 um 14:24 schrieb Daniel Vetter:
On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
Hi
Am 16.09.20 um 11:37 schrieb Daniel Vetter:
On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
Dma-buf provides vmap()
Hi
Am 16.09.20 um 14:59 schrieb Christian König:
> Am 16.09.20 um 14:24 schrieb Daniel Vetter:
>> On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 16.09.20 um 11:37 schrieb Daniel Vetter:
On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
Am 16.09.20 um 14:24 schrieb Daniel Vetter:
On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
Hi
Am 16.09.20 um 11:37 schrieb Daniel Vetter:
On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
Dma-buf provides vmap() and vunmap() for retrieving and releasing
On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 16.09.20 um 11:37 schrieb Daniel Vetter:
> > On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
> >> Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
> >> of dma-buf memory in
Hi
Am 16.09.20 um 11:37 schrieb Daniel Vetter:
> On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
>> Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
>> of dma-buf memory in kernel address space. The functions operate with plain
>> addresses and the
On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote:
> Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings
> of dma-buf memory in kernel address space. The functions operate with plain
> addresses and the assumption is that the memory can be accessed with load
On Tue, Sep 8, 2020 at 12:07 AM Gerd Hoffmann wrote:
>
>
> Gerd Hoffmann (3):
> drm/virtio: use drmm_mode_config_init
> drm/virtio: return virtio_gpu_queue errors
> drm/virtio: add virtio_gpu_cmd_unref_resource error handling
>
lgtm +/- nits:
- add a simple "why" in the first commit
On 04/09/2020 20:28, Jonathan Marek wrote:
Add support for SM8150 and SM8250 DSI.
Note I haven't tested SM8150 recently, but DSI is almost identical to SM8250.
On SM8250:
Tested-by: Dmitry Baryshkov
Jonathan Marek (3):
drm/msm/dsi: remove unused clk_pre/clk_post in msm_dsi_dphy_timing
On 2020-09-02 9:57 p.m., Pan, Xinhui wrote:
>
>
>> 2020年9月2日 22:50，Tuikov, Luben 写道：
>>
>> On 2020-09-02 00:43, Pan, Xinhui wrote:
>>>
>>>
2020年9月2日 11:46，Tuikov, Luben 写道：
On 2020-09-01 21:42, Pan, Xinhui wrote:
> If you take a look at the below function, you should not use
> 2020年9月2日 22:50，Tuikov, Luben 写道：
>
> On 2020-09-02 00:43, Pan, Xinhui wrote:
>>
>>
>>> 2020年9月2日 11:46，Tuikov, Luben 写道：
>>>
>>> On 2020-09-01 21:42, Pan, Xinhui wrote:
If you take a look at the below function, you should not use driver's
release to free adev. As dev is
On Wed, Sep 2, 2020 at 9:55 PM Daniel Vetter wrote:
>
> On Wed, Sep 2, 2020 at 9:17 PM Alex Deucher wrote:
> >
> > On Wed, Sep 2, 2020 at 3:04 PM Luben Tuikov wrote:
> > >
> > > On 2020-09-02 11:51 a.m., Daniel Stone wrote:
> > > > Hi Luben,
> > > >
> > > > On Wed, 2 Sep 2020 at 16:16, Luben
On Wed, Sep 2, 2020 at 9:17 PM Alex Deucher wrote:
>
> On Wed, Sep 2, 2020 at 3:04 PM Luben Tuikov wrote:
> >
> > On 2020-09-02 11:51 a.m., Daniel Stone wrote:
> > > Hi Luben,
> > >
> > > On Wed, 2 Sep 2020 at 16:16, Luben Tuikov wrote:
> > >> Not sure how I can do this when someone doesn't
On Wed, Sep 2, 2020 at 3:04 PM Luben Tuikov wrote:
>
> On 2020-09-02 11:51 a.m., Daniel Stone wrote:
> > Hi Luben,
> >
> > On Wed, 2 Sep 2020 at 16:16, Luben Tuikov wrote:
> >> Not sure how I can do this when someone doesn't want to read up on
> >> the kref infrastructure. Can you help?
> >>
>
On 2020-09-02 11:51 a.m., Daniel Stone wrote:
> Hi Luben,
>
> On Wed, 2 Sep 2020 at 16:16, Luben Tuikov wrote:
>> Not sure how I can do this when someone doesn't want to read up on
>> the kref infrastructure. Can you help?
>>
>> When someone starts off with "My understanding of ..." (as in the
Hi Luben,
On Wed, 2 Sep 2020 at 16:16, Luben Tuikov wrote:
> Not sure how I can do this when someone doesn't want to read up on
> the kref infrastructure. Can you help?
>
> When someone starts off with "My understanding of ..." (as in the OP) you
> know you're
> in trouble and in for a rough
On 2020-09-02 11:00, Daniel Stone wrote:
> Hi Luben,
>
> On Wed, 2 Sep 2020 at 15:51, Luben Tuikov wrote:
>> Of course it's true--good morning!
>>
>> Let me stop you right there--just read the documentation I pointed
>> to you at.
>>
>> No!
>>
>> I'm sorry, that doesn't make sense.
>>
>> No,
On 2020-09-02 02:52, Daniel Vetter wrote:
> On Tue, Sep 01, 2020 at 11:46:18PM -0400, Luben Tuikov wrote:
>> On 2020-09-01 21:42, Pan, Xinhui wrote:
>>> If you take a look at the below function, you should not use driver's
>>> release to free adev. As dev is embedded in adev.
>>
>> Do you mean
Hi Luben,
On Wed, 2 Sep 2020 at 15:51, Luben Tuikov wrote:
> Of course it's true--good morning!
>
> Let me stop you right there--just read the documentation I pointed
> to you at.
>
> No!
>
> I'm sorry, that doesn't make sense.
>
> No, that's horrible.
>
> No, that's horrible.
>
> You need to
On 2020-09-02 00:43, Pan, Xinhui wrote:
>
>
>> 2020年9月2日 11:46，Tuikov, Luben 写道：
>>
>> On 2020-09-01 21:42, Pan, Xinhui wrote:
>>> If you take a look at the below function, you should not use driver's
>>> release to free adev. As dev is embedded in adev.
>>
>> Do you mean "look at the function
The cat is somewhat out of the bag already.. so I took the approach of
making the more useful of the traces for visualization (freq_change
trace) identical to the i915 one in units and format, so userspace
just has to add another event name to a list, and not have to add more
parsing code.
But
On Tue, Sep 01, 2020 at 11:46:18PM -0400, Luben Tuikov wrote:
> On 2020-09-01 21:42, Pan, Xinhui wrote:
> > If you take a look at the below function, you should not use driver's
> > release to free adev. As dev is embedded in adev.
>
> Do you mean "look at the function below", using "below" as
Hi Rob,
Do you think we could make all these generic? Visualization tools will need
to do some processing so these can be neatly presented and it could be far
more convenient if people wouldn't need to add code for each GPU driver.
Maybe we could put all these tracepoints in DRM core as they
> 2020年9月2日 11:46，Tuikov, Luben 写道：
>
> On 2020-09-01 21:42, Pan, Xinhui wrote:
>> If you take a look at the below function, you should not use driver's
>> release to free adev. As dev is embedded in adev.
>
> Do you mean "look at the function below", using "below" as an adverb?
> "below" is
On 2020-09-01 21:42, Pan, Xinhui wrote:
> If you take a look at the below function, you should not use driver's release
> to free adev. As dev is embedded in adev.
Do you mean "look at the function below", using "below" as an adverb?
"below" is not an adjective.
I know dev is embedded in
If you take a look at the below function, you should not use driver's release
to free adev. As dev is embedded in adev.
809 static void drm_dev_release(struct kref *ref)
810 {
811 struct drm_device *dev = container_of(ref, struct drm_device, ref);
812
813 if
Hi!
On Fri, Aug 21, 2020 at 04:10:42PM +0900, Hoegeun Kwon wrote:
> Hi everyone,
>
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
>
> Rebased on top of next-20200708 and [1].
>
Hi Hoegeun,
Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
> Hi everyone,
>
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
thanks for providing this.
>
> Rebased on top of
Hi Brain,
On Wed, Aug 19, 2020 at 02:22:04PM +0100, Brian Starkey wrote:
> Hi KyongHo,
>
> On Wed, Aug 19, 2020 at 12:46:26PM +0900, Cho KyongHo wrote:
> > I have seriously considered CPA in our product but we developed our own
> > because of the pool in CPA.
>
> Oh good, I'm glad you
Hi KyongHo,
On Wed, Aug 19, 2020 at 12:46:26PM +0900, Cho KyongHo wrote:
> I have seriously considered CPA in our product but we developed our own
> because of the pool in CPA.
Oh good, I'm glad you considered it :-)
> The high-order pages are required by some specific users like Netflix
> app.
On Tue, Aug 18, 2020 at 11:55:57AM +0100, Brian Starkey wrote:
> Hi,
>
> On Tue, Aug 18, 2020 at 05:04:12PM +0900, Hyesoo Yu wrote:
> > These patch series to introduce a new dma heap, chunk heap.
> > That heap is needed for special HW that requires bulk allocation of
> > fixed high order pages.
On Tue, Aug 18, 2020 at 12:45 AM Hyesoo Yu wrote:
>
> These patch series to introduce a new dma heap, chunk heap.
> That heap is needed for special HW that requires bulk allocation of
> fixed high order pages. For example, 64MB dma-buf pages are made up
> to fixed order-4 pages * 1024.
>
> The
Hi,
On Tue, Aug 18, 2020 at 05:04:12PM +0900, Hyesoo Yu wrote:
> These patch series to introduce a new dma heap, chunk heap.
> That heap is needed for special HW that requires bulk allocation of
> fixed high order pages. For example, 64MB dma-buf pages are made up
> to fixed order-4 pages * 1024.
On Mon, Jul 20, 2020 at 9:27 PM Alexandru Stan wrote:
>
> I was trying to adjust the brightness for a new chromebook:
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291209
> Like a lot of panels, the low end needs to be cropped,
> and now that we have the
Applied the series. Thanks!
Alex
On Tue, Aug 4, 2020 at 4:08 PM Rikard Falkeborn
wrote:
>
> Constify a couple of instances of resource_funcs that are never
> modified to allow the compiler to put it in read-only memory.
>
> The other drivers in drivers/gpu/drm/amd/display/dc already have
>
On Wed, 29 Jul 2020 19:29:07 +0300, Laurent Pinchart wrote:
> This small series fixes a Kconfig dependency issue with the recently
> merged Xilixn DPSUB DRM/KMS driver. The fix is in patch 3/3, but
> requires a separate fixes in patches 1/3 and 2/3 to avoid circular
> dependencies:
>
>
Hi, Enric:
Chun-Kuang Hu 於 2020年5月10日 週日 上午9:24寫道：
>
> Hi, Enric:
>
> Enric Balletbo i Serra 於 2020年5月4日 週一
> 下午10:14寫道：
> >
> > The mtk-dpi driver still uses the drm_encoder API which is now somehow
> > deprecated. We started to move all the Mediatek drivers to the drm_bridge
> > API,
> >
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月4日 週一 下午10:14寫道：
>
> The mtk-dpi driver still uses the drm_encoder API which is now somehow
> deprecated. We started to move all the Mediatek drivers to the drm_bridge API,
> like we did for the mtk-dsi driver [1], this is another small step to be able
Applied. Thanks!
Alex
On Thu, Apr 30, 2020 at 9:07 AM Christian König
wrote:
>
> Reviewed-by: Christian König for the series.
>
> Am 30.04.20 um 04:26 schrieb Zheng Bin:
> > Zheng Bin (3):
> >drm/amdgpu: remove set but not used variable 'priority'
> >drm/amdgpu: remove set but not
Reviewed-by: Christian König for the series.
Am 30.04.20 um 04:26 schrieb Zheng Bin:
Zheng Bin (3):
drm/amdgpu: remove set but not used variable 'priority'
drm/amdgpu: remove set but not used variable 'direct_poll' in
vcn_v2_0.c
drm/amdgpu: remove set but not used variable
Hi All,
I noticed some API changes that were not present when I first wrote this
driver.
This will need correcting so I will send out a second version and respond
to Sam Ravnborg's feedback at the same time. I recommend waiting for that
version before reviewing as this will not function on
On Tue, Mar 31, 2020 at 01:59:32PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> On 3/27/20 9:25 AM, Takashi Iwai wrote:
> > On Fri, 20 Mar 2020 14:42:51 +0100,
> > Bartlomiej Zolnierkiewicz wrote:
> >>
> >>
> >> On 3/19/20 4:49 PM, Takashi Iwai wrote:
> >>> On Wed, 11 Mar 2020 10:32:27 +0100,
>
On 3/27/20 9:25 AM, Takashi Iwai wrote:
> On Fri, 20 Mar 2020 14:42:51 +0100,
> Bartlomiej Zolnierkiewicz wrote:
>>
>>
>> On 3/19/20 4:49 PM, Takashi Iwai wrote:
>>> On Wed, 11 Mar 2020 10:32:27 +0100,
>>> Takashi Iwai wrote:
Hi,
here is a series of trivial patches just to
On Fri, 20 Mar 2020 14:42:51 +0100,
Bartlomiej Zolnierkiewicz wrote:
>
>
> On 3/19/20 4:49 PM, Takashi Iwai wrote:
> > On Wed, 11 Mar 2020 10:32:27 +0100,
> > Takashi Iwai wrote:
> >>
> >> Hi,
> >>
> >> here is a series of trivial patches just to convert suspicious
> >> snprintf() usages with
On 3/19/20 4:49 PM, Takashi Iwai wrote:
> On Wed, 11 Mar 2020 10:32:27 +0100,
> Takashi Iwai wrote:
>>
>> Hi,
>>
>> here is a series of trivial patches just to convert suspicious
>> snprintf() usages with the more safer one, scnprintf().
>>
>>
>> Takashi
>>
>> ===
>>
>> Takashi Iwai (3):
>>
Hi Lyude,
On 3/4/20 11:36 PM, Lyude Paul wrote:
AMD's patch series for adding DSC support to the MST helpers
unfortunately introduced a few regressions into the kernel that I didn't
get around to fixing until just now. I would have reverted the changes
earlier, but seeing as that would have
On Wed, Feb 26, 2020 at 06:39:08AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 25.02.20 um 18:44 schrieb Daniel Vetter:
> > On Tue, Feb 25, 2020 at 04:58:59PM +0100, Thomas Zimmermann wrote:
> >> This patchset moves legacy, non-KMS driver state from struct drm_driver
> >> into struct
Hi
Am 25.02.20 um 18:44 schrieb Daniel Vetter:
> On Tue, Feb 25, 2020 at 04:58:59PM +0100, Thomas Zimmermann wrote:
>> This patchset moves legacy, non-KMS driver state from struct drm_driver
>> into struct drm_legacy_state. Only non-KMS drivers provide an instance
>> of the latter structure. One
On Tue, Feb 25, 2020 at 04:58:59PM +0100, Thomas Zimmermann wrote:
> This patchset moves legacy, non-KMS driver state from struct drm_driver
> into struct drm_legacy_state. Only non-KMS drivers provide an instance
> of the latter structure. One special case is nouveau, which supports
> legacy
On Fri, Feb 14, 2020 at 06:33:17PM -0500, Lyude Paul wrote:
> On Thu, 2020-02-13 at 16:15 -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > Hey all,
> > Earlier this week on my 5.5 kernel (I can't seem to get a 5.6 kernel to
> > behave on any of my devices), I ran into the multi-reply problem
On Thu, 2020-02-13 at 16:15 -0500, Sean Paul wrote:
> From: Sean Paul
>
> Hey all,
> Earlier this week on my 5.5 kernel (I can't seem to get a 5.6 kernel to
> behave on any of my devices), I ran into the multi-reply problem that
> Wayne fixed in January. Without realizing there was already a fix
04.02.2020 16:59, Thierry Reding пишет:
> From: Thierry Reding
>
> Hi,
>
> this contains a couple of fixes for a DMA API performance regression
> that was introduced in v5.5 for older Tegra devices. Patches 1 and 2
> will likely have to be backported to v5.5.
>
> Thierry
>
> Thierry Reding
Applied the series. Thanks!
Alex
On Sat, Dec 14, 2019 at 9:44 AM zhengbin wrote:
>
> zhengbin (3):
> drm/amdgpu: Remove unneeded semicolon in amdgpu_pmu.c
> drm/amdgpu: Remove unneeded semicolon in gfx_v10_0.c
> drm/amdgpu: Remove unneeded semicolon in amdgpu_ras.c
>
>
Please ignore the tegra diff on the bottom of this. I never fail to
find a way to mess up git-send-email.
-James
On 12/11/19 12:59 PM, James Jones wrote:
This series modifies the NV5x+ nouveau display backends to advertise
appropriate format modifiers on their display planes in atomic mode
Hi Adam,
On Mon, Dec 02, 2019 at 07:24:09AM -0600, Adam Ford wrote:
> On Mon, Dec 2, 2019 at 7:13 AM Laurent Pinchart wrote:
> > On Thu, Nov 14, 2019 at 11:39:47AM +0200, Tomi Valkeinen wrote:
> > > Hi Tony, Thierry, Laurent,
> > >
> > > After the recent change of moving from omapdrm specific
On Mon, Dec 2, 2019 at 7:13 AM Laurent Pinchart
wrote:
>
> Hi Tomi,
>
> On Thu, Nov 14, 2019 at 11:39:47AM +0200, Tomi Valkeinen wrote:
> > Hi Tony, Thierry, Laurent,
> >
> > After the recent change of moving from omapdrm specific panel-dpi driver
> > to the DRM simple panel, AM4 EVM/ePOS's panel
Hi Tomi,
On Thu, Nov 14, 2019 at 11:39:47AM +0200, Tomi Valkeinen wrote:
> Hi Tony, Thierry, Laurent,
>
> After the recent change of moving from omapdrm specific panel-dpi driver
> to the DRM simple panel, AM4 EVM/ePOS's panel is not working quite
> right. This series has fixes for it, but I'm
Hi
* Tomi Valkeinen [191127 12:59]:
> 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
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 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
On Tue, Nov 19, 2019 at 04:18:15PM +0100, Hans de Goede wrote:
> Hi All,
>
> This series needs to be merged through a single tree, to keep things
> bisectable. I have even considered just squashing all 3 patches into 1,
> but having separate commits seems better, but that does lead to an
>
On Tue, 19 Nov 2019, Hans de Goede wrote:
> Hi All,
>
> This series needs to be merged through a single tree, to keep things
> bisectable. I have even considered just squashing all 3 patches into 1,
> but having separate commits seems better, but that does lead to an
> intermediate state where
On Fri, Nov 15, 2019 at 10:27:04PM +0800, zhengbin wrote:
> zhengbin (3):
> drm/gma500: remove set but not used variable 'htotal'
> drm/gma500: remove set but not used variable 'error'
> drm/gma500: remove set but not used variable 'is_hdmi','is_crt'
All three applied, thanks for the
On 2019-11-08 03:34, Daniel Vetter wrote:
On Thu, Nov 07, 2019 at 02:39:11PM -0500, Steve Cohen wrote:
Fuzzers used in Android compliance testing repeatedly call the
create blob IOCTL which eventually exhausts the system memory.
This series adds a hook which allows drivers to impose their own
On Sat, Nov 9, 2019 at 1:01 AM wrote:
>
> On 2019-11-08 03:34, Daniel Vetter wrote:
> > On Thu, Nov 07, 2019 at 02:39:11PM -0500, Steve Cohen wrote:
> >> Fuzzers used in Android compliance testing repeatedly call the
> >> create blob IOCTL which eventually exhausts the system memory.
> >> This
On Thu, Nov 07, 2019 at 02:39:11PM -0500, Steve Cohen wrote:
> Fuzzers used in Android compliance testing repeatedly call the
> create blob IOCTL which eventually exhausts the system memory.
> This series adds a hook which allows drivers to impose their own
> limitations on the size and/or number
On Mon, Nov 04, 2019 at 06:23:19PM -0800, Jamal Shareef wrote:
> This patchset removes spaces after left open parenthesis.
> Issue found by checkpatch.
I'd say that those spaces make code easier to look at, so it would
be better to teach checkpatch to ignore cases like these.
Best Regards,
On Tue, 2019-11-05 at 05:53 +0100, Michał Mirosław wrote:
> On Mon, Nov 04, 2019 at 06:23:19PM -0800, Jamal Shareef wrote:
> > This patchset removes spaces after left open parenthesis.
> > Issue found by checkpatch.
>
> I'd say that those spaces make code easier to look at, so it would
> be
ping
On 2019/10/9 14:25, zhengbin wrote:
> zhengbin (3):
> drm/amd/display: Remove set but not used variables
> 'bl_pwm_cntl','pwm_period_cntl'
> drm/amd/display: Remove set but not used variable 'value0'
> drm/amd/display: Remove set but not used variables 'regval','speakers'
>
>
Hi Zheng,
Harry's previous comment about the superfluous REG_READ()s is still unaddressed.
Once that's fixed, I can give my r-b.
Thanks,
Leo
On 2019-10-28 5:32 a.m., zhengbin (A) wrote:
> ping
>
> On 2019/10/9 14:25, zhengbin wrote:
>> zhengbin (3):
>> drm/amd/display: Remove set but not
Hi
Am 28.10.19 um 13:06 schrieb Hans de Goede:
> Hi,
>
> On 28-10-2019 12:34, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 28.10.19 um 12:26 schrieb Hans de Goede:
>>> Hi Thomas,
>>>
>>> On 11-10-2019 15:48, Thomas Zimmermann wrote:
The vboxvideo driver provides its own implementation for fbdev
Hi,
On 28-10-2019 12:34, Thomas Zimmermann wrote:
Hi
Am 28.10.19 um 12:26 schrieb Hans de Goede:
Hi Thomas,
On 11-10-2019 15:48, Thomas Zimmermann wrote:
The vboxvideo driver provides its own implementation for fbdev emulation
and framebuffers. Both can be replaced by DRM's generic code.
Hi
Am 28.10.19 um 12:26 schrieb Hans de Goede:
> Hi Thomas,
>
> On 11-10-2019 15:48, Thomas Zimmermann wrote:
>> The vboxvideo driver provides its own implementation for fbdev emulation
>> and framebuffers. Both can be replaced by DRM's generic code.
>>
>> All patches have been tested on
Hi Thomas,
On 11-10-2019 15:48, Thomas Zimmermann wrote:
The vboxvideo driver provides its own implementation for fbdev emulation
and framebuffers. Both can be replaced by DRM's generic code.
All patches have been tested on VirtualBox 6.0.12.
Thomas Zimmermann (3):
drm/vboxvideo: Switch to
(cc: Gerd)
Am 28.10.19 um 09:45 schrieb Thomas Zimmermann:
> Udl's GEM implementation is mostly SHMEM and we should attempt to
> replace it with the latter.
>
> Patches #1 and #2 update udl to simplify the conversion. In patch #3
> the udl code is being replaced by SHMEM. The GEM object's mmap()
301 - 400 of 706 matches
Mail list logo
