Re: [RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

On Mon, Feb 05, 2018 at 12:56:04PM +0100, Linus Walleij wrote:
> On Mon, Feb 5, 2018 at 9:47 AM, Ludovic Desroches
>  wrote:
> 
> > Use GPIO descriptors instead of relying on the old method.
> >
> > Signed-off-by: Ludovic Desroches 
> 
> Ah there it is :D
> Reviewed-by: Linus Walleij 
> 
> PS: why not move it all over to use DRI/DRM/KMS? It's becoming
> easier and easier.

It concerns old products, that's why it's not converted yet.

Regards

Ludovic

> 
> Yours,
> Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V2] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

Use GPIO descriptors instead of relying on the old method.

Signed-off-by: Ludovic Desroches 
Acked-by: Nicolas Ferre 
Reviewed-by: Linus Walleij 
Reviewed-by: Andy Shevchenko 
---
Changes
- V2:
  - remove of_gpio.h.
  - move gpiod declaration to preserve reversed tree style.
  - use devm_gpiod_get_index instead of devm_gpiod_get_index_optional
  since all errors are treated in the same way.

 drivers/video/fbdev/atmel_lcdfb.c | 31 ---
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index 3dee267d7c75..076d24afbd72 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -18,10 +18,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -61,8 +61,7 @@ struct atmel_lcdfb_info {
 };
 
 struct atmel_lcdfb_power_ctrl_gpio {
-   int gpio;
-   int active_low;
+   struct gpio_desc *gpiod;
 
struct list_head list;
 };
@@ -1018,7 +1017,7 @@ static void atmel_lcdfb_power_control_gpio(struct 
atmel_lcdfb_pdata *pdata, int
struct atmel_lcdfb_power_ctrl_gpio *og;
 
list_for_each_entry(og, >pwr_gpios, list)
-   gpio_set_value(og->gpio, on);
+   gpiod_set_value(og->gpiod, on);
 }
 
 static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
@@ -1031,11 +1030,11 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
struct device_node *display_np;
struct device_node *timings_np;
struct display_timings *timings;
-   enum of_gpio_flags flags;
struct atmel_lcdfb_power_ctrl_gpio *og;
bool is_gpio_power = false;
+   struct gpio_desc *gpiod;
int ret = -ENOENT;
-   int i, gpio;
+   int i;
 
sinfo->config = (struct atmel_lcdfb_config*)
of_match_device(atmel_lcdfb_dt_ids, dev)->data;
@@ -1072,28 +1071,22 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
 
INIT_LIST_HEAD(>pwr_gpios);
ret = -ENOMEM;
-   for (i = 0; i < of_gpio_named_count(display_np, 
"atmel,power-control-gpio"); i++) {
-   gpio = of_get_named_gpio_flags(display_np, 
"atmel,power-control-gpio",
-  i, );
-   if (gpio < 0)
+   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
+   gpiod = devm_gpiod_get_index(dev, "atmel,power-control",
+i, GPIOD_ASIS);
+   if (IS_ERR(gpiod))
continue;
 
og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
if (!og)
goto put_display_node;
 
-   og->gpio = gpio;
-   og->active_low = flags & OF_GPIO_ACTIVE_LOW;
+   og->gpiod = gpiod;
is_gpio_power = true;
-   ret = devm_gpio_request(dev, gpio, "lcd-power-control-gpio");
-   if (ret) {
-   dev_err(dev, "request gpio %d failed\n", gpio);
-   goto put_display_node;
-   }
 
-   ret = gpio_direction_output(gpio, og->active_low);
+   ret = gpiod_direction_output(gpiod, gpiod_is_active_low(gpiod));
if (ret) {
-   dev_err(dev, "set direction output gpio %d failed\n", 
gpio);
+   dev_err(dev, "set direction output gpio 
atmel,power-control[%d] failed\n", i);
goto put_display_node;
}
list_add(>list, >pwr_gpios);
-- 
2.12.2

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

[Bug 104963] MSI MoBo A88XM-E35 GPU Trinity A8-5600K (Aruba HD7560D) Boot loop without radeon.dpm=0

[bugzilla-daemon]

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

Bug ID: 104963
   Summary: MSI MoBo A88XM-E35 GPU Trinity A8-5600K (Aruba
HD7560D) Boot loop without radeon.dpm=0
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: f0r...@free.fr

Hi
I was driven here by Ubuntu team :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1746357

Only nomodeset and radeon.dpm=0 allow boot. Issue is here from kernel 3.13 to
4.15.1

-- 
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] drm/bridge/synopsys: dsi: Add read feature

[Brian Norris]

Hi,

On Sun, Feb 04, 2018 at 10:31:04PM +0100, Philippe Cornu wrote:
> This patch adds the DCS/GENERIC DSI read feature.
> 
> Signed-off-by: Philippe Cornu 
> ---
> Extra notes:
> DSI read tests have been performed with DCS & GENERIC, short & long
> commands, on two different panels.
> The maximum fifo size (32*32-bit = 128 bytes on stm32) has been
> verified too.

Seems OK to me, just comparing with work we've been borrowing from
Rockchip:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/863347

(And in fact, it looks much better than that.)

So FWIW:

Reviewed-by: Brian Norris 

and thanks a bunch!

Brian

>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 58 
> +--
>  1 file changed, 45 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index e9422d05e897..65aeb3f78b48 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -397,18 +397,46 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
>   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, le32_to_cpu(word));
>  }
>  
> +static int dw_mipi_dsi_read(struct dw_mipi_dsi *dsi,
> + const struct mipi_dsi_msg *msg)
> +{
> + int i, j, ret, len = msg->rx_len;
> + u8 *buf = msg->rx_buf;
> + u32 val;
> +
> + /* Wait end of the read operation */
> + ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
> +  val, !(val & GEN_RD_CMD_BUSY),
> +  1000, CMD_PKT_STATUS_TIMEOUT_US);
> + if (ret) {
> + dev_err(dsi->dev, "Timeout during read operation\n");
> + return ret;
> + }
> +
> + for (i = 0; i < len; i += 4) {
> + /* Read fifo must not be empty before all bytes are read */
> + ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
> +  val, !(val & GEN_PLD_R_EMPTY),
> +  1000, CMD_PKT_STATUS_TIMEOUT_US);
> + if (ret) {
> + dev_err(dsi->dev, "Read payload FIFO is empty\n");
> + return ret;
> + }
> +
> + val = dsi_read(dsi, DSI_GEN_PLD_DATA);
> + for (j = 0; j < 4 && j + i < len; j++)
> + buf[i + j] = val >> (8 * j);
> + }
> +
> + return ret;
> +}
> +
>  static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
>const struct mipi_dsi_msg *msg)
>  {
>   struct dw_mipi_dsi *dsi = host_to_dsi(host);
>   struct mipi_dsi_packet packet;
> - int ret;
> -
> - if (msg->rx_buf || msg->rx_len) {
> - /* TODO dw drv improvements: implement read feature */
> - dev_warn(dsi->dev, "read operations not yet implemented\n");
> - return -EINVAL;
> - }
> + int ret, nb_bytes;
>  
>   ret = mipi_dsi_create_packet(, msg);
>   if (ret) {
> @@ -422,12 +450,16 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
> mipi_dsi_host *host,
>   if (ret)
>   return ret;
>  
> - /*
> -  * TODO Only transmitted size is returned as actual driver does
> -  * not support dcs/generic reads. Please update return value when
> -  * delivering the read feature.
> -  */
> - return packet.size;
> + if (msg->rx_buf && msg->rx_len) {
> + ret = dw_mipi_dsi_read(dsi, msg);
> + if (ret)
> + return ret;
> + nb_bytes = msg->rx_len;
> + } else {
> + nb_bytes = packet.size;
> + }
> +
> + return nb_bytes;
>  }
>  
>  static const struct mipi_dsi_host_ops dw_mipi_dsi_host_ops = {
> -- 
> 2.15.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge/synopsys: dsi: Add 1.31 version support

[Brian Norris]

On Fri, Feb 02, 2018 at 10:19:15PM +, Philippe CORNU wrote:
> Hi Archit, Andrzej, Laurent & Brian,
> 
> What is your opinion regarding this patch? Do you have any advice for 
> handling hw versions?
> 
> Do not hesitate to comment.

I'll admit, I don't really have the bandwidth to handle this. I also
haven't looked into any version diffs to know the extent of changes
between HW versions.

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

Re: [Intel-gfx] Enabling i915 Panel Self Refresh by default on some devices ?

[Pandiyan, Dhinakaran]

On Thu, 2018-02-01 at 13:31 +0100, Hans de Goede wrote:
> Hi All,
> 
> As you may have heard I've recently been working on improving
> Linux laptop battery life, specifically the OOTB experience
> without tweaking any options such as e.g. powertop --auto-tune
> would do, see:
> 
> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
> 
> So far this is going quite nicely, it looks like Fedora 28
> will have SATA ALPM (big win), autosuspend of USB Bluetooth HCIs
> and snd_intel_hda powersaving all enabled OOTB.
> 
> Looking for more savings I've run some quick tests with
> i915.enable_psr=1, this seems to be another nice win (for an idle
> system) of aprox. 0.5W.
> 
> So as with the other 3 items I just mentioned I'm now looking into
> somehow enabling this be default, at least one some models.
> 
> Currently I'm thinking doing a whitelist or blacklist (*) for this,
> but first I think we need some more data about on how much models
> this just works and where it is causing issues, as such I've done
> a blog post to gather this data:
> 
> https://hansdegoede.livejournal.com/18653.html
> 
> So I will revisit this eventually, once people have had some time
> to respond to this blog-post.
> 
> In the mean time I wonder if anyone can explain why this options
> is currently disabled by default. E.g. are there any known specific
> models laptops / panels which are causing issues, are the bugzillas
> for this? Etc. ?
> 

I somehow missed reading your post.

There are few issues I know of:
1) frame counter reset that causes long vblank waits
2) fbcon screen freeze 
3) driver v/s HW aux channel usage needs to be serialized
4) occasional cursor lag
5) lack of IGT's to verify correctness

The first two have patches on the list, the third is being worked on.
The fourth needs investigation.


> Also does anyone know if any problems are mainly panel or laptop
> model specific ? I would expect this to mostly be panel specific
> and not depend on the model laptop (given then certain models
> ship with different panels over their production lifetime).

I am sure there are panel issues, but I haven't looked into them yet.
Like Rodrigo suggested, we probably have to rely on VBT for this and
enable PSR by default on only those panels.


> 
> Regards,
> 
> Hans
> 
> p.s.
> 
> If anyone on this list can make 10 minutes to run the tests
> described in my blogpost and gather the data mentioned there, then
> that would be great.
> 
> 
> *) I know that maintaining such a white/blacklist in the kernel
> is going to be a pain, so my current thinking on this is to make
> this runtime configurable through a sysfs attribute and then
> use a udev rule + udev hwdb entries for this.
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Rodrigo Vivi]

