dri-devel July 2018

dri-devel@lists.freedesktop.org

277 participants
1883 discussions

[PATCH RFC] driver core: Reprobe consumer if it was unbound by dropped device_link
by Jyri Sarha 15 Aug '18

15 Aug '18

Put consumer device to deferred probe list if it is unbound due to a dropped link to a supplier. When a device link supplier is unbound (either manually or because one of its own suppliers was unbound), its consumers are unbound as well. Currently if the supplier binds again after this the consumer does not automatically probe again. With this patch it does. If this patch is not acceptable as such, how about adding this behavior behind a new device link flag? The idea to this patch was gotten from this post by Lucas Wunner: https://www.spinics.net/lists/dri-devel/msg166318.html Part of the code and the description is borrowed from him. cc: Lukas Wunner <lukas(a)wunner.de> cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> cc: Thierry Reding <thierry.reding(a)gmail.com> Signed-off-by: Jyri Sarha <jsarha(a)ti.com> --- drivers/base/base.h | 1 + drivers/base/core.c | 2 ++ drivers/base/dd.c | 2 +- 3 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/base/base.h b/drivers/base/base.h index d800de6..39370eb 100644 --- a/drivers/base/base.h +++ b/drivers/base/base.h @@ -114,6 +114,7 @@ extern void device_release_driver_internal(struct device *dev, extern void driver_detach(struct device_driver *drv); extern int driver_probe_device(struct device_driver *drv, struct device *dev); +extern void driver_deferred_probe_add(struct device *dev); extern void driver_deferred_probe_del(struct device *dev); static inline int driver_match_device(struct device_driver *drv, struct device *dev) diff --git a/drivers/base/core.c b/drivers/base/core.c index b2261f9..0964ed5 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -570,6 +570,8 @@ void device_links_unbind_consumers(struct device *dev) device_release_driver_internal(consumer, NULL, consumer->parent); + driver_deferred_probe_add(consumer); + put_device(consumer); goto start; } diff --git a/drivers/base/dd.c b/drivers/base/dd.c index de6fd09..846ae78 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -140,7 +140,7 @@ static void deferred_probe_work_func(struct work_struct *work) } static DECLARE_WORK(deferred_probe_work, deferred_probe_work_func); -static void driver_deferred_probe_add(struct device *dev) +void driver_deferred_probe_add(struct device *dev) { mutex_lock(&deferred_probe_mutex); if (list_empty(&dev->p->deferred_probe)) { -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

3 5

[PATCH 1/2] drm/dp: add extended receiver capability field present bit
by matthew.s.atwood＠intel.com 14 Aug '18

14 Aug '18

From: Matt Atwood <matthew.s.atwood(a)intel.com> This bit was added to DP Training Aux RD interval with DP 1.3. Via descriptiion of the spec this field indicates the panels true capabilities are described in DPCD address space 02200h through 022FFh. v2: version comment update v3: version comment correction, commit message update v4: white space correction Signed-off-by: Matt Atwood <matthew.s.atwood(a)intel.com> --- include/drm/drm_dp_helper.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index c01564991a9f..44aaefdc8448 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -123,8 +123,9 @@ # define DP_FRAMING_CHANGE_CAP (1 << 1) # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */ -#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ -# define DP_TRAINING_AUX_RD_MASK 0x7F /* XXX 1.2? */ +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ +# define DP_TRAINING_AUX_RD_MASK 0x7F /* DP 1.3 */ +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* DP 1.3 */ #define DP_ADAPTER_CAP 0x00f /* 1.2 */ # define DP_FORCE_LOAD_SENSE_CAP (1 << 0) -- 2.17.1

3 6

[Bug 105996] [DC][CIK] Bonaire mobile - No displays being turned on
by bugzilla-daemon＠freedesktop.org 14 Aug '18

14 Aug '18

