Hi Daniel,
On Wed, 20 Jan 2021 13:12:21 +0100 Daniel Vetter wrote:
>
> I've pulled drm-misc-next into drm-next now, so as long as all other
> drm trees are merged after drm, this should be solved now.
> drm-intel-next also has their msm build breakage fixed (I acked the
> patch already), so
On Mon, Jan 18, 2021 at 2:06 AM Dave Airlie wrote:
>
> On Mon, 18 Jan 2021 at 10:59, Stephen Rothwell wrote:
> >
> > Hi all,
> >
> > On Mon, 11 Jan 2021 10:56:54 +1100 Stephen Rothwell
> > wrote:
> > >
> > > On Fri, 8 Jan 2021 12:25:40 +1100 Stephen Rothwell
> > > wrote:
> > > >
> > > > On
On Mon, 18 Jan 2021 at 10:59, Stephen Rothwell wrote:
>
> Hi all,
>
> On Mon, 11 Jan 2021 10:56:54 +1100 Stephen Rothwell
> wrote:
> >
> > On Fri, 8 Jan 2021 12:25:40 +1100 Stephen Rothwell
> > wrote:
> > >
> > > On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell
> > > wrote:
> > > >
> > >
Hi all,
On Mon, 11 Jan 2021 10:56:54 +1100 Stephen Rothwell
wrote:
>
> On Fri, 8 Jan 2021 12:25:40 +1100 Stephen Rothwell
> wrote:
> >
> > On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
>
Hi all,
On Fri, 8 Jan 2021 12:25:40 +1100 Stephen Rothwell
wrote:
>
> On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > error: the following would cause module name
Hi all,
On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> error: the following would cause module name conflict:
>
On Wed, Sep 30, 2020 at 06:45:02PM +0200, Paul Cercueil wrote:
>> We don't have such a thing in the Linux API at all.
>
> dma_pgprot(dev, vma->vm_page_prot, DMA_ATTR_NON_CONSISTENT);
>
> That was giving me non-coherent cached memory, and now I don't have an
> alternative.
Looking at Linux 5.9-rc
Le mer. 30 sept. 2020 à 18:40, Christoph Hellwig a écrit
:
On Wed, Sep 30, 2020 at 06:39:18PM +0200, Paul Cercueil wrote:
dma_alloc_pages gives you cached memory, so you can't just use an
uncached protection for the userspace mmap here. If you want
uncached
memory you need to use
On Wed, Sep 30, 2020 at 06:39:18PM +0200, Paul Cercueil wrote:
>> dma_alloc_pages gives you cached memory, so you can't just use an
>> uncached protection for the userspace mmap here. If you want uncached
>> memory you need to use dma_alloc_coherent paired with dma_mmap_coherent.
>> Or
Le mer. 30 sept. 2020 à 18:11, Christoph Hellwig a écrit
:
On Wed, Sep 30, 2020 at 03:33:13PM +0200, Paul Cercueil wrote:
One thing missing for remap_pfn_range(), I have no alternative for
this:
vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot,
DMA_ATTR_NON_CONSISTENT);
So I
On Wed, Sep 30, 2020 at 03:33:13PM +0200, Paul Cercueil wrote:
> One thing missing for remap_pfn_range(), I have no alternative for this:
>
> vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot,
> DMA_ATTR_NON_CONSISTENT);
>
> So I have to do:
>
> vma->vm_page_prot =
Hi Christoph,
Le mer. 30 sept. 2020 à 11:02, Christoph Hellwig a écrit
:
On Mon, Sep 28, 2020 at 03:31:28PM +0200, Paul Cercueil wrote:
It's allocated with dma_alloc_wc, but then it's only accessed as
non-coherent.
Anyway, for the time being I guess you could revert 37054fc81443.
But I
On Mon, Sep 28, 2020 at 03:31:28PM +0200, Paul Cercueil wrote:
> It's allocated with dma_alloc_wc, but then it's only accessed as
> non-coherent.
>
> Anyway, for the time being I guess you could revert 37054fc81443. But I
> have patches on top of it in drm-misc-next so it's going to be a mess.
>
Le lun. 28 sept. 2020 à 14:10, Christoph Hellwig a écrit
:
On Mon, Sep 28, 2020 at 01:46:55PM +0200, Paul Cercueil wrote:
dma_mmap_attrs can only be used on allocations from dma_mmap_attrs
with
the same attrs. As there is no allocation using
DMA_ATTR_NON_CONSISTENT
in the drm core,
On Mon, Sep 28, 2020 at 01:46:55PM +0200, Paul Cercueil wrote:
>> dma_mmap_attrs can only be used on allocations from dma_mmap_attrs with
>> the same attrs. As there is no allocation using DMA_ATTR_NON_CONSISTENT
>> in the drm core, something looks very fishy here.
>
> Is that a fact? I don't see
Le lun. 28 sept. 2020 à 13:34, Christoph Hellwig a écrit
:
On Mon, Sep 28, 2020 at 12:15:56PM +0200, Paul Cercueil wrote:
Hi Christoph,
Le lun. 28 sept. 2020 à 8:04, Christoph Hellwig a
écrit :
On Mon, Sep 28, 2020 at 01:54:05PM +1000, Stephen Rothwell wrote:
Hi all,
After
On Mon, Sep 28, 2020 at 12:15:56PM +0200, Paul Cercueil wrote:
> Hi Christoph,
>
> Le lun. 28 sept. 2020 à 8:04, Christoph Hellwig a écrit :
>> On Mon, Sep 28, 2020 at 01:54:05PM +1000, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> After merging the drm tree, today's linux-next build (x86_64
>>>
Hi Christoph,
Le lun. 28 sept. 2020 à 8:04, Christoph Hellwig a écrit :
On Mon, Sep 28, 2020 at 01:54:05PM +1000, Stephen Rothwell wrote:
Hi all,
After merging the drm tree, today's linux-next build (x86_64
allmodconfig)
failed like this:
The driver needs to switch do
On Mon, Sep 28, 2020 at 04:08:36PM +1000, Dave Airlie wrote:
> Is this possible in drm-next now (it's 5.9.0-rc5 based)?
>
> or will I need to get a stable shared git tree that goes into drm-next
> and you send to Linus early in the MR?
I think we'll need a stable branch. Let me help Paul with
On Mon, 28 Sep 2020 at 16:05, Christoph Hellwig wrote:
>
> On Mon, Sep 28, 2020 at 01:54:05PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
>
> The driver needs to switch do dma_alloc_noncoherent
On Mon, Sep 28, 2020 at 01:54:05PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
The driver needs to switch do dma_alloc_noncoherent + dma_sync_single*
like the other drivers converted in the dma tree.
I've applied this locally for now so I can continue arm64 builds :-)
Dave.
On 16 May 2018 at 18:09, Oded Gabbay wrote:
> On Wed, May 16, 2018 at 9:53 AM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> After merging the drm tree, today's linux-next
I've applied this locally for now so I can continue arm64 builds :-)
Dave.
On 16 May 2018 at 18:09, Oded Gabbay wrote:
> On Wed, May 16, 2018 at 9:53 AM, Stephen Rothwell
> wrote:
>> Hi all,
>>
>> After merging the drm tree, today's linux-next build (powerpc
>> allyesconfig) failed like this:
On Wed, May 16, 2018 at 9:53 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function
> 'init_user_pages':
>
On Wed, May 16, 2018 at 9:53 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function
> 'init_user_pages':
>
On Mon, Mar 20, 2017 at 9:03 AM, Daniel Vetter wrote:
> On Mon, Mar 20, 2017 at 1:51 AM, Stephen Rothwell
> wrote:
>> This cherry picking of fixes from new development back to Linus' tree
>> can be a real pain when so many other changes happen in
On Mon, Mar 20, 2017 at 9:03 AM, Daniel Vetter wrote:
> On Mon, Mar 20, 2017 at 1:51 AM, Stephen Rothwell
> wrote:
>> This cherry picking of fixes from new development back to Linus' tree
>> can be a real pain when so many other changes happen in the same files.
>
> One possible fix for this
On Mon, Mar 20, 2017 at 1:51 AM, Stephen Rothwell wrote:
> This cherry picking of fixes from new development back to Linus' tree
> can be a real pain when so many other changes happen in the same files.
One possible fix for this would be if you reuse our rerere cache. The
On Mon, Mar 20, 2017 at 1:51 AM, Stephen Rothwell wrote:
> This cherry picking of fixes from new development back to Linus' tree
> can be a real pain when so many other changes happen in the same files.
One possible fix for this would be if you reuse our rerere cache. The
only reason we don't go
Dave,
Here is the patch from Chris Wilson to solve the build issue:
[PATCH] drm/sti: Fix compilation failure for drm_framebuffer.pixel_format
BR
Vincent
> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: mardi 24 janvier 2017 02:25
> To: Dave Airlie
Dave,
Here is the patch from Chris Wilson to solve the build issue:
[PATCH] drm/sti: Fix compilation failure for drm_framebuffer.pixel_format
BR
Vincent
> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: mardi 24 janvier 2017 02:25
> To: Dave Airlie
>
On 7/15/16, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0:
> drivers/gpu/drm/i915/intel_opregion.c: In function
>
On 7/15/16, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/gpu/drm/i915/intel_opregion.c:34:0:
> drivers/gpu/drm/i915/intel_opregion.c: In function
>
On Thu, 28 Apr 2016, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_prepare_ddi_buffer':
>
On Thu, 28 Apr 2016, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_prepare_ddi_buffer':
> drivers/gpu/drm/i915/intel_ddi.c:447:15: error: 'struct
Hi Stephen,
yeah, indeed the release_pages() function is now used in two more files.
Your fix is Reviewed-by: Christian König .
Regards,
Christian.
Am 17.03.2016 um 05:41 schrieb Stephen Rothwell:
Hi Dave,
After merging the drm tree, today's linux-next build
Hi Stephen,
yeah, indeed the release_pages() function is now used in two more files.
Your fix is Reviewed-by: Christian König .
Regards,
Christian.
Am 17.03.2016 um 05:41 schrieb Stephen Rothwell:
Hi Dave,
After merging the drm tree, today's linux-next build (powerpc
allyesconfig) failed
Hi all,
On Thu, 31 Dec 2015 21:31:24 +1100 Stephen Rothwell
wrote:
>
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/tonga_thermal.c: In function
> 'tonga_fan_ctrl_get_fan_speed_percent':
>
Hi all,
On Thu, 31 Dec 2015 21:31:24 +1100 Stephen Rothwell
wrote:
>
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/tonga_thermal.c: In function
>
On 2015年12月31日 10:40, Stephen Rothwell wrote:
Hi Dave,
After merging the drm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
ERROR: "vop_component_ops" [drivers/gpu/drm/rockchip/rockchip_vop_reg.ko]
undefined!
Caused by commit
a67719d18229 ("drm/rockchip: vop:
On 2015年12月31日 10:40, Stephen Rothwell wrote:
Hi Dave,
After merging the drm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
ERROR: "vop_component_ops" [drivers/gpu/drm/rockchip/rockchip_vop_reg.ko]
undefined!
Caused by commit
a67719d18229 ("drm/rockchip: vop:
On Tue, Nov 10, 2015 at 1:45 AM, Guenter Roeck wrote:
> On Wed, Nov 04, 2015 at 08:22:26PM +1100, Stephen Rothwell wrote:
>> Hi Dave,
>>
>> After merging the drm tree, today's linux-next build (s390 allmodconfig)
>> failed like this:
>>
>>
On Wed, Nov 04, 2015 at 08:22:26PM +1100, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (s390 allmodconfig)
> failed like this:
>
> drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:143:2: error: implicit
> declaration of function 'dma_to_phys'
On Tue, Nov 10, 2015 at 1:45 AM, Guenter Roeck wrote:
> On Wed, Nov 04, 2015 at 08:22:26PM +1100, Stephen Rothwell wrote:
>> Hi Dave,
>>
>> After merging the drm tree, today's linux-next build (s390 allmodconfig)
>> failed like this:
>>
>>
On Wed, Nov 04, 2015 at 08:22:26PM +1100, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (s390 allmodconfig)
> failed like this:
>
> drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:143:2: error: implicit
> declaration of function 'dma_to_phys'
Hi Alex,
On Tue, 9 Jun 2015 14:02:21 + "Deucher, Alexander"
wrote:
>
> > -Original Message-
> > From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> > Sent: Tuesday, June 09, 2015 9:43 AM
> > To: Dave Airlie
> > Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org;
> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Tuesday, June 09, 2015 9:43 AM
> To: Dave Airlie
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Deucher,
> Alexander
> Subject: linux-next: build failure after merge of the drm tree
>
>
-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
Sent: Tuesday, June 09, 2015 9:43 AM
To: Dave Airlie
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Deucher,
Alexander
Subject: linux-next: build failure after merge of the drm tree
Hi Dave,
Hi Alex,
On Tue, 9 Jun 2015 14:02:21 + Deucher, Alexander
alexander.deuc...@amd.com wrote:
-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
Sent: Tuesday, June 09, 2015 9:43 AM
To: Dave Airlie
Cc: linux-n...@vger.kernel.org;
> >> > drm-next and fix it up there.
> >>
> >> Yep, against commit 79b066bd76d5 ("drm/amdkfd: Initialize sdma vm when
> >> creating sdma queue") which is in v4.1-rc3.
> >
> > So you could, of course, just merge that commit instead of Linus'
> > tree ...
> >
> > --
> > Cheers,
> > Stephen Rothwell
On Wed, May 20, 2015 at 8:31 AM, Stephen Rothwell wrote:
> Hi Dave,
>
> On Wed, 20 May 2015 15:25:38 +1000 Stephen Rothwell
> wrote:
>>
>> On Wed, 20 May 2015 05:41:46 +0100 (IST) Dave Airlie
>> wrote:
>> >
>> > > After merging the drm tree, today's linux-next build (powerpc
>> > >
drm-next and fix it up there.
Yep, against commit 79b066bd76d5 (drm/amdkfd: Initialize sdma vm when
creating sdma queue) which is in v4.1-rc3.
So you could, of course, just merge that commit instead of Linus'
tree ...
--
Cheers,
Stephen Rothwell
On Wed, May 20, 2015 at 8:31 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Dave,
On Wed, 20 May 2015 15:25:38 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
On Wed, 20 May 2015 05:41:46 +0100 (IST) Dave Airlie airl...@linux.ie
wrote:
After merging the drm tree, today's
Hi Dave,
On Wed, 20 May 2015 15:25:38 +1000 Stephen Rothwell
wrote:
>
> On Wed, 20 May 2015 05:41:46 +0100 (IST) Dave Airlie wrote:
> >
> > > After merging the drm tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > >
> > >
Hi Dave,
On Wed, 20 May 2015 05:41:46 +0100 (IST) Dave Airlie wrote:
>
> > After merging the drm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c: In function
> > 'create_queue_cpsch':
> >
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c: In function
> 'create_queue_cpsch':
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:888:2: error: implicit
>
Hi Dave,
After merging the drm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c: In function
'create_queue_cpsch':
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:888:2: error: implicit
declaration
Hi Dave,
On Wed, 20 May 2015 05:41:46 +0100 (IST) Dave Airlie airl...@linux.ie wrote:
After merging the drm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c: In function
'create_queue_cpsch':
Hi Dave,
On Wed, 20 May 2015 15:25:38 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
On Wed, 20 May 2015 05:41:46 +0100 (IST) Dave Airlie airl...@linux.ie wrote:
After merging the drm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
Hi Oded,
On Thu, 29 Jan 2015 10:21:04 +0200 Oded Gabbay wrote:
>
> So I think that Dave's drm-next now contains the correct code.
> Will you merge it again, or do you do it daily anyway ? I fear I'm entirely
> clear with the details of the linux-next process.
I fetch all the trees again each
On 01/29/2015 04:38 AM, Stephen Rothwell wrote:
After merging the drm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdkfd/kfd_device.c: In function 'kgd2kfd_device_init':
drivers/gpu/drm/amd/amdkfd/kfd_device.c:193:11: error:
On 01/29/2015 04:38 AM, Stephen Rothwell wrote:
After merging the drm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdkfd/kfd_device.c: In function 'kgd2kfd_device_init':
drivers/gpu/drm/amd/amdkfd/kfd_device.c:193:11: error:
Hi Oded,
On Thu, 29 Jan 2015 10:21:04 +0200 Oded Gabbay oded.gab...@amd.com wrote:
So I think that Dave's drm-next now contains the correct code.
Will you merge it again, or do you do it daily anyway ? I fear I'm entirely
clear with the details of the linux-next process.
I fetch all the
Hi Daniel,
On Thu, 5 Jun 2014 14:12:27 +1000 Stephen Rothwell
wrote:
>
> After merging the drm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/i915/intel_fbdev.c: In function 'intel_fb_initial_config':
> drivers/gpu/drm/i915/intel_fbdev.c:392:4:
Hi Daniel,
On Thu, 5 Jun 2014 14:12:27 +1000 Stephen Rothwell s...@canb.auug.org.au
wrote:
After merging the drm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/intel_fbdev.c: In function 'intel_fb_initial_config':
Hi Daniel,
On Mon, 24 Sep 2012 13:31:54 +0200 Daniel Vetter wrote:
>
> Looks good. I've known about this issue and tried to improve matters by
> applying the patch to both trees (to at least force a conflict), but not
> even with that patch applied in my drm-intel-next queue I get a proper
>
On Mon, Sep 24, 2012 at 01:18:34PM +1000, Stephen Rothwell wrote:
> Hi Dave,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/gpu/drm/i915/intel_hdmi.c: In function 'intel_enable_hdmi':
> drivers/gpu/drm/i915/intel_hdmi.c:633:31:
On Mon, Sep 24, 2012 at 01:18:34PM +1000, Stephen Rothwell wrote:
Hi Dave,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/gpu/drm/i915/intel_hdmi.c: In function 'intel_enable_hdmi':
drivers/gpu/drm/i915/intel_hdmi.c:633:31: error:
Hi Daniel,
On Mon, 24 Sep 2012 13:31:54 +0200 Daniel Vetter dan...@ffwll.ch wrote:
Looks good. I've known about this issue and tried to improve matters by
applying the patch to both trees (to at least force a conflict), but not
even with that patch applied in my drm-intel-next queue I get a
69 matches
Mail list logo