Re: [git pull] drm for v4.7

[Emil Velikov]

On 25 May 2016 at 17:13, Linus Torvalds  wrote:
> On Wed, May 25, 2016 at 1:28 AM, Jani Nikula
>  wrote:
>>
>> There may be better ones out there, but Artem's "aiaiai" has some
>> helpers [1] for diffing build logs, if you want something simple to
>> integrate into existing scripts.
>
> It would be lovely to have some kind of warning detection, but quite
> frankly, just doing a build and counting lines in 'stderr' from the
> build and having some trigger for "oops, lots of new lines" would be
> sufficient.
>
> So I don't think anything really fancy to diff build logs is
> necessarily needed, although the people who then get the report about
> "your merge causes lots of new warnings" might appreciate it.
>
The Intel 0-Day already checks when patch introduces new warnings,
emailing the author and subsystem with the details. In this particular
case, the patch was out the next day and I was silly enough not to ask
Dave to include it in the same pull request.

Regards,
Emil

Re: [git pull] drm for v4.7

[Emil Velikov]

On 25 May 2016 at 17:13, Linus Torvalds  wrote:
> On Wed, May 25, 2016 at 1:28 AM, Jani Nikula
>  wrote:
>>
>> There may be better ones out there, but Artem's "aiaiai" has some
>> helpers [1] for diffing build logs, if you want something simple to
>> integrate into existing scripts.
>
> It would be lovely to have some kind of warning detection, but quite
> frankly, just doing a build and counting lines in 'stderr' from the
> build and having some trigger for "oops, lots of new lines" would be
> sufficient.
>
> So I don't think anything really fancy to diff build logs is
> necessarily needed, although the people who then get the report about
> "your merge causes lots of new warnings" might appreciate it.
>
The Intel 0-Day already checks when patch introduces new warnings,
emailing the author and subsystem with the details. In this particular
case, the patch was out the next day and I was silly enough not to ask
Dave to include it in the same pull request.

Regards,
Emil

Re: [git pull] drm for v4.7

[Linus Torvalds]

On Wed, May 25, 2016 at 1:28 AM, Jani Nikula
 wrote:
>
> There may be better ones out there, but Artem's "aiaiai" has some
> helpers [1] for diffing build logs, if you want something simple to
> integrate into existing scripts.

It would be lovely to have some kind of warning detection, but quite
frankly, just doing a build and counting lines in 'stderr' from the
build and having some trigger for "oops, lots of new lines" would be
sufficient.

So I don't think anything really fancy to diff build logs is
necessarily needed, although the people who then get the report about
"your merge causes lots of new warnings" might appreciate it.

Linus

Re: [git pull] drm for v4.7

[Linus Torvalds]

On Wed, May 25, 2016 at 1:28 AM, Jani Nikula
 wrote:
>
> There may be better ones out there, but Artem's "aiaiai" has some
> helpers [1] for diffing build logs, if you want something simple to
> integrate into existing scripts.

It would be lovely to have some kind of warning detection, but quite
frankly, just doing a build and counting lines in 'stderr' from the
build and having some trigger for "oops, lots of new lines" would be
sufficient.

So I don't think anything really fancy to diff build logs is
necessarily needed, although the people who then get the report about
"your merge causes lots of new warnings" might appreciate it.

Linus

Re: [git pull] drm for v4.7

[Jani Nikula]

On Wed, 25 May 2016, Stephen Rothwell  wrote:
> My bad.  That warning turned up in linux-next last Wednesday but I
> didn't notice (I have other stuff to do and don't carefully watch all
> the builds all day - and there are quite a few warnings to filter new
> ones out out of).  Maybe I need some automated way to flag new warnings.

There may be better ones out there, but Artem's "aiaiai" has some
helpers [1] for diffing build logs, if you want something simple to
integrate into existing scripts.

BR,
Jani.


[1] http://git.infradead.org/users/dedekind/aiaiai.git/tree/HEAD:/helpers


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [git pull] drm for v4.7

[Jani Nikula]