On Mon, Feb 05, 2018 at 11:54:04PM +, Andy Lutomirski wrote:
> 
> 
> > On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi  wrote:
> > 
> >> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
> >>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski  wrote:
>  On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
> > On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson  
> > wrote:
> > Quoting Andy Lutomirski (2018-02-01 21:04:30)
> >> I got this after a recent suspend/resume:
> >> 
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan 
> >> all dirs
> >> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
> >> scanning /sys/bus
> >> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
> >> scanning /sys/class
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open
> >> configuration file '/etc/systemd/sleep.conf': No such file or
> >> directory
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending...
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
> >> sender=n/a destination=n/a object=/org/freedesktop/login1
> >> interface=org.freedesktop.login1.Manager member=PrepareForSleep
> >> cookie=570 reply
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Got message
> >> type=method_call sender=:1.46 destination=:1.1
> >> object=/org/freedesktop/login1/session/_32
> >> interface=org.freedesktop.login1.Session member=ReleaseDevice
> >> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
> >> sender=n/a destination=:1.46
> >> object=/org/freedesktop/login1/session/_32
> >> interface=org.freedesktop.login1.Session member=PauseDevice cookie
> >> Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane
> >> transform 0: Permission denied
> >> Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed
> >> with (Permission denied), drawing cursor with OpenGL from now on
> >> 
> >> But I don't see the word "cursor" in my system logs before the first
> >> suspend.  What am I looking for?  This is Fedora 27 running a Gnome
> >> Wayland session, but it hasn't been reinstalled in some time, so it's
> >> possible that there are some weird settings sitting around.  But I did
> >> check and I have no weird i915 parameters.
> > 
> > You are using gnome-shell as the display server. From that it appears to
> > have started off with a HW cursor and switched to a SW cursor after
> > suspend. Did you notice a change in behaviour? After rebooting or just
> > restarting gnome-shell?
>  
>  I think it's less consistently bad after a reboot before suspending.
>  
> > 
> >> Also, are these things potentially related:
> >> 
> >> [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
> >> atomic update failure on pipe A
> > 
> > They are just "missed the immediate vblank for the screen update"
> > messages. Should not be related to PSR, but may cause jitter by delaying
> > the odd screen update.
>  
>  I just got this one, and the timestamp is at least reasonably close to
>  a giant latency spike:
>  
>  [  288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
>  update failure on pipe A (start=31 end=32) time 15 us, min 1073, max
>  1079, scanline start 1087, end 1088
>  
> > 
> >> As I'm typing this, I've seen a couple instances of what seems like a
> >> full *second* of cursor latency, but I've only gotten the potential
> >> atomic update failure once.
> >> 
> >> And is there any straightforward tracing to do to distinguish between
> >> PSR exit latency and other potential sources of latency?
> > 
> > It looks plausible that we could at least report how long it takes the
> > registers to reflect the change in state (but we don't). The best source
> > of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status.
>  
>  Hmm.
>  
>  I went and looked at the code, and I noticed what could be bugs or
>  could (more likely) be my confusion since I don't know this code at
>  all:
>  
>  intel_single_frame_update() does something inscrutable to me, but I
>  imagine it does something that causes the next page flip to get
>  noticed by the panel even with PSR on.  But how does the code that
>  calls it know that anything happened?  (Looking at the commit history,
>  maybe this is something special that's only needed on some platforms
>  but doesn't replace the normal PSR exit sequence.)
>  
>  Perhaps more interestingly, intel_psr_flush() does this:
>  
> /* By definition flush = 

Re: [PATCH 2/4] drm/exynos: fix comparison to bitshift when dealing with a mask

[Inki Dae]

2018년 02월 06일 05:09에 Wolfram Sang 이(가) 쓴 글:
> Due to a typo, the mask was destroyed by a comparison instead of a bit
> shift.
> 
> Signed-off-by: Wolfram Sang 
> ---
> Only build tested. To be applied individually per subsystem.
> 
>  drivers/gpu/drm/exynos/regs-fimc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/regs-fimc.h 
> b/drivers/gpu/drm/exynos/regs-fimc.h
> index 30496134a3d072..d7cbe53c4c01f4 100644
> --- a/drivers/gpu/drm/exynos/regs-fimc.h
> +++ b/drivers/gpu/drm/exynos/regs-fimc.h
> @@ -569,7 +569,7 @@
>  #define EXYNOS_CIIMGEFF_FIN_EMBOSSING(4 << 26)
>  #define EXYNOS_CIIMGEFF_FIN_SILHOUETTE   (5 << 26)
>  #define EXYNOS_CIIMGEFF_FIN_MASK (7 << 26)
> -#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK((0xff < 13) | (0xff < 
> 0))
> +#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK((0xff << 13) | (0xff 
> << 0))
>  

Oops. Picked it up.

Thanks,
Inki Dae

>  /* Real input DMA size register */
>  #define EXYNOS_CIREAL_ISIZE_AUTOLOAD_ENABLE  (1 << 31)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] [v2] drm/exynos: g2d: use monotonic timestamps

[Inki Dae]

2018년 01월 18일 02:01에 Arnd Bergmann 이(가) 쓴 글:
> The exynos DRM driver uses real-time 'struct timeval' values
> for exporting its timestamps to user space. This has multiple
> problems:
> 
> 1. signed seconds overflow in y2038
> 2. the 'struct timeval' definition is deprecated in the kernel
> 3. time may jump or go backwards after a 'settimeofday()' syscall
> 4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they
>can't be compared
> 5. exporting microseconds requires a division by 1000, which may
>be slow on some architectures.
> 
> The code existed in two places before, but the IPP portion was
> removed in 8ded59413ccc ("drm/exynos: ipp: Remove Exynos DRM
> IPP subsystem"), so we no longer need to worry about it.
> 
> Ideally timestamps should just use 64-bit nanoseconds instead, but
> of course we can't change that now. Instead, this tries to address
> the first four points above by using monotonic 'timespec' values.
> 
> According to Tobias Jakobi, user space doesn't care about the
> timestamp at the moment, so we can change the format. Even if
> there is something looking at them, it will work just fine with
> monotonic times as long as the application only looks at the
> relative values between two events.
> 
> Link: https://patchwork.kernel.org/patch/10038593/
> Cc: Tobias Jakobi 
> Signed-off-by: Arnd Bergmann 

Picked it up.

Thanks,
Inki Dae

> ---
> v2: rebased to what will be in 4.15, now that ipp is gone,
> updated changelog text based on input from Tobias.
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 2b8bf2dd6387..9effe40f5fa5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -926,7 +926,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   struct drm_device *drm_dev = g2d->subdrv.drm_dev;
>   struct g2d_runqueue_node *runqueue_node = g2d->runqueue_node;
>   struct drm_exynos_pending_g2d_event *e;
> - struct timeval now;
> + struct timespec64 now;
>  
>   if (list_empty(_node->event_list))
>   return;
> @@ -934,9 +934,9 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   e = list_first_entry(_node->event_list,
>struct drm_exynos_pending_g2d_event, base.link);
>  
> - do_gettimeofday();
> + ktime_get_ts64();
>   e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + e->event.tv_usec = now.tv_nsec / NSEC_PER_USEC;
>   e->event.cmdlist_no = cmdlist_no;
>  
>   drm_send_event(drm_dev, >base);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

> On Feb 5, 2018, at 2:50 PM, Rodrigo Vivi  wrote:
> 
>> On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
>>> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski  wrote:
 On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson  
> wrote:
> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>> I got this after a recent suspend/resume:
>> 
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
>> Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all 
>> dirs
>> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
>> scanning /sys/bus
>> Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
>> scanning /sys/class
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open
>> configuration file '/etc/systemd/sleep.conf': No such file or
>> directory
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending...
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
>> sender=n/a destination=n/a object=/org/freedesktop/login1
>> interface=org.freedesktop.login1.Manager member=PrepareForSleep
>> cookie=570 reply
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Got message
>> type=method_call sender=:1.46 destination=:1.1
>> object=/org/freedesktop/login1/session/_32
>> interface=org.freedesktop.login1.Session member=ReleaseDevice
>> Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
>> sender=n/a destination=:1.46
>> object=/org/freedesktop/login1/session/_32
>> interface=org.freedesktop.login1.Session member=PauseDevice cookie
>> Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane
>> transform 0: Permission denied
>> Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed
>> with (Permission denied), drawing cursor with OpenGL from now on
>> 
>> But I don't see the word "cursor" in my system logs before the first
>> suspend.  What am I looking for?  This is Fedora 27 running a Gnome
>> Wayland session, but it hasn't been reinstalled in some time, so it's
>> possible that there are some weird settings sitting around.  But I did
>> check and I have no weird i915 parameters.
> 
> You are using gnome-shell as the display server. From that it appears to
> have started off with a HW cursor and switched to a SW cursor after
> suspend. Did you notice a change in behaviour? After rebooting or just
> restarting gnome-shell?
 
 I think it's less consistently bad after a reboot before suspending.
 
> 
>> Also, are these things potentially related:
>> 
>> [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
>> atomic update failure on pipe A
> 
> They are just "missed the immediate vblank for the screen update"
> messages. Should not be related to PSR, but may cause jitter by delaying
> the odd screen update.
 
 I just got this one, and the timestamp is at least reasonably close to
 a giant latency spike:
 
 [  288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
 update failure on pipe A (start=31 end=32) time 15 us, min 1073, max
 1079, scanline start 1087, end 1088
 
> 
>> As I'm typing this, I've seen a couple instances of what seems like a
>> full *second* of cursor latency, but I've only gotten the potential
>> atomic update failure once.
>> 
>> And is there any straightforward tracing to do to distinguish between
>> PSR exit latency and other potential sources of latency?
> 
> It looks plausible that we could at least report how long it takes the
> registers to reflect the change in state (but we don't). The best source
> of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status.
 
 Hmm.
 
 I went and looked at the code, and I noticed what could be bugs or
 could (more likely) be my confusion since I don't know this code at
 all:
 
 intel_single_frame_update() does something inscrutable to me, but I
 imagine it does something that causes the next page flip to get
 noticed by the panel even with PSR on.  But how does the code that
 calls it know that anything happened?  (Looking at the commit history,
 maybe this is something special that's only needed on some platforms
 but doesn't replace the normal PSR exit sequence.)
 
 Perhaps more interestingly, intel_psr_flush() does this:
 
/* By definition flush = invalidate + flush */
if (frontbuffer_bits)
intel_psr_exit(dev_priv);
 
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
if (!work_busy(_priv->psr.work.work))

Re: [PATCH 0/1] drm/nouveau/disp: prefer identity-mapped route of SOR <-> macro link

[Ben Skeggs]

On Tue, Feb 6, 2018 at 9:35 AM, Danilo Krummrich
 wrote:
> Hi Ben,
>
> still _assuming_ it's an issue of the card I thought about why it
> works with the NVIDIA binary driver.
>
> And I can image they're just trying to do an identity-mapping first
> and if that doesn't work (e.g. the particular SOR is already in use
> by another macro link) they just pick the next suitable one.
>
> So the case would be that the NVIDIA binary driver always assignes
> the only working mapping (SOR-1 <-> macro link D) on a Gainward
> GTX 1070.
>
> Therefore, if this is the case, maybe it is better to change the
> routing strategy to prefer a SOR which maps the identity of the
> particular macro link over a random one instead of having my
> orignally proposed quirk.
Thanks for your work looking into this.  I'm still also investigating
to try and determine for sure if this isn't just working around some
other driver bug that we should fix instead, but your patches are
good, so if I don't discover anything, I'll take them.

I shall let you know when I know more :)

Thanks again,
Ben.

>
> So here's the patch doing exactly that.
>
> Regards,
> Danilo
>
> Danilo Krummrich (1):
>   drm/nouveau/disp: prefer identity-mapped route of SOR <-> macro link
>
>  drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c | 38 
> +
>  1 file changed, 26 insertions(+), 12 deletions(-)
>
> --
> 2.14.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Keith Packard]

Rodrigo Vivi  writes:

> I didn't checked the drm one close enough yet to decide for that.
> DK or Keith? do you guys see anyone suitable for fixes?

Yeah, we should probably get 1, 3 and 7 into fixes. 2, 4, 5 and 6 add
explicit casts where the compiler would already introduce equivalent
implicit casts.

-- 
-keith


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

[PATCH 0/1] drm/nouveau/disp: prefer identity-mapped route of SOR <-> macro link

[Danilo Krummrich]

Hi Ben,

still _assuming_ it's an issue of the card I thought about why it
works with the NVIDIA binary driver.

And I can image they're just trying to do an identity-mapping first
and if that doesn't work (e.g. the particular SOR is already in use
by another macro link) they just pick the next suitable one.

So the case would be that the NVIDIA binary driver always assignes
the only working mapping (SOR-1 <-> macro link D) on a Gainward
GTX 1070.

Therefore, if this is the case, maybe it is better to change the
routing strategy to prefer a SOR which maps the identity of the
particular macro link over a random one instead of having my
orignally proposed quirk.

So here's the patch doing exactly that.

Regards,
Danilo

Danilo Krummrich (1):
  drm/nouveau/disp: prefer identity-mapped route of SOR <-> macro link

 drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c | 38 +
 1 file changed, 26 insertions(+), 12 deletions(-)

-- 
2.14.1

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

[PATCH 1/1] drm/nouveau/disp: prefer identity-mapped route of SOR <-> macro link

[Danilo Krummrich]

With DCB 4.1 implemented by VBIOS since GM20x GPUs, SOR crossbar
routing should be possible, such that any SOR sublink can drive
any macro link. Therefore, if crossbar routing is available,
the first suitable SOR was picked.

Unfortunately, there's at least one card where some SORs being
being connected to a particular macro link not matching the identity
of each other are causing failures.

To fix this, when searching for a suitable SOR to be mapped to a
macro link prefer a SOR which maps the identity of the macro link.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c | 38 +
 1 file changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
index be9e7f8c3b23..b7af9349504e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
@@ -112,7 +112,7 @@ nvkm_outp_acquire_ior(struct nvkm_outp *outp, u8 user, 
struct nvkm_ior *ior)
 int
 nvkm_outp_acquire(struct nvkm_outp *outp, u8 user)
 {
-   struct nvkm_ior *ior = outp->ior;
+   struct nvkm_ior *_ior, *ior = outp->ior;
enum nvkm_ior_proto proto;
enum nvkm_ior_type type;
 
@@ -130,26 +130,40 @@ nvkm_outp_acquire(struct nvkm_outp *outp, u8 user)
/* First preference is to reuse the OR that is currently armed
 * on HW, if any, in order to prevent unnecessary switching.
 */
-   list_for_each_entry(ior, >disp->ior, head) {
-   if (!ior->asy.outp && ior->arm.outp == outp)
-   return nvkm_outp_acquire_ior(outp, user, ior);
+   list_for_each_entry(_ior, >disp->ior, head) {
+   if (!_ior->asy.outp && _ior->arm.outp == outp)
+   return nvkm_outp_acquire_ior(outp, user, _ior);
}
 
/* Failing that, a completely unused OR is the next best thing. */
-   list_for_each_entry(ior, >disp->ior, head) {
-   if (!ior->asy.outp && ior->type == type && !ior->arm.outp &&
-   (ior->func->route.set || ior->id == __ffs(outp->info.or)))
-   return nvkm_outp_acquire_ior(outp, user, ior);
+   ior = NULL;
+   list_for_each_entry(_ior, >disp->ior, head) {
+   if (!_ior->asy.outp && _ior->type == type && !_ior->arm.outp) {
+   /* Prefer identity-mapped route. */
+   if (_ior->id == __ffs(outp->info.or))
+   return nvkm_outp_acquire_ior(outp, user, _ior);
+   else if (!ior)
+   ior = _ior;
+   }
}
+   if (ior && ior->func->route.set)
+   return nvkm_outp_acquire_ior(outp, user, ior);
 
/* Last resort is to assign an OR that's already active on HW,
 * but will be released during the next modeset.
 */
-   list_for_each_entry(ior, >disp->ior, head) {
-   if (!ior->asy.outp && ior->type == type &&
-   (ior->func->route.set || ior->id == __ffs(outp->info.or)))
-   return nvkm_outp_acquire_ior(outp, user, ior);
+   ior = NULL;
+   list_for_each_entry(_ior, >disp->ior, head) {
+   if (!_ior->asy.outp && _ior->type == type) {
+   /* Again prefer identity-mapped route. */
+   if (_ior->id == __ffs(outp->info.or))
+   return nvkm_outp_acquire_ior(outp, user, _ior);
+   else if (!ior)
+   ior = _ior;
+   }
}
+   if (ior && ior->func->route.set)
+   return nvkm_outp_acquire_ior(outp, user, _ior);
 
return -ENOSPC;
 }
-- 
2.14.1

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

Re: Enabling i915 Panel Self Refresh by default on some devices ?

[Rodrigo Vivi]

Hi Hans,

On Fri, Feb 02, 2018 at 09:55:32AM +, Hans de Goede wrote:
> Hi,
> 
> On 01-02-18 13:31, Hans de Goede wrote:
> > Hi All,
> > 
> > As you may have heard I've recently been working on improving
> > Linux laptop battery life, specifically the OOTB experience
> > without tweaking any options such as e.g. powertop --auto-tune
> > would do, see:
> > 
> > https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife

First of all thank you very much for triggering that. It's been
so helpful.

Also sorry for not having replied sooner here.

> > 
> > So far this is going quite nicely, it looks like Fedora 28
> > will have SATA ALPM (big win), autosuspend of USB Bluetooth HCIs
> > and snd_intel_hda powersaving all enabled OOTB.
> > 
> > Looking for more savings I've run some quick tests with
> > i915.enable_psr=1, this seems to be another nice win (for an idle
> > system) of aprox. 0.5W.
> > 
> > So as with the other 3 items I just mentioned I'm now looking into
> > somehow enabling this be default, at least one some models.
> > 
> > Currently I'm thinking doing a whitelist or blacklist (*) for this,
> > but first I think we need some more data about on how much models
> > this just works and where it is causing issues, as such I've done
> > a blog post to gather this data:
> > 
> > https://hansdegoede.livejournal.com/18653.html
> > 
> > So I will revisit this eventually, once people have had some time
> > to respond to this blog-post.
> > 
> > In the mean time I wonder if anyone can explain why this options
> > is currently disabled by default. E.g. are there any known specific
> > models laptops / panels which are causing issues, are the bugzillas
> > for this? Etc. ?
> > 
> > Also does anyone know if any problems are mainly panel or laptop
> > model specific ? I would expect this to mostly be panel specific
> > and not depend on the model laptop (given then certain models
> > ship with different panels over their production lifetime).
> > 
> > Regards,
> > 
> > Hans
> > 
> > p.s.
> > 
> > If anyone on this list can make 10 minutes to run the tests
> > described in my blogpost and gather the data mentioned there, then
> > that would be great.
> > 
> > 
> > *) I know that maintaining such a white/blacklist in the kernel
> > is going to be a pain, so my current thinking on this is to make
> > this runtime configurable through a sysfs attribute and then
> > use a udev rule + udev hwdb entries for this.
> 
> So a quick update on this. The response has been quite overwhelming,
> with well over 50 test-reports received sofar. The results are all
> over the place, some people see no changes, some people report the
> aprox. 0.5W saving my own test show and many people also report
> display problems, sometimes combined with a significant increase in
> power-consumption.

Do you have that public somewhere? I couldn't see the comments on your blog
or on wiki.

> 
> I need to take a closer look at all the results, but right now I
> believe that the best way forward with this is (unfortunately) a
> whitelist matching on a combination of panel-id (from edid) and
> dmi data, so that we can at least enable this on popular models
> (any model with atleast one user willing to contribute).

First I'd like to check what platform people used on the test.

Also on SKL+ platforms I expect bad issues since 
https://patchwork.freedesktop.org/series/37598/
is not merged yet. Anyone using DC state plus this will probably
have a bad experience.

> 
> So intel-gfx-team folks any input from your side, any feedback
> on the plan to use a udev rule + udev hwdb entries to build a
> whitelist for this?

It would be interesting to collect the /sys/kernel/debug/dri/0/i915_vbt
Is it possible to get back to these people asking this?

There is one particular field on VBT that is the OEM
telling it is safe to enable PSR with windows on that particular laptop.

So far we are ignoring this, but I believe we should start respecting
that. Maybe with that we could avoid the white list.

I want to avoid at maximum any kind of white list because it would be hard
to maintain and hard to expand.
And at this point we have known issues and this possibility of
the vbt list. So let's investigate before adopting this strategy.

What do you think?

Thanks,
Rodrigo.

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

Re: i915 PSR test results and cursor lag

[Rodrigo Vivi]

On Thu, Feb 01, 2018 at 05:43:56PM +, Andy Lutomirski wrote:
> On Thu, Feb 1, 2018 at 9:40 AM, Andy Lutomirski  wrote:
> > Hi-
> >
> > As requested in your blog post, I tested PSR.  I see something like
> > 2.69W with PSR off and 2.17W with PSR on.  Screen blanking,
> > suspend/resume, and the contents of the screen all seem okay.  This is
> > a Dell XPS 13 9350, i.e.:
> >
> > System Information
> > Manufacturer: Dell Inc.
> > Product Name: XPS 13 9350
> >
> > EDID is attached.
> >
> > *However*, I do see one unfortunate side effect of turning on PSR.  It
> > seems that, when I move my cursor a little bit after a few seconds of
> > doing nothing, there seems to be a little bit of lag, as if either a
> > few frames are dropped at the beginning of the motion or maybe the
> > entire motion is delayed a bit.  I don't notice a similar delay when
> > typing, so I'm wondering if maybe there's a minor driver bug in which
> > the driver doesn't kick the panel out of PSR quite as quickly when the
> > cursor is updated as it does when the framebuffer is updated.
> >
> 
> I'm also getting occasional messages like:
> 
> [ 2675.574486] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
> atomic update failure on pipe A
> 
> with PSR on.  But there is nowhere near one of these messages per tiny
> lag incident.

That's indeed strange.
I believe that should also be part of PSR + DMC, so could you check if you
see this with psr enabled + dc state disabled?

I wonder if those I915_READ_FW are not waking DMC hence reading 0 in some
registers.

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

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Rodrigo Vivi]

On Sat, Feb 03, 2018 at 05:33:08PM +, Andy Lutomirski wrote:
> On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski  wrote:
> > On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
> >> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson  
> >> wrote:
> >>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
>  I got this after a recent suspend/resume:
> 
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
>  Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all 
>  dirs
>  Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
>  scanning /sys/bus
>  Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
>  scanning /sys/class
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open
>  configuration file '/etc/systemd/sleep.conf': No such file or
>  directory
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending...
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
>  sender=n/a destination=n/a object=/org/freedesktop/login1
>  interface=org.freedesktop.login1.Manager member=PrepareForSleep
>  cookie=570 reply
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Got message
>  type=method_call sender=:1.46 destination=:1.1
>  object=/org/freedesktop/login1/session/_32
>  interface=org.freedesktop.login1.Session member=ReleaseDevice
>  Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
>  sender=n/a destination=:1.46
>  object=/org/freedesktop/login1/session/_32
>  interface=org.freedesktop.login1.Session member=PauseDevice cookie
>  Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane
>  transform 0: Permission denied
>  Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed
>  with (Permission denied), drawing cursor with OpenGL from now on
> 
>  But I don't see the word "cursor" in my system logs before the first
>  suspend.  What am I looking for?  This is Fedora 27 running a Gnome
>  Wayland session, but it hasn't been reinstalled in some time, so it's
>  possible that there are some weird settings sitting around.  But I did
>  check and I have no weird i915 parameters.
> >>>
> >>> You are using gnome-shell as the display server. From that it appears to
> >>> have started off with a HW cursor and switched to a SW cursor after
> >>> suspend. Did you notice a change in behaviour? After rebooting or just
> >>> restarting gnome-shell?
> >>
> >> I think it's less consistently bad after a reboot before suspending.
> >>
> >>>
>  Also, are these things potentially related:
> 
>  [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
>  atomic update failure on pipe A
> >>>
> >>> They are just "missed the immediate vblank for the screen update"
> >>> messages. Should not be related to PSR, but may cause jitter by delaying
> >>> the odd screen update.
> >>
> >> I just got this one, and the timestamp is at least reasonably close to
> >> a giant latency spike:
> >>
> >> [  288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
> >> update failure on pipe A (start=31 end=32) time 15 us, min 1073, max
> >> 1079, scanline start 1087, end 1088
> >>
> >>>
>  As I'm typing this, I've seen a couple instances of what seems like a
>  full *second* of cursor latency, but I've only gotten the potential
>  atomic update failure once.
> 
>  And is there any straightforward tracing to do to distinguish between
>  PSR exit latency and other potential sources of latency?
> >>>
> >>> It looks plausible that we could at least report how long it takes the
> >>> registers to reflect the change in state (but we don't). The best source
> >>> of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status.
> >>
> >> Hmm.
> >>
> >> I went and looked at the code, and I noticed what could be bugs or
> >> could (more likely) be my confusion since I don't know this code at
> >> all:
> >>
> >> intel_single_frame_update() does something inscrutable to me, but I
> >> imagine it does something that causes the next page flip to get
> >> noticed by the panel even with PSR on.  But how does the code that
> >> calls it know that anything happened?  (Looking at the commit history,
> >> maybe this is something special that's only needed on some platforms
> >> but doesn't replace the normal PSR exit sequence.)
> >>
> >> Perhaps more interestingly, intel_psr_flush() does this:
> >>
> >> /* By definition flush = invalidate + flush */
> >> if (frontbuffer_bits)
> >> intel_psr_exit(dev_priv);
> >>
> >> if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> >> if (!work_busy(_priv->psr.work.work))
> >> schedule_delayed_work(_priv->psr.work,
> >>   msecs_to_jiffies(100));
> >>
> >> I'm guessing that the idea is 

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Rodrigo Vivi]

On Mon, Feb 05, 2018 at 08:35:25PM +, Andy Lutomirski wrote:

Andy, first of all thank you very much for those findings.

> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
>  wrote:
> >
> >
> >
> > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
> >> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
> >> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
> >> >  wrote:
> >> >>
> >> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
> >> >>> I updated to 4.15, and the situation is much worse.  With
> >> >>> enable_psr=1, the system survives for several seconds and then the
> >> >>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
> >> >>> get to the Fedora login screen and then the system dies.  If I set
> >> >>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
> >> >>> seems like it also sometimes hangs even worse a bit after the screen
> >> >>> stops updating, but it's hard to tell.
> >> >>
> >> >> The login screen freeze sounds like what I have. Does this system have
> >> >> DMC firmware? If yes, can you try this series
> >> >> https://patchwork.freedesktop.org/series/37598/. You'll only need
> >> >> patches 1,8,9 and 10.
> >> >
> >> > That fixes the hang.  Feel free to add:
> >> >
> >> > Tested-by: Andy Lutomirski 
> >> >
> >> > to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
> >> > kernels?
> >>
> >> Correction: I'm still getting a second or two of complete screen
> >> freezing every now and then.  The kernel says:
> > Thanks a lot for testing. How do you trigger this freeze? Moving the
> > cursor? Did you apply these patches on top of drm-tip or was it
> > mainline?
> >
> > I also have another patch here that addresses screen freezes in console
> > mode with PSR - https://patchwork.freedesktop.org/patch/201144/ in case
> > that is what you are interested in.
> >>
> >> [69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
> >> update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
> >> 1079, scanline start 1068, end 1082
> >>
> >> So something might still be a bit buggy.
> >
> > This series fixes only the long freezes due to frame counter resets, I
> > am sure there are still other issues with PSR.
> >
> > BTW does your patch on top of these patches help with the cursor lag?

Andy, what happens if you keep psr enabled but disable dc state 
(i915.enable_dc=0).
Do you still see cursor lag in this case?

> 
> Maybe, but I'm not 100% sure.  I'm not currently seeing the lag with
> or without the patch.  I also think my distro fixed the cursor in the
> mean time so that it uses the HW cursor even after suspend/resume.
> 
> A couple of questions, though:
> 
> 1. Does moving the HW cursor cause the hardware to automatically turn off PSR?
> 
> 2 When something enables vblank interrupts (using drm_*_vblank_get(),
> for example), are vblank interrupts generated even if PSR is on?  And
> is the scanline, as returned by intel_get_crtc_scanline(), updated?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Rodrigo Vivi]

On Thu, Feb 01, 2018 at 08:33:29PM +, Chris Wilson wrote:
> Quoting Kristian Høgsberg (2018-02-01 20:22:40)
> > On Thu, Feb 1, 2018 at 9:53 AM Chris Wilson 
> > wrote:
> > 
> > > Quoting Andy Lutomirski (2018-02-01 17:40:22)
> > > > *However*, I do see one unfortunate side effect of turning on PSR.  It
> > > > seems that, when I move my cursor a little bit after a few seconds of
> > > > doing nothing, there seems to be a little bit of lag, as if either a
> > > > few frames are dropped at the beginning of the motion or maybe the
> > > > entire motion is delayed a bit.  I don't notice a similar delay when
> > > > typing, so I'm wondering if maybe there's a min
> > > or driver bug in which
> > > > the driver doesn't kick the panel out of PSR quite as quickly when the
> > > > cursor is updated as it does when the framebuffer is updated.
> > 
> > > One thing that's important know regarding the cursor is whether the
> > > display server is using a HW cursor or SW cursor. Could you please attach
> > > the log from the display server (or if you are using a stock
> > > distribution that's probably enough to work out what it is using)?
> > > -Chris
> > 
> > We had a similar problem for Rockchip in ChromeOS and ended up using an
> > input handler to let us start the PSR exit as early as possible:
> 
> Reminds me of mutter devs suggesting that we may like to kick the gpu to
> max clocks high frequency on any input activity as well. (I'm still not
> convinced that's a good idea, for mundane typing we barely need to wake
> up the gpu. :) I guess it all depends on expected wakeup latencies, but
> I didn't think PSR had multi-frame lag?

yeap. This shouldn't be needed for PSR. The wakeup latency is definitely
not a problem here.
All the current PSR related corner cases and limitations are probably
still related to *what* cases to exit PSR rather than *when*.

So I'd say the governor there is probably covering few of missing cases.

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

[PATCH] drm/i915: Improve PSR activation timing

[Andy Lutomirski]

The current PSR code has a two call sites that each schedule delayed
work to activate PSR.  As far as I can tell, each call site intends
to keep PSR inactive for the given amount of time and then allow it
to be activated.

The call sites are:

 - intel_psr_enable(), which explicitly states in a comment that
   it's trying to keep PSR off a short time after the dispay is
   initialized as a workaround.

 - intel_psr_flush().  There isn't an explcit explanation, but the
   intent is presumably to keep PSR off until the display has been
   idle for 100ms.

The current code doesn't actually accomplish either of these goals.
Rather than keeping PSR inactive for the given amount of time, it
will schedule PSR for activation after the given time, with the
earliest target time in such a request winning.

In other words, if intel_psr_enable() is immediately followed by
intel_psr_flush(), then PSR will be activated after 100ms even if
intel_psr_enable() wanted a longer delay.  And, if the screen is
being constantly updated so that intel_psr_flush() is called once
per frame at 60Hz, PSR will still be activated once every 100ms.

Rewrite the code so that it does what was intended.  This adds
a new function intel_psr_schedule(), which will enable PSR after
the requested time but no sooner.

Signed-off-by: Andy Lutomirski 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  9 +++--
 drivers/gpu/drm/i915/i915_drv.h |  4 ++-
 drivers/gpu/drm/i915/intel_psr.c| 69 -
 3 files changed, 71 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381b85f3..b67db93f905d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2663,8 +2663,13 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
   dev_priv->psr.busy_frontbuffer_bits);
-   seq_printf(m, "Re-enable work scheduled: %s\n",
-  yesno(work_busy(_priv->psr.work.work)));
+
+   if (timer_pending(_priv->psr.activate_timer))
+   seq_printf(m, "Activate scheduled: yes, in %ldms\n",
+  (long)(dev_priv->psr.earliest_activate - jiffies) *
+  1000 / HZ);
+   else
+   seq_printf(m, "Re-enable scheduled: no\n");
 
if (HAS_DDI(dev_priv)) {
if (dev_priv->psr.psr2_support)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 46eb729b367d..c0fb7d65cda6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1192,7 +1192,9 @@ struct i915_psr {
bool source_ok;
struct intel_dp *enabled;
bool active;
-   struct delayed_work work;
+   struct timer_list activate_timer;
+   struct work_struct activate_work;
+   unsigned long earliest_activate;
unsigned busy_frontbuffer_bits;
bool psr2_support;
bool aux_frame_sync;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 55ea5eb3b7df..333d90d4e5af 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -461,6 +461,30 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
dev_priv->psr.active = true;
 }
 
+static void intel_psr_schedule(struct drm_i915_private *dev_priv,
+  unsigned long min_wait_ms)
+{
+   unsigned long next;
+
+   lockdep_assert_held(_priv->psr.lock);
+
+   /*
+* We update next_enable *and* call mod_timer() because it's
+* possible that intel_psr_work() has already been called and is
+* waiting for psr.lock.  If that's the case, we don't want it
+* to immediately enable PSR.
+*
+* We also need to make sure that PSR is never activated earlier
+* than requested to avoid breaking intel_psr_enable()'s workaround
+* for pre-gen9 hardware.
+*/
+   next = jiffies + msecs_to_jiffies(min_wait_ms);
+   if (time_after(next, dev_priv->psr.earliest_activate)) {
+   dev_priv->psr.earliest_activate = next;
+   mod_timer(_priv->psr.activate_timer, next);
+   }
+}
+
 static void hsw_psr_enable_source(struct intel_dp *intel_dp,
  const struct intel_crtc_state *crtc_state)
 {
@@ -544,8 +568,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
 * - On HSW/BDW we get a recoverable frozen screen until
 *   next exit-activate sequence.
 */
-   schedule_delayed_work(_priv->psr.work,
- 
msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
+   intel_psr_schedule(dev_priv, intel_dp->panel_power_cycle_delay 
* 5);
}

[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198669

--- Comment #4 from ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk) 
---
Well it moved the problem. It crashed somewhere else in the driver with some
message about scratch. Sorry I cannot tell you what is was because I screwed up
the save of the the kernel message buffer, and now I cannot get the thing to
glitch again. My normal method of stamping on the floor next to the system is
not working. I think I might have overdone it and now the thing has bedded in.
Going to leave it powered off overnight and try again in the morning.

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

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

On Mon, Feb 5, 2018 at 9:17 PM, Pandiyan, Dhinakaran
 wrote:
>
> On Mon, 2018-02-05 at 20:35 +, Andy Lutomirski wrote:
>> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
>>  wrote:
>> >
>> >
>> >
>> > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
>> >> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
>> >> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
>> >> >  wrote:
>> >> >>
>> >> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
>> >> >>> I updated to 4.15, and the situation is much worse.  With
>> >> >>> enable_psr=1, the system survives for several seconds and then the
>> >> >>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
>> >> >>> get to the Fedora login screen and then the system dies.  If I set
>> >> >>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
>> >> >>> seems like it also sometimes hangs even worse a bit after the screen
>> >> >>> stops updating, but it's hard to tell.
>> >> >>
>> >> >> The login screen freeze sounds like what I have. Does this system have
>> >> >> DMC firmware? If yes, can you try this series
>> >> >> https://patchwork.freedesktop.org/series/37598/. You'll only need
>> >> >> patches 1,8,9 and 10.
>> >> >
>> >> > That fixes the hang.  Feel free to add:
>> >> >
>> >> > Tested-by: Andy Lutomirski 
>> >> >
>> >> > to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
>> >> > kernels?
>> >>
>> >> Correction: I'm still getting a second or two of complete screen
>> >> freezing every now and then.  The kernel says:
>> > Thanks a lot for testing. How do you trigger this freeze? Moving the
>> > cursor? Did you apply these patches on top of drm-tip or was it
>> > mainline?
>> >
>> > I also have another patch here that addresses screen freezes in console
>> > mode with PSR - https://patchwork.freedesktop.org/patch/201144/ in case
>> > that is what you are interested in.
>> >>
>> >> [69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
>> >> update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
>> >> 1079, scanline start 1068, end 1082
>> >>
>> >> So something might still be a bit buggy.
>> >
>> > This series fixes only the long freezes due to frame counter resets, I
>> > am sure there are still other issues with PSR.
>> >
>> > BTW does your patch on top of these patches help with the cursor lag?
>>
>> Maybe, but I'm not 100% sure.  I'm not currently seeing the lag with
>> or without the patch.  I also think my distro fixed the cursor in the
>> mean time so that it uses the HW cursor even after suspend/resume.
>>
>> A couple of questions, though:
>>
>> 1. Does moving the HW cursor cause the hardware to automatically turn off 
>> PSR?
>>
> That is correct.
>
>> 2 When something enables vblank interrupts (using drm_*_vblank_get(),
>> for example), are vblank interrupts generated even if PSR is on?
>
> Enabling vblank interrupts deactivates PSR (except on Braswell afaik)
>
>>   And
>> is the scanline, as returned by intel_get_crtc_scanline(), updated?
>
> I don't think so, I have not really checked but there are no frames
> generated, so the timing related registers will not get updated. This is
> the case with the frame counter register.
>

I bet that's the cause of some of the glitches I'm seeing.  I
instrumented intel_pipe_update_start() like this:

diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 4a8a5d918a83..6ce0a35187fb 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -97,6 +97,7 @@ void intel_pipe_update_start(const struct
intel_crtc_state *new_crtc_state)
 bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) ||
IS_CHERRYVIEW(dev_priv)) &&
 intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI);
 DEFINE_WAIT(wait);
+int first_scanline = -1;

 vblank_start = adjusted_mode->crtc_vblank_start;
 if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
@@ -131,9 +132,12 @@ void intel_pipe_update_start(const struct
intel_crtc_state *new_crtc_state)
 if (scanline < min || scanline > max)
 break;

+if (first_scanline == -1)
+first_scanline = scanline;
+
 if (timeout <= 0) {
-DRM_ERROR("Potential atomic update failure on pipe %c\n",
-  pipe_name(crtc->pipe));
+DRM_ERROR("Potential atomic update failure on pipe %c.
scanline=%d, first_scanline=%d\n",
+  pipe_name(crtc->pipe), scanline, first_scanline);
 break;
 }

and I got:

[drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update
failure on pipe A.  scanline=1079, first_scanline=1079

so it looks like it can get stuck if called at the wrong time.

Anyway, I'll send my patch.  I'm not convinced it fixes any of the
glitches I'm seeing, but I 

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Pandiyan, Dhinakaran]

On Mon, 2018-02-05 at 20:35 +, Andy Lutomirski wrote:
> On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
>  wrote:
> >
> >
> >
> > On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
> >> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
> >> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
> >> >  wrote:
> >> >>
> >> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
> >> >>> I updated to 4.15, and the situation is much worse.  With
> >> >>> enable_psr=1, the system survives for several seconds and then the
> >> >>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
> >> >>> get to the Fedora login screen and then the system dies.  If I set
> >> >>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
> >> >>> seems like it also sometimes hangs even worse a bit after the screen
> >> >>> stops updating, but it's hard to tell.
> >> >>
> >> >> The login screen freeze sounds like what I have. Does this system have
> >> >> DMC firmware? If yes, can you try this series
> >> >> https://patchwork.freedesktop.org/series/37598/. You'll only need
> >> >> patches 1,8,9 and 10.
> >> >
> >> > That fixes the hang.  Feel free to add:
> >> >
> >> > Tested-by: Andy Lutomirski 
> >> >
> >> > to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
> >> > kernels?
> >>
> >> Correction: I'm still getting a second or two of complete screen
> >> freezing every now and then.  The kernel says:
> > Thanks a lot for testing. How do you trigger this freeze? Moving the
> > cursor? Did you apply these patches on top of drm-tip or was it
> > mainline?
> >
> > I also have another patch here that addresses screen freezes in console
> > mode with PSR - https://patchwork.freedesktop.org/patch/201144/ in case
> > that is what you are interested in.
> >>
> >> [69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
> >> update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
> >> 1079, scanline start 1068, end 1082
> >>
> >> So something might still be a bit buggy.
> >
> > This series fixes only the long freezes due to frame counter resets, I
> > am sure there are still other issues with PSR.
> >
> > BTW does your patch on top of these patches help with the cursor lag?
> 
> Maybe, but I'm not 100% sure.  I'm not currently seeing the lag with
> or without the patch.  I also think my distro fixed the cursor in the
> mean time so that it uses the HW cursor even after suspend/resume.
> 
> A couple of questions, though:
> 
> 1. Does moving the HW cursor cause the hardware to automatically turn off PSR?
> 
That is correct.

> 2 When something enables vblank interrupts (using drm_*_vblank_get(),
> for example), are vblank interrupts generated even if PSR is on?

Enabling vblank interrupts deactivates PSR (except on Braswell afaik)

>   And
> is the scanline, as returned by intel_get_crtc_scanline(), updated?

I don't think so, I have not really checked but there are no frames
generated, so the timing related registers will not get updated. This is
the case with the frame counter register.


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

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Pandiyan, Dhinakaran]

On Mon, 2018-02-05 at 12:49 -0800, Rodrigo Vivi wrote:
> On Mon, Feb 05, 2018 at 08:37:13PM +, Dave Airlie wrote:
> > On 6 February 2018 at 06:32, Rodrigo Vivi  wrote:
> > > On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> > >> Dhinakaran Pandiyan  writes:
> > >>
> > >> > From: "Pandiyan, Dhinakaran" 
> > >> >
> > >> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank 
> > >> > count.
> > >> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the 
> > >> > user
> > >> > space requested vblank sequence using this clipped 32-bit count(when 
> > >> > the
> > >> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
> > >> > value and gets queued like that. However, the code that checks if the
> > >> > requested sequence has passed compares this against the 64-bit vblank
> > >> > count.
> > >>
> > >> For patches 1-7:
> > >>
> > >> Reviewed-by: Keith Packard 
> > >
> > > Dave, ack to merge them through drm-intel-next-queued ?
> > 
> > Ack. do we know if any of those need to be in -fixes?
> > 
> > or too early to tell?
> 
> I didn't checked the drm one close enough yet to decide for that.
> DK or Keith? do you guys see anyone suitable for fixes?

I was thinking patch 1 would be a candidate. But, it'd need the crtc to
be active continuously for > 2.2 years at 60 frames/s to trigger this.
The problem is exacerbated with PSR and PSR is disabled. So, I think we
can skip -fixes.

> 
> For the other work on top I believe we don't need to move to fixes
> since psr is still disabled.
> 
> > 
> > Dave.
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Rodrigo Vivi]

On Mon, Feb 05, 2018 at 08:37:13PM +, Dave Airlie wrote:
> On 6 February 2018 at 06:32, Rodrigo Vivi  wrote:
> > On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> >> Dhinakaran Pandiyan  writes:
> >>
> >> > From: "Pandiyan, Dhinakaran" 
> >> >
> >> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank 
> >> > count.
> >> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the 
> >> > user
> >> > space requested vblank sequence using this clipped 32-bit count(when the
> >> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
> >> > value and gets queued like that. However, the code that checks if the
> >> > requested sequence has passed compares this against the 64-bit vblank
> >> > count.
> >>
> >> For patches 1-7:
> >>
> >> Reviewed-by: Keith Packard 
> >
> > Dave, ack to merge them through drm-intel-next-queued ?
> 
> Ack. do we know if any of those need to be in -fixes?
> 
> or too early to tell?

I didn't checked the drm one close enough yet to decide for that.
DK or Keith? do you guys see anyone suitable for fixes?

For the other work on top I believe we don't need to move to fixes
since psr is still disabled.

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

Re: [PATCH v2 2/2] drm/i915/cmdparser: Do not check past the cmd length.

[Chris Wilson]

Quoting Chris Wilson (2018-02-05 16:04:25)
> Quoting Michal Srb (2018-02-05 15:17:45)
> > The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
> > possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
> > In that case check_cmd will read bits from the following command, or even 
> > past
> > the end of the buffer.
> > 
> > If the offset ends up outside of the command length, reject the command.
> > 
> > Signed-off-by: Michal Srb 
> 
> Looks good, both
> Reviewed-by: Chris Wilson 
> 
> I'll resend them to intel-gfx@ so CI picks them up for the checklist.

Added

Fixes: 76ff480ec963 ("drm/i915/cmdparser: Use binary search for faster
register lookup"

and

Fixes: 351e3db2b363 ("drm/i915: Implement command buffer parsing logic")

respectively and pushed. Thanks for the patches,
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Dave Airlie]

On 6 February 2018 at 06:32, Rodrigo Vivi  wrote:
> On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
>> Dhinakaran Pandiyan  writes:
>>
>> > From: "Pandiyan, Dhinakaran" 
>> >
>> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
>> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
>> > space requested vblank sequence using this clipped 32-bit count(when the
>> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
>> > value and gets queued like that. However, the code that checks if the
>> > requested sequence has passed compares this against the 64-bit vblank
>> > count.
>>
>> For patches 1-7:
>>
>> Reviewed-by: Keith Packard 
>
> Dave, ack to merge them through drm-intel-next-queued ?

Ack. do we know if any of those need to be in -fixes?

or too early to tell?

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

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

On Mon, Feb 5, 2018 at 6:53 PM, Pandiyan, Dhinakaran
 wrote:
>
>
>
> On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
>> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
>> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
>> >  wrote:
>> >>
>> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
>> >>> I updated to 4.15, and the situation is much worse.  With
>> >>> enable_psr=1, the system survives for several seconds and then the
>> >>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
>> >>> get to the Fedora login screen and then the system dies.  If I set
>> >>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
>> >>> seems like it also sometimes hangs even worse a bit after the screen
>> >>> stops updating, but it's hard to tell.
>> >>
>> >> The login screen freeze sounds like what I have. Does this system have
>> >> DMC firmware? If yes, can you try this series
>> >> https://patchwork.freedesktop.org/series/37598/. You'll only need
>> >> patches 1,8,9 and 10.
>> >
>> > That fixes the hang.  Feel free to add:
>> >
>> > Tested-by: Andy Lutomirski 
>> >
>> > to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
>> > kernels?
>>
>> Correction: I'm still getting a second or two of complete screen
>> freezing every now and then.  The kernel says:
> Thanks a lot for testing. How do you trigger this freeze? Moving the
> cursor? Did you apply these patches on top of drm-tip or was it
> mainline?
>
> I also have another patch here that addresses screen freezes in console
> mode with PSR - https://patchwork.freedesktop.org/patch/201144/ in case
> that is what you are interested in.
>>
>> [69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
>> update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
>> 1079, scanline start 1068, end 1082
>>
>> So something might still be a bit buggy.
>
> This series fixes only the long freezes due to frame counter resets, I
> am sure there are still other issues with PSR.
>
> BTW does your patch on top of these patches help with the cursor lag?

Maybe, but I'm not 100% sure.  I'm not currently seeing the lag with
or without the patch.  I also think my distro fixed the cursor in the
mean time so that it uses the HW cursor even after suspend/resume.

A couple of questions, though:

1. Does moving the HW cursor cause the hardware to automatically turn off PSR?

2 When something enables vblank interrupts (using drm_*_vblank_get(),
for example), are vblank interrupts generated even if PSR is on?  And
is the scanline, as returned by intel_get_crtc_scanline(), updated?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Rodrigo Vivi]

On Sat, Feb 03, 2018 at 08:14:48AM +, Keith Packard wrote:
> Dhinakaran Pandiyan  writes:
> 
> > From: "Pandiyan, Dhinakaran" 
> >
> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> > space requested vblank sequence using this clipped 32-bit count(when the
> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
> > value and gets queued like that. However, the code that checks if the
> > requested sequence has passed compares this against the 64-bit vblank
> > count.
> 
> For patches 1-7:
> 
> Reviewed-by: Keith Packard 

Dave, ack to merge them through drm-intel-next-queued ?

Patches 8 to 10 are ready as well.

Thanks,
Rodrigo.

> 
> -- 
> -keith


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

[PATCH 15/17] drm/dp: Set channel coding on link configuration

[Thierry Reding]

From: Thierry Reding 

Make use of ANSI 8B/10B channel coding if the DisplayPort sink supports
it.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f1a7f18ab795..828dc091b015 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -526,7 +526,7 @@ EXPORT_SYMBOL(drm_dp_link_power_down);
  */
 int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link)
 {
-   u8 values[2];
+   u8 values[2], value = 0;
int err;
 
values[0] = drm_dp_link_rate_to_bw_code(link->rate);
@@ -539,6 +539,13 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
if (err < 0)
return err;
 
+   if (link->caps.channel_coding)
+   value = DP_SET_ANSI_8B10B;
+
+   err = drm_dp_dpcd_writeb(aux, DP_MAIN_LINK_CHANNEL_CODING_SET, value);
+   if (err < 0)
+   return err;
+
return 0;
 }
 EXPORT_SYMBOL(drm_dp_link_configure);
-- 
2.15.1

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

[PATCH 17/17] drm/dp: Add drm_dp_link_choose() helper

[Thierry Reding]

From: Thierry Reding 

This helper chooses an appropriate configuration, according to the
bitrate requirements of the video mode and the capabilities of the
DisplayPort sink.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 55 +
 include/drm/drm_dp_helper.h |  5 
 2 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index c8b18c0161d7..fb6ee3ebc37d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -557,6 +557,61 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
 }
 EXPORT_SYMBOL(drm_dp_link_configure);
 
+/**
+ * drm_dp_link_choose() - choose the lowest possible configuration for a mode
+ * @link: DRM DP link object
+ * @mode: DRM display mode
+ * @info: DRM display information
+ *
+ * According to the eDP specification, a source should select a configuration
+ * with the lowest number of lanes and the lowest possible link rate that can
+ * match the bitrate requirements of a video mode. However it must ensure not
+ * to exceed the capabilities of the sink.
+ *
+ * Returns: 0 on success or a negative error code on failure.
+ */
+int drm_dp_link_choose(struct drm_dp_link *link,
+  const struct drm_display_mode *mode,
+  const struct drm_display_info *info)
+{
+   /* available link symbol clock rates */
+   static const unsigned int rates[3] = { 162000, 27, 54 };
+   /* available number of lanes */
+   static const unsigned int lanes[3] = { 1, 2, 4 };
+   unsigned long requirement, capacity;
+   unsigned int rate = link->max_rate;
+   unsigned int i, j;
+
+   /* bandwidth requirement */
+   requirement = mode->clock * info->bpc * 3;
+
+   for (i = 0; i < ARRAY_SIZE(lanes) && lanes[i] <= link->max_lanes; i++) {
+   for (j = 0; j < ARRAY_SIZE(rates) && rates[j] <= rate; j++) {
+   /*
+* Capacity for this combination of lanes and rate,
+* factoring in the ANSI 8B/10B encoding.
+*
+* Link rates in the DRM DP helpers are really link
+* symbol frequencies, so a tenth of the actual rate
+* of the link.
+*/
+   capacity = lanes[i] * (rates[j] * 10) * 8 / 10;
+
+   if (capacity >= requirement) {
+   DRM_DEBUG_KMS("using %u lanes at %u kHz 
(%lu/%lu kbps)\n",
+ lanes[i], rates[j], requirement,
+ capacity);
+   link->lanes = lanes[i];
+   link->rate = rates[j];
+   return 0;
+   }
+   }
+   }
+
+   return -ERANGE;
+}
+EXPORT_SYMBOL(drm_dp_link_choose);
+
 /**
  * drm_dp_downstream_max_clock() - extract branch device max
  * pixel rate for legacy VGA
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 4c7badcde945..39d134f9a954 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+#include 
+
 /*
  * Unless otherwise noted, all values are from the DP 1.1a spec.  Note that
  * DP and DPCD versions are independent.  Differences from 1.0 are not noted,
@@ -1194,6 +1196,9 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link);
 int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
+int drm_dp_link_choose(struct drm_dp_link *link,
+  const struct drm_display_mode *mode,
+  const struct drm_display_info *info);
 int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4]);
 int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
-- 
2.15.1

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

[PATCH 16/17] drm/dp: Enable alternate scrambler reset when supported

[Thierry Reding]

From: Thierry Reding 

If the sink is eDP and supports the alternate scrambler reset, enable
it.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 828dc091b015..c8b18c0161d7 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -546,6 +546,13 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
if (err < 0)
return err;
 
+   if (link->caps.alternate_scrambler_reset) {
+   err = drm_dp_dpcd_writeb(aux, DP_EDP_CONFIGURATION_SET,
+DP_ALTERNATE_SCRAMBLER_RESET_ENABLE);
+   if (err < 0)
+   return err;
+   }
+
return 0;
 }
 EXPORT_SYMBOL(drm_dp_link_configure);
-- 
2.15.1

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

[PATCH 10/17] drm/dp: Read eDP version from DPCD

[Thierry Reding]

From: Thierry Reding 

If the sink supports eDP, read the eDP revision from it's DPCD.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 16 +++-
 include/drm/drm_dp_helper.h |  2 ++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 23429a53452d..c78cc62f149f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -361,6 +361,7 @@ static void drm_dp_link_reset(struct drm_dp_link *link)
link->max_lanes = 0;
 
drm_dp_link_caps_reset(>caps);
+   link->edp = 0;
 
link->rate = 0;
link->lanes = 0;
@@ -397,9 +398,22 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
link->caps.fast_training = drm_dp_fast_training_cap(values);
link->caps.channel_coding = drm_dp_channel_coding_supported(values);
 
-   if (drm_dp_alternate_scrambler_reset_cap(values))
+   if (drm_dp_alternate_scrambler_reset_cap(values)) {
+   static const u8 edp_revs[] = { 0x11, 0x12, 0x13, 0x14 };
+   u8 value;
+
link->caps.alternate_scrambler_reset = true;
 
+   err = drm_dp_dpcd_readb(aux, DP_EDP_DPCD_REV, );
+   if (err < 0)
+   return err;
+
+   if (value >= ARRAY_SIZE(edp_revs))
+   DRM_ERROR("unsupported eDP version: %02x\n", value);
+   else
+   link->edp = edp_revs[value];
+   }
+
link->rate = link->max_rate;
link->lanes = link->max_lanes;
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c52b6cf96a81..705c56ebe74d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1146,6 +1146,7 @@ void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
  * @max_rate: maximum clock rate supported on the link
  * @max_lanes: maximum number of lanes supported on the link
  * @caps: capabilities supported on the link (see _dp_link_caps)
+ * @edp: eDP revision (0x11: eDP 1.1, 0x12: eDP 1.2, ...)
  * @rate: currently configured link rate
  * @lanes: currently configured number of lanes
  */
@@ -1155,6 +1156,7 @@ struct drm_dp_link {
unsigned int max_lanes;
 
struct drm_dp_link_caps caps;
+   unsigned char edp;
 
unsigned int rate;
unsigned int lanes;
-- 
2.15.1

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

[PATCH 12/17] drm/dp: Do not busy-loop during link training

[Thierry Reding]

From: Thierry Reding 

Use microsecond sleeps for the clock recovery and channel equalization
delays during link training. The duration of these delays can be from
100 us up to 16 ms. It is rude to busy-loop for that amount of time.

While at it, also convert to standard coding style by putting the
opening braces in a function definition on a new line.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0d9d5360465c..0d9e66ea9667 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -118,19 +118,29 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 }
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
-void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
-   udelay(100);
+void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   unsigned int min;
+
+   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] != 0)
+   min = dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4000;
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   min = 100;
+
+   usleep_range(min, min * 2);
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
-void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
-   udelay(400);
+void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   unsigned int min;
+
+   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] != 0)
+   min = dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4000;
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   min = 400;
+
+   usleep_range(min, min * 2);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
-- 
2.15.1

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

[PATCH 14/17] drm/dp: Add helper to get post-cursor adjustments

[Thierry Reding]

From: Thierry Reding 

If the transmitter supports pre-emphasis post cursor2 the sink will
request adjustments in a similar way to how it requests adjustments to
the voltage swing and pre-emphasis settings.

Add a helper to extract these adjustments on a per-lane basis from the
DPCD link status.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 10 ++
 include/drm/drm_dp_helper.h | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index dabac772dfc3..f1a7f18ab795 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -118,6 +118,16 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 }
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
+u8 drm_dp_get_adjust_request_post_cursor(const u8 
link_status[DP_LINK_STATUS_SIZE],
+unsigned int lane)
+{
+   unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
+   u8 value = dp_link_status(link_status, offset);
+
+   return (value >> (lane << 1)) & 0x3;
+}
+EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
+
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
 {
unsigned int min = drm_dp_aux_rd_interval(dpcd);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8213f1c53f9b..4c7badcde945 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -512,6 +512,14 @@
 # define DP_ADJUST_PRE_EMPHASIS_LANE1_SHIFT  6
 
 #define DP_ADJUST_REQUEST_POST_CURSOR2  0x20c
+# define DP_ADJUST_POST_CURSOR2_LANE0_MASK  0x03
+# define DP_ADJUST_POST_CURSOR2_LANE0_SHIFT 0
+# define DP_ADJUST_POST_CURSOR2_LANE1_MASK  0x0c
+# define DP_ADJUST_POST_CURSOR2_LANE1_SHIFT 2
+# define DP_ADJUST_POST_CURSOR2_LANE2_MASK  0x30
+# define DP_ADJUST_POST_CURSOR2_LANE2_SHIFT 4
+# define DP_ADJUST_POST_CURSOR2_LANE3_MASK  0xc0
+# define DP_ADJUST_POST_CURSOR2_LANE3_SHIFT 6
 
 #define DP_TEST_REQUEST0x218
 # define DP_TEST_LINK_TRAINING (1 << 0)
@@ -892,6 +900,8 @@ u8 drm_dp_get_adjust_request_voltage(const u8 
link_status[DP_LINK_STATUS_SIZE],
 int lane);
 u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SIZE],
  int lane);
+u8 drm_dp_get_adjust_request_post_cursor(const u8 
link_status[DP_LINK_STATUS_SIZE],
+unsigned int lane);
 
 #define DP_BRANCH_OUI_HEADER_SIZE  0xc
 #define DP_RECEIVER_CAP_SIZE   0xf
-- 
2.15.1

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

[PATCH 09/17] drm/dp: Read alternate scrambler reset capability from sink

[Thierry Reding]

From: Thierry Reding 

Parse from the sink capabilities whether or not the eDP alternate
scrambler reset value of 0xfffe is supported.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 5 +
 include/drm/drm_dp_helper.h | 9 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 743343527bfa..23429a53452d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -337,6 +337,7 @@ static void drm_dp_link_caps_reset(struct drm_dp_link_caps 
*caps)
caps->tps3_supported = false;
caps->fast_training = false;
caps->channel_coding = false;
+   caps->alternate_scrambler_reset = false;
 }
 
 void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
@@ -346,6 +347,7 @@ void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
dest->tps3_supported = src->tps3_supported;
dest->fast_training = src->fast_training;
dest->channel_coding = src->channel_coding;
+   dest->alternate_scrambler_reset = src->alternate_scrambler_reset;
 }
 EXPORT_SYMBOL(drm_dp_link_caps_copy);
 
@@ -395,6 +397,9 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
link->caps.fast_training = drm_dp_fast_training_cap(values);
link->caps.channel_coding = drm_dp_channel_coding_supported(values);
 
+   if (drm_dp_alternate_scrambler_reset_cap(values))
+   link->caps.alternate_scrambler_reset = true;
+
link->rate = link->max_rate;
link->lanes = link->max_lanes;
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index fe7aef2c0736..c52b6cf96a81 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -990,6 +990,13 @@ drm_dp_channel_coding_supported(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_8B10B;
 }
 
+static inline bool
+drm_dp_alternate_scrambler_reset_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   return dpcd[DP_EDP_CONFIGURATION_CAP] &
+   DP_ALTERNATE_SCRAMBLER_RESET_CAP;
+}
+
 /*
  * DisplayPort AUX channel
  */
@@ -1120,12 +1127,14 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
  * @tps3_supported: training pattern sequence 3 supported for equalization
  * @fast_training: AUX CH handshake not required for link training
  * @channel_coding: ANSI 8B/10B channel coding capability
+ * @alternate_scrambler_reset: eDP alternate scrambler reset capability
  */
 struct drm_dp_link_caps {
bool enhanced_framing;
bool tps3_supported;
bool fast_training;
bool channel_coding;
+   bool alternate_scrambler_reset;
 };
 
 void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
-- 
2.15.1

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

[PATCH 11/17] drm/dp: Read AUX read interval from DPCD

[Thierry Reding]

From: Thierry Reding 

Store the AUX read interval from DPCD, so that it can be used to wait
for the durations given in the specification during link training.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c |  3 +++
 include/drm/drm_dp_helper.h | 18 ++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index c78cc62f149f..0d9d5360465c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -361,6 +361,7 @@ static void drm_dp_link_reset(struct drm_dp_link *link)
link->max_lanes = 0;
 
drm_dp_link_caps_reset(>caps);
+   link->aux_rd_interval = 0;
link->edp = 0;
 
link->rate = 0;
@@ -414,6 +415,8 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
link->edp = edp_revs[value];
}
 
+   link->aux_rd_interval = drm_dp_aux_rd_interval(values);
+
link->rate = link->max_rate;
link->lanes = link->max_lanes;
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 705c56ebe74d..8213f1c53f9b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -997,6 +997,22 @@ drm_dp_alternate_scrambler_reset_cap(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
DP_ALTERNATE_SCRAMBLER_RESET_CAP;
 }
 
+/**
+ * drm_dp_read_aux_interval() - read the AUX read interval from the DPCD
+ * @dpcd: receiver capacity buffer
+ *
+ * Reads the AUX read interval (in microseconds) from the DPCD. Note that the
+ * TRAINING_AUX_RD_INTERVAL stores the value in units of 4 milliseconds.
+ *
+ * Returns:
+ * The read AUX interval in microseconds.
+ */
+static inline unsigned int
+drm_dp_aux_rd_interval(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   return dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4000;
+}
+
 /*
  * DisplayPort AUX channel
  */
@@ -1146,6 +1162,7 @@ void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
  * @max_rate: maximum clock rate supported on the link
  * @max_lanes: maximum number of lanes supported on the link
  * @caps: capabilities supported on the link (see _dp_link_caps)
+ * @aux_rd_interval: AUX read interval to use for training (in microseconds)
  * @edp: eDP revision (0x11: eDP 1.1, 0x12: eDP 1.2, ...)
  * @rate: currently configured link rate
  * @lanes: currently configured number of lanes
@@ -1156,6 +1173,7 @@ struct drm_dp_link {
unsigned int max_lanes;
 
struct drm_dp_link_caps caps;
+   unsigned int aux_rd_interval;
unsigned char edp;
 
unsigned int rate;
-- 
2.15.1

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

[PATCH 13/17] drm/dp: Use drm_dp_aux_rd_interval()

[Thierry Reding]

From: Thierry Reding 

Make use of the newly added drm_dp_aux_rd_interval() helper in existing
DP link training helpers and add comments about minimum required delays
mandated by the DP specification.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0d9e66ea9667..dabac772dfc3 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -120,11 +120,13 @@ EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
 {
-   unsigned int min;
+   unsigned int min = drm_dp_aux_rd_interval(dpcd);
 
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] != 0)
-   min = dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4000;
-   else
+   /*
+* The DP specification mandates a delay of 100 us during clock
+* recovery if the sink doesn't report an AUX read interval.
+*/
+   if (min == 0)
min = 100;
 
usleep_range(min, min * 2);
@@ -133,11 +135,13 @@ EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
-   unsigned int min;
+   unsigned int min = drm_dp_aux_rd_interval(dpcd);
 
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] != 0)
-   min = dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4000;
-   else
+   /*
+* The DP specification mandates a delay of 400 us during clock
+* recovery if the sink doesn't report an AUX read interval.
+*/
+   if (min == 0)
min = 400;
 
