dri-devel

[PATCH] drm/amd/display: restore plane with no modifiers code.

[Dave A. <ai...@re...>]

When this file was split in

5d945cbcd4b16a29d6470a80dfb19738f9a4319f
Author: Rodrigo Siqueira <Rod...@am...>
Date:   Wed Jul 20 15:31:42 2022 -0400

drm/amd/display: Create a file dedicated to planes

This chunk seemed to get dropped. Linus noticed on this
rx580 and I've reproduced on FIJI which makes sense as these
are pre-modifier GPUs.

With this applied, I get gdm back.

Fixes: 5d945cbcd4b1 ("drm/amd/display: Create a file dedicated to planes")
Signed-off-by: Dave Airlie <ai...@re...>
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 8cd25b2ea0dc..b841b8b0a9d8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
@@ -1591,6 +1591,9 @@ int amdgpu_dm_plane_init(struct amdgpu_display_manager *dm,
 	if (res)
 		return res;
 
+	if (modifiers == NULL)
+		adev_to_drm(dm->adev)->mode_config.fb_modifiers_not_supported = true;
+
 	res = drm_universal_plane_init(adev_to_drm(dm->adev), plane, possible_crtcs,
 				       &dm_plane_funcs, formats, num_formats,
 				       modifiers, plane->type, NULL);
-- 
2.37.1

[PATCH] docs: driver-api: firmware: add driver firmware guidelines. (v3)

[Dave A. <ai...@gm...>]

From: Dave Airlie <ai...@re...>

A recent snafu where Intel ignored upstream feedback on a firmware
change, led to a late rc6 fix being required. In order to avoid this
in the future we should document some expectations around
linux-firmware.

I was originally going to write this for drm, but it seems quite generic
advice.

v2: rewritten with suggestions from Thorsten Leemhuis
v3: rewritten with suggestions from Mauro

Acked-by: Luis Chamberlain <mc...@ke...>
Acked-by: Rodrigo Vivi <rod...@in...>
Acked-by: Daniel Vetter <da...@ff...>
Acked-by: Harry Wentland <har...@am...>
Signed-off-by: Dave Airlie <ai...@re...>
---
 Documentation/driver-api/firmware/core.rst    |  1 +
 .../firmware/firmware-usage-guidelines.rst    | 44 +++++++++++++++++++
 2 files changed, 45 insertions(+)
 create mode 100644 Documentation/driver-api/firmware/firmware-usage-guidelines.rst

diff --git a/Documentation/driver-api/firmware/core.rst b/Documentation/driver-api/firmware/core.rst
index 1d1688cbc078..803cd574bbd7 100644
--- a/Documentation/driver-api/firmware/core.rst
+++ b/Documentation/driver-api/firmware/core.rst
@@ -13,4 +13,5 @@ documents these features.
    direct-fs-lookup
    fallback-mechanisms
    lookup-order
+   firmware-usage-guidelines
 
diff --git a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
new file mode 100644
index 000000000000..fdcfce42c6d2
--- /dev/null
+++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
@@ -0,0 +1,44 @@
+===================
+Firmware Guidelines
+===================
+
+Users switching to a newer kernel should *not* have to install newer
+firmware files to keep their hardware working. At the same time updated
+firmware files must not cause any regressions for users of older kernel
+releases.
+
+Drivers that use firmware from linux-firmware should follow the rules in
+this guide. (Where there is limited control of the firmware,
+i.e. company doesn't support Linux, firmwares sourced from misc places,
+then of course these rules will not apply strictly.)
+
+* Firmware files shall be designed in a way that it allows checking for
+  firmware ABI version changes. It is recommended that firmware files be
+  versioned with at least a major/minor version. It is suggested that
+  the firmware files in linux-firmware be named with some device
+  specific name, and just the major version. The firmware version should
+  be stored in the firmware header, or as an exception, as part of the
+  firmware file name, in order to let the driver detact any non-ABI
+  fixes/changes. The firmware files in linux-firmware should be
+  overwritten with the newest compatible major version. Newer major
+  version firmware shall remain compatible with all kernels that load
+  that major number.
+
+* If the kernel support for the hardware is normally inactive, or the
+  hardware isn't available for public consumption, this can
+  be ignored, until the first kernel release that enables that hardware.
+  This means no major version bumps without the kernel retaining
+  backwards compatibility for the older major versions.  Minor version
+  bumps should not introduce new features that newer kernels depend on
+  non-optionally.
+
+* If a security fix needs lockstep firmware and kernel fixes in order to
+  be successful, then all supported major versions in the linux-firmware
+  repo that are required by currently supported stable/LTS kernels,
+  should be updated with the security fix. The kernel patches should
+  detect if the firmware is new enough to declare if the security issue
+  is fixed.  All communications around security fixes should point at
+  both the firmware and kernel fixes. If a security fix requires
+  deprecating old major versions, then this should only be done as a
+  last option, and be stated clearly in all communications.
+
-- 
2.36.1

Re: [PATCH] docs: driver-api: firmware: add driver firmware guidelines. (v2)

[Dave A. <ai...@gm...>]

> It is hard to enforce how vendors will version their firmware. On media,
> we have some drivers whose major means different hardware versions. For
> instance, on xc3028, v3.x means low voltage chips, while v2.x means
> "normal" voltage. We end changing the file name on Linux to avoid the risk
> of damaging the hardware, as using v27 firmware on low power chips damage
> them. So, we have:
>
>         drivers/media/tuners/xc2028.h:#define XC2028_DEFAULT_FIRMWARE "xc3028-v27.fw"
>         drivers/media/tuners/xc2028.h:#define XC3028L_DEFAULT_FIRMWARE "xc3028L-v36.fw"
>
> As their main market is not Linux - nor PC - as their main sales are on
> TV sets, and them don't officially support Linux, there's nothing we can
> do to enforce it.
>
> IMO we need a more generic text here to indicate that Linux firmware
> files should be defined in a way that it should be possible to detect
> when there are incompatibilities with past versions.
> So, I would say, instead:
>
>         Firmware files shall be designed in a way that it allows
>         checking for firmware ABI version changes. It is recommended
>         that firmware files to be versioned with at least major/minor
>         version.

This sounds good, will update with this.

>
> > It
> > +  is suggested that the firmware files in linux-firmware be named with
> > +  some device specific name, and just the major version.
>
> > The
> > +  major/minor/patch versions should be stored in a header in the
> > +  firmware file for the driver to detect any non-ABI fixes/issues.
>
> I would also make this more generic. On media, we ended adding the firmware
> version indicated at the file name. For instance, xc4000 driver checks for
> two firmware files:
>
> drivers/media/tuners/xc4000.c:#define XC4000_DEFAULT_FIRMWARE "dvb-fe-xc4000-1.4.fw"
> drivers/media/tuners/xc4000.c:#define XC4000_DEFAULT_FIRMWARE_NEW "dvb-fe-xc4000-1.4.1.fw"

This is probably fine for products where development never produces
much firmwares, but it quickly becomes unmanageable when you end up
with _NEW_NEW_NEW etc.

I'd rather not encourage this sort of thing unless it is totally
outside our control. So I'd like to keep the guidelines for when we
have some control what we'd recommend.

In this case I'd have recommended you put the 1.4.1 in the header of
the fw, and just have it called dvb-fe-xc4000-1.fw and overwrite the
NEW with the OLD, I understand we likely don't have the control here.

> > +  firmware files in linux-firmware should be overwritten with the newest
> > +  compatible major version.
>
> For me "shall" is mandatory, while "should" is optional.
>
> In this specific case, I'm not so sure if overriding it is the best thing
> to do on all subsystems. I mean, even with the same ABI, older firmware
> usually means that some bugs and/or limitations will be present there.

As long as you can detect the minor/patch versions from the firmware
file after loading it you should be able to do sufficient workarounds.
>
> That's specially true on codecs: even having the same ABI, older versions
> won't support decoding newer protocols. We have one case with some
> digital TV decoders that only support some Cable-TV protocols with
> newer firmware versions. We have also one case were remote controller
> decoding is buggy with older firmwares. On both situations, the ABI
> didn't change.

If the only way to figure that out is by the filename or minor
version, then so be it, but where people have some control I'd rather
provide some harder guidelines.

Dave.

[PATCH] docs: driver-api: firmware: add driver firmware guidelines. (v2)

[Dave A. <ai...@gm...>]

From: Dave Airlie <ai...@re...>

A recent snafu where Intel ignored upstream feedback on a firmware
change, led to a late rc6 fix being required. In order to avoid this
in the future we should document some expectations around
linux-firmware.

I was originally going to write this for drm, but it seems quite generic
advice.

v2: rewritten with suggestions from Thorsten Leemhuis.

Acked-by: Luis Chamberlain <mc...@ke...>
Acked-by: Rodrigo Vivi <rod...@in...>
Signed-off-by: Dave Airlie <ai...@re...>
---
 Documentation/driver-api/firmware/core.rst    |  1 +
 .../firmware/firmware-usage-guidelines.rst    | 34 +++++++++++++++++++
 2 files changed, 35 insertions(+)
 create mode 100644 Documentation/driver-api/firmware/firmware-usage-guidelines.rst

diff --git a/Documentation/driver-api/firmware/core.rst b/Documentation/driver-api/firmware/core.rst
index 1d1688cbc078..803cd574bbd7 100644
--- a/Documentation/driver-api/firmware/core.rst
+++ b/Documentation/driver-api/firmware/core.rst
@@ -13,4 +13,5 @@ documents these features.
    direct-fs-lookup
    fallback-mechanisms
    lookup-order
+   firmware-usage-guidelines
 
diff --git a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
new file mode 100644
index 000000000000..34d2412e78c6
--- /dev/null
+++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
@@ -0,0 +1,34 @@
+===================
+Firmware Guidelines
+===================
+
+Drivers that use firmware from linux-firmware should attempt to follow
+the rules in this guide.
+
+* Firmware should be versioned with at least a major/minor version. It
+  is suggested that the firmware files in linux-firmware be named with
+  some device specific name, and just the major version. The
+  major/minor/patch versions should be stored in a header in the
+  firmware file for the driver to detect any non-ABI fixes/issues. The
+  firmware files in linux-firmware should be overwritten with the newest
+  compatible major version. Newer major version firmware should remain
+  compatible with all kernels that load that major number.
+
+* Users should *not* have to install newer firmware to use existing
+  hardware when they install a newer kernel.  If the hardware isn't
+  enabled by default or under development, this can be ignored, until
+  the first kernel release that enables that hardware.  This means no
+  major version bumps without the kernel retaining backwards
+  compatibility for the older major versions.  Minor version bumps
+  should not introduce new features that newer kernels depend on
+  non-optionally.
+
+* If a security fix needs lockstep firmware and kernel fixes in order to
+  be successful, then all supported major versions in the linux-firmware
+  repo should be updated with the security fix, and the kernel patches
+  should detect if the firmware is new enough to declare if the security
+  issue is fixed.  All communications around security fixes should point
+  at both the firmware and kernel fixes. If a security fix requires
+  deprecating old major versions, then this should only be done as a
+  last option, and be stated clearly in all communications.
+
-- 
2.36.1

Re: [PATCH] docs: driver-api: firmware: add driver firmware guidelines.

[Dave A. <ai...@gm...>]

On Tue, 19 Jul 2022 at 08:04, Jakub Kicinski <ku...@ke...> wrote:
>
> On Mon, 18 Jul 2022 11:33:11 +0200 Thorsten Leemhuis wrote:
> > > If the hardware isn't
> > > +  enabled by default or under development,
> >
> > Wondering if it might be better to drop the "or under development", as
> > the "enabled by default" is the main part afaics. Maybe something like
> > "If support for the hardware is normally inactive (e.g. has to be
> > enabled manually by a kernel parameter)" would be better anyway.
>
> It's a tricky one, I'd say something like you can break the FW ABI
> "until HW becomes available for public consumption" or such.
> I'm guessing what we're after is letting people break the compatibility
> in early stages of the product development cycles. Pre-silicon and
> bring up, but not after there are products on the market?

