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 hopef
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 Fr
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 confl
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:
> drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm
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 dma_a
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 dma_alloc_w
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 hav
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 = pgprot_noncached(vma->vm_pag
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, so
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 merg
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 dma_alloc_noncohe
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 t
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 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':
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_
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 wou
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
> C
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
> 'intel_opregion_get_panel_t
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 drm_i91
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 lik
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':
> driv
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: sp
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:
>>
>> drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:143:2:
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' [-W
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; Deucher
> -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
> >> > 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
>> > > ppc64_defco
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:
> > >
> > > drivers/gpu/drm/amd/amdkfd/kfd_device
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':
> > drivers/gpu/dr
> 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
> decl
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 mo
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: 'max_num_of_processes'
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: erro
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
> conf
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
45 matches
Mail list logo