On Wed, 25 May 2016, Stephen Rothwell  wrote:
> My bad.  That warning turned up in linux-next last Wednesday but I
> didn't notice (I have other stuff to do and don't carefully watch all
> the builds all day - and there are quite a few warnings to filter new
> ones out out of).  Maybe I need some automated way to flag new warnings.

There may be better ones out there, but Artem's "aiaiai" has some
helpers [1] for diffing build logs, if you want something simple to
integrate into existing scripts.

BR,
Jani.


[1] http://git.infradead.org/users/dedekind/aiaiai.git/tree/HEAD:/helpers


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [git pull] drm for v4.7

[Stephen Rothwell]

Hi Linus,

On Mon, 23 May 2016 12:10:25 -0700 Linus Torvalds 
 wrote:
>
> Is there a patch pending for this that I'm not aware of, or is it just
> that nobody but me hates spurious warnings? Didn't this show up in
> linux-next? And if it _did_ show up in linux-next, why was the pull
> request not talking about it?

My bad.  That warning turned up in linux-next last Wednesday but I
didn't notice (I have other stuff to do and don't carefully watch all
the builds all day - and there are quite a few warnings to filter new
ones out out of).  Maybe I need some automated way to flag new warnings.

-- 
Cheers,
Stephen Rothwell

Re: [git pull] drm for v4.7

[Stephen Rothwell]

Hi Linus,

On Mon, 23 May 2016 12:10:25 -0700 Linus Torvalds 
 wrote:
>
> Is there a patch pending for this that I'm not aware of, or is it just
> that nobody but me hates spurious warnings? Didn't this show up in
> linux-next? And if it _did_ show up in linux-next, why was the pull
> request not talking about it?

My bad.  That warning turned up in linux-next last Wednesday but I
didn't notice (I have other stuff to do and don't carefully watch all
the builds all day - and there are quite a few warnings to filter new
ones out out of).  Maybe I need some automated way to flag new warnings.

-- 
Cheers,
Stephen Rothwell

Re: [git pull] drm for v4.7

[Dave Airlie]

On 24 May 2016 at 05:23, Dave Airlie  wrote:
> On 24 May 2016 at 05:20, Dave Airlie  wrote:
>> On 24 May 2016 at 04:59, Linus Torvalds  
>> wrote:
>>> On Sun, May 22, 2016 at 11:41 PM, Dave Airlie  wrote:

 Here's the main drm pull request for 4.7, it's been
 a busy one, and I've been a bit more distracted in
 real life this merge window.
>>>
>>> Hmm.
>>>
>>> I pulled this, but I think I'll have to unpull again.
>>>
>>> Neither the diffstat not the shortlog match what you sent me. There's
>>> four extra commits at the top that aren't mentioned:
>>>
>>>   Dave Airlie (3):
>>>   drm/edid: move displayid tiled block parsing into separate function.
>>>   drm/edid: move displayid validation to it's own function.
>>>   drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)
>>>
>>>   Tomas Bzatek (1):
>>>   drm/displayid: Iterate over all DisplayID blocks
>>>
>>> was that intentional? What happened? Are those commits meant to be
>>> merged, or are they wrong? They _look_ ok, but dammit, according to
>>> your message they shouldn't be there.
>>
>> Okay they are meant to be in there, I just had them on my merge list,
>> remembered I hadn't merged them, but had generated a pull request earlier
>> to edit for you and forgot to regenerate it. I'll follow up with a new
>> pull request
>> if you like just to keep things straight.
>>
>> The "extern C" warnings were one of the patches Arnd sent, I'll follow up 
>> with
>> those today.

FYI:
https://patchwork.freedesktop.org/patch/87900/

is a link to Arnd's patch.

Dave.

Re: [git pull] drm for v4.7

[Dave Airlie]

On 24 May 2016 at 05:23, Dave Airlie  wrote:
> On 24 May 2016 at 05:20, Dave Airlie  wrote:
>> On 24 May 2016 at 04:59, Linus Torvalds  
>> wrote:
>>> On Sun, May 22, 2016 at 11:41 PM, Dave Airlie  wrote:

 Here's the main drm pull request for 4.7, it's been
 a busy one, and I've been a bit more distracted in
 real life this merge window.