usleep_range(min, min * 2);
-- 
2.15.1

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

[PATCH 08/17] drm/dp: Read channel coding capability from sink

[Thierry Reding]

From: Thierry Reding 

Parse from the sink capabilities whether or not it supports ANSI 8B/10B
channel coding as specified in ANSI X3.230-1994, clause 11.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 3 +++
 include/drm/drm_dp_helper.h | 9 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 664d814ab250..743343527bfa 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -336,6 +336,7 @@ static void drm_dp_link_caps_reset(struct drm_dp_link_caps 
*caps)
caps->enhanced_framing = false;
caps->tps3_supported = false;
caps->fast_training = false;
+   caps->channel_coding = false;
 }
 
 void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
@@ -344,6 +345,7 @@ void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
dest->enhanced_framing = src->enhanced_framing;
dest->tps3_supported = src->tps3_supported;
dest->fast_training = src->fast_training;
+   dest->channel_coding = src->channel_coding;
 }
 EXPORT_SYMBOL(drm_dp_link_caps_copy);
 
@@ -391,6 +393,7 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
link->caps.enhanced_framing = drm_dp_enhanced_frame_cap(values);
link->caps.tps3_supported = drm_dp_tps3_supported(values);
link->caps.fast_training = drm_dp_fast_training_cap(values);
+   link->caps.channel_coding = drm_dp_channel_coding_supported(values);
 
link->rate = link->max_rate;
link->lanes = link->max_lanes;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 81af618c6b4a..fe7aef2c0736 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -89,6 +89,7 @@
 # define DP_DETAILED_CAP_INFO_AVAILABLE(1 << 4) /* DPI */
 
 #define DP_MAIN_LINK_CHANNEL_CODING 0x006
+# define DP_CAP_ANSI_8B10B (1 << 0)
 
 #define DP_DOWN_STREAM_PORT_COUNT  0x007
 # define DP_PORT_COUNT_MASK0x0f
@@ -983,6 +984,12 @@ drm_dp_fast_training_cap(const u8 
dpcd[DP_RECEIVER_CAP_SIZE])
(dpcd[DP_MAX_DOWNSPREAD] & DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
 }
 
+static inline bool
+drm_dp_channel_coding_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_8B10B;
+}
+
 /*
  * DisplayPort AUX channel
  */
@@ -1112,11 +1119,13 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
  * @enhanced_framing: enhanced framing capability (mandatory as of DP 1.2)
  * @tps3_supported: training pattern sequence 3 supported for equalization
  * @fast_training: AUX CH handshake not required for link training
+ * @channel_coding: ANSI 8B/10B channel coding capability
  */
 struct drm_dp_link_caps {
bool enhanced_framing;
bool tps3_supported;
bool fast_training;
+   bool channel_coding;
 };
 
 void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
-- 
2.15.1

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

[PATCH 07/17] drm/dp: Read TPS3 capability from sink

[Thierry Reding]

From: Thierry Reding 

The TPS3 capability can be exposed by DP 1.2 and later sinks if they
support the alternative training pattern for channel equalization.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 3 +++
 include/drm/drm_dp_helper.h | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2d56aeda1b75..664d814ab250 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -334,6 +334,7 @@ EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
 static void drm_dp_link_caps_reset(struct drm_dp_link_caps *caps)
 {
caps->enhanced_framing = false;
+   caps->tps3_supported = false;
caps->fast_training = false;
 }
 
@@ -341,6 +342,7 @@ void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
   const struct drm_dp_link_caps *src)
 {
dest->enhanced_framing = src->enhanced_framing;
+   dest->tps3_supported = src->tps3_supported;
dest->fast_training = src->fast_training;
 }
 EXPORT_SYMBOL(drm_dp_link_caps_copy);
@@ -387,6 +389,7 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
link->max_lanes = drm_dp_max_lane_count(values);
 
link->caps.enhanced_framing = drm_dp_enhanced_frame_cap(values);
+   link->caps.tps3_supported = drm_dp_tps3_supported(values);
link->caps.fast_training = drm_dp_fast_training_cap(values);
 
link->rate = link->max_rate;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 680d6719d463..81af618c6b4a 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1110,10 +1110,12 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
 /**
  * struct drm_dp_link_caps - DP link capabilities
  * @enhanced_framing: enhanced framing capability (mandatory as of DP 1.2)
+ * @tps3_supported: training pattern sequence 3 supported for equalization
  * @fast_training: AUX CH handshake not required for link training
  */
 struct drm_dp_link_caps {
bool enhanced_framing;
+   bool tps3_supported;
bool fast_training;
 };
 
-- 
2.15.1

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

[PATCH 03/17] drm/dp: Track link capabilities alongside settings

[Thierry Reding]

From: Thierry Reding 

Store capabilities in max_* fields and add separate fields for the
currently selected settings.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/bridge/tc358767.c  | 14 +++---
 drivers/gpu/drm/drm_dp_helper.c| 16 +++-
 drivers/gpu/drm/msm/edp/edp_ctrl.c |  8 
 drivers/gpu/drm/rockchip/cdn-dp-core.c |  8 
 drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 13 ++---
 drivers/gpu/drm/tegra/dpaux.c  |  8 
 drivers/gpu/drm/tegra/sor.c| 28 ++--
 include/drm/drm_dp_helper.h| 15 ++-
 8 files changed, 60 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 08ab7d6aea65..55037f999579 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -391,7 +391,7 @@ static u32 tc_srcctrl(struct tc_data *tc)
reg |= DP0_SRCCTRL_EN810B;
if (tc->link.spread)
reg |= DP0_SRCCTRL_SSCG;/* Spread Spectrum Enable */
-   if (tc->link.base.num_lanes == 2)
+   if (tc->link.base.lanes == 2)
reg |= DP0_SRCCTRL_LANES_2; /* Two Main Channel Lanes */
if (tc->link.base.rate != 162000)
reg |= DP0_SRCCTRL_BW27;/* 2.7 Gbps link */
@@ -610,9 +610,9 @@ static int tc_get_display_props(struct tc_data *tc)
tc->link.base.rate = 27;
}
 
-   if (tc->link.base.num_lanes > 2) {
+   if (tc->link.base.lanes > 2) {
dev_dbg(tc->dev, "Falling to 2 lanes\n");
-   tc->link.base.num_lanes = 2;
+   tc->link.base.lanes = 2;
}
 
ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, tmp);
@@ -634,7 +634,7 @@ static int tc_get_display_props(struct tc_data *tc)
dev_dbg(tc->dev, "DPCD rev: %d.%d, rate: %s, lanes: %d, framing: %s\n",
tc->link.base.revision >> 4, tc->link.base.revision & 0x0f,
(tc->link.base.rate == 162000) ? "1.62Gbps" : "2.7Gbps",
-   tc->link.base.num_lanes,
+   tc->link.base.lanes,
(tc->link.base.capabilities & DP_LINK_CAP_ENHANCED_FRAMING) ?
"enhanced" : "non-enhanced");
dev_dbg(tc->dev, "ANSI 8B/10B: %d\n", tc->link.coding8b10b);
@@ -788,13 +788,13 @@ static int tc_link_training(struct tc_data *tc, int 
pattern)
 LT_INTERLANE_ALIGN_DONE |
 LT_CHANNEL0_EQ_BITS;
/* in case of two lanes */
-   if ((tc->link.base.num_lanes == 2) &&
+   if ((tc->link.base.lanes == 2) &&
(value == (LT_CHANNEL1_EQ_BITS |
   LT_INTERLANE_ALIGN_DONE |
   LT_CHANNEL0_EQ_BITS)))
break;
/* in case of one line */
-   if ((tc->link.base.num_lanes == 1) &&
+   if ((tc->link.base.lanes == 1) &&
(value == (LT_INTERLANE_ALIGN_DONE |
   LT_CHANNEL0_EQ_BITS)))
break;
@@ -966,7 +966,7 @@ static int tc_main_link_setup(struct tc_data *tc)
if (ret < 0)
goto err_dpcd_read;
} while ((--timeout) &&
-!(drm_dp_channel_eq_ok(tmp + 2,  tc->link.base.num_lanes)));
+!(drm_dp_channel_eq_ok(tmp + 2,  tc->link.base.lanes)));
 
if (timeout == 0) {
/* Read DPCD 0x200-0x201 */
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1b8a471ec1b7..f401377a199d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -321,9 +321,12 @@ static void drm_dp_link_reset(struct drm_dp_link *link)
return;
 
link->revision = 0;
-   link->rate = 0;
-   link->num_lanes = 0;
+   link->max_rate = 0;
+   link->max_lanes = 0;
link->capabilities = 0;
+
+   link->rate = 0;
+   link->lanes = 0;
 }
 
 /**
@@ -349,12 +352,15 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
return err;
 
link->revision = values[0];
-   link->rate = drm_dp_bw_code_to_link_rate(values[1]);
-   link->num_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
+   link->max_rate = drm_dp_bw_code_to_link_rate(values[1]);
+   link->max_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
 
if (values[2] & DP_ENHANCED_FRAME_CAP)
link->capabilities |= DP_LINK_CAP_ENHANCED_FRAMING;
 
+   link->rate = link->max_rate;
+   link->lanes = link->max_lanes;
+

[PATCH 06/17] drm/dp: Read fast training capability from link

[Thierry Reding]

From: Thierry Reding 

While probing the DisplayPort link, query the fast training capability.
If supported, drivers can use the fast link training sequence instead of
the more involved full link training sequence.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 3 +++
 include/drm/drm_dp_helper.h | 9 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 982dd9febb1c..2d56aeda1b75 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -334,12 +334,14 @@ EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
 static void drm_dp_link_caps_reset(struct drm_dp_link_caps *caps)
 {
caps->enhanced_framing = false;
+   caps->fast_training = false;
 }
 
 void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
   const struct drm_dp_link_caps *src)
 {
dest->enhanced_framing = src->enhanced_framing;
+   dest->fast_training = src->fast_training;
 }
 EXPORT_SYMBOL(drm_dp_link_caps_copy);
 
@@ -385,6 +387,7 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
link->max_lanes = drm_dp_max_lane_count(values);
 
link->caps.enhanced_framing = drm_dp_enhanced_frame_cap(values);
+   link->caps.fast_training = drm_dp_fast_training_cap(values);
 
link->rate = link->max_rate;
link->lanes = link->max_lanes;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 85ff67958875..680d6719d463 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -976,6 +976,13 @@ drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
return dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT;
 }
 
+static inline bool
+drm_dp_fast_training_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   return dpcd[DP_DPCD_REV] >= 0x11 &&
+   (dpcd[DP_MAX_DOWNSPREAD] & DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
+}
+
 /*
  * DisplayPort AUX channel
  */
@@ -1103,9 +1110,11 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
 /**
  * struct drm_dp_link_caps - DP link capabilities
  * @enhanced_framing: enhanced framing capability (mandatory as of DP 1.2)
+ * @fast_training: AUX CH handshake not required for link training
  */
 struct drm_dp_link_caps {
bool enhanced_framing;
+   bool fast_training;
 };
 
 void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
-- 
2.15.1

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

[PATCH 00/17] drm/dp: Miscellaneous improvements

[Thierry Reding]

From: Thierry Reding 

Hi,

this set of patches is based on work that I had done some 2-3 years ago
to enable DP support on Pixel C. I never really got that to work, but I
recently got my hands on newer hardware with DP connectivity, so I went
to revive these patches.

I think this takes into account all review comments I was able to find
and adds a bit of kerneldoc here and there. I've got a couple of patches
on top of this that implement DP support (and make use of more of these
helpers in the existing eDP support) for Tegra.

Thierry

Thierry Reding (17):
  drm/dp: Add missing kerneldoc for struct drm_dp_link
  drm/dp: Add drm_dp_link_reset() implementation
  drm/dp: Track link capabilities alongside settings
  drm/dp: Turn link capabilities into booleans
  drm/dp: Probe link using existing parsing helpers
  drm/dp: Read fast training capability from link
  drm/dp: Read TPS3 capability from sink
  drm/dp: Read channel coding capability from sink
  drm/dp: Read alternate scrambler reset capability from sink
  drm/dp: Read eDP version from DPCD
  drm/dp: Read AUX read interval from DPCD
  drm/dp: Do not busy-loop during link training
  drm/dp: Use drm_dp_aux_rd_interval()
  drm/dp: Add helper to get post-cursor adjustments
  drm/dp: Set channel coding on link configuration
  drm/dp: Enable alternate scrambler reset when supported
  drm/dp: Add drm_dp_link_choose() helper

 drivers/gpu/drm/bridge/tc358767.c  |  20 ++--
 drivers/gpu/drm/drm_dp_helper.c| 211 +
 drivers/gpu/drm/msm/edp/edp_ctrl.c |  12 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c |   8 +-
 drivers/gpu/drm/rockchip/cdn-dp-reg.c  |  13 +-
 drivers/gpu/drm/tegra/dpaux.c  |   8 +-
 drivers/gpu/drm/tegra/sor.c|  32 ++---
 include/drm/drm_dp_helper.h|  95 ++-
 8 files changed, 328 insertions(+), 71 deletions(-)

-- 
2.15.1

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

[PATCH 05/17] drm/dp: Probe link using existing parsing helpers

[Thierry Reding]

From: Thierry Reding 

Use existing parsing helpers to probe a DisplayPort link.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 29 ++---
 include/drm/drm_dp_helper.h |  2 ++
 2 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 6fbce4554029..982dd9febb1c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -299,6 +299,22 @@ ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned 
int offset,
 }
 EXPORT_SYMBOL(drm_dp_dpcd_write);
 
