Re: [PATCH 00/34] treewide: simplify getting the adapter of an I2C client
Hi Peter, > Similar things go on in: > > drivers/hwmon/lm90.c > drivers/leds/leds-is31fl319x.c > drivers/of/unittest.c Right. I'll fix them, too. > And drivers/rtc/rtc-fm3130.c has a couple of these: These are fixed in patch 26 of this series. Thanks and happy hacking, Wolfram signature.asc Description: PGP signature
[Bug 110871] hello
https://bugs.freedesktop.org/show_bug.cgi?id=110871 Bug ID: 110871 Summary: hello Product: DRI Version: DRI git Hardware: Other OS: Windows (All) Status: NEW Severity: normal Priority: medium Component: General Assignee: dri-devel@lists.freedesktop.org Reporter: juby.jub...@gmail.com hello bugzilla -- 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 110871] hellobugzilla
https://bugs.freedesktop.org/show_bug.cgi?id=110871 Juby changed: What|Removed |Added Summary|hello |hellobugzilla -- 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 110871] hellobugzilla
https://bugs.freedesktop.org/show_bug.cgi?id=110871 Juby changed: What|Removed |Added Status|NEW |ASSIGNED -- 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] drm: add fallback override/firmware EDID modes workaround
We've moved the override and firmware EDID (simply "override EDID" from
now on) handling to the low level drm_do_get_edid() function in order to
transparently use the override throughout the stack. The idea is that
you get the override EDID via the ->get_modes() hook.
Unfortunately, there are scenarios where the DDC probe in drm_get_edid()
called via ->get_modes() fails, although the preceding ->detect()
succeeds.
In the case reported by Paul Wise, the ->detect() hook,
intel_crt_detect(), relies on hotplug detect, bypassing the DDC. In the
case reported by Ilpo Järvinen, there is no ->detect() hook, which is
interpreted as connected. The subsequent DDC probe reached via
->get_modes() fails, and we don't even look at the override EDID,
resulting in no modes being added.
Because drm_get_edid() is used via ->detect() all over the place, we
can't trivially remove the DDC probe, as it leads to override EDID
effectively meaning connector forcing. The goal is that connector
forcing and override EDID remain orthogonal.
Generally, the underlying problem here is the conflation of ->detect()
and ->get_modes() via drm_get_edid(). The former should just detect, and
the latter should just get the modes, typically via reading the EDID. As
long as drm_get_edid() is used in ->detect(), it needs to retain the DDC
probe. Or such users need to have a separate DDC probe step first.
The EDID caching between ->detect() and ->get_modes() done by some
drivers is a further complication that prevents us from making
drm_do_get_edid() adapt to the two cases.
Work around the regression by falling back to a separate attempt at
getting the override EDID at drm_helper_probe_single_connector_modes()
level. With a working DDC and override EDID, it'll never be called; the
override EDID will come via ->get_modes(). There will still be a failing
DDC probe attempt in the cases that require the fallback.
v2:
- Call drm_connector_update_edid_property (Paul)
- Update commit message about EDID caching (Daniel)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107583
Reported-by: Paul Wise
Cc: Paul Wise
References:
alpine.DEB.2.20.1905262211270.24390@whs-18.cs.helsinki.fi">http://mid.mail-archive.com/alpine.DEB.2.20.1905262211270.24390@whs-18.cs.helsinki.fi
Reported-by: Ilpo Järvinen
Cc: Ilpo Järvinen
Suggested-by: Daniel Vetter
References: 15f080f08d48 ("drm/edid: respect connector force for drm_get_edid
ddc probe")
Fixes: 53fd40a90f3c ("drm: handle override and firmware EDID at
drm_do_get_edid() level")
Cc: # v4.15+
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Harish Chegondi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 30 ++
drivers/gpu/drm/drm_probe_helper.c | 7 +++
include/drm/drm_edid.h | 1 +
3 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c59a1e8c5ada..9d8f2b952004 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1587,6 +1587,36 @@ static struct edid *drm_get_override_edid(struct
drm_connector *connector)
return IS_ERR(override) ? NULL : override;
}
+/**
+ * drm_add_override_edid_modes - add modes from override/firmware EDID
+ * @connector: connector we're probing
+ *
+ * Add modes from the override/firmware EDID, if available. Only to be used
from
+ * drm_helper_probe_single_connector_modes() as a fallback for when DDC probe
+ * failed during drm_get_edid() and caused the override/firmware EDID to be
+ * skipped.
+ *
+ * Return: The number of modes added or 0 if we couldn't find any.
+ */
+int drm_add_override_edid_modes(struct drm_connector *connector)
+{
+ struct edid *override;
+ int num_modes = 0;
+
+ override = drm_get_override_edid(connector);
+ if (override) {
+ drm_connector_update_edid_property(connector, override);
+ num_modes = drm_add_edid_modes(connector, override);
+ kfree(override);
+
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] adding %d modes via fallback
override/firmware EDID\n",
+ connector->base.id, connector->name, num_modes);
+ }
+
+ return num_modes;
+}
+EXPORT_SYMBOL(drm_add_override_edid_modes);
+
/**
* drm_do_get_edid - get EDID data using a custom EDID block read function
* @connector: connector we're probing
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 01e243f1ea94..ef2c468205a2 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -480,6 +480,13 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
count = (*connector_funcs->get_modes)(connector);
+ /*
+* Fallback for when DDC probe failed in drm_get_edid() and thus skipped
+* override/firmware EDID.
+*/
+ if (count == 0 && connector->status == connector_status_connected)
+ count = dr
Re: [PATCH 2/2] drm: add fallback override/firmware EDID modes workaround
On Sat, 08 Jun 2019, Paul Wise wrote: > On Sat, 2019-06-08 at 13:10 +0800, Paul Wise wrote: > >> I've tested these two patches on top of Linux v5.2-rc3 and the EDID >> override works correctly on an Intel Ironlake GPU with a monitor that >> lost its EDID a while ago. > > While testing I noticed a couple of things: > > While everything the GUI is the correct resolution, GNOME is unable to > identify the monitor vendor or model. This is a regression from the > previous edid override functionality. It looks like this is because the > edid file in /sys is not populated with the EDID override data. Right, I've added a call to drm_connector_update_edid_property() in v2 to address this issue. > I got a crash due to null pointer dereference at one point, I'll try to > track down when this happens. Can't think of why this would happen; the backtrace might offer clues. Thanks for testing! BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix_dp: Convert to GPIO descriptors
Hi Linus,
On 2019-06-10 01:13, Linus Walleij wrote:
> This converts the Analogix display port to use GPIO descriptors
> instead of DT-extracted numbers.
>
> Cc: Douglas Anderson
> Cc: Sean Paul
> Cc: Marek Szyprowski
> Cc: Enric Balletbo i Serra
> Signed-off-by: Linus Walleij
Tested-by: Marek Szyprowski
although this patch doesn't apply cleanly on current linux-next.
> ---
> .../drm/bridge/analogix/analogix_dp_core.c| 28 +--
> .../drm/bridge/analogix/analogix_dp_core.h| 4 ++-
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 +-
> 3 files changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 225f5e5dd69b..64842bbb2f3d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -18,8 +18,7 @@
> #include
> #include
> #include
> -#include
> -#include
> +#include
> #include
> #include
>
> @@ -1585,12 +1584,18 @@ analogix_dp_bind(struct device *dev, struct
> drm_device *drm_dev,
>
> dp->force_hpd = of_property_read_bool(dev->of_node, "force-hpd");
>
> - dp->hpd_gpio = of_get_named_gpio(dev->of_node, "hpd-gpios", 0);
> - if (!gpio_is_valid(dp->hpd_gpio))
> - dp->hpd_gpio = of_get_named_gpio(dev->of_node,
> - "samsung,hpd-gpio", 0);
> + /* Try two different names */
> + dp->hpd_gpiod = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN);
> + if (!dp->hpd_gpiod)
> + dp->hpd_gpiod = devm_gpiod_get_optional(dev, "samsung,hpd",
> + GPIOD_IN);
> + if (IS_ERR(dp->hpd_gpiod)) {
> + dev_err(dev, "error getting HDP GPIO: %ld\n",
> + PTR_ERR(dp->hpd_gpiod));
> + return ERR_CAST(dp->hpd_gpiod);
> + }
>
> - if (gpio_is_valid(dp->hpd_gpio)) {
> + if (dp->hpd_gpiod) {
> /*
>* Set up the hotplug GPIO from the device tree as an interrupt.
>* Simply specifying a different interrupt in the device tree
> @@ -1598,16 +1603,9 @@ analogix_dp_bind(struct device *dev, struct drm_device
> *drm_dev,
>* using a GPIO. We also need the actual GPIO specifier so
>* that we can get the current state of the GPIO.
>*/
> - ret = devm_gpio_request_one(&pdev->dev, dp->hpd_gpio, GPIOF_IN,
> - "hpd_gpio");
> - if (ret) {
> - dev_err(&pdev->dev, "failed to get hpd gpio\n");
> - return ERR_PTR(ret);
> - }
> - dp->irq = gpio_to_irq(dp->hpd_gpio);
> + dp->irq = gpiod_to_irq(dp->hpd_gpiod);
> irq_flags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;
> } else {
> - dp->hpd_gpio = -ENODEV;
> dp->irq = platform_get_irq(pdev, 0);
> irq_flags = 0;
> }
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> index 769255dc6e99..dc65c2bafa63 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> @@ -38,6 +38,8 @@
> #define DPCD_VOLTAGE_SWING_SET(x) (((x) & 0x3) << 0)
> #define DPCD_VOLTAGE_SWING_GET(x) (((x) >> 0) & 0x3)
>
> +struct gpio_desc;
> +
> enum link_lane_count_type {
> LANE_COUNT1 = 1,
> LANE_COUNT2 = 2,
> @@ -171,7 +173,7 @@ struct analogix_dp_device {
> struct link_train link_train;
> struct phy *phy;
> int dpms_mode;
> - int hpd_gpio;
> + struct gpio_desc*hpd_gpiod;
> boolforce_hpd;
> boolpsr_enable;
> boolfast_train_enable;
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index a5f2763d72e4..7aab2d6d710c 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -12,7 +12,7 @@
>
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> @@ -397,7 +397,7 @@ void analogix_dp_clear_hotplug_interrupts(struct
> analogix_dp_device *dp)
> {
> u32 reg;
>
> - if (gpio_is_valid(dp->hpd_gpio))
> + if (dp->hpd_gpiod)
> return;
>
> reg = HOTPLUG_CHG | HPD_LOST | PLUG;
> @@ -411,7 +411,7 @@ void analogix_dp_init_hpd(struct analogix_dp_device *dp)
> {
> u32 reg;
>
> - if (gpio_is_valid(dp->hpd_gpio))
> + if (dp->hpd_gpiod)
> return;
>
> analogix_dp_clear_hotplug_interrupts(dp);
> @@ -434,8 +434,8 @@ enum
Re: [PATCH 2/3] drm/komeda: Add split support for scaler
On Fri, Jun 07, 2019 at 05:46:36PM +0800, Liviu Dudau wrote:
> Hi James,
>
> On Mon, May 20, 2019 at 11:44:47AM +0100, james qian wang (Arm Technology
> China) wrote:
> > To achieve same caling effect compare with none split, the texel
> > calculation need to use the same scaling ratio before split, so add
> > "total_xxx" to pipeline to describe the hsize/vsize before split.
> > Update pipeline and d71_scaler_update accordingly.
> >
> > Signed-off-by: James Qian Wang (Arm Technology China)
> >
> > ---
> > .../arm/display/komeda/d71/d71_component.c| 47 +--
> > .../drm/arm/display/komeda/komeda_pipeline.h | 19 ++--
> > .../display/komeda/komeda_pipeline_state.c| 21 -
> > .../gpu/drm/arm/display/komeda/komeda_plane.c | 8 ++--
> > .../arm/display/komeda/komeda_wb_connector.c | 2 +-
> > 5 files changed, 81 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > index 3266bd54c936..d101a5cc2766 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > @@ -642,23 +642,58 @@ static void d71_scaler_update(struct komeda_component
> > *c,
> >
> > malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize_in, st->vsize_in));
> > malidp_write32(reg, SC_OUT_SIZE, HV_SIZE(st->hsize_out, st->vsize_out));
> > + malidp_write32(reg, SC_H_CROP, HV_CROP(st->left_crop, st->right_crop));
> > +
> > + /* for right part, HW only sample the valid pixel which means the pixels
> > +* in left_crop will be jumpped, and the first sample pixel is:
> > +*
> > +* dst_a = st->total_hsize_out - st->hsize_out + st->left_crop + 0.5;
> > +*
> > +* Then the corresponding texel in src is:
> > +*
> > +* h_delta_phase = st->total_hsize_in / st->total_hsize_out;
> > +* src_a = dst_A * h_delta_phase;
> > +*
> > +* and h_init_phase is src_a deduct the real source start src_S;
> > +*
> > +* src_S = st->total_hsize_in - st->hsize_in;
> > +* h_init_phase = src_a - src_S;
> > +*
> > +* And HW precision for the initial/delta_phase is 16:16 fixed point,
> > +* the following is the simplified formula
> > +*/
> > + if (st->right_part) {
> > + u32 dst_a = st->total_hsize_out - st->hsize_out + st->left_crop;
> > +
> > + if (st->en_img_enhancement)
> > + dst_a -= 1;
> > +
> > + init_ph = ((st->total_hsize_in * (2 * dst_a + 1) -
> > + 2 * st->total_hsize_out * (st->total_hsize_in -
> > + st->hsize_in)) << 15) / st->total_hsize_out;
> > + } else {
> > + init_ph = (st->total_hsize_in << 15) / st->total_hsize_out;
> > + }
> >
> > - init_ph = (st->hsize_in << 15) / st->hsize_out;
> > malidp_write32(reg, SC_H_INIT_PH, init_ph);
> >
> > - delta_ph = (st->hsize_in << 16) / st->hsize_out;
> > + delta_ph = (st->total_hsize_in << 16) / st->total_hsize_out;
> > malidp_write32(reg, SC_H_DELTA_PH, delta_ph);
> >
> > - init_ph = (st->vsize_in << 15) / st->vsize_out;
> > + init_ph = (st->total_vsize_in << 15) / st->vsize_out;
> > malidp_write32(reg, SC_V_INIT_PH, init_ph);
> >
> > - delta_ph = (st->vsize_in << 16) / st->vsize_out;
> > + delta_ph = (st->total_vsize_in << 16) / st->vsize_out;
> > malidp_write32(reg, SC_V_DELTA_PH, delta_ph);
> >
> > ctrl = 0;
> > ctrl |= st->en_scaling ? SC_CTRL_SCL : 0;
> > ctrl |= st->en_alpha ? SC_CTRL_AP : 0;
> > ctrl |= st->en_img_enhancement ? SC_CTRL_IENH : 0;
> > + /* If we use the hardware splitter we shouldn't set SC_CTRL_LS */
> > + if (st->en_split &&
> > + state->inputs[0].component->id != KOMEDA_COMPONENT_SPLITTER)
> > + ctrl |= SC_CTRL_LS;
> >
> > malidp_write32(reg, BLK_CONTROL, ctrl);
> > malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(&state->inputs[0]));
> > @@ -716,10 +751,12 @@ static int d71_scaler_init(struct d71_dev *d71,
> > }
> >
> > scaler = to_scaler(c);
> > - set_range(&scaler->hsize, 4, d71->max_line_size);
> > + set_range(&scaler->hsize, 4, 2048);
> > set_range(&scaler->vsize, 4, 4096);
> > scaler->max_downscaling = 6;
> > scaler->max_upscaling = 64;
> > + scaler->scaling_split_overlap = 8;
> > + scaler->enh_split_overlap = 1;
> >
> > malidp_write32(c->reg, BLK_CONTROL, 0);
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > index c92733736799..4e1cf8fd89bf 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > @@ -247,15 +247,22 @@ struct komeda_scaler {
> > struct malidp_range hsize, vsize;
> > u32 max_upscaling;
> > u32 max_downscaling;
> > + u8 scaling_split_overlap; /* split overlap
[Bug 110871] hellobugzilla
https://bugs.freedesktop.org/show_bug.cgi?id=110871 Andre Klapper changed: What|Removed |Added Component|General |Two Product|DRI |Spam Status|ASSIGNED|RESOLVED Resolution|--- |INVALID Version|DRI git |unspecified Group||spam --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- 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 1/3] drm/komeda: Add component komeda_merger
Introduce a new component komeda_merger, because D71 HW supports to split
a whole image to two half parts and does the scaling independently. Merger
merges two separate results to one, and output it to compositor or wb_layer
For this patch:
- Add the definition of komeda_merger/merger_state
- Report and initialize komeda_merger according to the D71 HW.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 74 +++
.../drm/arm/display/komeda/komeda_pipeline.c | 3 +
.../drm/arm/display/komeda/komeda_pipeline.h | 18 -
.../arm/display/komeda/komeda_private_obj.c | 49
4 files changed, 143 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index c5185ce062a4..71f58bf1e880 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -767,6 +767,77 @@ static int d71_downscaling_clk_check(struct
komeda_pipeline *pipe,
0 : -EINVAL;
}
+static void d71_merger_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct komeda_merger_state *st = to_merger_st(state);
+ u32 __iomem *reg = c->reg;
+ u32 index;
+
+ for_each_changed_input(state, index)
+ malidp_write32(reg, MG_INPUT_ID0 + index * 4,
+ to_d71_input_id(&state->inputs[index]));
+
+ malidp_write32(reg, MG_SIZE, HV_SIZE(st->hsize_merged,
+st->vsize_merged));
+ malidp_write32(reg, BLK_CONTROL, BLK_CTRL_EN);
+}
+
+static void d71_merger_dump(struct komeda_component *c, struct seq_file *sf)
+{
+ u32 v;
+
+ dump_block_header(sf, c->reg);
+
+ get_values_from_reg(c->reg, MG_INPUT_ID0, 1, &v);
+ seq_printf(sf, "MG_INPUT_ID0:\t\t0x%X\n", v);
+
+ get_values_from_reg(c->reg, MG_INPUT_ID1, 1, &v);
+ seq_printf(sf, "MG_INPUT_ID1:\t\t0x%X\n", v);
+
+ get_values_from_reg(c->reg, BLK_CONTROL, 1, &v);
+ seq_printf(sf, "MG_CONTROL:\t\t0x%X\n", v);
+
+ get_values_from_reg(c->reg, MG_SIZE, 1, &v);
+ seq_printf(sf, "MG_SIZE:\t\t0x%X\n", v);
+}
+
+static const struct komeda_component_funcs d71_merger_funcs = {
+ .update = d71_merger_update,
+ .disable= d71_component_disable,
+ .dump_register = d71_merger_dump,
+};
+
+static int d71_merger_init(struct d71_dev *d71,
+ struct block_header *blk, u32 __iomem *reg)
+{
+ struct komeda_component *c;
+ struct komeda_merger *merger;
+ u32 pipe_id, comp_id;
+
+ get_resources_id(blk->block_info, &pipe_id, &comp_id);
+
+ c = komeda_component_add(&d71->pipes[pipe_id]->base, sizeof(*merger),
+comp_id,
+BLOCK_INFO_INPUT_ID(blk->block_info),
+&d71_merger_funcs,
+MG_NUM_INPUTS_IDS, get_valid_inputs(blk),
+MG_NUM_OUTPUTS_IDS, reg,
+"CU%d_MERGER", pipe_id);
+
+ if (IS_ERR(c)) {
+ DRM_ERROR("Failed to initialize merger.\n");
+ return PTR_ERR(c);
+ }
+
+ merger = to_merger(c);
+
+ set_range(&merger->hsize_merged, 4, 4032);
+ set_range(&merger->vsize_merged, 4, 4096);
+
+ return 0;
+}
+
static void d71_improc_update(struct komeda_component *c,
struct komeda_component_state *state)
{
@@ -992,7 +1063,10 @@ int d71_probe_block(struct d71_dev *d71,
break;
case D71_BLK_TYPE_CU_SPLITTER:
+ break;
+
case D71_BLK_TYPE_CU_MERGER:
+ err = d71_merger_init(d71, blk, reg);
break;
case D71_BLK_TYPE_DOU:
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index f4882c1b70d7..543ecc80703f 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -91,6 +91,9 @@ komeda_pipeline_get_component_pos(struct komeda_pipeline
*pipe, int id)
case KOMEDA_COMPONENT_SCALER1:
pos = to_cpos(pipe->scalers[id - KOMEDA_COMPONENT_SCALER0]);
break;
+ case KOMEDA_COMPONENT_MERGER:
+ pos = to_cpos(pipe->merger);
+ break;
case KOMEDA_COMPONENT_IPS0:
case KOMEDA_COMPONENT_IPS1:
temp = mdev->pipelines[id - KOMEDA_COMPONENT_IPS0];
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 1a9b2cf8061a..20e6f7a78d12 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm
[PATCH v2 2/3] drm/komeda: Add split support for scaler
To achieve same caling effect compare with none split, the texel
calculation need to use the same scaling ratio before split, so add
"total_xxx" to pipeline to describe the hsize/vsize before split.
Update pipeline and d71_scaler_update accordingly.
v2: Rebase and addressed Liviu's comments
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 47 +--
.../drm/arm/display/komeda/komeda_pipeline.h | 19 ++--
.../display/komeda/komeda_pipeline_state.c| 18 ++-
.../gpu/drm/arm/display/komeda/komeda_plane.c | 11 ++---
.../arm/display/komeda/komeda_wb_connector.c | 2 +-
5 files changed, 80 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 71f58bf1e880..c83b95b33139 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -642,23 +642,58 @@ static void d71_scaler_update(struct komeda_component *c,
malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize_in, st->vsize_in));
malidp_write32(reg, SC_OUT_SIZE, HV_SIZE(st->hsize_out, st->vsize_out));
+ malidp_write32(reg, SC_H_CROP, HV_CROP(st->left_crop, st->right_crop));
+
+ /* for right part, HW only sample the valid pixel which means the pixels
+* in left_crop will be jumpped, and the first sample pixel is:
+*
+* dst_a = st->total_hsize_out - st->hsize_out + st->left_crop + 0.5;
+*
+* Then the corresponding texel in src is:
+*
+* h_delta_phase = st->total_hsize_in / st->total_hsize_out;
+* src_a = dst_A * h_delta_phase;
+*
+* and h_init_phase is src_a deduct the real source start src_S;
+*
+* src_S = st->total_hsize_in - st->hsize_in;
+* h_init_phase = src_a - src_S;
+*
+* And HW precision for the initial/delta_phase is 16:16 fixed point,
+* the following is the simplified formula
+*/
+ if (st->right_part) {
+ u32 dst_a = st->total_hsize_out - st->hsize_out + st->left_crop;
+
+ if (st->en_img_enhancement)
+ dst_a -= 1;
+
+ init_ph = ((st->total_hsize_in * (2 * dst_a + 1) -
+ 2 * st->total_hsize_out * (st->total_hsize_in -
+ st->hsize_in)) << 15) / st->total_hsize_out;
+ } else {
+ init_ph = (st->total_hsize_in << 15) / st->total_hsize_out;
+ }
- init_ph = (st->hsize_in << 15) / st->hsize_out;
malidp_write32(reg, SC_H_INIT_PH, init_ph);
- delta_ph = (st->hsize_in << 16) / st->hsize_out;
+ delta_ph = (st->total_hsize_in << 16) / st->total_hsize_out;
malidp_write32(reg, SC_H_DELTA_PH, delta_ph);
- init_ph = (st->vsize_in << 15) / st->vsize_out;
+ init_ph = (st->total_vsize_in << 15) / st->vsize_out;
malidp_write32(reg, SC_V_INIT_PH, init_ph);
- delta_ph = (st->vsize_in << 16) / st->vsize_out;
+ delta_ph = (st->total_vsize_in << 16) / st->vsize_out;
malidp_write32(reg, SC_V_DELTA_PH, delta_ph);
ctrl = 0;
ctrl |= st->en_scaling ? SC_CTRL_SCL : 0;
ctrl |= st->en_alpha ? SC_CTRL_AP : 0;
ctrl |= st->en_img_enhancement ? SC_CTRL_IENH : 0;
+ /* If we use the hardware splitter we shouldn't set SC_CTRL_LS */
+ if (st->en_split &&
+ state->inputs[0].component->id != KOMEDA_COMPONENT_SPLITTER)
+ ctrl |= SC_CTRL_LS;
malidp_write32(reg, BLK_CONTROL, ctrl);
malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(&state->inputs[0]));
@@ -716,10 +751,12 @@ static int d71_scaler_init(struct d71_dev *d71,
}
scaler = to_scaler(c);
- set_range(&scaler->hsize, 4, d71->max_line_size);
+ set_range(&scaler->hsize, 4, 2048);
set_range(&scaler->vsize, 4, 4096);
scaler->max_downscaling = 6;
scaler->max_upscaling = 64;
+ scaler->scaling_split_overlap = 8;
+ scaler->enh_split_overlap = 1;
malidp_write32(c->reg, BLK_CONTROL, 0);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 20e6f7a78d12..857be3f64b32 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -247,15 +247,22 @@ struct komeda_scaler {
struct malidp_range hsize, vsize;
u32 max_upscaling;
u32 max_downscaling;
+ u8 scaling_split_overlap; /* split overlap for scaling */
+ u8 enh_split_overlap; /* split overlap for image enhancement */
};
struct komeda_scaler_state {
struct komeda_component_state base;
u16 hsize_in, vsize_in;
u16 hsize_out, vsize_out;
+ u16 total_hsize_in, total_vsize_in;
+ u16 total_hsize_out; /
[PATCH v2 0/3] drm/komeda: Add layer split support
This patch series add laye split support for komeda. For layer split, a plane state will be split to two data flows and handled by two separated komeda layer input pipelines. komeda supports two types of layer split: - none-scaling split: / layer-left -> \ plane_state compiz-> ... \ layer-right-> / - scaling split: / layer-left -> scaler->\ plane_state merger -> compiz-> ... \ layer-right-> scaler->/ Since merger only supports scaler as input, so for none-scaling split, two layer data flows will be output to compiz directly. for scaling_split, two data flows will be merged by merger firstly, then merger outputs one merged data flow to compiz. This patch series depends on: - https://patchwork.freedesktop.org/series/60767/ - https://patchwork.freedesktop.org/series/60838/ v2: Rebase and addressed Liviu's comments james qian wang (Arm Technology China) (3): drm/komeda: Add component komeda_merger drm/komeda: Add split support for scaler drm/komeda: Add layer split support .../arm/display/komeda/d71/d71_component.c| 121 ++- .../gpu/drm/arm/display/komeda/komeda_kms.c | 8 + .../gpu/drm/arm/display/komeda/komeda_kms.h | 22 +- .../drm/arm/display/komeda/komeda_pipeline.c | 26 +- .../drm/arm/display/komeda/komeda_pipeline.h | 49 ++- .../display/komeda/komeda_pipeline_state.c| 318 +- .../gpu/drm/arm/display/komeda/komeda_plane.c | 33 +- .../arm/display/komeda/komeda_private_obj.c | 49 +++ .../arm/display/komeda/komeda_wb_connector.c | 2 +- 9 files changed, 600 insertions(+), 28 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/komeda: Add layer split support
Komeda supports two types of layer split:
- none-scaling split
- scaling split
Since D71 merger only support scaler as input, so for none-scaling split,
the two layer dflow will be output to compiz directly. for scaling_split,
the data flow will be merged by merger firstly, then output the merged
data flow to compiz.
Komeda handles the split in kernel completely to hide the detailed and
complicated split calcualtion to user mode, for user only need to set the
layer_split property to enable/disable it.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/komeda_kms.c | 8 +
.../gpu/drm/arm/display/komeda/komeda_kms.h | 22 +-
.../drm/arm/display/komeda/komeda_pipeline.c | 23 +-
.../drm/arm/display/komeda/komeda_pipeline.h | 12 +
.../display/komeda/komeda_pipeline_state.c| 300 +-
.../gpu/drm/arm/display/komeda/komeda_plane.c | 24 +-
6 files changed, 378 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 0ec76656cd1f..5d10c55c9c40 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -173,6 +173,14 @@ static int komeda_crtc_normalize_zpos(struct drm_crtc
*crtc,
plane = plane_st->plane;
plane_st->normalized_zpos = order++;
+ /* When layer_split has been enabled, one plane will be handled
+* by two separated komeda layers (left/right), which may needs
+* two zorders.
+* - zorder: for left_layer for left display part.
+* - zorder + 1: will be reserved for right layer.
+*/
+ if (to_kplane_st(plane_st)->layer_split)
+ order++;
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] zpos:%d, normalized zpos: %d\n",
plane->base.id, plane->name,
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 5f71e669d92b..9dcfe5a01e23 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -36,6 +36,8 @@ struct komeda_plane {
/** @prop_img_enhancement: for on/off image enhancement */
struct drm_property *prop_img_enhancement;
+ /** @prop_layer_split: for on/off layer_split */
+ struct drm_property *prop_layer_split;
};
/**
@@ -50,8 +52,11 @@ struct komeda_plane_state {
/** @zlist_node: zorder list node */
struct list_head zlist_node;
- /* @img_enhancement: on/off image enhancement */
- u8 img_enhancement : 1;
+ /* @img_enhancement: on/off image enhancement
+* @layer_split: on/off layer_split
+*/
+ u8 img_enhancement : 1,
+ layer_split : 1;
};
/**
@@ -155,6 +160,19 @@ is_only_changed_connector(struct drm_crtc_state *st,
struct drm_connector *conn)
return BIT(drm_connector_index(conn)) == changed_connectors;
}
+static inline bool has_flip_h(u32 rot)
+{
+ u32 rotation = drm_rotation_simplify(rot,
+DRM_MODE_ROTATE_0 |
+DRM_MODE_ROTATE_90 |
+DRM_MODE_REFLECT_MASK);
+
+ if (rotation & DRM_MODE_ROTATE_90)
+ return !!(rotation & DRM_MODE_REFLECT_Y);
+ else
+ return !!(rotation & DRM_MODE_REFLECT_X);
+}
+
unsigned long komeda_calc_aclk(struct komeda_crtc_state *kcrtc_st);
int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms, struct komeda_dev
*mdev);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index 543ecc80703f..eb9e0c0af8f3 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -265,16 +265,35 @@ static void komeda_component_verify_inputs(struct
komeda_component *c)
}
}
+static struct komeda_layer *
+komeda_get_layer_split_right_layer(struct komeda_pipeline *pipe,
+ struct komeda_layer *left)
+{
+ int index = left->base.id - KOMEDA_COMPONENT_LAYER0;
+ int i;
+
+ for (i = index + 1; i < pipe->n_layers; i++)
+ if (left->layer_type == pipe->layers[i]->layer_type)
+ return pipe->layers[i];
+ return NULL;
+}
+
static void komeda_pipeline_assemble(struct komeda_pipeline *pipe)
{
struct komeda_component *c;
- int id;
+ struct komeda_layer *layer;
+ int i, id;
dp_for_each_set_bit(id, pipe->avail_comps) {
c = komeda_pipeline_get_component(pipe, id);
-
komeda_component_verify_inputs(c);
}
+ /* calculate right layer for the layer split */
+ for (i = 0; i < pipe-
[Bug 109607] [CI][DRMTIP] Time is passing at a different rate between IGT machines and the controller
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #13 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-kbl-7560u, fi-cfl-8109u, fi-icl-u2, fi-icl-u3: random tests - incomplete
-}
{+ fi-kbl-7560u, fi-cfl-8109u, fi-icl-u2, fi-icl-u3: random tests - incomplete
+}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_302/fi-kbl-7560u/igt@kms_vbl...@pipe-c-wait-forked-hang.html
--
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 110822] [Bisected]Booting with kernel version 5.1.0 or higher on RX 580 hangs
https://bugs.freedesktop.org/show_bug.cgi?id=110822 b6khqjq...@ugsbm.anonbox.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #13 from b6khqjq...@ugsbm.anonbox.net --- Your bug sounds like mine which came after I bought and added a used RX580 to my system. Since then had random full system freezes (I think only when I was using Firefox or the internal Steam Chromium browser) and desktop hangs where Cinnamon would crash and nothing except the mouse pointer would be movable. No error in logs at first, but then I found this after the system hanged instead of a hard freeze: $ journalctl -p3: ... Jun 09 06:45:34 test systemd-coredump[1383]: Process 1328 (Web Content) of user 1000 dumped core. Stack trace of thread 1332: #0 0x7f04ecd3ed36 n/a (/home/test/tor-browser_en-US/Browser/libxul.so) #1 0x n/a (n/a) Jun 09 06:45:35 test systemd-coredump[1374]: Process 1106 (firefox.real) of user 1000 dumped core. Stack trace of thread 1124: #0 0x7fd89155036f raise (libpthread.so.0) #1 0x7fd88b6b3a5f n/a (/home/test/tor-browser_en-US/Browser/libxul.so) Jun 09 06:45:35 test systemd-coredump[1384]: Process 1162 (Web Content) of user 1000 dumped core. Stack trace of thread 1164: #0 0x7ffb32c6ad36 n/a (/home/test/tor-browser_en-US/Browser/libxul.so) #1 0x n/a (n/a) Jun 09 06:45:38 test systemd-coredump[1385]: Process 1237 (Web Content) of user 1000 dumped core. Stack trace of thread 1241: #0 0x7f9aa7f3ed36 n/a (/home/test/tor-browser_en-US/Browser/libxul.so) #1 0x n/a (n/a) Jun 09 06:47:31 test systemd-coredump[1640]: Process 1536 (Web Content) of user 1000 dumped core. Stack trace of thread 1536: #0 0x7f830d3ee3e7 n/a (/home/test/tor-browser_en-US/Browser/libxul.so) Jun 09 06:47:32 test systemd-coredump[1650]: Process 1603 (Web Content) of user 1000 dumped core. Stack trace of thread 1606: #0 0x7f8f129ebd36 n/a (/home/test/tor-browser_en-US/Browser/libxul.so) #1 0x n/a (n/a) Jun 09 06:47:32 test systemd-coredump[1639]: Process 1410 (firefox.real) of user 1000 dumped core. Stack trace of thread 1410: #0 0x7fe94ed5f36f raise (libpthread.so.0) #1 0x7fe948ec2a5f n/a (/home/test/tor-browser_en-US/Browser/libxul.so) Jun 09 06:47:32 test systemd-coredump[1649]: Process 1467 (Web Content) of user 1000 dumped core. Stack trace of thread 1469: #0 0x7fb2790c2d36 n/a (/home/test/tor-browser_en-US/Browser/libxul.so) #1 0x n/a (n/a) ... My system: - MSI B450 Tomahawk - Athlon 200GE (yes, this CPU will be upgraded to a Ryzen 3000 one of course ;)) - RX 580 4G Nitro+ - G.Skill Aegis DIMM Kit 16GB, DDR4-3000, CL16-18-18-38 (F4-3000C16D-16GISB) My fix: 2 things I can remember I did which are maybe the fix: 1.) I disabled integrated graphics in the BIOS. 2.) I installed amd-ucode. No hangs/freezes or anything since my fix. I'll report back here should I encounter a crash/freeze/hang again. -- 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 109607] [CI][DRMTIP] Time is passing at a different rate between IGT machines and the controller
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #14 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-kbl-7560u, fi-cfl-8109u, fi-icl-u2, fi-icl-u3: random tests - incomplete
-}
{+ fi-kbl-7560u, fi-cfl-8109u, fi-icl-u2, fi-icl-u3: random tests - incomplete
+}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_302/fi-kbl-7560u/igt@kms_vbl...@pipe-a-wait-idle.html
--
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 110822] [Bisected]Booting with kernel version 5.1.0 or higher on RX 580 hangs
https://bugs.freedesktop.org/show_bug.cgi?id=110822 --- Comment #14 from b6khqjq...@ugsbm.anonbox.net --- (In reply to b6khqjqov4 from comment #13) > Your bug sounds like mine which came after I bought and added a used RX580 > to my system. Since then had random full system freezes (I think only when I > was using Firefox or the internal Steam Chromium browser) and desktop hangs > where Cinnamon would crash and nothing except the mouse pointer would be > movable. No error in logs at first, but then I found this after the system > hanged instead of a hard freeze: > > $ journalctl -p3: > > > ... > Jun 09 06:45:34 test systemd-coredump[1383]: Process 1328 (Web Content) of > user 1000 dumped core. > > Stack trace of thread 1332: > #0 0x7f04ecd3ed36 n/a > (/home/test/tor-browser_en-US/Browser/libxul.so) > #1 0x n/a (n/a) > Jun 09 06:45:35 test systemd-coredump[1374]: Process 1106 (firefox.real) of > user 1000 dumped core. > > Stack trace of thread 1124: > #0 0x7fd89155036f raise > (libpthread.so.0) > #1 0x7fd88b6b3a5f n/a > (/home/test/tor-browser_en-US/Browser/libxul.so) > Jun 09 06:45:35 test systemd-coredump[1384]: Process 1162 (Web Content) of > user 1000 dumped core. > > Stack trace of thread 1164: > #0 0x7ffb32c6ad36 n/a > (/home/test/tor-browser_en-US/Browser/libxul.so) > #1 0x n/a (n/a) > Jun 09 06:45:38 test systemd-coredump[1385]: Process 1237 (Web Content) of > user 1000 dumped core. > > Stack trace of thread 1241: > #0 0x7f9aa7f3ed36 n/a > (/home/test/tor-browser_en-US/Browser/libxul.so) > #1 0x n/a (n/a) > Jun 09 06:47:31 test systemd-coredump[1640]: Process 1536 (Web Content) of > user 1000 dumped core. > > Stack trace of thread 1536: > #0 0x7f830d3ee3e7 n/a > (/home/test/tor-browser_en-US/Browser/libxul.so) > Jun 09 06:47:32 test systemd-coredump[1650]: Process 1603 (Web Content) of > user 1000 dumped core. > > Stack trace of thread 1606: > #0 0x7f8f129ebd36 n/a > (/home/test/tor-browser_en-US/Browser/libxul.so) > #1 0x n/a (n/a) > Jun 09 06:47:32 test systemd-coredump[1639]: Process 1410 (firefox.real) of > user 1000 dumped core. > > Stack trace of thread 1410: > #0 0x7fe94ed5f36f raise > (libpthread.so.0) > #1 0x7fe948ec2a5f n/a > (/home/test/tor-browser_en-US/Browser/libxul.so) > Jun 09 06:47:32 test systemd-coredump[1649]: Process 1467 (Web Content) of > user 1000 dumped core. > > Stack trace of thread 1469: > #0 0x7fb2790c2d36 n/a > (/home/test/tor-browser_en-US/Browser/libxul.so) > #1 0x n/a (n/a) > ... > > > My system: > - MSI B450 Tomahawk > - Athlon 200GE (yes, this CPU will be upgraded to a Ryzen 3000 one of course > ;)) > - RX 580 4G Nitro+ > - G.Skill Aegis DIMM Kit 16GB, DDR4-3000, CL16-18-18-38 (F4-3000C16D-16GISB) > > My fix: 2 things I can remember I did which are maybe the fix: > 1.) I disabled integrated graphics in the BIOS. > 2.) I installed amd-ucode. > > No hangs/freezes or anything since my fix. I'll report back here should I > encounter a crash/freeze/hang again. Addition: Arch (through Antergos) with all latest updates: - $ uname: 5.1.7-arch1-1-ARCH - $ glxinfo | grep version: server glx version string: 1.4 client glx version string: 1.4 GLX version: 1.4 Max core profile version: 4.5 Max compat profile version: 4.5 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.6 OpenGL core profile shading language version string: 4.50 OpenGL version string: 4.5 (Compatibil
[Bug 110822] [Bisected]Booting with kernel version 5.1.0 or higher on RX 580 hangs
https://bugs.freedesktop.org/show_bug.cgi?id=110822 b6khqjq...@ugsbm.anonbox.net changed: What|Removed |Added Status|RESOLVED|VERIFIED -- 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 110813] Vega hang on Surviving Mars game
https://bugs.freedesktop.org/show_bug.cgi?id=110813 --- Comment #1 from Sam --- Related: https://bugs.freedesktop.org/show_bug.cgi?id=109955 https://bugs.freedesktop.org/show_bug.cgi?id=102322 This seems to be a widespread issue for Vega and 4xx/5xx owners -- 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 110813] Vega hang on Surviving Mars game
https://bugs.freedesktop.org/show_bug.cgi?id=110813 --- Comment #2 from Yury Zhuravlev --- > This seems to be a widespread issue for Vega and 4xx/5xx owners I know but looks like the trace call is different. -- 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 0/8] fix warnings for same module names
On Thu, 6 Jun 2019 at 12:11, Mauro Carvalho Chehab wrote: > > Em Thu, 6 Jun 2019 11:46:57 +0200 > Anders Roxell escreveu: > > > Hi, > > > > This patch set addresses warnings that module names are named the > > same, this may lead to a problem that wrong module gets loaded or if one > > of the two same-name modules exports a symbol, this can confuse the > > dependency resolution. and the build may fail. > > > > > > Patch "drivers: net: dsa: realtek: fix warning same module names" and > > "drivers: net: phy: realtek: fix warning same module names" resolves the > > name clatch realtek.ko. > > > > warning: same module names found: > > drivers/net/phy/realtek.ko > > drivers/net/dsa/realtek.ko > > > > > > Patch "drivers: (video|gpu): fix warning same module names" resolves > > the name clatch mxsfb.ko. > > > > warning: same module names found: > > drivers/video/fbdev/mxsfb.ko > > drivers/gpu/drm/mxsfb/mxsfb.ko > > > > Patch "drivers: media: i2c: fix warning same module names" resolves the > > name clatch adv7511.ko however, it seams to refer to the same device > > name in i2c_device_id, does anyone have any guidance how that should be > > solved? > > > > warning: same module names found: > > drivers/gpu/drm/bridge/adv7511/adv7511.ko > > drivers/media/i2c/adv7511.ko > > > > > > Patch "drivers: media: coda: fix warning same module names" resolves the > > name clatch coda.ko. > > > > warning: same module names found: > > fs/coda/coda.ko > > drivers/media/platform/coda/coda.ko > > Media change look ok, and probably the other patches too, but the > problem here is: who will apply it and when. > > The way you grouped the changes makes harder for subsystem maintainers > to pick, as the same patch touches multiple subsystems. > > On the other hand, if this gets picked by someone else, it has the > potential to cause conflicts between linux-next and the maintainer's > tree. > > So, the best would be if you re-arrange this series to submit one > patch per subsystem. I will send it per subsystem. Cheers, Anders > > > > > > > > Patch "drivers: net: phy: fix warning same module names" resolves the > > name clatch asix.ko. > > > > warning: same module names found: > > drivers/net/phy/asix.ko > > drivers/net/usb/asix.ko > > > > Patch "drivers: mfd: 88pm800: fix warning same module names" and > > "drivers: regulator: 88pm800: fix warning same module names" resolves > > the name clatch 88pm800.ko. > > > > warning: same module names found: > > drivers/regulator/88pm800.ko > > drivers/mfd/88pm800.ko > > > > > > Cheers, > > Anders > > > > Anders Roxell (8): > > drivers: net: dsa: realtek: fix warning same module names > > drivers: net: phy: realtek: fix warning same module names > > drivers: (video|gpu): fix warning same module names > > drivers: media: i2c: fix warning same module names > > drivers: media: coda: fix warning same module names > > drivers: net: phy: fix warning same module names > > drivers: mfd: 88pm800: fix warning same module names > > drivers: regulator: 88pm800: fix warning same module names > > > > drivers/gpu/drm/bridge/adv7511/Makefile | 10 +- > > drivers/gpu/drm/mxsfb/Makefile | 4 ++-- > > drivers/media/i2c/Makefile | 3 ++- > > drivers/media/platform/coda/Makefile| 4 ++-- > > drivers/mfd/Makefile| 7 +-- > > drivers/net/dsa/Makefile| 4 ++-- > > drivers/net/phy/Makefile| 6 -- > > drivers/regulator/Makefile | 3 ++- > > drivers/video/fbdev/Makefile| 3 ++- > > 9 files changed, 26 insertions(+), 18 deletions(-) > > > > > > Thanks, > Mauro
Re: [PATCH 8/8] drivers: regulator: 88pm800: fix warning same module names
On Thu, 6 Jun 2019 at 13:00, Mark Brown wrote: > > On Thu, Jun 06, 2019 at 11:47:36AM +0200, Anders Roxell wrote: > > > obj-$(CONFIG_REGULATOR_88PG86X) += 88pg86x.o > > -obj-$(CONFIG_REGULATOR_88PM800) += 88pm800.o > > +obj-$(CONFIG_REGULATOR_88PM800) += 88pm800-regulator.o > > +88pm800-regulator-objs := 88pm800.o > > Don't do this, no need for this driver to look different to all the > others in the Makefile - just rename the whole file. Thank you for your review, I'll rework and resend v2 shortly. Cheers, Anders
[Bug 110883] [Regression linux 5.2-rc4][bisected] hang on boot
https://bugs.freedesktop.org/show_bug.cgi?id=110883 Bug ID: 110883 Summary: [Regression linux 5.2-rc4][bisected] hang on boot Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: freedesk...@sibrenvasse.nl Created attachment 144491 --> https://bugs.freedesktop.org/attachment.cgi?id=144491&action=edit bisect log Laptop Hardware: Model: HP EliteBook 8570w GPU: Chelsea XT GL [FirePro M4000] relevant kernel command line: amdgpu.si_support=1 amdgpu.dc=1 radeon.si_support=0 After upgrading from 5.2-rc3 to 5.2-rc4 laptop hangs during boot. (Xorg does not start and I'm unable to switch to a TTY) --- Jun 10 12:36:32 hostname kernel: amdgpu :01:00.0: amdgpu_device_ip_init failed Jun 10 12:36:32 hostname kernel: amdgpu :01:00.0: Fatal error during GPU init Jun 10 12:36:32 hostname kernel: [drm] amdgpu: finishing device. Jun 10 12:36:32 hostname kernel: [drm] amdgpu atom LVDS backlight unloaded Jun 10 12:36:32 hostname kernel: [ cut here ] Jun 10 12:36:32 hostname kernel: Memory manager not clean during takedown. Jun 10 12:36:32 hostname kernel: WARNING: CPU: 1 PID: 226 at drivers/gpu/drm/drm_mm.c:939 drm_mm_takedown+0x1f/0x30 [drm] Jun 10 12:36:32 hostname kernel: Modules linked in: amdgpu(+) amd_iommu_v2 gpu_sched i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpgart Jun 10 12:36:32 hostname kernel: CPU: 1 PID: 226 Comm: modprobe Not tainted 5.2.0-rc4-mainline #6 Jun 10 12:36:32 hostname kernel: Hardware name: Hewlett-Packard HP EliteBook 8570w/176B, BIOS 68IAV Ver. F.70 07/30/2018 Jun 10 12:36:32 hostname kernel: RIP: 0010:drm_mm_takedown+0x1f/0x30 [drm] Jun 10 12:36:32 hostname kernel: Code: c4 ce d1 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 38 48 83 c7 38 48 39 c7 75 01 c3 48 c7 c7 48 ad 1d c0 e8 9b c7 ce d1 <0f> 0b c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 Jun 10 12:36:32 hostname kernel: RSP: 0018:b846c1cc7990 EFLAGS: 00010286 Jun 10 12:36:32 hostname kernel: RAX: RBX: 92bb29eb4060 RCX: Jun 10 12:36:32 hostname kernel: RDX: RSI: 0082 RDI: Jun 10 12:36:32 hostname kernel: RBP: 92bb29eb41f0 R08: 02ae R09: 0001 Jun 10 12:36:32 hostname kernel: R10: R11: 0001 R12: 92bb2b104f00 Jun 10 12:36:32 hostname kernel: R13: 92bb2b104fe8 R14: 0170 R15: 92bb29ce1020 Jun 10 12:36:32 hostname kernel: FS: 7f6a1ec00740() GS:92bb2da4() knlGS: Jun 10 12:36:32 hostname kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 10 12:36:32 hostname kernel: CR2: 7ffe870f1fc0 CR3: 000429ec6003 CR4: 001606e0 Jun 10 12:36:32 hostname kernel: Call Trace: Jun 10 12:36:32 hostname kernel: amdgpu_vram_mgr_fini+0x2d/0xa0 [amdgpu] Jun 10 12:36:32 hostname kernel: ttm_bo_clean_mm+0xa9/0xb0 [ttm] Jun 10 12:36:32 hostname kernel: amdgpu_ttm_fini+0x71/0xd0 [amdgpu] Jun 10 12:36:32 hostname kernel: amdgpu_bo_fini+0xe/0x30 [amdgpu] Jun 10 12:36:32 hostname kernel: gmc_v6_0_sw_fini+0x26/0x50 [amdgpu] Jun 10 12:36:32 hostname kernel: amdgpu_device_fini+0x257/0x43d [amdgpu] Jun 10 12:36:32 hostname kernel: amdgpu_driver_unload_kms+0xb2/0x150 [amdgpu] Jun 10 12:36:32 hostname kernel: amdgpu_driver_load_kms.cold.2+0x5a/0xc4 [amdgpu] Jun 10 12:36:32 hostname kernel: drm_dev_register+0x10d/0x150 [drm] Jun 10 12:36:32 hostname kernel: amdgpu_pci_probe+0xcb/0x130 [amdgpu] Jun 10 12:36:32 hostname kernel: ? _raw_spin_unlock_irqrestore+0x20/0x40 Jun 10 12:36:32 hostname kernel: local_pci_probe+0x42/0x80 Jun 10 12:36:32 hostname kernel: ? pci_match_device+0xc5/0x100 Jun 10 12:36:32 hostname kernel: pci_device_probe+0x112/0x190 Jun 10 12:36:32 hostname kernel: really_probe+0xef/0x390 Jun 10 12:36:32 hostname kernel: driver_probe_device+0xb4/0x100 Jun 10 12:36:32 hostname kernel: device_driver_attach+0x4f/0x60 Jun 10 12:36:32 hostname kernel: __driver_attach+0x86/0x140 Jun 10 12:36:32 hostname kernel: ? device_driver_attach+0x60/0x60 Jun 10 12:36:32 hostname kernel: ? device_driver_attach+0x60/0x60 Jun 10 12:36:32 hostname kernel: bus_for_each_dev+0x77/0xc0 Jun 10 12:36:32 hostname kernel: bus_add_driver+0x14a/0x1e0 Jun 10 12:36:32 hostname kernel: ? 0xc0694000 Jun 10 12:36:32 hostname kernel: driver_register+0x6b/0xb0 Jun 10 12:36:32 hostname kernel: ? 0xc0694000 Jun 10 12:36:32 hostname kernel: do_one_initcall+0x46/0x224 Jun 10 12:36:32 hostname kernel: ? kmem_cache_alloc_trace+0x33/0x1c0 Jun 10 12:36:32 hostname kernel: ? do_init_module+0x22/0x220 Jun 10 12:36:32 hostname kernel: do_init_module+0x5a/0x220 Jun 10 12:36:32 hostname
[Bug 110883] [Regression linux 5.2-rc4][bisected] hang on boot
https://bugs.freedesktop.org/show_bug.cgi?id=110883 --- Comment #1 from Sibren Vasse --- Created attachment 144492 --> https://bugs.freedesktop.org/attachment.cgi?id=144492&action=edit dmesg -- 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 5/8] drivers: media: coda: fix warning same module names
On Thu, 6 Jun 2019 at 12:13, Hans Verkuil wrote: > > On 6/6/19 11:47 AM, Anders Roxell wrote: > > When building with CONFIG_VIDEO_CODA and CONFIG_CODA_FS enabled as > > loadable modules, we see the following warning: > > > > warning: same module names found: > > fs/coda/coda.ko > > drivers/media/platform/coda/coda.ko > > > > Rework so media coda matches the config fragment. Leaving CODA_FS as is > > since thats a well known module. > > > > Signed-off-by: Anders Roxell > > --- > > drivers/media/platform/coda/Makefile | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/platform/coda/Makefile > > b/drivers/media/platform/coda/Makefile > > index 54e9a73a92ab..588e6bf7c190 100644 > > --- a/drivers/media/platform/coda/Makefile > > +++ b/drivers/media/platform/coda/Makefile > > @@ -1,6 +1,6 @@ > > # SPDX-License-Identifier: GPL-2.0-only > > > > -coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-mpeg2.o > > coda-mpeg4.o coda-jpeg.o > > +video-coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o > > coda-mpeg2.o coda-mpeg4.o coda-jpeg.o > > > > -obj-$(CONFIG_VIDEO_CODA) += coda.o > > +obj-$(CONFIG_VIDEO_CODA) += video-coda.o > > How about imx-coda? video-coda suggests it is part of the video subsystem, > which it isn't. I'll resend a v2 shortly with imx-coda instead. Cheers, Anders > > Regards, > > Hans > > > obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o > > >
[Bug 110883] [Regression linux 5.2-rc4][bisected] hang on boot
https://bugs.freedesktop.org/show_bug.cgi?id=110883 --- Comment #2 from Sibren Vasse --- Created attachment 144493 --> https://bugs.freedesktop.org/attachment.cgi?id=144493&action=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
[PATCH v5] drm/vc4: fix fb references in async update
commit c16b85559dcfb5a348cc085a7b4c75ed49b05e2c upstream.
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().
Cc: # v4.19+
Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic")
Suggested-by: Boris Brezillon
Signed-off-by: Helen Koike
Reviewed-by: Boris Brezillon
Signed-off-by: Boris Brezillon
Link:
https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-5-helen.ko...@collabora.com
---
Hi,
This patch failed to apply on kernel stable v4.19, I'm re-sending it
fixing the conflict.
Thanks
Helen
drivers/gpu/drm/vc4/vc4_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index ab39315c9078..39e608271263 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -818,6 +818,7 @@ static void vc4_plane_atomic_async_update(struct drm_plane
*plane,
drm_atomic_set_fb_for_plane(plane->state, state->fb);
}
+ swap(plane->state->fb, state->fb);
/* Set the cursor's position on the screen. This is the
* expected change from the drm_mode_cursor_universal()
* helper.
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: Add AArch64 page table format support
On Wed, May 29, 2019 at 10:38 AM Tomeu Vizoso wrote: > > On Wed, 29 May 2019 at 15:00, Robin Murphy wrote: > > > > Hi Tomeu, Rob, > > > > On 28/05/2019 08:03, Tomeu Vizoso wrote: > > > Robin, Steven, > > > > > > would you or someone else at Arm be able to run the IGT tests [0] on > > > 5.2-rc2 with this patch on top? > > > > > > I don't have any hw with Bifrost and am not planning to work on the > > > userspace any time soon, but I think it would be good to at least > > > check that the kernel doesn't have any obvious bugs. > > > > I've managed to cobble something together which appears to sort-of-work, > > although I don't have the knowledge, time or patience to dive down the > > rabbit-hole of getting a working Arm DDK driver to actually prove the > > setup. The immediate observation is that I get a lot of this: > > > > [ 305.602001] panfrost 6e00.gpu: error powering up gpu > > > > Which appears to stem from the poking of STACK_PWRON_LO. Judging by > > CONFIG_MALI_CORESTACK in kbase, maybe we shouldn't always be going there > > anyway (Steve probably knows more, but is away for a few weeks ATM). > > > > I can't make much sense of the IGT output, but trying > > "scripts/run-tests.sh -t panfrost" (because I also don't have the > > patience to watch it skip through all ~63,000 tests...) seems pretty > > much consistent with or without this patch. > > Oops, sorry about that. It would have been sufficient to directly run > these executables: > > tests/panfrost_gem_new > tests/panfrost_get_param > tests/panfrost_prime > tests/panfrost_submit > > > Same for trying kmscube with > > mesa/master; that produces lots of job errors: > > > > [ 42.409568] panfrost 6e00.gpu: js fault, js=0, > > status=DATA_INVALID_FAULT, head=0x2400b00, tail=0x2400b00 > > [ 42.419380] panfrost 6e00.gpu: gpu sched timeout, js=0, > > status=0x58, head=0x2400b00, tail=0x2400b00, sched_job=d17b91 > > > > rather than MMU faults either way, so at least this change doesn't seem > > to present any significant regression. > > That sounds pretty good to me. We know that the cmdstream and compiler > aren't ready yet for Bifrost. > > > It looks like without this patch > > we end up using AS_TRANSCFG_ADRMODE_LEGACY, which presumably means > > exactly what it sounds like, although whether that's sufficiently > > reliable I don't know; those kinds of backwards-compatibility features > > do have a habit of eventually disappearing, and what I've tried so far > > is certainly not the latest and greatest. > > One for Rob when he's back, I think :) I wouldn't have expected AS_TRANSCFG_ADRMODE_LEGACY to work and if it did it was by chance. So I don't think it is something we want to support. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] drivers: media: coda: fix warning same module names
On 10/06/2019 14:03, Anders Roxell wrote: > On Thu, 6 Jun 2019 at 12:13, Hans Verkuil wrote: >> >> On 6/6/19 11:47 AM, Anders Roxell wrote: >>> When building with CONFIG_VIDEO_CODA and CONFIG_CODA_FS enabled as >>> loadable modules, we see the following warning: >>> >>> warning: same module names found: >>>fs/coda/coda.ko >>>drivers/media/platform/coda/coda.ko >>> >>> Rework so media coda matches the config fragment. Leaving CODA_FS as is >>> since thats a well known module. >>> >>> Signed-off-by: Anders Roxell >>> --- >>> drivers/media/platform/coda/Makefile | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/media/platform/coda/Makefile >>> b/drivers/media/platform/coda/Makefile >>> index 54e9a73a92ab..588e6bf7c190 100644 >>> --- a/drivers/media/platform/coda/Makefile >>> +++ b/drivers/media/platform/coda/Makefile >>> @@ -1,6 +1,6 @@ >>> # SPDX-License-Identifier: GPL-2.0-only >>> >>> -coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-mpeg2.o >>> coda-mpeg4.o coda-jpeg.o >>> +video-coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o >>> coda-mpeg2.o coda-mpeg4.o coda-jpeg.o >>> >>> -obj-$(CONFIG_VIDEO_CODA) += coda.o >>> +obj-$(CONFIG_VIDEO_CODA) += video-coda.o >> >> How about imx-coda? video-coda suggests it is part of the video subsystem, >> which it isn't. > > I'll resend a v2 shortly with imx-coda instead. What about other vendor SoCs implementing the Coda IP block which are not an imx? I'd prefer a more generic name - maybe media-coda. Thanks, Matt > > > Cheers, > Anders > >> >> Regards, >> >> Hans >> >>> obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o >>> >>
RE: [PATCH] drm: remove the newline for CRC source name.
Hi Sam, Thanks for the good catch. Actually it's a typo in email reply. It should be 'len - 1'. Regards, -Original Message- From: Sam Ravnborg Sent: Saturday, June 8, 2019 7:56 AM To: Zhang, Dingchen (David) Cc: dri-devel@lists.freedesktop.org; Li, Sun peng (Leo) ; Wentland, Harry Subject: Re: [PATCH] drm: remove the newline for CRC source name. Hi Dingchen. Patch is much better now. On Fri, Jun 07, 2019 at 05:38:17PM -0400, Dingchen Zhang wrote: > userspace may transfer a newline, and this terminating newline is > replaced by a '\0' to avoid followup issues. > > 'n-1' is the index to replace the newline of CRC source name. I am a little confused where 'n' comes from here? I you had written ' len - 1' then there was a clear connection to the patch. With this fixed: Reviewed-by: Sam Ravnborg > > v2: update patch subject, body and format. (Sam) > > Cc: Leo Li > Cc: Harry Wentland > Cc: Sam Ravnborg > Signed-off-by: Dingchen Zhang > --- > drivers/gpu/drm/drm_debugfs_crc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c > b/drivers/gpu/drm/drm_debugfs_crc.c > index 585169f0dcc5..dac267e840af 100644 > --- a/drivers/gpu/drm/drm_debugfs_crc.c > +++ b/drivers/gpu/drm/drm_debugfs_crc.c > @@ -131,8 +131,8 @@ static ssize_t crc_control_write(struct file *file, const > char __user *ubuf, > if (IS_ERR(source)) > return PTR_ERR(source); > > - if (source[len] == '\n') > - source[len] = '\0'; > + if (source[len - 1] == '\n') > + source[len - 1] = '\0'; > > ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt); > if (ret) > -- > 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support
On Wed, 29 May 2019 at 19:38, Robin Murphy wrote:
>
> On 29/05/2019 16:09, Tomeu Vizoso wrote:
> > On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
> >>
> > [snip]
> >> [ 345.204813] panfrost 180.gpu: mmu irq status=1
> >> [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA
> >> 0x02400400
> >
> > From what I can see here, 0x02400400 points to the first byte
> > of the first submitted job descriptor.
> >
> > So mapping buffers for the GPU doesn't seem to be working at all on
> > 64-bit T-760.
> >
> > Steven, Robin, do you have any idea of why this could be?
>
> I tried rolling back to the old panfrost/nondrm shim, and it works fine
> with kbase, and I also found that T-820 falls over in the exact same
> manner, so the fact that it seemed to be common to the smaller 33-bit
> designs rather than anything to do with the other
> job_descriptor_size/v4/v5 complication turned out to be telling.
>
> [ as an aside, are 64-bit jobs actually known not to work on v4 GPUs, or
> is it just that nobody's yet observed a 64-bit blob driving one? ]
Do you know if 64-bit descriptors work on v4 GPUs with our kernel
driver but with the DDK?
Wonder if there something else to be fixed in the kernel for that scenario.
Thanks,
Tomeu
> Long story short, it appears that 'Mali LPAE' is also lacking the start
> level notion of VMSA, and expects a full 4-level table even for <40 bits
> when level 0 effectively redundant. Thus walking the 3-level table that
> io-pgtable comes back with ends up going wildly wrong. The hack below
> seems to do the job for me; if Clément can confirm (on T-720 you'll
> still need the userspace hack to force 32-bit jobs as well) then I think
> I'll cook up a proper refactoring of the allocator to put things right.
>
> Robin.
>
>
> ->8-
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 546968d8a349..f29da6e8dc08 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -1023,12 +1023,14 @@ arm_mali_lpae_alloc_pgtable(struct
> io_pgtable_cfg *cfg, void *cookie)
> iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie);
> if (iop) {
> u64 mair, ttbr;
> + struct arm_lpae_io_pgtable *data =
> io_pgtable_ops_to_data(&iop->ops);
>
> + data->levels = 4;
> /* Copy values as union fields overlap */
> mair = cfg->arm_lpae_s1_cfg.mair[0];
> ttbr = cfg->arm_lpae_s1_cfg.ttbr[0];
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: don't block fb changes for async plane updates
commit 89a4aac0ab0e6f5eea10d7bf4869dd15c3de2cd4 upstream.
In the case of a normal sync update, the preparation of framebuffers (be
it calling drm_atomic_helper_prepare_planes() or doing setups with
drm_framebuffer_get()) are performed in the new_state and the respective
cleanups are performed in the old_state.
In the case of async updates, the preparation is also done in the
new_state but the cleanups are done in the new_state (because updates
are performed in place, i.e. in the current state).
The current code blocks async udpates when the fb is changed, turning
async updates into sync updates, slowing down cursor updates and
introducing regressions in igt tests with errors of type:
"CRITICAL: completed 97 cursor updated in a period of 30 flips, we
expect to complete approximately 15360 updates, with the threshold set
at 7680"
Fb changes in async updates were prevented to avoid the following scenario:
- Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)
Where we have a single call to prepare fb2 but double cleanup call to fb2.
To solve the above problems, instead of blocking async fb changes, we
place the old framebuffer in the new_state object, so when the code
performs cleanups in the new_state it will cleanup the old_fb and we
will have the following scenario instead:
- Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
Where calls to prepare/cleanup are balanced.
Cc: # v4.14+
Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
Suggested-by: Boris Brezillon
Signed-off-by: Helen Koike
Reviewed-by: Boris Brezillon
Reviewed-by: Nicholas Kazlauskas
Signed-off-by: Boris Brezillon
Link:
https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-6-helen.ko...@collabora.com
---
Hi,
This patch failed to apply on kernel stable v4.14, I'm re-sending it
fixing the conflict.
Thanks
Helen
drivers/gpu/drm/drm_atomic_helper.c | 10 ++
include/drm/drm_modeset_helper_vtables.h | 8
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d05ed0521e20..331478bd2ff8 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1462,6 +1462,8 @@ EXPORT_SYMBOL(drm_atomic_helper_async_check);
* drm_atomic_async_check() succeeds. Async commits are not supposed to swap
* the states like normal sync commits, but just do in-place changes on the
* current state.
+ *
+ * TODO: Implement full swap instead of doing in-place changes.
*/
void drm_atomic_helper_async_commit(struct drm_device *dev,
struct drm_atomic_state *state)
@@ -1472,8 +1474,16 @@ void drm_atomic_helper_async_commit(struct drm_device
*dev,
int i;
for_each_new_plane_in_state(state, plane, plane_state, i) {
+ struct drm_framebuffer *old_fb = plane->state->fb;
+
funcs = plane->helper_private;
funcs->atomic_async_update(plane, plane_state);
+
+ /*
+* Make sure the FBs have been swapped so that cleanups in the
+* new_state performs a cleanup in the old FB.
+*/
+ WARN_ON_ONCE(plane_state->fb != old_fb);
}
}
EXPORT_SYMBOL(drm_atomic_helper_async_commit);
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index c55cf3ff6847..2f6d0f3ae985 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -1159,6 +1159,14 @@ struct drm_plane_helper_funcs {
* current one with the new plane configurations in the new
* plane_state.
*
+* Drivers should also swap the framebuffers between current plane
+* state (&drm_plane.state) and new_state.
+* This is required since cleanup for async commits is performed on
+* the new state, rather than old state like for traditional commits.
+* Since we want to give up the reference on the current (old) fb
+* instead of our brand new one, swap them in the driver during the
+* async commit.
+*
* FIXME:
* - It only works for single plane updates
* - Async Pageflips are not supported yet
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/vc4: fix fb references in async update
On 6/10/19 10:18 AM, Helen Koike wrote:
> commit c16b85559dcfb5a348cc085a7b4c75ed49b05e2c upstream.
>
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
>
> Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
> fb and put the old fb) is not required, as it's taken care by
> drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().
>
> Cc: # v4.19+
> Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic")
> Suggested-by: Boris Brezillon
> Signed-off-by: Helen Koike
> Reviewed-by: Boris Brezillon
> Signed-off-by: Boris Brezillon
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-5-helen.ko...@collabora.com
> ---
>
> Hi,
>
> This patch failed to apply on kernel stable v4.19, I'm re-sending it
> fixing the conflict.
fyi, this patch was already applied in other stable branches.
Thanks
Helen
>
> Thanks
> Helen
>
> drivers/gpu/drm/vc4/vc4_plane.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index ab39315c9078..39e608271263 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -818,6 +818,7 @@ static void vc4_plane_atomic_async_update(struct
> drm_plane *plane,
> drm_atomic_set_fb_for_plane(plane->state, state->fb);
> }
>
> + swap(plane->state->fb, state->fb);
> /* Set the cursor's position on the screen. This is the
>* expected change from the drm_mode_cursor_universal()
>* helper.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: don't block fb changes for async plane updates
Hi,
Correcting the tag, just for the record, is v5 of the patch.
On 6/10/19 10:36 AM, Helen Koike wrote:
> commit 89a4aac0ab0e6f5eea10d7bf4869dd15c3de2cd4 upstream.
>
> In the case of a normal sync update, the preparation of framebuffers (be
> it calling drm_atomic_helper_prepare_planes() or doing setups with
> drm_framebuffer_get()) are performed in the new_state and the respective
> cleanups are performed in the old_state.
>
> In the case of async updates, the preparation is also done in the
> new_state but the cleanups are done in the new_state (because updates
> are performed in place, i.e. in the current state).
>
> The current code blocks async udpates when the fb is changed, turning
> async updates into sync updates, slowing down cursor updates and
> introducing regressions in igt tests with errors of type:
>
> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
> expect to complete approximately 15360 updates, with the threshold set
> at 7680"
>
> Fb changes in async updates were prevented to avoid the following scenario:
>
> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)
> Where we have a single call to prepare fb2 but double cleanup call to fb2.
>
> To solve the above problems, instead of blocking async fb changes, we
> place the old framebuffer in the new_state object, so when the code
> performs cleanups in the new_state it will cleanup the old_fb and we
> will have the following scenario instead:
>
> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
>
> Where calls to prepare/cleanup are balanced.
>
> Cc: # v4.14+
> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
> Suggested-by: Boris Brezillon
> Signed-off-by: Helen Koike
> Reviewed-by: Boris Brezillon
> Reviewed-by: Nicholas Kazlauskas
> Signed-off-by: Boris Brezillon
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-6-helen.ko...@collabora.com
> ---
>
> Hi,
>
> This patch failed to apply on kernel stable v4.14, I'm re-sending it
> fixing the conflict.
fyi, this patch was already applied in other stable branches.
Thanks
Helen
>
> Thanks
> Helen
>
> drivers/gpu/drm/drm_atomic_helper.c | 10 ++
> include/drm/drm_modeset_helper_vtables.h | 8
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index d05ed0521e20..331478bd2ff8 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1462,6 +1462,8 @@ EXPORT_SYMBOL(drm_atomic_helper_async_check);
> * drm_atomic_async_check() succeeds. Async commits are not supposed to swap
> * the states like normal sync commits, but just do in-place changes on the
> * current state.
> + *
> + * TODO: Implement full swap instead of doing in-place changes.
> */
> void drm_atomic_helper_async_commit(struct drm_device *dev,
> struct drm_atomic_state *state)
> @@ -1472,8 +1474,16 @@ void drm_atomic_helper_async_commit(struct drm_device
> *dev,
> int i;
>
> for_each_new_plane_in_state(state, plane, plane_state, i) {
> + struct drm_framebuffer *old_fb = plane->state->fb;
> +
> funcs = plane->helper_private;
> funcs->atomic_async_update(plane, plane_state);
> +
> + /*
> + * Make sure the FBs have been swapped so that cleanups in the
> + * new_state performs a cleanup in the old FB.
> + */
> + WARN_ON_ONCE(plane_state->fb != old_fb);
> }
> }
> EXPORT_SYMBOL(drm_atomic_helper_async_commit);
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index c55cf3ff6847..2f6d0f3ae985 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1159,6 +1159,14 @@ struct drm_plane_helper_funcs {
>* current one with the new plane configurations in the new
>* plane_state.
>*
> + * Drivers should also swap the framebuffers between current plane
> + * state (&drm_plane.state) and new_state.
> + * This is required since cleanup for async commits is performed on
> + * the new state, rather than old state like for traditional commits.
> + * Since we want to give up the reference on the current (old) fb
> + * instead of our brand new one, swap them in the driver during the
> + * async commit.
> + *
>* FIXME:
>* - It only works for single plane updates
>* - Async Pageflips are not supported yet
>
_
[PATCH 2/2] drm/bridge: tfp410: fix use of cancel_delayed_work_sync
We use delayed_work in HPD handling, and cancel any scheduled work in
tfp410_fini using cancel_delayed_work_sync(). However, we have only
initialized the delayed work if we actually have a HPD interrupt
configured in the DT, but in the tfp410_fini, we always cancel the work,
possibly causing a WARN().
Fix this by doing the cancel only if we actually had the delayed work
set up.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/ti-tfp410.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index 9f0836cc712b..07b695172db2 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -381,7 +381,8 @@ static int tfp410_fini(struct device *dev)
{
struct tfp410 *dvi = dev_get_drvdata(dev);
- cancel_delayed_work_sync(&dvi->hpd_work);
+ if (dvi->hpd_irq >= 0)
+ cancel_delayed_work_sync(&dvi->hpd_work);
drm_bridge_remove(&dvi->bridge);
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/bridge: tfp410: fix memleak in get_modes()
We don't free the edid blob allocated by the call to drm_get_edid(), causing a memleak. Fix this by calling kfree(edid) at the end of the get_modes(). Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/bridge/ti-tfp410.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c index 8b0e71bd3ca7..9f0836cc712b 100644 --- a/drivers/gpu/drm/bridge/ti-tfp410.c +++ b/drivers/gpu/drm/bridge/ti-tfp410.c @@ -70,7 +70,12 @@ static int tfp410_get_modes(struct drm_connector *connector) drm_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + ret = drm_add_edid_modes(connector, edid); + + kfree(edid); + + return ret; + fallback: /* No EDID, fallback on the XGA standard modes */ ret = drm_add_modes_noedid(connector, 1920, 1200); -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: remove the newline for CRC source name.
userspace may transfer a newline, and this terminating newline is replaced by a '\0' to avoid followup issues. 'len-1' is the index to replace the newline of CRC source name. v3: typo fix (Sam) v2: update patch subject, body and format. (Sam) Cc: Leo Li Cc: Harry Wentland Cc: Sam Ravnborg Signed-off-by: Dingchen Zhang --- drivers/gpu/drm/drm_debugfs_crc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c index 585169f0dcc5..dac267e840af 100644 --- a/drivers/gpu/drm/drm_debugfs_crc.c +++ b/drivers/gpu/drm/drm_debugfs_crc.c @@ -131,8 +131,8 @@ static ssize_t crc_control_write(struct file *file, const char __user *ubuf, if (IS_ERR(source)) return PTR_ERR(source); - if (source[len] == '\n') - source[len] = '\0'; + if (source[len - 1] == '\n') + source[len - 1] = '\0'; ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt); if (ret) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/panfrost: Add a module parameter to expose unstable ioctls
+Daniel and David
On Wed, May 29, 2019 at 3:52 AM Boris Brezillon
wrote:
>
> We plan to expose performance counters through 2 driver specific
> ioctls until there's a solution to expose them in a generic way.
> In order to be able to deprecate those ioctls when this new
> infrastructure is in place we add an unsafe module parameter that
> will keep those ioctls hidden unless it's set to true (which also
> has the effect of tainting the kernel).
>
> All unstable ioctl handlers should use panfrost_unstable_ioctl_check()
> to check whether they're supposed to handle the request or reject it
> with ENOSYS.
>
> Suggested-by: Emil Velikov
> Signed-off-by: Boris Brezillon
Daniel, David, Any issues with this approach for an unstable interface?
> ---
> Chnages in v3:
> * New patch
> ---
> drivers/gpu/drm/panfrost/panfrost_device.h | 2 ++
> drivers/gpu/drm/panfrost/panfrost_drv.c| 11 +++
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> b/drivers/gpu/drm/panfrost/panfrost_device.h
> index 8074f221034b..031168f83bd2 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> @@ -115,6 +115,8 @@ static inline bool panfrost_model_eq(struct
> panfrost_device *pfdev, s32 id)
> return !panfrost_model_cmp(pfdev, id);
> }
>
> +int panfrost_unstable_ioctl_check(void);
> +
> int panfrost_device_init(struct panfrost_device *pfdev);
> void panfrost_device_fini(struct panfrost_device *pfdev);
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index d11e2281dde6..754881ece8d7 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -20,6 +20,9 @@
> #include "panfrost_job.h"
> #include "panfrost_gpu.h"
>
> +static bool unstable_ioctls;
> +module_param_unsafe(unstable_ioctls, bool, 0600);
> +
> static int panfrost_ioctl_get_param(struct drm_device *ddev, void *data,
> struct drm_file *file)
> {
> struct drm_panfrost_get_param *param = data;
> @@ -297,6 +300,14 @@ static int panfrost_ioctl_get_bo_offset(struct
> drm_device *dev, void *data,
> return 0;
> }
>
> +int panfrost_unstable_ioctl_check(void)
> +{
> + if (!unstable_ioctls)
> + return -ENOSYS;
> +
> + return 0;
> +}
> +
> static int
> panfrost_open(struct drm_device *dev, struct drm_file *file)
> {
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110822] [Bisected]Booting with kernel version 5.1.0 or higher on RX 580 hangs
https://bugs.freedesktop.org/show_bug.cgi?id=110822 --- Comment #15 from Gobinda Joy --- (In reply to b6khqjqov4 from comment #14) > (In reply to b6khqjqov4 from comment #13) > > Your bug sounds like mine which came after I bought and added a used RX580 > > to my system. Since then had random full system freezes (I think only when I > > was using Firefox or the internal Steam Chromium browser) and desktop hangs > > where Cinnamon would crash and nothing except the mouse pointer would be > > movable. No error in logs at first, but then I found this after the system > > hanged instead of a hard freeze: > > > > $ journalctl -p3: > > > > > > ... > > Jun 09 06:45:34 test systemd-coredump[1383]: Process 1328 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1332: > > #0 0x7f04ecd3ed36 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > #1 0x n/a > > (n/a) > > Jun 09 06:45:35 test systemd-coredump[1374]: Process 1106 (firefox.real) of > > user 1000 dumped core. > > > > Stack trace of thread 1124: > > #0 0x7fd89155036f raise > > (libpthread.so.0) > > #1 0x7fd88b6b3a5f n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > Jun 09 06:45:35 test systemd-coredump[1384]: Process 1162 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1164: > > #0 0x7ffb32c6ad36 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > #1 0x n/a > > (n/a) > > Jun 09 06:45:38 test systemd-coredump[1385]: Process 1237 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1241: > > #0 0x7f9aa7f3ed36 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > #1 0x n/a > > (n/a) > > Jun 09 06:47:31 test systemd-coredump[1640]: Process 1536 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1536: > > #0 0x7f830d3ee3e7 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > Jun 09 06:47:32 test systemd-coredump[1650]: Process 1603 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1606: > > #0 0x7f8f129ebd36 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > #1 0x n/a > > (n/a) > > Jun 09 06:47:32 test systemd-coredump[1639]: Process 1410 (firefox.real) of > > user 1000 dumped core. > > > > Stack trace of thread 1410: > > #0 0x7fe94ed5f36f raise > > (libpthread.so.0) > > #1 0x7fe948ec2a5f n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > Jun 09 06:47:32 test systemd-coredump[1649]: Process 1467 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1469: > > #0 0x7fb2790c2d36 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > #1 0x n/a > > (n/a) > > ... > > > > > > My system: > > - MSI B450 Tomahawk > > - Athlon 200GE (yes, this CPU will be upgraded to a Ryzen 3000 one of course > > ;)) > > - RX 580 4G Nitro+ > > - G.Skill Aegis DIMM Kit 16GB, DDR4-3000, CL16-18-18-38 (F4-3000C16D-16GISB) > > > > My fix: 2 things I can remember I did which are maybe the fix: > > 1.) I disabled integrated graphics in the BIOS. > > 2.) I installed amd-ucode. > > > > No hangs/freezes or anything since my fix. I'll report back here should I > > encounter a crash/freeze/hang again. > > Addition: > Arch (through Antergos) with all latest updates: > - $ uname: 5.1.7-arch1-1-ARCH > - $ glxinfo | grep version: > server glx version string: 1.4 > client glx version string: 1.4 > GLX version: 1.4 > Max core profile version: 4.5 > Max compat profile version:
[PATCH v3] drm/vmwgfx: fix a warning due to missing dma_parms
From: Qian Cai
Booting up with DMA_API_DEBUG_SG=y generates a warning due to the driver
forgot to set dma_parms appropriately. Set it just after vmw_dma_masks()
in vmw_driver_load().
DMA-API: vmwgfx :00:0f.0: mapping sg segment longer than device
claims to support [len=2097152] [max=65536]
WARNING: CPU: 2 PID: 261 at kernel/dma/debug.c:1232
debug_dma_map_sg+0x360/0x480
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
Reference Platform, BIOS 6.00 04/13/2018
RIP: 0010:debug_dma_map_sg+0x360/0x480
Call Trace:
vmw_ttm_map_dma+0x3b1/0x5b0 [vmwgfx]
vmw_bo_map_dma+0x25/0x30 [vmwgfx]
vmw_otables_setup+0x2a8/0x750 [vmwgfx]
vmw_request_device_late+0x78/0xc0 [vmwgfx]
vmw_request_device+0xee/0x4e0 [vmwgfx]
vmw_driver_load.cold+0x757/0xd84 [vmwgfx]
drm_dev_register+0x1ff/0x340 [drm]
drm_get_pci_dev+0x110/0x290 [drm]
vmw_probe+0x15/0x20 [vmwgfx]
local_pci_probe+0x7a/0xc0
pci_device_probe+0x1b9/0x290
really_probe+0x1b5/0x630
driver_probe_device+0xa3/0x1a0
device_driver_attach+0x94/0xa0
__driver_attach+0xdd/0x1c0
bus_for_each_dev+0xfe/0x150
driver_attach+0x2d/0x40
bus_add_driver+0x290/0x350
driver_register+0xdc/0x1d0
__pci_register_driver+0xda/0xf0
vmwgfx_init+0x34/0x1000 [vmwgfx]
do_one_initcall+0xe5/0x40a
do_init_module+0x10f/0x3a0
load_module+0x16a5/0x1a40
__se_sys_finit_module+0x183/0x1c0
__x64_sys_finit_module+0x43/0x50
do_syscall_64+0xc8/0x606
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Co-developed-by: Thomas Hellstrom
Signed-off-by: Qian Cai
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 6d417e29bcec..447b49d6ade1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -745,6 +745,9 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
if (unlikely(ret != 0))
goto out_err0;
+ dma_set_max_seg_size(dev->dev, min_t(unsigned int, U32_MAX & PAGE_MASK,
+SCATTERLIST_MAX_SEGMENT));
+
if (dev_priv->capabilities & SVGA_CAP_GMR2) {
DRM_INFO("Max GMR ids is %u\n",
(unsigned)dev_priv->max_gmr_ids);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110856] Freesync causes in-game blackscreens when game has low fps.
https://bugs.freedesktop.org/show_bug.cgi?id=110856 Nicholas Kazlauskas changed: What|Removed |Added CC||nicholas.kazlaus...@amd.com --- Comment #1 from Nicholas Kazlauskas --- Please attach a full dmesg log and an Xorg log if you're using X. -- 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 110822] [Bisected]Booting with kernel version 5.1.0 or higher on RX 580 hangs
https://bugs.freedesktop.org/show_bug.cgi?id=110822 Gobinda Joy changed: What|Removed |Added Status|VERIFIED|REOPENED Resolution|WORKSFORME |--- -- 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] efifb: BGRT: Add check for new BGRT status field rotation bits
On Wed, 29 May 2019 at 17:46, Hans de Goede wrote:
>
> Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
> reserved. These bits are now used to indicate if the image needs to be
> rotated before being displayed.
>
> The efifb code does not support rotating the image before copying it to
> the screen.
>
> This commit adds a check for these new bits and if they are set leaves the
> fb contents as is instead of trying to use the un-rotated BGRT image.
>
> Signed-off-by: Hans de Goede
Acked-by: Ard Biesheuvel
> ---
> drivers/video/fbdev/efifb.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 9f39f0c360e0..dfa8dd47d19d 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -169,6 +169,11 @@ static void efifb_show_boot_graphics(struct fb_info
> *info)
> return;
> }
>
> + if (bgrt_tab.status & 0x06) {
> + pr_info("efifb: BGRT rotation bits set, not showing boot
> graphics\n");
> + return;
> + }
> +
> /* Avoid flashing the logo if we're going to print std probe messages
> */
> if (console_loglevel > CONSOLE_LOGLEVEL_QUIET)
> return;
> --
> 2.21.0
>
Re: [PATCH] drm/panfrost: Require the simple_ondemand governor
On Wed, Jun 5, 2019 at 12:49 PM Ezequiel Garcia wrote:
>
> Panfrost depends on the simple_ondemand governor, and therefore
> it's a required configuration. Select it.
>
> Fixes: f3617b449d ("drm/panfrost: Select devfreq")
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/gpu/drm/panfrost/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Applied.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/panfrost: make devfreq optional again
On Wed, Jun 5, 2019 at 9:02 AM Neil Armstrong wrote:
>
> Devfreq runtime usage was made mandatory, thus making panfrost fail to probe
> on Amlogic S912 SoCs missing the "operating-points-v2" property.
> Make it optional again, leaving PM_DEVFREQ selected by default.
>
> Fixes: f3617b449d ("drm/panfrost: Select devfreq")
> Signed-off-by: Neil Armstrong
> ---
> Changes since v1:
> - fixed else/if logic in panfrost_devfreq_init
>
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
Applied.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/panfrost: Use drm_gem_shmem_map_offset()
On Wed, May 22, 2019 at 6:39 AM Steven Price wrote: > > On 21/05/2019 19:23, Chris Wilson wrote: > > Quoting Rob Herring (2019-05-21 16:24:27) > >> On Mon, May 20, 2019 at 4:23 AM Steven Price wrote: > >>> > >> > >> You forgot to update the subject. I can fixup when applying, but I'd > >> like an ack from Chris on patch 1. > > Sorry about that - I'll try to be more careful in the future. > > > I still think it is incorrect as the limitation is purely an issue with > > the shmem backend and not a generic GEM limitation. It matters if you > > Do you prefer the previous version of this series[1] with the shmem helper? > > [1] > https://lore.kernel.org/lkml/20190516141447.46839-1-steven.pr...@arm.com/ > > Although this isn't a generic GEM limitation it's currently the same > limitation that applies to the 'dumb' drivers as well as shmem backend, > so I'd prefer not implementing two identical functions purely because > this limitation could be removed in the future. In interest of moving this forward, how about some comments in drm_gem_map_offset() explaining the limitations and when it is appropriate to use the function. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/vkms: Add support for writeback
On Fri, Jun 07, 2019 at 11:58:04AM -0300, Rodrigo Siqueira wrote:
> On Fri, Jun 7, 2019 at 4:48 AM Daniel Vetter wrote:
> >
> > On Thu, Jun 06, 2019 at 07:41:01PM -0300, Rodrigo Siqueira wrote:
> > > This patch implements the necessary functions to add writeback support
> > > for vkms. This feature is useful for testing compositors if you don’t
> > > have hardware with writeback support.
> > >
> > > Signed-off-by: Rodrigo Siqueira
> > > ---
> > > drivers/gpu/drm/vkms/Makefile | 9 +-
> > > drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
> > > drivers/gpu/drm/vkms/vkms_drv.c | 10 ++
> > > drivers/gpu/drm/vkms/vkms_drv.h | 12 ++
> > > drivers/gpu/drm/vkms/vkms_output.c| 6 +
> > > drivers/gpu/drm/vkms/vkms_writeback.c | 165 ++
> > > 6 files changed, 206 insertions(+), 1 deletion(-)
> > > create mode 100644 drivers/gpu/drm/vkms/vkms_writeback.c
> > >
> > > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> > > index 89f09bec7b23..90eb7acd618d 100644
> > > --- a/drivers/gpu/drm/vkms/Makefile
> > > +++ b/drivers/gpu/drm/vkms/Makefile
> > > @@ -1,4 +1,11 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > > -vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o
> > > vkms_crc.o
> > > +vkms-y := \
> > > + vkms_drv.o \
> > > + vkms_plane.o \
> > > + vkms_output.o \
> > > + vkms_crtc.o \
> > > + vkms_gem.o \
> > > + vkms_crc.o \
> > > + vkms_writeback.o
> > >
> > > obj-$(CONFIG_DRM_VKMS) += vkms.o
> > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > index 1bbe099b7db8..ce797e265b1b 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > @@ -23,6 +23,11 @@ static enum hrtimer_restart
> > > vkms_vblank_simulate(struct hrtimer *timer)
> > > if (!ret)
> > > DRM_ERROR("vkms failure on handling vblank");
> > >
> > > + if (output->writeback_status == WB_START) {
> > > + drm_writeback_signal_completion(&output->wb_connector, 0);
> > > + output->writeback_status = WB_STOP;
> > > + }
> > > +
> > > if (state && output->crc_enabled) {
> > > u64 frame = drm_crtc_accurate_vblank_count(crtc);
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> > > b/drivers/gpu/drm/vkms/vkms_drv.c
> > > index 92296bd8f623..d5917d5a45e3 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > @@ -29,6 +29,10 @@ bool enable_cursor;
> > > module_param_named(enable_cursor, enable_cursor, bool, 0444);
> > > MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
> > >
> > > +int enable_writeback;
> > > +module_param_named(enable_writeback, enable_writeback, int, 0444);
> > > +MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector");
> > > +
> > > static const struct file_operations vkms_driver_fops = {
> > > .owner = THIS_MODULE,
> > > .open = drm_open,
> > > @@ -123,6 +127,12 @@ static int __init vkms_init(void)
> > > goto out_fini;
> > > }
> > >
> > > + vkms_device->output.writeback_status = WB_DISABLED;
> > > + if (enable_writeback) {
> > > + vkms_device->output.writeback_status = WB_STOP;
> > > + DRM_INFO("Writeback connector enabled");
> > > + }
> > > +
> > > ret = vkms_modeset_init(vkms_device);
> > > if (ret)
> > > goto out_fini;
> > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
> > > b/drivers/gpu/drm/vkms/vkms_drv.h
> > > index e81073dea154..ca1f9ee63ec8 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_drv.h
> > > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> > > @@ -7,6 +7,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
> > > #define XRES_MIN20
> > > @@ -60,14 +61,22 @@ struct vkms_crtc_state {
> > > u64 frame_end;
> > > };
> > >
> > > +enum wb_status {
> > > + WB_DISABLED,
> > > + WB_START,
> > > + WB_STOP,
> > > +};
> > > +
> > > struct vkms_output {
> > > struct drm_crtc crtc;
> > > struct drm_encoder encoder;
> > > struct drm_connector connector;
> > > + struct drm_writeback_connector wb_connector;
> > > struct hrtimer vblank_hrtimer;
> > > ktime_t period_ns;
> > > struct drm_pending_vblank_event *event;
> > > bool crc_enabled;
> > > + enum wb_status writeback_status;
> > > /* ordered wq for crc_work */
> > > struct workqueue_struct *crc_workq;
> > > /* protects concurrent access to crc_data */
> > > @@ -141,4 +150,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc,
> > > const char *source_name,
> > > size_t *values_cnt);
> > > void vkms_crc_work_handle(struct work_struct *work);
> > >
> > > +/* Writeback */
> > > +int enable_writeback_connector(struct vkms_device *vkmsdev);
> > > +
> > >
Re: [PATCH] drm/gem_shmem: Use a writecombine mapping for ->vaddr
On Wed, May 29, 2019 at 12:51 AM Boris Brezillon wrote: > > Right now, the BO is mapped as a cached region when ->vmap() is called > and the underlying object is not a dmabuf. > Doing that makes cache management a bit more complicated (you'd need > to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about > to be passed to the GPU/CPU), so let's map the BO with writecombine > attributes instead (as done in most drivers). > > Signed-off-by: Boris Brezillon > --- > Found this issue while working on panfrost perfcnt where the GPU dumps > perf counter values in memory and the CPU reads them back in > kernel-space. This patch seems to solve the unpredictable behavior I > had. > > I can also go for the other option (call dma_map/unmap/_sg() when > needed) if you think that's more appropriate. Using writecombine everywhere was the intention, but I missed this spot. I've applied this adding a Fixes tag. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: remove the newline for CRC source name.
Hi Dingchen. On Mon, Jun 10, 2019 at 09:47:51AM -0400, Dingchen Zhang wrote: > userspace may transfer a newline, and this terminating newline > is replaced by a '\0' to avoid followup issues. > > 'len-1' is the index to replace the newline of CRC source name. > > v3: typo fix (Sam) > > v2: update patch subject, body and format. (Sam) > > Cc: Leo Li > Cc: Harry Wentland > Cc: Sam Ravnborg > Signed-off-by: Dingchen Zhang Reviewed-by: Sam Ravnborg > --- > drivers/gpu/drm/drm_debugfs_crc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c > b/drivers/gpu/drm/drm_debugfs_crc.c > index 585169f0dcc5..dac267e840af 100644 > --- a/drivers/gpu/drm/drm_debugfs_crc.c > +++ b/drivers/gpu/drm/drm_debugfs_crc.c > @@ -131,8 +131,8 @@ static ssize_t crc_control_write(struct file *file, const > char __user *ubuf, > if (IS_ERR(source)) > return PTR_ERR(source); > > - if (source[len] == '\n') > - source[len] = '\0'; > + if (source[len - 1] == '\n') > + source[len - 1] = '\0'; > > ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt); > if (ret) > -- > 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110822] [Bisected]Booting with kernel version 5.1.0 or higher on RX 580 hangs
https://bugs.freedesktop.org/show_bug.cgi?id=110822 --- Comment #16 from Gobinda Joy --- (In reply to b6khqjqov4 from comment #14) > (In reply to b6khqjqov4 from comment #13) > > Your bug sounds like mine which came after I bought and added a used RX580 > > to my system. Since then had random full system freezes (I think only when I > > was using Firefox or the internal Steam Chromium browser) and desktop hangs > > where Cinnamon would crash and nothing except the mouse pointer would be > > movable. No error in logs at first, but then I found this after the system > > hanged instead of a hard freeze: > > > > $ journalctl -p3: > > > > > > ... > > Jun 09 06:45:34 test systemd-coredump[1383]: Process 1328 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1332: > > #0 0x7f04ecd3ed36 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > #1 0x n/a > > (n/a) > > Jun 09 06:45:35 test systemd-coredump[1374]: Process 1106 (firefox.real) of > > user 1000 dumped core. > > > > Stack trace of thread 1124: > > #0 0x7fd89155036f raise > > (libpthread.so.0) > > #1 0x7fd88b6b3a5f n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > Jun 09 06:45:35 test systemd-coredump[1384]: Process 1162 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1164: > > #0 0x7ffb32c6ad36 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > #1 0x n/a > > (n/a) > > Jun 09 06:45:38 test systemd-coredump[1385]: Process 1237 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1241: > > #0 0x7f9aa7f3ed36 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > #1 0x n/a > > (n/a) > > Jun 09 06:47:31 test systemd-coredump[1640]: Process 1536 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1536: > > #0 0x7f830d3ee3e7 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > Jun 09 06:47:32 test systemd-coredump[1650]: Process 1603 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1606: > > #0 0x7f8f129ebd36 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > #1 0x n/a > > (n/a) > > Jun 09 06:47:32 test systemd-coredump[1639]: Process 1410 (firefox.real) of > > user 1000 dumped core. > > > > Stack trace of thread 1410: > > #0 0x7fe94ed5f36f raise > > (libpthread.so.0) > > #1 0x7fe948ec2a5f n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > Jun 09 06:47:32 test systemd-coredump[1649]: Process 1467 (Web Content) of > > user 1000 dumped core. > > > > Stack trace of thread 1469: > > #0 0x7fb2790c2d36 n/a > > (/home/test/tor-browser_en-US/Browser/libxul.so) > > #1 0x n/a > > (n/a) > > ... > > > > > > My system: > > - MSI B450 Tomahawk > > - Athlon 200GE (yes, this CPU will be upgraded to a Ryzen 3000 one of course > > ;)) > > - RX 580 4G Nitro+ > > - G.Skill Aegis DIMM Kit 16GB, DDR4-3000, CL16-18-18-38 (F4-3000C16D-16GISB) > > > > My fix: 2 things I can remember I did which are maybe the fix: > > 1.) I disabled integrated graphics in the BIOS. > > 2.) I installed amd-ucode. > > > > No hangs/freezes or anything since my fix. I'll report back here should I > > encounter a crash/freeze/hang again. > > Addition: > Arch (through Antergos) with all latest updates: > - $ uname: 5.1.7-arch1-1-ARCH > - $ glxinfo | grep version: > server glx version string: 1.4 > client glx version string: 1.4 > GLX version: 1.4 > Max core profile version: 4.5 > Max compat profile version:
[PATCH] drm/panfrost: Align GEM objects GPU VA to 2MB
In order to increase the chances of using 2MB pages, we need to align the GPU VA mapping to 2MB. Only do this if the object size is 2MB or more. Cc: Robin Murphy Cc: Steven Price Cc: Tomeu Vizoso Signed-off-by: Rob Herring --- drivers/gpu/drm/panfrost/panfrost_gem.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c index a5528a360ef4..886875ae31d3 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gem.c +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c @@ -52,6 +52,7 @@ struct drm_gem_object *panfrost_gem_create_object(struct drm_device *dev, size_t int ret; struct panfrost_device *pfdev = dev->dev_private; struct panfrost_gem_object *obj; + u64 align; obj = kzalloc(sizeof(*obj), GFP_KERNEL); if (!obj) @@ -59,9 +60,12 @@ struct drm_gem_object *panfrost_gem_create_object(struct drm_device *dev, size_t obj->base.base.funcs = &panfrost_gem_funcs; + size = roundup(size, PAGE_SIZE); + align = size >= SZ_2M ? SZ_2M >> PAGE_SHIFT : 0; + spin_lock(&pfdev->mm_lock); - ret = drm_mm_insert_node(&pfdev->mm, &obj->node, -roundup(size, PAGE_SIZE) >> PAGE_SHIFT); + ret = drm_mm_insert_node_generic(&pfdev->mm, &obj->node, +size >> PAGE_SHIFT, align, 0, 0); spin_unlock(&pfdev->mm_lock); if (ret) goto free_obj; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/panfrost: Add support for mapping BOs on GPU page faults
The midgard/bifrost GPUs need to allocate GPU memory which is allocated
on GPU page faults and not pinned in memory. The vendor driver calls
this functionality GROW_ON_GPF.
This implementation assumes that BOs allocated with the
PANFROST_BO_NOMAP flag are never mmapped or exported. Both of those may
actually work, but I'm unsure if there's some interaction there. It
would cause the whole object to be pinned in memory which would defeat
the point of this.
Issues/questions/thoughts:
What's the difference between i_mapping and f_mapping?
What kind of clean-up on close is needed? Based on vgem faults, there
doesn't seem to be any refcounting. Assume userspace is responsible for
not freeing the BO while a page fault can occur?
What about evictions? Need to call mapping_set_unevictable()? Maybe we
want these pages to be swappable, but then we need some notification to
unmap them.
No need for runtime PM, because faults should only occur during job
submit?
Need to fault in 2MB sections when possible. It seems this has to be
done by getting an array of struct pages and then converting to a
scatterlist. Not sure if there is a better way to do that. There's also
some errata on T604 needing to fault in at least 8 pages at a time which
isn't handled.
Cc: Robin Murphy
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Tomeu Vizoso
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/TODO | 2 -
drivers/gpu/drm/panfrost/panfrost_drv.c | 22 +--
drivers/gpu/drm/panfrost/panfrost_gem.c | 3 +-
drivers/gpu/drm/panfrost/panfrost_gem.h | 8 +++
drivers/gpu/drm/panfrost/panfrost_mmu.c | 76 +++--
include/uapi/drm/panfrost_drm.h | 2 +
6 files changed, 100 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/TODO b/drivers/gpu/drm/panfrost/TODO
index c2e44add37d8..64129bf73933 100644
--- a/drivers/gpu/drm/panfrost/TODO
+++ b/drivers/gpu/drm/panfrost/TODO
@@ -14,8 +14,6 @@
The hard part is handling when more address spaces are needed than what
the h/w provides.
-- Support pinning pages on demand (GPU page faults).
-
- Support userspace controlled GPU virtual addresses. Needed for Vulkan.
(Tomeu)
- Support for madvise and a shrinker.
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index d11e2281dde6..f08d41d5186a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -44,9 +44,11 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev,
void *data,
{
int ret;
struct drm_gem_shmem_object *shmem;
+ struct panfrost_gem_object *bo;
struct drm_panfrost_create_bo *args = data;
- if (!args->size || args->flags || args->pad)
+ if (!args->size || args->pad ||
+ (args->flags & ~PANFROST_BO_NOMAP))
return -EINVAL;
shmem = drm_gem_shmem_create_with_handle(file, dev, args->size,
@@ -54,11 +56,16 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev,
void *data,
if (IS_ERR(shmem))
return PTR_ERR(shmem);
- ret = panfrost_mmu_map(to_panfrost_bo(&shmem->base));
- if (ret)
- goto err_free;
+ bo = to_panfrost_bo(&shmem->base);
- args->offset = to_panfrost_bo(&shmem->base)->node.start << PAGE_SHIFT;
+ if (!(args->flags & PANFROST_BO_NOMAP)) {
+ ret = panfrost_mmu_map(bo);
+ if (ret)
+ goto err_free;
+ } else
+ bo->no_map = 1;
+
+ args->offset = bo->node.start << PAGE_SHIFT;
return 0;
@@ -269,6 +276,11 @@ static int panfrost_ioctl_mmap_bo(struct drm_device *dev,
void *data,
return -ENOENT;
}
+ if (to_panfrost_bo(gem_obj)->no_map) {
+ DRM_DEBUG("Can't mmap 'no_map' GEM BO %d\n", args->handle);
+ return -EINVAL;
+ }
+
ret = drm_gem_create_mmap_offset(gem_obj);
if (ret == 0)
args->offset = drm_vma_node_offset_addr(&gem_obj->vma_node);
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 886875ae31d3..ed0b4f79610a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -19,7 +19,8 @@ static void panfrost_gem_free_object(struct drm_gem_object
*obj)
struct panfrost_gem_object *bo = to_panfrost_bo(obj);
struct panfrost_device *pfdev = obj->dev->dev_private;
- panfrost_mmu_unmap(bo);
+ if (!bo->no_map)
+ panfrost_mmu_unmap(bo);
spin_lock(&pfdev->mm_lock);
drm_mm_remove_node(&bo->node);
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h
b/drivers/gpu/drm/panfrost/panfrost_gem.h
index 045000eb5fcf..aa210d7cbf3f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.h
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
@@ -11,6 +11,7 @@ struct panfrost_gem_object {
struct drm_gem
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #30 from Sam --- Update: I can now confirm, at least in my case, that the freezes DO occur using the parameters above, and also with all of them (shown below), while doing another test round on Pillars of Eternity. amdgpu.dc=1 amdgpu.vm_update_mode=0 amdgpu.dpm=-1 amdgpu.ppfeaturemask=0x amdgpu.vm_fault_stop=2 amdgpu.vm_debug=1 amdgpu.gpu_recovery=0 I was continuously writing dmesg to a file but yet again I didn't get any messages/warnings/errors. -- 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
Pine64+ sun4i-drm Attempting to unwedge stuck i2c bus
Hi, updating my Pine64+ to the latest drm-misc-next today (427231bc6d5) started giving me the BUG and Oops below. It's consistently reproduceable. Without KASAN I still get the Oops. I was able to bisect it to [50f9495efe308eb25fd921ea7c8c8143ddeeae30] drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus . Reading the comments on that patch I'm not sure why it is even trying to run this "unwedge" handler on the Pine64+. Any clue? Thanks Erico [ 11.295570] sun4i-drm display-engine: bound 110.mixer (ops sun8i_mixer_ops [sun8i_mixer]) [ 11.311050] sun4i-drm display-engine: bound 120.mixer (ops sun8i_mixer_ops [sun8i_mixer]) [ 11.323249] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 11.331231] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops sun4i_tcon_ops [sun4i_tcon]) [ 11.342553] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops sun4i_tcon_ops [sun4i_tcon]) [ 11.356378] sun8i-dw-hdmi 1ee.hdmi: Detected HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_phy) [ 11.369609] sun8i-dw-hdmi 1ee.hdmi: registered DesignWare HDMI I2C bus driver [ 11.382381] sun4i-drm display-engine: bound 1ee.hdmi (ops sun8i_dw_hdmi_ops [sun8i_drm_hdmi]) [ 11.391385] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 11.398082] [drm] No driver support for vblank timestamp query. [ 11.408146] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0 [ 11.517050] sun8i-dw-hdmi 1ee.hdmi: Attempting to unwedge stuck i2c bus [ 11.524067] == [ 11.531315] BUG: KASAN: null-ptr-deref in pinctrl_select_state+0x1c/0x50 [ 11.538023] Read of size 8 at addr 0015 by task udevd/213 [ 11.544462] [ 11.545974] CPU: 1 PID: 213 Comm: udevd Not tainted 5.2.0-rc2 #5 [ 11.551984] Hardware name: Pine64+ (DT) [ 11.555825] Call trace: [ 11.558295] dump_backtrace+0x0/0x1d0 [ 11.561974] show_stack+0x14/0x20 [ 11.565309] dump_stack+0xc4/0xfc [ 11.568640] __kasan_report+0x19c/0x1a0 [ 11.572487] kasan_report+0xc/0x20 [ 11.575903] __asan_load8+0x54/0xa0 [ 11.579404] pinctrl_select_state+0x1c/0x50 [ 11.583636] dw_hdmi_i2c_wait+0xcc/0x110 [dw_hdmi] [ 11.588472] dw_hdmi_i2c_xfer+0x37c/0x6a0 [dw_hdmi] [ 11.593376] __i2c_transfer+0x29c/0x550 [ 11.597233] i2c_transfer+0x100/0x190 [ 11.601594] drm_do_probe_ddc_edid+0x128/0x1d0 [drm] [ 11.607254] drm_get_edid+0xa8/0x530 [drm] [ 11.611410] dw_hdmi_connector_get_modes+0x28/0xb0 [dw_hdmi] [ 11.617380] drm_helper_probe_single_connector_modes+0x290/0x9e0 [drm_kms_helper] [ 11.625169] drm_setup_crtcs+0x274/0x15f0 [drm_kms_helper] [ 11.630945] __drm_fb_helper_initial_config_and_unlock+0xb4/0x770 [drm_kms_helper] [ 11.638769] drm_fbdev_client_hotplug+0x14c/0x230 [drm_kms_helper] [ 11.645205] drm_fbdev_generic_setup+0xc8/0x190 [drm_kms_helper] [ 11.651252] sun4i_drv_bind+0x1cc/0x240 [sun4i_drm] [ 11.656153] try_to_bring_up_master+0x280/0x300 [ 11.660700] component_master_add_with_match+0x13c/0x180 [ 11.666049] sun4i_drv_probe+0x26c/0x2f0 [sun4i_drm] [ 11.671027] platform_drv_probe+0x6c/0xd0 [ 11.675054] really_probe+0x144/0x3a0 [ 11.678733] driver_probe_device+0x74/0x130 [ 11.682932] device_driver_attach+0x94/0xa0 [ 11.687131] __driver_attach+0x70/0x110 [ 11.690982] bus_for_each_dev+0xe8/0x160 [ 11.694920] driver_attach+0x30/0x40 [ 11.698511] bus_add_driver+0x250/0x2b0 [ 11.702357] driver_register+0xbc/0x1d0 [ 11.706207] __platform_driver_register+0x7c/0x90 [ 11.710948] sun4i_drv_platform_driver_init+0x20/0x1000 [sun4i_drm] [ 11.717229] do_one_initcall+0xd4/0x254 [ 11.721083] do_init_module+0xfc/0x360 [ 11.724845] load_module+0x2e6c/0x3580 [ 11.728609] __se_sys_finit_module+0x138/0x150 [ 11.733067] __arm64_sys_finit_module+0x40/0x50 [ 11.737617] el0_svc_common.constprop.0+0xc0/0x1c0 [ 11.742423] el0_svc_handler+0x34/0x90 [ 11.746185] el0_svc+0x8/0xc [ 11.749065] == [ 11.756288] Disabling lock debugging due to kernel taint [ 11.762018] Unable to handle kernel NULL pointer dereference at virtual address 0015 [ 11.770983] Mem abort info: [ 11.773930] ESR = 0x9606 [ 11.777084] Exception class = DABT (current EL), IL = 32 bits [ 11.783163] SET = 0, FnV = 0 [ 11.786314] EA = 0, S1PTW = 0 [ 11.789534] Data abort info: [ 11.792454] ISV = 0, ISS = 0x0006 [ 11.796412] CM = 0, WnR = 0 [ 11.799481] user pgtable: 4k pages, 48-bit VAs, pgdp=a425e000 [ 11.806025] [0015] pgd=a425f003, pud=a4260003, pmd= [ 11.814881] Internal error: Oops: 9606 [#1] PREEMPT SMP [ 11.820469] Modules linked in: snd_soc_hdmi_codec(+) dw_hdmi_i2s_audio sun4i_drm(+) sun4i_frontend sun4i_tcon sun8i_mixer sun8i_drm_hdmi dw_hdmi sun8i_tcon_top drm_km
Re: Pine64+ sun4i-drm Attempting to unwedge stuck i2c bus
Hi, On Mon, Jun 10, 2019 at 10:28 AM Erico Nunes wrote: > > Hi, > > updating my Pine64+ to the latest drm-misc-next today (427231bc6d5) > started giving me the BUG and Oops below. It's consistently > reproduceable. Without KASAN I still get the Oops. > I was able to bisect it to [50f9495efe308eb25fd921ea7c8c8143ddeeae30] > drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus . > Reading the comments on that patch I'm not sure why it is even trying > to run this "unwedge" handler on the Pine64+. > > Any clue? I see the bug. Patch coming right up. Sorry. -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/synopsys: dw-hdmi: Fix unwedge crash when no pinctrl entries
In commit 50f9495efe30 ("drm/bridge/synopsys: dw-hdmi: Add "unwedge"
for ddc bus") I stupidly used IS_ERR() to check for whether we have an
"unwedge" pinctrl state even though on most flows through the driver
the unwedge state will just be NULL.
Fix it so that we consistently use NULL for no unwedge state.
Fixes: 50f9495efe30 ("drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus")
Reported-by: Erico Nunes
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index f25e091b93c5..5e4e9408d00f 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -251,7 +251,7 @@ static void dw_hdmi_i2c_init(struct dw_hdmi *hdmi)
static bool dw_hdmi_i2c_unwedge(struct dw_hdmi *hdmi)
{
/* If no unwedge state then give up */
- if (IS_ERR(hdmi->unwedge_state))
+ if (!hdmi->unwedge_state)
return false;
dev_info(hdmi->dev, "Attempting to unwedge stuck i2c bus\n");
@@ -2686,11 +2686,13 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->default_state =
pinctrl_lookup_state(hdmi->pinctrl, "default");
- if (IS_ERR(hdmi->default_state) &&
- !IS_ERR(hdmi->unwedge_state)) {
- dev_warn(dev,
-"Unwedge requires default pinctrl\n");
- hdmi->unwedge_state = ERR_PTR(-ENODEV);
+ if (IS_ERR(hdmi->default_state) ||
+ IS_ERR(hdmi->unwedge_state)) {
+ if (!IS_ERR(hdmi->unwedge_state))
+ dev_warn(dev,
+"Unwedge requires default
pinctrl\n");
+ hdmi->default_state = NULL;
+ hdmi->unwedge_state = NULL;
}
}
--
2.22.0.rc2.383.gf4fbbf30c2-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Pine64+ sun4i-drm Attempting to unwedge stuck i2c bus
Hi, On Mon, Jun 10, 2019 at 10:32 AM Doug Anderson wrote: > > Hi, > > On Mon, Jun 10, 2019 at 10:28 AM Erico Nunes wrote: > > > > Hi, > > > > updating my Pine64+ to the latest drm-misc-next today (427231bc6d5) > > started giving me the BUG and Oops below. It's consistently > > reproduceable. Without KASAN I still get the Oops. > > I was able to bisect it to [50f9495efe308eb25fd921ea7c8c8143ddeeae30] > > drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc bus . > > Reading the comments on that patch I'm not sure why it is even trying > > to run this "unwedge" handler on the Pine64+. > > > > Any clue? > > I see the bug. Patch coming right up. Sorry. Breadcrumbs: https://lkml.kernel.org/r/20190610175234.196844-1-diand...@chromium.org -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v16 02/16] arm64: untag user pointers in access_ok and __uaccess_mask_ptr
On Mon, Jun 10, 2019 at 06:53:27PM +0100, Catalin Marinas wrote:
> On Mon, Jun 03, 2019 at 06:55:04PM +0200, Andrey Konovalov wrote:
> > diff --git a/arch/arm64/include/asm/uaccess.h
> > b/arch/arm64/include/asm/uaccess.h
> > index e5d5f31c6d36..9164ecb5feca 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -94,7 +94,7 @@ static inline unsigned long __range_ok(const void __user
> > *addr, unsigned long si
> > return ret;
> > }
> >
> > -#define access_ok(addr, size) __range_ok(addr, size)
> > +#define access_ok(addr, size) __range_ok(untagged_addr(addr), size)
>
> I'm going to propose an opt-in method here (RFC for now). We can't have
> a check in untagged_addr() since this is already used throughout the
> kernel for both user and kernel addresses (khwasan) but we can add one
> in __range_ok(). The same prctl() option will be used for controlling
> the precise/imprecise mode of MTE later on. We can use a TIF_ flag here
> assuming that this will be called early on and any cloned thread will
> inherit this.
>
> Anyway, it's easier to paste some diff than explain but Vincenzo can
> fold them into his ABI patches that should really go together with
> these. I added a couple of MTE definitions for prctl() as an example,
> not used currently:
>
> --8<-
> diff --git a/arch/arm64/include/asm/processor.h
> b/arch/arm64/include/asm/processor.h
> index fcd0e691b1ea..2d4cb7e4edab 100644
> --- a/arch/arm64/include/asm/processor.h
> +++ b/arch/arm64/include/asm/processor.h
> @@ -307,6 +307,10 @@ extern void __init minsigstksz_setup(void);
> /* PR_PAC_RESET_KEYS prctl */
> #define PAC_RESET_KEYS(tsk, arg) ptrauth_prctl_reset_keys(tsk, arg)
>
> +/* PR_UNTAGGED_UADDR prctl */
> +int untagged_uaddr_set_mode(unsigned long arg);
> +#define SET_UNTAGGED_UADDR_MODE(arg) untagged_uaddr_set_mode(arg)
> +
> /*
> * For CONFIG_GCC_PLUGIN_STACKLEAK
> *
> diff --git a/arch/arm64/include/asm/thread_info.h
> b/arch/arm64/include/asm/thread_info.h
> index c285d1ce7186..89ce3c49 100644
> --- a/arch/arm64/include/asm/thread_info.h
> +++ b/arch/arm64/include/asm/thread_info.h
> @@ -101,6 +101,7 @@ void arch_release_task_struct(struct task_struct *tsk);
> #define TIF_SVE 23 /* Scalable Vector Extension in
> use */
> #define TIF_SVE_VL_INHERIT 24 /* Inherit sve_vl_onexec across exec */
> #define TIF_SSBD 25 /* Wants SSB mitigation */
> +#define TIF_UNTAGGED_UADDR 26
>
> #define _TIF_SIGPENDING (1 << TIF_SIGPENDING)
> #define _TIF_NEED_RESCHED(1 << TIF_NEED_RESCHED)
> @@ -116,6 +117,7 @@ void arch_release_task_struct(struct task_struct *tsk);
> #define _TIF_FSCHECK (1 << TIF_FSCHECK)
> #define _TIF_32BIT (1 << TIF_32BIT)
> #define _TIF_SVE (1 << TIF_SVE)
> +#define _TIF_UNTAGGED_UADDR (1 << TIF_UNTAGGED_UADDR)
>
> #define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
>_TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE | \
> diff --git a/arch/arm64/include/asm/uaccess.h
> b/arch/arm64/include/asm/uaccess.h
> index 9164ecb5feca..54f5bbaebbc4 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -73,6 +73,9 @@ static inline unsigned long __range_ok(const void __user
> *addr, unsigned long si
> {
> unsigned long ret, limit = current_thread_info()->addr_limit;
>
> + if (test_thread_flag(TIF_UNTAGGED_UADDR))
> + addr = untagged_addr(addr);
> +
> __chk_user_ptr(addr);
> asm volatile(
> // A + B <= C + 1 for all A,B,C, in four easy steps:
> @@ -94,7 +97,7 @@ static inline unsigned long __range_ok(const void __user
> *addr, unsigned long si
> return ret;
> }
>
> -#define access_ok(addr, size)__range_ok(untagged_addr(addr), size)
> +#define access_ok(addr, size)__range_ok(addr, size)
> #define user_addr_maxget_fs
>
> #define _ASM_EXTABLE(from, to)
> \
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index 3767fb21a5b8..fd191c5b92aa 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -552,3 +552,18 @@ void arch_setup_new_exec(void)
>
> ptrauth_thread_init_user(current);
> }
> +
> +/*
> + * Enable the relaxed ABI allowing tagged user addresses into the kernel.
> + */
> +int untagged_uaddr_set_mode(unsigned long arg)
> +{
> + if (is_compat_task())
> + return -ENOTSUPP;
> + if (arg)
> + return -EINVAL;
> +
> + set_thread_flag(TIF_UNTAGGED_UADDR);
> +
> + return 0;
> +}
I think this should be paired with a flag clearing in copy_thread(),
yes? (i.e. each binary needs to opt in)
--
Kees Cook
___
dri-devel mailing list
dri
[Bug 110883] [Regression linux 5.2-rc4][bisected] hang on boot
https://bugs.freedesktop.org/show_bug.cgi?id=110883 --- Comment #3 from Sibren Vasse --- Created attachment 144495 --> https://bugs.freedesktop.org/attachment.cgi?id=144495&action=edit patch I've created this patch, which fixes the issue for me. Can someone take a look at it and consider including it? -- 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 v1 0/7] drm/radeon: drop obsolete header files
On Sat, Jun 8, 2019 at 4:03 AM Sam Ravnborg wrote: > > This patchset contains updates to two header files > in include/drm/. > The header files caused build errors due to missing dependencies. > Fixed this so others will not be hit by the same. > > The header file drm_os_linux.h is deprecated and should > no longer be used. > For radeon it was a simple 1:1 replacement of the > used macros + a adding missing include files. > > The remaining patches perpare for and remove the use > of drmP.h in the rest of the driver. > > The patches was all build tested on various architectures, > and as usual alpha resulted in a few extra build issues. > > The patches are made on top of drm-misc-next, but applies > clean to drm-next-5.3-wip branch of the agd5f git tree. Series is: Reviewed-by: Alex Deucher Feel free to take it through drm-misc if you want, otherwise, let me know and I'll take it through my tree. Alex > > Sam > > Sam Ravnborg (7): > drm: drm_crtc.h self-contained > drm: drm_debugfs.h self-contained > drm/radeon: drop dependency on drm_os_linux.h > drm/radeon: drop drmP.h from header files > drm/radeon: prepare header files for drmP.h removal > drm/radeon: drop use of drmP.h (1/2) > drm/radeon: drop use of drmP.h (2/2) > > drivers/gpu/drm/radeon/atom.c | 2 ++ > drivers/gpu/drm/radeon/atom.h | 1 - > drivers/gpu/drm/radeon/atombios_crtc.c | 7 +++-- > drivers/gpu/drm/radeon/atombios_dp.c| 2 +- > drivers/gpu/drm/radeon/atombios_encoders.c | 14 ++ > drivers/gpu/drm/radeon/atombios_i2c.c | 2 +- > drivers/gpu/drm/radeon/btc_dpm.c| 16 ++- > drivers/gpu/drm/radeon/btc_dpm.h| 3 +++ > drivers/gpu/drm/radeon/ci_dpm.c | 14 +- > drivers/gpu/drm/radeon/ci_dpm.h | 1 + > drivers/gpu/drm/radeon/ci_smc.c | 2 +- > drivers/gpu/drm/radeon/cik.c| 18 - > drivers/gpu/drm/radeon/cik_sdma.c | 6 ++--- > drivers/gpu/drm/radeon/clearstate_cayman.h | 2 ++ > drivers/gpu/drm/radeon/clearstate_ci.h | 2 ++ > drivers/gpu/drm/radeon/clearstate_si.h | 2 ++ > drivers/gpu/drm/radeon/cypress_dpm.c| 11 > drivers/gpu/drm/radeon/dce3_1_afmt.c| 2 +- > drivers/gpu/drm/radeon/dce6_afmt.c | 2 +- > drivers/gpu/drm/radeon/evergreen.c | 16 ++- > drivers/gpu/drm/radeon/evergreen_cs.c | 2 +- > drivers/gpu/drm/radeon/evergreen_dma.c | 2 +- > drivers/gpu/drm/radeon/evergreen_hdmi.c | 2 +- > drivers/gpu/drm/radeon/kv_dpm.c | 10 --- > drivers/gpu/drm/radeon/kv_smc.c | 2 +- > drivers/gpu/drm/radeon/ni.c | 17 +++- > drivers/gpu/drm/radeon/ni_dma.c | 2 +- > drivers/gpu/drm/radeon/ni_dpm.c | 16 ++- > drivers/gpu/drm/radeon/r100.c | 36 > ++--- > drivers/gpu/drm/radeon/r100_track.h | 2 ++ > drivers/gpu/drm/radeon/r200.c | 2 +- > drivers/gpu/drm/radeon/r300.c | 18 - > drivers/gpu/drm/radeon/r420.c | 16 +++ > drivers/gpu/drm/radeon/r520.c | 4 +-- > drivers/gpu/drm/radeon/r600.c | 18 - > drivers/gpu/drm/radeon/r600_cs.c| 2 +- > drivers/gpu/drm/radeon/r600_dma.c | 6 ++--- > drivers/gpu/drm/radeon/r600_dpm.c | 2 +- > drivers/gpu/drm/radeon/r600_dpm.h | 2 ++ > drivers/gpu/drm/radeon/r600_hdmi.c | 2 +- > drivers/gpu/drm/radeon/radeon_acpi.c| 13 + > drivers/gpu/drm/radeon/radeon_agp.c | 8 -- > drivers/gpu/drm/radeon/radeon_asic.c| 10 --- > drivers/gpu/drm/radeon/radeon_atombios.c| 5 +++- > drivers/gpu/drm/radeon/radeon_audio.c | 2 +- > drivers/gpu/drm/radeon/radeon_benchmark.c | 2 +- > drivers/gpu/drm/radeon/radeon_bios.c| 12 ++--- > drivers/gpu/drm/radeon/radeon_clocks.c | 9 --- > drivers/gpu/drm/radeon/radeon_combios.c | 5 +++- > drivers/gpu/drm/radeon/radeon_connectors.c | 2 +- > drivers/gpu/drm/radeon/radeon_cs.c | 10 +-- > drivers/gpu/drm/radeon/radeon_cursor.c | 4 ++- > drivers/gpu/drm/radeon/radeon_device.c | 18 - > drivers/gpu/drm/radeon/radeon_display.c | 21 +-- > drivers/gpu/drm/radeon/radeon_dp_auxch.c| 2 +- > drivers/gpu/drm/radeon/radeon_dp_mst.c | 6 +++-- > drivers/gpu/drm/radeon/radeon_drv.c | 19 - > drivers/gpu/drm/radeon/radeon_encoders.c| 5 +++- > drivers/gpu/drm/radeon/radeon_fb.c | 13 ---
Re: [PATCH v1 0/10] drm/amd: drop use of drmP.h
On Sun, Jun 9, 2019 at 6:08 PM Sam Ravnborg wrote: > > This patcset drop all uses of drm_os_linux.h and > drmP.h in drm/amd/. > The patchset depends on the earlier series removing drmP.h > from drm/radeon. > https://lists.freedesktop.org/archives/dri-devel/2019-June/220969.html > > The only dependency os the patch to drm_debugfs.h: > https://lists.freedesktop.org/archives/dri-devel/2019-June/220971.html > > The removal was done in a number of steps, mainly to easy potential reviews > and to allow some parts to be applied if not everything are OK. > The patches are made on top of drm-misc-next. > > There is a single patch touching drm_print.h - this was needed > to prevent adding include of to a lot of files, > because it is required by one of the macros in drm_print.h. > As this patch only adds an include file, it should be straightforward to > apply. > > All patches are build tested with various configs and various architectures. > > In a few cases the include of header files was re-arranged, but in > general the changes are kept to a minimum. > When adding new include files the different blocks of include > failes are seperated by empty lines. > This account for some of the added lines. Series is: Reviewed-by: Alex Deucher I'm fine to have this go through either drm-misc or my tree. Alex > > Sam > > Sam Ravnborg (10): > drm: fix build errors with drm_print.h > drm/amd: drop dependencies on drm_os_linux.h > drm/amd: drop use of drmp.h in os_types.h > drm/amd: drop use of drmP.h in amdgpu.h > drm/amd: drop use of drmP.h in atom.h > drm/amd: drop use of drmP.h from all header files > drm/amd: drop use of drmP.h in powerplay/ > drm/amd: drop use of drmP.h in display/ > drm/amd: drop use of drmP.h in amdgpu/amdgpu* > drm/amd: drop use of drmP.h in remaining files > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 ++-- > drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 -- > drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 7 +-- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 - > drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 14 +++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c| 4 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 5 - > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 ++ > drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 4 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.c| 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 5 - > drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 - > drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 5 - > drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c| 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 ++ > drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 3 ++- > drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c | 2 +- >
Re: [PATCH v1 0/7] drm/radeon: drop obsolete header files
Hi Alex. > > Series is: > Reviewed-by: Alex Deucher > > Feel free to take it through drm-misc if you want, otherwise, let me > know and I'll take it through my tree. Applied to drm-misc-next. I had accidently left a few empty lines that checkpatch complained about. I fixed these when I applied the patches. Will push it after iy passes my final pre-push build tests. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110795] Unable to install on latest Ubuntu (19.04)
https://bugs.freedesktop.org/show_bug.cgi?id=110795 --- Comment #12 from Rolf --- @Andrew, I'm transitioning from Windows to Linux for software development. Though not new to Linux, I'm new to running it with a head. Perhaps I'm trying to do something unnecessary under Ubuntu? I have an ASUS Radeon VII 16GB installed in this system. The first thing I had to do under Windows was update the driver from AMD's website. I was following suit for Linux. I don't believe I can run the Pro version on my hardware. The downloaded driver installs either. Ubuntu identifies the graphics as AMD® Vega20. Any and all advice would be most appreciated. -- 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 v16 02/16] arm64: untag user pointers in access_ok and __uaccess_mask_ptr
On Mon, Jun 10, 2019 at 07:53:30PM +0100, Catalin Marinas wrote:
> On Mon, Jun 10, 2019 at 11:07:03AM -0700, Kees Cook wrote:
> > On Mon, Jun 10, 2019 at 06:53:27PM +0100, Catalin Marinas wrote:
> > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > > index 3767fb21a5b8..fd191c5b92aa 100644
> > > --- a/arch/arm64/kernel/process.c
> > > +++ b/arch/arm64/kernel/process.c
> > > @@ -552,3 +552,18 @@ void arch_setup_new_exec(void)
> > >
> > > ptrauth_thread_init_user(current);
> > > }
> > > +
> > > +/*
> > > + * Enable the relaxed ABI allowing tagged user addresses into the kernel.
> > > + */
> > > +int untagged_uaddr_set_mode(unsigned long arg)
> > > +{
> > > + if (is_compat_task())
> > > + return -ENOTSUPP;
> > > + if (arg)
> > > + return -EINVAL;
> > > +
> > > + set_thread_flag(TIF_UNTAGGED_UADDR);
> > > +
> > > + return 0;
> > > +}
> >
> > I think this should be paired with a flag clearing in copy_thread(),
> > yes? (i.e. each binary needs to opt in)
>
> It indeed needs clearing though not in copy_thread() as that's used on
> clone/fork but rather in flush_thread(), called on the execve() path.
Ah! Yes, thanks.
> And a note to myself: I think PR_UNTAGGED_ADDR (not UADDR) looks better
> in a uapi header, the user doesn't differentiate between uaddr and
> kaddr.
Good point. I would agree. :)
--
Kees Cook
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dw-hdmi: Fix unwedge crash when no pinctrl entries
On Mon, Jun 10, 2019 at 1:52 PM Douglas Anderson wrote:
>
> In commit 50f9495efe30 ("drm/bridge/synopsys: dw-hdmi: Add "unwedge"
> for ddc bus") I stupidly used IS_ERR() to check for whether we have an
> "unwedge" pinctrl state even though on most flows through the driver
> the unwedge state will just be NULL.
>
> Fix it so that we consistently use NULL for no unwedge state.
>
> Fixes: 50f9495efe30 ("drm/bridge/synopsys: dw-hdmi: Add "unwedge" for ddc
> bus")
> Reported-by: Erico Nunes
> Signed-off-by: Douglas Anderson
Thanks Erico for the report, and Doug for fixing this up quickly, I've applied
the patch to drm-misc-next
Sean
> ---
>
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index f25e091b93c5..5e4e9408d00f 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -251,7 +251,7 @@ static void dw_hdmi_i2c_init(struct dw_hdmi *hdmi)
> static bool dw_hdmi_i2c_unwedge(struct dw_hdmi *hdmi)
> {
> /* If no unwedge state then give up */
> - if (IS_ERR(hdmi->unwedge_state))
> + if (!hdmi->unwedge_state)
> return false;
>
> dev_info(hdmi->dev, "Attempting to unwedge stuck i2c bus\n");
> @@ -2686,11 +2686,13 @@ __dw_hdmi_probe(struct platform_device *pdev,
> hdmi->default_state =
> pinctrl_lookup_state(hdmi->pinctrl,
> "default");
>
> - if (IS_ERR(hdmi->default_state) &&
> - !IS_ERR(hdmi->unwedge_state)) {
> - dev_warn(dev,
> -"Unwedge requires default
> pinctrl\n");
> - hdmi->unwedge_state = ERR_PTR(-ENODEV);
> + if (IS_ERR(hdmi->default_state) ||
> + IS_ERR(hdmi->unwedge_state)) {
> + if (!IS_ERR(hdmi->unwedge_state))
> + dev_warn(dev,
> +"Unwedge requires default
> pinctrl\n");
> + hdmi->default_state = NULL;
> + hdmi->unwedge_state = NULL;
> }
> }
>
> --
> 2.22.0.rc2.383.gf4fbbf30c2-goog
>
Re: [PATCH v3 16/33] docs: locking: convert docs to ReST and rename to *.rst
In data Sunday, June 9, 2019 4:27:06 AM CEST, Mauro Carvalho Chehab ha
scritto:
> Convert the locking documents to ReST and add them to the
> kernel development book where it belongs.
>
> Most of the stuff here is just to make Sphinx to properly
> parse the text file, as they're already in good shape,
> not requiring massive changes in order to be parsed.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - mark literal blocks;
> - adjust title markups.
>
> At its new index.rst, let's add a :orphan: while this is not linked to
> the main index.rst file, in order to avoid build warnings.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/kernel-hacking/locking.rst | 2 +-
> Documentation/locking/index.rst | 24 ++
> ...{lockdep-design.txt => lockdep-design.rst} | 51 ++--
> .../locking/{lockstat.txt => lockstat.rst}| 221 ++
> .../{locktorture.txt => locktorture.rst} | 105 +
> .../{mutex-design.txt => mutex-design.rst}| 26 ++-
> ...t-mutex-design.txt => rt-mutex-design.rst} | 139 ++-
> .../locking/{rt-mutex.txt => rt-mutex.rst}| 30 +--
> .../locking/{spinlocks.txt => spinlocks.rst} | 32 ++-
> ...w-mutex-design.txt => ww-mutex-design.rst} | 82 ---
> Documentation/pi-futex.txt| 2 +-
> .../it_IT/kernel-hacking/locking.rst | 2 +-
Limited to translations/it_IT
Acked-by: Federico Vaga
> drivers/gpu/drm/drm_modeset_lock.c| 2 +-
> include/linux/lockdep.h | 2 +-
> include/linux/mutex.h | 2 +-
> include/linux/rwsem.h | 2 +-
> kernel/locking/mutex.c| 2 +-
> kernel/locking/rtmutex.c | 2 +-
> lib/Kconfig.debug | 4 +-
> 19 files changed, 428 insertions(+), 304 deletions(-)
> create mode 100644 Documentation/locking/index.rst
> rename Documentation/locking/{lockdep-design.txt => lockdep-design.rst}
> (93%) rename Documentation/locking/{lockstat.txt => lockstat.rst} (41%)
> rename Documentation/locking/{locktorture.txt => locktorture.rst} (57%)
> rename Documentation/locking/{mutex-design.txt => mutex-design.rst} (94%)
> rename Documentation/locking/{rt-mutex-design.txt => rt-mutex-design.rst}
> (91%) rename Documentation/locking/{rt-mutex.txt => rt-mutex.rst} (71%)
> rename Documentation/locking/{spinlocks.txt => spinlocks.rst} (89%) rename
> Documentation/locking/{ww-mutex-design.txt => ww-mutex-design.rst} (93%)
>
[PATCH v2 0/4] drm/virtio: Ensure cached capset entries are valid before copying.
From: David Riley v2: Updated barriers. David Riley (4): drm/virtio: Ensure cached capset entries are valid before copying. drm/virtio: Wake up all waiters when capset response comes in. drm/virtio: Fix cache entry creation race. drm/virtio: Add memory barriers for capset cache. drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6 -- drivers/gpu/drm/virtio/virtgpu_vq.c| 26 -- 2 files changed, 28 insertions(+), 4 deletions(-) -- 2.22.0.rc2.383.gf4fbbf30c2-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/virtio: Wake up all waiters when capset response comes in.
From: David Riley If multiple callers occur simultaneously, wake them all up. Signed-off-by: David Riley --- drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index e62fe24b1a2e..da71568adb9a 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -588,7 +588,7 @@ static void virtio_gpu_cmd_capset_cb(struct virtio_gpu_device *vgdev, } } spin_unlock(&vgdev->display_info_lock); - wake_up(&vgdev->resp_wq); + wake_up_all(&vgdev->resp_wq); } static int virtio_get_edid_block(void *data, u8 *buf, -- 2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH v2 4/4] drm/virtio: Add memory barriers for capset cache.
From: David Riley
After data is copied to the cache entry, atomic_set is used indicate
that the data is the entry is valid without appropriate memory barriers.
Similarly the read side was missing the corresponding memory barriers.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +++
drivers/gpu/drm/virtio/virtgpu_vq.c| 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 88c1ed57a3c5..a50495083d6f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -542,6 +542,9 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
if (!ret)
return -EBUSY;
+ /* is_valid check must proceed before copy of the cache entry. */
+ smp_rmb();
+
ptr = cache_ent->caps_cache;
if (copy_to_user((void __user *)(unsigned long)args->addr, ptr, size))
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index dd5ead2541c2..c7a5ca027245 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -583,6 +583,8 @@ static void virtio_gpu_cmd_capset_cb(struct
virtio_gpu_device *vgdev,
cache_ent->id == le32_to_cpu(cmd->capset_id)) {
memcpy(cache_ent->caps_cache, resp->capset_data,
cache_ent->size);
+ /* Copy must occur before is_valid is signalled. */
+ smp_wmb();
atomic_set(&cache_ent->is_valid, 1);
break;
}
--
2.22.0.rc2.383.gf4fbbf30c2-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/virtio: Ensure cached capset entries are valid before copying.
From: David Riley
virtio_gpu_get_caps_ioctl could return success with invalid data if a
second caller to the function occurred after the entry was created in
virtio_gpu_cmd_get_capset but prior to the virtio_gpu_cmd_capset_cb
callback being called. This could leak contents of memory as well
since the caps_cache allocation is done without zeroing.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 949a264985fc..88c1ed57a3c5 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -526,7 +526,6 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
list_for_each_entry(cache_ent, &vgdev->cap_cache, head) {
if (cache_ent->id == args->cap_set_id &&
cache_ent->version == args->cap_set_ver) {
- ptr = cache_ent->caps_cache;
spin_unlock(&vgdev->display_info_lock);
goto copy_exit;
}
@@ -537,6 +536,7 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
virtio_gpu_cmd_get_capset(vgdev, found_valid, args->cap_set_ver,
&cache_ent);
+copy_exit:
ret = wait_event_timeout(vgdev->resp_wq,
atomic_read(&cache_ent->is_valid), 5 * HZ);
if (!ret)
@@ -544,7 +544,6 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
ptr = cache_ent->caps_cache;
-copy_exit:
if (copy_to_user((void __user *)(unsigned long)args->addr, ptr, size))
return -EFAULT;
--
2.22.0.rc2.383.gf4fbbf30c2-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/virtio: Fix cache entry creation race.
From: David Riley
virtio_gpu_cmd_get_capset would check for the existence of an entry
under lock. If it was not found, it would unlock and call
virtio_gpu_cmd_get_capset to create a new entry. The new entry would
be added it to the list without checking if it was added by another
task during the period where the lock was not held resulting in
duplicate entries.
Compounding this issue, virtio_gpu_cmd_capset_cb would stop iterating
after find the first matching entry. Multiple callbacks would modify
the first entry, but any subsequent entries and their associated waiters
would eventually timeout since they don't become valid, also wasting
memory along the way.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index da71568adb9a..dd5ead2541c2 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -684,8 +684,11 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device
*vgdev,
struct virtio_gpu_vbuffer *vbuf;
int max_size;
struct virtio_gpu_drv_cap_cache *cache_ent;
+ struct virtio_gpu_drv_cap_cache *search_ent;
void *resp_buf;
+ *cache_p = NULL;
+
if (idx >= vgdev->num_capsets)
return -EINVAL;
@@ -716,9 +719,26 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device
*vgdev,
atomic_set(&cache_ent->is_valid, 0);
cache_ent->size = max_size;
spin_lock(&vgdev->display_info_lock);
- list_add_tail(&cache_ent->head, &vgdev->cap_cache);
+ /* Search while under lock in case it was added by another task. */
+ list_for_each_entry(search_ent, &vgdev->cap_cache, head) {
+ if (search_ent->id == vgdev->capsets[idx].id &&
+ search_ent->version == version) {
+ *cache_p = search_ent;
+ break;
+ }
+ }
+ if (!*cache_p)
+ list_add_tail(&cache_ent->head, &vgdev->cap_cache);
spin_unlock(&vgdev->display_info_lock);
+ if (*cache_p) {
+ /* Entry was found, so free everything that was just created. */
+ kfree(resp_buf);
+ kfree(cache_ent->caps_cache);
+ kfree(cache_ent);
+ return 0;
+ }
+
cmd_p = virtio_gpu_alloc_cmd_resp
(vgdev, &virtio_gpu_cmd_capset_cb, &vbuf, sizeof(*cmd_p),
sizeof(struct virtio_gpu_resp_capset) + max_size,
--
2.22.0.rc2.383.gf4fbbf30c2-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110795] Unable to install on latest Ubuntu (19.04)
https://bugs.freedesktop.org/show_bug.cgi?id=110795 --- Comment #13 from Alex Deucher --- (In reply to Rolf from comment #12) > @Andrew, I'm transitioning from Windows to Linux for software development. > Though not new to Linux, I'm new to running it with a head. Perhaps I'm > trying to do something unnecessary under Ubuntu? I have an ASUS Radeon VII > 16GB installed in this system. The first thing I had to do under Windows was > update the driver from AMD's website. I was following suit for Linux. In general, on Linux most users use the in box drivers or a ppa (if you want bleeding edge) rather than the packaged drivers. The packaged drivers from AMD are mainly there to support workstation customers or users that want to use an older enterprise distro which may not have support in the box. -- 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 110783] Mesa 19.1 rc crashing MPV with VAAPI
https://bugs.freedesktop.org/show_bug.cgi?id=110783 --- Comment #2 from Matt Turner --- Looks like this was reported as a Gentoo bug as well (https://bugs.gentoo.org/686252) Have you tried bisecting? -- 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 v1 0/10] drm/amd: drop use of drmP.h
Hi Alex. > > Series is: > Reviewed-by: Alex Deucher > I'm fine to have this go through either drm-misc or my tree. Thanks, pushed to drm-misc-next. I ended up with a merge error in drm-tip that I dunno how to work with. Help would be appreciated. (I also wrote this on irc) It is getting late here, I hope someone has fixed it tomorrow morning. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v16 16/16] selftests, arm64: add a selftest for passing tagged pointers to kernel
On 6/7/19 9:56 PM, Kees Cook wrote: On Mon, Jun 03, 2019 at 06:55:18PM +0200, Andrey Konovalov wrote: This patch is a part of a series that extends arm64 kernel ABI to allow to pass tagged user pointers (with the top byte set to something else other than 0x00) as syscall arguments. This patch adds a simple test, that calls the uname syscall with a tagged user pointer as an argument. Without the kernel accepting tagged user pointers the test fails with EFAULT. Signed-off-by: Andrey Konovalov I'm adding Shuah to CC in case she has some suggestions about the new selftest. Thanks Kees. Reviewed-by: Kees Cook -Kees Looks good to me. Acked-by: Shuah Khan thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x
https://bugs.freedesktop.org/show_bug.cgi?id=110781 --- Comment #62 from Richard Thier --- Added a blog post about the whole issue and its solving process here: http://ballmerpeak.web.elte.hu/devblog/debugging-mesa-and-the-linux-3d-graphics-stack.html I have linked to this bug report and every other place and people where communications were done for solving this slowdown issue. I just wanted to put things together as it might be valuable for others wanting to do similar things - I was and still is a rookie for these things after all. -- 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 1/2] dt-bindings: pwm-backlight: Add 'max-brightness' property
Add an optional 'max-brightness' property, which is used to specify the number of brightness levels (max-brightness + 1) when the node has no 'brightness-levels' table. Signed-off-by: Matthias Kaehlcke --- .../devicetree/bindings/leds/backlight/pwm-backlight.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt index 64fa2fbd98c9..98f4ba626054 100644 --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt @@ -27,6 +27,9 @@ Optional properties: resolution pwm duty cycle can be used without having to list out every possible value in the brightness-level array. + - max-brightness: Maximum brightness value. Used to specify the number of +brightness levels (max-brightness + 1) when the node +has no 'brightness-levels' table. [0]: Documentation/devicetree/bindings/pwm/pwm.txt [1]: Documentation/devicetree/bindings/gpio/gpio.txt -- 2.22.0.rc2.383.gf4fbbf30c2-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] backlight: pwm_bl: Get number of brightness levels for CIE 1931 from the device tree
Commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
linearly to human eye") uses pwm_period / hweight32(pwm_period) as
as heuristic to determine the number of brightness levels when the DT
doesn't provide a brightness level table. This heuristic is broken
and can result in excessively large brightness tables.
Instead of using the heuristic try to retrieve the number of
brightness levels from the device tree (property 'max-brightness'
+ 1). If the value is not specified use a default of 256 levels.
Fixes: 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly to
human eye")
Signed-off-by: Matthias Kaehlcke
---
drivers/video/backlight/pwm_bl.c | 59
1 file changed, 21 insertions(+), 38 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index fb45f866b923..2913cbe9cfcb 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -194,38 +194,19 @@ int pwm_backlight_brightness_default(struct device *dev,
struct platform_pwm_backlight_data *data,
unsigned int period)
{
- unsigned int counter = 0;
- unsigned int i, n;
+ unsigned int i;
+ unsigned int nlevels = data->max_brightness + 1;
u64 retval;
- /*
-* Count the number of bits needed to represent the period number. The
-* number of bits is used to calculate the number of levels used for the
-* brightness-levels table, the purpose of this calculation is have a
-* pre-computed table with enough levels to get linear brightness
-* perception. The period is divided by the number of bits so for a
-* 8-bit PWM we have 255 / 8 = 32 brightness levels or for a 16-bit PWM
-* we have 65535 / 16 = 4096 brightness levels.
-*
-* Note that this method is based on empirical testing on different
-* devices with PWM of 8 and 16 bits of resolution.
-*/
- n = period;
- while (n) {
- counter += n % 2;
- n >>= 1;
- }
-
- data->max_brightness = DIV_ROUND_UP(period, counter);
- data->levels = devm_kcalloc(dev, data->max_brightness,
+ data->levels = devm_kcalloc(dev, nlevels,
sizeof(*data->levels), GFP_KERNEL);
if (!data->levels)
return -ENOMEM;
/* Fill the table using the cie1931 algorithm */
- for (i = 0; i < data->max_brightness; i++) {
+ for (i = 0; i < nlevels; i++) {
retval = cie1931((i * PWM_LUMINANCE_SCALE) /
-data->max_brightness, PWM_LUMINANCE_SCALE) *
+nlevels, PWM_LUMINANCE_SCALE) *
period;
retval = DIV_ROUND_CLOSEST_ULL(retval, PWM_LUMINANCE_SCALE);
if (retval > UINT_MAX)
@@ -233,8 +214,7 @@ int pwm_backlight_brightness_default(struct device *dev,
data->levels[i] = (unsigned int)retval;
}
- data->dft_brightness = data->max_brightness / 2;
- data->max_brightness--;
+ data->dft_brightness = nlevels / 2;
return 0;
}
@@ -272,8 +252,13 @@ static int pwm_backlight_parse_dt(struct device *dev,
* set a default table of brightness levels will be used.
*/
prop = of_find_property(node, "brightness-levels", &length);
- if (!prop)
+ if (!prop) {
+ if (of_property_read_u32(node, "max-brightness",
+&data->max_brightness))
+ data->max_brightness = 255;
+
return 0;
+ }
data->max_brightness = length / sizeof(u32);
@@ -565,13 +550,10 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
pb->levels = data->levels;
}
- } else if (!data->max_brightness) {
+ } else if (node) {
/*
-* If no brightness levels are provided and max_brightness is
-* not set, use the default brightness table. For the DT case,
-* max_brightness is set to 0 when brightness levels is not
-* specified. For the non-DT case, max_brightness is usually
-* set to some value.
+* If no brightness levels are provided use the default
+* brightness table.
*/
/* Get the PWM period (in nanoseconds) */
@@ -591,12 +573,13 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
pb->levels = data->levels;
}
- } else {
- /*
-* That only happens for the non-DT case, where platform data
-* sets the max_brightness value.
-*/
+ } else if (data->max_brightness) {
+
[Bug 110885] [OverDrive] Add option to change acoustic limit
https://bugs.freedesktop.org/show_bug.cgi?id=110885 Bug ID: 110885 Summary: [OverDrive] Add option to change acoustic limit Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: magis...@gmail.com Please add the ability to change the acoustic limit. My RX580 has an acoustic limit of 1360 MHz, and even with slight overclocking (1400 MHz) it becomes really noisy on high load. -- 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
[RESEND PATCH v3 0/3] Improve the dma-buf tracking
Currently, all dma-bufs share the same anonymous inode. While we can count
how many dma-buf fds or mappings a process has, we can't get the size of
the backing buffers or tell if two entries point to the same dma-buf. And
in debugfs, we can get a per-buffer breakdown of size and reference count,
but can't tell which processes are actually holding the references to each
buffer.
To resolve the issue above and provide better method for userspace to track
the dma-buf usage across different processes, the following changes are
proposed in dma-buf kernel side. First of all, replace the singleton inode
inside the dma-buf subsystem with a mini-filesystem, and assign each
dma-buf a unique inode out of this filesystem. With this change, calling
stat(2) on each entry gives the caller a unique ID (st_ino), the buffer's
size (st_size), and even the number of pages assigned to each dma-buffer.
Secoundly, add the inode information to /sys/kernel/debug/dma_buf/bufinfo
so in the case where a buffer is mmap()ed into a process’s address space
but all remaining fds have been closed, we can still get the dma-buf
information and try to accociate it with the process by searching the
proc/pid/maps and looking for the corresponding inode number exposed in
dma-buf debug fs. Thirdly, created an ioctl to assign names to dma-bufs
which lets userspace assign short names (e.g., "CAMERA") to buffers. This
information can be extremely helpful for tracking and accounting shared
buffers based on their usage and original purpose. Last but not least, add
dma-buf information to /proc/pid/fdinfo by adding a show_fdinfo() handler
to dma_buf_file_operations. The handler will print the file_count and name
of each buffer.
Change in v2:
* Add a check to prevent changing dma-buf name when it is attached to
devices.
* Fixed some compile warnings
Change in v3:
* Removed the GET_DMA_BUF_NAME ioctls, add the dma_buf pointer to dentry
d_fsdata so the name can be displayed in proc/pid/maps and
proc/pid/map_files.
Greg Hackmann (3):
dma-buf: give each buffer a full-fledged inode
dma-buf: add DMA_BUF_{GET,SET}_NAME ioctls
dma-buf: add show_fdinfo handler
drivers/dma-buf/dma-buf.c| 122 +--
include/linux/dma-buf.h | 5 +-
include/uapi/linux/dma-buf.h | 3 +
include/uapi/linux/magic.h | 1 +
4 files changed, 124 insertions(+), 7 deletions(-)
--
2.21.0.1020.gf2820cf01a-goog
[RESEND PATCH v3 3/3] dma-buf: add show_fdinfo handler
From: Greg Hackmann
The show_fdinfo handler exports the same information available through
debugfs on a per-buffer basis.
Signed-off-by: Greg Hackmann
Signed-off-by: Chenbo Feng
---
drivers/dma-buf/dma-buf.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c1da5f9ce44d..c4efc272fc34 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -381,6 +381,20 @@ static long dma_buf_ioctl(struct file *file,
}
}
+static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file)
+{
+ struct dma_buf *dmabuf = file->private_data;
+
+ seq_printf(m, "size:\t%zu\n", dmabuf->size);
+ /* Don't count the temporary reference taken inside procfs seq_show */
+ seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
+ seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name);
+ mutex_lock(&dmabuf->lock);
+ if (dmabuf->name)
+ seq_printf(m, "name:\t%s\n", dmabuf->name);
+ mutex_unlock(&dmabuf->lock);
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
@@ -390,6 +404,7 @@ static const struct file_operations dma_buf_fops = {
#ifdef CONFIG_COMPAT
.compat_ioctl = dma_buf_ioctl,
#endif
+ .show_fdinfo= dma_buf_show_fdinfo,
};
/*
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[RESEND PATCH v3 2/3] dma-buf: add DMA_BUF_{GET,SET}_NAME ioctls
From: Greg Hackmann
This patch adds complimentary DMA_BUF_SET_NAME and DMA_BUF_GET_NAME
ioctls, which lets userspace processes attach a free-form name to each
buffer.
This information can be extremely helpful for tracking and accounting
shared buffers. For example, on Android, we know what each buffer will
be used for at allocation time: GL, multimedia, camera, etc. The
userspace allocator can use DMA_BUF_SET_NAME to associate that
information with the buffer, so we can later give developers a
breakdown of how much memory they're allocating for graphics, camera,
etc.
Signed-off-by: Greg Hackmann
Signed-off-by: Chenbo Feng
---
drivers/dma-buf/dma-buf.c| 49 +---
include/linux/dma-buf.h | 5 +++-
include/uapi/linux/dma-buf.h | 3 +++
3 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ffd5a2ad7d6f..c1da5f9ce44d 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -48,8 +48,24 @@ struct dma_buf_list {
static struct dma_buf_list db_list;
+static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
+{
+ struct dma_buf *dmabuf;
+ char name[DMA_BUF_NAME_LEN];
+ size_t ret = 0;
+
+ dmabuf = dentry->d_fsdata;
+ mutex_lock(&dmabuf->lock);
+ if (dmabuf->name)
+ ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
+ mutex_unlock(&dmabuf->lock);
+
+ return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
+dentry->d_name.name, ret > 0 ? name : "");
+}
+
static const struct dentry_operations dma_buf_dentry_ops = {
- .d_dname = simple_dname,
+ .d_dname = dmabuffs_dname,
};
static struct vfsmount *dma_buf_mnt;
@@ -297,6 +313,27 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
return events;
}
+static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf)
+{
+ char *name = strndup_user(buf, DMA_BUF_NAME_LEN);
+ long ret = 0;
+
+ if (IS_ERR(name))
+ return PTR_ERR(name);
+
+ mutex_lock(&dmabuf->lock);
+ if (!list_empty(&dmabuf->attachments)) {
+ ret = -EBUSY;
+ goto out_unlock;
+ }
+ kfree(dmabuf->name);
+ dmabuf->name = name;
+
+out_unlock:
+ mutex_unlock(&dmabuf->lock);
+ return ret;
+}
+
static long dma_buf_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
@@ -335,6 +372,10 @@ static long dma_buf_ioctl(struct file *file,
ret = dma_buf_begin_cpu_access(dmabuf, direction);
return ret;
+
+ case DMA_BUF_SET_NAME:
+ return dma_buf_set_name(dmabuf, (const char __user *)arg);
+
default:
return -ENOTTY;
}
@@ -376,6 +417,7 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf,
int flags)
goto err_alloc_file;
file->f_flags = flags & (O_ACCMODE | O_NONBLOCK);
file->private_data = dmabuf;
+ file->f_path.dentry->d_fsdata = dmabuf;
return file;
@@ -1082,12 +1124,13 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
continue;
}
- seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\n",
+ seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\t%s\n",
buf_obj->size,
buf_obj->file->f_flags, buf_obj->file->f_mode,
file_count(buf_obj->file),
buf_obj->exp_name,
- file_inode(buf_obj->file)->i_ino);
+ file_inode(buf_obj->file)->i_ino,
+ buf_obj->name ?: "");
robj = buf_obj->resv;
while (true) {
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 58725f890b5b..582998e19df6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -255,10 +255,12 @@ struct dma_buf_ops {
* @file: file pointer used for sharing buffers across, and for refcounting.
* @attachments: list of dma_buf_attachment that denotes all devices attached.
* @ops: dma_buf_ops associated with this buffer object.
- * @lock: used internally to serialize list manipulation, attach/detach and
vmap/unmap
+ * @lock: used internally to serialize list manipulation, attach/detach and
+ *vmap/unmap, and accesses to name
* @vmapping_counter: used internally to refcnt the vmaps
* @vmap_ptr: the current vmap ptr if vmapping_counter > 0
* @exp_name: name of the exporter; useful for debugging.
+ * @name: userspace-provided name; useful for accounting and debugging.
* @owner: pointer to exporter module; used for refcounting when exporter is a
* kernel module.
* @list_node: node for dma_buf accounting and
[RESEND PATCH v3 3/3] dma-buf: add show_fdinfo handler
From: Greg Hackmann
The show_fdinfo handler exports the same information available through
debugfs on a per-buffer basis.
Signed-off-by: Greg Hackmann
Signed-off-by: Chenbo Feng
---
drivers/dma-buf/dma-buf.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c1da5f9ce44d..c4efc272fc34 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -381,6 +381,20 @@ static long dma_buf_ioctl(struct file *file,
}
}
+static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file)
+{
+ struct dma_buf *dmabuf = file->private_data;
+
+ seq_printf(m, "size:\t%zu\n", dmabuf->size);
+ /* Don't count the temporary reference taken inside procfs seq_show */
+ seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
+ seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name);
+ mutex_lock(&dmabuf->lock);
+ if (dmabuf->name)
+ seq_printf(m, "name:\t%s\n", dmabuf->name);
+ mutex_unlock(&dmabuf->lock);
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
@@ -390,6 +404,7 @@ static const struct file_operations dma_buf_fops = {
#ifdef CONFIG_COMPAT
.compat_ioctl = dma_buf_ioctl,
#endif
+ .show_fdinfo= dma_buf_show_fdinfo,
};
/*
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[Bug 110885] [OverDrive] Add option to change acoustic limit
https://bugs.freedesktop.org/show_bug.cgi?id=110885 Andre Klapper changed: What|Removed |Added Severity|normal |enhancement -- 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
[RESEND PATCH v3 0/3] Improve the dma-buf tracking
Currently, all dma-bufs share the same anonymous inode. While we can count
how many dma-buf fds or mappings a process has, we can't get the size of
the backing buffers or tell if two entries point to the same dma-buf. And
in debugfs, we can get a per-buffer breakdown of size and reference count,
but can't tell which processes are actually holding the references to each
buffer.
To resolve the issue above and provide better method for userspace to track
the dma-buf usage across different processes, the following changes are
proposed in dma-buf kernel side. First of all, replace the singleton inode
inside the dma-buf subsystem with a mini-filesystem, and assign each
dma-buf a unique inode out of this filesystem. With this change, calling
stat(2) on each entry gives the caller a unique ID (st_ino), the buffer's
size (st_size), and even the number of pages assigned to each dma-buffer.
Secoundly, add the inode information to /sys/kernel/debug/dma_buf/bufinfo
so in the case where a buffer is mmap()ed into a process’s address space
but all remaining fds have been closed, we can still get the dma-buf
information and try to accociate it with the process by searching the
proc/pid/maps and looking for the corresponding inode number exposed in
dma-buf debug fs. Thirdly, created an ioctl to assign names to dma-bufs
which lets userspace assign short names (e.g., "CAMERA") to buffers. This
information can be extremely helpful for tracking and accounting shared
buffers based on their usage and original purpose. Last but not least, add
dma-buf information to /proc/pid/fdinfo by adding a show_fdinfo() handler
to dma_buf_file_operations. The handler will print the file_count and name
of each buffer.
Change in v2:
* Add a check to prevent changing dma-buf name when it is attached to
devices.
* Fixed some compile warnings
Change in v3:
* Removed the GET_DMA_BUF_NAME ioctls, add the dma_buf pointer to dentry
d_fsdata so the name can be displayed in proc/pid/maps and
proc/pid/map_files.
Greg Hackmann (3):
dma-buf: give each buffer a full-fledged inode
dma-buf: add DMA_BUF_{GET,SET}_NAME ioctls
dma-buf: add show_fdinfo handler
drivers/dma-buf/dma-buf.c| 122 +--
include/linux/dma-buf.h | 5 +-
include/uapi/linux/dma-buf.h | 3 +
include/uapi/linux/magic.h | 1 +
4 files changed, 124 insertions(+), 7 deletions(-)
--
2.21.0.1020.gf2820cf01a-goog
[RESEND PATCH v3 2/3] dma-buf: add DMA_BUF_{GET,SET}_NAME ioctls
From: Greg Hackmann
This patch adds complimentary DMA_BUF_SET_NAME and DMA_BUF_GET_NAME
ioctls, which lets userspace processes attach a free-form name to each
buffer.
This information can be extremely helpful for tracking and accounting
shared buffers. For example, on Android, we know what each buffer will
be used for at allocation time: GL, multimedia, camera, etc. The
userspace allocator can use DMA_BUF_SET_NAME to associate that
information with the buffer, so we can later give developers a
breakdown of how much memory they're allocating for graphics, camera,
etc.
Signed-off-by: Greg Hackmann
Signed-off-by: Chenbo Feng
---
drivers/dma-buf/dma-buf.c| 49 +---
include/linux/dma-buf.h | 5 +++-
include/uapi/linux/dma-buf.h | 3 +++
3 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ffd5a2ad7d6f..c1da5f9ce44d 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -48,8 +48,24 @@ struct dma_buf_list {
static struct dma_buf_list db_list;
+static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
+{
+ struct dma_buf *dmabuf;
+ char name[DMA_BUF_NAME_LEN];
+ size_t ret = 0;
+
+ dmabuf = dentry->d_fsdata;
+ mutex_lock(&dmabuf->lock);
+ if (dmabuf->name)
+ ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
+ mutex_unlock(&dmabuf->lock);
+
+ return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
+dentry->d_name.name, ret > 0 ? name : "");
+}
+
static const struct dentry_operations dma_buf_dentry_ops = {
- .d_dname = simple_dname,
+ .d_dname = dmabuffs_dname,
};
static struct vfsmount *dma_buf_mnt;
@@ -297,6 +313,27 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
return events;
}
+static long dma_buf_set_name(struct dma_buf *dmabuf, const char __user *buf)
+{
+ char *name = strndup_user(buf, DMA_BUF_NAME_LEN);
+ long ret = 0;
+
+ if (IS_ERR(name))
+ return PTR_ERR(name);
+
+ mutex_lock(&dmabuf->lock);
+ if (!list_empty(&dmabuf->attachments)) {
+ ret = -EBUSY;
+ goto out_unlock;
+ }
+ kfree(dmabuf->name);
+ dmabuf->name = name;
+
+out_unlock:
+ mutex_unlock(&dmabuf->lock);
+ return ret;
+}
+
static long dma_buf_ioctl(struct file *file,
unsigned int cmd, unsigned long arg)
{
@@ -335,6 +372,10 @@ static long dma_buf_ioctl(struct file *file,
ret = dma_buf_begin_cpu_access(dmabuf, direction);
return ret;
+
+ case DMA_BUF_SET_NAME:
+ return dma_buf_set_name(dmabuf, (const char __user *)arg);
+
default:
return -ENOTTY;
}
@@ -376,6 +417,7 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf,
int flags)
goto err_alloc_file;
file->f_flags = flags & (O_ACCMODE | O_NONBLOCK);
file->private_data = dmabuf;
+ file->f_path.dentry->d_fsdata = dmabuf;
return file;
@@ -1082,12 +1124,13 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
continue;
}
- seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\n",
+ seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\t%s\n",
buf_obj->size,
buf_obj->file->f_flags, buf_obj->file->f_mode,
file_count(buf_obj->file),
buf_obj->exp_name,
- file_inode(buf_obj->file)->i_ino);
+ file_inode(buf_obj->file)->i_ino,
+ buf_obj->name ?: "");
robj = buf_obj->resv;
while (true) {
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 58725f890b5b..582998e19df6 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -255,10 +255,12 @@ struct dma_buf_ops {
* @file: file pointer used for sharing buffers across, and for refcounting.
* @attachments: list of dma_buf_attachment that denotes all devices attached.
* @ops: dma_buf_ops associated with this buffer object.
- * @lock: used internally to serialize list manipulation, attach/detach and
vmap/unmap
+ * @lock: used internally to serialize list manipulation, attach/detach and
+ *vmap/unmap, and accesses to name
* @vmapping_counter: used internally to refcnt the vmaps
* @vmap_ptr: the current vmap ptr if vmapping_counter > 0
* @exp_name: name of the exporter; useful for debugging.
+ * @name: userspace-provided name; useful for accounting and debugging.
* @owner: pointer to exporter module; used for refcounting when exporter is a
* kernel module.
* @list_node: node for dma_buf accounting and
[PATCH 2/5] dt-bindings: display/panel: Expand rotation documentation
This adds to the rotation documentation to explain how drivers should
use the property and gives an example of the property in a devicetree
node.
Signed-off-by: Derek Basehore
---
.../bindings/display/panel/panel.txt | 32 +++
1 file changed, 32 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt
b/Documentation/devicetree/bindings/display/panel/panel.txt
index e2e6867852b8..f35d62d933fc 100644
--- a/Documentation/devicetree/bindings/display/panel/panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/panel.txt
@@ -2,3 +2,35 @@ Common display properties
-
- rotation:Display rotation in degrees counter clockwise (0,90,180,270)
+
+Property read from the device tree using of of_drm_get_panel_orientation
+
+The panel driver may apply the rotation at the TCON level, which will
+make the panel look like it isn't rotated to the kernel and any other
+software.
+
+If not, a panel orientation property should be added through the SoC
+vendor DRM code using the drm_connector_init_panel_orientation_property
+function.
+
+Example:
+ panel: panel@0 {
+ compatible = "boe,himax8279d8p";
+ reg = <0>;
+ enable-gpios = <&pio 45 0>;
+ pp33-gpios = <&pio 35 0>;
+ pp18-gpios = <&pio 36 0>;
+ pinctrl-names = "default", "state_3300mv", "state_1800mv";
+ pinctrl-0 = <&panel_pins_default>;
+ pinctrl-1 = <&panel_pins_3300mv>;
+ pinctrl-2 = <&panel_pins_1800mv>;
+ backlight = <&backlight_lcd0>;
+ rotation = <180>;
+ status = "okay";
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH 4/5] drm/connector: Split out orientation quirk detection
This removes the orientation quirk detection from the code to add
an orientation property to a panel. This is used only for legacy x86
systems, yet we'd like to start using this on device tree systems
where quirk detection like this is not needed.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_connector.c | 16
drivers/gpu/drm/i915/vlv_dsi.c | 13 +
include/drm/drm_connector.h | 2 +-
3 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e17586aaa80f..58a09b65028b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1894,31 +1894,23 @@ EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
* drm_connector_init_panel_orientation_property -
* initialize the connecters panel_orientation property
* @connector: connector for which to init the panel-orientation property.
- * @width: width in pixels of the panel, used for panel quirk detection
- * @height: height in pixels of the panel, used for panel quirk detection
*
* This function should only be called for built-in panels, after setting
* connector->display_info.panel_orientation first (if known).
*
- * This function will check for platform specific (e.g. DMI based) quirks
- * overriding display_info.panel_orientation first, then if panel_orientation
- * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
- * "panel orientation" property to the connector.
+ * This function will check if the panel_orientation is not
+ * DRM_MODE_PANEL_ORIENTATION_UNKNOWN. If not, it will attach the "panel
+ * orientation" property to the connector.
*
* Returns:
* Zero on success, negative errno on failure.
*/
int drm_connector_init_panel_orientation_property(
- struct drm_connector *connector, int width, int height)
+ struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct drm_display_info *info = &connector->display_info;
struct drm_property *prop;
- int orientation_quirk;
-
- orientation_quirk = drm_get_panel_orientation_quirk(width, height);
- if (orientation_quirk != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
- info->panel_orientation = orientation_quirk;
if (info->panel_orientation == DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
return 0;
diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index bfe2891eac37..113129996530 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -1650,6 +1650,7 @@ static void intel_dsi_add_properties(struct
intel_connector *connector)
if (connector->panel.fixed_mode) {
u32 allowed_scalers;
+ int orientation;
allowed_scalers = BIT(DRM_MODE_SCALE_ASPECT) |
BIT(DRM_MODE_SCALE_FULLSCREEN);
if (!HAS_GMCH(dev_priv))
@@ -1660,12 +1661,16 @@ static void intel_dsi_add_properties(struct
intel_connector *connector)
connector->base.state->scaling_mode = DRM_MODE_SCALE_ASPECT;
- connector->base.display_info.panel_orientation =
- vlv_dsi_get_panel_orientation(connector);
- drm_connector_init_panel_orientation_property(
- &connector->base,
+ orientation = drm_get_panel_orientation_quirk(
connector->panel.fixed_mode->hdisplay,
connector->panel.fixed_mode->vdisplay);
+ if (orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN)
+ connector->display_info.panel_orientation = orientation;
+ else
+ connector->display_info.panel_orientation =
+ intel_dsi_get_panel_orientation(connector);
+
+ drm_connector_init_panel_orientation_property(&connector->base);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 47e749b74e5f..c2992f7a0dd5 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1370,7 +1370,7 @@ void drm_connector_set_link_status_property(struct
drm_connector *connector,
void drm_connector_set_vrr_capable_property(
struct drm_connector *connector, bool capable);
int drm_connector_init_panel_orientation_property(
- struct drm_connector *connector, int width, int height);
+ struct drm_connector *connector);
int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
int min, int max);
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH 5/5] drm/mtk: add panel orientation property
This inits the panel orientation property for the mediatek dsi driver
if the panel orientation (connector.display_info.panel_orientation) is
not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 4a0b9150a7bb..08ffdc7526dd 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -782,10 +782,18 @@ static int mtk_dsi_create_connector(struct drm_device
*drm, struct mtk_dsi *dsi)
DRM_ERROR("Failed to attach panel to drm\n");
goto err_connector_cleanup;
}
+
+ ret = drm_connector_init_panel_orientation_property(&dsi->conn);
+ if (ret) {
+ DRM_ERROR("Failed to init panel orientation\n");
+ goto err_panel_detach;
+ }
}
return 0;
+err_panel_detach:
+ drm_panel_detach(dsi->panel);
err_connector_cleanup:
drm_connector_cleanup(&dsi->conn);
return ret;
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH 1/5] drm/panel: Add helper for reading DT rotation
This adds a helper function for reading the rotation (panel
orientation) from the device tree.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 41 +
include/drm/drm_panel.h | 7 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index dbd5b873e8f2..3b689ce4a51a 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -172,6 +172,47 @@ struct drm_panel *of_drm_find_panel(const struct
device_node *np)
return ERR_PTR(-EPROBE_DEFER);
}
EXPORT_SYMBOL(of_drm_find_panel);
+
+/**
+ * of_drm_get_panel_orientation - look up the rotation of the panel using a
+ * device tree node
+ * @np: device tree node of the panel
+ * @orientation: orientation enum to be filled in
+ *
+ * Looks up the rotation of a panel in the device tree. The rotation in the
+ * device tree is counter clockwise.
+ *
+ * Return: 0 when a valid rotation value (0, 90, 180, or 270) is read or the
+ * rotation property doesn't exist. -EERROR otherwise.
+ */
+int of_drm_get_panel_orientation(const struct device_node *np, int
*orientation)
+{
+ int rotation, ret;
+
+ ret = of_property_read_u32(np, "rotation", &rotation);
+ if (ret == -EINVAL) {
+ /* Don't return an error if there's no rotation property. */
+ *orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
+ return 0;
+ }
+
+ if (ret < 0)
+ return ret;
+
+ if (rotation == 0)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
+ else if (rotation == 90)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+ else if (rotation == 180)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+ else if (rotation == 270)
+ *orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+EXPORT_SYMBOL(of_drm_get_panel_orientation);
#endif
MODULE_AUTHOR("Thierry Reding ");
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 8c738c0e6e9f..13631b2efbaa 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -197,11 +197,18 @@ int drm_panel_detach(struct drm_panel *panel);
#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
struct drm_panel *of_drm_find_panel(const struct device_node *np);
+int of_drm_get_panel_orientation(const struct device_node *np,
+int *orientation);
#else
static inline struct drm_panel *of_drm_find_panel(const struct device_node *np)
{
return ERR_PTR(-ENODEV);
}
+int of_drm_get_panel_orientation(const struct device_node *np,
+int *orientation)
+{
+ return -ENODEV;
+}
#endif
#endif
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH 3/5] drm/panel: Add attach/detach callbacks
This adds the attach/detach callbacks. These are for setting up
internal state for the connector/panel pair that can't be done at
probe (since the connector doesn't exist) and which don't need to be
repeatedly done for every get/modes, prepare, or enable callback.
Values such as the panel orientation, and display size can be filled
in for the connector.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 14 ++
include/drm/drm_panel.h | 4
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 3b689ce4a51a..72f67678d9d5 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -104,12 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
*/
int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
{
+ int ret;
+
if (panel->connector)
return -EBUSY;
panel->connector = connector;
panel->drm = connector->dev;
+ if (panel->funcs->attach) {
+ ret = panel->funcs->attach(panel);
+ if (ret < 0) {
+ panel->connector = NULL;
+ panel->drm = NULL;
+ return ret;
+ }
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_panel_attach);
@@ -128,6 +139,9 @@ EXPORT_SYMBOL(drm_panel_attach);
*/
int drm_panel_detach(struct drm_panel *panel)
{
+ if (panel->funcs->detach)
+ panel->funcs->detach(panel);
+
panel->connector = NULL;
panel->drm = NULL;
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 13631b2efbaa..e136e3a3c996 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -37,6 +37,8 @@ struct display_timing;
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
* @unprepare: turn off panel
+ * @detach: detach panel->connector (clear internal state, etc.)
+ * @attach: attach panel->connector (update internal state, etc.)
* @prepare: turn on panel and perform set up
* @enable: enable panel (turn on back light, etc.)
* @get_modes: add modes to the connector that the panel is attached to and
@@ -70,6 +72,8 @@ struct display_timing;
struct drm_panel_funcs {
int (*disable)(struct drm_panel *panel);
int (*unprepare)(struct drm_panel *panel);
+ void (*detach)(struct drm_panel *panel);
+ int (*attach)(struct drm_panel *panel);
int (*prepare)(struct drm_panel *panel);
int (*enable)(struct drm_panel *panel);
int (*get_modes)(struct drm_panel *panel);
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH 0/5] Panel rotation patches
This adds the plumbing for reading panel rotation from the devicetree and sets up adding a panel property for the panel orientation on Mediatek SoCs when a rotation is present. Derek Basehore (5): drm/panel: Add helper for reading DT rotation dt-bindings: display/panel: Expand rotation documentation drm/panel: Add attach/detach callbacks drm/connector: Split out orientation quirk detection drm/mtk: add panel orientation property .../bindings/display/panel/panel.txt | 32 +++ drivers/gpu/drm/drm_connector.c | 16 ++ drivers/gpu/drm/drm_panel.c | 55 +++ drivers/gpu/drm/i915/vlv_dsi.c| 13 +++-- drivers/gpu/drm/mediatek/mtk_dsi.c| 8 +++ include/drm/drm_connector.h | 2 +- include/drm/drm_panel.h | 11 7 files changed, 120 insertions(+), 17 deletions(-) -- 2.22.0.rc2.383.gf4fbbf30c2-goog
[RESEND PATCH v3 1/3] dma-buf: give each buffer a full-fledged inode
From: Greg Hackmann
By traversing /proc/*/fd and /proc/*/map_files, processes with CAP_ADMIN
can get a lot of fine-grained data about how shmem buffers are shared
among processes. stat(2) on each entry gives the caller a unique
ID (st_ino), the buffer's size (st_size), and even the number of pages
currently charged to the buffer (st_blocks / 512).
In contrast, all dma-bufs share the same anonymous inode. So while we
can count how many dma-buf fds or mappings a process has, we can't get
the size of the backing buffers or tell if two entries point to the same
dma-buf. On systems with debugfs, we can get a per-buffer breakdown of
size and reference count, but can't tell which processes are actually
holding the references to each buffer.
Replace the singleton inode with full-fledged inodes allocated by
alloc_anon_inode(). This involves creating and mounting a
mini-pseudo-filesystem for dma-buf, following the example in fs/aio.c.
Signed-off-by: Greg Hackmann
Signed-off-by: Chenbo Feng
---
drivers/dma-buf/dma-buf.c | 63 ++
include/uapi/linux/magic.h | 1 +
2 files changed, 58 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 7c858020d14b..ffd5a2ad7d6f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -34,8 +34,10 @@
#include
#include
#include
+#include
#include
+#include
static inline int is_dma_buf_file(struct file *);
@@ -46,6 +48,25 @@ struct dma_buf_list {
static struct dma_buf_list db_list;
+static const struct dentry_operations dma_buf_dentry_ops = {
+ .d_dname = simple_dname,
+};
+
+static struct vfsmount *dma_buf_mnt;
+
+static struct dentry *dma_buf_fs_mount(struct file_system_type *fs_type,
+ int flags, const char *name, void *data)
+{
+ return mount_pseudo(fs_type, "dmabuf:", NULL, &dma_buf_dentry_ops,
+ DMA_BUF_MAGIC);
+}
+
+static struct file_system_type dma_buf_fs_type = {
+ .name = "dmabuf",
+ .mount = dma_buf_fs_mount,
+ .kill_sb = kill_anon_super,
+};
+
static int dma_buf_release(struct inode *inode, struct file *file)
{
struct dma_buf *dmabuf;
@@ -338,6 +359,31 @@ static inline int is_dma_buf_file(struct file *file)
return file->f_op == &dma_buf_fops;
}
+static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
+{
+ struct file *file;
+ struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
+
+ if (IS_ERR(inode))
+ return ERR_CAST(inode);
+
+ inode->i_size = dmabuf->size;
+ inode_set_bytes(inode, dmabuf->size);
+
+ file = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf",
+flags, &dma_buf_fops);
+ if (IS_ERR(file))
+ goto err_alloc_file;
+ file->f_flags = flags & (O_ACCMODE | O_NONBLOCK);
+ file->private_data = dmabuf;
+
+ return file;
+
+err_alloc_file:
+ iput(inode);
+ return file;
+}
+
/**
* DOC: dma buf device access
*
@@ -433,8 +479,7 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
}
dmabuf->resv = resv;
- file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf,
- exp_info->flags);
+ file = dma_buf_getfile(dmabuf, exp_info->flags);
if (IS_ERR(file)) {
ret = PTR_ERR(file);
goto err_dmabuf;
@@ -1025,8 +1070,8 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
return ret;
seq_puts(s, "\nDma-buf Objects:\n");
- seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\n",
- "size", "flags", "mode", "count");
+ seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\t%-8s\n",
+ "size", "flags", "mode", "count", "ino");
list_for_each_entry(buf_obj, &db_list.head, list_node) {
ret = mutex_lock_interruptible(&buf_obj->lock);
@@ -1037,11 +1082,12 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
continue;
}
- seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\n",
+ seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\n",
buf_obj->size,
buf_obj->file->f_flags, buf_obj->file->f_mode,
file_count(buf_obj->file),
- buf_obj->exp_name);
+ buf_obj->exp_name,
+ file_inode(buf_obj->file)->i_ino);
robj = buf_obj->resv;
while (true) {
@@ -1136,6 +1182,10 @@ static inline void dma_buf_uninit_debugfs(void)
static int __init dma_buf_init(void)
{
+ dma_buf_mnt = kern_mount(&dma_buf_fs_type);
+ if (IS_ERR(dma_buf_mnt))
+ return PTR_ERR(dma_buf_mnt);
+
mutex_init(&db_l
Re: [PATCH v2 hmm 11/11] mm/hmm: Remove confusing comment and logic from hmm_release
On Fri, Jun 07, 2019 at 02:37:07PM -0700, Ralph Campbell wrote: > > On 6/6/19 11:44 AM, Jason Gunthorpe wrote: > > From: Jason Gunthorpe > > > > hmm_release() is called exactly once per hmm. ops->release() cannot > > accidentally trigger any action that would recurse back onto > > hmm->mirrors_sem. > > > > This fixes a use after-free race of the form: > > > > CPU0 CPU1 > > hmm_release() > > up_write(&hmm->mirrors_sem); > > hmm_mirror_unregister(mirror) > >down_write(&hmm->mirrors_sem); > >up_write(&hmm->mirrors_sem); > >kfree(mirror) > > mirror->ops->release(mirror) > > > > The only user we have today for ops->release is an empty function, so this > > is unambiguously safe. > > > > As a consequence of plugging this race drivers are not allowed to > > register/unregister mirrors from within a release op. > > > > Signed-off-by: Jason Gunthorpe > > I agree with the analysis above but I'm not sure that release() will > always be an empty function. It might be more efficient to write back > all data migrated to a device "in one pass" instead of relying > on unmap_vmas() calling hmm_start_range_invalidate() per VMA. I think we have to focus on the *current* kernel - and we have two users of release, nouveau_svm.c is empty and amdgpu_mn.c does schedule_work() - so I believe we should go ahead with this simple solution to the actual race today that both of those will suffer from. If we find a need for a more complex version then it can be debated and justified with proper context... Ok? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: analogix_dp: Convert to GPIO descriptors
Hi,
On 10/6/19 1:13, Linus Walleij wrote:
> This converts the Analogix display port to use GPIO descriptors
> instead of DT-extracted numbers.
>
> Cc: Douglas Anderson
> Cc: Sean Paul
> Cc: Marek Szyprowski
> Cc: Enric Balletbo i Serra
> Signed-off-by: Linus Walleij
Reviewed-by: Enric Balletbo i Serra
> ---
> .../drm/bridge/analogix/analogix_dp_core.c| 28 +--
> .../drm/bridge/analogix/analogix_dp_core.h| 4 ++-
> .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 +-
> 3 files changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 225f5e5dd69b..64842bbb2f3d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -18,8 +18,7 @@
> #include
> #include
> #include
> -#include
> -#include
> +#include
> #include
> #include
>
> @@ -1585,12 +1584,18 @@ analogix_dp_bind(struct device *dev, struct
> drm_device *drm_dev,
>
> dp->force_hpd = of_property_read_bool(dev->of_node, "force-hpd");
>
> - dp->hpd_gpio = of_get_named_gpio(dev->of_node, "hpd-gpios", 0);
> - if (!gpio_is_valid(dp->hpd_gpio))
> - dp->hpd_gpio = of_get_named_gpio(dev->of_node,
> - "samsung,hpd-gpio", 0);
> + /* Try two different names */
> + dp->hpd_gpiod = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN);
> + if (!dp->hpd_gpiod)
> + dp->hpd_gpiod = devm_gpiod_get_optional(dev, "samsung,hpd",
> + GPIOD_IN);
> + if (IS_ERR(dp->hpd_gpiod)) {
> + dev_err(dev, "error getting HDP GPIO: %ld\n",
> + PTR_ERR(dp->hpd_gpiod));
> + return ERR_CAST(dp->hpd_gpiod);
> + }
>
> - if (gpio_is_valid(dp->hpd_gpio)) {
> + if (dp->hpd_gpiod) {
> /*
>* Set up the hotplug GPIO from the device tree as an interrupt.
>* Simply specifying a different interrupt in the device tree
> @@ -1598,16 +1603,9 @@ analogix_dp_bind(struct device *dev, struct drm_device
> *drm_dev,
>* using a GPIO. We also need the actual GPIO specifier so
>* that we can get the current state of the GPIO.
>*/
> - ret = devm_gpio_request_one(&pdev->dev, dp->hpd_gpio, GPIOF_IN,
> - "hpd_gpio");
> - if (ret) {
> - dev_err(&pdev->dev, "failed to get hpd gpio\n");
> - return ERR_PTR(ret);
> - }
> - dp->irq = gpio_to_irq(dp->hpd_gpio);
> + dp->irq = gpiod_to_irq(dp->hpd_gpiod);
> irq_flags = IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;
> } else {
> - dp->hpd_gpio = -ENODEV;
> dp->irq = platform_get_irq(pdev, 0);
> irq_flags = 0;
> }
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> index 769255dc6e99..dc65c2bafa63 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> @@ -38,6 +38,8 @@
> #define DPCD_VOLTAGE_SWING_SET(x)(((x) & 0x3) << 0)
> #define DPCD_VOLTAGE_SWING_GET(x)(((x) >> 0) & 0x3)
>
> +struct gpio_desc;
> +
> enum link_lane_count_type {
> LANE_COUNT1 = 1,
> LANE_COUNT2 = 2,
> @@ -171,7 +173,7 @@ struct analogix_dp_device {
> struct link_train link_train;
> struct phy *phy;
> int dpms_mode;
> - int hpd_gpio;
> + struct gpio_desc*hpd_gpiod;
> boolforce_hpd;
> boolpsr_enable;
> boolfast_train_enable;
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index a5f2763d72e4..7aab2d6d710c 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -12,7 +12,7 @@
>
> #include
> #include
> -#include
> +#include
> #include
> #include
>
> @@ -397,7 +397,7 @@ void analogix_dp_clear_hotplug_interrupts(struct
> analogix_dp_device *dp)
> {
> u32 reg;
>
> - if (gpio_is_valid(dp->hpd_gpio))
> + if (dp->hpd_gpiod)
> return;
>
> reg = HOTPLUG_CHG | HPD_LOST | PLUG;
> @@ -411,7 +411,7 @@ void analogix_dp_init_hpd(struct analogix_dp_device *dp)
> {
> u32 reg;
>
> - if (gpio_is_valid(dp->hpd_gpio))
> + if (dp->hpd_gpiod)
> return;
>
> analogix_dp_clear_hotplug_interrupts(dp);
> @@ -434,8 +434,8 @@ enum dp_irq_type analogix_dp_get_irq_type(struct
> analogix_dp_device *dp)
> {
> u32 reg;
[RESEND PATCH v3 1/3] dma-buf: give each buffer a full-fledged inode
From: Greg Hackmann
By traversing /proc/*/fd and /proc/*/map_files, processes with CAP_ADMIN
can get a lot of fine-grained data about how shmem buffers are shared
among processes. stat(2) on each entry gives the caller a unique
ID (st_ino), the buffer's size (st_size), and even the number of pages
currently charged to the buffer (st_blocks / 512).
In contrast, all dma-bufs share the same anonymous inode. So while we
can count how many dma-buf fds or mappings a process has, we can't get
the size of the backing buffers or tell if two entries point to the same
dma-buf. On systems with debugfs, we can get a per-buffer breakdown of
size and reference count, but can't tell which processes are actually
holding the references to each buffer.
Replace the singleton inode with full-fledged inodes allocated by
alloc_anon_inode(). This involves creating and mounting a
mini-pseudo-filesystem for dma-buf, following the example in fs/aio.c.
Signed-off-by: Greg Hackmann
Signed-off-by: Chenbo Feng
---
drivers/dma-buf/dma-buf.c | 63 ++
include/uapi/linux/magic.h | 1 +
2 files changed, 58 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 7c858020d14b..ffd5a2ad7d6f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -34,8 +34,10 @@
#include
#include
#include
+#include
#include
+#include
static inline int is_dma_buf_file(struct file *);
@@ -46,6 +48,25 @@ struct dma_buf_list {
static struct dma_buf_list db_list;
+static const struct dentry_operations dma_buf_dentry_ops = {
+ .d_dname = simple_dname,
+};
+
+static struct vfsmount *dma_buf_mnt;
+
+static struct dentry *dma_buf_fs_mount(struct file_system_type *fs_type,
+ int flags, const char *name, void *data)
+{
+ return mount_pseudo(fs_type, "dmabuf:", NULL, &dma_buf_dentry_ops,
+ DMA_BUF_MAGIC);
+}
+
+static struct file_system_type dma_buf_fs_type = {
+ .name = "dmabuf",
+ .mount = dma_buf_fs_mount,
+ .kill_sb = kill_anon_super,
+};
+
static int dma_buf_release(struct inode *inode, struct file *file)
{
struct dma_buf *dmabuf;
@@ -338,6 +359,31 @@ static inline int is_dma_buf_file(struct file *file)
return file->f_op == &dma_buf_fops;
}
+static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
+{
+ struct file *file;
+ struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
+
+ if (IS_ERR(inode))
+ return ERR_CAST(inode);
+
+ inode->i_size = dmabuf->size;
+ inode_set_bytes(inode, dmabuf->size);
+
+ file = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf",
+flags, &dma_buf_fops);
+ if (IS_ERR(file))
+ goto err_alloc_file;
+ file->f_flags = flags & (O_ACCMODE | O_NONBLOCK);
+ file->private_data = dmabuf;
+
+ return file;
+
+err_alloc_file:
+ iput(inode);
+ return file;
+}
+
/**
* DOC: dma buf device access
*
@@ -433,8 +479,7 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
}
dmabuf->resv = resv;
- file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf,
- exp_info->flags);
+ file = dma_buf_getfile(dmabuf, exp_info->flags);
if (IS_ERR(file)) {
ret = PTR_ERR(file);
goto err_dmabuf;
@@ -1025,8 +1070,8 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
return ret;
seq_puts(s, "\nDma-buf Objects:\n");
- seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\n",
- "size", "flags", "mode", "count");
+ seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\t%-8s\n",
+ "size", "flags", "mode", "count", "ino");
list_for_each_entry(buf_obj, &db_list.head, list_node) {
ret = mutex_lock_interruptible(&buf_obj->lock);
@@ -1037,11 +1082,12 @@ static int dma_buf_debug_show(struct seq_file *s, void
*unused)
continue;
}
- seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\n",
+ seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\n",
buf_obj->size,
buf_obj->file->f_flags, buf_obj->file->f_mode,
file_count(buf_obj->file),
- buf_obj->exp_name);
+ buf_obj->exp_name,
+ file_inode(buf_obj->file)->i_ino);
robj = buf_obj->resv;
while (true) {
@@ -1136,6 +1182,10 @@ static inline void dma_buf_uninit_debugfs(void)
static int __init dma_buf_init(void)
{
+ dma_buf_mnt = kern_mount(&dma_buf_fs_type);
+ if (IS_ERR(dma_buf_mnt))
+ return PTR_ERR(dma_buf_mnt);
+
mutex_init(&db_l
Re: [PATCH] drm/bridge: analogix-anx78xx: Drop of_gpio.h include
Hi, On 10/6/19 0:32, Linus Walleij wrote: > This include is only used for some gpio drivers and consumers > that look up GPIO numbers directly from the device tree. > This driver does not use it and only needs . > Delete the unused include. > > Cc: Enric Balletbo i Serra > Cc: Jose Abreu > Signed-off-by: Linus Walleij Reviewed-by: Enric Balletbo i Serra > --- > drivers/gpu/drm/bridge/analogix-anx78xx.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c > b/drivers/gpu/drm/bridge/analogix-anx78xx.c > index c09aaf93ae1b..61b5122e5a52 100644 > --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c > +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c > @@ -20,7 +20,6 @@ > #include > #include > #include > -#include > #include > #include > #include > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 hmm 02/11] mm/hmm: Use hmm_mirror not mm as an argument for hmm_range_register
On Fri, Jun 07, 2019 at 03:39:06PM -0700, Ralph Campbell wrote: > > > + range->hmm = hmm; > > > + kref_get(&hmm->kref); > > > /* Initialize range to track CPU page table updates. */ > > > mutex_lock(&hmm->lock); > > > > > I forgot to add that I think you can delete the duplicate > "range->hmm = hmm;" > here between the mutex_lock/unlock. Done, thanks Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 hmm 11/11] mm/hmm: Remove confusing comment and logic from hmm_release
On 6/10/19 9:02 AM, Jason Gunthorpe wrote: On Fri, Jun 07, 2019 at 02:37:07PM -0700, Ralph Campbell wrote: On 6/6/19 11:44 AM, Jason Gunthorpe wrote: From: Jason Gunthorpe hmm_release() is called exactly once per hmm. ops->release() cannot accidentally trigger any action that would recurse back onto hmm->mirrors_sem. This fixes a use after-free race of the form: CPU0 CPU1 hmm_release() up_write(&hmm->mirrors_sem); hmm_mirror_unregister(mirror) down_write(&hmm->mirrors_sem); up_write(&hmm->mirrors_sem); kfree(mirror) mirror->ops->release(mirror) The only user we have today for ops->release is an empty function, so this is unambiguously safe. As a consequence of plugging this race drivers are not allowed to register/unregister mirrors from within a release op. Signed-off-by: Jason Gunthorpe I agree with the analysis above but I'm not sure that release() will always be an empty function. It might be more efficient to write back all data migrated to a device "in one pass" instead of relying on unmap_vmas() calling hmm_start_range_invalidate() per VMA. I think we have to focus on the *current* kernel - and we have two users of release, nouveau_svm.c is empty and amdgpu_mn.c does schedule_work() - so I believe we should go ahead with this simple solution to the actual race today that both of those will suffer from. If we find a need for a more complex version then it can be debated and justified with proper context... Ok? Jason OK. I guess we have enough on the plate already :-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables
On 6/8/19 4:41 AM, Jason Gunthorpe wrote: > On Sat, Jun 08, 2019 at 02:10:08AM -0700, Christoph Hellwig wrote: >> On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote: >>> HMM defines its own struct hmm_update which is passed to the >>> sync_cpu_device_pagetables() callback function. This is >>> sufficient when the only action is to invalidate. However, >>> a device may want to know the reason for the invalidation and >>> be able to see the new permissions on a range, update device access >>> rights or range statistics. Since sync_cpu_device_pagetables() >>> can be called from try_to_unmap(), the mmap_sem may not be held >>> and find_vma() is not safe to be called. >>> Pass the struct mmu_notifier_range to sync_cpu_device_pagetables() >>> to allow the full invalidation information to be used. >>> >>> Signed-off-by: Ralph Campbell >>> >>> I'm sending this out now since we are updating many of the HMM APIs >>> and I think it will be useful. >> >> This is the right thing to do. But the really right thing is to just >> kill the hmm_mirror API entirely and move to mmu_notifiers. At least >> for noveau this already is way simpler, although right now it defeats >> Jasons patch to avoid allocating the struct hmm in the fault path. >> But as said before that can be avoided by just killing struct hmm, >> which for many reasons is the right thing to do anyway. >> >> I've got a series here, which is a bit broken (epecially the last >> patch can't work as-is), but should explain where I'm trying to head: >> >> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/hmm-mirror-simplification > > At least the current hmm approach does rely on the collision retry > locking scheme in struct hmm/struct hmm_range for the pagefault side > to work right. > > So, before we can apply patch one in this series we need to fix > hmm_vma_fault() and all its varients. Otherwise the driver will be > broken. > > I'm hoping to first define what this locking should be (see other > emails to Ralph) then, ideally, see if we can extend mmu notifiers to > get it directly withouth hmm stuff. > > Then we apply your patch one and the hmm ops wrapper dies. > This all makes sense, and thanks for all this work to simplify and clarify HMM. It's going to make it a lot easier to work with, when the dust settles. thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