>>>
>>> Hmm.
>>>
>>> I pulled this, but I think I'll have to unpull again.
>>>
>>> Neither the diffstat not the shortlog match what you sent me. There's
>>> four extra commits at the top that aren't mentioned:
>>>
>>>   Dave Airlie (3):
>>>   drm/edid: move displayid tiled block parsing into separate function.
>>>   drm/edid: move displayid validation to it's own function.
>>>   drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)
>>>
>>>   Tomas Bzatek (1):
>>>   drm/displayid: Iterate over all DisplayID blocks
>>>
>>> was that intentional? What happened? Are those commits meant to be
>>> merged, or are they wrong? They _look_ ok, but dammit, according to
>>> your message they shouldn't be there.
>>
>> Okay they are meant to be in there, I just had them on my merge list,
>> remembered I hadn't merged them, but had generated a pull request earlier
>> to edit for you and forgot to regenerate it. I'll follow up with a new
>> pull request
>> if you like just to keep things straight.
>>
>> The "extern C" warnings were one of the patches Arnd sent, I'll follow up 
>> with
>> those today.

FYI:
https://patchwork.freedesktop.org/patch/87900/

is a link to Arnd's patch.

Dave.

Re: [git pull] drm for v4.7

[Dave Airlie]

On 24 May 2016 at 05:20, Dave Airlie  wrote:
> On 24 May 2016 at 04:59, Linus Torvalds  wrote:
>> On Sun, May 22, 2016 at 11:41 PM, Dave Airlie  wrote:
>>>
>>> Here's the main drm pull request for 4.7, it's been
>>> a busy one, and I've been a bit more distracted in
>>> real life this merge window.
>>
>> Hmm.
>>
>> I pulled this, but I think I'll have to unpull again.
>>
>> Neither the diffstat not the shortlog match what you sent me. There's
>> four extra commits at the top that aren't mentioned:
>>
>>   Dave Airlie (3):
>>   drm/edid: move displayid tiled block parsing into separate function.
>>   drm/edid: move displayid validation to it's own function.
>>   drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)
>>
>>   Tomas Bzatek (1):
>>   drm/displayid: Iterate over all DisplayID blocks
>>
>> was that intentional? What happened? Are those commits meant to be
>> merged, or are they wrong? They _look_ ok, but dammit, according to
>> your message they shouldn't be there.
>
> Okay they are meant to be in there, I just had them on my merge list,
> remembered I hadn't merged them, but had generated a pull request earlier
> to edit for you and forgot to regenerate it. I'll follow up with a new
> pull request
> if you like just to keep things straight.
>
> The "extern C" warnings were one of the patches Arnd sent, I'll follow up with
> those today.

Updated pull request:

The following changes since commit 44549e8f5eea4e0a41b487b63e616cb089922b99:

  Linux 4.6-rc7 (2016-05-08 14:38:32 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-next

for you to fetch changes up to a39ed680bddb1ead592e22ed812c7e47286bfc03:

  drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)
(2016-05-23 11:35:31 +1000)


Akash Goel (4):
  drm/i915: Fixup the free space logic in ring_prepare
  drm/i915: Macros to convert PM time interval values to microseconds
  drm/i915: Correct the i915_frequency_info debugfs output
  drm/i915/bxt: Explicitly clear the Turbo control register

Alan (1):
  drm/gma500/mdfld_dsi: remove bogus if check

Alex Dai (2):
  drm/i915/guc: Support GuC SKL v6.1
  drm/i915/guc: drop cached copy of 'wq_head'

