Re: linux-next: build failure after merge of the drm tree

2021-01-20 Thread Stephen Rothwell
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 hopefully we should be all clean again.

Thanks.

-- 
Cheers,
Stephen Rothwell


pgpWyoZVyva1l.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2021-01-20 Thread Daniel Vetter
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 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 conflict:
> > > > >   drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> > > > >   drivers/gpu/drm/panel/panel-dsi-cm.ko
> > > > >
> > > > > Maybe caused by commit
> > > > >
> > > > >   cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel 
> > > > > driver")
> > > > >
> > > > > I have used the drm tree from next-20210107 for today.
> > > >
> > > > This has affected the drm-misc tree as well (since it merged in the drm
> > > > tree).
> > > >
> > > > I have used the drm-misc tree from next-20210107 for today.
> > >
> > > And now the drm-intel tree.
> > >
> > > I have used the drm-intel tree from next-20210108 for today.
> >
> > This is still affecting the drm and drm-intel trees.
>
> I think the fix for this is in drm-misc-next, Maarten can you send me
> a -next PR to fix this?

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 hopefully we should be all clean again.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: linux-next: build failure after merge of the drm tree

2021-01-17 Thread Dave Airlie
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:
> > > >
> > > > 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.ko
> > > >   drivers/gpu/drm/panel/panel-dsi-cm.ko
> > > >
> > > > Maybe caused by commit
> > > >
> > > >   cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> > > >
> > > > I have used the drm tree from next-20210107 for today.
> > >
> > > This has affected the drm-misc tree as well (since it merged in the drm
> > > tree).
> > >
> > > I have used the drm-misc tree from next-20210107 for today.
> >
> > And now the drm-intel tree.
> >
> > I have used the drm-intel tree from next-20210108 for today.
>
> This is still affecting the drm and drm-intel trees.

I think the fix for this is in drm-misc-next, Maarten can you send me
a -next PR to fix this?

Dave.


Re: linux-next: build failure after merge of the drm tree

2021-01-17 Thread Stephen Rothwell
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)
> > > failed like this:
> > > 
> > > error: the following would cause module name conflict:
> > >   drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> > >   drivers/gpu/drm/panel/panel-dsi-cm.ko
> > > 
> > > Maybe caused by commit
> > > 
> > >   cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> > > 
> > > I have used the drm tree from next-20210107 for today.
> > 
> > This has affected the drm-misc tree as well (since it merged in the drm
> > tree).
> > 
> > I have used the drm-misc tree from next-20210107 for today.  
> 
> And now the drm-intel tree.
> 
> I have used the drm-intel tree from next-20210108 for today.

This is still affecting the drm and drm-intel trees.

-- 
Cheers,
Stephen Rothwell


pgpY9APCO2GMS.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2021-01-10 Thread Stephen Rothwell
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 conflict:
> >   drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> >   drivers/gpu/drm/panel/panel-dsi-cm.ko
> > 
> > Maybe caused by commit
> > 
> >   cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> > 
> > I have used the drm tree from next-20210107 for today.  
> 
> This has affected the drm-misc tree as well (since it merged in the drm
> tree).
> 
> I have used the drm-misc tree from next-20210107 for today.

And now the drm-intel tree.

I have used the drm-intel tree from next-20210108 for today.
-- 
Cheers,
Stephen Rothwell


pgpuLYcdWwBET.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2021-01-07 Thread Stephen Rothwell
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.ko
>   drivers/gpu/drm/panel/panel-dsi-cm.ko
> 
> Maybe caused by commit
> 
>   cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> 
> I have used the drm tree from next-20210107 for today.

This has affected the drm-misc tree as well (since it merged in the drm
tree).

I have used the drm-misc tree from next-20210107 for today.
-- 
Cheers,
Stephen Rothwell


pgpfAUCZqzykI.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2020-09-30 Thread Christoph Hellwig
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 dma_pgprot is defined as:

pgprot_t dma_pgprot(struct device *dev, pgprot_t prot, unsigned long attrs)
{
if (force_dma_unencrypted(dev))
prot = pgprot_decrypted(prot);
if (dev_is_dma_coherent(dev) ||
(IS_ENABLED(CONFIG_DMA_NONCOHERENT_CACHE_SYNC) &&
 (attrs & DMA_ATTR_NON_CONSISTENT)))
return prot;
#ifdef CONFIG_ARCH_HAS_DMA_WRITE_COMBINE
if (attrs & DMA_ATTR_WRITE_COMBINE)
return pgprot_writecombine(prot);
#endif
return pgprot_dmacoherent(prot);
}

so it doesn't change vma->vm_page_prot at all.

The only place that uses _CACHE_CACHABLE_NONCOHERENT is the MIPS specific
kmap_noncoherent which ha sa single caller that doesn't leak anywhere
into driver code.


Re: linux-next: build failure after merge of the drm tree

2020-09-30 Thread Paul Cercueil




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_alloc_coherent paired with 
dma_mmap_coherent.

 Or dma_alloc_wc for a slightly different flavor of uncached. (both
 of the map to dma_alloc_attrs / dma_mmap_attrs eventually).


 I don't want uncached memory, I want non-coherent cached memory.


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.


-Paul




Re: linux-next: build failure after merge of the drm tree

2020-09-30 Thread Christoph Hellwig
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_wc for a slightly different flavor of uncached. (both
>> of the map to dma_alloc_attrs / dma_mmap_attrs eventually).
>
> I don't want uncached memory, I want non-coherent cached memory.

We don't have such a thing in the Linux API at all.


Re: linux-next: build failure after merge of the drm tree

2020-09-30 Thread Paul Cercueil




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 have to do:

 vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
 pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK;
 pgprot_val(vma->vm_page_prot) |= _CACHE_CACHABLE_NONCOHERENT;

 And that will only compile on MIPS, because these _CACHE_* macros 
are only

 defined there.

 I would need something like a pgprot_noncoherent(), I think.


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_wc for a slightly different flavor of uncached. (both
of the map to dma_alloc_attrs / dma_mmap_attrs eventually).


I don't want uncached memory, I want non-coherent cached memory.

-Paul




Re: linux-next: build failure after merge of the drm tree

2020-09-30 Thread Christoph Hellwig
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_page_prot);
> pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK;
> pgprot_val(vma->vm_page_prot) |= _CACHE_CACHABLE_NONCOHERENT;
>
> And that will only compile on MIPS, because these _CACHE_* macros are only 
> defined there.
>
> I would need something like a pgprot_noncoherent(), I think.

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_wc for a slightly different flavor of uncached. (both
of the map to dma_alloc_attrs / dma_mmap_attrs eventually).


Re: linux-next: build failure after merge of the drm tree

2020-09-30 Thread Paul Cercueil

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
 have patches on top of it in drm-misc-next so it's going to be a 
mess.


 If we have time I can come up with a custom dumb_create() fonction, 
to make
 sure that the GEM buffers are allocated with 
dma_alloc_noncoherent(). Is

 there a dma_mmap_noncoherent() too?


Please use the lower-level dma_alloc_pages and then just insert the
pages directly using remap_pfn_range.  Although it might make sense
to eventually create a wrapper around remap_pfn_range for all the
vma sizing sanity checks.


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_page_prot);
pgprot_val(vma->vm_page_prot) &= ~_CACHE_MASK;
pgprot_val(vma->vm_page_prot) |= _CACHE_CACHABLE_NONCOHERENT;

And that will only compile on MIPS, because these _CACHE_* macros are 
only defined there.


I would need something like a pgprot_noncoherent(), I think.

-Paul




Re: linux-next: build failure after merge of the drm tree

2020-09-30 Thread Christoph Hellwig
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.
>
> If we have time I can come up with a custom dumb_create() fonction, to make 
> sure that the GEM buffers are allocated with dma_alloc_noncoherent(). Is 
> there a dma_mmap_noncoherent() too?

