On Tue, 12 May 2020 at 09:06, Ilia Mirkin wrote:
>
> On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote:
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> > b/drivers/gpu/drm/nouveau/nouveau_connector.c
> > index 43bcbb6d73c4..6dae00da5d7e 100644
> > --- a/drivers/gpu/drm/nouveau/nouv
On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote:
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 43bcbb6d73c4..6dae00da5d7e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connec
Currently, the nv50_mstc_mode_valid() function is happy to take any and
all modes, even the ones we can't actually support sometimes like
interlaced modes.
Luckily, the only difference between the mode validation that needs to
be performed for MST vs. SST is that eventually we'll need to check the
This just limits the BPC for MST connectors to a maximum of 8 from
nv50_mstc_get_modes(), instead of doing so during
nv50_msto_atomic_check(). This doesn't introduce any functional changes
yet (other then userspace now lying about the max bpc, but we can't
support that yet anyway so meh). But, we'l
Right now, we make the mistake of allowing interlacing on all
connectors. Nvidia hardware does not always support interlacing with DP
though, so we need to make sure that we don't allow interlaced modes to
be set in such situations as otherwise we'll end up accidentally hanging
the display HW.
Thi
We advertise being able to set interlaced modes, so let's actually make
sure to do that. Otherwise, we'll end up hanging the display engine due
to trying to set a mode with timings adjusted for interlacing without
telling the hardware it's actually an interlaced mode.
Signed-off-by: Lyude Paul
--
Currently, nouveau doesn't actually bother to try probing whether or not
it can actually handle interlaced modes over DisplayPort. As a result,
on volta and later we'll end up trying to set an interlaced mode even
when it's not supported and cause the front end for the display engine
to hang.
So,
We'll need the core channel initialized and ready by the time that we
start creating modesetting objects, so that we can call the
NV507D_GET_CAPABILITIES method to make the hardware expose it's
modesetting capabilities for later probing.
So, when loading the driver prepare the core channel from wi
On Mon, 11 May 2020 at 21:43, Dave Airlie wrote:
>
> On Tue, 12 May 2020 at 06:28, Alex Deucher wrote:
> >
> > On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir
> > wrote:
> > >
> > > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > > > Hi guys,
> > >
> > > > Well let's face it AGP i
On Tue, 12 May 2020 at 06:28, Alex Deucher wrote:
>
> On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir wrote:
> >
> > On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > > Hi guys,
> >
> > > Well let's face it AGP is a total headache to maintain and dead for at
> > > least 10+ years.
>
On Mon, May 11, 2020 at 4:22 PM Al Dunsmuir wrote:
>
> On Monday, May 11, 2020, 1:17:19 PM, "Christian König" wrote:
> > Hi guys,
>
> > Well let's face it AGP is a total headache to maintain and dead for at
> > least 10+ years.
>
> > We have a lot of x86 specific stuff in the architecture indepen
On Mon, May 11, 2020 at 1:17 PM Christian König
wrote:
>
> AGP is deprecated for 10+ years now and not used any more on modern hardware.
>
> Old hardware should continue to work in PCI mode.
Might want to clarify that there is no loss of functionality here.
Something like:
"There is no loss of f
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/Makefile | 1 -
drivers/gpu/drm/ttm/ttm_agp_backend.c | 150 --
include/drm/ttm/ttm_set_memory.h | 44
include/drm/ttm/ttm_tt.h | 22
4 files changed, 21
AGP is deprecated for 10+ years now and not used any more on modern hardware.
Old hardware should continue to work in PCI mode.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/Makefile| 4 +-
drivers/gpu/drm/radeon/evergreen.c | 7 -
drivers/gpu/drm/radeon/r100.c
AGP is deprecated for 10+ years now and not used any more on modern hardware.
Old hardware should continue to work in PCI mode.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 16 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 46 +
drivers/gpu/drm/n
Hi guys,
Well let's face it AGP is a total headache to maintain and dead for at least
10+ years.
We have a lot of x86 specific stuff in the architecture independent graphics
memory management to get the caching right, abusing the DMA API on multiple
occasions, need to distinct between AGP and
On 5/8/20 8:17 PM, Matthew Wilcox wrote:
On Fri, May 08, 2020 at 01:17:55PM -0700, Ralph Campbell wrote:
On 5/8/20 12:59 PM, Matthew Wilcox wrote:
On Fri, May 08, 2020 at 12:20:03PM -0700, Ralph Campbell wrote:
hmm_range_fault() returns an array of page frame numbers and flags for
how the pa
On Mon, May 11, 2020 at 4:49 PM Tejun Heo wrote:
>
> Hello,
>
> On Fri, May 08, 2020 at 04:46:51PM -0400, Lyude Paul wrote:
> > +bool kthread_queue_flush_work(struct kthread_work *work,
> > + struct kthread_flush_work *fwork);
> > +void __kthread_flush_work_fn(struct kthr
On Fri, May 08, 2020 at 04:46:52PM -0400, Lyude Paul wrote:
> Add some simple wrappers around incrementing/decrementing
> kthread_work.cancelling under lock, along with checking whether queuing
> is currently allowed on a given kthread_work, which we'll use want to
> implement work cancelling with
Hello,
On Fri, May 08, 2020 at 04:46:51PM -0400, Lyude Paul wrote:
> +bool kthread_queue_flush_work(struct kthread_work *work,
> + struct kthread_flush_work *fwork);
> +void __kthread_flush_work_fn(struct kthread_work *work);
As an exposed interface, this doesn't seem gr
On Fri, May 08, 2020 at 04:40:09PM +0200, Arnd Bergmann wrote:
> CONFIG_DEVICE_PRIVATE cannot be selected in configurations
> without ZONE_DEVICE:
>
> WARNING: unmet direct dependencies detected for DEVICE_PRIVATE
> Depends on [n]: ZONE_DEVICE [=n]
> Selected by [y]:
> - DRM_NOUVEAU_SVM [=y]
On Sat, May 09, 2020 at 05:16:12PM -0700, Andrew Morton wrote:
> On Fri, 1 May 2020 15:20:44 -0300 Jason Gunthorpe wrote:
>
> > From: Jason Gunthorpe
> >
> > There is no reason for a user to select this or not directly - it should
> > be selected by drivers that are going to use the feature, s
22 matches
Mail list logo