https://bugs.freedesktop.org/show_bug.cgi?id=105996 Bug ID: 105996 Summary: [DC][CIK] Bonaire mobile - No displays being turned on Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: shawn.starr(a)rogers.com Created attachment 138777 --> https://bugs.freedesktop.org/attachment.cgi?id=138777&action=edit Dmesg krnel boot with dc_log enabled Fedora kernel: 4.17.0-0.rc0.git7.2.fc29.x86_64 (pre -rc1) Boot options: root=UUID=c88abf6f-2561-41e5-bec5-c3b2881d0ffc ro rhgb slub_debug=- cgroup_disable=memory console=tty0 console=ttyUSB0,9600n8 nmi_watchdog=0 audit=0 radeon.cik_support=0 amdgpu.cik_support=1 resume=/dev/sda7 i915.enable_rc6=1 i915.semaphores=1 i915.enable_psr=1 i915.enable_fbc=1 drm_kms_helper.poll=0 mce=off amdgpu.dc=1 amdgpu.dc_log=1 Note: BIOS is in dGPU only mode, so i915 is disabled. both VGA and the LCD (LVDS) panel remain turned off, no display is available. Attached is kernel dmesg and Xorg log files. -- You are receiving this mail because: You are the assignee for the bug.

1 10

[PATCH v3 0/2] drm/blend: Add per-plane pixel blend mode property
by Lowry Li 14 Aug '18

14 Aug '18

Hi, This serie aims at adding the support for pixel blend modes represent the alpha blending equation selection in the driver. It also introduces to use it in the malidp driver. Let me know what you think, Lowry Changes for v3: - Refines the comments of drm_plane_create_blend_mode_property: 1) Puts the descriptions (after the ":") on a new line 2) Adds explaining why @supported_modes need PREMUL as default - Refines the comments of drm/mali-dp patchset - Rebased on drm-misc-next and fixed the confilcts with plane alpha patch Changes for v2: - Moves the blending equation into the DOC comment - Refines the comments of drm_plane_create_blend_mode_property to not enumerate the #defines, but instead the string values - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha - Introduces to use it in the malidp driver, which depends on the plane alpha patch Changes from v1: - v1 is just the core changes to request for commments - Adds a pixel_blend_mode to drm_plane_state and a blend_mode_property to drm_plane, and related support functions - Defines three blend modes in drm_blend.h - Rebased on current drm-next Lowry Li (2): drm: Add per-plane pixel blend mode property drm/mali-dp: Implement plane alpha and pixel blend on malidp drivers/gpu/drm/arm/malidp_planes.c | 76 +++++++++++++--------- drivers/gpu/drm/drm_atomic.c | 4 ++ drivers/gpu/drm/drm_atomic_helper.c | 1 + drivers/gpu/drm/drm_blend.c | 126 ++++++++++++++++++++++++++++++++++++ include/drm/drm_blend.h | 6 ++ include/drm/drm_plane.h | 5 ++ 6 files changed, 186 insertions(+), 32 deletions(-) -- 1.9.1

4 11

[PATCH] drm/bridge/synopsys: dw-hdmi: re-run dw_hdmi_setup when setting mode
by Icenowy Zheng 14 Aug '18

14 Aug '18

Currently dw_hdmi_setup is only run when the dw-hdmi bridge is enabled, with the mode set last time. When the bridge is enabled before any mode is set (this may happen when booting), the mode won't be set at all, some setup steps will be skipped or fail, and the HDMI output may not work. Re-run dw_hdmi_setup when setting mode, in order to prevent such situation. Signed-off-by: Icenowy Zheng <icenowy(a)aosc.io> --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 5971976284bf..e2f832182afe 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2007,6 +2007,7 @@ static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge, /* Store the display mode for plugin/DKMS poweron events */ memcpy(&hdmi->previous_mode, mode, sizeof(hdmi->previous_mode)); + dw_hdmi_setup(hdmi, mode); mutex_unlock(&hdmi->mutex); } -- 2.18.0

2 3

More drm-panel help volunteers?
by Daniel Vetter 14 Aug '18

14 Aug '18

Hi all, I chatted a bit with Thierry about drm-panel, and state of things still seems to be that when Thierry's on vacations/leave/busy patches don't move. So I looked at people with a few patches who could be volunteered to sometimes help out with review&merging: 31 Thierry Reding 16 Philipp Zabel 11 Lucas Stach 9 Ajay Kumar 9 Alexandre Courbot 8 Philippe CORNU 6 Boris Brezillon 6 Maxime Ripard 6 Stefan Agner 5 Arnd Bergmann 5 Dave Airlie 5 Yakir Yang There's fairly little patch activity going on in drm/panel, main goal would be just to reduce the occasional long waits (recently a contributor pinged 3 times or so every few weeks for feedback). Philipp Z and Lucas, either of you interested in drm-misc commit rights and occasionally scanning for drm-panel patches? We also have a pile of people here who already are drm-misc committers. Phillippe C., Boris, Maxime, would be awesome if you could help out occsasionally? I'd say anyone with drm-misc committer experience has more than sufficient judgement to figure out whether to push a patch or not. Any other ideas? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

4 6

[PATCH v2] backlight: pwm_bl: switch to using "atomic" PWM API
by Enric Balletbo i Serra 14 Aug '18

14 Aug '18

The "atomic" API allows us to configure PWM period and duty_cycle and enable it in one call. The patch also moves the pwm_init_state just before any use of the pwm_state struct, this fixes a potential bug where pwm_get_state can be called before pwm_init_state. Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> --- Changes in v2: - Do not force the PWM be off in the first call to pwm_apply_state. - Delayed applying the state until we know what the period is. - Removed pb->period as after the conversion is not needed. drivers/video/backlight/pwm_bl.c | 71 ++++++++++++++++++-------------- 1 file changed, 41 insertions(+), 30 deletions(-) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index bdfcc0a71db1..dd1cb29b5332 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -28,7 +28,6 @@ struct pwm_bl_data { struct pwm_device *pwm; struct device *dev; - unsigned int period; unsigned int lth_brightness; unsigned int *levels; bool enabled; @@ -46,7 +45,8 @@ struct pwm_bl_data { void (*exit)(struct device *); }; -static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness) +static void pwm_backlight_power_on(struct pwm_bl_data *pb, + struct pwm_state *state) { int err; @@ -57,7 +57,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness) if (err < 0) dev_err(pb->dev, "failed to enable power supply\n"); - pwm_enable(pb->pwm); + state->enabled = true; + pwm_apply_state(pb->pwm, state); if (pb->post_pwm_on_delay) msleep(pb->post_pwm_on_delay); @@ -70,6 +71,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb, int brightness) static void pwm_backlight_power_off(struct pwm_bl_data *pb) { + struct pwm_state state; + if (!pb->enabled) return; @@ -79,8 +82,10 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb) if (pb->pwm_off_delay) msleep(pb->pwm_off_delay); - pwm_config(pb->pwm, 0, pb->period); - pwm_disable(pb->pwm); + pwm_get_state(pb->pwm, &state); + state.enabled = false; + state.duty_cycle = 0; + pwm_apply_state(pb->pwm, &state); regulator_disable(pb->power_supply); pb->enabled = false; @@ -89,14 +94,17 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb) static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness) { unsigned int lth = pb->lth_brightness; + struct pwm_state state; u64 duty_cycle; + pwm_get_state(pb->pwm, &state); + if (pb->levels) duty_cycle = pb->levels[brightness]; else duty_cycle = brightness; - duty_cycle *= pb->period - lth; + duty_cycle *= state.period - lth; do_div(duty_cycle, pb->scale); return duty_cycle + lth; @@ -106,6 +114,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl) { struct pwm_bl_data *pb = bl_get_data(bl); int brightness = bl->props.brightness; + struct pwm_state state; int duty_cycle; if (bl->props.power != FB_BLANK_UNBLANK || @@ -118,8 +127,12 @@ static int pwm_backlight_update_status(struct backlight_device *bl) if (brightness > 0) { duty_cycle = compute_duty_cycle(pb, brightness); - pwm_config(pb->pwm, duty_cycle, pb->period); - pwm_backlight_power_on(pb, brightness); + pwm_get_state(pb->pwm, &state); + state.duty_cycle = duty_cycle; + if (!state.enabled) + pwm_backlight_power_on(pb, &state); + else + pwm_apply_state(pb->pwm, &state); } else pwm_backlight_power_off(pb); @@ -447,7 +460,6 @@ static int pwm_backlight_probe(struct platform_device *pdev) struct device_node *node = pdev->dev.of_node; struct pwm_bl_data *pb; struct pwm_state state; - struct pwm_args pargs; unsigned int i; int ret; @@ -539,10 +551,26 @@ static int pwm_backlight_probe(struct platform_device *pdev) dev_dbg(&pdev->dev, "got pwm for backlight\n"); - if (!data->levels) { - /* Get the PWM period (in nanoseconds) */ - pwm_get_state(pb->pwm, &state); + /* Sync up PWM state. */ + pwm_init_state(pb->pwm, &state); + + /* + * The DT case will set the pwm_period_ns field to 0 and store the + * period, parsed from the DT, in the PWM device. For the non-DT case, + * set the period from platform data if it has not already been set + * via the PWM lookup table. + */ + if (!state.period && (data->pwm_period_ns > 0)) + state.period = data->pwm_period_ns; + ret = pwm_apply_state(pb->pwm, &state); + if (ret) { + dev_err(&pdev->dev, "failed to apply initial PWM state: %d\n", + ret); + goto err_alloc; + } + + if (!data->levels) { ret = pwm_backlight_brightness_default(&pdev->dev, data, state.period); if (ret < 0) { @@ -559,24 +587,7 @@ static int pwm_backlight_probe(struct platform_device *pdev) pb->levels = data->levels; } - /* - * FIXME: pwm_apply_args() should be removed when switching to - * the atomic PWM API. - */ - pwm_apply_args(pb->pwm); - - /* - * The DT case will set the pwm_period_ns field to 0 and store the - * period, parsed from the DT, in the PWM device. For the non-DT case, - * set the period from platform data if it has not already been set - * via the PWM lookup table. - */ - pwm_get_args(pb->pwm, &pargs); - pb->period = pargs.period; - if (!pb->period && (data->pwm_period_ns > 0)) - pb->period = data->pwm_period_ns; - - pb->lth_brightness = data->lth_brightness * (pb->period / pb->scale); + pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); memset(&props, 0, sizeof(struct backlight_properties)); props.type = BACKLIGHT_RAW; -- 2.18.0

2 3

[PATCH v3 0/8] drm/rockchip: migrate to common dw-mipi-dsi bridge and dual-dsi
by Heiko Stuebner 14 Aug '18

14 Aug '18

The Rockchip DSI driver was separate till now, not using the common bridge driver that was introduced a bit later. So this series migrates over to use that common bridge driver and then also adds support for dual-dsi to both the bridge and Rockchip glue code. The bridge-migration itself is based on Nickeys earlier v8 work, but adapted to current kernels and with a new split between probe and bind, so that we do not create and drop the dsi-host on each deferred bind attempt. changes in v2: - rebase against newer drm code (dsi-bridge+rockchip changes) - add SPDX header to new glue driver - expect regular interface lanes from panel (like 4) not the double number Similar to tegra - keep links to both master and slave changes in v3: - don't defer in bridge_attach, instead add ability to check for finalized panel attachement, for example in bind - address bridge-conversion comments from Andrzej: - include ordering - moved hwaccess from mode_set to enable callback - move pllref_clk enablement to bind (needed by bridge mode_set->lane_mbps) - limited slave settings to dw_mipi_dsi_set_slave - address dual-dsi comments from Philippe: - remove unneeded separate variables - remove unneeded second slave settings - disable slave before master - lane-sum calculation comments Unchanged from review comments: - kept dw_mipi_dsi_bind, as the dsi->bridge member is only part of the bridge drivers struct, so not accessible from glue drivers - kept panel deferral in rk-bind, as the dsi bus containing the panel will only be created during probe, so this gives the system a chance to probe the panel between probe and bind calls, saving around 2 deferral rounds on my Gru-Scarlet - when compared to always deferring during probe. (panel module-load time + async probing) + of course saving time not re-creating the dsi bus on each probe try - kept helper to find second host, as I think it's pretty near to Archit's description - kept dual-dsi handling that mimicks tegra for now Cover-letter blurb from v2: --------------------------- The dual-dsi setup follows the port description introduced by Archit [0], in that the panel defines two input ports that get connected to both dsi-controllers instances. So on Gru-Scarlett this looks for example like: &mipi_dsi { status = "okay"; clock-master; ports { mipi_out: port@1 { reg = <1>; mipi_out_panel: endpoint { remote-endpoint = <&mipi_in_panel>; }; }; }; mipi_panel: panel@0 { /* 2 different panels are used, compatibles are in dts files */ reg = <0>; backlight = <&backlight>; enable-gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>; pinctrl-names = "default"; pinctrl-0 = <&display_rst_l>; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; mipi_in_panel: endpoint { remote-endpoint = <&mipi_out_panel>; }; }; port@1 { reg = <1>; mipi1_in_panel: endpoint@1 { remote-endpoint = <&mipi1_out_panel>; }; }; }; }; }; &mipi_dsi1 { status = "okay"; ports { mipi1_out: port@1 { reg = <1>; mipi1_out_panel: endpoint { remote-endpoint = <&mipi1_in_panel>; }; }; }; }; The driver internal setup is pretty similar to what tegra does with its ganged-mode [1][2]. But here a new helper function allows to traverse the devicetree from one controller port through the panel to find another dsi-controller using that same panel. This way we don't need a special phandle-property to link the controllers together. For the CRTC it is still one single display to handle, only with an additional switch that enables the dual-dsi output. For practical purposes it is possible to just pick half the series (till patch 5) to get the migration to the bridge driver first, so that we can get rid of the dw-dsi copy in the Rockchip driver. But of course Acks / Reviews of the dsi-bridge changes would be needed. [0] https://patchwork.kernel.org/patch/10172381/ [1] https://lkml.org/lkml/2014/8/5/396 [2] https://patchwork.kernel.org/patch/5075161/ Heiko Stuebner (5): drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to __dw_mipi_dsi_remove drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from dw_mipi_dsi_bind drm/bridge/synopsys: dsi: add ability to check dsi-device attachment drm/dsi: add helper function to find the second host in a dual-dsi setup drm/rockchip: dsi: add dual mipi support Nickey Yang (3): dt-bindings: display: rockchip: update DSI controller drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver drm/bridge/synopsys: dsi: add dual-dsi support .../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 +- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 124 +- drivers/gpu/drm/drm_mipi_dsi.c | 56 + drivers/gpu/drm/rockchip/Kconfig | 2 +- drivers/gpu/drm/rockchip/Makefile | 2 +- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1005 ++++++++++++ drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1349 ----------------- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 3 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 + drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 + include/drm/bridge/dw_mipi_dsi.h | 7 +- include/drm/drm_mipi_dsi.h | 2 + 14 files changed, 1204 insertions(+), 1379 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c -- 2.17.0

2 13

[PATCH v2 00/18] Allwinner R40 HDMI refactoring
by Jernej Skrabec 14 Aug '18

14 Aug '18

This series fixes several issues found in R40 HDMI patch series after it was applied. Conversation can be found here: http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/586011.html Patches are based on latest linux-next (next-20180710) and are ordered in such way that they don't break R40 HDMI at any time. Because of that I suggest that whole series goes through drm-misc to preserve that order. I also tested those patches on H3 to make sure it doesn't break other platforms. However, it would be nice to test for regressions also on older SoCs (with DE1). Best regards, Jernej Changes from v1: - added Review-by and Acked-by tags - added a patch which reorders mixer includes alphabetically - reworked function which finds mixer id - dropped register initialization in TCON TOP - reworded some commit messages Jernej Skrabec (18): dt-bindings: display: sun4i-drm: Add R40 display engine compatible drm/sun4i: Add R40 display engine compatible ARM: dts: sun8i: r40: Remove fallback display engine compatible drm/sun4i: tcon-top: Cleanup clock handling drm/sun4i: tcon: Release node when traversing of graph dt-bindings: display: sun4i-drm: Add R40 TV TCON description drm/sun4i: DW HDMI: Release nodes if error happens during CRTC search ARM: dts: sun8i: r40: Add mixer ids to TCON TOP drm/sun4i: mixer: Order includes alphabetically drm/sun4i: mixer: Read id from DT drm/sun4i: tcon-top: Add helpers for mux switching drm/sun4i: tcon: Add another way for matching mixers with tcon drm/sun4i: tcon: Add support for R40 TCON ARM: dts: sun8i: r40: Remove fallback compatible for TCON TV ARM: dts: sun8i: r40: Add missing TCON-TOP - TCON connections ARM: dts: sun8i: r40: Disable TCONs by default. drm/sun4i: tcon-top: Remove mux configuration at probe time dt-bindings: display: sun4i-drm: Fix order of DW HDMI PHY compatibles .../bindings/display/sunxi/sun4i-drm.txt | 6 +- .../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 20 +- arch/arm/boot/dts/sun8i-r40.dtsi | 65 ++++++- drivers/gpu/drm/sun4i/sun4i_drv.c | 1 + drivers/gpu/drm/sun4i/sun4i_tcon.c | 92 ++++++++- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 15 +- drivers/gpu/drm/sun4i/sun8i_mixer.c | 42 ++++- drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 178 ++++++++---------- drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 4 + 9 files changed, 278 insertions(+), 145 deletions(-) -- 2.18.0

6 39

Re: [PATCH libdrm] msm: add msm drm uapi header
by Tanmay Shah 14 Aug '18

14 Aug '18

On 2018-07-25 17:56, Rob Clark wrote: > On Wed, Jul 25, 2018 at 8:43 PM, Tanmay Shah <tanmay(a)codeaurora.org> > wrote: >> On 2018-07-25 17:33, Tanmay Shah wrote: >>> >>> On 2018-07-24 15:21, Eric Anholt wrote: >>>> >>>> Tanmay Shah <tanmay(a)codeaurora.org> writes: >>>> >>>>> On 2018-07-24 12:19, Eric Anholt wrote: >>>>>> >>>>>> Tanmay Shah <tanmay(a)codeaurora.org> writes: >>>>>> >>>>>>> file derived from msm-next kernel uapi header. >>>>>> >>>>>> >>>>>> Unless there's an exception from Dave, I believe uapi headers in >>>>>> libdrm >>>>>> and Mesa should be direct copies from "make headers_install" on >>>>>> the >>>>>> drm-next branch. How does this compare to that? >>>>> >>>>> >>>>> The header file is identical as in drm-next kernel. >>>> >>>> >>>> Great, let's say "drm-next" instead to make that clear. Also, looks >>>> like freedreno/msm/msm_drm.h should probably get removed in favor of >>>> this? >>>> >>>> _______________________________________________ >>>> dri-devel mailing list >>>> dri-devel(a)lists.freedesktop.org >>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >>> >>> +Rob Clark >>> >>> Thanks Eric, I will send v2 with suggested changes. >>> >>> freedreno/msm/msm_drm.h is owned by Rob, I am not sure if we need it >>> there >>> or not. I would let Rob comment on this. >>> >>> We require msm_drm.h in include/drm/ directory to export GEM ioctls >>> so >>> other modules >>> such as gbm can use it. Other platforms have similar strategy. >> >> >> Sorry, Actually +Rob Clark > > yeah, we should remove the duplicate header in libdrm.. so far it > hasn't been exported outside of libdrm_freedreno since it was > unneeded.. but as long as libdrm_freedreno still compiles properly > with the moved header, I'm fine with it. There might be some include > path tweaking required, not sure.. > > (and PS. "ownership" is not a thing upstream.. if it lives in the same > git tree and changing it doesn't break the build, it is not off-limits > ;-)) > > BR, > -R Thanks, Rob. -- Tanmay Shah

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2018