+/**
+ * drm_dp_dpcd_read_link_caps() - read DPCD link capabilities
+ * @aux: DisplayPort AUX channel
+ * @caps: buffer to store the link capabilities in
+ *
+ * Returns:
+ * The number of bytes transferred on success or a negative error code on
+ * failure.
+ */
+int drm_dp_dpcd_read_link_caps(struct drm_dp_aux *aux,
+  u8 caps[DP_RECEIVER_CAP_SIZE])
+{
+   return drm_dp_dpcd_read(aux, DP_DPCD_REV, caps, DP_RECEIVER_CAP_SIZE);
+}
+EXPORT_SYMBOL(drm_dp_dpcd_read_link_caps);
+
 /**
  * drm_dp_dpcd_read_link_status() - read DPCD link status (bytes 0x202-0x207)
  * @aux: DisplayPort AUX channel
@@ -355,21 +371,20 @@ static void drm_dp_link_reset(struct drm_dp_link *link)
  */
 int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link)
 {
-   u8 values[3];
+   u8 values[DP_RECEIVER_CAP_SIZE];
int err;
 
drm_dp_link_reset(link);
 
-   err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
+   err = drm_dp_dpcd_read_link_caps(aux, values);
if (err < 0)
return err;
 
-   link->revision = values[0];
-   link->max_rate = drm_dp_bw_code_to_link_rate(values[1]);
-   link->max_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
+   link->revision = values[DP_DPCD_REV];
+   link->max_rate = drm_dp_max_link_rate(values);
+   link->max_lanes = drm_dp_max_lane_count(values);
 
-   if (values[2] & DP_ENHANCED_FRAME_CAP)
-   link->caps.enhanced_framing = true;
+   link->caps.enhanced_framing = drm_dp_enhanced_frame_cap(values);
 
link->rate = link->max_rate;
link->lanes = link->max_lanes;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e3429abb03f9..85ff67958875 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1091,6 +1091,8 @@ static inline ssize_t drm_dp_dpcd_writeb(struct 
drm_dp_aux *aux,
return drm_dp_dpcd_write(aux, offset, , 1);
 }
 
+int drm_dp_dpcd_read_link_caps(struct drm_dp_aux *aux,
+  u8 caps[DP_RECEIVER_CAP_SIZE]);
 int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
 u8 status[DP_LINK_STATUS_SIZE]);
 
-- 
2.15.1

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

[PATCH 04/17] drm/dp: Turn link capabilities into booleans

[Thierry Reding]

From: Thierry Reding 

Rather than storing capabilities as flags in an integer, use a separate
boolean per capability. This simplifies the code that checks for these
capabilities.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/bridge/tc358767.c  |  6 +++---
 drivers/gpu/drm/drm_dp_helper.c| 19 ---
 drivers/gpu/drm/msm/edp/edp_ctrl.c |  4 ++--
 drivers/gpu/drm/tegra/sor.c|  4 ++--
 include/drm/drm_dp_helper.h| 17 ++---
 5 files changed, 37 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 55037f999579..ad278a79feb3 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -635,8 +635,8 @@ static int tc_get_display_props(struct tc_data *tc)
tc->link.base.revision >> 4, tc->link.base.revision & 0x0f,
(tc->link.base.rate == 162000) ? "1.62Gbps" : "2.7Gbps",
tc->link.base.lanes,
-   (tc->link.base.capabilities & DP_LINK_CAP_ENHANCED_FRAMING) ?
-   "enhanced" : "non-enhanced");
+   (tc->link.base.caps.enhanced_framing) ? "enhanced" :
+   "non-enhanced");
dev_dbg(tc->dev, "ANSI 8B/10B: %d\n", tc->link.coding8b10b);
dev_dbg(tc->dev, "Display ASSR: %d, TC358767 ASSR: %d\n",
tc->link.assr, tc->assr);
@@ -1015,7 +1015,7 @@ static int tc_main_link_stream(struct tc_data *tc, int 
state)
 
if (state) {
value = VID_MN_GEN | DP_EN;
-   if (tc->link.base.capabilities & DP_LINK_CAP_ENHANCED_FRAMING)
+   if (tc->link.base.caps.enhanced_framing)
value |= EF_EN;
tc_write(DP0CTL, value);
/*
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f401377a199d..6fbce4554029 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -315,6 +315,18 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
 }
 EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
 
+static void drm_dp_link_caps_reset(struct drm_dp_link_caps *caps)
+{
+   caps->enhanced_framing = false;
+}
+
+void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
+  const struct drm_dp_link_caps *src)
+{
+   dest->enhanced_framing = src->enhanced_framing;
+}
+EXPORT_SYMBOL(drm_dp_link_caps_copy);
+
 static void drm_dp_link_reset(struct drm_dp_link *link)
 {
if (!link)
@@ -323,7 +335,8 @@ static void drm_dp_link_reset(struct drm_dp_link *link)
link->revision = 0;
link->max_rate = 0;
link->max_lanes = 0;
-   link->capabilities = 0;
+
+   drm_dp_link_caps_reset(>caps);
 
link->rate = 0;
link->lanes = 0;
@@ -356,7 +369,7 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
link->max_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
 
if (values[2] & DP_ENHANCED_FRAME_CAP)
-   link->capabilities |= DP_LINK_CAP_ENHANCED_FRAMING;
+   link->caps.enhanced_framing = true;
 
link->rate = link->max_rate;
link->lanes = link->max_lanes;
@@ -449,7 +462,7 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
values[0] = drm_dp_link_rate_to_bw_code(link->rate);
values[1] = link->lanes;
 
-   if (link->capabilities & DP_LINK_CAP_ENHANCED_FRAMING)
+   if (link->caps.enhanced_framing)
values[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
 
err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, values, sizeof(values));
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c 
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 71192a0656e3..489fa81bb508 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -447,7 +447,7 @@ static void edp_config_ctrl(struct edp_ctrl *ctrl)
 
data = EDP_CONFIGURATION_CTRL_LANES(ctrl->lane_cnt - 1);
 
-   if (ctrl->dp_link.capabilities & DP_LINK_CAP_ENHANCED_FRAMING)
+   if (ctrl->dp_link.caps.enhanced_framing)
data |= EDP_CONFIGURATION_CTRL_ENHANCED_FRAMING;
 
depth = EDP_6BIT;
@@ -769,7 +769,7 @@ static int edp_do_link_train(struct edp_ctrl *ctrl)
 */
dp_link.lanes = ctrl->lane_cnt;
dp_link.rate = drm_dp_bw_code_to_link_rate(ctrl->link_rate);
-   dp_link.capabilities = ctrl->dp_link.capabilities;
+   drm_dp_link_caps_copy(_link.caps, >dp_link.caps);
if (drm_dp_link_configure(ctrl->drm_aux, _link) < 0)
return EDP_TRAIN_FAIL;
 
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index e3c3f5add411..f24c012f1b41 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -912,7 +912,7 @@ static int tegra_sor_compute_config(struct tegra_sor *sor,
num = ((mode->htotal - mode->hdisplay) - 7) * link_rate;

[PATCH 02/17] drm/dp: Add drm_dp_link_reset() implementation

[Thierry Reding]

From: Thierry Reding 

Subsequent patches will add non-volatile fields to struct drm_dp_link,
so introduce a function to zero out only the volatile fields.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be42c1e..1b8a471ec1b7 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -315,6 +315,17 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
 }
 EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
 
+static void drm_dp_link_reset(struct drm_dp_link *link)
+{
+   if (!link)
+   return;
+
+   link->revision = 0;
+   link->rate = 0;
+   link->num_lanes = 0;
+   link->capabilities = 0;
+}
+
 /**
  * drm_dp_link_probe() - probe a DisplayPort link for capabilities
  * @aux: DisplayPort AUX channel
@@ -331,7 +342,7 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
u8 values[3];
int err;
 
-   memset(link, 0, sizeof(*link));
+   drm_dp_link_reset(link);
 
err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
if (err < 0)
-- 
2.15.1

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

[PATCH 01/17] drm/dp: Add missing kerneldoc for struct drm_dp_link

[Thierry Reding]

From: Thierry Reding 

The drm_dp_link structure tracks capabilities on the DP link. Add some
kerneldoc to explain what each of its fields means.

Signed-off-by: Thierry Reding 
---
 include/drm/drm_dp_helper.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a428c8d7..6ced0bc6feb9 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1099,6 +1099,13 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
  */
 #define DP_LINK_CAP_ENHANCED_FRAMING (1 << 0)
 
+/**
+ * struct drm_dp_link - DP link capabilities
+ * @revision: DP specification revision supported on the link
+ * @rate: maximum clock rate supported on the link
+ * @num_lanes: maximum number of lanes supported on the link
+ * @capabilities: bitmask of capabilities supported on the link
+ */
 struct drm_dp_link {
unsigned char revision;
unsigned int rate;
-- 
2.15.1

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

[PATCH 2/2 v2] drm/panel: Add support for ARM Versatile panels

[Linus Walleij]

The ARM reference designs "Versatile AB" and "Versatile PB"
contain panel connectors with autodetection of the connected
panel type. This adds a small driver utilizing the MFD syscon
look-up to read the autodetection register and set up the
corresponding panel appropriately.

In the source file there is a bit of elaboration of the
panel types and interfaces on these boards.

This was tested with the PL111 DRM driver on the ARM Versatile
AB with the IB2 daughterboard.

Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Use inline documentation style for the structs.
- Explicit positive hsync and vsync on the panels requiring it
- Convert two dev_info() to dev_dbg()
- Collect Eric's Review tag.
---
 MAINTAINERS |   7 +
 drivers/gpu/drm/panel/Kconfig   |  10 +
 drivers/gpu/drm/panel/Makefile  |   1 +
 drivers/gpu/drm/panel/panel-arm-versatile.c | 377 
 4 files changed, 395 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-arm-versatile.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 18994806e441..e4fc490fa320 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4442,6 +4442,13 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 S: Supported
 F: drivers/gpu/drm/pl111/
 
+DRM DRIVER FOR ARM VERSATILE TFT PANELS
+M: Linus Walleij 
+T: git git://anongit.freedesktop.org/drm/drm-misc
+S: Maintained
+F: drivers/gpu/drm/panel/panel-arm-versatile.c
+F: 
Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt
+
 DRM DRIVER FOR AST SERVER GRAPHICS CHIPS
 M: Dave Airlie 
 S: Odd Fixes
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 726f3fb3312d..04732adbb48f 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -7,6 +7,16 @@ config DRM_PANEL
 menu "Display Panels"
depends on DRM && DRM_PANEL
 
+config DRM_PANEL_ARM_VERSATILE
+   tristate "ARM Versatile panel driver"
+   depends on OF
+   depends on MFD_SYSCON
+   select VIDEOMODE_HELPERS
+   help
+ This driver supports the ARM Versatile panels connected to ARM
+ reference designs. The panel is detected using special registers
+ in the Versatile family syscon registers.
+
 config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 2c4e1a93e05f..091fa6647769 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c 
b/drivers/gpu/drm/panel/panel-arm-versatile.c
new file mode 100644
index ..3930b4925b15
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
@@ -0,0 +1,377 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Panel driver for the ARM Versatile family reference designs from
+ * ARM Limited.
+ *
+ * Author:
+ * Linus Walleij 
+ *
+ * On the Versatile AB, these panels come mounted on daughterboards
+ * named "IB1" or "IB2" (Interface Board 1 & 2 respectively.) They
+ * are documented in ARM DUI 0225D Appendix C and D. These daughter
+ * boards support TFT display panels.
+ *
+ * - The IB1 is a passive board where the display connector defines a
+ *   few wires for encoding the display type for autodetection,
+ *   suitable display settings can then be looked up from this setting.
+ *   The magic bits can be read out from the system controller.
+ *
+ * - The IB2 is a more complex board intended for GSM phone development
+ *   with some logic and a control register, which needs to be accessed
+ *   and the board display needs to be turned on explicitly.
+ *
+ * On the Versatile PB, a special CLCD adaptor board is available
+ * supporting the same displays as the Versatile AB, plus one more
+ * Epson QCIF display.
+ *
+ */
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/*
+ * This configuration register in the Versatile and RealView
+ * family is uniformly present but appears more and more
+ * unutilized starting with the RealView series.
+ */
+#define SYS_CLCD   0x50
+
+/* The Versatile can detect the connected panel type */
+#define SYS_CLCD_CLCDID_MASK   (BIT(8)|BIT(9)|BIT(10)|BIT(11)|BIT(12))
+#define SYS_CLCD_ID_SANYO_3_8  (0x00 << 8)
+#define SYS_CLCD_ID_SHARP_8_4  (0x01 << 8)
+#define SYS_CLCD_ID_EPSON_2_2  (0x02 << 8)
+#define 

Re: [PATCH v1 1/2] drm/stm: ltdc: add non-alpha color formats

[kbuild test robot]

Hi Philippe,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.15 next-20180205]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Philippe-Cornu/drm-stm-ltdc-add-non-alpha-color-formats/20180201-211736
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/stm/ltdc.c: In function 'ltdc_plane_atomic_update':
>> drivers/gpu//drm/stm/ltdc.c:661:17: error: 'const struct drm_format_info' 
>> has no member named 'has_alpha'
 if (!fb->format->has_alpha)
^~

vim +661 drivers/gpu//drm/stm/ltdc.c

   587  
   588  static void ltdc_plane_atomic_update(struct drm_plane *plane,
   589   struct drm_plane_state *oldstate)
   590  {
   591  struct ltdc_device *ldev = plane_to_ltdc(plane);
   592  struct drm_plane_state *state = plane->state;
   593  struct drm_framebuffer *fb = state->fb;
   594  u32 lofs = plane->index * LAY_OFS;
   595  u32 x0 = state->crtc_x;
   596  u32 x1 = state->crtc_x + state->crtc_w - 1;
   597  u32 y0 = state->crtc_y;
   598  u32 y1 = state->crtc_y + state->crtc_h - 1;
   599  u32 src_x, src_y, src_w, src_h;
   600  u32 val, pitch_in_bytes, line_length, paddr, ahbp, avbp, bpcr;
   601  enum ltdc_pix_fmt pf;
   602  
   603  if (!state->crtc || !fb) {
   604  DRM_DEBUG_DRIVER("fb or crtc NULL");
   605  return;
   606  }
   607  
   608  /* convert src_ from 16:16 format */
   609  src_x = state->src_x >> 16;
   610  src_y = state->src_y >> 16;
   611  src_w = state->src_w >> 16;
   612  src_h = state->src_h >> 16;
   613  
   614  DRM_DEBUG_DRIVER("plane:%d fb:%d (%dx%d)@(%d,%d) -> 
(%dx%d)@(%d,%d)\n",
   615   plane->base.id, fb->base.id,
   616   src_w, src_h, src_x, src_y,
   617   state->crtc_w, state->crtc_h,
   618   state->crtc_x, state->crtc_y);
   619  
   620  bpcr = reg_read(ldev->regs, LTDC_BPCR);
   621  ahbp = (bpcr & BPCR_AHBP) >> 16;
   622  avbp = bpcr & BPCR_AVBP;
   623  
   624  /* Configures the horizontal start and stop position */
   625  val = ((x1 + 1 + ahbp) << 16) + (x0 + 1 + ahbp);
   626  reg_update_bits(ldev->regs, LTDC_L1WHPCR + lofs,
   627  LXWHPCR_WHSTPOS | LXWHPCR_WHSPPOS, val);
   628  
   629  /* Configures the vertical start and stop position */
   630  val = ((y1 + 1 + avbp) << 16) + (y0 + 1 + avbp);
   631  reg_update_bits(ldev->regs, LTDC_L1WVPCR + lofs,
   632  LXWVPCR_WVSTPOS | LXWVPCR_WVSPPOS, val);
   633  
   634  /* Specifies the pixel format */
   635  pf = to_ltdc_pixelformat(fb->format->format);
   636  for (val = 0; val < NB_PF; val++)
   637  if (ldev->caps.pix_fmt_hw[val] == pf)
   638  break;
   639  
   640  if (val == NB_PF) {
   641  DRM_ERROR("Pixel format %.4s not supported\n",
   642(char *)>format->format);
   643  val = 0;/* set by default ARGB 32 bits */
   644  }
   645  reg_update_bits(ldev->regs, LTDC_L1PFCR + lofs, LXPFCR_PF, val);
   646  
   647  /* Configures the color frame buffer pitch in bytes & line 
length */
   648  pitch_in_bytes = fb->pitches[0];
   649  line_length = drm_format_plane_cpp(fb->format->format, 0) *
   650(x1 - x0 + 1) + (ldev->caps.bus_width >> 3) - 1;
   651  val = ((pitch_in_bytes << 16) | line_length);
   652  reg_update_bits(ldev->regs, LTDC_L1CFBLR + lofs,
   653  LXCFBLR_CFBLL | LXCFBLR_CFBP, val);
   654  
   655  /* Specifies the constant alpha value */
   656  val = CONSTA_MAX;
   657  reg_update_bits(ldev->regs, LTDC_L1CACR + lofs, LXCACR_CONSTA, 
val);
   658  
   659  /* Specifies the blending factors */
   660  val = BF1_PAXCA | BF2_1PAXCA;
 > 661   

[PATCH 1/2 v2] drm/panel: Device tree bindings for ARM Versatile panels

[Linus Walleij]

This adds a pretty simple set of device tree bindings for
ARM Versatile panels appearing as child nodes of a system
controller.

Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Collect Rob's ACK.
---
 .../display/panel/arm,versatile-tft-panel.txt  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt 
b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt
new file mode 100644
index ..248141c3c7e3
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt
@@ -0,0 +1,31 @@
+ARM Versatile TFT Panels
+
+These panels are connected to the daughterboards found on the
+ARM Versatile reference designs.
+
+This device node must appear as a child to a "syscon"-compatible
+node.
+
+Required properties:
+- compatible: should be "arm,versatile-tft-panel"
+
+Required subnodes:
+- port: see display/panel/panel-common.txt, graph.txt
+
+
+Example:
+
+sysreg@0 {
+   compatible = "arm,versatile-sysreg", "syscon", "simple-mfd";
+   reg = <0x0 0x1000>;
+
+   panel: display@0 {
+   compatible = "arm,versatile-tft-panel";
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <>;
+   };
+   };
+   };
+};
-- 
2.14.3

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

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Pandiyan, Dhinakaran]

On Sun, 2018-02-04 at 21:50 +, Andy Lutomirski wrote:
> On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
> > On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
> >  wrote:
> >>
> >> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
> >>> I updated to 4.15, and the situation is much worse.  With
> >>> enable_psr=1, the system survives for several seconds and then the
> >>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
> >>> get to the Fedora login screen and then the system dies.  If I set
> >>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
> >>> seems like it also sometimes hangs even worse a bit after the screen
> >>> stops updating, but it's hard to tell.
> >>
> >> The login screen freeze sounds like what I have. Does this system have
> >> DMC firmware? If yes, can you try this series
> >> https://patchwork.freedesktop.org/series/37598/. You'll only need
> >> patches 1,8,9 and 10.
> >
> > That fixes the hang.  Feel free to add:
> >
> > Tested-by: Andy Lutomirski 
> >
> > to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
> > kernels?
> 
> Correction: I'm still getting a second or two of complete screen
> freezing every now and then.  The kernel says:
Thanks a lot for testing. How do you trigger this freeze? Moving the
cursor? Did you apply these patches on top of drm-tip or was it
mainline?