I'll stick with enabled by default I think, "public consumption"
invites efforts to describe corners of the cloud or other places where
hw has shipped but is not technically "public",

Dave.

Re: [PATCH] docs: driver-api: firmware: add driver firmware guidelines.

[Dave A. <ai...@gm...>]

> > +* Firmware should be versioned with at least a major/minor version. It
> > +  is suggested that the firmware files in linux-firmware be named with
> > +  some device specific name, and just the major version. The
> > +  major/minor/patch versions should be stored in a header in the
> > +  firmware file for the driver to detect any non-ABI fixes/issues. The
> > +  firmware files in linux-firmware should be overwritten with the newest
> > +  compatible major version. Newer major version firmware should remain
> > +  compatible with all kernels that load that major number.
>
> would symbolic links be acceptable in the linux-firmware.git where
> the <fmw>_<major>.bin is a sym link to <fwm>_<major>.<minor>.bin
>
> or having the <fwm>_<major>.bin really to be the overwritten every minor
> update?

I don't think providing multiple minor versions of fw in
linux-firmware is that interesting.
Like if the major is the same, surely you always want the newer ones.
As long as the
ABI doesn't break. Otherwise we are just wasting disk space with fws
nobody will be using.

Dave.

[PATCH] docs: driver-api: firmware: add driver firmware guidelines.

[Dave A. <ai...@gm...>]

From: Dave Airlie <ai...@re...>

A recent snafu where Intel ignored upstream feedback on a firmware
change, led to a late rc6 fix being required. In order to avoid this
in the future we should document some expectations around
linux-firmware.

I was originally going to write this for drm, but it seems quite generic
advice.

I'm cc'ing this quite widely to reach subsystems which use fw a lot.

Signed-off-by: Dave Airlie <ai...@re...>
---
 Documentation/driver-api/firmware/core.rst    |  1 +
 .../firmware/firmware-usage-guidelines.rst    | 34 +++++++++++++++++++
 2 files changed, 35 insertions(+)
 create mode 100644 Documentation/driver-api/firmware/firmware-usage-guidelines.rst

diff --git a/Documentation/driver-api/firmware/core.rst b/Documentation/driver-api/firmware/core.rst
index 1d1688cbc078..803cd574bbd7 100644
--- a/Documentation/driver-api/firmware/core.rst
+++ b/Documentation/driver-api/firmware/core.rst
@@ -13,4 +13,5 @@ documents these features.
    direct-fs-lookup
    fallback-mechanisms
    lookup-order
+   firmware-usage-guidelines
 
diff --git a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
new file mode 100644
index 000000000000..34d2412e78c6
--- /dev/null
+++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
@@ -0,0 +1,34 @@
+===================
+Firmware Guidelines
+===================
+
+Drivers that use firmware from linux-firmware should attempt to follow
+the rules in this guide.
+
+* Firmware should be versioned with at least a major/minor version. It
+  is suggested that the firmware files in linux-firmware be named with
+  some device specific name, and just the major version. The
+  major/minor/patch versions should be stored in a header in the
+  firmware file for the driver to detect any non-ABI fixes/issues. The
+  firmware files in linux-firmware should be overwritten with the newest
+  compatible major version. Newer major version firmware should remain
+  compatible with all kernels that load that major number.
+
+* Users should *not* have to install newer firmware to use existing
+  hardware when they install a newer kernel.  If the hardware isn't
+  enabled by default or under development, this can be ignored, until
+  the first kernel release that enables that hardware.  This means no
+  major version bumps without the kernel retaining backwards
+  compatibility for the older major versions.  Minor version bumps
+  should not introduce new features that newer kernels depend on
+  non-optionally.
+
+* If a security fix needs lockstep firmware and kernel fixes in order to
+  be successful, then all supported major versions in the linux-firmware
+  repo should be updated with the security fix, and the kernel patches
+  should detect if the firmware is new enough to declare if the security
+  issue is fixed.  All communications around security fixes should point
+  at both the firmware and kernel fixes. If a security fix requires
+  deprecating old major versions, then this should only be done as a
+  last option, and be stated clearly in all communications.
+
-- 
2.36.1

[PATCH] docs: driver-api: firmware: add driver firmware guidelines.

[Dave A. <ai...@re...>]

A recent snafu where Intel ignored upstream feedback on a firmware
change, led to a late rc6 fix being required. In order to avoid this
in the future we should document some expectations around
linux-firmware.

I was originally going to write this for drm, but it seems quite generic
advice.

Signed-off-by: Dave Airlie <ai...@re...>
---
 Documentation/driver-api/firmware/core.rst    |  1 +
 .../firmware/firmware-usage-guidelines.rst    | 34 +++++++++++++++++++
 2 files changed, 35 insertions(+)
 create mode 100644 Documentation/driver-api/firmware/firmware-usage-guidelines.rst

diff --git a/Documentation/driver-api/firmware/core.rst b/Documentation/driver-api/firmware/core.rst
index 1d1688cbc078..803cd574bbd7 100644
--- a/Documentation/driver-api/firmware/core.rst
+++ b/Documentation/driver-api/firmware/core.rst
@@ -13,4 +13,5 @@ documents these features.
    direct-fs-lookup
    fallback-mechanisms
    lookup-order
+   firmware-usage-guidelines
 
diff --git a/Documentation/driver-api/firmware/firmware-usage-guidelines.rst b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
new file mode 100644
index 000000000000..34d2412e78c6
--- /dev/null
+++ b/Documentation/driver-api/firmware/firmware-usage-guidelines.rst
@@ -0,0 +1,34 @@
+===================
+Firmware Guidelines
+===================
+
+Drivers that use firmware from linux-firmware should attempt to follow
+the rules in this guide.
+
+* Firmware should be versioned with at least a major/minor version. It
+  is suggested that the firmware files in linux-firmware be named with
+  some device specific name, and just the major version. The
+  major/minor/patch versions should be stored in a header in the
+  firmware file for the driver to detect any non-ABI fixes/issues. The
+  firmware files in linux-firmware should be overwritten with the newest
+  compatible major version. Newer major version firmware should remain
+  compatible with all kernels that load that major number.
+
+* Users should *not* have to install newer firmware to use existing
+  hardware when they install a newer kernel.  If the hardware isn't
+  enabled by default or under development, this can be ignored, until
+  the first kernel release that enables that hardware.  This means no
+  major version bumps without the kernel retaining backwards
+  compatibility for the older major versions.  Minor version bumps
+  should not introduce new features that newer kernels depend on
+  non-optionally.
+
+* If a security fix needs lockstep firmware and kernel fixes in order to
+  be successful, then all supported major versions in the linux-firmware
+  repo should be updated with the security fix, and the kernel patches
+  should detect if the firmware is new enough to declare if the security
+  issue is fixed.  All communications around security fixes should point
+  at both the firmware and kernel fixes. If a security fix requires
+  deprecating old major versions, then this should only be done as a
+  last option, and be stated clearly in all communications.
+
-- 
2.36.1

Re: [git pull] drm fixes for v4.12-rc1

[Linus T. <tor...@li...>]

On Thu, May 11, 2017 at 11:00 PM, Dave Airlie <ai...@gm...> wrote:
>
> It also has an amdgpu fixes pull, with lots of ongoing work on Vega10
> which is new in this kernel and is preliminary support so may have a
> fair bit of movement.

Note: I will *not* be taking these kinds of pull requests after rc1.

If Vega10 is in such bad shape that it will need this kind of stuff
and isn't worth shipping without them in 4.12, I will take a *oneline*
that just disables it.

So no "thousands of lines of fixes for a new driver".

Being new to 4.12 isn't an excuse for crazy stuff after the merge
window. If it will need more of this kind of attention, all it means
is that it shouldn't have been sent to me at all in the first place.

The drm subsystem is still on my "no more of this shit" list, so I'm
going to be very unforgiving of big pull requests when they aren't
appropriate.

             Linus

[git pull] drm fixes for v4.12-rc1

[Dave A. <ai...@gm...>]

Hi Linus,

Some fixes that it would be good to have in rc1. It contains the i915
quiet fix that you reported.

It also has an amdgpu fixes pull, with lots of ongoing work on Vega10
which is new in this kernel and is preliminary support so may have a
fair bit of movement.

Otherwise a few non-Vega10 AMD fixes, one EDID fix and some nouveau
regression fixers.

Dave.

The following changes since commit 09d79d103371b1b7ea70ea7f9c05ac207ef22f5d:

  Merge tag 'docs-4.12-2' of git://git.lwn.net/linux (2017-05-11 11:29:52 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc1

for you to fetch changes up to 7b8cd3363e8a0e6b90a7067f75aaeaae61a7d612:

  drm/i915: Make vblank evade warnings optional (2017-05-12 14:28:02 +1000)

----------------------------------------------------------------
amd, nouveau, one i915 and one EDID fix for v4.12-rc1

----------------------------------------------------------------
Alex Deucher (12):
      drm/amdgpu: fix spelling in header comment
      drm/amdgpu: bump version number to note race fix and new fence
functionality
      Revert "drm/amd/amdgpu: Set VCE/UVD off during late init"
      drm/amdgpu: update revision id settings for BR/ST
      drm/amdgpu/gfx9: use actual gpu num se setting for ngg allocation
      drm/amdgpu/gfx9: fix typo in mpd init
      drm/amdgpu/gfx9: add additional MQD initialization
      drm/amdgpu/gfx: drop max_gs_waves_per_vgt
      drm/amdgpu/gfx9: derive tile pipes from golden settings
      drm/amdgpu/atomfirmware: add function to update engine hang status
      drm/amdgpu/soc15: use atomfirmware for setting bios scratch for reset
      drm/amdgpu: add some additional vega10 pci ids

Alex Xie (8):
      drm/amdgpu: Fix use of interruptible waiting
      drm/amdgpu: Fix use of interruptible waiting
      drm/amdgpu: Fix use of interruptible waiting
      drm/amdgpu: Fix use of interruptible waiting
      drm/amdgpu: Real return value can be over-written when clean up
      drm/amdgpu: Fix use of interruptible waiting
      drm/amdgpu: Fix use of interruptible waiting
      drm/amdgpu: Fix use of interruptible waiting

Ben Skeggs (10):
      drm/nouveau/kms/nv50: remove pointless argument to window
atomic_check_acquire()
      drm/nouveau/kms/nv50: fix source-rect-only plane updates
      drm/nouveau/kms/nv50: skip core channel cursor update on
position-only changes
      drm/nouveau/fb/ram/gf100-: remove 0x10f200 read
      drm/nouveau/core: fix static checker warning
      drm/nouveau/tmr: ack interrupt before processing alarms
      drm/nouveau/tmr: handle races with hw when updating the next alarm time
      drm/nouveau/tmr: fix corruption of the pending list when
rescheduling an alarm
      drm/nouveau/tmr: avoid processing completed alarms when adding a new one
      drm/nouveau/therm: remove ineffective workarounds for alarm bugs

Christian König (14):
      drm/amdgpu: add VMHUB to ring association
      drm/amdgpu: drop VMID per ring tracking
      drm/amdgpu: split VMID management by VMHUB
      drm/amdgpu: invalidate only the currently needed VMHUB v2
      drm/amdgpu: assign VM invalidation engine manually v2
      drm/amdgpu: allow concurrent VM flushes
      drm/amdgpu: trace the vmhub in grab_id as well
      drm/amdgpu: trace vm hub during flush as well v2
      drm/radeon: force the UVD DPB into VRAM as well
      drm/amdgpu: fix coding style and printing in amdgpu_doorbell_init
      drm/amdgpu: fix amdgpu_vm_clear_freed v2
      drm/amdgpu: fix amdgpu_ttm_bo_eviction_valuable
      drm/amdgpu: fix VM clearing in amdgpu_gem_object_close
      drm/amdgpu: remove unused and mostly unimplemented CGS functions v2

Chunming Zhou (8):
      drm/amdgpu: add gtt print like vram when dump mm table V2
      drm/amdgpu: increase gtt size to 3GB by default v2
      drm/amdgpu: fix no-vmid job
      drm/amdgpu: fix gpu reset crash
      drm/amdgpu: fix NULL pointer error
      drm/amdgpu: fix deadlock of reservation between cs and gpu reset v2
      drm/amd: fix init order of sched job
      drm/amdgpu: fix dependency issue

Daniel Wang (2):
      drm/amdgpu/psp: skip loading SDMA/RLCG under SRIOV VF
      drm/amdgpu/vce4: fix a PSP loading VCE issue

Dave Airlie (3):
      Merge tag 'drm-misc-next-fixes-2017-05-05' of
git://anongit.freedesktop.org/git/drm-misc into drm-next
      Merge branch 'drm-next-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-next
      Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next

Evan Quan (1):
      drm/amdgpu: update smu9 driver interface

Frank Min (7):
      drm/amdgpu/vce4: update VCE initialization sequence for SRIOV
      drm/amdgpu/vce4: enable ring & ib test for sriov
      drm/amdgpu/vce4: move mm table constructions functions into
mmsch header file
      drm/amdgpu/uvd7: add sriov uvd initialization sequences
      drm/amdgpu/uvd7: add uvd doorbell initialization for sriov
      drm/amdgpu/uvd7: add UVD hw init sequences for sriov
      drm/amdgpu/soc15: enable UVD code path for sriov

Guenter Roeck (1):
      drm/amdgpu: Use less generic enum definitions

Huang Rui (14):
      drm/amdgpu: split psp tmr init function
      drm/amdgpu: add psp firmware private memory
      drm/amdgpu: use private memory to store psp firmware data
      drm/amdgpu: split psp asd function
      drm/amdgpu: split psp ring init function
      drm/amdgpu: add hw_start and non-psp firmware loading into resume
      drm/amd/powerplay: fix suspend error on DPM disabled
      drm/amdgpu: do not free fence buf when driver probes.
      drm/amdgpu: fix to clear ASIC INIT COMPLETE bit on resuming phase
      drm/amdgpu: fix to add buffer funcs check
      drm/amdgpu: fix dead lock if any ip block resume failed in s3
      drm/amdgpu: fix to print incorrect wptr address
      drm/ttm: cleanup unuse ret value
      drm/amd/powerplay: add error message to remind user updating firmware

Julien Isorce (1):
      drm/radeon: only warn once in radeon_ttm_bo_destroy if va list not empty

Junwei Zhang (3):
      drm/amdgpu: fix double_offchip_lds_buf for gfx v6
      drm/amdgpu: export more gpu info for gfx9
      drm/amdgpu: bump version for exporting gpu info for gfx9

Mario Kleiner (4):
      drm/amdgpu: Add missing lb_vblank_lead_lines setup to DCE-6 path.
      drm/radeon: Avoid overflows/divide-by-zero in latency_watermark
calculations.
      drm/radeon: Make display watermark calculations more accurate
      drm/edid: Add 10 bpc quirk for LGD 764 panel in HP zBook 17 G2

Michel Dänzer (2):
      drm/amdgpu: Make amdgpu_bo_reserve use uninterruptible waits for cleanup
      Revert "drm/amdgpu: Refactor flip into prepare submit and submit. (v3)"

Monk Liu (3):
      drm/amdgpu:fix race condition
      drm/amdgpu:PTE flag should be 64 bit width
      drm/amdgpu:fix waiting on dirty fence

Pan Bian (2):
      drm/radeon: check return value of radeon_ring_lock
      drm/radeon: check return value of radeon_fence_emit

Pixel Ding (2):
      drm/amdgpu/virt: don't check VALID bit for FLR completion message
      drm/amdgpu: fix mutex list null pointer reference

Rex Zhu (32):
      drm/amd/powerplay: align with VBIOS to support new AVFS structure
      drm/amdgpu: Remove redundant itermediate return val in sdma_v4_0.c
      drm/amd/amdgpu: coding style refine in sdma_v4_0.c
      drm/amd/powerplay: delete dead functions in vega10.
      drm/amdgpu: fix memory clock can't switch on CI.
      drm/amd/powerplay: enable AGM logging while dpm disabled.
      drm/amd/powerplay: allocate fb for avfs fuse table on vega10.
      drm/amd/powerplay: enable pcie dpm on Vega10.
      drm/amd/powerplay: enable clock stretch feature on Vega10.
      drm/amd/powerplay: Fix AVFS param.
      drm/amd/powerplay: correct UlvOffsetVid on Vega10.
      drm/amd/powerplay: disable cks by default on vega10.
      drm/amd/powerplay: refine set pcie dpm default table on vega10.
      drm/amd/powerplay: add disable_smc_ctf callback in hwmgr.
      drm/amd/powerplay: complete disable_smc_firmware_ctf_tasks.
      drm/amd/powerplay: implement stop dpm task for vega10.
      drm/amd/powerplay: refine code in vega10_smumgr.c
      drm/amd/powerplay: set soc floor voltage on boot on vega10.
      drm/amd/powerplay: set fan target temperature by msg on vega10.
      drm/amd/powerplay: Allow duplicate enteries in pptable.
      drm/amd/powerplay: correct LoadLineResistance value in pptable.
      drm/amd/powerplay: clean up code in vega10_smumgr.c
      drm/amd/powerplay: disable engine spread spectrum feature on Vega10.
      drm/amd/powerplay: delete dead code in powerplay.
      drm/amd/powerplay: Setup sw CTF to allow graceful exit when
temperature exceeds maximum.
      drm/amd/powerplay: fix bug sclk/mclk level can't be set on vega10.
      drm/amd/powerplay: add more smu message on Vega10.
      drm/amdgpu: add amd fan ctrl mode enums.
      drm/amdgpu: refine amdgpu pwm1_enable sysfs interface.
      drm/amd/powerplay: refine pwm1_enable callback functions for Vega10.
      drm/amd/powerplay: refine pwm1_enable callback functions for vi.
      drm/amd/powerplay: refine pwm1_enable callback functions for CI.

Roger.He (2):
      drm/amdgpu: fix indent
      drm/amdgpu: validate shadow before restoring from it

Shaoyun Liu (1):
      drm/amdgpu: Reserve 0-2 invalidation reg sets for none-amdgpu usages

Tom St Denis (5):
      drm/amd/amdgpu: Introduce new read/write macros for SOC15
      drm/amd/amdgpu: Port gfx9 driver over to new read/write macros
      drm/amd/amdgpu: Change comp GFXv6 ring name to remove space
      drm/amd/amdgpu: Change comp GFXv9 ring name to remove space
      drm/amd/amdgpu: Print out ring name in dev_info

Trigger Huang (3):
      drm/amdgpu: Fix firmware UCODE_ID_STORAGE issue (v2)
      drm/amdgpu: Fix module unload hang by KIQ on Vega10
      drm/amdgpu: Destroy psp ring in hw_fini

Ville Syrjälä (1):
      drm/i915: Make vblank evade warnings optional

Xiangliang Yu (5):
      drm/amdgpu/vce4: workaround VCE ring test slow issue
      drm/amdgpu/mmhub_v1: bypass clockgating setting
      drm/amdgpu/gfx9: bypass clockgating setting
      drm/amdgpu/virt: add two functions for MM table
      drm/amdgpu/vce4: replaced with virt_alloc_mm_table

Zhang, Jerry (1):
      drm/amdgpu: PRT support for gfx9 (v3)

 drivers/gpu/drm/amd/amdgpu/amdgpu.h                |  16 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c       |   6 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c   |  20 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.h   |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c      |  13 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c            | 208 +--------
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c             |   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c            |   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c         | 104 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c        | 140 ++----
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c            |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c             |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c           |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c            |  68 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c        |   9 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c             |   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c            |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c            |  21 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h           |  15 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c         |  23 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h         |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c             |  12 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c          |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c            | 229 +++++----
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h            |  18 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h           |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c             |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h          |  37 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c            |  36 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c          |  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c            |  14 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c           |  46 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h           |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c             | 155 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h             |  21 +-
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c                |  30 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c             |   6 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c             |   6 +-
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c              |  13 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c              |   6 +-
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c           |   2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c              |  10 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c              |  12 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c              |  22 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c              | 517 +++++++++++----------
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c              |   5 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c              |   5 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c              |   5 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c              |  23 +-
 drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c            |   3 +
 drivers/gpu/drm/amd/amdgpu/mmsch_v1_0.h            |  57 +++
 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c              |   9 +-
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.c              |  86 ++--
 drivers/gpu/drm/amd/amdgpu/psp_v3_1.h              |   4 +
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c             | 222 +++++----
 drivers/gpu/drm/amd/amdgpu/soc15.c                 |   9 +-
 drivers/gpu/drm/amd/amdgpu/soc15_common.h          |  20 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c              | 466 +++++++++++++++----
 drivers/gpu/drm/amd/amdgpu/vce_v4_0.c              | 224 ++++-----
 drivers/gpu/drm/amd/include/amd_shared.h           |   6 +
 drivers/gpu/drm/amd/include/cgs_common.h           | 270 -----------
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c      |   4 +-
 .../drm/amd/powerplay/eventmgr/eventsubchains.c    |   2 +-
 .../gpu/drm/amd/powerplay/eventmgr/eventtasks.c    |   5 +
 .../gpu/drm/amd/powerplay/eventmgr/eventtasks.h    |   1 +
 .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c  |  10 +
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.c |  49 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomfwctrl.h |  39 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  64 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.c |   9 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.h |   2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 408 +++++++++-------
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h |   3 +
 .../gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c |  27 +-
 .../gpu/drm/amd/powerplay/hwmgr/vega10_powertune.h |   1 +
 .../amd/powerplay/hwmgr/vega10_processpptables.c   |   4 +-
 .../gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c   |  80 ++--
 .../gpu/drm/amd/powerplay/hwmgr/vega10_thermal.h   |   2 +
 .../gpu/drm/amd/powerplay/inc/hardwaremanager.h    |   2 +-
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h          |   4 +-
 drivers/gpu/drm/amd/powerplay/inc/smu9_driver_if.h |  18 +-
 drivers/gpu/drm/amd/powerplay/inc/vega10_ppsmc.h   |   5 +-
 .../gpu/drm/amd/powerplay/smumgr/vega10_smumgr.c   | 226 +++++----
 .../gpu/drm/amd/powerplay/smumgr/vega10_smumgr.h   |   2 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c      |  23 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h      |   2 +
 drivers/gpu/drm/drm_edid.c                         |   8 +
 drivers/gpu/drm/i915/Kconfig.debug                 |  13 +
 drivers/gpu/drm/i915/intel_sprite.c                |   7 +-
 drivers/gpu/drm/nouveau/nv50_display.c             |  29 +-
 drivers/gpu/drm/nouveau/nvkm/core/object.c         |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c  |   1 -
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c   |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/fan.c    |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/fantog.c |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/temp.c   |   2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/timer/base.c   |  59 ++-
 drivers/gpu/drm/nouveau/nvkm/subdev/timer/nv04.c   |   2 +-
 drivers/gpu/drm/radeon/cik.c                       |  29 +-
 drivers/gpu/drm/radeon/evergreen.c                 |  18 +-
 drivers/gpu/drm/radeon/r420.c                      |   8 +-
 drivers/gpu/drm/radeon/radeon_cs.c                 |  10 +-
 drivers/gpu/drm/radeon/radeon_object.c             |   2 +-
 drivers/gpu/drm/radeon/radeon_test.c               |   7 +-
 drivers/gpu/drm/radeon/radeon_uvd.c                |   2 +-
 drivers/gpu/drm/radeon/si.c                        |  29 +-
 drivers/gpu/drm/ttm/ttm_bo.c                       |   3 +-
 include/uapi/drm/amdgpu_drm.h                      |  24 +-
 108 files changed, 2431 insertions(+), 2120 deletions(-)

Re: drm/exynos: g2d userptr memory corruption

[Tobias J. <liq...@gm...>]

Thanks Lucas for the explanation!


Lucas Stach wrote:
> Hi Tobias,
> 
> Am Sonntag, den 16.08.2015, 14:48 +0200 schrieb Tobias Jakobi:
>> Hello,
>>
>> some time ago I checked whether I could use the userptr functionality to
>> do zero-copy from userspace allocated buffers via the G2D. This didn't
>> work out so well, so kinda put this to the bottom of my TODO list.
>>
>> Now that IOMMU support has landed and Jan Kara has rewrote page pinning
>> using frame vectors (see [1]) I gave userptr another try.
>>
>> The results are much better. I'm not experiencing any kernel lockups or
>> sysmmu pagefaults anymore. However the image now suffers from visual
>> artifacts. These images show the nature of the artifacts:
>> http://i.imgur.com/nzT6g3Y.jpg
>> http://i.imgur.com/wkuYI6X.jpg
>>
>> The corruption always manifests itself in these pixel lines of fixed
>> size and wrong color.
>>
>> I have written a testcase as part of libdrm for this issue:
>> https://github.com/tobiasjakobi/libdrm/commit/db8bf6844436598251f67a71fc334b929bfb2b71
>>
>> It allocates N (N an even number) buffers which are aligned to the
>> system pagesize. Then it does this each iteration:
>> 1) Fill the first N/2 buffers with random data
>> 2) Copy the first half to the second half of the buffers
>> 3) memcmp() first and second half (verification pass)
>>
>> Usually this verification already fails on the first iteration. An
>> interesting observation is that increasing (!) the buffer size (so the
>> amount of pixels that have to copied per buffer grows) makes this issue
>> less likely to happen.
>>
>> With the default 512x512 buffers however it happens, like I said above,
>> almost immediately.
>>
> This is obviously a cache flush missing. The memory you get from
> userspace is normal cached memory, so to make it visible to the GPU you
> need to flush parts of the cache out to main memory.
> 
> The corruption you are seeing is just unflushed cachelines. This also
> explains why increasing the buffer size helps: the more memory the CPU
> touches the more cachelines will be flushed out to be replaced with new
> data.
I should point out that the snapshots I uploaded were done with a
different setup. There only the source memory of the G2D operation is a
userspace allocated buffer. The destination is a GEM buffer allocated
through libdrm, which is then used as framebuffer. So the issue already
appears when just the source is userspace allocated.

What works however is an operation between GEM to GEM. However this
might be related to the default allocation flags libdrm uses.



> So you need to go and have a look at dma_map() and dma_sync_*_for_*()
> and friends.
> 
> Regards,
> Lucas
> 


With best wishes,
Tobias

Re: drm/exynos: g2d userptr memory corruption

[Lucas S. <l....@pe...>]

Hi Tobias,

Am Sonntag, den 16.08.2015, 14:48 +0200 schrieb Tobias Jakobi:
> Hello,
> 
> some time ago I checked whether I could use the userptr functionality to
> do zero-copy from userspace allocated buffers via the G2D. This didn't
> work out so well, so kinda put this to the bottom of my TODO list.
> 
> Now that IOMMU support has landed and Jan Kara has rewrote page pinning
> using frame vectors (see [1]) I gave userptr another try.
> 
> The results are much better. I'm not experiencing any kernel lockups or
> sysmmu pagefaults anymore. However the image now suffers from visual
> artifacts. These images show the nature of the artifacts:
> http://i.imgur.com/nzT6g3Y.jpg
> http://i.imgur.com/wkuYI6X.jpg
> 
> The corruption always manifests itself in these pixel lines of fixed
> size and wrong color.
> 
> I have written a testcase as part of libdrm for this issue:
> https://github.com/tobiasjakobi/libdrm/commit/db8bf6844436598251f67a71fc334b929bfb2b71
> 
> It allocates N (N an even number) buffers which are aligned to the
> system pagesize. Then it does this each iteration:
> 1) Fill the first N/2 buffers with random data
> 2) Copy the first half to the second half of the buffers
> 3) memcmp() first and second half (verification pass)
> 
> Usually this verification already fails on the first iteration. An
> interesting observation is that increasing (!) the buffer size (so the
> amount of pixels that have to copied per buffer grows) makes this issue
> less likely to happen.
> 
> With the default 512x512 buffers however it happens, like I said above,
> almost immediately.
> 
This is obviously a cache flush missing. The memory you get from
userspace is normal cached memory, so to make it visible to the GPU you
need to flush parts of the cache out to main memory.

