m not from Loongson, just some user trying to
> mess around it.
There are some purposed "workarounds" like reducing the link speed (from
x16 to x8), tweaking the power management setting, etc. Someone even
claims improving the heat sink of the LS7A chip can help to work around
thi
On Mon, 2022-07-04 at 13:04 +0200, Javier Martinez Canillas wrote:
> Hello Xi,
> >
> > With CONFIG_SYSFB_SIMPLEFB and CONFIG_FB_SIMPLE enabled, there is no
> > issue.
> >
> > I guess it's something going wrong on a "drm -> drm" pass over. For now
> > I'll continue to use simpledrm with this comm
On Fri, 2022-06-17 at 08:46 +0200, Javier Martinez Canillas wrote:
> Hello Zack,
>
> On 6/17/22 03:35, Zack Rusin wrote:
> > On Fri, 2022-06-17 at 01:21 +0200, Javier Martinez Canillas wrote:
> > > On 6/17/22 00:18, Javier Martinez Canillas wrote:
> > > > On 6/16/22 23:03, Zack Rusin wrote:
> > >
On Mon, 2022-07-04 at 17:36 +0800, Xi Ruoyao wrote:
> > Yes, please do. Either with CONFIG_SYSFB_SIMPLEFB disabled and CONFIG_FB_EFI
> > enabled (so that "efi-framebuffer" is registered and efifb probed) or with
> > CONFIG_SYSFB_SIMPLEFB but CONFIG_FB_SIMPLE enabled (s
On 2021-03-30 15:24 +0200, Christian König wrote:
> Am 30.03.21 um 15:23 schrieb Dan Horák:
> > On Tue, 30 Mar 2021 21:09:12 +0800
> > Xi Ruoyao wrote:
> >
> > > On 2021-03-30 21:02 +0800, Xi Ruoyao wrote:
> > > > On 2021-03-30 14:55 +0200, Christian Kön
On 2021-03-30 03:40 +0800, Xi Ruoyao wrote:
> On 2021-03-29 21:36 +0200, Christian König wrote:
> > Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
> > > Hi Christian,
> > >
> > > I don't think there is any constraint implemented to ensure `num_entries %
>
On 2021-03-30 21:02 +0800, Xi Ruoyao wrote:
> On 2021-03-30 14:55 +0200, Christian König wrote:
> >
> > I rather see this as a kernel bug. Can you test if this code fragment
> > fixes your issue:
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
On 2021-03-30 14:55 +0200, Christian König wrote:
> Am 30.03.21 um 14:04 schrieb Xi Ruoyao:
> > On 2021-03-30 03:40 +0800, Xi Ruoyao wrote:
> > > On 2021-03-29 21:36 +0200, Christian König wrote:
> > > > Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
> > > > &g
->last - mapping->start + 1) %
AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0, then we should replace "AMDGPU_GPU_PAGE_MASK"
in "validate the parameters" with "PAGE_MASK".
I tried it and it broke userspace: Xorg startup fails with EINVAL with this
change.
On 2021-03-30 02
a" from gtk3-demo (which just renders a triangle with GL)
under Xorg, on MIPS64. See the BugLink.
> Christian.
>
> >
> > BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1549
> > Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
&g
-/issues/1549
> > > > Fixes: a39f2a8d7066 ("drm/amdgpu: nuke amdgpu_vm_bo_split_mapping v2")
> > > > Reported-by: Xi Ruoyao
> > > > Reported-by: Dan Horák
> > > > Cc: sta...@vger.kernel.org
> > > > Signed-off-by: Xi Ruoyao
> > > &
On 2021-03-29 21:36 +0200, Christian König wrote:
> Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
> > Hi Christian,
> >
> > I don't think there is any constraint implemented to ensure `num_entries %
> > AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0`. F
On 2021-03-30 02:21 +0800, Xi Ruoyao wrote:
> On 2021-03-29 20:10 +0200, Christian König wrote:
> > You need to identify the root cause of this, most likely start or last
> > are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
>
> I printk'ed the value of start & la
ork.
I'm not a kernel expert so I can't tell if there is a bug in Kees' patch, or his
patch exploits a bug in i915 or module loader.
My CPU is an i3-3217u. If a kdump is helpful I'll try to gather it.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
> On 03/26/2015 at 03:40 AM, Josh Boyer wrote:
>> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
>> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>>
>> and this patch:
I hide the patch since it has b
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
>
>
> å¨ 03/26/2015 03:40 AM, Josh Boyer åé:
Sorry for these Chinese charactor. Thunderbird generated them
and I forgot to change.
>> On Wed, Mar 25, 2015 at 01:37:41PM -0400, Josh Boyer wrote:
>>>>>>> Yeah that
tc = &intel_crtc->base;
> update_state_fb(intel_crtc->base.primary);
> return;
> }
> @@ -2469,6 +2471,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>
> drm_framebuffer_reference(c->primary->fb);
> intel_crtc->base.primary->fb = c->primary->fb;
> + intel_crtc->base.primary->state->crtc =
> &intel_crtc->base;
> + intel_crtc->base.primary->crtc = &intel_crtc->base;
> obj->frontbuffer_bits |=
> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> break;
> }
>
> which is a mash-up of:
>
> "drm/i915: Fix atomic state when reusing the firmware fb"
>
> and
>
> "drm/i915: Fixup legacy plane->crtc link for initial fb config"
>
> which you just sent out.
>
> I think that covers everything.
>
> josh
I've got an HDMI device from the laboratory. I'll help to test the solution.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
On 03/25/2015 at 10:56 PM, Xi Ruoyao wrote:
>
> On 03/25/2015 at 10:00 PM, Daniel Vetter wrote:
>> On Wed, Mar 25, 2015 at 09:11:17AM -0400, Josh Boyer wrote:
>>> On Wed, Mar 25, 2015 at 4:54 AM, Daniel Vetter wrote:
>>>>>>> commit f55548b5af87ebfc586ca
ase.primary->fb = c->primary->fb;
> + intel_crtc->base.primary->state->crtc =
> &intel_crtc->base;
> obj->frontbuffer_bits |=
> INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
> break;
> }
I found a bad thing. My buggy code also affects linux-next now because of
the manual merge on 2014-03-16.
So, Daniel and Stephen please check it and end this mess...
It's annoying to see my code caused so much trouble. I didn't test my code
with a HDMI device or I should've found this trouble before commiting. I
apologize for that again.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
>>>>>>>>>> On Tue, Mar 24, 2015 at 3:32 AM, Daniel Vetter
>>>>>>>>>> wrote:
>>>>>>>>>>> On Mon, Mar 23, 2015 at 02:34:27PM -0400, Josh Boyer wrote:
>>>>>>>>>>>> On Mon, Mar 23, 201
be done in linux-next. We should
change
Matt's update_state_fb to use drm_atomic_set_fb_for_plane since the logic of
Matt's code is duplicated with drm_atomic_set_fb_for_plane.
--
Xi Ruoyao
School of Aerospace Science and Technology
Xidian University, Xi'an, China
>state->fb
to get the framebuffer assigned to crtc->primaty. Then a framebuffer
object can be unpinned twice and a kernel BUG will be produced in i915_gem.c.
So, update crtc->primary->state->fb in intel_display.c using
drm_atomic_set_fb_for_plane to fix the BUG.
Signed-off
22 matches
Mail list logo
