https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #37 from Andrew Sheldon ---
(In reply to Daniel Suarez from comment #33)
> That workaround delays the hangs af best, and I have gotten hangs from
> OpenGl Games and also by using amdvlk.
>
Those hangs shouldn't be SDMA related,
On 11/12/19 3:14 PM, Dan Williams wrote:
...
>>
>> Is that OK, or did you want to go further (possibly in a follow-up
>> patchset, as I'm hoping to get this one in soon)?
>
> That looks ok. Something to maybe push down into the core in a future
Great! I'll post a cleaned up v4 (with the
On 11/12/19 2:45 PM, Dan Williams wrote:
> On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
>>
>> On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
>> ...
-}
+ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
+page,
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #36 from John H ---
Also, for people who have a 5700XT card, check if yours has dual BIOS's
Typically one is for running at normal clock speeds, and the other is for
running overclocked values.
My card, the Powercolor Red Devil
On Tue, Nov 12, 2019 at 3:08 PM John Hubbard wrote:
>
> On 11/12/19 2:43 PM, Dan Williams wrote:
> ...
> > Ah, sorry. This was the first time I had looked at this series and
> > jumped in without reading the background.
> >
> > Your patch as is looks ok, I assume you've removed the FOLL_LONGTERM
On 11/12/19 2:43 PM, Dan Williams wrote:
...
> Ah, sorry. This was the first time I had looked at this series and
> jumped in without reading the background.
>
> Your patch as is looks ok, I assume you've removed the FOLL_LONGTERM
> warning in get_user_pages_remote in another patch?
>
On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
>
> On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
> ...
> >> -}
> >> +ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
> >> +page, vmas, NULL);
> >> +/*
> >> + * The
On Tue, Nov 12, 2019 at 2:24 PM John Hubbard wrote:
>
> On 11/12/19 1:57 PM, Dan Williams wrote:
> ...
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c
> >> b/drivers/vfio/vfio_iommu_type1.c
> >> index d864277ea16f..017689b7c32b 100644
> >> --- a/drivers/vfio/vfio_iommu_type1.c
> >> +++
On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
...
>> -}
>> +ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
>> +page, vmas, NULL);
>> +/*
>> + * The lifetime of a vaddr_get_pfn() page pin is
>> + *
On 11/12/19 1:57 PM, Dan Williams wrote:
...
>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>> b/drivers/vfio/vfio_iommu_type1.c
>> index d864277ea16f..017689b7c32b 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -348,24 +348,20 @@ static int
On Tue, Nov 12, 2019 at 03:26:35PM +0100, Daniel Vetter wrote:
> On Tue, Nov 12, 2019 at 3:06 PM Christoph Hellwig wrote:
> > On Tue, Nov 12, 2019 at 02:04:16PM +0100, Daniel Vetter wrote:
> > > Wut ... Maybe I'm missing something, but from how we use mtrr in other
> > > gpu drivers it's a)
For gen12+ architectures, i915 no longer supports use of GET_TILING
ioctl [1]. This breaks the usage of two libdrm functions on those
platforms:
drm_intel_bo_gem_create_from_name() and
drm_intel_bo_gem_create_from_prime().
We also have IGTs which test drm_intel_gem_bo_flink() followed by
On Tue, Nov 12, 2019 at 03:06:31PM +0100, Christoph Hellwig wrote:
> On Tue, Nov 12, 2019 at 02:04:16PM +0100, Daniel Vetter wrote:
> > Wut ... Maybe I'm missing something, but from how we use mtrr in other
> > gpu drivers it's a) either you use MTRR because that's all you got or
> > b) you use
On Tue, Nov 12, 2019 at 10:31 PM Rob Herring wrote:
>
> On Tue, Nov 12, 2019 at 1:06 PM Daniel Vetter wrote:
> >
> > On Tue, Nov 12, 2019 at 09:37:45AM -0600, Rob Herring wrote:
> > > On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Nov 12, 2019 at 09:52:54AM +0100,
Booting the adreno driver on a imx53 board leads to the following
error message:
adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU
powerlevels
As the "qcom,gpu-pwrlevels" property is optional and never present on
i.MX5, turn the message into debug level instead.
On Mon, Nov 11, 2019 at 4:07 PM John Hubbard wrote:
>
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_remote()
On Tue, Nov 12, 2019 at 07:35:53PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: amd-gfx On Behalf Of
> > Bjorn Helgaas
> > Sent: Tuesday, November 12, 2019 12:35 PM
> > To: Deucher, Alexander ; Koenig, Christian
> > ; Zhou, David(ChunMing)
> > ; David Airlie ; Daniel
LGTM, thanks,
Reviewed-by: Dave Airlie
On Sat, 9 Nov 2019 at 10:52, Manasi Navare wrote:
>
> In case of tiled displays, if we hotplug just one connector,
> fbcon currently just selects the preferred mode and if it is
> tiled mode then that becomes a problem if rest of the tiles are
> not
On Tue, Nov 12, 2019 at 1:06 PM Daniel Vetter wrote:
>
> On Tue, Nov 12, 2019 at 09:37:45AM -0600, Rob Herring wrote:
> > On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
> > >
> > > On Tue, Nov 12, 2019 at 09:52:54AM +0100, Gerd Hoffmann wrote:
> > > > On Fri, Nov 08, 2019 at 05:55:28PM
On 11/12/19 12:44 PM, Jason Gunthorpe wrote:
> On Mon, Nov 11, 2019 at 04:06:48PM -0800, John Hubbard wrote:
>> @@ -542,7 +541,7 @@ static int ib_umem_odp_map_dma_single_page(
>> }
>>
>> out:
>> -put_user_page(page);
>> +put_page(page);
>>
>> if (remove_existing_mapping) {
On 11/12/19 12:38 PM, Jason Gunthorpe wrote:
> On Mon, Nov 11, 2019 at 04:06:37PM -0800, John Hubbard wrote:
>> Hi,
>>
>> The cover letter is long, so the more important stuff is first:
>>
>> * Jason, if you or someone could look at the the VFIO cleanup (patch 8)
>> and conversion to FOLL_PIN
On Tue, Nov 12, 2019 at 9:57 PM Noralf Trønnes wrote:
> Den 12.11.2019 18.50, skrev Daniel Vetter:
> > There's a pile of things protecting against racing hotunplugs:
> > - drm_dev_enter/exit against the underlying device disappearing
> > - drm_dev_get/put against drm_device disappearing
> > - we
Den 12.11.2019 18.50, skrev Daniel Vetter:
> There's a pile of things protecting against racing hotunplugs:
> - drm_dev_enter/exit against the underlying device disappearing
> - drm_dev_get/put against drm_device disappearing
> - we unregister everything in drm_dev_unregister to stop userspace
Den 12.11.2019 18.50, skrev Daniel Vetter:
> Not sure we don't yet have this as a patch somewhere ...
>
> Motivation is that the automatic lifetime management of the generic fbdev
> code is quite tricky, and it'll get even more tricky. Allowing drivers
> to just use the fb_probe looks like a
On Tue, Nov 12, 2019 at 08:32:07AM -0800, Rob Clark wrote:
> On Tue, Nov 12, 2019 at 6:01 AM Daniel Vetter wrote:
> >
> > On Tue, Nov 12, 2019 at 11:40:01AM +0100, Johan Hovold wrote:
> > > On Wed, Oct 30, 2019 at 11:01:46AM +0100, Johan Hovold wrote:
> > > > On Thu, Oct 10, 2019 at 03:13:30PM
On 2019-11-11 7:28 a.m., YueHaibing wrote:
> Fix a build warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
> warning: 'static' is not at beginning of declaration
> [-Wold-style-declaration]
>
> Signed-off-by: YueHaibing
Reviewed-by: Harry Wentland
Harry
> ---
>
On 2019-11-12 2:51 a.m., Yuehaibing wrote:
> On 2019/11/12 10:39, Joe Perches wrote:
>> On Mon, 2019-11-11 at 20:28 +0800, YueHaibing wrote:
>>> Fix a build warning:
>>>
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
>>> warning: 'static' is not at beginning of declaration
>>>
On Tue, Nov 12, 2019 at 10:17:10AM -0800, Yiwei Zhang wrote:
> Hi folks,
>
> What do you think about:
> > For the sysfs approach, I'm assuming the upstream vendors still need
> > to provide a pair of UMD and KMD, and this ioctl to label the BO is
> > kept as driver private ioctl. Then will each
On Tue, Nov 12, 2019 at 8:13 PM John Donnelly
wrote:
>
>
>
> > On Nov 11, 2019, at 9:57 AM, Thomas Zimmermann wrote:
> >
> > Hi John
> >
> > Am 08.11.19 um 19:07 schrieb John Donnelly:
> >>
> >>
> >>> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote:
> >>>
> >>> Hi
> >>>
> >>> Am 08.11.19 um
On Tue, Nov 12, 2019 at 06:59:40PM +0100, Torsten Duwe wrote:
>
> The anx6345 driver originally was copied from anx78xx.c, which has meanwhile
> seen a few changes. In particular, the removal of drm_dp_link helpers and the
> discontinuation to include drm_bridge.h from drm_crtc.h breaks
> -Original Message-
> From: amd-gfx On Behalf Of
> Bjorn Helgaas
> Sent: Tuesday, November 12, 2019 12:35 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
>
> Cc: Frederick Lawler ; linux-...@vger.kernel.org;
> Michel Dänzer ;
> On Nov 11, 2019, at 9:57 AM, Thomas Zimmermann wrote:
>
> Hi John
>
> Am 08.11.19 um 19:07 schrieb John Donnelly:
>>
>>
>>> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote:
>>>
>>> Hi
>>>
>>> Am 08.11.19 um 13:55 schrieb John Donnelly:
> On Nov 8, 2019, at 1:46 AM,
On Tue, Nov 12, 2019 at 09:37:45AM -0600, Rob Herring wrote:
> On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
> >
> > On Tue, Nov 12, 2019 at 09:52:54AM +0100, Gerd Hoffmann wrote:
> > > On Fri, Nov 08, 2019 at 05:55:28PM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 08, 2019 at
https://bugs.freedesktop.org/show_bug.cgi?id=112103
erik.brandsb...@gmail.com changed:
What|Removed |Added
Priority|not set |high
--- Comment #1 from
On Tue, Nov 12, 2019 at 08:09:09PM +0300, Wambui Karuga wrote:
> Add the DRM_DEV_WARN helper macro for printing warnings
> that use device pointers in their log output format.
> DRM_DEV_WARN can replace the use of dev_warn in such cases.
>
> Signed-off-by: Wambui Karuga
Can you pls include this
On Tue, Nov 12, 2019 at 2:00 PM Mihail Atanassov
wrote:
>
> On Monday, 11 November 2019 15:53:14 GMT Liviu Dudau wrote:
> > On Thu, Nov 07, 2019 at 11:42:44AM +, Mihail Atanassov wrote:
> > > It's possible to get multiple events in a single frame/flip, so add an
> > > option to print them
guess the
> next rebase will change these. next-20191112 plus the anx6345-v5a series plus
> this patch compile cleanly on arm64.
>
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -19,6 +19,7 @@
> #incl
.
Signed-off-by: Torsten Duwe
---
The commits in question are ff1e8fb68ea06 and ee68c743f8d07, but I guess the
next rebase will change these. next-20191112 plus the anx6345-v5a series plus
this patch compile cleanly on arm64.
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu
Not sure we don't yet have this as a patch somewhere ...
Motivation is that the automatic lifetime management of the generic fbdev
code is quite tricky, and it'll get even more tricky. Allowing drivers
to just use the fb_probe looks like a recipe for disaster.
Cc: Gerd Hoffmann
Cc: Noralf
There's a pile of things protecting against racing hotunplugs:
- drm_dev_enter/exit against the underlying device disappearing
- drm_dev_get/put against drm_device disappearing
- we unregister everything in drm_dev_unregister to stop userspace from
creating new open files to access the
From: Bjorn Helgaas
Add definitions for the Enter Compliance and Transmit Margin fields of the
PCIe Link Control 2 register.
Signed-off-by: Bjorn Helgaas
---
include/uapi/linux/pci_regs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/pci_regs.h
From: Bjorn Helgaas
Previously we masked PCIe Link Control 2 register values with "7 << 9",
which was apparently intended to be the Transmit Margin field, but instead
was the high order bit of Transmit Margin, the Enter Modified Compliance
bit, and the Compliance SOS bit.
Correct the mask to "7
From: Bjorn Helgaas
amdgpu and radeon do a bit of mucking with the PCIe Link Control 2
register, some of it using hard-coded magic numbers. The idea here is to
replace those with #defines.
Since v2:
- Fix a gpu_cfg2 case in amdgpu/si.c that I had missed
- Separate out the functional
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descriptive PCI_EXP_LNKCTL2
definitions. No functional change intended.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/cik.c | 22 ++
drivers/gpu/drm/amd/amdgpu/si.c |
On Tue, Nov 12, 2019 at 05:45:15PM +0100, Michel Dänzer wrote:
> On 2019-11-11 8:29 p.m., Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > Add definitions for these PCIe Link Control 2 register fields:
> >
> > Enter Compliance
> > Transmit Margin
> >
> > and use them in amdgpu and
https://bugs.freedesktop.org/show_bug.cgi?id=98376
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=112235
Sylvain BERTRAND changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=112254
vishu.201...@gmail.com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=112254
vishu.201...@gmail.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=112254
Bug ID: 112254
Summary: DRM>> video not playing
Product: DRI
Version: XOrg git
Hardware: PowerPC
OS: All
Status: NEW
Severity: critical
https://bugs.freedesktop.org/show_bug.cgi?id=112235
--- Comment #5 from Sylvain BERTRAND ---
ok, seems I got it: was weird I got no debug infos with a constant crash
location in a debug build... because the crash was... in c++ cr*p, namely llvm,
which had no debug infos since I did a release
On Fri, Nov 08, 2019 at 10:32:52PM +0100, Arnd Bergmann wrote:
> The timespec structure and associated interfaces are deprecated and will
> be removed in the future because of the y2038 overflow.
>
> The use of ktime_to_timespec() in timeout_to_jiffies() does not
> suffer from that overflow, but
https://bugzilla.kernel.org/show_bug.cgi?id=205497
V.I.S. (itemc...@mail.ru) changed:
What|Removed |Added
CC||itemc...@mail.ru
--- Comment
On Tue, Nov 12, 2019 at 01:40:22PM -0300, Fabio Estevam wrote:
> Hi Jordan,
>
> On Fri, Nov 1, 2019 at 11:52 AM Jordan Crouse wrote:
>
> > I'm good with this. This really should only be around for
> > compatibility with downstream device tree files which should mean nothing
> > for
> > I.MX5.
On Mon, Nov 11, 2019 at 03:47:22AM -0800, Devarsh Thakkar wrote:
> For the scenario where user may require to modeset with a mode
> supporting a fractional value for vertical refresh-rate,
> appropriate mode can be selected by searching for mode
> having matching fractional vertical refresh rate
On 2019-11-11 8:29 p.m., Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> Add definitions for these PCIe Link Control 2 register fields:
>
> Enter Compliance
> Transmit Margin
>
> and use them in amdgpu and radeon.
>
> NOTE: This is a functional change because "7 << 9" was apparently a
On Tue, Nov 12, 2019 at 9:23 AM Böszörményi Zoltán wrote:
> But no, all GPU devices (now only one, the UDL device) have screen 0
> (a.k.a. DISPLAY=:0.0) set when AutoBindGPU is true:
>
> [ 2444.576] xf86AutoConfigOutputDevices: xf86NumScreens 2 xf86NumGPUScreens 1
> [ 2444.576]
Hi Jordan,
On Fri, Nov 1, 2019 at 11:52 AM Jordan Crouse wrote:
> I'm good with this. This really should only be around for
> compatibility with downstream device tree files which should mean nothing for
> I.MX5.
May I resend it with your Reviewed-by tag?
Thanks
On Tue, Nov 12, 2019 at 6:01 AM Daniel Vetter wrote:
>
> On Tue, Nov 12, 2019 at 11:40:01AM +0100, Johan Hovold wrote:
> > On Wed, Oct 30, 2019 at 11:01:46AM +0100, Johan Hovold wrote:
> > > On Thu, Oct 10, 2019 at 03:13:30PM +0200, Johan Hovold wrote:
> > > > If a process is interrupted while
On Tue, Nov 12, 2019 at 7:51 AM Enric Balletbo Serra
wrote:
>
> Hi Rob,
>
> Missatge de Rob Clark del dia dl., 4 de nov.
> 2019 a les 18:42:
> >
> > From: Rob Clark
> >
> > The new state should not be accessed after this point. Clear the
> > pointers to make that explicit.
> >
> >
Hi Heiko,
On 11/8/19 1:02 AM, Heiko Stuebner wrote:
> If implementation-specific phy_ops need to be defined they probably
> should be enabled before trying to talk to the panel and disabled only
> after the panel was disabled.
>
> Right now they are enabled last and disabled first, so might make
On Tue, Nov 12, 2019 at 3:13 AM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function
> get_pbn_from_timing:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2364:11: warning:
> variable bpc set but
On 12-11-19 16:08, Ville Syrjälä wrote:
On Tue, Nov 12, 2019 at 03:18:21PM +0100, Bas Vermeulen wrote:
Hello,
I am trying to create a new display mode for a new display I have to
support.
I have the following information:
Dotclock - frequency period - 1/TCLP - 89.6 MHz
Hi Rob,
Missatge de Rob Clark del dia dl., 4 de nov.
2019 a les 18:42:
>
> From: Rob Clark
>
> The new state should not be accessed after this point. Clear the
> pointers to make that explicit.
>
> Signed-off-by: Rob Clark
While looking to another issue I applied this patch on top of 5.4-rc7
Hi,
On Tue 12 Nov 19, 16:11, Paul Kocialkowski wrote:
> Hi,
>
> On Tue 12 Nov 19, 11:20, Patrik Jakobsson wrote:
> > On Thu, Nov 7, 2019 at 4:30 PM Paul Kocialkowski
> > wrote:
> > >
> > > psbfb_probe performs an evaluation of the required size from the stolen
> > > GTT memory, but gets it
On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
>
> On Tue, Nov 12, 2019 at 09:52:54AM +0100, Gerd Hoffmann wrote:
> > On Fri, Nov 08, 2019 at 05:55:28PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 08, 2019 at 05:27:59PM +0100, Daniel Vetter wrote:
> > > > On Fri, Oct 25, 2019 at
On Mon, Oct 28, 2019 at 12:38:14PM +0200, Jani Nikula wrote:
> Resend of [1]; I may have rebased but I'm not sure anymore...
>
> For starters some fairly benign cleanup, and a proposal for new struct
> drm_device based drm logging macros analoguous to core kernel struct
> device based macros.
>
On Tue, Nov 12, 2019 at 3:51 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 12.11.19 um 15:31 schrieb Daniel Vetter:
> > On Tue, Nov 12, 2019 at 3:03 PM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> Am 12.11.19 um 14:40 schrieb Daniel Vetter:
> >>> On Tue, Nov 12, 2019 at 12:55 PM Thomas
Hi,
On Tue 12 Nov 19, 11:20, Patrik Jakobsson wrote:
> On Thu, Nov 7, 2019 at 4:30 PM Paul Kocialkowski
> wrote:
> >
> > psbfb_probe performs an evaluation of the required size from the stolen
> > GTT memory, but gets it wrong in two distinct ways:
> > - The resulting size must be
https://bugzilla.kernel.org/show_bug.cgi?id=205497
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
Attachment #285881|0 |1
is
On Tue, Nov 12, 2019 at 03:18:21PM +0100, Bas Vermeulen wrote:
> Hello,
>
> I am trying to create a new display mode for a new display I have to
> support.
>
> I have the following information:
>
> Dotclock - frequency period - 1/TCLP - 89.6 MHz
> TCDP - 11,16 ns
Hi all,
Dave and me chatted about this last week on irc. Essentially we have:
$ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c'
drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0
drivers/gpu/drm/drm_damage_helper.c:// SPDX-License-Identifier: GPL-2.0 OR MIT
https://bugzilla.kernel.org/show_bug.cgi?id=205497
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
Hi
Am 12.11.19 um 15:31 schrieb Daniel Vetter:
> On Tue, Nov 12, 2019 at 3:03 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 12.11.19 um 14:40 schrieb Daniel Vetter:
>>> On Tue, Nov 12, 2019 at 12:55 PM Thomas Zimmermann
>>> wrote:
Hi
Am 08.11.19 um 16:37 schrieb Noralf
Hello,
I am trying to create a new display mode for a new display I have to
support.
I have the following information:
Dotclock - frequency period - 1/TCLP - 89.6 MHz
TCDP - 11,16 ns
Hsync - Period - TH - 2048 dotclock, 43,75 KHz, 22,86 us
Pulse Width -
On Tue, Nov 12, 2019 at 11:38:19AM +0100, Gerd Hoffmann wrote:
> On Tue, Nov 12, 2019 at 10:49:21AM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 12.11.19 um 10:32 schrieb Daniel Vetter:
> > > On Tue, Nov 12, 2019 at 10:26:44AM +0100, Thomas Zimmermann wrote:
> > >> Hi
> > >>
> > >> Am
On Tue, Nov 12, 2019 at 3:03 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 12.11.19 um 14:40 schrieb Daniel Vetter:
> > On Tue, Nov 12, 2019 at 12:55 PM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> Am 08.11.19 um 16:37 schrieb Noralf Trønnes:
> >>>
> >>>
> >>> Den 08.11.2019 13.33, skrev
On 08/11/2019 01:02, Heiko Stuebner wrote:
> If implementation-specific phy_ops need to be defined they probably
> should be enabled before trying to talk to the panel and disabled only
> after the panel was disabled.
>
> Right now they are enabled last and disabled first, so might make it
>
On Tue, Nov 12, 2019 at 3:06 PM Christoph Hellwig wrote:
> On Tue, Nov 12, 2019 at 02:04:16PM +0100, Daniel Vetter wrote:
> > Wut ... Maybe I'm missing something, but from how we use mtrr in other
> > gpu drivers it's a) either you use MTRR because that's all you got or
> > b) you use pat. Mixing
2019. 11. 05. 15:22 keltezéssel, Böszörményi Zoltán írta:
Hi,
2019. 10. 23. 15:32 keltezéssel, Ilia Mirkin írta:
On Wed, Oct 23, 2019 at 2:41 AM Böszörményi Zoltán wrote:
2019. 10. 22. 22:57 keltezéssel, Ilia Mirkin írta:
On Tue, Oct 22, 2019 at 11:50 AM Böszörményi Zoltán wrote:
Section
There are no external callers of unlink_framebuffer() left. Make the
function an internal interface.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fbmem.c | 3 +--
include/linux/fb.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git
The udl driver can use the generic fbdev emulation. After conversion,
a number of cleanups can be applied.
Patch 1 prepares the prefered defaults. 32 bpp work well with driver,
console and X11. The fbdev conversion is in patch 2. The original fbdev
code in udl mapped the framebuffer's GEM object
The udl driver only supports color depths that are powers of two.
Change prefered default to 32 bpp.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_modeset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
Udl used to have a custom implementation for free_object() of
struct drm_gem_object_funcs. It unmapped the memory buffer of
the fbdev emulation. With the switch to generic fbdev emulation,
this is now handled by the fbdev code internally.
Signed-off-by: Thomas Zimmermann
---
The udl driver can use the generic fbdev implementation. Convert it.
v3:
* remove module parameter fb_bpp in favor of fbdev's video
* call drm_fbdev_generic_setup() directly; remove udl_fbdev_init()
* use default for struct drm_mode_config_funcs.output_poll_changed
There are no callers of drm_fb_helper_unlink_fbi() left. Remove the
function.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 16 +---
include/drm/drm_fb_helper.h | 6 --
2 files changed, 1 insertion(+), 21 deletions(-)
diff --git
Hi
Am 12.11.19 um 14:40 schrieb Daniel Vetter:
> On Tue, Nov 12, 2019 at 12:55 PM Thomas Zimmermann
> wrote:
>>
>> Hi
>>
>> Am 08.11.19 um 16:37 schrieb Noralf Trønnes:
>>>
>>>
>>> Den 08.11.2019 13.33, skrev Thomas Zimmermann:
The udl driver can use the generic fbdev implementation.
On Tue, Nov 12, 2019 at 11:40:01AM +0100, Johan Hovold wrote:
> On Wed, Oct 30, 2019 at 11:01:46AM +0100, Johan Hovold wrote:
> > On Thu, Oct 10, 2019 at 03:13:30PM +0200, Johan Hovold wrote:
> > > If a process is interrupted while accessing the "gpu" debugfs file and
> > > the drm device
On Tue, Nov 12, 2019 at 2:39 PM Hans de Goede wrote:
>
> Hi,
>
> On 12-11-2019 14:32, Daniel Vetter wrote:
> > On Tue, Nov 12, 2019 at 11:43 AM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 12-11-2019 10:47, Daniel Vetter wrote:
> >>> On Sun, Nov 10, 2019 at 04:41:01PM +0100, Hans de Goede
On Tue, Nov 12, 2019 at 12:55 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 08.11.19 um 16:37 schrieb Noralf Trønnes:
> >
> >
> > Den 08.11.2019 13.33, skrev Thomas Zimmermann:
> >> The udl driver can use the generic fbdev implementation. Convert it.
> >>
> >> Signed-off-by: Thomas Zimmermann
> >>
Hi,
On 12-11-2019 14:32, Daniel Vetter wrote:
On Tue, Nov 12, 2019 at 11:43 AM Hans de Goede wrote:
Hi,
On 12-11-2019 10:47, Daniel Vetter wrote:
On Sun, Nov 10, 2019 at 04:41:01PM +0100, Hans de Goede wrote:
If the new video=... panel_orientation option is set for a connector, honor
it
On Tue, Nov 12, 2019 at 11:43 AM Hans de Goede wrote:
>
> Hi,
>
> On 12-11-2019 10:47, Daniel Vetter wrote:
> > On Sun, Nov 10, 2019 at 04:41:01PM +0100, Hans de Goede wrote:
> >> If the new video=... panel_orientation option is set for a connector, honor
> >> it and setup a matching "panel
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-5.2
head: a48b0cc1cdf3900e3e73801f9de64afbb70dc193
commit: c7c81b24394a38d14607a15614ebea5da335ebd7 [2713/2834] drm/amdkcl: drop
kcl_drm_get_format_name
reproduce:
# apt-get install sparse
# sparse version:
On Tue, Nov 12, 2019 at 11:55 AM Christoph Hellwig wrote:
>
> On Mon, Nov 11, 2019 at 08:22:50PM +0100, Arnd Bergmann wrote:
> > ioremap_uc() is only meaningful on old x86-32 systems with the PAT
> > extension, and on ia64 with its slightly unconventional ioremap()
> > behavior, everywhere else
On Monday, 11 November 2019 15:53:14 GMT Liviu Dudau wrote:
> On Thu, Nov 07, 2019 at 11:42:44AM +, Mihail Atanassov wrote:
> > It's possible to get multiple events in a single frame/flip, so add an
> > option to print them all.
> >
> > Reviewed-by: James Qian Wang (Arm Technology China)
> >
On 11/1/19 2:05 PM, Emil Velikov wrote:
> From: Emil Velikov
>
> With earlier commit 9c84aeba67cc ("drm/vmwgfx: Kill unneeded legacy
> security features") we removed the no longer applicable validation, as
> we now have isolation of primary clients from different master realms.
>
> As of last
On 11/1/19 2:05 PM, Emil Velikov wrote:
> From: Emil Velikov
>
> With later commit we'll rework DRM authentication handling. Namely
> DRM_AUTH will not be a requirement for DRM_RENDER_ALLOW ioctls.
>
> Since vmwgfx does isolation for primary clients in different master
> realms, the DRM_AUTH can
On 11/1/19 2:05 PM, Emil Velikov wrote:
> From: Emil Velikov
>
> Move the render_client hunk for require_exist alongside the rest.
> Keeping all the reasons why an existing object is needed, in a single
> place makes it easier to follow.
>
> Cc: VMware Graphics
> Cc: Thomas Hellstrom
>
https://bugzilla.kernel.org/show_bug.cgi?id=205497
clst (claudius+ker...@hausnetz.lettenbach.com) changed:
What|Removed |Added
CC|
Hi
Am 08.11.19 um 16:37 schrieb Noralf Trønnes:
>
>
> Den 08.11.2019 13.33, skrev Thomas Zimmermann:
>> The udl driver can use the generic fbdev implementation. Convert it.
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>
>> diff --git a/drivers/gpu/drm/udl/udl_drv.c
101 - 200 of 247 matches
Mail list logo