Please use the lower-level dma_alloc_pages and then just insert the
pages directly using remap_pfn_range.  Although it might make sense
to eventually create a wrapper around remap_pfn_range for all the
vma sizing sanity checks.


>
> -Paul
>
---end quoted text---


Re: linux-next: build failure after merge of the drm tree

2020-09-28 Thread Paul Cercueil




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, something looks very fishy here.


 Is that a fact? I don't see why you couldn't change the cache 
settings

 after allocation. In practice it works just fine.


Accessing the same physical address using different caching attributes
is undefined behavior and fairly dangerous on most architectures, and
thus not supported by the DMA API.


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.


If we have time I can come up with a custom dumb_create() fonction, to 
make sure that the GEM buffers are allocated with 
dma_alloc_noncoherent(). Is there a dma_mmap_noncoherent() too?


-Paul




Re: linux-next: build failure after merge of the drm tree

2020-09-28 Thread Christoph Hellwig
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 why you couldn't change the cache settings 
> after allocation. In practice it works just fine.

Accessing the same physical address using different caching attributes
is undefined behavior and fairly dangerous on most architectures, and
thus not supported by the DMA API.


Re: linux-next: build failure after merge of the drm tree

2020-09-28 Thread Paul Cercueil




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 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.  Paul, let me 
know if

 you have any questions.


 I don't dma_alloc* anything, DRM core does. I use the
 DMA_ATTR_NON_CONSISTENT attr with dma_mmap_attrs(). Is there a 
replacement

 for that?


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 why you couldn't change the cache settings 
after allocation. In practice it works just fine.


Where does the allocation you try to mmap come from?  All the 
allocations

in drivers/gpu/drm/drm_gem_cma_helper.c seems to use dma_alloc_wc (aka
dma_allloc_attrs with the DMA_ATTR_WRITE_COMBINE flag).


It's the dma_alloc_wc.

-Paul




Re: linux-next: build failure after merge of the drm tree

2020-09-28 Thread Christoph Hellwig
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 
>>> 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.  Paul, let me know if
>> you have any questions.
>
> I don't dma_alloc* anything, DRM core does. I use the 
> DMA_ATTR_NON_CONSISTENT attr with dma_mmap_attrs(). Is there a replacement 
> for that?

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.

Where does the allocation you try to mmap come from?  All the allocations
in drivers/gpu/drm/drm_gem_cma_helper.c seems to use dma_alloc_wc (aka
dma_allloc_attrs with the DMA_ATTR_WRITE_COMBINE flag).


Re: linux-next: build failure after merge of the drm tree

2020-09-28 Thread Paul Cercueil

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_noncoherent + dma_sync_single*
like the other drivers converted in the dma tree.  Paul, let me know 
if

you have any questions.


I don't dma_alloc* anything, DRM core does. I use the 
DMA_ATTR_NON_CONSISTENT attr with dma_mmap_attrs(). Is there a 
replacement for that?


-Paul




Re: linux-next: build failure after merge of the drm tree

2020-09-28 Thread Christoph Hellwig
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 the
conversion first, and once we are done I'll create a shared branch.


Re: linux-next: build failure after merge of the drm tree

2020-09-28 Thread Dave Airlie
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 + dma_sync_single*
> like the other drivers converted in the dma tree.  Paul, let me know if
> you have any questions.

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?

Dave.


Re: linux-next: build failure after merge of the drm tree

2020-09-28 Thread Christoph Hellwig
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.  Paul, let me know if
you have any questions.


Re: linux-next: build failure after merge of the drm tree

2018-05-16 Thread Dave Airlie
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:
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function 
>> 'init_user_pages':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:632:3: error: implicit 
>> declaration of function 'release_pages'; did you mean 'release_task'? 
>> [-Werror=implicit-function-declaration]
>>release_pages(mem->user_pages, bo->tbo.ttm->num_pages);
>>^
>>release_task
>>
>> Caused by commit
>>
>>   5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
>>
>> I have applied the following patch for today:
>>
>> From: Stephen Rothwell 
>> Date: Wed, 16 May 2018 16:43:34 +1000
>> Subject: [PATCH] drm/amdgpu: include pagemap.h for release_pages()
>>
>> Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD"
>> Cc: Felix Kuehling 
>> Cc: Oded Gabbay 
>> Signed-off-by: Stephen Rothwell 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index 72ab2b1ffe75..ff8fd75f7ca5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -23,6 +23,7 @@
>>  #define pr_fmt(fmt) "kfd2kgd: " fmt
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include "amdgpu_object.h"
>> --
>> 2.17.0
>>
>> --
>> Cheers,
>> Stephen Rothwell
>
> Thanks Stephen,
>
> I'll add it to amdkfd-next and send it to Dave with other fixes.
>
> Oded
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: linux-next: build failure after merge of the drm tree

2018-05-16 Thread Dave Airlie
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:
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function 
>> 'init_user_pages':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:632:3: error: implicit 
>> declaration of function 'release_pages'; did you mean 'release_task'? 
>> [-Werror=implicit-function-declaration]
>>release_pages(mem->user_pages, bo->tbo.ttm->num_pages);
>>^
>>release_task
>>
>> Caused by commit
>>
>>   5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
>>
>> I have applied the following patch for today:
>>
>> From: Stephen Rothwell 
>> Date: Wed, 16 May 2018 16:43:34 +1000
>> Subject: [PATCH] drm/amdgpu: include pagemap.h for release_pages()
>>
>> Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD"
>> Cc: Felix Kuehling 
>> Cc: Oded Gabbay 
>> Signed-off-by: Stephen Rothwell 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index 72ab2b1ffe75..ff8fd75f7ca5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -23,6 +23,7 @@
>>  #define pr_fmt(fmt) "kfd2kgd: " fmt
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include "amdgpu_object.h"
>> --
>> 2.17.0
>>
>> --
>> Cheers,
>> Stephen Rothwell
>
> Thanks Stephen,
>
> I'll add it to amdkfd-next and send it to Dave with other fixes.
>
> Oded
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: linux-next: build failure after merge of the drm tree

2018-05-16 Thread Oded Gabbay
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_gpuvm.c:632:3: error: implicit 
> declaration of function 'release_pages'; did you mean 'release_task'? 
> [-Werror=implicit-function-declaration]
>release_pages(mem->user_pages, bo->tbo.ttm->num_pages);
>^
>release_task
>
> Caused by commit
>
>   5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell 
> Date: Wed, 16 May 2018 16:43:34 +1000
> Subject: [PATCH] drm/amdgpu: include pagemap.h for release_pages()
>
> Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD"
> Cc: Felix Kuehling 
> Cc: Oded Gabbay 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index 72ab2b1ffe75..ff8fd75f7ca5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -23,6 +23,7 @@
>  #define pr_fmt(fmt) "kfd2kgd: " fmt
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "amdgpu_object.h"
> --
> 2.17.0
>
> --
> Cheers,
> Stephen Rothwell

Thanks Stephen,

I'll add it to amdkfd-next and send it to Dave with other fixes.

Oded


Re: linux-next: build failure after merge of the drm tree

