Originally when trying to fix the issue of runtime PM references with
non-blocking CRTCs on nv50, I ended up stumbling on this code when
trying to remove nouveau_drm->have_disp_power_ref, and attempted to fix
it to remove the dependency on have_disp_power_ref. However, Ilia Mirkin
pointed out that
Just some runtime PM fixes for some much less noticeable runtime PM ref
tracking issues that I got reminded of when fixing some unrelated issues
with nouveau.
Changes since v1:
* Don't fix CRTC RPM code in dispnv04, because it's not actually doing
anything in the first place. Just get rid of
This is something that got noticed a while ago back when I was fixing a
large number of runtime PM related issues in nouveau, but never got
fixed:
https://patchwork.freedesktop.org/series/46815/#rev7
It's not safe to iterate the entire list of CRTCs in
nv50_disp_atomic_commit(), as we could be
On Wed, 2019-08-07 at 19:06 -0400, Ilia Mirkin wrote:
> On Wed, Aug 7, 2019 at 5:55 PM Daniel Vetter wrote:
> > On Wed, Aug 07, 2019 at 05:33:00PM -0400, Lyude Paul wrote:
> > > The code claims to grab a runtime PM ref when at least one CRTC is
> > > active, but that's not actually the case as we
On Wed, Aug 7, 2019 at 5:55 PM Daniel Vetter wrote:
>
> On Wed, Aug 07, 2019 at 05:33:00PM -0400, Lyude Paul wrote:
> > The code claims to grab a runtime PM ref when at least one CRTC is
> > active, but that's not actually the case as we grab a runtime PM ref
> > whenever a CRTC is enabled
On Wed, Aug 07, 2019 at 05:33:00PM -0400, Lyude Paul wrote:
> The code claims to grab a runtime PM ref when at least one CRTC is
> active, but that's not actually the case as we grab a runtime PM ref
> whenever a CRTC is enabled regardless of it's DPMS state. Meaning that
> we can end up keeping
Just some runtime PM fixes for some much less noticeable runtime PM ref
tracking issues that I got reminded of when fixing some unrelated issues
with nouveau.
Lyude Paul (2):
drm/nouveau/dispnv04: Grab/put runtime PM refs on DPMS on/off
drm/nouveau/dispnv50: Fix runtime PM ref tracking for
The code claims to grab a runtime PM ref when at least one CRTC is
active, but that's not actually the case as we grab a runtime PM ref
whenever a CRTC is enabled regardless of it's DPMS state. Meaning that
we can end up keeping the GPU awake when there are no screens enabled,
something we don't
This is something that got noticed a while ago back when I was fixing a
large number of runtime PM related issues in nouveau, but never got
fixed:
https://patchwork.freedesktop.org/series/46815/#rev7
It's not safe to iterate the entire list of CRTCs in
nv50_disp_atomic_commit(), as we could be
https://bugs.freedesktop.org/show_bug.cgi?id=110500
--- Comment #15 from Juddy Piterson ---
If you jot a note down on paper, save it and use the rest of the sheet for your
notes. American business waste 21 million tonnes of paper per annum! Ideally,
try to have your business as paperless as
On Wed, Aug 7, 2019 at 10:45 AM Jason Gunthorpe wrote:
>
> On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote:
> > There is only a single place where the pgmap is passed over a function
> > call, so replace it with local variables in the places where we deal
> > with the pgmap.
> >
On Tue, Aug 06, 2019 at 07:05:38PM +0300, Christoph Hellwig wrote:
>
> Hi Jérôme, Ben, Felix and Jason,
>
> below is a series against the hmm tree which cleans up various minor
> bits and allows HMM_MIRROR to be built on all architectures.
>
> Diffstat:
>
> 11 files changed, 94
On Tue, Aug 06, 2019 at 07:05:45PM +0300, Christoph Hellwig wrote:
> All users pass PAGE_SIZE here, and if we wanted to support single
> entries for huge pages we should really just add a HMM_FAULT_HUGEPAGE
> flag instead that uses the huge page size instead of having the
> caller calculate that
On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote:
> There is only a single place where the pgmap is passed over a function
> call, so replace it with local variables in the places where we deal
> with the pgmap.
>
> Signed-off-by: Christoph Hellwig
> mm/hmm.c | 62
On Tue, Aug 06, 2019 at 07:05:47PM +0300, Christoph Hellwig wrote:
> pte_index is an internal arch helper in various architectures,
> without consistent semantics. Open code that calculation of a PMD
> index based on the virtual address instead.
>
> Signed-off-by: Christoph Hellwig
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=110955
--- Comment #11 from Juan A. Suarez ---
This should be fixed in Mesa 19.1.4.
Can you try?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
Do you know why xrandr rounds up to "3840x2160 59.97" but the
lubuntu GUI says "3840x2160 59.9685"?
I thought it might be the TV only does 30Hz or 60Hz but it does
fractional rates at lower resolutions.
I don't know.
Maybe it is the colour depth.
Why is my first monitor 1920x1200 for
I got this in dmesg.
I reconnected it and it works fine.
What caused that?
[ 253.203797] nouveau :07:00.0: HDMI-A-1: EDID is invalid:
[ 253.203801] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 253.203802] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct nvif_mmu_kind_v0 {
...
__u8 data[];
};
Make use of the
When memory is migrated to the GPU it is likely to be accessed by GPU
code soon afterwards. Instead of waiting for a GPU fault, map the
migrated memory into the GPU page tables with the same access permissions
as the source CPU page table entries. This preserves copy on write
semantics.
On Wed, Aug 07, 2019 at 06:57:24AM +, Koenig, Christian wrote:
> Am 06.08.19 um 22:03 schrieb Jason Gunthorpe:
> > On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote:
> >> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix
> >> wrote:
> >>> On 2019-08-06 13:44, Jason Gunthorpe wrote:
>
Am 06.08.19 um 22:03 schrieb Jason Gunthorpe:
> On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote:
>> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix
>> wrote:
>>> On 2019-08-06 13:44, Jason Gunthorpe wrote:
On Tue, Aug 06, 2019 at 07:05:53PM +0300, Christoph Hellwig wrote:
>
22 matches
Mail list logo
