Re: [PATCH V7 2/2] drm/panel: Add Sitronix ST7701 panel driver

[Jagan Teki]

On Sat, Jan 12, 2019 at 2:49 AM Sam Ravnborg  wrote:
>
> Hi Jagan.
>
> Gave this another more detailed read - triggered some additional comments.
> Depite the comments it looks good, and this is all more or
> less cosmetic improvements.

Thanks for the review.

>
> Sam
>
> > +struct st7701_panel_desc {
> > + const struct drm_display_mode *mode;
> > + unsigned int lanes;
> > + unsigned long flags;
> > + enum mipi_dsi_pixel_format format;
> > + const char *const *supply_names;
> > + unsigned int num_supplies;
> > + unsigned int panel_sleep_delay;
> > +};
> > +
> > +struct st7701 {
> > + struct drm_panel panel;
> > + struct mipi_dsi_device *dsi;
> > + const struct st7701_panel_desc *desc;
> > +
> > + struct backlight_device *backlight;
> > + struct regulator_bulk_data *supplies;
> > + unsigned int num_supplies;
> I cannot see that num_supplies in this struct are used?

Yes it is used in the code, please check in struct st7701_panel_desc.

>
>
> > + struct gpio_desc *reset;
> > + unsigned int sleep_delay;
> > +};
> > +
> > +static inline struct st7701 *panel_to_st7701(struct drm_panel *panel)
> > +{
> > + return container_of(panel, struct st7701, panel);
> > +}
> > +
> > +static inline int st7701_dsi_write(struct st7701 *st7701, const void *seq,
> > +size_t len)
> > +{
> > + return mipi_dsi_dcs_write_buffer(st7701->dsi, seq, len);
> > +}
> > +
>
>
> > +static int st7701_prepare(struct drm_panel *panel)
> > +{
> > + struct st7701 *st7701 = panel_to_st7701(panel);
> > + int ret;
> > +
> > + gpiod_set_value(st7701->reset, 0);
> > + msleep(20);
> > +
> > + ret = regulator_bulk_enable(st7701->desc->num_supplies,
> > + st7701->supplies);
> > + if (ret < 0)
> > + return ret;
> > + msleep(20);
> > +
> > + gpiod_set_value(st7701->reset, 1);
> > + msleep(20);
> > +
> > + gpiod_set_value(st7701->reset, 0);
> > + msleep(30);
> > +
> > + gpiod_set_value(st7701->reset, 1);
> > + msleep(150);
> > +
> > + st7701_init_sequence(st7701);
> > +
> > + return 0;
> > +}
> > +
>
> > +static int st7701_unprepare(struct drm_panel *panel)
> > +{
> > + struct st7701 *st7701 = panel_to_st7701(panel);
> > +
> > + ST7701_DSI(st7701, MIPI_DCS_EXIT_SLEEP_MODE, 0x00);
> > +
> > + msleep(st7701->sleep_delay);
> > +
> > + gpiod_set_value(st7701->reset, 0);
> > +
> > + gpiod_set_value(st7701->reset, 1);
> > +
> > + gpiod_set_value(st7701->reset, 0);
> No timing constrains here? In prepare there are sleeps intermixed.

Delay while doing unprare is not needed I suppose.

>
> > +
> > + regulator_bulk_disable(st7701->desc->num_supplies, st7701->supplies);
> > +
> > + return 0;
> > +}
> > +
> > +static int st7701_get_modes(struct drm_panel *panel)
> > +{
> > + struct st7701 *st7701 = panel_to_st7701(panel);
> > + const struct drm_display_mode *desc_mode = st7701->desc->mode;
> > + struct drm_display_mode *mode;
> > +
> > + mode = drm_mode_duplicate(panel->drm, desc_mode);
> > + if (!mode) {
> > + dev_err(>dsi->dev, "failed to add mode %ux%ux@%u\n",
> > + desc_mode->hdisplay, desc_mode->vdisplay,
> > + desc_mode->vrefresh);
> Use something like:
> DRM_DEV_ERROR(st7701->dev, "failed to add mode" DRM_MODE_FMT 
> ",
>   DRM_MODE_ARG(desc_mode));
>
> > + return -ENOMEM;
> > + }
> > +
> > + drm_mode_set_name(mode);
> > + drm_mode_probed_add(panel->connector, mode);
> > +
> > + panel->connector->display_info.width_mm = desc_mode->width_mm;
> > + panel->connector->display_info.height_mm = desc_mode->height_mm;
> > +
> > + return 1;
> > +}
> > +
>
> > +static const struct st7701_panel_desc ts8550b_desc = {
> > + .mode = _mode,
> > + .lanes = 2,
> > + .flags = MIPI_DSI_MODE_VIDEO,
> > + .format = MIPI_DSI_FMT_RGB888,
> > + .supply_names = ts8550b_supply_names,
> > + .num_supplies = ARRAY_SIZE(ts8550b_supply_names),
> > + .panel_sleep_delay = 80, /* panel need extra 80ms for sleep out cmd */
> In the only place this is used there is added 120 ms too.
> Looks inconsistent - do we have the same delay twice?

120ms is the one recommended by st7701 controller delay after a sleep
out command, please check it in datasheet [1], page 188. And this 80ms
is specific to TS8550B panel as per BSP code this doesn't have proper
documentation but the BSP code doing this extra 80ms.

>
>
> > +
> > +static int st7701_dsi_probe(struct mipi_dsi_device *dsi)
> > +{
> > + const struct st7701_panel_desc *desc;
> > + struct device_node *np;
> > + struct st7701 *st7701;
> > + int ret, i;
> > +
> > + st7701 = devm_kzalloc(>dev, sizeof(*st7701), GFP_KERNEL);
> > + if (!st7701)
> > + return -ENOMEM;
> > +
> > + desc = 

Re: [PATCH v2 35/49] drm: Clarify definition of the DRM_BUS_FLAG_(PIXDATA|SYNC)_* macros

[Laurent Pinchart]

Hi Daniel,

On Friday, 11 January 2019 11:23:10 EET Daniel Vetter wrote:
> On Fri, Jan 11, 2019 at 05:51:06AM +0200, Laurent Pinchart wrote:
> > From: Laurent Pinchart 
> > 
> > The DRM_BUS_FLAG_PIXDATA_POSEDGE and DRM_BUS_FLAG_PIXDATA_NEGEDGE macros
> > and their DRM_BUS_FLAG_SYNC_* counterparts define on which pixel clock
> > edge data and sync signals are driven. They are however used in some
> > drivers to define on which pixel clock edge data and sync signals are
> > sampled, which should usually (but not always) be the opposite edge of
> > the driving edge. This creates confusion.
> > 
> > Create four new macros for both PIXDATA and SYNC that explicitly state
> > the driving and sampling edge in their name to remove the confusion. The
> > driving macros are defined as the opposite of the sampling macros to
> > made code simpler based on the assumption that the driving and sampling
> > edges are opposite.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > Acked-by: Linus Walleij 
> > ---
> > Changes since v1:
> > 
> > - Address the DRM_BUS_FLAG_SYNC_* flags
> > - Rebase on top of drm-next
> > ---
> > 
> >  include/drm/drm_connector.h | 36 
> >  1 file changed, 32 insertions(+), 4 deletions(-)
> > 
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 9be2181b3ed7..00bb7a74962b 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -330,19 +330,47 @@ struct drm_display_info {
> > 
> >  #define DRM_BUS_FLAG_DE_LOW(1<<0)
> >  #define DRM_BUS_FLAG_DE_HIGH   (1<<1)
> > 
> > -/* drive data on pos. edge */
> > +
> > +/*
> > + * Don't use those two flags directly, use the
> > DRM_BUS_FLAG_PIXDATA_DRIVE_* + * and DRM_BUS_FLAG_PIXDATA_SAMPLE_*
> > variants to qualify the flags explicitly. + * The
> > DRM_BUS_FLAG_PIXDATA_SAMPLE_* flags are defined as the opposite of the +
> > * DRM_BUS_FLAG_PIXDATA_DRIVE_* flags to make code simpler, as signals are
> > + * usually to be sampled on the opposite edge of the driving edge. + */
> > 
> >  #define DRM_BUS_FLAG_PIXDATA_POSEDGE   (1<<2)
> > 
> > -/* drive data on neg. edge */
> > 
> >  #define DRM_BUS_FLAG_PIXDATA_NEGEDGE   (1<<3)
> > 
> > +
> > +/* Drive data on rising edge */
> > +#define DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE DRM_BUS_FLAG_PIXDATA_POSEDGE
> > +/* Drive data on falling edge */
> > +#define DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE DRM_BUS_FLAG_PIXDATA_NEGEDGE
> > +/* Sample data on rising edge */
> > +#define DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE
DRM_BUS_FLAG_PIXDATA_NEGEDGE
> > +/* Sample data on falling edge */
> > +#define DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE
DRM_BUS_FLAG_PIXDATA_POSEDGE
> > +
> > 
> >  /* data is transmitted MSB to LSB on the bus */
> >  #define DRM_BUS_FLAG_DATA_MSB_TO_LSB   (1<<4)
> >  /* data is transmitted LSB to MSB on the bus */
> >  #define DRM_BUS_FLAG_DATA_LSB_TO_MSB   (1<<5)
> > 
> > -/* drive sync on pos. edge */
> > +
> > +/*
> > + * Similarly to the DRM_BUS_FLAG_PIXDATA_* flags, don't use these two
> > flags + * directly, use one of the DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_*
> > instead. + */
> > 
> >  #define DRM_BUS_FLAG_SYNC_POSEDGE  (1<<6)
> > 
> > -/* drive sync on neg. edge */
> > 
> >  #define DRM_BUS_FLAG_SYNC_NEGEDGE  (1<<7)
> > 
> > +/* Drive sync on rising edge */
> > +#define DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE
> > DRM_BUS_FLAG_SYNC_POSEDGE
> > +/* Drive sync on falling edge */
> > +#define DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE
> > DRM_BUS_FLAG_SYNC_NEGEDGE
> > +/* Sample sync on rising edge */
> > +#define DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE   DRM_BUS_FLAG_SYNC_NEGEDGE
> > +/* Sample sync on falling edge */
> > +#define DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE   DRM_BUS_FLAG_SYNC_POSEDGE
> 
> Since these are internal I recommend you convert them over to an enum and
> up this to full kerneldoc comments. That way you can have lots more pretty
> formatting and linking, and an easy way to give others a public link to
> full docs.

The patch is in your mailbox.

> > +
> > /**
> >  * @bus_flags: Additional information (like pixel signal polarity) for
> >  * the pixel data on the bus, using DRM_BUS_FLAGS\_ defines.

-- 
Regards,

Laurent Pinchart



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

[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

[bugzilla-daemon]

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

--- Comment #87 from Brandon Wright  ---
It's important to distinguish between when the compositor and application
desync and when there's actually a driver hiccup. 

If the compositor and application swaps get switched around briefly, it'll
produce stutter, but this won't be reflected on the vsynctester graph (it'll
stay green). If it's red, that means the the application missed a frame. The
former is strictly the compositor's fault.

-- 
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

[PATCH] drm: Turn bus flags macros into an enum

[Laurent Pinchart]

This allows nicer kerneldoc with an easy way to reference the enum and
the values.

Signed-off-by: Laurent Pinchart 
---
 include/drm/drm_connector.h | 108 +---
 1 file changed, 64 insertions(+), 44 deletions(-)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 00bb7a74962b..f5ce255a2cb4 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -253,6 +253,68 @@ enum drm_panel_orientation {
DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
 };
 
+/**
+ * enum drm_bus_flags - bus_flags info for _display_info
+ *
+ * This enum defines signal polarities and clock edge information for signals 
on
+ * a bus as bitmask flags.
+ *
+ * The clock edge information is conveyed by two sets of symbols,
+ * DRM_BUS_FLAGS_*_DRIVE_\* and DRM_BUS_FLAGS_*_SAMPLE_\*. When this enum is
+ * used to describe a bus from the point of view of the transmitter, the
+ * \*_DRIVE_\* flags should be used. When used from the point of view of the
+ * receiver, the \*_SAMPLE_\* flags should be used. The \*_DRIVE_\* and
+ * \*_SAMPLE_\* flags alias each other, with the \*_SAMPLE_POSEDGE and
+ * \*_SAMPLE_NEGEDGE flags being equal to \*_DRIVE_NEGEDGE and \*_DRIVE_POSEDGE
+ * respectively. This simplifies code as signals are usually sampled on the
+ * opposite edge of the driving edge. Transmitters and receivers may however
+ * need to take other signal timings into account to convert between driving
+ * and sample edges.
+ *
+ * @DRM_BUS_FLAG_DE_LOW:   The Data Enable signal is active low
+ * @DRM_BUS_FLAG_DE_HIGH:  The Data Enable signal is active high
+ * @DRM_BUS_FLAG_PIXDATA_POSEDGE:  Legacy value, do not use
+ * @DRM_BUS_FLAG_PIXDATA_NEGEDGE:  Legacy value, do not use
+ * @DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE:Data is driven on the rising 
edge of
+ * the pixel clock
+ * @DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE:Data is driven on the falling 
edge of
+ * the pixel clock
+ * @DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE: Data is sampled on the rising edge of
+ * the pixel clock
+ * @DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE: Data is sampled on the falling edge of
+ * the pixel clock
+ * @DRM_BUS_FLAG_DATA_MSB_TO_LSB:  Data is transmitted MSB to LSB on the 
bus
+ * @DRM_BUS_FLAG_DATA_LSB_TO_MSB:  Data is transmitted LSB to MSB on the 
bus
+ * @DRM_BUS_FLAG_SYNC_POSEDGE: Legacy value, do not use
+ * @DRM_BUS_FLAG_SYNC_NEGEDGE: Legacy value, do not use
+ * @DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE:   Sync signals are driven on the rising
+ * edge of the pixel clock
+ * @DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE:   Sync signals are driven on the falling
+ * edge of the pixel clock
+ * @DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE:  Sync signals are sampled on the rising
+ * edge of the pixel clock
+ * @DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE:  Sync signals are sampled on the falling
+ * edge of the pixel clock
+ */
+enum drm_bus_flags {
+   DRM_BUS_FLAG_DE_LOW = BIT(0),
+   DRM_BUS_FLAG_DE_HIGH = BIT(1),
+   DRM_BUS_FLAG_PIXDATA_POSEDGE = BIT(2),
+   DRM_BUS_FLAG_PIXDATA_NEGEDGE = BIT(3),
+   DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+   DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE = DRM_BUS_FLAG_PIXDATA_NEGEDGE,
+   DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE = DRM_BUS_FLAG_PIXDATA_NEGEDGE,
+   DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+   DRM_BUS_FLAG_DATA_MSB_TO_LSB = BIT(4),
+   DRM_BUS_FLAG_DATA_LSB_TO_MSB = BIT(5),
+   DRM_BUS_FLAG_SYNC_POSEDGE = BIT(6),
+   DRM_BUS_FLAG_SYNC_NEGEDGE = BIT(7),
+   DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE = DRM_BUS_FLAG_SYNC_POSEDGE,
+   DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE = DRM_BUS_FLAG_SYNC_NEGEDGE,
+   DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE = DRM_BUS_FLAG_SYNC_NEGEDGE,
+   DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE = DRM_BUS_FLAG_SYNC_POSEDGE,
+};
+
 /**
  * struct drm_display_info - runtime data about the connected sink
  *
@@ -328,52 +390,10 @@ struct drm_display_info {
 */
unsigned int num_bus_formats;
 
-#define DRM_BUS_FLAG_DE_LOW(1<<0)
-#define DRM_BUS_FLAG_DE_HIGH   (1<<1)
-
-/*
- * Don't use those two flags directly, use the DRM_BUS_FLAG_PIXDATA_DRIVE_*
- * and DRM_BUS_FLAG_PIXDATA_SAMPLE_* variants to qualify the flags explicitly.
- * The DRM_BUS_FLAG_PIXDATA_SAMPLE_* flags are defined as the opposite of the
- * DRM_BUS_FLAG_PIXDATA_DRIVE_* flags to make code simpler, as signals are
- * usually to be sampled on the opposite edge of the driving edge.
- */
-#define DRM_BUS_FLAG_PIXDATA_POSEDGE   (1<<2)
-#define DRM_BUS_FLAG_PIXDATA_NEGEDGE   (1<<3)
-
-/* Drive data on rising edge */
-#define 

Re: [PATCH] drm/msm: Fix A6XX support for opp-level

[Jordan Crouse]

On Fri, Jan 11, 2019 at 02:27:21PM -0800, Douglas Anderson wrote:
> The bindings for Qualcomm opp levels changed after being Acked but
> before landing.  Thus the code in the GPU that was relying on the old
> bindings is now broken.
> 
> While we could just change the string 'qcom,level' to the string
> 'opp-level', it actually seems better to use the newly-introduced
> dev_pm_opp_get_level().
> 
> This patch thus has a hard dependency on the outstanding patch ("OPP:
> Add support for parsing the 'opp-level' property") and will need to
> land in a tree that contains that patch.
> 
> This patch needs to land before the patch ("arm64: dts: sdm845: Add
> gpu and gmu device nodes") since if a tree contains the device tree
> patch but not this one you'll get a crash at bootup.
> 
> Signed-off-by: Douglas Anderson 

Reviewed-by: Jordan Crouse 

> ---
> 
>  drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 5beb83d1cf87..900f18dc1577 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -928,25 +928,20 @@ static int a6xx_gmu_memory_probe(struct a6xx_gmu *gmu)
>  }
>  
>  /* Return the 'arc-level' for the given frequency */
> -static u32 a6xx_gmu_get_arc_level(struct device *dev, unsigned long freq)
> +static unsigned int a6xx_gmu_get_arc_level(struct device *dev,
> +unsigned long freq)
>  {
>   struct dev_pm_opp *opp;
> - struct device_node *np;
> - u32 val = 0;
> + unsigned int val;
>  
>   if (!freq)
>   return 0;
>  
> - opp  = dev_pm_opp_find_freq_exact(dev, freq, true);
> + opp = dev_pm_opp_find_freq_exact(dev, freq, true);
>   if (IS_ERR(opp))
>   return 0;
>  
> - np = dev_pm_opp_get_of_node(opp);
> -
> - if (np) {
> - of_property_read_u32(np, "qcom,level", );
> - of_node_put(np);
> - }
> + val = dev_pm_opp_get_level(opp);
>  
>   dev_pm_opp_put(opp);
>  
> @@ -982,7 +977,7 @@ static int a6xx_gmu_rpmh_arc_votes_init(struct device 
> *dev, u32 *votes,
>   /* Construct a vote for each frequency */
>   for (i = 0; i < freqs_count; i++) {
>   u8 pindex = 0, sindex = 0;
> - u32 level = a6xx_gmu_get_arc_level(dev, freqs[i]);
> + unsigned int level = a6xx_gmu_get_arc_level(dev, freqs[i]);
>  
>   /* Get the primary index that matches the arc level */
>   for (j = 0; j < pri_count; j++) {
> -- 
> 2.20.1.97.g81188d93c3-goog
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109327] Wolfenstein II The New Colossus crashes after the first cutscene of the game

[bugzilla-daemon]

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

--- Comment #1 from Ahmed Elsayed  ---
I forgot to mention that Doom 2016 does the same thing, but it has option to
switch to OpenGl 4.5 which works for me.

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

[Bug 109327] Wolfenstein II The New Colossus crashes after the first cutscene of the game

[bugzilla-daemon]

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

Bug ID: 109327
   Summary: Wolfenstein II The New Colossus crashes after the
first cutscene of the game
   Product: Mesa
   Version: 18.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ahmed@protonmail.com
QA Contact: dri-devel@lists.freedesktop.org

System Specifications:

CPU: Intel core I5 4200M
GPU: AMD HD 8750M (2gb)
Ram: DDR3 6gb
OS: Manjaro KDE 18.02
GPU Driver: Mesa 18.3.1 stable LLVM 7.0.1

The game at first was running on my iGPU, so I had to delete Vulkan-intel in
order to force it to run on my dGPU and that worked, but after that I got an
error message: (Driver issue) Required version 17.10.2 | Detected 0.0.0 |
Installed driver is out of date, please upgrade to the latest version. After I
press ok the game runs, but after starting the game for the first time, it
crashes after the first cutscene, and I had to force close my computer.

-- 
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

[PULL] drm-fixes

[Daniel Vetter]

Hi Linus,

Dave sends out his pull, everybody remembers holidays are over :-)

Since Dave's already in w/e mode and it was quite a few patches I figured
better to apply all the pulls and forward them to you. Hence here 2nd part
of bugfixes for -rc2.

nouveau:
one backlight, falcon register access, and a fan fix.

i915:
- Disable PSR for Apple panels
- Broxton ERR_PTR error state fix
- Kabylake VECS workaround fix
- Unwind failure on pinning the gen7 ppgtt
- GVT workload request allocation fix

core:
- Fix fb-helper to work correctly with SDL 1.2 bugs.
- Fix lockdep warning in the atomic ioctl and setproperty.

Cheers, Daniel

The following changes since commit f34c48e06ddcc197f2cf7cbc006ceb74e28e1ccf:

  Merge branch 'drm-fixes-5.0' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2019-01-11 07:38:56 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-11-1

for you to fetch changes up to e2d3c414ec0f9d1557c8c5ff2c32166e68bbc4ad:

  Merge tag 'drm-intel-fixes-2019-01-11' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-01-11 10:26:21 
+0100)


drm-fixes for 5.0-rc2, part 2

nouveau:
one backlight, falcon register access, and a fan fix.

i915:
- Disable PSR for Apple panels
- Broxton ERR_PTR error state fix
- Kabylake VECS workaround fix
- Unwind failure on pinning the gen7 ppgtt
- GVT workload request allocation fix

core:
- Fix fb-helper to work correctly with SDL 1.2 bugs.
- Fix lockdep warning in the atomic ioctl and setproperty.


Ben Skeggs (1):
  drm/nouveau: register backlight on pascal and newer

Chris Wilson (2):
  drm/i915: Skip the ERR_PTR error state
  drm/i915: Unwind failure on pinning the gen7 ppgtt

Daniel Vetter (2):
  Merge tag 'drm-misc-fixes-2019-01-10-1' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2019-01-11' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Daniele Ceraolo Spurio (1):
  drm/i915: init per-engine WAs for all engines

Dave Airlie (1):
  Merge branch 'linux-4.21' of git://github.com/skeggsb/linux into drm-fixes

Ilia Mirkin (1):
  drm/nouveau/falcon: avoid touching registers if engine is off

Ivan Mironov (2):
  drm/fb-helper: Partially bring back workaround for bugs of SDL 1.2
  drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock

Jani Nikula (1):
  Merge tag 'gvt-fixes-2019-01-09' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

José Roberto de Souza (2):
  drm/i915: Disable PSR in Apple panels
  drm: Fix documentation generation for DP_DPCD_QUIRK_NO_PSR

Takashi Iwai (1):
  drm/nouveau: Don't disable polling in fallback mode

Tetsuo Handa (1):
  gpu/drm: Fix lock held when returning to user space.

Zhenyu Wang (1):
  drm/i915/gvt: Fix workload request allocation before request add

 drivers/gpu/drm/drm_atomic_uapi.c|   3 +-
 drivers/gpu/drm/drm_dp_helper.c  |   2 +
 drivers/gpu/drm/drm_fb_helper.c  | 133 ++-
 drivers/gpu/drm/drm_mode_object.c|   4 +-
 drivers/gpu/drm/i915/gvt/scheduler.c |  64 +++
 drivers/gpu/drm/i915/gvt/scheduler.h |   1 +
 drivers/gpu/drm/i915/i915_debugfs.c  |  12 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  15 ++-
 drivers/gpu/drm/i915/i915_gpu_error.c|  23 ++--
 drivers/gpu/drm/i915/i915_sysfs.c|   4 +-
 drivers/gpu/drm/i915/intel_lrc.c |   3 +-
 drivers/gpu/drm/i915/intel_psr.c |   6 +
 drivers/gpu/drm/nouveau/nouveau_backlight.c  |   3 +
 drivers/gpu/drm/nouveau/nvkm/engine/falcon.c |   7 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c |   7 +-
 include/drm/drm_dp_helper.h  |   7 ++
 16 files changed, 192 insertions(+), 102 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/5] drm/of: Fix kerneldoc

[Sam Ravnborg]

On Fri, Jan 11, 2019 at 05:40:45PM +0100, Daniel Vetter wrote:
> I noticed a link that didn't work ...
> 
> Fixes: 1f2db3034c9f ("drm: of: introduce drm_of_find_panel_or_bridge")
> Cc: Rob Herring 
> Cc: Philipp Zabel 
> Cc: Sean Paul 
> Signed-off-by: Daniel Vetter 
Reviewed-by: Sam Ravnborg 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/doc: Move bridge link target to the right place

[Sam Ravnborg]

On Fri, Jan 11, 2019 at 05:40:47PM +0100, Daniel Vetter wrote:
> I screwed up a rebase somehow.
> 
> v2: Drop bogus hunk.
> 
> v3: Really drop bogus hunk (Lubomir).
> 
> Cc: Lubomir Rintel 
> Signed-off-by: Daniel Vetter 
Reviewed-by: Sam Ravnborg 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/panel: Small documentation polish

[Sam Ravnborg]

On Fri, Jan 11, 2019 at 05:40:46PM +0100, Daniel Vetter wrote:
> Need to make sure people can find the panel-bridge to avoid typing too
> much.
> 
> Signed-off-by: Daniel Vetter 
Reviewed-by: Sam Ravnborg 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/docs: improve docs for drm_drv.c

[Sam Ravnborg]

On Fri, Jan 11, 2019 at 05:40:44PM +0100, Daniel Vetter wrote:
> Just a bit of drive-by reading:
> - drm_dev_set_unique() is really the exception, make that clear.
> - drm_dev_init() is the recomended approach.
> 
> Signed-off-by: Daniel Vetter 
Reviewed-by: Sam Ravnborg 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm: Fix A6XX support for opp-level

[Douglas Anderson]

The bindings for Qualcomm opp levels changed after being Acked but
before landing.  Thus the code in the GPU that was relying on the old
bindings is now broken.

While we could just change the string 'qcom,level' to the string
'opp-level', it actually seems better to use the newly-introduced
dev_pm_opp_get_level().

This patch thus has a hard dependency on the outstanding patch ("OPP:
Add support for parsing the 'opp-level' property") and will need to
land in a tree that contains that patch.

This patch needs to land before the patch ("arm64: dts: sdm845: Add
gpu and gmu device nodes") since if a tree contains the device tree
patch but not this one you'll get a crash at bootup.

Signed-off-by: Douglas Anderson 
---

 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 5beb83d1cf87..900f18dc1577 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -928,25 +928,20 @@ static int a6xx_gmu_memory_probe(struct a6xx_gmu *gmu)
 }
 
 /* Return the 'arc-level' for the given frequency */
-static u32 a6xx_gmu_get_arc_level(struct device *dev, unsigned long freq)
+static unsigned int a6xx_gmu_get_arc_level(struct device *dev,
+  unsigned long freq)
 {
struct dev_pm_opp *opp;
-   struct device_node *np;
-   u32 val = 0;
+   unsigned int val;
 
if (!freq)
return 0;
 
-   opp  = dev_pm_opp_find_freq_exact(dev, freq, true);
+   opp = dev_pm_opp_find_freq_exact(dev, freq, true);
if (IS_ERR(opp))
return 0;
 
-   np = dev_pm_opp_get_of_node(opp);
-
-   if (np) {
-   of_property_read_u32(np, "qcom,level", );
-   of_node_put(np);
-   }
+   val = dev_pm_opp_get_level(opp);
 
dev_pm_opp_put(opp);
 
@@ -982,7 +977,7 @@ static int a6xx_gmu_rpmh_arc_votes_init(struct device *dev, 
u32 *votes,
/* Construct a vote for each frequency */
for (i = 0; i < freqs_count; i++) {
u8 pindex = 0, sindex = 0;
-   u32 level = a6xx_gmu_get_arc_level(dev, freqs[i]);
+   unsigned int level = a6xx_gmu_get_arc_level(dev, freqs[i]);
 
/* Get the primary index that matches the arc level */
for (j = 0; j < pri_count; j++) {
-- 
2.20.1.97.g81188d93c3-goog

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

Re: [PATCH v4 1/2] drm: Add color management LUT validation helper (v4)

[Matt Roper]

Dave, Daniel - any concerns if we merge this drm core patch through the
Intel tree?  The second patch in the series doesn't apply cleanly in
drm-misc-next.


Matt


On Mon, Dec 17, 2018 at 02:44:14PM -0800, Matt Roper wrote:
> Some hardware may place additional restrictions on the gamma/degamma
> curves described by our LUT properties.  E.g., that a gamma curve never
> decreases or that the red/green/blue channels of a LUT's entries must be
> equal.  Let's add a helper function that drivers can use to test that a
> userspace-provided LUT is valid and doesn't violate hardware
> requirements.
> 
> v2:
>  - Combine into a single helper that just takes a bitmask of the tests
>to apply.  (Brian Starkey)
>  - Add additional check (always performed) that LUT property blob size
>is always a multiple of the LUT entry size.  (stolen from ARM driver)
> 
> v3:
>  - Drop the LUT size check again since
>drm_atomic_replace_property_blob_from_id() already covers this for
>us.  (Alexandru Gheorghe)
> 
> v4:
>  - Use an enum to describe possible test values rather than #define's;
>this is cleaner to provide kerneldoc for.  (Daniel Vetter)
>  - s/DRM_COLOR_LUT_INCREASING/DRM_COLOR_LUT_NON_DECREASING/.  (Ville)
> 
> Cc: Uma Shankar 
> Cc: Swati Sharma 
> Cc: Brian Starkey 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Signed-off-by: Matt Roper 
> Reviewed-by(v1): Brian Starkey 
> Reviewed-by: Alexandru Gheorghe 
> Reviewed-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_color_mgmt.c | 44 
> 
>  include/drm/drm_color_mgmt.h | 29 ++
>  2 files changed, 73 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 07dcf47daafe..968ca7c91ad8 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -462,3 +462,47 @@ int drm_plane_create_color_properties(struct drm_plane 
> *plane,
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_plane_create_color_properties);
> +
> +/**
> + * drm_color_lut_check - check validity of lookup table
> + * @lut: property blob containing LUT to check
> + * @tests: bitmask of tests to run
> + *
> + * Helper to check whether a userspace-provided lookup table is valid and
> + * satisfies hardware requirements.  Drivers pass a bitmask indicating which 
> of
> + * the tests in _color_lut_tests should be performed.
> + *
> + * Returns 0 on success, -EINVAL on failure.
> + */
> +int drm_color_lut_check(struct drm_property_blob *lut,
> + uint32_t tests)
> +{
> + struct drm_color_lut *entry;
> + int i;
> +
> + if (!lut || !tests)
> + return 0;
> +
> + entry = lut->data;
> + for (i = 0; i < drm_color_lut_size(lut); i++) {
> + if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
> + if (entry[i].red != entry[i].blue ||
> + entry[i].red != entry[i].green) {
> + DRM_DEBUG_KMS("All LUT entries must have equal 
> r/g/b\n");
> + return -EINVAL;
> + }
> + }
> +
> + if (i > 0 && tests & DRM_COLOR_LUT_NON_DECREASING) {
> + if (entry[i].red < entry[i - 1].red ||
> + entry[i].green < entry[i - 1].green ||
> + entry[i].blue < entry[i - 1].blue) {
> + DRM_DEBUG_KMS("LUT entries must never 
> decrease.\n");
> + return -EINVAL;
> + }
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_color_lut_check);
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 90ef9996d9a4..6affbda6d9cb 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -69,4 +69,33 @@ int drm_plane_create_color_properties(struct drm_plane 
> *plane,
> u32 supported_ranges,
> enum drm_color_encoding default_encoding,
> enum drm_color_range default_range);
> +
> +/**
> + * enum drm_color_lut_tests - hw-specific LUT tests to perform
> + *
> + * The drm_color_lut_check() function takes a bitmask of the values here to
> + * determine which tests to apply to a userspace-provided LUT.
> + */
> +enum drm_color_lut_tests {
> + /**
> +  * @DRM_COLOR_LUT_EQUAL_CHANNELS:
> +  *
> +  * Checks whether the entries of a LUT all have equal values for the
> +  * red, green, and blue channels.  Intended for hardware that only
> +  * accepts a single value per LUT entry and assumes that value applies
> +  * to all three color components.
> +  */
> + DRM_COLOR_LUT_EQUAL_CHANNELS = BIT(0),
> +
> + /**
> +  * @DRM_COLOR_LUT_NON_DECREASING:
> +  *
> +  * Checks whether the entries of a LUT are always flat or increasing
> +  * (never 

Re: [PATCH 6/7] drm/tda998x: Don't set dpms hook

[Russell King - ARM Linux]

On Fri, Jan 11, 2019 at 10:55:42PM +0100, Daniel Vetter wrote:
> On Fri, Jan 11, 2019 at 04:41:21PM +0100, Noralf Trønnes wrote:
> > Den 17.12.2018 20.43, skrev Daniel Vetter:
> > > Doesn't do anything for atomic drivers.
> > > 
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Russell King 
> > > ---
> > >  drivers/gpu/drm/i2c/tda998x_drv.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> > > b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > index a7c39f39793f..f8a1d70a31c7 100644
> > > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > @@ -1122,7 +1122,6 @@ static void tda998x_connector_destroy(struct 
> > > drm_connector *connector)
> > >  }
> > >  
> > >  static const struct drm_connector_funcs tda998x_connector_funcs = {
> > > - .dpms = drm_helper_connector_dpms,
> > >   .reset = drm_atomic_helper_connector_reset,
> > >   .fill_modes = drm_helper_probe_single_connector_modes,
> > >   .detect = tda998x_connector_detect,
> > > 
> > 
> > Acked-by: Noralf Trønnes 
> 
> Thanks for taking a look. The next patch unfortunately needs a lot more
> work, and quite some coordination with other trees, due to all the
> in-flight drmP.h cleanups. I think I'll wait a bit before resending that
> one again.

Are there any dependencies that would affect where the above patch can
be applied?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/doc: Polish kerneldoc for drm_device.h

[Daniel Vetter]

On Fri, Jan 11, 2019 at 06:15:17PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
> 
> Thanks, good to have it ready and plugged into DRM doc.
> I like that the legacy stuff is now separate - so one knows
> what not to look at.
> 
> > +
> > +   /**
> > +* @irq: Use by the drm_irq_install() and drm_irq_unistall() helpers.
> > +*/
> > int irq;
> 
> "Use => Used"
> 
> Other than the above nit:
> Acked-by: Sam Ravnborg 

Fixed and applied, thanks for taking a look. Care to also review the first
4 patches in this small documentation series?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/cirrus: fix connector leak at unload

[Daniel Vetter]

On Fri, Jan 11, 2019 at 11:06:20PM +0100, Daniel Vetter wrote:
> On Fri, Jan 11, 2019 at 09:02:34AM -0500, Rob Clark wrote:
> > This fixes an '*ERROR* connector VGA-2 leaked!' splat at driver unload.
> > 
> > Signed-off-by: Rob Clark 
> > ---
> > Similar case to the issue that was fixed recently in drm/ast
> 
> Reviewed-by: Daniel Vetter 

Actually I just pushed a patch to drm-misc-next to rename this function to
drm_helper_force_disable_all(), so you need to respin ... My r-b still
holds.
-Daniel

> 
> > 
> >  drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> > b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> > index 4dd499c7d1ba..bb379ec4c182 100644
> > --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> > +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> > @@ -256,6 +256,8 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
> >  {
> > struct drm_framebuffer *gfb = gfbdev->gfb;
> >  
> > +   drm_crtc_force_disable_all(dev);
> > +
> > drm_fb_helper_unregister_fbi(>helper);
> >  
> > vfree(gfbdev->sysram);
> > -- 
> > 2.20.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

[bugzilla-daemon]

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

--- Comment #86 from tempel.jul...@gmail.com ---
Thanks for trying to reproduce.
Hm, that leaves me clueless. It's 100% reproducible here and I tried things
like forcing high performance profile, using plain 60Hz edid and disabling
overclock, which all don't show any effect in that regard.
I perhaps should attach new logfiles.

-- 
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/cirrus: fix connector leak at unload

[Daniel Vetter]

On Fri, Jan 11, 2019 at 09:02:34AM -0500, Rob Clark wrote:
> This fixes an '*ERROR* connector VGA-2 leaked!' splat at driver unload.
> 
> Signed-off-by: Rob Clark 
> ---
> Similar case to the issue that was fixed recently in drm/ast

Reviewed-by: Daniel Vetter 

> 
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 4dd499c7d1ba..bb379ec4c182 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -256,6 +256,8 @@ static int cirrus_fbdev_destroy(struct drm_device *dev,
>  {
>   struct drm_framebuffer *gfb = gfbdev->gfb;
>  
> + drm_crtc_force_disable_all(dev);
> +
>   drm_fb_helper_unregister_fbi(>helper);
>  
>   vfree(gfbdev->sysram);
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/2] drm/sched: Refactor ring mirror list handling.

[Grodzovsky, Andrey]

On 01/11/2019 02:11 PM, Koenig, Christian wrote:
> Am 11.01.19 um 16:37 schrieb Grodzovsky, Andrey:
>> On 01/11/2019 04:42 AM, Koenig, Christian wrote:
>>> Am 10.01.19 um 16:56 schrieb Grodzovsky, Andrey:
 [SNIP]
>>> But we will not be adding the cb back in drm_sched_stop anymore, now we
>>> are only going to add back the cb in drm_sched_startr after rerunning
>>> those jobs in drm_sched_resubmit_jobs and assign them a new parent
>>> there
>>> anyway.
>> Yeah, but when we find that we don't need to reset anything anymore
>> then adding the callbacks again won't be possible any more.
>>
>> Christian.
> I am not sure I understand it, can u point me to example of how this
> will happen ? I am attaching my latest patches with waiting only for
> the last job's fence here just so we are on same page regarding the code.
>>> Well the whole idea is to prepare all schedulers, then check once more
>>> if the offending job hasn't completed in the meantime.
>>>
>>> If the job completed we need to be able to rollback everything and
>>> continue as if nothing had happened.
>>>
>>> Christian.
>> Oh, but this piece of functionality - skipping HW ASIC reset in case the
>> guilty job done is totally missing form this patch series and so needs
>> to be added. So what you say actually is that for the case were we skip
>> HW asic reset because the guilty job did complete we also need to skip
>> resubmitting the jobs in drm_sched_resubmit_jobs and hence preserve the
>> old parent fence pointer for reuse ? If so I would like to add all this
>> functionality as a third patch since the first 2 patches are more about
>> resolving race condition with jobs in flight while doing reset - what do
>> you think ?
> Yeah, sounds perfectly fine to me.
>
> Christian.

I realized there is another complication now for XGMI hive use case, we 
currently skip gpu recover for adev in case another gpu recover for 
different adev in same hive is running, under the assumption that we are 
going to reset all devices in hive anyway because that should cover our 
own dev too. But if we chose to skip now HW asic reset if our guilty job 
did finish we will aslo not HW reset any other devices in the hive even 
if one of them might actually had a bad job, wanted to do gpu recover 
but skipped it because our recover was in progress in that time.
My general idea on that is to keep a list of guilty jobs per hive, when 
you start gpu recover you first add you guilty job to the hive and 
trylock hive->reset_lock. Any owner of hive->reset_lock (gpu recovery in 
progress) once he finished his recovery and released hive->reset_lock 
should go over hive->bad_jobs_list and if at least one of them is still 
not signaled (not done) trigger another gpu recovery and so on. If you 
do manage to trylock you also go over the list, clean it and perform 
recovery. This list probably needs to be protected with per hive lock.
I also think we can for now at least finish reviewing the first 2 
patches and submit them since as I said before they are not dealing with 
this topic and fixing existing race conditions. If you are OK with that 
I can send for review the last iteration of the first 2 patches where I 
wait for the last fence in ring mirror list.

Andrey

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

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

Re: [PATCH 6/7] drm/tda998x: Don't set dpms hook

[Daniel Vetter]

On Fri, Jan 11, 2019 at 04:41:21PM +0100, Noralf Trønnes wrote:
> Den 17.12.2018 20.43, skrev Daniel Vetter:
> > Doesn't do anything for atomic drivers.
> > 
> > Signed-off-by: Daniel Vetter 
> > Cc: Russell King 
> > ---
> >  drivers/gpu/drm/i2c/tda998x_drv.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> > b/drivers/gpu/drm/i2c/tda998x_drv.c
> > index a7c39f39793f..f8a1d70a31c7 100644
> > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > @@ -1122,7 +1122,6 @@ static void tda998x_connector_destroy(struct 
> > drm_connector *connector)
> >  }
> >  
> >  static const struct drm_connector_funcs tda998x_connector_funcs = {
> > -   .dpms = drm_helper_connector_dpms,
> > .reset = drm_atomic_helper_connector_reset,
> > .fill_modes = drm_helper_probe_single_connector_modes,
> > .detect = tda998x_connector_detect,
> > 
> 
> Acked-by: Noralf Trønnes 

Thanks for taking a look. The next patch unfortunately needs a lot more
work, and quite some coordination with other trees, due to all the
in-flight drmP.h cleanups. I think I'll wait a bit before resending that
one again.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6] drm/panel: Add a driver for the TPO TPG110

[Daniel Vetter]

On Fri, Jan 11, 2019 at 8:54 PM Linus Walleij  wrote:
>
> On Thu, Jan 10, 2019 at 9:01 PM Jagan Teki  wrote:
>
> > Just for my information, for each new panel addition, is MAINTAINERS
> > file will update only by drm-misc members or anyone who submitted the
> > patch? The last communication with seanpaul mentioned this context[1]
> > just want to understand how this panels were maintained.
> >
> >  [1] https://lkml.org/lkml/2018/12/14/1275
>
> Aha I see. Well this per-panel entry is good because then
> get_maintainer.pl will also get me specifically and not just
> the people listed for panel/drm-misc (whether I am, was
> or will be a member of that group or not).
>
> get_maintainer.pl will present all of them with me on
> top:
>
> $ scripts/get_maintainer.pl -f drivers/gpu/drm/panel/panel-tpo-tpg110.c
> Linus Walleij  (maintainer:DRM DRIVER FOR
> TPO TPG110 PANELS)
> Thierry Reding  (maintainer:DRM PANEL DRIVERS)
> David Airlie  (maintainer:DRM DRIVERS)
> Daniel Vetter  (maintainer:DRM DRIVERS)
> dri-devel@lists.freedesktop.org (open list:DRM PANEL DRIVERS)
> linux-ker...@vger.kernel.org (open list)
>
> So I would advice against the above practice: one does not
> exclude the other.

Yeah we have lots of MAINTAINERS entries for all the various things
maintained as part of drm-misc. Only thing I'm encouraging is that
everything has at least a T: git repo entry pointing at drm-misc
somewhere, to have some easy overview of what's under the drm-misc
umbrella. But the overall drm panel entry has that covered already.
And we also have some other more specific entries for individual
panels already.
-Daniel

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



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V7 2/2] drm/panel: Add Sitronix ST7701 panel driver

[Noralf Trønnes]

Den 11.01.2019 22.19, skrev Sam Ravnborg:
> Hi Jagan.
> 
> Gave this another more detailed read - triggered some additional comments.
> Depite the comments it looks good, and this is all more or
> less cosmetic improvements.
> 
>   Sam
> 
>> +struct st7701_panel_desc {
>> +const struct drm_display_mode *mode;
>> +unsigned int lanes;
>> +unsigned long flags;
>> +enum mipi_dsi_pixel_format format;
>> +const char *const *supply_names;
>> +unsigned int num_supplies;
>> +unsigned int panel_sleep_delay;
>> +};
>> +
>> +struct st7701 {
>> +struct drm_panel panel;
>> +struct mipi_dsi_device *dsi;
>> +const struct st7701_panel_desc *desc;
>> +
>> +struct backlight_device *backlight;
>> +struct regulator_bulk_data *supplies;
>> +unsigned int num_supplies;
> I cannot see that num_supplies in this struct are used?
> 
> 
>> +struct gpio_desc *reset;
>> +unsigned int sleep_delay;
>> +};
>> +
>> +static inline struct st7701 *panel_to_st7701(struct drm_panel *panel)
>> +{
>> +return container_of(panel, struct st7701, panel);
>> +}
>> +
>> +static inline int st7701_dsi_write(struct st7701 *st7701, const void *seq,
>> +   size_t len)
>> +{
>> +return mipi_dsi_dcs_write_buffer(st7701->dsi, seq, len);
>> +}
>> +
> 
> 
>> +static int st7701_prepare(struct drm_panel *panel)
>> +{
>> +struct st7701 *st7701 = panel_to_st7701(panel);
>> +int ret;
>> +
>> +gpiod_set_value(st7701->reset, 0);
>> +msleep(20);
>> +
>> +ret = regulator_bulk_enable(st7701->desc->num_supplies,
>> +st7701->supplies);
>> +if (ret < 0)
>> +return ret;
>> +msleep(20);
>> +
>> +gpiod_set_value(st7701->reset, 1);
>> +msleep(20);
>> +
>> +gpiod_set_value(st7701->reset, 0);
>> +msleep(30);
>> +
>> +gpiod_set_value(st7701->reset, 1);
>> +msleep(150);
>> +
>> +st7701_init_sequence(st7701);
>> +
>> +return 0;
>> +}
>> +
> 
>> +static int st7701_unprepare(struct drm_panel *panel)
>> +{
>> +struct st7701 *st7701 = panel_to_st7701(panel);
>> +
>> +ST7701_DSI(st7701, MIPI_DCS_EXIT_SLEEP_MODE, 0x00);
>> +
>> +msleep(st7701->sleep_delay);
>> +
>> +gpiod_set_value(st7701->reset, 0);
>> +
>> +gpiod_set_value(st7701->reset, 1);
>> +
>> +gpiod_set_value(st7701->reset, 0);
> No timing constrains here? In prepare there are sleeps intermixed.
> 
>> +
>> +regulator_bulk_disable(st7701->desc->num_supplies, st7701->supplies);
>> +
>> +return 0;
>> +}
>> +
>> +static int st7701_get_modes(struct drm_panel *panel)
>> +{
>> +struct st7701 *st7701 = panel_to_st7701(panel);
>> +const struct drm_display_mode *desc_mode = st7701->desc->mode;
>> +struct drm_display_mode *mode;
>> +
>> +mode = drm_mode_duplicate(panel->drm, desc_mode);
>> +if (!mode) {
>> +dev_err(>dsi->dev, "failed to add mode %ux%ux@%u\n",
>> +desc_mode->hdisplay, desc_mode->vdisplay,
>> +desc_mode->vrefresh);
> Use something like:
>   DRM_DEV_ERROR(st7701->dev, "failed to add mode" DRM_MODE_FMT ",
> DRM_MODE_ARG(desc_mode));
> 
>> +return -ENOMEM;
>> +}
>> +
>> +drm_mode_set_name(mode);
>> +drm_mode_probed_add(panel->connector, mode);
>> +
>> +panel->connector->display_info.width_mm = desc_mode->width_mm;
>> +panel->connector->display_info.height_mm = desc_mode->height_mm;
>> +
>> +return 1;
>> +}
>> +
> 
>> +static const struct st7701_panel_desc ts8550b_desc = {
>> +.mode = _mode,
>> +.lanes = 2,
>> +.flags = MIPI_DSI_MODE_VIDEO,
>> +.format = MIPI_DSI_FMT_RGB888,
>> +.supply_names = ts8550b_supply_names,
>> +.num_supplies = ARRAY_SIZE(ts8550b_supply_names),
>> +.panel_sleep_delay = 80, /* panel need extra 80ms for sleep out cmd */
> In the only place this is used there is added 120 ms too.
> Looks inconsistent - do we have the same delay twice?
> 
> 
>> +
>> +static int st7701_dsi_probe(struct mipi_dsi_device *dsi)
>> +{
>> +const struct st7701_panel_desc *desc;
>> +struct device_node *np;
>> +struct st7701 *st7701;
>> +int ret, i;
>> +
>> +st7701 = devm_kzalloc(>dev, sizeof(*st7701), GFP_KERNEL);
>> +if (!st7701)
>> +return -ENOMEM;
>> +
>> +desc = of_device_get_match_data(>dev);
>> +dsi->mode_flags = desc->flags;
>> +dsi->format = desc->format;
>> +dsi->lanes = desc->lanes;
>> +
>> +st7701->supplies = devm_kcalloc(>dev, desc->num_supplies,
>> +sizeof(*st7701->supplies),
>> +GFP_KERNEL);
>> +if (!st7701->supplies)
>> +return -ENOMEM;
>> +
>> +for (i = 0; i < desc->num_supplies; i++)
>> +st7701->supplies[i].supply = desc->supply_names[i];
>> +
>> +ret = devm_regulator_bulk_get(>dev, desc->num_supplies,
>> +  

Re: [PATCH V7 2/2] drm/panel: Add Sitronix ST7701 panel driver

[Sam Ravnborg]

Hi Jagan.

Gave this another more detailed read - triggered some additional comments.
Depite the comments it looks good, and this is all more or
less cosmetic improvements.

Sam

> +struct st7701_panel_desc {
> + const struct drm_display_mode *mode;
> + unsigned int lanes;
> + unsigned long flags;
> + enum mipi_dsi_pixel_format format;
> + const char *const *supply_names;
> + unsigned int num_supplies;
> + unsigned int panel_sleep_delay;
> +};
> +
> +struct st7701 {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + const struct st7701_panel_desc *desc;
> +
> + struct backlight_device *backlight;
> + struct regulator_bulk_data *supplies;
> + unsigned int num_supplies;
I cannot see that num_supplies in this struct are used?


> + struct gpio_desc *reset;
> + unsigned int sleep_delay;
> +};
> +
> +static inline struct st7701 *panel_to_st7701(struct drm_panel *panel)
> +{
> + return container_of(panel, struct st7701, panel);
> +}
> +
> +static inline int st7701_dsi_write(struct st7701 *st7701, const void *seq,
> +size_t len)
> +{
> + return mipi_dsi_dcs_write_buffer(st7701->dsi, seq, len);
> +}
> +


> +static int st7701_prepare(struct drm_panel *panel)
> +{
> + struct st7701 *st7701 = panel_to_st7701(panel);
> + int ret;
> +
> + gpiod_set_value(st7701->reset, 0);
> + msleep(20);
> +
> + ret = regulator_bulk_enable(st7701->desc->num_supplies,
> + st7701->supplies);
> + if (ret < 0)
> + return ret;
> + msleep(20);
> +
> + gpiod_set_value(st7701->reset, 1);
> + msleep(20);
> +
> + gpiod_set_value(st7701->reset, 0);
> + msleep(30);
> +
> + gpiod_set_value(st7701->reset, 1);
> + msleep(150);
> +
> + st7701_init_sequence(st7701);
> +
> + return 0;
> +}
> +

> +static int st7701_unprepare(struct drm_panel *panel)
> +{
> + struct st7701 *st7701 = panel_to_st7701(panel);
> +
> + ST7701_DSI(st7701, MIPI_DCS_EXIT_SLEEP_MODE, 0x00);
> +
> + msleep(st7701->sleep_delay);
> +
> + gpiod_set_value(st7701->reset, 0);
> +
> + gpiod_set_value(st7701->reset, 1);
> +
> + gpiod_set_value(st7701->reset, 0);
No timing constrains here? In prepare there are sleeps intermixed.

> +
> + regulator_bulk_disable(st7701->desc->num_supplies, st7701->supplies);
> +
> + return 0;
> +}
> +
> +static int st7701_get_modes(struct drm_panel *panel)
> +{
> + struct st7701 *st7701 = panel_to_st7701(panel);
> + const struct drm_display_mode *desc_mode = st7701->desc->mode;
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_duplicate(panel->drm, desc_mode);
> + if (!mode) {
> + dev_err(>dsi->dev, "failed to add mode %ux%ux@%u\n",
> + desc_mode->hdisplay, desc_mode->vdisplay,
> + desc_mode->vrefresh);
Use something like:
DRM_DEV_ERROR(st7701->dev, "failed to add mode" DRM_MODE_FMT ",
  DRM_MODE_ARG(desc_mode));

> + return -ENOMEM;
> + }
> +
> + drm_mode_set_name(mode);
> + drm_mode_probed_add(panel->connector, mode);
> +
> + panel->connector->display_info.width_mm = desc_mode->width_mm;
> + panel->connector->display_info.height_mm = desc_mode->height_mm;
> +
> + return 1;
> +}
> +

> +static const struct st7701_panel_desc ts8550b_desc = {
> + .mode = _mode,
> + .lanes = 2,
> + .flags = MIPI_DSI_MODE_VIDEO,
> + .format = MIPI_DSI_FMT_RGB888,
> + .supply_names = ts8550b_supply_names,
> + .num_supplies = ARRAY_SIZE(ts8550b_supply_names),
> + .panel_sleep_delay = 80, /* panel need extra 80ms for sleep out cmd */
In the only place this is used there is added 120 ms too.
Looks inconsistent - do we have the same delay twice?


> +
> +static int st7701_dsi_probe(struct mipi_dsi_device *dsi)
> +{
> + const struct st7701_panel_desc *desc;
> + struct device_node *np;
> + struct st7701 *st7701;
> + int ret, i;
> +
> + st7701 = devm_kzalloc(>dev, sizeof(*st7701), GFP_KERNEL);
> + if (!st7701)
> + return -ENOMEM;
> +
> + desc = of_device_get_match_data(>dev);
> + dsi->mode_flags = desc->flags;
> + dsi->format = desc->format;
> + dsi->lanes = desc->lanes;
> +
> + st7701->supplies = devm_kcalloc(>dev, desc->num_supplies,
> + sizeof(*st7701->supplies),
> + GFP_KERNEL);
> + if (!st7701->supplies)
> + return -ENOMEM;
> +
> + for (i = 0; i < desc->num_supplies; i++)
> + st7701->supplies[i].supply = desc->supply_names[i];
> +
> + ret = devm_regulator_bulk_get(>dev, desc->num_supplies,
> +   st7701->supplies);
> + if (ret < 0)
> + return ret;
> +
> + st7701->reset = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
> + if 

Re: [PATCH] drm/virtio: drop prime import/export callbacks

[Dave Airlie]

On Thu, 10 Jan 2019 at 21:16, Gerd Hoffmann  wrote:
>
> Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> userspace.

Reviewed-by: Dave Airlie 
>
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.h   |  4 
>  drivers/gpu/drm/virtio/virtgpu_drv.c   |  4 
>  drivers/gpu/drm/virtio/virtgpu_prime.c | 14 --
>  3 files changed, 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index cf896d8793..4f2f3c43a4 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -354,10 +354,6 @@ int virtio_gpu_object_wait(struct virtio_gpu_object *bo, 
> bool no_wait);
>  /* virtgpu_prime.c */
>  int virtgpu_gem_prime_pin(struct drm_gem_object *obj);
>  void virtgpu_gem_prime_unpin(struct drm_gem_object *obj);
> -struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
> -struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
> -   struct drm_device *dev, struct dma_buf_attachment *attach,
> -   struct sg_table *sgt);
>  void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj);
>  void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
>  int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
> b/drivers/gpu/drm/virtio/virtgpu_drv.c
> index af92964b68..b996ac1d4f 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -205,14 +205,10 @@ static struct drm_driver driver = {
>  #if defined(CONFIG_DEBUG_FS)
> .debugfs_init = virtio_gpu_debugfs_init,
>  #endif
> -   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> -   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_export = drm_gem_prime_export,
> .gem_prime_import = drm_gem_prime_import,
> .gem_prime_pin = virtgpu_gem_prime_pin,
> .gem_prime_unpin = virtgpu_gem_prime_unpin,
> -   .gem_prime_get_sg_table = virtgpu_gem_prime_get_sg_table,
> -   .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
> .gem_prime_vmap = virtgpu_gem_prime_vmap,
> .gem_prime_vunmap = virtgpu_gem_prime_vunmap,
> .gem_prime_mmap = virtgpu_gem_prime_mmap,
> diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
> b/drivers/gpu/drm/virtio/virtgpu_prime.c
> index 86ce0ae93f..c59ec34c80 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_prime.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> @@ -39,20 +39,6 @@ void virtgpu_gem_prime_unpin(struct drm_gem_object *obj)
> WARN_ONCE(1, "not implemented");
>  }
>
> -struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
> -{
> -   WARN_ONCE(1, "not implemented");
> -   return ERR_PTR(-ENODEV);
> -}
> -
> -struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
> -   struct drm_device *dev, struct dma_buf_attachment *attach,
> -   struct sg_table *table)
> -{
> -   WARN_ONCE(1, "not implemented");
> -   return ERR_PTR(-ENODEV);
> -}
> -
>  void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj)
>  {
> struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> --
> 2.9.3
>
> ___
> 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] drm/qxl: drop prime import/export callbacks

[Dave Airlie]

On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann  wrote:
>
> Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> userspace.
>
> Signed-off-by: Gerd Hoffmann 

Reviewed-by: Dave Airlie 
> ---
>  drivers/gpu/drm/qxl/qxl_drv.c   |  4 
>  drivers/gpu/drm/qxl/qxl_prime.c | 14 --
>  2 files changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 13c8a662f9..ccb090f3ab 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -250,14 +250,10 @@ static struct drm_driver qxl_driver = {
>  #if defined(CONFIG_DEBUG_FS)
> .debugfs_init = qxl_debugfs_init,
>  #endif
> -   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> -   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_export = drm_gem_prime_export,
> .gem_prime_import = drm_gem_prime_import,
> .gem_prime_pin = qxl_gem_prime_pin,
> .gem_prime_unpin = qxl_gem_prime_unpin,
> -   .gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
> -   .gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
> .gem_prime_vmap = qxl_gem_prime_vmap,
> .gem_prime_vunmap = qxl_gem_prime_vunmap,
> .gem_prime_mmap = qxl_gem_prime_mmap,
> diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/gpu/drm/qxl/qxl_prime.c
> index a55dece118..df65d3c1a7 100644
> --- a/drivers/gpu/drm/qxl/qxl_prime.c
> +++ b/drivers/gpu/drm/qxl/qxl_prime.c
> @@ -38,20 +38,6 @@ void qxl_gem_prime_unpin(struct drm_gem_object *obj)
> WARN_ONCE(1, "not implemented");
>  }
>
> -struct sg_table *qxl_gem_prime_get_sg_table(struct drm_gem_object *obj)
> -{
> -   WARN_ONCE(1, "not implemented");
> -   return ERR_PTR(-ENOSYS);
> -}
> -
> -struct drm_gem_object *qxl_gem_prime_import_sg_table(
> -   struct drm_device *dev, struct dma_buf_attachment *attach,
> -   struct sg_table *table)
> -{
> -   WARN_ONCE(1, "not implemented");
> -   return ERR_PTR(-ENOSYS);
> -}
> -
>  void *qxl_gem_prime_vmap(struct drm_gem_object *obj)
>  {
> WARN_ONCE(1, "not implemented");
> --
> 2.9.3
>
> ___
> 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: [Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[Alex Deucher]

On Fri, Jan 11, 2019 at 3:44 PM  wrote:
>
> Okay. I'm recompiling the first bisect now, there were no problems starting it
> this time after using "git stash." However I didn't issue "make clean" because
> it's unclear if it's necessary and I'm hoping I don't have to recompile
> everything for each iteration. Is it necessary or not? The instructions are
> vague and simple say you "might" have to. How would one know if they should?
> Does the compile fail if you need to, or can silent problems be introduced if
> you don't?
>
 Generally it's not required to make clean every time unless you run
into a build related problem.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

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

--- Comment #14 from Alex Deucher  ---
On Fri, Jan 11, 2019 at 3:44 PM  wrote:
>
> Okay. I'm recompiling the first bisect now, there were no problems starting it
> this time after using "git stash." However I didn't issue "make clean" because
> it's unclear if it's necessary and I'm hoping I don't have to recompile
> everything for each iteration. Is it necessary or not? The instructions are
> vague and simple say you "might" have to. How would one know if they should?
> Does the compile fail if you need to, or can silent problems be introduced if
> you don't?
>
 Generally it's not required to make clean every time unless you run
into a build related problem.

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

[Bug 109298] AMDGPU leaving DRI2 enabled causes white artifacting

[bugzilla-daemon]

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

--- Comment #6 from Alex Deucher  ---
(In reply to tkdestroyer2+bugs-freedesktop from comment #2)
> (In reply to Michel Dänzer from comment #1)
> > Does not specifying the dpm parameter at all on the kernel command line or
> > anywhere else make a difference?
> 
> I just tested. DPM is required to prevent crashing, but DC is not.

4.18 and older used the old dpm implementation by default and setting to 1
selected the new one.  The new on is default in 4.19, so you no longer need to
specify dpm=1 as of 4.19.

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

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

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

--- Comment #13 from rmuncr...@humanavance.com ---
(In reply to Alex Deucher from comment #12)
> (In reply to iive from comment #10)
> > (In reply to Alex Deucher from comment #9)
> > > (In reply to rmuncrief from comment #8)
> > > > (In reply to Alex Deucher from comment #7)
> > > > > Can you bisect to figure out what commit broke things for you?
> > > > 
> > > > Actually I remember doing that many years ago when I was a maintainer 
> > > > for
> > > > Steam under wine. I'll look and see if I can find a current bisect 
> > > > tutorial
> > > > and give it a try. Any links or tips you can give to help give me a 
> > > > quick
> > > > start would be appreciated. I do remember it can take many days, which 
> > > > I'm
> > > > willing to invest as I said. However the fewer days the better! :)
> > > 
> > > It's pretty straight forward.  Just google for "kernel git bisect howto".
> > 
> > Bisecting between two major stable kernel versions is a nightmare.(Aka
> > 4.18.0 - 4.19.0)
> > 
> > Most of the new changes are done before RC1 and it is quite common that
> > there are major breakages there, in systems we do not want to bother with.
> > These breakages are usually fixed (or reverted) in later Release Candidates.
> 
> This is not always the case; in most cases bisects are pretty smooth.  If
> you run into unrelated problems with a particular commit, you can always
> skip it during the bisect (git bisect skip).

Okay. I'm recompiling the first bisect now, there were no problems starting it
this time after using "git stash." However I didn't issue "make clean" because
it's unclear if it's necessary and I'm hoping I don't have to recompile
everything for each iteration. Is it necessary or not? The instructions are
vague and simple say you "might" have to. How would one know if they should?
Does the compile fail if you need to, or can silent problems be introduced if
you don't?

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

[Bug 202217] Integrated laptop display doesnt come back up after using PRIME on wayland

[bugzilla-daemon]

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

--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Don't worry about the xorg log.  Sorry, habit.

-- 
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

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

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

--- Comment #12 from Alex Deucher  ---
(In reply to iive from comment #10)
> (In reply to Alex Deucher from comment #9)
> > (In reply to rmuncrief from comment #8)
> > > (In reply to Alex Deucher from comment #7)
> > > > Can you bisect to figure out what commit broke things for you?
> > > 
> > > Actually I remember doing that many years ago when I was a maintainer for
> > > Steam under wine. I'll look and see if I can find a current bisect 
> > > tutorial
> > > and give it a try. Any links or tips you can give to help give me a quick
> > > start would be appreciated. I do remember it can take many days, which I'm
> > > willing to invest as I said. However the fewer days the better! :)
> > 
> > It's pretty straight forward.  Just google for "kernel git bisect howto".
> 
> Bisecting between two major stable kernel versions is a nightmare.(Aka
> 4.18.0 - 4.19.0)
> 
> Most of the new changes are done before RC1 and it is quite common that
> there are major breakages there, in systems we do not want to bother with.
> These breakages are usually fixed (or reverted) in later Release Candidates.

This is not always the case; in most cases bisects are pretty smooth.  If you
run into unrelated problems with a particular commit, you can always skip it
during the bisect (git bisect skip).

-- 
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

[PATCH v2 0/5] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

Changes:
- Improve drm_gem_fb_create_with_dirty() docs (Daniel)
- Remove unnecessary clearing of damage clips
- Rebase on Sam's drmP.h series
- Remove fb NULL check in mipi_dbi_enable_flush() (kbuild test robot)
- Update todo.rst (Sam)

Maxime has done a backmerge so the damage helper is now in
drm-misc-next.

Noralf.

Noralf Trønnes (5):
  drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()
  drm/damage-helper: Add drm_atomic_helper_damage_merged()
  drm/tinydrm: Use struct drm_rect
  drm/tinydrm: Use damage helper for dirtyfb
  drm/todo: Tick off some tinydrm entries

 Documentation/gpu/todo.rst|  35 -
 drivers/gpu/drm/drm_damage_helper.c   |  41 ++
 drivers/gpu/drm/drm_gem_framebuffer_helper.c  |  50 ++-
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c   |  21 +--
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 100 +
 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c   |  30 
 drivers/gpu/drm/tinydrm/hx8357d.c |   2 +-
 drivers/gpu/drm/tinydrm/ili9225.c | 138 +++---
 drivers/gpu/drm/tinydrm/ili9341.c |   2 +-
 drivers/gpu/drm/tinydrm/mi0283qt.c|   2 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c|  89 ++-
 drivers/gpu/drm/tinydrm/repaper.c |  42 +++---
 drivers/gpu/drm/tinydrm/st7586.c  |  73 -
 drivers/gpu/drm/tinydrm/st7735r.c |   2 +-
 include/drm/drm_damage_helper.h   |   3 +
 include/drm/drm_gem_framebuffer_helper.h  |   3 +
 include/drm/tinydrm/mipi-dbi.h|   5 +-
 include/drm/tinydrm/tinydrm-helpers.h |  20 +--
 include/drm/tinydrm/tinydrm.h |  26 
 19 files changed, 282 insertions(+), 402 deletions(-)

-- 
2.20.1

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

[PATCH v2 2/5] drm/damage-helper: Add drm_atomic_helper_damage_merged()

[Noralf Trønnes]

Useful for drivers that only care about the combined damage.

v2: Remove unnecessary clearing of damage clips

Cc: Deepak Rawat 
Signed-off-by: Noralf Trønnes 
Acked-by: Sam Ravnborg 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_damage_helper.c | 41 +
 include/drm/drm_damage_helper.h |  3 +++
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_damage_helper.c 
b/drivers/gpu/drm/drm_damage_helper.c
index 31032407254d..e16aa5ae00b4 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -333,3 +333,44 @@ drm_atomic_helper_damage_iter_next(struct 
drm_atomic_helper_damage_iter *iter,
return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_damage_iter_next);
+
+/**
+ * drm_atomic_helper_damage_merged - Merged plane damage
+ * @old_state: Old plane state for validation.
+ * @state: Plane state from which to iterate the damage clips.
+ * @rect: Returns the merged damage rectangle
+ *
+ * This function merges any valid plane damage clips into one rectangle and
+ * returns it in @rect.
+ *
+ * For details see: drm_atomic_helper_damage_iter_init() and
+ * drm_atomic_helper_damage_iter_next().
+ *
+ * Returns:
+ * True if there is valid plane damage otherwise false.
+ */
+bool drm_atomic_helper_damage_merged(const struct drm_plane_state *old_state,
+struct drm_plane_state *state,
+struct drm_rect *rect)
+{
+   struct drm_atomic_helper_damage_iter iter;
+   struct drm_rect clip;
+   bool valid = false;
+
+   rect->x1 = INT_MAX;
+   rect->y1 = INT_MAX;
+   rect->x2 = 0;
+   rect->y2 = 0;
+
+   drm_atomic_helper_damage_iter_init(, old_state, state);
+   drm_atomic_for_each_plane_damage(, ) {
+   rect->x1 = min(rect->x1, clip.x1);
+   rect->y1 = min(rect->y1, clip.y1);
+   rect->x2 = max(rect->x2, clip.x2);
+   rect->y2 = max(rect->y2, clip.y2);
+   valid = true;
+   }
+
+   return valid;
+}
+EXPORT_SYMBOL(drm_atomic_helper_damage_merged);
diff --git a/include/drm/drm_damage_helper.h b/include/drm/drm_damage_helper.h
index 4487660b26b8..40c34a5bf149 100644
--- a/include/drm/drm_damage_helper.h
+++ b/include/drm/drm_damage_helper.h
@@ -78,6 +78,9 @@ drm_atomic_helper_damage_iter_init(struct 
drm_atomic_helper_damage_iter *iter,
 bool
 drm_atomic_helper_damage_iter_next(struct drm_atomic_helper_damage_iter *iter,
   struct drm_rect *rect);
+bool drm_atomic_helper_damage_merged(const struct drm_plane_state *old_state,
+struct drm_plane_state *state,
+struct drm_rect *rect);
 
 /**
  * drm_helper_get_plane_damage_clips - Returns damage clips in _rect.
-- 
2.20.1

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

[PATCH v2 3/5] drm/tinydrm: Use struct drm_rect

[Noralf Trønnes]

This prepares for the switch to drm_atomic_helper_dirtyfb() in the next
patch. The damage helper returns a drm_rect so switch to that everywhere
including using a pointer in the dirty functions.

This is a non-functional change except for the debug print which looks a
bit different.

Signed-off-by: Noralf Trønnes 
Acked-by: Sam Ravnborg 
Acked-by: Daniel Vetter 
---
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 19 
 drivers/gpu/drm/tinydrm/ili9225.c | 43 ++-
 drivers/gpu/drm/tinydrm/mipi-dbi.c| 21 -
 drivers/gpu/drm/tinydrm/repaper.c |  3 +-
 drivers/gpu/drm/tinydrm/st7586.c  | 27 ++--
 include/drm/tinydrm/mipi-dbi.h|  3 +-
 include/drm/tinydrm/tinydrm-helpers.h | 11 ++---
 7 files changed, 67 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bf6bfbc5d412..d0ece6ad4a1c 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,7 +42,7 @@ MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer 
size");
  * Returns:
  * true if it's a full clip, false otherwise
  */
-bool tinydrm_merge_clips(struct drm_clip_rect *dst,
+bool tinydrm_merge_clips(struct drm_rect *dst,
 struct drm_clip_rect *src, unsigned int num_clips,
 unsigned int flags, u32 max_width, u32 max_height)
 {
@@ -63,10 +64,10 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
for (i = 0; i < num_clips; i++) {
if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
i++;
-   dst->x1 = min(dst->x1, src[i].x1);
-   dst->x2 = max(dst->x2, src[i].x2);
-   dst->y1 = min(dst->y1, src[i].y1);
-   dst->y2 = max(dst->y2, src[i].y2);
+   dst->x1 = min_t(int, dst->x1, src[i].x1);
+   dst->x2 = max_t(int, dst->x2, src[i].x2);
+   dst->y1 = min_t(int, dst->y1, src[i].y1);
+   dst->y2 = max_t(int, dst->y2, src[i].y2);
}
 
if (dst->x2 > max_width || dst->y2 > max_height ||
@@ -122,7 +123,7 @@ EXPORT_SYMBOL(tinydrm_fb_dirty);
  * @clip: Clip rectangle area to copy
  */
 void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip)
+   struct drm_rect *clip)
 {
unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
unsigned int pitch = fb->pitches[0];
@@ -146,7 +147,7 @@ EXPORT_SYMBOL(tinydrm_memcpy);
  * @clip: Clip rectangle area to copy
  */
 void tinydrm_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip)
+   struct drm_rect *clip)
 {
size_t len = (clip->x2 - clip->x1) * sizeof(u16);
unsigned int x, y;
@@ -186,7 +187,7 @@ EXPORT_SYMBOL(tinydrm_swab16);
  */
 void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip, bool swap)
+   struct drm_rect *clip, bool swap)
 {
size_t len = (clip->x2 - clip->x1) * sizeof(u32);
unsigned int x, y;
@@ -235,7 +236,7 @@ EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
  * ITU BT.601 is used for the RGB -> luma (brightness) conversion.
  */
 void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer 
*fb,
-  struct drm_clip_rect *clip)
+  struct drm_rect *clip)
 {
unsigned int len = (clip->x2 - clip->x1) * sizeof(u32);
unsigned int x, y;
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index b0ad58b97227..ad644069089f 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -84,7 +85,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
struct tinydrm_device *tdev = fb->dev->dev_private;
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
bool swap = mipi->swap_bytes;
-   struct drm_clip_rect clip;
+   struct drm_rect clip;
+   struct drm_rect *rect = 
u16 x_start, y_start;
u16 x1, x2, y1, y2;
int ret = 0;
@@ -97,13 +99,12 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
full = tinydrm_merge_clips(, clips, num_clips, flags,
   fb->width, fb->height);
 
-   DRM_DEBUG("Flushing [FB:%d] x1=%u, x2=%u, y1=%u, y2=%u\n", fb->base.id,
- clip.x1, clip.x2, clip.y1, clip.y2);
+   DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id, 
DRM_RECT_ARG(rect));
 
  

[PATCH v2 1/5] drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()

[Noralf Trønnes]

This adds a .fb_create helper that sets the .dirty callback to
drm_atomic_helper_dirtyfb().

v2: Improve docs (Daniel)

Signed-off-by: Noralf Trønnes 
Acked-by: Sam Ravnborg 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem_framebuffer_helper.c | 50 +---
 include/drm/drm_gem_framebuffer_helper.h |  3 ++
 2 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index acb466d25afc..65edb1ccb185 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -136,10 +137,9 @@ EXPORT_SYMBOL(drm_gem_fb_create_handle);
  * @mode_cmd: Metadata from the userspace framebuffer creation request
  * @funcs: vtable to be used for the new framebuffer object
  *
- * This can be used to set _framebuffer_funcs for drivers that need the
- * _framebuffer_funcs.dirty callback. Use drm_gem_fb_create() if you don't
- * need to change _framebuffer_funcs.
- * The function does buffer size validation.
+ * This function can be used to set _framebuffer_funcs for drivers that 
need
+ * custom framebuffer callbacks. Use drm_gem_fb_create() if you don't need to
+ * change _framebuffer_funcs. The function does buffer size validation.
  *
  * Returns:
  * Pointer to a _framebuffer on success or an error pointer on failure.
@@ -215,8 +215,8 @@ static const struct drm_framebuffer_funcs drm_gem_fb_funcs 
= {
  *
  * If your hardware has special alignment or pitch requirements these should be
  * checked before calling this function. The function does buffer size
- * validation. Use drm_gem_fb_create_with_funcs() if you need to set
- * _framebuffer_funcs.dirty.
+ * validation. Use drm_gem_fb_create_with_dirty() if you need framebuffer
+ * flushing.
  *
  * Drivers can use this as their _mode_config_funcs.fb_create callback.
  * The ADDFB2 IOCTL calls into this callback.
@@ -233,6 +233,44 @@ drm_gem_fb_create(struct drm_device *dev, struct drm_file 
*file,
 }
 EXPORT_SYMBOL_GPL(drm_gem_fb_create);
 
+static const struct drm_framebuffer_funcs drm_gem_fb_funcs_dirtyfb = {
+   .destroy= drm_gem_fb_destroy,
+   .create_handle  = drm_gem_fb_create_handle,
+   .dirty  = drm_atomic_helper_dirtyfb,
+};
+
+/**
+ * drm_gem_fb_create_with_dirty() - Helper function for the
+ *   _mode_config_funcs.fb_create callback
+ * @dev: DRM device
+ * @file: DRM file that holds the GEM handle(s) backing the framebuffer
+ * @mode_cmd: Metadata from the userspace framebuffer creation request
+ *
+ * This function creates a new framebuffer object described by
+ * _mode_fb_cmd2. This description includes handles for the buffer(s)
+ * backing the framebuffer. drm_atomic_helper_dirtyfb() is used for the dirty
+ * callback giving framebuffer flushing through the atomic machinery. Use
+ * drm_gem_fb_create() if you don't need the dirty callback.
+ * The function does buffer size validation.
+ *
+ * Drivers should also call drm_plane_enable_fb_damage_clips() on all planes
+ * to enable userspace to use damage clips also with the ATOMIC IOCTL.
+ *
+ * Drivers can use this as their _mode_config_funcs.fb_create callback.
+ * The ADDFB2 IOCTL calls into this callback.
+ *
+ * Returns:
+ * Pointer to a _framebuffer on success or an error pointer on failure.
+ */
+struct drm_framebuffer *
+drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
+   _gem_fb_funcs_dirtyfb);
+}
+EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
+
 /**
  * drm_gem_fb_prepare_fb() - Prepare a GEM backed framebuffer
  * @plane: Plane
diff --git a/include/drm/drm_gem_framebuffer_helper.h 
b/include/drm/drm_gem_framebuffer_helper.h
index a38de7eb55b4..7f307e834eef 100644
--- a/include/drm/drm_gem_framebuffer_helper.h
+++ b/include/drm/drm_gem_framebuffer_helper.h
@@ -25,6 +25,9 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev, struct 
drm_file *file,
 struct drm_framebuffer *
 drm_gem_fb_create(struct drm_device *dev, struct drm_file *file,
  const struct drm_mode_fb_cmd2 *mode_cmd);
+struct drm_framebuffer *
+drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd);
 
 int drm_gem_fb_prepare_fb(struct drm_plane *plane,
  struct drm_plane_state *state);
-- 
2.20.1

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

[PATCH v2 5/5] drm/todo: Tick off some tinydrm entries

[Noralf Trønnes]

- Better manual-upload support for atomic
  The new damage helper has the necessary pieces to make this work.

- tinydrm_gem_cma_prime_import_sg_table
  This is now moved to the CMA helper and can be set using the
  DRM_GEM_CMA_VMAP_DRIVER_OPS macro.

- tinydrm_fb_create
  This is now covered by drm_gem_fb_create_with_dirty()

Cc: Sam Ravnborg 
Signed-off-by: Noralf Trønnes 
---
 Documentation/gpu/todo.rst | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 0a85dad876ae..38360ede1221 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -82,30 +82,6 @@ events for atomic commits correctly. But fixing these bugs 
is good anyway.
 
 Contact: Daniel Vetter, respective driver maintainers
 
-Better manual-upload support for atomic

-
-This would be especially useful for tinydrm:
-
-- Add a struct drm_rect dirty_clip to drm_crtc_state. When duplicating the
-  crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in
-  __drm_atomic_helper_crtc_duplicate_state().
-
-- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_
-  prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this
-  is a function useful to implement the fb->dirty function.
-
-- Create a new drm_fb_dirty function which does essentially what e.g.
-  mipi_dbi_fb_dirty does. You can use e.g. drm_atomic_helper_update_plane as 
the
-  template. But instead of doing a simple full-screen plane update, this new
-  helper also sets crtc_state->dirty_clip to the right coordinates. And of
-  course it needs to check whether the fb is actually active (and maybe where),
-  so there's some book-keeping involved. There's also some good fun involved in
-  scaling things appropriately. For that case we might simply give up and
-  declare the entire area covered by the plane as dirty.
-
-Contact: Noralf Trønnes, Daniel Vetter
-
 Fallout from atomic KMS
 ---
 
@@ -459,21 +435,10 @@ those drivers as simple as possible, so lots of room for 
refactoring:
   one of the ideas for having a shared dsi/dbi helper, abstracting away the
   transport details more.
 
-- tinydrm_gem_cma_prime_import_sg_table should probably go into the cma
-  helpers, as a _vmapped variant (since not every driver needs the vmap).
-  And tinydrm_gem_cma_free_object could the be merged into
-  drm_gem_cma_free_object().
-
-- tinydrm_fb_create we could move into drm_simple_pipe, only need to add
-  the fb_create hook to drm_simple_pipe_funcs, which would again simplify a
-  bunch of things (since it gives you a one-stop vfunc for simple drivers).
-
 - Quick aside: The unregister devm stuff is kinda getting the lifetimes of
   a drm_device wrong. Doesn't matter, since everyone else gets it wrong
   too :-)
 
-- also rework the drm_framebuffer_funcs->dirty hook wire-up, see above.
-
 Contact: Noralf Trønnes, Daniel Vetter
 
 AMD DC Display Driver
-- 
2.20.1

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

[PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
handler. All flushing will now happen in the pipe functions.

Also enable the damage plane property for all except repaper which can
only do full updates.

ili9225:
This change made ili9225_init() equal to mipi_dbi_init() so use it.

v2: Remove fb check in mipi_dbi_enable_flush() it can't be NULL
(kbuild test robot)

Cc: David Lechner 
Cc: Eric Anholt 
Signed-off-by: Noralf Trønnes 
Acked-by: Sam Ravnborg 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c   |  21 +---
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c|  91 +---
 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c   |  30 --
 drivers/gpu/drm/tinydrm/hx8357d.c |   2 +-
 drivers/gpu/drm/tinydrm/ili9225.c | 101 ++
 drivers/gpu/drm/tinydrm/ili9341.c |   2 +-
 drivers/gpu/drm/tinydrm/mi0283qt.c|   2 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c|  74 -
 drivers/gpu/drm/tinydrm/repaper.c |  39 ---
 drivers/gpu/drm/tinydrm/st7586.c  |  50 +
 drivers/gpu/drm/tinydrm/st7735r.c |   2 +-
 include/drm/tinydrm/mipi-dbi.h|   2 +
 include/drm/tinydrm/tinydrm-helpers.h |  11 +-
 include/drm/tinydrm/tinydrm.h |  26 -
 14 files changed, 138 insertions(+), 315 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index aeb93eadb047..614f532ea89f 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -39,31 +39,17 @@
  * and registers the DRM device using devm_tinydrm_register().
  */
 
-static struct drm_framebuffer *
-tinydrm_fb_create(struct drm_device *drm, struct drm_file *file_priv,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
-   struct tinydrm_device *tdev = drm->dev_private;
-
-   return drm_gem_fb_create_with_funcs(drm, file_priv, mode_cmd,
-   tdev->fb_funcs);
-}
-
 static const struct drm_mode_config_funcs tinydrm_mode_config_funcs = {
-   .fb_create = tinydrm_fb_create,
+   .fb_create = drm_gem_fb_create_with_dirty,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
 
 static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
-   const struct drm_framebuffer_funcs *fb_funcs,
struct drm_driver *driver)
 {
struct drm_device *drm;
 
-   mutex_init(>dirty_lock);
-   tdev->fb_funcs = fb_funcs;
-
/*
 * We don't embed drm_device, because that prevent us from using
 * devm_kzalloc() to allocate tinydrm_device in the driver since
@@ -86,7 +72,6 @@ static int tinydrm_init(struct device *parent, struct 
tinydrm_device *tdev,
 static void tinydrm_fini(struct tinydrm_device *tdev)
 {
drm_mode_config_cleanup(tdev->drm);
-   mutex_destroy(>dirty_lock);
tdev->drm->dev_private = NULL;
drm_dev_put(tdev->drm);
 }
@@ -100,7 +85,6 @@ static void devm_tinydrm_release(void *data)
  * devm_tinydrm_init - Initialize tinydrm device
  * @parent: Parent device object
  * @tdev: tinydrm device
- * @fb_funcs: Framebuffer functions
  * @driver: DRM driver
  *
  * This function initializes @tdev, the underlying DRM device and it's
@@ -111,12 +95,11 @@ static void devm_tinydrm_release(void *data)
  * Zero on success, negative error code on failure.
  */
 int devm_tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
- const struct drm_framebuffer_funcs *fb_funcs,
  struct drm_driver *driver)
 {
int ret;
 
-   ret = tinydrm_init(parent, tdev, fb_funcs, driver);
+   ret = tinydrm_init(parent, tdev, driver);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d0ece6ad4a1c..2737b6fdadc8 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -17,104 +17,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
-#include 
 
 static unsigned int spi_max;
 module_param(spi_max, uint, 0400);
 MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
 
-/**
- * tinydrm_merge_clips - Merge clip rectangles
- * @dst: Destination clip rectangle
- * @src: Source clip rectangle(s)
- * @num_clips: Number of @src clip rectangles
- * @flags: Dirty fb ioctl flags
- * @max_width: Maximum width of @dst
- * @max_height: Maximum height of @dst
- *
- * This function merges @src clip rectangle(s) into @dst. If @src is NULL,
- * @max_width and @min_width is used to set a full @dst clip rectangle.
- *
- * Returns:
- * true if it's a full clip, false otherwise
- */
-bool 

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

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

--- Comment #11 from rmuncr...@humanavance.com ---
(In reply to iive from comment #10)
> (In reply to Alex Deucher from comment #9)
> > (In reply to rmuncrief from comment #8)
> > > (In reply to Alex Deucher from comment #7)
> > > > Can you bisect to figure out what commit broke things for you?
> > > 
> > > Actually I remember doing that many years ago when I was a maintainer for
> > > Steam under wine. I'll look and see if I can find a current bisect 
> > > tutorial
> > > and give it a try. Any links or tips you can give to help give me a quick
> > > start would be appreciated. I do remember it can take many days, which I'm
> > > willing to invest as I said. However the fewer days the better! :)
> > 
> > It's pretty straight forward.  Just google for "kernel git bisect howto".
> 
> Bisecting between two major stable kernel versions is a nightmare.(Aka
> 4.18.0 - 4.19.0)
> 
> Most of the new changes are done before RC1 and it is quite common that
> there are major breakages there, in systems we do not want to bother with.
> These breakages are usually fixed (or reverted) in later Release Candidates.
> 
> It may be better to use some of the drm-next repositories, assuming that
> they hold all graphic changes that are going upstream, but are not rebased
> until the final release is done.

Yes, that's the kind of stuff I was worried about. I understand bisect is
simple in theory, but in practice there are usually a lot of problems.

And I already ran into my first and am redoing everything from scratch again. I
was able to cobble together a working PKGBUILD and tested it by compiling
4.18.20 from stable-branch git without any of the ARCH or Manjaro patches. I
did some quick tests with my compiled 4.18.20 to make sure it was working, and
then built 4.19.14 and made sure that one didn't work.

But when I went to do the first bisect it complained about uncommitted files
and aborted. I tried various things and eventually discovered that I probably
should have just executed "git stash", but by that time I couldn't be sure of
the integrity of the build so I just started all over again this morning.

However now I'm more confused because it seems you might be saying I should be
using a 4.19 release candidate instead of a stable build? Like I said, I'm
willing to put in substantial effort to help fix this problem, but I'd like to
waste the least amount of time possible. I also understand there are various
ways to speed things up by disabling unused kernel features, caching, etc. but
I'm from the old school of engineering and am hesitant to modify anything I'm
testing unless absolutely necessary. After all, since it's a completely unknown
problem there's no way to know what's causing it. It could very well be
something completely unexpected that has to do with components one wouldn't
normally consider.

And by the way, by "old school" I mean I started out as a hardware/firmware
designer when the most advanced processors were 8 bits running at 2Mhz! Yes,
that's right, I'm freakin' old! :)

In any case at this point if someone could tell me whether I should be
targeting a stable release or release candidate it would be helpful.

-- 
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 v6] drm/panel: Add a driver for the TPO TPG110

[Linus Walleij]

On Thu, Jan 10, 2019 at 9:01 PM Jagan Teki  wrote:

> Just for my information, for each new panel addition, is MAINTAINERS
> file will update only by drm-misc members or anyone who submitted the
> patch? The last communication with seanpaul mentioned this context[1]
> just want to understand how this panels were maintained.
>
>  [1] https://lkml.org/lkml/2018/12/14/1275

Aha I see. Well this per-panel entry is good because then
get_maintainer.pl will also get me specifically and not just
the people listed for panel/drm-misc (whether I am, was
or will be a member of that group or not).

get_maintainer.pl will present all of them with me on
top:

$ scripts/get_maintainer.pl -f drivers/gpu/drm/panel/panel-tpo-tpg110.c
Linus Walleij  (maintainer:DRM DRIVER FOR
TPO TPG110 PANELS)
Thierry Reding  (maintainer:DRM PANEL DRIVERS)
David Airlie  (maintainer:DRM DRIVERS)
Daniel Vetter  (maintainer:DRM DRIVERS)
dri-devel@lists.freedesktop.org (open list:DRM PANEL DRIVERS)
linux-ker...@vger.kernel.org (open list)

So I would advice against the above practice: one does not
exclude the other.

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

[Bug 109319] [radeonsi] Two Point Hospital: rendered in mostly black on an Oland XT GPU

[bugzilla-daemon]

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

--- Comment #2 from Kai  ---
Created attachment 143076
  --> https://bugs.freedesktop.org/attachment.cgi?id=143076=edit
TPH graphics settings (pt. 2)

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

[Bug 109319] [radeonsi] Two Point Hospital: rendered in mostly black on an Oland XT GPU

[bugzilla-daemon]

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

--- Comment #1 from Kai  ---
Created attachment 143075
  --> https://bugs.freedesktop.org/attachment.cgi?id=143075=edit
TPH graphics settings (pt. 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

[Bug 109319] [radeonsi] Two Point Hospital: rendered in mostly black on an Oland XT GPU

[bugzilla-daemon]

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

Bug ID: 109319
   Summary: [radeonsi] Two Point Hospital: rendered in mostly
black on an Oland XT GPU
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: have-backtrace
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: k...@dev.carbon-project.org
QA Contact: dri-devel@lists.freedesktop.org
Blocks: 77449

Created attachment 143074
  --> https://bugs.freedesktop.org/attachment.cgi?id=143074=edit
Image showing the rendering issues of TPH with radeonsi on OLAND

A friend of mine for whom I'm doing the Linux tech support has trouble playing
Two Point Hospital (TPH) on his Oland XT GPU with radeonsi. With older versions
of Mesa the game locked up the GPU after a while, therefore I built him a Mesa
from Git, linked against LLVM 8 (see below for details on the complete stack).
But with the Git version the game becomes completely unplayable, because most
of the screen is rendered in black. Menus and some outlines are shown. See the
attached picture my friend sent me for details on how this looks. [NB: I've
been able to play TPH on my HAWAII PRO based system without any issues so far.]
He uses the radeon stack, due to the limitations of amdgpu with this GPU
generation.

At  you'll find
an apitrace my friend recorded, which reproduces the issue on his system when
played back.

The stack my friend uses is (Debian Stretch with backports as a base):
GPU: Oland XT [R7 250] (ChipID = 0x6610)
Mesa: Git:master/8847370424
libdrm: 2.4.95-1~bpo9+1
LLVM: SVN:trunk/r350064 (8.0 devel)
X.Org: 2:1.19.2-1+deb9u5
Linux: 4.20-1~exp1
Firmware: 20180825+dfsg-1~bpo9+1
DDX: 1:7.8.0-1+b1

Let me know, if you need anything else.


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=77449
[Bug 77449] Tracker bug for all bugs related to Steam titles
-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

[bugzilla-daemon]

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

--- Comment #85 from Nicholas Kazlauskas  ---
(In reply to tempel.julian from comment #82)
> Could you please try the following?
> 
> -disable Plasma compositing with Ctr + Alt + F12 (or in the compositor
> settings and log out and in again)
> -get the latest Compton release by yshui: https://github.com/yshui/compton
> -start Compton (Mesa still enables vsync automatically in the latest
> release, this has changed with compton-git)
> -open a Dolphin window and www.vsynctester.com in webbrowser
> -now click Dolphin's title bar, move it a bit, release it and repeat the
> procedure several times in a row
> -there should be stutter happening in the vsynctester.com browser window
> 
> -now quit Compton and start it with "vblank_mode=0 compton" to enable GLX
> compositing without vsync
> -now the repeatedly moving Dolphin's window procedure described above
> shouldn't lead to any stutter
> -when booting with amdgpu.dc=0, there also shouldn't be any stutter when
> vsync is kept enabled
> 
> My layman impression is that this indicates the problem originating
> somewhere in the xorg/driver space, and not in Plasma or the compositor.

I've tried the setup you've described but I see no stuttering in vsynctester
and no difference with vblank_mode=0. The perf overlay on compton itself looks
stutter free as well. I only see the stuttering doing what you first described
with the dock widgets/tray widgets.

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

[Bug 109298] AMDGPU leaving DRI2 enabled causes white artifacting

[bugzilla-daemon]

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

--- Comment #5 from tkdestroyer2+bugs-freedesk...@gmail.com ---
Created attachment 143073
  --> https://bugs.freedesktop.org/attachment.cgi?id=143073=edit
xorg log

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

[Bug 109298] AMDGPU leaving DRI2 enabled causes white artifacting

[bugzilla-daemon]

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

--- Comment #4 from tkdestroyer2+bugs-freedesk...@gmail.com ---
Created attachment 143072
  --> https://bugs.freedesktop.org/attachment.cgi?id=143072=edit
dmesg log

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

[Bug 109298] AMDGPU leaving DRI2 enabled causes white artifacting

[bugzilla-daemon]

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

--- Comment #3 from tkdestroyer2+bugs-freedesk...@gmail.com ---
Created attachment 143071
  --> https://bugs.freedesktop.org/attachment.cgi?id=143071=edit
Screenshot

> Please attach a screenshot, the Xorg log file and the output of dmesg
> corresponding to the problem.

The screenshot was not able to capture a majority of the screen (shown in
black) for some reason. The point can still be seen in the bottom, in a
screenshot of the freedesktop bug list.

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

[Bug 109298] AMDGPU leaving DRI2 enabled causes white artifacting

[bugzilla-daemon]

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

--- Comment #2 from tkdestroyer2+bugs-freedesk...@gmail.com ---
(In reply to Michel Dänzer from comment #1)
> Does not specifying the dpm parameter at all on the kernel command line or
> anywhere else make a difference?

I just tested. DPM is required to prevent crashing, but DC is not.

-- 
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 4/4] drm/tinydrm: Use damage helper for dirtyfb

[kbuild test robot]

Hi Noralf,

url:
https://github.com/0day-ci/linux/commits/Noralf-Tr-nnes/drm-tinydrm-Use-damage-helper-for-dirtyfb/20190110-194410

New smatch warnings:
drivers/gpu/drm/tinydrm/mipi-dbi.c:305 mipi_dbi_enable_flush() warn: variable 
dereferenced before check 'fb' (see line 299)

Old smatch warnings:
drivers/gpu/drm/tinydrm/mipi-dbi.c:108 mipi_dbi_command_is_read() error: buffer 
overflow 'mipi->read_commands' 21 <= 254
drivers/gpu/drm/tinydrm/mipi-dbi.c:110 mipi_dbi_command_is_read() error: buffer 
overflow 'mipi->read_commands' 21 <= 254

# 
https://github.com/0day-ci/linux/commit/50dd14907581e982f534b7718bc3f8c903f46c88
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 50dd14907581e982f534b7718bc3f8c903f46c88
vim +/fb +305 drivers/gpu/drm/tinydrm/mipi-dbi.c

02dd95fe Noralf Trønnes 2017-01-22  281  
02dd95fe Noralf Trønnes 2017-01-22  282  /**
22edc8d3 Noralf Trønnes 2018-01-10  283   * mipi_dbi_enable_flush - MIPI 
DBI enable helper
22edc8d3 Noralf Trønnes 2018-01-10  284   * @mipi: MIPI DBI structure
5685ca0c Noralf Trønnes 2018-07-10  285   * @crtc_state: CRTC state
5685ca0c Noralf Trønnes 2018-07-10  286   * @plane_state: Plane state
22edc8d3 Noralf Trønnes 2018-01-10  287   *
22edc8d3 Noralf Trønnes 2018-01-10  288   * This function sets 
_dbi->enabled, flushes the whole framebuffer and
22edc8d3 Noralf Trønnes 2018-01-10  289   * enables the backlight. Drivers 
can use this in their
22edc8d3 Noralf Trønnes 2018-01-10  290   * 
_simple_display_pipe_funcs->enable callback.
22edc8d3 Noralf Trønnes 2018-01-10  291   */
e85d3006 Ville Syrjälä  2018-03-23  292  void mipi_dbi_enable_flush(struct 
mipi_dbi *mipi,
e85d3006 Ville Syrjälä  2018-03-23  293struct 
drm_crtc_state *crtc_state,
e85d3006 Ville Syrjälä  2018-03-23  294struct 
drm_plane_state *plane_state)
22edc8d3 Noralf Trønnes 2018-01-10  295  {
e85d3006 Ville Syrjälä  2018-03-23  296 struct drm_framebuffer *fb = 
plane_state->fb;
50dd1490 Noralf Trønnes 2019-01-09  297 struct drm_rect rect = {
50dd1490 Noralf Trønnes 2019-01-09  298 .x1 = 0,
50dd1490 Noralf Trønnes 2019-01-09 @299 .x2 = fb->width,
50dd1490 Noralf Trønnes 2019-01-09  300 .y1 = 0,
50dd1490 Noralf Trønnes 2019-01-09  301 .y2 = fb->height,
50dd1490 Noralf Trønnes 2019-01-09  302 };
22edc8d3 Noralf Trønnes 2018-01-10  303  
22edc8d3 Noralf Trønnes 2018-01-10  304 mipi->enabled = true;
22edc8d3 Noralf Trønnes 2018-01-10 @305 if (fb)
50dd1490 Noralf Trønnes 2019-01-09  306 mipi_dbi_fb_dirty(fb, 
);
22edc8d3 Noralf Trønnes 2018-01-10  307  
414147e8 Meghana Madhyastha 2018-01-24  308 
backlight_enable(mipi->backlight);
22edc8d3 Noralf Trønnes 2018-01-10  309  }
22edc8d3 Noralf Trønnes 2018-01-10  310  
EXPORT_SYMBOL(mipi_dbi_enable_flush);
22edc8d3 Noralf Trønnes 2018-01-10  311  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: stop always moving BOs on the LRU on page fault

[Christian König]

Am 11.01.19 um 15:17 schrieb Michel Dänzer:

On 2019-01-11 2:15 p.m., Christian König wrote:

Move the BO on the LRU only when it is actually moved by a DMA
operation.

[...]

@@ -177,6 +175,13 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
ret = VM_FAULT_SIGBUS;
goto out_unlock;
}
+
+   if (bo->moving != moving) {

Hmm, could a driver just update the existing fence instead of attaching
a new one?


Mhm, not as far as I know. That would violate similar checks elsewhere.

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

Re: [PATCH v5 1/2] drm/sched: Refactor ring mirror list handling.

[Koenig, Christian]

Am 11.01.19 um 16:37 schrieb Grodzovsky, Andrey:
>
> On 01/11/2019 04:42 AM, Koenig, Christian wrote:
>> Am 10.01.19 um 16:56 schrieb Grodzovsky, Andrey:
>>> [SNIP]
>> But we will not be adding the cb back in drm_sched_stop anymore, now we
>> are only going to add back the cb in drm_sched_startr after rerunning
>> those jobs in drm_sched_resubmit_jobs and assign them a new parent
>> there
>> anyway.
> Yeah, but when we find that we don't need to reset anything anymore
> then adding the callbacks again won't be possible any more.
>
> Christian.
 I am not sure I understand it, can u point me to example of how this
 will happen ? I am attaching my latest patches with waiting only for
 the last job's fence here just so we are on same page regarding the code.
>> Well the whole idea is to prepare all schedulers, then check once more
>> if the offending job hasn't completed in the meantime.
>>
>> If the job completed we need to be able to rollback everything and
>> continue as if nothing had happened.
>>
>> Christian.
> Oh, but this piece of functionality - skipping HW ASIC reset in case the
> guilty job done is totally missing form this patch series and so needs
> to be added. So what you say actually is that for the case were we skip
> HW asic reset because the guilty job did complete we also need to skip
> resubmitting the jobs in drm_sched_resubmit_jobs and hence preserve the
> old parent fence pointer for reuse ? If so I would like to add all this
> functionality as a third patch since the first 2 patches are more about
> resolving race condition with jobs in flight while doing reset - what do
> you think ?

Yeah, sounds perfectly fine to me.

Christian.

>
> Andrey
 Andrey

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

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

[Bug 109303] [CI][SHARDS] igt@i915_query@query-topology-known-pci-ids - skip - Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(de

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |NOTABUG

--- Comment #3 from Chris Wilson  ---
(In reply to Lionel Landwerlin from comment #2)
> (In reply to Martin Peres from comment #0)
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5388/shard-iclb2/
> > igt@i915_qu...@query-topology-known-pci-ids.html
> > 
> > Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) ||
> > IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(devid)
> > Subtest query-topology-known-pci-ids: SKIP (0.000s)
> > 
> > I doubt that this would only be supported on these platforms and not on CNL
> > and ICL.
> 
> It does only support haswell/gen8/gen9 because that's the only place where
> based off the GT we can deduct the number of slices/subslices and do some
> actual checks on the values returned by i915.
> On gen10+ fusing is a lot more fuzzy.
> 
> One way to extend coverage would be to beef up lib/intel_device_info.c to
> contain information about the topology of the device.

Not really, I think. The purpose of the topology i915_query is precisely to
retrieve the more flexible configurations that are not simply defined in static
pci-id tables.

So long as we have sanity checks on the ioctl to catch garbage returns; along
with the static checks to make sure known configs are reported, that seems like
we have our boundary conditions covered.

If were possible to use the topology and verify that matches hw, that would be
a useful test (I presume that would also closely match use).

-- 
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 v8] drm/panel: Add a driver for the TPO TPG110

[Jagan Teki]

On Fri, Jan 11, 2019 at 11:24 PM Linus Walleij  wrote:
>
> The TPO (Toppoly) TPG110 is a pretty generic display driver
> similar in vein to the Ilitek 93xx devices. It is not a panel
> per se but a driver used with several low-cost noname panels.
>
> This is used on the Nomadik NHK15 combined with a OSD
> OSD057VA01CT display for WVGA 800x480.
>
> The driver is pretty minimalistic right now but can be
> extended to handle non-default polarities, gamma correction
> etc.
>
> The driver is based on the baked-in code in
> drivers/video/fbdev/amba-clcd-nomadik.c which will be
> decomissioned once this us upstream.
>
> Cc: Noralf Trønnes 
> Acked-by: Sam Ravnborg 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v7->v8:
> - Lifecycle the backlight properly with devm_of_find_backlight()
> - Drop if (backlight) clauses since helper are NULL-tolerant
> ChangeLog v6->v7:
> - Drop the video mode helpers.
> - Do not include  but instead the granular APIs.
> - Switch dev_info() and dev_err() for DRM_DEV_INFO()
>   and DRM_DEV_ERROR().
> - Switch mdelay(1) for usleep_range(1000,2000) so we don't
>   spin unecessarily during boot.
> - Use DRM_DEV_DEBUG() for information about deasserted reset.
> - Make a proper DRM_DEV_ERROR() for illegal resolution settings.
> - Simplify the inlined backlight enable/disable code by using
>   the existing inline helpers.
> - Add a few missing stray \n's
> ChangeLog v5->v6:
> - Collected Sam's ACK.
> ChangeLog v4->v5:
> - Assign proper bus_flags.
> - This is now the only remaining patch.
> ChangeLog v3->v4:
> - Tag on the SPI_3WIRE_HIZ flag to the SPI slave mode.
> ChangeLog v2->v3:
> - Rewrite as an SPI child device.
> ---
>  MAINTAINERS  |   7 +
>  drivers/gpu/drm/panel/Kconfig|   9 +
>  drivers/gpu/drm/panel/Makefile   |   1 +
>  drivers/gpu/drm/panel/panel-tpo-tpg110.c | 496 +++
>  4 files changed, 513 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-tpo-tpg110.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 32d76a90..e177473d5417 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4909,6 +4909,13 @@ DRM DRIVER FOR TDFX VIDEO CARDS
>  S: Orphan / Obsolete
>  F: drivers/gpu/drm/tdfx/
>
> +DRM DRIVER FOR TPO TPG110 PANELS
> +M: Linus Walleij 
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +S: Maintained
> +F: drivers/gpu/drm/panel/panel-tpo-tpg110.c
> +F: Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt

Except my query about this change in v6, all look fine on this driver.

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

[PATCH 07/14] staging: android: ion: Sync comment docs with struct ion_buffer

[Andrew F. Davis]

This struct is no longer documented correctly, fix this.

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion.h | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 2ef78c951a6b..e291299fd35f 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -23,8 +23,8 @@
 
 /**
  * struct ion_buffer - metadata for a particular buffer
- * @ref:   reference count
  * @node:  node in the ion_device buffers tree
+ * @list:  element in list of deferred freeable buffers
  * @dev:   back pointer to the ion_device
  * @heap:  back pointer to the heap the buffer came from
  * @flags: buffer specific flags
@@ -35,7 +35,8 @@
  * @lock:  protects the buffers cnt fields
  * @kmap_cnt:  number of times the buffer is mapped to the kernel
  * @vaddr: the kernel mapping if kmap_cnt is not zero
- * @sg_table:  the sg table for the buffer if dmap_cnt is not zero
+ * @sg_table:  the sg table for the buffer
+ * @attachments:   list of devices attached to this buffer
  */
 struct ion_buffer {
union {
@@ -151,12 +152,16 @@ struct ion_heap {
unsigned long flags;
unsigned int id;
const char *name;
+
+   /* deferred free support */
struct shrinker shrinker;
struct list_head free_list;
size_t free_list_size;
spinlock_t free_lock;
wait_queue_head_t waitqueue;
struct task_struct *task;
+
+   /* heap statistics */
u64 num_of_buffers;
u64 num_of_alloc_bytes;
u64 alloc_bytes_wm;
-- 
2.19.1

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

[PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap

[Andrew F. Davis]

Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses from the CPU to a cached heap should be bracketed with
{begin,end}_cpu_access calls so maintenance should not be needed anyway.

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 14e48f6eb734..09cb5a8e2b09 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct 
dma_buf_attachment *attachment,
 
table = a->table;
 
-   if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
-   direction))
+   if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
+ direction, DMA_ATTR_SKIP_CPU_SYNC))
return ERR_PTR(-ENOMEM);
 
return table;
@@ -272,7 +272,8 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
  struct sg_table *table,
  enum dma_data_direction direction)
 {
-   dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+   dma_unmap_sg_attrs(attachment->dev, table->sgl, table->nents,
+  direction, DMA_ATTR_SKIP_CPU_SYNC);
 }
 
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
-- 
2.19.1

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

Re: [PATCH v8] drm/panel: Add a driver for the TPO TPG110

[Noralf Trønnes]

Den 11.01.2019 18.54, skrev Linus Walleij:
> The TPO (Toppoly) TPG110 is a pretty generic display driver
> similar in vein to the Ilitek 93xx devices. It is not a panel
> per se but a driver used with several low-cost noname panels.
> 
> This is used on the Nomadik NHK15 combined with a OSD
> OSD057VA01CT display for WVGA 800x480.
> 
> The driver is pretty minimalistic right now but can be
> extended to handle non-default polarities, gamma correction
> etc.
> 
> The driver is based on the baked-in code in
> drivers/video/fbdev/amba-clcd-nomadik.c which will be
> decomissioned once this us upstream.
> 
> Cc: Noralf Trønnes 
> Acked-by: Sam Ravnborg 
> Signed-off-by: Linus Walleij 
> ---

Seems like it could make sense to add a devm_drm_panel_add(), but maybe
for another day.

Acked-by: Noralf Trønnes 


> ChangeLog v7->v8:
> - Lifecycle the backlight properly with devm_of_find_backlight()
> - Drop if (backlight) clauses since helper are NULL-tolerant
> ChangeLog v6->v7:
> - Drop the video mode helpers.
> - Do not include  but instead the granular APIs.
> - Switch dev_info() and dev_err() for DRM_DEV_INFO()
>   and DRM_DEV_ERROR().
> - Switch mdelay(1) for usleep_range(1000,2000) so we don't
>   spin unecessarily during boot.
> - Use DRM_DEV_DEBUG() for information about deasserted reset.
> - Make a proper DRM_DEV_ERROR() for illegal resolution settings.
> - Simplify the inlined backlight enable/disable code by using
>   the existing inline helpers.
> - Add a few missing stray \n's
> ChangeLog v5->v6:
> - Collected Sam's ACK.
> ChangeLog v4->v5:
> - Assign proper bus_flags.
> - This is now the only remaining patch.
> ChangeLog v3->v4:
> - Tag on the SPI_3WIRE_HIZ flag to the SPI slave mode.
> ChangeLog v2->v3:
> - Rewrite as an SPI child device.
> ---
>  MAINTAINERS  |   7 +
>  drivers/gpu/drm/panel/Kconfig|   9 +
>  drivers/gpu/drm/panel/Makefile   |   1 +
>  drivers/gpu/drm/panel/panel-tpo-tpg110.c | 496 +++
>  4 files changed, 513 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-tpo-tpg110.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 32d76a90..e177473d5417 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4909,6 +4909,13 @@ DRM DRIVER FOR TDFX VIDEO CARDS
>  S:   Orphan / Obsolete
>  F:   drivers/gpu/drm/tdfx/
>  
> +DRM DRIVER FOR TPO TPG110 PANELS
> +M:   Linus Walleij 
> +T:   git git://anongit.freedesktop.org/drm/drm-misc
> +S:   Maintained
> +F:   drivers/gpu/drm/panel/panel-tpo-tpg110.c
> +F:   Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> +
>  DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS
>  M:   Dave Airlie 
>  R:   Sean Paul 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 3f3537719beb..a71f44191273 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -204,6 +204,15 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>  
> +config DRM_PANEL_TPO_TPG110
> + tristate "TPO TPG 800x400 panel"
> + depends on OF && SPI && GPIOLIB
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y here if you want to enable support for TPO TPG110
> +   400CH LTPS TFT LCD Single Chip Digital Driver for up to
> +   800x400 LCD panels.
> +
>  config DRM_PANEL_TRULY_NT35597_WQXGA
>   tristate "Truly WQXGA"
>   depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 4396658a7996..cd14ca39c6e0 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -21,4 +21,5 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += 
> panel-seiko-43wvf1g.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
>  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
>  obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c 
> b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
> new file mode 100644
> index ..5a9f8f4d5d24
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
> @@ -0,0 +1,496 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Panel driver for the TPO TPG110 400CH LTPS TFT LCD Single Chip
> + * Digital Driver.
> + *
> + * This chip drives a TFT LCD, so it does not know what kind of
> + * display is actually connected to it, so the width and height of that
> + * display needs to be supplied from the machine configuration.
> + *
> + * Author:
> + * Linus Walleij 
> + */
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TPG110_TEST  0x00
> 

[PATCH 14/14] staging: android: ion: Add UNMAPPED heap type and helper

[Andrew F. Davis]

The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This memory can still be
allocated from and used by devices that do have access to the
backing memory.

Based originally on the secure/unmapped heap from Linaro for
the OP-TEE SDP implementation, this was re-written to match
the carveout heap helper code.

Suggested-by: Etienne Carriere 
Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/Kconfig   |  10 ++
 drivers/staging/android/ion/Makefile  |   1 +
 drivers/staging/android/ion/ion.h |  16 +++
 .../staging/android/ion/ion_unmapped_heap.c   | 123 ++
 drivers/staging/android/uapi/ion.h|   3 +
 5 files changed, 153 insertions(+)
 create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 0fdda6f62953..a117b8b91b14 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -42,3 +42,13 @@ config ION_CMA_HEAP
  Choose this option to enable CMA heaps with Ion. This heap is backed
  by the Contiguous Memory Allocator (CMA). If your system has these
  regions, you should say Y here.
+
+config ION_UNMAPPED_HEAP
+   bool "ION unmapped heap support"
+   depends on ION
+   help
+ Choose this option to enable UNMAPPED heaps with Ion. This heap is
+ backed in specific memory pools, carveout from the Linux memory.
+ Unlike carveout heaps these are assumed to be not mappable by
+ kernel or user-space.
+ Unless you know your system has these regions, you should say N here.
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index 17f3a7569e3d..c71a1f3de581 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o 
ion_page_pool.o
 obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
 obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
 obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
+obj-$(CONFIG_ION_UNMAPPED_HEAP) += ion_unmapped_heap.o
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 97b2876b165a..ce74332018ba 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -341,4 +341,20 @@ static inline struct ion_heap 
*ion_chunk_heap_create(phys_addr_t base, size_t si
 }
 #endif
 
+#ifdef CONFIG_ION_UNMAPPED_HEAP
+/**
+ * ion_unmapped_heap_create
+ * @base:  base address of carveout memory
+ * @size:  size of carveout memory region
+ *
+ * Creates an unmapped ion_heap using the passed in data
+ */
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size);
+#else
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif
+
 #endif /* _ION_H */
diff --git a/drivers/staging/android/ion/ion_unmapped_heap.c 
b/drivers/staging/android/ion/ion_unmapped_heap.c
new file mode 100644
index ..7602b659c2ec
--- /dev/null
+++ b/drivers/staging/android/ion/ion_unmapped_heap.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ION Memory Allocator unmapped heap helper
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
+ *
+ * ION "unmapped" heaps are physical memory heaps not by default mapped into
+ * a virtual address space. The buffer owner can explicitly request kernel
+ * space mappings but the underlying memory may still not be accessible for
+ * various reasons, such as firewalls.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "ion.h"
+
+#define ION_UNMAPPED_ALLOCATE_FAIL -1
+
+struct ion_unmapped_heap {
+   struct ion_heap heap;
+   struct gen_pool *pool;
+};
+
+static phys_addr_t ion_unmapped_allocate(struct ion_heap *heap,
+unsigned long size)
+{
+   struct ion_unmapped_heap *unmapped_heap =
+   container_of(heap, struct ion_unmapped_heap, heap);
+   unsigned long offset;
+
+   offset = gen_pool_alloc(unmapped_heap->pool, size);
+   if (!offset)
+   return ION_UNMAPPED_ALLOCATE_FAIL;
+
+   return offset;
+}
+
+static void ion_unmapped_free(struct ion_heap *heap, phys_addr_t addr,
+ unsigned long size)
+{
+   struct ion_unmapped_heap *unmapped_heap =
+   container_of(heap, struct ion_unmapped_heap, heap);
+
+   gen_pool_free(unmapped_heap->pool, addr, size);
+}
+
+static int ion_unmapped_heap_allocate(struct ion_heap *heap,
+ struct ion_buffer *buffer,
+ unsigned long size,
+ unsigned long 

[PATCH 01/14] staging: android: ion: Add proper header information

[Andrew F. Davis]

The filenames in headers add nothing are often wrong after moves, lets
drop them here and add a little description of the files contents.

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion.c   | 2 +-
 drivers/staging/android/ion/ion.h   | 2 +-
 drivers/staging/android/ion/ion_carveout_heap.c | 2 +-
 drivers/staging/android/ion/ion_chunk_heap.c| 2 +-
 drivers/staging/android/ion/ion_cma_heap.c  | 2 +-
 drivers/staging/android/ion/ion_heap.c  | 2 +-
 drivers/staging/android/ion/ion_page_pool.c | 2 +-
 drivers/staging/android/ion/ion_system_heap.c   | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index a0802de8c3a1..de1ca5e26a4a 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * drivers/staging/android/ion/ion.c
+ * ION Memory Allocator
  *
  * Copyright (C) 2011 Google, Inc.
  */
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 47b594cf1ac9..ff455fdde1a8 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * drivers/staging/android/ion/ion.h
+ * ION Memory Allocator kernel interface header
  *
  * Copyright (C) 2011 Google, Inc.
  */
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index e129237a0417..4a9f9c275654 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * drivers/staging/android/ion/ion_carveout_heap.c
+ * ION Memory Allocator carveout heap helper
  *
  * Copyright (C) 2011 Google, Inc.
  */
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 159d72f5bc42..5a8917d9beac 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * drivers/staging/android/ion/ion_chunk_heap.c
+ * ION memory allocator chunk heap helper
  *
  * Copyright (C) 2012 Google, Inc.
  */
diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index 3fafd013d80a..7b557dd5e78b 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * drivers/staging/android/ion/ion_cma_heap.c
+ * ION Memory Allocator CMA heap exporter
  *
  * Copyright (C) Linaro 2012
  * Author:  for ST-Ericsson.
diff --git a/drivers/staging/android/ion/ion_heap.c 
b/drivers/staging/android/ion/ion_heap.c
index 31db510018a9..6ee0ac6e4be4 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * drivers/staging/android/ion/ion_heap.c
+ * ION Memory Allocator generic heap helpers
  *
  * Copyright (C) 2011 Google, Inc.
  */
diff --git a/drivers/staging/android/ion/ion_page_pool.c 
b/drivers/staging/android/ion/ion_page_pool.c
index 0d2a95957ee8..fd4995fb676e 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * drivers/staging/android/ion/ion_mem_pool.c
+ * ION Memory Allocator page pool helpers
  *
  * Copyright (C) 2011 Google, Inc.
  */
diff --git a/drivers/staging/android/ion/ion_system_heap.c 
b/drivers/staging/android/ion/ion_system_heap.c
index 0383f7548d48..643b32099488 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * drivers/staging/android/ion/ion_system_heap.c
+ * ION Memory Allocator system heap exporter
  *
  * Copyright (C) 2011 Google, Inc.
  */
-- 
2.19.1

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

[PATCH 02/14] staging: android: ion: Remove empty ion_ioctl_dir() function

[Andrew F. Davis]

This function is empty of real function and can be replaced with
_IOC_DIR().

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion-ioctl.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index a8d3cc412fb9..b366f97a5728 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -31,23 +31,11 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
return 0;
 }
 
-/* fix up the cases where the ioctl direction bits are incorrect */
-static unsigned int ion_ioctl_dir(unsigned int cmd)
-{
-   switch (cmd) {
-   default:
-   return _IOC_DIR(cmd);
-   }
-}
-
 long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
int ret = 0;
-   unsigned int dir;
union ion_ioctl_arg data;
 
-   dir = ion_ioctl_dir(cmd);
-
if (_IOC_SIZE(cmd) > sizeof(data))
return -EINVAL;
 
@@ -65,7 +53,7 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
return ret;
}
 
-   if (!(dir & _IOC_WRITE))
+   if (!(_IOC_DIR(cmd) & _IOC_WRITE))
memset(, 0, sizeof(data));
 
switch (cmd) {
@@ -90,7 +78,7 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
return -ENOTTY;
}
 
-   if (dir & _IOC_READ) {
+   if (_IOC_DIR(cmd) & _IOC_READ) {
if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd)))
return -EFAULT;
}
-- 
2.19.1

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

[PATCH 08/14] staging: android: ion: Remove base from ion_carveout_heap

[Andrew F. Davis]

The base address is not used anywhere and tracked by the pool
allocator. No need to store this anymore.

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion_carveout_heap.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index be80671df9c8..ab9b72adca9c 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -20,7 +20,6 @@
 struct ion_carveout_heap {
struct ion_heap heap;
struct gen_pool *pool;
-   phys_addr_t base;
 };
 
 static phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
@@ -125,8 +124,7 @@ struct ion_heap *ion_carveout_heap_create(phys_addr_t base, 
size_t size)
kfree(carveout_heap);
return ERR_PTR(-ENOMEM);
}
-   carveout_heap->base = base;
-   gen_pool_add(carveout_heap->pool, carveout_heap->base, size, -1);
+   gen_pool_add(carveout_heap->pool, base, size, -1);
carveout_heap->heap.ops = _heap_ops;
carveout_heap->heap.type = ION_HEAP_TYPE_CARVEOUT;
carveout_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
-- 
2.19.1

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

[PATCH 04/14] staging: android: ion: Remove leftover comment

[Andrew F. Davis]

Since we use CMA APIs directly there is no device nor private heaps data,
drop this comment.

Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion_cma_heap.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index 7b557dd5e78b..bf65e67ef9d8 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -111,10 +111,6 @@ static struct ion_heap *__ion_cma_heap_create(struct cma 
*cma)
return ERR_PTR(-ENOMEM);
 
cma_heap->heap.ops = _cma_ops;
-   /*
-* get device from private heaps data, later it will be
-* used to make the link with reserved CMA memory
-*/
cma_heap->cma = cma;
cma_heap->heap.type = ION_HEAP_TYPE_DMA;
return _heap->heap;
-- 
2.19.1

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

[PATCH 03/14] staging: android: ion: Merge ion-ioctl.c into ion.c

[Andrew F. Davis]

The file ion-ioctl.c is now much to small and tightly integrated
with the main ion.c file to justify keeping it separate. Merge
this file.

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/Makefile|  2 +-
 drivers/staging/android/ion/ion-ioctl.c | 86 -
 drivers/staging/android/ion/ion.c   | 79 ++-
 drivers/staging/android/ion/ion.h   |  8 ---
 4 files changed, 78 insertions(+), 97 deletions(-)
 delete mode 100644 drivers/staging/android/ion/ion-ioctl.c

diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index bb30bf8774a0..17f3a7569e3d 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_ION) +=   ion.o ion-ioctl.o ion_heap.o
+obj-$(CONFIG_ION) += ion.o ion_heap.o
 obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
 obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
 obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
deleted file mode 100644
index b366f97a5728..
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ /dev/null
@@ -1,86 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright (C) 2011 Google, Inc.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include "ion.h"
-
-union ion_ioctl_arg {
-   struct ion_allocation_data allocation;
-   struct ion_heap_query query;
-};
-
-static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
-{
-   switch (cmd) {
-   case ION_IOC_HEAP_QUERY:
-   if (arg->query.reserved0 ||
-   arg->query.reserved1 ||
-   arg->query.reserved2)
-   return -EINVAL;
-   break;
-   default:
-   break;
-   }
-
-   return 0;
-}
-
-long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
-{
-   int ret = 0;
-   union ion_ioctl_arg data;
-
-   if (_IOC_SIZE(cmd) > sizeof(data))
-   return -EINVAL;
-
-   /*
-* The copy_from_user is unconditional here for both read and write
-* to do the validate. If there is no write for the ioctl, the
-* buffer is cleared
-*/
-   if (copy_from_user(, (void __user *)arg, _IOC_SIZE(cmd)))
-   return -EFAULT;
-
-   ret = validate_ioctl_arg(cmd, );
-   if (ret) {
-   pr_warn_once("%s: ioctl validate failed\n", __func__);
-   return ret;
-   }
-
-   if (!(_IOC_DIR(cmd) & _IOC_WRITE))
-   memset(, 0, sizeof(data));
-
-   switch (cmd) {
-   case ION_IOC_ALLOC:
-   {
-   int fd;
-
-   fd = ion_alloc(data.allocation.len,
-  data.allocation.heap_id_mask,
-  data.allocation.flags);
-   if (fd < 0)
-   return fd;
-
-   data.allocation.fd = fd;
-
-   break;
-   }
-   case ION_IOC_HEAP_QUERY:
-   ret = ion_query_heaps();
-   break;
-   default:
-   return -ENOTTY;
-   }
-
-   if (_IOC_DIR(cmd) & _IOC_READ) {
-   if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd)))
-   return -EFAULT;
-   }
-   return ret;
-}
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index de1ca5e26a4a..2d6d8c0994b2 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -390,7 +390,7 @@ static const struct dma_buf_ops dma_buf_ops = {
.unmap = ion_dma_buf_kunmap,
 };
 
-int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
+static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
 {
struct ion_device *dev = internal_dev;
struct ion_buffer *buffer = NULL;
@@ -447,7 +447,7 @@ int ion_alloc(size_t len, unsigned int heap_id_mask, 
unsigned int flags)
return fd;
 }
 
-int ion_query_heaps(struct ion_heap_query *query)
+static int ion_query_heaps(struct ion_heap_query *query)
 {
struct ion_device *dev = internal_dev;
struct ion_heap_data __user *buffer = u64_to_user_ptr(query->heaps);
@@ -492,6 +492,81 @@ int ion_query_heaps(struct ion_heap_query *query)
return ret;
 }
 
+union ion_ioctl_arg {
+   struct ion_allocation_data allocation;
+   struct ion_heap_query query;
+};
+
+static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
+{
+   switch (cmd) {
+   case ION_IOC_HEAP_QUERY:
+   if (arg->query.reserved0 ||
+   arg->query.reserved1 ||
+   arg->query.reserved2)
+   return -EINVAL;
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+

[PATCH 12/14] staging: android: ion: Declare helpers for carveout and chunk heaps

[Andrew F. Davis]

When enabled the helpers functions for creating carveout and chunk heaps
should have declarations in the ION header.

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion.h | 33 +++
 1 file changed, 33 insertions(+)

diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index e291299fd35f..97b2876b165a 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -308,4 +308,37 @@ void ion_page_pool_free(struct ion_page_pool *pool, struct 
page *page);
 int ion_page_pool_shrink(struct ion_page_pool *pool, gfp_t gfp_mask,
 int nr_to_scan);
 
+#ifdef CONFIG_ION_CARVEOUT_HEAP
+/**
+ * ion_carveout_heap_create
+ * @base:  base address of carveout memory
+ * @size:  size of carveout memory region
+ *
+ * Creates a carveout ion_heap using the passed in data
+ */
+struct ion_heap *ion_carveout_heap_create(phys_addr_t base, size_t size);
+#else
+static inline struct ion_heap *ion_carveout_heap_create(phys_addr_t base, 
size_t size)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif
+
+#ifdef CONFIG_ION_CHUNK_HEAP
+/**
+ * ion_chunk_heap_create
+ * @base:  base address of carveout memory
+ * @size:  size of carveout memory region
+ * @chunk_size:minimum allocation granularity
+ *
+ * Creates a chunk ion_heap using the passed in data
+ */
+struct ion_heap *ion_chunk_heap_create(phys_addr_t base, size_t size, size_t 
chunk_size);
+#else
+static inline struct ion_heap *ion_chunk_heap_create(phys_addr_t base, size_t 
size, size_t chunk_size)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif
+
 #endif /* _ION_H */
-- 
2.19.1

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

[PATCH 09/14] staging: android: ion: Remove base from ion_chunk_heap

[Andrew F. Davis]

The base address is not used anywhere and tracked by the pool
allocator. No need to store this anymore.

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion_chunk_heap.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index b82eac1c2d7a..899380b1 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -18,7 +18,6 @@
 struct ion_chunk_heap {
struct ion_heap heap;
struct gen_pool *pool;
-   phys_addr_t base;
unsigned long chunk_size;
unsigned long size;
unsigned long allocated;
@@ -131,16 +130,14 @@ struct ion_heap *ion_chunk_heap_create(phys_addr_t base, 
size_t size, size_t chu
ret = -ENOMEM;
goto error_gen_pool_create;
}
-   chunk_heap->base = base;
chunk_heap->size = size;
chunk_heap->allocated = 0;
 
-   gen_pool_add(chunk_heap->pool, chunk_heap->base, size, -1);
+   gen_pool_add(chunk_heap->pool, base, size, -1);
chunk_heap->heap.ops = _heap_ops;
chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
-   pr_debug("%s: base %pa size %zu\n", __func__,
-_heap->base, size);
+   pr_debug("%s: base %pa size %zu\n", __func__, , size);
 
return _heap->heap;
 
-- 
2.19.1

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

[PATCH 10/14] staging: android: ion: Remove unused headers

[Andrew F. Davis]

Various cleanups have removed the use of some headers in ION, remove
these here.

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion.c   | 3 ---
 drivers/staging/android/ion/ion_carveout_heap.c | 4 ++--
 drivers/staging/android/ion/ion_chunk_heap.c| 3 +--
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 2d6d8c0994b2..bba5f682bc25 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -5,7 +5,6 @@
  * Copyright (C) 2011 Google, Inc.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -14,10 +13,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index ab9b72adca9c..bb9d614767a2 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -4,7 +4,7 @@
  *
  * Copyright (C) 2011 Google, Inc.
  */
-#include 
+
 #include 
 #include 
 #include 
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+
 #include "ion.h"
 
 #define ION_CARVEOUT_ALLOCATE_FAIL -1
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 899380b1..3cdde9c1a717 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -8,11 +8,10 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
+
 #include "ion.h"
 
 struct ion_chunk_heap {
-- 
2.19.1

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

[PATCH 11/14] staging: android: ion: Allow heap name to be null

[Andrew F. Davis]

The heap name can be used for debugging but otherwise does not seem
to be required and no other part of the code will fail if left NULL
except here. We can make it required and check for it at some point,
for now lets just prevent this from causing a NULL pointer exception.

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index bba5f682bc25..14e48f6eb734 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -467,7 +467,7 @@ static int ion_query_heaps(struct ion_heap_query *query)
max_cnt = query->cnt;
 
plist_for_each_entry(heap, >heaps, node) {
-   strncpy(hdata.name, heap->name, MAX_HEAP_NAME);
+   strncpy(hdata.name, heap->name ?: "(null)", MAX_HEAP_NAME);
hdata.name[sizeof(hdata.name) - 1] = '\0';
hdata.type = heap->type;
hdata.heap_id = heap->id;
-- 
2.19.1

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

[PATCH 05/14] staging: android: ion: Remove struct ion_platform_heap

[Andrew F. Davis]

Now that ION heap registration has been re-worked to not depend on board
files or have a central heap register helper there is no need to have
this data structure. Most of the fields are unused.

Some heap creation helpers are still available that use this to define
the a heap but only use 2 or 3 elements from this struct, just convert
these to get supplied these values from the heap registrar directly.

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion.h | 23 ---
 .../staging/android/ion/ion_carveout_heap.c   | 12 --
 drivers/staging/android/ion/ion_chunk_heap.c  | 17 ++
 3 files changed, 11 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 084f246dcfc9..2ef78c951a6b 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -21,29 +21,6 @@
 
 #include "../uapi/ion.h"
 
-/**
- * struct ion_platform_heap - defines a heap in the given platform
- * @type:  type of the heap from ion_heap_type enum
- * @id:unique identifier for heap.  When allocating higher 
numb ers
- * will be allocated from first.  At allocation these are passed
- * as a bit mask and therefore can not exceed ION_NUM_HEAP_IDS.
- * @name:  used for debug purposes
- * @base:  base address of heap in physical memory if applicable
- * @size:  size of the heap in bytes if applicable
- * @priv:  private info passed from the board file
- *
- * Provided by the board file.
- */
-struct ion_platform_heap {
-   enum ion_heap_type type;
-   unsigned int id;
-   const char *name;
-   phys_addr_t base;
-   size_t size;
-   phys_addr_t align;
-   void *priv;
-};
-
 /**
  * struct ion_buffer - metadata for a particular buffer
  * @ref:   reference count
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index 4a9f9c275654..891f5703220b 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -103,17 +103,14 @@ static struct ion_heap_ops carveout_heap_ops = {
.unmap_kernel = ion_heap_unmap_kernel,
 };
 
-struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data)
+struct ion_heap *ion_carveout_heap_create(phys_addr_t base, size_t size)
 {
struct ion_carveout_heap *carveout_heap;
int ret;
 
struct page *page;
-   size_t size;
-
-   page = pfn_to_page(PFN_DOWN(heap_data->base));
-   size = heap_data->size;
 
+   page = pfn_to_page(PFN_DOWN(base));
ret = ion_heap_pages_zero(page, size, pgprot_writecombine(PAGE_KERNEL));
if (ret)
return ERR_PTR(ret);
@@ -127,9 +124,8 @@ struct ion_heap *ion_carveout_heap_create(struct 
ion_platform_heap *heap_data)
kfree(carveout_heap);
return ERR_PTR(-ENOMEM);
}
-   carveout_heap->base = heap_data->base;
-   gen_pool_add(carveout_heap->pool, carveout_heap->base, heap_data->size,
--1);
+   carveout_heap->base = base;
+   gen_pool_add(carveout_heap->pool, carveout_heap->base, size, -1);
carveout_heap->heap.ops = _heap_ops;
carveout_heap->heap.type = ION_HEAP_TYPE_CARVEOUT;
carveout_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 5a8917d9beac..c2321a047f0f 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -108,16 +108,13 @@ static struct ion_heap_ops chunk_heap_ops = {
.unmap_kernel = ion_heap_unmap_kernel,
 };
 
-struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data)
+struct ion_heap *ion_chunk_heap_create(phys_addr_t base, size_t size, size_t 
chunk_size)
 {
struct ion_chunk_heap *chunk_heap;
int ret;
struct page *page;
-   size_t size;
-
-   page = pfn_to_page(PFN_DOWN(heap_data->base));
-   size = heap_data->size;
 
+   page = pfn_to_page(PFN_DOWN(base));
ret = ion_heap_pages_zero(page, size, pgprot_writecombine(PAGE_KERNEL));
if (ret)
return ERR_PTR(ret);
@@ -126,23 +123,23 @@ struct ion_heap *ion_chunk_heap_create(struct 
ion_platform_heap *heap_data)
if (!chunk_heap)
return ERR_PTR(-ENOMEM);
 
-   chunk_heap->chunk_size = (unsigned long)heap_data->priv;
+   chunk_heap->chunk_size = chunk_size;
chunk_heap->pool = gen_pool_create(get_order(chunk_heap->chunk_size) +
   PAGE_SHIFT, -1);
if (!chunk_heap->pool) {
ret = -ENOMEM;
goto error_gen_pool_create;
}
-   chunk_heap->base = heap_data->base;
-   chunk_heap->size = heap_data->size;
+   

Re: [RFC AFBC 03/12] drm/afbc: Add AFBC modifier usage documentation

[Liviu Dudau]

On Thu, Jan 03, 2019 at 05:44:26PM -0300, Ezequiel Garcia wrote:
> Hi Liviu,
> 
> On Mon, 2018-12-03 at 11:31 +, Ayan Halder wrote:
> > From: Brian Starkey 
> > 
> > AFBC is a flexible, proprietary, lossless compression protocol and
> > format, with a number of defined DRM format modifiers. To facilitate
> > consistency and compatibility between different AFBC producers and
> > consumers, document the expectations for usage of the AFBC DRM format
> > modifiers in a new .rst chapter.
> > 
> > Signed-off-by: Brian Starkey 
> > Reviewed-by: Liviu Dudau 
> > ---
> 
> I can't find this commit anywhere. Did you decide to reject
> this or perhaps it just fell thru the cracks?

Cracks have opened wide enough to let this through, sorry about that!

I've now sent a pull request to get it merged.

Best regards,
Liviu

> 
> Thanks!
> Ezequiel
> 
> 
> >  Documentation/gpu/afbc.rst| 233 
> > ++
> >  Documentation/gpu/drivers.rst |   1 +
> >  MAINTAINERS   |   1 +
> >  include/uapi/drm/drm_fourcc.h |   3 +
> >  4 files changed, 238 insertions(+)
> >  create mode 100644 Documentation/gpu/afbc.rst
> > 
> > diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst
> > new file mode 100644
> > index 000..922d955
> > --- /dev/null
> > +++ b/Documentation/gpu/afbc.rst
> > @@ -0,0 +1,233 @@
> > +===
> > + Arm Framebuffer Compression (AFBC)
> > +===
> > +
> > +AFBC is a proprietary lossless image compression protocol and format.
> > +It provides fine-grained random access and minimizes the amount of
> > +data transferred between IP blocks.
> > +
> > +AFBC can be enabled on drivers which support it via use of the AFBC
> > +format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*).
> > +
> > +All users of the AFBC modifiers must follow the usage guidelines laid
> > +out in this document, to ensure compatibility across different AFBC
> > +producers and consumers.
> > +
> > +Components and Ordering
> > +===
> > +
> > +AFBC streams can contain several components - where a component
> > +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr).
> > +The assignment of input/output color channels must be consistent
> > +between the encoder and the decoder for correct operation, otherwise
> > +the consumer will interpret the decoded data incorrectly.
> > +
> > +Furthermore, when the lossless colorspace transform is used
> > +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for
> > +maximum compression efficiency), the component order must be:
> > +
> > + * Component 0: R
> > + * Component 1: G
> > + * Component 2: B
> > +
> > +The component ordering is communicated via the fourcc code in the
> > +fourcc:modifier pair. In general, component '0' is considered to
> > +reside in the least-significant bits of the corresponding linear
> > +format. For example, COMP(bits):
> > +
> > + * DRM_FORMAT_ABGR
> > +
> > +   * Component 0: R(8)
> > +   * Component 1: G(8)
> > +   * Component 2: B(8)
> > +   * Component 3: A(8)
> > +
> > + * DRM_FORMAT_BGR888
> > +
> > +   * Component 0: R(8)
> > +   * Component 1: G(8)
> > +   * Component 2: B(8)
> > +
> > + * DRM_FORMAT_YUYV
> > +
> > +   * Component 0: Y(8)
> > +   * Component 1: Cb(8, 2x1 subsampled)
> > +   * Component 2: Cr(8, 2x1 subsampled)
> > +
> > +In AFBC, 'X' components are not treated any differently from any other
> > +component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR
> > +encodes with 4 components, like so:
> > +
> > + * DRM_FORMAT_XBGR
> > +
> > +   * Component 0: R(8)
> > +   * Component 1: G(8)
> > +   * Component 2: B(8)
> > +   * Component 3: X(8)
> > +
> > +Please note, however, that the inclusion of a "wasted" 'X' channel is
> > +bad for compression efficiency, and so it's recommended to avoid
> > +formats containing 'X' bits. If a fourth component is
> > +required/expected by the encoder/decoder, then it is recommended to
> > +instead use an equivalent format with alpha, setting all alpha bits to
> > +'1'. If there is no requirement for a fourth component, then a format
> > +which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888.
> > +
> > +Number of Planes
> > +
> > +
> > +Formats which are typically multi-planar in linear layouts (e.g. YUV
> > +420), can be encoded into one, or multiple, AFBC planes. As with
> > +component order, the encoder and decoder must agree about the number
> > +of planes in order to correctly decode the buffer. The fourcc code is
> > +used to determine the number of encoded planes in an AFBC buffer,
> > +matching the number of planes for the linear (unmodified) format.
> > +Within each plane, the component ordering also follows the fourcc
> > +code:
> > +
> > +For example:
> > +
> > + * DRM_FORMAT_YUYV: nplanes = 1
> > +
> > +   * Plane 0:
> > +
> > + * Component 0: Y(8)
> > + * Component 1: Cb(8, 2x1 

[PATCH 00/14] Misc ION cleanups and adding unmapped heap

[Andrew F. Davis]

Hello all,

This is a set of (hopefully) non-controversial cleanups for the ION
framework and current set of heaps. These were found as I start to
familiarize myself with the framework to help in whatever way I
can in getting all this up to the standards needed for de-staging.

I would like to get some ideas of what is left to work on to get ION
out of staging. Has there been some kind of agreement on what ION should
eventually end up being? To me it looks like it is being whittled away at
to it's most core functions. To me that is looking like being a DMA-BUF
user-space front end, simply advertising available memory backings in a
system and providing allocations as DMA-BUF handles. If this is the case
then it looks close to being ready to me at least, but I would love to
hear any other opinions and concerns.

Back to this patchset, the last patch may be a bit different than the
others, it adds an unmapped heaps type and creation helper. I wanted to
get this in to show off another heap type and maybe some issues we may
have with the current ION framework. The unmapped heap is used when the
backing memory should not (or cannot) be touched. Currently this kind
of heap is used for firewalled secure memory that can be allocated like
normal heap memory but only used by secure devices (OP-TEE, crypto HW,
etc). It is basically just copied from the "carveout" heap type with the
only difference being it is not mappable to userspace and we do not clear
the memory (as we should not map it either). So should this really be a
new heap type? Or maybe advertised as a carveout heap but with an
additional allocation flag? Perhaps we do away with "types" altogether
and just have flags, coherent/non-coherent, mapped/unmapped, etc.

Maybe more thinking will be needed afterall..

Thanks,
Andrew

Andrew F. Davis (14):
  staging: android: ion: Add proper header information
  staging: android: ion: Remove empty ion_ioctl_dir() function
  staging: android: ion: Merge ion-ioctl.c into ion.c
  staging: android: ion: Remove leftover comment
  staging: android: ion: Remove struct ion_platform_heap
  staging: android: ion: Fixup some white-space issues
  staging: android: ion: Sync comment docs with struct ion_buffer
  staging: android: ion: Remove base from ion_carveout_heap
  staging: android: ion: Remove base from ion_chunk_heap
  staging: android: ion: Remove unused headers
  staging: android: ion: Allow heap name to be null
  staging: android: ion: Declare helpers for carveout and chunk heaps
  staging: android: ion: Do not sync CPU cache on map/unmap
  staging: android: ion: Add UNMAPPED heap type and helper

 drivers/staging/android/ion/Kconfig   |  10 ++
 drivers/staging/android/ion/Makefile  |   3 +-
 drivers/staging/android/ion/ion-ioctl.c   |  98 --
 drivers/staging/android/ion/ion.c |  93 +++--
 drivers/staging/android/ion/ion.h |  87 -
 .../staging/android/ion/ion_carveout_heap.c   |  19 +--
 drivers/staging/android/ion/ion_chunk_heap.c  |  25 ++--
 drivers/staging/android/ion/ion_cma_heap.c|   6 +-
 drivers/staging/android/ion/ion_heap.c|   8 +-
 drivers/staging/android/ion/ion_page_pool.c   |   2 +-
 drivers/staging/android/ion/ion_system_heap.c |   8 +-
 .../staging/android/ion/ion_unmapped_heap.c   | 123 ++
 drivers/staging/android/uapi/ion.h|   3 +
 13 files changed, 307 insertions(+), 178 deletions(-)
 delete mode 100644 drivers/staging/android/ion/ion-ioctl.c
 create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c

-- 
2.19.1

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

[PATCH 06/14] staging: android: ion: Fixup some white-space issues

[Andrew F. Davis]

Add white-space for easier reading and remove some where it does
not belong. No functional changes, they just bug me..

Signed-off-by: Andrew F. Davis 
---
 drivers/staging/android/ion/ion_carveout_heap.c | 1 +
 drivers/staging/android/ion/ion_chunk_heap.c| 2 +-
 drivers/staging/android/ion/ion_heap.c  | 6 ++
 drivers/staging/android/ion/ion_system_heap.c   | 6 +-
 4 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index 891f5703220b..be80671df9c8 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -44,6 +44,7 @@ static void ion_carveout_free(struct ion_heap *heap, 
phys_addr_t addr,
 
if (addr == ION_CARVEOUT_ALLOCATE_FAIL)
return;
+
gen_pool_free(carveout_heap->pool, addr, size);
 }
 
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index c2321a047f0f..b82eac1c2d7a 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -4,6 +4,7 @@
  *
  * Copyright (C) 2012 Google, Inc.
  */
+
 #include 
 #include 
 #include 
@@ -147,4 +148,3 @@ struct ion_heap *ion_chunk_heap_create(phys_addr_t base, 
size_t size, size_t chu
kfree(chunk_heap);
return ERR_PTR(ret);
 }
-
diff --git a/drivers/staging/android/ion/ion_heap.c 
b/drivers/staging/android/ion/ion_heap.c
index 6ee0ac6e4be4..473b465724f1 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+
 #include "ion.h"
 
 void *ion_heap_map_kernel(struct ion_heap *heap,
@@ -92,6 +93,7 @@ int ion_heap_map_user(struct ion_heap *heap, struct 
ion_buffer *buffer,
if (addr >= vma->vm_end)
return 0;
}
+
return 0;
 }
 
@@ -254,6 +256,7 @@ int ion_heap_init_deferred_free(struct ion_heap *heap)
return PTR_ERR_OR_ZERO(heap->task);
}
sched_setscheduler(heap->task, SCHED_IDLE, );
+
return 0;
 }
 
@@ -265,8 +268,10 @@ static unsigned long ion_heap_shrink_count(struct shrinker 
*shrinker,
int total = 0;
 
total = ion_heap_freelist_size(heap) / PAGE_SIZE;
+
if (heap->ops->shrink)
total += heap->ops->shrink(heap, sc->gfp_mask, 0);
+
return total;
 }
 
@@ -295,6 +300,7 @@ static unsigned long ion_heap_shrink_scan(struct shrinker 
*shrinker,
 
if (heap->ops->shrink)
freed += heap->ops->shrink(heap, sc->gfp_mask, to_scan);
+
return freed;
 }
 
diff --git a/drivers/staging/android/ion/ion_system_heap.c 
b/drivers/staging/android/ion/ion_system_heap.c
index 643b32099488..ec526a464db8 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+
 #include "ion.h"
 
 #define NUM_ORDERS ARRAY_SIZE(orders)
@@ -236,6 +237,7 @@ static int ion_system_heap_create_pools(struct 
ion_page_pool **pools)
goto err_create_pool;
pools[i] = pool;
}
+
return 0;
 
 err_create_pool:
@@ -274,6 +276,7 @@ static int ion_system_heap_create(void)
heap->name = "ion_system_heap";
 
ion_device_add_heap(heap);
+
return 0;
 }
 device_initcall(ion_system_heap_create);
@@ -355,6 +358,7 @@ static struct ion_heap 
*__ion_system_contig_heap_create(void)
heap->ops = _ops;
heap->type = ION_HEAP_TYPE_SYSTEM_CONTIG;
heap->name = "ion_system_contig_heap";
+
return heap;
 }
 
@@ -367,7 +371,7 @@ static int ion_system_contig_heap_create(void)
return PTR_ERR(heap);
 
ion_device_add_heap(heap);
+
return 0;
 }
 device_initcall(ion_system_contig_heap_create);
-
-- 
2.19.1

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

Re: [git pull] drm fixes for 5.0-rc2

[pr-tracker-bot]

The pull request you sent on Fri, 11 Jan 2019 12:11:42 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-11

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/385c59c7baaa4626f5c01888d50e86e5636e655e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8] drm/panel: Add a driver for the TPO TPG110

[Linus Walleij]

The TPO (Toppoly) TPG110 is a pretty generic display driver
similar in vein to the Ilitek 93xx devices. It is not a panel
per se but a driver used with several low-cost noname panels.

This is used on the Nomadik NHK15 combined with a OSD
OSD057VA01CT display for WVGA 800x480.

The driver is pretty minimalistic right now but can be
extended to handle non-default polarities, gamma correction
etc.

The driver is based on the baked-in code in
drivers/video/fbdev/amba-clcd-nomadik.c which will be
decomissioned once this us upstream.

Cc: Noralf Trønnes 
Acked-by: Sam Ravnborg 
Signed-off-by: Linus Walleij 
---
ChangeLog v7->v8:
- Lifecycle the backlight properly with devm_of_find_backlight()
- Drop if (backlight) clauses since helper are NULL-tolerant
ChangeLog v6->v7:
- Drop the video mode helpers.
- Do not include  but instead the granular APIs.
- Switch dev_info() and dev_err() for DRM_DEV_INFO()
  and DRM_DEV_ERROR().
- Switch mdelay(1) for usleep_range(1000,2000) so we don't
  spin unecessarily during boot.
- Use DRM_DEV_DEBUG() for information about deasserted reset.
- Make a proper DRM_DEV_ERROR() for illegal resolution settings.
- Simplify the inlined backlight enable/disable code by using
  the existing inline helpers.
- Add a few missing stray \n's
ChangeLog v5->v6:
- Collected Sam's ACK.
ChangeLog v4->v5:
- Assign proper bus_flags.
- This is now the only remaining patch.
ChangeLog v3->v4:
- Tag on the SPI_3WIRE_HIZ flag to the SPI slave mode.
ChangeLog v2->v3:
- Rewrite as an SPI child device.
---
 MAINTAINERS  |   7 +
 drivers/gpu/drm/panel/Kconfig|   9 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-tpo-tpg110.c | 496 +++
 4 files changed, 513 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-tpo-tpg110.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 32d76a90..e177473d5417 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4909,6 +4909,13 @@ DRM DRIVER FOR TDFX VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/tdfx/
 
+DRM DRIVER FOR TPO TPG110 PANELS
+M: Linus Walleij 
+T: git git://anongit.freedesktop.org/drm/drm-misc
+S: Maintained
+F: drivers/gpu/drm/panel/panel-tpo-tpg110.c
+F: Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
+
 DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS
 M: Dave Airlie 
 R: Sean Paul 
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3f3537719beb..a71f44191273 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -204,6 +204,15 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
 
+config DRM_PANEL_TPO_TPG110
+   tristate "TPO TPG 800x400 panel"
+   depends on OF && SPI && GPIOLIB
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for TPO TPG110
+ 400CH LTPS TFT LCD Single Chip Digital Driver for up to
+ 800x400 LCD panels.
+
 config DRM_PANEL_TRULY_NT35597_WQXGA
tristate "Truly WQXGA"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4396658a7996..cd14ca39c6e0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -21,4 +21,5 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
 obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c 
b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
new file mode 100644
index ..5a9f8f4d5d24
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
@@ -0,0 +1,496 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Panel driver for the TPO TPG110 400CH LTPS TFT LCD Single Chip
+ * Digital Driver.
+ *
+ * This chip drives a TFT LCD, so it does not know what kind of
+ * display is actually connected to it, so the width and height of that
+ * display needs to be supplied from the machine configuration.
+ *
+ * Author:
+ * Linus Walleij 
+ */
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TPG110_TEST0x00
+#define TPG110_CHIPID  0x01
+#define TPG110_CTRL1   0x02
+#define TPG110_RES_MASKGENMASK(2, 0)
+#define TPG110_RES_800X480 0x07
+#define TPG110_RES_640X480 0x06
+#define TPG110_RES_480X272 0x05
+#define TPG110_RES_480X640 0x04
+#define TPG110_RES_480X272_D   0x01 /* Dual scan: 

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

[bugzilla-daemon]

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

--- Comment #13 from Andrey Grodzovsky  ---
(In reply to nmr from comment #10)
> Created attachment 143036 [details]
> UMR dump for PoE/gallium-nine induced AMDGPU hang
> 
> I am experiencing the same bug, here is the UMR dump.

Marek, I am seeing waves dumps in here during the hang, could you please take a
look and advise ?

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

[Bug 104347] AMD RX 580: Hide/Show Chromium sometimes corrupts screen (see screenshot)

[bugzilla-daemon]

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

--- Comment #19 from Michel Dänzer  ---
If this is still happening,
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/21
might help.

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

[Bug 97639] Intermittent flickering artifacts with AMD R7 260x

[bugzilla-daemon]

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

--- Comment #12 from Michel Dänzer  ---
Is this still happening with current drivers?

-- 
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 2/3] dt-bindings: drm/panel: simple: add Evervision VGG804821

[Sam Ravnborg]

Hi Rob.

> > > +++ 
> > > b/Documentation/devicetree/bindings/display/panel/evervision,vgg804821.txt
> > > @@ -0,0 +1,12 @@
> > > +Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel
> > > +
> > > +Required properties:
> > > +- compatible: should be "evervision,vgg804821"
> > > +- power-supply: See simple-panel.txt
> > > +
> > > +Optional properties:
> > > +- backlight: See simple-panel.txt
> > > +- enable-gpios: See simple-panel.txt
> > > +
> > > +This binding is compatible with the simple-panel binding, which is 
> > > specified
> > > +in simple-panel.txt in this directory.
> > 
> > Other bindings just have the compatible listed and the above two lines and
> > do not repeat the required/optional properties.
> > If there is not special reason to add these they I suggest to simplify the 
> > binding.
> 
> It is not sufficient to just refer to simple-panel.txt. For example, 
> that doesn't convey if a panel has a single supply or multiple and the 
> author just ignored supplies. Or what if a panel doesn't have a 
> backlight or enable line?

Thanks, noted.
I have a few bindings awaiting to be sent that will need a small update.

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

Re: [PATCH 5/5] drm/doc: Polish kerneldoc for drm_device.h

[Sam Ravnborg]

Hi Daniel.

Thanks, good to have it ready and plugged into DRM doc.
I like that the legacy stuff is now separate - so one knows
what not to look at.

> +
> + /**
> +  * @irq: Use by the drm_irq_install() and drm_irq_unistall() helpers.
> +  */
>   int irq;

"Use => Used"

Other than the above nit:
Acked-by: Sam Ravnborg 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] dt-bindings: drm/panel: simple: add Evervision VGG804821

[Rob Herring]

On Fri, Jan 04, 2019 at 05:38:31PM +0100, Sam Ravnborg wrote:
> Hi Marco.
> 
> On Thu, Jan 03, 2019 at 07:26:57PM +0100, Marco Felsch wrote:
> > Add support for the Evervision VG804821 800x480 5.0" LCD TFT parallel
> > panel to DRM simple panel driver.
> > 
> > Signed-off-by: Marco Felsch 
> > ---
> >  .../bindings/display/panel/evervision,vgg804821.txt  | 12 
> >  1 file changed, 12 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/panel/evervision,vgg804821.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/evervision,vgg804821.txt 
> > b/Documentation/devicetree/bindings/display/panel/evervision,vgg804821.txt
> > new file mode 100644
> > index ..82d22e191ac3
> > --- /dev/null
> > +++ 
> > b/Documentation/devicetree/bindings/display/panel/evervision,vgg804821.txt
> > @@ -0,0 +1,12 @@
> > +Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel
> > +
> > +Required properties:
> > +- compatible: should be "evervision,vgg804821"
> > +- power-supply: See simple-panel.txt
> > +
> > +Optional properties:
> > +- backlight: See simple-panel.txt
> > +- enable-gpios: See simple-panel.txt
> > +
> > +This binding is compatible with the simple-panel binding, which is 
> > specified
> > +in simple-panel.txt in this directory.
> 
> Other bindings just have the compatible listed and the above two lines and
> do not repeat the required/optional properties.
> If there is not special reason to add these they I suggest to simplify the 
> binding.

It is not sufficient to just refer to simple-panel.txt. For example, 
that doesn't convey if a panel has a single supply or multiple and the 
author just ignored supplies. Or what if a panel doesn't have a 
backlight or enable line?

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

Re: [PATCH 2/3] dt-bindings: drm/panel: simple: add Evervision VGG804821

[Rob Herring]

On Thu,  3 Jan 2019 19:26:57 +0100, Marco Felsch wrote:
> Add support for the Evervision VG804821 800x480 5.0" LCD TFT parallel
> panel to DRM simple panel driver.
> 
> Signed-off-by: Marco Felsch 
> ---
>  .../bindings/display/panel/evervision,vgg804821.txt  | 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/evervision,vgg804821.txt
> 

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

Re: [PATCH 1/3] dt-bindings: add vendor prefix for Evervision Electronics

[Rob Herring]

On Thu,  3 Jan 2019 19:26:56 +0100, Marco Felsch wrote:
> Evervision Electronics is a panel manufacturer from Taipei.
> http://www.evervisionlcd.com/index.php?lang=en
> 
> Signed-off-by: Marco Felsch 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

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

[PATCH 4/5] drm/doc: Move bridge link target to the right place

[Daniel Vetter]

I screwed up a rebase somehow.

v2: Drop bogus hunk.

v3: Really drop bogus hunk (Lubomir).

Cc: Lubomir Rintel 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms-helpers.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 7a3fc569bc68..fbd11b2fe5b5 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -116,8 +116,6 @@ Framebuffer CMA Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_fb_cma_helper.c
:export:
 
-.. _drm_bridges:
-
 Framebuffer GEM Helper Reference
 
 
@@ -127,6 +125,8 @@ Framebuffer GEM Helper Reference
 .. kernel-doc:: drivers/gpu/drm/drm_gem_framebuffer_helper.c
:export:
 
+.. _drm_bridges:
+
 Bridges
 ===
 
-- 
2.20.1

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

[PATCH 5/5] drm/doc: Polish kerneldoc for drm_device.h

[Daniel Vetter]

- Move all the legacy gunk at the bottom, and exclude it from
  kerneldoc.
- Documentation for the remaining bits.

Cc: Sam Ravnborg 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-internals.rst |   3 +
 include/drm/drm_device.h| 150 
 2 files changed, 88 insertions(+), 65 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index 36c569444e12..2d2d8ad7e05f 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -81,6 +81,9 @@ Device Instance and Driver Handling
 .. kernel-doc:: drivers/gpu/drm/drm_drv.c
:doc: driver instance overview
 
+.. kernel-doc:: include/drm/drm_device.h
+   :internal:
+
 .. kernel-doc:: include/drm/drm_drv.h
:internal:
 
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index d7cedbac66a3..ab6d3a6396bb 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -69,7 +69,13 @@ struct drm_device {
/** @driver: DRM driver managing the device */
struct drm_driver *driver;
 
-   /** @dev_private: DRM driver private data */
+   /**
+* @dev_private:
+*
+* DRM driver private data. Instead of using this pointer it is
+* recommended that drivers use drm_dev_init() and embed struct
+* _device in their larger per-device structure.
+*/
void *dev_private;
 
/** @primary: Primary node */
@@ -78,6 +84,11 @@ struct drm_device {
/** @render: Render node */
struct drm_minor *render;
 
+   /**
+* @registered:
+*
+* Internally used by drm_dev_register() and drm_connector_register().
+*/
bool registered;
 
/**
@@ -134,16 +145,13 @@ struct drm_device {
 */
int open_count;
 
-   /** @buf_lock: Lock for _use and a few other things. */
-   spinlock_t buf_lock;
-
-   /** @buf_use: Usage counter for buffers in use -- cannot alloc */
-   int buf_use;
-
-   /** @buf_alloc: Buffer allocation in progress */
-   atomic_t buf_alloc;
-
+   /** @filelist_mutex: Protects @filelist. */
struct mutex filelist_mutex;
+   /**
+* @filelist:
+*
+* List of userspace clients, linked through _file.lhead.
+*/
struct list_head filelist;
 
/**
@@ -168,46 +176,6 @@ struct drm_device {
 */
struct list_head clientlist;
 
-   /** @maplist: Memory management - linked list of regions */
-   struct list_head maplist;
-
-   /** @map_hash: Memory management - user token hash table for maps */
-   struct drm_open_hash map_hash;
-
-   /**
-* @ctxlist:
-* Context handle management - linked list of context handles
-*/
-   struct list_head ctxlist;
-
-   /**
-* @ctxlist_mutex:
-*
-* Context handle management - mutex for 
-*/
-   struct mutex ctxlist_mutex;
-
-   /**
-* @ctx_idr:
-* Context handle management
-*/
-   struct idr ctx_idr;
-
-   /**
-* @vmalist:
-* Context handle management - list of vmas (for debugging)
-*/
-   struct list_head vmalist;
-
-   /** @dma: Optional pointer for DMA support */
-   struct drm_device_dma *dma;
-
-   /** @context_flag: Context swapping flag */
-   __volatile__ long context_flag;
-
-   /** @last_context: Last current context */
-   int last_context;
-
/**
 * @irq_enabled:
 *
@@ -216,6 +184,10 @@ struct drm_device {
 * to true manually.
 */
bool irq_enabled;
+
+   /**
+* @irq: Use by the drm_irq_install() and drm_irq_unistall() helpers.
+*/
int irq;
 
/**
@@ -249,6 +221,10 @@ struct drm_device {
 *  Protects vblank count and time updates during vblank enable/disable
 */
spinlock_t vblank_time_lock;
+   /**
+* @vbl_lock: Top-level vblank references lock, wraps the low-level
+* @vblank_time_lock.
+*/
spinlock_t vbl_lock;
 
/**
@@ -264,14 +240,19 @@ struct drm_device {
 * races and imprecision over longer time periods, hence exposing a
 * hardware vblank counter is always recommended.
 *
-* If non-zeor, _crtc_funcs.get_vblank_counter must be set.
+* If non-zero, _crtc_funcs.get_vblank_counter must be set.
 */
-
-   /** @max_vblank_count: Size of vblank counter register */
u32 max_vblank_count;
 
/** @vblank_event_list: List of vblank events */
struct list_head vblank_event_list;
+
+   /**
+* @event_lock:
+*
+* Protects @vblank_event_list and event delivery in
+* general. See drm_send_event() and drm_send_event_locked().
+*/
spinlock_t event_lock;
 
/** @agp: AGP data */
@@ -281,23 +262,12 @@ struct drm_device {
 

[PATCH 2/5] drm/of: Fix kerneldoc

[Daniel Vetter]

I noticed a link that didn't work ...

Fixes: 1f2db3034c9f ("drm: of: introduce drm_of_find_panel_or_bridge")
Cc: Rob Herring 
Cc: Philipp Zabel 
Cc: Sean Paul 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_of.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 2763a5ec845b..f2f71d71494a 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -217,9 +217,11 @@ int drm_of_encoder_active_endpoint(struct device_node 
*node,
 }
 EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
 
-/*
+/**
  * drm_of_find_panel_or_bridge - return connected panel or bridge device
  * @np: device tree node containing encoder output ports
+ * @port: port in the device tree node
+ * @endpoint: endpoint in the device tree node
  * @panel: pointer to hold returned drm_panel
  * @bridge: pointer to hold returned drm_bridge
  *
-- 
2.20.1

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

[PATCH 3/5] drm/panel: Small documentation polish

[Daniel Vetter]

Need to make sure people can find the panel-bridge to avoid typing too
much.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/bridge/panel.c | 22 ++
 drivers/gpu/drm/drm_panel.c|  3 +++
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index caf12b8fd572..e3687d78cd0c 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -134,8 +134,8 @@ static const struct drm_bridge_funcs 
panel_bridge_bridge_funcs = {
 };
 
 /**
- * drm_panel_bridge_add - Creates a drm_bridge and drm_connector that
- * just calls the appropriate functions from drm_panel.
+ * drm_panel_bridge_add - Creates a _bridge and _connector that
+ * just calls the appropriate functions from _panel.
  *
  * @panel: The drm_panel being wrapped.  Must be non-NULL.
  * @connector_type: The DRM_MODE_CONNECTOR_* for the connector to be
@@ -149,9 +149,12 @@ static const struct drm_bridge_funcs 
panel_bridge_bridge_funcs = {
  * passed to drm_bridge_attach().  The drm_panel_prepare() and related
  * functions can be dropped from the encoder driver (they're now
  * called by the KMS helpers before calling into the encoder), along
- * with connector creation.  When done with the bridge,
- * drm_bridge_detach() should be called as normal, then
+ * with connector creation.  When done with the bridge (after
+ * drm_mode_config_cleanup() if the bridge has already been attached), then
  * drm_panel_bridge_remove() to free it.
+ *
+ * See devm_drm_panel_bridge_add() for an automatically manged version of this
+ * function.
  */
 struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
u32 connector_type)
@@ -210,6 +213,17 @@ static void devm_drm_panel_bridge_release(struct device 
*dev, void *res)
drm_panel_bridge_remove(*bridge);
 }
 
+/**
+ * devm_drm_panel_bridge_add - Creates a managed _bridge and _connector
+ * that just calls the appropriate functions from _panel.
+ * @dev: device to tie the bridge lifetime to
+ * @panel: The drm_panel being wrapped.  Must be non-NULL.
+ * @connector_type: The DRM_MODE_CONNECTOR_* for the connector to be
+ * created.
+ *
+ * This is the managed version of drm_panel_bridge_add() which automatically
+ * calls drm_panel_bridge_remove() when @dev is unbound.
+ */
 struct drm_bridge *devm_drm_panel_bridge_add(struct device *dev,
 struct drm_panel *panel,
 u32 connector_type)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index c33f95e08e1b..dbd5b873e8f2 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -36,6 +36,9 @@ static LIST_HEAD(panel_list);
  * The DRM panel helpers allow drivers to register panel objects with a
  * central registry and provide functions to retrieve those panels in display
  * drivers.
+ *
+ * For easy integration into drivers using the _bridge infrastructure 
please
+ * take look at drm_panel_bridge_add() and devm_drm_panel_bridge_add().
  */
 
 /**
-- 
2.20.1

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

[PATCH 1/5] drm/docs: improve docs for drm_drv.c

[Daniel Vetter]

Just a bit of drive-by reading:
- drm_dev_set_unique() is really the exception, make that clear.
- drm_dev_init() is the recomended approach.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_drv.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a5fe91b8c3c9..381581b01d48 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -264,14 +264,13 @@ void drm_minor_release(struct drm_minor *minor)
  * DOC: driver instance overview
  *
  * A device instance for a drm driver is represented by  drm_device. 
This
- * is allocated with drm_dev_alloc(), usually from bus-specific ->probe()
+ * is initialized with drm_dev_init(), usually from bus-specific ->probe()
  * callbacks implemented by the driver. The driver then needs to initialize all
  * the various subsystems for the drm device like memory management, vblank
  * handling, modesetting support and intial output configuration plus obviously
- * initialize all the corresponding hardware bits. An important part of this is
- * also calling drm_dev_set_unique() to set the userspace-visible unique name 
of
- * this device instance. Finally when everything is up and running and ready 
for
- * userspace the device instance can be published using drm_dev_register().
+ * initialize all the corresponding hardware bits. Finally when everything is 
up
+ * and running and ready for userspace the device instance can be published
+ * using drm_dev_register().
  *
  * There is also deprecated support for initalizing device instances using
  * bus-specific helpers and the _driver.load callback. But due to
@@ -287,9 +286,6 @@ void drm_minor_release(struct drm_minor *minor)
  * Note that the lifetime rules for _device instance has still a lot of
  * historical baggage. Hence use the reference counting provided by
  * drm_dev_get() and drm_dev_put() only carefully.
- *
- * It is recommended that drivers embed  drm_device into their own 
device
- * structure, which is supported through drm_dev_init().
  */
 
 /**
@@ -475,6 +471,9 @@ static void drm_fs_inode_free(struct inode *inode)
  * The initial ref-count of the object is 1. Use drm_dev_get() and
  * drm_dev_put() to take and drop further ref-counts.
  *
+ * It is recommended that drivers embed  drm_device into their own 
device
+ * structure.
+ *
  * Drivers that do not want to allocate their own device struct
  * embedding  drm_device can call drm_dev_alloc() instead. For drivers
  * that do embed  drm_device it must be placed first in the overall
@@ -765,7 +764,7 @@ static void remove_compat_control_link(struct drm_device 
*dev)
  * @flags: Flags passed to the driver's .load() function
  *
  * Register the DRM device @dev with the system, advertise device to user-space
- * and start normal device operation. @dev must be allocated via 
drm_dev_alloc()
+ * and start normal device operation. @dev must be initialized via 
drm_dev_init()
  * previously.
  *
  * Never call this twice on any device!
@@ -877,9 +876,9 @@ EXPORT_SYMBOL(drm_dev_unregister);
  * @dev: device of which to set the unique name
  * @name: unique name
  *
- * Sets the unique name of a DRM device using the specified string. Drivers
- * can use this at driver probe time if the unique name of the devices they
- * drive is static.
+ * Sets the unique name of a DRM device using the specified string. This is
+ * already done by drm_dev_init(), drivers should only override the default
+ * unique name for backwards compatibility reasons.
  *
  * Return: 0 on success or a negative error code on failure.
  */
-- 
2.20.1

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

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

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

--- Comment #10 from i...@yahoo.com ---
(In reply to Alex Deucher from comment #9)
> (In reply to rmuncrief from comment #8)
> > (In reply to Alex Deucher from comment #7)
> > > Can you bisect to figure out what commit broke things for you?
> > 
> > Actually I remember doing that many years ago when I was a maintainer for
> > Steam under wine. I'll look and see if I can find a current bisect tutorial
> > and give it a try. Any links or tips you can give to help give me a quick
> > start would be appreciated. I do remember it can take many days, which I'm
> > willing to invest as I said. However the fewer days the better! :)
> 
> It's pretty straight forward.  Just google for "kernel git bisect howto".

Bisecting between two major stable kernel versions is a nightmare.(Aka 4.18.0 -
4.19.0)

Most of the new changes are done before RC1 and it is quite common that there
are major breakages there, in systems we do not want to bother with. These
breakages are usually fixed (or reverted) in later Release Candidates.

It may be better to use some of the drm-next repositories, assuming that they
hold all graphic changes that are going upstream, but are not rebased until the
final release is done.

-- 
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 4/4] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

Den 11.01.2019 02.06, skrev David Lechner:
> On 1/9/19 11:49 AM, Noralf Trønnes wrote:
>> This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
>> handler. All flushing will now happen in the pipe functions.
>>
>> Also enable the damage plane property for all except repaper which can
>> only do full updates.
>>
>> ili9225:
>> This change made ili9225_init() equal to mipi_dbi_init() so use it.
>>
>> Cc: David Lechner 
>> Cc: Eric Anholt 
>> Signed-off-by: Noralf Trønnes 
>> ---
> 
> ...
> 
>> +static void ili9225_pipe_update(struct drm_simple_display_pipe *pipe,
>> +    struct drm_plane_state *old_state)
>> +{
>> +    struct drm_plane_state *state = pipe->plane.state;
>> +    struct drm_crtc *crtc = >crtc;
>> +    struct drm_rect rect;
>> +
>> +    if (drm_atomic_helper_damage_merged(old_state, state, ))
>> +    ili9225_fb_dirty(state->fb, );
>> +
>> +    if (crtc->state->event) {
>> +    spin_lock_irq(>dev->event_lock);
>> +    drm_crtc_send_vblank_event(crtc, crtc->state->event);
>> +    spin_unlock_irq(>dev->event_lock);
>> +    crtc->state->event = NULL;
>> +    }
>> +}
> 
> It looks like this function body is repeated 4 times with the only
> difference being the dirty function. Perhaps a helper function is
> called for?

I agree, this is used in several other drivers too. The problem is that
this is magic code to me so I wouldn't even know what to call the
function and certainly not what to put in the docs. So I left it out.
And the drm_crtc_arm_vblank_event() function used elsewhere adds even
more mystery to it all.

> 
> Also, I was going to test out this series the displays that I have,
> but I guess I will wait until it is easier to apply the patches.

I will send a version 2 when Maxime has backmerged -rc1.

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

Re: [PATCH v4 2/9] dt/bindings: drm/komeda: Add DT bindings for ARM display processor D71

[Rob Herring]

On Thu, Jan 03, 2019 at 11:40:04AM +, james qian wang (Arm Technology 
China) wrote:
> From: "james qian wang (Arm Technology China)" 
> 
> Add DT bindings documentation for the ARM display processor D71 and later
> IPs.
> 
> Changes in v4:
> - Deleted unnecessary address-cells, size-cells [Liviu Dudau]
> 
> Changes in v3:
> - Deleted unnecessary property: interrupt-names.
> - Dropped 'ports' and moving 'port' up a level.
> 
> Signed-off-by: James Qian Wang (Arm Technology China) 
> 
> Reviewed-by: Liviu Dudau 
> ---
>  .../bindings/display/arm/arm,komeda.txt   | 73 +++
>  1 file changed, 73 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/arm/arm,komeda.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/arm/arm,komeda.txt 
> b/Documentation/devicetree/bindings/display/arm/arm,komeda.txt
> new file mode 100644
> index ..919d651d3e8c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/arm/arm,komeda.txt
> @@ -0,0 +1,73 @@
> +Device Tree bindings for Arm Komeda display driver
> +
> +Required properties:
> +- compatible: Should be "arm,mali-d71"
> +- reg: Physical base address and length of the registers in the system
> +- interrupts: the interrupt line number of the device in the system
> +- clocks: A list of phandle + clock-specifier pairs, one for each entry
> +in 'clock-names'
> +- clock-names: A list of clock names. It should contain:
> +  - "mclk": for the main processor clock
> +  - "pclk": for the APB interface clock
> +- #address-cells: Must be 1
> +- #size-cells: Must be 0
> +
> +Required properties for sub-node: pipeline@nq
> +Each device contains one or two pipeline sub-nodes (at least one), each
> +pipeline node should provide properties:
> +- reg: Zero-indexed identifier for the pipeline
> +- clocks: A list of phandle + clock-specifier pairs, one for each entry
> +in 'clock-names'
> +- clock-names: should contain:
> +  - "pxclk": pixel clock
> +  - "aclk": AXI interface clock
> +
> +- port: each pipeline connect to an encoder input port. The connection is
> +modeled using the OF graph bindings specified in
> +Documentation/devicetree/bindings/graph.txt
> +
> +Optional properties:
> +  - memory-region: phandle to a node describing memory (see
> +Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
> +to be used for the framebuffer; if not present, the framebuffer may
> +be located anywhere in memory.
> +
> +Example:
> +/ {
> + ...
> +
> + dp0: display@c0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "arm,mali-d71";
> + reg = <0xc0 0x2>;
> + interrupts = <0 168 4>;
> + clocks = <_mclk>, <_aclk>;
> + clock-names = "mclk", "pclk";
> +
> + dp0_pipe0: pipeline@0 {
> + clocks = <>, <_aclk>;
> + clock-names = "pxclk", "aclk";
> + reg = <0>;
> +
> + port@0 {

Drop the '@0'

> + dp0_pipe0_out: endpoint {
> + remote-endpoint = <_dvi0_in>;
> + };
> + };
> + };
> +
> + dp0_pipe1: pipeline@1 {
> + clocks = <>, <_aclk>;
> + clock-names = "pxclk", "aclk";
> + reg = <1>;
> +
> + port@0 {

And here.

With that,

Reviewed-by: Rob Herring 

> + dp0_pipe1_out: endpoint {
> + remote-endpoint = <_dvi1_in>;
> + };
> + };
> + };
> + };
> + ...
> +};
> -- 
> 2.17.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

Re: [PATCH] drm/mediatek: Add MTK Framebuffer-Device (mt7623)

[Noralf Trønnes]

Den 11.01.2019 11.25, skrev Daniel Vetter:
> On Fri, Jan 11, 2019 at 05:49:15PM +0800, CK Hu wrote:
>> Hi, Daniel:
>>
>> On Fri, 2019-01-11 at 10:20 +0100, Daniel Vetter wrote:
>>> On Fri, Jan 11, 2019 at 11:20:09AM +0800, CK Hu wrote:
 Hi, Daniel:

 On Thu, 2019-01-10 at 21:02 +0100, Daniel Vetter wrote:
> On Thu, Jan 10, 2019 at 08:01:37PM +0100, Frank Wunderlich wrote:
>> Hi Daniel,
>>
 Would be good to use the new generic fbdev emulation code here, for 
 even
 less code. Or at least know why this isn't possible to use for mtk (and
 maybe address that in the core code). Hand-rolling fbdev code 
 shouldn't be
 needed anymore.
>>>
>>> Back on the mailing list, no private replies please:
>>
>> i don't wanted to spam all people with dumb questions ;)
>
> There's no dumb questions, only insufficient documentation :-)
>
>>> For examples please grep for drm_fbdev_generic_setup(). There's also a
>>> still in-flight series from Gerd Hoffmann to convert over bochs. That,
>>> plus all the kerneldoc linked from there should get you started.
>>> -Daniel
>>
>> this is one of google best founds if i search for 
>> drm_fbdev_generic_setup:
>>
>> https://lkml.org/lkml/2018/12/19/305
>>
>> not very helpful...
>>
>> so i tried kernel-doc
>>
>> https://www.kernel.org/doc/html/latest/gpu/drm-kms-helpers.html?highlight=drm_fbdev_generic_setup#c.drm_fbdev_generic_setup
>>
>> which is nice function-reference but i've found no generic workflow
>>
>> as the posted driver is "only" a driver ported from kernel 4.4 by 
>> Alexander, i don't know if this new framework can be used and which 
>> parts need to be changed. I only try to bring his code Mainline
>> Maybe CK Hu can help here because driver is originally from him and he 
>> knows internals. Or maybe you can help here?
>>
>> i personally make my first steps as spare-time kernel-developer :)
>
> There's a ton of in-kernel users of that function already, I meant you can
> use those to serve as examples ... If those + the kerneldoc aren't
> good enough, then we need to improve them.
> -Daniel

 I've tried with drm_fbdev_generic_setup() and it works fine with simple
 modification. The patch is

 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
 +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
 @@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -379,6 +380,7 @@ static void mtk_drm_kms_deinit(struct drm_device
 *drm)
 .gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
 .gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
 .gem_prime_mmap = mtk_drm_gem_mmap_buf,
 +   .gem_prime_vmap = mtk_drm_gem_prime_vmap,
 .ioctls = mtk_ioctls,
 .num_ioctls = ARRAY_SIZE(mtk_ioctls),
 .fops = _drm_fops,
 @@ -416,6 +418,8 @@ static int mtk_drm_bind(struct device *dev)
 if (ret < 0)
 goto err_deinit;

 +   drm_fbdev_generic_setup(drm, 32);
 +
 return 0;


 But I implement .gem_prime_vmap with a workaround,


 --- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
 +++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
 @@ -280,3 +280,8 @@ int mtk_gem_create_ioctl(struct drm_device *dev,
 void *data,
 mtk_drm_gem_free_object(_gem->base);
 return ret;
  }
 +
 +void *mtk_drm_gem_prime_vmap(struct drm_gem_object *obj)
 +{
 +   return (void *)1;
 +}

 Current drm_fb_helper depends on drm_client to create fbdev. When
 drm_client create drm_client_buffer, it need to vmap to get kernel
 vaddr. But I think for fbdev, the vaddr is useless. Do you agree that I
 temporarily implement .gem_prime_vmap in such way?
>>>
>>> The vmap is used by fbcon, without that fbdev won't really work I think.
>>> So I'm rather confused on what you tested ...
>>>
>>> Adding Noralf, he's the expert here.
>>> -Daniel
>>
>> I test with fb_test [1], it is a user space program just open /dev/fb0
>> and mmap it to user space. I does not turn on fbcon so everything looks
>> well. If support fbcon is essential, I would implement vmap correctly.
>> If it's not essential, I think I could return 0 when
>> CONFIG_FRAMBUFFER_CONSOLE is defined.
> 
> I think fbdev emulation without working fbcon is fairly useless. And it
> shouldn't be that much work to make it work, we have quite a few more
> helers for gem bo nowadays.

If the virtual address is not set, fbcon can't be used and that means it
has to be disabled using something like this in the driver Kconfig:
depends on !FRAMEBUFFER_CONSOLE

Otherwise it will crash if someone tries to use it.

The problem here is 

Re: [Freedreno] [DPU PATCH v2 1/3] dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon 845

[Sean Paul]

On Mon, Jan 07, 2019 at 12:51:09PM -0800, Chandan Uddaraju wrote:
> Add bindings for Snapdragon 845 DisplayPort and
> display-port PLL driver.
> 
> Changes in V2:
> Provide details about sel-gpio
> 
> Signed-off-by: Chandan Uddaraju 
> ---
>  .../devicetree/bindings/display/msm/dp.txt | 249 
> +
>  .../devicetree/bindings/display/msm/dpu.txt|  16 +-
>  2 files changed, 261 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/msm/dp.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/dp.txt 
> b/Documentation/devicetree/bindings/display/msm/dp.txt
> new file mode 100644
> index 000..38be36d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dp.txt
> @@ -0,0 +1,249 @@
> +Qualcomm Technologies, Inc.
> +DP is the master Display Port device which supports DP host controllers that 
> are compatible with VESA Display Port interface specification.
> +DP Controller: Required properties:
> +- compatible:   Should be "qcom,dp-display".
> +- reg:  Base address and length of DP hardware's memory 
> mapped regions.
> +- cell-index:   Specifies the controller instance.
> +- reg-names:A list of strings that name the list of regs.
> + "dp_ahb" - DP controller memory region.
> + "dp_aux" - DP AUX memory region.
> + "dp_link" - DP link layer memory region.
> + "dp_p0" - DP pixel clock domain memory region.
> + "dp_phy" - DP PHY memory region.
> + "dp_ln_tx0" - USB3 DP PHY combo TX-0 lane memory region.
> + "dp_ln_tx1" - USB3 DP PHY combo TX-1 lane memory region.
> + "dp_mmss_cc" - Display Clock Control memory region.
> + "qfprom_physical" - QFPROM Phys memory region.
> + "dp_pll" - USB3 DP combo PLL memory region.
> + "usb3_dp_com" - USB3 DP PHY combo memory region.
> + "hdcp_physical" - DP HDCP memory region.
> +- interrupt-parent   phandle to the interrupt parent device node.
> +- interrupts:The interrupt signal from the DP block.
> +- clocks:   Clocks required for Display Port operation. See [1] 
> for details on clock bindings.
> +- clock-names:  Names of the clocks corresponding to handles. 
> Following clocks are required:
> + "core_aux_clk", 
> "core_usb_ref_clk_src","core_usb_ref_clk", "core_usb_cfg_ahb_clk",
> + "core_usb_pipe_clk", "ctrl_link_clk", 
> "ctrl_link_iface_clk", "ctrl_crypto_clk",
> + "ctrl_pixel_clk", "pixel_clk_rcg", "pixel_parent".
> +- pll-node:  phandle to DP PLL node.
> +- vdda-1p2-supply:   phandle to vdda 1.2V regulator node.
> +- vdda-0p9-supply:   phandle to vdda 0.9V regulator node.
> +- qcom,aux-cfg0-settings:Specifies the DP AUX configuration 0 
> settings. The first
> + entry in this array corresponds to the 
> register offset
> + within DP AUX, while the remaining 
> entries indicate the
> + programmable values.
> +- qcom,aux-cfg1-settings:Specifies the DP AUX configuration 1 
> settings. The first
> + entry in this array corresponds to the 
> register offset
> + within DP AUX, while the remaining 
> entries indicate the
> + programmable values.
> +- qcom,aux-cfg2-settings:Specifies the DP AUX configuration 2 
> settings. The first
> + entry in this array corresponds to the 
> register offset
> + within DP AUX, while the remaining 
> entries indicate the
> + programmable values.
> +- qcom,aux-cfg3-settings:Specifies the DP AUX configuration 3 
> settings. The first
> + entry in this array corresponds to the 
> register offset
> + within DP AUX, while the remaining 
> entries indicate the
> + programmable values.
> +- qcom,aux-cfg4-settings:Specifies the DP AUX configuration 4 
> settings. The first
> + entry in this array corresponds to the 
> register offset
> + within DP AUX, while the remaining 
> entries indicate the
> + programmable values.
> +- qcom,aux-cfg5-settings:Specifies the DP AUX configuration 5 
> settings. The first
> + entry in this array corresponds to the 
> register offset
> + within DP 

Re: [PATCH v3 08/12] drm: remove include of drmP.h from drm_modeset_helper.h

[Daniel Vetter]

On Wed, Jan 09, 2019 at 10:53:54PM +0100, Daniel Vetter wrote:
> On Tue, Jan 08, 2019 at 08:29:35PM +0100, Sam Ravnborg wrote:
> > drmP.h is an relic from the days when there was a single header file.
> > To enable the removal of drmP.h from all users drop include
> > of drmP.h from drm_modeset_helper.h.
> > 
> > A few files relied on the file included in drmP.h - add explicit
> > include statements to these files.
> > Build tested with arm and x86.
> > 
> > v2:
> > - Add forward declarations to drm_modeset_helper.h (Laurent Pinchart)
> > 
> > Signed-off-by: Sam Ravnborg 
> > Reviewed-by: Laurent Pinchart 
> > Cc: Alexey Brodkin 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Archit Taneja 
> > Cc: Andrzej Hajda 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Sean Paul 
> > Cc: Kieran Bingham 
> 
> This one here breaks tinydrm without the tinydrm patch first. I reorderd
> while applying. It also breaks kirin (and maybe more, I didn't check), so
> I've left this one out for now.

Note that I've just fixed up a large pile of these in i915 because I've
been rebasing a patch that removes lots of drm_modeset_helper.h includes.

Getting this all merged will be fun :-/
-Daniel

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/arc/arcpgu_sim.c | 1 +
> >  drivers/gpu/drm/bridge/cdns-dsi.c| 2 ++
> >  drivers/gpu/drm/drm_modeset_helper.c | 2 ++
> >  drivers/gpu/drm/rcar-du/rcar_lvds.c  | 1 +
> >  include/drm/drm_modeset_helper.h | 6 +-
> >  5 files changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c 
> > b/drivers/gpu/drm/arc/arcpgu_sim.c
> > index 68629e614990..3b7556f62230 100644
> > --- a/drivers/gpu/drm/arc/arcpgu_sim.c
> > +++ b/drivers/gpu/drm/arc/arcpgu_sim.c
> > @@ -14,6 +14,7 @@
> >   *
> >   */
> >  
> > +#include 
> >  #include 
> >  #include 
> >  
> > diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
> > b/drivers/gpu/drm/bridge/cdns-dsi.c
> > index ce9496d13986..4b73d0969468 100644
> > --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> > +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> > @@ -8,11 +8,13 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > diff --git a/drivers/gpu/drm/drm_modeset_helper.c 
> > b/drivers/gpu/drm/drm_modeset_helper.c
> > index 9150fa385bba..9bc1ef788c77 100644
> > --- a/drivers/gpu/drm/drm_modeset_helper.c
> > +++ b/drivers/gpu/drm/drm_modeset_helper.c
> > @@ -23,8 +23,10 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  /**
> >   * DOC: aux kms helpers
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index 534a128a869d..8010ed702509 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -10,6 +10,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > diff --git a/include/drm/drm_modeset_helper.h 
> > b/include/drm/drm_modeset_helper.h
> > index efa337f03129..995fd981cab0 100644
> > --- a/include/drm/drm_modeset_helper.h
> > +++ b/include/drm/drm_modeset_helper.h
> > @@ -23,7 +23,11 @@
> >  #ifndef __DRM_KMS_HELPER_H__
> >  #define __DRM_KMS_HELPER_H__
> >  
> > -#include 
> > +struct drm_crtc;
> > +struct drm_crtc_funcs;
> > +struct drm_device;
> > +struct drm_framebuffer;
> > +struct drm_mode_fb_cmd2;
> >  
> >  void drm_helper_move_panel_connectors_to_head(struct drm_device *);
> >  
> > -- 
> > 2.12.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Auto-set allow_fb_modifiers when given modifiers at plane init

[Maxime Ripard]

On Mon, Jan 07, 2019 at 11:49:16AM +0100, Daniel Vetter wrote:
> On Fri, Jan 04, 2019 at 09:56:10AM +0100, Paul Kocialkowski wrote:
> > When drivers pass non-empty lists of modifiers for initializing their
> > planes, we can infer that they allow framebuffer modifiers and set the
> > driver's allow_fb_modifiers mode config element.
> > 
> > In case the allow_fb_modifiers element was not set (some drivers tend
> > to set them after registering planes), the modifiers will still be
> > registered but won't be available to userspace unless the flag is set
> > later. However in that case, the IN_FORMATS blob won't be created.
> > 
> > In order to avoid this case and generally reduce the trouble associated
> > with the flag, always set allow_fb_modifiers when a non-empty list of
> > format modifiers is passed at plane init.
> > 
> > Signed-off-by: Paul Kocialkowski 
> 
> The automatic primary plane drm_crtc_init() creates doesn't set this, so
> looks correct in all cases.
> 
> Reviewed-by: Daniel Vetter 
> 
> (boolin.com has a bunch of drm-misc committers, so I'll leave pushing to
> them).

Applied,

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://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: [PATCH] drm/vc4: Limit SAND tiling support to semiplanar YUV420 formats

[Maxime Ripard]

On Fri, Dec 14, 2018 at 08:16:32AM -0800, Eric Anholt wrote:
> Paul Kocialkowski  writes:
> 
> > Despite what the HVS documentation indicates, the VC4 does not actually
> > support SAND tiling modes for any RGB format and only semiplanar YUV420
> > formats (NV12/NV21) can be used in these tiling modes.
> >
> > The driver currently claims to support RGB formats for the associated
> > modifiers, so remove them from the supported list in the
> > format_mod_supported helper for RGB formats.
> >
> > Remove further checks that are no longer necessary along the way, since
> > semi-planar YUV420 formats support every SAND tiling mode.
> >
> > Signed-off-by: Paul Kocialkowski 
> 
> Reviewed-by: Eric Anholt 

Applied,

Maxime


-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://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: [PATCH 6/7] drm/tda998x: Don't set dpms hook

[Noralf Trønnes]

Den 17.12.2018 20.43, skrev Daniel Vetter:
> Doesn't do anything for atomic drivers.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Russell King 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index a7c39f39793f..f8a1d70a31c7 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1122,7 +1122,6 @@ static void tda998x_connector_destroy(struct 
> drm_connector *connector)
>  }
>  
>  static const struct drm_connector_funcs tda998x_connector_funcs = {
> - .dpms = drm_helper_connector_dpms,
>   .reset = drm_atomic_helper_connector_reset,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .detect = tda998x_connector_detect,
> 

Acked-by: Noralf Trønnes 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/7] drm/arc: Don't set the dpms hook

[Noralf Trønnes]

Den 17.12.2018 20.43, skrev Daniel Vetter:
> Doesn't do anything for atomic.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Alexey Brodkin 
> ---
>  drivers/gpu/drm/arc/arcpgu_sim.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c 
> b/drivers/gpu/drm/arc/arcpgu_sim.c
> index 68629e614990..6530d88f7293 100644
> --- a/drivers/gpu/drm/arc/arcpgu_sim.c
> +++ b/drivers/gpu/drm/arc/arcpgu_sim.c
> @@ -51,7 +51,6 @@ arcpgu_drm_connector_helper_funcs = {
>  };
>  
>  static const struct drm_connector_funcs arcpgu_drm_connector_funcs = {
> - .dpms = drm_helper_connector_dpms,
>   .reset = drm_atomic_helper_connector_reset,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .destroy = arcpgu_drm_connector_destroy,
> 

Acked-by: Noralf Trønnes 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/2] drm/sched: Refactor ring mirror list handling.

[Grodzovsky, Andrey]

On 01/11/2019 04:42 AM, Koenig, Christian wrote:
> Am 10.01.19 um 16:56 schrieb Grodzovsky, Andrey:
>> [SNIP]
> But we will not be adding the cb back in drm_sched_stop anymore, now we
> are only going to add back the cb in drm_sched_startr after rerunning
> those jobs in drm_sched_resubmit_jobs and assign them a new parent
> there
> anyway.
 Yeah, but when we find that we don't need to reset anything anymore
 then adding the callbacks again won't be possible any more.

 Christian.
>>> I am not sure I understand it, can u point me to example of how this
>>> will happen ? I am attaching my latest patches with waiting only for
>>> the last job's fence here just so we are on same page regarding the code.
> Well the whole idea is to prepare all schedulers, then check once more
> if the offending job hasn't completed in the meantime.
>
> If the job completed we need to be able to rollback everything and
> continue as if nothing had happened.
>
> Christian.

Oh, but this piece of functionality - skipping HW ASIC reset in case the 
guilty job done is totally missing form this patch series and so needs 
to be added. So what you say actually is that for the case were we skip 
HW asic reset because the guilty job did complete we also need to skip  
resubmitting the jobs in drm_sched_resubmit_jobs and hence preserve the 
old parent fence pointer for reuse ? If so I would like to add all this 
functionality as a third patch since the first 2 patches are more about 
resolving race condition with jobs in flight while doing reset - what do 
you think ?

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

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

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

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

--- Comment #9 from Alex Deucher  ---
(In reply to rmuncrief from comment #8)
> (In reply to Alex Deucher from comment #7)
> > Can you bisect to figure out what commit broke things for you?
> 
> Actually I remember doing that many years ago when I was a maintainer for
> Steam under wine. I'll look and see if I can find a current bisect tutorial
> and give it a try. Any links or tips you can give to help give me a quick
> start would be appreciated. I do remember it can take many days, which I'm
> willing to invest as I said. However the fewer days the better! :)

It's pretty straight forward.  Just google for "kernel git bisect howto".

-- 
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/atomic: Add missing () to function ref in kerneldoc

[Daniel Vetter]

On Wed, Oct 24, 2018 at 11:47:31AM -0400, Lyude Paul wrote:
> Reviewed-by: Lyude Paul 

Thanks for your review, patch applied.
-Daniel

> 
> On Fri, 2018-10-12 at 09:34 +0200, Daniel Vetter wrote:
> > Pure drive-by while reading code
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  include/drm/drm_atomic.h | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> > index c09ecaf43825..627210f3ff59 100644
> > --- a/include/drm/drm_atomic.h
> > +++ b/include/drm/drm_atomic.h
> > @@ -139,9 +139,9 @@ struct drm_crtc_commit {
> > /**
> >  * @abort_completion:
> >  *
> > -* A flag that's set after drm_atomic_helper_setup_commit takes a
> > second
> > -* reference for the completion of $drm_crtc_state.event. It's used by
> > -* the free code to remove the second reference if commit fails.
> > +* A flag that's set after drm_atomic_helper_setup_commit() takes a
> > +* second reference for the completion of $drm_crtc_state.event. It's
> > +* used by the free code to remove the second reference if commit
> > fails.
> >  */
> > bool abort_completion;
> >  };
> -- 
> Cheers,
>   Lyude Paul
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/9] drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range

[Oleksandr Andrushchenko]

On 1/11/19 5:10 PM, Souptick Joarder wrote:

Convert to use vm_insert_range() to map range of kernel
memory to user vma.

Signed-off-by: Souptick Joarder 

Reviewed-by: Oleksandr Andrushchenko 

---
  drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
  1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index 47ff019..9990c2f 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -225,8 +225,7 @@ struct drm_gem_object *
  static int gem_mmap_obj(struct xen_gem_object *xen_obj,
struct vm_area_struct *vma)
  {
-   unsigned long addr = vma->vm_start;
-   int i;
+   int ret;
  
  	/*

 * clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
@@ -247,18 +246,11 @@ static int gem_mmap_obj(struct xen_gem_object *xen_obj,
 * FIXME: as we insert all the pages now then no .fault handler must
 * be called, so don't provide one
 */
-   for (i = 0; i < xen_obj->num_pages; i++) {
-   int ret;
-
-   ret = vm_insert_page(vma, addr, xen_obj->pages[i]);
-   if (ret < 0) {
-   DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
-   return ret;
-   }
+   ret = vm_insert_range(vma, xen_obj->pages, xen_obj->num_pages);
+   if (ret < 0)
+   DRM_ERROR("Failed to insert pages into vma: %d\n", ret);
  
-		addr += PAGE_SIZE;

-   }
-   return 0;
+   return ret;
  }
  
  int xen_drm_front_gem_mmap(struct file *filp, struct vm_area_struct *vma)


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

[PATCH -stable] drm/fb_helper: Allow leaking fbdev smem_start

[Maxime Ripard]

From: Neil Armstrong 

commit 4be9bd10e22dfc7fc101c5cf5969ef2d3a042d8a upstream.

Since "drm/fb: Stop leaking physical address", the default behaviour of
the DRM fbdev emulation is to set the smem_base to 0 and pass the new
FBINFO_HIDE_SMEM_START flag.

The main reason is to avoid leaking physical addresse to user-space, and
it follows a general move over the kernel code to avoid user-space to
manipulate physical addresses and then use some other mechanisms like
dma-buf to transfer physical buffer handles over multiple subsystems.

But, a lot of devices depends on closed sources binaries to enable
OpenGL hardware acceleration that uses this smem_start value to
pass physical addresses to out-of-tree modules in order to render
into these physical adresses. These should use dma-buf buffers allocated
from the DRM display device instead and stop relying on fbdev overallocation
to gather DMA memory (some HW vendors delivers GBM and Wayland capable
binaries, but older unsupported devices won't have these new binaries
and are doomed until an Open Source solution like Lima finalizes).

Since these devices heavily depends on this kind of software and because
the smem_start population was available for years, it's a breakage to
stop leaking smem_start without any alternative solutions.

This patch adds a Kconfig depending on the EXPERT config and an unsafe
kernel module parameter tainting the kernel when enabled.

A clear comment and Kconfig help text was added to clarify why and when
this patch should be reverted, but in the meantime it's a necessary
feature to keep.

Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Noralf Trønnes 
Cc: Maxime Ripard 
Cc: Eric Anholt 
Cc: Lucas Stach 
Cc: Rob Clark 
Cc: Ben Skeggs 
Cc: Christian König 
Signed-off-by: Neil Armstrong 
Reviewed-by: Maxime Ripard 
Tested-by: Maxime Ripard 
Acked-by: Daniel Vetter 
Acked-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/1538136355-15383-1-git-send-email-narmstr...@baylibre.com
Signed-off-by: Maxime Ripard 

---

Hi,

This is a backport of a patch fixing a regression introduced in 4.19, and
merged in 4.20. Therefore, it targets 4.19 only.

Thanks!
Maxime
---
 drivers/gpu/drm/Kconfig | 20 
 drivers/gpu/drm/drm_fb_helper.c | 25 +
 2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index cb88528e7b10..e44e567bd789 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -110,6 +110,26 @@ config DRM_FBDEV_OVERALLOC
  is 100. Typical values for double buffering will be 200,
  triple buffering 300.
 
+config DRM_FBDEV_LEAK_PHYS_SMEM
+   bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)"
+   depends on DRM_FBDEV_EMULATION && EXPERT
+   default n
+   help
+ In order to keep user-space compatibility, we want in certain
+ use-cases to keep leaking the fbdev physical address to the
+ user-space program handling the fbdev buffer.
+ This affects, not only, Amlogic, Allwinner or Rockchip devices
+ with ARM Mali GPUs using an userspace Blob.
+ This option is not supported by upstream developers and should be
+ removed as soon as possible and be considered as a broken and
+ legacy behaviour from a modern fbdev device driver.
+
+ Please send any bug reports when using this to your proprietary
+ software vendor that requires this.
+
+ If in doubt, say "N" or spread the word to your closed source
+ library vendor.
+
 config DRM_LOAD_EDID_FIRMWARE
bool "Allow to specify an EDID data set instead of probing for it"
depends on DRM
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9628dd617826..c52e3c80e9e6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -56,6 +56,25 @@ MODULE_PARM_DESC(drm_fbdev_overalloc,
 "Overallocation of the fbdev buffer (%) [default="
 __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
 
+/*
+ * In order to keep user-space compatibility, we want in certain use-cases
+ * to keep leaking the fbdev physical address to the user-space program
+ * handling the fbdev buffer.
+ * This is a bad habit essentially kept into closed source opengl driver
+ * that should really be moved into open-source upstream projects instead
+ * of using legacy physical addresses in user space to communicate with
+ * other out-of-tree kernel modules.
+ *
+ * This module_param *should* be removed as soon as possible and be
+ * considered as a broken and legacy behaviour from a modern fbdev device.
+ */
+#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
+static bool drm_leak_fbdev_smem = false;
+module_param_unsafe(drm_leak_fbdev_smem, bool, 0600);
+MODULE_PARM_DESC(fbdev_emulation,
+"Allow unsafe leaking fbdev physical smem address