I also have another patch here that addresses screen freezes in console
mode with PSR - https://patchwork.freedesktop.org/patch/201144/ in case
that is what you are interested in.
> 
> [69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
> update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
> 1079, scanline start 1068, end 1082
> 
> So something might still be a bit buggy.

This series fixes only the long freezes due to frame counter resets, I
am sure there are still other issues with PSR.

BTW does your patch on top of these patches help with the cursor lag?

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

[radeon-alex:drm-next-4.17-wip 59/249] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple definition of `amdgpu_dm_crtc_handle_crc_irq'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head:   a5592a6df4f45a018b48f252ad1c498e683e9b9d
commit: 30de3c24e044a36ad8738faddb8986fe4e3a2319 [59/249] drm/amd/display: 
Implement interface for CRC on CRTC
config: x86_64-randconfig-a0-02052326 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout 30de3c24e044a36ad8738faddb8986fe4e3a2319
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/amdgpu_device.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/atombios_crtc.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/atom.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_object.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_gart.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_display.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280:
 first defined here
   drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.o: In function 
`amdgpu_dm_crtc_handle_crc_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:280: multiple 
>> definition of `amdgpu_dm_crtc_handle_crc_irq'
   

Re: [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()

[Alex Deucher]

On Sat, Feb 3, 2018 at 12:12 AM, Dhinakaran Pandiyan
 wrote:
> 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> return type for drm_crtc_vblank_count() to u64. This could cause
> potential problems if the return value is used in arithmetic operations
> with a 32-bit reference HW vblank count. Explicitly typecasting this down
> to u32 either fixes a potential problem or serves to add clarity in case
> the typecasting was implicitly done.
>
> Cc: Keith Packard 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Signed-off-by: Dhinakaran Pandiyan 

Acked-by: Alex Deucher  for both this patch
and the radeon one.

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 2 +-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 38d47559f098..c2fa5d55f04e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -207,7 +207,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
> amdgpu_bo_unreserve(new_abo);
>
> work->base = base;
> -   work->target_vblank = target - drm_crtc_vblank_count(crtc) +
> +   work->target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
> amdgpu_get_vblank_counter_kms(dev, work->crtc_id);
>
> /* we borrow the event spin lock for protecting flip_wrok */
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 1ce4c98385e3..b7254a29b34a 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3836,7 +3836,7 @@ static void amdgpu_dm_do_flip(struct drm_crtc *crtc,
>
>
> /* Prepare wait for target vblank early - before the fence-waits */
> -   target_vblank = target - drm_crtc_vblank_count(crtc) +
> +   target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
> amdgpu_get_vblank_counter_kms(crtc->dev, 
> acrtc->crtc_id);
>
> /* TODO This might fail and hence better not used, wait
> @@ -3982,7 +3982,7 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
> amdgpu_dm_do_flip(
> crtc,
> fb,
> -   drm_crtc_vblank_count(crtc) + 
> *wait_for_vblank,
> +   (uint32_t)drm_crtc_vblank_count(crtc) + 
> *wait_for_vblank,
> dm_state->context);
> }
>
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104216] Firefox quirks (black and/or white squares)

[bugzilla-daemon]

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

--- Comment #14 from Germano Massullo  ---
(In reply to Emil Velikov from comment #13)
> (In reply to Germano Massullo from comment #12)
> > Is there anything else I can do to retrieve useful informations?
> > Thank you
> 
> 
> You can track (git bisect) which version of Mesa, ideally which commit,
> caused the regression. You will need to rebuild mesa a few times, so ensure
> you use the exact same build options as in your distro packaging.

Ok I will try and let you know as soon as possible

-- 
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] drm: don't link DP aux i2c adapter to the hardware device node

[Thierry Reding]

On Mon, Feb 05, 2018 at 06:39:05PM +0100, Lucas Stach wrote:
> Am Montag, den 05.02.2018, 18:33 +0100 schrieb Thierry Reding:
> > On Mon, Feb 05, 2018 at 05:11:30PM +0100, Thierry Reding wrote:
> > > On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Reding wrote:
> > > > On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
> > > > > Hi Rob,
> > > > > 
> > > > > Am Mittwoch, den 29.03.2017, 08:56 -0500 schrieb Rob Herring:
> > > > > > On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding
> > > > > > > > > > >  wrote:
> > > > > > > On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote:
> > > > > > > > The i2c adapter on DP AUX is purely a software construct. 
> > > > > > > > Linking
> > > > > > > > it to the device node of the parent device is wrong, as it 
> > > > > > > > leads to
> > > > > > > > 2 devices sharing the same device node, which is bad practice, 
> > > > > > > > as
> > > > > > > 
> > > > > > > Who says that two devices can't share the same device node? It's 
> > > > > > > done
> > > > > > > all the time.
> > > > > > 
> > > > > > It's done *some of the time* and I would not consider it best 
> > > > > > practice.
> > > > > > 
> > > > > > > > well as the i2c trying to populate children of the i2c adapter 
> > > > > > > > by
> > > > > > > > looking at the child device nodes of the parent device.
> > > > > > > 
> > > > > > > A set of patches landed in v4.9 to work around this issue in a 
> > > > > > > better
> > > > > > > way. See:
> > > > > > > 
> > > > > > > 98b00488459e dt-bindings: i2c: Add support for 'i2c-bus' 
> > > > > > > subnode
> > > > > > > 7e4c224abfe8 i2c: core: Add support for 'i2c-bus' subnode
> > > > > > 
> > > > > > What does this buy us? I don't see why this needs to be in DT 
> > > > > > either.
> > > > > > Contrary to popular belief, DT is not the only way to instantiate
> > > > > > devices, C code can still do it.
> > > > > > 
> > > > > > Also, if this one line removal has no side effects, then how was it
> > > > > > even needed? We can always add it back if there's some argument for
> > > > > > why it is needed.
> > > > > 
> > > > > Okay, so I take this as you mostly agreeing with the rationale of this
> > > > > patch.
> > > > 
> > > > For some general background on this: I was originally using this for DP
> > > > support on Tegra (though that ended up never getting merged because of a
> > > > particularily frustrating episode of trying to get better link training
> > > > support into the core helpers) and use it as a means to obtain the I2C
> > > > controller used for DDC. On Tegra, and I suspect other devices as well,
> > > > the DP AUX controller is separate from the encoder, so the idea was to
> > > > link them together using a standard ddc-i2c-bus phandle.
> > > > 
> > > > I ended up not needing that because the encoder and DP AUX controller
> > > > are so tightly linked on Tegra that I need direct access to the DP AUX
> > > > anyway and can therefore directly get the I2C controller from that.
> > > > 
> > > > If there aren't any other users of this, I suppose we could simply
> > > > remove the line. Should someone turn up in the future and require the
> > > > I2C controller to be looked up from a phandle we could add it again,
> > > > at which point we'd have to investigate again how to get rid of the
> > > > errors.
> > > > 
> > > > Acked-by: Thierry Reding 
> > > 
> > > I'm going to have to retract that: I just noticed that this patch breaks
> > > eDP for Venice2 (and presumably all Tegra124 Nyan boards as well, though
> > > I don't have those to test with).
> > > 
> > > My description above isn't quite correct. For eDP device we do use the
> > > ddc-i2c-bus property in DT to denote which I2C bus to use for probing
> > > the EDID. So the reason why eDP now breaks is because the simple-panel
> > > driver will look for the I2C adapter, not find a matching one and defer
> > > probe (indefinitely).
> > > 
> > > A, perhaps nicer, alternative I found to make it work is the below
> > > patch. Would that be more reasonable? Looping in Wolfram.
> > > 
> > > Thierry
> > > --- >8 ---
> > > diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
> > > index 8d474bb1dc15..f88527a61cd1 100644
> > > --- a/drivers/i2c/i2c-core-of.c
> > > +++ b/drivers/i2c/i2c-core-of.c
> > > @@ -118,6 +118,14 @@ static int of_dev_node_match(struct device *dev, 
> > > void *data)
> > > > >   return dev->of_node == data;
> > >  }
> > >  
> > > +static int of_parent_node_match(struct device *dev, void *data)
> > > +{
> > > > > + if (dev->parent)
> > > > > + return dev->parent->of_node == data;
> > > +
> > > > > + return 0;
> > > +}
> > > +
> > >  /* must call put_device() when done with returned i2c_client device */
> > >  struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
> > >  {
> > > @@ -143,6 +151,9 @@ struct i2c_adapter 
> > > *of_find_i2c_adapter_by_node(struct 

[PATCH] drm: exynos: Use proper macro definition for HDMI_I2S_PIN_SEL_1

[Sylwester Nawrocki]

Bit field [2:0] of HDMI_I2S_PIN_SEL_1 corresponds to SDATA_0,
not SDATA_2. This patch removes redefinition of HDMI_I2S_SEL_DATA2
constant and adds missing HDMI_I2S_SEL_DATA0. There is no functional
change.

Signed-off-by: Sylwester Nawrocki 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +--
 drivers/gpu/drm/exynos/regs-hdmi.h   | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a4b75a46f946..abd84cbcf1c2 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1068,10 +1068,13 @@ static void hdmi_audio_config(struct hdmi_context 
*hdata)
/* Configuration I2S input ports. Configure I2S_PIN_SEL_0~4 */
hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_0, HDMI_I2S_SEL_SCLK(5)
| HDMI_I2S_SEL_LRCK(6));
-   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(1)
-   | HDMI_I2S_SEL_SDATA2(4));
+
+   hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_1, HDMI_I2S_SEL_SDATA1(3)
+   | HDMI_I2S_SEL_SDATA0(4));
+
hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_2, HDMI_I2S_SEL_SDATA3(1)
| HDMI_I2S_SEL_SDATA2(2));
+
hdmi_reg_writeb(hdata, HDMI_I2S_PIN_SEL_3, HDMI_I2S_SEL_DSD(0));
 
/* I2S_CON_1 & 2 */
diff --git a/drivers/gpu/drm/exynos/regs-hdmi.h 
b/drivers/gpu/drm/exynos/regs-hdmi.h
index 04be0f7e8193..4420c203ac85 100644
--- a/drivers/gpu/drm/exynos/regs-hdmi.h
+++ b/drivers/gpu/drm/exynos/regs-hdmi.h
@@ -464,7 +464,7 @@
 
 /* I2S_PIN_SEL_1 */
 #define HDMI_I2S_SEL_SDATA1(x) (((x) & 0x7) << 4)
-#define HDMI_I2S_SEL_SDATA2(x) ((x) & 0x7)
+#define HDMI_I2S_SEL_SDATA0(x) ((x) & 0x7)
 
 /* I2S_PIN_SEL_2 */
 #define HDMI_I2S_SEL_SDATA3(x) (((x) & 0x7) << 4)
-- 
2.14.2

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

Re: [PATCH] drm: don't link DP aux i2c adapter to the hardware device node

[Lucas Stach]

Am Montag, den 05.02.2018, 18:33 +0100 schrieb Thierry Reding:
> On Mon, Feb 05, 2018 at 05:11:30PM +0100, Thierry Reding wrote:
> > On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Reding wrote:
> > > On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
> > > > Hi Rob,
> > > > 
> > > > Am Mittwoch, den 29.03.2017, 08:56 -0500 schrieb Rob Herring:
> > > > > On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding
> > > > > > > > > >  wrote:
> > > > > > On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote:
> > > > > > > The i2c adapter on DP AUX is purely a software construct. Linking
> > > > > > > it to the device node of the parent device is wrong, as it leads 
> > > > > > > to
> > > > > > > 2 devices sharing the same device node, which is bad practice, as
> > > > > > 
> > > > > > Who says that two devices can't share the same device node? It's 
> > > > > > done
> > > > > > all the time.
> > > > > 
> > > > > It's done *some of the time* and I would not consider it best 
> > > > > practice.
> > > > > 
> > > > > > > well as the i2c trying to populate children of the i2c adapter by
> > > > > > > looking at the child device nodes of the parent device.
> > > > > > 
> > > > > > A set of patches landed in v4.9 to work around this issue in a 
> > > > > > better
> > > > > > way. See:
> > > > > > 
> > > > > > 98b00488459e dt-bindings: i2c: Add support for 'i2c-bus' 
> > > > > > subnode
> > > > > > 7e4c224abfe8 i2c: core: Add support for 'i2c-bus' subnode
> > > > > 
> > > > > What does this buy us? I don't see why this needs to be in DT either.
> > > > > Contrary to popular belief, DT is not the only way to instantiate
> > > > > devices, C code can still do it.
> > > > > 
> > > > > Also, if this one line removal has no side effects, then how was it
> > > > > even needed? We can always add it back if there's some argument for
> > > > > why it is needed.
> > > > 
> > > > Okay, so I take this as you mostly agreeing with the rationale of this
> > > > patch.
> > > 
> > > For some general background on this: I was originally using this for DP
> > > support on Tegra (though that ended up never getting merged because of a
> > > particularily frustrating episode of trying to get better link training
> > > support into the core helpers) and use it as a means to obtain the I2C
> > > controller used for DDC. On Tegra, and I suspect other devices as well,
> > > the DP AUX controller is separate from the encoder, so the idea was to
> > > link them together using a standard ddc-i2c-bus phandle.
> > > 
> > > I ended up not needing that because the encoder and DP AUX controller
> > > are so tightly linked on Tegra that I need direct access to the DP AUX
> > > anyway and can therefore directly get the I2C controller from that.
> > > 
> > > If there aren't any other users of this, I suppose we could simply
> > > remove the line. Should someone turn up in the future and require the
> > > I2C controller to be looked up from a phandle we could add it again,
> > > at which point we'd have to investigate again how to get rid of the
> > > errors.
> > > 
> > > Acked-by: Thierry Reding 
> > 
> > I'm going to have to retract that: I just noticed that this patch breaks
> > eDP for Venice2 (and presumably all Tegra124 Nyan boards as well, though
> > I don't have those to test with).
> > 
> > My description above isn't quite correct. For eDP device we do use the
> > ddc-i2c-bus property in DT to denote which I2C bus to use for probing
> > the EDID. So the reason why eDP now breaks is because the simple-panel
> > driver will look for the I2C adapter, not find a matching one and defer
> > probe (indefinitely).
> > 
> > A, perhaps nicer, alternative I found to make it work is the below
> > patch. Would that be more reasonable? Looping in Wolfram.
> > 
> > Thierry
> > --- >8 ---
> > diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
> > index 8d474bb1dc15..f88527a61cd1 100644
> > --- a/drivers/i2c/i2c-core-of.c
> > +++ b/drivers/i2c/i2c-core-of.c
> > @@ -118,6 +118,14 @@ static int of_dev_node_match(struct device *dev, void 
> > *data)
> > > >     return dev->of_node == data;
> >  }
> >  
> > +static int of_parent_node_match(struct device *dev, void *data)
> > +{
> > > > +   if (dev->parent)
> > > > +   return dev->parent->of_node == data;
> > +
> > > > +   return 0;
> > +}
> > +
> >  /* must call put_device() when done with returned i2c_client device */
> >  struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
> >  {
> > @@ -143,6 +151,9 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
> > device_node *node)
> > > >     struct i2c_adapter *adapter;
> >  
> > > >     dev = bus_find_device(_bus_type, NULL, node, 
> > > > of_dev_node_match);
> > > > +   if (!dev)
> > > > +   dev = bus_find_device(_bus_type, NULL, node, 
> > > > of_parent_node_match);
> > +
> > > >     if (!dev)
> > > >   

Re: [PATCH] drm: don't link DP aux i2c adapter to the hardware device node

[Thierry Reding]

On Mon, Feb 05, 2018 at 05:11:30PM +0100, Thierry Reding wrote:
> On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Reding wrote:
> > On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
> > > Hi Rob,
> > > 
> > > Am Mittwoch, den 29.03.2017, 08:56 -0500 schrieb Rob Herring:
> > > > On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding
> > > >  wrote:
> > > > > On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote:
> > > > >> The i2c adapter on DP AUX is purely a software construct. Linking
> > > > >> it to the device node of the parent device is wrong, as it leads to
> > > > >> 2 devices sharing the same device node, which is bad practice, as
> > > > >
> > > > > Who says that two devices can't share the same device node? It's done
> > > > > all the time.
> > > > 
> > > > It's done *some of the time* and I would not consider it best practice.
> > > > 
> > > > >> well as the i2c trying to populate children of the i2c adapter by
> > > > >> looking at the child device nodes of the parent device.
> > > > >
> > > > > A set of patches landed in v4.9 to work around this issue in a better
> > > > > way. See:
> > > > >
> > > > > 98b00488459e dt-bindings: i2c: Add support for 'i2c-bus' 
> > > > > subnode
> > > > > 7e4c224abfe8 i2c: core: Add support for 'i2c-bus' subnode
> > > > 
> > > > What does this buy us? I don't see why this needs to be in DT either.
> > > > Contrary to popular belief, DT is not the only way to instantiate
> > > > devices, C code can still do it.
> > > > 
> > > > Also, if this one line removal has no side effects, then how was it
> > > > even needed? We can always add it back if there's some argument for
> > > > why it is needed.
> > > 
> > > Okay, so I take this as you mostly agreeing with the rationale of this
> > > patch.
> > 
> > For some general background on this: I was originally using this for DP
> > support on Tegra (though that ended up never getting merged because of a
> > particularily frustrating episode of trying to get better link training
> > support into the core helpers) and use it as a means to obtain the I2C
> > controller used for DDC. On Tegra, and I suspect other devices as well,
> > the DP AUX controller is separate from the encoder, so the idea was to
> > link them together using a standard ddc-i2c-bus phandle.
> > 
> > I ended up not needing that because the encoder and DP AUX controller
> > are so tightly linked on Tegra that I need direct access to the DP AUX
> > anyway and can therefore directly get the I2C controller from that.
> > 
> > If there aren't any other users of this, I suppose we could simply
> > remove the line. Should someone turn up in the future and require the
> > I2C controller to be looked up from a phandle we could add it again,
> > at which point we'd have to investigate again how to get rid of the
> > errors.
> > 
> > Acked-by: Thierry Reding 
> 
> I'm going to have to retract that: I just noticed that this patch breaks
> eDP for Venice2 (and presumably all Tegra124 Nyan boards as well, though
> I don't have those to test with).
> 
> My description above isn't quite correct. For eDP device we do use the
> ddc-i2c-bus property in DT to denote which I2C bus to use for probing
> the EDID. So the reason why eDP now breaks is because the simple-panel
> driver will look for the I2C adapter, not find a matching one and defer
> probe (indefinitely).
> 
> A, perhaps nicer, alternative I found to make it work is the below
> patch. Would that be more reasonable? Looping in Wolfram.
> 
> Thierry
> --- >8 ---
> diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
> index 8d474bb1dc15..f88527a61cd1 100644
> --- a/drivers/i2c/i2c-core-of.c
> +++ b/drivers/i2c/i2c-core-of.c
> @@ -118,6 +118,14 @@ static int of_dev_node_match(struct device *dev, void 
> *data)
>   return dev->of_node == data;
>  }
>  
> +static int of_parent_node_match(struct device *dev, void *data)
> +{
> + if (dev->parent)
> + return dev->parent->of_node == data;
> +
> + return 0;
> +}
> +
>  /* must call put_device() when done with returned i2c_client device */
>  struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
>  {
> @@ -143,6 +151,9 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
> device_node *node)
>   struct i2c_adapter *adapter;
>  
>   dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
> + if (!dev)
> + dev = bus_find_device(_bus_type, NULL, node, 
> of_parent_node_match);
> +
>   if (!dev)
>   return NULL;
>  

I'd like to point out that a lot of I2C bus drivers actually do the same
thing as the DRM AUX helpers used to do:

$ git grep -n 'dev.of_node.*=' -- drivers/i2c/busses/
drivers/i2c/busses/i2c-altera.c:467:idev->adapter.dev.of_node = 
pdev->dev.of_node;
drivers/i2c/busses/i2c-aspeed.c:882:bus->adap.dev.of_node = 
pdev->dev.of_node;

Re: [PATCH] drm: don't link DP aux i2c adapter to the hardware device node

[Thierry Reding]

On Mon, Feb 05, 2018 at 05:29:09PM +0100, Lucas Stach wrote:
> Am Montag, den 05.02.2018, 17:11 +0100 schrieb Thierry Reding:
> > On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Reding wrote:
> > > On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
> > > > Hi Rob,
> > > > 
> > > > Am Mittwoch, den 29.03.2017, 08:56 -0500 schrieb Rob Herring:
> > > > > On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding
> > > > > > > > >  wrote:
> > > > > > On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote:
> > > > > > > The i2c adapter on DP AUX is purely a software construct. Linking
> > > > > > > it to the device node of the parent device is wrong, as it leads 
> > > > > > > to
> > > > > > > 2 devices sharing the same device node, which is bad practice, as
> > > > > > 
> > > > > > Who says that two devices can't share the same device node? It's 
> > > > > > done
> > > > > > all the time.
> > > > > 
> > > > > It's done *some of the time* and I would not consider it best 
> > > > > practice.
> > > > > 
> > > > > > > well as the i2c trying to populate children of the i2c adapter by
> > > > > > > looking at the child device nodes of the parent device.
> > > > > > 
> > > > > > A set of patches landed in v4.9 to work around this issue in a 
> > > > > > better
> > > > > > way. See:
> > > > > > 
> > > > > > 98b00488459e dt-bindings: i2c: Add support for 'i2c-bus' 
> > > > > > subnode
> > > > > > 7e4c224abfe8 i2c: core: Add support for 'i2c-bus' subnode
> > > > > 
> > > > > What does this buy us? I don't see why this needs to be in DT either.
> > > > > Contrary to popular belief, DT is not the only way to instantiate
> > > > > devices, C code can still do it.
> > > > > 
> > > > > Also, if this one line removal has no side effects, then how was it
> > > > > even needed? We can always add it back if there's some argument for
> > > > > why it is needed.
> > > > 
> > > > Okay, so I take this as you mostly agreeing with the rationale of this
> > > > patch.
> > > 
> > > For some general background on this: I was originally using this for DP
> > > support on Tegra (though that ended up never getting merged because of a
> > > particularily frustrating episode of trying to get better link training
> > > support into the core helpers) and use it as a means to obtain the I2C
> > > controller used for DDC. On Tegra, and I suspect other devices as well,
> > > the DP AUX controller is separate from the encoder, so the idea was to
> > > link them together using a standard ddc-i2c-bus phandle.
> > > 
> > > I ended up not needing that because the encoder and DP AUX controller
> > > are so tightly linked on Tegra that I need direct access to the DP AUX
> > > anyway and can therefore directly get the I2C controller from that.
> > > 
> > > If there aren't any other users of this, I suppose we could simply
> > > remove the line. Should someone turn up in the future and require the
> > > I2C controller to be looked up from a phandle we could add it again,
> > > at which point we'd have to investigate again how to get rid of the
> > > errors.
> > > 
> > > Acked-by: Thierry Reding 
> > 
> > I'm going to have to retract that: I just noticed that this patch breaks
> > eDP for Venice2 (and presumably all Tegra124 Nyan boards as well, though
> > I don't have those to test with).
> > 
> > My description above isn't quite correct. For eDP device we do use the
> > ddc-i2c-bus property in DT to denote which I2C bus to use for probing
> > the EDID. So the reason why eDP now breaks is because the simple-panel
> > driver will look for the I2C adapter, not find a matching one and defer
> > probe (indefinitely).
> > 
> > A, perhaps nicer, alternative I found to make it work is the below
> > patch. Would that be more reasonable? Looping in Wolfram.
> 
> Taking a step back from the immediate breakage: why do you need the
> ddc-i2c-bus phandle on the eDP panel at all? I would consider this DT
> buggy, as it tries to point to something which is purely a software
> construct. It's not like you are likely to use any other i2c adapter to
> get the eDP panel EDID than the eDP AUX adapter.
> 
> I know this is trading different levels of breakage, but without this
> patch I'm forced to describe a (not actually existent) i2c-bus in DT on
> eDP bridges, to shut down the warnings from the i2c core when it tries
> to populate child devices of the bridge that aren't i2c devices.

So the reason why we have the ddc-i2c-bus property is because the panel
is a free-standing device tree node and therefore doesn't have any
knowledge of AUX. I guess one could argue that this is itself a problem
and I'd agree with that. But things are what they are, and we have this
device tree that used to work but this patch renders these devices more
or less useless (they don't really come with a debug UART or anything,
so display is the only thing that you can use to diagnose issues).

Perhaps the solution is that we need 

Re: Questions on page flips and atomic modeset

[Ville Syrjälä]

On Mon, Feb 05, 2018 at 06:03:25PM +0200, Oleksandr Andrushchenko wrote:
> Hello,
> 
> 
> I have a DRM driver which implements display protocol for Xen [1]
> and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
> tells the other end that some display buffer needs to be displayed,
> e.g. it is issued by the frontend DRM driver to the corresponding
> backend when the former wants to display a buffer.
> Two notes:
> 1. Communication between two remote parties can obviously fail.
> 2. At the moment only primary plane is supported, so we can think of
> the display buffer as of CRTC's primary fb.
> 
> There are two APIs available for user-space to initiate a page-flip
> (please correct me if I am wrong here): legacy via DRM_IOCTL_MODE_PAGE_FLIP
> and more recent via DRM_IOCTL_MODE_ATOMIC. My current implementation
> (which is 4.9 based) uses drm_crtc_funcs.page_flip callback to send
> XENDISPL_OP_PG_FLIP request to the backend, so if communication fails
> I can return an error code, so the DRM core knows that page flip
> cannot be done.
> 
> But now I am about to enable page flipping via DRM_IOCTL_MODE_ATOMIC for
> which this happens without DRM_IOCTL_MODE_PAGE_FLIP, but via .atomic_check +
> .atomic_flush callbacks.
> 
> The solution I have in mind is that I move the XENDISPL_OP_PG_FLIP request
> to the .atomic_flush callback which seems to be the right place to serve
> both DRM_IOCTL_MODE_PAGE_FLIP and DRM_IOCTL_MODE_ATOMIC (is this?).
> 
> The questions I have with this are:
> 
> 1. What is the framebuffer I can send to the backend?
> I assume I can use crtc->primary->fb from 
> drm_crtc_helper_funcs.atomic_flush,
> is this assumption correct?

Planes are explicit in the atomic world, so you should just deal with
the plane if and when it's part of the drm_atomic_state. Look at eg.
drm_atomic_helper_commit_planes() how to figure out what's in the
state. And I guess you're already planning on using that helper since
you mention .atomic_flush().

One should really think of the drm_atomic_state as more of a transaction
rather than as a state (since not all objects need be part of it).

> 
> 2. Is the check (either to send or not) for crtc->primary->fb != NULL 
> enough?
> I assume there are other cases when .atomic_flush gets called,
> so is there a way I can filter out unneeded cases? E.g. those which
> are not for page flipping?

Each object taking part in the transaction will have an associated
new state and old state. You can compare the two to figure out what
changed, and in addition there may already some flags in the base
class for the state that indicate what may have changed (eg.
drm_crtc_state::mode_changed etc.). Such flags may be set by the
core to help figure out what needs doing.

> 
> 3. If communication with the backend fails there is no way for me
> to tell the DRM core about this as .atomic_flush is called after
> "the point of no return". Do you think I can remember the error
> code and report it next time .atomic_check is called? So, other page
> flips will not run on broken connection, for example.

Do you know when it might fail? If so you should implement the appropriate
checks in .atomic_check() etc. to try and make sure it never happens
(barring a total hardware failure for example).

Generally what we (i915) do is try to check everything up front, but if
an unexpected error does happen later we just muddle through and log an
error.

For us I think the most common late failure is DP link training failure.
That we can't fully check up front since it depends on external factors:
sink, dongles, cabling, etc. For those we added a new connector property
to signal to userspace that the link is having issues, allowing
userspace to reconfigure things such that we lower the link bandwidth
requirements.

The link_status mechanism could perhaps be used to to work around other
"late errors". But in general if you want to somehow fix that error you
have to know what caused it, no? So if you just get a random error for
seemingly no reason there's very little you can do apart from blindly
retrying and logging an error. For the DP case the fallback mechanism is
pretty clear: reduce link rate and/or number of lanes.

As for signalling the error in the next ioctl call, that could be done
I suppose. But again the question is how would userspace know what
(if anything) it can do to fix the problem?

> 
> 4. As per my understanding I cannot put XENDISPL_OP_PG_FLIP request
> into .atomic_check as the check doesn't guarantee that .atomic_flush
> will follow. Is this correct or there is a more neat solution exists?

Thou shalt not touch the hardware until .atomic_commit(). Note that
.atomic_commit() itself is still allowed to fail, but only if you
can fail atomically.

The .atomic_flush() & co. helper stuff is designed in a way that
expects no failures at that late stage of the commit. If that
doesn't suit your hardware design then you may opt to not use the
helper.

Also note that non-blocking 

Re: [PATCH] drm: don't link DP aux i2c adapter to the hardware device node

[Lucas Stach]

Am Montag, den 05.02.2018, 17:11 +0100 schrieb Thierry Reding:
> On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Reding wrote:
> > On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
> > > Hi Rob,
> > > 
> > > Am Mittwoch, den 29.03.2017, 08:56 -0500 schrieb Rob Herring:
> > > > On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding
> > > > > > > >  wrote:
> > > > > On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote:
> > > > > > The i2c adapter on DP AUX is purely a software construct. Linking
> > > > > > it to the device node of the parent device is wrong, as it leads to
> > > > > > 2 devices sharing the same device node, which is bad practice, as
> > > > > 
> > > > > Who says that two devices can't share the same device node? It's done
> > > > > all the time.
> > > > 
> > > > It's done *some of the time* and I would not consider it best practice.
> > > > 
> > > > > > well as the i2c trying to populate children of the i2c adapter by
> > > > > > looking at the child device nodes of the parent device.
> > > > > 
> > > > > A set of patches landed in v4.9 to work around this issue in a better
> > > > > way. See:
> > > > > 
> > > > > 98b00488459e dt-bindings: i2c: Add support for 'i2c-bus' 
> > > > > subnode
> > > > > 7e4c224abfe8 i2c: core: Add support for 'i2c-bus' subnode
> > > > 
> > > > What does this buy us? I don't see why this needs to be in DT either.
> > > > Contrary to popular belief, DT is not the only way to instantiate
> > > > devices, C code can still do it.
> > > > 
> > > > Also, if this one line removal has no side effects, then how was it
> > > > even needed? We can always add it back if there's some argument for
> > > > why it is needed.
> > > 
> > > Okay, so I take this as you mostly agreeing with the rationale of this
> > > patch.
> > 
> > For some general background on this: I was originally using this for DP
> > support on Tegra (though that ended up never getting merged because of a
> > particularily frustrating episode of trying to get better link training
> > support into the core helpers) and use it as a means to obtain the I2C
> > controller used for DDC. On Tegra, and I suspect other devices as well,
> > the DP AUX controller is separate from the encoder, so the idea was to
> > link them together using a standard ddc-i2c-bus phandle.
> > 
> > I ended up not needing that because the encoder and DP AUX controller
> > are so tightly linked on Tegra that I need direct access to the DP AUX
> > anyway and can therefore directly get the I2C controller from that.
> > 
> > If there aren't any other users of this, I suppose we could simply
> > remove the line. Should someone turn up in the future and require the
> > I2C controller to be looked up from a phandle we could add it again,
> > at which point we'd have to investigate again how to get rid of the
> > errors.
> > 
> > Acked-by: Thierry Reding 
> 
> I'm going to have to retract that: I just noticed that this patch breaks
> eDP for Venice2 (and presumably all Tegra124 Nyan boards as well, though
> I don't have those to test with).
> 
> My description above isn't quite correct. For eDP device we do use the
> ddc-i2c-bus property in DT to denote which I2C bus to use for probing
> the EDID. So the reason why eDP now breaks is because the simple-panel
> driver will look for the I2C adapter, not find a matching one and defer
> probe (indefinitely).
> 
> A, perhaps nicer, alternative I found to make it work is the below
> patch. Would that be more reasonable? Looping in Wolfram.

Taking a step back from the immediate breakage: why do you need the
ddc-i2c-bus phandle on the eDP panel at all? I would consider this DT
buggy, as it tries to point to something which is purely a software
construct. It's not like you are likely to use any other i2c adapter to
get the eDP panel EDID than the eDP AUX adapter.

I know this is trading different levels of breakage, but without this
patch I'm forced to describe a (not actually existent) i2c-bus in DT on
eDP bridges, to shut down the warnings from the i2c core when it tries
to populate child devices of the bridge that aren't i2c devices.

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

Re: [PATCH] drm: don't link DP aux i2c adapter to the hardware device node

[Thierry Reding]

On Wed, Apr 05, 2017 at 02:04:31PM +0200, Thierry Reding wrote:
> On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
> > Hi Rob,
> > 
> > Am Mittwoch, den 29.03.2017, 08:56 -0500 schrieb Rob Herring:
> > > On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding
> > >  wrote:
> > > > On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote:
> > > >> The i2c adapter on DP AUX is purely a software construct. Linking
> > > >> it to the device node of the parent device is wrong, as it leads to
> > > >> 2 devices sharing the same device node, which is bad practice, as
> > > >
> > > > Who says that two devices can't share the same device node? It's done
> > > > all the time.
> > > 
> > > It's done *some of the time* and I would not consider it best practice.
> > > 
> > > >> well as the i2c trying to populate children of the i2c adapter by
> > > >> looking at the child device nodes of the parent device.
> > > >
> > > > A set of patches landed in v4.9 to work around this issue in a better
> > > > way. See:
> > > >
> > > > 98b00488459e dt-bindings: i2c: Add support for 'i2c-bus' subnode
> > > > 7e4c224abfe8 i2c: core: Add support for 'i2c-bus' subnode
> > > 
> > > What does this buy us? I don't see why this needs to be in DT either.
> > > Contrary to popular belief, DT is not the only way to instantiate
> > > devices, C code can still do it.
> > > 
> > > Also, if this one line removal has no side effects, then how was it
> > > even needed? We can always add it back if there's some argument for
> > > why it is needed.
> > 
> > Okay, so I take this as you mostly agreeing with the rationale of this
> > patch.
> 
> For some general background on this: I was originally using this for DP
> support on Tegra (though that ended up never getting merged because of a
> particularily frustrating episode of trying to get better link training
> support into the core helpers) and use it as a means to obtain the I2C
> controller used for DDC. On Tegra, and I suspect other devices as well,
> the DP AUX controller is separate from the encoder, so the idea was to
> link them together using a standard ddc-i2c-bus phandle.
> 
> I ended up not needing that because the encoder and DP AUX controller
> are so tightly linked on Tegra that I need direct access to the DP AUX
> anyway and can therefore directly get the I2C controller from that.
> 
> If there aren't any other users of this, I suppose we could simply
> remove the line. Should someone turn up in the future and require the
> I2C controller to be looked up from a phandle we could add it again,
> at which point we'd have to investigate again how to get rid of the
> errors.
> 
> Acked-by: Thierry Reding 

I'm going to have to retract that: I just noticed that this patch breaks
eDP for Venice2 (and presumably all Tegra124 Nyan boards as well, though
I don't have those to test with).

My description above isn't quite correct. For eDP device we do use the
ddc-i2c-bus property in DT to denote which I2C bus to use for probing
the EDID. So the reason why eDP now breaks is because the simple-panel
driver will look for the I2C adapter, not find a matching one and defer
probe (indefinitely).

A, perhaps nicer, alternative I found to make it work is the below
patch. Would that be more reasonable? Looping in Wolfram.

Thierry
--- >8 ---
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 8d474bb1dc15..f88527a61cd1 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -118,6 +118,14 @@ static int of_dev_node_match(struct device *dev, void 
*data)
return dev->of_node == data;
 }
 
+static int of_parent_node_match(struct device *dev, void *data)
+{
+   if (dev->parent)
+   return dev->parent->of_node == data;
+
+   return 0;
+}
+
 /* must call put_device() when done with returned i2c_client device */
 struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
 {
@@ -143,6 +151,9 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
device_node *node)
struct i2c_adapter *adapter;
 
dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
+   if (!dev)
+   dev = bus_find_device(_bus_type, NULL, node, 
of_parent_node_match);
+
if (!dev)
return NULL;
 


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

[Bug 104216] Firefox quirks (black and/or white squares)

[bugzilla-daemon]

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

--- Comment #13 from Emil Velikov  ---
(In reply to Germano Massullo from comment #12)
> Is there anything else I can do to retrieve useful informations?
> Thank you


You can track (git bisect) which version of Mesa, ideally which commit, caused
the regression. You will need to rebuild mesa a few times, so ensure you use
the exact same build options as in your distro packaging.

-- 
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 v2 2/2] drm/i915/cmdparser: Do not check past the cmd length.

[Chris Wilson]

Quoting Michal Srb (2018-02-05 15:17:45)
> The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
> possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
> In that case check_cmd will read bits from the following command, or even past
> the end of the buffer.
> 
> If the offset ends up outside of the command length, reject the command.
> 
> Signed-off-by: Michal Srb 

Looks good, both
Reviewed-by: Chris Wilson 

I'll resend them to intel-gfx@ so CI picks them up for the checklist.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Gerd Hoffmann]

On Mon, Feb 05, 2018 at 03:46:17PM +0100, Tomeu Vizoso wrote:
> On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:
> >Hi,
> > 
> > > > Why not use virtio-vsock to run the wayland protocol? I don't like
> > > > the idea to duplicate something with very simliar functionality in
> > > > virtio-gpu.
> > > 
> > > The reason for abandoning that approach was the type of objects that
> > > could be shared via virtio-vsock would be extremely limited. Besides
> > > that being potentially confusing to users, it would mean from the
> > > implementation side that either virtio-vsock would gain a dependency on
> > > the drm subsystem, or an appropriate abstraction for shareable buffers
> > > would need to be added for little gain.
> > 
> > Well, no.  The idea is that virtio-vsock and virtio-gpu are used largely
> > as-is, without knowing about each other.  The guest wayland proxy which
> > does the buffer management talks to both devices.
> 
> Note that the proxy won't know anything about buffers if clients opt-in for
> zero-copy support (they allocate the buffers in a way that allows for
> sharing with the host).

Hmm?  I'm assuming the wayland client (in the guest) talks to the
wayland proxy, using the wayland protocol, like it would talk to a
wayland display server.  Buffers must be passed from client to
server/proxy somehow, probably using fd passing, so where is the
problem?

Or did I misunderstand the role of the proxy?

> > > > If you have a guest proxy anyway using virtio-sock for the protocol
> > > > stream and virtio-gpu for buffer sharing (and some day 3d rendering
> > > > too) should work fine I think.
> > > 
> > > If I understand correctly your proposal, virtio-gpu would be used for
> > > creating buffers that could be shared across domains, but something
> > > equivalent to SCM_RIGHTS would still be needed in virtio-vsock?
> > 
> > Yes, the proxy would send a reference to the buffer over virtio-vsock.
> > I was more thinking about a struct specifying something like
> > "ressource-id 42 on virtio-gpu-pci device in slot 1:23.0" instead of
> > using SCM_RIGHTS.
> 
> Can you extend on this? I'm having trouble figuring out how this could work
> in a way that keeps protocol data together with the resources it refers to.

Don't know much about the wayland protocol.  Assuming you are passing
buffers as file handles, together with some information what kind of
buffer this is (sysv shm, dma-buf, ...).

We have a proxy on both ends.  One running in the guest, one on the host
(be it qemu or some external one).  So these two have to agree on how to
pass buffers from one to the other.  One way would be to have them talk
a simple meta protocol to each other, with "here comes a chunk wayland
protocol to pass along" and "here is a buffer mgmt message".  Possibly
it is better to extend the wayland protocol to also cover this new kind
of buffer, so you don't need the meta protocol.

The proxies would talk normal wayland protocol to the client (in the
guest) and the server (on the host).  They will have to transform the
buffer into something they can pass along using the wayland protocol.

> > > > What is the plan for the host side? I see basically two options. Either
> > > > implement the host wayland proxy directly in qemu. Or
> > > > implement it as separate process, which then needs some help from
> > > > qemu to get access to the buffers. The later would allow qemu running
> > > > independant from the desktop session.
> > > 
> > > Regarding synchronizing buffers, this will stop becoming needed in
> > > subsequent commits as all shared memory is allocated in the host and
> > > mapped to the guest via KVM_SET_USER_MEMORY_REGION.
> > 
> > --verbose please.  The qemu patches linked from the cover letter not
> > exactly helpful in understanding how all this is supposed to work.
> 
> A client will allocate a buffer with DRM_VIRTGPU_RESOURCE_CREATE, export it
> and pass the FD to the compositor (via the proxy).
> 
> During resource creation, QEMU would allocate a shmem buffer and map it into
> the guest with KVM_SET_USER_MEMORY_REGION.

So the buffer magically shows up somewhere in the physical address space
of the guest?  That kind if magic usually isn't a very good idea.

> When a FD comes from the compositor, QEMU mmaps it and maps that virtual
> address to the guest via KVM_SET_USER_MEMORY_REGION.
> 
> When the guest proxy reads from the winsrv socket, it will get a FD that
> wraps the buffer referenced above.
> 
> When the client reads from the guest proxy, it would get a FD that
> references that same buffer and would mmap it. At that point, the client is
> reading from the same physical pages where the compositor wrote to.

Hmm.  I allways assumed the wayland client allocates the buffers, not
the server.  Is that wrong?

What is your plan for 3d acceleration support?

> To be clear, I'm not against solving this via some form of restricted FD
> passing in virtio-vsock, but Stefan (added to CC) thought that it would be
> 

Questions on page flips and atomic modeset

[Oleksandr Andrushchenko]

Hello,


I have a DRM driver which implements display protocol for Xen [1]
and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
tells the other end that some display buffer needs to be displayed,
e.g. it is issued by the frontend DRM driver to the corresponding
backend when the former wants to display a buffer.
Two notes:
1. Communication between two remote parties can obviously fail.
2. At the moment only primary plane is supported, so we can think of
the display buffer as of CRTC's primary fb.

There are two APIs available for user-space to initiate a page-flip
(please correct me if I am wrong here): legacy via DRM_IOCTL_MODE_PAGE_FLIP
and more recent via DRM_IOCTL_MODE_ATOMIC. My current implementation
(which is 4.9 based) uses drm_crtc_funcs.page_flip callback to send
XENDISPL_OP_PG_FLIP request to the backend, so if communication fails
I can return an error code, so the DRM core knows that page flip
cannot be done.

But now I am about to enable page flipping via DRM_IOCTL_MODE_ATOMIC for
which this happens without DRM_IOCTL_MODE_PAGE_FLIP, but via .atomic_check +
.atomic_flush callbacks.

The solution I have in mind is that I move the XENDISPL_OP_PG_FLIP request
to the .atomic_flush callback which seems to be the right place to serve
both DRM_IOCTL_MODE_PAGE_FLIP and DRM_IOCTL_MODE_ATOMIC (is this?).

The questions I have with this are:

1. What is the framebuffer I can send to the backend?
I assume I can use crtc->primary->fb from 
drm_crtc_helper_funcs.atomic_flush,

is this assumption correct?

2. Is the check (either to send or not) for crtc->primary->fb != NULL 
enough?

I assume there are other cases when .atomic_flush gets called,
so is there a way I can filter out unneeded cases? E.g. those which
are not for page flipping?

3. If communication with the backend fails there is no way for me
to tell the DRM core about this as .atomic_flush is called after
"the point of no return". Do you think I can remember the error
code and report it next time .atomic_check is called? So, other page
flips will not run on broken connection, for example.

4. As per my understanding I cannot put XENDISPL_OP_PG_FLIP request
into .atomic_check as the check doesn't guarantee that .atomic_flush
will follow. Is this correct or there is a more neat solution exists?

Thank you very much for you time,
Oleksandr Andrushchenko


[1] 
http://elixir.free-electrons.com/linux/v4.15/source/include/xen/interface/io/displif.h


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

Re: [RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Ludovic Desroches]

On Mon, Feb 05, 2018 at 03:06:33PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 5, 2018 at 10:47 AM, Ludovic Desroches
>  wrote:
> > Use GPIO descriptors instead of relying on the old method.
> 
> Reviewed-by: Andy Shevchenko 
> 
> Though few nitpicks below.
> 
> 
> > --- a/drivers/video/fbdev/atmel_lcdfb.c
> > +++ b/drivers/video/fbdev/atmel_lcdfb.c
> > @@ -18,6 +18,7 @@
> >  #include 
> >  #include 
> >  #include 
> 
> > +#include 
> 
> I think you forgot to remove of_gpio.h.

Right. I'll remove it.

> 
> >  #include 
> >  #include 
> >  #include 
> 
> > struct device_node *display_np;
> > struct device_node *timings_np;
> > struct display_timings *timings;
> > -   enum of_gpio_flags flags;
> > struct atmel_lcdfb_power_ctrl_gpio *og;
> > bool is_gpio_power = false;
> > int ret = -ENOENT;
> > -   int i, gpio;
> > +   int i;
> > +   struct gpio_desc *gpiod;
> 
> I would rather preserve reversed tree style, i.e. put longer line upper.

Ok.

> 
> 
> > +   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
> > +   gpiod = devm_gpiod_get_index_optional(dev,
> > +   "atmel,power-control", i, GPIOD_ASIS);
> > +   if (!gpiod)
> > continue;
> 
> What about IS_ERR() case?

if (!gpiod || IS_ERR(gpiod))
continue;

Thanks.

> 
> >
> > og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
> > if (!og)
> > goto put_display_node;
> >
> > +   og->gpiod = gpiod;
> > is_gpio_power = true;
> >
> > +   ret = gpiod_direction_output(gpiod, 
> > gpiod_is_active_low(gpiod));
> > if (ret) {
> 
> I'm not sure this will be needed if you check IS_ERR() above.
> 

When in doubt, I keep it.

Regards

Ludovic

> > +   dev_err(dev, "set direction output gpio 
> > atmel,power-control[%d] failed\n", i);
> > goto put_display_node;
> > }
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/10] drm/amdgpu: Handle 64-bit return from drm_crtc_vblank_count()

[Harry Wentland]

On 2018-02-03 12:12 AM, Dhinakaran Pandiyan wrote:
> 570e86963a51 ("drm: Widen vblank count to 64-bits [v3]") changed the
> return type for drm_crtc_vblank_count() to u64. This could cause
> potential problems if the return value is used in arithmetic operations
> with a 32-bit reference HW vblank count. Explicitly typecasting this down
> to u32 either fixes a potential problem or serves to add clarity in case
> the typecasting was implicitly done.
> 
> Cc: Keith Packard 
> Cc: Alex Deucher 
> Cc: Harry Wentland 
> Signed-off-by: Dhinakaran Pandiyan 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 2 +-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index 38d47559f098..c2fa5d55f04e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -207,7 +207,7 @@ int amdgpu_crtc_page_flip_target(struct drm_crtc *crtc,
>   amdgpu_bo_unreserve(new_abo);
>  
>   work->base = base;
> - work->target_vblank = target - drm_crtc_vblank_count(crtc) +
> + work->target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
>   amdgpu_get_vblank_counter_kms(dev, work->crtc_id);
>  
>   /* we borrow the event spin lock for protecting flip_wrok */
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 1ce4c98385e3..b7254a29b34a 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3836,7 +3836,7 @@ static void amdgpu_dm_do_flip(struct drm_crtc *crtc,
>  
>  
>   /* Prepare wait for target vblank early - before the fence-waits */
> - target_vblank = target - drm_crtc_vblank_count(crtc) +
> + target_vblank = target - (uint32_t)drm_crtc_vblank_count(crtc) +
>   amdgpu_get_vblank_counter_kms(crtc->dev, 
> acrtc->crtc_id);
>  
>   /* TODO This might fail and hence better not used, wait
> @@ -3982,7 +3982,7 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
>   amdgpu_dm_do_flip(
>   crtc,
>   fb,
> - drm_crtc_vblank_count(crtc) + *wait_for_vblank,
> + (uint32_t)drm_crtc_vblank_count(crtc) + 
> *wait_for_vblank,
>   dm_state->context);
>   }
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] drm/i915/cmdparser: Do not check past the cmd length.

[Michal Srb]

The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
In that case check_cmd will read bits from the following command, or even past
the end of the buffer.

If the offset ends up outside of the command length, reject the command.

Signed-off-by: Michal Srb 
---

 v2: Return false instead of continuing - reject the command instead of
 ignoring.

 drivers/gpu/drm/i915/i915_cmd_parser.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index de7ec59433d1..ef7ad016d67c 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1218,6 +1218,12 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
continue;
}
 
+   if (desc->bits[i].offset >= length) {
+   DRM_DEBUG_DRIVER("CMD: Rejected command 0x%08X, 
too short to check bitmask (%s)\n",
+*cmd, engine->name);
+   return false;
+   }
+
dword = cmd[desc->bits[i].offset] &
desc->bits[i].mask;
 
-- 
2.13.6

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

[PATCH v2 3/3] drm/nouveau/pci: SOR crossbar quirk for 10b0:1b81

[Danilo Krummrich]

On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link
'D' (pad macro 1, link 2) causes failures:

[6.712111] nouveau :01:00.0: bus: MMIO read of  FAULT at 61c880 
[ IBUS ]
[6.724888] nouveau :01:00.0: disp: intr24 8000
[8.716668] nouveau :01:00.0: DRM: base-0: timeout
[   10.716679] nouveau :01:00.0: DRM: base-1: timeout
[   63.511862] nouveau :01:00.0: DRM: EVO timeout

As I'm not able to spot an issue in the driver, I suppose it's
firmware related.

Therefore to work around this issue skip crossbar routing for this
particular macro link and instead use identity mapping.

Signed-off-by: Danilo Krummrich 
---
v2: quirk for the actual macro link instead of the outp index
---
 drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
index d2f9664afcf4..a882e590464b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
@@ -797,6 +797,13 @@ nvkm_device_pci_10de_139b[] = {
{}
 };
 
+static const struct nvkm_device_pci_vendor
+nvkm_device_pci_10de_1b81[] = {
+   /* Gainward GTX 1070 8192 MB */
+   { 0x10b0, 0x1b81, "GeForce GTX 1070", { .outp_links_skip = BIT(4) } },
+   {}
+};
+
 static const struct nvkm_device_pci_device
 nvkm_device_pci_10de[] = {
{ 0x0020, "RIVA TNT" },
@@ -1556,7 +1563,7 @@ nvkm_device_pci_10de[] = {
{ 0x1b06, "GeForce GTX 1080 TI" },
{ 0x1bb7, "Quadro P6000" },
{ 0x1b80, "GeForce GTX 1080" },
-   { 0x1b81, "GeForce GTX 1070" },
+   { 0x1b81, "GeForce GTX 1070", nvkm_device_pci_10de_1b81 },
{ 0x1b82, "GeForce GTX 1070 TI" },
{ 0x1b84, "GeForce GTX 1060 3GB" },
{ 0x1b87, "P104-100" },
-- 
2.14.1

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

[PATCH v2 1/3] drm/nouveau/pci: PCI IDs for pascal architecture

[Danilo Krummrich]

Taken from NVIDIA binary driver (Linux 64-bit, revision 390.25)
from README.txt.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 41 
 1 file changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
index f302d2b5782a..d2f9664afcf4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
@@ -1551,6 +1551,47 @@ nvkm_device_pci_10de[] = {
{ 0x17c2, "GeForce GTX TITAN X" },
{ 0x17c8, "GeForce GTX 980 Ti" },
{ 0x17f0, "Quadro M6000" },
+   { 0x1b00, "TITAN X (Pascal)" },
+   { 0x1b02, "TITAN Xp" },
+   { 0x1b06, "GeForce GTX 1080 TI" },
+   { 0x1bb7, "Quadro P6000" },
+   { 0x1b80, "GeForce GTX 1080" },
+   { 0x1b81, "GeForce GTX 1070" },
+   { 0x1b82, "GeForce GTX 1070 TI" },
+   { 0x1b84, "GeForce GTX 1060 3GB" },
+   { 0x1b87, "P104-100" },
+   { 0x1ba0, "GeForce GTX 1080M" },
+   { 0x1ba1, "GeForce GTX 1070M" },
+   { 0x1bb0, "Quadro P5000" },
+   { 0x1bb1, "Quadro P4000" },
+   { 0x1bb6, "Quadro P5000" },
+   { 0x1bb7, "Quadro P4000" },
+   { 0x1bb8, "Quadro P3000" },
+   { 0x1be0, "GeForce GTX 1080M" },
+   { 0x1be1, "GeForce GTX 1070M" },
+   { 0x1bc7, "P104-101" },
+   { 0x1c02, "GeForce GTX 1060 3GB" },
+   { 0x1c03, "GeForce GTX 1060 6GB" },
+   { 0x1c04, "GeForce GTX 1050 5GB" },
+   { 0x1c06, "GeForce GTX 1050 6GB" },
+   { 0x1c07, "P106-100" },
+   { 0x1c09, "P106-090" },
+   { 0x1c20, "GeForce GTX 1060M" },
+   { 0x1c21, "GeForce GTX 1050M TI" },
+   { 0x1c22, "GeForce GTX 1050M" },
+   { 0x1c30, "Quadro P2000" },
+   { 0x1c60, "GeForce GTX 1060M 6GB" },
+   { 0x1c61, "GeForce GTX 1050M TI" },
+   { 0x1c81, "GeForce GTX 1050" },
+   { 0x1c82, "GeForce GTX 1050 TI" },
+   { 0x1c8c, "GeForce GTX 1050M TI" },
+   { 0x1c8d, "GeForce GTX 1050M" },
+   { 0x1cb1, "Quadro P2000" },
+   { 0x1cb2, "Quadro P600" },
+   { 0x1cb3, "Quadro P400" },
+   { 0x1d01, "GeForce GT 1030" },
+   { 0x1d10, "GeForce MX 150" },
+   { 0x1d12, "GeForce MX 150" },
{}
 };
 
-- 
2.14.1

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

[PATCH v2 2/3] drm/nouveau/disp: quirk for SOR crossbar routing

[Danilo Krummrich]

With DCB 4.1 implemented by VBIOS since GM20x GPUs, SOR crossbar
routing should be possible, such that any SOR sublink can drive
any macro link.

Unfortunately, there's at least one card where some SOR sublinks
being connected to a particular macro link are causing failures.

To work around this issue, supply a quirk for such cards which
prevents a dynamic mapping of SOR sublink and macro link and
instead relies on identity mapping.

Signed-off-by: Danilo Krummrich 
---
v2: checking actual pad macro and link instead of outp index
---
 drivers/gpu/drm/nouveau/include/nvkm/core/device.h |  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c| 19 +--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/device.h 
b/drivers/gpu/drm/nouveau/include/nvkm/core/device.h
index 560265b15ec2..d384cb03ad85 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/core/device.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/core/device.h
@@ -184,6 +184,7 @@ struct nvkm_device_func {
 struct nvkm_device_quirk {
u8 tv_pin_mask;
u8 tv_gpio;
+   u8 outp_links_skip;
 };
 
 struct nvkm_device_chip {
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
index be9e7f8c3b23..a574746ddd82 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
@@ -99,6 +99,18 @@ nvkm_outp_release(struct nvkm_outp *outp, u8 user)
}
 }
 
+static inline bool
+nvkm_outp_ior_route_quirk(struct nvkm_outp *outp)
+{
+   struct nvkm_device *dev = outp->disp->engine.subdev.device;
+
+   int macro_link = __ffs(outp->info.or) * 2 + outp->info.sorconf.link;
+   if (unlikely(dev->quirk))
+   return !(dev->quirk->outp_links_skip & BIT(macro_link));
+
+   return true;
+}
+
 static inline int
 nvkm_outp_acquire_ior(struct nvkm_outp *outp, u8 user, struct nvkm_ior *ior)
 {
@@ -115,6 +127,7 @@ nvkm_outp_acquire(struct nvkm_outp *outp, u8 user)
struct nvkm_ior *ior = outp->ior;
enum nvkm_ior_proto proto;
enum nvkm_ior_type type;
+   bool route_crossbar = nvkm_outp_ior_route_quirk(outp);
 
OUTP_TRACE(outp, "acquire %02x |= %02x %p", outp->acquired, user, ior);
if (ior) {
@@ -138,7 +151,8 @@ nvkm_outp_acquire(struct nvkm_outp *outp, u8 user)
/* Failing that, a completely unused OR is the next best thing. */
list_for_each_entry(ior, >disp->ior, head) {
if (!ior->asy.outp && ior->type == type && !ior->arm.outp &&
-   (ior->func->route.set || ior->id == __ffs(outp->info.or)))
+   ((ior->func->route.set && route_crossbar) ||
+ior->id == __ffs(outp->info.or)))
return nvkm_outp_acquire_ior(outp, user, ior);
}
 
@@ -147,7 +161,8 @@ nvkm_outp_acquire(struct nvkm_outp *outp, u8 user)
 */
list_for_each_entry(ior, >disp->ior, head) {
if (!ior->asy.outp && ior->type == type &&
-   (ior->func->route.set || ior->id == __ffs(outp->info.or)))
+   ((ior->func->route.set && route_crossbar) ||
+ior->id == __ffs(outp->info.or)))
return nvkm_outp_acquire_ior(outp, user, ior);
}
 
-- 
2.14.1

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

Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86

[Emil Velikov]

On 1 February 2018 at 14:59, Rob Herring  wrote:
> On Wed, Jan 31, 2018 at 12:46 PM, John Stultz  wrote:
>> On Wed, Jan 31, 2018 at 8:01 AM, Emil Velikov  
>> wrote:
>>> On 30 January 2018 at 05:42, John Stultz  wrote:
 On Fri, Jan 26, 2018 at 10:33 AM, Emil Velikov  
 wrote:
> Hi all,
>
> Couple of ideas/notes,
>
> On 10 January 2018 at 20:36, Rob Herring  wrote:
>> On Wed, Jan 10, 2018 at 1:09 PM, John Stultz  
>> wrote:
>>> On Wed, Jan 10, 2018 at 5:48 AM, Rob Herring  wrote:
 On Tue, Jan 9, 2018 at 11:25 PM, John Stultz  
 wrote:
> When building AOSP after updating libdrm project to the
> freedesktop/master branch, I've seen the following build errors:
>
> external/libdrm/intel/Android.mk: error: libdrm_intel

 This is only needed for i915 (not i965) now BTW. I'm not sure at what
 point we stop caring about i915.
> If you're using any other Intel components - say Beignet or the va
> driver, I think those still use libdrm_intel.
>
> An alternative solution IMHO, is to drop/tweak the API to not bother
> libpciaccess.
> I have some ancient cleanup/rework branch
>
> https://github.com/evelikov/libdrm/commits/intel-remove-legacy

 I'm not opposed to this, but I'm really not familiar with intel use
 cases and what would be ok or not there.


>>> The unfortunate part is that people familiar don't have to
>>> time/interest to weight in :-(
>>> I might give it another try, one of these days. Unless someone beats me to 
>>> it.
>>>
> (SHARED_LIBRARIES android-arm64) missing libpciaccess
> (SHARED_LIBRARIES android-arm64) You can set
> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
> intentional, but that may defer real problems until later in the
> build.
>
> Using ALLOW_MISSING_DEPENDENCIES=true when building allows
> things to function properly, but is not ideal.
>
> So basically, while I'm not including the libdrm_intel package
> into the build, just the fact that the Android.mk file references
> libpciaccess which isn't a repo included in AOSP causes the build
> failure.
>
> So it seems we need some sort of conditional filter in the
> Android.mk to skip over it if we're not building for intel.
>
> This is my initial attempt at solving this.
>
> Feedback would be greatly appreciated!
>
> I note that in the AOSP version of libdrm, the reference to
> libpciaccess has been removed. See:
>  
> https://android.googlesource.com/platform/external/libdrm/+/f6a1130dffae8de9ddd0c379066daf1df27fc8af%5E%21/
> So I wonder if it make sense to instead remove this upstream as
> well?

 Only if we drop i915.
>>>
>>> To be more precise, drop i915 for Android builds (I'm not suggesting
>>> dropping it elsewhere, just for the Android.mk). I'm really not sure
>>> which devices might be affected. Anyone able to point me to someone in
>>> Intel who would know?
>>
>> The android-x86 folks would be the ones to ask. I added Chih-Wei.
>>
> A really silly question - how are you triggering any of this if you're
> building on !x86?
> Is that because the GPU driver is not selected thus you we fall-back
> to "build all"?

 I think its mostly due the fact we're using the toplevel Android.mk
 which includes all Android.mk files in subdirectories.

>>> That does not matter. Unless otherwise stated the objects are optional.
>>> Thus they should not be build, unless...
>>>
>>> Android changed the policy or you're somehow building stuff that's not 
>>> required?
>>
>> I don't think its a policy, its seems its just how the toplevel
>> Android.mk file is setup:
>>https://cgit.freedesktop.org/drm/libdrm/tree/Android.mk#n63
>>
>> Where it includes all the Android.mk from all subdirectories, which
>> pulls in the intel/Android.mk, which adds libpciaccess to the
>> LOCAL_SHARED_LIBRARIES
>>https://cgit.freedesktop.org/drm/libdrm/tree/intel/Android.mk#n36
>
> That's not quite right. The build system descends directories til it
> finds an Android.mk. For subdirs under that Android.mk, the Android.mk
> file must descend. That's why we have:
>
> include $(call all-makefiles-under,$(LOCAL_PATH))
>
AFAICT the "include" has nothing to do with what gets build (by default).

This page [1] states that, LOCAL_MODULE_TAGS - it's not set, defaults
to optional.
And anything optional is not build/installed.

[1] https://source.android.com/setup/add-device

 I'm not sure quite how to select a 

Re: [PATCH] drm/bridge/synopsys: dsi: Add 1.31 version support

[Philippe CORNU]

Hi Andrzej,

And many thanks for your good comments

On 02/05/2018 02:03 PM, Andrzej Hajda wrote:
> On 22.01.2018 16:08, Philippe Cornu wrote:
>> From: Philippe CORNU 
>>
>> Add support for the Synopsys DesignWare MIPI DSI version 1.31
>> Two registers need to be updated/added for supporting 1.31:
>> * PHY_TMR_CFG 0x9c (updated)
>>1.30 [31:24] phy_hs2lp_time
>> [23:16] phy_lp2hs_time
>> [14: 0] max_rd_time
>>
>>1.31 [25:16] phy_hs2lp_time
>> [ 9: 0] phy_lp2hs_time
>>
>> * PHY_TMR_RD_CFG 0xf4 (new)
>>1.31 [14: 0] max_rd_time
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 52 
>> +++
>>   1 file changed, 46 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> index 735f38429c06..20a2ca14a7ad 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> @@ -25,7 +25,13 @@
>>   #include 
>>   #include 
>>   
>> +#define HWVER_130   0x31333000  /* IP version 1.30 */
>> +#define HWVER_131   0x31333100  /* IP version 1.31 */
>> +#define HWVER_OLDESTHWVER_130
>> +#define HWVER_NEWESTHWVER_131
>> +
>>   #define DSI_VERSION0x00
>> +#define VERSION GENMASK(31, 8)
>>   
>>   #define DSI_PWR_UP 0x04
>>   #define RESET  0
>> @@ -161,11 +167,12 @@
>>   #define PHY_CLKHS2LP_TIME(lbcc)(((lbcc) & 0x3ff) << 16)
>>   #define PHY_CLKLP2HS_TIME(lbcc)((lbcc) & 0x3ff)
>>   
>> -/* TODO Next register is slightly different between 1.30 & 1.31 IP version 
>> */
>>   #define DSI_PHY_TMR_CFG0x9c
>> -#define PHY_HS2LP_TIME(lbcc)(((lbcc) & 0xff) << 24)
>> -#define PHY_LP2HS_TIME(lbcc)(((lbcc) & 0xff) << 16)
>> -#define MAX_RD_TIME(lbcc)   ((lbcc) & 0x7fff)
>> +#define PHY_HS2LP_TIME_V130(lbcc)   (((lbcc) & 0xff) << 24)
>> +#define PHY_LP2HS_TIME_V130(lbcc)   (((lbcc) & 0xff) << 16)
>> +#define MAX_RD_TIME_V130(lbcc)  ((lbcc) & 0x7fff)
>> +#define PHY_HS2LP_TIME_V131(lbcc)   (((lbcc) & 0x3ff) << 16)
>> +#define PHY_LP2HS_TIME_V131(lbcc)   ((lbcc) & 0x3ff)
>>   
>>   #define DSI_PHY_RSTZ   0xa0
>>   #define PHY_DISFORCEPLL0
>> @@ -204,7 +211,9 @@
>>   #define DSI_INT_ST10xc0
>>   #define DSI_INT_MSK0   0xc4
>>   #define DSI_INT_MSK1   0xc8
>> +
>>   #define DSI_PHY_TMR_RD_CFG 0xf4
>> +#define MAX_RD_TIME_V131(lbcc)  ((lbcc) & 0x7fff)
>>   
>>   #define PHY_STATUS_TIMEOUT_US  1
>>   #define CMD_PKT_STATUS_TIMEOUT_US  2
>> @@ -215,6 +224,7 @@ struct dw_mipi_dsi {
>>  struct drm_bridge *panel_bridge;
>>  struct device *dev;
>>  void __iomem *base;
>> +u32 hw_version;
>>   
>>  struct clk *pclk;
>>  struct clk *px_clk;
>> @@ -616,8 +626,14 @@ static void dw_mipi_dsi_dphy_timing_config(struct 
>> dw_mipi_dsi *dsi)
>>   * note: DSI_PHY_TMR_CFG.MAX_RD_TIME should be in line with
>>   * DSI_CMD_MODE_CFG.MAX_RD_PKT_SIZE_LP (see CMD_MODE_ALL_LP)
>>   */
>> -dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME(0x40)
>> -  | PHY_LP2HS_TIME(0x40) | MAX_RD_TIME(1));
>> +if (dsi->hw_version == HWVER_131) {
>> +dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME_V131(0x40) |
>> +  PHY_LP2HS_TIME_V131(0x40));
>> +dsi_write(dsi, DSI_PHY_TMR_RD_CFG, MAX_RD_TIME_V131(1));
>> +} else {
>> +dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME_V130(0x40) |
>> +  PHY_LP2HS_TIME_V130(0x40) | MAX_RD_TIME_V130(1));
>> +}
>>   
>>  dsi_write(dsi, DSI_PHY_TMR_LPCLK_CFG, PHY_CLKHS2LP_TIME(0x40)
>>| PHY_CLKLP2HS_TIME(0x40));
>> @@ -791,6 +807,28 @@ static const struct drm_bridge_funcs 
>> dw_mipi_dsi_bridge_funcs = {
>>  .attach   = dw_mipi_dsi_bridge_attach,
>>   };
>>   
>> +static void dsi_get_version(struct dw_mipi_dsi *dsi)
>> +{
>> +u32 hw_version;
>> +
>> +clk_prepare_enable(dsi->pclk);
>> +hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
>> +clk_disable_unprepare(dsi->pclk);
>> +
>> +if (hw_version > HWVER_NEWEST) {
>> +DRM_DEBUG("hw version: use 0x%08x for this recent 0x%08x\n",
>> +  HWVER_NEWEST, hw_version);
>> +hw_version = HWVER_NEWEST;
>> +
>> +} else if (hw_version < HWVER_OLDEST) {
>> +DRM_DEBUG("hw version: use 0x%08x for this old 0x%08x\n",
>> +  HWVER_OLDEST, hw_version);
>> +hw_version = HWVER_OLDEST;
>> +}
>> +
>> +dsi->hw_version = hw_version;
>> 

Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.

[Maarten Lankhorst]

Op 05-02-18 om 15:16 schreef Ville Syrjälä:
> On Mon, Feb 05, 2018 at 01:59:05PM +0100, Maarten Lankhorst wrote:
>> Op 02-02-18 om 15:46 schreef Ville Syrjälä:
>>> On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote:
 This will make it possible for userspace to know whether reading
 will block, without blocking on the fd. This makes it possible to
 drain all queued CRC's in blocking mode, without having to reopen
 the fd.

 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/drm_debugfs_crc.c | 19 +++
  1 file changed, 19 insertions(+)

 diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
 b/drivers/gpu/drm/drm_debugfs_crc.c
 index 9dd879589a2c..8af1a74ec64d 100644
 --- a/drivers/gpu/drm/drm_debugfs_crc.c
 +++ b/drivers/gpu/drm/drm_debugfs_crc.c
 @@ -307,10 +307,29 @@ static ssize_t crtc_crc_read(struct file *filep, 
 char __user *user_buf,
return LINE_LEN(crc->values_cnt);
  }
  
 +static unsigned int crtc_crc_poll(struct file *file, poll_table *wait)
 +{
 +  struct drm_crtc *crtc = file->f_inode->i_private;
 +  struct drm_crtc_crc *crc = >crc;
 +  unsigned ret;
 +
 +  poll_wait(file, >wq, wait);
 +
 +  spin_lock_irq(>lock);
 +  if (crc->source && crtc_crc_data_count(crc))
 +  ret = POLLIN;
>>> Most places seem to also set POLLRDNORM. Maybe we should do it as well?
>>>
>>> Apart from that this seems good to me.
>>> Reviewed-by: Ville Syrjälä 
>> Yeah, changed it and pushed, thanks for the suggestion. :)
>>> Could replace the usleep() loop in igt read_one_crc() with
>>> poll/select() I suppose? Either that or we should switch between
>>> blocking and nonblocking dynamically.
>> It could, but it would use 100% of cpu on older kernels that don't support 
>> poll(), if that's not a problem we could do it. :)
> Maybe we can probe for poll support when we create the pipe_crc object?
>
I fear that will make a mess since you would need to support the fallback path 
anyway. I think blindly touching the fd with fcntl is better. :)

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

Re: [PATCH 2/2] drm/i915/cmdparser: Do not check past the cmd length.

[Chris Wilson]

Quoting Michal Srb (2018-02-05 14:29:16)
> The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
> possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
> In that case check_cmd will read bits from the following command, or even past
> the end of the buffer.
> 
> Similarly to how registers are checked - if the offset ends up outside of the
> command length, just ignore it.
> 
> Signed-off-by: Michal Srb 
> ---
>  drivers/gpu/drm/i915/i915_cmd_parser.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index de7ec59433d1..827740b866a8 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -1218,6 +1218,9 @@ static bool check_cmd(const struct intel_engine_cs 
> *engine,
> continue;
> }
>  
> +   if (desc->bits[i].offset >= length)
> +   continue;

Should be return false since the command can't be validated.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/2] drm/virtio: Add window server support

[Tomeu Vizoso]

On 02/05/2018 01:20 PM, Gerd Hoffmann wrote:

   Hi,


Why not use virtio-vsock to run the wayland protocol? I don't like
the idea to duplicate something with very simliar functionality in
virtio-gpu.


The reason for abandoning that approach was the type of objects that
could be shared via virtio-vsock would be extremely limited. Besides
that being potentially confusing to users, it would mean from the
implementation side that either virtio-vsock would gain a dependency on
the drm subsystem, or an appropriate abstraction for shareable buffers
would need to be added for little gain.


Well, no.  The idea is that virtio-vsock and virtio-gpu are used largely
as-is, without knowing about each other.  The guest wayland proxy which
does the buffer management talks to both devices.


Note that the proxy won't know anything about buffers if clients opt-in 
for zero-copy support (they allocate the buffers in a way that allows 
for sharing with the host).



If you have a guest proxy anyway using virtio-sock for the protocol
stream and virtio-gpu for buffer sharing (and some day 3d rendering
too) should work fine I think.


If I understand correctly your proposal, virtio-gpu would be used for
creating buffers that could be shared across domains, but something
equivalent to SCM_RIGHTS would still be needed in virtio-vsock?


Yes, the proxy would send a reference to the buffer over virtio-vsock.
I was more thinking about a struct specifying something like
"ressource-id 42 on virtio-gpu-pci device in slot 1:23.0" instead of
using SCM_RIGHTS.


Can you extend on this? I'm having trouble figuring out how this could 
work in a way that keeps protocol data together with the resources it 
refers to.



If the mechanics of passing presentation data were very complex, I think
this approach would have more merit. But as you can see from the code,
it isn't that bad.


Well, the devil is in the details.  If you have multiple connections you
don't want one being able to stall the others for example.  There are
reasons took quite a while to bring virtio-vsock to the state where it
is today.


Yes, but at the same time there are use cases that virtio-vsock has to 
support but aren't important in this scenario.



What is the plan for the host side? I see basically two options. Either
implement the host wayland proxy directly in qemu. Or
implement it as separate process, which then needs some help from
qemu to get access to the buffers. The later would allow qemu running
independant from the desktop session.


Regarding synchronizing buffers, this will stop becoming needed in
subsequent commits as all shared memory is allocated in the host and
mapped to the guest via KVM_SET_USER_MEMORY_REGION.


--verbose please.  The qemu patches linked from the cover letter not
exactly helpful in understanding how all this is supposed to work.


A client will allocate a buffer with DRM_VIRTGPU_RESOURCE_CREATE, export 
it and pass the FD to the compositor (via the proxy).


During resource creation, QEMU would allocate a shmem buffer and map it 
into the guest with KVM_SET_USER_MEMORY_REGION.


The client would mmap that resource and render to it. Because it's 
backed by host memory, the compositor would be able to read it without 
any further copies.



This is already the case for buffers passed from the compositor to the
clients (see patch 2/2), and I'm working on the equivalent for buffers
from the guest to the host (clients still have to create buffers with
DRM_VIRTGPU_RESOURCE_CREATE but they will be only backend by host memory
so no calls to DRM_VIRTGPU_TRANSFER_TO_HOST are needed).


Same here.  --verbose please.


When a FD comes from the compositor, QEMU mmaps it and maps that virtual 
address to the guest via KVM_SET_USER_MEMORY_REGION.


When the guest proxy reads from the winsrv socket, it will get a FD that 
wraps the buffer referenced above.


When the client reads from the guest proxy, it would get a FD that 
references that same buffer and would mmap it. At that point, the client 
is reading from the same physical pages where the compositor wrote to.


To be clear, I'm not against solving this via some form of restricted FD 
passing in virtio-vsock, but Stefan (added to CC) thought that it would 
be cleaner to do it all within virtio-gpu. This is the thread where it 
was discussed:


https://lkml.kernel.org/r/<2d73a3e1-af70-83a1-0e84-98b5932ea...@collabora.com>

Thanks,

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

Re: [PATCH 1/5] backlight: lp8788: document sysfs attributes

[Daniel Thompson]

On Mon, Feb 05, 2018 at 12:55:50PM +0530, Aishwarya Pant wrote:
> On Thu, Feb 01, 2018 at 11:36:04AM +, Daniel Thompson wrote:
> > On Wed, Jan 31, 2018 at 01:51:21PM +0200, Jani Nikula wrote:
> > > On Wed, 31 Jan 2018, Daniel Thompson  wrote:
> > > > On Fri, Jan 26, 2018 at 08:20:08PM +0530, Aishwarya Pant wrote:
> > > >> Add documentation for sysfs interfaces of lp8788 backlight driver by
> > > >> looking through the code and the git commit history.
> > > >> 
> > > >> Signed-off-by: Aishwarya Pant 
> > > >> ---
> > > >>  Documentation/ABI/testing/sysfs-class-backlight-lp8788 | 10 ++
> > > >>  1 file changed, 10 insertions(+)
> > > >>  create mode 100644 
> > > >> Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > > >> 
> > > >> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lp8788 
> > > >> b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > > >> new file mode 100644
> > > >> index ..c0e565c8d63d
> > > >> --- /dev/null
> > > >> +++ b/Documentation/ABI/testing/sysfs-class-backlight-lp8788
> > > >> @@ -0,0 +1,10 @@
> > > >> +sysfs interface for Texas Instruments lp8788 mfd backlight driver
> > > >> +-
> > > >> +
> > > >> +What: /sys/class/backlight//bl_ctl_mode
> > > >> +Date: Feb, 2013
> > > >> +KernelVersion:v3.10
> > > >> +Contact:  Milo Kim 
> > > >> +Description:
> > > >> +  (RO) Displays whether the brightness is controlled by 
> > > >> the PWM
> > > >> +  input("PWM based") or the I2C register("Register 
> > > >> based").
> > > >
> > > > I rather dislike drivers with this type of "bonus" sysfs controls. I'm
> > > > struggling to come up with any reason why the userspace would want to
> > > > read this control (and I think bl_ctl_mode gets the fewest hits after
> > > > searching with google hits of any search I've tried) . It looks to me 
> > > > like this is debug information that should never have gone into sysfs 
> > > > at all.
> > > 
> > > Agreed. I think the same holds for the other extra sysfs attributes. At
> > > worst, having these prevents the backlight class from adding the names
> > > later on, which is just backwards.
> > 
> > The problem is that they do exist...
> > 
> > For controls which appear to be misplaced debug attributes I think I am
> > happy to nuke the values entirely. It is extremely improbable that any
> > userspace will notice.
> > 
> > Unfortunately some of the controls look like they could be poked by an
> > custom userspace so I'm quite so confident about nuking these ones...and if 
> > we
> > don't nuke we should document (so thanks Aishwarya!). 
> > 
> 
> Hi
> 
> Thanks for reviewing. Should I take it to assume that we would like to keep 
> the
> debug-like attributes in documentation for now?

The opposite I think!

Can you drop patch 1/2 from this series, tidy the maintainer values, etc
and resubmit?

If you want to propose patches to remove the debug attributes from the
TI drivers that's up to you (perhaps adding a dev_dbg() containing
equivalent information). If you want to you are welcome to add to these:
Suggested-by: Daniel Thompson 


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

[PATCH 8/9] drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data object

[Heiko Stuebner]

When using special phy handling operations we'll often need access to
the rockchip_hdmi struct. As the chip-data that occupies the phy_data
pointer initially gets assigned to the rockchip_hdmi struct we can not
re-use this phy_data pointer to hold the reference to the rockchip_hdmi
struct, similar to how meson-hdmi does it for example.

Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 512f8556e7c0..5a62328887d5 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -342,7 +342,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
 void *data)
 {
struct platform_device *pdev = to_platform_device(dev);
-   const struct dw_hdmi_plat_data *plat_data;
+   struct dw_hdmi_plat_data *plat_data;
const struct of_device_id *match;
struct drm_device *drm = data;
struct drm_encoder *encoder;
@@ -357,9 +357,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
return -ENOMEM;
 
match = of_match_node(dw_hdmi_rockchip_dt_ids, pdev->dev.of_node);
-   plat_data = match->data;
+   plat_data = devm_kmemdup(>dev, match->data,
+sizeof(*plat_data), GFP_KERNEL);
+   if (!plat_data)
+   return -ENOMEM;
+
hdmi->dev = >dev;
hdmi->chip_data = plat_data->phy_data;
+   plat_data->phy_data = hdmi;
encoder = >encoder;
 
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
-- 
2.15.1

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

[PATCH 1/9] dt-bindings: add binding for Rockchip hdmi phy using an Innosilicon IP

[Heiko Stuebner]

From: Zheng Yang 

The phy is used so far in two Rockchip socs the rk3228 and the rk3328.

Signed-off-by: Zheng Yang 
Signed-off-by: Heiko Stuebner 
---
 .../bindings/phy/phy-rockchip-inno-hdmi.txt| 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt 
b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt
new file mode 100644
index ..7d36fd8d5d94
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt
@@ -0,0 +1,42 @@
+ROCKCHIP HDMI PHY WITH INNO IP BLOCK
+
+Required properties:
+ - compatible : should be one of the listed compatibles:
+   * "rockchip,rk3228-hdmi-phy",
+   * "rockchip,rk3328-hdmi-phy";
+ - reg : Address and length of the hdmi phy control register set
+ - clocks : phandle + clock specifier for the phy clocks
+ - clock-names : string, clock name, must contain "sysclk" for system
+ control and register configuration and "refclk" for reference
+ crystal oscillator clock input to PLL
+ - #clock-cells: should be 0.
+ - clock-output-names : shall be the name for the output clock.
+ - interrupts : phandle + interrupt specified for the hdmiphy interrupt
+ - #phy-cells : must be 0. See ./phy-bindings.txt for details.
+
+Optional properties for rk3328-hdmi-phy:
+ - nvmem-cells = phandle + nvmem specifier for the cpu-version efuse
+ - nvmem-cell-names : "cpu-version" to read the chip version, required
+ for adjustment to some frequency settings
+
+Example:
+   hdmi_phy: hdmi-phy@1203 {
+   compatible = "rockchip,rk3228-hdmi-phy";
+   reg = <0x1203 0x1>;
+   #phy-cells = <0>;
+   clocks = < PCLK_HDMI_PHY>, <>;
+   clock-names = "sysclk", "refclk";
+   #clock-cells = <0>;
+   clock-output-names = "hdmi_phy";
+   status = "disabled";
+   };
+
+Then the PHY can be used in other nodes such as:
+
+   hdmi: hdmi@200a {
+   compatible = "rockchip,rk3228-dw-hdmi";
+   ...
+   phys = <_phy>;
+   phy-names = "hdmi";
+   ...
+   };
-- 
2.15.1

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

[PATCH 6/9] dt-bindings: allow optional phys in Rockchip dw_hdmi binding

[Heiko Stuebner]

Some newer Rockchip SoCs use an Innosilicon hdmiphy accessed via general
mmio, so allow these to be referenced via the regular phy interfaces
and therefore add optional phy-related properties to the binding.

Signed-off-by: Heiko Stuebner 
---
 Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index adc94fc3c9f8..937bfb472e1d 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -34,6 +34,8 @@ Optional properties
 - clock-names: May contain "cec" as defined in dw_hdmi.txt.
 - clock-names: May contain "grf", power for grf io.
 - clock-names: May contain "vpll", external clock for some hdmi phy.
+- phys: from general PHY binding: the phandle for the PHY device.
+- phy-names: Should be "hdmi" if phys references an external phy.
 
 Example:
 
-- 
2.15.1

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

[PATCH 5/9] drm/rockchip: dw_hdmi: Allow outputs that don't need output switching

[Heiko Stuebner]

So far we always encountered socs with 2 output crtcs needing the driver
to tell the hdmi block which output to connect to. But there also exist
socs with only one crtc like the rk3228, rk3328 and rk3368.

So adapt the register field to simply carry a negative value to signal
that now output-switching is necessary.

Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 1eb02a82fd91..304f61bd2eec 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -36,7 +36,7 @@
  * @lcdsel_lit: reg value of selecting vop little for HDMI
  */
 struct rockchip_hdmi_chip_data {
-   u32 lcdsel_grf_reg;
+   int lcdsel_grf_reg;
u32 lcdsel_big;
u32 lcdsel_lit;
 };
@@ -252,6 +252,9 @@ static void dw_hdmi_rockchip_encoder_enable(struct 
drm_encoder *encoder)
u32 val;
int ret;
 
+   if (hdmi->chip_data->lcdsel_grf_reg < 0)
+   return;
+
ret = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
if (ret)
val = hdmi->chip_data->lcdsel_lit;
-- 
2.15.1

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

[PATCH 2/9] phy: add Rockchip Innosilicon hdmi phy

[Heiko Stuebner]

From: Zheng Yang 

Add a driver for the Innosilicon hdmi phy used on rk3228/rk3229
and rk3328 socs from Rockchip.

Signed-off-by: Zheng Yang 
Signed-off-by: Heiko Stuebner 
---
 drivers/phy/rockchip/Kconfig  |7 +
 drivers/phy/rockchip/Makefile |1 +
 drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 1221 +
 3 files changed, 1229 insertions(+)
 create mode 100644 drivers/phy/rockchip/phy-rockchip-inno-hdmi.c

diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index f5325b2b679e..41ab78364661 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -15,6 +15,13 @@ config PHY_ROCKCHIP_EMMC
help
  Enable this to support the Rockchip EMMC PHY.
 
+config PHY_ROCKCHIP_INNO_HDMI
+   tristate "Rockchip INNO HDMI PHY Driver"
+   depends on (ARCH_ROCKCHIP || COMPILE_TEST) && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip Innosilicon HDMI PHY.
+
 config PHY_ROCKCHIP_INNO_USB2
tristate "Rockchip INNO USB2PHY Driver"
depends on (ARCH_ROCKCHIP || COMPILE_TEST) && OF
diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
index 7f149d989046..fd21cbaf40dd 100644
--- a/drivers/phy/rockchip/Makefile
+++ b/drivers/phy/rockchip/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_ROCKCHIP_EMMC)+= phy-rockchip-emmc.o
+obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI)   += phy-rockchip-inno-hdmi.o
 obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2)   += phy-rockchip-inno-usb2.o
 obj-$(CONFIG_PHY_ROCKCHIP_PCIE)+= phy-rockchip-pcie.o
 obj-$(CONFIG_PHY_ROCKCHIP_TYPEC)   += phy-rockchip-typec.o
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c 
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
new file mode 100644
index ..da622e850aae
--- /dev/null
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -0,0 +1,1221 @@
+/*
+ * Copyright (c) 2017 Rockchip Electronics Co. Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UPDATE(x, h, l)(((x) << (l)) & GENMASK((h), (l)))
+
+/* REG: 0x00 */
+#define RK3228_PRE_PLL_REFCLK_SEL_PCLK BIT(0)
+/* REG: 0x01 */
+#define RK3228_BYPASS_RXSENSE_EN   BIT(2)
+#define RK3228_BYPASS_PWRON_EN BIT(1)
+#define RK3228_BYPASS_PLLPD_EN BIT(0)
+/* REG: 0x02 */
+#define RK3228_BYPASS_PDATA_EN BIT(4)
+#define RK3228_PDATAEN_DISABLE BIT(0)
+/* REG: 0x03 */
+#define RK3228_BYPASS_AUTO_TERM_RES_CALBIT(7)
+#define RK3228_AUTO_TERM_RES_CAL_SPEED_14_8(x) UPDATE(x, 6, 0)
+/* REG: 0x04 */
+#define RK3228_AUTO_TERM_RES_CAL_SPEED_7_0(x)  UPDATE(x, 7, 0)
+/* REG: 0xaa */
+#define RK3228_POST_PLL_CTRL_MANUALBIT(0)
+/* REG: 0xe0 */
+#define RK3228_POST_PLL_POWER_DOWN BIT(5)
+#define RK3228_PRE_PLL_POWER_DOWN  BIT(4)
+#define RK3228_RXSENSE_CLK_CH_ENABLE   BIT(3)
+#define RK3228_RXSENSE_DATA_CH2_ENABLE BIT(2)
+#define RK3228_RXSENSE_DATA_CH1_ENABLE BIT(1)
+#define RK3228_RXSENSE_DATA_CH0_ENABLE BIT(0)
+/* REG: 0xe1 */
+#define RK3228_BANDGAP_ENABLE  BIT(4)
+#define RK3228_TMDS_DRIVER_ENABLE  GENMASK(3, 0)
+/* REG: 0xe2 */
+#define RK3228_PRE_PLL_FB_DIV_8_MASK   BIT(7)
+#define RK3228_PRE_PLL_FB_DIV_8(x) UPDATE((x) >> 8, 7, 7)
+#define RK3228_PCLK_VCO_DIV_5_MASK BIT(5)
+#define RK3228_PCLK_VCO_DIV_5(x)   UPDATE(x, 5, 5)
+#define RK3228_PRE_PLL_PRE_DIV_MASKGENMASK(4, 0)
+#define RK3228_PRE_PLL_PRE_DIV(x)  UPDATE(x, 4, 0)
+/* REG: 0xe3 */
+#define RK3228_PRE_PLL_FB_DIV_7_0(x)   UPDATE(x, 7, 0)
+/* REG: 0xe4 */
+#define RK3228_PRE_PLL_PCLK_DIV_B_MASK GENMASK(6, 5)
+#define RK3228_PRE_PLL_PCLK_DIV_B(x)   UPDATE(x, 6, 5)
+#define RK3228_PRE_PLL_PCLK_DIV_A_MASK GENMASK(4, 0)
+#define 

[PATCH 3/9] drm/bridge: dw-hdmi: allow overriding of phy-type reading

[Heiko Stuebner]

In some IP implementations the reading of the phy-type may be broken.
One example are the Rockchip rk3228 and rk3328 socs that use a separate
phy from Innosilicon but still report the HDMI20_TX type.

So allow the glue driver to force a specific type, like the vendor-phy
for these cases.

Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +++-
 include/drm/bridge/dw_hdmi.h  | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..7255fafce089 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2200,7 +2200,9 @@ static int dw_hdmi_detect_phy(struct dw_hdmi *hdmi)
unsigned int i;
u8 phy_type;
 
-   phy_type = hdmi_readb(hdmi, HDMI_CONFIG2_ID);
+   phy_type = (hdmi->plat_data->phy_force_type) ?
+   hdmi->plat_data->phy_force_type :
+   hdmi_readb(hdmi, HDMI_CONFIG2_ID);
 
if (phy_type == DW_HDMI_PHY_VENDOR_PHY) {
/* Vendor PHYs require support from the glue layer. */
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 182f83283e24..c5bc2804b29e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -133,6 +133,7 @@ struct dw_hdmi_plat_data {
const struct dw_hdmi_phy_ops *phy_ops;
const char *phy_name;
void *phy_data;
+   u8 phy_force_type;
 
/* Synopsys PHY support */
const struct dw_hdmi_mpll_config *mpll_cfg;
-- 
2.15.1

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

[PATCH 7/9] drm/rockchip: dw_hdmi: allow including external phys

[Heiko Stuebner]

Some variants of the dw-hdmi on Rockchip socs use a separate phy block
accessed via the generic phy framework, so allow them to be included
if such a phy reference is found.

Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 304f61bd2eec..512f8556e7c0 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -48,6 +49,7 @@ struct rockchip_hdmi {
const struct rockchip_hdmi_chip_data *chip_data;
struct clk *vpll_clk;
struct clk *grf_clk;
+   struct phy *phy;
 };
 
 #define to_rockchip_hdmi(x)container_of(x, struct rockchip_hdmi, x)
@@ -376,6 +378,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
return ret;
}
 
+   hdmi->phy = devm_phy_optional_get(dev, "hdmi");
+   if (IS_ERR(hdmi->phy)) {
+   ret = PTR_ERR(hdmi->phy);
+   if (ret != -EPROBE_DEFER)
+   DRM_DEV_ERROR(hdmi->dev, "failed to get phy\n");
+   return ret;
+   }
+
drm_encoder_helper_add(encoder, _hdmi_rockchip_encoder_helper_funcs);
drm_encoder_init(drm, encoder, _hdmi_rockchip_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
-- 
2.15.1

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

[PATCH 4/9] drm/bridge: dw-hdmi: export hotplug functions

[Heiko Stuebner]

From: Algea Cao 

External phys may not provide their own hotplug-related
routines but instead rely on the dw-hdmi ones.
Export these functions so that external hdmi-phys can
use them if necessary.

Signed-off-by: Algea Cao 
[export all 3 hotplug-related functions]
Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 11 +++
 include/drm/bridge/dw_hdmi.h  |  6 +-
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7255fafce089..2760e1b51422 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1251,14 +1251,15 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, 
void *data)
dw_hdmi_phy_power_off(hdmi);
 }
 
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+  void *data)
 {
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
 
-static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
   bool force, bool disabled, bool rxsense)
 {
u8 old_mask = hdmi->phy_mask;
@@ -1271,8 +1272,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, 
void *data,
if (old_mask != hdmi->phy_mask)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
 
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
 {
/*
 * Configure the PHY RX SENSE and HPD interrupts polarities and clear
@@ -1291,6 +1293,7 @@ static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, 
void *data)
hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
HDMI_IH_MUTE_PHY_STAT0);
 }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_setup_hpd);
 
 static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
.init = dw_hdmi_phy_init,
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index c5bc2804b29e..d9d7c75b3bfb 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -152,7 +152,11 @@ int dw_hdmi_bind(struct platform_device *pdev, struct 
drm_encoder *encoder,
 const struct dw_hdmi_plat_data *plat_data);
 
 void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense);
-
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+  void *data);
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+  bool force, bool disabled, bool rxsense);
+void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
 void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
 void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
 void dw_hdmi_audio_disable(struct dw_hdmi *hdmi);
-- 
2.15.1

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

[PATCH 0/9] drm/rockchip: hdmi support for rk3328

[Heiko Stuebner]

The rk3228/rk3229 and rk3328 socs started using a new type of hdmi-phy
from Innosilicon that resides completely separate from the dw-hdmi block
and gets accessed via mmio.

Additionally the rk3328 dw-hdmi does not report the vendor-phy type
but a different one instead, so add the possibility to override the
phy type when the glue driver knows better than the ip block itself.


I've put both the phy driver and dw-hdmi changes into one series just
to showcase how everything comes together, but would of course still
expect things to go through the separate phy and drm trees once deemed
ready.


Algea Cao (1):
  drm/bridge: dw-hdmi: export hotplug functions

Heiko Stuebner (6):
  drm/bridge: dw-hdmi: allow overriding of phy-type reading
  drm/rockchip: dw_hdmi: Allow outputs that don't need output switching
  dt-bindings: allow optional phys in Rockchip dw_hdmi binding
  drm/rockchip: dw_hdmi: allow including external phys
  drm/rockchip: dw_hdmi: store rockchip_hdmi reference in phy_data
object
  drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328

Zheng Yang (2):
  dt-bindings: add binding for Rockchip hdmi phy using an Innosilicon IP
  phy: add Rockchip Innosilicon hdmi phy

 .../bindings/display/rockchip/dw_hdmi-rockchip.txt |3 +
 .../bindings/phy/phy-rockchip-inno-hdmi.txt|   42 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |   15 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c|  130 ++-
 drivers/phy/rockchip/Kconfig   |7 +
 drivers/phy/rockchip/Makefile  |1 +
 drivers/phy/rockchip/phy-rockchip-inno-hdmi.c  | 1221 
 include/drm/bridge/dw_hdmi.h   |7 +-
 8 files changed, 1417 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt
 create mode 100644 drivers/phy/rockchip/phy-rockchip-inno-hdmi.c

-- 
2.15.1

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

[PATCH 9/9] drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328

[Heiko Stuebner]

The rk3328 uses an external hdmi phy from Innosilicon which uses
the generic phy framework for access. Add the necessary data
and the compatible for it.

Signed-off-by: Heiko Stuebner 
---
 .../bindings/display/rockchip/dw_hdmi-rockchip.txt |   1 +
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 106 +
 2 files changed, 107 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
index 937bfb472e1d..39143424a474 100644
--- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt
@@ -13,6 +13,7 @@ Required properties:
 
 - compatible: should be one of the following:
"rockchip,rk3288-dw-hdmi"
+   "rockchip,rk3328-dw-hdmi"
"rockchip,rk3399-dw-hdmi"
 - reg: See dw_hdmi.txt.
 - reg-io-width: See dw_hdmi.txt. Shall be 4.
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 5a62328887d5..30b8f44d0418 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -25,6 +25,24 @@
 
 #define RK3288_GRF_SOC_CON60x025C
 #define RK3288_HDMI_LCDC_SEL   BIT(4)
+#define RK3328_GRF_SOC_CON20x0408
+
+#define RK3328_HDMI_SDAIN_MSK  BIT(11)
+#define RK3328_HDMI_SCLIN_MSK  BIT(10)
+#define RK3328_HDMI_HPD_IOEBIT(2)
+#define RK3328_GRF_SOC_CON30x040c
+/* need to be unset if hdmi or i2c should control voltage */
+#define RK3328_HDMI_SDA5V_GRF  BIT(15)
+#define RK3328_HDMI_SCL5V_GRF  BIT(14)
+#define RK3328_HDMI_HPD5V_GRF  BIT(13)
+#define RK3328_HDMI_CEC5V_GRF  BIT(12)
+#define RK3328_GRF_SOC_CON40x0410
+#define RK3328_HDMI_HPD_SARADC BIT(13)
+#define RK3328_HDMI_CEC_5V BIT(11)
+#define RK3328_HDMI_SDA_5V BIT(10)
+#define RK3328_HDMI_SCL_5V BIT(9)
+#define RK3328_HDMI_HPD_5V BIT(8)
+
 #define RK3399_GRF_SOC_CON20   0x6250
 #define RK3399_HDMI_LCDC_SEL   BIT(6)
 
@@ -299,6 +317,68 @@ static const struct drm_encoder_helper_funcs 
dw_hdmi_rockchip_encoder_helper_fun
.atomic_check = dw_hdmi_rockchip_encoder_atomic_check,
 };
 
+static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi *dw_hdmi, void *data,
+struct drm_display_mode *mode)
+{
+   struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+   return phy_power_on(hdmi->phy);
+}
+
+static void dw_hdmi_rockchip_genphy_disable(struct dw_hdmi *dw_hdmi, void 
*data)
+{
+   struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+   phy_power_off(hdmi->phy);
+}
+
+static enum drm_connector_status
+dw_hdmi_rk3328_read_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+   struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+   enum drm_connector_status status;
+
+   status = dw_hdmi_phy_read_hpd(dw_hdmi, data);
+
+   if (status == connector_status_connected)
+   regmap_write(hdmi->regmap,
+   RK3328_GRF_SOC_CON4,
+   HIWORD_UPDATE(RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V,
+ RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V));
+   else
+   regmap_write(hdmi->regmap,
+   RK3328_GRF_SOC_CON4,
+   HIWORD_UPDATE(0,
+ RK3328_HDMI_CEC_5V | RK3328_HDMI_SDA_5V |
+ RK3328_HDMI_SCL_5V));
+   return status;
+}
+
+static void dw_hdmi_rk3328_setup_hpd(struct dw_hdmi *dw_hdmi, void *data)
+{
+   struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+
+   dw_hdmi_phy_setup_hpd(dw_hdmi, data);
+
+   /* Enable and map pins to 3V grf-controlled io-voltage */
+   regmap_write(hdmi->regmap,
+   RK3328_GRF_SOC_CON4,
+   HIWORD_UPDATE(0, RK3328_HDMI_HPD_SARADC | RK3328_HDMI_CEC_5V |
+RK3328_HDMI_SDA_5V | RK3328_HDMI_SCL_5V |
+RK3328_HDMI_HPD_5V));
+   regmap_write(hdmi->regmap,
+   RK3328_GRF_SOC_CON3,
+   HIWORD_UPDATE(0, RK3328_HDMI_SDA5V_GRF | RK3328_HDMI_SCL5V_GRF |
+RK3328_HDMI_HPD5V_GRF | 
RK3328_HDMI_CEC5V_GRF));
+   regmap_write(hdmi->regmap,
+   RK3328_GRF_SOC_CON2,
+   HIWORD_UPDATE(RK3328_HDMI_SDAIN_MSK | RK3328_HDMI_SCLIN_MSK,
+ RK3328_HDMI_SDAIN_MSK | RK3328_HDMI_SCLIN_MSK |
+ RK3328_HDMI_HPD_IOE));
+}
+
 static struct rockchip_hdmi_chip_data rk3288_chip_data = {
   

[PATCH 1/2] drm/i915/cmdparser: Check reg_table_count before derefencing.

[Michal Srb]

The find_reg function was assuming that there is always at least one table in
reg_tables. It is not always true.

In case of VCS or VECS, the reg_tables is NULL and reg_table_count is 0,
implying that no register-accessing commands are allowed. However, the command
tables include commands such as MI_STORE_REGISTER_MEM. When trying to check
such command, the find_reg would dereference NULL pointer.

Now it will just return NULL meaning that the register was not found and the
command will be rejected.

Signed-off-by: Michal Srb 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 8ba932b22f7c..de7ec59433d1 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1038,7 +1038,7 @@ find_reg(const struct intel_engine_cs *engine, bool 
is_master, u32 addr)
const struct drm_i915_reg_table *table = engine->reg_tables;
int count = engine->reg_table_count;
 
-   do {
+   for (; count > 0; ++table, --count) {
if (!table->master || is_master) {
const struct drm_i915_reg_descriptor *reg;
 
@@ -1046,7 +1046,7 @@ find_reg(const struct intel_engine_cs *engine, bool 
is_master, u32 addr)
if (reg != NULL)
return reg;
}
-   } while (table++, --count);
+   }
 
return NULL;
 }
-- 
2.13.6

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

[PATCH 2/2] drm/i915/cmdparser: Do not check past the cmd length.

[Michal Srb]

The command MEDIA_VFE_STATE checks bits at offset +2 dwords. However, it is
possible to have MEDIA_VFE_STATE command with length = 0 + LENGTH_BIAS = 2.
In that case check_cmd will read bits from the following command, or even past
the end of the buffer.

Similarly to how registers are checked - if the offset ends up outside of the
command length, just ignore it.

Signed-off-by: Michal Srb 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index de7ec59433d1..827740b866a8 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1218,6 +1218,9 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
continue;
}
 
+   if (desc->bits[i].offset >= length)
+   continue;
+
dword = cmd[desc->bits[i].offset] &
desc->bits[i].mask;
 
-- 
2.13.6

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

[PATCH 0/2] Fixes in drm/i915/cmdparser.

[Michal Srb]

Hi,

I have tried to extract the intel_engine_cmd_parser into a user-space binary
and run libFuzzer on it. It found two ways to cause undefined behavior.

I am not completely sure if the same issues can be triggered in the driver, or
if something would prevent them from happening. Still I thought it is worth
sharing it here.

Michal Srb (2):
  drm/i915/cmdparser: Check reg_table_count before derefencing.
  drm/i915/cmdparser: Do not check bits past the cmd length.

 drivers/gpu/drm/i915/i915_cmd_parser.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

-- 
2.13.6

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

Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

[Maxime Ripard]

On Thu, Feb 01, 2018 at 05:09:33PM +0100, Giulio Benetti wrote:
> Il 01/02/2018 11:14, Maxime Ripard ha scritto:
> > On Sat, Jan 27, 2018 at 11:07:09PM +0100, Giulio Benetti wrote:
> > > > > > > I don't really know what the polarity of D0 would be just by
> > > > > > > judging at that capture, but we would have noticed if the colors
> > > > > > > were inverted for quite some time now.
> > > > > > 
> > > > > > D0-D23 are correct.
> > > > > > 
> > > > > > With that capture, I mean to show you instead dclk is inverted, as
> > > > > > dclk samples D0 on falling edge.
> > > > > 
> > > > > Ah right, DCLK being the first channel?
> > > > 
> > > > Yes, sorry I didn't place a label on channels
> > > > 
> > > > > 
> > > > > > So 0 is NEGEDGE and 1 is POSEDGE(1/3 of clock phase).
> > > > > > 1/3 clock phase seems enough to me to be considered POSEDGE,
> > > > > > 2/3 instead risks to go too much to the right of D0(even if it
> > > > > > could work).
> > > > > 
> > > > > Do you have captures with both settings?
> > > > 
> > > > Not now, but asap I'm going to take.
> > > 
> > > Here we are:
> > > 1/3 phase: https://pasteboard.co/H4VehON.png
> > > 2/3 phase: https://pasteboard.co/H4Veq8a.png
> > > 
> > > Yellow: D0
> > > Blue: DCLK
> > > 
> > > As you can see:
> > > 1/3 phase has DCLK rising edge almost in the middle of D0
> > > 2/3 phase has DCLK rising edge that comes too late
> > > 
> > > I would go for "1/3 phase" for Rising edge and "normal phase" for
> > > Falling edge.
> > > 
> > > What do you think?
> > 
> > It seems fair. This need a whole lot of comments though :)
> 
> Yes, then, do I proceed resubmitting both corrected patches with corrected
> commit logs?

Yes, please.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


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

Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.

[Ville Syrjälä]

On Mon, Feb 05, 2018 at 01:59:05PM +0100, Maarten Lankhorst wrote:
> Op 02-02-18 om 15:46 schreef Ville Syrjälä:
> > On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote:
> >> This will make it possible for userspace to know whether reading
> >> will block, without blocking on the fd. This makes it possible to
> >> drain all queued CRC's in blocking mode, without having to reopen
> >> the fd.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/drm_debugfs_crc.c | 19 +++
> >>  1 file changed, 19 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> >> b/drivers/gpu/drm/drm_debugfs_crc.c
> >> index 9dd879589a2c..8af1a74ec64d 100644
> >> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> >> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> >> @@ -307,10 +307,29 @@ static ssize_t crtc_crc_read(struct file *filep, 
> >> char __user *user_buf,
> >>return LINE_LEN(crc->values_cnt);
> >>  }
> >>  
> >> +static unsigned int crtc_crc_poll(struct file *file, poll_table *wait)
> >> +{
> >> +  struct drm_crtc *crtc = file->f_inode->i_private;
> >> +  struct drm_crtc_crc *crc = >crc;
> >> +  unsigned ret;
> >> +
> >> +  poll_wait(file, >wq, wait);
> >> +
> >> +  spin_lock_irq(>lock);
> >> +  if (crc->source && crtc_crc_data_count(crc))
> >> +  ret = POLLIN;
> > Most places seem to also set POLLRDNORM. Maybe we should do it as well?
> >
> > Apart from that this seems good to me.
> > Reviewed-by: Ville Syrjälä 
> Yeah, changed it and pushed, thanks for the suggestion. :)
> > Could replace the usleep() loop in igt read_one_crc() with
> > poll/select() I suppose? Either that or we should switch between
> > blocking and nonblocking dynamically.
> It could, but it would use 100% of cpu on older kernels that don't support 
> poll(), if that's not a problem we could do it. :)

Maybe we can probe for poll support when we create the pipe_crc object?

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: prefer XBGR2101010 for addfb ioctl

[Ilia Mirkin]

On Mon, Feb 5, 2018 at 8:58 AM, Ville Syrjälä
 wrote:
> On Sat, Feb 03, 2018 at 02:11:23PM -0500, Ilia Mirkin wrote:
>> Nouveau only exposes support for XBGR2101010. Prior to the atomic
>> conversion, drm would pass in the wrong format in the framebuffer, but
>> it was always ignored -- both userspace (xf86-video-nouveau) and the
>> kernel driver agreed on the layout, so the fact that the format was
>> wrong didn't matter.
>>
>> With the atomic conversion, nouveau all of a sudden started caring about
>> the exact format, and so the previously-working code in
>> xf86-video-nouveau no longer functioned since the (internally-assigned)
>> format from the addfb ioctl was wrong.
>>
>> This change adds infrastructure to allow a drm driver to specify that it
>> prefers the XBGR format variant for the addfb ioctl, and makes nouveau's
>> nv50 display driver set it. (Prior gens had no support for 30bpp at all.)
>>
>> Signed-off-by: Ilia Mirkin 
>> Cc: sta...@vger.kernel.org # v4.10+
>> ---
>>
>> Wasn't sure if the nouveau line needs to be split out into a separate
>> change or not.
>>
>>  drivers/gpu/drm/drm_framebuffer.c  | 4 
>>  drivers/gpu/drm/nouveau/nv50_display.c | 1 +
>>  include/drm/drm_drv.h  | 1 +
>>  3 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
>> b/drivers/gpu/drm/drm_framebuffer.c
>> index 5a13ff29f4f0..c0530a1af5e3 100644
>> --- a/drivers/gpu/drm/drm_framebuffer.c
>> +++ b/drivers/gpu/drm/drm_framebuffer.c
>> @@ -121,6 +121,10 @@ int drm_mode_addfb(struct drm_device *dev,
>>   r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
>>   r.handles[0] = or->handle;
>>
>> + if (r.pixel_format == DRM_FORMAT_XRGB2101010 &&
>> + dev->driver->driver_features & DRIVER_PREFER_XBGR_30BPP)
>> + r.pixel_format = DRM_FORMAT_XBGR2101010;
>
> I think I'd much prefer if the driver just passed some kind of a
> bpp/depth->format mapping table to the core, or maybe an optional
> vfunc to allow the driver to override drm_mode_legacy_fb_format()
> behaviour.
>
> drm_mode_legacy_fb_format() is called from the fbdev setup as well
> so handling this only in addfb doesn't look sufficient.

Well, in practice fbdev won't pick a 30bpp mode. But I get the point.
It would also enable a driver to have a funky RGB ordering for depth
24/32 and others. Although I don't know if there are any customers for
that in practice.

A vfunc works for me.

Anyone else want to opine before I go for it? I'm happy to do the
work, but want to make sure I'm not just doing things that'll get
rejected, as I have a limited amount of time to do these things.

Cheers,

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

Re: [PATCH] drm/nouveau: prefer XBGR2101010 for addfb ioctl

[Ville Syrjälä]

On Sat, Feb 03, 2018 at 02:11:23PM -0500, Ilia Mirkin wrote:
> Nouveau only exposes support for XBGR2101010. Prior to the atomic
> conversion, drm would pass in the wrong format in the framebuffer, but
> it was always ignored -- both userspace (xf86-video-nouveau) and the
> kernel driver agreed on the layout, so the fact that the format was
> wrong didn't matter.
> 
> With the atomic conversion, nouveau all of a sudden started caring about
> the exact format, and so the previously-working code in
> xf86-video-nouveau no longer functioned since the (internally-assigned)
> format from the addfb ioctl was wrong.
> 
> This change adds infrastructure to allow a drm driver to specify that it
> prefers the XBGR format variant for the addfb ioctl, and makes nouveau's
> nv50 display driver set it. (Prior gens had no support for 30bpp at all.)
> 
> Signed-off-by: Ilia Mirkin 
> Cc: sta...@vger.kernel.org # v4.10+
> ---
> 
> Wasn't sure if the nouveau line needs to be split out into a separate
> change or not.
> 
>  drivers/gpu/drm/drm_framebuffer.c  | 4 
>  drivers/gpu/drm/nouveau/nv50_display.c | 1 +
>  include/drm/drm_drv.h  | 1 +
>  3 files changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index 5a13ff29f4f0..c0530a1af5e3 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -121,6 +121,10 @@ int drm_mode_addfb(struct drm_device *dev,
>   r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
>   r.handles[0] = or->handle;
>  
> + if (r.pixel_format == DRM_FORMAT_XRGB2101010 &&
> + dev->driver->driver_features & DRIVER_PREFER_XBGR_30BPP)
> + r.pixel_format = DRM_FORMAT_XBGR2101010;

I think I'd much prefer if the driver just passed some kind of a
bpp/depth->format mapping table to the core, or maybe an optional
vfunc to allow the driver to override drm_mode_legacy_fb_format()
behaviour.

drm_mode_legacy_fb_format() is called from the fbdev setup as well
so handling this only in addfb doesn't look sufficient.

> +
>   ret = drm_mode_addfb2(dev, , file_priv);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index dd8d4352ed99..caddce88d2d8 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -4477,6 +4477,7 @@ nv50_display_create(struct drm_device *dev)
>   nouveau_display(dev)->fini = nv50_display_fini;
>   disp->disp = _display(dev)->disp;
>   dev->mode_config.funcs = _disp_func;
> + dev->driver->driver_features |= DRIVER_PREFER_XBGR_30BPP;
>   if (nouveau_atomic)
>   dev->driver->driver_features |= DRIVER_ATOMIC;
>  
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index d32b688eb346..d23dcdd1bd95 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -56,6 +56,7 @@ struct drm_printer;
>  #define DRIVER_ATOMIC0x1
>  #define DRIVER_KMS_LEGACY_CONTEXT0x2
>  #define DRIVER_SYNCOBJ  0x4
> +#define DRIVER_PREFER_XBGR_30BPP0x8
>  
>  /**
>   * struct drm_driver - DRM driver structure
> -- 
> 2.13.6
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

[Tom St Denis]

Attached is a patch for umr{master} which should in theory support both 
iova and iomem.


I can add the write method if you want since ya it should be fairly 
simple to copy/pasta that up.


Cheers,
Tom

On 05/02/18 07:07 AM, Christian König wrote:

Well adding write support is trivial.

What I'm more concerned about is if setting page->mapping during 
allocation of the page could have any negative effect?


I of hand don't see any since the page isn't reclaimable directly 
anyway, but I'm not 100% sure of that.


Christian.

Am 05.02.2018 um 12:49 schrieb Tom St Denis:
Another thing that occurred to me is this will break write access to 
GPU bound memory.  Previously we relied on iova to translate the 
address and then /dev/mem or /dev/fmem to read/write it.  But since 
this is literally a read only method obviously there's no write support.


Tom


On 04/02/18 09:56 PM, He, Roger wrote:

Patch1 & 2 & 4,   Reviewed-by: Roger He 
Patch 5:  Acked-by: Roger He 

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On 
Behalf Of Christian K?nig

Sent: Saturday, February 03, 2018 3:10 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

This allows access to pages allocated through the driver with 
optional IOMMU mapping.


Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 57 
-

  1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

index 648c449aaa79..795ceaeb82d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1929,38 +1929,51 @@ static const struct file_operations 
amdgpu_ttm_gtt_fops = {

    #endif
  -static ssize_t amdgpu_iova_to_phys_read(struct file *f, char 
__user *buf,

-   size_t size, loff_t *pos)
+static ssize_t amdgpu_iomem_read(struct file *f, char __user *buf,
+ size_t size, loff_t *pos)
  {
  struct amdgpu_device *adev = file_inode(f)->i_private;
-    int r;
-    uint64_t phys;
  struct iommu_domain *dom;
+    ssize_t result = 0;
+    int r;
  -    // always return 8 bytes
-    if (size != 8)
-    return -EINVAL;
+    dom = iommu_get_domain_for_dev(adev->dev);
  -    // only accept page addresses
-    if (*pos & 0xFFF)
-    return -EINVAL;
+    while (size) {
+    phys_addr_t addr = *pos & PAGE_MASK;
+    loff_t off = *pos & ~PAGE_MASK;
+    size_t bytes = PAGE_SIZE - off;
+    unsigned long pfn;
+    struct page *p;
+    void *ptr;
  -    dom = iommu_get_domain_for_dev(adev->dev);
-    if (dom)
-    phys = iommu_iova_to_phys(dom, *pos);
-    else
-    phys = *pos;
+    addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
  -    r = copy_to_user(buf, , 8);
-    if (r)
-    return -EFAULT;
+    pfn = addr >> PAGE_SHIFT;
+    if (!pfn_valid(pfn))
+    return -EPERM;
+
+    p = pfn_to_page(pfn);
+    if (p->mapping != adev->mman.bdev.dev_mapping)
+    return -EPERM;
+
+    ptr = kmap(p);
+    r = copy_to_user(buf, ptr, bytes);
+    kunmap(p);
+    if (r)
+    return -EFAULT;
  -    return 8;
+    size -= bytes;
+    *pos += bytes;
+    result += bytes;
+    }
+
+    return result;
  }
  -static const struct file_operations amdgpu_ttm_iova_fops = {
+static const struct file_operations amdgpu_ttm_iomem_fops = {
  .owner = THIS_MODULE,
-    .read = amdgpu_iova_to_phys_read,
+    .read = amdgpu_iomem_read,
  .llseek = default_llseek
  };
  @@ -1973,7 +1986,7 @@ static const struct {  #ifdef 
CONFIG_DRM_AMDGPU_GART_DEBUGFS

  { "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT }, #endif
-    { "amdgpu_iova", _ttm_iova_fops, TTM_PL_SYSTEM },
+    { "amdgpu_iomem", _ttm_iomem_fops, TTM_PL_SYSTEM },
  };
    #endif
--
2.14.1

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







>From 67703a62763dfb2107bd503c5ae76414a50c50a4 Mon Sep 17 00:00:00 2001
From: Tom St Denis 
Date: Mon, 5 Feb 2018 08:53:40 -0500
Subject: [PATCH umr] add support for new iomem debugfs entry

Signed-off-by: Tom St Denis 
---
 src/lib/close_asic.c |  1 +
 src/lib/discover.c   |  3 +++
 src/lib/read_vram.c  | 29 +++--
 src/umr.h|  3 ++-
 4 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/src/lib/close_asic.c b/src/lib/close_asic.c
index 782b1a0d029b..6b220cd578e9 100644
--- a/src/lib/close_asic.c
+++ b/src/lib/close_asic.c
@@ 

Re: [RESEND][PATCH] video: fbdev: atmel_lcdfb: convert to use GPIO descriptors

[Andy Shevchenko]

On Mon, Feb 5, 2018 at 10:47 AM, Ludovic Desroches
 wrote:
> Use GPIO descriptors instead of relying on the old method.

Reviewed-by: Andy Shevchenko 

Though few nitpicks below.


> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 

> +#include 

I think you forgot to remove of_gpio.h.

>  #include 
>  #include 
>  #include 

> struct device_node *display_np;
> struct device_node *timings_np;
> struct display_timings *timings;
> -   enum of_gpio_flags flags;
> struct atmel_lcdfb_power_ctrl_gpio *og;
> bool is_gpio_power = false;
> int ret = -ENOENT;
> -   int i, gpio;
> +   int i;
> +   struct gpio_desc *gpiod;

I would rather preserve reversed tree style, i.e. put longer line upper.


> +   for (i = 0; i < gpiod_count(dev, "atmel,power-control"); i++) {
> +   gpiod = devm_gpiod_get_index_optional(dev,
> +   "atmel,power-control", i, GPIOD_ASIS);
> +   if (!gpiod)
> continue;

What about IS_ERR() case?

>
> og = devm_kzalloc(dev, sizeof(*og), GFP_KERNEL);
> if (!og)
> goto put_display_node;
>
> +   og->gpiod = gpiod;
> is_gpio_power = true;
>
> +   ret = gpiod_direction_output(gpiod, 
> gpiod_is_active_low(gpiod));
> if (ret) {

I'm not sure this will be needed if you check IS_ERR() above.

> +   dev_err(dev, "set direction output gpio 
> atmel,power-control[%d] failed\n", i);
> goto put_display_node;
> }


-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge/synopsys: dsi: Add 1.31 version support

[Andrzej Hajda]

On 22.01.2018 16:08, Philippe Cornu wrote:
> From: Philippe CORNU 
>
> Add support for the Synopsys DesignWare MIPI DSI version 1.31
> Two registers need to be updated/added for supporting 1.31:
> * PHY_TMR_CFG 0x9c (updated)
>   1.30 [31:24] phy_hs2lp_time
>[23:16] phy_lp2hs_time
>[14: 0] max_rd_time
>
>   1.31 [25:16] phy_hs2lp_time
>[ 9: 0] phy_lp2hs_time
>
> * PHY_TMR_RD_CFG 0xf4 (new)
>   1.31 [14: 0] max_rd_time
>
> Signed-off-by: Philippe Cornu 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 52 
> +++
>  1 file changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 735f38429c06..20a2ca14a7ad 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -25,7 +25,13 @@
>  #include 
>  #include 
>  
> +#define HWVER_1300x31333000  /* IP version 1.30 */
> +#define HWVER_1310x31333100  /* IP version 1.31 */
> +#define HWVER_OLDEST HWVER_130
> +#define HWVER_NEWEST HWVER_131
> +
>  #define DSI_VERSION  0x00
> +#define VERSION  GENMASK(31, 8)
>  
>  #define DSI_PWR_UP   0x04
>  #define RESET0
> @@ -161,11 +167,12 @@
>  #define PHY_CLKHS2LP_TIME(lbcc)  (((lbcc) & 0x3ff) << 16)
>  #define PHY_CLKLP2HS_TIME(lbcc)  ((lbcc) & 0x3ff)
>  
> -/* TODO Next register is slightly different between 1.30 & 1.31 IP version */
>  #define DSI_PHY_TMR_CFG  0x9c
> -#define PHY_HS2LP_TIME(lbcc) (((lbcc) & 0xff) << 24)
> -#define PHY_LP2HS_TIME(lbcc) (((lbcc) & 0xff) << 16)
> -#define MAX_RD_TIME(lbcc)((lbcc) & 0x7fff)
> +#define PHY_HS2LP_TIME_V130(lbcc)(((lbcc) & 0xff) << 24)
> +#define PHY_LP2HS_TIME_V130(lbcc)(((lbcc) & 0xff) << 16)
> +#define MAX_RD_TIME_V130(lbcc)   ((lbcc) & 0x7fff)
> +#define PHY_HS2LP_TIME_V131(lbcc)(((lbcc) & 0x3ff) << 16)
> +#define PHY_LP2HS_TIME_V131(lbcc)((lbcc) & 0x3ff)
>  
>  #define DSI_PHY_RSTZ 0xa0
>  #define PHY_DISFORCEPLL  0
> @@ -204,7 +211,9 @@
>  #define DSI_INT_ST1  0xc0
>  #define DSI_INT_MSK0 0xc4
>  #define DSI_INT_MSK1 0xc8
> +
>  #define DSI_PHY_TMR_RD_CFG   0xf4
> +#define MAX_RD_TIME_V131(lbcc)   ((lbcc) & 0x7fff)
>  
>  #define PHY_STATUS_TIMEOUT_US1
>  #define CMD_PKT_STATUS_TIMEOUT_US2
> @@ -215,6 +224,7 @@ struct dw_mipi_dsi {
>   struct drm_bridge *panel_bridge;
>   struct device *dev;
>   void __iomem *base;
> + u32 hw_version;
>  
>   struct clk *pclk;
>   struct clk *px_clk;
> @@ -616,8 +626,14 @@ static void dw_mipi_dsi_dphy_timing_config(struct 
> dw_mipi_dsi *dsi)
>* note: DSI_PHY_TMR_CFG.MAX_RD_TIME should be in line with
>* DSI_CMD_MODE_CFG.MAX_RD_PKT_SIZE_LP (see CMD_MODE_ALL_LP)
>*/
> - dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME(0x40)
> -   | PHY_LP2HS_TIME(0x40) | MAX_RD_TIME(1));
> + if (dsi->hw_version == HWVER_131) {
> + dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME_V131(0x40) |
> +   PHY_LP2HS_TIME_V131(0x40));
> + dsi_write(dsi, DSI_PHY_TMR_RD_CFG, MAX_RD_TIME_V131(1));
> + } else {
> + dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME_V130(0x40) |
> +   PHY_LP2HS_TIME_V130(0x40) | MAX_RD_TIME_V130(1));
> + }
>  
>   dsi_write(dsi, DSI_PHY_TMR_LPCLK_CFG, PHY_CLKHS2LP_TIME(0x40)
> | PHY_CLKLP2HS_TIME(0x40));
> @@ -791,6 +807,28 @@ static const struct drm_bridge_funcs 
> dw_mipi_dsi_bridge_funcs = {
>   .attach   = dw_mipi_dsi_bridge_attach,
>  };
>  
> +static void dsi_get_version(struct dw_mipi_dsi *dsi)
> +{
> + u32 hw_version;
> +
> + clk_prepare_enable(dsi->pclk);
> + hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
> + clk_disable_unprepare(dsi->pclk);
> +
> + if (hw_version > HWVER_NEWEST) {
> + DRM_DEBUG("hw version: use 0x%08x for this recent 0x%08x\n",
> +   HWVER_NEWEST, hw_version);
> + hw_version = HWVER_NEWEST;
> +
> + } else if (hw_version < HWVER_OLDEST) {
> + DRM_DEBUG("hw version: use 0x%08x for this old 0x%08x\n",
> +   HWVER_OLDEST, hw_version);
> + hw_version = HWVER_OLDEST;
> + }
> +
> + dsi->hw_version = hw_version;
> +}
> +
>  static struct dw_mipi_dsi *
>  __dw_mipi_dsi_probe(struct platform_device *pdev,
>   const struct dw_mipi_dsi_plat_data *plat_data)
> @@ -870,6 +908,8 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
>   

Re: [Intel-gfx] [PATCH] drm/crc: Add support for polling on the data fd.

[Maarten Lankhorst]

Op 02-02-18 om 15:46 schreef Ville Syrjälä:
> On Fri, Feb 02, 2018 at 03:27:43PM +0100, Maarten Lankhorst wrote:
>> This will make it possible for userspace to know whether reading
>> will block, without blocking on the fd. This makes it possible to
>> drain all queued CRC's in blocking mode, without having to reopen
>> the fd.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_debugfs_crc.c | 19 +++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
>> b/drivers/gpu/drm/drm_debugfs_crc.c
>> index 9dd879589a2c..8af1a74ec64d 100644
>> --- a/drivers/gpu/drm/drm_debugfs_crc.c
>> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
>> @@ -307,10 +307,29 @@ static ssize_t crtc_crc_read(struct file *filep, char 
>> __user *user_buf,
>>  return LINE_LEN(crc->values_cnt);
>>  }
>>  
>> +static unsigned int crtc_crc_poll(struct file *file, poll_table *wait)
>> +{
>> +struct drm_crtc *crtc = file->f_inode->i_private;
>> +struct drm_crtc_crc *crc = >crc;
>> +unsigned ret;
>> +
>> +poll_wait(file, >wq, wait);
>> +
>> +spin_lock_irq(>lock);
>> +if (crc->source && crtc_crc_data_count(crc))
>> +ret = POLLIN;
> Most places seem to also set POLLRDNORM. Maybe we should do it as well?
>
> Apart from that this seems good to me.
> Reviewed-by: Ville Syrjälä 
Yeah, changed it and pushed, thanks for the suggestion. :)
> Could replace the usleep() loop in igt read_one_crc() with
> poll/select() I suppose? Either that or we should switch between
> blocking and nonblocking dynamically.
It could, but it would use 100% of cpu on older kernels that don't support 
poll(), if that's not a problem we could do it. :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge/synopsys: dsi: Add read feature

[Philippe CORNU]

Hi Andrzej,

And many thanks
Philippe :-)

On 02/05/2018 11:07 AM, Andrzej Hajda wrote:
> On 04.02.2018 22:31, Philippe Cornu wrote:
>> This patch adds the DCS/GENERIC DSI read feature.
>>
>> Signed-off-by: Philippe Cornu 
> 
> Reviewed-by: Andrzej Hajda 
> 
> If there will be no objections I will merge it at the end of the week.
> 
>   --
> Regards
> Andrzej
> 
>> ---
>> Extra notes:
>> DSI read tests have been performed with DCS & GENERIC, short & long
>> commands, on two different panels.
>> The maximum fifo size (32*32-bit = 128 bytes on stm32) has been
>> verified too.
>>
>>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 58 
>> +--
>>   1 file changed, 45 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> index e9422d05e897..65aeb3f78b48 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> @@ -397,18 +397,46 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
>>  return dw_mipi_dsi_gen_pkt_hdr_write(dsi, le32_to_cpu(word));
>>   }
>>   
>> +static int dw_mipi_dsi_read(struct dw_mipi_dsi *dsi,
>> +const struct mipi_dsi_msg *msg)
>> +{
>> +int i, j, ret, len = msg->rx_len;
>> +u8 *buf = msg->rx_buf;
>> +u32 val;
>> +
>> +/* Wait end of the read operation */
>> +ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
>> + val, !(val & GEN_RD_CMD_BUSY),
>> + 1000, CMD_PKT_STATUS_TIMEOUT_US);
>> +if (ret) {
>> +dev_err(dsi->dev, "Timeout during read operation\n");
>> +return ret;
>> +}
>> +
>> +for (i = 0; i < len; i += 4) {
>> +/* Read fifo must not be empty before all bytes are read */
>> +ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
>> + val, !(val & GEN_PLD_R_EMPTY),
>> + 1000, CMD_PKT_STATUS_TIMEOUT_US);
>> +if (ret) {
>> +dev_err(dsi->dev, "Read payload FIFO is empty\n");
>> +return ret;
>> +}
>> +
>> +val = dsi_read(dsi, DSI_GEN_PLD_DATA);
>> +for (j = 0; j < 4 && j + i < len; j++)
>> +buf[i + j] = val >> (8 * j);
>> +}
>> +
>> +return ret;
>> +}
>> +
>>   static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
>>   const struct mipi_dsi_msg *msg)
>>   {
>>  struct dw_mipi_dsi *dsi = host_to_dsi(host);
>>  struct mipi_dsi_packet packet;
>> -int ret;
>> -
>> -if (msg->rx_buf || msg->rx_len) {
>> -/* TODO dw drv improvements: implement read feature */
>> -dev_warn(dsi->dev, "read operations not yet implemented\n");
>> -return -EINVAL;
>> -}
>> +int ret, nb_bytes;
>>   
>>  ret = mipi_dsi_create_packet(, msg);
>>  if (ret) {
>> @@ -422,12 +450,16 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
>> mipi_dsi_host *host,
>>  if (ret)
>>  return ret;
>>   
>> -/*
>> - * TODO Only transmitted size is returned as actual driver does
>> - * not support dcs/generic reads. Please update return value when
>> - * delivering the read feature.
>> - */
>> -return packet.size;
>> +if (msg->rx_buf && msg->rx_len) {
>> +ret = dw_mipi_dsi_read(dsi, msg);
>> +if (ret)
>> +return ret;
>> +nb_bytes = msg->rx_len;
>> +} else {
>> +nb_bytes = packet.size;
>> +}
>> +
>> +return nb_bytes;
>>   }
>>   
>>   static const struct mipi_dsi_host_ops dw_mipi_dsi_host_ops = {
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel