[PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

2017-12-31 Thread Stefan Brüns 
The ACK/NACK implementation as found in e.g. the G965 has the falling
clock edge and the release of the data line after the ACK for the received
byte happen at the same time.

This is conformant with the I2C specification, which allows a zero hold
time, see footnote [3]: "A device must internally provide a hold time of
at least 300 ns for the SDA signal (with respect to the V IH(min) of the
SCL signal) to bridge the undefined region of the falling edge of SCL."

Some HDMI-to-VGA converters apparently fail to adhere to this requirement
and latch SDA at the falling clock edge, so instead of an ACK
sometimes a NACK is read and the slave (i.e. the EDID ROM) ends the
transfer.

The bitbanging releases the data line for the ACK only 1/4 bit time after
the falling clock edge, so a slave will see the correct value no matter
if it samples at the rising or the falling clock edge or in the center.

Fallback to bitbanging is already done for the CRT connector.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92685

Signed-off-by: Stefan Brüns 

---

Changes in v2:
- Fix/enhance commit message, no code changes

 drivers/gpu/drm/i915/intel_hdmi.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 4dea833f9d1b..847cda4c017c 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1573,12 +1573,20 @@ intel_hdmi_set_edid(struct drm_connector *connector)
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct edid *edid;
bool connected = false;
+   struct i2c_adapter *i2c;
 
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
 
-   edid = drm_get_edid(connector,
-   intel_gmbus_get_adapter(dev_priv,
-   intel_hdmi->ddc_bus));
+   i2c = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+   edid = drm_get_edid(connector, i2c);
+
+   if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
+   DRM_DEBUG_KMS("HDMI GMBUS EDID read failed, retry using GPIO 
bit-banging\n");
+   intel_gmbus_force_bit(i2c, true);
+   edid = drm_get_edid(connector, i2c);
+   intel_gmbus_force_bit(i2c, false);
+   }
 
intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
 
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] drm: split up drm_ioctl to allow drivers to hook into "core" functions

2017-12-31 Thread Ilia Mirkin 
On Sun, Dec 31, 2017 at 1:15 PM, Ilia Mirkin  wrote:
> Currently there's no way to allow a driver to reimplement any ioctls
> from the drm core. This can be desirable to, e.g., override fixed format
> selection logic, without turning to a midlayer-like solution.
>
> Signed-off-by: Ilia Mirkin 
> ---
>
> I want drm_mode_addfb to pick a different format for depth=30 than the
> one it currently selects. Flipping it for all drivers would break a
> bunch of existing ones, so this enables a driver to take control.
>
> Alternatively I can stash something into drm_device which specifies the
> preferred depth=30 fb format. However from my cursory observations of
> dri-devel discussions, midlayering is seen as a problem and not a
> solution.

Ugh, of course this is turning into a disaster as well.
drm_mode_addfb2 isn't exported, so I have to copy all the
functionality into nouveau, or move it to drm_kms_helper or whatever.
The flag in drm_device approach is sounding a lot more palatable. Let
me know what the best way to proceed is.

This is all to fix a regression, btw, since previous to nouveau
becoming atomic this all worked fine -- it just looked at the
30bpp'ness of the fb and assumed. Now it actually cares about specific
formats, and we run into all these problems.

>
>  drivers/gpu/drm/drm_ioctl.c | 36 
>  include/drm/drm_ioctl.h |  2 ++
>  2 files changed, 26 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 4aafe4802099..698d69c6db0a 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -767,12 +767,7 @@ long drm_ioctl(struct file *filp,
> struct drm_file *file_priv = filp->private_data;
> struct drm_device *dev;
> const struct drm_ioctl_desc *ioctl = NULL;
> -   drm_ioctl_t *func;
> unsigned int nr = DRM_IOCTL_NR(cmd);
> -   int retcode = -EINVAL;
> -   char stack_kdata[128];
> -   char *kdata = NULL;
> -   unsigned int in_size, out_size, drv_size, ksize;
> bool is_driver_ioctl;
>
> dev = file_priv->minor->dev;
> @@ -784,16 +779,33 @@ long drm_ioctl(struct file *filp,
>
> if (is_driver_ioctl) {
> /* driver ioctl */
> -   if (nr - DRM_COMMAND_BASE >= dev->driver->num_ioctls)
> -   goto err_i1;
> -   ioctl = >driver->ioctls[nr - DRM_COMMAND_BASE];
> +   if (nr - DRM_COMMAND_BASE < dev->driver->num_ioctls)
> +   ioctl = >driver->ioctls[nr - DRM_COMMAND_BASE];
> } else {
> /* core ioctl */
> -   if (nr >= DRM_CORE_IOCTL_COUNT)
> -   goto err_i1;
> -   ioctl = _ioctls[nr];
> +   if (nr < DRM_CORE_IOCTL_COUNT)
> +   ioctl = _ioctls[nr];
> }
>
> +   return __drm_ioctl(filp, cmd, arg, ioctl);
> +}
> +EXPORT_SYMBOL(drm_ioctl);
> +
> +long __drm_ioctl(struct file *filp,
> +unsigned int cmd, unsigned long arg,
> +const struct drm_ioctl_desc *ioctl)
> +{
> +   struct drm_file *file_priv = filp->private_data;
> +   drm_ioctl_t *func;
> +   unsigned int nr = DRM_IOCTL_NR(cmd);
> +   int retcode = -EINVAL;
> +   char stack_kdata[128];
> +   char *kdata = NULL;
> +   unsigned int in_size, out_size, drv_size, ksize;
> +
> +   if (!ioctl)
> +   goto err_i1;
> +
> drv_size = _IOC_SIZE(ioctl->cmd);
> out_size = in_size = _IOC_SIZE(cmd);
> if ((cmd & ioctl->cmd & IOC_IN) == 0)
> @@ -851,7 +863,7 @@ long drm_ioctl(struct file *filp,
> DRM_DEBUG("ret = %d\n", retcode);
> return retcode;
>  }
> -EXPORT_SYMBOL(drm_ioctl);
> +EXPORT_SYMBOL(__drm_ioctl);
>
>  /**
>   * drm_ioctl_flags - Check for core ioctl and return ioctl permission flags
> diff --git a/include/drm/drm_ioctl.h b/include/drm/drm_ioctl.h
> index add42809642a..e08f8ea66f2a 100644
> --- a/include/drm/drm_ioctl.h
> +++ b/include/drm/drm_ioctl.h
> @@ -172,6 +172,8 @@ struct drm_ioctl_desc {
>
>  int drm_ioctl_permit(u32 flags, struct drm_file *file_priv);
>  long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
> +long __drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg,
> +const struct drm_ioctl_desc *ioctl);
>  long drm_ioctl_kernel(struct file *, drm_ioctl_t, void *, u32);
>  #ifdef CONFIG_COMPAT
>  long drm_compat_ioctl(struct file *filp, unsigned int cmd, unsigned long 
> arg);
> --
> 2.13.6
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau. swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

2017-12-31 Thread Ilia Mirkin 
On Tue, Dec 19, 2017 at 8:45 AM, Christian König
 wrote:
> Am 19.12.2017 um 11:39 schrieb Michel Dänzer:
>>
>> On 2017-12-19 11:37 AM, Michel Dänzer wrote:
>>>
>>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote:

 On 12/18/17 7:06 PM, Mike Galbraith wrote:
>
> Greetings,
>
> Kernel bound workloads seem to trigger the below for whatever reason.
>I only see this when beating up NFS.  There was a kworker wakeup
> latency issue, but with a bandaid applied to fix that up, I can still
> trigger this.


 Hi,

 i have seen this one as well with my system, but i could not find an
 easy way to trigger it for bisecting purpose. If you can trigger it
 conveniently, a bisect would be nice!
>>>
>>> I'm seeing this (with the amdgpu and radeon drivers) when restic takes a
>>> backup, creating memory pressure. I happen to have just finished
>>> bisecting, the result is:
>>>
>>> 648bc3574716400acc06f99915815f80d9563783 is the first bad commit
>>> commit 648bc3574716400acc06f99915815f80d9563783
>>> Author: Christian König 
>>> Date:   Thu Jul 6 09:59:43 2017 +0200
>>>
>>>  drm/ttm: add transparent huge page support for DMA allocations v2
>>>
>>>  Try to allocate huge pages when it makes sense.
>>>
>>>  v2: fix comment and use ifdef
>>>
>>>
>> BTW, I haven't noticed any bad effects other than the dmesg splats, so
>> maybe it's just noise about transient failures for which there is a
>> proper fallback in place.
>
>
> Yeah, I think that is exactly what happens here.
>
> We try to allocate a huge page, but fail and so fall back to using multiple
> 4k pages instead.
>
> Going to send out a patch to suppress the warning.

Hi Christian,

Did you ever send out such a patch? I didn't see one on the list, but
perhaps I missed it. One definitely hasn't made it upstream yet. (I
just hit the issue myself with Linus's tree from last night.)

Thanks,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH] drm: split up drm_ioctl to allow drivers to hook into "core" functions

2017-12-31 Thread Ilia Mirkin 
Currently there's no way to allow a driver to reimplement any ioctls
from the drm core. This can be desirable to, e.g., override fixed format
selection logic, without turning to a midlayer-like solution.

Signed-off-by: Ilia Mirkin 
---

I want drm_mode_addfb to pick a different format for depth=30 than the
one it currently selects. Flipping it for all drivers would break a
bunch of existing ones, so this enables a driver to take control.

Alternatively I can stash something into drm_device which specifies the
preferred depth=30 fb format. However from my cursory observations of
dri-devel discussions, midlayering is seen as a problem and not a
solution.

 drivers/gpu/drm/drm_ioctl.c | 36 
 include/drm/drm_ioctl.h |  2 ++
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 4aafe4802099..698d69c6db0a 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -767,12 +767,7 @@ long drm_ioctl(struct file *filp,
struct drm_file *file_priv = filp->private_data;
struct drm_device *dev;
const struct drm_ioctl_desc *ioctl = NULL;
-   drm_ioctl_t *func;
unsigned int nr = DRM_IOCTL_NR(cmd);
-   int retcode = -EINVAL;
-   char stack_kdata[128];
-   char *kdata = NULL;
-   unsigned int in_size, out_size, drv_size, ksize;
bool is_driver_ioctl;
 
dev = file_priv->minor->dev;
@@ -784,16 +779,33 @@ long drm_ioctl(struct file *filp,
 
if (is_driver_ioctl) {
/* driver ioctl */
-   if (nr - DRM_COMMAND_BASE >= dev->driver->num_ioctls)
-   goto err_i1;
-   ioctl = >driver->ioctls[nr - DRM_COMMAND_BASE];
+   if (nr - DRM_COMMAND_BASE < dev->driver->num_ioctls)
+   ioctl = >driver->ioctls[nr - DRM_COMMAND_BASE];
} else {
/* core ioctl */
-   if (nr >= DRM_CORE_IOCTL_COUNT)
-   goto err_i1;
-   ioctl = _ioctls[nr];
+   if (nr < DRM_CORE_IOCTL_COUNT)
+   ioctl = _ioctls[nr];
}
 
+   return __drm_ioctl(filp, cmd, arg, ioctl);
+}
+EXPORT_SYMBOL(drm_ioctl);
+
+long __drm_ioctl(struct file *filp,
+unsigned int cmd, unsigned long arg,
+const struct drm_ioctl_desc *ioctl)
+{
+   struct drm_file *file_priv = filp->private_data;
+   drm_ioctl_t *func;
+   unsigned int nr = DRM_IOCTL_NR(cmd);
+   int retcode = -EINVAL;
+   char stack_kdata[128];
+   char *kdata = NULL;
+   unsigned int in_size, out_size, drv_size, ksize;
+
+   if (!ioctl)
+   goto err_i1;
+
drv_size = _IOC_SIZE(ioctl->cmd);
out_size = in_size = _IOC_SIZE(cmd);
if ((cmd & ioctl->cmd & IOC_IN) == 0)
@@ -851,7 +863,7 @@ long drm_ioctl(struct file *filp,
DRM_DEBUG("ret = %d\n", retcode);
return retcode;
 }
-EXPORT_SYMBOL(drm_ioctl);
+EXPORT_SYMBOL(__drm_ioctl);
 
 /**
  * drm_ioctl_flags - Check for core ioctl and return ioctl permission flags
diff --git a/include/drm/drm_ioctl.h b/include/drm/drm_ioctl.h
index add42809642a..e08f8ea66f2a 100644
--- a/include/drm/drm_ioctl.h
+++ b/include/drm/drm_ioctl.h
@@ -172,6 +172,8 @@ struct drm_ioctl_desc {
 
 int drm_ioctl_permit(u32 flags, struct drm_file *file_priv);
 long drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
+long __drm_ioctl(struct file *filp, unsigned int cmd, unsigned long arg,
+const struct drm_ioctl_desc *ioctl);
 long drm_ioctl_kernel(struct file *, drm_ioctl_t, void *, u32);
 #ifdef CONFIG_COMPAT
 long drm_compat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
-- 
2.13.6

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104362] GPU fault detected on wine-nine Path of Exile

2017-12-31 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #1 from Vladimir Usikov  ---
What I mean by freezing.
The computer does not respond to the keyboard and mouse.
When I press 'Num Lock' or 'Caps Lock' the LED does not light up.
Clicking on Ctrl+Alt+F# does not switch to the TTY#.
Today, when I went to a hung computer, I saw a new error in dmesg.

[26173.119284] INFO: task amdgpu_cs:0:660 blocked for more than 120 seconds.
[26173.119292]   Tainted: G   O4.14.9-1-ARCH #1
[26173.119295] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[26173.119299] amdgpu_cs:0 D0   660629 0x
[26173.119303] Call Trace:
[26173.119316]  ? __schedule+0x290/0x890
[26173.119320]  schedule+0x2f/0x90
[26173.119407]  amd_sched_entity_push_job+0xd2/0x110 [amdgpu]
[26173.119415]  ? wait_woken+0x80/0x80
[26173.119488]  amdgpu_job_submit+0x76/0x90 [amdgpu]
[26173.119550]  amdgpu_vm_bo_update_mapping.constprop.25+0x35a/0x3c0 [amdgpu]
[26173.119612]  ? amdgpu_vm_prt_cb+0x20/0x20 [amdgpu]
[26173.119673]  amdgpu_vm_bo_update+0x272/0x550 [amdgpu]
[26173.119734]  amdgpu_cs_ioctl+0x12a9/0x1a50 [amdgpu]
[26173.119797]  ? amdgpu_cs_find_mapping+0x90/0x90 [amdgpu]
[26173.119826]  drm_ioctl_kernel+0x59/0xb0 [drm]
[26173.119851]  drm_ioctl+0x2d5/0x370 [drm]
[26173.119910]  ? amdgpu_cs_find_mapping+0x90/0x90 [amdgpu]
[26173.119964]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[26173.119971]  do_vfs_ioctl+0xa1/0x610
[26173.119976]  ? SyS_futex+0x12d/0x180
[26173.119980]  SyS_ioctl+0x74/0x80
[26173.119984]  entry_SYSCALL_64_fastpath+0x1a/0x7d
[26173.119988] RIP: 0033:0x7effda21d337
[26173.119990] RSP: 002b:7effd028eb08 EFLAGS: 0246 ORIG_RAX:
0010
[26173.119993] RAX: ffda RBX: 555f9a2f4870 RCX:
7effda21d337
[26173.119994] RDX: 7effd028eb70 RSI: c0186444 RDI:
0018
[26173.119996] RBP: 7effd028eae0 R08: 7effd028ec10 R09:
7effd028eb50
[26173.119998] R10: 7effd028ec10 R11: 0246 R12:
40086409
[26173.11] R13: 0018 R14: 555f99557420 R15:
555f9a1ecf60

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] drm/tinydrm: add driver for ST7735R panels

2017-12-31 Thread Noralf Trønnes 


Den 21.12.2017 20.35, skrev David Lechner:

On 12/21/2017 01:23 PM, David Lechner wrote:

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner 
---




+    mipi_dbi_command(mipi, ST7735R_GAMCTRP1, 0x0f, 0x1a, 0x0f, 0x18, 
0x2f,

+ 0x28, 0x20, 0x22, 0x1f, 0x1b, 0x23, 0x37, 0x00, 0x07,
+ 0x02, 0x10);
+    mipi_dbi_command(mipi, ST7735R_GAMCTRN1, 0x0f, 0x1b, 0x0f, 0x17, 
0x33,

+ 0x2c, 0x29, 0x2e, 0x30, 0x30, 0x39, 0x3f, 0x00, 0x07,
+ 0x03, 0x10);
By the way, how do you know what is the "right" gamma curve? I think I 
copied this from the generic st7735r driver in fbtft, but I noticed 
that there is also a different curve for the Adafruit 1.8" display in 
fbtft. I'm wondering if I should have used that one instead. I can't 
really tell a difference looking at the display.


From what I can tell this is the curve used by the Arduino library:

https://github.com/adafruit/Adafruit-ST7735-Library/blob/master/Adafruit_ST7735.cpp

static const uint8_t PROGMEM
  Rcmd3[] = { // Init for 7735R, part 3 (red or green tab)
    4,    //  4 commands in list:
    ST7735_GMCTRP1, 16  , //  1: Magical unicorn dust, 16 args, no 
delay:

  0x02, 0x1c, 0x07, 0x12,
  0x37, 0x32, 0x29, 0x2d,
  0x29, 0x25, 0x2B, 0x39,
  0x00, 0x01, 0x03, 0x10,
    ST7735_GMCTRN1, 16  , //  2: Sparkles and rainbows, 16 args, no 
delay:

  0x03, 0x1d, 0x07, 0x06,
  0x2E, 0x2C, 0x29, 0x2D,
  0x2E, 0x2E, 0x37, 0x3F,
  0x00, 0x00, 0x02, 0x10,

void Adafruit_ST7735::initR(uint8_t options) {
  commonInit(Rcmd1);
...
  commandList(Rcmd3);


Noralf.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] drm/tinydrm: add driver for ST7735R panels

2017-12-31 Thread Noralf Trønnes 


Den 21.12.2017 20.23, skrev David Lechner:

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.

Signed-off-by: David Lechner 
---

v3 changes:
* Changed compatible string
* use SPDX license header
* Renamed mode struct to use panel name instead of controller name

v2 changes:
* Change delay from 10ms to 20ms to avoid checkpatch warning
* Use mipi_dbi_pipe_enable()/mipi_dbi_pipe_disable() to reduce duplicated code
* Rebase on drm-misc-next (tinydrm_lastclose => drm_fb_helper_lastclose)
* Use mipi_dbi_debugfs_init
* Add mipi->read_commands = NULL; since this display is write-only



diff --git a/drivers/gpu/drm/tinydrm/st7735r.c 
b/drivers/gpu/drm/tinydrm/st7735r.c
new file mode 100644
index 000..0b05b2c
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Sitronix ST7735R panels
+ *
+ * Copyright 2017 David Lechner 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define ST7735R_FRMCTR10xb1
+#define ST7735R_FRMCTR20xb2
+#define ST7735R_FRMCTR30xb3
+#define ST7735R_INVCTR 0xb4
+#define ST7735R_PWCTR1 0xc0
+#define ST7735R_PWCTR2 0xc1
+#define ST7735R_PWCTR3 0xc2
+#define ST7735R_PWCTR4 0xc3
+#define ST7735R_PWCTR5 0xc4
+#define ST7735R_VMCTR1 0xc5
+#define ST7735R_GAMCTRP1   0xe0
+#define ST7735R_GAMCTRN1   0xe1
+
+#define ST7735R_MY BIT(7)
+#define ST7735R_MX BIT(6)
+#define ST7735R_MV BIT(5)
+
+static void st7735r_pipe_enable(struct drm_simple_display_pipe *pipe,
+   struct drm_crtc_state *crtc_state)


This is confusing, you name the mode after the panel, but not the enable
function which has an initialization sequence that is also panel specific.

With .enable function named after the panel (and *_pipe_funcs):

Reviewed-by: Noralf Trønnes 


+{
+   struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   struct device *dev = tdev->drm->dev;
+   int ret;
+   u8 addr_mode;
+
+   DRM_DEBUG_KMS("\n");
+
+   mipi_dbi_hw_reset(mipi);
+
+   ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
+   return;
+   }
+
+   msleep(150);
+
+   mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+   msleep(500);
+
+   mipi_dbi_command(mipi, ST7735R_FRMCTR1, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR2, 0x01, 0x2c, 0x2d);
+   mipi_dbi_command(mipi, ST7735R_FRMCTR3, 0x01, 0x2c, 0x2d, 0x01, 0x2c,
+0x2d);
+   mipi_dbi_command(mipi, ST7735R_INVCTR, 0x07);
+   mipi_dbi_command(mipi, ST7735R_PWCTR1, 0xa2, 0x02, 0x84);
+   mipi_dbi_command(mipi, ST7735R_PWCTR2, 0xc5);
+   mipi_dbi_command(mipi, ST7735R_PWCTR3, 0x0a, 0x00);
+   mipi_dbi_command(mipi, ST7735R_PWCTR4, 0x8a, 0x2a);
+   mipi_dbi_command(mipi, ST7735R_PWCTR5, 0x8a, 0xee);
+   mipi_dbi_command(mipi, ST7735R_VMCTR1, 0x0e);
+   mipi_dbi_command(mipi, MIPI_DCS_EXIT_INVERT_MODE);
+   switch (mipi->rotation) {
+   default:
+   addr_mode = ST7735R_MX | ST7735R_MY;
+   break;
+   case 90:
+   addr_mode = ST7735R_MX | ST7735R_MV;
+   break;
+   case 180:
+   addr_mode = 0;
+   break;
+   case 270:
+   addr_mode = ST7735R_MY | ST7735R_MV;
+   break;
+   }
+   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+   mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT,
+MIPI_DCS_PIXEL_FMT_16BIT);
+   mipi_dbi_command(mipi, ST7735R_GAMCTRP1, 0x0f, 0x1a, 0x0f, 0x18, 0x2f,
+0x28, 0x20, 0x22, 0x1f, 0x1b, 0x23, 0x37, 0x00, 0x07,
+0x02, 0x10);
+   mipi_dbi_command(mipi, ST7735R_GAMCTRN1, 0x0f, 0x1b, 0x0f, 0x17, 0x33,
+0x2c, 0x29, 0x2e, 0x30, 0x30, 0x39, 0x3f, 0x00, 0x07,
+0x03, 0x10);
+   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+
+   msleep(100);
+
+   mipi_dbi_command(mipi, MIPI_DCS_ENTER_NORMAL_MODE);
+
+   msleep(20);
+
+   mipi_dbi_pipe_enable(pipe, crtc_state);
+}
+
+static const struct drm_simple_display_pipe_funcs st7735r_pipe_funcs = {
+   .enable = st7735r_pipe_enable,
+   .disable= mipi_dbi_pipe_disable,
+   .update = tinydrm_display_pipe_update,
+   .prepare_fb = tinydrm_display_pipe_prepare_fb,
+};
+
+static const struct drm_display_mode jd_t18003_t01_mode = {
+   TINYDRM_MODE(128, 160, 28, 35),
+};
+

Re: [Intel-gfx] [RFC 4/7] drm/prime: Clear drm_gem_object->dma_buf on release

2017-12-31 Thread Chris Wilson 
Quoting Noralf Trønnes (2017-12-31 13:58:40)
> Clear the pointer so the buffer can be re-exported. Otherwise use
> after free happens in the next call to drm_gem_prime_handle_to_fd().
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_prime.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 9a17725b0f7a..3214c0eb7466 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -343,6 +343,7 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
>  
> /* drop the reference on the export fd holds */
> drm_gem_object_put_unlocked(obj);
> +   obj->dma_buf = NULL;

obj->dma_buf holds a reference to the dma_buf, so to get to the dma_buf
release we must have already called dma_buf_put(obj->dma_buf). See
drm_gem_object_exported_dma_buf_free(). (Note you would do the
obj->dma_buf = NULL before dropping the potentially last ref to obj.)
A BUG_ON(obj->dma_buf) may help clarify the cache was already released.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4.15] drm/amd/display: call set csc_default if enable adjustment is false