The corruption you are seeing is just unflushed cachelines. This also
explains why increasing the buffer size helps: the more memory the CPU
touches the more cachelines will be flushed out to be replaced with new
data.

So you need to go and have a look at dma_map() and dma_sync_*_for_*()
and friends.

Regards,
Lucas
-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

drm/exynos: g2d userptr memory corruption

[Tobias J. <tj...@ma...>]

Hello,

some time ago I checked whether I could use the userptr functionality to
do zero-copy from userspace allocated buffers via the G2D. This didn't
work out so well, so kinda put this to the bottom of my TODO list.

Now that IOMMU support has landed and Jan Kara has rewrote page pinning
using frame vectors (see [1]) I gave userptr another try.

The results are much better. I'm not experiencing any kernel lockups or
sysmmu pagefaults anymore. However the image now suffers from visual
artifacts. These images show the nature of the artifacts:
http://i.imgur.com/nzT6g3Y.jpg
http://i.imgur.com/wkuYI6X.jpg

The corruption always manifests itself in these pixel lines of fixed
size and wrong color.

I have written a testcase as part of libdrm for this issue:
https://github.com/tobiasjakobi/libdrm/commit/db8bf6844436598251f67a71fc334b929bfb2b71

It allocates N (N an even number) buffers which are aligned to the
system pagesize. Then it does this each iteration:
1) Fill the first N/2 buffers with random data
2) Copy the first half to the second half of the buffers
3) memcmp() first and second half (verification pass)

Usually this verification already fails on the first iteration. An
interesting observation is that increasing (!) the buffer size (so the
amount of pixels that have to copied per buffer grows) makes this issue
less likely to happen.

With the default 512x512 buffers however it happens, like I said above,
almost immediately.

I first suspected that the clock rate of the G2D was too high (I
overclock the engine from 200MHz to 400MHz here), but even with the
default clock there is no change to the behaviour.

While looking at the issue I remember this discussion [2] so while ago.

Adding Marek to Cc since I guess that this could be related to the IOMMU
as well (some missing flushing?).


With best wishes,
Tobias


[1] http://www.spinics.net/lists/linux-samsung-soc/msg45931.html
[2] http://lists.freedesktop.org/archives/dri-devel/2014-July/062675.html

[PATCH] drm/bochs: disable video before changing video mode

[Chris R. <chr...@in...>]

qemu and simics simulators both seem to expect that video should be disabled
before changing the video mode.

references:
http://git.qemu.org/?p=qemu.git;a=blob;f=hw/display/vga.c;h=c0f7b343bbab586c8593d29c7a765f1e6ca3662c;hb=HEAD#l727
http://wiki.osdev.org/Bochs_VBE_Extensions#Setting_display_resolution_and_bit_depth

Signed-off-by: Chris Ruffin <chr...@in...>
Reviewed-by: Gerd Hoffmann <kr...@re...>
---
 drivers/gpu/drm/bochs/bochs_hw.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index 4603897..a39b034 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -164,6 +164,7 @@ void bochs_hw_setmode(struct bochs_device *bochs,
 
 	bochs_vga_writeb(bochs, 0x3c0, 0x20); /* unblank */
 
+	bochs_dispi_write(bochs, VBE_DISPI_INDEX_ENABLE,      0);
 	bochs_dispi_write(bochs, VBE_DISPI_INDEX_BPP,         bochs->bpp);
 	bochs_dispi_write(bochs, VBE_DISPI_INDEX_XRES,        bochs->xres);
 	bochs_dispi_write(bochs, VBE_DISPI_INDEX_YRES,        bochs->yres);
-- 
1.7.10.4

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[Pavel M. <pa...@uc...>]

On Thu 2015-01-29 14:11:25, Dave Airlie wrote:
> These two copy to/from VGA memory, however on the Silicon
> Motion SMI750 VGA card on a 64-bit system cause console corruption.
> 
> This is due to the hw being buggy and not handling a 64-bit transaction
> correctly.
> 
> We could try and create a 32-bit version of these routines,
> but I'm not sure the optimisation is worth much today.
> 
> Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1132826
> 
> Tested-by: Huawei engineering.
> Signed-off-by: Dave Airlie <ai...@re...>

Actually... are you sure this is right fix?

IOW can gcc do the optimalization behind your back and still break the
buggy card?
								Pavel

> diff --git a/include/linux/vt_buffer.h b/include/linux/vt_buffer.h
> index 057db7d..f38c10b 100644
> --- a/include/linux/vt_buffer.h
> +++ b/include/linux/vt_buffer.h
> @@ -21,10 +21,6 @@
>  #ifndef VT_BUF_HAVE_RW
>  #define scr_writew(val, addr) (*(addr) = (val))
>  #define scr_readw(addr) (*(addr))
> -#define scr_memcpyw(d, s, c) memcpy(d, s, c)
> -#define scr_memmovew(d, s, c) memmove(d, s, c)
> -#define VT_BUF_HAVE_MEMCPYW
> -#define VT_BUF_HAVE_MEMMOVEW
>  #endif
>  
>  #ifndef VT_BUF_HAVE_MEMSETW

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[One T. G. <gn...@lx...>]

On Mon, 9 Feb 2015 11:00:55 +0000
Daniel Stone <da...@fo...> wrote:

> On 9 February 2015 at 10:49, Geert Uytterhoeven <ge...@li...> wrote:
> > On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone <da...@fo...> wrote:
> >> On 5 February 2015 at 11:35, One Thousand Gnomes
> >> <gn...@lx...> wrote:
> >>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
> >>>
> >>> #endif
> >>>
> >>> around that and its sorted as an option everyone can leave off but the
> >>> afflicted.
> >>
> >> Well, given all the distros will enable that, might as well be #if
> >> !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).
> >
> > All distros on 1 out of 29 architectures?
> 
> It's a fairly popular architecture.

I imagine most distros wouldn't enable it even on x86. It's an incredibly
obscure setup from the evidence of how long it took to get reported.

Most distributions don't support non PAE processors and other far more
common things 8)

Alan

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[Daniel S. <da...@fo...>]

On 5 February 2015 at 11:35, One Thousand Gnomes
<gn...@lx...> wrote:
>> If I'm not mistaken, that would be as simple as adding
>>
>>     #define VT_BUF_HAVE_RW.
>>     #define scr_writew(val, addr) (*(addr) = (val))
>>     #define scr_readw(addr) (*(addr))
>>
>> to arch/x86/include/asm/vga.h.
>
> and stick an
>
> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
>
> #endif
>
> around that and its sorted as an option everyone can leave off but the
> afflicted.

Well, given all the distros will enable that, might as well be #if
!defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[Daniel S. <da...@fo...>]

On 9 February 2015 at 10:49, Geert Uytterhoeven <ge...@li...> wrote:
> On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone <da...@fo...> wrote:
>> On 5 February 2015 at 11:35, One Thousand Gnomes
>> <gn...@lx...> wrote:
>>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
>>>
>>> #endif
>>>
>>> around that and its sorted as an option everyone can leave off but the
>>> afflicted.
>>
>> Well, given all the distros will enable that, might as well be #if
>> !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).
>
> All distros on 1 out of 29 architectures?

It's a fairly popular architecture.

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[Geert U. <ge...@li...>]

On Mon, Feb 9, 2015 at 11:35 AM, Daniel Stone <da...@fo...> wrote:
> On 5 February 2015 at 11:35, One Thousand Gnomes
> <gn...@lx...> wrote:
>>> If I'm not mistaken, that would be as simple as adding
>>>
>>>     #define VT_BUF_HAVE_RW.
>>>     #define scr_writew(val, addr) (*(addr) = (val))
>>>     #define scr_readw(addr) (*(addr))
>>>
>>> to arch/x86/include/asm/vga.h.
>>
>> and stick an
>>
>> #if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)
>>
>> #endif
>>
>> around that and its sorted as an option everyone can leave off but the
>> afflicted.
>
> Well, given all the distros will enable that, might as well be #if
> !defined(CONFIG_BREAK_SOME_HARDWARE_BUT_VGA_SCROLLING_WILL_BE_IMMEASURABLY_FASTER).

All distros on 1 out of 29 architectures?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[One T. G. <gn...@lx...>]

> If I'm not mistaken, that would be as simple as adding
> 
>     #define VT_BUF_HAVE_RW.
>     #define scr_writew(val, addr) (*(addr) = (val))
>     #define scr_readw(addr) (*(addr))
> 
> to arch/x86/include/asm/vga.h.

and stick an

#if defined (CONFIG_SUPPORT_SHITE_VGA_ADAPTERS)

#endif

around that and its sorted as an option everyone can leave off but the
afflicted.

Alan

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[Geert U. <ge...@li...>]

On Tue, Feb 3, 2015 at 4:54 PM, One Thousand Gnomes
<gn...@lx...> wrote:
> On Thu, 29 Jan 2015 15:40:33 -0800
> Linus Torvalds <tor...@li...> wrote:
>
>> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie <ai...@re...> wrote:
>> >
>> > Linus, this came up a while back I finally got some confirmation
>> > that it fixes those servers.
>>
>> I'm certainly ok with this. which way should it go in? The users are:
>>
>>  - drivers/tty/vt/vt.c (Greg KH, "tty layer")
>>
>>  - drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)
>>
>> and it might make sense to have *some* indication of how much worse
>> this makes fbcon performance in particular..
>
> For devices that have no hardware scrolling it used to be double digit
> percentages difference between 32 and 64bit when reading from the fb
> because the reads are not posted and the latency killed you. Writes - not
> so big a deal - but the bridge should combine them anyway. I imagine
> 16bit read would be unprintably bad.

Fbcon uses scr_mem{cpy,move}w() for the VT buffer (characters + attributes)
only, not for the frame buffer data.
So the performance degradation should be minimal.

However, as this affects real VGA on x86 only, perhaps it can be fixed
in arch/x86/include/asm/vga.h instead of include/linux/vt_buffer.h, so
platforms not having VGA are not affected? We have these VT_BUF_*
and scr_*() abstractions for a reason...

If I'm not mistaken, that would be as simple as adding

    #define VT_BUF_HAVE_RW.
    #define scr_writew(val, addr) (*(addr) = (val))
    #define scr_readw(addr) (*(addr))

to arch/x86/include/asm/vga.h.

If someone wants to put one of the "bad" VGA cards in a non-x86 PCI slot,
perhaps a few more architecture-specific asm/vga.h have to be updated:

$ git grep -w VT_BUF_HAVE_RW -- arch
arch/alpha/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/mips/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/powerpc/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/sparc/include/asm/vga.h:#define VT_BUF_HAVE_RW
arch/tile/include/asm/vga.h:#define VT_BUF_HAVE_RW

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[One T. G. <gn...@lx...>]

On Thu, 29 Jan 2015 15:40:33 -0800
Linus Torvalds <tor...@li...> wrote:

> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie <ai...@re...> wrote:
> >
> > Linus, this came up a while back I finally got some confirmation
> > that it fixes those servers.
> 
> I'm certainly ok with this. which way should it go in? The users are:
> 
>  - drivers/tty/vt/vt.c (Greg KH, "tty layer")
> 
>  - drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)
> 
> and it might make sense to have *some* indication of how much worse
> this makes fbcon performance in particular..

For devices that have no hardware scrolling it used to be double digit
percentages difference between 32 and 64bit when reading from the fb
because the reads are not posted and the latency killed you. Writes - not
so big a deal - but the bridge should combine them anyway. I imagine
16bit read would be unprintably bad.

Is it reads or writes that kill the card ?

Also note that switching to lots of small writes may break the 3Dfx
driver for the early 3Dfx PCI cards - they are really quite touchy about
how they are fed.

Unfortunately fbcon still matters for dumb EFI framebuffer fallbacks.

vgacon it doesn't matter (if it was too slow you could make vgacon as
fast as you want by only updating the off screen characters once per
vertical blank). fbcon that is a bit harder as you are allowed to
scribble on the display as well. You can't even check open/mmapped as you
can open, scribble and close.

Alan

Re: Can't gmake libdrm-2.4.59 on OmniOS

[Emil V. <emi...@gm...>]

On 1 February 2015 at 01:03, CodeSwim OS Development
<os...@co...> wrote:
> I'm trying to build libdrm and have an issue when I gmake after
> configuring.  Steps to reproduce:
>
> # uname -a
> SunOS omnios 5.11 omnios-10b9c79 i86pc i386 i86pc
>
Where can one get a copy of OmniOS ? Free of charge of course :-P
But more seriously

>From the massive log I can spot a few interesting things
 - _FILE_OFFSET_BITS redefinition.
Autotools correctly detects and sets it set to 64 (as you've got a
32bit system/build), yet further down the gcc headers, it's already
set to 32. This won't "break" the build but will likely cause problems
at runtime.

 - A ton of -Wparentheses warnings.
These should be safe - you might also want to silence them so that
serious issues are clearer.

 - And last but not leask the missing _IOC symbol.
Gentoo people have a patch on the topic [1] - might be nice to clean
it up and upstream it.

Cheers,
Emil

[1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/files/libdrm-2.4.58-solaris.patch?view=markup

Can't gmake libdrm-2.4.59 on OmniOS

[CodeSwim OS D. <os...@co...>]

I'm trying to build libdrm and have an issue when I gmake after
configuring.  Steps to reproduce:

# uname -a
SunOS omnios 5.11 omnios-10b9c79 i86pc i386 i86pc

# cd libdrm-2.4.59

# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking whether make supports nested variables... (cached) yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/ggrep
checking for egrep... /usr/bin/ggrep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking build system type... i386-pc-solaris2.11
checking host system type... i386-pc-solaris2.11
checking how to print strings... print -r
checking for a sed that does not truncate output... /usr/bin/gsed
checking for fgrep... /usr/bin/ggrep -F
checking for ld used by gcc... /bin/ld
checking if the linker (/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -p
checking the name lister (/usr/bin/nm -p) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 786240
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i386-pc-solaris2.11 file names to
i386-pc-solaris2.11 format... func_convert_file_noop
checking how to convert i386-pc-solaris2.11 file names to toolchain
format... func_convert_file_noop
checking for /bin/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... print -r --
checking for ar... ar
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -p output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... solaris2.11 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for PTHREADSTUBS... yes
checking for clock_gettime... yes
checking for open_memstream... no
checking for supported warning flags...
checking whether gcc supports -Wall... yes
checking whether gcc supports -Wextra... yes
checking whether gcc supports -Wsign-compare... yes
checking whether gcc supports -Werror-implicit-function-declaration... yes
checking whether gcc supports -Wpointer-arith... yes
checking whether gcc supports -Wwrite-strings... yes
checking whether gcc supports -Wstrict-prototypes... yes
checking whether gcc supports -Wmissing-prototypes... yes
checking whether gcc supports -Wmissing-declarations... yes
checking whether gcc supports -Wnested-externs... yes
checking whether gcc supports -Wpacked... yes
checking whether gcc supports -Wswitch-enum... yes
checking whether gcc supports -Wmissing-format-attribute... yes
checking whether gcc supports -Wstrict-aliasing=2... yes
checking whether gcc supports -Winit-self... yes
checking whether gcc supports -Wdeclaration-after-statement... yes
checking whether gcc supports -Wold-style-definition... yes
checking whether gcc supports -Wno-missing-field-initializers... yes
checking whether gcc supports -Wno-unused-parameter... yes
checking whether gcc supports -Wno-attributes... yes
checking whether gcc supports -Wno-long-long... yes
checking whether gcc supports -Winline... yes
checking which warning flags were supported...  -Wall -Wextra
-Wsign-compare -Werror-implicit-function-declaration -Wpointer-arith
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -Wpacked -Wswitch-enum
-Wmissing-format-attribute -Wstrict-aliasing=2 -Winit-self
-Wdeclaration-after-statement -Wold-style-definition
-Wno-missing-field-initializers -Wno-unused-parameter -Wno-attributes
-Wno-long-long -Winline
checking for native atomic primitives... Intel
checking for PCIACCESS... yes
checking for CAIRO... yes
checking whether to enable Cairo tests... yes
checking for LIBUDEV... no
checking for xsltproc... /usr/bin/xsltproc
checking for docbook manpages stylesheet... no
checking for VALGRIND... no
checking whether gcc supports -fvisibility=hidden... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating libkms/Makefile
config.status: creating libkms/libkms.pc
config.status: creating intel/Makefile
config.status: creating intel/libdrm_intel.pc
config.status: creating radeon/Makefile
config.status: creating radeon/libdrm_radeon.pc
config.status: creating nouveau/Makefile
config.status: creating nouveau/libdrm_nouveau.pc
config.status: creating omap/Makefile
config.status: creating omap/libdrm_omap.pc
config.status: creating exynos/Makefile
config.status: creating exynos/libdrm_exynos.pc
config.status: creating freedreno/Makefile
config.status: creating freedreno/libdrm_freedreno.pc
config.status: creating tegra/Makefile
config.status: creating tegra/libdrm_tegra.pc
config.status: creating tests/Makefile
config.status: creating tests/modeprint/Makefile
config.status: creating tests/modetest/Makefile
config.status: creating tests/kmstest/Makefile
config.status: creating tests/proptest/Makefile
config.status: creating tests/radeon/Makefile
config.status: creating tests/vbltest/Makefile
config.status: creating tests/exynos/Makefile
config.status: creating tests/tegra/Makefile
config.status: creating man/Makefile
config.status: creating libdrm.pc
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands

libdrm 2.4.59 will be compiled with:

  libkms         no
  Intel API      yes
  vmwgfx API     yes
  Radeon API     yes
  Nouveau API    yes
  OMAP API       no
  EXYNOS API     no
  Freedreno API  no (kgsl: no)
  Tegra API      no

# gmake
gmake  all-recursive
gmake[1]: Entering directory `/usr/share/src/libdrm-2.4.59'
Making all in .
gmake[2]: Entering directory `/usr/share/src/libdrm-2.4.59'
  CC       libdrm_la-xf86drm.lo
  CC       libdrm_la-xf86drmHash.lo
  CC       libdrm_la-xf86drmRandom.lo
  CC       libdrm_la-xf86drmSL.lo
  CC       libdrm_la-xf86drmMode.lo
In file included from xf86drmMode.c:45:0:
config.h:173:0: warning: "_FILE_OFFSET_BITS" redefined [enabled by default]
 #define _FILE_OFFSET_BITS 64
 ^
In file included from /usr/include/sys/int_types.h:55:0,
                 from /usr/include/sys/stdint.h:38,
                 from /usr/include/stdint.h:38,
                 from
/opt/gcc-4.8.1/lib/gcc/i386-pc-solaris2.11/4.8.1/include/stdint.h:9,
                 from xf86drmMode.c:40:
/opt/gcc-4.8.1/lib/gcc/i386-pc-solaris2.11/4.8.1/include-fixed/sys/feature_tests.h:231:0:
note: this is the location of the previous definition
 #define _FILE_OFFSET_BITS 32
 ^
  CCLD     libdrm.la
gmake[2]: Leaving directory `/usr/share/src/libdrm-2.4.59'
Making all in intel
gmake[2]: Entering directory `/usr/share/src/libdrm-2.4.59/intel'
  CC       intel_bufmgr.lo
In file included from ../include/drm/drm.h:47:0,
                 from intel_bufmgr.c:37:
intel_bufmgr.c: In function 'drm_intel_get_aperture_sizes':
../include/drm/i915_drm.h:265:104: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_GET_APERTURE DRM_IOR  (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_APERTURE, struct drm_i915_gem_get_aperture)
                                                                                                        ^
../include/drm/i915_drm.h:265:41: note: in expansion of macro 'DRM_IOR'
 #define DRM_IOCTL_I915_GEM_GET_APERTURE DRM_IOR  (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_APERTURE, struct drm_i915_gem_get_aperture)
                                         ^
intel_bufmgr.c:342:21: note: in expansion of macro
'DRM_IOCTL_I915_GEM_GET_APERTURE'
  ret = drmIoctl(fd, DRM_IOCTL_I915_GEM_GET_APERTURE, &aperture);
                     ^
  CC       intel_bufmgr_fake.lo
  CC       intel_bufmgr_gem.lo
intel_bufmgr_gem.c: In function 'drm_intel_gem_dump_validation_list':
intel_bufmgr_gem.c:401:4: warning: format '%lx' expects argument of type
'long unsigned int', but argument 9 has type 'uint64_t' [-Wformat=]
    DBG("%2d: %d (%s)@0x%08llx -> "
    ^
In file included from ../include/drm/drm.h:47:0,
                 from ../xf86drm.h:40,
                 from intel_bufmgr_gem.c:41:
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_busy':
../include/drm/i915_drm.h:250:88: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_BUSY  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
                                                                                        ^
../include/drm/i915_drm.h:250:34: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_BUSY  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
                                  ^
intel_bufmgr_gem.c:599:33: note: in expansion of macro
'DRM_IOCTL_I915_GEM_BUSY'
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_BUSY, &busy);
                                 ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_madvise_internal':
../include/drm/i915_drm.h:267:93: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_MADVISE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_MADVISE, struct drm_i915_gem_madvise)
                                                                                             ^
../include/drm/i915_drm.h:267:36: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_MADVISE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_MADVISE, struct drm_i915_gem_madvise)
                                    ^
intel_bufmgr_gem.c:619:27: note: in expansion of macro
'DRM_IOCTL_I915_GEM_MADVISE'
  drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_MADVISE, &madv);
                           ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_alloc_internal':
../include/drm/i915_drm.h:256:91: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_CREATE, struct drm_i915_gem_create)
                                                                                           ^
../include/drm/i915_drm.h:256:35: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_CREATE, struct drm_i915_gem_create)
                                   ^
intel_bufmgr_gem.c:748:11: note: in expansion of macro
'DRM_IOCTL_I915_GEM_CREATE'
           DRM_IOCTL_I915_GEM_CREATE,
           ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_alloc_userptr':
../include/drm/i915_drm.h:277:95: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_USERPTR  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR,  struct drm_i915_gem_userptr)
                                                                                               ^
../include/drm/i915_drm.h:277:37: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_USERPTR  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR,  struct drm_i915_gem_userptr)
                                     ^
intel_bufmgr_gem.c:897:4: note: in expansion of macro
'DRM_IOCTL_I915_GEM_USERPTR'
    DRM_IOCTL_I915_GEM_USERPTR,
    ^
intel_bufmgr_gem.c: In function 'drm_intel_bo_gem_create_from_name':
../include/drm/i915_drm.h:264:100: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_GET_TILING DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_TILING, struct drm_i915_gem_get_tiling)
                                                                                                    ^
../include/drm/i915_drm.h:264:39: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_GET_TILING DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_TILING, struct drm_i915_gem_get_tiling)
                                       ^
intel_bufmgr_gem.c:1023:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_GET_TILING'
          DRM_IOCTL_I915_GEM_GET_TILING,
          ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_map':
../include/drm/i915_drm.h:259:88: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_MMAP  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_MMAP, struct drm_i915_gem_mmap)
                                                                                        ^
../include/drm/i915_drm.h:259:34: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_MMAP  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_MMAP, struct drm_i915_gem_mmap)
                                  ^
intel_bufmgr_gem.c:1300:11: note: in expansion of macro
'DRM_IOCTL_I915_GEM_MMAP'
           DRM_IOCTL_I915_GEM_MMAP,
           ^
../include/drm/i915_drm.h:261:99: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_SET_DOMAIN DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_SET_DOMAIN, struct drm_i915_gem_set_domain)
                                                                                                   ^
../include/drm/i915_drm.h:261:39: note: in expansion of macro 'DRM_IOW'
 #define DRM_IOCTL_I915_GEM_SET_DOMAIN DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_SET_DOMAIN, struct drm_i915_gem_set_domain)
                                       ^
intel_bufmgr_gem.c:1327:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_SET_DOMAIN'
          DRM_IOCTL_I915_GEM_SET_DOMAIN,
          ^
intel_bufmgr_gem.c: In function 'map_gtt':
../include/drm/i915_drm.h:260:95: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_MMAP_GTT DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_MMAP_GTT, struct drm_i915_gem_mmap_gtt)
                                                                                               ^
../include/drm/i915_drm.h:260:37: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_MMAP_GTT DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_MMAP_GTT, struct drm_i915_gem_mmap_gtt)
                                     ^
intel_bufmgr_gem.c:1370:11: note: in expansion of macro
'DRM_IOCTL_I915_GEM_MMAP_GTT'
           DRM_IOCTL_I915_GEM_MMAP_GTT,
           ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_map_gtt':
../include/drm/i915_drm.h:261:99: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_SET_DOMAIN DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_SET_DOMAIN, struct drm_i915_gem_set_domain)
                                                                                                   ^
../include/drm/i915_drm.h:261:39: note: in expansion of macro 'DRM_IOW'
 #define DRM_IOCTL_I915_GEM_SET_DOMAIN DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_SET_DOMAIN, struct drm_i915_gem_set_domain)
                                       ^
intel_bufmgr_gem.c:1438:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_SET_DOMAIN'
          DRM_IOCTL_I915_GEM_SET_DOMAIN,
          ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_unmap':
../include/drm/i915_drm.h:262:97: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_SW_FINISH DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_SW_FINISH, struct drm_i915_gem_sw_finish)
                                                                                                 ^
../include/drm/i915_drm.h:262:38: note: in expansion of macro 'DRM_IOW'
 #define DRM_IOCTL_I915_GEM_SW_FINISH DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_SW_FINISH, struct drm_i915_gem_sw_finish)
                                      ^
intel_bufmgr_gem.c:1535:11: note: in expansion of macro
'DRM_IOCTL_I915_GEM_SW_FINISH'
           DRM_IOCTL_I915_GEM_SW_FINISH,
           ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_subdata':
../include/drm/i915_drm.h:258:91: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_PWRITE DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_PWRITE, struct drm_i915_gem_pwrite)
                                                                                           ^
../include/drm/i915_drm.h:258:35: note: in expansion of macro 'DRM_IOW'
 #define DRM_IOCTL_I915_GEM_PWRITE DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_PWRITE, struct drm_i915_gem_pwrite)
                                   ^
intel_bufmgr_gem.c:1580:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_PWRITE'
          DRM_IOCTL_I915_GEM_PWRITE,
          ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_get_pipe_from_crtc_id':
../include/drm/i915_drm.h:266:113: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GET_PIPE_FROM_CRTC_ID, struct drm_i915_get_pipe_from_crtc_id)
                                                                                                                 ^
../include/drm/i915_drm.h:266:46: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GET_PIPE_FROM_CRTC_ID, struct drm_i915_get_pipe_from_crtc_id)
                                              ^
intel_bufmgr_gem.c:1602:10: note: in expansion of macro
'DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID'
          DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID,
          ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_get_subdata':
../include/drm/i915_drm.h:257:89: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_PREAD DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_PREAD, struct drm_i915_gem_pread)
                                                                                         ^
../include/drm/i915_drm.h:257:34: note: in expansion of macro 'DRM_IOW'
 #define DRM_IOCTL_I915_GEM_PREAD DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_PREAD, struct drm_i915_gem_pread)
                                  ^
intel_bufmgr_gem.c:1635:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_PREAD'
          DRM_IOCTL_I915_GEM_PREAD,
          ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_wait':
../include/drm/i915_drm.h:272:88: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_WAIT  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
                                                                                        ^
../include/drm/i915_drm.h:272:34: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_WAIT  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
                                  ^
intel_bufmgr_gem.c:1700:33: note: in expansion of macro
'DRM_IOCTL_I915_GEM_WAIT'
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_WAIT, &wait);
                                 ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_start_gtt_access':
../include/drm/i915_drm.h:261:99: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_SET_DOMAIN DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_SET_DOMAIN, struct drm_i915_gem_set_domain)
                                                                                                   ^
../include/drm/i915_drm.h:261:39: note: in expansion of macro 'DRM_IOW'
 #define DRM_IOCTL_I915_GEM_SET_DOMAIN DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_SET_DOMAIN, struct drm_i915_gem_set_domain)
                                       ^
intel_bufmgr_gem.c:1727:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_SET_DOMAIN'
          DRM_IOCTL_I915_GEM_SET_DOMAIN,
          ^
intel_bufmgr_gem.c: In function 'drm_intel_update_buffer_offsets':
intel_bufmgr_gem.c:1998:4: warning: format '%lx' expects argument of type
'long unsigned int', but argument 5 has type 'uint64_t' [-Wformat=]
    DBG("BO %d (%s) migrated: 0x%08lx -> 0x%08llx\n",
    ^
intel_bufmgr_gem.c: In function 'drm_intel_update_buffer_offsets2':
intel_bufmgr_gem.c:2019:4: warning: format '%lx' expects argument of type
'long unsigned int', but argument 5 has type 'uint64_t' [-Wformat=]
    DBG("BO %d (%s) migrated: 0x%08lx -> 0x%08llx\n",
    ^
In file included from ../include/drm/drm.h:47:0,
                 from ../xf86drm.h:40,
                 from intel_bufmgr_gem.c:41:
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_exec':
../include/drm/i915_drm.h:246:98: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_EXECBUFFER DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER, struct drm_i915_gem_execbuffer)
                                                                                                  ^
../include/drm/i915_drm.h:246:39: note: in expansion of macro 'DRM_IOW'
 #define DRM_IOCTL_I915_GEM_EXECBUFFER DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER, struct drm_i915_gem_execbuffer)
                                       ^
intel_bufmgr_gem.c:2353:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_EXECBUFFER'
          DRM_IOCTL_I915_GEM_EXECBUFFER,
          ^
intel_bufmgr_gem.c: In function 'do_exec2':
../include/drm/i915_drm.h:247:100: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_EXECBUFFER2 DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER2, struct drm_i915_gem_execbuffer2)
                                                                                                    ^
../include/drm/i915_drm.h:247:40: note: in expansion of macro 'DRM_IOW'
 #define DRM_IOCTL_I915_GEM_EXECBUFFER2 DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_EXECBUFFER2, struct drm_i915_gem_execbuffer2)
                                        ^
intel_bufmgr_gem.c:2451:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_EXECBUFFER2'
          DRM_IOCTL_I915_GEM_EXECBUFFER2,
          ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_pin':
../include/drm/i915_drm.h:248:86: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_PIN  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
                                                                                      ^
../include/drm/i915_drm.h:248:33: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_PIN  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
                                 ^
intel_bufmgr_gem.c:2525:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_PIN'
          DRM_IOCTL_I915_GEM_PIN,
          ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_unpin':
../include/drm/i915_drm.h:249:88: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
                                                                                        ^
../include/drm/i915_drm.h:249:34: note: in expansion of macro 'DRM_IOW'
 #define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
                                  ^
intel_bufmgr_gem.c:2546:33: note: in expansion of macro
'DRM_IOCTL_I915_GEM_UNPIN'
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_UNPIN, &unpin);
                                 ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_bo_set_tiling_internal':
../include/drm/i915_drm.h:263:100: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_SET_TILING DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_SET_TILING, struct drm_i915_gem_set_tiling)
                                                                                                    ^
../include/drm/i915_drm.h:263:39: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_SET_TILING DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_SET_TILING, struct drm_i915_gem_set_tiling)
                                       ^
intel_bufmgr_gem.c:2579:8: note: in expansion of macro
'DRM_IOCTL_I915_GEM_SET_TILING'
        DRM_IOCTL_I915_GEM_SET_TILING,
        ^
intel_bufmgr_gem.c: In function 'drm_intel_bo_gem_create_from_prime':
../include/drm/i915_drm.h:264:100: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_GET_TILING DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_TILING, struct drm_i915_gem_get_tiling)
                                                                                                    ^
../include/drm/i915_drm.h:264:39: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_GET_TILING DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_TILING, struct drm_i915_gem_get_tiling)
                                       ^
intel_bufmgr_gem.c:2702:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_GET_TILING'
          DRM_IOCTL_I915_GEM_GET_TILING,
          ^
intel_bufmgr_gem.c: In function 'get_pci_device_id':
intel_bufmgr_gem.c:3097:2: warning: suggest parentheses around arithmetic
in operand of '|' [-Wparentheses]
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
  ^
In file included from ../include/drm/drm.h:47:0,
                 from ../xf86drm.h:40,
                 from intel_bufmgr_gem.c:41:
intel_bufmgr_gem.c: In function 'drm_intel_gem_context_create':
../include/drm/i915_drm.h:273:108: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
                                                                                                            ^
../include/drm/i915_drm.h:273:43: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
                                           ^
intel_bufmgr_gem.c:3208:33: note: in expansion of macro
'DRM_IOCTL_I915_GEM_CONTEXT_CREATE'
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, &create);
                                 ^
intel_bufmgr_gem.c: In function 'drm_intel_gem_context_destroy':
../include/drm/i915_drm.h:274:109: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
                                                                                                             ^
../include/drm/i915_drm.h:274:44: note: in expansion of macro 'DRM_IOW'
 #define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
                                            ^
intel_bufmgr_gem.c:3236:33: note: in expansion of macro
'DRM_IOCTL_I915_GEM_CONTEXT_DESTROY'
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_CONTEXT_DESTROY,
                                 ^
intel_bufmgr_gem.c: In function 'drm_intel_get_reset_stats':
../include/drm/i915_drm.h:276:103: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GET_RESET_STATS  DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
                                                                                                       ^
../include/drm/i915_drm.h:276:41: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GET_RESET_STATS  DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
                                         ^
intel_bufmgr_gem.c:3263:10: note: in expansion of macro
'DRM_IOCTL_I915_GET_RESET_STATS'
          DRM_IOCTL_I915_GET_RESET_STATS,
          ^
intel_bufmgr_gem.c: In function 'drm_intel_reg_read':
../include/drm/i915_drm.h:275:90: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_REG_READ   DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_REG_READ, struct drm_i915_reg_read)
                                                                                          ^
../include/drm/i915_drm.h:275:35: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_REG_READ   DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_REG_READ, struct drm_i915_reg_read)
                                   ^
intel_bufmgr_gem.c:3291:33: note: in expansion of macro
'DRM_IOCTL_I915_REG_READ'
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_REG_READ, &reg_read);
                                 ^
intel_bufmgr_gem.c: In function 'has_userptr':
../include/drm/i915_drm.h:277:95: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_USERPTR  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR,  struct drm_i915_gem_userptr)
                                                                                               ^
../include/drm/i915_drm.h:277:37: note: in expansion of macro 'DRM_IOWR'
 #define DRM_IOCTL_I915_GEM_USERPTR  DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_USERPTR,  struct drm_i915_gem_userptr)
                                     ^
intel_bufmgr_gem.c:3398:33: note: in expansion of macro
'DRM_IOCTL_I915_GEM_USERPTR'
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_USERPTR, &userptr);
                                 ^
intel_bufmgr_gem.c: In function 'drm_intel_bufmgr_gem_init':
../include/drm/i915_drm.h:265:104: warning: suggest parentheses around
arithmetic in operand of '|' [-Wparentheses]
 #define DRM_IOCTL_I915_GEM_GET_APERTURE DRM_IOR  (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_APERTURE, struct drm_i915_gem_get_aperture)
                                                                                                        ^
../include/drm/i915_drm.h:265:41: note: in expansion of macro 'DRM_IOR'
 #define DRM_IOCTL_I915_GEM_GET_APERTURE DRM_IOR  (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_APERTURE, struct drm_i915_gem_get_aperture)
                                         ^
intel_bufmgr_gem.c:3455:10: note: in expansion of macro
'DRM_IOCTL_I915_GEM_GET_APERTURE'
          DRM_IOCTL_I915_GEM_GET_APERTURE,
          ^
intel_bufmgr_gem.c:3507:2: warning: suggest parentheses around arithmetic
in operand of '|' [-Wparentheses]
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
  ^
intel_bufmgr_gem.c:3512:2: warning: suggest parentheses around arithmetic
in operand of '|' [-Wparentheses]
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
  ^
intel_bufmgr_gem.c:3516:2: warning: suggest parentheses around arithmetic
in operand of '|' [-Wparentheses]
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
  ^
intel_bufmgr_gem.c:3520:2: warning: suggest parentheses around arithmetic
in operand of '|' [-Wparentheses]
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
  ^
intel_bufmgr_gem.c:3528:2: warning: suggest parentheses around arithmetic
in operand of '|' [-Wparentheses]
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
  ^
intel_bufmgr_gem.c:3532:2: warning: suggest parentheses around arithmetic
in operand of '|' [-Wparentheses]
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
  ^
intel_bufmgr_gem.c:3543:2: warning: suggest parentheses around arithmetic
in operand of '|' [-Wparentheses]
  ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
  ^
intel_bufmgr_gem.c:3549:3: warning: suggest parentheses around arithmetic
in operand of '|' [-Wparentheses]
   ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
   ^
  CC       intel_decode.lo
  CC       mm.lo
  CCLD     libdrm_intel.la
  CC       test_decode.o
test_decode.c: In function ‘compare_batch’:
test_decode.c:94:9: warning: unused variable ‘size’ [-Wunused-variable]
  size_t size, ref_size, batch_size;
         ^
  CCLD     test_decode
ld: warning: file ../.libs/libdrm.so: linked to
/usr/src/libdrm-2.4.59/.libs/libdrm.so: attempted multiple inclusion of
file
Undefined			first referenced
 symbol  			    in file
_IOC                                /usr/src/libdrm-2.4.59/.libs/libdrm.so
ld: fatal: symbol referencing errors. No output written to .libs/test_decode
collect2: error: ld returned 1 exit status
gmake[2]: *** [test_decode] Error 1
gmake[2]: Leaving directory `/usr/share/src/libdrm-2.4.59/intel'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/share/src/libdrm-2.4.59'
gmake: *** [all] Error 2

[felt sad]

Expected
can run
./configure
gmake
gmake install
[feel accomplished]

This (https://code.google.com/p/tesseract-ocr/issues/detail?id=582) seems
like it might help but I'm not sure what LIBS to include.

Thank you,

Damon Zwolinski

Re: [PATCH] vt_buffer: drop console buffer copying optimisations

[Greg Kroah-H. <gr...@li...>]

On Thu, Jan 29, 2015 at 03:40:33PM -0800, Linus Torvalds wrote:
> On Wed, Jan 28, 2015 at 8:11 PM, Dave Airlie <ai...@re...> wrote:
> >
> > Linus, this came up a while back I finally got some confirmation
> > that it fixes those servers.
> 
> I'm certainly ok with this. which way should it go in? The users are:
> 
>  - drivers/tty/vt/vt.c (Greg KH, "tty layer")
> 
>  - drivers/video/console/* (fbcon people: Tomi Valkeinen and friends)
> 
> and it might make sense to have *some* indication of how much worse
> this makes fbcon performance in particular..
> 
> Greg/Tomi - the patch is removing this:
> 
>   #define scr_memcpyw(d, s, c) memcpy(d, s, c)
>   #define scr_memmovew(d, s, c) memmove(d, s, c)
>   #define VT_BUF_HAVE_MEMCPYW
>   #define VT_BUF_HAVE_MEMMOVEW
> 
> from <linux/vt_buffer.h>, because some stupid graphics cards
> apparently cannot handle 64-bit accesses of regular memcpy/memmove.
> 
> And on other setups, this will be the reverse: 8-bit accesses due to
> using "rep movsb", which is the fast way to move/clear memory on
> modern Intel CPU's, but is really wrong for MMIO where it will be slow
> as hell.
> 
> So just getting rid of the memcpy/memmove is likely the right thing in
> general, since the fallbacks go this the traditional 16-bit-at-a-time
> way. And getting rid of the memcpy _may_ speed things up.
> 
> But if it slows things down, we might have to try something else. Like
> saying "all cards we've ever seen have been ok with aligned 32-bit
> accesses", and extend the open-coded scr_memcpy/memmove functions to
> do that.
> 
> Hmm?

I can take this through the tty tree, but can I put it in linux-next and
wait for the 3.20 merge window to give people who might notice a
slow-down a chance to object?

thanks,

greg k-h