2018-05-16 Thread Oded Gabbay
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_gpuvm.c:632:3: error: implicit 
> declaration of function 'release_pages'; did you mean 'release_task'? 
> [-Werror=implicit-function-declaration]
>release_pages(mem->user_pages, bo->tbo.ttm->num_pages);
>^
>release_task
>
> Caused by commit
>
>   5ae0283e831a ("drm/amdgpu: Add userptr support for KFD")
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell 
> Date: Wed, 16 May 2018 16:43:34 +1000
> Subject: [PATCH] drm/amdgpu: include pagemap.h for release_pages()
>
> Fixes: 5ae0283e831a ("drm/amdgpu: Add userptr support for KFD"
> Cc: Felix Kuehling 
> Cc: Oded Gabbay 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index 72ab2b1ffe75..ff8fd75f7ca5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -23,6 +23,7 @@
>  #define pr_fmt(fmt) "kfd2kgd: " fmt
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "amdgpu_object.h"
> --
> 2.17.0
>
> --
> Cheers,
> Stephen Rothwell

Thanks Stephen,

I'll add it to amdkfd-next and send it to Dave with other fixes.

Oded


Re: linux-next: build failure after merge of the drm tree

2017-03-20 Thread Daniel Vetter
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 would be if you reuse our rerere cache. The
> only reason we don't go insane with all the drm conflicts is that we
> completely distributed conflict resolution. Developers push a patch,
> script tells them there's a conflict, they resolve it, maintainers
> never even notice.We only notice when we double-check the merge
> resolution when rerere re-applies it for the real backmerge :-) The
> merge order in drm-tip should also match what you have in linux-next,
> so you should be able to entirely reuse them.
>
> Anyway, if you trust us enough to scoop up random git rerere caches
> (or at least use them to double-check your own), they're all public:
>
> git://anongit.freedesktop.org/drm-tip rerere-cache
>
> Or
>
> https://cgit.freedesktop.org/drm-tip/tree/rr-cache?h=rerere-cache
>
> Yes we should probably gc them, but disk space is cheap.

And the merge order, in case you want to check that. We can adjust it ofc:

https://cgit.freedesktop.org/drm-tip/tree/nightly.conf?h=rerere-cache

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Re: linux-next: build failure after merge of the drm tree

2017-03-20 Thread Daniel Vetter
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 would be if you reuse our rerere cache. The
> only reason we don't go insane with all the drm conflicts is that we
> completely distributed conflict resolution. Developers push a patch,
> script tells them there's a conflict, they resolve it, maintainers
> never even notice.We only notice when we double-check the merge
> resolution when rerere re-applies it for the real backmerge :-) The
> merge order in drm-tip should also match what you have in linux-next,
> so you should be able to entirely reuse them.
>
> Anyway, if you trust us enough to scoop up random git rerere caches
> (or at least use them to double-check your own), they're all public:
>
> git://anongit.freedesktop.org/drm-tip rerere-cache
>
> Or
>
> https://cgit.freedesktop.org/drm-tip/tree/rr-cache?h=rerere-cache
>
> Yes we should probably gc them, but disk space is cheap.

And the merge order, in case you want to check that. We can adjust it ofc:

https://cgit.freedesktop.org/drm-tip/tree/nightly.conf?h=rerere-cache

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Re: linux-next: build failure after merge of the drm tree

2017-03-20 Thread Daniel Vetter
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 insane with all the drm conflicts is that we
completely distributed conflict resolution. Developers push a patch,
script tells them there's a conflict, they resolve it, maintainers
never even notice.We only notice when we double-check the merge
resolution when rerere re-applies it for the real backmerge :-) The
merge order in drm-tip should also match what you have in linux-next,
so you should be able to entirely reuse them.

Anyway, if you trust us enough to scoop up random git rerere caches
(or at least use them to double-check your own), they're all public:

git://anongit.freedesktop.org/drm-tip rerere-cache

Or

https://cgit.freedesktop.org/drm-tip/tree/rr-cache?h=rerere-cache

Yes we should probably gc them, but disk space is cheap.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


Re: linux-next: build failure after merge of the drm tree

2017-03-20 Thread Daniel Vetter
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 insane with all the drm conflicts is that we
completely distributed conflict resolution. Developers push a patch,
script tells them there's a conflict, they resolve it, maintainers
never even notice.We only notice when we double-check the merge
resolution when rerere re-applies it for the real backmerge :-) The
merge order in drm-tip should also match what you have in linux-next,
so you should be able to entirely reuse them.

Anyway, if you trust us enough to scoop up random git rerere caches
(or at least use them to double-check your own), they're all public:

git://anongit.freedesktop.org/drm-tip rerere-cache

Or

https://cgit.freedesktop.org/drm-tip/tree/rr-cache?h=rerere-cache

Yes we should probably gc them, but disk space is cheap.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


RE: linux-next: build failure after merge of the drm tree

2017-01-25 Thread Vincent ABRIOU
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 
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Vincent
> ABRIOU ; Ville Syrjälä
> 
> Subject: linux-next: build failure after merge of the drm tree
> 
> Hi Dave,
> 
> After merging the drm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> drivers/gpu/drm/sti/sti_plane.c: In function 'sti_plane_update_fps':
> drivers/gpu/drm/sti/sti_plane.c:76:33: error: 'struct drm_framebuffer' has
> no member named 'pixel_format'
>  (char *)>drm_plane.fb->pixel_format,
>  ^
> 
> Caused by commit
> 
>   a69e466b0666 ("drm/sti: update fps debugfs entries")
> 
> Interacting with commit
> 
>   438b74a5497c ("drm: Nuke fb->pixel_format")
> 
> This should have been fixed up in commit
> 
>   d64a1661c8f7 ("Merge tag 'sti-drm-next-2017-01-06' of
> https://github.com/vinceab/linux into drm-next")
> 
> I have used the drm tree from next-20170123 for today.
> 
> --
> Cheers,
> Stephen Rothwell


RE: linux-next: build failure after merge of the drm tree

2017-01-25 Thread Vincent ABRIOU
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 
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Vincent
> ABRIOU ; Ville Syrjälä
> 
> Subject: linux-next: build failure after merge of the drm tree
> 
> Hi Dave,
> 
> After merging the drm tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> drivers/gpu/drm/sti/sti_plane.c: In function 'sti_plane_update_fps':
> drivers/gpu/drm/sti/sti_plane.c:76:33: error: 'struct drm_framebuffer' has
> no member named 'pixel_format'
>  (char *)>drm_plane.fb->pixel_format,
>  ^
> 
> Caused by commit
> 
>   a69e466b0666 ("drm/sti: update fps debugfs entries")
> 
> Interacting with commit
> 
>   438b74a5497c ("drm: Nuke fb->pixel_format")
> 
> This should have been fixed up in commit
> 
>   d64a1661c8f7 ("Merge tag 'sti-drm-next-2017-01-06' of
> https://github.com/vinceab/linux into drm-next")
> 
> I have used the drm tree from next-20170123 for today.
> 
> --
> Cheers,
> Stephen Rothwell


Re: linux-next: build failure after merge of the drm tree

2016-07-14 Thread Sedat Dilek
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_type':
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: error: 'dev' undeclared
> (first use in this function)
>   if (IS_SKYLAKE(dev)) {
>  ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
>   if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
>  #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
>   if (IS_SKYLAKE(dev)) {
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: note: each undeclared
> identifier is reported only once for each function it appears in
>   if (IS_SKYLAKE(dev)) {
>  ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
>   if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
>  #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
>   if (IS_SKYLAKE(dev)) {
>   ^
>
> Caused by commit
>
>   6f9f4b7a2cf7 ("drm/i915/opregion: Convert to using native
> drm_i915_private")
>
> interacting with commit
>
>   aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
>
> from the drm-intel-fixes tree.
>
> I applied this merge fix patch:
>
> From: Stephen Rothwell 
> Date: Fri, 15 Jul 2016 13:34:05 +1000
> Subject: [PATCH] drm/i915/opregion: fix up for argument change
>
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 21f19641e33e..dcdb346b596c 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1039,7 +1039,7 @@ intel_opregion_get_panel_type(struct drm_i915_private
> *dev_priv)
>* vswing instead. Low vswing results in some display flickers, so
>* let's simply ignore the OpRegion panel type on SKL for now.
>*/
> - if (IS_SKYLAKE(dev)) {
> + if (IS_SKYLAKE(dev_priv)) {
>   DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
>   return -ENODEV;
>   }
> --
> 2.8.1
>

I fell over the same issue when testing drm-intel-nightly and sent a patch.

- Sedat -

https://lists.freedesktop.org/archives/intel-gfx/2016-July/100691.html


Re: linux-next: build failure after merge of the drm tree

2016-07-14 Thread Sedat Dilek
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_type':
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: error: 'dev' undeclared
> (first use in this function)
>   if (IS_SKYLAKE(dev)) {
>  ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
>   if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
>  #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
>   if (IS_SKYLAKE(dev)) {
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:17: note: each undeclared
> identifier is reported only once for each function it appears in
>   if (IS_SKYLAKE(dev)) {
>  ^
> drivers/gpu/drm/i915/i915_drv.h:2603:43: note: in definition of macro
> '__I915__'
>   if (__builtin_types_compatible_p(typeof(*p), struct drm_i915_private)) \
>^
> drivers/gpu/drm/i915/i915_drv.h:2670:26: note: in expansion of macro
> 'INTEL_INFO'
>  #define IS_SKYLAKE(dev) (INTEL_INFO(dev)->is_skylake)
>   ^
> drivers/gpu/drm/i915/intel_opregion.c:1042:6: note: in expansion of macro
> 'IS_SKYLAKE'
>   if (IS_SKYLAKE(dev)) {
>   ^
>
> Caused by commit
>
>   6f9f4b7a2cf7 ("drm/i915/opregion: Convert to using native
> drm_i915_private")
>
> interacting with commit
>
>   aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL")
>
> from the drm-intel-fixes tree.
>
> I applied this merge fix patch:
>
> From: Stephen Rothwell 
> Date: Fri, 15 Jul 2016 13:34:05 +1000
> Subject: [PATCH] drm/i915/opregion: fix up for argument change
>
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 21f19641e33e..dcdb346b596c 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -1039,7 +1039,7 @@ intel_opregion_get_panel_type(struct drm_i915_private
> *dev_priv)
>* vswing instead. Low vswing results in some display flickers, so
>* let's simply ignore the OpRegion panel type on SKL for now.
>*/
> - if (IS_SKYLAKE(dev)) {
> + if (IS_SKYLAKE(dev_priv)) {
>   DRM_DEBUG_KMS("Ignoring OpRegion panel type (%d)\n", ret - 1);
>   return -ENODEV;
>   }
> --
> 2.8.1
>

I fell over the same issue when testing drm-intel-nightly and sent a patch.

- Sedat -

https://lists.freedesktop.org/archives/intel-gfx/2016-July/100691.html


Re: linux-next: build failure after merge of the drm tree

2016-04-28 Thread Jani Nikula
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_i915_private' has 
> no member named 'edp_low_vswing'
>if (dev_priv->edp_low_vswing) {
>^
>
> Caused by commit
>
>   06411f08b3f3 ("drm/i915: move edp low vswing config to vbt data")
>
> interacting with commit
>
>   992e7a41f9fc ("drm/i915: Fix eDP low vswing for Broadwell")
>
> from the drm-intel-fixes tree.
>
> I applied the following merge fixup patch (which is suggested by the "v3:
> Change dev_priv->edp_low_vswing to use dev_priv->vbt.edp.low_vswing"
> comment in the drm-intel-fixes tree patch, but clearly could not be
> done there).
>
> From: Stephen Rothwell 
> Date: Thu, 28 Apr 2016 11:53:36 +1000
> Subject: [PATCH] drm/i915: fix up for edp_low_vswing change
>
> Signed-off-by: Stephen Rothwell 

FWIW,

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6080b5481984..e304857ba405 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -444,7 +444,7 @@ void intel_prepare_ddi_buffer(struct intel_encoder 
> *encoder)
>   ddi_translations_fdi = bdw_ddi_translations_fdi;
>   ddi_translations_dp = bdw_ddi_translations_dp;
>  
> - if (dev_priv->edp_low_vswing) {
> + if (dev_priv->vbt.edp.low_vswing) {
>   ddi_translations_edp = bdw_ddi_translations_edp;
>   n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
>   } else {
> -- 
> 2.7.0

-- 
Jani Nikula, Intel Open Source Technology Center


Re: linux-next: build failure after merge of the drm tree

2016-04-28 Thread Jani Nikula
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_i915_private' has 
> no member named 'edp_low_vswing'
>if (dev_priv->edp_low_vswing) {
>^
>
> Caused by commit
>
>   06411f08b3f3 ("drm/i915: move edp low vswing config to vbt data")
>
> interacting with commit
>
>   992e7a41f9fc ("drm/i915: Fix eDP low vswing for Broadwell")
>
> from the drm-intel-fixes tree.
>
> I applied the following merge fixup patch (which is suggested by the "v3:
> Change dev_priv->edp_low_vswing to use dev_priv->vbt.edp.low_vswing"
> comment in the drm-intel-fixes tree patch, but clearly could not be
> done there).
>
> From: Stephen Rothwell 
> Date: Thu, 28 Apr 2016 11:53:36 +1000
> Subject: [PATCH] drm/i915: fix up for edp_low_vswing change
>
> Signed-off-by: Stephen Rothwell 

FWIW,

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6080b5481984..e304857ba405 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -444,7 +444,7 @@ void intel_prepare_ddi_buffer(struct intel_encoder 
> *encoder)
>   ddi_translations_fdi = bdw_ddi_translations_fdi;
>   ddi_translations_dp = bdw_ddi_translations_dp;
>  
> - if (dev_priv->edp_low_vswing) {
> + if (dev_priv->vbt.edp.low_vswing) {
>   ddi_translations_edp = bdw_ddi_translations_edp;
>   n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
>   } else {
> -- 
> 2.7.0

-- 
Jani Nikula, Intel Open Source Technology Center


Re: linux-next: build failure after merge of the drm tree

2016-03-19 Thread Christian König

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 like this:

drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_userptr_ioctl':
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:321:2: error: implicit declaration of 
function 'release_pages' [-Werror=implicit-function-declaration]
   release_pages(bo->tbo.ttm->pages, bo->tbo.ttm->num_pages, false);
   ^
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_bos':
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:410:5: error: implicit declaration of 
function 'release_pages' [-Werror=implicit-function-declaration]
  release_pages(e->user_pages,
  ^

Caused by commit

   2f568dbd6b94 ("drm/amdgpu: move get_user_pages out of amdgpu_ttm_tt_pin_userptr 
v6")

Presumably a forgotten include file.

I added this fix patch for today:

From: Stephen Rothwell 
Date: Thu, 17 Mar 2016 15:30:49 +1100
Subject: [PATCH] drm/amdgpu: release_pages requires linux/pagemap.h

Signed-off-by: Stephen Rothwell 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4f5ef4149e87..9392e50a7ba4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -25,6 +25,7 @@
   *Jerome Glisse 
   */
  #include 
+#include 
  #include 
  #include 
  #include "amdgpu.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 1ecdf6c01368..0f2391ec1ed9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -26,6 +26,7 @@
   *  Jerome Glisse
   */
  #include 
+#include 
  #include 
  #include 
  #include "amdgpu.h"




Re: linux-next: build failure after merge of the drm tree

2016-03-19 Thread Christian König

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 like this:

drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_userptr_ioctl':
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:321:2: error: implicit declaration of 
function 'release_pages' [-Werror=implicit-function-declaration]
   release_pages(bo->tbo.ttm->pages, bo->tbo.ttm->num_pages, false);
   ^
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_bos':
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:410:5: error: implicit declaration of 
function 'release_pages' [-Werror=implicit-function-declaration]
  release_pages(e->user_pages,
  ^

Caused by commit

   2f568dbd6b94 ("drm/amdgpu: move get_user_pages out of amdgpu_ttm_tt_pin_userptr 
v6")

Presumably a forgotten include file.

I added this fix patch for today:

From: Stephen Rothwell 
Date: Thu, 17 Mar 2016 15:30:49 +1100
Subject: [PATCH] drm/amdgpu: release_pages requires linux/pagemap.h

Signed-off-by: Stephen Rothwell 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4f5ef4149e87..9392e50a7ba4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -25,6 +25,7 @@
   *Jerome Glisse 
   */
  #include 
+#include 
  #include 
  #include 
  #include "amdgpu.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 1ecdf6c01368..0f2391ec1ed9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -26,6 +26,7 @@
   *  Jerome Glisse
   */
  #include 
+#include 
  #include 
  #include 
  #include "amdgpu.h"




Re: linux-next: build failure after merge of the drm tree

2016-01-06 Thread Stephen Rothwell
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':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/tonga_thermal.c:84:2: error: 
> implicit declaration of function 'do_div' 
> [-Werror=implicit-function-declaration]
>   do_div(tmp64, duty100);
>   ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_thermal.c: In function 
> 'fiji_fan_ctrl_get_fan_speed_percent':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_thermal.c:78:2: error: 
> implicit declaration of function 'do_div' 
> [-Werror=implicit-function-declaration]
>   do_div(tmp64, duty100);
>   ^
> 
> Caused by commit
> 
>   1e4854e96c35 ("drm/amdgpu/powerplay: implement thermal control for tonga.")
> 
> [I notice that that commit does not have a Signed-off-by from its
> committer (Alex)]
> 
> I applied the following fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Thu, 31 Dec 2015 21:20:20 +1100
> Subject: [PATCH] drm/amdgpu/powerplay: include asm/div64.h for do_div()
> 
> Fixes: 1e4854e96c35 ("drm/amdgpu/powerplay: implement thermal control for 
> tonga.")
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c  | 2 +-
>  drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> index def57d0675ed..e76a7de9aa32 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> @@ -20,7 +20,7 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   *
>   */
> -
> +#include 
>  #include "fiji_thermal.h"
>  #include "fiji_hwmgr.h"
>  #include "fiji_smumgr.h"
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> index 2e159b003e71..a188174747c9 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> @@ -20,7 +20,7 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   *
>   */
> -
> +#include 
>  #include "tonga_thermal.h"
>  #include "tonga_hwmgr.h"
>  #include "tonga_smumgr.h"
> -- 
> 2.6.4

Ping?  I am still applying that patch ...

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2016-01-06 Thread Stephen Rothwell
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':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/tonga_thermal.c:84:2: error: 
> implicit declaration of function 'do_div' 
> [-Werror=implicit-function-declaration]
>   do_div(tmp64, duty100);
>   ^
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_thermal.c: In function 
> 'fiji_fan_ctrl_get_fan_speed_percent':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/fiji_thermal.c:78:2: error: 
> implicit declaration of function 'do_div' 
> [-Werror=implicit-function-declaration]
>   do_div(tmp64, duty100);
>   ^
> 
> Caused by commit
> 
>   1e4854e96c35 ("drm/amdgpu/powerplay: implement thermal control for tonga.")
> 
> [I notice that that commit does not have a Signed-off-by from its
> committer (Alex)]
> 
> I applied the following fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Thu, 31 Dec 2015 21:20:20 +1100
> Subject: [PATCH] drm/amdgpu/powerplay: include asm/div64.h for do_div()
> 
> Fixes: 1e4854e96c35 ("drm/amdgpu/powerplay: implement thermal control for 
> tonga.")
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c  | 2 +-
>  drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> index def57d0675ed..e76a7de9aa32 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_thermal.c
> @@ -20,7 +20,7 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   *
>   */
> -
> +#include 
>  #include "fiji_thermal.h"
>  #include "fiji_hwmgr.h"
>  #include "fiji_smumgr.h"
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> index 2e159b003e71..a188174747c9 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_thermal.c
> @@ -20,7 +20,7 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   *
>   */
> -
> +#include 
>  #include "tonga_thermal.h"
>  #include "tonga_hwmgr.h"
>  #include "tonga_smumgr.h"
> -- 
> 2.6.4

Ping?  I am still applying that patch ...

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-12-30 Thread Mark yao

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: spilt register related into 
rockchip_reg_vop.c")

I have added the following fix patch for today (just because its
Christmas :-)):

From: Stephen Rothwell 
Date: Thu, 31 Dec 2015 13:35:27 +1100
Subject: [PATCH] drm/rockchip: vop: export vop_component_ops to modules

Fixes: a67719d18229 ("drm/rockchip: vop: spilt register related into 
rockchip_reg_vop.c")
Signed-off-by: Stephen Rothwell 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d83bf87ba71e..f5b3da2f92d7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1395,3 +1395,4 @@ const struct component_ops vop_component_ops = {
.bind = vop_bind,
.unbind = vop_unbind,
  };
+EXPORT_SYMBOL_GPL(vop_component_ops);

Hi Stephen

Thanks for the fix, Sorry for forgetting test it with modules,  and

Acked-by: Mark Yao 

Hi Dave
   Can you pick this one?


Thanks.:-)

--
Mark Yao


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-12-30 Thread Mark yao

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: spilt register related into 
rockchip_reg_vop.c")

I have added the following fix patch for today (just because its
Christmas :-)):

From: Stephen Rothwell 
Date: Thu, 31 Dec 2015 13:35:27 +1100
Subject: [PATCH] drm/rockchip: vop: export vop_component_ops to modules

Fixes: a67719d18229 ("drm/rockchip: vop: spilt register related into 
rockchip_reg_vop.c")
Signed-off-by: Stephen Rothwell 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d83bf87ba71e..f5b3da2f92d7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1395,3 +1395,4 @@ const struct component_ops vop_component_ops = {
.bind = vop_bind,
.unbind = vop_unbind,
  };
+EXPORT_SYMBOL_GPL(vop_component_ops);

Hi Stephen

Thanks for the fix, Sorry for forgetting test it with modules,  and

Acked-by: Mark Yao 

Hi Dave
   Can you pick this one?


Thanks.:-)

--
Mark Yao


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-11-09 Thread Alexandre Courbot
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: error: implicit 
>> declaration of function 'dma_to_phys' [-Werror=implicit-function-declaration]
>>
>> Caused by commit
>>
>>   69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access")
>>
>> Discovered after the release.
>>
> Still seen in next-20151109, affecting at least alpha, i386, parisc, s390,
> and xtensa, but probably other architectures as well.
>
> dma_to_phys() was until now not used from driver code, and is only declared
> for an architecture if it is used/needed there.

Mmm there doesn't seem to be a portable way of getting a physical
address from a DMA handle, which is what we are trying to do in this
code.

In that particular case a cast is enough though, so we should probably
just do that. I will send a patch for Ben/David to include in order to
fix this issue at least.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-11-09 Thread Guenter Roeck
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' [-Werror=implicit-function-declaration]
> 
> Caused by commit
> 
>   69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access")
> 
> Discovered after the release.
> 
Still seen in next-20151109, affecting at least alpha, i386, parisc, s390,
and xtensa, but probably other architectures as well.

dma_to_phys() was until now not used from driver code, and is only declared
for an architecture if it is used/needed there.

Also:

ERROR: "drm_gem_cma_create" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_prime_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_prime_get_sg_table" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_vm_ops" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_prime_vunmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_prime_import_sg_table" [drivers/gpu/drm/vc4/vc4.ko] 
undefined!
ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_prime_vmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_dumb_map_offset" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_create" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
ERROR: "drm_gem_cma_describe" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/drm_kms_helper.ko] undefined!

seen with m68k:allmodconfig.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-11-09 Thread Alexandre Courbot
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: error: implicit 
>> declaration of function 'dma_to_phys' [-Werror=implicit-function-declaration]
>>
>> Caused by commit
>>
>>   69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access")
>>
>> Discovered after the release.
>>
> Still seen in next-20151109, affecting at least alpha, i386, parisc, s390,
> and xtensa, but probably other architectures as well.
>
> dma_to_phys() was until now not used from driver code, and is only declared
> for an architecture if it is used/needed there.

Mmm there doesn't seem to be a portable way of getting a physical
address from a DMA handle, which is what we are trying to do in this
code.

In that particular case a cast is enough though, so we should probably
just do that. I will send a patch for Ben/David to include in order to
fix this issue at least.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-11-09 Thread Guenter Roeck
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' [-Werror=implicit-function-declaration]
> 
> Caused by commit
> 
>   69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access")
> 
> Discovered after the release.
> 
Still seen in next-20151109, affecting at least alpha, i386, parisc, s390,
and xtensa, but probably other architectures as well.

dma_to_phys() was until now not used from driver code, and is only declared
for an architecture if it is used/needed there.

Also:

ERROR: "drm_gem_cma_create" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_prime_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_prime_get_sg_table" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_vm_ops" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_prime_vunmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_prime_import_sg_table" [drivers/gpu/drm/vc4/vc4.ko] 
undefined!
ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_prime_vmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_dumb_map_offset" [drivers/gpu/drm/vc4/vc4.ko] undefined!
ERROR: "drm_gem_cma_create" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
ERROR: "drm_gem_cma_describe" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/drm_kms_helper.ko] undefined!

seen with m68k:allmodconfig.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-06-09 Thread Stephen Rothwell
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,
> > Alexander
> > Subject: linux-next: build failure after merge of the drm tree
> > 
> > Hi Dave,
> > 
> > After merging the drm tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> > 
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
> > 'gfx_v7_0_cp_gfx_resume':
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: error: 'BUF_SWAP_32BIT'
> > undeclared (first use in this function)
> >   tmp |= BUF_SWAP_32BIT;
> >  ^
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: note: each undeclared
> > identifier is reported only once for each function it appears in
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
> > 'gfx_v7_0_cp_compute_resume':
> > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3398:41: error:
> > 'BUF_SWAP_32BIT' undeclared (first use in this function)
> >mqd->queue_state.cp_hqd_pq_control |= BUF_SWAP_32BIT;
> >  ^
> > drivers/gpu/drm/amd/amdgpu/cik_sdma.c: In function
> > 'cik_sdma_gfx_resume':
> > drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: error:
> > 'SDMA_RB_SWAP_ENABLE' undeclared (first use in this function)
> >rb_cntl |= SDMA_RB_SWAP_ENABLE |
> > SDMA_RPTR_WRITEBACK_SWAP_ENABLE;
> >   ^
> > drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: note: each undeclared
> > identifier is reported only once for each function it appears in
> > drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:36: error:
> > 'SDMA_RPTR_WRITEBACK_SWAP_ENABLE' undeclared (first use in this
> > function)
> >rb_cntl |= SDMA_RB_SWAP_ENABLE |
> > SDMA_RPTR_WRITEBACK_SWAP_ENABLE;
> > ^
> > 
> > Caused by commit a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts").
> > 
> 
> Should be fixed with this patch.  Sorry for the breakage.

I will apply this as a fix to the drm tree merge today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpBCSXAVQQ3h.pgp
Description: OpenPGP digital signature


RE: linux-next: build failure after merge of the drm tree

2015-06-09 Thread Deucher, Alexander
> -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,
> 
> After merging the drm tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
> 'gfx_v7_0_cp_gfx_resume':
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: error: 'BUF_SWAP_32BIT'
> undeclared (first use in this function)
>   tmp |= BUF_SWAP_32BIT;
>  ^
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: note: each undeclared
> identifier is reported only once for each function it appears in
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
> 'gfx_v7_0_cp_compute_resume':
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3398:41: error:
> 'BUF_SWAP_32BIT' undeclared (first use in this function)
>mqd->queue_state.cp_hqd_pq_control |= BUF_SWAP_32BIT;
>  ^
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c: In function
> 'cik_sdma_gfx_resume':
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: error:
> 'SDMA_RB_SWAP_ENABLE' undeclared (first use in this function)
>rb_cntl |= SDMA_RB_SWAP_ENABLE |
> SDMA_RPTR_WRITEBACK_SWAP_ENABLE;
>   ^
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: note: each undeclared
> identifier is reported only once for each function it appears in
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:36: error:
> 'SDMA_RPTR_WRITEBACK_SWAP_ENABLE' undeclared (first use in this
> function)
>rb_cntl |= SDMA_RB_SWAP_ENABLE |
> SDMA_RPTR_WRITEBACK_SWAP_ENABLE;
> ^
> 
> Caused by commit a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts").
> 

Should be fixed with this patch.  Sorry for the breakage.

Alex


> I added the following patch to disable this code for today:
> 
> From: Stephen Rothwell 
> Date: Tue, 9 Jun 2015 23:38:30 +1000
> Subject: [PATCH] drm/amdgpu: disable CIK parts for now
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/amd/amdgpu/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig
> b/drivers/gpu/drm/amd/amdgpu/Kconfig
> index b30fcfa4b1f2..8da6bf7f39c8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig
> +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
> @@ -1,6 +1,7 @@
>  config DRM_AMDGPU_CIK
>   bool "Enable amdgpu support for CIK parts"
>   depends on DRM_AMDGPU
> + depends on BROKEN
>   help
> Choose this option if you want to enable experimental support
> for CIK asics.
> --
> 2.1.4
> 
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au


0001-drm-amdgpu-fix-the-build-on-big-endian.patch
Description: 0001-drm-amdgpu-fix-the-build-on-big-endian.patch


RE: linux-next: build failure after merge of the drm tree

2015-06-09 Thread Deucher, Alexander
 -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,
 
 After merging the drm tree, today's linux-next build (powerpc
 allyesconfig) failed like this:
 
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
 'gfx_v7_0_cp_gfx_resume':
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: error: 'BUF_SWAP_32BIT'
 undeclared (first use in this function)
   tmp |= BUF_SWAP_32BIT;
  ^
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: note: each undeclared
 identifier is reported only once for each function it appears in
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
 'gfx_v7_0_cp_compute_resume':
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3398:41: error:
 'BUF_SWAP_32BIT' undeclared (first use in this function)
mqd-queue_state.cp_hqd_pq_control |= BUF_SWAP_32BIT;
  ^
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c: In function
 'cik_sdma_gfx_resume':
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: error:
 'SDMA_RB_SWAP_ENABLE' undeclared (first use in this function)
rb_cntl |= SDMA_RB_SWAP_ENABLE |
 SDMA_RPTR_WRITEBACK_SWAP_ENABLE;
   ^
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: note: each undeclared
 identifier is reported only once for each function it appears in
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:36: error:
 'SDMA_RPTR_WRITEBACK_SWAP_ENABLE' undeclared (first use in this
 function)
rb_cntl |= SDMA_RB_SWAP_ENABLE |
 SDMA_RPTR_WRITEBACK_SWAP_ENABLE;
 ^
 
 Caused by commit a2e73f56fa62 (drm/amdgpu: Add support for CIK parts).
 

Should be fixed with this patch.  Sorry for the breakage.

Alex


 I added the following patch to disable this code for today:
 
 From: Stephen Rothwell s...@canb.auug.org.au
 Date: Tue, 9 Jun 2015 23:38:30 +1000
 Subject: [PATCH] drm/amdgpu: disable CIK parts for now
 
 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
 ---
  drivers/gpu/drm/amd/amdgpu/Kconfig | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig
 b/drivers/gpu/drm/amd/amdgpu/Kconfig
 index b30fcfa4b1f2..8da6bf7f39c8 100644
 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig
 +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
 @@ -1,6 +1,7 @@
  config DRM_AMDGPU_CIK
   bool Enable amdgpu support for CIK parts
   depends on DRM_AMDGPU
 + depends on BROKEN
   help
 Choose this option if you want to enable experimental support
 for CIK asics.
 --
 2.1.4
 
 --
 Cheers,
 Stephen Rothwells...@canb.auug.org.au


0001-drm-amdgpu-fix-the-build-on-big-endian.patch
Description: 0001-drm-amdgpu-fix-the-build-on-big-endian.patch


Re: linux-next: build failure after merge of the drm tree

2015-06-09 Thread Stephen Rothwell
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; linux-kernel@vger.kernel.org; Deucher,
  Alexander
  Subject: linux-next: build failure after merge of the drm tree
  
  Hi Dave,
  
  After merging the drm tree, today's linux-next build (powerpc
  allyesconfig) failed like this:
  
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
  'gfx_v7_0_cp_gfx_resume':
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: error: 'BUF_SWAP_32BIT'
  undeclared (first use in this function)
tmp |= BUF_SWAP_32BIT;
   ^
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: note: each undeclared
  identifier is reported only once for each function it appears in
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function
  'gfx_v7_0_cp_compute_resume':
  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3398:41: error:
  'BUF_SWAP_32BIT' undeclared (first use in this function)
 mqd-queue_state.cp_hqd_pq_control |= BUF_SWAP_32BIT;
   ^
  drivers/gpu/drm/amd/amdgpu/cik_sdma.c: In function
  'cik_sdma_gfx_resume':
  drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: error:
  'SDMA_RB_SWAP_ENABLE' undeclared (first use in this function)
 rb_cntl |= SDMA_RB_SWAP_ENABLE |
  SDMA_RPTR_WRITEBACK_SWAP_ENABLE;
^
  drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: note: each undeclared
  identifier is reported only once for each function it appears in
  drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:36: error:
  'SDMA_RPTR_WRITEBACK_SWAP_ENABLE' undeclared (first use in this
  function)
 rb_cntl |= SDMA_RB_SWAP_ENABLE |
  SDMA_RPTR_WRITEBACK_SWAP_ENABLE;
  ^
  
  Caused by commit a2e73f56fa62 (drm/amdgpu: Add support for CIK parts).
  
 
 Should be fixed with this patch.  Sorry for the breakage.

I will apply this as a fix to the drm tree merge today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpBCSXAVQQ3h.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2015-05-20 Thread Dave Airlie

> >> > 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 Rothwells...@canb.auug.org.au
> 
> Hi,
> Did I need to do something different in order to prevent this conflict ?
> Do some manual merge before sending the pull request ?
> 

Well this sort of thing is why linux-next exists, you can pull Linus's 
tree into yours to see if it builds before pulling, but you can find 
yourself fixing conflicts in other parts of the drm stack then.

I'll pull v4.1-rc4 tag in as a nicer merge point that misc Linus master.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-05-20 Thread Oded Gabbay
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_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 of function 'init_sdma_vm' 
>> > > [-Werror=implicit-function-declaration]
>> > >   init_sdma_vm(dqm, q, qpd);
>> > >   ^
>> > >
>> > > Caused by commit 3e3f6e1a90a8 ("drm/amdkfd: make the sdma vm init to be
>> > > asic specific").
>> > >
>> > > I have used the drm tree from next-20150519 for today.
>> >
>> > Okay this looks like a silent conflict, I'll have to pull Linus tree into
>> > 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 Rothwells...@canb.auug.org.au

Hi,
Did I need to do something different in order to prevent this conflict ?
Do some manual merge before sending the pull request ?

Thanks,
  Oded
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-05-20 Thread Dave Airlie

   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 Rothwells...@canb.auug.org.au
 
 Hi,
 Did I need to do something different in order to prevent this conflict ?
 Do some manual merge before sending the pull request ?
 

Well this sort of thing is why linux-next exists, you can pull Linus's 
tree into yours to see if it builds before pulling, but you can find 
yourself fixing conflicts in other parts of the drm stack then.

I'll pull v4.1-rc4 tag in as a nicer merge point that misc Linus master.

Dave.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-05-20 Thread Oded Gabbay
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 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 of function 'init_sdma_vm' 
   [-Werror=implicit-function-declaration]
 init_sdma_vm(dqm, q, qpd);
 ^
  
   Caused by commit 3e3f6e1a90a8 (drm/amdkfd: make the sdma vm init to be
   asic specific).
  
   I have used the drm tree from next-20150519 for today.
 
  Okay this looks like a silent conflict, I'll have to pull Linus tree into
  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 Rothwells...@canb.auug.org.au

Hi,
Did I need to do something different in order to prevent this conflict ?
Do some manual merge before sending the pull request ?

Thanks,
  Oded
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-05-19 Thread Stephen Rothwell
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_queue_manager.c: In function 
> > > 'create_queue_cpsch':
> > > drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:888:2: error: 
> > > implicit declaration of function 'init_sdma_vm' 
> > > [-Werror=implicit-function-declaration]
> > >   init_sdma_vm(dqm, q, qpd);
> > >   ^
> > > 
> > > Caused by commit 3e3f6e1a90a8 ("drm/amdkfd: make the sdma vm init to be
> > > asic specific").
> > > 
> > > I have used the drm tree from next-20150519 for today.
> > 
> > Okay this looks like a silent conflict, I'll have to pull Linus tree into
> > 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 Rothwells...@canb.auug.org.au


pgpndUQyxoZkJ.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2015-05-19 Thread Stephen Rothwell
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/drm/amd/amdkfd/kfd_device_queue_manager.c:888:2: error: 
> > implicit declaration of function 'init_sdma_vm' 
> > [-Werror=implicit-function-declaration]
> >   init_sdma_vm(dqm, q, qpd);
> >   ^
> > 
> > Caused by commit 3e3f6e1a90a8 ("drm/amdkfd: make the sdma vm init to be
> > asic specific").
> > 
> > I have used the drm tree from next-20150519 for today.
> 
> Okay this looks like a silent conflict, I'll have to pull Linus tree into
> 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.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp9uY_MvwwL5.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2015-05-19 Thread Dave Airlie

> 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 of function 'init_sdma_vm' [-Werror=implicit-function-declaration]
>   init_sdma_vm(dqm, q, qpd);
>   ^
> 
> Caused by commit 3e3f6e1a90a8 ("drm/amdkfd: make the sdma vm init to be
> asic specific").
> 
> I have used the drm tree from next-20150519 for today.

Okay this looks like a silent conflict, I'll have to pull Linus tree into
drm-next and fix it up there.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-05-19 Thread Dave Airlie

 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 of function 'init_sdma_vm' [-Werror=implicit-function-declaration]
   init_sdma_vm(dqm, q, qpd);
   ^
 
 Caused by commit 3e3f6e1a90a8 (drm/amdkfd: make the sdma vm init to be
 asic specific).
 
 I have used the drm tree from next-20150519 for today.

Okay this looks like a silent conflict, I'll have to pull Linus tree into
drm-next and fix it up there.

Dave.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-05-19 Thread Stephen Rothwell
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':
  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c:888:2: error: 
  implicit declaration of function 'init_sdma_vm' 
  [-Werror=implicit-function-declaration]
init_sdma_vm(dqm, q, qpd);
^
  
  Caused by commit 3e3f6e1a90a8 (drm/amdkfd: make the sdma vm init to be
  asic specific).
  
  I have used the drm tree from next-20150519 for today.
 
 Okay this looks like a silent conflict, I'll have to pull Linus tree into
 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.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp9uY_MvwwL5.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2015-05-19 Thread Stephen Rothwell
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:
   
   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 of function 'init_sdma_vm' 
   [-Werror=implicit-function-declaration]
 init_sdma_vm(dqm, q, qpd);
 ^
   
   Caused by commit 3e3f6e1a90a8 (drm/amdkfd: make the sdma vm init to be
   asic specific).
   
   I have used the drm tree from next-20150519 for today.
  
  Okay this looks like a silent conflict, I'll have to pull Linus tree into
  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 Rothwells...@canb.auug.org.au


pgpndUQyxoZkJ.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2015-01-29 Thread Stephen Rothwell
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 morning and then merge them, so
tomorrow all will be well.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpOvOt60gZoP.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2015-01-29 Thread Oded Gabbay



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' 
undeclared (first use in this function)
   size += (max_num_of_processes * sizeof(struct pm4_map_process) +
^
drivers/gpu/drm/amd/amdkfd/kfd_device.c:193:11: note: each undeclared 
identifier is reported only once for each function it appears in
drivers/gpu/drm/amd/amdkfd/kfd_device.c:194:26: error: 
'max_num_of_queues_per_process' undeclared (first use in this function)
max_num_of_processes * max_num_of_queues_per_process *
   ^

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.


Oded
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-01-29 Thread Oded Gabbay



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' 
undeclared (first use in this function)
   size += (max_num_of_processes * sizeof(struct pm4_map_process) +
^
drivers/gpu/drm/amd/amdkfd/kfd_device.c:193:11: note: each undeclared 
identifier is reported only once for each function it appears in
drivers/gpu/drm/amd/amdkfd/kfd_device.c:194:26: error: 
'max_num_of_queues_per_process' undeclared (first use in this function)
max_num_of_processes * max_num_of_queues_per_process *
   ^

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.


Oded
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2015-01-29 Thread Stephen Rothwell
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 trees again each morning and then merge them, so
tomorrow all will be well.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpOvOt60gZoP.pgp
Description: OpenPGP digital signature


Re: linux-next: build failure after merge of the drm tree

2014-06-04 Thread Stephen Rothwell
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: error: implicit declaration of 
> function 'drm_get_connector_name' [-Werror=implicit-function-declaration]
> DRM_DEBUG_KMS("using first mode listed on connector %s\n",
> ^
> 
> Caused by commits c0c97622c1bd ("drm/i915: Use the connector name in
> fbdev debug messages") and c23cc4178dd1 ("drm/i915: replace
> drm_get_connector_name() with direct name field use").
> 
> I have used the drm tree from next-20140604 for today.

This affected the drm-intel tree as well, so it is back to
next-20140604.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature


Re: linux-next: build failure after merge of the drm tree

2014-06-04 Thread Stephen Rothwell
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':
 drivers/gpu/drm/i915/intel_fbdev.c:392:4: error: implicit declaration of 
 function 'drm_get_connector_name' [-Werror=implicit-function-declaration]
 DRM_DEBUG_KMS(using first mode listed on connector %s\n,
 ^
 
 Caused by commits c0c97622c1bd (drm/i915: Use the connector name in
 fbdev debug messages) and c23cc4178dd1 (drm/i915: replace
 drm_get_connector_name() with direct name field use).
 
 I have used the drm tree from next-20140604 for today.

This affected the drm-intel tree as well, so it is back to
next-20140604.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature


Re: linux-next: build failure after merge of the drm tree

2012-09-24 Thread Stephen Rothwell
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
> conflict. I guess I need to do a proper backmerge.
> 
> Fixup patch looks good for now.

If that is all that is needed, just make sure Linus is informed of the
merge conflict fix when he merged the drm tree.  If there is more, it is
up to you and Dave.  If you do a back merge, make sure that it is
properly commented.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpp6NqeLI7LB.pgp
Description: PGP signature


Re: linux-next: build failure after merge of the drm tree

2012-09-24 Thread Daniel Vetter
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: 'mode' undeclared (first use 
> in this function)
> 
> Caused by commit b98b60167279 ("drm/i915: HDMI - Clear Audio Enable bit
> for Hot Plug") from Linus' tree interacting with commit 5ab432ef4997
> ("drm/i915/hdmi: convert to encoder->disable/enable") from the drm tree.
> 
> I added the following merge fix patch (which may be wrong, of course):
> 
> From: Stephen Rothwell 
> Date: Mon, 24 Sep 2012 13:14:40 +1000
> Subject: [PATCH] drm/i915: HDMI: update for API change
> 
> Signed-off-by: Stephen Rothwell 

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
conflict. I guess I need to do a proper backmerge.

Fixup patch looks good for now.

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_hdmi.c |5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 2ec9c76..d39ed58 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -630,7 +630,7 @@ static void intel_enable_hdmi(struct intel_encoder 
> *encoder)
>   u32 temp;
>   u32 enable_bits = SDVO_ENABLE;
>  
> - if (intel_hdmi->has_audio || mode != DRM_MODE_DPMS_ON)
> + if (intel_hdmi->has_audio)
>   enable_bits |= SDVO_AUDIO_ENABLE;
>  
>   temp = I915_READ(intel_hdmi->sdvox_reg);
> @@ -676,8 +676,7 @@ static void intel_disable_hdmi(struct intel_encoder 
> *encoder)
>   u32 temp;
>   u32 enable_bits = SDVO_ENABLE;
>  
> - if (intel_hdmi->has_audio)
> - enable_bits |= SDVO_AUDIO_ENABLE;
> + enable_bits |= SDVO_AUDIO_ENABLE;
>  
>   temp = I915_READ(intel_hdmi->sdvox_reg);
>  
> -- 
> 1.7.10.280.gaa39
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2012-09-24 Thread Daniel Vetter
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: 'mode' undeclared (first use 
 in this function)
 
 Caused by commit b98b60167279 (drm/i915: HDMI - Clear Audio Enable bit
 for Hot Plug) from Linus' tree interacting with commit 5ab432ef4997
 (drm/i915/hdmi: convert to encoder-disable/enable) from the drm tree.
 
 I added the following merge fix patch (which may be wrong, of course):
 
 From: Stephen Rothwell s...@canb.auug.org.au
 Date: Mon, 24 Sep 2012 13:14:40 +1000
 Subject: [PATCH] drm/i915: HDMI: update for API change
 
 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au

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
conflict. I guess I need to do a proper backmerge.

Fixup patch looks good for now.

Thanks, Daniel

 ---
  drivers/gpu/drm/i915/intel_hdmi.c |5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
 b/drivers/gpu/drm/i915/intel_hdmi.c
 index 2ec9c76..d39ed58 100644
 --- a/drivers/gpu/drm/i915/intel_hdmi.c
 +++ b/drivers/gpu/drm/i915/intel_hdmi.c
 @@ -630,7 +630,7 @@ static void intel_enable_hdmi(struct intel_encoder 
 *encoder)
   u32 temp;
   u32 enable_bits = SDVO_ENABLE;
  
 - if (intel_hdmi-has_audio || mode != DRM_MODE_DPMS_ON)
 + if (intel_hdmi-has_audio)
   enable_bits |= SDVO_AUDIO_ENABLE;
  
   temp = I915_READ(intel_hdmi-sdvox_reg);
 @@ -676,8 +676,7 @@ static void intel_disable_hdmi(struct intel_encoder 
 *encoder)
   u32 temp;
   u32 enable_bits = SDVO_ENABLE;
  
 - if (intel_hdmi-has_audio)
 - enable_bits |= SDVO_AUDIO_ENABLE;
 + enable_bits |= SDVO_AUDIO_ENABLE;
  
   temp = I915_READ(intel_hdmi-sdvox_reg);
  
 -- 
 1.7.10.280.gaa39
 
 -- 
 Cheers,
 Stephen Rothwells...@canb.auug.org.au



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: linux-next: build failure after merge of the drm tree

2012-09-24 Thread Stephen Rothwell
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 proper
 conflict. I guess I need to do a proper backmerge.
 
 Fixup patch looks good for now.

If that is all that is needed, just make sure Linus is informed of the
merge conflict fix when he merged the drm tree.  If there is more, it is
up to you and Dave.  If you do a back merge, make sure that it is
properly commented.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpp6NqeLI7LB.pgp
Description: PGP signature