2017-12-31 Thread Alex Deucher 
On Fri, Dec 29, 2017 at 6:11 AM, Daniel Drake  wrote:
> From: Yue Hin Lau 
>
> Signed-off-by: Yue Hin Lau 
> Reviewed-by: Eric Bernstein 
> Acked-by: Harry Wentland 
> Signed-off-by: Alex Deucher 
> [dr...@endlessm.com: backport to 4.15]
> Signed-off-by: Daniel Drake 
> ---
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h  | 2 +-
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c   | 6 ++
>  drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 ++
>  drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h   | 2 +-
>  4 files changed, 6 insertions(+), 6 deletions(-)
>
> Testing Acer Aspire TC-380 engineering sample (Raven Ridge), the display
> comes up with an excessively green tint. This patch (from 
> amd-staging-drm-next)
> solves the issue. Can it be included in Linux 4.15?

Looks ok to me.  Unless Harry or Leo have any objections, I'll add it
to my queue.

Thanks!

Alex


>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h 
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h
> index a9782b1aba47..34daf895f848 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.h
> @@ -1360,7 +1360,7 @@ void dpp1_cm_set_output_csc_adjustment(
>
>  void dpp1_cm_set_output_csc_default(
> struct dpp *dpp_base,
> -   const struct default_adjustment *default_adjust);
> +   enum dc_color_space colorspace);
>
>  void dpp1_cm_set_gamut_remap(
> struct dpp *dpp,
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c 
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c
> index 40627c244bf5..ed1216b53465 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_cm.c
> @@ -225,14 +225,13 @@ void dpp1_cm_set_gamut_remap(
>
>  void dpp1_cm_set_output_csc_default(
> struct dpp *dpp_base,
> -   const struct default_adjustment *default_adjust)
> +   enum dc_color_space colorspace)
>  {
>
> struct dcn10_dpp *dpp = TO_DCN10_DPP(dpp_base);
> uint32_t ocsc_mode = 0;
>
> -   if (default_adjust != NULL) {
> -   switch (default_adjust->out_color_space) {
> +   switch (colorspace) {
> case COLOR_SPACE_SRGB:
> case COLOR_SPACE_2020_RGB_FULLRANGE:
> ocsc_mode = 0;
> @@ -253,7 +252,6 @@ void dpp1_cm_set_output_csc_default(
> case COLOR_SPACE_UNKNOWN:
> default:
> break;
> -   }
> }
>
> REG_SET(CM_OCSC_CONTROL, 0, CM_OCSC_MODE, ocsc_mode);
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c 
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> index 961ad5c3b454..05dc01e54531 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> @@ -2097,6 +2097,8 @@ static void program_csc_matrix(struct pipe_ctx 
> *pipe_ctx,
> tbl_entry.color_space = color_space;
> //tbl_entry.regval = matrix;
> 
> pipe_ctx->plane_res.dpp->funcs->opp_set_csc_adjustment(pipe_ctx->plane_res.dpp,
>  _entry);
> +   } else {
> +   
> pipe_ctx->plane_res.dpp->funcs->opp_set_csc_default(pipe_ctx->plane_res.dpp, 
> colorspace);
> }
>  }
>  static bool is_lower_pipe_tree_visible(struct pipe_ctx *pipe_ctx)
> diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h 
> b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
> index 83a68460edcd..9420dfb94d39 100644
> --- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
> +++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
> @@ -64,7 +64,7 @@ struct dpp_funcs {
>
> void (*opp_set_csc_default)(
> struct dpp *dpp,
> -   const struct default_adjustment *default_adjust);
> +   enum dc_color_space colorspace);
>
> void (*opp_set_csc_adjustment)(
> struct dpp *dpp,
> --
> 2.14.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104289] [regression][vega10] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout on exiting certain Steam games

2017-12-31 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=104289

--- Comment #10 from Tom Englund  ---
i could reliably reproduce this with starting fallout 4 in wine, getting same
or similiar crashes in dmesg,

however with the last attachment Christian König posted it now runs.
https://bugs.freedesktop.org/attachment.cgi?id=136343

dmesg: 

dec 31 15:01:22 tom-pc kernel: WARNING: CPU: 6 PID: 25993 at
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1641
amdgpu_vm_bo_update_mapping+0x3dd/0x3f0 [amdgpu]
dec 31 15:01:22 tom-pc kernel: Modules linked in: fuse mousedev msr
nls_iso8859_1 nls_cp437 vfat fat intel_rapl x86_pkg_temp_thermal
intel_powerclamp coretemp 
dec 31 15:01:22 tom-pc kernel:  gpu_sched drm_kms_helper syscopyarea
sysfillrect sysimgblt fb_sys_fops ttm drm agpgart
dec 31 15:01:22 tom-pc kernel: CPU: 6 PID: 25993 Comm: amdgpu_cs:0 Tainted: G  
 W4.15.0-rc2-mainline #1
dec 31 15:01:22 tom-pc kernel: Hardware name: Gigabyte Technology Co., Ltd.
Z170-HD3P/Z170-HD3P-CF, BIOS F20 11/04/2016
dec 31 15:01:22 tom-pc kernel: task: 569a51e8 task.stack:
bc284a6f
dec 31 15:01:22 tom-pc kernel: RIP:
0010:amdgpu_vm_bo_update_mapping+0x3dd/0x3f0 [amdgpu]
dec 31 15:01:22 tom-pc kernel: RSP: 0018:ace501b7b9e0 EFLAGS: 00010216
dec 31 15:01:22 tom-pc kernel: RAX: 92a0f7ac6e58 RBX: 92a0c072d800 RCX:
92a1682b6550
dec 31 15:01:22 tom-pc kernel: RDX: ace50336c700 RSI: 92a0f7ac6e58 RDI:
92a1682b6560
dec 31 15:01:22 tom-pc kernel: RBP: 92a1682b R08: 0002 R09:

dec 31 15:01:22 tom-pc kernel: R10: 07fb R11: 07f9 R12:
078e
dec 31 15:01:22 tom-pc kernel: R13: 92a1682b6560 R14: 00109200 R15:

dec 31 15:01:22 tom-pc kernel: FS:  7fc349c21700()
GS:92a17ed8() knlGS:7fea8000
dec 31 15:01:22 tom-pc kernel: CS:  0010 DS:  ES:  CR0:
80050033
dec 31 15:01:22 tom-pc kernel: CR2: 7fc296881fa8 CR3: 0003e8fbd003 CR4:
003606e0
dec 31 15:01:22 tom-pc kernel: DR0:  DR1:  DR2:

dec 31 15:01:22 tom-pc kernel: DR3:  DR6: fffe0ff0 DR7:
0400
dec 31 15:01:22 tom-pc kernel: Call Trace:
dec 31 15:01:22 tom-pc kernel:  ? amdgpu_vm_free_mapping.isra.24+0x20/0x20
[amdgpu]
dec 31 15:01:22 tom-pc kernel:  amdgpu_vm_bo_update+0x327/0x5e0 [amdgpu]
dec 31 15:01:22 tom-pc kernel:  amdgpu_vm_handle_moved+0x73/0xa0 [amdgpu]
dec 31 15:01:22 tom-pc kernel:  amdgpu_cs_ioctl+0x1a4a/0x1ae0 [amdgpu]
dec 31 15:01:22 tom-pc kernel:  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
dec 31 15:01:22 tom-pc kernel:  drm_ioctl_kernel+0x59/0xb0 [drm]
dec 31 15:01:22 tom-pc kernel:  drm_ioctl+0x2d5/0x370 [drm]
dec 31 15:01:22 tom-pc kernel:  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
dec 31 15:01:22 tom-pc kernel:  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
dec 31 15:01:22 tom-pc kernel:  do_vfs_ioctl+0xa1/0x610
dec 31 15:01:22 tom-pc kernel:  ? SyS_futex+0x12d/0x180
dec 31 15:01:22 tom-pc kernel:  SyS_ioctl+0x74/0x80
dec 31 15:01:22 tom-pc kernel:  entry_SYSCALL_64_fastpath+0x1a/0x7d
dec 31 15:01:22 tom-pc kernel: RIP: 0033:0x7fc41e3b1a07
dec 31 15:01:22 tom-pc kernel: RSP: 002b:7fc349c20c78 EFLAGS: 0246
ORIG_RAX: 0010
dec 31 15:01:22 tom-pc kernel: RAX: ffda RBX: 0008 RCX:
7fc41e3b1a07
dec 31 15:01:22 tom-pc kernel: RDX: 7fc349c20ce0 RSI: c0186444 RDI:
001e
dec 31 15:01:22 tom-pc kernel: RBP: 7fc349c20e00 R08: 7fc349c20d80 R09:
7fc349c20cc0
dec 31 15:01:22 tom-pc kernel: R10: 0001 R11: 0246 R12:
7cdf0a98
dec 31 15:01:22 tom-pc kernel: R13: 0001 R14: 7fc349c20cf0 R15:

dec 31 15:01:22 tom-pc kernel: Code: ff 74 16 f0 ff 0f 0f 88 3c d4 12 00 75 0b
89 04 24 e8 c8 44 0a e3 8b 04 24 48 8b 54 24 38 48 8b 5c 24 08 48 89 13 e9 0b
fd
dec 31 15:01:22 tom-pc kernel: ---[ end trace 425bb209c57fc66b ]---
dec 31 15:01:32 tom-pc kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring
sdma0 timeout, last signaled seq=53896, last emitted seq=53898
dec 31 15:01:32 tom-pc kernel: [drm] No hardware hang detected. Did some blocks
stall?
dec 31 15:01:35 tom-pc systemd-logind[561]: Power key pressed.
dec 31 15:01:35 tom-pc systemd-logind[561]: Powering Off...
dec 31 15:01:35 tom-pc systemd-logind[561]: System is powering down.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103976] Regression: Videogame (Wakfu) no longer works with Mesa 17.2 (17.1 works)

2017-12-31 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103976

Azari  changed:

   What|Removed |Added

 CC||azari4...@gmail.com

--- Comment #1 from Azari  ---
Created attachment 136459
  --> https://bugs.freedesktop.org/attachment.cgi?id=136459=edit
Revert Mesa commit 92b4ca45504e7ffc5f4fa385ada1be48e6123181

I bisected and tracked this down to the following commit: 
https://cgit.freedesktop.org/mesa/mesa/commit/?id=92b4ca45504e7ffc5f4fa385ada1be48e6123181

"remove the 'Gallium 0.4 on' prefix from GL_RENDERER"

It looks like the game or one of the game's libraries (jogl?) are checking for
gallium in the renderer string. Based on the nature of this patch and tone of
the commit message, I guess I shouldn't be very optimistic about this being
reverted.

I found that MATLAB and Scilab appear to suffer from the same issue though,
these have been filed as bug 103078.

I reverted the commit and made a patch for myself to use until a better
workaround/solution appears, I'm attaching it here in the hope that others
running into this problem find it useful.

I imagine more people will run into this as more distributions upgrade to 17.2
(especially when LTS versions start upgrading).

It would be nice if there was at least a better workaround, like the ability to
override the renderer string with an env var or through drirc

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 6/7] drm/fb-helper: Add generic fbdev emulation

2017-12-31 Thread Noralf Trønnes 
Add generic fbdev emulation which uses a drm_file to get a dumb_buffer
and drm_framebuffer. The buffer is exported and vmap/mmap called on
the dma-buf.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 289 
 include/drm/drm_fb_helper.h |  33 +
 2 files changed, 322 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f9dcc7a5761f..d51bd5b1ecf1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -30,6 +30,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -43,6 +44,7 @@
 
 #include "drm_crtc_internal.h"
 #include "drm_crtc_helper_internal.h"
+#include "drm_internal.h"
 
 static bool drm_fbdev_emulation = true;
 module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
@@ -2975,6 +2977,293 @@ void drm_fb_helper_output_poll_changed(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
 
+static int drm_fb_helper_generic_vmap(struct drm_fb_helper *fb_helper)
+{
+   struct drm_prime_handle prime_args = {
+   .handle = fb_helper->dumb_handle,
+   };
+   struct dma_buf *dma_buf;
+   void *vaddr;
+   int ret;
+
+   ret = drm_prime_handle_to_fd_ioctl(fb_helper->dev, _args,
+  fb_helper->file);
+   if (ret)
+   return ret;
+
+   dma_buf = dma_buf_get(prime_args.fd);
+   if (WARN_ON(IS_ERR(dma_buf)))
+   return PTR_ERR(dma_buf);
+
+   /* drop the ref we picked up in handle_to_fd */
+   dma_buf_put(dma_buf);
+
+   vaddr = dma_buf_vmap(dma_buf);
+   if (!vaddr) {
+   ret = -ENOMEM;
+   goto err_remove_handle;
+   }
+
+   if (fb_helper->fbdev->fbdefio)
+   fb_deferred_io_init(fb_helper->fbdev);
+
+   fb_helper->fbdev->screen_buffer = vaddr;
+   fb_helper->dma_buf = dma_buf;
+
+   return 0;
+
+err_remove_handle:
+   drm_prime_remove_buf_handle_locked(_helper->file->prime,
+  fb_helper->dma_buf);
+   dma_buf_put(dma_buf);
+
+   return ret;
+}
+
+static void drm_fb_helper_generic_vunmap(struct drm_fb_helper *fb_helper)
+{
+   if (fb_helper->fbdev->fbdefio) {
+   cancel_delayed_work_sync(_helper->fbdev->deferred_work);
+   cancel_work_sync(_helper->dirty_work);
+   fb_deferred_io_cleanup(fb_helper->fbdev);
+   }
+
+   dma_buf_vunmap(fb_helper->dma_buf, fb_helper->fbdev->screen_buffer);
+   fb_helper->fbdev->screen_buffer = NULL;
+
+   drm_prime_remove_buf_handle_locked(_helper->file->prime,
+  fb_helper->dma_buf);
+   dma_buf_put(fb_helper->dma_buf);
+   fb_helper->dma_buf = NULL;
+}
+
+static int drm_fb_helper_generic_fb_open(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   int ret;
+
+   ret = drm_fb_helper_fb_open(info, user);
+   if (ret)
+   return ret;
+
+   if (!fb_helper->fbdev->screen_buffer) {
+   /*
+* Exporting a buffer to get a virtual address results in
+* dma-buf pinning the driver module. This means that we have
+* to vmap/vunmap in open/close to be able to unload the driver
+* module.
+*/
+   ret = drm_fb_helper_generic_vmap(fb_helper);
+   if (ret) {
+   DRM_ERROR("fbdev: Failed to vmap buffer: %d\n", ret);
+   drm_fb_helper_fb_release(info, user);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+static int drm_fb_helper_generic_fb_release(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   drm_fb_helper_fb_release(info, user);
+
+   if (!atomic_read(_helper->open_count))
+   drm_fb_helper_generic_vunmap(fb_helper);
+
+   return 0;
+}
+
+static int drm_fb_helper_generic_fb_mmap(struct fb_info *info,
+struct vm_area_struct *vma)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   return dma_buf_mmap(fb_helper->dma_buf, vma, 0);
+}
+
+static struct fb_ops drm_fb_helper_generic_fbdev_ops = {
+   .owner  = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,
+   .fb_open= drm_fb_helper_generic_fb_open,
+   .fb_release = drm_fb_helper_generic_fb_release,
+   .fb_mmap= drm_fb_helper_generic_fb_mmap,
+   .fb_read= drm_fb_helper_sys_read,
+   .fb_write   = drm_fb_helper_sys_write,
+   .fb_fillrect= drm_fb_helper_sys_fillrect,
+   .fb_copyarea= drm_fb_helper_sys_copyarea,
+   .fb_imageblit   = drm_fb_helper_sys_imageblit,
+};
+
+static struct fb_deferred_io

[RFC 5/7] drm: Handle fbdev emulation in core

2017-12-31 Thread Noralf Trønnes 
Prepare for generic fbdev emulation by letting DRM core work directly
with the fbdev compatibility layer. This is done by adding new fbdev
helper vtable callbacks for restore, hotplug_event, unregister and
release.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_file.c | 12 +++-
 drivers/gpu/drm/drm_mode_config.c  | 10 ++
 drivers/gpu/drm/drm_probe_helper.c |  4 
 include/drm/drm_fb_helper.h| 33 +
 4 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index d208faade27e..67f0309e22ff 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -439,10 +440,19 @@ static void drm_legacy_dev_reinit(struct drm_device *dev)
 
 void drm_lastclose(struct drm_device * dev)
 {
+   struct drm_fb_helper *fb_helper = dev->fb_helper;
+   int ret;
+
DRM_DEBUG("\n");
 
-   if (dev->driver->lastclose)
+   if (dev->driver->lastclose) {
dev->driver->lastclose(dev);
+   } else if (fb_helper && fb_helper->funcs && fb_helper->funcs->restore) {
+   ret = fb_helper->funcs->restore(fb_helper);
+   if (ret)
+   DRM_ERROR("Failed to restore fbdev: %d\n", ret);
+   }
+
DRM_DEBUG("driver lastclose completed\n");
 
if (drm_core_check_feature(dev, DRIVER_LEGACY))
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index bc5c46306b3d..260eb1730244 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -21,6 +21,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -61,6 +62,11 @@ int drm_modeset_register_all(struct drm_device *dev)
 
 void drm_modeset_unregister_all(struct drm_device *dev)
 {
+   struct drm_fb_helper *fb_helper = dev->fb_helper;
+
+   if (fb_helper && fb_helper->funcs && fb_helper->funcs->unregister)
+   fb_helper->funcs->unregister(fb_helper);
+
drm_connector_unregister_all(dev);
drm_encoder_unregister_all(dev);
drm_crtc_unregister_all(dev);
@@ -408,6 +414,7 @@ EXPORT_SYMBOL(drm_mode_config_init);
  */
 void drm_mode_config_cleanup(struct drm_device *dev)
 {
+   struct drm_fb_helper *fb_helper = dev->fb_helper;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
struct drm_crtc *crtc, *ct;
@@ -417,6 +424,9 @@ void drm_mode_config_cleanup(struct drm_device *dev)
struct drm_property_blob *blob, *bt;
struct drm_plane *plane, *plt;
 
+   if (fb_helper && fb_helper->funcs && fb_helper->funcs->release)
+   fb_helper->funcs->release(fb_helper);
+
list_for_each_entry_safe(encoder, enct, >mode_config.encoder_list,
 head) {
encoder->funcs->destroy(encoder);
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 555fbe54d6e2..9d8b0ba54173 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -559,10 +559,14 @@ EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
  */
 void drm_kms_helper_hotplug_event(struct drm_device *dev)
 {
+   struct drm_fb_helper *fb_helper = dev->fb_helper;
+
/* send a uevent + call fbdev */
drm_sysfs_hotplug_event(dev);
if (dev->mode_config.funcs->output_poll_changed)
dev->mode_config.funcs->output_poll_changed(dev);
+   else if (fb_helper && fb_helper->funcs && 
fb_helper->funcs->hotplug_event)
+   fb_helper->funcs->hotplug_event(fb_helper);
 }
 EXPORT_SYMBOL(drm_kms_helper_hotplug_event);
 
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 5d4ccc3f28aa..f5ea79bbb831 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -125,6 +125,39 @@ struct drm_fb_helper_funcs {
   struct drm_display_mode **modes,
   struct drm_fb_offset *offsets,
   bool *enabled, int width, int height);
+
+   /**
+* @restore:
+*
+* Optional callback for restoring fbdev emulation.
+* Called by drm_lastclose() if _driver->lastclose is not set.
+*/
+   int (*restore)(struct drm_fb_helper *fb_helper);
+
+   /**
+* @hotplug_event:
+*
+* Optional callback for hotplug events.
+* Called by drm_kms_helper_hotplug_event() if
+* _mode_config_funcs->output_poll_changed  is not set.
+*/
+   int (*hotplug_event)(struct drm_fb_helper *fb_helper);
+
+   /**
+* @unregister:
+*
+* Optional callback for unregistrering fbdev emulation.
+* Called by drm_dev_unregister().
+*/
+   void (*unregister)(struct drm_fb_helper

[RFC 7/7] drm/vc4: Test generic fbdev emulation

2017-12-31 Thread Noralf Trønnes 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 3 ---
 drivers/gpu/drm/vc4/vc4_kms.c | 3 +--
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index ceb385fd69c5..ef8a2d3a6d1f 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -152,7 +152,6 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_HAVE_IRQ |
DRIVER_RENDER |
DRIVER_PRIME),
-   .lastclose = drm_fb_helper_lastclose,
.irq_handler = vc4_irq,
.irq_preinstall = vc4_irq_preinstall,
.irq_postinstall = vc4_irq_postinstall,
@@ -297,8 +296,6 @@ static void vc4_drm_unbind(struct device *dev)
 
drm_dev_unregister(drm);
 
-   drm_fb_cma_fbdev_fini(drm);
-
drm_mode_config_cleanup(drm);
 
drm_dev_unref(drm);
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 4256f294c346..671c62f1b4d3 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -188,7 +188,6 @@ static struct drm_framebuffer *vc4_fb_create(struct 
drm_device *dev,
 }
 
 static const struct drm_mode_config_funcs vc4_mode_funcs = {
-   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = vc4_atomic_commit,
.fb_create = vc4_fb_create,
@@ -219,7 +218,7 @@ int vc4_kms_load(struct drm_device *dev)
drm_mode_config_reset(dev);
 
if (dev->mode_config.num_connector)
-   drm_fb_cma_fbdev_init(dev, 32, 0);
+   drm_fb_helper_generic_fbdev_setup(dev, 32, 0);
 
drm_kms_helper_poll_init(dev);
 
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 4/7] drm/prime: Clear drm_gem_object->dma_buf on release

2017-12-31 Thread Noralf Trønnes 
Clear the pointer so the buffer can be re-exported. Otherwise use
after free happens in the next call to drm_gem_prime_handle_to_fd().

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_prime.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9a17725b0f7a..3214c0eb7466 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -343,6 +343,7 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
 
/* drop the reference on the export fd holds */
drm_gem_object_put_unlocked(obj);
+   obj->dma_buf = NULL;
 
drm_dev_put(dev);
 }
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 3/7] drm/fb-helper: Don't restore if fbdev is not in use

2017-12-31 Thread Noralf Trønnes 
Keep track of fbdev users and only restore fbdev in
drm_fb_helper_restore_fbdev_mode_unlocked() when in use. This avoids
fbdev being restored in drm_driver.last_close when nothing uses it.
Additionally fbdev is turned off when the last user is closing.
fbcon is a user in this context.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 15 +++
 include/drm/drm_fb_helper.h | 14 ++
 2 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2c6adf1d80c2..f9dcc7a5761f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -522,6 +522,9 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
if (READ_ONCE(fb_helper->deferred_setup))
return 0;
 
+   if (!atomic_read(_helper->open_count))
+   return 0;
+
mutex_lock(_helper->lock);
ret = restore_fbdev_mode(fb_helper);
 
@@ -781,6 +784,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct 
drm_fb_helper *helper,
INIT_WORK(>resume_work, drm_fb_helper_resume_worker);
INIT_WORK(>dirty_work, drm_fb_helper_dirty_work);
helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
+   atomic_set(>open_count, 1);
mutex_init(>lock);
helper->funcs = funcs;
helper->dev = dev;
@@ -1212,6 +1216,7 @@ EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
  * @info: fbdev registered by the helper
  * @user: 1=userspace, 0=fbcon
  *
+ * Increase fbdev use count.
  * If _ops is wrapped in a library, pin the driver module.
  */
 int drm_fb_helper_fb_open(struct fb_info *info, int user)
@@ -1224,6 +1229,8 @@ int drm_fb_helper_fb_open(struct fb_info *info, int user)
return -ENODEV;
}
 
+   atomic_inc(_helper->open_count);
+
return 0;
 }
 EXPORT_SYMBOL(drm_fb_helper_fb_open);
@@ -1233,6 +1240,7 @@ EXPORT_SYMBOL(drm_fb_helper_fb_open);
  * @info: fbdev registered by the helper
  * @user: 1=userspace, 0=fbcon
  *
+ * Decrease fbdev use count and turn off if there are no users left.
  * If _ops is wrapped in a library, unpin the driver module.
  */
 int drm_fb_helper_fb_release(struct fb_info *info, int user)
@@ -1240,6 +1248,10 @@ int drm_fb_helper_fb_release(struct fb_info *info, int 
user)
struct drm_fb_helper *fb_helper = info->par;
struct drm_device *dev = fb_helper->dev;
 
+   if (atomic_dec_and_test(_helper->open_count) &&
+   !drm_dev_is_unplugged(fb_helper->dev))
+   drm_fb_helper_blank(FB_BLANK_POWERDOWN, info);
+
if (info->fbops->owner != dev->driver->fops->owner)
module_put(dev->driver->fops->owner);
 
@@ -1936,6 +1948,9 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
if (ret < 0)
return ret;
 
+   if (fb_helper->fbdev->fbops->fb_open == drm_fb_helper_fb_open)
+   atomic_set(_helper->open_count, 0);
+
strcpy(fb_helper->fb->comm, "[fbcon]");
return 0;
 }
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 6f546ca3a6a1..5d4ccc3f28aa 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -232,6 +232,20 @@ struct drm_fb_helper {
 * See also: @deferred_setup
 */
int preferred_bpp;
+
+   /**
+* @open_count:
+*
+* Keeps track of fbdev use to know when to not restore fbdev.
+*
+* Drivers that use DRM_FB_HELPER_DEFAULT_OPS and don't override
+* \.fb_open will get an initial value of 0 and get restore based on
+* actual use. Others will get an initial value of 1 which means that
+* fbdev will always be restored. Drivers that call
+* drm_fb_helper_fb_open() in their \.fb_open, thus needs to set the
+* initial value to 0 themselves.
+*/
+   atomic_t open_count;
 };
 
 /**
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/7] drm: Add generic fbdev emulation

2017-12-31 Thread Noralf Trønnes 
This patchset explores the possibility of having generic fbdev emulation
in DRM for drivers that supports dumb buffers which they can export.

I was about to polish up my 'vmalloc BO helper' series, which has fbdev
support, when this idea[1] of Laurent popped into my mind:

  Ideally I'd like to remove 100% of fbdev-related code from drivers. This
  includes
  - initialization and cleanup of fbdev helpers
  - fbdev restore in last_close()
  - forwarding of hotplug events to fbdev compatibility layer

  In practice we'll likely need to keep one initialization function (or a
  drm_driver flag) to let drivers opt-in to fbdev compatibility, but the rest
  should go away. Or maybe we could even enable fbdev compatibility in all
  drivers unconditionally.

So I set out to see what it would take to accomplish that.

Noralf.

[1] https://lists.freedesktop.org/archives/dri-devel/2017-September/152612.html


David Herrmann (1):
  drm: provide management functions for drm_file

Noralf Trønnes (6):
  drm/fb-helper: Ensure driver module is pinned in fb_open()
  drm/fb-helper: Don't restore if fbdev is not in use
  drm/prime: Clear drm_gem_object->dma_buf on release
  drm: Handle fbdev emulation in core
  drm/fb-helper: Add generic fbdev emulation
  drm/vc4: Test generic fbdev emulation

 drivers/gpu/drm/drm_fb_helper.c| 344 +
 drivers/gpu/drm/drm_file.c | 321 --
 drivers/gpu/drm/drm_internal.h |   2 +
 drivers/gpu/drm/drm_mode_config.c  |  10 ++
 drivers/gpu/drm/drm_prime.c|   1 +
 drivers/gpu/drm/drm_probe_helper.c |   4 +
 drivers/gpu/drm/vc4/vc4_drv.c  |   3 -
 drivers/gpu/drm/vc4/vc4_kms.c  |   3 +-
 include/drm/drm_fb_helper.h|  95 ++
 9 files changed, 645 insertions(+), 138 deletions(-)

-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 2/7] drm/fb-helper: Ensure driver module is pinned in fb_open()

2017-12-31 Thread Noralf Trønnes 
If struct fb_ops is defined in a library like cma, fb_open() and fbcon
takes a ref on the library instead of the driver module. Use
fb_ops.fb_open/fb_release to ensure that the driver module is pinned.

Add drm_fb_helper_fb_open() and drm_fb_helper_fb_release() to
DRM_FB_HELPER_DEFAULT_OPS().

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 40 
 include/drm/drm_fb_helper.h | 15 +++
 2 files changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 035784ddd133..2c6adf1d80c2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1207,6 +1207,46 @@ void drm_fb_helper_cfb_imageblit(struct fb_info *info,
 }
 EXPORT_SYMBOL(drm_fb_helper_cfb_imageblit);
 
+/**
+ * drm_fb_helper_fb_open - implementation for _ops.fb_open
+ * @info: fbdev registered by the helper
+ * @user: 1=userspace, 0=fbcon
+ *
+ * If _ops is wrapped in a library, pin the driver module.
+ */
+int drm_fb_helper_fb_open(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   struct drm_device *dev = fb_helper->dev;
+
+   if (info->fbops->owner != dev->driver->fops->owner) {
+   if (!try_module_get(dev->driver->fops->owner))
+   return -ENODEV;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_fb_open);
+
+/**
+ * drm_fb_helper_fb_release - implementation for _ops.fb_release
+ * @info: fbdev registered by the helper
+ * @user: 1=userspace, 0=fbcon
+ *
+ * If _ops is wrapped in a library, unpin the driver module.
+ */
+int drm_fb_helper_fb_release(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   struct drm_device *dev = fb_helper->dev;
+
+   if (info->fbops->owner != dev->driver->fops->owner)
+   module_put(dev->driver->fops->owner);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_fb_release);
+
 /**
  * drm_fb_helper_set_suspend - wrapper around fb_set_suspend
  * @fb_helper: driver-allocated fbdev helper, can be NULL
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index b069433e7fc1..6f546ca3a6a1 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -241,6 +241,8 @@ struct drm_fb_helper {
  * functions. To be used in struct fb_ops of drm drivers.
  */
 #define DRM_FB_HELPER_DEFAULT_OPS \
+   .fb_open= drm_fb_helper_fb_open, \
+   .fb_release = drm_fb_helper_fb_release, \
.fb_check_var   = drm_fb_helper_check_var, \
.fb_set_par = drm_fb_helper_set_par, \
.fb_setcmap = drm_fb_helper_setcmap, \
@@ -297,6 +299,9 @@ void drm_fb_helper_cfb_copyarea(struct fb_info *info,
 void drm_fb_helper_cfb_imageblit(struct fb_info *info,
 const struct fb_image *image);
 
+int drm_fb_helper_fb_open(struct fb_info *info, int user);
+int drm_fb_helper_fb_release(struct fb_info *info, int user);
+
 void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, bool suspend);
 void drm_fb_helper_set_suspend_unlocked(struct drm_fb_helper *fb_helper,
bool suspend);
@@ -473,6 +478,16 @@ static inline void drm_fb_helper_cfb_imageblit(struct 
fb_info *info,
 {
 }
 
+static inline int drm_fb_helper_fb_open(struct fb_info *info, int user)
+{
+   return -ENODEV;
+}
+
+static inline int drm_fb_helper_fb_release(struct fb_info *info, int user)
+{
+   return -ENODEV;
+}
+
 static inline void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper,
 bool suspend)
 {
-- 
2.14.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 1/7] drm: provide management functions for drm_file

2017-12-31 Thread Noralf Trønnes 
From: David Herrmann 

Rather than doing drm_file allocation/destruction right in the fops, lets
provide separate helpers. This decouples drm_file management from the
still-mandatory drm-fops. It prepares for use of drm_file without the
fops, both by possible separate fops implementations and APIs (not that I
am aware of any such plans), and more importantly from in-kernel use where
no real file is available.

Signed-off-by: David Herrmann 
[rebased]
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_file.c | 309 +++--
 drivers/gpu/drm/drm_internal.h |   2 +
 2 files changed, 179 insertions(+), 132 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index b3c6e997ccdb..d208faade27e 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -101,6 +101,179 @@ DEFINE_MUTEX(drm_global_mutex);
 
 static int drm_open_helper(struct file *filp, struct drm_minor *minor);
 
+/**
+ * drm_file_alloc - allocate file context
+ * @minor: minor to allocate on
+ *
+ * This allocates a new DRM file context. It is not linked into any context and
+ * can be used by the caller freely. Note that the context keeps a pointer to
+ * @minor, so it must be freed before @minor is.
+ *
+ * The legacy paths might require the drm_global_mutex to be held.
+ *
+ * RETURNS:
+ * Pointer to newly allocated context, ERR_PTR on failure.
+ */
+struct drm_file *drm_file_alloc(struct drm_minor *minor)
+{
+   struct drm_device *dev = minor->dev;
+   struct drm_file *file;
+   int ret;
+
+   file = kzalloc(sizeof(*file), GFP_KERNEL);
+   if (!file)
+   return ERR_PTR(-ENOMEM);
+
+   file->pid = get_pid(task_pid(current));
+   file->minor = minor;
+
+   /* for compatibility root is always authenticated */
+   file->authenticated = capable(CAP_SYS_ADMIN);
+   file->lock_count = 0;
+
+   INIT_LIST_HEAD(>lhead);
+   INIT_LIST_HEAD(>fbs);
+   mutex_init(>fbs_lock);
+   INIT_LIST_HEAD(>blobs);
+   INIT_LIST_HEAD(>pending_event_list);
+   INIT_LIST_HEAD(>event_list);
+   init_waitqueue_head(>event_wait);
+   file->event_space = 4096; /* set aside 4k for event buffer */
+
+   mutex_init(>event_read_lock);
+
+   if (drm_core_check_feature(dev, DRIVER_GEM))
+   drm_gem_open(dev, file);
+
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_open(file);
+
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_init_file_private(>prime);
+
+   if (dev->driver->open) {
+   ret = dev->driver->open(dev, file);
+   if (ret < 0)
+   goto out_prime_destroy;
+   }
+
+   if (drm_is_primary_client(file)) {
+   ret = drm_master_open(file);
+   if (ret)
+   goto out_close;
+   }
+
+   return file;
+
+out_close:
+   if (dev->driver->postclose)
+   dev->driver->postclose(dev, file);
+out_prime_destroy:
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_destroy_file_private(>prime);
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_release(file);
+   if (drm_core_check_feature(dev, DRIVER_GEM))
+   drm_gem_release(dev, file);
+   put_pid(file->pid);
+   kfree(file);
+
+   return ERR_PTR(ret);
+}
+
+static void drm_events_release(struct drm_file *file_priv)
+{
+   struct drm_device *dev = file_priv->minor->dev;
+   struct drm_pending_event *e, *et;
+   unsigned long flags;
+
+   spin_lock_irqsave(>event_lock, flags);
+
+   /* Unlink pending events */
+   list_for_each_entry_safe(e, et, _priv->pending_event_list,
+pending_link) {
+   list_del(>pending_link);
+   e->file_priv = NULL;
+   }
+
+   /* Remove unconsumed events */
+   list_for_each_entry_safe(e, et, _priv->event_list, link) {
+   list_del(>link);
+   kfree(e);
+   }
+
+   spin_unlock_irqrestore(>event_lock, flags);
+}
+
+/**
+ * drm_file_free - free file context
+ * @file: context to free, or NULL
+ *
+ * This destroys and deallocates a DRM file context previously allocated via
+ * drm_file_alloc(). The caller must make sure to unlink it from any contexts
+ * before calling this.
+ *
+ * The legacy paths might require the drm_global_mutex to be held.
+ *
+ * If NULL is passed, this is a no-op.
+ *
+ * RETURNS:
+ * 0 on success, or error code on failure.
+ */
+void drm_file_free(struct drm_file *file)
+{
+   struct drm_device *dev;
+
+   if (!file)
+   return;
+
+   dev = file->minor->dev;
+
+   DRM_DEBUG("pid = %d, device = 0x%lx, open_count = %d\n",
+ task_pid_nr(current),
+

Re: [PATCH 01/33] clk_ops: change round_rate() to return unsigned long

2017-12-31 Thread Bryan O'Donoghue 

On 30/12/17 16:36, Mikko Perttunen wrote:
FWIW, we had this problem some years ago with the Tegra CPU clock - then 
it was determined that a simpler solution was to have the determine_rate 
callback support unsigned long rates - so clock drivers that need to 
return rates higher than 2^31 can instead implement the determine_rate 
callback. That is what's currently implemented.


Mikko


Granted we could work around it but, having both zero and less than zero 
indicate error means you can't support larger than LONG_MAX which is I 
think worth fixing.


---
bod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

2017-12-31 Thread Alan Cox 
On Tue, 19 Dec 2017 15:07:53 +0100
Oliver Neukum  wrote:

> Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter:
> > > Would you like me to extend the FB API or not?  
> > 
> > Yes. Well for real I'd like you to do kms, so maybe you need to explain
> > why exactly you absolutely have to use fbdev (aka which driver isn't
> > supported by drm that you want to enable this on).  
> 
> Hi,
> 
> those would be at a minimum efifb, vesafb, xenfb
> Those are obviously not sexy, but from a practical point of view
> they are the minimum you need to support.

I think it's more constructive to look at it the other way around. What
drivers do we have that actually need to be used which don't have DRM
equivalents - and how do we fix that instead ?

Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

2017-12-31 Thread Alan Cox 
> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
> But most likely you want this on a highly embedded system, which

It wouldn't be in kernel on such a device, it'll be in the bootstrap
before (or on a dual core device quite possibly while) the kernel data is
being uncompressed. Most displays need some time to stabilize clocks and
PLLs so you have to get the mode set up really really early on embedded
devices where in some cases you've got regulatory requirements to show
something on the display really really quickly. Consumers perceive a
second from on to displaying something as sluggish on a fixed function
device.

> probably is compiled for your exact hw, with pretty much everything
> built in. Also, no fbcon, maybe even no vt subsystem at all.
> Definitely not your general purpose distro.

Probably no console or tty layer even present, no keyboard drivers, no
mouse.

Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

2017-12-31 Thread Alan Cox 
On Tue, 19 Dec 2017 19:40:12 +0100
Max Staudt  wrote:

> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt  wrote:  
> >> Well, those could enable fbcon if they want the bootsplash. Shouldn't make 
> >> a difference anyway if they're powerful enough to run Linux. As long as 
> >> the bootsplash is shown, no fbcon drawing operations are executed, so 
> >> there is no expensive scrolling or such to hog the system.  
> > 
> > It's too big, and those folks tend to be super picky about space.  
> 
> I know, they really are.
> 
> However, given just how big and clunky modern systems have become, I raise my 
> doubts about a few extra KB for fbcon code to be relevant.

For embedded every KB counts. That is likely to remain the same for some
time because at the end of the day small devices are constrained about the
amount of SRAM you can put on die and the amount of power you can afford
for DRAM. 

> > this by ignoring it an adding a hole new layer on top. That doesn't
> > sound like any kind of good idea to me.  
> 
> Yes. It is a vast improvement over the status quo, and people are asking for 
> it. And the bootsplash layer can be moved elsewhere, just change the hooks 
> and keep the loading/rendering.
> 
> Also, gfx driver loading isn't a dumpster fire, it mostly just works. It just 
> mustn't be done 100% carelessly.

It's a total mess (the fbcon layer loading and locking that is). Doing all
this extra kernel stuff is like sitting in a hole and instead of trying to
climb out digging the hole bigger so you've got more room to sit in it.

Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel