[Bug 91107] [Radeonsi/290x] In the Dota2 Reborn beta only half on the ingame GUI is rendered
https://bugs.freedesktop.org/show_bug.cgi?id=91107 Christoph Haag changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #2 from Christoph Haag --- So it wasn't an actual bug in the drivers after all. > It was a problem with relying on undefined behavior when GL_CLIP_DISTANCE0 > is enabled and the shader does not write gl_ClipDistance[0] https://github.com/ValveSoftware/Dota-2-Reborn/issues/79#issuecomment-115401636 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/ce6aa284/attachment.html>
[Bug 91110] Textures missing iff character in specific areas in dolphin running Xenoblades Chronicles
https://bugs.freedesktop.org/show_bug.cgi?id=91110 Bug ID: 91110 Summary: Textures missing iff character in specific areas in dolphin running Xenoblades Chronicles Product: Mesa Version: git Hardware: x86-64 (AMD64) URL: https://code.google.com/p/dolphin-emu/issues/detail?id =8688 OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: christian at madez.de QA Contact: dri-devel at lists.freedesktop.org Iff a character is in specific areas some textures on him are not rendered. In the entry of colony 9 is such an area. The textures are rendered properly on the Intel GPU. There are screenshots, a fifolog and an apitrace at the end of the linked bugreport. The problem appears in Debian Jessie, Sid and mesa-git the last time checked, which was 9 days ago. I compiled mesa-git with CFLAGS = -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -DDEBUG and set $ export LIBGL_DEBUG=verbose $ export MESA_DEBUG=1 $ export EGL_LOG_LEVEL=debug before running dolphin. Running dolphin with the game until the issue appears gives the following output $ dolphin-emu Gtk-Message: Failed to load module "canberra-gtk-module" libGL: screen 0 does not appear to be DRI3 capable libGL: pci id for fd 22: 1002:679a, driver radeonsi libGL: OpenDriver: trying lib/tls/radeonsi_dri.so libGL: OpenDriver: trying lib/radeonsi_dri.so libGL: Can't open configuration file /home/user/.drirc: Arquivo ou diretório não encontrado. libGL: Can't open configuration file /home/user/.drirc: Arquivo ou diretório não encontrado. libGL: Using DRI2 for screen 0 I'm sorry, I don't know how to write a simple GLUT-based test program. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/e6c5be77/attachment.html>
[Intel-gfx] [v2 7/7] drm/i915: Backlight control using CRC PMIC based PWM driver
On Thu, Jun 25, 2015 at 6:17 PM, Ville Syrjälä
wrote:
> On Thu, Jun 25, 2015 at 05:38:50PM +0530, Shobhit Kumar wrote:
>> On Thu, Jun 25, 2015 at 2:18 PM, Ville Syrjälä
>> wrote:
>> > On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
>> >> Use the CRC PWM device in intel_panel.c and add new MIPI backlight
>> >> specififc callbacks
>> >>
>> >> v2: Modify to use pwm_config callback
>> >> v3: Addressed Jani's comments
>> >> - Renamed all function as pwm_* instead of vlv_*
>> >> - Call intel_panel_actually_set_backlight in enable function
>> >> - Return -ENODEV in case pwm_get fails
>> >> - in case pwm_config error return error cdoe from pwm_config
>> >> - Cleanup pwm in intel_panel_destroy_backlight
>> >>
>> >> CC: Samuel Ortiz
>> >> Cc: Linus Walleij
>> >> Cc: Alexandre Courbot
>> >> Cc: Thierry Reding
>> >> Signed-off-by: Shobhit Kumar
>> >> ---
>> >> drivers/gpu/drm/i915/intel_drv.h | 4 ++
>> >> drivers/gpu/drm/i915/intel_dsi.c | 6 +++
>> >> drivers/gpu/drm/i915/intel_panel.c | 95
>> >> --
>> >> 3 files changed, 100 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> >> b/drivers/gpu/drm/i915/intel_drv.h
>> >> index 2afb31a..561c17f 100644
>> >> --- a/drivers/gpu/drm/i915/intel_drv.h
>> >> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> >> @@ -182,6 +182,10 @@ struct intel_panel {
>> >> bool enabled;
>> >> bool combination_mode; /* gen 2/4 only */
>> >> bool active_low_pwm;
>> >> +
>> >> + /* PWM chip */
>> >> + struct pwm_device *pwm;
>> >> +
>> >> struct backlight_device *device;
>> >> } backlight;
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
>> >> b/drivers/gpu/drm/i915/intel_dsi.c
>> >> index c4db74a..be8722c 100644
>> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> >> @@ -402,6 +402,8 @@ static void intel_dsi_enable(struct intel_encoder
>> >> *encoder)
>> >>
>> >> intel_dsi_port_enable(encoder);
>> >> }
>> >> +
>> >> + intel_panel_enable_backlight(intel_dsi->attached_connector);
>> >> }
>> >>
>> >> static void intel_dsi_pre_enable(struct intel_encoder *encoder)
>> >> @@ -466,6 +468,8 @@ static void intel_dsi_pre_disable(struct
>> >> intel_encoder *encoder)
>> >>
>> >> DRM_DEBUG_KMS("\n");
>> >>
>> >> + intel_panel_disable_backlight(intel_dsi->attached_connector);
>> >> +
>> >> if (is_vid_mode(intel_dsi)) {
>> >> /* Send Shutdown command to the panel in LP mode */
>> >> for_each_dsi_port(port, intel_dsi->ports)
>> >> @@ -1132,6 +1136,8 @@ void intel_dsi_init(struct drm_device *dev)
>> >> }
>> >>
>> >> intel_panel_init(_connector->panel, fixed_mode, NULL);
>> >> + intel_panel_setup_backlight(connector,
>> >> + (intel_encoder->crtc_mask = (1 << PIPE_A)) ? PIPE_A :
>> >> PIPE_B);
>> > ^
>> >
>> > Whoops. But since the PWM backlight doesn't need the initial pipe for
>> > anything you can actually just pass INVALID_PIPE here.
>> >
>>
>> You are right, its unused, but I thought passing right value still
>> made sense. Otherwise it makes it look like I am setting up back-light
>> for invalid pipe, when the real meaning is something like
>> DONTCARE_PIPE
>
> Well it's not really about the pipe. It's about which set of BLC
> registers we're supoosed to use when using the BLC built into the
> display engine. And that's only done so that we take over the
> hardware state correctly. So INVALID_PIPE is just fine in this case
> since the backlight control has nothing to do with the pipe.
>
Ok, will update.
Regards
Shobhit
[Intel-gfx] [v2 4/7] mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM
On Tue, Jun 23, 2015 at 12:49 PM, Lee Jones wrote: > On Mon, 22 Jun 2015, Daniel Vetter wrote: > >> On Mon, Jun 22, 2015 at 04:33:22PM +0530, Varka Bhadram wrote: >> > Hi Shobhit Kumar, >> > >> > On 06/22/2015 04:24 PM, Shobhit Kumar wrote: >> > >> > >On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup >> > >entry for the same to be used by the consumer (Intel GFX) >> > > >> > >v2: Remove the lookup table on driver unload (Thierry) >> > > >> > >v3: Correct the subject line (Lee jones) >> > >> > This part should only describe what this is about.. >> > >> > Don't put this patch change history over here. >> > Include this change history after >> > ... >> > Signed-off-by: Author >> > --- >> > >> > >CC: Samuel Ortiz >> > >Cc: Linus Walleij >> > >Cc: Alexandre Courbot >> > >Cc: Thierry Reding >> > >Acked-by: Lee Jones >> > >Signed-off-by: Shobhit Kumar >> > >--- >> > >> > Here you add this change history so that after applying this >> > will not be the part of your commit description. >> > >> > This comment is applicable for all of your patches. >> >> It's honestly a per-maintainer thing and hard to tell who wants what ... >> Personally I do want to include the patch changelog in the commit message. > > The patch change-log should go below the '---'. There are very few > (weird ;) ) Maintainers who like to see them in the commit log. To satisfy everybody, for the last two patches for intel-gfx, I will keep the version history as is, for others, I will move it down as suggested. Will push all again as new series after addressing all comments. Regards Shobhit > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead > Linaro.org â Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v2 7/7] drm/i915: Backlight control using CRC PMIC based PWM driver
On Thu, Jun 25, 2015 at 2:18 PM, Ville Syrjälä
wrote:
> On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
>> Use the CRC PWM device in intel_panel.c and add new MIPI backlight
>> specififc callbacks
>>
>> v2: Modify to use pwm_config callback
>> v3: Addressed Jani's comments
>> - Renamed all function as pwm_* instead of vlv_*
>> - Call intel_panel_actually_set_backlight in enable function
>> - Return -ENODEV in case pwm_get fails
>> - in case pwm_config error return error cdoe from pwm_config
>> - Cleanup pwm in intel_panel_destroy_backlight
>>
>> CC: Samuel Ortiz
>> Cc: Linus Walleij
>> Cc: Alexandre Courbot
>> Cc: Thierry Reding
>> Signed-off-by: Shobhit Kumar
>> ---
>> drivers/gpu/drm/i915/intel_drv.h | 4 ++
>> drivers/gpu/drm/i915/intel_dsi.c | 6 +++
>> drivers/gpu/drm/i915/intel_panel.c | 95
>> --
>> 3 files changed, 100 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index 2afb31a..561c17f 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -182,6 +182,10 @@ struct intel_panel {
>> bool enabled;
>> bool combination_mode; /* gen 2/4 only */
>> bool active_low_pwm;
>> +
>> + /* PWM chip */
>> + struct pwm_device *pwm;
>> +
>> struct backlight_device *device;
>> } backlight;
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
>> b/drivers/gpu/drm/i915/intel_dsi.c
>> index c4db74a..be8722c 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> @@ -402,6 +402,8 @@ static void intel_dsi_enable(struct intel_encoder
>> *encoder)
>>
>> intel_dsi_port_enable(encoder);
>> }
>> +
>> + intel_panel_enable_backlight(intel_dsi->attached_connector);
>> }
>>
>> static void intel_dsi_pre_enable(struct intel_encoder *encoder)
>> @@ -466,6 +468,8 @@ static void intel_dsi_pre_disable(struct intel_encoder
>> *encoder)
>>
>> DRM_DEBUG_KMS("\n");
>>
>> + intel_panel_disable_backlight(intel_dsi->attached_connector);
>> +
>> if (is_vid_mode(intel_dsi)) {
>> /* Send Shutdown command to the panel in LP mode */
>> for_each_dsi_port(port, intel_dsi->ports)
>> @@ -1132,6 +1136,8 @@ void intel_dsi_init(struct drm_device *dev)
>> }
>>
>> intel_panel_init(_connector->panel, fixed_mode, NULL);
>> + intel_panel_setup_backlight(connector,
>> + (intel_encoder->crtc_mask = (1 << PIPE_A)) ? PIPE_A : PIPE_B);
> ^
>
> Whoops. But since the PWM backlight doesn't need the initial pipe for
> anything you can actually just pass INVALID_PIPE here.
>
You are right, its unused, but I thought passing right value still
made sense. Otherwise it makes it look like I am setting up back-light
for invalid pipe, when the real meaning is something like
DONTCARE_PIPE
>>
>> return;
>>
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c
>> b/drivers/gpu/drm/i915/intel_panel.c
>> index 7d83527..2aa30db 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -32,8 +32,12 @@
>>
>> #include
>> #include
>> +#include
>> #include "intel_drv.h"
>>
>> +#define CRC_PMIC_PWM_PERIOD_NS 21333
>> +#define CRC_PMIC_PWM_STEPS 255
>
> This define appears to be unused.
>
Yeah, missed removing it.
>> +
>> void
>> intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
>> struct drm_display_mode *adjusted_mode)
>> @@ -544,6 +548,15 @@ static u32 bxt_get_backlight(struct intel_connector
>> *connector)
>> return I915_READ(BXT_BLC_PWM_DUTY1);
>> }
>>
>> +static u32 pwm_get_backlight(struct intel_connector *connector)
>> +{
>> + struct intel_panel *panel = >panel;
>> + int duty_ns;
>> +
>> + duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
>> + return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
>> +}
>> +
>> static u32 intel_panel_get_backlight(struct intel_connector *connector)
>> {
>> struct drm_device *dev = connector->base.dev;
>> @@ -632,6 +645,14 @@ static void bxt_set_backlight(struct intel_connector
>> *connector, u32 level)
>> I915_WRITE(BXT_BLC_PWM_DUTY1, level);
>> }
>>
>> +static void pwm_set_backlight(struct intel_connector *connector, u32 level)
>> +{
>> + struct intel_panel *panel = >panel;
>> + int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
>> +
>> + pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
>> +}
>> +
>> static void
>> intel_panel_actually_set_backlight(struct intel_connector *connector, u32
>> level)
>> {
>> @@ -769,6 +790,16 @@ static void bxt_disable_backlight(struct
>> intel_connector *connector)
>> I915_WRITE(BXT_BLC_PWM_CTL1, tmp & ~BXT_BLC_PWM_ENABLE);
>> }
>>
>> +static
[PATCH 3/3] drm/msm/mdp5: Add plane blending operation support for MDP5(V2)
This change is to add properties alpha/zpos/blend_mode to mdp5 plane
for alpha blending operation to generate the blended output.
V1: Initial change
V2: Change "premultilied" property to enum (Rob's comment)
Signed-off-by: Jilai Wang
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 110 ++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 66 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 32 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 16 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 124 +++---
drivers/gpu/drm/msm/msm_drv.h | 10 +++
6 files changed, 273 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index dea3d2e..e6e53b8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -160,7 +160,7 @@ static void complete_flip(struct drm_crtc *crtc, struct
drm_file *file)
if (mdp5_crtc->ctl && !crtc->state->enable) {
/* set STAGE_UNUSED for all layers */
- mdp5_ctl_blend(mdp5_crtc->ctl, mdp5_crtc->lm, 0x);
+ mdp5_ctl_blend(mdp5_crtc->ctl, mdp5_crtc->lm, NULL, 0, 0);
mdp5_ctl_release(mdp5_crtc->ctl);
mdp5_crtc->ctl = NULL;
}
@@ -196,13 +196,9 @@ static bool mdp5_crtc_mode_fixup(struct drm_crtc *crtc,
/*
* blend_setup() - blend all the planes of a CRTC
*
- * When border is enabled, the border color will ALWAYS be the base layer.
- * Therefore, the first plane (private RGB pipe) will start at STAGE0.
- * If disabled, the first plane starts at STAGE_BASE.
- *
- * Note:
- * Border is not enabled here because the private plane is exactly
- * the CRTC resolution.
+ * If no base layer is available, border will be enabled as the base layer.
+ * Otherwise all layers will be blended based on their stage calculated
+ * in mdp5_crtc_atomic_check.
*/
static void blend_setup(struct drm_crtc *crtc)
{
@@ -210,9 +206,14 @@ static void blend_setup(struct drm_crtc *crtc)
struct mdp5_kms *mdp5_kms = get_kms(crtc);
struct drm_plane *plane;
const struct mdp5_cfg_hw *hw_cfg;
- uint32_t lm = mdp5_crtc->lm, blend_cfg = 0;
+ struct mdp5_plane_state *pstate, *pstates[STAGE_MAX + 1] = {NULL};
+ const struct mdp_format *format;
+ uint32_t lm = mdp5_crtc->lm;
+ uint32_t blend_op, fg_alpha, bg_alpha, ctl_blend_flags = 0;
unsigned long flags;
-#define blender(stage) ((stage) - STAGE_BASE)
+ uint8_t stage[STAGE_MAX + 1];
+ int i, plane_cnt = 0;
+#define blender(stage) ((stage) - STAGE0)
hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
@@ -222,33 +223,73 @@ static void blend_setup(struct drm_crtc *crtc)
if (!mdp5_crtc->ctl)
goto out;
+ /* Collect all plane information */
drm_atomic_crtc_for_each_plane(plane, crtc) {
- enum mdp_mixer_stage_id stage =
- to_mdp5_plane_state(plane->state)->stage;
+ pstate = to_mdp5_plane_state(plane->state);
+ pstates[pstate->stage] = pstate;
+ stage[pstate->stage] = mdp5_plane_pipe(plane);
+ plane_cnt++;
+ }
- /*
-* Note: This cannot happen with current implementation but
-* we need to check this condition once z property is added
-*/
- BUG_ON(stage > hw_cfg->lm.nb_stages);
+ /*
+ * If there is no base layer, enable border color.
+ * Although it's not possbile in current blend logic,
+ * put it here as a reminder.
+ */
+ if (!pstates[STAGE_BASE] && plane_cnt) {
+ ctl_blend_flags |= MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT;
+ DBG("Border Color is enabled");
+ }
- /* LM */
- mdp5_write(mdp5_kms,
- REG_MDP5_LM_BLEND_OP_MODE(lm, blender(stage)),
- MDP5_LM_BLEND_OP_MODE_FG_ALPHA(FG_CONST) |
- MDP5_LM_BLEND_OP_MODE_BG_ALPHA(BG_CONST));
+ /* The reset for blending */
+ for (i = STAGE0; i <= STAGE_MAX; i++) {
+ if (!pstates[i])
+ continue;
+
+ format = to_mdp_format(
+ msm_framebuffer_format(pstates[i]->base.fb));
+ plane = pstates[i]->base.plane;
+ blend_op = MDP5_LM_BLEND_OP_MODE_FG_ALPHA(FG_CONST) |
+ MDP5_LM_BLEND_OP_MODE_BG_ALPHA(BG_CONST);
+ fg_alpha = pstates[i]->alpha;
+ bg_alpha = 0xFF - pstates[i]->alpha;
+ DBG("Stage %d fg_alpha %x bg_alpha %x", i, fg_alpha, bg_alpha);
+
+ if (format->alpha_enable && pstates[i]->premultiplied) {
+ blend_op = MDP5_LM_BLEND_OP_MODE_FG_ALPHA(FG_CONST) |
+
[PATCH 1/3] drm/doc: Add description of drm properties in msm(V2)
Add plane properties "premultiplied/zpos/alpha" used in msm MDP
driver to perform proper blending operation.
V1: Initial change
V2: Change "premultiplied" property to enum (Rob's comment)
Signed-off-by: Jilai Wang
---
Documentation/DocBook/drm.tmpl | 23 +++
1 file changed, 23 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 109fde8..d9f5613 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3500,6 +3500,29 @@ void intel_crt_init(struct drm_device *dev)
Plane
TBD
+
+ msm
+ Generic
+ "premultiplied"
+ ENUM
+ { "false", "true" }
+ Plane
+ property to indicate the framebuffer used by this
plane is alpha pre-multiplied
+
+
+ "alpha"
+ RANGE
+ Min=0, Max=255
+ Plane
+ property to set plane's global alpha value
+
+
+ "zpos"
+ RANGE
+ Min=1, Max=255
+ Plane
+ property to set plane's z position during
blending
+
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Color management in DRM framework
Gentle reminder for the review and comments. For those who prefer having the design available with the mail, I am attaching a PDF copy of the design document with this mail. It would be great for us to hear from you guys, on this. Regards Shashank From: Sharma, Shashank Sent: Monday, June 22, 2015 7:09 PM To: robdclark at gmail.com; alexander.deucher at amd.com; bskeggs at redhat.com; dri-devel at lists.freedesktop.org Cc: Smith, Gary K; Barnes, Jesse; Lespiau, Damien; Roper, Matthew D; Vetter, Daniel; Bhattacharjee, Susanta; Matheson, Annie J; Malladi, Kausal; Mukherjee, Indranil; Kamath, Sunil; Pillai, Manikandan K; Palleti, Avinash Reddy; R, Dhanya p Subject: Color management in DRM framework Hi Rob, Alex, Ben, All :) I am Shashank Sharma, from Linux display team Intel, Bangalore. We are planning to add a color management extension in the existing I915 driver, for Intel HWs. Plan was to provide a color correction and enhancement interface for any Linux based userspace, based on various HW capabilities. We are now thinking that if we can generalize this implementation, in such a way that other drivers can also utilize this, this idea can act as an extension to the DRM framework itself. Based on that thought, We have prepared a design for the same, and a rough implementation based on this design. Would you all be kind enough to have a look at this design, and give us some feedback, so that we can implement this in a way best suitable to most of the drivers ? We have gone through few rounds of design discussions internally (design contributors, reviewers in CC), and we all are moreover agree on the design (few comments still in progress). The highlights of the design: 1. The color correction capabilities of a HW are being registered as a DRM property of a CRTC / Plane (depending on a HW) 2. Properties will be of blob type. 3. New data structures will be added in DRM layer, to encoder and decode color correction and enhancement data. 4. The color correction DRM properties would look like : a. Palette correction / programming based color properties (like gamma correction). This can support various coefficients counts and correction values, based on the underneath HW. b. Color transformation matrix based color correction (CSC, wide and narrow gamut mapping) c. Plane level corrections like gamma correction, hue, saturation, contrast and brightness. d. One blob type property to showcase the color correction capabilities to the userspace, superset of all other color correction properties. 5. The driver's init function can create the superset color property, and show its color capabilities to the userspace. 6. Userspace can query the current color correction Or apply a new color correction using a set/get property interface. Please find the detailed design, in this shared google document: https://docs.google.com/document/d/1jyfNSAStKHEpmIUZd_1Gd68cPuyiyr8wmJXThSDb_2w/ Please feel free to add more people in the design discussion, once we have some basic agreement on the design, we will share the patches in dri-devel level. Regards Shashank -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/da920a31/attachment-0001.html> -- next part -- A non-text attachment was scrubbed... Name: Design-Color-Management-for-DRI-Devel.pdf Type: application/pdf Size: 748812 bytes Desc: Design-Color-Management-for-DRI-Devel.pdf URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/da920a31/attachment-0001.pdf>
[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon
https://bugs.freedesktop.org/show_bug.cgi?id=91041 --- Comment #6 from robotbuilderfiletransfer at gmail.com --- occures* -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/03a91721/attachment.html>
[Intel-gfx] [v2 7/7] drm/i915: Backlight control using CRC PMIC based PWM driver
On Thu, Jun 25, 2015 at 05:38:50PM +0530, Shobhit Kumar wrote:
> On Thu, Jun 25, 2015 at 2:18 PM, Ville Syrjälä
> wrote:
> > On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
> >> Use the CRC PWM device in intel_panel.c and add new MIPI backlight
> >> specififc callbacks
> >>
> >> v2: Modify to use pwm_config callback
> >> v3: Addressed Jani's comments
> >> - Renamed all function as pwm_* instead of vlv_*
> >> - Call intel_panel_actually_set_backlight in enable function
> >> - Return -ENODEV in case pwm_get fails
> >> - in case pwm_config error return error cdoe from pwm_config
> >> - Cleanup pwm in intel_panel_destroy_backlight
> >>
> >> CC: Samuel Ortiz
> >> Cc: Linus Walleij
> >> Cc: Alexandre Courbot
> >> Cc: Thierry Reding
> >> Signed-off-by: Shobhit Kumar
> >> ---
> >> drivers/gpu/drm/i915/intel_drv.h | 4 ++
> >> drivers/gpu/drm/i915/intel_dsi.c | 6 +++
> >> drivers/gpu/drm/i915/intel_panel.c | 95
> >> --
> >> 3 files changed, 100 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >> b/drivers/gpu/drm/i915/intel_drv.h
> >> index 2afb31a..561c17f 100644
> >> --- a/drivers/gpu/drm/i915/intel_drv.h
> >> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >> @@ -182,6 +182,10 @@ struct intel_panel {
> >> bool enabled;
> >> bool combination_mode; /* gen 2/4 only */
> >> bool active_low_pwm;
> >> +
> >> + /* PWM chip */
> >> + struct pwm_device *pwm;
> >> +
> >> struct backlight_device *device;
> >> } backlight;
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> index c4db74a..be8722c 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> @@ -402,6 +402,8 @@ static void intel_dsi_enable(struct intel_encoder
> >> *encoder)
> >>
> >> intel_dsi_port_enable(encoder);
> >> }
> >> +
> >> + intel_panel_enable_backlight(intel_dsi->attached_connector);
> >> }
> >>
> >> static void intel_dsi_pre_enable(struct intel_encoder *encoder)
> >> @@ -466,6 +468,8 @@ static void intel_dsi_pre_disable(struct intel_encoder
> >> *encoder)
> >>
> >> DRM_DEBUG_KMS("\n");
> >>
> >> + intel_panel_disable_backlight(intel_dsi->attached_connector);
> >> +
> >> if (is_vid_mode(intel_dsi)) {
> >> /* Send Shutdown command to the panel in LP mode */
> >> for_each_dsi_port(port, intel_dsi->ports)
> >> @@ -1132,6 +1136,8 @@ void intel_dsi_init(struct drm_device *dev)
> >> }
> >>
> >> intel_panel_init(_connector->panel, fixed_mode, NULL);
> >> + intel_panel_setup_backlight(connector,
> >> + (intel_encoder->crtc_mask = (1 << PIPE_A)) ? PIPE_A :
> >> PIPE_B);
> > ^
> >
> > Whoops. But since the PWM backlight doesn't need the initial pipe for
> > anything you can actually just pass INVALID_PIPE here.
> >
>
> You are right, its unused, but I thought passing right value still
> made sense. Otherwise it makes it look like I am setting up back-light
> for invalid pipe, when the real meaning is something like
> DONTCARE_PIPE
Well it's not really about the pipe. It's about which set of BLC
registers we're supoosed to use when using the BLC built into the
display engine. And that's only done so that we take over the
hardware state correctly. So INVALID_PIPE is just fine in this case
since the backlight control has nothing to do with the pipe.
--
Ville Syrjälä
Intel OTC
[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon
https://bugs.freedesktop.org/show_bug.cgi?id=91041 --- Comment #5 from robotbuilderfiletransfer at gmail.com --- (In reply to Alex Deucher from comment #2) > Is this still an issue with a newer kernel? Please attach your xorg log and > dmesg output. I have upgraded to the latest linux kernel version: 4.0.6-1, and the bug still occurres. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/8f6a427d/attachment.html>
[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon
https://bugs.freedesktop.org/show_bug.cgi?id=91041 --- Comment #4 from robotbuilderfiletransfer at gmail.com --- Created attachment 116717 --> https://bugs.freedesktop.org/attachment.cgi?id=116717=edit xorg log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/292d0e89/attachment.html>
[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon
https://bugs.freedesktop.org/show_bug.cgi?id=91041 --- Comment #3 from robotbuilderfiletransfer at gmail.com --- Created attachment 116716 --> https://bugs.freedesktop.org/attachment.cgi?id=116716=edit dmesg output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/7c13de82/attachment.html>
[PATCH] drm/exynos: iommu: fix potential NULL pointer dereference
Some drivers (like Exynos mixer) calls drm_iommu_attach_device_if_possible
before registering crtc, so additional check for NULL crtc pointer is
required.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
index d4ec7465e9cc..d4eb730ba254 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
@@ -151,7 +151,7 @@ int drm_iommu_attach_device_if_possible(struct
exynos_drm_crtc *exynos_crtc,
int ret = 0;
if (is_drm_iommu_supported(drm_dev)) {
- if (exynos_crtc->ops->clear_channels)
+ if (exynos_crtc && exynos_crtc->ops->clear_channels)
exynos_crtc->ops->clear_channels(exynos_crtc);
return drm_iommu_attach_device(drm_dev, subdrv_dev);
}
--
1.9.2
[Bug 91107] [Radeonsi/290x] In the Dota2 Reborn beta only half on the ingame GUI is rendered
https://bugs.freedesktop.org/show_bug.cgi?id=91107 --- Comment #1 from Christoph Haag --- In case not everyone looks at the linked issue report: I see the "half" issue and heavy flickering on my 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] (rev ff) but not on my 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) Here is a video of the issue: https://www.youtube.com/watch?v=vPxaC_pFD-o and here is a shorter and a slightly longer apitrace: http://haagch.frickel.club/files/dota2.trace.xz http://haagch.frickel.club/files/dota2-longer.trace.xz The traces work on intel, but are broken on radeonsi. Interestingly the "in game" rendering in replays of the traces doen't work on either driver, but it works when actually running the game. So far I have only tested with latest mesa git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/f3e11c8c/attachment.html>
[Intel-gfx] [v2 7/7] drm/i915: Backlight control using CRC PMIC based PWM driver
On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
> Use the CRC PWM device in intel_panel.c and add new MIPI backlight
> specififc callbacks
>
> v2: Modify to use pwm_config callback
> v3: Addressed Jani's comments
> - Renamed all function as pwm_* instead of vlv_*
> - Call intel_panel_actually_set_backlight in enable function
> - Return -ENODEV in case pwm_get fails
> - in case pwm_config error return error cdoe from pwm_config
> - Cleanup pwm in intel_panel_destroy_backlight
>
> CC: Samuel Ortiz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/i915/intel_drv.h | 4 ++
> drivers/gpu/drm/i915/intel_dsi.c | 6 +++
> drivers/gpu/drm/i915/intel_panel.c | 95
> --
> 3 files changed, 100 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 2afb31a..561c17f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -182,6 +182,10 @@ struct intel_panel {
> bool enabled;
> bool combination_mode; /* gen 2/4 only */
> bool active_low_pwm;
> +
> + /* PWM chip */
> + struct pwm_device *pwm;
> +
> struct backlight_device *device;
> } backlight;
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index c4db74a..be8722c 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -402,6 +402,8 @@ static void intel_dsi_enable(struct intel_encoder
> *encoder)
>
> intel_dsi_port_enable(encoder);
> }
> +
> + intel_panel_enable_backlight(intel_dsi->attached_connector);
> }
>
> static void intel_dsi_pre_enable(struct intel_encoder *encoder)
> @@ -466,6 +468,8 @@ static void intel_dsi_pre_disable(struct intel_encoder
> *encoder)
>
> DRM_DEBUG_KMS("\n");
>
> + intel_panel_disable_backlight(intel_dsi->attached_connector);
> +
> if (is_vid_mode(intel_dsi)) {
> /* Send Shutdown command to the panel in LP mode */
> for_each_dsi_port(port, intel_dsi->ports)
> @@ -1132,6 +1136,8 @@ void intel_dsi_init(struct drm_device *dev)
> }
>
> intel_panel_init(_connector->panel, fixed_mode, NULL);
> + intel_panel_setup_backlight(connector,
> + (intel_encoder->crtc_mask = (1 << PIPE_A)) ? PIPE_A : PIPE_B);
^
Whoops. But since the PWM backlight doesn't need the initial pipe for
anything you can actually just pass INVALID_PIPE here.
>
> return;
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 7d83527..2aa30db 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -32,8 +32,12 @@
>
> #include
> #include
> +#include
> #include "intel_drv.h"
>
> +#define CRC_PMIC_PWM_PERIOD_NS 21333
> +#define CRC_PMIC_PWM_STEPS 255
This define appears to be unused.
> +
> void
> intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
> struct drm_display_mode *adjusted_mode)
> @@ -544,6 +548,15 @@ static u32 bxt_get_backlight(struct intel_connector
> *connector)
> return I915_READ(BXT_BLC_PWM_DUTY1);
> }
>
> +static u32 pwm_get_backlight(struct intel_connector *connector)
> +{
> + struct intel_panel *panel = >panel;
> + int duty_ns;
> +
> + duty_ns = pwm_get_duty_cycle(panel->backlight.pwm);
> + return DIV_ROUND_UP(duty_ns * 100, CRC_PMIC_PWM_PERIOD_NS);
> +}
> +
> static u32 intel_panel_get_backlight(struct intel_connector *connector)
> {
> struct drm_device *dev = connector->base.dev;
> @@ -632,6 +645,14 @@ static void bxt_set_backlight(struct intel_connector
> *connector, u32 level)
> I915_WRITE(BXT_BLC_PWM_DUTY1, level);
> }
>
> +static void pwm_set_backlight(struct intel_connector *connector, u32 level)
> +{
> + struct intel_panel *panel = >panel;
> + int duty_ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100);
> +
> + pwm_config(panel->backlight.pwm, duty_ns, CRC_PMIC_PWM_PERIOD_NS);
> +}
> +
> static void
> intel_panel_actually_set_backlight(struct intel_connector *connector, u32
> level)
> {
> @@ -769,6 +790,16 @@ static void bxt_disable_backlight(struct intel_connector
> *connector)
> I915_WRITE(BXT_BLC_PWM_CTL1, tmp & ~BXT_BLC_PWM_ENABLE);
> }
>
> +static void pwm_disable_backlight(struct intel_connector *connector)
> +{
> + struct intel_panel *panel = >panel;
> +
> + /* Disable the backlight */
> + pwm_config(panel->backlight.pwm, 0, CRC_PMIC_PWM_PERIOD_NS);
> + usleep_range(2000, 3000);
> + pwm_disable(panel->backlight.pwm);
> +}
> +
> void intel_panel_disable_backlight(struct intel_connector *connector)
> {
> struct drm_device *dev =
[PATCH 2/2] drm/msm/dsi: Report PHY errors only when they really occur
DSI PHY errors are falsely reported whenever a dsi error occurs. This is
because DSI_DLN0_PHY_ERR isn't only used as a status register, but also
used to mask PHY errors. Currently, we end up reading the mask bits too
and therefore always report errors.
Ignore the register mask bits and check for only the status/clear bits.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 932efab..5bc9544 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1260,7 +1260,11 @@ static void dsi_dln0_phy_err(struct msm_dsi_host
*msm_host)
status = dsi_read(msm_host, REG_DSI_DLN0_PHY_ERR);
- if (status) {
+ if (status & (DSI_DLN0_PHY_ERR_DLN0_ERR_ESC |
+ DSI_DLN0_PHY_ERR_DLN0_ERR_SYNC_ESC |
+ DSI_DLN0_PHY_ERR_DLN0_ERR_CONTROL |
+ DSI_DLN0_PHY_ERR_DLN0_ERR_CONTENTION_LP0 |
+ DSI_DLN0_PHY_ERR_DLN0_ERR_CONTENTION_LP1)) {
dsi_write(msm_host, REG_DSI_DLN0_PHY_ERR, status);
msm_host->err_work_state |= DSI_ERR_STATE_DLN0_PHY;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 1/2] drm/msm/dsi: Update generated headers with DSI_DLN0_PHY_ERR bitfields
Add bitfieds in DSI_DLN0_PHY_ERR which are used to report and clear errors. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/dsi/dsi.xml.h | 18 +++--- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h b/drivers/gpu/drm/msm/dsi/dsi.xml.h index 9791ea0..ccfa374 100644 --- a/drivers/gpu/drm/msm/dsi/dsi.xml.h +++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h @@ -8,17 +8,8 @@ http://github.com/freedreno/envytools/ git clone https://github.com/freedreno/envytools.git The rules-ng-ng source files this header was generated from are: -- /home/robclark/src/freedreno/envytools/rnndb/msm.xml ( 676 bytes, from 2014-12-05 15:34:49) -- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml ( 1453 bytes, from 2013-03-31 16:51:27) -- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml( 20915 bytes, from 2015-03-24 22:05:22) -- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml ( 2352 bytes, from 2015-04-12 15:02:42) -- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml( 35083 bytes, from 2015-04-12 15:04:03) -- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml ( 22094 bytes, from 2015-05-12 12:45:23) -- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml( 344 bytes, from 2013-08-11 19:26:32) -- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml ( 1686 bytes, from 2014-10-31 16:48:57) -- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml ( 600 bytes, from 2013-07-05 19:21:12) -- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml ( 29012 bytes, from 2015-05-12 12:45:23) -- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml ( 10416 bytes, from 2015-05-12 12:45:23) +- /local/mnt/workspace/source_trees/envytools/rnndb/../rnndb/dsi/dsi.xml( 22421 bytes, from 2015-06-25 05:24:08) +- /local/mnt/workspace/source_trees/envytools/rnndb/freedreno_copyright.xml ( 1453 bytes, from 2015-02-09 03:18:10) Copyright (C) 2013-2015 by the following authors: - Rob Clark (robclark) @@ -382,6 +373,11 @@ static inline uint32_t DSI_TRIG_CTRL_STREAM(uint32_t val) #define REG_DSI_TRIG_DMA 0x008c #define REG_DSI_DLN0_PHY_ERR 0x00b0 +#define DSI_DLN0_PHY_ERR_DLN0_ERR_ESC 0x0001 +#define DSI_DLN0_PHY_ERR_DLN0_ERR_SYNC_ESC 0x0010 +#define DSI_DLN0_PHY_ERR_DLN0_ERR_CONTROL 0x0100 +#define DSI_DLN0_PHY_ERR_DLN0_ERR_CONTENTION_LP0 0x1000 +#define DSI_DLN0_PHY_ERR_DLN0_ERR_CONTENTION_LP1 0x0001 #define REG_DSI_TIMEOUT_STATUS 0x00bc -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH] rnndb/dsi: Add error related bitfields for DSI_DLN0_PHY_ERR
Add error related bitfields for DLN0_PHY_ERR. These are needed by the driver when handling errors. Signed-off-by: Archit Taneja --- rnndb/dsi/dsi.xml | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/rnndb/dsi/dsi.xml b/rnndb/dsi/dsi.xml index d19bea9..8aa139e 100644 --- a/rnndb/dsi/dsi.xml +++ b/rnndb/dsi/dsi.xml @@ -177,7 +177,13 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> - + + + + + + + -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/2] drm/radeon: SDMA fix hibernation (CI GPU family).
On Fri, Jun 19, 2015 at 10:32 AM, wrote: > From: Jérôme Glisse > > In order for hibernation to reliably work we need to properly turn > off the SDMA block, sadly after numerous attemps i haven't not found > proper sequence for clean and full shutdown. So simply reset both > SDMA block, this makes hibernation works reliably on sea island GPU > family (CI) > > Hibernation and suspend to ram were tested (several times) on : > Bonaire > Hawaii > Mullins > Kaveri > Kabini > > Cc: stable at vger.kernel.org > Signed-off-by: Jérôme Glisse > Reviewed-by: Christian König Applied the series. thanks! Alex > --- > drivers/gpu/drm/radeon/cik_sdma.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/radeon/cik_sdma.c > b/drivers/gpu/drm/radeon/cik_sdma.c > index f86eb54..d16f2ee 100644 > --- a/drivers/gpu/drm/radeon/cik_sdma.c > +++ b/drivers/gpu/drm/radeon/cik_sdma.c > @@ -268,6 +268,17 @@ static void cik_sdma_gfx_stop(struct radeon_device *rdev) > } > rdev->ring[R600_RING_TYPE_DMA_INDEX].ready = false; > rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX].ready = false; > + > + /* FIXME use something else than big hammer but after few days can not > +* seem to find good combination so reset SDMA blocks as it seems we > +* do not shut them down properly. This fix hibernation and does not > +* affect suspend to ram. > +*/ > + WREG32(SRBM_SOFT_RESET, SOFT_RESET_SDMA | SOFT_RESET_SDMA1); > + (void)RREG32(SRBM_SOFT_RESET); > + udelay(50); > + WREG32(SRBM_SOFT_RESET, 0); > + (void)RREG32(SRBM_SOFT_RESET); > } > > /** > -- > 2.1.0 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Nouveau] [PATCH v2 0/6] Improve GK20A support, introduce GM20B, firmware paths
On 23 June 2015 at 16:16, Alexandre Courbot wrote: > Second version of this patchset. Not many changes since first version - I hope > this means the changes are not too controversial. > > Changes since v1: > - Removed lookup for previous FW files in "nouveau/" > - Went back to using request_firmware() since we only try to load one file Hey Alex, I've merged this in my tree as-is for the moment, hopefully to go to Linus for the next merge window. If there's any changes from you guys on how you want the firmware to be handled, it'd be nice to have those made concrete before then :) Thanks, Ben. > > Original cover letter follows: > > GM20B is the GPU of the upcoming Tegra X1 SoC. This series adds initial > support > for it, based on a rework of the already-supported GK20A. It also introduces > support for NVIDIA-provided firmware files, which is why I have added a few > NVIDIA people who are relevant to this discussion. > > The first patch adds support for loading the FECS and GPCCS firmwares from > firmware files officially released by NVIDIA. As you know such firmwares will > soon become a necessity for newer GPUs because some falcons will require > signed > firmware to operate. In addition there is no reverse-engineered version of the > GK20A firmwares yet, so since an external file is needed anyway, it may as > well > be provided officially. NVIDIA plans to release firmwares as one file per > binary > to keep things simple. The layout will be nvidia//.bin, so for > GK20A FECS/GPCCS we have: > > nvidia/gk20a/fecs_inst.bin (aka fuc409c) > nvidia/gk20a/fecs_data.bin (aka fuc409d) > nvidia/gk20a/gpccs_inst.bin (aka fuc41ac) > nvidia/gk20a/gpccs_data.bin (aka fuc41ad) > > All firmware files listed in this patchset are clean for release, and I am > just > waiting for a community ack of the layout to send a patch to linux-firmware. > > The second patch reworks existing GK20A support to make it closer to what our > nvgpu driver does. Support so far was heavily based on GK104, which somehow > made > me feel uneasy - and quite scared after I looked more closely at what nvgpu > does. In particular the GK104 MMIO bundles differed significantly from what > nvgpu does. This change aligns things and (probably less significant, but > still > safer) reorders the initialization sequence to match the one of nvgpu. > > You will note that the MMIO bundles now come as firmware files of their own. I > am not sure the community will be pleased with an increase of firmware files, > however the rationale for this is as follows: > - These initialization sequences are related to the firmwares, so it makes > sense > to distribute them under the same medium > - If NVIDIA needs to update the firmwares for some reason, it can atomically > update the MMIO bundles and provide a coherent set, instead of having to > introduce versioning into the firmware and driver > - For IP reasons, I as an NVIDIA employee cannot extract these register > sequences and link them into Nouveau > - These are just a bunch of register address/value pairs anyway > > The new firmware files introduced are: > > nvidia/gk20a/sw_nonctx.bin (gr_pack_mmio) > nvidia/gk20a/sw_ctx.bin (grctx_pack_hub, grctx_pack_gpc, grctx_pack_zcull, > grctx_pack_tpc, grctx_pack_ppc) > nvidia/gk20a/sw_bundle_init.bin (grctx_pack_icmd) > nvidia/gk20a/sw_method_init.bin (grctx_pack_mthd) > > Third patch is trivial and adds the GM20B FIFO device. > > Fourth patch adds GM20B GR based on the reworked GK20A support. GM20B will > rely > on the same firmware files as GK20A (also clean for release). Note that this > is > not full support yet for released devices, which will require secure boot. > This > will be my focus once this patchset is merged (Deepak got a working version, > but there is still a lot of work to do on it before it is upstreamable). > > The last two patches recognize GM20B at the device and platform level. Nothing > really exciting. > > I hope the addition of firmware files will not become too controversial. If it > does, I have good arguments to support it. ;) Besides the GK20A rework that > probably few people care about, the point is the addition of a basic layout > for > the firmwares that NVIDIA will officially release to finally support secure > boot, and I would like to make sure we get this right. > > Alexandre Courbot (6): > gr: use NVIDIA-provided external firmwares > gr/gk20a: use same initialization sequence as nvgpu > fifo: add GM20B fifo > gr: add GM20B support > device: recognize GM20B > platform: recognize GM20B > > drm/nouveau/include/nvkm/engine/fifo.h | 1 + > drm/nouveau/include/nvkm/engine/gr.h | 1 + > drm/nouveau/nouveau_platform.c | 1 + > drm/nouveau/nvkm/engine/device/gm100.c | 20 ++ > drm/nouveau/nvkm/engine/fifo/Kbuild| 1 + > drm/nouveau/nvkm/engine/fifo/gk104.h | 4 + > drm/nouveau/nvkm/engine/fifo/gm204.c | 2 +- > drm/nouveau/nvkm/engine/fifo/gm20b.c
[Bug 91107] [Radeonsi/290x] In the Dota2 Reborn beta only half on the ingame GUI is rendered
https://bugs.freedesktop.org/show_bug.cgi?id=91107 Sebastian Parborg changed: What|Removed |Added Attachment #116713|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/01242544/attachment.html>
[Bug 91107] [Radeonsi/290x] In the Dota2 Reborn beta only half on the ingame GUI is rendered
https://bugs.freedesktop.org/show_bug.cgi?id=91107 Bug ID: 91107 Summary: [Radeonsi/290x] In the Dota2 Reborn beta only half on the ingame GUI is rendered Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: darkdefende at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 116713 --> https://bugs.freedesktop.org/attachment.cgi?id=116713=edit Picture of the hero pick screen When I try to play a bot match (and probably any other game type) in the dota2 reborn beta, only half of the ingame GUI is rendered. It seems to be that some textures only renders half of it's content. For example in the hero pick menu (see the attached png file) the "Repick" button should be a red cross. But now only half of it is shown. There also seems to be some z fighting issues as some ground textures flicker and the green/red dots on the minimap flickers sometimes also. I've opened a bug ticked on the official dota2 reborn bugtracker: https://github.com/ValveSoftware/Dota-2-Reborn/issues/79 It seems like this might only be a problem with Hawaii cards. I'm running Gentoo Linux with kernel 4.1.0 and git versions (checked out as of today, jun 25) of mesa, xorg, llvm etc. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/9c56cb39/attachment.html>
[PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver
Hi, Jianwei, I used to write FB driver for DCU. I think this DRM driver is good. Reviewed-by: Alison Wang Best Regards, Alison Wang > -Original Message- > From: Wang Jianwei-B52261 > Sent: Tuesday, June 23, 2015 3:50 PM > To: Wang Jianwei-B52261; airlied at linux.ie; daniel.vetter at intel.com; > stefan at agner.ch; Wood Scott-B07421; dri-devel at lists.freedesktop.org > Cc: linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; > Jin Zhengxiong-R64188; Wang Huan-B18965; Xiubo Li > Subject: RE: [PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM > driver > > Hi all, > > Anybody have any comments for this series of patches? Any comments are > welcomed. They had been send out for more than two monthes. Thanks. > > BR. > Jianwei > > > -Original Message- > > From: Jianwei Wang [mailto:jianwei.wang at freescale.com] > > Sent: Friday, April 17, 2015 2:36 PM > > To: airlied at linux.ie; daniel.vetter at intel.com; stefan at agner.ch; > > Wood > > Scott-B07421; dri-devel at lists.freedesktop.org > > Cc: linux-kernel at vger.kernel.org; linux-arm- > kernel at lists.infradead.org; > > Jin Zhengxiong-R64188; Wang Jianwei-B52261; Wang Huan-B18965; Xiubo > Li; > > Wang Jianwei-B52261 > > Subject: [PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver > > > > From: Jianwei Wang > > > > This patch add support for Two Dimensional Animation and Compositing > > Engine (2D-ACE) on the Freescale SoCs. > > > > 2D-ACE is a Freescale display controller. 2D-ACE describes the > > functionality of the module extremely well its name is a value that > cannot > > be used as a token in programming languages. > > Instead the valid token "DCU" is used to tag the register names and > > function names. > > > > The Display Controller Unit (DCU) module is a system master that > fetches > > graphics stored in internal or external memory and displays them on a > TFT > > LCD panel. A wide range of panel sizes is supported and the timing of > the > > interface signals is highly configurable. > > Graphics are read directly from memory and then blended in real-time, > > which allows for dynamic content creation with minimal CPU > intervention. > > > > The features: > > (1) Full RGB888 output to TFT LCD panel. > > (2) For the current LCD panel, WQVGA "480x272" is supported. > > (3) Blending of each pixel using up to 4 source layers dependent on > size > > of panel. > > (4) Each graphic layer can be placed with one pixel resolution in > either > > axis. > > (5) Each graphic layer support RGB565 and RGB888 direct colors > without > > alpha channel and BGRA BGRA ARGB1555 direct colors with an > alpha > > channel and YUV422 format. > > (6) Each graphic layer support alpha blending with 8-bit resolution. > > > > This is a simplified version, only one primary plane, one framebuffer > > created for fbdev, one crtc, one connector for TFT LCD panel, an > encoder. > > > > Signed-off-by: Alison Wang > > Signed-off-by: Xiubo Li > > Signed-off-by: Jianwei Wang > > --- > > > > Changed in V5 > > > > - Update commit message > > - Add layer registers initialization > > - Remove unused functions > > - Rename driver folder > > - Move pixel clock control functions to fsl_dcu_drm_drv.c > > - remove redundant enable the clock implicitly using regmap > > - Add maintainer message > > > > Changed in V4: > > > > -This version doesn't have functionality changed Just a minor > adjustment. > > > > Changed in V3: > > > > - Test driver on Vybrid board and add compatible string > > - Remove unused functions > > - set default crtc for encoder > > - replace legacy functions with atomic help functions > > - Set the unique name of the DRM device > > - Implement irq handle function for vblank interrupt > > > > Changed in v2: > > - Add atomic support > > - Modify bindings file > > - Rename node for compatibility > > - Move platform related code out for compatibility > > > > .../devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt| 50 +++ > > MAINTAINERS| 8 + > > drivers/gpu/drm/Kconfig| 2 + > > drivers/gpu/drm/Makefile | 1 + > > drivers/gpu/drm/fsl-dcu/Kconfig| 17 + > > drivers/gpu/drm/fsl-dcu/Makefile | 7 + > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c| 194 +++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h| 30 ++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 172 ++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h | 22 ++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 373 > > + > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 223 > > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c| 26 ++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 42 +++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h | 17 + > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
randconfig build error with next-20150625, in drivers/gpu/drm/amd/amdgpu
Building with the attached random configuration file, ERROR: "amdgpu_debugfs_regs_cleanup" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: "amdgpu_debugfs_regs_init" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! -- next part -- # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.1.0 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # # RCU Subsystem # CONFIG_TINY_RCU=y CONFIG_RCU_EXPERT=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_KTHREAD_PRIO=0 # CONFIG_RCU_EXPEDITE_BOOT is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y # CONFIG_MEMCG_KMEM is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_SCHED_AUTOGROUP=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_LTO_MENU=y CONFIG_LTO_DISABLE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y # CONFIG_EXPERT is not set CONFIG_MULTIUSER=y CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y # CONFIG_BPF_SYSCALL is not set CONFIG_SHMEM=y
[Nouveau] [PATCH v2 0/6] Improve GK20A support, introduce GM20B, firmware paths
On 06/25/2015 08:59 AM, Ben Skeggs wrote: > On 23 June 2015 at 16:16, Alexandre Courbot wrote: >> Second version of this patchset. Not many changes since first version - I >> hope >> this means the changes are not too controversial. >> >> Changes since v1: >> - Removed lookup for previous FW files in "nouveau/" >> - Went back to using request_firmware() since we only try to load one file > Hey Alex, > > I've merged this in my tree as-is for the moment, hopefully to go to > Linus for the next merge window. If there's any changes from you guys > on how you want the firmware to be handled, it'd be nice to have those > made concrete before then :) Excellent, that will give us a short grace period. Thanks Ben! :)
[Bug 91084] RadeonSI crash while playing World Of Tanks
https://bugs.freedesktop.org/show_bug.cgi?id=91084 --- Comment #6 from Eduards Bezverhijs --- Well, might be, once I tried posting to that bug as well, but with rather incomplete info, now I have a lot more and it didn't look like that bug, albeit the reason for bug might be the same. Suggest plz how to proceed further, repost everything to that bug, or ... ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/278013d2/attachment.html>
[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)
https://bugs.freedesktop.org/show_bug.cgi?id=90537 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Michel Dänzer --- Fixed with https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.1.y=3bc980bf19bb62007e923691fa2869ba113be895 (in the 4.1 release) and http://cgit.freedesktop.org/mesa/mesa/commit/?id=7796e8889a9a2cc1b454dc32d8da3d756404339a . -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/32dca758/attachment.html>
[Bug 91084] RadeonSI crash while playing World Of Tanks
https://bugs.freedesktop.org/show_bug.cgi?id=91084 --- Comment #5 from Michel Dänzer --- If you're using the Gallium nine state tracker, this may be a duplicate of bug 89713. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150625/14275332/attachment.html>
[PATCH] scripts/kernel-doc: Adding cross-reference links to html documentation.
On Wed, Jun 24, 2015 at 04:10:24PM -0300, Danilo Cesar Lemes de Paula wrote: > Functions, Structs and Parameters definitions on kernel documentation > are pure cosmetic, it only highlights the element. > > To ease the navigation in the documentation we should use inside > those tags so readers can easily jump between methods directly. > > This was discussed in 2014[1] and is implemented by getting a list > of from the DocBook XML to generate a database. Then it looks > for , and tags that matches the ones in > the database. As it only links existent references, no broken links are > added. > > [1] - lists.freedesktop.org/archives/dri-devel/2014-August/065404.html > > Signed-off-by: Danilo Cesar Lemes de Paula > Cc: Randy Dunlap > Cc: Daniel Vetter > Cc: Laurent Pinchart > Cc: linux-doc at vger.kernel.org > Cc: intel-gfx > Cc: dri-devel > --- > To understand a bit more of what this patch is trying to acomplish you can > find > two examples of the old and new htmldocs outputs: > OLD: > https://people.collabora.com/~danilo/intel/Documentation.old/DocBook/drm/API-drm-crtc-vblank-on.html > NEW: > https://people.collabora.com/~danilo/intel/Documentation.new/DocBook/drm/API-drm-crtc-vblank-on.html Already discussed on irc With Danilo but here for the record: I really like this since it massively improves the usefulness of the docbooks we have. One small thing I noticed though while clicking a bit more through the generated html: It also generates selflinks, i.e. drm_crtc_vblank_on links to itself. That one is a bit confusing. Could we filter out self-links somehow on the reference sections? -Daniel > > Documentation/DocBook/Makefile | 34 +--- > scripts/kernel-doc-xml-ref | 176 > + > 2 files changed, 197 insertions(+), 13 deletions(-) > create mode 100755 scripts/kernel-doc-xml-ref > > diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile > index b6a6a2e..8aea45a 100644 > --- a/Documentation/DocBook/Makefile > +++ b/Documentation/DocBook/Makefile > @@ -64,8 +64,9 @@ installmandocs: mandocs > > ### > #External programs used > -KERNELDOC = $(srctree)/scripts/kernel-doc > -DOCPROC = $(objtree)/scripts/docproc > +KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref > +KERNELDOC = $(srctree)/scripts/kernel-doc > +DOCPROC = $(objtree)/scripts/docproc > > XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl > XMLTOFLAGS += --skip-validation > @@ -89,7 +90,7 @@ define rule_docproc > ) > $(dir $@).$(notdir $@).cmd > endef > > -%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE > +%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE > $(call if_changed_rule,docproc) > > # Tell kbuild to always build the programs > @@ -139,8 +140,12 @@ quiet_cmd_db2html = HTML$@ >cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< > && \ > echo ' \ > $(patsubst %.html,%,$(notdir $@))' > $@ > +%.aux.xml: %.xml > + @rm -rf $@ > + (cat $< | egrep "^ > $<.db) > + $(KERNELDOCXMLREF) -db $<.db $< > $@ > > -%.html: %.xml > +%.html: %.aux.xml > @(which xmlto > /dev/null 2>&1) || \ >(echo "*** You need to install xmlto ***"; \ > exit 1) > @@ -209,15 +214,18 @@ dochelp: > ### > # Temporary files left by various tools > clean-files := $(DOCBOOKS) \ > - $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \ > - $(patsubst %.xml, %.aux, $(DOCBOOKS)) \ > - $(patsubst %.xml, %.tex, $(DOCBOOKS)) \ > - $(patsubst %.xml, %.log, $(DOCBOOKS)) \ > - $(patsubst %.xml, %.out, $(DOCBOOKS)) \ > - $(patsubst %.xml, %.ps, $(DOCBOOKS)) \ > - $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ > - $(patsubst %.xml, %.html, $(DOCBOOKS)) \ > - $(patsubst %.xml, %.9,$(DOCBOOKS)) \ > + $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \ > + $(patsubst %.xml, %.aux, $(DOCBOOKS)) \ > + $(patsubst %.xml, %.tex, $(DOCBOOKS)) \ > + $(patsubst %.xml, %.log, $(DOCBOOKS)) \ > + $(patsubst %.xml, %.out, $(DOCBOOKS)) \ > + $(patsubst %.xml, %.ps, $(DOCBOOKS)) \ > + $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ > + $(patsubst %.xml, %.html,$(DOCBOOKS)) \ > + $(patsubst %.xml, %.9, $(DOCBOOKS)) \ > + $(patsubst %.xml, %.aux.xml, $(DOCBOOKS)) \ > + $(patsubst %.xml, %.xml.db, $(DOCBOOKS)) \ > + $(patsubst %.xml, %.xml, $(DOCBOOKS)) \ > $(index) > > clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man > diff --git a/scripts/kernel-doc-xml-ref b/scripts/kernel-doc-xml-ref > new file mode 100755 > index 000..756e897 > --- /dev/null > +++ b/scripts/kernel-doc-xml-ref > @@ -0,0 +1,176 @@ > +#!/usr/bin/perl -w > + > +use strict; > + > +## Copyright (C) 2015 Intel Corporation ## > +### > +## This software falls under the GNU General Public License.