Alex Deucher (42):
  drm/amd/powerplay: fix stutter setup in mclk level init
  drm/amdgpu: add new CG flag for ROM clockgating
  drm/amdgpu/gfx: add proper CG flags for fiji
  drm/amdgpu/sdma: add proper CG flags for fiji
  drm/amdgpu/common: add proper CG flags for fiji
  drm/amdgpu/gmc: add proper CG flags for fiji
  drm/amdgpu/gfx8: rename send_serdes_cmd
  drm/amdgpu/gfx: adjust gfx_v8_0_send_serdes_cmd for ST
  drm/amdgpu: add a new set of rlc function pointers
  drm/amdgpu/gfx: rework fiji cg functions so they can be shared
  drm/amdgpu: enable gfx clockgating for CZ
  drm/amdgpu: enable gfx clockgating for ST (v2)
  drm/amdgpu/vi: rename fiji cg functions
  drm/amdgpu: enable gmc clockgating for CZ
  drm/amdgpu: enable gmc clockgating for ST
  drm/amdgpu/sdma: rename fiji cg functions
  drm/amdgpu: enable sdma clockgating on CZ
  drm/amdgpu: enable sdma clockgating on ST
  drm/amd: add DCE 11.2 register headers
  drm/amdgpu: add ELM/BAF asic types
  drm/amdgpu: add ELM/BAF DCE11 configs (v2)
  drm/amdgpu: use defines for CRTCs and AMFT blocks
  drm/amdgpu: bump the afmt limit for CZ, ST, Polaris
  drm/amdgpu: update atombios.h (v2)
  drm/amdgpu/atom: add SetDCEClock helper
  drm/amdgpu/atom: add support for new SetPixelClock table
  drm/amdgpu/atom: add support for new DIGxEncoderControl cmd table
  drm/amdgpu/atom: add support for new UNIPHYTransmitterContol cmd table
  drm/amdgpu: add ELM/BAF support to dce_v11_0_pick_pll (v2)
  drm/amdgpu/dce11: update pll programming for ELM/BAF
  drm/amdgpu/dce11: add dce clock setting for ELM/BAF
  drm/amdgpu: add an interface to get gfx constants from atombios
  drm/amd/powerplay: fix copy paste error in error message
  drm/powerplay: add missing clockgating callback for tonga
  drm/amdgpu/fiji: set UVD CG state when enabling UVD DPM (v2)
  drm/amdgpu/uvd6: add bypass support for fiji (v3)
  drm/amdgpu: use drm_mode_vrefresh() rather than mode->vrefresh
  drm/amdgpu: fetch cu_info once at init
  drm/amdgpu: add missing licenses on a couple of files
  drm/amdgpu/dce11: don't share PLLs on Polaris
  drm/amdgpu: Support DRM_MODE_PAGE_FLIP_ASYNC (v2)
  drm/amdgpu/dce11: fix audio offset for asics with >7 audio pins

Alexandre Courbot (1):
  drm/nouveau/devinit/gf100: make devinit on resume safer

Alexey Brodkin (9):
  drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all()
  drm: Introduce drm_connector_register_all() helper

Re: [git pull] drm for v4.7

[Dave Airlie]

On 24 May 2016 at 05:20, Dave Airlie  wrote:
> On 24 May 2016 at 04:59, Linus Torvalds  wrote:
>> On Sun, May 22, 2016 at 11:41 PM, Dave Airlie  wrote:
>>>
>>> Here's the main drm pull request for 4.7, it's been
>>> a busy one, and I've been a bit more distracted in
>>> real life this merge window.
>>
>> Hmm.
>>
>> I pulled this, but I think I'll have to unpull again.
>>
>> Neither the diffstat not the shortlog match what you sent me. There's
>> four extra commits at the top that aren't mentioned:
>>
>>   Dave Airlie (3):
>>   drm/edid: move displayid tiled block parsing into separate function.
>>   drm/edid: move displayid validation to it's own function.
>>   drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)
>>
>>   Tomas Bzatek (1):
>>   drm/displayid: Iterate over all DisplayID blocks
>>
>> was that intentional? What happened? Are those commits meant to be
>> merged, or are they wrong? They _look_ ok, but dammit, according to
>> your message they shouldn't be there.
>
> Okay they are meant to be in there, I just had them on my merge list,
> remembered I hadn't merged them, but had generated a pull request earlier
> to edit for you and forgot to regenerate it. I'll follow up with a new
> pull request
> if you like just to keep things straight.
>
> The "extern C" warnings were one of the patches Arnd sent, I'll follow up with
> those today.

Updated pull request:

The following changes since commit 44549e8f5eea4e0a41b487b63e616cb089922b99:

  Linux 4.6-rc7 (2016-05-08 14:38:32 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-next

for you to fetch changes up to a39ed680bddb1ead592e22ed812c7e47286bfc03:

  drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)
(2016-05-23 11:35:31 +1000)


Akash Goel (4):
  drm/i915: Fixup the free space logic in ring_prepare
  drm/i915: Macros to convert PM time interval values to microseconds
  drm/i915: Correct the i915_frequency_info debugfs output
  drm/i915/bxt: Explicitly clear the Turbo control register

Alan (1):
  drm/gma500/mdfld_dsi: remove bogus if check

Alex Dai (2):
  drm/i915/guc: Support GuC SKL v6.1
  drm/i915/guc: drop cached copy of 'wq_head'

Alex Deucher (42):
  drm/amd/powerplay: fix stutter setup in mclk level init
  drm/amdgpu: add new CG flag for ROM clockgating
  drm/amdgpu/gfx: add proper CG flags for fiji
  drm/amdgpu/sdma: add proper CG flags for fiji
  drm/amdgpu/common: add proper CG flags for fiji
  drm/amdgpu/gmc: add proper CG flags for fiji
  drm/amdgpu/gfx8: rename send_serdes_cmd
  drm/amdgpu/gfx: adjust gfx_v8_0_send_serdes_cmd for ST
  drm/amdgpu: add a new set of rlc function pointers
  drm/amdgpu/gfx: rework fiji cg functions so they can be shared
  drm/amdgpu: enable gfx clockgating for CZ
  drm/amdgpu: enable gfx clockgating for ST (v2)
  drm/amdgpu/vi: rename fiji cg functions
  drm/amdgpu: enable gmc clockgating for CZ
  drm/amdgpu: enable gmc clockgating for ST
  drm/amdgpu/sdma: rename fiji cg functions
  drm/amdgpu: enable sdma clockgating on CZ
  drm/amdgpu: enable sdma clockgating on ST
  drm/amd: add DCE 11.2 register headers
  drm/amdgpu: add ELM/BAF asic types
  drm/amdgpu: add ELM/BAF DCE11 configs (v2)
  drm/amdgpu: use defines for CRTCs and AMFT blocks
  drm/amdgpu: bump the afmt limit for CZ, ST, Polaris
  drm/amdgpu: update atombios.h (v2)
  drm/amdgpu/atom: add SetDCEClock helper
  drm/amdgpu/atom: add support for new SetPixelClock table
  drm/amdgpu/atom: add support for new DIGxEncoderControl cmd table
  drm/amdgpu/atom: add support for new UNIPHYTransmitterContol cmd table
  drm/amdgpu: add ELM/BAF support to dce_v11_0_pick_pll (v2)
  drm/amdgpu/dce11: update pll programming for ELM/BAF
  drm/amdgpu/dce11: add dce clock setting for ELM/BAF
  drm/amdgpu: add an interface to get gfx constants from atombios
  drm/amd/powerplay: fix copy paste error in error message
  drm/powerplay: add missing clockgating callback for tonga
  drm/amdgpu/fiji: set UVD CG state when enabling UVD DPM (v2)
  drm/amdgpu/uvd6: add bypass support for fiji (v3)
  drm/amdgpu: use drm_mode_vrefresh() rather than mode->vrefresh
  drm/amdgpu: fetch cu_info once at init
  drm/amdgpu: add missing licenses on a couple of files
  drm/amdgpu/dce11: don't share PLLs on Polaris
  drm/amdgpu: Support DRM_MODE_PAGE_FLIP_ASYNC (v2)
  drm/amdgpu/dce11: fix audio offset for asics with >7 audio pins

Alexandre Courbot (1):
  drm/nouveau/devinit/gf100: make devinit on resume safer

Alexey Brodkin (9):
  drm: Rename drm_connector_unplug_all() to drm_connector_unregister_all()
  drm: Introduce drm_connector_register_all() helper
  drm: atmel_hldc: Use generic drm_connector_register_all() 

Re: [git pull] drm for v4.7

[Dave Airlie]

On 24 May 2016 at 04:59, Linus Torvalds  wrote:
> On Sun, May 22, 2016 at 11:41 PM, Dave Airlie  wrote:
>>
>> Here's the main drm pull request for 4.7, it's been
>> a busy one, and I've been a bit more distracted in
>> real life this merge window.
>
> Hmm.
>
> I pulled this, but I think I'll have to unpull again.
>
> Neither the diffstat not the shortlog match what you sent me. There's
> four extra commits at the top that aren't mentioned:
>
>   Dave Airlie (3):
>   drm/edid: move displayid tiled block parsing into separate function.
>   drm/edid: move displayid validation to it's own function.
>   drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)
>
>   Tomas Bzatek (1):
>   drm/displayid: Iterate over all DisplayID blocks
>
> was that intentional? What happened? Are those commits meant to be
> merged, or are they wrong? They _look_ ok, but dammit, according to
> your message they shouldn't be there.

Okay they are meant to be in there, I just had them on my merge list,
remembered I hadn't merged them, but had generated a pull request earlier
to edit for you and forgot to regenerate it. I'll follow up with a new
pull request
if you like just to keep things straight.

The "extern C" warnings were one of the patches Arnd sent, I'll follow up with
those today.
>
>
> This is one reason I much prefer getting explicit tags rather than a
> random branch. Did you update the branch on purpose and wanted me to
> get the new state, or did you update the branch just because you
> happened to do development on that branch and pushed it out? With an
> explicit tag, there's a much more _intentional_ "push this to Linus"
> thing going on, and it's less ambiguous in cases like this.

I'll try and do explicit tags from now on, it should stop me doing
stupid things as well.

Dave.

Re: [git pull] drm for v4.7

[Dave Airlie]

On 24 May 2016 at 04:59, Linus Torvalds  wrote:
> On Sun, May 22, 2016 at 11:41 PM, Dave Airlie  wrote:
>>
>> Here's the main drm pull request for 4.7, it's been
>> a busy one, and I've been a bit more distracted in
>> real life this merge window.
>
> Hmm.
>
> I pulled this, but I think I'll have to unpull again.
>
> Neither the diffstat not the shortlog match what you sent me. There's
> four extra commits at the top that aren't mentioned:
>
>   Dave Airlie (3):
>   drm/edid: move displayid tiled block parsing into separate function.
>   drm/edid: move displayid validation to it's own function.
>   drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)
>
>   Tomas Bzatek (1):
>   drm/displayid: Iterate over all DisplayID blocks
>
> was that intentional? What happened? Are those commits meant to be
> merged, or are they wrong? They _look_ ok, but dammit, according to
> your message they shouldn't be there.

Okay they are meant to be in there, I just had them on my merge list,
remembered I hadn't merged them, but had generated a pull request earlier
to edit for you and forgot to regenerate it. I'll follow up with a new
pull request
if you like just to keep things straight.

The "extern C" warnings were one of the patches Arnd sent, I'll follow up with
those today.
>
>
> This is one reason I much prefer getting explicit tags rather than a
> random branch. Did you update the branch on purpose and wanted me to
> get the new state, or did you update the branch just because you
> happened to do development on that branch and pushed it out? With an
> explicit tag, there's a much more _intentional_ "push this to Linus"
> thing going on, and it's less ambiguous in cases like this.

I'll try and do explicit tags from now on, it should stop me doing
stupid things as well.

Dave.

Re: [git pull] drm for v4.7

[Linus Torvalds]

On Mon, May 23, 2016 at 11:59 AM, Linus Torvalds
 wrote:
>
> I'll test this out and look what happens, but I hate getting different
> results than what I'm told to expect.

Hmm. I also get a lot of

  ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference
function or variable defined in the kernel
  ./usr/include/drm/drm.h:63: userspace cannot reference function or
variable defined in the kernel
  ./usr/include/drm/drm.h:699: userspace cannot reference function or
variable defined in the kernel
  ...

warnings with my allmodconfig build. They do seem to be due to
checkpatch not really grokking the

  #if defined(__cplusplus)
  extern "C" {
  #endif

and thinking that's a sign of a kernel function or variable
declaration being exported to user space, but it's a bit annoying.

Is there a patch pending for this that I'm not aware of, or is it just
that nobody but me hates spurious warnings? Didn't this show up in
linux-next? And if it _did_ show up in linux-next, why was the pull
request not talking about it?

 Linus

Re: [git pull] drm for v4.7

[Linus Torvalds]

On Mon, May 23, 2016 at 11:59 AM, Linus Torvalds
 wrote:
>
> I'll test this out and look what happens, but I hate getting different
> results than what I'm told to expect.

Hmm. I also get a lot of

  ./usr/include/drm/amdgpu_drm.h:38: userspace cannot reference
function or variable defined in the kernel
  ./usr/include/drm/drm.h:63: userspace cannot reference function or
variable defined in the kernel
  ./usr/include/drm/drm.h:699: userspace cannot reference function or
variable defined in the kernel
  ...

warnings with my allmodconfig build. They do seem to be due to
checkpatch not really grokking the

  #if defined(__cplusplus)
  extern "C" {
  #endif

and thinking that's a sign of a kernel function or variable
declaration being exported to user space, but it's a bit annoying.

Is there a patch pending for this that I'm not aware of, or is it just
that nobody but me hates spurious warnings? Didn't this show up in
linux-next? And if it _did_ show up in linux-next, why was the pull
request not talking about it?

 Linus

Re: [git pull] drm for v4.7

[Linus Torvalds]

On Sun, May 22, 2016 at 11:41 PM, Dave Airlie  wrote:
>
> Here's the main drm pull request for 4.7, it's been
> a busy one, and I've been a bit more distracted in
> real life this merge window.

Hmm.

I pulled this, but I think I'll have to unpull again.

Neither the diffstat not the shortlog match what you sent me. There's
four extra commits at the top that aren't mentioned:

  Dave Airlie (3):
  drm/edid: move displayid tiled block parsing into separate function.
  drm/edid: move displayid validation to it's own function.
  drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)

  Tomas Bzatek (1):
  drm/displayid: Iterate over all DisplayID blocks

was that intentional? What happened? Are those commits meant to be
merged, or are they wrong? They _look_ ok, but dammit, according to
your message they shouldn't be there.

I'll test this out and look what happens, but I hate getting different
results than what I'm told to expect.

This is one reason I much prefer getting explicit tags rather than a
random branch. Did you update the branch on purpose and wanted me to
get the new state, or did you update the branch just because you
happened to do development on that branch and pushed it out? With an
explicit tag, there's a much more _intentional_ "push this to Linus"
thing going on, and it's less ambiguous in cases like this.

 Linus

Re: [git pull] drm for v4.7

[Linus Torvalds]

On Sun, May 22, 2016 at 11:41 PM, Dave Airlie  wrote:
>
> Here's the main drm pull request for 4.7, it's been
> a busy one, and I've been a bit more distracted in
> real life this merge window.

Hmm.

I pulled this, but I think I'll have to unpull again.

Neither the diffstat not the shortlog match what you sent me. There's
four extra commits at the top that aren't mentioned:

  Dave Airlie (3):
  drm/edid: move displayid tiled block parsing into separate function.
  drm/edid: move displayid validation to it's own function.
  drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)

  Tomas Bzatek (1):
  drm/displayid: Iterate over all DisplayID blocks

was that intentional? What happened? Are those commits meant to be
merged, or are they wrong? They _look_ ok, but dammit, according to
your message they shouldn't be there.

I'll test this out and look what happens, but I hate getting different
results than what I'm told to expect.

This is one reason I much prefer getting explicit tags rather than a
random branch. Did you update the branch on purpose and wanted me to
get the new state, or did you update the branch just because you
happened to do development on that branch and pushed it out? With an
explicit tag, there's a much more _intentional_ "push this to Linus"
thing going on, and it's less ambiguous in cases like this.

 Linus